US08-05: Automate Container Deployment Acceptance (#100)

README.md

@@ -241,6 +241,40 @@ image. The stack is managed by Portainer from git (`docker-compose.yml`), and th
 values live in the Portainer stack's environment, so rotation is one place and a
 repository read discloses nothing. A test asserts the workflows never name them.
 
+## Container acceptance gate (US08-05)
+
+The deployed container is verified the way the host application is, by one command:
+
+```bash
+work_item/scripts/python -m photo_pipeline container-gate --output gate-evidence
+```
+
+It builds the image, provisions the composition against a **temporary fixture library
+on a bind mount and an isolated data volume**, runs the `phase_h` journeys against it,
+destroys every stack afterwards, and writes `release-report.json`, `logs/container.log`,
+and `CHECKSUMS.sha256` into the evidence directory. It exits non-zero when a journey
+fails, when the story matrix has a hole, **or when any check skipped at all** — unlike
+the release gate, this one accepts no environment excuse: a run that never reached the
+containers proved nothing about them.
+
+The journeys (`tests/e2e/test_phase_h_container.py`) are:
+
+| journey | what it proves |
+|---|---|
+| browser | discovery, duplicate review, analysis, album proposal, rename, upload preflight, and archive views, driven through the containerized frontend — including a rename that really moves the operator's folder on the bind mount |
+| upgrade | the previous version's image runs first, then this one against the same volume: schema at the new head, assets, analysis results, job progress, the unapplied rename plan, and the thumbnail cache all survive |
+| restart | `docker kill` on both containers mid-job; the job resumes, every photo ends with exactly one stored result, and only the in-flight item ever reaches the provider twice |
+| security | no session refused, a forged `X-Forwarded-Host` cannot smuggle an allowed hostname past the check, a symlink out of the mounted library is refused, an unmounted library root refuses startup, and no secret appears in `docker compose logs` |
+
+The upgrade journey builds the previous commit's tree when no published image is named;
+point it at the real one with `PHOTO_PIPELINE_PREVIOUS_IMAGE`. On a Docker VM (Colima,
+Docker Desktop) the fixture library must live on a shared path — it defaults to
+`~/.cache/photo-pipeline`, overridable with `PHOTO_PIPELINE_TEST_MOUNT_BASE`.
+
+CI runs this gate as the `container` job of **Test** on pushes to `main` and keeps its
+evidence as a run artefact. Deploy waits for the whole `Test` workflow, so a red
+container gate is a publish that does not happen.
+
 ## Testing
 
 One offline command runs the whole suite (unit, integration, and browser