deep-interview

Deep Interview 是一种以意图为先的苏格拉底式澄清流程，在规划或实现之前进行。它通过针对性提问，了解用户为什么想要进行更改、期望的范围、哪些内容应排除在范围之外，以及 OMX 可以在无需确认的情况下决定什么，从而将模糊想法转化为可直接执行的规格说明。

<Use_When>

• 请求范围宽泛、含义模糊，或缺少具体的验收标准
• 用户说“deep interview”“interview me”“ask me everything”“don't assume”或“ouroboros”
• 用户希望避免因需求定义不充分而导致实现偏离预期
• 需要先产出需求文档，再交接给 ralplan、autopilot、ultragoal 或 team </Use_When>

<Do_Not_Use_When>

• 请求已经明确指定文件或符号目标，并给出了清晰的验收标准
• 用户明确要求跳过规划或访谈，立即执行
• 用户只想进行轻量头脑风暴（改用 plan）
• 完整的 PRD 或计划已经存在，应开始执行 </Do_Not_Use_When>

<Why_This_Exists> 执行质量的瓶颈通常在于意图是否清晰，而不只是实现细节是否完整。单轮扩展往往无法充分了解用户为什么想要进行更改、范围应止于何处、哪些取舍不可接受，以及哪些决定仍需用户批准。此工作流结合苏格拉底式追问和量化歧义评分，让编排模式从明确、可测试且符合意图的规格说明开始。 </Why_This_Exists>

<Depth_Profiles>

• Quick (--quick)：快速的 PRD 前置访谈；目标阈值 <= 0.30；最多 5 轮
• Standard (--standard，默认)：完整需求访谈；目标阈值 <= 0.20；最多 12 轮
• Deep (--deep)：高严谨度探索；目标阈值 <= 0.15；最多 20 轮
• Autoresearch (--autoresearch)：访谈严谨度与 Standard 相同，但专为 $autoresearch 任务就绪度和 .omx/specs/ 文档交接而设计

配置中的 max rounds 是硬性上限，而非目标。不要为了达到指定轮数而继续访谈。更高的苏格拉底式严谨度不会覆盖当前生效的阈值，除非配置文件或配置项发生变化。

如果未提供标志，则使用 Standard。

<Mode_Flags>

• --autoresearch：将访谈切换为 autoresearch 接入模式，以便交接给 $autoresearch。在此模式下，访谈应收敛为可供验证器使用的研究任务，在 .omx/specs/ 下编写规范文档，并保留明确的“进一步完善”与“启动”边界，以供下游技能接入。 </Mode_Flags> </Depth_Profiles> <Execution_Policy>
• 每轮只问一个问题（绝不把多个访谈轮次批量塞进一个 questions[] 表单）
• 先问意图和边界，再问实现细节
• 在应用下方阶段优先级规则后，每轮针对最弱的清晰度维度
• 把每个回答都视为需要加压检验的主张，再继续推进：下一个问题通常应要求证据或示例、暴露隐藏假设、强制做出权衡或划定边界，或重新界定根因与症状
• 当当前回答仍然模糊时，不要仅为覆盖而轮换到新的清晰度维度；停留在同一线索上，直到深入一层、澄清一个假设或收紧一条边界
• 在结晶之前，至少完成一次显式加压，用更深入、聚焦假设或聚焦权衡的追问重新审视先前的回答
• 在询问用户内部实现之前，先通过 explore 收集代码库事实
• omx explore 已弃用。对于简单的只读棕地事实收集，使用常规仓库检查工具/子 Agent；仅在需要显式 shell 原生的只读证据时使用 omx sparkshell，并将含糊或非仅 shell 的调查保留在更丰富的常规路径上。
• 在第一个访谈问题之前，始终运行预检上下文收集
• 对于棕地工作，预检必须在面向用户的问题之前包含文档/上下文接地：检查适用的 AGENTS.md 文件、README/入门文档、相关的 docs/ 契约/计划/ADR、现有的 .omx/context/ 快照，以及任何项目本地的术语表/上下文文件，例如存在时的 CONTEXT.md 或 CONTEXT-MAP.md。
• 将现有仓库语言视为证据，而非权威：如果用户使用了模糊、过载或冲突的术语，先呈现具体的文档/代码措辞，并在实现前询问应以哪个含义为准。
• 在可发现时，将用户关于当前行为的说法与代码或文档化契约进行交叉核对。如果文档与代码不一致，提出一个同时点明两个来源的确认问题，而不是默默选择其一。
• 当关系、边界或交接行为不清楚时，使用基于场景的边缘情况盘问：虚构一个具体场景来压测含糊的边界，然后就预期结果提出一个聚焦的问题。
• 持久化文档、术语表、ADR 或记忆更新是可选加入的，且仅限公开安全内容。deep-interview 可以在交接摘要中建议此类更新，但不得从访谈记录自动创建或倾倒公开文档，除非用户明确选择将其纳入范围。
• 如果初始上下文过大或会超出提示预算，不要将原始载荷粘贴或转发到访谈提示中；先请求并记录一份提示安全的初始上下文摘要
• 过大初始上下文摘要关卡是阻塞性的：在模糊度评分、结晶产物或任何下游执行交接之前，等待简明摘要
• 摘要必须保留目标、约束、成功标准、非目标、决策边界，以及对任何完整源文档的引用，以便下游消费者收到提示安全但忠实于原意的上下文
• 通过摘要或裁剪保留的历史，将提示总载荷保持在安全预算内；保留最新/最高信号的回答，绝不让原始过大上下文挤占当前问题
• 减少用户负担：只问最高杠杆的未解决问题，绝不向用户询问可直接发现的代码库事实
• 对于棕地工作，优先使用有证据支撑的确认问题，例如“我在 Y 中发现了 X。此更改是否应遵循该模式？”
• 按 Ouroboros 风格在判断之前先归类事实：在呈现面向用户的访谈轮次之前，分类所需信息是可发现的事实、需要确认的事实，还是人类决策。访谈是与人类就判断进行的，而不是为 Agent 可检查的事实进行的。
• 当未解决的模糊度取决于当前外部最佳实践、官方/上游指南、标准或版本感知行为时，在结晶需求或交接给规划/执行之前，使用 $best-practice-research 作为有界证据包装器。
• 仅使用以下 transcript/spec 标签；绝不将其用作 omx question 的 source 值，也绝不为面向用户的 deep-interview 问题替换运行时的 source: "deep-interview" 契约：
  • [from-code][auto-confirmed] — 来自清单/配置或直接源码证据的精确、高置信度代码库事实，且不附带任何规定性内容。
  • [from-code] — 有用但属于推断、基于模式或中低置信度的代码库发现，因此在被视为确定之前需要一个确认式的面向用户轮次。
  • [from-research] — 外部来源的事实，例如 API 限制、兼容性或公开文档；仅为事实，而非决策。
  • [from-user] — 目标、偏好、业务逻辑、范围、非目标、验收标准、权衡，以及任何承载决策的解释。
• 将 [from-code][auto-confirmed] 及其他非用户事实发现视为上下文/记录更新，而非访谈轮次：不要调用 omx question，不要创建待处理的 deep-interview 问题义务，也不要为 Agent 可安全确立的事实递增面向用户的轮次编号。
• 仅自动确认描述性事实。如果某项发现暗示新功能应做什么、应遵循哪种模式、应接受哪种权衡，或什么应保持在范围内/范围外，则即使代码或研究事实可用，也要将该整个承载决策的问题作为 [from-user] 路由给用户。
• 在附加 tmux 的 Codex CLI 中，deep-interview 使用 omx question 作为每个访谈轮次所需的 OMX 持有的结构化提问路径
• 通过附加 tmux 的 Bash/工具路径调用 omx question 时，通过在该命令前加 OMX_QUESTION_RETURN_PANE=$TMUX_PANE（或具体的 %pane 值）来保留 leader 窗格的返回目标
• 如果你在后台终端中启动 omx question，立即等待该后台终端完成并读取其 JSON 答案，然后再进行模糊度评分、提出另一轮或交接
• 将 answers[] 视为主要 omx question 成功契约。对于单个访谈轮次，读取 answers[0].answer；仅在需要时使用旧版顶层 answer 作为兼容性回退
• 如果当前运行时位于 tmux 之外且无法渲染 omx question，则在可用时使用原生结构化提问工具；否则提出恰好一个简明的纯文本问题并等待回答
• 在每次回答后重新评分模糊度，并透明地显示进展
• 一旦模糊度达到或低于当前配置的阈值，停止普通提问。运行实用的收尾审计：当就绪关卡通过时进行结晶/交接；否则只提出满足某个具名关卡所需的最终收尾问题。
• 将 max_rounds 视为停止上限，而非需要更多轮次的证据。
• 当模糊度仍高于阈值时，不要交接给执行，除非用户明确选择在警告下继续
• 当 Non-goals 或 Decision Boundaries 仍未解决时，不要结晶或交接，即使加权模糊度阈值已满足
• 将提前退出视为安全阀，而非默认成功路径
• 仅为恢复安全而持久化模式状态，且仅通过 CLI/编程式单写入者权威（omx state write/read --input '<json>' --json，由 src/state/operations.ts 支撑）。MCP 状态服务是只读投影，绝不能成为第二写入者。 </Execution_Policy>

阶段 0：预检上下文收集

1. 解析 {{ARGUMENTS}}，并生成一个简短的任务 slug。
2. 尝试从 .omx/context/{slug}-*.md 加载最新的相关上下文快照。
3. 检查提供的初始上下文或已加载的快照是否过大，不适合安全地用于提示词。如果内容过大，第一轮访谈必须要求提供简洁、适用于提示词的摘要，而不是评估歧义或继续交接到后续阶段。
4. 如果不存在快照，则创建一个最简上下文快照，包含：
   • 任务说明
   • 期望结果
   • 已说明的解决方案（用户提出的需求）
   • 可能的意图假设（用户提出该需求的可能原因）
   • 已知事实／证据
   • 约束
   • 未知事项／待解决问题
   • 决策边界上的未知事项
   • 可能涉及的代码库位置
   • 已检查的相关仓库文档／规则／上下文
   • 发现的术语或文档／代码冲突
   • 适用于提示词的初始上下文摘要状态（not_needed、needed 或 recorded）
5. 对于棕地任务，在第一轮面向用户的访谈之前，先检查适用的文档／规则范围。优先查看精确且邻近的来源，而不是广泛扫描：
   • 适用于受影响路径的主导 AGENTS.md 文件，以及模板／运行时指令范围
   • README／入门文档，以及 docs/ 下的相关文档，尤其是契约、计划、类似 ADR 的记录和工作流文档
   • 与 slug 相关的现有 .omx/context/ 快照、.omx/specs/ 和规划资料
   • 项目本地的术语表／上下文文件（例如 CONTEXT.md、CONTEXT-MAP.md），或存在时的特定上下文文档
6. 将快照保存到 .omx/context/{slug}-{timestamp}.md（UTC YYYYMMDDTHHMMSSZ），并在模式状态中引用它。

阶段 1：初始化

1. 解析 {{ARGUMENTS}} 和深度配置（--quick|--standard|--deep）。
2. 检测项目上下文：
   • 运行 explore，将目标分类为棕地（现有代码库）或绿地。
   • 对于棕地，在提问之前收集相关代码库上下文。
3. 通过 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. 宣布启动，并说明配置、阈值和当前歧义程度。

阶段 2：苏格拉底式访谈循环

重复此过程，直至歧义程度 <= threshold、压力审查完成、就绪门槛明确、用户在收到警告后退出，或达到最大轮数。这是停止条件：低于阈值后，不要开启新的常规访谈分支。

2a) 生成下一个问题

如果初始上下文过大，且尚未记录可安全用于提示词的摘要，则下一个问题必须仅是摘要请求。不要评估歧义度，不要运行就绪门禁，也不要交给 $ultragoal、$ralplan、$autopilot 或 $team，直到该摘要回答被记录下来。

使用：

• 原始想法
• 之前的问答轮次
• 当前维度评分
• Brownfield 上下文（如有）
• 文档/上下文依据说明，包括既有术语、治理规则，以及任何文档/代码不一致
• 已激活的挑战模式注入（阶段 3）

瞄准得分最低的维度，但遵循阶段优先级：

• 阶段 1 — 意图优先： 意图、结果、范围、非目标、决策边界
• 阶段 2 — 可行性： 约束、成功标准
• 阶段 3 — Brownfield 依据： 上下文清晰度（仅限 Brownfield）

每个回答后的追问压力阶梯：

1. 要求给出最新说法背后的具体示例、反例或证据信号
2. 探究使该说法成立的隐藏假设、依赖或信念
3. 强制给出边界或取舍：你会明确不做什么、推迟什么或拒绝什么？
4. 对照仓库中记录的用语和当前代码行为，挑战模糊或冲突的术语
5. 当关系或交接仍不明确时，用一个具体场景或边缘案例压力测试边界
6. 如果回答仍在描述症状，先重新表述为本质/根因，再继续推进

当同一线程具有最高杠杆时，优先在同一线程上停留多轮。没有压力的广度不是进展。

在独立的歧义轨道上维护一份广度账本：范围、约束、输出、验证、Brownfield 集成，以及任何用户提到的交付轨道。该账本是护栏，不是强制轮换规则：在当前线程上保持深入，直到它经过压力测试，然后仅当另一个重要轨道仍未解决且会改变执行时，才拉远视角。

为 Brownfield 访谈维护一份文档/术语账本：

• 已检查的仓库文档/规则/上下文来源，附路径引用
• 仓库已使用的规范术语，以及应避免或需要消歧的术语
• 与文档或当前代码行为冲突的用户术语
• 需要人工决策后才能实现的文档/代码不一致
• 可安全提出但不会自动应用的持久文档后续事项

详细维度：

• 意图清晰度 — 用户为什么想要这个
• 结果清晰度 — 他们想要什么最终状态
• 范围清晰度 — 变更应推进到多远
• 约束清晰度 — 必须成立的技术或业务限制
• 成功标准清晰度 — 如何判断完成
• 上下文清晰度 — 对现有代码库的理解（仅限 Brownfield）

Non-goals 和 Decision Boundaries 是强制性就绪门禁。尽早询问它们，并持续 revisit，直到它们明确。

2b) 提出问题

在每一轮访谈中都使用与交互界面相适应的结构化提问路径。在附加的 tmux 会话中，通过 omx question 使用 OMX 提供的结构化提问（这是 deep-interview 所需的结构化提问等价形式，也是所需的 AskUserQuestion 等价形式）。在 tmux 之外，若可用则使用原生结构化输入；否则只提出一个简洁的纯文本问题并等待回答。呈现：

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

{question}

访谈轮次的 omx question 载荷指引：

• Deep-interview 是苏格拉底式的：一次只提出一个聚焦的轮次。不要使用批量 questions[] 来合并多个访谈轮次，即使 omx question 为其他工作流支持批量形式。
• 使用规范的 type 值，而不要手工编写原始的 multi_select 标志。type: "single-answerable" 是单路径决策的默认值；type: "multi-answerable" 是有界多选轮次的规范形式。运行时会保持 multi_select 与 type 一致。
• 当恰好只有一个答案应当驱动下一分支、各选项互斥，或选择多个答案会模糊决策边界时，使用 single-answerable。典型情况：选择交接通道、选择主要失败模式，或确认若干相互竞争的解释中哪一个是正确的。
• 当多个选项可能同时成立，且你需要在一轮中捕获一组有界并存的约束、非目标、风险或验收检查时，使用 multi-answerable。典型情况：选择所有范围外事项、所有必须成立的成效指标，或所有同时适用的部署约束。
• 如果某个选中的选项会立即需要提出后续问题以消除其他选项的歧义，则优先现在进行 single-answerable 轮次，并在下一步提出后续问题。不要把一个分叉的访谈树隐藏在一个过载的多选提示词中。
• 保持访谈选项有界且具体。如果有效答案已已知，设置 allow_other: false；仅当访谈确实需要一个无法预先枚举的用户自定义选项时，才保留 allow_other: true。
• 从主 answers[] 数组中结构化地读取答案。对于正常的单轮访谈响应，使用 answers[0].answer 作为事实来源；顶层 answer 字段仅是旧式单问题投影/回退。
• 对于 single-answerable，预期在 answers[0].answer 的 value 字段中有一个决定性的选择及其选中值元数据。对于 multi-answerable，将 answers[0].answer 内的选中值字段视为所有所选约束/非目标的事实来源，并在记录/规范中保留完整集合。在旧式单问题投影中，这等价于：对于 multi-answerable，将 answer.selected_values 视为事实来源。

规范的有界单选载荷：

{
  "question": "Which execution lane should own this once the interview is complete?",
  "type": "single-answerable",
  "options": [
    {
      "label": "Plan first",
      "value": "ralplan",
      "description": "Need architecture and test-shape review before execution"
    },
    {
      "label": "Execute directly",
      "value": "autopilot",
      "description": "Requirements are already explicit enough for planning plus execution"
    },
    {
      "label": "Refine further",
      "value": "refine",
      "description": "Clarification is still needed before any handoff"
    }
  ],
  "allow_other": false,
  "other_label": "Other",
  "source": "deep-interview"
}

规范的有界多选载荷：

{
  "question": "Which non-goals must stay out of scope for the first pass?",
  "type": "multi-answerable",
  "options": [
    {
      "label": "No UI redesign",
      "value": "no-ui-redesign",
      "description": "Keep layout and styling unchanged"
    },
    {
      "label": "No new dependencies",
      "value": "no-new-dependencies",
      "description": "Work within the existing toolchain"
    },
    {
      "label": "No API contract changes",
      "value": "no-api-contract-changes",
      "description": "Preserve external request and response shapes"
    }
  ],
  "allow_other": false,
  "other_label": "Other",
  "source": "deep-interview"
}

规范的答案形态提醒：

{
  "answer": {
    "kind": "option",
    "value": "ralplan",
    "selected_labels": ["Plan first"],
    "selected_values": ["ralplan"]
  }
}

{
  "answer": {
    "kind": "multi",
    "value": ["no-new-dependencies", "no-api-contract-changes"],
    "selected_labels": ["No new dependencies", "No API contract changes"],
    "selected_values": ["no-new-dependencies", "no-api-contract-changes"]
  }
}

2c) 评分歧义度

对每个加权维度按 [0.0, 1.0] 评分，并给出理由与差距。

全新项目：ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)

存量项目：ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)

就绪门槛：

• Non-goals 必须明确
• Decision Boundaries 必须明确
• 压力审问必须完成：至少有一个此前的回答被重新审视，并附带证据、假设或权衡方面的追问
• 必须通过实际关闭审计：另一个问题会实质性改变执行，而不仅仅是润色措辞或追逐一个狭窄的边界情况
• 如果任一门槛未解决，或压力审问未完成，则只有在提出一个点明未解决门槛、且会实质性改变执行的最终关闭问题时，才可继续低于阈值。
• 将低歧义度评分视为允许审计关闭，而非允许无限深入。如果剩余不确定性不会改变实现，就应固化规格，而不是开启新分支。
• 如果歧义度 <= 0.10，只允许再提出那一个最终关闭问题作为面向用户的问题；否则立即固化。

2d) 报告进展

展示加权明细表、就绪门槛状态（Non-goals、Decision Boundaries），以及下一个聚焦维度。

2e) 持久化状态

通过 omx state write --input '<json>' --json 追加轮次结果与更新后的评分。不要直接写入 {mode}-state.json，也不要将只读的 MCP 状态投影用作写入器。

2f) 轮次控制

• 在首次明确的假设探针和一次持续的追问发生之前，不要提供提前退出
• 应用辩证节奏守卫：跟踪连续的非用户事实发现和确认式回答（[from-code][auto-confirmed]、[from-code] 或 [from-research]）。在连续 3 次非用户或确认式回答后，下一个实质性的面向用户轮次必须征求直接的人类判断（[from-user]），除非关闭审计表明访谈已准备好固化。
• 第 4 轮及以后：允许显式提前退出并附带风险警告
• 在画像中点给出软警告（例如，根据画像在第 3/6/10 轮）
• 在画像 max_rounds 处硬性封顶；切勿将此上限视为期望的访谈长度或配额

阶段 3：挑战模式（假设压力测试）

在适用时每种模式各使用一次。这些是常规的升级工具，而非罕见的救援手段：

• 反方（第 2 轮及以后，或当某个回答建立在未经检验的假设之上时立即使用）：挑战核心假设
• 术语专家（存量项目，每当某个关键术语模糊、含义过载，或与仓库文档/代码冲突时）：在实现之前，针对现有项目语言强制确定一个规范含义
• 简化者（第 4 轮及以后，或当范围扩张速度快于结果清晰度时）：探究最小可行范围
• 本体论者（第 5 轮及以后且歧义度 > 0.25，或当用户不断描述症状时）：要求进行本质层面的重新表述

在状态中跟踪已使用的模式，以防重复。

阶段 4：固化产物

当达到阈值时（或用户带警告退出 / 达到硬性上限）：

1. 将访谈记录摘要写入：
   • .omx/interviews/{slug}-{timestamp}.md （保留以兼容 ralph PRD）
2. 将可执行规格写入：
   • .omx/specs/deep-interview-{slug}.md

规格应包含：

• 元数据（profile、轮次、最终歧义度、阈值、上下文类型）
• 上下文快照引用/路径（供 ralplan/team 复用）
• 当提供了超大上下文时，提供对提示词安全的初始上下文摘要，并附上任何完整源文档的引用
• 清晰度分解表
• 意图（用户为何想要这个）
• 期望结果
• 范围内
• 范围外 / 非目标
• 决策边界（OMX 可在无需确认的情况下决定什么）
• 约束
• 可测试的验收标准
• 暴露的假设 + 解决方案
• 压力测试发现（重新审视了哪个回答，以及发生了什么变化）
• 针对任何基于仓库的确认问题的棕地证据与推断说明
• 文档/术语台账，包含已检查的仓库文档/规则/上下文、术语冲突，以及任何文档/代码不一致的决策
• 对范围或验收标准产生实质性影响的场景/边缘案例压力测试发现
• 可选的持久文档建议，明确标记为选择性加入且公开安全；不要包含原始私密访谈记录转储
• 技术上下文发现
• 完整或精简的访谈记录

Autoresearch 专项化

当澄清后的任务明确涉及 $autoresearch，或该技能以 --autoresearch 调用时，保持访谈领域特定，并输出可供技能消费的产物，不得跳过澄清环节。

• 接受的种子输入： topic、evaluator、keep-policy、slug、现有 mission 草稿文本，以及先前的评估器示例/模板
• 必需的访谈重点： mission 清晰度、评估器就绪度、保留策略、slug/会话命名，以及草稿是现在就绪可启动还是应进一步细化
• 规范产物路径： .omx/specs/deep-interview-autoresearch-{slug}.md
• 启动产物包： .omx/specs/autoresearch-{slug}/mission.md、.omx/specs/autoresearch-{slug}/sandbox.md 和 .omx/specs/autoresearch-{slug}/result.json
• 启动产物目录： .omx/specs/autoresearch-{slug}/
• 必需的产物章节：
  • Mission Draft
  • Evaluator Draft
  • Launch Readiness
  • Seed Inputs
  • Confirmation Bridge
• .omx/specs/autoresearch-{slug}/ 下必需的启动产物：
  • mission.md
  • sandbox.md
  • result.json
• 启动就绪规则： 当评估器命令仍包含占位符标记（如 <...>、TODO、TBD、REPLACE_ME、CHANGEME 或 your-command-here）时，将草稿标记为未就绪启动
• 结构化结果契约： result.json 应指向草稿 + mission/sandbox 产物，并携带最终确定的 topic、evaluatorCommand、keepPolicy、slug、launchReady 和 blockedReasons 字段，以便 $autoresearch 可直接消费
• 确认桥接： 在产物生成后，至少提供 refine further 和 launch；不要执行直接 CLI 启动或分离/拆分 tmux 启动，只有在明确确认后才移交给 $autoresearch
• 移交规则： 下游执行必须保留此产物中澄清后的 mission 意图、评估器预期、决策边界和启动就绪状态，而不得绕过草稿审查步骤

阶段 5：执行桥接

在产物生成后，使用明确的移交契约呈现执行选项。将 deep-interview 规格视为当前需求的唯一事实来源，并在整个移交过程中保留意图、非目标、决策边界、验收标准、文档/术语依据，以及任何残余风险警告。

可选执行契约基础

当 Autopilot/deep-interview 交接明确要求 stride 契约时，应将其作为结构化数据而非散文形式输出。这是验证基础，而非宽泛度推断功能：不要根据任务长度、阶段标签、快照或自由文本措辞来推断 stride。

Autopilot 状态下的规范位置：

{
  "handoff_artifacts": {
    "deep_interview": {
      "execution_contract_required": true,
      "execution_contract": {
        "version": 1,
        "execution_stride": "task",
        "source": "deep-interview",
        "selected_by": "user",
        "allow_task_shrink": true,
        "completion_unit": "One focused task",
        "stop_condition": "Stop after that task is implemented and verified",
        "acceptance_coverage_scope": "task",
        "shrink_policy": "allowed"
      }
    }
  }
}

Stride 含义：

• task：保守的小步执行；allow_task_shrink:true、acceptance_coverage_scope:"task"、shrink_policy:"allowed"。
• deliverable：在停止前完成指定的交付物；allow_task_shrink:false、acceptance_coverage_scope:"deliverable"、shrink_policy:"ask_before_shrink"。
• milestone：除非被阻塞，否则完成更大的已批准里程碑；allow_task_shrink:false、acceptance_coverage_scope:"milestone"、shrink_policy:"deny_unless_blocked"。

仅当所选的下游工作流需要这一显式的 stride/停止条件防护时，才设置 execution_contract_required:true。新工件必须在 handoff_artifacts.deep_interview 下写入上文所示的规范 snake_case schema；运行时读取端可以接受旧式 camelCase 字段/标记别名以及直接/嵌套的 execution_contract 位置，但仅作为兼容性输入。如果 execution_contract_required 缺失或为 false，则下游 Autopilot 兼容行为保持不变。

目标模式后续操作

在符合已澄清的 spec 时，应包含以下面向产品的建议，同时不删除现有的 $ultragoal、$ralplan、$autopilot 和 $team 交接选项：

• $ultragoal — 用于实现或通用目标导向后续 spec 的默认目标模式后续操作，这些 spec 应被转换为具有顺序完成跟踪的持久 Codex/OMX 目标。
• $autoresearch — 当已澄清的上下文是一个研究项目时使用：研究问题、参考资料/文献收集、评估器支持的分析，或教授/评审员风格的交付物。
• $performance-goal — 当已澄清的上下文是具有可衡量的速度、延迟、吞吐量、内存、基准或评估器标准的优化或性能项目时使用。

推荐将 $ultragoal 作为默认的持久目标模式后续操作，因为它取代了 Ralph 用于目标跟踪。保留 $team 用于协调并行实现。

1. $ultragoal（默认持久执行后续操作）

• 输入工件： .omx/specs/deep-interview-{slug}.md（可选附带转录/上下文快照以保证可追溯性）
• 调用： $ultragoal create-goals --brief-file <spec-path>，随后在活跃执行通道中执行 $ultragoal complete-goals
• 消费端行为： 将已澄清的 spec 转换为持久的目标模式工作。将意图、非目标、决策边界、验收标准、文档/术语依据、场景压力发现以及残余风险警告保留为绑定故事约束。
• 跳过的/已满足的阶段： 需求访谈、歧义澄清、文档/上下文预检以及早期意图边界引出
• 预期输出： .omx/ultragoal/brief.md、.omx/ultragoal/goals.json、.omx/ultragoal/ledger.jsonl、实现证据、验证证据以及最终清理/审查关口证据
• 最适用场景： 已澄清的 spec 已可执行，或用户明确希望将持久目标跟踪作为下一步
• 推荐的下一步： 运行 Ultragoal 完成循环；仅在活跃的 Ultragoal 故事内、且并行通道确有必要时启动 $team

2. $ralplan（当仍需要架构/测试形态评审时推荐）

• 输入产物： .omx/specs/deep-interview-{slug}.md（可选附上转录/上下文快照以便追溯）
• 调用方式： $ralplan <spec-path>
• 消费方行为： 将深度访谈规格视为需求的唯一事实来源。默认不重复访谈；而是围绕已厘清的意图与边界来细化架构/可行性。
• 跳过/已满足的阶段： 需求发现、歧义澄清以及早期意图-边界引导
• 预期输出： .omx/plans/ 下的规范化规划产物，尤其是 prd-*.md 和 test-spec-*.md
• 最适用于： 需求已足够清晰，可以停止访谈，但仍需要进行架构验证/共识规划
• 下一步推荐： 将已批准的规划产物与 $ultragoal 一起使用，作为默认的持久目标模式后续步骤（可选搭配 $team 实现并行泳道）；选择 $autoresearch 进行研究验证，或选择 $performance-goal 进行可衡量的优化

3. $autopilot

• 输入产物： .omx/specs/deep-interview-{slug}.md
• 调用方式： $autopilot <spec-path>
• 消费方行为： 将深度访谈规格用作已厘清的执行简报。保留意图、非目标、决策边界和验收标准，作为规划/执行的约束性上下文。
• 跳过/已满足的阶段： 初始需求发现与歧义降低
• 预期输出： 由 autopilot 生成的规划/执行进度、QA 证据和验证产物
• 最适用于： 已厘清的规格已经足够强大，可以直接进行规划 + 执行，而无需额外的共识关卡
• 下一步推荐： 继续走 autopilot 的执行/QA/验证流程；如果出现协调密集型的执行，优先在由 leader 拥有的 $ultragoal 账本下使用 $team

4. $team

• 输入产物： .omx/specs/deep-interview-{slug}.md
• 调用方式： $team <spec-path>
• 消费方行为： 将规格视为协调并行工作的共享执行上下文。保留已厘清的意图、非目标、决策边界和验收标准，作为各泳道的共同约束。
• 跳过/已满足的阶段： 需求澄清与早期歧义降低
• 预期输出： 针对共享规格的协调式多 Agent 执行，并在适用时在已激活的 Ultragoal 账本中提供最终验证证据与检查点
• 最适用于： 任务规模大、多泳道或对阻塞因素敏感，足以证明应使用协调式并行执行而非单一持久循环
• 下一步推荐： 当协调执行阶段结束时，遵循 team 的验证路径；在适用时对已激活的 $ultragoal 账本设置检查点。不要仅为了验证而启动另一个执行循环。

5. 进一步细化

• 输入产物： 现有转录、上下文快照和当前规格草稿
• 调用方式： 继续访谈循环
• 消费方行为： 重新进入提问，以解决剩余影响力最高的不确定性
• 跳过/已满足的阶段： 除已捕获的上下文外，无其他跳过内容
• 预期输出： 一份歧义更低、边界更紧凑、未解决假设更少的规格
• 最适用于： 残余歧义仍然过高、用户希望获得更强的清晰度，或超过阈值/提前退出的警告表明继续推进存在过多风险而难以干净地完成
• 下一步推荐： 当规格得到充分澄清后，回到上述某个执行交接契约

残余风险规则： 如果访谈以提前退出、硬性上限完成或超过阈值的带警告继续方式结束，则在交接中显式保留该残余风险状态，以便下游技能知道其继承的是一份仅部分厘清的简报。 重要： Deep-interview 是一种需求模式。在交接时，使用上述契约调用选定的技能。不要在 deep-interview 内直接实现。

<Tool_Usage>

• 使用 explore 进行代码库事实收集
• 当有附加的 tmux 渲染器可用时，使用 omx question 作为 OMX 原生的结构化用户输入工具，用于每一轮访谈
• 从附加的 tmux Bash/工具路径调用时，使用 OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ...，除非已经知道明确的 %pane 返回目标
• 如果当前运行时位于 tmux 之外且无法渲染 omx question，则在可用时使用原生结构化输入；否则只提出一个简洁的纯文本问题并等待回答
• 在 omx question 返回 JSON 后，优先使用 answers[0].answer / answers[]；仅将旧版 answer 用作较旧记录的兜底
• 使用 omx state write/read --input '<json>' --json，通过唯一写入者状态操作路径实现可恢复的模式状态；MCP 状态服务是只读的，不是兜底写入者
• 如果访谈无法提出必需的 omx question 轮次，则将阻塞项持久化为终止状态，使用 active: false 和 current_phase: "blocked"；不要写入 active: true 的终止阻塞阶段
• 在 .omx/context/ 下读取/写入上下文快照
• 在预检期间读取适用的仓库文档/规则/上下文；仅在用户明确选择加入且内容对公开安全时，才写入持久文档、术语表、ADR 或记忆更新
• 在任何评分或交接步骤之前，记录超大上下文摘要门控是无需处理、待处理还是已满足
• 将转录/规格产物保存到 .omx/interviews/ 和 .omx/specs/ 下 </Tool_Usage>

<Escalation_And_Stop_Conditions>

• 用户说停止/取消/中止 -> 持久化状态并停止
• 歧义停滞 3 轮（+/- 0.05）-> 强制进入 Ontologist 模式一次
• 达到最大轮数 -> 在明确残余风险警告的情况下继续
• 所有维度 >= 0.9 -> 即使在达到最大轮数之前也允许提前结晶 </Escalation_And_Stop_Conditions>

<Final_Checklist>

• 预检上下文快照存在于 .omx/context/{slug}-{timestamp}.md 下
• 超大初始上下文（如果存在）在歧义评分或下游交接之前已记录提示安全的摘要
• 每轮显示歧义分数
• 在实现细节之前使用意图优先的阶段优先级
• 在活动阶段内使用最弱维度定位
• 在结晶之前至少进行了一次明确的假设探查
• 至少一次持续的后续跟进/施压环节深化了先前的回答
• 在阈值处触发了挑战模式（如适用）
• 转录写入 .omx/interviews/{slug}-{timestamp}.md
• 规格写入 .omx/specs/deep-interview-{slug}.md
• 如适用，棕地问题使用证据支持的确认
• 棕地预检在面向用户的问题之前检查了适用的仓库文档/规则/上下文
• 如适用，模糊或冲突的术语已根据仓库语言/当前代码行为进行了挑战
• 当边界歧义会实质性影响实现时，使用了基于场景的边缘情况拷问
• 持久文档/ADR/记忆更新（如有）已明确选择加入且对公开安全
• 提供了交接选项（$ultragoal、$ralplan、$autopilot、$team），以及如适用时的上下文敏感目标模式建议（$autoresearch、$performance-goal）
• 在此模式下未执行任何直接实现 </Final_Checklist>

## 建议配置（可选）

Deep-interview 按以下顺序从第一个存在的配置源读取运行时默认值：

1. 仓库本地 .omx/config.toml
2. 仓库根目录 omx.toml
3. 用户全局 ~/.omx/config.toml

本节目前是 deep-interview 专用的运行时覆盖入口，并非对 Codex config.toml 或 .omx-config.json 模型/环境路由的通用替代。 格式错误的配置文件会被以 fail-soft 方式忽略，以便 $deep-interview 激活仍可继续使用内置默认值。 显式的 --quick、--standard 或 --deep 调用标志会覆盖 defaultProfile。

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

恢复

如果被中断，请重新运行 $deep-interview。通过 omx state read --input '{"mode":"deep-interview"}' --json 从持久化的模式状态恢复。

规范 Autopilot 入口流水线

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

• Autopilot 以此独立的 deep-interview 清晰度门禁开始；它不得以 $plan --interview 替代。
• 阶段 1（deep-interview）：消除歧义并产出可执行的需求工件
• 阶段 2（ralplan）：可行性、架构与共识门禁
• 阶段 3（ultragoal）：持久执行、验证与完成回执