---
name: scope-definition
description: >
  Relentlessly resolve material owner decisions for a Bearing Lifecycle, one
  dependency-ordered question at a time, until shared understanding is explicit.
  Use for Scope Definition or unresolved plan intent. Do not use for discoverable
  repository facts, design drafting, implementation, or settled decisions.
---

# Scope Definition

Fresh planning node. If you are the Orchestrator, dispatch this; do not execute it.

## Match and inputs

- **Match:** a material scope, behavior, authority, risk, or acceptance
  decision is unresolved. Development strategy is not gathered here; the
  Orchestrator records `single_implementer` or `tdd` from the profile or an
  explicit owner choice in `implementation.json`.
- **Non-match:** evidence can answer it, the owner already decided it, or a work
  packet is ready.
- **Inputs:** goal, visible plan state, repository evidence, prior decisions,
  open decision tree, and return schema. Runs after Architectural Alignment.

## Algorithm

1. Inspect the repository and available evidence before asking. Never ask the
   owner for a fact tools can establish. Maintain a coverage ledger from
   required roles and artifacts. Cells are `DISCOVERABLE`, `OPEN`, `DECIDED`,
   `DEFERRED`, `NOT_APPLICABLE`, or `BLOCKED`. Exit is falsifiable: zero
   `OPEN`; `DECIDED` cites owner decision and source; `DEFERRED` has a bounded
   owner-approved destination or trigger; `NOT_APPLICABLE` has a reason;
   `BLOCKED` is surfaced. Planning is a fan-out/fan-in DAG with Scribe as an
   event side lane.
2. Select the earliest unresolved decision whose dependencies are satisfied.
3. Ask exactly one question, relayed to the owner through the Orchestrator. Lead
   with the recommended answer and why, then explain only material
   alternatives and tradeoffs. Wait for the owner.
4. Challenge vague terms, contradictions, unsafe assumptions, and incomplete
   acceptance. A default, probability, or silence is not approval.
5. Follow the affected dependency branch. Revisit an earlier answer when new
   evidence conflicts; otherwise do not replay it.
6. Buffer confirmed decisions in the active session. Do not persist, patch, or
   re-render Lifecycle state after each answer.
7. Return one consolidated decision batch to the Orchestrator at a natural checkpoint:
   the dependency branch is complete, Planning and Design is next, handoff/context
   loss is imminent, or the owner requests a flush.
8. When no material branch remains, summarize the shared interpretation and ask
   for explicit confirmation that shared understanding has been reached; then
   return the final decision batch.

## Return and recovery

Return `DECISION_CONFIRMED`, `SHARED_UNDERSTANDING_CONFIRMED`,
`NEEDS_EVIDENCE`, or `OWNER_DECISION_REQUIRED` with decision ID, answer,
rationale, affected requirements, buffered decision count, remaining branch,
checkpoint, and next action. Stop after three evidence-changing attempts on one
blocked decision.

Never write Lifecycle state, choose for the owner, design, or implement.