The chain

The chain is a set of small documents, plain JSON files in your own repository, each holding one kind of statement and a reference to the layer above it. Your agent authors and maintains them; you meet them in the tree viewer at review time. Top to bottom:

PRD    what you asked for
 └─ REQ    one capability the product must have
     └─ US + AC    a story of using it, with checks that define done
         └─ TS + TC    the tests that prove the checks
                └─ CN    the source files that implement them

TAD + TAC + ADR    the architecture and its decisions
BS + FBS           the ordered queue of build work

The requirements spine

The product statement (PRD). The root: the problem, who has it, what changes when it is solved, and what is out of scope. Without it, product intent lives in prompt history, and prompt history is not a spec. One per project; everything descends from it.

Requirements (REQ). One testable capability each, with a priority and a rationale. The layer forces something valuable: a wish like "search should be good" cannot survive here, because a requirement that cannot be verified by tests is treated as a requirement that needs splitting or sharpening. Vagueness is caught at the top, where it is cheap.

Stories and their checks (US and AC). A story is one person using one capability: who they are, what they want, why. Under each story sit its acceptance criteria: observable statements of done, each one a sentence someone could check. These checks are the currency of the whole method. Work is scoped to them, coverage is measured against them, tests point at them. When you push back at the review, this is the layer you are really editing.

Tests (TS and TC). Suites and cases, each case naming the check it verifies and pointing at the executable test that does the verifying. The pointer matters: a claim of "tested" that points at nothing is exactly the failure this layer exists to close, and the tooling refuses to count it.

The bridge to code (CN). Code Nodes tie source files, down to individual functions, to the checks they implement. Renaming or deleting a file that the chain depends on is caught the same way a broken reference between documents is. This is what makes "which code serves this requirement?" a query instead of an act of faith.

The technical side

Architecture (TAD, TAC, ADR). The architecture document is the root; under it, components describe the lasting parts of the system, and decision records hold each consequential choice: the context, the decision, the consequences, and the alternatives with the reason each was not chosen. The decision record is where a deferral lives too. When you tell your agent "I have not decided where this will be hosted", that answer is recorded here, visibly, instead of evaporating.

The work queue (BS and FBS). The build sequence orders the work, and each item in it is a build specification: one coherent slice of delivery, scoped to a named set of checks, with dependencies and a status. The queue is what your agent drives, item by item, through the build cycle.

Why it stays consistent

One structural rule keeps the chain from rotting: every reference points upward, from child to parent, and parents never hold lists of their children. Adding, moving or deleting a document touches exactly one file, so two files can never disagree about the same relationship. The downward view you see in the viewer is computed fresh from the upward references every time.

That is the shape. The full per-type specification, the one your agent actually authors against, ships inside the package and is published verbatim at the document model; the same material in reference form is at document types.