# Traceability Map

## Operation

Create or refresh only the requested repository map. A map is a navigation index, not proof of correctness. Verify entries against current owners and preserve stable IDs. If the user asks for an explanation in chat, do not insist on writing a file.

## Goal

Create or update `docs/traceability_map.md` as the cross-reference from requirements, product decisions, invariants, docs, code owners, tests, release gates, and implementation workstreams.

## Inspect

Product docs, PRDs, README/design docs, issue text supplied by the user, existing maps, routes/components/API/jobs, schemas, tests, generated artifacts, release/deploy docs, migrations, feature flags, analytics events, and known audit outputs.

## Map content

### Evidence and IDs

- Write or update `docs/traceability_map.md` when possible. If writing is unavailable, print the complete markdown content in chat.
- Use stable IDs and preserve existing IDs: trace row `TRC-*`, requirement `REQ-*`, invariant `INV-*`, code owner `CODE-*`, test anchor `TEST-*`, release gate `REL-*`.
- A trace row must include direct evidence for each link when available; missing links are explicit gaps, not invented references.

### Coverage

Cover requirement → owner → implementation surfaces → API/data/runtime/auth contracts → tests → docs → release/rollout gates. Include acceptance coverage, stale docs, orphan code, orphan tests, missing tests, and decisions that lack owner evidence.

### Entry details

For each trace row, capture source requirement or decision, expected behavior, implementation owners, affected contracts, tests/checks, docs/maps, release gate, residual gaps, and recommended next prompt-skill.

## Markdown structure

Use summary, conventions, traceability matrix, orphaned requirements, orphaned code/tests/docs, acceptance gaps, release gates, unknowns, assumptions.