US01-01: Inventory and Characterize Donor Code

This commit is contained in:
2026-07-13 16:42:51 +02:00
parent 43ffde71da
commit a0e1752ff1
11 changed files with 646 additions and 13 deletions

View File

@@ -1,7 +1,20 @@
# Agent Instructions — Photo Analyzer
Read `CLAUDE.md` and `INTEGRATED_PIPELINE_CONCEPT.md` before implementation. Preserve
the established project invariants: never inspect or process content beneath any
`INTEGRATED_PIPELINE_CONCEPT.md` is the authoritative product and architecture
foundation for every user story. Before claiming or resuming implementation, read it
in full, then use it to interpret the story's scope, acceptance criteria, donor
strategy, architecture boundaries, safety invariants, fixture requirements, and test
obligations. Read `CLAUDE.md` as operational donor context after the concept. If an
issue, backlog Markdown file, or implementation idea conflicts with the concept, do
not silently follow the conflicting source: preserve the concept and stop for an
explicit decision when the conflict materially changes scope or behavior.
Re-read the complete concept whenever context has been compacted/lost, the concept has
changed since the story began, or an implementation session is resumed without a
reliable record that the current version was read. A summary, prior familiarity, or
reading only the story's phase is not sufficient.
Preserve the established project invariants: never inspect or process content beneath any
`_IGNORE/` directory; write verified EXIF before Immich upload; use managed
`immich-go` uploads rather than External Libraries; keep operations resume-safe; and
treat the existing CLI implementations as primary donors rather than rewriting them.
@@ -54,22 +67,26 @@ When asked to start, resume, or continue implementation, work from this isolated
repository and use `work_item/scripts/work-item`. Gitea issues and their dependencies
are the authoritative backlog.
1. Run `work_item/scripts/work-item claim`.
2. Run `work_item/scripts/work-item status` when resuming or whenever branch/state is
1. Read the current `INTEGRATED_PIPELINE_CONCEPT.md` completely and treat it as the
foundation for all decisions in the story. Then read `CLAUDE.md` for operational
donor context.
2. Run `work_item/scripts/work-item claim`.
3. Run `work_item/scripts/work-item status` when resuming or whenever branch/state is
uncertain. Work only on the claimed story and its generated feature branch.
3. Read the entire issue, linked specification, dependencies, and acceptance criteria.
4. Inspect the legacy CLI donors before replacing applicable behavior. Update the donor
4. Read the entire issue, linked specification, dependencies, and acceptance criteria.
Reconcile them with the concept before designing or changing code.
5. Inspect the legacy CLI donors before replacing applicable behavior. Update the donor
ledger and characterization tests required by the story.
5. Implement every acceptance criterion and its automated tests.
6. Run story-specific tests and the accumulated regression suite required by the epic.
7. Run `work_item/scripts/work-item submit --test "<story-specific command>"` without
6. Implement every acceptance criterion and its automated tests.
7. Run story-specific tests and the accumulated regression suite required by the epic.
8. Run `work_item/scripts/work-item submit --test "<story-specific command>"` without
`--yes` and review the reported diff and file list.
8. If the changes are correct and safe, rerun with `--yes`. This commits, pushes, opens
9. If the changes are correct and safe, rerun with `--yes`. This commits, pushes, opens
a pull request, records test evidence, and moves the issue to review.
9. After review and successful CI, run
10. After review and successful CI, run
`work_item/scripts/work-item complete --merge`. This verifies the merge, closes the
issue, returns to updated `main`, and removes the local feature branch.
10. Continue with the next eligible story by returning to step 1.
11. Continue with the next eligible story by returning to step 1.
If genuinely blocked, run
`work_item/scripts/work-item block --reason "<precise reason>"` and stop. Never skip to