Mermaid diagrams

Use a diagram when relationships, phases, or boundaries are easier to understand visually. Keep the surrounding explanation short. A simple edit or single fact usually needs only prose.

Establish the meaning

• Check the relevant implementation or design before drawing. State whether the diagram describes current behavior, a proposal, or a before/after comparison.
• Show the important relationships and major boundaries, not every function. Name subgraphs for the phases or boundaries they explain.
• Use solid arrows for implemented connections and dashed arrows for pending or unconnected integration. Label arrows with short verbs or conditions. Express asynchronous behavior in words rather than repurposing dashed arrows.
• Make blockers, missing connections, and out-of-scope work explicit. A proposed connection stays dashed even when its components already exist.
• Match claims to the evidence: implemented source does not by itself prove a working deployment. If that distinction matters, include it in the diagram or its caption. Do not infer a completed path from neighboring components.

Draw compactly

Use a native Markdown mermaid code block. Prefer flowchart TB; choose another diagram type when it better explains the relationship, such as sequence order. Keep any alternate notation's meaning clear in the caption.

For flowcharts, start from the flowchart template. Its sample behavior is illustrative; replace its nodes and connections with the actual subject.

• Enable htmlLabels: true in Mermaid's YAML frontmatter.
• Give nodes short bold headings with <b>...</b> and separate supporting lines with <br/>. Aim for roughly 15–25 characters per line and 2–3 lines per node where practical. Preserve precise names when shortening would obscure meaning.
• Avoid long single-line labels, fixed-width HTML containers, complex inline CSS, and excessive text. Split an overfull diagram into focused views.
• Use muted, desaturated fills with dark labels and thin borders; start with 1px strokes. Keep phase outlines neutral so they do not compete with the nodes. Define reusable classDef styles and reinforce color with words and line styles.
• Start with 14–16px text and balanced spacing. Set subGraphTitleMargin separately from node padding so phase headings have room above their nodes. Tune nodeSpacing and rankSpacing rather than adding empty label lines.
• Align parallel phases when practical. An extra hyphen on an existing solid arrow (--->) can span another layout rank without adding a relationship. Keep its meaning and endpoints unchanged; avoid inventing edges to force layout.

Color	Meaning
Blue	APIs, configuration, persisted state
Purple	Operator inputs, secrets, external dependencies
Teal	Processing, protected operations, implemented capabilities
Amber	Gates, blockers, conditions requiring attention
Gray with a dashed border	Pending or out-of-scope integration

Verify and report

Check that every edge reflects the relevant evidence and that labels distinguish implemented behavior from pending work. Keep confidential details out of diagrams destined for a public document or PR, just as in the surrounding text.

When available, render at the intended document width and inspect label contrast, phase-title clearance, node padding, large empty areas, and confusing crossings. Compare before/after views at the same viewport; a narrower SVG may be enlarged by its viewer. Prefer the destination's renderer; local rendering can differ from the published result. Adjust labels or layout when needed.

Report validation precisely: reviewing source text, passing a Mermaid syntax check, and visually inspecting a rendered diagram are separate checks. If rendering is unavailable, say so; do not describe the diagram as visually verified. Diagram checks do not establish runtime behavior.