The requirements contract — validated upstream intake for the pipeline
Make work intake a **validated artifact instead of a conversation**. A requirement file (`.ana/requirements/REQ-<id>.md`) captures upstream intent — the problem, the evidence, what done looks like, priority — *before* any work item exists. `ana work status` surfaces open requirements; Think picks one up, skips re-interviewing the user about what and why, and redirects that energy into scrutiny. In the founder's words: "It has everything the engineering human on your team and the local Anas need to use the pipeline normally."
getRequirementsSummary counts validation-malformed requirements as open — `ana work status` reports 3 open while `ana req list` reports 1 open + 2 malformed for the same backlog
The `req list --json` emission path (runReqList) is never directly tested — A017/A018 are verified against buildRequirementList data, not the JSON mapping that reshapes malformed rows to {req, malformed, error}
@ana tag namespace collision in template-propagation.test.ts — pre-existing A029/A030 tags (a prior contract) coexist with this contract's A029/A030 in the same file; a naive tag scan could match the wrong test
obspackages/cli/src/commands/work.ts→ monitor
Archive-on-complete commit stages the whole `.ana/requirements/` dir (`git add .ana/requirements/`) rather than only the moved files — can sweep unrelated requirement edits into the completion commit
claimRequirement reads the requirement file twice (assertRequirementClaimable + claimRequirement each readFileSync the same path) — minor redundant IO, harmless in a single-process CLI