The real triad

The artifact table in specs.approach.md fixes what each file is. Reading it against F6.1 turns the abstract triad into three concrete documents, each with a scope, an audience, and a fixed set of sections.

f6.1.md is the spec: scope one rung, for an author and a reviewer, answering what & why & done across Goal, Rationale, Scope, Deliverables, Invariants, and the Definition of Done. Its Goal opens "After F6.1, the Portal runs as a Phoenix app". f6.1.stories.md is the stories: for product and QA, answering who wants what across five Connextra stories with Given/When/Then, ending with the Coverage line. f6.1.llms.md is the agent brief: for a coding agent, answering how to build it, with proof gates across References, Requirements, the execution topology, the agent stories, and the implementation prompt.

If the three files partition the rung cleanly, then every identifier the spec mints — a deliverable, an invariant, a story, the Coverage line, a requirement — lives in exactly one file. Select a real F6.1 id and the readout names the file that holds it and quotes what it says.

The deliverable F6.1-D6 and the invariant F6.1-INV1 are in the contract. The story F6.1-US2 and the Coverage line are in the stories. The requirement F6.1-R1 is in the brief. No id appears twice; reading one file gives a reviewer the whole of one side of the rung and none of the others.

On the Portal, the artifact table reads the same for every rung; F6.1 is the worked instance. Each row names a file, the question it answers, and the F6.1 content that fills it. The spec carries the contract, the stories carry the user's side and the Coverage line that closes it, the brief carries the requirements and the prompt an agent runs.

The fragment below is the artifact table, read against F6.1. It is markdown specification text, not code: the file in one colour, the question in a comment, the F6.1 content as the result. Three rows, three files, one rung.

# specs.approach.md — the artifact table, read against F6.1. (markdown, not code)
f6.1.md         # what & why & done      Goal · Rationale · Scope · Deliverables D1..D7 · Invariants INV1..INV5 · DoD
f6.1.stories.md # who wants what       US1..US5 (Connextra) · Given/When/Then · INVEST + encodes · Coverage line
f6.1.llms.md    # how to build, gated  References · Requirements R1..R8 · Execution topology · Agent stories · prompt

# One rung, three files — and every F6.1 id (D6, INV1, US2, R1, the Coverage line) sorts to one row.

F6.1's specification is three real files, each with a scope, an audience, and a fixed set of sections from the artifact table: the spec for the contract, the stories for the user's side, the brief for the agent. They cover the same rung from three sides with no overlap — every id lives in exactly one. The triad is not a Portal peculiarity; the closing dive shows the course holds itself to the same shape.

The sources behind the three-file triad, and where it connects in the course.