企业官网建设流程全解析

oh-my-codex 0.18.9 发布就绪审计：更新通道、resume 历史修复与全量门禁验证实践

【免费下载链接】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

导读

本文基于 oh-my-codex 仓库中的 release-readiness-0.18.9.md 发布就绪文档，系统还原 0.18.9 这一"更新/运行时可靠性"特性列车的发布全过程：包括稳定版/开发版双更新通道、Windowsnpm.cmd回退、项目级 resume 历史与OMX_ROOT记忆查找修复、omx question在 cmux/tmux 下的环境投递、深度访谈短窗格可见性、HUD 窗格作用域收敛等 15 个合并 PR，以及从版本同步探针、构建、Lint、5787 项测试到 npm 发布（含 Sigstore/Fulcio 故障回退）的完整门禁证据链。读者读完后将掌握：OmX 的发布就绪流程长什么样、每次小版本背后修复了哪些真实问题、以及"冻结候选 → 本地验证 → CI 推广 → 发布 → 收尾同步"这一可复用的发布方法论。

0.18.9 的发布范围：一次"更新与运行时可靠性"列车

0.18.9 不是功能大版本，而是打包了0.18.8之后一组围绕更新机制、运行时可靠性、交互可见性与 CI 加固的补丁集合。按就绪文档的 Release scope 划分，本次范围包含六条主线：

1. 稳定/开发双更新通道：omx update支持stable与dev两种 channel，支持 dev 源包工件安装，并为 Windows 提供npm.cmd回退；
2. 项目级 resume 历史修复：修复隔离启动时项目本地 resume 历史丢失（#2713），并修复 boxedOMX_ROOT下的SessionStart项目记忆查找（#2708）；
3. 问答与深度访谈体验：omx question在 cmux 下通过 export 前缀投递环境变量（tmux-eshim 变通，#2709）、短 tmux 窗格中保持深度访谈问题可见（#2702）、repo 文档支撑的访谈交接（#2690）；
4. Autopilot 与团队行为：Autopilot ralplan 写入守卫改为阶段感知（#2691）、review 子代理尊重 model/effort 设置（#2697）、Ultragoal HUD 在目标完成前保持活跃（#2699）；
5. HUD 与 CI 加固：重复 HUD 对账收敛到发出事件的窗格（#2703）、fork/自托管 CI 加固（#2704、#2693）；
6. 发布卫生：0.18.8 发布后证据清理与就绪审计修正。

此外，冻结的 dev 范围内还有 6 个无 PR 的内部提交（6a897a81、757b84a8、a7482450、dd7f369f、320fe769、403e2549），全部围绕"发布同步证据规范化"与"Fulcio 中断期间的 npm 发布回退记录"。

事实依据：release-readiness-0.18.9.md 的 "Release scope" 与 "Merged PR inventory"、"Internal/no-PR commits in frozen dev range" 小节。

候选版本冻结与范围审计

发布就绪文档在 "Range" 小节精确记录了候选版本的来源与校验方式，这是整个流程的起点：

• 上一标签：v0.18.8；
• 候选分支：dev分支 / 来自dev的 release-prep worktree；
• 目标标签：v0.18.9；
• 冻结的 dev 候选：115b697d153d9a9842fbd3459fefd2fb09df6d94（提交说明为 "Preserve project resume history during isolated launches (#2713)"），即本次发布内容中最后一个需要封存的提交；
• 对比区间：v0.18.8..origin/dev。

冻结后的复验命令非常明确，这也是"可复现冻结"的关键：

# 确认 origin/dev 与本地 HEAD 都指向冻结提交 git rev-parse origin/dev git rev-parse HEAD # 确认 v0.18.8 是 origin/dev 的祖先，保证范围干净 git merge-base --is-ancestor v0.18.8 origin/dev

其中git merge-base --is-ancestor v0.18.8 origin/dev通过，意味着v0.18.8..dev区间内不存在反向合入或分叉，候选范围是线性的、可审计的。另外，在发布准备提交之前，dev 头部的 GitHub Actions CI（run26856266656）对115b697d已完成且成功，这保证了冻结候选在进入本地门禁前就有一份远程 CI 证据。

关于 issue 清单，本地发布准备期间未发现v0.18.8..HEAD区间内有单独关闭的 GitHub issue，整个发布范围完全由上述合并 PR 清单表示。

版本与锁文件审计：一处同步，处处同步

0.18.9 的版本号一致性检查覆盖了 npm 与 Rust 两侧：

• 根package.json与package-lock.json：升到0.18.9；
• 根Cargo.toml与根Cargo.lock：升到0.18.9；
• plugins/oh-my-codex/.codex-plugin/plugin.json：同步到0.18.9；
• crates/omx-sparkshell/Cargo.lock：保持独立的0.1.0历史锁文件，cargo generate-lockfile --manifest-path crates/omx-sparkshell/Cargo.toml执行后不变——它不受 workspace 发布版本约束，workspace 发布版本由根Cargo.toml/ 根Cargo.lock决定。

这条审计的意义在于：OmX 是 npm 包 + Rust 子 crate（sparkshell 等）的混合仓库，如果只改package.json而漏掉plugin.json或根Cargo.toml，发布后的产物会出现版本不一致。仓库为此专门提供了 check-version-sync.js 探针（见下节门禁清单）来机械地保证这一点。

本地验证门禁：从版本同步探针到全量测试

就绪文档 "Local validation evidence" 给出了完整的门禁清单。所有命令在/Users/bellman/Documents/Workspace/oh-my-codex下执行，且会继承会话/运行时变量的门禁在复跑时主动清空了USE_OMX_EXPLORE_CMD、OMX_ROOT、OMX_STATE_ROOT、OMX_TEAM_STATE_ROOT、OMX_SESSION_ID、CODEX_SESSION_ID等变量——这是为了防止本地残留的会话状态污染发布判定。

版本同步与静态门禁

node dist/scripts/check-version-sync.js --tag v0.18.9 # 版本同步探针，PASS npm run build # 构建，PASS npm run lint # Lint，PASS npm run check:no-unused # 未使用代码检查，PASS npm run verify:native-agents # native agents 清单校验，PASS npm run sync:plugin && npm run sync:plugin:check # 插件镜像同步与校验，PASS npm run verify:plugin-bundle # 插件 bundle 校验，PASS node dist/scripts/generate-catalog-docs.js --check # 目录文档生成检查，PASS git diff --check # 空白/冲突标记检查，PASS

其中check-version-sync.js正是对上一节"版本与锁文件审计"的自动化执行；sync:plugin/sync-plugin-mirror对应的脚本位于 sync-plugin-mirror.ts，保证plugins/oh-my-codex与主包内容同步。

全量测试矩阵

npm test # 5787 pass / 0 fail / 1 intentional skip npm run test:ci:compiled # 编译产物 CI 测试，同样 5787/0/1 npm run test:compat:node # Node 兼容性测试 npm run test:sparkshell # sparkshell（Rust）测试 npm run test:explore # explore 测试 npm run test:recent-bug-regressions:compiled # 近期 bug 回归 npm run test:team:worker-runtime-identity:compiled # 团队 worker 运行时身份 npm run test:plugin-boundaries:compiled # 插件边界 npm run test:ralph-persistence:compiled # ralph 持久化 npm run test:explicit-terminal-contract:compiled # 显式终端契约

全量npm test与编译后 CI 测试均为5787 通过 / 0 失败 / 1 个有意的跳过，且test:question在行内 TTY 加固后单独复跑通过。仓库根目录 package.json 中的test:ci:compiled、test:recent-bug-regressions:compiled等脚本即对应这些门禁，读者可对照查看每个脚本实际启动的测试文件。

运行时冒烟与发布探针

omx doctor # PASS，仅 1 条本地用户配置告警 codex login status # PASS（token 脱敏） omx exec --skip-git-repo-check -C . "Reply with exactly OMX-EXEC-OK" # exec 冒烟，PASS npm run test:reply-listener:live # 按契约 SKIP（未设 OMX_REPLY_LISTENER_LIVE=1） npm pack --dry-run # 生成 oh-my-codex-0.18.9.tgz，3.9 MB / 解包 24.0 MB / 3029 文件 npm run smoke:packed-install # 打包安装冒烟，PASS

npm pack --dry-run的产物尺寸（oh-my-codex-0.18.9.tgz，3.9 MB，解包 24.0 MB，3029 个文件）直接写入就绪文档，作为打包内容与体积的客观证据。

团队演示的失败关闭（Fail-Closed）实践

一个值得单独说明的细节：WORKER_COUNT=5 bash src/scripts/demo-team-e2e.sh现场演示在活动的 Autopilot tmux leader 内被标记为ENV-BLOCKED/CLEANED——提交前运行正确地因leader_workspace_dirty_for_worktrees失败关闭（fail closed），提交后/隔离尝试虽进入 worker 启动但被强制清理且无根目录改动。这是发布流程中"环境不满足就宁可放弃演示证据，也不伪造成功"的典型做法：替代证据是编译后的团队运行时/身份门禁（test:team:worker-runtime-identity:compiled）与全套件中的团队 API 覆盖。

静态审查子代理与 UltraQA 对抗性检查

• 静态发布审查子代理：第一轮因过期的就绪复选框与盲按键轮询被 BLOCKED，修复后最终轮 APPROVE/CLEAR（子代理019e8cb9-cff6-74e1-bc4c-1de10f7ef2b2）；
• UltraQA 发布流程对抗性检查：PASS/CLEAN，报告写入.omx/release-0.18.9/ultraqa-report.md，动态探针在.omx/release-0.18.9/logs/ultraqa-*.log。

这个"子代理先审、UltraQA 再打"的两级模式，把发布质量从人工经验判断提升为可追踪的自动化门禁。

CI 与发布证据：从 dev 推广到 tag 触发工作流

CI 证据链

• 发布准备devCI：GitHub Actions run26875635807，对ffd02c65完成/成功；
• 主分支（main）推广 CI：run26876121950，对ffd02c65完成/成功；
• tag 触发的发布工作流：run26876924380通过了从版本同步到打包全局安装冒烟的全部门禁，但npm publish --provenance两次失败于CA_CREATE_SIGNING_CERTIFICATE_ERROR/ Fulcioread ECONNRESET。

npm 发布失败与回退（Fulcio 中断）

npm publish --provenance依赖 Sigstore Fulcio 服务签发签名证书。本次发布中 Fulcio 连续两次重置签名证书请求，导致带 provenance 的发布失败。仓库的处理是临时回退工作流：run26878002529检出v0.18.9标签后，以npm publish --access public --provenance=false发布完全相同的标签工件，不重新打标签、不改变代码内容。这也是为什么就绪文档把"npm provenance"列为 0.18.9 唯一例外。

发布后证据核验

# GitHub release 状态：draft=false, prerelease=false, 57 个资产（含 native-release-manifest.json） # npm 视角 npm view oh-my-codex version dist-tags --json # 0.18.9 / latest: 0.18.9

发布后的 REST release 证明显示v0.18.9为非草稿、非预发布，含 57 个资产（含native-release-manifest.json）；发布资产清单的生成与校验逻辑可参考 generate-native-release-manifest.ts 与 verify-native-release-assets.ts。npm 侧latestdist-tag 确认为0.18.9。

回退工作流移除与证据更新后，main与dev同步到同一"发布后文档证据 tip"，发货源码标签仍为v0.18.9（d409013946bf61a0747d75cd93206ea5673b0fc9）。最终同步后的分支 CI 在.omx/release-0.18.9/logs/final-ci-runs.tsv记录后关闭 Autopilot goal。

本次发布的修复点源码级解读

就绪文档列出了 15 个 PR，其中与用户直接相关的修复在源码中都能找到对应实现。以下选取 4 个最能体现"可靠性"主题的修复做源码级展开。

1. 更新通道：stable / dev 双通道与 Windows 回退

omx update的通道模型定义在 src/cli/update.ts：

export type UpdateChannel = 'stable' | 'dev'; // L65 export interface UpdateChannelConfig { channel: UpdateChannel; installSource: string; } export function resolveUpdateChannelConfig(channel: UpdateChannel = 'stable'): UpdateChannelConfig { if (channel === 'dev') { return { channel: 'dev', installSource: DEV_INSTALL_SOURCE }; // github:Yeachan-Heo/oh-my-codex#dev } return { channel: 'stable', installSource: STABLE_INSTALL_SOURCE }; // oh-my-codex@latest }

稳定通道安装源为oh-my-codex@latest（npm registry），开发通道为github:Yeachan-Heo/oh-my-codex#dev（GitHub 仓库 dev 分支），并带 300 秒的 dev 更新超时（DEV_UPDATE_TIMEOUT_MS）。更新检查状态写入项目.omx/state/update-check.json，检查间隔为 12 小时（CHECK_INTERVAL_MS），版本比较使用严格的 semver 解析（isNewerVersion）。

更新执行结果状态机覆盖updated / scheduled / up-to-date / declined / failed / skipped / unavailable（UpdateExecutionResult.status），自动更新模式由OMX_AUTO_UPDATE环境变量控制：空值/未设置为prompt，0为disabled，defer为延迟执行（resolveAutoUpdateMode）。PR [#2706] 的 Windowsnpm.cmd回退，则让 Windows 上通过 npm 安装的用户在更新时能正确解析npm.cmd而不是裸npm。

2. 项目级 resume 历史与 boxed OMX_ROOT

PR [#2713] 修复"隔离启动时项目本地 resume 历史丢失"。会话历史的落盘逻辑位于 src/hooks/session.ts：历史文件为session-history.jsonl（HISTORY_FILE），由historyDirectory(context)/historyPath(context)计算路径，追加写入historyEntry（含session_id、native_session_id、active_session_id、preserved_active_session_id等字段），并保证"先归档、再删除属主指针"，避免历史未写入就丢失指针。

PR [#2708] 修复 boxedOMX_ROOT下的SessionStart项目记忆查找。OmX 支持用OMX_ROOT把状态根"装箱"到指定目录（例如OMX_ROOT="$HOME/.omx/instances/second-conversation" omx这种多会话隔离用法），此前SessionStart钩子在该模式下查找项目记忆时会因 cwd 默认值与 boxed 根不一致而失效；修复后记忆查找以 boxedOMX_ROOT为准。session-search.ts 中的--project current | all | <cwd-fragment>过滤则提供用户侧的项目维度会话检索入口。

3. omx question：cmux 环境投递与短窗格可见性

PR [#2709] 解决omx question在 cmux（轻量 tmux 兼容层）下无法把环境变量投递给渲染器的问题，采用"export 前缀"变通 tmux-eshim：不依赖tmux -e直接注入环境，而是在发送的 pane argv 前拼export KEY=VALUE; ...。question/renderer.ts 的策略判定逻辑（resolveQuestionRendererStrategy）优先使用inside-tmux（当TMUX存在），支持OMX_QUESTION_RETURN_PANE/OMX_LEADER_PANE_ID显式桥接提示，tmux 不存在且TMUX缺失时失败关闭（fail closed），Windows 无 tmux 桥接但终端交互时回退inline-tty。对应测试见 question/tests/renderer.test.ts。

PR [#2702] 让深度访谈问题在短 tmux 窗格中保持可见：此前窗格高度不足时渲染器可能把问题滚出可视区，本次通过调整渲染/裁剪逻辑保证问题文本常驻。这与 deep-interview.ts 的问答循环共同构成了omx question的完整交互链路。

4. HUD 对账窗格收敛与 Ultragoal 完成可见性

PR [#2703] 修复"重复 tmux HUD 对账作用域发散"：每次对账只应作用于发出事件的窗格，而不是把同 session 所有窗格都当成 HUD 重建对象。HUD 对账入口在 hud/index.ts 的hudCommand(['--reconcile-tmux'], ...)（实际委托reconcileHudForPromptSubmit）；窗格归属通过OMX_TMUX_HUD_OWNER环境变量标记，即便OMX_SESSION_ID/OMX_ROOT未设置也始终发射该标记（见 hud/tests/hud-tmux-injection.test.ts）。对应实现位于 hud/reconcile.ts，并提供窗格自适应高度调整与历史清理能力（resizeTmuxPaneFn/clearTmuxPaneHistoryFn）。

PR [#2699] 让 Ultragoal HUD 在目标完成前保持活跃，避免目标未完成时 HUD 提前退出。PR [#2691] 让 Autopilot 的 ralplan 写入守卫阶段感知——不同 ralplan 阶段（如证据收集 vs 提交判定）允许的写入不同，守卫不再一刀切。PR [#2697] 让 review 子代理真正尊重配置的 model 与 effort 设置，避免子代理悄悄降级模型。

就绪结论：已发货，唯一例外是 npm provenance

就绪文档的最终判定是：Release 0.18.9 is shipped。

• GitHub release 与 57 个 native 资产完整（draft=false、prerelease=false）；
• npmlatest为0.18.9；
• main与dev已同步到发布后文档证据 tip；
• 唯一例外是 npm provenance：Sigstore Fulcio 两次重置签名证书请求导致带 provenance 的发布失败，随后通过临时 GitHub Actions 回退以--provenance=false发布了同一v0.18.9标签工件；
• 最终分支 tip CI 作为该证据提交的收尾门禁，在.omx/release-0.18.9/logs/final-ci-runs.tsv中记录。

方法论沉淀：从这份就绪文档可复用的发布清单

结合 RELEASE_PROTOCOL.md 与本次文档，0.18.9 的实践可以提炼为一条可复用的发布清单：

1. 冻结并锁定候选：记录冻结提交 SHA，用git rev-parse+git merge-base --is-ancestor复验线性范围；
2. 范围审计：汇总区间内合并 PR 与内部提交，声明 issue 清单（可为空）；
3. 版本同步审计：package.json/package-lock.json/ 根Cargo.toml/Cargo.lock/plugin.json全部对齐，独立 lockfile（如 sparkshell）明确标注为不受 workspace 版本约束；
4. 全量本地门禁：版本同步探针 → build → lint → no-unused → native-agents 校验 → 插件同步/校验 → 目录文档 check → 全套测试矩阵（含编译产物 CI、兼容性、sparkshell、explore、回归、团队、插件边界、持久化、终端契约）→ doctor / exec 冒烟 →npm pack --dry-run→ 打包安装冒烟；
5. 隔离环境复跑：清空OMX_ROOT、OMX_STATE_ROOT、OMX_SESSION_ID等会话变量后再跑可继承变量的门禁，防止环境污染判定；
6. 对抗性复查：静态发布审查子代理（必要时修复后复审）+ UltraQA 对抗性检查；
7. CI 推广与发布：dev CI → main 推广 CI → tag 触发发布工作流；发布失败时不重打标签，用回退工作流发布同一标签工件并如实记录例外；
8. 发布后核验与收尾：REST release 视图（非草稿/非预发布/资产数）+npm viewdist-tags +main/dev同步 + 最终分支 CI 记录后关闭 goal。

这套流程的关键特征在于证据全覆盖与失败关闭：每一个门禁都有对应日志路径（.omx/release-0.18.9/logs/*），环境不满足时宁可 BLOCK/ENV-BLOCKED 也不伪造成功，发布例外（provenance）被如实写入就绪结论——这正是发布工程中"可审计、可追溯、不掩盖异常"的最佳实践。

相关阅读：发布协议、0.18.8 就绪审计（若需对比上一版本的差异范围，可对照 0.18.8 release-notes 与 0.18.9 release-notes）。

【免费下载链接】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