Terminal Diagrams

Step 1: Define the rendering contract

1. IDENTIFY architecture | schema | topology | process | dependency graph | state machine | table | repair.
2. RECORD target environment (markdown_code_block or ansi_terminal), charset (unicode or ascii), maximum canvas columns, width profile, alignment, flow direction, node hierarchy, edge directions/labels, required emphasis, and whether every canvas row or only named rectangular components must share a width.
3. COPY assets/layout-request.json when the request is structured; validate its shape against assets/layout-request.schema.json before layout.
4. READ references/width-model.md before measuring non-ASCII labels or adding ANSI.
5. CHOOSE Mermaid/SVG instead when exact graph routing or browser-native scaling matters more than terminal fidelity; keep text diagrams for genuine terminal/Markdown output.

Completion: target, character repertoire, cell-width policy, canvas bound, components, and edge semantics are explicit.

Step 2: Normalize the semantic graph

1. LIST nodes with stable IDs, labels, body rows, border emphasis, and optional style.
2. LIST directed, reverse, bidirectional, and undirected edges with source, target, label, and required route.
3. COLLAPSE decorative nodes that add no semantic distinction; group repeated siblings only when the grouping remains clear.
4. ORDER nodes by reading flow and dependencies. Use top-to-bottom for sequences/hierarchies and left-to-right for compact pipelines.
5. BREAK cycles with a clearly labeled return edge; never imply direction solely through placement or color.