spec-design

/spec-design - Global SDD backbone gate

The outcome is a compact set of technical decisions, boundaries, and canonical contracts that constrains later agents without prescribing implementation. The gate is mandatory but adaptive in depth:

• local/simple pressure may produce a valid minimal backbone with explicit not_applicable rationale;
• shared-boundary, contract, state/data, runtime, security, or strict pressure requires a complete scaffold and applicable canonical specs;
• unresolved material decisions produce blocked and stop the handoff.

This command also records the explicit Foundation Dev Path decision. It never creates task records, implementation plans, REQ-000, or FT-000.

<input_contract> Run after /prd-to-features with no argument. If a successful positive-revision backbone already exists, route changes to /spec-redesign.

Require the clarified product feature set, pre-design backbone/registry, and relevant accepted/current evidence. Load and apply .memory-bank/workflows/sdd-design-contract.md; it owns source authority, canonical artifact ownership, SDD coverage, architecture integrity, and shared semantic validation. </input_contract>

<hard_invariants>

• Do not skip this gate, even for local/simple work.
• Feature docs remain composition roots for behavior and exact applicable spec links. Feature-level concern completion and spec_design_status normally belong to /feature-to-tasks or /spec-auto.
• This command owns only initial Planning Revision activation. Accepted backbone changes and later revision decisions belong to /spec-redesign.
• Foundation work is product-enabling infrastructure only. Do not move product behavior into the foundation path. </hard_invariants>

<operator_decisions> Apply the shared operator-decision boundary. In interactive mode, ask only for unresolved material choices; in unattended mode, block and name /spec-design as the resume route.

When architecture_style is unresolved, evidence identifies an application-shaped greenfield project, and no accepted decision or concrete trade-off points elsewhere, first recommend one deployable modular monolith whose primary change units are capability/vertical slices. Include one runtime composition, narrow module contracts, explicit write ownership including a shared-database case, and a credible verification path per significant capability. Present another style first only when current evidence supports the trade-off; hypothetical future scale or reuse is insufficient.

This recommendation order does not create target authority. Propose one coherent initial slice map and its material ownership/boundary choices as part of the same focused architecture decision, then obtain one explicit operator confirmation rather than a questionnaire per slice. An explicit alternative always wins. A previously accepted operator/project policy may authorize this preferred style and an evidence-determined slice map only when the evidence yields one materially unambiguous decomposition; otherwise unattended mode uses the existing blocker below.

Do not force this recommendation onto a library/package, CLI, firmware, data pipeline, plugin/protocol system, established brownfield boundary, or genuinely independently deployed services. Recommend the evidence-backed natural primary change unit for those shapes. Brownfield migration to the preferred target still requires an accepted target decision.

Brownfield special case: when meaningful code exists but a credible mapped current-state baseline is missing, ask the operator to choose the immediate route unless the accepted scope already proves a strictly local delta:

• run /map-codebase first;
• explicitly accept PRD-only drift risk;
• constrain the work to an evidenced local delta.

An unresolved initial choice sets Global Backbone Status blocked and uses the active workflow's existing HALT_BLOCKING_QUESTIONS or HALT_CLARIFICATION_REQUIRED state. </operator_decisions>