Write traced docs with diagrams and tables¶
TL;DR
Give each requirement and design element a heading that starts with its ID. Everything
under it, down to the next heading at the same or a higher level, is the item — sub-sections,
tables and diagrams included. Write its fields and links as Key: value lines anywhere in
that section, never in a table. Tables, diagrams and prose may name IDs; they declare nothing.
Steps¶
-
Start the item's heading with its ID. A section number before it, bold or backticks around it, and a Pandoc attribute after the title are layout, not part of the ID or the title:
### 1.1 REQ-RCH-01 — Registration under a supplied client ID {#req-registration} ### 1.2 **REQ-RCH-02** — Only a caller with the key registers ### 2.2 `DSN-RCH-02` — Key guardAn ID later in the heading —
## Key guard (DSN-RCH-02)— declares nothing. -
Structure the item under its heading as you like. A deeper heading —
#### Acceptance criteria,#### Flow— belongs to the item, and so do its tables and diagrams. They are the item's text: after a baseline, editing them is a change like rewording the statement. Renumbering the document is not. -
Write each field and link as a line in the item's section — right under the heading, or in a sub-section such as
#### Traceability:A
Satisfiescell in a table is not read. Nor is a line outside every item's section. -
Name IDs freely in tables, diagrams and prose — a summary of the requirements, a flow between elements. They link nothing. An ID of this repo's kind that nothing declares, later in a heading or at the start of a table row, is reported: it was probably meant as a declaration.
-
Plan test cases the same way, where the project keeps a Test Specification. A test case is a heading with its ID and a
verifies:line; the automated tests that run it name its ID, not the requirement: -
Check.
A design document written this way¶
It reads as an architecture guide, and every element in it is declared:
---
summary: The gateway's design, written to be traced.
---
# Gateway — design
## 1. Overview
```mermaid
flowchart LR
A[Agent] -->|register| K[Key guard] --> R[Registry]
```
## 2. Elements
### 2.1 DSN-RCH-01 — Agent registry {#dsn-registry}
Keeps one record per client ID; registering again refreshes the record.
#### 2.1.1 Flow
```mermaid
sequenceDiagram
Agent->>Registry: register(client_id)
Registry-->>Agent: 200, as just seen
```
#### 2.1.2 Traceability
Satisfies: REQ-RCH-01
### 2.2 `DSN-RCH-02` — Key guard
Checks the API key before any handler runs.
| Key | Status |
|---|---|
| missing | 401 |
| wrong | 401 |
- Satisfies: REQ-RCH-02
qmstrace check --strict in that repo:
read: 2 requirements, 2 design elements
result: 0 violations, 0 gaps in 4 items · 0 suspects (informational) · exit 0 · gate: gaps fail
When something is not read¶
Three slips in the same repo — the link to REQ-RCH-02 moved into the key guard's table, a
planned REQ-RCH-03 added to the summary table, and a heading that ends with (DSN-RCH-03):
read: 2 requirements, 2 design elements
violations — wrong at any stage; each fails the check:
V16 docs/design/gateway-design.md:42 DSN-RCH-03 is in this heading but not first, so it declares nothing — and nothing else declares it. Fix: to declare it, start a heading with it — `### DSN-RCH-03 — <title>`, a section number before it is fine — where a design element is read (docs/design/*.md); if the heading only names it, correct the ID. Never invent the item to make the ID resolve.
V16 docs/req/gateway-srs.md:36 REQ-RCH-03 starts a table row, but a table declares nothing — and nothing else declares it. Fix: to declare it, write a heading `### REQ-RCH-03 — <title>` where a requirement is read (docs/req/*-srs.md); if the row only lists it, correct the ID. Never invent the item to make the ID resolve.
gaps — coverage not met yet; only the gate (qmstrace check --strict) fails on them:
G05 docs/design/gateway-design.md:32 DSN-RCH-02: satisfies no requirement — every design element points back to one. Fix: the 'Satisfies' table row at docs/design/gateway-design.md:40 is not read — a table declares nothing; write `Satisfies: …` as a line in the item's section.
G01 docs/req/gateway-srs.md:21 REQ-RCH-02: no design element satisfies it yet. Fix: the 'Satisfies' table row at docs/design/gateway-design.md:40 is not read — a table declares nothing; write `Satisfies: …` as a line in the item's section.
result: 2 violations, 2 gaps in 4 items · 0 suspects (informational) · exit 1 · authoring: gaps do not fail — the gate is qmstrace check --strict
- The table row leaves two gaps, and both name it: the design element satisfies nothing, and the requirement has no design element. Write the link as a line in the section.
- An ID that nothing declares is
V16. Declare it as a heading where its kind is read — or, if it only names a planned item, take it out of the table until the item exists.
Not built yet
An ID named in prose or inside a diagram is not checked yet: one that exists nowhere passes silently. Only the forms above — later in a heading, first in a table row — are reported.