【免费下载链接】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 仓库devlog/_fin/260723_open_pr_review/100_merge_records.md记录的一次真实「开放 PR 评审与本地合并」会话为骨架系统讲解一种只在本地产出合并提交、不触碰远程仓库、由 Sol 子代理逐轮审计的 PR 合并工作流从 base refresh、逐 PR 的 Sol auditPASS/FAIL/NOOP/NEEDS_HUMAN、fixup 补丁、冲突裁决到与上游 maintainer dev 的对齐集成和最终推送并穿插源码级证据说明每个审计结论背后的实现依据。读完本文你将掌握一套可复用的「审计—合并—验证—推送」四段式 PR 处理流水线以及 opencodex 中 Google wire 编译、SSE 解码、Chat Completions 翻译等关键模块的底层原理。会话背景一份本地合并栈记录100_merge_records.md记录了 2026-07-23 前后 opencodex 维护流程中的一轮「open PR review」执行结果完整计划见 000_plan.md。其核心工作方式是在独立 worktree 上创建本地分支codex/pr-review-260723trackingorigin/dev把所有评审通过的 PR以本地 merge commit 形式叠放在栈上NO push、NO GitHub mutations——合并过程完全不触碰远程仓库GitHub 状态保持原样每个工作包Work PackageWP由Sol 子代理gpt-5.6-solmedium effort执行审计并给出 PASS / FAIL / CLEAN 等结论人工只在必要时介入如 NEEDS_HUMAN 裁决每次合并后以bun run typecheck与bun run test作为硬性验证门槛记录测试总数3614 → 3631 → 3651 → 3650 → 3676全部 0 fail。该计划最初盘点 8 个开放 PR#316/#309/#307/#306/#304/#303/#279/#249/#317而合并记录文档聚焦于最终进入本地栈的 4 个工作包WP2/WP3/WP4/WP5/WP6并追加了 WP-INT与 maintainer dev 集成与 WP-PUSH推送两节。阶段一Base refresh —— 先对齐上游再叠 PR在开始逐 PR 合并之前记录明确了一个关键步骤先把本地分支刷新到最新origin/dev。1639af37: no-ff merge of origin/dev 02b67b03这次 no-ff 合并一次性吸收了上游已合入的#316anthropic SSE 终帧修复与#317WHAM 月度配额窗口。它的直接收益是WP3PR #317在评审前就已包含在栈基中因此后续被判定为NOOP——不重复合并。判定证据是 git 的祖先关系检查git merge-base --is-ancestor pr-317 HEAD → true这条命令验证了「目标 PR 的 HEAD 已经是当前分支的祖先」从而避免重复合入。这是整个工作流的第一条可复用经验叠 PR 之前先吸收上游并用 merge-base 祖先关系去重把「已合入」与「待合入」精确区分开。阶段二WP2 合入 —— 审计 PASS 路径PR #307PR #307custom model display names详见 030_pr307_display_name.md是第一个走完完整 PASS 路径的 PRSol auditagent 019f8dbcPASS0 blockers。审计确认合并树干净、与 #313/#316/#317 无语义冲突、注入面受控JSON.stringify持久化 CLI/API 层拒绝斜杠、catalogModelSlug导出存在。Merge commit2523a6f53 文件 168/−1零冲突。验证bun run typecheck退出码 0bun run test3631 pass / 0 fail3614→363117 个测试来自 #307 与 base refresh。记录中特别提到一个环境性插曲首次运行时出现 2 fails 2 errors根因是全新 worktree 缺少 gui/ 下的 node_modulesreact/jsx-dev-runtime执行bun install后即恢复与合并本身无关。这提醒我们在干净 worktree 中做合并验证必须先补装依赖再下结论。阶段三WP4 裁决 —— 审计 FAIL 与 NEEDS_HUMAN 路径PR #309PR #309google wire 兼容消除 Antigravity 请求形状 400详见 020_pr309_google_wire_compat.md展示了当 Sol 审计判定 FAIL 时维护者如何处理——不粗暴合入也不当场私改而是升级为 NEEDS_HUMAN。Blocker 1HightoolNameCodec 跨请求的非确定性碰撞PR 引入的toolNameCodecgoogle-wire-compiler.ts会给非法工具名如 MCP 的server.tool点号违反^[A-Za-z_][A-Za-z0-9_-]{0,63}$见 L15生成prefix_hash8形式的 wire 名。问题在于盐化名字依赖 encounter 顺序——如果某个合法工具名恰好等于生成的prefix_hash8候选重排工具集合就会改变碰撞工具在 wire 上的名字。而 Antigravity replay 缓存按 provider 可见名字签名google-antigravity-replay.ts:39,120跨 turn 的重排/子集变化会导致缓存签名失配从而重新触发 400。评审综合意见REVIEW-SYNTHESIS-01承认常规场景无碰撞是确定性的因为 hash 基于原始名字只有对抗性/运气不佳的名字碰撞才会触发。属于真实但低概率的正确性缺口应交给上游修复。Blocker 2Mediumallowlist 过度裁剪 Vertex / AI StudioPR 将 schema 清洗从 blocklist 换成 Google 文档 allowlist 子集但minimum/maximum/additionalProperties/pattern被一并丢弃——而 Google 明确文档支持这些字段。因此 PR 声称的「Google-documented allowlist」对非 CCA 路径不成立且反向推翻了现有测试断言google-tool-schema.test.ts:27,80。建议方案是provider-profiled 编译仅在 Cloud Code Assist 路径启用严格清洗Vertex / AI Studio 保留文档化字段。裁决WP4 关闭为NEEDS_HUMAN——按当前组成不并入本地栈两项 findings 作为上游反馈记录本会话不向 GitHub 发帖交由维护者决定如何转达。栈状态保持不变最后一个 green 节点是 2523a6f5。核心经验审计 FAIL 不等于 PR 无价值而是「当前形态不可入栈」修复属于作者/维护者的工作不属于合并现场临时补丁。阶段四WP5 合入 —— 两轮 fixup 修复后 PASSPR #279PR #279GitHub Copilot App 通过 OpenAI 兼容 chat completions 接入详见 070_pr279_copilot_chat_completions.md是工作流中最完整的一次「审计→修复→再审→合入」循环共经历3 轮 Sol audit。Round 13 个 blockerHigh —— /v1/models 鉴权回归PR 把GET /v1/models从requireApiAuth(data-plane)切到requireResponsesApiAuth导致远程绑定下不再接受Authorization/x-api-key的裸 bearer 放行会同时破坏 OpenAI bearer 客户端和 Claude gateway 经anthropic-version的发现流程。修复改回requireApiAuth——因为/v1/models从不向上游转发 Authorization「双 bearer 冲突」的顾虑不成立。Medium —— 文档自相矛盾docs/github-copilot-app.md 的远程配置同时写了 API-key 字段和x-opencodex-api-key头。判定为residual仅文档、loopback 不受影响只记录为上游反馈不本地修复。High —— 手写 SSE 切分器缺陷outbound 用自写的\n\nsplitter既漏掉 CRLF 帧边界又在 EOF 时丢终帧——导致有效响应被误报为 truncated。这与栈内共享的 SSE 解码器#316 引入构成语义冲突。修复改用decodeServerSentEvents。Round 2新 blocker —— cancel() 悬挂Round 1 的修复提交fixup commit 1/v1/models恢复requireApiAuth(data-plane)并注释说明responsesSseToChatCompletionsSse重写为共享解码器补 CRLF/EOF 回归测试之后Round 2 仍 FAILcancel() 悬挂在空闲的上游读取之后——generator return 会等待 pending awaitlive probe 显示upstreamCancelled:false。Round 3PASSfixup commit 2 的解法是给decodeServerSentEvents增加可选{ signal }参数abort 直接 cancel 底层 reader从而让消费者的iterator.return()不再悬挂在空闲上游之后。这在 sse-decoder.ts 中有清晰实现——注释明确说明「a plain generator return waits for the pending await first」而onAbort会reader.cancel(signal?.reason)立即解开 in-flight read。outbound 侧则「先 abort 再关迭代器」并为 idle-upstream 取消补了回归测试no-signal 消费者#316 anthropic 路径行为不变。最终PASScancellation resolves promptly, cancels upstream exactly once, listener cleanup safe, no-signal consumers unchanged, 27 focused tests pass。合并提交eebd4977 2 fixupstypecheck 0bun run test3651 pass / 0 fail覆盖 297 个文件85.97s。源码佐证outbound 的翻译层PR 落地后的核心代码现存于仓库src/chat/outbound.ts 实现了 Responses SSE → Chat Completions 形状的转换流式输出data: {choices:[{delta:...}]}以data: [DONE]收尾非流式输出{ id, object:chat.completion, choices:[{message}], usage }。其中chatCompletionsUsage把 Responses 的input_tokens/output_tokens含 cached / reasoning 明细映射为 OpenAI 兼容的prompt_tokens/completion_tokens/total_tokens——并总是输出 detail 对象零值兜底使要求严格的 OpenAI 兼容客户端在路由到不报告缓存/推理数的 provider 时也不会失败。入站侧 src/chat/inbound.ts 的assertChatCompletionsRoutingBody只校验 Chat 路由前必需字段model非空字符串、messages非空数组产出体必须通过responsesRequestSchema从而完整继承现有 routing/OAuth/pool/sidecar 逻辑。阶段五WP6 合入 —— 安全评审 冲突裁决PR #304PR #304kiro 修复恢复加固并完成文本回合详见 050_pr304_kiro_followup.md涉及 Kiro OAuth/凭据导入按 MAINTAINERS.md 属security-review 范围。Sol 安全子裁决CLEAN只读的KIROCLI_DB_PATHselector实现见 src/adapters/kiro/adapter.ts 与 src/adapters/kiro/wire.ts%:token常量绑定参数——无 SQL 注入面模糊/缺失 token 选择时 fail-fast不泄露 values/keys/pathsclientIdHash受限诊断信息分类化redaction 完整upstream-http-error.ts:6安全文件 HEAD vs pr-304byte-identical凭据加固已随 #302 restore 落地privacy:scan通过。合并裁决 Round 1FAIL —— 5 处真实冲突kiro.ts、structure/04、kiro-stream 2 个 e2e 测试文件冲突。记录坦诚指出手工 merge-tree preflight 漏看了前缀标记而 Sol 正确使用了merge-tree --write-tree——教训被记录在案。冲突解决策略PR 侧优先superset 原则pr-304 已经在上游 dev 9ca7ea32 合并过因此PR 侧是包含栈侧的超集。5 个区域全部取 PR 侧后验证4 个代码/测试文件与 pr-304 逐字节一致structure 文档保留栈内 Cursor 章节kiro-stream 测试数 5353。合并提交bb94ecbeSol C 轮验证 PASSconflict resolution faithfully preserves the stack while applying #304s intended completion behavior测试 delta -1 是有意为之4 个旧 fallback 用例 → 2 个 completion-semantics 用例 test-runner 测试#279/#316 blobs 未变。验证typecheck 0bun run test3650 pass / 0 fail298 个文件privacy scan 通过。栈终态合并记录汇总WPPROutcomeMerge SHATests afterWP2#307 display namesDONE2523a6f53631/0WP3#317 WHAM monthlyNOOP经 base refresh 1639af37 吸收——WP4#309 google wireNEEDS_HUMANSol FAILcodec 碰撞 Vertex allowlist 过度裁剪未合并—WP5#279 Copilot chatDONE2 个经审计 fixupeebd49773651/0WP6#304 kiro follow-upDONE安全 CLEAN5 处冲突已裁决bb94ecbe3650/0分支codex/pr-review-260723仅存本地未推送GitHub 未被触碰。应反馈上游的事项#309 两个 blocker、#279 文档矛盾residual。阶段六WP-INT —— 与 maintainer dev 的理性对齐在本地栈构建期间维护者将 origin/dev 推进到a0b9688d上游合入了 #307、#309按原样不带本地 fixup、#279、#303 docs、#318 cursor continuation、#319 fast-uri 3.1.4并从 main 收敛出 v2.7.34。此时本地栈面临两棵树的分叉记录给出了对齐原则上游是维护者决策的事实基准#309 尽管本地审计为 NEEDS_HUMAN仍被上游合入——尊重而非回滚两个 blocker 作为 KNOWN-ISSUE 反馈保留WP4 已记录。本地侧携带上游缺失的已验证改进两个 #279 fixup/v1/models恢复requireApiAuth——上游合入了回归版本可 abort 的共享 SSE 解码器替代手写 splitter修复 CRLF/EOF 与 idle-cancel 缺陷和 #304 合并kiro clean-text-EOF 测试隔离安全评审 CLEANPR 在上游仍开放。合并机制是git merge --no-ff origin/dev → ab72fc10零冲突结果树d31cce0d被验证为与 Sol 审计过的合成树逐字节相等。Sol 集成审计agent 019f8ded覆盖 5 个区域PASS 且无 blocker、无需要手工混编的文件package.json的混合是预期并集上游 fast-uri override 本地 scripts/test.ts runner版本保持在 2.7.34。验证typecheck 0bun run test3676 pass / 0 fail299 个文件privacy scan 通过。阶段七WP-PUSH —— 用户批准的最终推送本地栈与上游对齐后进入推送环节本次会话经用户批准Sol 推前门禁GO——祖先关系成立32 个变更文件与已审栈一致无 junk/local-state 路径推送树内无 codexclaw/goalplan 文件。推送a0b9688d..3a87829f HEAD - devfast-forward无 force。pre-push hook 运行范围无 gui/ 变更gui doctor 跳过。远程校验git ls-remote origin dev3a87829f 本地 HEAD。副作用GitHub 自动关闭 PR #304其 head 9ca7ea32 已成为 dev 的祖先。推送后仍开放的 PR#306等待 CI GUI 审批、#325新、未分类。最终 dev 树携带上游a0b9688d含作为维护者决策合入的 #309 本地 #304 合并 两个 #279 fixup review/merge/integration 各 devlog 单元。可复用的方法总结本地先行所有合并先在本地分支完成并审计GitHub 保持原样——审计结论与合并结果解耦评审可以放心大胆地说 FAIL / NEEDS_HUMAN。Base refresh 先行 merge-base 去重吸收上游后用git merge-base --is-ancestor识别 NOOP避免重复劳动。三轮审计循环PASS 即合FAIL 则产出最小 fixup 补丁并进入下一轮直到 Sol 给出「cancellation resolves promptly / upstream exactly once / no-signal consumers unchanged」级别的精确结论。安全评审单列赛道涉及凭据/OAuth 的 PR 必须先跑安全子裁决只读 selector、常量绑定参数、fail-fast 不泄露、redaction、privacy scan再谈合并。冲突裁决用 superset 原则当 PR 已在上游合入时PR 侧是超集逐区域取 PR 侧并用字节级对比 测试数做收敛验证。集成阶段以「上游为准 本地改进不丢」维护者决策优先本地已验证改进如可 abort 的共享 SSE 解码器通过 fixup 携带进主干最终用 push 门禁祖先关系、文件白名单、无 force收口。这套工作流对应的审计证据、逐 PR 详细分析与源码实现均可在此仓库内追溯计划与决策见 000_plan.md 及 020 / 030 / 050 / 070 / 090实现层可分别对照 google-wire-compiler.ts工具名 codec 与 400 修复路径、sse-decoder.ts可 abort 的共享 SSE 解码、src/chat/inbound.ts 与 src/chat/outbound.tsCopilot chat completions 翻译层。赞分享【免费下载链接】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 仓库 2026 07 22opencodex 分支合并冲突全记录claudecode 与 dev 双线合并的文本/语义冲突解决与验证门禁实践opencodex 分支合并冲突全记录claudecode 与 dev 双线合并的文本/语义冲突解决与验证门禁实践 导读 本文基于 opencodex 仓库opencodex PR 队列合并审查实战从 CI 根因定位到冲突地图与可复现验证opencodex PR 队列合并审查实战从 CI 根因定位到冲突地图与可复现验证 导读 本文完整还原 opencodex 项目在 2026 07 20 对一上一篇地理分布式部署如何优化P2P网络延迟tracker.23794.top服务器架构深度分析下一篇Chapyter 开源项目教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
：物理内存管理器——让内核学会“分配”》)
