diagram-synclisted

# diagram-sync ## Premise An architecture diagram is a *rendering of the real module/import graph*, re-verified against that graph — never hand-drawn in a whiteboard tool, pasted in, and left to rot. A diagram that contradicts the code is worse than none: it teaches a wrong mental model with the authority of a picture, and readers trust it precisely because it looks deliberate. Cite-or-halt. Every node and edge in a generated diagram traces to a `<path>` (a module directory) or a `<path:line>` (the import / service call that creates the edge). Every DRIFT finding cites **the diagram element + the graph fact that contradicts it** — "box `PaymentGateway` in docs/architecture.md, no module resolves to it (deleted in `git log --diff-filter=D`)". "The diagram looks stale" is a vibe, not a finding. **Boundary — this skill does NOT build the dependency graph.** The module/import graph is produced by `code-quality`'s `architectural-diagnosis` skill and emitted to `ai/optimize/_dep-graph.json` (rows: `{from, to, layer_from, layer_to}`) plus `ai/optimize/_responsibility-map.md`. diagram-sync **consumes** that artifact and renders it. If the artifact is absent, halt and ask for an architectural-diagnosis run first — do not re-walk the source and reinvent a parallel, drifting graph. Rendering is this skill; graphing is that one. ## When to run - After a refactor that adds, removes, renames, or re-wires a module or service. - Before a release / design review — the diagram is the fir