【免费下载链接】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 #139/#140 语义化子提交栈semantic child stack内的WP140 Dashboard query migration工作相位展开完整解读这一轮重构的目标、边界、验收与回滚契约。你将看到为什么 Dashboard 页面的数据流要从轮询后 setState 镜像 组件内重复计算迁移为查询派生状态、500 行子提交门禁如何约束拆解粒度、react-doctor等工具链如何把关渲染循环以及 loading/error/empty/refetch 四类条件分支在 GUI QA 协议中如何被逐项驱动和留证。背景PR #139/#140 语义子提交栈与 WP140 的位置在 260717_pr139_140_stacked_rebuild/000_plan.md 中记录了这次大规模重构的来龙去脉一次完整的来源追溯周期结束后贡献者快照中留下了764 个源码 hunksPR #139 占 276 个、PR #140 占 488 个需要被转换成可审查、可独立回滚的子提交child commits。整套重构遵循几条硬性契约依赖有序子提交按 WP010 → WP180 的依赖顺序叠放在origin/dev之上单回滚行为每个 child 默认最多改动500 行超过 500 行必须拆分子相位归属保留被整体重建的贡献者行为保留作者Wibias维护者仅作为 committer证据可审计001_hunk_ledger.tsv必须恰好覆盖 764 行数据每个 hunk 都有明确归属与去向。WP140 在这一路线图中的定义是#140 Dashboard query migration其上游是 WP130Providers/Models 诊断下游是 WP141Usage query migration完整链条见 roadmap 表格。WP140 与 WP141 属于已知的超 500 行大相位在设计阶段就被预切分——这正是本相位文档中 Split into sub-children at P to stay under 500-line gate 的由来。WP140 的范围裁定全量承接 Dashboard 变更按符号/选择器扇出相位文档 140_pr140_dashboard_usage.md 的第一条就是范围裁定Interview decision: take ALL Wibias Dashboard changes (currently 1671 lines). Split into sub-children at P to stay under 500-line gate.即全部Wibias Dashboard 变更当时累计 1671 行都要被承接不做选择性丢弃超过 500 行门禁的在 P 相位拆分为子子提交。这与 WP130 的部分 REJECT / 部分 DEFER处置形成鲜明对比——后者因源提交落后于 dev 主干的三层 openai 加固见 130_pr140_providers_models.md 的 P stale-check后端文件被整体拒绝。而 Dashboard 是纯前端 GUI 变更不触碰后端契约因此具备全量承接的基础。样式层面的改动被严格收敛只允许修改 gui/src/styles.css 中由001_hunk_fanout.tsv分配assigned给 Dashboard 的选择器。001_hunk_fanout.tsv是 hunk 扇出台账将 42 个符号/选择器/键子行逐一映射到唯一子提交是哪个 child 能动哪段样式的单一事实来源。重构目标镜像式请求状态 → 查询派生状态相位文档给出了一行浓缩的 before → aftermirrored query data/setState-in-effect and repeated computation - query-derived state with behavior parity拆开来看包含两层问题镜像式数据mirrored query data页面局部把请求返回的数据复制进本地 state再在 effect 中把 state 写回setState-in-effect造成数据有多份拷贝、来源不清重复计算repeated computation同一份数据在不同组件/位置被反复派生计算缺少单一派生入口。迁移目标是query-derived state——状态由查询基础设施直接派生组件只消费派生结果且必须保持行为对齐behavior parity即对外可见的 UI 行为不因内部重构而改变。在 gui/src/pages/use-dashboard-data.ts 中可以看到这种镜像式模式的现状痕迹文件内大量使用setStateuseEffect把轮询快照镜像进可变 UI 状态并在代码中显式标注了 linter 豁免/* oxlint-disable react/react-compiler -- mirror client-resource snapshots into mutable dashboard UI state that handlers also update */ /* eslint-disable react-hooks/set-state-in-effect -- mirror client-resource snapshots into mutable dashboard UI state that handlers also update */这两条豁免注释恰好印证了 WP140 要消灭的反模式在 effect 中 setState 镜像查询结果。迁移后的目标形态是让查询层直接持有状态、组件从查询层派生从而可以移除这类豁免。显式丢弃清单不做的部分为了避免在 500 行门禁内混入无关改动相位文档给出了明确的不做边界Explicit drops视觉重设计visual redesign不借机改版样式大型辅助函数内联large helper inlining不把大函数随手内联格式性改动formatting churn不为了格式化而改动代码。判据只有一条该项改动是否是清除某个已命名诊断named diagnostic所必需的。凡与诊断无关的润色一律不进本 child。这是最小行为修复哲学的体现——每一个进入 diff 的字节都要能追溯到一条诊断或一个行为缺陷。条件激活四类分支必须在 QA 中真实驱动查询派生状态重构最大的风险是加载中、出错、空数据、刷新这四个分支只在真实交互中才出现如果只测 happy path重构后的状态机可能在某条分支上静默退化。因此相位文档规定Conditional activation: loading/error/empty/refetch and editable-state transitions are exercised; no render-time state loop.即这些分支必须被真实触发exercised而不是靠代码阅读推断应该没问题同时必须证明没有渲染期状态循环render-time state loop——即不能在渲染过程中再次触发 setState 导致无限重渲染。后者正是 gui/package.json 中doctor脚本react-doctor0.9.11 --scope changed要抓的典型缺陷。值得注意的分支细节editable-state transitions可编辑状态转换也被纳入验证范围。在 Dashboard 中这对应设置项保存、sidecar 配置、多代理模式切换等乐观更新→失败回滚的交互路径——可参考 use-dashboard-data.ts 中dashboardSettingsReducer对save-started / save-succeeded / save-failed / save-finished的显式状态机以及saveSidecar/saveShadowCall中先写乐观值、失败回滚到 previous的模式。这类状态转换是查询派生重构中最容易在轮询覆盖保存中状态处出问题的环节源码中dashboardSettingsReducer的polled分支正是为阻止轮询覆盖正在保存的偏好而存在。验证门禁五道命令 QA 证据相位文档给出了完整的验证流程bun run --cwd gui doctor:full # react-doctor 全量扫描诊断渲染循环/反模式 bun run --cwd gui lint # oxlint 全量 lint bun run --cwd gui build # tsc -b vite build 类型与构建 git diff --check # 空白错误检查 # diff 500 行子提交行数门禁其中doctor:full在 gui/package.json 中定义为npx --yes react-doctor0.9.11 --verbose --scope full --no-telemetry即全量扫描而日常开发中的doctor则是--scope changed --base origin/main的增量模式。这两条脚本是 WP140 中清除命名诊断目标的直接工具支撑。GUI QA 协议loading/error/empty/refetch 的留证流程相位文档要求按 006_gui_qa_protocol.md 执行 QA并设置WP_ID140 ROUTE#dashboard协议的核心流程从子提交 worktree 根目录执行包括启动 GUI dev serverbun run dev -- --host 127.0.0.1记录gui.log启动agbrowse start --headless无头浏览器导航到http://127.0.0.1:5173/#dashboard等待后依次在1280×720与760×900两种视口下抓取--interactiveDOM 快照、全页截图 JSON、console 与 network 记录对每个命名交互状态loading/error/empty/refetch先抓交互快照用agbrowse click/type/check/select操作当前引用再立即重抓快照证据落盘evidence/WP140/state.md含操作前后命令与观察文本state.screenshot.json。协议中有一条容易被忽略的纪律截图 JSON 路径本身不是观察结果——C检查者必须打开并阅读图片在状态 markdown 中记录视觉结论visual verdict。失败策略也很明确agbrowse连不上时只允许agbrowse statusagbrowse start --headless重试一次禁止为临时 QA 引入新的 Playwright/Puppeteer 运行器结束必须 kill GUI 进程并停止浏览器teardown.txt是收尾凭证。回滚契约Dashboard 与 Usage 各回各的WP140 的回滚保证RollbackDashboard child reverts independently; Usage is WP141.即 Dashboard 子提交可以独立回滚不牵连其他相位Usage 页面的查询迁移被隔离在 WP141见 141_pr140_usage_query.md其目标同样是镜像请求状态与组件内波动 → query 派生 Usage 状态并把 zero-token零 token与 date-range日期范围列为额外必须驱动的分支。两个子提交在行数门禁与 QA 协议上各自独立回滚互不干扰——这正是一个 child 一个回滚行为路线图原则在 Dashboard/Usage 页面上的落地。现状对照Dashboard 数据流在当前源码中的形态理解 WP140 的迁移方向需要看当前仓库中 Dashboard 数据流的真实形态。入口组件 gui/src/pages/Dashboard.tsx 本身是纯展示壳它调用useDashboardData(apiBase, refreshEpoch)取回全部状态与回调按 overview / providers / models 三个 tab 分发并处理键盘导航方向键切换 tab、Home/End 跳首尾与鉴权失败、数据不可用等错误态。数据层的核心在 use-dashboard-data.ts它呈现了一个典型的镜像式轮询架构多路轮询资源通过useKeyedClientResource见 gui/src/client-resource.ts创建 8 路命名轮询包括dashboard-overview5s、dashboard-sidecars5s、dashboard-settings5s、dashboard-multi-agent5s、dashboard-usage60s、dashboard-models、dashboard-startup-health30s、dashboard-diagnostics等两级波次Waveoverview/ma-mode/sidecars/settings 属于 Wave 1启动即轮询multi-agent/usage/diagnostics/models 以enabled: overviewReady延迟启动modelsPoll还附加error依赖避免在错误态下继续请求快照镜像进 state每路轮询的.data通过 effect 镜像进setHealth/setProviders/setModels/...同时写入sessionListCache前缀如ocx.dash.overview.v1:、ocx.dash.usage30d.v1:以便刷新后冷启动直接读到缓存fetch 层独立所有请求封装在 dashboard-core-poll.ts例如fetchDashboardUsage固定请求/api/usage?range30d并注释说明usage 在旧服务器上可能昂贵独立资源使其不阻塞 health/provider/settings 提交失败刷新保留上次好快照fetchDashboardModels则强调非 OK/空响应必须抛错让 client-resource 保留旧快照而不是把 HTTP 错误当作成功空列表。把这段现状与 WP140 的 before → after 对照可以清楚看到迁移的落点把8 路轮询 effect 镜像 多份本地 state收敛为查询派生态让setState-in-effect的豁免当前以eslint-disable react-hooks/set-state-in-effect显式标注的 13 行逐步消失同时保持 loading/error/empty/refetch 四类分支的可验证行为不变。结语一次以门禁换安全的查询架构演进WP140 的价值不在于引入全新的查询库而在于确立了一套可审计、可回滚、可验证的迁移方法论全量承接上游变更1671 行→ 按 500 行门禁拆解 → 只改诊断相关代码 → 四类条件分支逐一驱动留证 → 独立回滚。这套研究优先、证据留痕、拒绝侥幸的做法与整个 PR #139/#140 子提交栈的 hunk 台账、扇出台账、冲突矩阵一脉相承是大型 GUI 重构落地时值得复用的工程模板。若你想继续深入可以按顺序阅读同目录下的 120_pr140_query_foundation.md查询/客户端基础与 141_pr140_usage_query.mdUsage 页面的同型迁移再回到 use-dashboard-data.ts 对照当前实现逐段印证。赞分享【免费下载链接】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点击查看免费下载相关推荐如何将TwUI集成到现有AppKit项目TUINSView桥接技术详解如何将TwUI集成到现有AppKit项目TUINSView桥接技术详解 TwUI是一款基于Core Animation的Mac UI框架它能够帮助开发者构建UI库/组件桌面应用GetQzonehistory 完整指南如何把你的 QQ 空间历史说说导出成 Excel 和图片GetQzonehistory 完整指南如何把你的 QQ 空间历史说说导出成 Excel 和图片 GetQzonehistory 是一款开源的 QQ 空间备份网页爬虫数据分析前端状态管理迁移gh_mirrors/ji/jira_clone从Redux到React Query实践前端状态管理迁移gh_mirrors/ji/jira_clone从Redux到React Query实践 在现代前端开发中状态管理方案的选择直接影响应用性能前端后端企业应用上一篇FlagGems核心揭秘Triton语言如何打造大模型专用加速算子下一篇Spring Authorization Server 核心概念解析深入理解 OAuth2 授权流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考