write-architecturelisted

# write-architecture — design (Stage 4) Two modes. Pick by what the user needs. ## Reuse first Reuse the capability, keep the house format (template, `house.css` tokens, section structure): - **Inventory with the `Explore` agent** (below) instead of reading the tree inline. - **Weighing design alternatives?** Run the **`Plan`** agent first — it returns step-by-step options and architectural trade-offs. Its output feeds the trade-offs table; it does not replace it, and the doc still names what was rejected and why. - Before each section's SVG, load **`artifact-diagramming`**; load **`dataviz`** for charts. ## Before writing — read the contract (methodology R11) `docs/CONSTRAINTS.md` holds the agreed top-level design (`A1…`). Both modes below are checked against it **before** anything is written: - **Mode A** designs *within* it, then **extends** it — an architecture commits to boundaries and stores the RFC/DRP only implied. Add those as new constraints (keep the one-page cap: merge or retire weaker ones rather than growing the list past ~15). **Extension is not drift**: a *new* ID that contradicts nothing is logged as `ext` and needs no drift report. Only a change that makes an existing sentence **false** is an `amend`, and that stops the build first (R11). - **Mode B** must not silently contradict it. A CR that needs a constraint changed is a **drift**: stop, report (ID · what the contract says · what the CR needs · why · comply/amend/defer), and get approv