graph-protocollisted

# Graph Protocol The notation spec for **Design Graphs**. A Design Graph is the annotated call graph of a concrete problem: nodes are functions, edges are data flow, and every node carries annotations for data (A), cardinality, failure (E), and requirements (R). The Protocol is stack-agnostic. A graph written for Go, Rust, Python, TypeScript, SQL, or a spreadsheet renders identically. Only the vocabulary inside the annotations changes (e.g. what "retry" means in your language). Every tool in this package (`/cg`, `/cg-plan`, `/cg-review`, `/cg-map`, and the `/dt` active mode) MUST emit output in the format below. --- ## Canonical output skeleton Sections appear in this fixed order. Omit a section only when it is genuinely empty for the problem at hand (say so: `SCOPE: none`), never to skip thinking. ``` PROBLEM: <one-line statement of what you're building or examining> 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: <the nouns: records, IDs, variants, errors> GRAPH: <ascii call graph, annotated inline> CARDINALITY: <node (1|N|T) list> BOUNDARIES: <every edge crossing untrusted → trusted> BEHAVIOR: <cross-cutting layers that wrap nodes> SCOPE: <resources: acquire@… → relea