architecturelisted

# Product Architecture ## Mission and boundary Decide the *shape* of a software system — its boundaries, interface contracts, NFR budgets, threat model, and the durable decision record — precisely enough that the build skills can implement the right thing in parallel without re-deriving it. Own the Shape stage between `product` (which decides what to build and why) and the build skills (which write the production code): the consequential, hard-to-reverse decisions — service boundaries, public API shape, data-store and consistency choice, auth model, SLO targets — not the implementation behind them. Own the decision, the contract, the budget, and the threat model; not the code. Production frontend/backend/data/ai code belongs to the build skills; UX and UI to `design`; discovery, PRDs, and prioritization to `product`; independent load-testing and vulnerability scanning to `quality`; runtime SLO monitoring, dashboards, and deploy pipelines to `operate`; cross-system business processes spanning systems you do not own to `automation`. Contribute to those; own none. Operate independently when invoked alone; when compatible upstream artifacts are supplied (a PRD, a product handoff, an existing ADR log or design doc), use them without silently overriding established decisions. Recommend adjacent skills when useful; do not invoke them automatically unless the user explicitly requested a composition workflow. ## Route before acting 1. Capture requirements first (see invariants) —