Every requirement, traced

A5.2.2 left the requirements numbered, so each is a single statement a reviewer can run a check against. A trace adds one more thing to each line: the user story it exists to serve. In the Portal's brief, every requirement ends with a bracket — [US: F6.1-USn] — naming that story. The bracket is the difference between a list of checks and a list of accountable checks. Each line of work now points back to a reason it exists, and forward to the check that closes it.

The link runs both ways. Forward: a requirement names the story, so a reviewer reading the requirement knows what user need it serves. Backward: every user story should have at least one requirement carrying its id, so no story is left unbuilt. A requirement can serve more than one story — F6.1-R4 serves three — and that is the trace doing its job, recording that one slice of work satisfies several needs at once.

Traceability earns its keep on the requirement that has no story. Number a list and you can check each line; trace a list and you can also find the line that should not be there. Toggle the figure below: as the brief ships, all eight requirements carry a story, so the untraced count is zero. Inject a ninth requirement with no [US: …] bracket, and the readout flags it — the agent would build work no story asked for, and the reviewer would have no check to close it against.

The flag is the point. An untraced requirement is not a small omission to fix later; it is a decision that escaped the spec. Either it serves a real need — in which case the story is missing and should be written — or it serves none, and the requirement should be dropped. The trace forces that question before the agent runs, not after it has built something the Operator never asked for.

The densest trace in the Portal's web brief is F6.1-R4, the controller requirement. One requirement, three stories — it renders a user's courses, holds the boundary by calling only the facade, and fails soft with a 422 render. The check that closes it is a controller test over Portal.courses_of/1 plus the master-invariant grep. The thinnest trace is the master invariant itself, F6.1-R7: one story, one runnable check — an empty grep.

# f6.1.llms.md — Requirements (each line ends with the story it serves)
  F6.1-R1  the Endpoint plug stack + the LiveView socket                       [US: F6.1-US1]
  F6.1-R3  the :browser pipeline + get "/courses/:user_id"                   [US: F6.1-US2]
  F6.1-R4  the controller calls only Portal.courses_of/1; error renders 422  [US: F6.1-US2, F6.1-US3, F6.1-US5]
  F6.1-R7  no Portal.Engine / Repo / GenServer.call under apps/portal_web/lib/  [US: F6.1-US3]
  F6.1-R8  expected failure renders 422 not 500; the endpoint restarts         [US: F6.1-US4, F6.1-US5]
#
# Each [US: …] is the trace. R4 serves three stories; R7 serves one and closes on an empty grep.
# A requirement with no [US: …] would be flagged — work no story asked for.

Across A5.2 the brief's first two parts took shape: References first (the sources read before any requirement), then requirements that are numbered (each a single checkable line), and now traced (each accountable to a story and a check). A list that is referenced, numbered, and traced leaves nothing the agent must do implicit and nothing a reviewer must take on trust. The next part of the brief is the third: the execution topology — the runtime shape, the build order, and the file list the agent assembles.

Primary sources for tracing requirements back to user needs and forward to checks, and where these requirements are built and the user stories they trace to are defined in the course.