devsecops-traceabilitylisted

# DevSecOps Traceability Create one explainable chain from intent to outcome. Traceability is a decision aid, not paperwork: every link should help prove coverage, investigate change impact or recover evidence. ## Workflow 1. Inspect the repository and local conventions before proposing identifiers. Identify existing IDs, issue references, branch/commit conventions, test reports and release metadata. 2. Define scope, owners, retention and the direction of traceability: backward (why does this exist?) and forward (what proves it works?). 3. Normalize or preserve existing IDs. Do not rename IDs casually; document aliases when migration is necessary. 4. Build a matrix linking request/bug -> requirement/use case -> design/ADR/threat -> code/change -> test -> artifact/release -> deployment/incident/documentation. 5. Mark each relation as `verified`, `inferred`, `missing` or `conflicting`; never silently fill gaps. 6. Recommend the smallest correction, then validate links against actual files, metadata or reports. ## Default identifiers Use a repository-approved prefix where one exists. Otherwise use stable IDs such as `FR-*` (feature request), `BUG-*`, `REQ-*`, `UC-*`, `SEC-*`, `ADR-*`, `TC-*`, `TS-*`, `REL-*`, `INC-*` and `DOC-*`. IDs must be unique, human-readable and independent from line numbers. ## Required output ```markdown # Traceability Report ## Scope and assumptions ## Identifier policy ## Traceability matrix | Source ID | Artifact/type | Links | Status | Evidenc