deep-interview

<Purpose> Deep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation. </Purpose>

<Use_When>

• 用户需要系统梳理相互关联的目标、范围、取舍与验收条件
• The user says "deep interview", "interview me", "ask me everything", "don't assume", or "ouroboros"
• The user wants to avoid misaligned implementation from underspecified requirements
• 活动工作流要求需求交接阶段；完整的既有规格可按下文复用 </Use_When>

<Do_Not_Use_When>

• The request already has concrete file/symbol targets and clear acceptance criteria
• The user explicitly asks to skip planning/interview and execute immediately
• The user asks for lightweight brainstorming only (use plan instead)
• 已有完整 PRD/plan 且用户要求直接执行；若活动 Autopilot 要求此阶段，则核对并复用规格后交接 </Do_Not_Use_When>

<Why_This_Exists> Execution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec. </Why_This_Exists>

<Depth_Profiles>

• Quick (--quick): fast pre-PRD pass; target threshold <= 0.30; max rounds 5
• Standard (--standard, default): full requirement interview; target threshold <= 0.20; max rounds 12
• Deep (--deep): high-rigor exploration; target threshold <= 0.15; max rounds 20
• Autoresearch (--autoresearch): same interview rigor as Standard, but specialized for $autoresearch mission readiness and .omx/specs/ artifact handoff

Profile max rounds is a hard cap, not a target. Do not continue only to reach a numbered round count. Extra Socratic rigor does not override the active threshold unless the profile/config changes.

If no flag is provided, use Standard.

<Mode_Flags>

• --autoresearch: switch the interview into autoresearch-intake mode for $autoresearch handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under .omx/specs/, and preserve the explicit refine further vs launch boundary for downstream skill intake. </Mode_Flags> </Depth_Profiles>

<Execution_Policy>

• Ask ONE question per round (never batch multiple interview rounds into one questions[] form)
• Ask about intent and boundaries before implementation detail
• Target the weakest clarity dimension each round after applying the stage-priority rules below
• Quick / Standard 只追问会改变实现或验收的缺口；答案已明确时继续收敛，不逐条要求用户举证。
• Deep 模式才要求至少一次明确的 pressure pass，追问关键假设或取舍；可复用当前任务已完成且仍有效的追问证据。
• Gather codebase facts via explore before asking user about internals
• omx explore is deprecated. Use normal repository inspection tools/subagents for simple read-only brownfield fact gathering; use omx sparkshell only for explicit shell-native read-only evidence, and keep ambiguous or non-shell-only investigation on the richer normal path.
• Always run a preflight context intake before the first interview question
• Brownfield preflight 先读取适用的 AGENTS.md 与目标附近的代码或契约；仅在存在相关缺口时查阅 README、ADR、术语表或历史快照，可复用未变化的已读材料。
• Treat existing repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern before implementation.
• 核对可查明的当前行为；文档与代码冲突时说明证据，只有无法从既有需求确定预期且会改变结果时才提问。
• Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.
• Durable docs, glossary, ADR, or memory updates are opt-in and public-safe only. Deep-interview may recommend such updates in the handoff summary, but must not automatically create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.
• If initial context is oversized, read accessible source documents in bounded portions and record a faithful prompt-safe summary with source references. Ask the user only for inaccessible material or a decision-bearing ambiguity that cannot be resolved from those sources.
• The oversized initial-context summary gate requires a recorded faithful summary before scoring or handoff; an agent-authored summary satisfies it when the source is available. It is not an automatic user-summary request.
• The summary must preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to any full source documents so downstream consumers receive a prompt-safe but faithful context
• Keep total prompt payloads within a safe budget by summarizing or trimming retained history; preserve newest/highest-signal answers and never let raw oversized context crowd out the current question
• Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly
• 提问时给出相关仓库证据与待决定的具体取舍；符合既有授权的常规实现选择可直接说明并继续。
• Route facts before judgment in the Ouroboros style: before presenting a user-facing interview round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.
• When unresolved ambiguity depends on current external best practices, official/upstream guidance, standards, or version-aware behavior, use $best-practice-research as the bounded evidence wrapper before crystallizing requirements or handing off to planning/execution.
• Use these transcript/spec labels only; never use them as omx question source values, and never replace the runtime source: "deep-interview" contract for user-facing deep-interview questions:
  • [from-code][auto-confirmed] — exact, high-confidence codebase facts from manifests/configs or direct source evidence, with no prescription attached.
  • [from-code] — 仓库推断或模式证据，注明置信度；优先补充可查证据，只将影响结果且无法自行确定的决策交给用户。
  • [from-research] — externally sourced facts such as API limits, compatibility, or public documentation; facts only, not decisions.
  • [from-user] — goals, preferences, business logic, scope, non-goals, acceptance criteria, tradeoffs, and any decision-bearing interpretation.
• Treat [from-code][auto-confirmed] and other non-user fact discoveries as context/transcript updates, not interview rounds: do not call omx question, do not create a pending deep-interview question obligation, and do not increment the user-facing round number for facts the agent can safely establish.
• 用户决定产品范围与实质取舍；已明确的需求和授权仍然有效。常规技术选择依据仓库契约解决，不能仅因发现可用模式就再次请求确认。
• In attached-tmux Codex CLI, deep-interview uses omx question as the required OMX-owned structured questioning path for every interview round
• When invoking omx question through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with OMX_QUESTION_RETURN_PANE=$TMUX_PANE (or a concrete %pane value)
• If you launch omx question in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off
• Treat answers[] as the primary omx question success contract. For a single interview round, read answers[0].answer; use legacy top-level answer only as a compatibility fallback when needed.
• If the current runtime is outside tmux and cannot render omx question, use the native structured question tool when available; otherwise ask exactly one concise plain-text question and wait for the answer
• Re-score after each answer once a faithful context summary is available. A user-facing source request counts toward the profile's round cap; display ambiguity as not scored until the summary exists. If the cap is reached without it, report the incomplete intake and do not crystallize an execution-ready spec.
• Once ambiguity is at or below the active profile threshold, stop ordinary questioning. Run the practical closure audit: crystallize/handoff when readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.
• Treat max_rounds as a stop cap, not evidence that more rounds are needed.
• Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning
• Do not crystallize or hand off while Non-goals or Decision Boundaries remain unresolved, even if the weighted ambiguity threshold is met
• Treat early exit as a safety valve, not the default success path
• Persist mode state for resume safety only through the CLI/programmatic single-writer authority (omx state write/read --input '<json>' --json, backed by src/state/operations.ts). The MCP state server is a read-only projection and must never become a second writer. </Execution_Policy>

<Steps>

Phase 0: Preflight Context Intake

1. Parse {{ARGUMENTS}} and derive a short task slug.
2. Attempt to load the latest relevant context snapshot from .omx/context/{slug}-*.md.
3. Check whether the initial context or snapshot is too large. Summarize accessible sources before scoring or handoff; request missing material only when a faithful summary cannot be produced. Agent fact-gathering does not count as an interview round.
4. If no snapshot exists, create a minimum context snapshot with:
   • Task statement
   • Desired outcome
   • Stated solution (what the user asked for)
   • Probable intent hypothesis (why they likely want it)
   • Known facts/evidence
   • Constraints
   • Unknowns/open questions
   • Decision-boundary unknowns
   • Likely codebase touchpoints
   • Relevant repo docs/rules/context inspected
   • Terminology or doc/code conflicts found
   • Prompt-safe initial-context summary status (not_needed, needed, or recorded)
5. 按 Execution Policy 中的 preflight 范围收集证据，不把文档目录当作必读清单。
6. Save snapshot to .omx/context/{slug}-{timestamp}.md (UTC YYYYMMDDTHHMMSSZ) and reference it in mode state.

Phase 1: Initialize

1. Parse {{ARGUMENTS}} and depth profile (--quick|--standard|--deep).
2. Detect project context:
   • Run explore to classify brownfield (existing codebase target) vs greenfield.
   • For brownfield, collect relevant codebase context before questioning.
3. Initialize state via omx state write --input '{"mode":"deep-interview","active":true}' --json:

{
  "active": true,
  "current_phase": "deep-interview",
  "state": {
    "interview_id": "<uuid>",
    "profile": "quick|standard|deep",
    "type": "greenfield|brownfield",
    "initial_idea": "<user input>",
    "rounds": [],
    "current_ambiguity": 1.0,
    "threshold": 0.3,
    "max_rounds": 5,
    "challenge_modes_used": [],
    "codebase_context": null,
    "current_stage": "intent-first",
    "current_focus": "intent",
    "context_snapshot_path": ".omx/context/<slug>-<timestamp>.md"
  }
}

4. Announce kickoff with profile, threshold, and current ambiguity.

Phase 2: Socratic Interview Loop

先依据当前需求和证据评分；达到阈值且 readiness gates 明确时即可收敛。只有 Deep 模式要求 pressure pass。否则围绕实质缺口提问，直到满足条件、用户退出或达到轮次上限；低于阈值后不再开启普通追问分支。

复用完整规格

若已有规格覆盖目标、范围、Non-goals、Decision Boundaries、约束和验收条件，核对其与当前任务和代码的一致性。Quick / Standard 可在零新增问答下完成本阶段；Deep 仍须有有效的 pressure pass 证据。记录真实的来源、核对结果与完成理由，生成或更新规范的交接产物；rounds 如实为空，不编造用户回答或授权。存在未解决的实质缺口时继续访谈。

2a) Generate next question

If oversized context lacks a faithful recorded summary, finish bounded source reading and summarization first. If essential source material is inaccessible, ask one focused question for it and wait. Score and hand off only after the summary is recorded.

Use:

• Original idea
• Prior Q&A rounds
• Current dimension scores
• Brownfield context (if any)
• Doc/context grounding notes, including existing terminology, governing rules, and any doc/code mismatch
• Activated challenge mode injection (Phase 3)

Target the lowest-scoring dimension, but respect stage priority:

• Stage 1 — Intent-first: Intent, Outcome, Scope, Non-goals, Decision Boundaries
• Stage 2 — Feasibility: Constraints, Success Criteria
• Stage 3 — Brownfield grounding: Context Clarity (brownfield only)

Deep 模式的追问工具；Quick / Standard 仅在存在具体决策缺口时选用：

1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim
2. Probe the hidden assumption, dependency, or belief that makes the claim true
3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?
4. Challenge fuzzy or conflicting terms against the repo's documented language and current code behavior
5. Stress-test the boundary with one concrete scenario or edge case when a relationship or handoff remains ambiguous
6. If the answer still describes symptoms, reframe toward essence / root cause before moving on

仅当下一问仍会改变结果时继续当前话题。

在 Breadth Ledger 中记录范围、约束、输出、验证和集成的未解决项；只处理会改变执行结果的缺口，不轮流补问已明确的维度。

Maintain a Docs/Terminology Ledger for brownfield interviews:

• repo docs/rules/context sources inspected, with path references
• canonical terms already used by the repo and terms to avoid or disambiguate
• user terms that conflict with docs or current code behavior
• doc/code mismatches that require a human decision before implementation
• optional durable-doc follow-ups that are safe to propose but not auto-apply

Detailed dimensions:

• Intent Clarity — why the user wants this
• Outcome Clarity — what end state they want
• Scope Clarity — how far the change should go
• Constraint Clarity — technical or business limits that must hold
• Success Criteria Clarity — how completion will be judged
• Context Clarity — existing codebase understanding (brownfield only)

Non-goals 和 Decision Boundaries 是必需 readiness gates；可以引用既有明确需求，仅在缺失或冲突时询问。

2b) Ask the question

Use the surface-appropriate structured questioning path for every interview round. In attached-tmux sessions, use OMX-owned structured questioning via omx question (this is the required structured-question equivalent and required AskUserQuestion equivalent for deep-interview). Outside tmux, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer. Present:

Round {n} | Target: {weakest_dimension} | Ambiguity: {score}%

{question}

omx question payload guidance for interview rounds:

• Deep-interview is Socratic: ask one focused round at a time. Do not use batch questions[] to combine multiple interview rounds, even though omx question supports batch forms for other workflows.
• Use canonical type values instead of authoring raw multi_select flags by hand. type: "single-answerable" is the default for one-path decisions; type: "multi-answerable" is the canonical shape for bounded multi-select rounds. The runtime will keep multi_select aligned with type.
• Use single-answerable when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.
• Use multi-answerable when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.
• If one selected option would immediately require a follow-up question to disambiguate the others, prefer a single-answerable round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.
• Keep interview options bounded and concrete. If the valid answers are already known, set allow_other: false; only leave allow_other: true when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.
• Read answers structurally from the primary answers[] array. For a normal single-round interview response, use answers[0].answer as the source of truth; the top-level answer field is a legacy single-question projection/fallback only.
• For single-answerable, expect one decisive selection in the value field of answers[0].answer plus its selected-values metadata. For multi-answerable, treat the selected-values field inside answers[0].answer as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec. In legacy single-question projections, this is equivalent to: For multi-answerable, treat answer.selected_values as the source of truth.

When using the attached-tmux question bridge, read question payloads for canonical payload and answer examples. Native question tools use their own schema.

2c) Score ambiguity

Score each weighted dimension in [0.0, 1.0] with justification + gap.

Greenfield: ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)

Brownfield: ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)

Readiness gate:

• Non-goals must be explicit
• Decision Boundaries must be explicit
• 仅 Deep 模式要求完成 pressure pass；其他模式以剩余问题是否会改变执行结果为准
• A practical closure audit must pass: remaining questions would not change execution materially; unresolved material decisions still require a focused closure question
• 若必需 gate 未解决，或 Deep 模式的 pressure pass 缺失，仅围绕该缺口提出收敛问题；已满足的 gate 不重复确认。
• Treat a low ambiguity score as permission to audit closure, not permission to keep drilling indefinitely. If remaining uncertainty would not change implementation, crystallize the spec instead of opening a new branch.
• If ambiguity is <= 0.10, another user-facing question is allowed only as that final closure question; otherwise crystallize immediately.

2d) Report progress

Show weighted breakdown table, readiness-gate status (Non-goals, Decision Boundaries), and the next focus dimension.

2e) Persist state

Append round result and updated scores via omx state write --input '<json>' --json. Do not write {mode}-state.json directly and do not use the read-only MCP state projection as a writer.

2f) Round controls

• 用户可随时结束访谈；区分“已满足完成条件”和“带未解决项退出”，不能把退出当作执行授权。
• 查明仓库事实不占用户问答轮次，也不触发为了调整问答比例而追加的问题。
• Soft warning at profile midpoint (e.g., round 3/6/10 depending on profile)
• Hard cap at profile max_rounds; never treat this cap as a desired interview length or quota

Phase 3: Challenge Modes (assumption stress tests)

按未解决的假设、术语或范围问题选择下列工具，不因达到某个轮次自动追加问题：

• Contrarian (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions
• Terminologist (brownfield, whenever a key term is fuzzy, overloaded, or conflicts with repo docs/code): force a canonical meaning against existing project language before implementation
• Simplifier (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope
• Ontologist (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing

Track used modes in state to prevent repetition.

Phase 4: Crystallize Artifacts

达到阈值并满足 readiness gates 时生成可执行规格；用户提前退出或达到上限时也可保存产物，但未解决的实质缺口必须标为待定，不得宣称已完成需求交接。

1. Write interview transcript summary to:
   • .omx/interviews/{slug}-{timestamp}.md (kept for ralph PRD compatibility)
2. 将规格及其就绪状态写入：
   • .omx/specs/deep-interview-{slug}.md

Spec should include:

• Metadata (profile, rounds, final ambiguity, threshold, context type)
• Context snapshot reference/path (for ralplan/team reuse)
• Prompt-safe initial-context summary when oversized context was provided, plus references to any full source documents
• Clarity breakdown table
• Intent (why the user wants this)
• Desired Outcome
• In-Scope
• Out-of-Scope / Non-goals
• Decision Boundaries (what OMX may decide without confirmation)
• Constraints
• Testable acceptance criteria
• Assumptions exposed + resolutions
• Pressure-pass findings（仅实际进行过时记录；其他情况注明不适用）
• Brownfield evidence vs inference notes for any repository-grounded confirmation questions
• Docs/Terminology Ledger with inspected repo docs/rules/context, term conflicts, and any doc/code mismatch decisions
• Scenario/edge-case pressure findings that materially shaped scope or acceptance criteria
• Optional durable documentation recommendations, explicitly marked opt-in and public-safe; do not include raw private transcript dumps
• Technical context findings
• Full or condensed transcript

For --autoresearch, read autoresearch intake before generating its launch bundle; preserve the explicit refine/launch boundary.

Phase 5: Execution Bridge

Present execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, and any residual-risk warnings across the handoff.

When the selected Autopilot handoff requires a structured execution stride, read execution contract. Local artifacts never grant runtime authority.

Select the next stage

Pass the spec, context reference, acceptance criteria, non-goals, decision boundaries, and residual risks to the selected consumer. Reuse resolved requirements instead of repeating the interview. Follow authorization already established for the active task; a standalone interview does not authorize implementation.

Need	Handoff
Architecture/consensus still needed	$ralplan <spec-path>
Explicit supervised orchestration	$autopilot <spec-path>; retain its Ralplan stage
Durable execution tracking	$ultragoal create-goals --brief-file <spec-path>, then its documented execution gate
Approved parallel implementation with runtime support	$team using the spec as shared scope; Team remains separately authorized
Validator-gated research	$autoresearch using the intake bundle and confirmed launch decision
Measurable performance optimization	$performance-goal with metric/evaluator
Material uncertainty remains	Continue the focused interview

Retired entrypoints are not execution alternatives. In App, check the selected skill's surface and authority requirements before handoff.

Residual-Risk Rule: If the interview ended via early exit, hard-cap completion, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.

IMPORTANT: Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. Do NOT implement directly inside deep-interview.

</Steps>

<Tool_Usage>

• Use explore for codebase fact gathering
• Use omx question as the OMX-native structured user-input tool for each interview round when an attached tmux renderer is available
• From attached-tmux Bash/tool paths, call it as OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ... unless an explicit %pane return target is already known
• If the current runtime is outside tmux and cannot render omx question, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer
• After omx question returns JSON, prefer answers[0].answer / answers[]; use legacy answer only as a fallback for older records
• Use omx state write/read --input '<json>' --json for resumable mode state through the sole-writer state operations path; the MCP state server is read-only and is not a fallback writer
• If the interview cannot ask a required omx question round, persist the blocker as terminal state with active: false and current_phase: "blocked"; do not write a terminal blocked phase with active: true
• Read/write context snapshots under .omx/context/
• Read applicable repo docs/rules/context during preflight; write durable docs, glossary, ADR, or memory updates only when the user explicitly opts in and the content is public-safe
• Record whether the oversized-context summary gate is not needed, pending, or satisfied before any scoring or handoff step
• Save transcript/spec artifacts under .omx/interviews/ and .omx/specs/ </Tool_Usage>

<Escalation_And_Stop_Conditions>

• User says stop/cancel/abort -> persist state and stop
• Ambiguity stalls for 3 rounds (+/- 0.05) -> force Ontologist mode once
• 达到轮次上限 -> 输出未解决项；未满足 readiness gates 时不宣称规格可执行，也不自动交接执行
• All dimensions >= 0.9 -> allow early crystallization even before max rounds </Escalation_And_Stop_Conditions>

<Final_Checklist>

• Preflight context snapshot exists under .omx/context/{slug}-{timestamp}.md
• Oversized initial context, if present, has a prompt-safe summary recorded before ambiguity scoring or downstream handoff
• Ambiguity score shown each round
• Intent-first stage priority used before implementation detail
• Weakest-dimension targeting used within the active stage
• Deep 模式已有至少一次明确的假设追问 / pressure pass；Quick / Standard 不以问答数量作为完成条件
• Challenge modes 仅用于实际存在的决策缺口
• Transcript written to .omx/interviews/{slug}-{timestamp}.md
• Spec written to .omx/specs/deep-interview-{slug}.md
• Brownfield questions use evidence-backed confirmation when applicable
• Brownfield preflight inspected applicable repo docs/rules/context before user-facing questions
• Fuzzy or conflicting terminology was challenged against repo language/current code behavior when applicable
• Scenario-based edge-case grilling was used when boundary ambiguity would materially affect implementation
• Durable docs/ADR/memory updates, if any, were explicitly opted into and public-safe
• Selected handoff uses a supported workflow and preserves the spec, residual risks, and existing authority
• No direct implementation performed in this mode </Final_Checklist>

<Advanced> ## Suggested Config (optional)

Deep-interview reads runtime defaults from the first existing config source in this order:

1. Repository-local .omx/config.toml
2. Repository-root omx.toml
3. User-global ~/.omx/config.toml

This section is currently a deep-interview-specific runtime override surface, not a general replacement for Codex config.toml or .omx-config.json model/env routing. Malformed config files are ignored fail-soft so $deep-interview activation can continue with built-in defaults. Explicit --quick, --standard, or --deep invocation flags override defaultProfile.

[omx.deepInterview]
defaultProfile = "standard"
quickThreshold = 0.30
standardThreshold = 0.20
deepThreshold = 0.15
quickMaxRounds = 5
standardMaxRounds = 12
deepMaxRounds = 20
enableChallengeModes = true

Resume

If interrupted, rerun $deep-interview. Resume from persisted mode state via omx state read --input '{"mode":"deep-interview"}' --json.

Canonical Autopilot Entry Pipeline

autopilot -> deep-interview -> ralplan -> ultragoal

• Autopilot begins with this independent deep-interview clarity gate; it must not substitute $plan --interview.
• Stage 1 (deep-interview): ambiguity clearance and execution-ready requirements artifact
• Stage 2 (ralplan): feasibility, architecture, and consensus gate
• Stage 3 (ultragoal): durable execution, verification, and completion receipts </Advanced>