traceabilitylisted

# Traceability ## Purpose Make it possible to determine what implements and tests each Requirement, why code exists, and what a change affects. ## Trigger Run whenever traceable Artifacts are created/changed, before verification/Stage Gate, or when impact analysis lacks reliable links. ## Inputs - Artifact Registry and current revisions. - Requirements/use cases, design/models, architecture/ADRs, API/Contracts, Components, tasks, code, tests, findings, and release evidence. - Workflow Level, target, and existing trace links. ## Prerequisites - Each managed item has a stable ID or durable code/path reference. - Distinguish current revisions from superseded history. ## Procedure 1. Define target-relevant chain: `Requirement → Design → Architecture → API/Component → Task → Code → Test`. 2. Add optional use-case/domain/model/ADR/review/release links where they reduce risk. 3. Walk each Requirement forward and record implementation and verification coverage. 4. Walk each changed code/test item backward to a Requirement, decision, defect, maintenance rationale, or explicit technical necessity. 5. Validate link revisions and semantics; a path mention alone is not proof of satisfaction. 6. Mark coverage as complete, partial, missing, stale, conflicting, or not applicable with rationale. 7. Detect Requirements without design/implementation/tests, code without rationale, orphan tests, and model/code drift. 8. Update links after Change Impact and preserve superseded history. 9