oh-my-codex 0.18.2 发布解读：Prometheus Strict 规划表面、Ultragoal HUD 进度与 post-0.18.1 缺陷列车合入

oh-my-codex 0.18.2 发布解读：Prometheus Strict 规划表面、Ultragoal HUD 进度与 post-0.18.1 缺陷列车合入

【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex

0.18.2是 oh-my-codex 在v0.18.1之后的第一个主分支（main）发布：它将dev分支上所有在v0.18.1之后开启并已关闭、已完成的 issue 列车整体提升到main，同时包含同一比较区间内合入的 Prometheus Strict 规划表面（planner surface）与 Ultragoal HUD 进度展示。本文将围绕这份发布说明逐条拆解：合入了哪些修复、Prometheus Strict 配方工作流如何使用、Ultragoal 进度如何进入 HUD、工作流交接如何变得更显式，并结合仓库源码与测试说明这些能力背后的实现原理，帮助你评估是否升级以及如何用好在 0.18.2 中出现的新表面。

版本背景：一次"关闭 issue 列车"的整体合入

发布说明明确给出了 0.18.2 的定位：它不是一次从零开始的新功能发布，而是把dev分支上v0.18.1之后积累的、已关闭且已完成的 issue 全部提升到main。这意味着本版本的实际内容 = 你关心的 bug 修复 + 两个在同一比较区间合并的大功能（Prometheus Strict、Ultragoal HUD 进度）。

从仓库的 git 历史可以印证这一合入路径（提交29e87a24 "Ship 0.18.2 from the closed post-0.18.1 issue train"），并看到几个代表性 PR 被一起合入：

• #2472 feat(hud): show ultragoal progress（HUD 展示 Ultragoal 进度）以及后续的852932bd fix(hud): tighten ultragoal review followups；
• #2437 feat(prometheus-strict-question-surface-dev)（Prometheus Strict 的omx question路由表面）与c2da7f99 feat(prometheus-strict): require second planning round、f1dffc25 feat(prometheus-strict): pin researcher mini fanout；
• #2471/a9a1c070 Fix duplicate native hooks and trust-state loss for project-scope launches（项目级启动时原生 hooks 重复与信任状态丢失）；
• #2432/86170773 Merge PR #2432（Autopilot 链状态可见性）；
• #2467/ba2271ed Preserve auditable ultragoal recovery when Codex goal storage is unavailable（Codex goal 存储不可用时保留可审计的 Ultragoal 恢复）；
• #2463/4fbdaacc Clarify unsafe madmax same-directory lock contention、#2461/ba2c0688 Keep tmux HUDs scoped to their leader session、#2457/5018c64f Bound desktop notify dispatch after stale turns等。

对于使用者来说，理解这个背景的意义在于：如果你此前在dev分支上已经观察到其中某些修复，0.18.2 就是它们正式进入稳定主线的时点。

Highlights 一：post-0.18.1 关闭 bug 列车全部合入

发布说明将这批修复概括为七大类：

• doctor / plugin hook 诊断：插件模式下的 doctor 检查现在直接校验插件 hook 清单（manifest），而不是把用户反复引导到无效的setup --force指引；
• Autopilot 链可见性：Autopilot 激活时暴露其持久化的链式状态，便于追踪；
• tmux / HUD / madmax 回归：见下文 "Fixes / compatibility" 分类详解；
• Team Stop 泄漏：陈旧或外来 Team Stop 状态现在失败关闭（fail closed）；
• 通知 turn-ended 风暴：Codex Desktop 的 turn-ended 通知派发被限流（bounded），避免陈旧 turn 触发通知风暴；
• Ultragoal goal 存储恢复：Codex goal 存储不可用时，Ultragoal 记录为可恢复的 blocked 证据，而不是削弱最终 checkpoint 对账；
• research-planning 措辞：研究规划边界措辞澄清（9f6c6fa0 Clarify research planning boundaries）；
• 项目级原生 hook 重复：项目作用域运行时CODEX_HOME不再以导致 hooks 重复、信任状态丢失的方式镜像 hook/配置文件。

这些条目既是缺陷修复，也是 0.18.2 中最值得升级的理由：它们集中在会话状态、HUD 渲染、通知派发与多进程生命周期上，属于长期运行工作流最容易踩中的"慢性病"。

Highlights 二：Prometheus Strict 配方工作流

Prometheus Strict 是本版本合入的一个以配方（recipe）形式存在的规划工作流。发布说明强调它现在具备完整的表面：omx question路由、native agent 定义、catalog 条目、plugin 镜像以及 dogfood 文档。

它是配方（recipe），不是技能

仓库中的 prometheus-inspired-deliberation.md 明确说明这是non-canonical（非规范化）配方，不是活跃的 OMX skill、keyword、hook 或 native-agent 表面，且不随包发布名为$prometheus-strict的可调用技能。它是对 OMO Prometheus 高层概念的启发式再实现（concept-only guidance，MIT 许可），并未复制任何 OMO 源码文本。使用前提是：操作员希望在规范路径$deep-interview -> $ralplan -> $ultragoal之上额外增加一份手动检查清单。

配方步骤如下：

1. 运行$deep-interview，直到需求、非目标（non-goals）、验收标准与未决假设全部显式化；
2. 运行$ralplan，并要求计划明确陈述：目标与非目标、证据与假设的区分、验证门（verification gates）、回滚或升级触发条件、是否存在真正独立的$team车道；
3. 进入$ultragoal之前，用三个问题人工挑战计划：还有哪些歧义可能改变实施范围？哪种验证能抓住代价最高的失败？什么样的工作拆分会造成所有权冲突或合并风险？
4. 若答案改变计划，修订$ralplan工件本身，而不是创建新的工作流表面；
5. 将获批计划交给$ultragoal；只有在具体 Ultragoal story 内需要并行车道时才启动$team。

边界同样清晰：不调用$prometheus-strict（没有随包提供该技能）；不为该配方新增 Metis/Momus/Oracle 这类 prompt-backed native agent；不创建独立的 Prometheus 工件约定，继续使用既有的$deep-interview、$ralplan、$ultragoal工件。

Dogfood 证据：三类场景的实测数据

发布说明提到的 "dogfood docs" 即是 dogfood-2026-05-22.md。它记录了三个场景的 Agent 执行 dry-run 结果，可作为该规划表面如何工作的实证：

三个场景共同验证了其核心机制——6 项清单（6-item checklist）清除制：objective、scope IN+OUT、acceptance、test strategy、handoff target、no outstanding CRITICAL，每一项都要落到USER_ANSWERED、INFERRED_FROM_SPEC或ABSORBED_WITH_CITATION三态之一。场景 C 还展示了"吸收与浮现"的比例控制：吸收 6 项、浮现 5 个 CRITICAL 问题（如"JWT 与 cookie 会话是共存还是切换""回滚是否允许使已签发 JWT 失效""哪些消费者第一天必须兼容"），最终全部落入清单状态。这与提交历史中6a7eac6d test(prometheus-strict): add contract assertions for checklist clearance and Turn Termination Rules、59ceec34 feat(prometheus-strict): replace count-based clearance with 6-item checklist and add Turn Termination Rules互相印证：0.18.2 合入的 Prometheus Strict 表面，其清除判据已经从事先计数改为结构化清单，并配套了契约断言测试。

Highlights 三：Ultragoal 进度进入 HUD

0.18.2 将活跃持久化目标的进度与 review 后续状态直接呈现在 HUD 上，让长时间运行的工作流不再"黑盒"。仓库中的 HUD 状态实现 state.ts 给出了这一能力的源码级证据：

• readUltragoalState(cwd)读取.omx/ultragoal/goals.json（路径常量定义于 artifacts.ts 的ULTRAGOAL_DIR = '.omx/ultragoal'、ULTRAGOAL_GOALS = 'goals.json'、ULTRAGOAL_LEDGER = 'ledger.jsonl'）；
• 对每个 goal 归一化后，按ULTRAGOAL_ACTIVE_STATUSES（in_progress、review_blocked、needs_user_decision）与ULTRAGOAL_UNRESOLVED_STATUSES（pending、in_progress、failed、review_blocked、needs_user_decision）分别统计 pending / in_progress / failed / review_blocked / needs_user_decision / unresolved 数量；
• 完成阻塞判断复用了与artifacts.ts一致的语义：superseded目标须等其所有替代目标解决、review_blocked目标须等指定的 resolver 完成且反向指针闭合（isHudCompletionBlockingUltragoalGoal）。

这意味着 HUD 上显示的"进度"不是简单的计数，而是与 Ultragoal 完成语义严格对齐的派生状态：一个review_blocked的最终 story 即使其 resolver 已完成，也必须通过reviewBlockerResolution双向校验才会在 HUD 中反映为可关闭。测试目录 artifacts.test.ts 中有大量对应用例（如"两个未解决 review-blocked 父目标指向同一个 resolver 时不终态化""review-blocked 父目标指定的 resolver 反向指针指向其他目标时不终态化""最终聚合候选被 steering-blocked 时不终态化"），发布说明中提到的852932bd fix(hud): tighten ultragoal review followups正是这类收紧的后续修复。

Highlights 四：工作流交接更显式

发布说明把四项变更归入"工作流交接显式化"：

1. deep-interview 保持为需求边界：对应 PR#2427/03972c51 Merge pull request #2427 from Yeachan-Heo/fix/issue-2426-deep-interview-handoff——修复 issue-2426 的 deep-interview 交接问题；
2. Autopilot 记录持久化阶段状态：提交ccbe7689 Make autopilot activation expose its durable chain与86170773 Merge PR #2432，让 Autopilot 激活暴露其持久化链，交接不再是内存态；
3. ralplan consensus 要求 Architect/Critic 证据：ralplan 的 advisory 生命周期在 0.18.x 系列逐步收紧为"证据驱动"。源码 advisory.ts 展示了其终态语义：只有outcome=approved且integrity_status=proven时 fence 才会进入closed，且要求plan_manifest_sha256、architect_review_sha256、critic_review_sha256、evidence_bundle_sha256全部绑定；缺失任一即判为approved_proven_binding_invalid损坏态。同时 advisory-activation.ts 中的激活只接受producer === 'native'且threadKind === 'root-or-drift'（ralplan_advisory_activation_authority_required），配合ralplan-state.json的workflow_variant: 'advisory'绑定与 generation 标识，确保只有权威激活者能推进生命周期；
4. ralplan 示例默认改用 Ultragoal 做持久执行：提交5b6a2ddd Align ralplan handoff docs with durable goal default与882dd838 Merge PR #2455（issue-2453），文档层面的交接链收敛为deep-interview → ralplan(advisory) → ultragoal。

Fixes / compatibility 逐条详解

发布说明的修复清单可按模块拆解：

doctor / 插件 hook

• 插件模式 doctor 校验插件 hook 清单本身，而非循环引导setup --force。这意味着"doctor 误诊"类体验问题在本版本被根治：诊断直接定位 manifest，而不是让用户反复重装。

native subagent 与项目级 CODEX_HOME

• native subagent 抑制带引号的工作流关键字激活（避免子代理误触发 workflow）；
• 项目级运行时CODEX_HOME不再以"重复 hooks / 丢失信任状态"的方式镜像 hook 与配置文件（提交a9a1c070，PR#2471）。

tmux / HUD / madmax

• tmux 3.2a resize hooks 加固；
• OMX_ROOTHUD 面板支持盒式（boxed）渲染；
• HUD 面板按 leader 会话归属（提交ba2c0688 Keep tmux HUDs scoped to their leader session，PR#2461），避免跨 leader 串面板；
• madmax 支持独立的 detached 启动，且不再等待陈旧锁（PR#2452，issue-2451）；
• 澄清 madmax 同目录锁竞争风险（PR#2463，issue-2462），并新增同目录锁诊断。

Team Stop 与通知

• Team 启动的直接触发要求证据；
• 陈旧/外来 Team Stop 状态失败关闭；
• Codex Desktop turn-ended 通知派发限流（提交5018c64f Bound desktop notify dispatch after stale turns，PR#2457，issue-2456），通知风暴被抑制。

Ultragoal 恢复

• Codex goal 存储不可用时（如no such table: thread_goals这类 DB/schema/context 错误），Ultragoal 不再硬性要求--status complete对账，而是记录为可审计的、非终态的 blocked 证据（提交ba2271ed，PR#2467，issue-2466）。artifacts.ts 中的buildUnavailableCodexGoalRemediation给出了标准恢复动作：用omx ultragoal checkpoint --goal-id <id> --status blocked --evidence "<get_goal 不可用原因>" --codex-goal-json "<错误 JSON 或路径>"记录阻塞，随后在get_goal可用的 Codex goal 上下文中继续，从而保住严格完成对账的可证性。

Closed issue audit 与合并 PR 清单

发布说明的 issue 审计结论如下：

• 已完成并合入dev：#2429→#2431、#2430→#2432、#2433→#2434、#2435→#2436、#2438→#2439、#2440→#2442、#2443→#2447、#2445→#2448、#2449→#2450、#2451→#2452、#2453→#2455、#2456→#2457、#2460→#2461、#2462→#2463、#2466→#2467、#2468→#2469、#2470→#2471；
• 关闭但未进入执行合并：#2428（范围过大，要求拆分为更窄的后续 issue）与 #2465（贡献门关闭）。

合并 PR 清单：#2415、#2427、#2431、#2432、#2434、#2436、#2437、#2439、#2442、#2447、#2448、#2450、#2452、#2455、#2457、#2461、#2463、#2467、#2469、#2471、#2472。

其中与前面分析对应的关键映射：#2437 = Prometheus Strict question 表面、#2472 = HUD Ultragoal 进度、#2427 = deep-interview 交接、#2432 = Autopilot 链状态、#2457 = 通知限流、#2461 = HUD 归属、#2463 = madmax 锁诊断、#2467 = Ultragoal 恢复、#2471 = 项目级 hooks 修复、#2455 = ralplan 文档对齐。

验证与发布流程

发布说明给出的验证矩阵（0.18.2合入前实际执行）：

• npm run build
• npm run verify:native-agents
• npm run verify:plugin-bundle
• npm run test:recent-bug-regressions:compiled
• 定点测试：node --test dist/hud/__tests__/authority.test.js dist/hooks/__tests__/notify-fallback-watcher.test.js dist/scripts/__tests__/notify-dispatcher.test.js dist/ultragoal/__tests__/artifacts.test.js dist/cli/__tests__/codex-plugin-layout.test.js dist/cli/__tests__/setup-install-mode.test.js dist/hooks/__tests__/keyword-detector.test.js dist/team/__tests__/runtime.test.js
• npm run sync:plugin:check
• cargo check --workspace（Rust 侧工作区编译检查）

定点测试文件的选取本身就能反推出本次改动的核心区域：HUD 面板权威（hud/authority）、通知回退监视与派发（notify-fallback-watcher、notify-dispatcher）、Ultragoal 工件（ultragoal/artifacts）、插件布局与安装模式（codex-plugin-layout、setup-install-mode）、关键字检测（keyword-detector，对应 native subagent 抑制带引号关键字激活）、Team 运行时（team/runtime，对应 Team Stop 失败关闭）。

此外，tag 时刻的发布工作流会在v0.18.2存在后基于 RELEASE_BODY.md 重新生成 release body，保证发布说明与实际 tag 一致。

升级建议与使用前提

结合源码与发布说明，给出几条可操作的结论：

1. 如果你在dev上体验过上述修复，或正被 tmux/HUD、通知风暴、madmax 锁、Team Stop 泄漏、插件 doctor 误诊等问题困扰，0.18.2 是值得升级的修复型版本；它没有引入破坏性配置迁移，重点在状态机收紧与边界修复。
2. Prometheus Strict 是配方而非技能：不要期望$prometheus-strict开箱即用；它存在于 docs/recipes 与 prometheus-inspired-deliberation.md 的指导中，落地方式是手动执行$deep-interview → $ralplan → $ultragoal并套用 6 项清单与三问挑战。dogfood 证据（dogfood-2026-05-22.md）可作为期望值的参照：trivial 任务 0 轮 0 问、simple 任务 1 轮 1 问、architecture 任务 2 轮 5 问。
3. HUD 的 Ultragoal 进度与完成语义强绑定：review_blocked目标必须由指定 resolver 双向确认后才能解除阻塞，superseded目标必须等替代目标全部解决；如果你在 HUD 上看到进度"卡住"，优先检查这些元数据是否闭合（可参考 artifacts.test.ts 中的反例用例）。
4. ralplan 的 advisory 生命周期是证据驱动的：终态closed需要approved + proven且 plan/architect/critic/evidence 四个摘要全部绑定；执行交接只对native+root-or-drift激活者开放。任何证据缺失都会落入损坏态（advisory.ts中可见大量*_invalid判定），这保证了共识门不被绕过。

0.18.2的整体画像是一个"稳"字：没有新的大功能面，但把 0.18.1 之后积累的 17 个 issue 与 21 个 PR 的修复一次性送达main，并用 8 组定点测试与全量构建、native agents 校验、插件包校验、Rust workspace 编译检查兜底。对正在使用 Autopilot 链、Team 并行、Ultragoal 长期目标与 HUD 监控的用户而言，这是低风险、高收益的一次升级。

【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex