ralplan

Ralplan（共识规划别名）

Ralplan 是 Autopilot 在 $deep-interview 与 $ultragoal 之间使用的标准共识规划阶段。它驱动 Planner、Architect 和 Critic 的规划，并通过 RALPLAN-DR 结构化审议记录其评审生命周期（默认使用 short 模式，高风险工作使用 deliberate 模式）。本地生命周期证据不是宿主机颁发的安全授权，但在可执行计划与顺序评审证据持久化之后，通往 Ultragoal 的常规推进必须保持可达；缺失宿主机来源证明不得使 Ralplan 进入终态，也不得阻止取消、清除或恢复。

用法

$ralplan "task description"

独立咨询式规划需显式选择启用：

$ralplan --advisory "task description"

咨询式运行执行相同的顺序 Planner → Architect → Critic 评审生命周期，将计划与两份评审产物绑定到精确字节和一次由 tracker 支持的迭代，然后以 active:false 返回调用方。这是一种协作式工作流暂停，而非安全围栏或权限系统。它绝不会发出 PreToolUse 允许/阻止决策，绝不会完成宿主机共识门禁，绝不会授权执行，也绝不会抑制无关的宿主机行为。终态必须为共识门禁、宿主机验证和执行交接携带显式的 false 值，而不是将其省略。后续具体的肯定性执行请求可能产生非权威的路由上下文，但它不会持久化权限、重写终态证据或创建自动交接；引文、代码、示例、文档、问题、模态请求、否定表述和含糊的批准仍属于分类器负例。approved+proven 需要完整的生命周期摘要以及写入后重新验证。管理性放弃是仅追加的，对已准备或已提交的日志具有幂等性，并记录一个单独的字节绑定管理事件，而不重写原始的收尾日志。真正的强制执行需要宿主机在不可由用户伪造的表面上显式颁发并经宿主机验证的凭据或能力；本地 Advisory 文件、提示词、会话/线程字段、tracker 记录和 HERDR 可观测性都无法替代它。在 Darwin 上，每个 Advisory 证据产物受固定目录读取器限制为 128 KiB；其他受支持平台允许最多 8 MiB。

标志

• --interactive：在关键决策点启用用户提示（第 2 步的草案评审和第 6 步的最终批准）。没有此标志时，工作流完全自动运行——Planner → Architect → Critic 循环——并在不请求确认的情况下输出最终计划。
• --deliberate：对高风险工作强制使用 deliberate 模式。增加事前验尸（3 个场景）和扩展测试规划（单元/集成/e2e/可观测性）。没有此标志时，deliberate 模式仍可在请求明确表示高风险（认证/安全、迁移、破坏性变更、生产事故、合规/PII、公共 API 破坏）时自动启用。
• --advisory：仅限独立使用。它不能与 Autopilot、Pipeline、Team、Ralph、Ultragoal、执行标志或未知标志组合使用。启用需要规范的会话、根线程和轮次身份。

本体论密集型评审

对于需求语义、分类法、提示词/规范设计、策略区分或类别风险架构，请引用 architect 角色 Agent 的只读评审作为咨询证据。其发现可在明确使用时为计划或后续证据提供参考，但 $ralplan 本身仅记录 Architect→Critic 生命周期证据，且咨询式评审永远不是持久的执行授权。

与交互模式搭配使用

$ralplan --interactive "task description"

行为

GPT-5.6 指引对齐

使用共享工作流指导模式：结果优先的框架、针对多步骤规划的简洁可见更新、针对当前工作流分支的本地覆盖、有证据支撑的规划与验证预期、明确的停止规则、大小合适的实现/PRD 形态，以及对安全可逆步骤的自动继续。仅针对实质性、破坏性、需要凭据、外部生产环境或依赖偏好的分支进行询问。

本技能运行自己的共识运行时；它不会委托给一个不存在的 Plan 共识模式：

omx ralplan run --task <arguments> [--session <id>]

共识工作流：

1. Planner 在评审前创建一个自适应计划（大小与任务范围相匹配；不要默认恰好五个步骤）以及一份紧凑的 RALPLAN-DR 摘要。当前 [main] 与 [planner] 的行为：独立的 $ralplan 可能由当前活跃的 main 规划通道编写，除非调用方/运行时提供了专门的 planner 路由记录；在 $autopilot 内，状态字段 planning_routing.owner:"planner" 表示初始 Planner 草稿/分解必须使用专门的 [planner]。将 .omx-config.json 的 agentModels.planner 设置为选择特定的 planner 模型，并为复杂的 Autopilot 规划强制使用专门的 planner 所有权，即使 [main] 并不廉价/mini。RALPLAN-DR 摘要包括：
   • 原则（3-5 条）
   • 决策驱动因素（前 3 项）
   • 可行选项（>=2）及其有边界的优缺点
   • 如果只剩一个可行选项，需为其他备选方案提供明确的失效理由
   • 仅限 Deliberate 模式：预演（3 个场景）+ 扩展测试计划（单元/集成/e2e/可观测性）
2. 用户反馈 （仅 --interactive）：如果设置了 --interactive，使用结构化问题 UI（在附加的 tmux 中使用 omx question；在可用时，tmux 之外使用原生结构化输入）在评审前展示草稿计划以及原则/驱动因素/选项摘要（继续评审 / 请求更改 / 跳过评审）。否则，自动进入评审。 原生角色路由预检： 关键字路由可能已经选择了 Ralplan，但这并不具备权威性。仅当原生任务界面报告 role_routing_unavailable，且此工作流尝试经适配的 Ralplan Planner、Architect 或 Critic 权威、经适配的角色意图或经适配的共识权威时，才运行 omx ralplan preflight --json。在出现 unsupported_documented_leader_proof 时，在该经适配的权威之前停止，并使用具有已记录 root 证明的 Codex 界面或经过评审的替代工作流。不要从 session_id、未记录的 thread_id、会话/指针/转录/cwd 状态、子数据的缺失或提示词标签推断 root 身份。普通原生规划、生命周期、状态、状态检查、健康检查、HUD、运行时、设置、安装、同步以及无关的委托均在此预检边界之外，仍受现有控制措施管辖。

原生角色路由规则： 当原生界面暴露 agent_type 角色路由时，将 agent_type 设置为已安装的 OMX 角色，并且对于 OMX 工作绝不省略它。当原生界面不暴露它（role_routing_unavailable）时，不要伪造 agent_type。在确切经过评审的 Codex 版本 0.144.5、0.145.0、0.146.1 和 0.148.0-alpha.5 上，经适配的 Ralplan Planner、Architect、Critic、角色意图和共识权威不可用，因为它们缺少已记录的 root 证明；所有其他版本仍然未知并会失败关闭（fail closed）。不要通过提示词角色标签或推断的载体静默削弱路由。对于该权威，请使用具有已记录 root 证明的 Codex 界面或经过评审的替代工作流。直接尝试 omx ralplan role-intent write 会被拒绝，并给出机器原因 unsupported_documented_leader_proof。 3. Architect 审查架构合理性，必须提供最强的钢人式反命题、至少一个真实的权衡张力，以及（在可能时）综合结论 —— 在步骤 4 之前等待其完成。将此作为后续的角色专属 Architect 子 Agent 启动，并传入完整任务说明、上下文快照、PRD/test-spec 路径及相关先前发现；不得用未经核验的审查者身份或简短的临时审查者提示词替代。在 deliberate 模式下，Architect 应明确标记原则违规。 4. Critic 依据质量标准进行评估 —— 仅在步骤 3 完成后运行。将此作为后续的角色专属 Critic 子 Agent 启动，并传入完整任务说明、上下文快照、PRD/test-spec 路径及已完成的 Architect 审查；不得要求 Architect 子 Agent 执行 Critic 关卡，也不得用未经核验的审查者身份或简短的临时审查者提示词替代。Critic 必须强制确保原则与选项一致性、公平的替代方案、风险缓解清晰度、可测试的验收标准及具体的验证步骤。在 deliberate 模式下，Critic 必须拒绝缺失或薄弱的 pre-mortem 或扩展测试计划。 5. 复审循环（最多 5 次迭代）：任何非 APPROVE 的 Critic 裁决（ITERATE 或 REJECT）都必须运行相同的完整闭环： a. 收集 Architect 和 Critic 的反馈 b. 与 Planner 一起修订计划 c. 返回 Architect 审查 d. 返回 Critic 评估 e. 重复此循环，直到 Critic 返回 APPROVE 或达到 5 次迭代 f. 如果达到 5 次迭代仍未获得 APPROVE，向用户呈现最佳版本 6. Critic 批准后，持久化可供执行的规划产物及顺序 Architect→Critic 证据。在独立交互式 Ralplan 中，呈现所请求的未来执行通道。在 Autopilot 内，现有的显式 $autopilot 调用授权受监督地过渡到其定义的下一阶段 $ultragoal；持久化一个 Autopilot 拥有的 ralplan_execution_handoff，绑定到同一会话和审查循环。 7. 记录 ralplan_execution_handoff，格式为 {authorized: true, reason, authorized_at, session_id, review_cycle, source: "autopilot"|"user"}。source:"autopilot" 仅对当前阶段为 ralplan 的受监督活动 Autopilot 运行有效；它不声称拥有宿主共识权威。 8. 在持久化计划、顺序批准及绑定的执行交接存在后，过渡到 $ultragoal。不要在 Ralplan 内直接实现。

重要： 步骤 3 和步骤 4 必须作为角色专属子 Agent 顺序运行。不要在同一并行批次中同时发出两个 Agent 调用。务必在调用后续 Critic 之前等待后续 Architect 结果；它们完成的批准仅建立本地生命周期证据，无法满足持久化执行关卡。

规划/执行边界

$ralplan 是一种规划模式。当 ralplan 处于活动状态且没有显式执行交接处于活动状态时，以实现为重点的写入工具不在范围内。Ralplan 可以检查仓库，并且只能写入规划产物，例如 .omx/context/、.omx/plans/、.omx/specs/ 及所需的 .omx/state/ 记录。

规范流程为：

$ralplan -> local Architect→Critic lifecycle evidence -> bound execution handoff -> $ultragoal

在任何执行通道开始之前，ralplan 必须发出终端规划状态（完成、暂停、失败或等待输入）以及下方的持久化交接记录。不要在同一 ralplan 会话中从共识规划继续进入直接代码编辑。

持久共识交接契约

Ralplan 并不会仅仅因为 .omx/plans/prd-*.md 和 .omx/plans/test-spec-*.md 存在就完成、可跳过或可进入执行。这些文件是规划产物，而非共识证据。

在任何 Autopilot、Ultragoal、Team 或实现交接之前，持久化一份交接记录，用以区分：

• planning_artifacts：PRD/test-spec 路径。
• ralplan_architect_review：已完成的 Architect 审查，且结论为批准。
• ralplan_critic_review：已完成的 Critic 审查，且结论为批准，仅在 Architect 审查之后记录。
• ralplan_execution_handoff：持久化 {authorized: true, reason: "<rationale>", authorized_at: "<ISO timestamp>", session_id: "<current session>", review_cycle: <matching lifecycle cycle>, source: "autopilot"|"user"}。Autopilot 只能为其自身受监督的 ralplan 阶段签发此项；独立 Ralplan 使用 source:"user"。
• ralplan_consensus_gate.complete 记录在顺序执行的 Architect 和 Critic 批准之后的生命周期完成。它不是主机安全声明。本地编写的 JSON/env/prompt/tracker/transcript/receipt 形式的证据，绝不能被描述为主机签发的权威。

如果 Architect 缺失/受阻，将工作流保持在 Architect 审查，或报告该阻塞。如果 Critic 缺失/受阻/未批准，将工作流保持在 Critic/复审，或报告最大迭代结果。在两项审查均批准后，只有当匹配的 ralplan_execution_handoff 已持久化时，执行才会开始。仅有现有的 plan/test-spec 文件，绝不构成跳过 Ralplan 或执行的许可。

关于共识模式详情，请遵循 Plan 技能的完整文档。

Goal 模式后续建议

当绑定的 ralplan_execution_handoff 允许执行时，在协调的 Team 执行之外，一并包含面向产品的 goal 模式建议。记录所请求的 lane，并持久化交接，而不声称主机签发的权威。

• $ultragoal — 默认的 goal 模式后续，适用于实现或一般性的目标导向后续计划，这些计划应成为持久的 Codex/OMX 目标，并进行顺序完成跟踪。
• $autoresearch — 研究项目后续，当计划以问题、文献/参考资料收集、评估器支持的研究或教授/critic 式研究交付物为中心时使用。（$autoresearch-goal 已在 OMX 0.21 中退役为日落存根。）
• $performance-goal — 优化/性能后续，当计划以速度、延迟、吞吐量、内存、基准或其他可衡量的性能工作为中心时使用。

使用 $ultragoal 进行持久目标跟踪，使用 $team 进行协调的并行实现。二者结合时，Ultragoal 拥有账本，Team 返回可检点的执行证据。 使用 available-agent-types 名册，为任何未来经 receipt 授权的执行路径生成明确的角色/人员分配、按 lane 推理的指导、具体的启动提示（包括在并行交付合理时的 omx team），以及团队验证职责。

前置上下文收集

在共识规划或执行交接之前，确保存在一份扎实的上下文快照：

1. 根据请求推导出一个任务 slug。
2. 当可用时，复用 .omx/context/{slug}-*.md 中最新的相关快照。
3. 如果不存在，则创建 .omx/context/{slug}-{timestamp}.md（UTC YYYYMMDDTHHMMSSZ），包含：
   • 任务陈述
   • 期望结果
   • 已知事实/证据
   • 约束
   • 未知项/待解问题
   • 可能的代码库接触点
4. 如果歧义仍然很高，先收集棕地事实。omx explore 已弃用；对于简单的只读仓库查询，使用常规的仓库检查工具/子 Agent，仅对明确的 shell 原生只读证据使用 omx sparkshell。然后在继续之前运行 $deep-interview --quick <task>。
5. 如果计划依赖于官方文档、版本感知的框架指导、最佳实践或外部依赖行为，在最终确定规划交接之前，使用 $best-practice-research 作为有界证据包装器，并自动委派 researcher 进行官方/上游查询，以免执行仅从仓库本地记忆开始。
6. 如果存在先前的 $autoresearch 运行，将其已批准的产物视为计划的证据。仅将 $autoresearch-goal 中的历史产物作为兼容性输入读取。除非用户明确要求持续的研究自动化，否则不要将 Autoresearch 作为最终架构或运行时组件纳入；否则将证据综合到 $ralplan 的 ADR、风险和验证步骤中。

在此收集完成之前，不要交接给执行模式；如果紧迫性迫使推进，请明确记录风险权衡。

路由边界

普通的限定范围任务留在 templates/AGENTS.md 所描述的直接执行通道中。 显式的工作流请求遵循关键字注册表（src/hooks/keyword-registry.ts）及其所属的技能契约；本卡片不定义第二个激活表。 一旦 Ralplan 处于活动状态，保留上述规划/执行和共识交接要求。对话式的“直接做吧”不能替代所需的评审证据。

场景示例

好： 在工作流已有明确下一步之后，用户说 continue。继续当前工作分支，而不是重新开始或重复询问同一问题。

好： 用户只更改输出形态或下游交付步骤（例如 make a PR）。保留早先不冲突的工作流约束，并在本地应用该更新。

坏： 用户说 continue，而工作流重新开始发现过程，或在收集到缺失的验证/证据之前就停止。