domverse
792134c72d
Adds the installation manual, architecture overview, and illustrated user manual as a five-story epic, plus the acceptance gate that keeps them true. The documentation is markdown under docs/, so the same files are readable in the repository and rendered by the deployed application at /app/#/docs. An operator who was handed a URL and an access secret has no repository checkout in front of them, and the network the application is deployed to is not assumed to reach a CDN. Two decisions are recorded in the epic rather than left to implementation: - The renderer is vendored (marked), not written and not fetched. - Diagrams are mermaid, rendered client-side, with script-src untouched. Whether mermaid needs 'unsafe-eval' was measured rather than assumed: its bundle contains no eval( and no new Function, and rendered under this application's exact CSP it produced an SVG with no script-src violation. What it does violate is style-src, which gains 'unsafe-inline'. With script-src, img-src, connect-src, and font-src all unchanged, that leaves defacement rather than execution or exfiltration. The alternative -- pre-rendering diagrams to committed SVG with the already-installed Playwright -- is recorded as the migration if that trade is ever refused. Screenshots are generated from the running application, never pasted, and every documented setting, command, exit code, error code, and state is cross-checked against the code that implements it, so stale documentation fails a test instead of misleading an operator. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015csGY8XV1M92fHfKnMmjtu
55 lines
2.7 KiB
Markdown
55 lines
2.7 KiB
Markdown
# Integrated Photo Pipeline Delivery Backlog
|
|
|
|
This backlog decomposes the phases in
|
|
[`INTEGRATED_PIPELINE_CONCEPT.md`](../INTEGRATED_PIPELINE_CONCEPT.md) into seven
|
|
epics and small, independently verifiable user stories, plus two delivery-format
|
|
epics: E08 packages the released application as a deployable container, and E09
|
|
documents it for the people who install, operate, and use it.
|
|
|
|
## Numbering and file naming
|
|
|
|
- Epics: `E01` through `E07`, matching concept Phases A through G; `E08` and `E09`
|
|
have no concept phase and must not change product scope.
|
|
- Stories: `US<epic>-<sequence>`, for example `US03-02`.
|
|
- Epic files: `E01-<slug>.md`.
|
|
- Story files: `stories/US01-01-<slug>.md`.
|
|
- IDs are permanent. Renaming or reordering a story must not reuse its ID.
|
|
|
|
## Delivery rules
|
|
|
|
- Implement epics in numeric order unless an epic explicitly permits overlap.
|
|
- A story should produce one coherent, reviewable outcome and be small enough for one
|
|
focused implementation change.
|
|
- Donor-first migration is mandatory: characterize and extract useful CLI behavior
|
|
before replacing it. Record provenance in the donor ledger.
|
|
- Every implementation story includes automated unit, property, golden, contract, or
|
|
integration tests appropriate to its risk.
|
|
- Every epic ends with a dedicated automated end-to-end story that exercises the real
|
|
browser, API/SSE, worker, isolated database, and temporary fixture library.
|
|
- A story is complete only when all acceptance criteria and automated tests pass with
|
|
no unexplained skips. An epic is complete only when its cumulative regression suite
|
|
and end-to-end gate pass.
|
|
|
|
## Epics
|
|
|
|
1. [E01 — Shared identity and inventory](E01-shared-identity-inventory.md)
|
|
2. [E02 — Unified workflow shell](E02-unified-workflow-shell.md)
|
|
3. [E03 — Album proposals](E03-album-proposals.md)
|
|
4. [E04 — Guarded renaming](E04-guarded-renaming.md)
|
|
5. [E05 — Immich upload](E05-immich-upload.md)
|
|
6. [E06 — Archive lifecycle](E06-archive-lifecycle.md)
|
|
7. [E07 — Hardening and release](E07-hardening-release.md)
|
|
8. [E08 — Container deployment](E08-container-deployment.md)
|
|
9. [E09 — Product documentation](E09-documentation.md)
|
|
|
|
## Shared definition of done
|
|
|
|
- Acceptance criteria are demonstrably satisfied.
|
|
- Public API/schema changes are documented and contract-tested.
|
|
- Database and filesystem mutations are restart-safe and idempotent where required.
|
|
- Paths are constrained by the shared library policy.
|
|
- No credentials or private image data appear in logs or browser responses.
|
|
- Relevant donor-ledger rows and story-to-test traceability entries are current.
|
|
- Automated tests pass locally and in CI; changed user behavior has an automated
|
|
acceptance test.
|