US01-01: Inventory and Characterize Donor Code
This commit is contained in:
41
AGENTS.md
41
AGENTS.md
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user