architecturelisted

# Blueprint: architecture Read `${CLAUDE_PLUGIN_ROOT}/FORMAT.md` first (or `FORMAT.md` at the repo root if you are working inside the blueprint repo itself). It defines the ID grammar and the exact document shape. Do not improvise a variant. ## Input `.blueprint/<slug>/requirements.md`. Resolve the slug from the argument, or from the single existing `.blueprint/*/requirements.md`, or ask. Stop before you start if `## Open questions` still has unanswered `Q<n>` items — unanswered meaning no `status: answered` on the line. Surface them and ask, then have `/blueprint:requirements` record the answers before you design. Designing around an unresolved question produces a component that gets deleted. ## What you do 1. **Read the existing codebase properly.** Where does this feature attach? What patterns, helpers, and types already exist that this should reuse? The most common failure is an architecture that reinvents something living three files over. Grep before you design. 2. **Pick the approach and justify it against one real alternative.** Two sentences on the alternative and why not. If you cannot name an alternative, you have not thought about it yet. 3. **Cut components at responsibility boundaries.** One `### C<n>` per unit with a single responsibility, a named file, and a concrete interface — real signatures, not prose. If a component's responsibility needs the word "and", split it. That applies to the heading too: a name like "Model and p