【免费下载链接】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点击查看免费下载本文以 opencodexUniversal provider proxy for OpenAI Codex Claude Code一次集中式 PR 审查工作为样本完整还原其「dev 中间分支 四阶段合并 严格验证清单」的社区 PR 治理流程。读者可以从中掌握一套可复用的策略如何按风险等级给 PR 分类、如何识别范围失控的污染分支、如何用源码级 diff 验证社区贡献、以及如何通过ghCLI 与测试命令把合并决策落地为可执行动作。背景一次 11 个开放 PR 的集中审查2026-07-22 前后项目dev分支位于 v2.7.31提交 304a1eab仓库同时积压了 11 个开放 PR——其中 6 个以dev为目标、5 个直接以main为目标。审查工作由两条线并行完成Sol 子代理gpt-5.6-solhigh effort基于gh pr diff对每个 PR 做敌意式adversarialdiff 审查主代理基于rg对当前代码库做交叉验证确认 PR 声称的改动与代码现状是否一致。审查产出了一份包含 11 个 PR 的详细清单devlog/_fin/260722_pr_review_strategy/001_pr_inventory.md并按「规模 风险 初判」三维度打标PR主题规模风险初判#215strip mismatched agent_message item ids3/-0, 2 文件LOWMERGE-READY#219detect sc.exe error 1060 under Bun truncation34/-4, 2 文件LOWMERGE-READY#224forward prompt_cache_key through openai-chat42/-0, 5 文件LOWMERGE-READY#211complete RU parity with dev en.ts161/-13, 6 文件LOWMERGE-READY#225enforce issue quality for feature requests453/-1, 3 文件MEDIUMMERGE-WITH-FIXES#221do not persist needsReauth across restarts4434/-185, 90 文件HIGHNEEDS-REWORK#223clamp reasoning efforts to installed binary186/-5, 3 文件MEDIUMMERGE-WITH-FIXES#220add Gemini 3.6 Flash and 3.5 Flash-Lite33/-3, 5 文件LOWMERGE-READY#213expose private-network opt-in for presets13/-5, 2 文件LOWMERGE-READY#214rename combos custom public model name1028/-76, 24 文件MEDIUMMERGE-WITH-FIXES#226redesign provider setup Codex restart875/-198, 19 文件HIGHNEEDS-REWORK初判只是起点。经过 Sol 的敌意 diff 审查与主代理的源码交叉验证后最终判定发生了大面积修正完整对照表见 devlog/_fin/260722_pr_review_strategy/002_audit_synthesis.md#219、#211由 READY 降为 WITH-FIXES#213由 READY 直接转为 REJECT#220、#225、#214均被降级#221维持 REJECT。这体现了该审查流程的核心价值初判基于 PR 自述终判必须基于 diff 事实与当前代码库的双重证据。合并策略的四大原则策略文档 devlog/_fin/260722_pr_review_strategy/003_merge_strategy.md 开篇即给出不可动摇的四条原则所有 PR 必须经由dev禁止任何对main的直接合并。即便 PR 的 base 是main如 #223、#220、#214、#226也要请求作者改写 base或在本地 cherry-pick 后以dev为基底重新合入。dev→main的晋升只允许通过发布门禁release gatedev是集散地main是发布线两者之间不能手工直推。污染 PR 一律要求拆分把无关改动混进一个 PR 的#221要么作者拆分重提要么直接 REJECT已被dev更安全实现覆盖的 PR#213直接 close。AI 生成的 PR 必须经过 diff 级验证后才能接受Claude Code 等生成的代码质量可能很高如 #215但同样需要逐行核对 diff 与测试证据不可因生成来源就豁免。Phase 1 立即合并小改动、独立、测试充分Phase 1 选取的是「3 行到 42 行、零冲突、有测试兜底」的低风险 PR直接顺序合并gh pr merge 215 --squash --delete-branch gh pr merge 224 --squash --delete-branch#215 — agent_message item id strip3 行修复production 级 bugResponses API 的混合方言dialect-mixed线程历史中带msg_前缀的agent_message项会触发上游 Responses 400 错误导致线程被永久卡死brick。修复方式是在stripInvalidItemIds的validPrefixes映射表中补一行agent_message → amsg_。这一修复在现仓库中有完整落地入口定义位于 src/adapters/openai-responses/request-strips.tsvalidPrefixes现在覆盖message/msg_、agent_message/amsg_、reasoning/rs_、function_call/fc_、custom_tool_call/ctc_、tool_search_call/tsc_、web_search_call/ws_七种类型。stripInvalidItemIds的语义是只有当 item 的id不以对应合法前缀开头时才删除该 id没有id字段的 item 原样保留因此它只清理错误方言的引用不触碰合法线程历史。该函数在 src/adapters/openai-responses/passthrough.ts 的出口序列化管道中被调用与stripItemIdsWhenUnstored、scrubOcxCompactionItems等组成统一的「非规范边界清理」层。对应测试 tests/responses/openai-responses-passthrough.test.ts 明确覆盖了两类行为agent_message携带错误方言msg_wrong-dialect时 id 被删除携带正确前缀amsg_1时 id 被保留。#224 — prompt_cache_key 透传opt-in遵循既有模式Responses 解析器会把promptCacheKey写入options.promptCacheKey但 openai-chat 适配器的buildRequest()此前未将其复制到出站请求体。PR 以 provider 开关promptCacheKey: boolean的方式做 opt-in 透传——默认关闭避免影响 Groq、Cerebras 这类严格后端。当前 src/adapters/openai-chat.ts 的实现即为证据if (provider.promptCacheKey parsed.options.promptCacheKey ! undefined) { body.prompt_cache_key parsed.options.promptCacheKey; }同时在 src/router.ts 采用了与既有parallelToolCalls完全一致的回填模式当用户配置未显式给出promptCacheKey时从 registry 条目取值回填。这正是该 PR「遵循既有模式、opt-in 无行为变更」判定的源码依据。Phase 2 先 rebase 再合并与 dev 已有进展对齐Phase 2 的两个 PR 本身质量不差但 Sol 审查发现dev 上已经先期合入了部分相关修复直接合并会产生冗余或冲突。策略是让作者先 rebase 到最新dev剥离已解决的部分只保留增量并同步 retitle。#211 — RU 本地化补平rebase retitle背景#207RU 本地化合并后dev 的en.ts新增了 13 个 key、修改 5 个 key导致ru.ts无法满足RecordTKey, string类型约束GUI 构建失败。作者的原始 PR 是修复构建但 Sol 验证发现 dev 已达成 956/956 的 key 对齐因此 rebase 后实际只剩下 wording 与文档刷新。合并要求retitle 为fix(i18n): refresh RU wording add ocx account docs验证手段cd gui bun run build。#219 — winsw SCM 探针加固rebase retitleWindows 服务生命周期中sc.exe探针有两个隐蔽陷阱Bun 会把 exit code 截断为 8 位1060ERROR_SERVICE_DOES_NOT_EXIST被截成361060 0xffsc.exe的FAILED前缀是本地化的pt-BR 输出FALHAde-DE 输出FEHLER不能依赖英文关键字。修复方案以 word boundary 匹配数字码/\b1060\b/数字 1060 在任何 locale 下不变把e.message移出扫描范围防止误报并增加 Buffer 解码。当前 src/lib/winsw.ts 的实现完全对应[e.stderr, e.stdout, e.message]拼接后做/\b1060\b/.test(text)且只接受 exit 1060 或其文本形式作为「服务不存在」的唯一证据——status 36 单独出现不被接受会与任何 ≡ 36 (mod 256) 的 status 冲突。测试 tests/service/winsw.test.ts 给出了 7 个针对性用例exit 1060、stderr 通道、stdout 通道、Bun 截断 status 36 本地化输出pt-BRFALHA、韩文지정된 서비스가、word boundary 文本、权限错误exit 5 →error、spawn 失败ENOENT →error完整刻画了「存在 / 确认不存在 / 不确定」三分支的判定语义。Phase 3 修改后合并采纳思路、补齐安全边界Phase 3 的两个 PR 思路正确但 Sol 审查发现实现存在安全缺口需要作者修改后再合入dev。#223 — reasoning effort clampbase 改 dev safe fallback问题根因Codex 0.133.0 的ReasoningEffort枚举只到xhigh而 opencodex 在 catalog 中 mock 了max/ultra导致严格枚举解析时整个 catalog 解析失败。修复思路是从安装的 Codex 二进制自带 catalogcodex debug models --bundled中读取真实支持的 effort 集合对 entry 做 clamp。设计上做到 self-adapting未来 Codex 若支持max/ultraclamp 自动不再裁剪。Sol 的敌意审查发现两处 unsafe全不支持的 ladder 被原样保留——必须改为保守回退保留low/medium/high探针失败时 no-op——必须改为 warning 日志并走安全路径此外要求syncCatalogModels与/v1/models两个出口边界都加 clamp并补边界测试。该思路已完整落地到 src/codex/catalog/effort.tssupportedCodexReasoningEffortsFromObservedCatalogL318-L333从观察到的 bundled catalog 字节推导 effort 词汇表codexSupportedReasoningEffortsL335-L337是其带默认依赖的包装clampEntryToCodexSupportedEffortsL353-L403按「运行时可观测 effort ∩ 免裁剪集合」过滤 ladderUNCLAMPABLE_REASONING_EFFORTSmax/ultra永远保留而当过滤后 ladder 为空时回退到保守的low/medium/high通用阶梯——这正是 Sol 要求的 safe fallbackclampCatalogModelsToCodexSupportL504-L563是出口级入口先解析并持久化 Codex 运行时resolveAndPersistCodexRuntime探针失败时只输出警告、保留原模型见 L541-L545 的 catch 分支并将 clamp 诊断写入persistEffortClamp。测试证据在 tests/codex-integration/codex-catalog.test.tsmax/ultra在运行时可观测 ladder 止步于xhigh时被保留、全不支持时回退到[low,medium,high]、clampedDefaultEffort(max, [])回退到medium、探针不可用时整个 clamp 是 no-op结构化克隆前后相等。#220 — Gemini 3.5 Flash-Lite 拆分只留 deltaSol 审查发现 dev 的 registry 已包含 Gemini 3.6 Flash因此 #220 只有「3.5 Flash-Lite」这一项是有效增量。策略不是整体合并而是让作者把 3.5 Flash-Lite 单独抽成一个以 dev 为 base 的新 PRAntigravity wire 集遵循 dev 既有路由。当前 src/providers/registry/entries-core.ts 的 google 条目即为该增量落地后的现状模型列表包含gemini-3.5-flash-lite其 context window 为 1,048,576输入模态为[text, image]。Phase 4 需要重新设计大改动的收敛路径Phase 4 的三个 PR 均为大改动各自 400 行、涉及 3-24 个文件且存在设计级缺陷不能简单合并需作者按清单重构。#214 — combo 别名/v1/models 去重 RU key 前后端分离combo rename 别名功能以裸名如deepseek-v4-flash暴露 combo。Sol 发现其 alias collision 处理只在 catalog 的 client_version shape 下生效普通/v1/models模型列表会发出重复 ID。修改清单/v1/models通用 shape 下也需要 alias 去重补 RU 本地化 key对应en.ts902、941-975 区域后端 aliasing/rename 与 GUI 变更分离审查rebase 到 dev 后重跑 CI。#226 — provider 设置页重设计RU 对齐 异步错误 测试升级875 行新增、19 个文件的 provider 页面整体重设计OAuth/API 分区、可搜索 provider picker、restart 端点。Sol 指出的问题缺 RU 本地化 keyrestart 的异步错误未处理测试停留在 source-string 断言层未覆盖真实渲染。修改要求补 RU、处理 restart 异步错误、把 source-string 测试升级为渲染级 UI 测试、强制经由dev。#225 — issue 质量 CI维护者关闭所有权 去除 bug 目标GitHub Actions 工作流自动关闭低质量 feature request检测空/短 section、重复文本、只有标题的 bodytrusted contributor 豁免blank_issues_enabled: false阻断结构化表单绕过。Sol 发现的设计缺陷bot 只依据自身 marker 判断 reopen维护者手动关闭的 issue 会被 bot 重新打开且工作流把bug也纳入目标与 PR 描述的「仅 feature request」不符。修改要求维护者手动关闭时bot 不得 reopen需要跟踪closed_by移除 bug 目标只处理 feature request把验证逻辑抽成可测试的独立脚本。Close / Reject范围失控与已被超越#221 — REJECT 拆分请求污染分支的教科书案例PR 标题声称是 OAuthneedsReauth修复避免 Windows 开机时网络未就绪导致的首刷失败被永久写入 disk、进而卡死 OAuth 账号核心改动本身合理——把needsReauth从 disk 持久化改为 in-memory Set。但实际 diff 是29 个 commit、90 个文件、4434/-185其中needsReauth相关只有约 10 个文件src/oauth/store.ts、src/oauth/index.ts、src/oauth/anthropic.ts、src/oauth/local-token-detect.ts及三个测试文件其余 80 文件混入了 devlog、GUIApp.tsx、ComboWorkspace.tsx、Debug.tsx、Logs.tsx、Models.tsx、styles.css、i18nde/en/ko/ru/zh、combo、cursor、google、catalog、server、winsw、types、registry 等完全无关的改动。Sol 还在 OAuth 核心中找出两处硬伤store.ts:291-296存在不可达代码unreachable codemarkAccountNeedsReauthIfGeneration的 unlocked read-then-mark:433-441区域存在生成竞态且测试没有模拟 fresh process 场景无法证明「重启后不持久化」这一核心声明。最终处置REJECT 整个 PR要求作者只抽取 OAuth 核心store.ts、index.ts、anthropic.ts、local-token-detect.ts 相关测试另开新 PR并顺带修复上述两处代码问题。#213 — Close as resolved被 dev 更安全实现超越PR 试图在内置 provider preset 上也暴露allowPrivateNetwork复选框。Sol 验证发现 dev 的f2fa0c20提交已经以更安全的方式实现现仓库 gui/src/components/AddProviderModal.tsx 的 preset 表单中allowPrivateNetwork: false默认值及 add-provider-form-pane.tsx 的复选框渲染即为证据因此直接 close感谢贡献。交叉依赖图合并顺序不是随意的策略文档给出了精确的 PR 间依赖关系合并顺序必须遵循#215 ──→ (独立) #224 ──→ (独立须在 #214/#220 之前) #211 ──→ (须在 #214/#226 的 i18n 之前) #219 ──→ (独立) #223 ──→ (须在 #214 catalog 之前) #220 ──→ (须在 #224 registry 之后) #214 ──→ (须在 #223、#224、#211 之后) #226 ──→ (须在 #211 之后) #225 ──→ (独立与产品发布分离) #221 ──→ REJECT #213 ──→ REJECT背后的工程逻辑很清晰i18n 类 PR 必须先于所有触碰本地化文件的 PRregistry 类 PR 必须先于所有依赖模型注册表的 PRcatalog 重构必须先于依赖 catalog 的功能 PR。这也解释了为什么合并清单把 #211 放在 #214/#226 之前、把 #224 放在 #220 之前。验证清单合并不是终点每个合并决策都配有可执行的验证动作策略文档原样保留如下#215 合并后运行bun test tests/responses/openai-responses-passthrough.test.ts#224 合并后运行bun test tests/adapters/openai/openai-chat-hardening.test.ts#211 rebase 后运行cd gui bun run build#219 rebase 后运行bun test tests/service/winsw.test.ts#223 修改后运行bun test tests/codex-integration/codex-catalog.test.ts e2ePhase 1-2 全部完成后运行整体bun run testbun run typecheck注原文档中的测试文件名如openai-responses-passthrough.test.ts在当前仓库中位于tests/responses/、openai-chat-hardening.test.ts位于tests/adapters/openai/、winsw.test.ts位于tests/service/、codex-catalog.test.ts位于tests/codex-integration/。这一清单把「合并了」与「合并好了」区分开每个 PR 落地后立即在其最相关的测试套件上验证全部 Phase 1-2 完成后再做全量回归。后续工作区devlog/_fin/260722_pr_review_strategy/010_safe_merges.md 等记录了从「策略」到「执行」的落地过程最终验收标准是gh pr list --state open归零、bun run typecheck退出码 0、bun test --isolate ./tests/无新增失败见 devlog/_fin/260722_pr_review_strategy/050_final_verification.md。小结这套策略可以带走的五个动作初判与终判分离PR 自述只用于初筛最终判定必须结合gh pr diff逐行审查与rg源码交叉验证按风险分四阶段READY 立即合、WITH-FIXES 修完再合、NEEDS-REWORK 重设计、范围失控直接 REJECT 并要求拆分AI 生成 PR 无豁免diff 级验证 测试证据是唯一标准质量高的#215照样进质量低的#221照样拒依赖图决定顺序i18n 先于 UI、registry 先于模型功能、catalog 先于依赖 catalog 的功能冲突面可预测合并即验证每个 PR 绑定专属测试命令全阶段完成后再做全量bun run test与bun run typecheck收口。赞分享【免费下载链接】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 PR 审查与合并策略实战从 11 个 PR 的分诊、敌意代码审查到分阶段合并的全流程复盘opencodex PR 审查与合并策略实战从 11 个 PR 的分诊、敌意代码审查到分阶段合并的全流程复盘 本篇技术指南以 opencodex 项目 202opencodex 分支合并冲突全记录claudecode 与 dev 双线合并的文本/语义冲突解决与验证门禁实践opencodex 分支合并冲突全记录claudecode 与 dev 双线合并的文本/语义冲突解决与验证门禁实践 导读 本文基于 opencodex 仓库opencodex 分支合并实战claudecode → dev 的 53 提交安全合流与冲突解决记录opencodex 分支合并实战claudecode → dev 的 53 提交安全合流与冲突解决记录 本文基于 opencodex 仓库 devlog/_f上一篇ROCm GPU 内存实战三个问题决定显存用得划不划算下一篇HunyuanCustom视频编辑功能教程AI驱动的智能主体替换技术创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
