【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本文基于 opencodex 仓库的 260722_dev_sync_stabilize 开发记录 展开完整还原一次「大规模 PR 吸收 → 敌对审查 → 门禁稳定化 → 部署就绪 → 发布列车」的完整工程闭环21 个远端提交如何同步进本地 devsol 敌对审查如何揪出两处 BLOCKERocx init无条件删除迁移备份的缺陷如何被修复为「分类保留回滚快照」以及最终如何以「本地门禁 远端 CI 敌对审查」三层证据判定部署就绪、并把 preview/main 收敛到同一 SHA 完成 v2.7.33 发布。读者可以借此掌握一套可复用的多分支同步、审查驱动修复与发布门禁实践并深入了解 opencodex 的 OpenAI tier 迁移备份保护机制issue #257。背景为何需要一次「dev 同步 稳定化」作战opencodex 的维护者团队Wibias、Ingwannu、Lami在同一时期批量处理了大量社区 PR。由此产生一个典型的工程问题本地 dev 分支与远端 origin/dev 严重脱节。在这次行动开始时本地 devc5e5b6d2相对 origin/dev 落后了21 个提交。由于本地独有的提交此前均已合入远端ahead 为空团队采用了最稳妥的同步策略git pull --ff-only只允许 fast-forward绝不产生合并提交或改写历史最终本地被同步到远端3a5f984d。这一步是整个稳定化工作的前提——只有先拿到与远端完全一致的基线后续的审查、修复和门禁验证才具备可复现性。远端 21 个新提交的构成与风险盘点同步进来的897bdcca..3a5f984d共 21 个提交文档按「功能影响面 × 风险等级」逐一盘点。这是理解本次行动重点的关键清单提交PR内容风险度2aa4430c—auth/provider 问题批量解决anthropic adaptivemax_tokens重设 stop_reason→incomplete传递bridge.ts、oauth alias、expireCodexAuthFlow(null)清空全部 pending 流、CLIaccount alias最高改动最大42 个文件afce7cf6#230combo child 去除content-encoding/content-length中fdacd146—合入后稳定化buildComboChildHeaders重构、ja.ts新增 45 行、测试修正中c3517cee#258config 迁移存在 backup 时以「替换」代替崩溃中a1fdbdc2#244日语本地化guija.ts984 行 docs-site ja 全量中key 同步4d61025e#231GUI Accounts 标签页移除 API-key 行Providers.tsx低与 #259 冲突待查07d7b919#229issue intake CI wrong-branch 重定向 ping低897bdcca#235OpenRouter provider routing新文件 测试中86f887a8#251google-tool-schema required 去重低38f3789a#250Kimi root object 类型归一化openai-chat.ts仅限api.kimi.com中ad51994e#248v1 compact reasoning sanitizeresponses.ts中b99bc416#232Kiro OAuth resolve-before-paste中04dfc7fc#262ocx init保持 openai passthrough#261中3a5f984d#264MAINTAINERS.mdCODEOWNERS文档化无未被吸收的 PR 状态文档同时记录了同步时刻的 PR 态势用于界定工作边界已关闭但未合入#260、#254、#243、#237、#233、#226、#225、#223、#221、#220仍打开#256anthropic adaptivemax_tokens与2aa4430c内容重叠需注意重复吸收、#255、#249、#247、#238。这个盘点揭示了同步工作的本质远端合入并不等于风险消除。尤其2aa4430c横跨 42 个文件、触及认证与 provider 迁移等核心路径属于必须重点审查的对象。远端 CI 基线确认在本地同步完成后需要确认远端 CI 的可信度Cross-platform CIfdacd146处 success但3a5f984d是 docs-only 提交需要确认「沿用此前绿色结果」是否成立Issue quality tests07d7b919successservice-lifecycle.yml仅在 preview 分支最近运行过success需确认它在 dev 分支上的触发条件。这说明「远端 CI 绿」需要按提交逐点核对docs-only 提交不能想当然继承此前结果。验证计划八个攻击角度的敌对审查同步完成后团队制定了两层验证计划其中核心是sol 敌对审查adversarial review——由 Meitner 子代理从 8 个攻击角度对本次吸收的变更进行攻击性复核adaptive max_tokens 回归anthropic 自适应 token 重设是否会破坏既有请求路径expireCodexAuthFlow(null)并发性无 flowId 的全局 pending 流过期在并发场景下是否安全schema 归一化双重应用Kimi root object 归一化与既有 schema 逻辑是否叠加出错combo 头重构忠实性buildComboChildHeaders重构后 header 行为是否与重构前等价ja 键同步984 行日语本地化是否有漏翻或键位漂移config backup 数据丢失迁移备份是否存在被静默销毁的风险这正是后来 BLOCKER 的出处OpenRouter 泄漏新增 OpenRouter routing 是否存在跨 provider 的配置/凭据泄漏本地 merge 覆盖本地快进同步是否会覆盖或丢失任何提交。与此同时bun test --isolate测试发布门禁在后台持续运行并核对tsc/ build 是否绿色。发现缺陷后采取「在 dev 之上按 pathspec 范围提交修复」的策略保持提交粒度可追踪。sol 敌对审查结果两个 BLOCKER 的发现与修复审查在 3 轮中推进最终 HEAD29763560共揪出两个必须修复的阻塞级缺陷轮次结果缺陷修复提交R1FAILinit.ts无条件unlink导致有效 v1 回滚备份被删除数据丢失a41170c9R2FAILDate.now命名冲突导致回滚快照被覆盖29763560改用COPYFILE_EXCL无替换发布R3PASS对897bdcca..29763560全范围无残留部署阻塞项—修复一ocx init不得无条件删除迁移备份这是本次行动最重要的一项修复。背景是此前 #257 引入的行为ocx init写入全新的 v2 config 后旧的.pre-openai-tiers-v2.bak备份会变成孤儿若不清理下一次ocx start会遇到 stale-backup collision 而崩溃——因此原实现选择在saveConfig之后无条件unlinkSync删除该备份见 src/cli/init.ts 的修复后实现。问题在于「删除孤儿」没有经过「孤儿判定」。config 迁移侧的策略src/config/openai-tier-backup.ts本来会把备份分类处理stale可安全删除/替换JSON 解析失败非本工具写入或被截断、或已是 post-migrationtier v2快照rollback绝不可静默销毁解析为有效的 pre-migrationv1配置即用户有意的回滚点。init路径绕过了这个分类策略把用户有意保留的回滚点也一并删掉——属于不可逆的数据丢失。修复后的cleanupOpenAiTierBackupAfterInitsrc/cli/init.ts采用与迁移侧完全相同的分类规则export function cleanupOpenAiTierBackupAfterInit(configPath getConfigPath()): void { const backup ${configPath}.pre-openai-tiers-v2.bak; try { if (!existsSync(backup)) return; // 无备份 → no-op if (classifyOpenAiTierBackup(readFileSync(backup)) stale) { unlinkSync(backup); // stale不可解析 / v2→ 删除 return; } // 有效 v1 回滚快照 → rename 旋转保留绝不删除 const preserved preserveOpenAiTierRollbackSnapshot(configPath); console.warn(⚠️ Kept your pre-migration config rollback snapshot at ${preserved}); } catch { /* cleanup 是 best-effort绝不阻塞 init */ } }关键设计决策策略单一化分类逻辑收敛到classifyOpenAiTierBackup(bytes): stale | rollback一个导出函数src/config/openai-tier-backup.ts迁移启动路径与 init 清理路径共用杜绝两处策略漂移。保留方式为「旋转」而非「覆盖」有效 v1 备份被复制到.pre-openai-tiers-v1-rollback.timestamp[suffix].bak最多尝试 16 个唯一后缀见OPENAI_TIER_ROLLBACK_PRESERVE_ATTEMPTS复制采用COPYFILE_EXCL无替换发布复制并校验字节一致后才unlink原 v2 名src/config/openai-tier-backup.ts。修复后为什么不会再次碰撞init 之后 config 已是 v2下一次启动的迁移投影src/providers/openai-tier-startup.ts会得到changed: false根本不会进入 backup 路径projectOpenAiTierMigration返回projection.changed为假见openai-tiers.tscollision 崩溃自然消失而把 rollback 备份从 v2 命名下移走是为了防御用户日后重新添加 legacy provider 的边界场景。修复二回滚快照不得被同名覆盖R2 发现单纯用Date.now()构造的保留文件名在同一时钟 tick 内可能撞名导致新快照覆盖旧快照。修复29763560将发布方式改为fs.constants.COPYFILE_EXCL独占复制 字节一致性校验目标已存在则换后缀重试穷尽 16 次仍无唯一名则抛OpenAiTierRollbackPreserveErrorcodeexhausted且源 v2 备份在复制失败时绝不删除。修复的测试证据仓库中的 tests/service/init-backup-cleanup.test.ts 完整覆盖了上述策略可作为回归防线无备份 → no-op目录保持为空stale v2 备份 → 被删除不可解析not-json{{{→ 被删除有效 v1 备份 →不被删除而是出现在pre-openai-tiers-v1-rollback保留文件中且字节一致保留目标被占用 → 既有快照不被覆盖v1 备份被保留到其他唯一路径classifyOpenAiTierBackup与迁移策略共享openaiProviderTierVersion: 2→ stalegarbage→ staleopenaiProviderTierVersion: 1→ rollback空对象{}→ rollback复制失败 → 原 v2 备份保持原样、unlink不得执行16 次命名穷尽 → 抛OpenAiTierRollbackPreserveError源与已占用目标均原样保留。迁移启动侧还同步补充了回归用例tests/adapters/openai/openai-provider-option-startup.test.tspreserveRollback依赖注入验证以及preserveOpenAiTierRollbackSnapshot拒绝 stale 备份且不删除它#1599。WP2 稳定化门禁最终 HEAD 的三层本地验证修复提交a41170c9、29763560落在 dev 上后稳定化门禁WP2以最终 HEAD 为基准重跑全部本地检查devlog/_fin/260722_dev_sync_stabilize/020_stabilize_gates.md测试bun test --isolate ./tests/29763560→3431 pass / 0 fail / 287 files78.06s类型检查bun x tsc --noEmit→ exit 0推送门禁push 时 prepush 钩子typecheck lint:gui test privacy:scan全绿后3a5f984d..29763560成功推送结论无新增缺陷 → 无需新的修复提交NOOP 记录。WP3 部署就绪判定三层层级证据WP3 的目标是给出明确的「可部署/不可部署」判定devlog/_fin/260722_dev_sync_stabilize/030_deploy_readiness.md。分支状态快照2026-07-22devHEAD29763560本地 originahead/behind 均为 0preview相对 dev 仅多 1 个发布提交26fd5ea9v2.7.32-preview.20260722preview..dev 44 提交 / 140 文件 / 9657 −385main完全被 dev 包含dev..main0 提交main..dev 51 提交npmpackage.json为 2.7.31preview 标签为2.7.32-preview.20260722。三层判定证据本地门禁 bun test --isolate 29763560 3431/0tsc 0lint/privacy/locale 绿 远端门禁 Cross-platform CI 29763560 success含 Ubuntu/Windows 全部 job Issue quality tests success 敌对审查 sol 3 轮最终 PASS —— 897bdcca..29763560 无残留 deploy blocker 判定 READYpreview 与 main 的 merge release 可立即执行延期项不阻塞合并MAJOR无 flowId 的login/cancel会触发 provider 全局 OAuth flow 取消并清空全部 pending 流auth-api.ts:808的expireCodexAuthFlow(null)、GUIAddCodexAccountModal409 处理器。本地单用户代理特性下实际冲突频率低但需要所有权 token 设计应另立 issue/工作分片追踪MINORja.tscustom-model / cost-breakdown 存在英文回退992、1019 行附近不崩溃属翻译 PR 范畴。WP4 发布列车preview 与 main 收敛到同一 SHA发布执行devlog/_fin/260722_dev_sync_stabilize/040_release_train.md严格遵循 scripts/release.ts 的发布规范preflight → bump commit → push → 等 ci.yml service-lifecycle.yml 绿 → dispatch release.yml → watch。版本决策preview 的package.json已是2.7.32-preview.20260722npm version不允许无变化重复 bump且该版本从未实际发布此前 release.yml run 为 dry-runnpm 上并无此版本。因此preview →2.7.33-preview.20260722main →2.7.332.7.32 stable 全局从未部署直接跳过执行序列与结果切 preview 分支并合并 devbase 之后 dev 未改版本package.json预期无冲突preview 上bun scripts/release.ts 2.7.33-preview.20260722 --publishdev29763560合入为9a140a20→ bump6c112450→ ci.yml service-lifecycle.yml success → Release run29904313855success → npm preview 2.7.33-preview.20260722main 以 preview tip 快进6c112450后bun scripts/release.ts 2.7.33 --publishbump6d6bef8b→ 双门禁绿 → npm latest 2.7.33tagv2.7.33dev 以 main tip6d6bef8b快进并推送preview 同步推到6d6bef8b远端 dev / preview / main 三分支收敛到同一 SHA本地 HEAD dev、工作树干净npm view bitkyc08/opencodex dist-tags --json终态latest2.7.33、preview2.7.33-preview.20260722dev push 后按规范独立确认 dev 分支上的 CI run同一 SHA 虽已在 main 验证过绿色仍按约定各自核验。沉淀本次行动的可复用工程方法从这次「同步 稳定化 发布」的完整闭环中可以提炼出一套可迁移的实践快进式远端同步多分支脱节时优先git pull --ff-only避免无谓的 merge commit 污染历史前提是确认本地无 ahead 提交按风险分层盘点提交先按改动面与触及模块auth/provider/config标注风险等级审查资源优先投入高风险提交敌对审查而非善意走查用明确的攻击角度清单回归、并发、双重应用、重构忠实性、本地化键同步、数据丢失、泄漏、覆盖驱动 reviewBLOCKER 级缺陷静默删用户回滚点、快照同名覆盖正是在这种视角下才暴露策略单一来源备份分类逻辑收敛为共享导出函数 同一套保留函数init 与迁移启动两条路径永不漂移并配以「不覆盖已占用目标」「复制校验后再删源」的防御式文件操作三层门禁合取本地isolate 测试 tsc lint/privacy/locale× 远端Cross-platform CI issue tests× 独立敌对审查三者全绿才给 READY 判定deferred 项显式记录并指定后续归属发布列车收敛preview/main/dev 依次快进到同一 release SHArelease.ts 规范里 preflight、bump、双工作流等待、dist-tags 验证缺一不可未部署的中间版本直接跳过避免版本号空洞。对 opencodex 的维护者与关注者而言本次记录完整展示了一次看似普通的「拉取远端 跑测试」背后是怎样的风险盘点、缺陷修复与发布门禁纪律而ocx init的备份保留修复也为所有涉及「迁移 备份」的配置系统提供了一个值得参照的防御模式——用户有意的回滚点永远不能被静默销毁。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐opencodex 发布可部署性加固从 dev 分支脏工作区到 npm 2.6.14 的发布门禁实战opencodex 发布可部署性加固从 dev 分支脏工作区到 npm 2.6.14 的发布门禁实战 本文基于 opencodex 仓库 devlog 中的发opencodex 2.7.20 发布实战dev/main/preview 三分支集成、跨平台 CI 门禁与 OIDC npm 发布全流程opencodex 2.7.20 发布实战dev/main/preview 三分支集成、跨平台 CI 门禁与 OIDC npm 发布全流程 opencodexopencodex PR 集成与 Triage 工程实践基于 spec-satisfaction 循环的合并门禁、对抗性评审与三线分支同步opencodex PR 集成与 Triage 工程实践基于 spec satisfaction 循环的合并门禁、对抗性评审与三线分支同步 本文基于 devl上一篇终极指南如何快速计算C语言中阶乘的尾零数量下一篇eBPF系统调用详解基于Learning eBPF第四章BCC框架实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 opencodex 远程同步与稳定性加固：dev 分支批量 PR 吸收、`ocx init` 回滚备份保护与三层发布门禁实录
【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本文基于 opencodex 仓库的 260722_dev_sync_stabilize 开发记录 展开完整还原一次「大规模 PR 吸收 → 敌对审查 → 门禁稳定化 → 部署就绪 → 发布列车」的完整工程闭环21 个远端提交如何同步进本地 devsol 敌对审查如何揪出两处 BLOCKERocx init无条件删除迁移备份的缺陷如何被修复为「分类保留回滚快照」以及最终如何以「本地门禁 远端 CI 敌对审查」三层证据判定部署就绪、并把 preview/main 收敛到同一 SHA 完成 v2.7.33 发布。读者可以借此掌握一套可复用的多分支同步、审查驱动修复与发布门禁实践并深入了解 opencodex 的 OpenAI tier 迁移备份保护机制issue #257。背景为何需要一次「dev 同步 稳定化」作战opencodex 的维护者团队Wibias、Ingwannu、Lami在同一时期批量处理了大量社区 PR。由此产生一个典型的工程问题本地 dev 分支与远端 origin/dev 严重脱节。在这次行动开始时本地 devc5e5b6d2相对 origin/dev 落后了21 个提交。由于本地独有的提交此前均已合入远端ahead 为空团队采用了最稳妥的同步策略git pull --ff-only只允许 fast-forward绝不产生合并提交或改写历史最终本地被同步到远端3a5f984d。这一步是整个稳定化工作的前提——只有先拿到与远端完全一致的基线后续的审查、修复和门禁验证才具备可复现性。远端 21 个新提交的构成与风险盘点同步进来的897bdcca..3a5f984d共 21 个提交文档按「功能影响面 × 风险等级」逐一盘点。这是理解本次行动重点的关键清单提交PR内容风险度2aa4430c—auth/provider 问题批量解决anthropic adaptivemax_tokens重设 stop_reason→incomplete传递bridge.ts、oauth alias、expireCodexAuthFlow(null)清空全部 pending 流、CLIaccount alias最高改动最大42 个文件afce7cf6#230combo child 去除content-encoding/content-length中fdacd146—合入后稳定化buildComboChildHeaders重构、ja.ts新增 45 行、测试修正中c3517cee#258config 迁移存在 backup 时以「替换」代替崩溃中a1fdbdc2#244日语本地化guija.ts984 行 docs-site ja 全量中key 同步4d61025e#231GUI Accounts 标签页移除 API-key 行Providers.tsx低与 #259 冲突待查07d7b919#229issue intake CI wrong-branch 重定向 ping低897bdcca#235OpenRouter provider routing新文件 测试中86f887a8#251google-tool-schema required 去重低38f3789a#250Kimi root object 类型归一化openai-chat.ts仅限api.kimi.com中ad51994e#248v1 compact reasoning sanitizeresponses.ts中b99bc416#232Kiro OAuth resolve-before-paste中04dfc7fc#262ocx init保持 openai passthrough#261中3a5f984d#264MAINTAINERS.mdCODEOWNERS文档化无未被吸收的 PR 状态文档同时记录了同步时刻的 PR 态势用于界定工作边界已关闭但未合入#260、#254、#243、#237、#233、#226、#225、#223、#221、#220仍打开#256anthropic adaptivemax_tokens与2aa4430c内容重叠需注意重复吸收、#255、#249、#247、#238。这个盘点揭示了同步工作的本质远端合入并不等于风险消除。尤其2aa4430c横跨 42 个文件、触及认证与 provider 迁移等核心路径属于必须重点审查的对象。远端 CI 基线确认在本地同步完成后需要确认远端 CI 的可信度Cross-platform CIfdacd146处 success但3a5f984d是 docs-only 提交需要确认「沿用此前绿色结果」是否成立Issue quality tests07d7b919successservice-lifecycle.yml仅在 preview 分支最近运行过success需确认它在 dev 分支上的触发条件。这说明「远端 CI 绿」需要按提交逐点核对docs-only 提交不能想当然继承此前结果。验证计划八个攻击角度的敌对审查同步完成后团队制定了两层验证计划其中核心是sol 敌对审查adversarial review——由 Meitner 子代理从 8 个攻击角度对本次吸收的变更进行攻击性复核adaptive max_tokens 回归anthropic 自适应 token 重设是否会破坏既有请求路径expireCodexAuthFlow(null)并发性无 flowId 的全局 pending 流过期在并发场景下是否安全schema 归一化双重应用Kimi root object 归一化与既有 schema 逻辑是否叠加出错combo 头重构忠实性buildComboChildHeaders重构后 header 行为是否与重构前等价ja 键同步984 行日语本地化是否有漏翻或键位漂移config backup 数据丢失迁移备份是否存在被静默销毁的风险这正是后来 BLOCKER 的出处OpenRouter 泄漏新增 OpenRouter routing 是否存在跨 provider 的配置/凭据泄漏本地 merge 覆盖本地快进同步是否会覆盖或丢失任何提交。与此同时bun test --isolate测试发布门禁在后台持续运行并核对tsc/ build 是否绿色。发现缺陷后采取「在 dev 之上按 pathspec 范围提交修复」的策略保持提交粒度可追踪。sol 敌对审查结果两个 BLOCKER 的发现与修复审查在 3 轮中推进最终 HEAD29763560共揪出两个必须修复的阻塞级缺陷轮次结果缺陷修复提交R1FAILinit.ts无条件unlink导致有效 v1 回滚备份被删除数据丢失a41170c9R2FAILDate.now命名冲突导致回滚快照被覆盖29763560改用COPYFILE_EXCL无替换发布R3PASS对897bdcca..29763560全范围无残留部署阻塞项—修复一ocx init不得无条件删除迁移备份这是本次行动最重要的一项修复。背景是此前 #257 引入的行为ocx init写入全新的 v2 config 后旧的.pre-openai-tiers-v2.bak备份会变成孤儿若不清理下一次ocx start会遇到 stale-backup collision 而崩溃——因此原实现选择在saveConfig之后无条件unlinkSync删除该备份见 src/cli/init.ts 的修复后实现。问题在于「删除孤儿」没有经过「孤儿判定」。config 迁移侧的策略src/config/openai-tier-backup.ts本来会把备份分类处理stale可安全删除/替换JSON 解析失败非本工具写入或被截断、或已是 post-migrationtier v2快照rollback绝不可静默销毁解析为有效的 pre-migrationv1配置即用户有意的回滚点。init路径绕过了这个分类策略把用户有意保留的回滚点也一并删掉——属于不可逆的数据丢失。修复后的cleanupOpenAiTierBackupAfterInitsrc/cli/init.ts采用与迁移侧完全相同的分类规则export function cleanupOpenAiTierBackupAfterInit(configPath getConfigPath()): void { const backup ${configPath}.pre-openai-tiers-v2.bak; try { if (!existsSync(backup)) return; // 无备份 → no-op if (classifyOpenAiTierBackup(readFileSync(backup)) stale) { unlinkSync(backup); // stale不可解析 / v2→ 删除 return; } // 有效 v1 回滚快照 → rename 旋转保留绝不删除 const preserved preserveOpenAiTierRollbackSnapshot(configPath); console.warn(⚠️ Kept your pre-migration config rollback snapshot at ${preserved}); } catch { /* cleanup 是 best-effort绝不阻塞 init */ } }关键设计决策策略单一化分类逻辑收敛到classifyOpenAiTierBackup(bytes): stale | rollback一个导出函数src/config/openai-tier-backup.ts迁移启动路径与 init 清理路径共用杜绝两处策略漂移。保留方式为「旋转」而非「覆盖」有效 v1 备份被复制到.pre-openai-tiers-v1-rollback.timestamp[suffix].bak最多尝试 16 个唯一后缀见OPENAI_TIER_ROLLBACK_PRESERVE_ATTEMPTS复制采用COPYFILE_EXCL无替换发布复制并校验字节一致后才unlink原 v2 名src/config/openai-tier-backup.ts。修复后为什么不会再次碰撞init 之后 config 已是 v2下一次启动的迁移投影src/providers/openai-tier-startup.ts会得到changed: false根本不会进入 backup 路径projectOpenAiTierMigration返回projection.changed为假见openai-tiers.tscollision 崩溃自然消失而把 rollback 备份从 v2 命名下移走是为了防御用户日后重新添加 legacy provider 的边界场景。修复二回滚快照不得被同名覆盖R2 发现单纯用Date.now()构造的保留文件名在同一时钟 tick 内可能撞名导致新快照覆盖旧快照。修复29763560将发布方式改为fs.constants.COPYFILE_EXCL独占复制 字节一致性校验目标已存在则换后缀重试穷尽 16 次仍无唯一名则抛OpenAiTierRollbackPreserveErrorcodeexhausted且源 v2 备份在复制失败时绝不删除。修复的测试证据仓库中的 tests/service/init-backup-cleanup.test.ts 完整覆盖了上述策略可作为回归防线无备份 → no-op目录保持为空stale v2 备份 → 被删除不可解析not-json{{{→ 被删除有效 v1 备份 →不被删除而是出现在pre-openai-tiers-v1-rollback保留文件中且字节一致保留目标被占用 → 既有快照不被覆盖v1 备份被保留到其他唯一路径classifyOpenAiTierBackup与迁移策略共享openaiProviderTierVersion: 2→ stalegarbage→ staleopenaiProviderTierVersion: 1→ rollback空对象{}→ rollback复制失败 → 原 v2 备份保持原样、unlink不得执行16 次命名穷尽 → 抛OpenAiTierRollbackPreserveError源与已占用目标均原样保留。迁移启动侧还同步补充了回归用例tests/adapters/openai/openai-provider-option-startup.test.tspreserveRollback依赖注入验证以及preserveOpenAiTierRollbackSnapshot拒绝 stale 备份且不删除它#1599。WP2 稳定化门禁最终 HEAD 的三层本地验证修复提交a41170c9、29763560落在 dev 上后稳定化门禁WP2以最终 HEAD 为基准重跑全部本地检查devlog/_fin/260722_dev_sync_stabilize/020_stabilize_gates.md测试bun test --isolate ./tests/29763560→3431 pass / 0 fail / 287 files78.06s类型检查bun x tsc --noEmit→ exit 0推送门禁push 时 prepush 钩子typecheck lint:gui test privacy:scan全绿后3a5f984d..29763560成功推送结论无新增缺陷 → 无需新的修复提交NOOP 记录。WP3 部署就绪判定三层层级证据WP3 的目标是给出明确的「可部署/不可部署」判定devlog/_fin/260722_dev_sync_stabilize/030_deploy_readiness.md。分支状态快照2026-07-22devHEAD29763560本地 originahead/behind 均为 0preview相对 dev 仅多 1 个发布提交26fd5ea9v2.7.32-preview.20260722preview..dev 44 提交 / 140 文件 / 9657 −385main完全被 dev 包含dev..main0 提交main..dev 51 提交npmpackage.json为 2.7.31preview 标签为2.7.32-preview.20260722。三层判定证据本地门禁 bun test --isolate 29763560 3431/0tsc 0lint/privacy/locale 绿 远端门禁 Cross-platform CI 29763560 success含 Ubuntu/Windows 全部 job Issue quality tests success 敌对审查 sol 3 轮最终 PASS —— 897bdcca..29763560 无残留 deploy blocker 判定 READYpreview 与 main 的 merge release 可立即执行延期项不阻塞合并MAJOR无 flowId 的login/cancel会触发 provider 全局 OAuth flow 取消并清空全部 pending 流auth-api.ts:808的expireCodexAuthFlow(null)、GUIAddCodexAccountModal409 处理器。本地单用户代理特性下实际冲突频率低但需要所有权 token 设计应另立 issue/工作分片追踪MINORja.tscustom-model / cost-breakdown 存在英文回退992、1019 行附近不崩溃属翻译 PR 范畴。WP4 发布列车preview 与 main 收敛到同一 SHA发布执行devlog/_fin/260722_dev_sync_stabilize/040_release_train.md严格遵循 scripts/release.ts 的发布规范preflight → bump commit → push → 等 ci.yml service-lifecycle.yml 绿 → dispatch release.yml → watch。版本决策preview 的package.json已是2.7.32-preview.20260722npm version不允许无变化重复 bump且该版本从未实际发布此前 release.yml run 为 dry-runnpm 上并无此版本。因此preview →2.7.33-preview.20260722main →2.7.332.7.32 stable 全局从未部署直接跳过执行序列与结果切 preview 分支并合并 devbase 之后 dev 未改版本package.json预期无冲突preview 上bun scripts/release.ts 2.7.33-preview.20260722 --publishdev29763560合入为9a140a20→ bump6c112450→ ci.yml service-lifecycle.yml success → Release run29904313855success → npm preview 2.7.33-preview.20260722main 以 preview tip 快进6c112450后bun scripts/release.ts 2.7.33 --publishbump6d6bef8b→ 双门禁绿 → npm latest 2.7.33tagv2.7.33dev 以 main tip6d6bef8b快进并推送preview 同步推到6d6bef8b远端 dev / preview / main 三分支收敛到同一 SHA本地 HEAD dev、工作树干净npm view bitkyc08/opencodex dist-tags --json终态latest2.7.33、preview2.7.33-preview.20260722dev push 后按规范独立确认 dev 分支上的 CI run同一 SHA 虽已在 main 验证过绿色仍按约定各自核验。沉淀本次行动的可复用工程方法从这次「同步 稳定化 发布」的完整闭环中可以提炼出一套可迁移的实践快进式远端同步多分支脱节时优先git pull --ff-only避免无谓的 merge commit 污染历史前提是确认本地无 ahead 提交按风险分层盘点提交先按改动面与触及模块auth/provider/config标注风险等级审查资源优先投入高风险提交敌对审查而非善意走查用明确的攻击角度清单回归、并发、双重应用、重构忠实性、本地化键同步、数据丢失、泄漏、覆盖驱动 reviewBLOCKER 级缺陷静默删用户回滚点、快照同名覆盖正是在这种视角下才暴露策略单一来源备份分类逻辑收敛为共享导出函数 同一套保留函数init 与迁移启动两条路径永不漂移并配以「不覆盖已占用目标」「复制校验后再删源」的防御式文件操作三层门禁合取本地isolate 测试 tsc lint/privacy/locale× 远端Cross-platform CI issue tests× 独立敌对审查三者全绿才给 READY 判定deferred 项显式记录并指定后续归属发布列车收敛preview/main/dev 依次快进到同一 release SHArelease.ts 规范里 preflight、bump、双工作流等待、dist-tags 验证缺一不可未部署的中间版本直接跳过避免版本号空洞。对 opencodex 的维护者与关注者而言本次记录完整展示了一次看似普通的「拉取远端 跑测试」背后是怎样的风险盘点、缺陷修复与发布门禁纪律而ocx init的备份保留修复也为所有涉及「迁移 备份」的配置系统提供了一个值得参照的防御模式——用户有意的回滚点永远不能被静默销毁。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐opencodex 发布可部署性加固从 dev 分支脏工作区到 npm 2.6.14 的发布门禁实战opencodex 发布可部署性加固从 dev 分支脏工作区到 npm 2.6.14 的发布门禁实战 本文基于 opencodex 仓库 devlog 中的发opencodex 2.7.20 发布实战dev/main/preview 三分支集成、跨平台 CI 门禁与 OIDC npm 发布全流程opencodex 2.7.20 发布实战dev/main/preview 三分支集成、跨平台 CI 门禁与 OIDC npm 发布全流程 opencodexopencodex PR 集成与 Triage 工程实践基于 spec-satisfaction 循环的合并门禁、对抗性评审与三线分支同步opencodex PR 集成与 Triage 工程实践基于 spec satisfaction 循环的合并门禁、对抗性评审与三线分支同步 本文基于 devl上一篇终极指南如何快速计算C语言中阶乘的尾零数量下一篇eBPF系统调用详解基于Learning eBPF第四章BCC框架实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考