35 lines
1.6 KiB
Markdown
35 lines
1.6 KiB
Markdown
# Photo Pipeline documentation
|
|
|
|
One local application that takes a photo library from discovery to a verified Immich
|
|
upload: duplicate detection, safety review, content analysis, album naming, guarded
|
|
renaming, upload, and archive — one visible, resume-safe workflow.
|
|
|
|
These pages are readable three ways, and they are the same files each time: in the
|
|
repository under `docs/`, on Gitea, and inside the running application under
|
|
**Docs**. There is no separate copy to fall out of date.
|
|
|
|
## Read in this order
|
|
|
|
1. [Overview](overview.md) — what the application does, the stages it moves a photo
|
|
through, and the rules it will not break.
|
|
2. [Installation and operations](installation.md) — host and container installation,
|
|
every setting, the first-run checklist, upgrades, backup and restore, and what
|
|
each refusal at startup means.
|
|
|
|
## Being written
|
|
|
|
The remaining manuals are accepted work, not aspiration; each is a story in
|
|
[E09](https://git.domverse-berlin.eu/domverse/photoanalyzer/src/branch/main/delivery_backlog/E09-documentation.md)
|
|
and will appear here as it lands.
|
|
|
|
- **Architecture** — context and runtime diagrams, the module map, the job and
|
|
journal state machines, and where each invariant is enforced (US09-03).
|
|
- **User manual** — one page per workflow stage with screenshots of the real
|
|
application, and a catalogue of every error and refusal (US09-04).
|
|
|
|
## Conventions
|
|
|
|
A page tells you what a stage **changes on disk or on the server** before it tells
|
|
you how to run it. Refusals are documented as intentional: this application would
|
|
rather stop and explain than guess about somebody's photographs.
|