The SDLC pipeline

Traceability

The matrix from requirement to feature, design component and test case — and where coverage is missing.

The Traceability step lays out, for every requirement, the design components that implement it and the test cases that verify it, and marks where a link is missing. It is the quickest step in the pipeline: there is no agent call at all. The bridge computes the matrix from the links the SRS, SDS and STS steps already recorded.

What you get

A Markdown document titled Traceability Matrix, written entirely by the bridge:

Section	Contents
Title block	Project, client, version, date.
Coverage Summary	A table of total requirements, how many are fully traced, and the coverage percentage — followed by a pie chart of requirements by trace status: "Design and tests", "Design only" and "No design".
Phase Gates	Three rows, each "Pass" or "Blocked" with the requirement ids holding it: Design → Test Planning, Test Planning → Estimate, Estimate → Proposal.
Traceability Matrix	One row per requirement: id, title, priority, design components, test cases, and its gap.

The run's completion message repeats the essentials in plain text: coverage, gaps by severity, and each gate's result.

Before you run it

The SDS must exist. It does not need to be approved. Until it exists, /traceability is locked with "Run /sds first".
The project state must hold a non-empty requirement list.

You can run it right after the SDS, before any test cases exist; the matrix then shows every requirement's test links as missing. Run it again after the STS for the full picture. It is not a reviewed step, so it is complete as soon as it is written, and you can re-run it at any time.

How it works

Drawing diagram…

Each requirement carries three sets of forward links, filled in by earlier steps: the SDS step adds the design components that implement it, and the STS step adds the test cases that verify it. The third set, cost line items, belonged to an estimate step that is not part of the current pipeline.

For each requirement the bridge works out its gap, taking the first missing link in this order:

Gap	Severity	Meaning
design	critical	No design component implements it.
test	high	It has a design but no test case.
cost	medium	It has design and tests but no cost line item.
—	—	Fully traced: all three links present.

Coverage is the average across requirements, where each requirement scores 0, 33, 67 or 100% for having none, one, two or all three kinds of link.

The phase gates look only at "must" requirements:

Gate	Blocked when a "must" requirement has no …
Design → Test Planning	design component
Test Planning → Estimate	test case
Estimate → Proposal	cost line item

The run panel shows: Checking project state, Computing the traceability matrix, Writing the Markdown document.

Ids this step owns

None. The matrix reads requirement ids (REQ-…), design component ids (DC-NNN) and test case ids (TC-NNN) created by the SRS, SDS and STS steps.

Reviewing it

There is no approval, but the matrix is the quickest way to spot a hole:

A design gap on any requirement means the design does not implement it. The SDS step's coverage check makes this rare; if you see one, the SDS may be older than the SRS — look for the "re-run, upstream changed" flag.
A test gap after the STS means a requirement slipped through test authoring. Request changes on the STS naming the requirement.
A requirement whose "won't have" priority kept it out of the design shows as a design gap here; that is expected.

Because the matrix is computed from the links in the project state, re-run it whenever you regenerate the SRS, SDS or STS.

When it fails

What you see	Why	What to do
`/traceability` locked: "Run /sds first"	There is no SDS yet.	Run `/sds`.
"artifacts.sds missing — run /sds first."	The project state has no SDS registered.	Run `/sds`.
"requirements[] is empty — run /srs first."	The project state has no requirements.	Run `/srs`.

Traceability makes no agent calls, so it cannot fail on the agent, and it costs nothing to run.

Under the hood

The driver is bridge/src/services/traceabilityPipeline.service.ts. It reads requirements[].traceForward from the project state and writes nothing else back except the document's registration.
The document is .sdlc/artifacts/traceability-vN.md, registered as artifacts.traceability. Because it is never approved, every run takes the next version number.
The SDS step separately keeps a traceabilityMatrix in the project state and a Requirements Traceability table in the SDS document; this step's matrix adds the test-case links on top.