diagramslisted

Condensed binding of Part 4's architecture-diagram section and the diagram halves of Parts 3, 5, 6 and 8b. On any conflict the edition wins; load it with `bash "${CLAUDE_PLUGIN_ROOT}/scripts/part.sh" 4`. Type references load on demand, only when you are drawing that type: `${CLAUDE_PLUGIN_ROOT}/skills/diagrams/references/flowchart.md`, `${CLAUDE_PLUGIN_ROOT}/skills/diagrams/references/sequence.md`, `${CLAUDE_PLUGIN_ROOT}/skills/diagrams/references/state.md`, `${CLAUDE_PLUGIN_ROOT}/skills/diagrams/references/er-and-class.md`, `${CLAUDE_PLUGIN_ROOT}/skills/diagrams/references/comparison.md`. **The switch, first, because everything mechanical below depends on it.** A project is opted in when `docs/diagrams/` exists in the tree; then the close checks in "At close" run. Absent, they do not run at all and the project behaves exactly as it did before the diagram half existed. Opting in is a chore of its own, never a side effect of an upgrade. - **When to draw.** A diagram earns its place when a cold reader sees a mechanism they would otherwise assemble from prose. If a sentence says it faster, write the sentence. - **What to draw.** The MECHANISM, not its name: the path a request takes, the boundary crossed, the hop added, the data that moves. As much as the decision turns on and no more. Comparing options: draw the DIFFERENCE, side by side, never two labeled boxes. One figure, one claim; a second claim is a second figure. - **What a diagram may not do.** A diagram is