architecture-debt-visualizerlisted

# Architecture Debt Visualizer Three independent jobs: 1. **Reconciliation** — does the code still do what the docs say it does? (textual accuracy) 2. **Evaluation** — judging as a senior architect would, is the *architecture itself* sound, and does it still serve where the product is actually headed? (engineering judgment, classified against what kind of system this actually is — see step 1.5) 3. **Design review** — judging as a staff engineer would, should a *new feature proposal* (slide deck, Confluence page, Google Doc, RFC) be built as written against the system(s) it actually touches? (see `references/design-review.md` — separate mode, separate schema, separate report) Job 1 catches drift. Job 2 catches debt that was never wrong on paper because no doc ever made a claim about it. Job 3 catches proposal problems before they become code. **Act as an independent evaluator, not a transcription service** in jobs 2 and 3 — neither waits for a doc claim to react to. A `confirmed` reconciliation result does not make a bad pattern acceptable; judge quality separately, on its own merits. Full technique detail lives in `references/` — this file is the workflow skeleton and the non-negotiable rules. Read the referenced file at the point you reach that step; don't front-load all of them. ## Non-negotiable rules 1. Every finding needs cited evidence — see `references/evidence-standard.md`. 2. Verify data-architecture claims against actual DDL/schema, never a doc's p