oh-my-codex 0.18.10 发布就绪报告解析：从可靠性修复到可复现的发布验证门禁

导读

本文基于仓库中的发布就绪评估文档 docs/qa/release-readiness-0.18.10.md，系统拆解 oh-my-codex 0.18.10 这一"可靠性列车"版本：它打包了哪几类回归修复、为什么每次发版前要跑一长串本地验证门禁，以及这些门禁对应的源码与测试依据。读完本文，你将理解该项目"先本地证据、后远程 CI、再发布流水线"的三段式发布协议，并能复现 0.18.10 的完整发布就绪检查流程。

版本范围与发布背景

0.18.10 是 oh-my-codex 继 v0.18.9 之后的下一个补丁版本，其发布准备基线如下：

项目	内容
上一个标签	v0.18.9
候选分支	origin/dev（干净发布工作树）
冻结的 dev 候选提交	bd365573f0cee7dfb300c71de447482fc5356f5d（Debloat generated AGENTS bootstrap）
计划创建的标签	v0.18.10
分支 CI 证据	GitHub Actions run 27067833038，对 bd365573 完成且成功
发布时积压	无未解决问题；外部草稿 PR 2737 基于 dev，未达到合并就绪，不属于本次发布

需要说明的是，本仓库当前根目录 package.json 已演进到 0.21.2（见 package.json），0.18.10 属于历史发布流程记录。本文聚焦该文档所记录的发布就绪方法论，它作为可复现的质量门禁模板，在后继版本中仍持续复用。

发布范围：0.18.9 之后的"可靠性列车"

0.18.10 打包了五个方向的修复，每个方向都有明确的问题域与对应 PR：

1. Stop hook 可靠性：畸形 stdin 恢复（#2731）、planning 空设备重定向（#2730）、侧会话 Stop hook 隔离（#2743）、hook 插件 runner stdin EAGAIN 处理（#2722）。
2. Team/HUD 可靠性：worker Stop 提醒路由为团队 steering（#2719）、tmux HUD 重复归属修复（#2738）、阻止 worker 启动脚本拥有 HUD pane（#2739）。
3. Autopilot/Ultragoal/ralplan 护栏：Autopilot 执行契约基础（#2720）、Ultragoal 团队上下文显式 fail-closed（#2736）、ralplan 原生 subagent leader gate 修复（#2735）。
4. Auth 与生成 Agent 指导：订阅 Codex 默认值种子化（#2725）、ultrawork 文档路由澄清（#2717）、生成的 AGENTS bootstrap 瘦身同时保留必需契约（#2741）。
5. 发布卫生：Biome 2.4.16 升级（#2715）及 0.18.9 发布后证据提交纳入比较范围。

合并 PR 清单：14 个 PR 的技术归属

文档列出的 14 个合并 PR 可以直接映射到上述修复方向，便于按主题追溯：

• 工具链与文档：#2715（Biome 2.4.15 → 2.4.16）、#2717（ultrawork 文档路由）、#2741（AGENTS bootstrap 瘦身）。
• Hook 可靠性：#2722（plugin runner stdin EAGAIN）、#2730（planning hook 空设备重定向）、#2731（Stop 畸形 stdin 恢复）、#2743（侧会话 Stop hook 隔离）。
• 团队与 HUD：#2719（worker Stop 提醒路由为 team steering）、#2738（重复 tmux HUD 归属）、#2739（worker 启动脚本不得拥有 HUD pane）。
• 护栏：#2720（Autopilot 执行契约）、#2725（订阅 Codex 默认值种子化）、#2735（ralplan 原生 subagent leader gate）、#2736（Ultragoal 显式 fail-closed）。

比较范围内还有 4 个非 PR 的内部提交：1bc3f9d0（0.18.9 Fulcio 中断的临时 npm fallback）、f2efc145（记录 0.18.9 发布 fallback 证据）、75bc9f97（在发布说明中命名 native manifest）、73935230（准备 0.18.9 最终 CI 证据门禁）。这些提交不改变产品行为，只影响发布流程本身。

版本与锁文件审计：四处版本号必须同步

0.18.10 的版本同步检查覆盖四个位置，任何一处遗漏都会导致发布工件版本不一致：

1. 根目录 package.json 与 package-lock.json 的 version 字段；
2. 根目录 Cargo.toml workspace 包版本与根目录 Cargo.lock 中的 workspace 包版本；
3. plugins/oh-my-codex/.codex-plugin/plugin.json 的 version 字段。

对应验证命令是 node dist/scripts/check-version-sync.js --tag v0.18.10（脚本实现见 src/scripts/check-version-sync.ts），它会在发布前确认四处版本号与目标 tag 完全一致，防止出现"npm 包是 0.18.10 而插件 manifest 还停留在 0.18.9"这类发布事故。

本地验证门禁：发布前必须全绿的证据清单

文档记录了在干净发布工作树中逐条执行的 14 项本地验证，这是整个发布就绪流程的核心部分。每项都输出到 .omx/release-0.18.10/logs/ 下的独立日志文件，形成可追溯的证据链：

门禁	命令	证据说明
依赖安装	npm ci	安装 151 个包，保留依赖图中的既有 audit 警告
TypeScript 构建	npm run build	产物进入 dist/
版本同步	node dist/scripts/check-version-sync.js --tag v0.18.10	四处版本号一致
Lint	npm run lint	Biome 2.4.16 检查
未使用代码检查	npm run check:no-unused	基于 tsconfig.no-unused.json 的 tsc 检查（package.json）
原生 Agent 验证	npm run verify:native-agents	运行 src/scripts/verify-native-agents.ts
插件镜像同步检查	npm run sync:plugin:check	运行 src/scripts/sync-plugin-mirror.ts 的 --check 模式
插件包验证	npm run verify:plugin-bundle	同为 sync-plugin-mirror 检查，见 package.json
目录文档检查	node dist/scripts/generate-catalog-docs.js --check	确认生成文档与仓库一致
近期回归测试	npm run test:recent-bug-regressions:compiled	运行 package.json 列出的 7 个测试文件；文档记录 runtime 子套件约 139 秒，全部通过
团队 worker 运行时身份	npm run test:team:worker-runtime-identity:compiled	运行 src/team/tests/worker-runtime-identity.test.ts
插件边界	npm run test:plugin-boundaries:compiled	运行 4 个插件布局/所有权测试，见 package.json
显式终止契约	npm run test:explicit-terminal-contract:compiled	运行 package.json 列出的 5 个测试文件
打包与冒烟	npm pack --dry-run + npm run smoke:packed-install	包 oh-my-codex-0.18.10.tgz，3.9 MB，解包 24.3 MB，3045 个文件；冒烟脚本 src/scripts/smoke-packed-install.ts
补丁卫生	git diff --check	无空白错误

此外 prepack 钩子会在打包前自动执行构建与验证链：npm run build && npm run verify:native-agents && npm run sync:plugin && npm run verify:plugin-bundle && npm run clean:native-package-assets（package.json），从机制上防止未验证产物被打包。

源码级深挖：三个 0.18.10 修复的实现证据

1. Hook 插件 runner 的 stdin EAGAIN 处理（#2722）

该修复的核心是让 runner 读取 stdin 时不触碰文件描述符。实现位于 src/hooks/extensibility/plugin-runner-stdin.ts：readStdin 通过 for await 异步迭代输入流，使用 TextDecoder 以 stream: true 模式增量解码，保证多字节 UTF-8 字符跨 chunk 边界不损坏，最后 trim() 去除首尾空白。

测试 src/hooks/extensibility/tests/plugin-runner.test.ts 直接复现了 EAGAIN 场景：构造一个 fd getter 会抛出 code: 'EAGAIN' 的 resource temporarily unavailable 错误的流，验证 readStdin 依然能正确返回拼接后的 JSON。另有测试验证 65,535 字节偏移处 € 多字节字符跨流边界时 payload 完整（L97-L136），以及空 stdin 返回 empty_request、无效 JSON 返回 invalid_json、缺 onHookEvent 返回 invalid_export 等错误契约。

2. 阻止 worker 启动脚本拥有 HUD pane（#2739）

问题背景是 worker 的启动脚本若携带 HUD 相关的环境变量（如 OMX_SESSION_ID 与 OMX_TMUX_HUD_LEADER_PANE_ENV），会被 HUD 归属解析误判为 HUD 的合法 owner，导致 pane 归属错乱。修复后，交互式 worker 启动命令会剥离 HUD 归属环境变量。测试证据在 src/team/tests/tmux-session.test.ts：scrubs HUD ownership env from interactive worker startup commands 与 keeps HUD-looking prompt text out of worker startup env assignments 两个用例锁定了该行为。HUD 归属判定本身由 src/hud/tests/tmux.test.ts 覆盖，包括 env 前缀、引号包裹、外层转义、重复赋值拒绝等解析规则。

3. ralplan 原生 subagent leader gate（#2735）

该修复保证只有真实 leader 线程的 root id 才被授权进入 ralplan 执行交接。测试在 src/ralplan/tests/advisory.test.ts 中构造了 subagent-tracking.json，包含 leader_thread_id 与带 provenance_kind: 'native_subagent' 的子代理记录，并用 foreign-root 场景验证非 leader 的 root 被拒绝（L215 附近）。配套的 src/ralplan/documented-leader-preflight.ts 负责在不可变文档 leader 语境下做中立化预检，ralplan_consensus_gate: { complete: false } 在多个测试中作为未达成共识的基准状态出现。

远程发布门禁与就绪结论

本地证据全绿后，文档列出的剩余发布门禁全部处于 pending 状态，按顺序执行：

1. 推送 origin/dev 后等待 release-prep 分支 CI 变绿；
2. main 分支快进合并后等待 main promotion CI 变绿；
3. 推送 v0.18.10 标签触发 tag 驱动的发布工作流；
4. 生成 GitHub release 证明（release proof）；
5. 完成 npm 发布并保存 npm proof。

就绪结论明确：本地发布准备已完成可推送——版本同步、定向发布门禁、包 dry-run、packed-install 冒烟全部通过；远程分支 CI、main promotion、tag 工作流、GitHub release 证明与 npm 证明是最终发布前的剩余关卡。

可复现的发布就绪检查清单

将 0.18.10 的流程抽象为通用清单，可复用于后续版本：

1. 冻结 dev 候选提交，记录其 SHA 与分支 CI run id；
2. 核对四类版本号（package.json、package-lock.json、Cargo workspace、plugin manifest）；
3. 在干净工作树执行 npm ci → npm run build → lint/no-unused → 原生 Agent 与插件验证 → 定向回归测试 → npm pack --dry-run → npm run smoke:packed-install → git diff --check，逐条留存日志；
4. 推送分支、快进 main、打 tag，逐步收集分支 CI、promotion CI、tag 工作流、GitHub release 与 npm 的五项远程证据；
5. 只有本地证据与远程证据全部闭环，才宣告版本发布完成。

这套"先本地证据、后远程 CI、再发布流水线"的三段式协议，正是 oh-my-codex 从 0.18.10 延续至今的发布质量基线，其完整上下文可继续阅读 docs/qa/release-readiness-follow-up.md 与 RELEASE_PROTOCOL.md。