design-methodlisted

# Design Thinking — The Method A stack-agnostic design methodology. Read the problem. Draw the data flow as a call graph (the **Design Graph**). Write code that IS the graph. If the code doesn't match the graph, something is wrong. The method is language-neutral. Where it says "Effect", "gen", or "pipe" in the Effect-TS appendix (`effect-ts.md`), substitute your stack's equivalent: Result types, exceptions at layer joins, middleware, RAII, constructor injection — whatever your language provides. The discipline never changes, only the vocabulary. **Hard gate — applies in every harness (pi, omp, Claude Code, any agent):** When the user asks for a feature, change, fix, or refactor — or when any turn will end in proposed code or file edits — you MUST render the Design Graph (Graph Protocol) and any clarifying questions BEFORE touching any file, and implement only after the user approves the design. Reading and exploring code first is fine; the FIRST edit is not allowed before the graph. This rule is not optional and not stack-dependent. Render every result in Graph Protocol format (see the `graph-protocol` skill). ``` X → DesignGraph<A, E, R> │ │ │ │ │ │ │ │ │ └─ what each node needs (§5) │ │ │ └──── where the graph breaks (§4) │ │ └─────── what flows through nodes (§2) │ │ │ └─ nodes = functions, edges = data flow │ └─ the problem: what you're trying to build §1 Shapes t