Exploration

Exploration (Design + Spike)

Two modes, selected by router dispatch context: design (brainstorm a design) or spike (throwaway prototype). DESIGN includes an optional inline sub-procedure, the Doubt Pass, for high-stakes decisions — it is not a third mode.

Mode: DESIGN

Turn rough ideas into validated designs through collaborative dialogue. Understand what to build BEFORE designing how to build it. Use the user's domain language — don't invent new terminology when the repo or prompt already has a stable name.

Scope Triage (Front of Flow)

Before opening the interview, decide whether this is ONE design or MANY. A request spanning multiple independent subsystems produces a sprawling, unfocused design.

Multi-subsystem trigger: 2+ pieces that could be built, tested, and shipped independently — different surfaces, data stores, deploy targets, or pieces joined only by "and."

If multi-subsystem: emit a decomposition recommendation (independent pieces, relationships, build order), then brainstorm ONLY the first sub-project. The router carries the rest forward.

Synthesize-Now Fast Path

If goal + constraints + acceptance are ALL already evident from the prompt or context: skip the interview, draft the design directly, present for confirmation in ONE pass. Still record rejected alternatives (ADR notes). On correction, fix the named gap — don't restart the full interview.

Gate: take the fast path ONLY when all three are stated, not inferred. When in doubt, interview.

Interview (when fast path gate fails)

Cover these 5 dimensions, but only ask about dimensions that are still unresolved. Skip a question when the answer is already explicit — write the inferred answer, mention the assumption, continue.

1. Purpose — what problem does this solve?
2. Users — who will use this?
3. Success — how will we know it works?
4. Constraints — limitations, requirements, out-of-scope
5. Scope — single module, single file, full feature, cross-cutting

Always ask: "What is explicitly NOT part of this?" (out-of-scope discovery).

One question at a time — asking several questions at once is bewildering. Multiple choice preferred. If a fact can be found by exploring the environment (filesystem, tools), look it up rather than asking; the decisions are the user's. Present 2-3 approaches with trade-offs before asking which to pursue. YAGNI ruthlessly — defer what is not essential.

Intent Completeness Gate (before proceeding to design): (1) small enough to fit in one paragraph, (2) contradiction-free, (3) sufficiently specific that a builder could act without clarifying questions. If any fails, ask one more targeted question.

Domain Glossary + ADR Notes

Accrete domain vocabulary as the interview names terms. Record load-bearing rejected alternatives as ADR notes. Both are emitted in the handoff so the planner inherits the project's language and the rationale for rejected directions.

Challenge domain terms — don't just accrete, challenge.

• Contradiction with CONTEXT.md: when a term the user uses conflicts with the existing glossary, surface it immediately ("your glossary defines cancellation as X, but you seem to mean Y — which is it?"). Domain-shaping contradictions (contracts/persistence/user-language) stop for human input; low-blast-radius ones proceed with a recorded assumption.
• Contradiction with code: when the user states how something works, check whether the code agrees. If not, surface it: "your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
• Vague/overloaded terms: propose a precise canonical term ("you're saying account — do you mean the Customer or the User? those are different things").
• Update CONTEXT.md inline as terms resolve (append-only glossary entries). Use the format in cc10x:domain-modeling/CONTEXT-FORMAT.md. Create the file lazily if it doesn't exist.
• Offer an ADR only when all three are true: hard to reverse, surprising without context, and the result of a real trade-off. Use cc10x:domain-modeling/ADR-FORMAT.md; write to docs/adr/.

Exploration in DESIGN mode is a designated CONTEXT.md writer (alongside planner and doc-syncer).

Design Output

Save to docs/plans/YYYY-MM-DD-<feature>-design.md (use -design.md suffix, not -plan.md, to prevent collision with planner output).

Template: Purpose, Users, Success Criteria, Constraints, Out of Scope, Approach Chosen, Domain Glossary (if any), Decisions/ADR notes (if any), Architecture, Components, Data Flow, Error Handling, Testing Strategy, Observability (if applicable), UI Mockup (if UI feature), Questions Resolved.

Design Self-Review Gate (MANDATORY — before handoff)

Scan the design for the 4 failures that corrupt downstream plans. Fix inline — no second review pass.

1. No placeholders/TBD — every section holds a real decision, not a stub. If N/A, say so explicitly.
2. Internally consistent — components in Architecture all appear in Data Flow; Error Handling covers the chosen Approach's failure modes; Success Criteria don't conflict with Constraints/Out-of-Scope.
3. Single-plan scope — one coherent thing a single plan can sequence. If it grew to span multiple subsystems, narrow to the first and record the rest in Out of Scope.
4. No two-way-ambiguous requirements — pick ONE interpretation, state it explicitly.

Design Handoff (MACHINE-READABLE — do NOT edit .cc10x/*.md)

### Brainstorming Handoff (MACHINE-READABLE)
DESIGN_FILE: "{PROJECT_DIR}/docs/plans/YYYY-MM-DD-<feature>-design.md"
DESIGN_SUMMARY: "[one-sentence summary]"
MEMORY_NOTES:
  glossary:
    - term: "[Term]"
      meaning: "[precise meaning]"
  decisions:
    - decision: "[what was chosen]"
      rejected: "[alternative not taken]"
      why: "[the constraint or trade-off that decided it]"

Router carries design forward and persists memory. Do NOT write memory yourself.

Doubt Pass (DESIGN sub-procedure — inline self-check)

For non-trivial decisions where correctness matters more than speed: subject the decision to an adversarial re-read BEFORE it stands. This is IN-FLIGHT course correction, not post-hoc review.

When to Use

• Working in unfamiliar code
• Stakes are high (production, security-sensitive, irreversible operations)
• A confident output would be cheaper to verify now than to debug later
• The decision involves >2 non-trivial trade-offs