diagramlisted

# diagram — draw the process, not the box list Draw **one picture that answers one question** about how something works, in the library the user asked for. A reader who never saw the code should be able to follow the process from the diagram plus a few lines of prose. Seventh sibling of **rewrite**, **refactor**, **reskin**, **audit**, **report** and **specify**. Same house discipline — draw what is actually there, state the limits, never invent a step to make the picture tidy — but the artefact is a diagram. The three failure modes it exists to prevent: - **The wall** — forty nodes, every one connected, nobody reads it. A diagram that needs zooming has already failed; it should have been three diagrams. - **The box list** — the bullet points redrawn as rectangles in a line. It carries no branch, no actor, no failure path, so it says nothing the sentence above it didn't. - **The invented step** — a box drawn because the flow looked incomplete without it. The reader now believes in code that does not exist. --- ## Invariants - **One diagram = one question (MUST).** The title *is* the question, answered: *"How a request becomes a rendered frame"*. If you cannot write that title, you do not know what you are drawing. - **Ten nodes, fifteen edges — hard cap (MUST).** Over the cap, split (see *Splitting*). Never shrink a diagram by deleting a real branch; that is lying, not simplifying. - **Every branch edge is labelled.** A decision with unlabelled arrows is a co