Skip to content

VALIDATION.md

Latest commit

 

History

History
509 lines (358 loc) · 63.3 KB

VALIDATION.md

File metadata and controls

509 lines (358 loc) · 63.3 KB
Raw

开发验证记录

v0.2.14 发版记录（2026-11-08）

用户确认“验证后合并发版”。下方“合并前真实上游复测”一节保留为当轮状态。本次未部署或访问任何服务器。

发版

  • PR #18 以 squash 合并为 02d19ceefacc7a98cb527bd9453cc87758fad836，合并提交的源码树与 CI 全绿的分支头 34b34b8 一致。附注标签 v0.2.14 指向该提交。
  • 标签 CI 9 项任务全部通过（含 v0.2.13 → v0.2.14 热升级联测、最新 CPA 候选联测与发布），main 推送 CI 同样通过。
  • 公开 Release 已设为 Latest，共 11 个资产。下载全部资产，SHA-256 与 GitHub 记录的 digest 逐个一致，checksums.txt 与各 .zip.sha256 逐行一致；四平台包与独立页面包 BUILD.json 版本均为 0.2.14、来源提交均为 02d19ce 且工作区干净，两个 Linux 包 glibc_minimum 为 2.28。
  • tests/cpa_store_install.py 在隔离 Windows CPA v8.0.23 与 v8.0.59 中均通过：匿名公开源发现、选择 v0.2.14 Release、校验安装、重启加载并报告 0.2.14。

真实上游验收（正式 Windows 包）

凭证仅保存在仓库外的临时文件（仅当前用户可读），验收结束后删除。测试 CPA 经日本出口代理（香港出口下 Claude 模型返回 403，见下节）。以正式包内动态库（SHA-256 e0519cfa…f895e3）运行兼容探测，在 CPA v8.0.23 与 v8.0.59 上各 10 次请求、全部 200，宿主 /status 报告 0.2.14：

  • sonnet-5-5 (none)：原生 Messages 首次与再次、Chat 客户端、重启后流式均记录 thinking_off_unsupported:adaptive_low、reasoning_to=low，回复无推理内容。v8.0.59 由宿主剥离后缀再注入等级，插件仍正确改写，补上了付费模型在 v8.0.59 上未复测的空缺（仅限这两个 Claude 模型）。
  • sonnet-5-5 强制工具 tool／any／Chat required、重启后流式：均记录 forced_tool_choice_unsupported:auto，模型调用 read_file 且参数正确（Chat 客户端 1 个 tool_calls）。
  • haiku-5-5 (none) 与强制工具：无调整。重启后统计 10／10 成功、均有用量。

v0.2.14 合并前真实上游复测（2026-11-08）

使用 PR #18 head dbb2fc4 在 WSL 交叉编译的 Windows 动态库（版本号仍为 0.2.13，源码与发版仅差版本号和文档），宿主 CPA v8.0.23；凭证只放在仓库外的临时文件中，用后删除。

  • 出口导致的 403：首次复测时两款 Claude 模型均返回 403 permission_error「The provider refused this request. The refused request wasn't charged.」，不经插件直连上游也一样；同一时间 gpt-5.6-sol、deepseek-v4-pro 返回 200，账户额度正常（5 小时窗口几乎未用）。当时本机出口为香港（Cloudflare colo=HKG，IPv4／IPv6 相同）。只让测试 CPA 经日本出口的代理后，同一密钥的 Claude 请求恢复 200。插件对该 403 不做兼容调整（符合设计）；CPA v8.0.23 把它当作凭证故障，同模型随后返回 503 auth_unavailable。部署说明已加入排查提示。
  • 上游报错原文（直连）：thinking.type=disabled → 400「To turn thinking off on this model, send "thinking": {"type": "between_tools"} instead of {"type": "disabled"}…」；tool_choice 为 tool／any → 400「tool_choice: type "tool" and "any" are not supported for this model.」（CommandCode 把上游错误 JSON 作为字符串放在 message 中）。两者均命中现有匹配规则，无需修改。auto 返回 200 并调用工具；haiku-5-5 接受强制工具。
  • 兼容探测（经插件，10 次请求全部 200）：
    • sonnet (none) 首次：日志 adjustments=[thinking_off_unsupported:adaptive_low]、reasoning_to=low，返回纯文本；第二次直接改写（1.7 s，首次含被拒请求 2.7 s）；Chat 客户端同样改写，回复无推理内容。
    • sonnet 强制工具 tool 首次、any、Chat 客户端 required：均记录 forced_tool_choice_unsupported:auto，模型调用了 read_file 且参数正确。
    • haiku (none) 与强制工具：无调整，reasoning_to=none。
    • 重启 CPA 后的流式请求：两项都在输出前重试成功，流式 200；统计 10／10 成功且均有用量。
  • 验收脚本 commandcode_live.py --generate --tools --thinking --thinking-off --max-tokens 2048 --max-requests 7：haiku-5-5 7／7 PASS（无调整，4,052 tokens）；sonnet-5-5 7／7 PASS（工具调用 1 次 forced_tool_choice_unsupported:auto、关闭思考 1 次 thinking_off_unsupported:adaptive_low，2,379 tokens）；两者 CPA 用量计数与插件统计一致。

升版本号后的本地验证：Windows go test／go vet／gofmt、WSL Linux go test -race、Node 32 项、Prettier、CPAMP 页面校验 6 项通过；在固定基线源码上重建并内嵌 0.2.14 页面，WSL 交叉编译的 Windows 动态库在 CPA v8.0.23 与 v8.0.59 上跑完 9 项宿主联测（含 v0.2.13 正式包 → 新库热升级），18／18 通过。

尚未验证：付费模型在 CPA v8.0.59 上的复测（宿主剥离后缀后注入等级，插件映射路径相同）；sonnet-5-5 低强度下“不思考”只是抽样观察，不作保证。

真实验收发现的兼容修复（2026-11-08，v0.2.14）

针对下方付费验收发现的三个问题：

  • model(none) 与 sonnet-5-5：插件识别上游“改用 between_tools”的 400，改为自适应思考 + effort=low 重试一次，日志 adjustments 记录 thinking_off_unsupported:adaptive_low，reasoning_to 记为 low。依据：实测自适应低强度下 sonnet-5-5 对简单题不思考（见下方思考等级表）；between_tools 被 CommandCode 校验拒绝，无法使用。
  • 强制工具选择与 sonnet-5-5：识别 tool_choice “not supported” 的 400，改为 auto（保留工具列表与 disable_parallel_tool_use）重试一次，记录 forced_tool_choice_unsupported:auto。依据：实测 auto 在明确要求时会调用该工具。
  • 两项只作用于 Messages 协议模型和上述上游 400；重试在任何输出之前，统计计为一次请求。重试被接受后本进程内记住该模型，后续请求直接改写；重启或改 base_url 后重新探测；重试仍失败时不记住。
  • 默认超时：timeout_seconds 默认改为 1800（grok-4.7 实测 658 秒）。已保存过设置的实例仍使用 settings.json 中的值，需手动修改；未做自动迁移，以免覆盖用户有意设置的 600。
  • 验收脚本：commandcode_live.py 的 thinking 用例改用计数题 + effort=high，新增 --thinking-off 与 --request-timeout，逐请求记录兼容调整。

本地验证（Windows Go 1.27.2 + WSL Linux）：新增 8 个 Go 单元测试覆盖重试、记住与重启遗忘、失败不记住、其他错误不重试、两项同时发生（流式）、Chat 协议不受影响和默认超时；go test -race ./...（WSL Linux）、go vet、gofmt、Node 32 项、Prettier 检查通过。cpa_round2.py 新增模拟 sonnet-5-5 拒绝的端到端用例。WSL 交叉编译的 Windows 动态库在 CPA v8.0.23 与 v8.0.59 上跑完 9 项宿主联测（含 v0.2.12 → 新库热升级），18/18 通过；新用例中 5 次客户端请求对应 2 次上游拒绝与重试，统计与 CPA 用量队列均计 5 次。真实上游复测见上节。

付费推理模型真实验收（2026-11-08，v0.2.13 正式包）

用户授权使用付费模型、预算不设上限。全部使用 v0.2.13 正式 Windows 动态库，宿主以 CPA v8.0.23 为主；凭证仍只放在仓库外的临时文件中，用后删除。账户为 GOAT 套餐，本轮最后一次请求触发 5 小时用量上限（429），随即停止付费请求。超出预期的消耗主要来自长上下文用例：填充文本实际为 57 万（Claude）／31 万（GPT）tokens，远大于预估。

可用模型

GOAT 套餐可用：claude-sonnet-5-5、claude-haiku-5-5、gpt-5.6-sol、deepseek/deepseek-v4-pro、moonshotai/Kimi-K3、zai-org/GLM-5.2、Qwen/Qwen3.7-Max、xai/grok-4.7。其余被测的 Claude 4.x／Opus／Sonnet 5、GPT-5.4/5.5/6、Gemini 等返回 403 MODEL_NOT_IN_PLAN。上游模型目录不提供思考能力字段。

思考等级是否生效

同一道计数题，流式请求，每档 2 次（model(level) 后缀经 v8.0.23 原样交给插件，插件日志 reasoning_to 与请求等级一致）：

模型 low medium high 结论
deepseek-v4-pro 推理 777／630 tokens — 4,803／4,512 等级明显生效（约 6～7 倍）
gpt-5.6-sol 449／374 498／439 509／604 随等级小幅上升（均值 412／469／557）
claude-sonnet-5-5 不思考，正文写推导 不思考 先思考后作答 等级改变是否思考；上游不报告思考 tokens，思考内容为空（仅签名）
claude-haiku-5-5 2 次中 1 次思考 — 均思考 同上

v8.0.59 上免费模型 beam:free 的复核见下方 v0.2.13 发版记录；付费模型在 v8.0.59 上未单独复测（宿主剥离后缀后注入等级，插件映射路径与 v8.0.23 相同）。

Claude 原生 Messages、图片、思考签名

  • claude-haiku-5-5：原生 Messages 非流式／流式、强制工具调用与结果回传、图片传输均通过。
  • claude-sonnet-5-5：原生 Messages、图片通过；强制工具选择不受支持，tool_choice 为 tool／any 时上游返回 400 “not supported for this model”，auto 正常调用工具。
  • 思考签名回放：两模型对需要推理的题目返回带签名（2,164／3,188 字符）的空内容思考块；原样回放后的后续请求 200（非流式与流式）；篡改签名后上游返回 400，说明签名经插件完整往返且确由上游校验。
  • tests/commandcode_live.py --thinking 对两模型均失败：用例使用“Reply only OK.”，自适应思考模型对简单问题不思考，不产生思考块；--tools 对 sonnet-5-5 失败于强制工具选择。这是验收脚本假设与新模型不符，不是插件故障，脚本待调整。
  • model(none)：插件把关闭思考映射为 thinking.type=disabled。claude-haiku-5-5 接受；claude-sonnet-5-5 的上游拒绝 disabled 并提示改用 between_tools，而 CommandCode 的请求校验又拒绝 between_tools（对所有模型均返回 “Invalid input at thinking”）。因此经 CommandCode 无法关闭 sonnet-5-5 的思考，该后缀返回 400；请求后未见凭证冷却。不传 thinking 时 sonnet-5-5／haiku-5-5 默认会思考。

超时与时延

流式请求，高等级（max_tokens 32000；长上下文用例 8000）。“首字节”为插件记录的首段上游数据时间：

用例 首字节 首个正文 最大段间间隔 总时长
sonnet-5-5 难题 14.8 s 14.8 s 0.1 s 18.3 s
haiku-5-5 难题 17.3 s 17.3 s 0.02 s 17.3 s
gpt-5.6-sol 难题 11.8 s 11.8 s 0.2 s 12.0 s
deepseek-v4-pro 难题 2.0 s 105.8 s 0.2 s 105.9 s
Kimi-K3 难题 1.6 s 94.7 s 0.4 s 94.7 s
GLM-5.2 难题 1.6 s 133.7 s 0.2 s 133.8 s
Qwen3.7-Max 难题 1.9 s 140.9 s 3.1 s 141.0 s
grok-4.7 难题 2.7 s 658.1 s 58.5 s 658.1 s
sonnet-5-5 57 万 tokens 上下文 24.6 s 24.7 s 0.05 s 25.1 s
gpt-5.6-sol 31 万 tokens 上下文 13.5 s 13.6 s 0.2 s 13.8 s
  • Claude 与 GPT 在思考期间不向客户端发送任何数据（Claude 连 message_start 都在思考结束后才到），首字节等于全部思考时间；DeepSeek／Kimi／GLM／Qwen／Grok 约 2 秒内开始流式输出推理内容。
  • grok-4.7 高等级难题用时 658 秒，超过默认 timeout_seconds: 600，在默认配置下会被整体超时截断为 504；其输出中出现过 58 秒无数据的间隔。
  • 据此，启用停滞保护时建议首字节 ≥120 秒、流空闲 ≥120 秒；长推理（尤其 grok-4.7）应把 timeout_seconds 提高到 1200～1800。两项停滞保护仍默认关闭。

count_tokens 与真实客户端

真实 Claude Code 2.1.316 以隔离配置目录接入隔离 CPA（模拟上游，不消耗额度），在 v8.0.23 与 v8.0.59 上各运行一次 -p 普通请求和 /context：每个宿主上两条命令合计发出 24 次 POST /v1/messages/count_tokens，全部收到插件本地 404，未访问上游；两条命令均以 success 结束，/v1/messages 正常 200，凭证未冷却。

控制台源码可读化（2026-11-08，未发布源码）

internal/bridge/ui/console.js、console.css 原为长行手写压缩风格（JS 266 行、最长 1,709 字符；CSS 16 行、最长 4,024 字符），改为 Prettier 3.7.4 格式化的源码（JS 1,574 行、CSS 1,854 行），配置见 .prettierrc.json。

  • 等价性：prettier --debug-check 通过；另用 acorn 独立比较语法树，除去空语句与属性键引号写法后 JS 完全一致；postcss 比较 1,428 个 CSS 节点，仅 11 处为引号、属性选择器引号和小数前导零写法差异。
  • 未加压缩步骤：格式化后两文件共增加 16,842 B，控制台页面约增 17 KB，动态库从 16,232,403 B 增至 16,249,299 B（本机未裁剪符号的构建，约 0.1%）。控制台经 CPA 管理接口在本机或内网提供且不缓存；在四平台构建（含 manylinux 容器）中加入 Node 压缩工具会让发布内容与测试源码不同并增加构建依赖，收益不足以抵消，因此按原样内嵌。
  • 测试：三个 Node 测试文件改为用 between() 按唯一标记切片，标记缺失或重复时直接失败（原先 indexOf 返回 -1 时会静默截取错误片段）。Node 31 项、Go go test ./internal/... ./cmd/... 通过；CI 测试任务新增 prettier --check。
  • 宿主与浏览器：新 Windows 动态库在实际 CPA v8.0.23 与 v8.0.59 上 18/18 通过（含以 v0.2.12 正式包为前一版本的热升级）。console_preview.py 普通场景中登录并切换五个页面，无全局错误，设置页显示首字节／流空闲超时字段；与格式化前的 v0.2.13 构建逐页截图对比（1265×712），设置页 0 像素差异，其余四页差异仅为夹具时间戳和一次登录提示气泡。

v0.2.13 发版记录与真实上游验收（2026-11-08）

用户已确认合并 PR #16 并发版，并提供真实凭证用于验收。下方“未发布源码”一节保留为当轮验证时的状态。本次未部署或访问任何服务器。

发版

  • PR #16 以 squash 合并为 dfd0af2d3f237e3b9beb0e9b9ebe54a5ca2f24ec，合并提交的源码树与 CI 全绿的分支头 791b055 一致。附注标签 v0.2.13 指向该提交。
  • 标签 CI 9 项任务全部通过，含两个 Linux 架构在 glibc 2.28 用户态内的加载与宿主联测、最新 CPA 候选 v8.0.59 联测及发布。main 推送 CI 同样通过。
  • 公开 Release 已设为 Latest，共 11 个资产。匿名下载全部资产，大小与 SHA-256 逐个匹配 GitHub 记录的 digest；scripts/checksums.py --include-cpamp --max-glibc 2.28 通过，重新生成的清单与发布的 checksums.txt 逐行一致。四平台包与独立页面包版本均为 0.2.13、来源提交均为 dfd0af2、兼容基线均为 CPA v8.0.23。
  • 发布的 Linux 包 BUILD.json：amd64 glibc_minimum 2.28／glibc_symbol_version_max 2.3.2，arm64 为 2.28／2.17，与 objdump -T 实测一致。发布的 amd64 .so 在本机 manylinux_2_28 容器（glibc 2.28）中 dlopen 成功，并以 Linux CPA v8.0.23 通过 cpa_e2e.py、cpa_count_tokens.py、cpa_thinking_suffix.py。
  • 发布的 darwin dylib 为 LC_BUILD_VERSION minos 14.0／SDK 15.5，与 v0.2.12 相同。
  • tests/cpa_store_install.py 在隔离 Windows CPA v8.0.23 与 v8.0.59 中均通过：匿名公开源发现、选择 v0.2.13 Release、校验安装、重启加载并报告 0.2.13。

真实上游验收（正式 Windows 包）

凭证仅保存在仓库外的临时文件（仅当前用户可读），验收结束后已删除；报告与运行数据中经检查不含该 key。账户套餐 individual-goat，公开目录 96 个模型。为不消耗额度，生成请求只使用目录中的免费模型 reflection/beam:free，共 10 次真实请求、约 1.7k tokens。

  • tests/commandcode_live.py 只读检查通过（身份、额度 2 个窗口、目录刷新，key 不出现在凭证列表）。
  • 同脚本 --generate --tools 在 CPA v8.0.23 上 6/6 通过：Chat／Responses 的流式与非流式、工具调用与结果回传；共 596 tokens，插件统计与 CPA 用量队列一致。
  • 思考后缀：在 v8.0.23 与 v8.0.59 上各发送 beam:free(low)、beam:free(high) 流式请求，均为 200，插件日志的 reasoning_from／reasoning_to 分别为 low／high，请求后凭证无 unavailable。上游返回的推理 tokens 为 174／231（v8.0.23）与 232／188（v8.0.59），与等级不成单调关系：插件按等级转发已确认，该免费模型是否按等级调整推理深度无法据此判断，付费推理模型未测。
  • 超时参考：上述 4 次短问答流式请求，插件记录的首字节 1.8～3.4 秒，客户端观测的最大段间间隔 0.05～0.52 秒。仅代表免费模型的短请求，不足以确定长推理或大上下文模型的合适阈值，因此两项超时保持默认关闭。
  • count_tokens 的真实客户端行为（如 Claude Code 收到 404 后的处理）仍未验证：插件对该路径不访问上游，需要真实客户端联测。

热升级与宿主冷却（模拟上游）

使用 v0.2.11 正式 Windows 包（SHA-256 与包内清单一致）与 v0.2.13 正式包，在同一 CPA 进程内复现：

  • CPA v8.0.23：v0.2.11 下 cool-model(high) 返回 404，随后不带后缀的请求返回 503，凭证显示 unavailable、约 12 小时后重试。热升级到 v0.2.13 后凭证显示恢复 active，但带与不带后缀的请求仍返回 503 auth_unavailable（错误信息保留升级前的上游错误）；重启 CPA 后立即恢复 200。结论：插件热升级不清除宿主已记录的模型冷却，需要重启 CPA。已写入 DEPLOYMENT 与发布说明。
  • CPA v8.0.59：宿主剥离后缀，v0.2.11 下后缀请求即为 200，不产生冷却；升级前后均为 200。

v0.2.13 glibc 下限、写盘节流与卡顿超时（2026-11-07，未发布源码）

本轮只使用本地模拟上游，未进行真实模型生成，未访问或修改任何部署服务器。CPA 发布门槛仍为 v8.0.23；compatibility.json 未改动。包含 PR #14（Antigravity 额度回归纳入发布门槛）与 PR #16。

glibc 下限

  • v0.2.12 的 Linux 动态库在 runner 自带的 glibc 上构建：amd64 与 arm64 发布包 objdump -T 的最高符号版本均为 GLIBC_2.34（另含 2.32），而固定的 CPA v8.0.23 Linux 版本身只需 glibc 2.3.2，因此插件把 CPA 原本支持的 glibc 2.28–2.33 主机（如 RHEL/AlmaLinux 8、Debian 11）挡在外面。
  • Linux 改在按 digest 固定的 manylinux_2_28 镜像（2026.11.06-1）中构建。新库 amd64 最高符号版本为 GLIBC_2.3.2，arm64 为 GLIBC_2.17；构建步骤在超过 2.28 时失败，BUILD.json 记录 glibc_minimum: "2.28" 与实际 glibc_symbol_version_max，checksums.py --max-glibc 2.28 在两处发布校验中拒绝超标的包（test_cpamp_panel_validation.py 新增拒绝用例）。
  • 本机 manylinux_2_28 容器（glibc 2.28）中运行 Linux CPA v8.0.23：v0.2.12 动态库 dlopen 失败（缺 GLIBC_2.34），新库加载成功，并通过 cpa_e2e.py、cpa_count_tokens.py、cpa_thinking_suffix.py。CI 新增 “Load and run on glibc 2.28” 步骤，amd64 与 arm64 各在 glibc 2.28 用户态内完整运行上述三项；rebase 前 PR #16 的 CI（run 42362813526、42371142936）全部通过。

写盘节流

本机合成测量（90 天 × 2 模型的用量桶，共 21,768 个）：

  • 用量数据缩进 JSON 为 9,823,672 B，改为紧凑 JSON 后为 7,450,959 B，单次编码约 24 ms。
  • 持续请求时，旧逻辑每次变更都重写整个文件，折合约 39.29 MB/s；新逻辑按文件大小把重写间隔限制在 250 ms～10 s（按 1 MiB/s 折算），该规模下间隔约 7.1 s、约 1.05 MB/s，约降为 1/37.5。
  • 1,000 条最近请求记录从 988,002 B 降为 788,001 B，持续写入从约 3.92 MB/s 降为约 1.05 MB/s。
  • 插件关闭时仍强制立即写出全部待写文件（flushRuntimeFiles(true)），写入仍为原子替换；热升级联测确认记账数据在升级后保留。persistence_rate_test.go 覆盖间隔计算、大文件节流与紧凑 JSON。

首字节与流空闲超时

  • 新增 first_byte_timeout_seconds 与 stream_idle_timeout_seconds，默认 0（关闭，保持旧行为），启用时取值 5～1800 秒；超时分别以 504 upstream_first_byte_timeout／upstream_stream_idle_timeout 结束并记入失败计数。
  • upstream_timeouts_test.go 5 项通过。cpa_reliability.py 新增“上游先回首字节后停止输出”的故障用例：使用 v0.2.12 动态库时因新设置被拒绝（400）而失败，使用新库通过。
  • 浏览器实测设置页可保存两个字段并回读 90／120；config.example.yaml 已补充说明。

自动化与宿主联测

  • Windows Go 1.26 go vet ./internal/... ./cmd/...、gofmt -l 与 go test ./internal/... ./cmd/... -count=1 通过；Node 31 项通过；test_cpamp_panel_validation.py 在 WSL 下 6 项通过。
  • Windows amd64 动态库（版本 0.2.13，WSL 交叉编译，晚于最后一次源码修改）在实际 Windows CPA v8.0.23 与 v8.0.59 上各运行 9 项，共 18/18 通过：cpa_e2e.py、cpa_native_management.py、cpa_reliability.py、cpa_diagnostics.py、cpa_round2.py、cpa_count_tokens.py、cpa_thinking_suffix.py、cpa_hot_reload.py，以及以 v0.2.12 正式 Windows 包为前一版本的 cpa_hot_reload.py --previous-archive（同一 CPA 进程内 0.2.12 → 0.2.13）。CI 热升级联测的前一版本同步改为 v0.2.12。

待验证

  • 真实上游下两项超时的合适取值（默认关闭）、思考后缀等级效果与 count_tokens 客户端行为；插件热升级是否清除宿主已记录的冷却。——发版后已部分验证，见上方发版记录。
  • 真实 RHEL/AlmaLinux 8 等 glibc 2.28 主机上的部署（目前仅容器与 CI 验证）。

v0.2.12 发版记录（2026-11-07）

用户已确认合并 PR #15 并发版。下方“未发布源码”一节保留为当轮验证时的状态；真实上游验收仍未完成，本次未部署或访问任何服务器。

  • PR #15 以 squash 合并为 257b070cecdb5cc3819591942aac15280600cf9c，合并提交的源码树与 CI 全绿的分支头 ab3d07e 一致。附注标签 v0.2.12 指向该提交。
  • 标签 CI 9 项任务全部通过：CPA v8.0.23 基线、四平台构建与宿主联测（含新增 count_tokens／思考后缀联测，macOS 在 macos-15 构建）、CPAMP、最新 CPA 候选 v8.0.59 全套 8 项联测、统一校验及发布。main 推送 CI 同样通过。
  • 公开 Release 已设为 Latest，共 11 个资产。匿名下载全部资产，大小与 SHA-256 逐个匹配 GitHub 记录的 digest；scripts/checksums.py --include-cpamp 通过，重新生成的清单与发布的 checksums.txt 逐行一致（Windows 本地写入为 CRLF，仅按行比较）。四平台包与独立页面包版本均为 0.2.12、来源提交均为 257b070、兼容基线均为 CPA v8.0.23，内嵌页面摘要一致。
  • 发布的 darwin dylib 为 LC_BUILD_VERSION minos 14.0／SDK 15.5，最低系统与 v0.2.11 相同。
  • main 的 registry.json 已为 0.2.12。tests/cpa_store_install.py 在隔离 Windows CPA v8.0.23 与 v8.0.59 中均通过：匿名公开源发现、选择 v0.2.12 Release、校验安装、重启加载并报告 0.2.12。
  • 仍待验证：真实上游下的思考后缀等级效果与 count_tokens 客户端行为；插件热升级是否清除宿主已记录的冷却。

v0.2.12 CPA 兼容修复（2026-11-07，未发布源码）

本轮只使用本地模拟上游，未进行真实模型生成，未访问或修改任何部署服务器。CPA 发布门槛仍为 v8.0.23；compatibility.json 未改动。

问题复现

  • count_tokens：v0.2.11 对 /v1/messages/count_tokens 返回 501。在 Windows CPA v8.0.23 上复现：宿主把 501 当作凭证故障冷却凭证，随后同模型的 /v1/messages 返回 503 auth_unavailable（CLIProxyAPI #7271，上游修复 1c53721）。
  • 思考后缀：v8.0.23 把 mock-chat(high) 原样交给插件，v0.2.11 返回 404，宿主随即把凭证标为 unavailable，未带后缀的同模型请求也变为 503。实测约 12 小时后宿主才重试；重启 CPA 立即恢复。插件热升级本身是否清除宿主已记录的冷却未验证。
  • v8.0.59（上游 c9af529）由宿主剥离后缀，但 v0.2.11 以原始请求体重建原生 Messages 请求时丢失后缀等级；宿主注入的 reasoning_effort=auto 在 Chat 模型上原样发往上游，在 Anthropic 模型上返回 400 unsupported Anthropic reasoning effort。
  • 新增 tests/cpa_thinking_suffix.py 使用修复前动态库在 v8.0.23 与 v8.0.59 上均失败，确认该测试能识别上述问题。

自动化与宿主联测

  • Windows Go 1.26 go vet ./internal/... ./cmd/...、gofmt -l 与 go test ./internal/... ./cmd/... -count=1 通过，包括新增的 count_tokens 与思考后缀单元测试；Node 31 项通过；test_cpamp_panel_validation.py 在 WSL Python 3.10 下 6 项通过（Windows 商店版 Python 的 python.exe 无法被 shutil.copyfile 读取，该用例在本机 Windows 上属于环境错误，非代码失败）。
  • Windows amd64 动态库（WSL 交叉编译，晚于最后一次源码修改）在实际 Windows CPA v8.0.23 与 v8.0.59 上各运行 9 项，共 18/18 通过：cpa_e2e.py（25 个请求）、cpa_native_management.py、cpa_reliability.py、cpa_diagnostics.py、cpa_round2.py（13 次模拟请求，真实请求 0）、cpa_count_tokens.py（两类模型各 3 轮 count_tokens 均为 404、随后 Messages 均为 200）、cpa_thinking_suffix.py（Chat／Responses／原生 Messages、流式与请求体覆盖，事后无冷却）、cpa_hot_reload.py，以及以 v0.2.11 正式 Windows 包（SHA-256 与发布 checksums 一致）为前一版本的 cpa_hot_reload.py --previous-archive，确认同一 CPA 进程内 0.2.11 → 0.2.12 热升级。
  • tests/cpa_store_install.py 在隔离 Windows CPA v8.0.59 中通过：匿名公开源发现、Release 选包、校验安装、重启加载。当时 main 的 registry.json 仍为 0.2.11，因此该次按 0.2.11 断言，验证的是 v8.0.59 宿主的商店安装路径，不代表 v0.2.12 资产已发布。

CI 变更

  • GitHub 已于 2026-11-02 停用 macos-14 runner；PR #14 的 macOS 任务即因 The configuration 'macos-14-arm64-us-default' is not supported 被取消。darwin-arm64 改用 macos-15，并以 MACOSX_DEPLOYMENT_TARGET=14.0 保持与 v0.2.11 相同的最低系统（v0.2.11 发布包 dylib 的 LC_BUILD_VERSION 为 minos 14.0／SDK 14.5），构建后用 otool -l 校验。macOS 构建只能在 CI 验证，本机未运行。
  • 新增每周定时运行；最新 CPA 候选任务加跑原生管理、第二轮协议、count_tokens、思考后缀与热重载，定时运行时候选失败会使工作流失败。热升级联测的前一版本改为 v0.2.11。
  • PR #15 首次 CI 中，候选任务（v8.0.59）的 e2e／可靠性／诊断通过，cpa_native_management.py 因该任务未构建本地 OAuth 辅助程序 dist/commandcodebridge-login 而报 FileNotFoundError（测试环境缺失，非插件行为）。已在候选任务中构建该程序，并改为逐项运行全部联测、汇总失败后再退出，避免前一项失败掩盖后续结果。

待验证

  • 四平台 CI（尤其 macos-15 与 Linux ARM64 上的新增联测）——已在 PR 与标签 CI 中通过，见上方发版记录。
  • 真实上游下的思考后缀等级效果与 count_tokens 客户端行为。

v0.2.10 发版记录（2026-10-18）

用户已授权合并 PR #12 并发版。发布任务新增标签与源码版本、同一来源提交、四平台及 CPAMP 页面一致性检查；仅在协议测试、构建和校验通过后发布 11 个资产。实际发布状态以 Release 和对应标签 CI 为准。下方“未发布”描述保留为当轮验证时的历史状态，不代表真实上游验收已经完成。本次不部署目标服务。

  • PR #12 已合并，标签 v0.2.10 指向 71ce1a11bf8bf6491e5acf1786bc481a1969adcd。标签 CI 的 9 项任务全部通过，包括 CPA v8.0.23、四平台宿主联测、CPAMP、候选兼容、统一校验及发布。
  • 公开 Release 已设为 Latest。匿名下载全部 11 个资产，逐个匹配 GitHub SHA-256；再运行 scripts/checksums.py --include-cpamp，四平台与独立页面包版本、来源提交、兼容基线及内嵌页面摘要一致。统一清单内容核验通过（Windows 本地重写产生的 CRLF 仅按行比较，保留下载原件）。
  • registry.json 更新至 0.2.10，安装与升级文档同步；真实上游、身份共享、实际 200% zoom 与登录后官网参照仍待验证，未部署目标服务。

第三轮：Studio 风格五页与交互优化（2026-10-18，v0.2.10 未发布源码）

  • 按已核实的 CommandCode 公开概览／详情截图及当前登录页调整导航、字阶、中性按钮、近直角区域和明暗主题；凭据诊断折叠，模型加入组合搜索／筛选及手机列表，模型／日志统一右侧详情，设置按任务分区。完整来源、差异及精选图片见 第三轮核对。系统字体回退，无远程字体依赖，不声称加载了 Geist 或逐像素复刻当前登录后的 Studio。
  • Node 31 项通过，保留管理鉴权、证据来源／转义／延迟隔离，增加模型原索引筛选、白名单长错误、日志失败缓存、可见触发按钮焦点恢复、关闭窗口不抢新 modal 焦点、目录与测试的身份隔离、确认窗口外部关闭取消、待写／恢复结构化渲染。
  • Windows Go 1.26 go test ./internal/... ./cmd/... -count=1 与 go vet ./internal/... ./cmd/... 通过；最终 Windows amd64 动态库编译通过。实际 Windows CPA 8.0.23 加载本轮 UI，cpa_diagnostics.py 与 cpa_round2.py 通过；后者模拟端走完有上限的 13 次协议／工具／图片传输／thinking 重放／ZDR 请求头检查，真实请求为 0。最终 UI 另验证退出清空日志、详情、目录与测试输出及重新登录。
  • 五页 × 1280×900／390×844 × 明暗主题，共 20 组／40 张 before／after。最终 after 已重采，CSS 视口、编码像素、源码／动态库 SHA-256、图像哈希及最终根宽度记录在 截图清单。六张精选随仓库，其余本机 dist/round3/ 为忽略产物。20 个最终视图根无横向溢出。
  • 浏览器另验 375px／1440px、Tab／Shift+Tab 循环、Esc／返回焦点、嵌套编辑取消、空数据／单凭据／20 凭据与 100 长模型名、导入及模拟直测。实际损坏统计文件后显示检查点恢复缺口；旧额度保持原始采集时间，未知 cap 不画比例，8400 字符错误转义且不溢出。持续待写由 Node 渲染用例覆盖，未宣称浏览器已注入该故障。插件 console errors 0。
  • CSS 变量对比度计算：普通正文最低 4.80:1，状态正文最低 4.93:1，必要控件边界最低 4.12:1；保留减少动态效果规则。640×450 等效 200% CSS 重排五页无溢出；实际浏览器 200% zoom 未验证，当前浏览器能力与快捷键未成功改变缩放。
  • CPAMP 未改源码／面板；使用 dbf61dd 实际 Windows 宿主核对原生额度、停用状态、最近请求、授权入口及五页 iframe。未勾记住凭证时未自动复用宿主登录，单独 Bearer 管理认证通过，已修正认证方式标签。没有点击真实官网授权。没有把本轮未重跑的 CPAMP 前端组件／生产构建记录为已通过。
  • 真实 Claude／图片语义／thinking／ZDR／身份共享继续待验证；v0.2.10 未发布、未部署。 当前登录后的官网参照和实际 200% zoom 是单列的后续证据缺口。

第二轮：本地实现与模拟验收（2026-10-18，v0.2.10 未发布源码）

用户明确选择：先完成本地实现，真实验收标为待验证。 第二轮没有调用真实模型，没有发布／部署；第三轮 UI 后续交付见本文顶部。

交付与故障边界

  • GET /models/evidence?credential_id=... 和模型页选择器：模型观察绑定密钥／更新时间、代理、上游、ZDR、账户及完整模型配置。插件直测、CPA 请求分别展示；24 小时过期，旧无作用域记录不充当新证据；证据随保留日志截断而丢失。普通 403 不推断套餐拒绝，仅明确 MODEL_NOT_IN_PLAN 标为不在套餐，429 为临时限流，局部失败不使整张凭证失效。
  • 日志新增客户端／上游协议及 ZDR 请求标记。实际 CPA 会把 SourceFormat 改为翻译后的插件输入，因此优先使用原始 request_path 识别 Responses；本地 13 请求验收对照了该字段。
  • 独立变更标记保留 250ms 批量写入；额度更新只写 usage.json。每分钟检查点、格式清单、单文件损坏隔离与恢复警告；无检查点只重建该观察文件，设置／未知格式仍失败。缺失主文件可恢复检查点，部分 JSON 解码不会污染恢复值。
  • 分层统计保持累计总量，近期分钟／历史 UTC 日；默认不删除日总量，非零保留天数需明确确认。查询重叠整日时返回精度提示。首次迁移、清空均保留副本；清空前检查点被移走，关闭刷盘与 epoch 回归保留。
  • 采样保留缓存、错误退避、请求合并和 3 并发，周期增加 0–20% 正抖动。真实个人／组织与同账号多 key 身份未核实，因此没有跨凭据合并查询。

自动化与实际 CPA 宿主

  • Windows Go 1.26 本地测试／vet、WSL Linux race／vet 通过；Linux amd64 .so 和 Windows amd64 .dll 构建通过。新增作用域、过期、403／429 分类、恢复／损坏／设置拒绝、缺失主文件、独立写入、检查点节流、清空失败和迁移副本回归。
  • Node 管理登录／诊断／模型证据共 19 项通过：切换凭据和身份的较晚响应被丢弃、转义、来源区分、模型 403 不退出管理登录。Python／JavaScript 语法检查通过。
  • Windows CPA 8.0.23 实际加载动态库运行 tests/cpa_round2.py：明确套餐拒绝、普通 403、429 再试恢复、单模型不污染凭据、多凭据隔离、换 key／换映射失效、重启恢复；损坏请求文件隔离并恢复检查点、缺检查点的额度文件单独重建、清空统计后重启不回流。
  • 扩展后的真实验收脚本本身在 loopback 模拟端走完 13 次 Chat／Responses／Messages 流与非流、双协议工具往返、Messages 图片传输、thinking 签名返回／重放；逐条实际响应、插件统计、CPA usage queue 的 token 对账通过，模拟端实际收到 13 个 X-Cmd-Zdr: 1 请求头。
  • 原有 cpa_e2e.py 的 25 次协议模拟调用、cpa_reliability.py 异常／取消／超时／重启／用量对账，以及第一轮 cpa_diagnostics.py 均继续通过。

浏览器验证

实际访问动态库内嵌控制台，使用两张虚构本地凭据。1280px 桌面及 375／390px 手机、明暗主题已验证：凭据证据隔离、模型 403 错误留在测试窗口且保持管理登录、保留天数确认／取消、默认永久保留保存、刷盘状态、退出登录清空模型证据。新增证据列最初在窄屏被挤成逐字竖排，已修正为可聚焦、带提示的横向滚动表格；页面整体宽度与视口一致，证据和操作列可横向查看，浏览器运行错误 0。

截图位于本机忽略目录 dist/round2/screenshots/：models-desktop.png、models-mobile-390-dark.png、models-mobile-dark.png、settings-desktop.png、settings-mobile-light.png。仅包含虚构测试数据；临时浏览器与服务已清理。旧版纯额度刷盘会把空日志序列化为 null，已增加兼容回归，不把它误报为历史损坏。

本机合成测量

同一次 Windows Go 运行，90 天 × 2 模型 × 每分钟一条请求；固定 259,200 请求、每条 100 输入／20 输出 tokens。只对统计内存结构进行压缩前后对照，不调用上游。测量前两次 GC 排除上次 JSON 缓冲池暂留；不是生产负载与整进程内存承诺。

指标 压缩前 压缩后
统计桶 259,200 21,768
JSON 字节 77,241,601 6,492,669
序列化耗时 473.612ms 43.071ms
JSON 解码耗时 883.126ms 100.392ms
40 次统计查询 P95 90.065ms 5.033ms
GC 后 Go HeapAlloc 66,310,272B 5,730,944B
累计请求数 259,200 259,200

压缩耗时 129.314ms；JSON 缩减约 91.6%。这是可重复合成结构测量，解码耗时不是完整 CPA 启动时间。运行：BRIDGE_MEASURE=1 go test ./internal/bridge -run TestRuntimeScaleMeasurement -v -count=1。

原生 CPA + 固定模拟 SSE、每轮 32 请求、1,000 条日志缓冲的短样本对照：

并发 第一轮 requests/s / P95 第二轮 requests/s / P95
1 14.09 / 71.85ms 14.41 / 84.68ms
8 100.67 / 91.57ms 104.99 / 76.43ms

两轮均使用同机 Windows CPA v8.0.23 与相同夹具。样本小、有模拟分片等待，单并发 P95 本次变慢，多并发本次变快，不能据此宣称吞吐优化或真实推理变快。分类写入由确定性测试核实：一次纯额度变更，原逻辑写三文件，当前只写一个；检查点首次写入会额外写一次，后续一分钟内不重复刷新。无新增 SQLite／WAL 依赖。

待真实验证

组合 本轮状态
Claude Messages 流／非流、工具往返 模拟通过；真实待验证
图片语义理解 本地只验证传输；真实待验证
thinking 签名返回／重放 模拟通过；真实模型／权限待验证
ZDR 参数正确发送 模拟端实际请求头已验证
ZDR 上游接受／服务端保留策略 真实待验证／策略需官方依据
个人／组织身份、同账号多 key 额度与冷却归属 真实待验证；当前不合并采样

脚本支持无网络 --dry-run、最多 20 次请求／每次 8192 输出 tokens、仓库外凭据、脱敏报告和 token 对账；默认不生成。报告不含原始响应、thinking 签名或账户 ID。请求数和输出 token 上限不能直接等同费用金额。

v0.2.10 第一轮：登记诊断与升级兼容（2026-10-18，未发布源码）

实现与自动化

  • 新增 /diagnostics、/diagnostics/summary 和 /compatibility 管理接口；默认只读，不发模型生成或写入探测快照。凭证保存单独返回 saved 与 registration，会话重新分配返回 host_confirmed。
  • Go 回归覆盖正常／缺失／重复／旧 routing ID、启停未同步、变更待加载、宿主查询失败、文件回退未知、脱敏摘要及三类证据。CPA 的 live 文件登记也使用 source=file，以 auth_index 和运行 ID 区分磁盘回退；相同内容再次保存不使确认永久等待。
  • Windows Go 1.26.0 全部 ./internal/... ./cmd/... 测试、vet 通过；最终源码在 WSL Linux 通过 go test -race ./internal/... ./cmd/... -count=1 和 vet，Linux amd64 .so、Windows amd64 .dll 构建通过。
  • Node 15 项管理登录与诊断回归通过，覆盖输出转义、较晚响应不能覆盖新结果、切换身份／退出登录后丢弃旧结果、401 拒绝立即清理诊断；JavaScript／Python 语法及 git diff --check 通过。
  • 兼容检查覆盖匹配／旧页面、支持／旧／明确不支持／类型错误的后端声明；远程目标与 HTTP 重定向不探测，不转发管理密钥。页面、后端和浏览器缓存分别报告，缺少依据时保持未知。
  • CPAMP dbf61dd 适配重复应用及 --check 通过；TypeScript 检查、生产单文件构建、五个相关前端文件共 40 项通过。最终 Manager 后端 go test ./internal/service/quotasnapshot ./internal/http/controller/health -run TestCommandCode -count=1 通过，覆盖名单变更与 GET 能力／POST 405。

隔离宿主与浏览器

  • Windows CPA v8.0.23 使用最终动态库通过 tests/cpa_diagnostics.py：保存、三类证据隔离、停用／启用、会话重新分配、相同内容保存、重启、脱敏摘要；移除临时夹具文件后插件仍保留凭证、宿主登记缺失，客户端返回 503 且插件无新增执行日志，恢复文件后登记和请求恢复。
  • 最终 tests/cpa_hot_reload.py 验证 0.2.9 → 0.2.10 同进程热升级、配置即时生效／无效配置回滚，凭证、模型、记账与请求继续保留。此轮原生协议 25 次模拟请求、异常恢复、OAuth 接收器及页面安装／备份／幂等套件亦通过；均使用本机隔离目录和虚构凭证。
  • 浏览器访问最终动态库实际内嵌控制台：诊断／兼容重试、三类来源说明、脱敏摘要复制、插件直测范围提示、退出登录清除诊断通过。1280px 桌面及 375／390px 手机、明暗主题检查未见横向溢出或运行错误（console errors 0）。
  • 截图保存在本机忽略目录 dist/round1/screenshots/：credentials-desktop.jpg、compatibility-desktop.jpg、compatibility-mobile-light.jpg、credentials-mobile-dark.jpg、compatibility-mobile-dark.jpg；是虚构测试数据，不是目标部署。

发布与证据边界

  • 安装包清单增加共享兼容基线；临时四平台清单夹具验证一致基线通过、缺失或不一致基线被拒绝，未生成发行包。CI 保留固定 v8.0.23 门槛，新增不阻断发布的较新 CPA 候选兼容报告。该工作流尚未在远端运行，本轮不声称最新 CPA 或四平台发行验证通过。
  • 本地 CPAMP 使用已有源码归档与依赖完成测试和页面构建，页面手动嵌入用于联测；嵌套源码归档不能作为发行来源证明，正式打包需要独立上游 Git checkout、来源提交及统一校验。
  • v0.2.10 未发布、未更新 registry、未部署目标服务；本轮没有真实模型请求。已有真实免费模型／账户结果见历史章节，不代表 Claude、图片、ZDR 等真实验收已完成。
  • 第三轮已在 NEXT_STEPS.md 明确安排：继续参照 CommandCode 官网控制台的美术风格和页面设计，另做逐页面视觉对照与响应式验收。

v0.2.9 最近请求同步与额度持久化修复（2026-10-13）

  • 服务端将额度观察与账户标识哈希写入 data_dir/usage.json，复用异步原子落盘和关闭前最终刷新；重启后按密钥／代理／上游指纹恢复。管理接口返回脱敏额度和每个凭证最近十次实际请求，排除本地冷却跳过与旧密钥记录。
  • 前端打开凭证工作区时恢复服务端缓存，页面可见时每 30 秒同步最近请求与额度，切回页面立即同步。文件更新时间变化保留额度；管理连接、凭证索引与服务端密钥版本隔离旧数据。刷新失败保留原始采集时间，读到同一旧快照不会清除失败状态。
  • Go 1.26.0：Windows 全部项目测试和 go vet 通过；WSL Linux 的 go test -race ./internal/... ./cmd/... -count=1、go vet ./internal/... ./cmd/... 通过。新增重启恢复、密钥替换、超过 24 小时的最近记录、本地跳过排除与手动刷新错误退避回归。
  • CPAMP 七个相关测试文件共 121 项通过，覆盖页面重载、30 秒轮询及卸载清理、最近请求更新、网络失败保留、管理登录隔离、密钥更换、原始观察时间与旧快照失败标记；TypeScript 检查和单文件生产构建通过。适配脚本重复应用与兼容检查通过。
  • 已生成并内嵌匹配的新页面，Linux amd64 动态库构建通过；发行 CI 另验证四平台原生宿主、0.2.8 → 0.2.9 热升级和统一校验。生效需同步更新插件动态库和 CPAMP 页面，并持久化插件 data_dir；本轮发布不自动部署目标服务。

CPAMP 月额度与套餐显示修正（2026-10-13，当前源码）

  • 按用户提供的官方 Pricing & Limits 核实当前 Go 10、GOAT 70、Pro 80、Max 10× 150、Max 20× 300 credits。对照官方 npm command-code@1.81.0 的 getPlanTotalCredits：individual-pro 是旧版 30，individual-pro-v1 为新版 80；individual-max 为 150，individual-ultra 为 300。显示名统一为 Go、GOAT、Pro、Max，计算保留原始 ID，真实上游月 cap／比例优先。
  • 月百分比仅使用 monthly_credits，购买／免费 credits 不混入；列表、详情、状态汇总和周期快照共享规则。实际 GOAT 月余额 61.0826068507 显示 61.083 / 70 credits、剩余 87%。
  • 两个相关前端测试文件共 15 项通过，覆盖各套餐、旧 Pro、新 Pro、Max 两档、真实 cap 优先、缺失余额、部分失败和原生历史／快照；TypeScript 检查与单文件生产构建通过。
  • Chromium 连接实际接口和部署后页面，验证表格／卡片的月额度标题及进度条与 5h 高度相同、中间边框为 0；390px 深色卡片不溢出。额度详情和概览均显示 87%，月历史采用真实 10/02–11/02 订阅周期，历史与快照读写返回 200，浏览器 runtime errors 为 0。
  • 已备份并原子热替换现有外部页面，Manager Server PID 保持不变；公网根路径重定向到 /management.html，页面校验值与本地一致：cabcf28c8191c45d6b3f30ac5b2a03b6eabb924c1fe589e409f8103792c42928。本次未发付费模型请求。
  • 上述为发布前的页面现场验证。v0.2.8 发行构建从当前适配源码生成并内嵌页面；旧 v0.2.7 包内仍是旧页面，应升级插件后再使用「更新原生面板」。

v0.2.5 CPAMP 二进制面板一键安装（2026-10-12）

  • 核对上游 bin/install-cpamp.sh：官方默认安装目录为 ${HOME}/cpa-manager-plus，活动 runtime 标记写入 run.sh，配置位于 runtime 二进制目录；直接运行原生包由程序默认读取二进制旁 config.json。
  • 插件内置 gzip 压缩的同版本 CPAMP 页面，添加目录/配置/页面路径配置项、控制台安装和检查按钮。Linux 优先探测实际进程及必要的路径环境；否则查默认目录与活动 runtime，多实例不猜测选择。
  • Go race/vet 与安装回归通过：修改路径持久化、配置其他字段保留、原文件私有备份、幂等重复安装、非法路径/符号链接拒绝、并发修改拒绝、写入失败回滚、实际 HTTP 内容检查。
  • 本地真实 CPA v8.0.23 与官方 CPAMP v1.14.0 Linux 二进制隔离联测通过：运行实例探测、内置页面安装、配置备份、首次重启后 HTTP 字节一致，已有 PANEL_PATH 的文件替换可立即生效。使用虚构密钥，不访问目标服务的私有数据。
  • CI 先构建 pinned CPAMP 页面，再嵌入四平台插件；统一校验要求所有原生包的内置页面摘要与独立前端包一致，并随原生包附 CPAMP 许可证。

v0.2.4 官方 POST 回调和二进制面板部署修正（2026-10-11）

  • 重新核对官方 CLI 1.79.2 的 handleBrowserCallback / handleLegacyJsonCallback：mode=redirect 使用表单 POST，legacy 使用 JSON POST；凭证不在地址栏中。v0.2.3 的纯 URL 复制方案基于错误假设，先前模拟 URL 通过不能证明官网流程可用。
  • 新增浏览器电脑本地接收器，监听 127.0.0.1:45879，接收官方表单/JSON POST，再生成供 CPAMP 管理 POST 提交的复制结果。表单完成页 303 跳转只带 state；结果不写日志或文件，十分钟后清除，进程最多运行十五分钟。
  • 本地 Go race/vet 通过；接收器覆盖表单/JSON、CORS/PNA、state/有效期/重复字段/重放、拒绝、DNS rebinding 和裸 GET。真实 Linux CPA v8.0.23 验证「官方表单格式 → 实际本地接收器 → 受保护管理接口 → CPA 凭证保存及重启恢复」，使用虚构凭证和本地上游。
  • CPAMP 五个相关测试文件共 27 项通过，类型检查及单文件生产构建通过；原生卡片显示接收器说明、「认证结果」输入框和「打开本地接收器」入口。额度组件和真实字段规则保持原有实现。
  • 只读检查目标 https://cpa.gdp.pw/management.html，仍缺少原生额度与回调标记。用户确认 Manager Server 直接运行二进制；补充启动环境 PANEL_PATH、文件权限、内置页面回退行为与实际 HTTP 内容检查脚本。
  • 发布产物包含四平台接收器与页面检查脚本，CI 在四平台运行本地接收器到 CPA 的联测并验证包内校验。真实官网登录与目标面板安装仍由用户现场验收，未修改目标服务。

v0.2.2 原生认证与额度适配（2026-10-11）

  • Linux amd64 的真实 CPA v8.0.23 加载插件：commandcode-auth-url 成功、pending 轮询、受保护手动完成、官方 redirect 形状回调、CPA 保存 auth-dir、重启加载均通过；未使用真实账号或付费请求。
  • /quota/providers 正确发现 CommandCode；/quota/fetch 返回套餐、45 credits 总余额、40 credits 月余额、10 credits 本期月用量、5 小时 60% 和周 70% 余量。上游未提供月 cap 时不产生月百分比。
  • Go race / vet、原有 25 次原生协议生成、异常恢复套件通过；新增登录有效期、state 重放、拒绝、无效 key 脱敏、公开地址、额度失败/部分失败与未知字段回归。
  • 11 项浏览器管理登录存储测试通过，新增登录页脚本语法检查通过。
  • CPAMP 源码基线 dbf61ddf438f399558722df3467355c42af9005d 的原生卡片、列表与详情页补丁已完成 TypeScript 类型检查、生产单文件构建；11 项卡片、OAuth URL 及原有详情/API 回归测试通过。
  • 浏览器登录隔离 CPA 面板，实测原生列表刷新返回 pro、45/40 credits、5 小时 60%、周 70%、真实重置日期和「月上限未知」；切换卡片视图复用本次观察。修正列表刷新按钮嵌入详情触发按钮的问题。详情额度组件已通过测试；浏览器连接恢复被安全策略拦截，未完成详情页截图验证。
  • 发布前复核已修复 Windows CI 原生测试退出码未检查，以及套餐名缺失时缓存套餐被发布为新观察的问题；补充缺少 planId 的上游回归。四个平台和面板的发布构建由 GitHub Actions 执行，统一校验五个安装包及来源提交。
  • 此轮未部署目标 CPAMP，未完成真实 CommandCode 网站授权。当前 CPAMP 需要前端补丁才能显示插件额度，不能把 CPA 额度接口已实现等同于线上面板已更新。

工作台布局二次调整（2026-10-11）

  • 参考指定官方用量页公开的工作台组件、CSS 变量和 SVG 图标；未认证访问返回登录页，未读取用户的官方账户数据。
  • Chromium 使用当前源码内嵌的 HTML/CSS/JS 与本地虚构 API 数据，验证登录/刷新恢复、健康度、月额度、账号切换/编辑/停用状态、日志展开/搜索/筛选、主题、模型别名/导入、设置保存和自定义统计时间。
  • 5 个页面在 11 种宽度（375–1440px）完成 55 组检查，页面无横向溢出或脚本错误；桌面侧栏收起、手机导航抽屉及 Escape 关闭通过。
  • node --check internal/bridge/ui/console.js、10 个登录适配测试通过；查看明暗主题、概览、用量、日志和手机截图后调整数字排版。
  • 本轮仅调整 UI 资源。本机 WSL 调用无响应，已取消本轮动态库重编译；下节原生宿主与 Go 验证结果属于上一轮功能实现，不代表本次布局已重新完成原生宿主联测。

管理界面验证（2026-10-11）

  • Go 竞态测试与 go vet 通过；新增健康状态、同账号模型冷却、旧密钥记录隔离、默认别名和月度字段解析回归场景。
  • 10 个 CPA/CPAMP 登录适配测试通过，控制台脚本语法检查通过。
  • WSL Linux amd64 的 CPA v8.0.23 加载本轮本地动态库，完成 25 次模拟成功请求及 401/403 场景；确认新别名、真实字段月消耗、健康状态及内嵌 CSS/JS/SVG 资源。
  • 异常恢复套件通过：429/别名/同账号冷却、503 换号、SSE 中断、超时、取消、重启持久化和记账。
  • Chromium 验证控制台登录、3 类凭证状态、月额度显示、日志展开与失败筛选、官方图标、别名自动填写/自定义保留、明暗主题及 390px 手机布局，无脚本错误或页面横向溢出。
  • 新增月窗口与健康度的本轮运行使用虚构 key 和本地模拟上游；真实账户字段参考此前脱敏响应，未进行付费生成。

源码基线

  • 2026-10-11 创建私有仓库 Gaoshou101/CommandCodeBridge。
  • 初始提交：9a43db5，版本 0.1.0，C ABI 1 / RPC schema 6。
  • 基线通过 Go 竞态检查、go vet、10 个登录适配测试，以及 Linux/Windows CPA v8.0.23 的 25 次成功模拟请求和 401/403 场景。
  • 初次 GitHub Actions：运行 38102314575 全部成功，完成 Linux amd64/arm64、Windows amd64、macOS arm64 构建。此轮 ARM64/macOS 只构建，尚未在该轮运行宿主联测。
  • 后续 CI 38103638587 全部成功：Go 竞态检查、go vet、10 个登录测试，及 Linux amd64/arm64、Windows amd64、macOS arm64 的 CPA v8.0.23 原生宿主集成与异常恢复测试。四个平台均已完成实际宿主加载与调用。
  • 四平台 ZIP 的 SHA256、BUILD.json 动态库校验、干净构建状态及来源提交已核验；此轮两个 Linux 包的 glibc 最低要求均为 2.34。正式发布使用主分支 CI 产物，并再次核对版本及来源提交。

真实账户

  • 只读身份、余额、套餐、5 小时/周窗口、到期时间及请求数已验证；公开模型目录返回 87 个模型。
  • 真实用量汇总字段为 totalCount。插件已修正，并兼容较旧的 totalRequests；匿名字段样本位于 internal/bridge/testdata/account-summary.json。
  • 当前验证账户套餐为 individual-goat；GPT-5.4 Mini 和 Claude Haiku 4.5 返回明确的 MODEL_NOT_IN_PLAN，目录可见不能视为账号可用。
  • 免费模型 inclusionai/ling-3.1-flash:free 已在 Windows CPA v8.0.23 完成 6 次真实请求：Chat/Responses 流与非流，以及工具调用和结果回传。共 864 tokens，插件与 CPA 的实际 usage 一致。
  • Claude 原生 Messages、思考签名、图片和 ZDR 的真实验证仍待具备对应权限/能力的模型；已有模拟覆盖不代表真实验证。
  • 免费模型曾触发 429；后续联测应遵守上游冷却，避免快速重复启动整套生成测试。
  • 本机 Python 使用现有 Windows 系统代理，隔离 CPA 需明确设置全局代理。真实测试脚本提供 --system-proxy，将该设置仅应用于测试 CPA。
  • 真实 key 和原始账户响应保存在仓库之外，源码与模拟夹具不含该 key。

异常与恢复

tests/cpa_reliability.py 通过实际动态库和官方 CPA 宿主验证：

  • 429 / Retry-After、同模型别名共享冷却、同账号多 key 共享冷却、到期恢复。
  • 503 在多个凭据间切换；不完整 SSE 的非流式错误与流式中途错误。
  • 请求超时与客户端取消后释放上游连接。
  • 会话重新分配、停用和备注在宿主重启后保留。
  • 模型映射、日志与统计在重启后恢复，恢复后的请求正常记账。

所有异常测试使用本地模拟上游和虚构凭据。

CPA 的失败队列按上游尝试记录；503 换号可能产生多条失败记录。新增断言按实际尝试数核对，未报告 usage 的失败不得虚构 tokens。

持久化优化

原实现每次记录都在服务锁内序列化并写入日志/统计 JSON。当前实现：

  • 单个写入任务每 250ms 合并一次变更，无逐请求写入队列。
  • 在锁内取得快照，序列化和磁盘写入在服务锁外完成。
  • 写入失败保留待写状态并重试，管理状态返回 storage_error 与 storage_pending。
  • 正常卸载先等待活动请求完成，再执行最终刷盘。
  • 统计清空与磁盘快照串行，旧快照不能覆盖清空结果；旧请求的日志保留，计数按统计 epoch 处理。

正常刷新间隔为 250ms；强制结束进程或断电可能丢失尚未写入的记录。磁盘故障时不能保证这一时间窗口，错误状态会保留。双 JSON 文件不是跨文件事务。

前台记录基准

WSL Linux amd64，Go 1.27.2，i5-12600KF，完整保留缓存，每组 1 秒：

日志保留量 原实现 批量写入
1,000 2.820ms/op，约 2.10MB 分配/op 0.522µs/op，约 1.15KB 分配/op
10,000 22.853ms/op，约 17.78MB 分配/op 0.769µs/op，约 1.79KB 分配/op

这是前台记录调用的开销；新实现将序列化与 IO 转移至后台，不能将此倍率直接当作端到端吞吐提升。

实际 CPA 并发基线

tests/cpa_benchmark.py --requests 64，同一机器、默认保留 1,000 条，模拟 SSE 固定分片延迟，监听队列 128：

并发 原请求/秒 新请求/秒 原 P95 新 P95 原磁盘写入 新磁盘写入
1 18.42 20.04 57.34ms 50.87ms 39.54MB 8.66MB
8 98.62 138.68 100.22ms 60.52ms 39.54MB 1.86MB
32 130.95 212.41 281.01ms 182.21ms 39.54MB 1.25MB

短时模拟结果用于比较两种持久化方案，不代表真实 CommandCode 的速度或生产环境容量。

复现

go test -race ./...
go vet ./...
node --test tests/cpa-auth.test.cjs
CPA_BINARY=/path/to/cli-proxy-api python3 tests/cpa_e2e.py
CPA_BINARY=/path/to/cli-proxy-api python3 tests/cpa_native_management.py
CPA_BINARY=/path/to/cli-proxy-api python3 tests/cpa_reliability.py
CPA_BINARY=/path/to/cli-proxy-api python3 tests/cpa_benchmark.py --requests 64
go test ./internal/bridge -run '^$' -bench BenchmarkRecordAtRetention -benchmem

Windows 设置 BRIDGE_LIBRARY 为实际 .dll；macOS 设置为 .dylib。真实测试默认只读，必须显式提供仓库外的凭据文件；--generate 才启用少量真实请求，永不进入 CI。

部署状态

2026-10-12：v0.2.7 额度布局与热更新

  • 原生额度前端 28 项回归、TypeScript 检查与单文件生产构建通过；浏览器验证左侧 5h / 周额度、右侧月额度布局，含月比例未知状态、深浅主题及 375px 无横向溢出。
  • Go race、vet 与 11 项登录适配测试通过。
  • 在隔离 Linux CPA v8.0.23 中，控制台保存设置即生效；无效值被拒绝且磁盘及运行设置保持原值；宿主配置 PATCH 触发 plugin.reconfigure，保留已保存的请求设置与模型。
  • 使用已发布 v0.2.6 动态库启动，发布新版本化文件并切换至本地 v0.2.7，CPA PID 未变；版本确认后凭证、模型、已记录日志和请求统计保留，新请求继续成功。未调用真实模型。
  • 真实 CPAMP v1.14.0 的配置文件模式和环境变量模式均通过：首次启用外部面板需要重启一次，随后 JSON panelPath 和环境变量 PANEL_PATH 原路径更新均即时返回新页面，Manager PID 未变、其他配置保持原值。
  • 上述测试只操作本机临时夹具；未部署或重启目标服务器。

目标 CPAMP https://cpa.gdp.pw/ 页面可访问，当前页面要求 Manager Server 管理员密钥，它与 CPA Management Key 不同。服务器部署与重启由用户维护。

2026-10-12：环境变量模式的原生面板路径检测

  • 通过用户指定的 1Password RSA SSH 密钥只读核实实际进程、环境中的路径设置、凭证元数据和原生 Provider 登记。CPAMP v1.13.1 的环境变量模式没有默认 config.json；已安装 v0.2.5 因强制读取此文件误报「未找到同机 CPAMP」。
  • 公网与两处本机面板返回相同 SHA256，均缺少 CommandCode 原生额度/回调组件。已确认原生凭证与 Provider 存在，不能将显示缺失归因于凭证不存在。
  • 本地新增进程夹具覆盖缺失配置、仅数据库路径时阻止不安全的配置创建、已有 PANEL_PATH、配置损坏、准备期间快照变化、新文件原子无覆盖创建、写入失败回滚与匿名 HTTP 页面诊断。Go race、vet、JavaScript 语法和 diff 格式检查通过。
  • 使用真实 CPA v8.0.23 与校验过官方安装包的 CPAMP v1.13.1/v1.14.0，在本机隔离临时目录中通过 tests/cpamp_native_panel.py --environment-only：只读探测不创建配置；安装创建最小配置；临时 Manager 重启后返回与内置页面字节相同的原生面板；已有 PANEL_PATH 更新无需重启。v1.14.0 既有配置文件模式也通过。
  • 服务器二进制复制因 SSH 超时未完成；版本复现使用官方 v1.13.1 Release，不声称与现场自定义二进制完全相同。本次未重启线上服务、未修改远端文件，修复随 v0.2.6 发布，线上部署由维护者安排。详情见部署诊断。

GitHub 链接安装

  • 2026-10-11 按用户要求将仓库改为公开，匿名读取仓库、latest Release 和 checksums.txt 通过。
  • CPA v8.0.23 要求 ZIP 名称为 <插件ID>_<版本>_<GOOS>_<GOARCH>.zip，且 Release 必须含统一 checksums.txt。v0.1.0 新增四平台兼容命名别名，与原发布 ZIP 字节一致；九个新增资产的 GitHub SHA256 与本地值一致。
  • 提供公开 registry.json，通过 plugins.store-sources 加入自定义插件源。当前未登记至官方商店。
  • CI 38113046358 通过四平台构建/宿主联测及统一校验文件生成。
  • tests/cpa_store_install.py 在隔离 Windows CPA v8.0.23 中通过：公开源发现、匿名 Release 获取、选包、校验安装、配置登记、重启后加载和插件状态确认。测试移除 GitHub Token 环境设置，仅使用虚构 CPA 管理密钥，未发模型请求。
  • GitHub 安装器只写入动态库；目标主机的持久化目录、CPAMP 代理及真实凭据仍由用户安装后验收。

v0.2.3 远程 localhost 回调修复

  • 更正：此版本只模拟 URL 查询参数回调，未覆盖官网实际 POST 正文。地址栏复制方案不完整，已由 v0.2.4 的本地接收器补齐。
  • 用户截图确认官网拒绝远程公开域名 callback；官方 CLI 1.79.2 使用 loopback /callback 和 mode=redirect。
  • 对照 CPAMP Codex/Claude 的原生回调提交与当前 CPA oauth_callback.go：通用接口只读取 code/state/error，不会交付 CommandCode 的 apiKey。新面板复用原生卡片、请求作用域和状态轮询，经插件管理 POST 提交完整 URL 与当前 state。
  • 本地 Go race/vet、原生 CPA v8.0.23 登录/额度/协议/异常恢复测试通过。远程提交验证管理鉴权、错误 state、重复提交、取消、凭证重启持久化和日志脱敏。前端新增原生卡片交互与接口回归测试。
  • 自动化使用虚构凭证与本地上游，不访问用户账户，不修改目标 CPAMP。用户真实官网授权及现场代理验收待升级后测试。