autopilot

Autopilot

Autopilot 是面向无人值守交付的一等公民规范编排器。其标志性的默认链路是强制性的：

$deep-interview -> $ralplan -> $ultragoal

该链路不是一组可选的提示，Autopilot 也不是直接执行的别名。Autopilot 在单个可恢复会话中监督每个子阶段，将持久化产物向前传递，并持续进行实现验证，直到所请求的结果完成或记录下真正的阻塞项。

<Use_When>

• 用户显式调用 $autopilot。
• 用户要求从想法、issue 或需求种子出发进行端到端自主交付。
• 该工作需要将需求澄清、共识规划、持久化执行和基于证据的完成作为一个受监督的工作流。 </Use_When>

<Default_Chain> 按顺序运行或恢复以下阶段：

1. deep-interview — 澄清意图、范围、非目标、约束、验收标准以及未决事项。产出持久化的需求/规范交接。Deep Interview 是一个真实阶段；不要用单问题检查替代它，也不要仅仅因为任务看起来可执行就跳过它。
2. ralplan — 将澄清后的需求转化为可执行的共识计划，包含架构、顺序编排、测试和验证指引。将评审证据保留为生命周期证据，而非宿主签发的安全授权。
3. ultragoal — 通过持久化目标与台账回执、实现、聚焦验证、清理、评审和终态证据来执行已批准的计划。

当活跃的 Ultragoal 计划或验证边界需要时，可在受监督执行中使用 $team、$code-review 和 $ultraqa。它们不会取代或削弱标志性的三阶段链路。

当评审或 QA 证明需求或计划有误时，保持 Autopilot 活跃，将其受监督阶段返回到 ralplan，附上发现的问题，并再次通过 ultragoal 继续。仅涉及实现的评审修复可以保留在 Ultragoal 的阻塞项/评审循环内。 </Default_Chain>

<Execution_Policy>

• Autopilot 必须在新运行时从 deep-interview 开始，并且必须保持 deep-interview -> ralplan -> ultragoal 的阶段顺序。
• 子阶段是受监督的阶段，而非同级工作流激活。保持 mode:"autopilot" 活跃并更新 current_phase，而不是用独立的子状态替换 Autopilot。
• 使用当前 CLI 状态 SSOT（omx state ... --json）和当前会话作用域的状态根。不要创建第二个写入者，也不要恢复旧版根状态授权。
• 本地产物、提示词、跟踪器、记录、环境值和角色标签仅属于生命周期证据。不要重新引入已废弃的不可恢复宿主回执锁，也不要因为宿主来源不可用而将工作流终态化。
• 降低权限的操作始终可恢复：$cancel、状态清除、钩子禁用/卸载恢复以及陈旧状态修复必须保持可用，无需完成回执或子阶段批准。
• 在安全、可逆的阶段转换中自动继续。仅在显式用户取消、仅人工依赖或已验证的终态结果时停止。 </Execution_Policy>

<State_Management> Autopilot 状态是会话作用域的，由规范状态写入者拥有。新运行至少记录：

{
  "mode": "autopilot",
  "active": true,
  "current_phase": "deep-interview",
  "iteration": 1,
  "phase_cycle": ["deep-interview", "ralplan", "ultragoal"],
  "handoff_artifacts": {
    "deep_interview": null,
    "ralplan": null,
    "ultragoal": null
  },
  "return_to_ralplan_reason": null
}

仅通过 CLI 优先的状态接口启动或更新状态：

omx state write --input '{"mode":"autopilot","active":true,"current_phase":"deep-interview","state":{"phase_cycle":["deep-interview","ralplan","ultragoal"],"handoff_artifacts":{"deep_interview":null,"ralplan":null,"ultragoal":null},"return_to_ralplan_reason":null}}' --json

阶段转换：

• deep-interview -> ralplan：要求有持久化的澄清后需求/规格产物，以及非空的完成理由。若使用了提问界面，则保留同一会话内的提问证据。
• ralplan -> ultragoal：要求有持久化的规划产物、按顺序先 Architect 后 Critic 的批准，以及与会话/评审周期绑定的 ralplan_execution_handoff。对于受监督的 Autopilot，显式的 Autopilot 请求即为该绑定交接的来源。常规推进不得依赖宿主签发的共识回执；缺少宿主来源不构成阻碍。
• ultragoal -> complete：要求有持久化的目标/账本完成回执，以及与所请求结果一致的最新验证证据。
• 评审/QA 回环：保持 Autopilot 处于激活状态，设置 current_phase:"ralplan"，并持久化 return_to_ralplan_reason 及发现的问题。
• 取消：运行 $cancel；保留交接产物以供检查或恢复，并将确切的会话标记为终止，但不删除无关状态。
• 清除/恢复：确切会话清除可移除损坏或过期的 Autopilot 状态。它不得要求正向推进证据，也不得清除其他技能或会话。 </State_Management>

<Continuation_And_Resume> 当用户说 continue、resume 或 keep going 时，读取当前会话的 autopilot-state.json，并从 current_phase 继续：

• deep-interview：恢复澄清并生成需求交接产物。
• ralplan：从 deep-interview 产物及任何回环发现中恢复共识规划。
• ultragoal：从已批准的规划与账本中恢复持久化执行。
• complete：报告终止证据；不要重新开始。
• cancelled、cleared 或 failed：报告保留的产物，并且仅在收到新的显式 Autopilot 请求时才启动新运行。

切勿仅因对话恢复就丢弃有效的交接产物或重新开始发现。 </Continuation_And_Resume>

<Recovery_Contract> Autopilot 续接钩子可以推动处于活动状态的非终止运行，但它们必须为恢复而失败开放：

• 过期、格式错误、已取消、已清除、已完成或属于外来会话的状态不得持续阻塞 Stop。
• $cancel、确切会话状态清除，以及设置钩子禁用/卸载路径，在 Autopilot 处于活动或损坏状态时仍必须可执行。
• 续接必须有界且限定于会话；绝不重新创建无条件的钩子锁。 </Recovery_Contract>

<Final_Checklist>

• 新运行以 deep-interview 开始。
• Deep Interview 生成了持久化的澄清后需求/规格交接产物。
• Ralplan 生成了可执行的规划，并附有生命周期评审证据。
• Ultragoal 以持久化目标与账本回执完成了该规划。
• 验证证据覆盖所请求的行为、失败路径与恢复路径。
• 缺少宿主来源未阻碍常规推进、取消、清除或钩子恢复。
• Autopilot 状态已终止，且确切会话的产物保持连贯一致。 </Final_Checklist>

用户：`$autopilot implement issue #42` 流程：在 `deep-interview` 处激活 Autopilot，明确需求，继续到受监督的 `ralplan`，然后受监督的 `ultragoal`，验证已完成的结果，并将确切会话标记为完成。 用户：`continue` 上下文：Autopilot 状态为 `current_phase:"ralplan"`。 流程：从 deep-interview 交接产物恢复现有规划；不要创建单独的独立 Ralplan 运行。 流程：将 `$deep-interview`、`$ralplan` 和 `$ultragoal` 视为可选建议，并直接跳到实现。 为何不好：这掏空了 Autopilot 起决定性作用的编排契约。

Task: {{ARGUMENTS}}