design-graphlisted

# Design Graph — The Artifact A **Design Graph** is the annotated call graph of a concrete problem. It is what you produce when you apply Design Thinking (see the `design-method` skill) to something, and it is written in Graph Protocol notation (see the `graph-protocol` skill). Nodes are functions. Edges are data flow. The annotations answer, for every node: what flows through it (A), how many times it runs (cardinality), where and how it can fail (E), and what it needs to exist (R) — plus the global concerns: trust boundaries, behavior layers, resource scope, and test layers. A Design Graph is not documentation written after the fact. It is drawn **before** implementation (planning), **reconstructed** from implementation (review), and **compared** against implementation (verdict). The graph is the contract; the code is one instantiation of it. **Hard gate:** when a turn will produce code or file edits, the graph comes first — render it (and any clarifying questions), get the user's approval, and only then write code that matches it. --- ## What a complete Design Graph contains ``` PROBLEM: <one line> X → DesignGraph<A, E, R> │ │ │ │ │ │ │ │ │ └─ R: what each node needs (§5) │ │ │ └──── E: where the graph breaks (§4) │ │ └─────── A: what flows through nodes (§2) │ │ │ └─ nodes = functions, edges = data flow │ └─ the problem SHAPES: … every noun the graph needs G