CodexBar OpenCode Go 多工作区用量：自动扇出与堆叠卡片的决策设计与契约边界

CodexBar OpenCode Go 多工作区用量自动扇出与堆叠卡片的决策设计与契约边界【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar本篇技术文章围绕 CodexBar 仓库中的决策文档 2026-07-01-opencode-go-multi-workspace-decision.md 展开当一个 OpenCode 账号下存在多个各自持有 Go 订阅的工作区workspace时CodexBar 如何从只取第一个工作区演进为自动扇出、每个工作区一张堆叠卡片。读完后你可以掌握该特性的完整问题定义、三个候选方案的取舍理由、九条已接受的实现契约含截断上限、并发上限、失败隔离等硬性边界以及结合 OpenCodeGoUsageFetcher.swift 源码理解当前单工作区实现的具体调用链。问题定义发现多个工作区却只展示一个CodexBar 通过opencode.ai的浏览器会话读取 OpenCode Go 订阅用量。决策文档指出的核心问题是一个 OpenCode 账号可以拥有多个工作区每个工作区各自持有一份 Go 订阅CodexBar 能够发现所有工作区标识符但只选取第一个全链路快照模型、刷新状态、配置项、CLI 投影、菜单栏卡片都是单工作区标量设计用户想查看另一个工作区只能手动替换 override 再刷新。文档特别强调这不是多账号问题——浏览器会话是共享的工作区身份只是对用量请求和渲染结果的作用域限定。这一区分直接决定了后文的身份模型设计见存储与投影边界一节。当前实现与文档描述完全吻合。在 OpenCodeGoUsageFetcher.swift 中工作区发现走的是opencode.ai/_server的服务函数端点fetchWorkspaceID第 338–383 行先以 GET 请求workspaces服务函数服务函数 ID 硬编码为def39973...4f见第 32 行workspacesServerID解析函数parseWorkspaceIDs第 408–416 行用正则id\s*:\s*(wrk_[^])从text/javascript序列化响应中提取所有wrk_前缀标识符GET 拿不到时回退为parseWorkspaceIDsFromJSON第 418–448 行对 JSON 树做递归收集并天然去重再不行则用 POST 重试但无论解析出多少个最终都执行return ids[0]第 382 行——这正是文档所述selects only the first one的源码证据。override 机制同样可以在源码中逐行印证fetchUsage第 120–126 行接受workspaceIDOverride参数若normalizeWorkspaceID能规范化该值就跳过发现流程。规范化规则第 385–406 行接受三种输入裸的wrk_...ID、形如https://opencode.ai/workspace/...的完整 URL、或任意包含wrk_[A-Za-z0-9]片段的文本都不满足则返回nil。override 的两个来源在 OpenCodeGoProviderDescriptor.swift 中可见设置项settings?.opencodego?.workspaceID优先其次是环境变量CODEXBAR_OPENCODEGO_WORKSPACE_ID第 437–438 行docs/opencode.md 也记录了这个环境变量与 URL 形式的用法。此外一旦设置了 override或选择了 token 账号、手动 cookierequiresScopedWebStrategy第 147–159 行会切换到 Web 优先的抓取策略链——因为此时数据已是按工作区限定的设备级本地历史不应排在前面。已验证的约束哪些假设不能动摇文档列出了五条Verified constraints它们共同划定了方案的可行域订阅归属工作区。OpenCode 的公开 Go 文档说明每个工作区至多一名成员可订阅 Go因此多工作区等价于多份订阅这是扇出必要性的业务前提。发现响应只给出标识符不给展示名。当前解析只能得到wrk_...ID在拿到脱敏后的真实认证响应证明之前展示名display name不能作为持久化契约。这一约束后来体现为契约第 8 条。现有链路全是单工作区。快照、刷新状态、设置字段、CLI 投影、菜单卡片都是标量模型——这解释了为什么实现不能只改解析器而必须引入工作区作用域的快照模型。周窗口是可选的。已合并的 PR #1788 让 weekly usage 变为可选项多工作区投影必须为每个工作区独立保留rolling-only的结果形态。这一点在当前快照模型中已有体现OpenCodeGoUsageSnapshot.swift 定义了hasWeeklyUsage/hasMonthlyUsage布尔位第 5–6 行toUsageSnapshot()仅在hasWeeklyUsage为真时才生成 secondary 窗口第 80–90 行fan-out 实现必须逐工作区保持该语义。token 账号行是错误身份模型。CodexBar 的 token account 机制Session tokens见 OpenCodeGoProviderDescriptor.swift 第 15–21 行用于存储多份凭证而多工作区场景下所有工作区复用同一份凭证若把不同工作区的结果塞进 token 账号行会混淆身份与作用域两种概念。三个候选方案的取舍方案 A自动扇出 堆叠卡片已接受刷新时发现全部工作区用同一个认证会话并发拉取每个工作区渲染一张堆叠卡片保留现有 override 作为显式的单工作区过滤器服务于排障和超大账号场景。文档给出的收益与代价是符合用户预期、无需复制 cookie、且可复用 Kilo 已落地的作用域快照 堆叠卡片模式代价是刷新扇出的网络开销、部分失败状态、卡片排序以及新的工作区作用域快照模型。仓库中确实存在可复用的先例KiloOrganization.swift 定义了一个仅含id/name/role的轻量身份结构第 3–13 行配合 KiloUsageFetcher.swift 实现了一个凭证、多个组织、多张卡片的投影——这正是方案 A 想要迁移到 OpenCode Go 的既有形态。方案 B设置页勾选工作区在 Preferences 中提供发现/选择列表只拉取勾选的工作区。收益是网络开销可控、行为显式代价是要额外维护缓存的工作区元数据、处理失效选择、增加配置步骤并且对默认看到所有订阅的用户是一个反直觉的默认值。被否决。方案 C工作区子菜单保留一张 provider 卡片把工作区结果放进子菜单。收益是菜单紧凑代价是隐藏用量、引入 provider 专属导航且无法复用共享的堆叠卡片展示组件。被否决。已接受的契约九条实现边界方案 A 被接受但附带九条硬性契约。下面逐条解读并指出与现有代码的衔接点。新增OpenCodeGoWorkspace模型含标识符和可选展示名永远不得把名字当作请求键。请求路径上只能出现wrk_...ID名字只用于展示层。发现一次、归一化、去重、排序每次刷新只做一次发现卡片顺序必须按归一化后的标识符排序。响应到达时间、服务端返回顺序、展示名变化都不得改变卡片顺序——这保证 UI 稳定、可被截图对比测试。数量与并发双上限每次刷新最多处理 20 个已发现工作区最多 4 条工作区流水线并发。发现数超过 20 时必须展示结果被截断状态并引导用户去单工作区 override。结果按工作区隔离单个工作区失败不得抹掉或改写其他工作区的成功结果若保留上一轮快照需将其标记为 stale并把当前错误关联到同一个稳定标识符。工作区快照独立于 token 账号存储通过 provider identity 投影出安全的工作区标签供堆叠卡片和 CLI 输出使用但关联键始终是标识符而非标签。override 降级为过滤器设置后跳过发现精确拉取该归一化标识符非法输入必须在发起网络请求前失败请求失败绝不回退到其他工作区。对照现有实现fetchUsage中 override 的归一化校验第 133–140 行已经做到非法则走发现流程而契约进一步要求非法 override 直接报错而非静默走发现。复用同一内存认证会话所有工作区流水线共用一份 cookie绝不按工作区复制或持久化 cookie日志中不得出现原始凭证或工作区标识符。这与 OpenCodeGoUsageFetcher.swift 当前传入cookieHeader字符串、会话本身为 ephemeral 且禁用 cookie 存储第 111–118 行的做法一致fan-out 只需把同一 header 传给每条流水线。展示名暂不持久化若线上契约没有稳定展示名则显示简短的脱敏序号或标识符后缀推迟名字持久化持久化名字需要单独的认证契约证明。数据边界隔离工作区数据留在 OpenCode Go provider 内部不借用其他 provider 的身份或 plan 字段。从源码结构看第 3、7 条意味着新实现应在fetchUsage的调用层做扇出每条流水线独立携带workspaceIDOverride调用同一静态方法而不是重写抓取内核——现有的fetchUsage(cookieHeader:timeout:workspaceIDOverride:...)签名天然支持按工作区复用。实现前必须补齐的证明材料文档明确决策本身不改变运行时行为实现前需要四份证据——脱敏的认证发现响应证明存在稳定的工作区标识符与名字字段或证明名字不可用同一会话下两个工作区的脱敏用量响应验证一会话多工作区假设;打包应用截图两张堆叠卡片且不含任何账号/工作区机密失败证明一个工作区失败时另一个工作区仍然可见。前三项中第二、四项直接对应契约第 4、7 条第一项则决定契约第 8 条走向显示脱敏后缀还是持久化名字。验收测试清单文档把可执行的验收标准写得非常具体可作为实现时的测试大纲验收项验证点发现去重两个以上工作区标识符被去重缺失名字不崩溃共享凭证一个凭证产生每工作区一次请求不产生重复 cookie 持久化乱序完成响应乱序返回时结果仍正确关联到各自工作区部分失败兄弟工作区的成功卡片得以保留截断超过 20 个工作区产生确定性的 20 条结果 可见的截断状态并发至多 4 条工作区流水线同时运行override 生效手动 override 只拉取目标工作区override 失败语义非法 override 在网络请求前失败合法的失败 override 不回退确定性标签CLI JSON 与菜单模型对每个工作区给出确定性的标签门禁在确切实现头提交上make check与make test通过最后一条中的make test对应 Makefile 中的test目标第 33 行。仓库中已有的 OpenCode Go 相关测试如 OpenCodeGoProviderStrategyTests.swift、OpenCodeGoUsageFetcherCLIWaitTests.swift覆盖了单工作区 override 的 CLI 等待与超时路径为 fan-out 的乱序完成部分失败测试提供了可参照的测试基础设施。决策结论与适用范围文档最终决策为CodexBar 接受自动工作区扇出 堆叠卡片并保留现有单工作区 override全部实现以九条契约为边界。同时声明本文档不改变运行时行为实现仍需脱敏的认证多工作区证明、聚焦的解析器/模型测试、打包 UI 证明与独立评审工作区名字持久化在认证响应契约被证明之前保持范围之外。适用前提与限制该决策仅适用于 Web 会话cookie认证路径下的 OpenCode Go providerAPI key 路径fetchAPIUsage第 208–241 行走GET https://opencode.ai/zen/go/v1/usage不涉及工作区发现不在本契约范围内决策状态为accepted; not implemented即契约已定、代码尚未落地阅读时请以仓库当前实现为准。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考