oh-my-codex 0.20.2 发布就绪记录冻结提交盘点、发布门禁与不可变版本验证全解析【免费下载链接】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 仓库中的 发布就绪记录完整还原 0.20.2 补丁版本从冻结候选、提交盘点、本地质量门禁、评审、CI、打标签、npm 发布到公共注册表安装验证的全链路发布治理流程。读完本文你将掌握该项目的发布就绪记录Release Readiness Record如何组织证据、如何用一条 git 命令复现 22 个冻结提交的精确清单、8 项发布门禁分别验证什么以及不可变 tag 事后前向纠错的版本治理原则。文中所有门禁命令均可在仓库package.json与 CI 脚本中逐一找到对应实现可作为任何想为自身项目建立可审计发布流程的工程师的参考样板。一、发布就绪记录从预打标签声明到发布后对账docs/qa/release-readiness-0.20.2.md这份记录的生命周期在文档开篇即被明确它始于冻结候选0.20.2的预打标签pre-tag声明随后不断追加证据最终在 2026-07-16 收录了本地构建、独立评审、CI、npm 公开发布、公共注册表安装以及发布后证据对账post-publish reconciliation的完整闭环证据。这种先声明、后对账的模式与仓库中其他发布记录一脉相承见 docs/qa 下从 0.8.1 到 0.21.2 的系列release-readiness-*.md其核心目的有二冻结版本边界在打 tag 前把哪些提交算作本次发布钉死防止后续开发提交混入发布范围证据可审计每一项门禁都有可验证的证据落点而不是一句已通过的空话。值得注意的仓库约定可从 CHANGELOG.md 中 0.20.2 条目的 Verification 一节印证changelog 本身不宣称任何本地门禁、评审、CI、tag、GitHub release 或 npm 发布结果这些断言全部集中在发布就绪记录中——即证据单一来源原则。这也解释了为什么本文讨论的记录文档是所有门禁状态的唯一权威出口。二、版本身份与冻结范围22 个提交、20 个合并 PR记录首先定义版本身份Release identity发布类型0.20.2patch 补丁版本发布日期2026-07-16前一个 tagv0.20.1冻结开发基frozen dev basef5e4753135ebc86342e7353300ac3ec5d9ae3d8d精确比较范围v0.20.1..f5e4753135ebc86342e7353300ac3ec5d9ae3d8d预期范围清单22 个提交——20 个合并 PR、1 个发布开发准备提交、以及 #3129 发布配套release collateral的直接分支提交与合并提交兼容性声明无有意的 CLI 破坏性变更或 package 布局变更2.1 用一条命令复现冻结清单记录给出了可复现范围清单的权威命令git log --reverse --format%H%x09%s v0.20.1..f5e4753135ebc86342e7353300ac3ec5d9ae3d8d这条命令以--reverse按时间正序输出范围内每个提交的完整 SHA 与主题行%x09输出 Tab 分隔符。记录明确要求清单任何不一致都会阻断发布准备Any mismatch blocks release preparation——这是发布治理的第一道硬门禁。2.2 冻结提交清单逐条解读记录给出了 22 个提交的完整清单表。按发布处置Release disposition列可以清晰分成四类发布配套inventory only不构成产品头条提交分类说明c628486896ffa8b9188335b91a76192571e32c9d#3129 直接分支提交0.20.1 证据对账fce27bfd6c17c7665a6f1505b6b8384cc2c8edd5#3129 合并提交提升 0.20.1 证据对账结果发布准备不构成产品头条提交分类说明29bdeb5c5670c133d9f2feda7512ee01e80a63d5直接提交启动 0.20.2 开发与版本元数据同步依赖升级dependency提交依赖变化90601c96fca7a69bd65c25e0b66316e188672eb0TypeScript 6.0.3 → 7.0.2#3155c5f03c3498186bee4d6a97099a43435889ede428actions/setup-node6 → 7#3154d6e0349f5aed7ce4702c6c1dbb22190f16862fdfbiomejs/biome2.5.2 → 2.5.3#31579f4f8f09bd2f098c4cbe56ae4798dfbfb7085666types/node26.1.0 → 26.1.1#3156产品功能与修复product headline其余 16 个提交对应 #3136、#3158、#3164、#3165、#3152、#3168、#3169、#3172、#3151、#3166、#3179、#3140、#3180、#3183、#3184详见下一节。关联问题 #3118、#3133、#3162、#3163、#3175、#3177、#3181 属于问题单而非额外 PR不应重复计数。全部合并 PR 集合为#3129、#3136、#3140、#3151、#3152、#3154、#3155、#3156、#3157、#3158、#3164、#3165、#3166、#3168、#3169、#3172、#3179、#3180、#3183、#3184。三、0.20.2 的产品变更全貌结合源码佐证发布说明 docs/release-notes-0.20.2.md 与 CHANGELOG.md 中的[0.20.2]条目共同构成了对冻结提交的语义化解释。按主题归类如下。3.1 认证 Ralplan 引导#3184issue #3181变更内容全新认证的 App 领导者可以在其第一轮会话内写入 Ralplan 角色意图role intent具备持久化领导者证明durable leader attestation、原子 tracker 加锁的意图发布atomic tracker-locked intent publication、单飞行为single-flight、重启恢复以及在歧义情况下对 subagent/来源证明检查的 fail-closed 处理。源码佐证仓库中src/ralplan/documented-leader-preflight.ts完整实现了这一能力的 fail-closed 拒绝路径——当无法验证文档化、非用户可伪造的根身份时返回常量UNSUPPORTED_DOCUMENTED_LEADER_PROOF unsupported_documented_leader_proof并在 PreToolUse 阶段以permissionDecision: deny拒绝适配的 Ralplan 命令documented-leader-preflight.ts。相关的端到端测试位于 role-intent-bootstrap-e2e-3181.test.ts 与 ralplan-bootstrap-3181.test.ts。重要状态提示ADR 3212适用于上述权威性声明按发布记录与 CHANGELOG 中一致保留的 supersession 说明本地领导者证明与适配角色意图不再授权类型化路由/tracker 证据仅作为生命周期/诊断用途。在role_routing_unavailable的适配 Ralplan 权威尝试中已安装的角色意图/预检会以unsupported_documented_leader_proof失败关闭缺少官方宿主收据时共识以documented_host_consensus_receipt_unavailable不可用。相关 ADR 背景见 docs/adr/3194-codex-01445-documented-leader-proof.md 与 docs/adr/3212-same-user-native-child-auth-boundary.md。3.2 原生 subagent 与 hooks#3152、#3166、#3180issue #3118Appspawn_agent路由遵循表面感知的角色契约surface-aware role contract适配角色 tracker 证据与路由标记事务性绑定崩溃后可恢复并清理被遗弃的跨进程锁工件#3166被识别的原生子代理可以停止而不产生自动 nudge#3180。这与文档 docs/contracts/ralph-cancel-contract.md 系列契约所强调的显式终止语义方向一致停止动作应由用户明确发起而非系统自动推送。3.3 来源证明、通知与状态隔离#3168、#3165、#3158、#3172并发聊天隔离#3168prompt 会话来源证明provenance在并发聊天之间相互隔离避免会话身份串扰跨进程通知去重#3165issue #3162fallback 通知投递跨进程去重规范 Ralplan 会话状态#3158Ralplan 终态状态保持挂在规范会话上拒绝歧义会话别名陈旧过渡镜像拒绝#3172外部陈旧的 workflow-transition 镜像不能改写当前工作流状态——对应 src/state/workflow-transition.ts 中状态机写入路径的边界防护。3.4 Setup、Team 与状态安全#3164、#3136持久化显式AGENTS.md合并策略#3164issue #3163setup 在多次刷新之间持久化根级本地AGENTS.md合并策略同时保留缺失即语义absence semantics与瞬态--force行为显式 Team worker 策略#3136tmux 启动前校验并遵守显式 worker 策略。仓库中 src/team/tmux-session.ts 的TeamTopology结构体保留了workerCount、workerPaneIds、leaderPaneId、teamPaneOwnerId等字段从中可以看出 worker 槽位、leader 面板归属与清理权限的强约束设计。3.5 其他修复#3140、#3179、#3151、#3169、#3183显式工作流调用要求#3140issue #3133工作流激活必须由提示词开头的显式调用触发杜绝来自引用、否定、文档化、畸形、fenced 或其它非调用文本的误激活认证 deep-interview 终态写入#3179issue #3177认证会话的终态写入被接受外来 Codex hook 坐标保留#3151setup/refresh/doctor/uninstall 全程保留外来 Codex hook 坐标不认领、不删除BOM 前缀状态输入#3169接受 BOM 前缀的状态输入文件增强跨平台兼容性tmux 属主 detached 面板环境保留#3183issue #3175detached 面板保留 tmux 属主的终端环境变量值。四、发布门禁体系八道关卡逐项拆解发布记录用一张门禁表Required gates汇总了从代码冻结到公共注册表可安装的全部关卡。下表为原记录完整继承门禁证据状态配套/范围评审冻结的 22-commit 范围、全部 20 个合并 PR、分类、亮点、贡献者与 compare 链接在CHANGELOG.md、docs/release-notes-0.20.2.md、RELEASE_BODY.md与本记录间一致本地通过发布范围评审候选变更为四个发布配套文件加上既有测试中六处 Darwin 可移植性修正doctor 警告路径、resumestat可移植性/UTC、setup hook 信任路径与已安装 Codex 边界跳过、规范化适配角色/tracker cwd 期望。版本元数据保持0.20.2同步不含任何依赖、lockfile、工作流或产品运行时源码变更本地通过本地质量门禁见 4.1 节命令清单本地通过评审Ultragoal 清理零阻断发现Architect 评审对架构/产品/代码返回CLEAR与APPROVEexecutor QA/red-team 针对候选提交2e666461d4147fa4718691f7b4d9a1a282380f16treeef2acf5f20327d23742e8b08827b46802c39751c通过通过CIdevCI 与mainCI 对精确发货提交2e666461d4147fa4718691f7b4d9a1a282380f16均成功通过Tag 与发布注解 tag 对象4332cc6418430e8cdfc0769bf52e7ecbdfe08afdpeel 到发货提交2e666461d4147fa4718691f7b4d9a1a282380f16发布工作流完成全部七个原生构建、资产发布/验证、packed-install smoke 与 npm 发布通过npm 发布npm view oh-my-codex0.20.2返回版本0.20.2、tarball 地址与完整性校验sha512-f48bqkK3UX4D2VfKimiqVpbYVrqim7jJM6KDI/gzpKzLtnwNTyc06whrkWBqlah0Tg87rX5rG8mkPcGzoZGQ通过公共注册表安装从 npm 安装oh-my-codex0.20.2到隔离前缀/private/tmp/omx-public-install-0.20.2omx --version在 Darwin arm64 报告oh-my-codex v0.20.2omx --help输出非空npm ls -g --prefix ... --json解析出精确版本0.20.2npm 本地 allow-scripts 策略跳过了非关键 postinstall 生命周期但 CLI 仍成功启动通过4.1 本地质量门禁从 package.json 到 Cargo workspace记录列出的本地质量门禁命令逐一对应仓库package.json的 scripts 与 Cargo.toml workspace命令作用对应 package.json scriptnpm run buildtsc编译 TypeScript 到dist/并设置omx可执行位npm run build:full全量构建TS explore-harness sparkshell APInpm run sync:plugin:check校验插件镜像同步sync-plugin-mirror.js --checknpm run check:no-unused基于tsconfig.no-unused.json的未使用代码检查npm run lintbiome lint srcnpm test383 个编译测试文件全量执行cargo fmt --all --checkRust workspace 格式检查cargo clippy --workspace --all-targets -- -D warningsRust 静态检查warning 即失败cargo test --workspaceRust 全 workspace 单元/集成测试npm run smoke:packed-install打包安装冒烟smoke-packed-install.js其中packed-install smoke有一个容易被忽略的细节因为工作站默认的 Codex 可执行文件是 0.142.3冒烟测试使用了隔离的openai/codex0.142.5可执行文件来保证边界版本一致。这一版本钉死的实践在源码中得到印证src/scripts/smoke-packed-install.ts中定义了PINNED_CODEX_VERSION 0.142.5与PINNED_CODEX_VERSION_OUTPUT codex-cli 0.142.5确保冒烟测试面对的是精确已知的 Codex 行为边界smoke-packed-install.ts。4.2 评审与 CI双层独立验证独立评审链Ultragoal 清理 → Architect 评审CLEAR/APPROVE→ executor QA/red-team全部绑定到精确候选提交/树CI 双线验证dev与main两条分支线都对精确发货提交2e666461d4147fa4718691f7b4d9a1a282380f16成功排除发布与分支线漂移的风险。4.3 Tag 与 npm 发布不可变锚点 完整性校验注解 tag 对象4332cc6418430e8cdfc0769bf52e7ecbdfe08afdpeel 到与 CI 验证完全一致的提交形成代码 → tag → 发布资产的单链锚定npm 侧通过npm view校验版本、tarball 与 integritysha512 校验和再以隔离前缀/private/tmp/omx-public-install-0.20.2模拟全新用户安装验证omx --version、omx --help与精确依赖解析。即便 npm 的 allow-scripts 策略跳过了非关键 postinstall 生命周期CLI 也能正常启动——这验证了包对 postinstall 副作用零依赖。五、外部证据要求不可变发布与事后纠错的分工记录明确划分了两类证据的存放策略稳定公共证据CI 运行、不可变 tag、GitHub release、发布工作流、npm 包元数据与注册表 tarball均在记录中以链接给出本文不展开外部链接可对照原记录查阅本地可验证证据本地验证、清理与独立评审绑定到 Ultragoal 账本ledger中的精确候选提交/树发布后纠错原则发布后的修正使用正常前向提交forward commits绝不改写不可变 tag。这也解释了上一节中当前main分支线 候选提交 前向发布证据修正的表述当前main血统是该候选提交后仅跟随前向发布证据修正当前dev血统是该候选提交后跟随0.20.3开发基提升与对应前向证据修正。分支尖端的 CI 状态在 Ultragoal 完成前由外部核实而不是在本文件中嵌入自指提交哈希——避免记录文件自身产生自我引用循环。六、发布说明、Changelog 与贡献者0.20.2 的三份对外/对内文本分工明确文件定位docs/release-notes-0.20.2.md面向产品的发布说明亮点、修复清单、依赖与范围清单、兼容性、验证状态、贡献者RELEASE_BODY.mdGitHub 发布正文模板CHANGELOG.md变更日志条目只陈述变更事实不断言门禁结果提交证据识别出的贡献者包括 BellmanYeachan-Heo、cristph、terwox 与 dependabot[bot]——其中依赖升级提交由 dependabot 机器人完成与 4 个依赖 bump 提交一一对应。七、结语一份可复用的发布治理样板从 0.20.2 发布就绪记录可以提炼出这套流程的三个关键设计先冻结、后验证以精确 commit 范围v0.20.1..f5e475...冻结发布边界任何清单不一致直接阻断证据单一来源 分层门禁changelog 不断言门禁结果发布就绪记录是唯一权威出口本地质量门禁TS/Rust 双栈 packed-install smoke 钉死的 Codex 边界版本、独立评审、双线 CI、不可变 tag、npm 完整性校验、隔离前缀公共安装六层递进不可变与纠错分离tag 一旦创建即不可变发布后问题一律走前向提交修正保证任何历史发布都可被精确复现与审计。对于希望为自身项目引入可审计、可复现、可回滚发布流程的工程团队docs/qa/release-readiness-0.20.2.md连同其后的 0.20.x–0.21.x 系列记录就是一套可以直接借鉴的完整范本记录的每一条断言最终都能在CHANGELOG.md、docs/release-notes-*.md、package.jsonscripts 与 Rust workspace 构建配置中追溯到具体落点。【免费下载链接】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），仅供参考