oh-my-codex 0.18.4 发布就绪评估全解：补丁列车范围、PR 清单与本地验证门禁

oh-my-codex 0.18.4 发布就绪评估全解补丁列车范围、PR 清单与本地验证门禁【免费下载链接】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-codexdocs/qa/release-readiness-0.18.4.md是 oh-my-codex 项目在切出v0.18.4标签前记录的发布就绪评估文档属于 RELEASE_PROTOCOL.md 定义的强制性发布产物之一。本文以该文档为主体结合 0.18.4 发布说明 与仓库源码完整还原这次补丁列车的发布范围、十二个合并 PR 的技术内容、九项本地验证门禁的执行细节以及本地就绪 ≠ 已发布的最终判定逻辑。读完本文你将掌握 oh-my-codex 一类多包仓库的标准发布就绪流程也能针对 0.18.4 涉及的功能定位到对应源码文件继续深挖。一、发布范围从 v0.18.3 到 v0.18.4 的比较基准发布就绪评估的第一步是冻结比较范围这直接决定了后续 PR 清单和发布说明的事实边界。0.18.4 文档记录的 Range 如下项目值上一标签v0.18.3commitf512a177候选分支dev位于8ddeb799且origin/main上的 release-body 署名修复在 0.18.4 元数据 bump 前已合并回dev待创建标签v0.18.4对比命令打标签前v0.18.3..HEAD打标签后v0.18.3..v0.18.4为什么范围如此重要RELEASE_PROTOCOL.md 第 1 节明确规定发布说明和 GitHub release body必须基于精确的 compare range 生成而不是凭记忆或只依据发布评审中最后一个修复。协议给出的标准做法是# 验证上一标签是候选分支的祖先 git merge-base --is-ancestor $PREV $CANDIDATE # 从精确范围生成提交与 PR 清单 git log --oneline --decorate $PREV..$CANDIDATE git log --format%h %s $PREV..$CANDIDATE | grep -Eo #[0-9] | sort -u对应到 0.18.4 这次 cutdev分支在准备期间需要先吸收origin/main的 release-body 署名修复再做版本元数据 bump保证最终v0.18.4标签与main指向同一个发布提交避免 compare 范围与实际产物错位。二、0.18.4 补丁列车七个修复主题的源码级解读0.18.4是紧随0.18.3的补丁版本打包的是落地在dev上的运行时安全与运维体验修复。从源码结构看这些修复横跨 Ultragoal、explore、Team/HUD、Autopilot、插件原生 Agent、Codex 信任同步与 ralplan 七个子系统下面逐一展开。1. Ultragoal checklist 解析与 Stop 恢复回路加固#2499、#2507两个 PR 解决同一类问题解析层误判与恢复回路死循环。#2499 让 Ultragoal 解析忽略纯标签的 checklist 小节避免把没有实质目标的普通小节当作可执行目标参与进度计算#2507 修复已完成聚合目标仍触发不可恢复的 Stop 恢复循环即目标已经 complete 时恢复逻辑不应再反复尝试 Stop 恢复。Ultragoal 的目标、账本与状态文件都集中在 src/ultragoal/artifacts.tsULTRAGOAL_DIR .omx/ultragoal、goals.json与ledger.jsonl分别承载目标结构与流水账目标状态枚举包括pending / in_progress / complete / failed / review_blocked / needs_user_decision。该文件还定义了ULTRAGOAL_STEERING_MUTATION_KINDS如add_subgoal、split_subgoal、mark_blocked_superseded与ULTRAGOAL_STEERING_SOURCES对应测试见 artifacts.test.ts。修复的本质是无论从哪个来源用户提示提交、finding、CLI触发状态变更都必须先通过结构不变量与证据校验已完成的聚合目标不得再进入恢复回路。2. omx explore 正式弃用兼容行为保留#25040.18.4 在运行时指导中把omx explore标记为弃用但保留其兼容行为——旧调用方不会被立刻打断。弃用契约直接写在 src/cli/explore.ts 中export const EXPLORE_DEPRECATION_MESSAGE [ omx explore is hard-deprecated and the direct command surface has been removed., Use normal Codex repository inspection tools/subagents for read-only repository lookups., Use omx sparkshell -- command only for explicit shell-native read-only evidence or --tmux-pane summaries., ].join( );exploreCommand的实现非常直白只有--help/-h/help参数会打印EXPLORE_HELP后正常退出其余调用一律抛出弃用错误并附带迁移指引。官方推荐的迁移路径有两条简单的只读仓库查询 → 使用 Codex 常规仓库检查工具/子代理需要显式 shell 原生只读证据 → 使用omx sparkshell -- command或--tmux-pane摘要。同时源码保留了OMX_EXPLORE_BIN环境变量与内置 harness 的探测逻辑resolvePackagedExploreHarnessCommand并针对 Windows 平台给出内置 harness 不可用的原因说明依赖 POSIX sh/bash 包装器建议在 Windows 上设置自定义 harness 或改用 sparkshell。3. Team/HUD 归属修复worker 不再接管 HUD reconcile重复 pane 收敛#2502、#2525#2502 确保worker 的UserPromptSubmit路径不再拥有 HUD reconcile 权限——HUD 对账仍然由 leader 独占避免 worker 提示提交时触发与 leader 的对账竞争#2525 修复重复 HUD pane 生成收敛问题同一 leader 的 HUD pane 不再被重复拉起。从 src/team/tests/api-interop.test.ts 的用例marks only active leader-owned teams as stopped on session end与 tmux-session.test.ts 中的omx-tmux-win32-hud-reconcile-窗格标识可以看出HUD 生命周期始终以leader 所有权为不变量worker 侧只读不写。这一点与 0.18.3 的 HUD 清理工作一脉相承属于对上一版本 pane 生命周期收敛的补充修复。4. Autopilot 深度访谈可等待 omx question 回答#2508此前 Autopilot 的深度访谈deep-interview问题处理会在应当等待用户回答时过早继续。0.18.4 让 Autopilot 的深度访谈路径可以等待omx question的回答而不是跳过等待直接推进。等待逻辑位于 src/question/autopilot-wait.ts对应测试见 deep-interview.test.ts测试中通过runOmxQuestion与assert.rejects验证等待行为。这个修复让提问 → 阻塞等待 → 拿到答案再继续成为 Autopilot 访谈流程的强制节奏避免在缺少关键上下文时继续执行。5. 插件原生 Agent评审角色就绪、角色搭建 CI 与过时 Agent 保留#2515、#2519、#2521三个 PR 从三个角度加固插件原生 Agent 体系#2515 让omx doctor暴露插件原生 reviewer 角色的就绪状态运维可以直接看到缺了什么#2519 修复插件原生 Agent 角色搭建的 CI 覆盖保证角色初始化路径有测试兜底#2521 修复仅由插件提供的过时obsolete原生 Agent 被误删的问题——过时清理不应波及插件独占的 Agent。原生 Agent 的验证脚本在 verify-native-agents.js发布门禁中对应npm run verify:native-agents0.18.4 门禁记录为 22 个可安装原生 Agent、37 个 setup 提示资源。6. 项目本地 Codex 信任同步重启安全#2522#2522 修复了项目本地 Codex 信任同步trust sync重启后的回归问题此前重新同步可能污染本地配置0.18.4 保证 trust sync 重新启动时不会损坏项目本地的 Codex 配置文件。这属于典型的幂等重启问题——同步逻辑必须能在已存在信任状态的情况下安全重入。7. Ralplan 评审子代理契约收紧#2501、#2524#2524 收紧ralplan reviewer 子代理的指令契约让评审证据在执行交接前保持 grounded避免评审结论脱离证据#2501 让 ralplan 在等待前先对已完成的子代理做 reconcile防止已完成子代理的状态未对齐就进入等待阶段。ralplan 的评审证据体系可以在 advisory-evidence.ts 及其测试 advisory.test.ts 中看到端倪证据通过evidence_bundle_sha256与生命周期绑定测试覆盖了证据摘要变更/不可读导致的evidence_digest_changed/evidence_unreadable失效场景并要求证据严格绑定 root、session、activation 与 generation。三、合并 PR 清单总表0.18.4 共合并 12 个 PR覆盖上述七个主题PR主题#2499忽略纯标签的 Ultragoal checklist 小节#2501ralplan 等待前先 reconcile 已完成子代理#2502worker UserPromptSubmit 不再拥有 HUD reconcile#2504运行时指导中弃用omx explore#2507防止不可恢复的 Ultragoal Stop 恢复循环#2508允许 Autopilot 深度访谈等待omx question#2515doctor 暴露插件原生 reviewer 角色就绪#2519修复插件原生 Agent 角色搭建 CI#2521保留仅插件提供的过时原生 Agent#2522修复项目本地 Codex 信任同步重启回归#2524收紧 ralplan reviewer 子代理契约#2525修复重复 HUD pane 生成收敛该清单与 release-notes-0.18.4.md 中的 PR 清单完全一致这也是 RELEASE_PROTOCOL.md 第 2 节从证据而非记忆写发布说明的直接体现。四、本地验证证据九项发布门禁全记录打标签前0.18.4 完成了九项本地门禁全部 PASS每一项都有独立日志记录.omx/logs/release-0.18.4-*.log属于发布准备期的本地产物#门禁命令PASS 证据要点1release workflow 版本同步探测package0.18.4、workspace0.18.4、tagv0.18.4三处一致2npm run build构建通过3npm run lint检查 681 个文件无自动修复4npm run check:no-unused无未使用代码错误5npm run verify:native-agents22 个可安装原生 Agent、37 个 setup 提示资源6npm run sync:plugin29 个规范 skill 目录与插件元数据同步7npm run verify:plugin-bundle29 个规范 skill 目录与插件元数据验证通过8node dist/scripts/generate-catalog-docs.js --checkcatalog check ok9git diff --check无空白错误此外还有包体证据npm pack --dry-run生成oh-my-codex-0.18.4.tgz包体积 3.6 MB解包后 22.1 MB共 2974 个文件。这些命令在 package.json 中均有对应脚本定义例如verify:native-agents→node dist/scripts/verify-native-agents.jssync:plugin/verify:plugin-bundle→node dist/scripts/sync-plugin-mirror.js/--checkcheck:no-unused→tsc -p tsconfig.no-unused.json发布说明中列出的门禁集合与就绪文档一致build、lint、check:no-unused、verify:native-agents、sync:plugin、verify:plugin-bundle、generate-catalog-docs --check、git diff --check、npm pack --dry-run并明确指出标签推送后由 GitHub release workflow 承担跨平台原生资源与 npm 发布权的最终门禁——本地门禁无法替代发布流水线。五、不打标签/不发布的证据与外部发布动作0.18.4 就绪文档专门记录了本地准备阶段未执行发布的证据git tag --list v0.18.4在打标签前无本地v0.18.4标签git tag --points-at HEAD显示发布提交前 HEAD 无标签本地准备未运行任何npm publish发布权完全委托给v0.18.4标签推送后触发的 release workflow。随后的外部发布动作共六步使用 Lore 提交协议提交发布准备推送带发布准备与合并后的 main 署名修复的dev将dev合并到main从合并后的main创建并推送标签v0.18.4验证 GitHub release workflow 产物与 npm 发布必要时在发布后把 CI/发布证据补回本文档。这套顺序与 RELEASE_PROTOCOL.md 第 5 节的发布序列一致先合并已验证的候选到main→ 等待mainCI 绿 → 发布材料齐备后再创建/推送标签 → 等待标签触发的 release workflow 通过 → 验证 GitHub release 与npm view oh-my-codex version。发布完成后还需把devfast-forward 到已发布的main提交并把dev的 package/plugin/Cargo 元数据 bump 到下一个开发基线版本。六、最终就绪判定与发布边界文档的结论非常克制且明确本地发布准备已就绪可以提交、合并到main并切标签但在标签 workflow 与 npm/GitHub release 证据验证通过之前不得宣称 0.18.4 已发布。这正是 RELEASE_PROTOCOL.md 第 7 节停止条件的落地——一次发布只有在以下条件全部为真才算完成main与发布标签指向预期提交、dev指向该提交或仅含已记录的发布后修正与下一次版本 bump、GitHub release workflow 绿色、npm 显示预期版本、GitHub release body 准确覆盖完整 compare range、就绪文档包含 CI 与发布证明。就绪文档是发布准备的闸门而发布本身以流水线证据为准。七、延伸阅读0.18.4 发布说明同一补丁列车的用户视角 Highlights 与 FixesRELEASE_PROTOCOL.md本次发布遵循的完整发布协议上一版本就绪评估0.18.3 的 HUD/tmux 清理等前置补丁列车源码证据explore.tsexplore 弃用契约、ultragoal/artifacts.tsUltragoal 目标/账本结构、question/autopilot-wait.ts访谈等待逻辑、ralplan/advisory-evidence.ts评审证据体系。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考