WorkBuddy2API-Hub fnos-1.7.3

WorkBuddy2API-Hub fnos-<版本>

GitHub Release 正文模板。复制成 docs/phase-g-release-body.md（或任何文件）后替换 <...>，
再用 python3 scripts/gh-release.py release-edit fnos-<版本> <文件> 发布。
上传命令与校验清单见 docs/phase-g-local-release.md。

本次发布对应上游 v<上游版本>，包名 WorkBuddy2API-Hub_<版本>_all.fpk，appname 仍是
workbuddy2api（升级覆盖安装，数据目录 /vol1/@appdata/workbuddy2api 不变）。

文件与校验

文件	字节数	sha256
WorkBuddy2API-Hub_<版本>_all.fpk	<size>	<sha256>
WorkBuddy2API-Hub_<版本>_all.fpk.sha256	<size>	—

校验：sha256sum -c WorkBuddy2API-Hub_<版本>_all.fpk.sha256

安装 / 升级

1. 应用中心 → 手动安装 → 选择本 Release 的 .fpk（覆盖安装即可，端口仍是 8788）。
2. 升级前建议备份 /vol1/@appdata/workbuddy2api/（至少 accounts/ 与 usage/）。
3. 卸载默认保留数据目录。

本版包含

• <改动 1>
• <改动 2>

验证数字

• python3 tests/run_all.py --jobs 4：<passed> passed / 0 failed / 0 skipped
• bash scripts/verify-fpk.sh dist/WorkBuddy2API-Hub_<版本>_all.fpk：71 passed, 0 failed

已知限制

• <限制 1>

WorkBuddy2API-Hub 1.6.19（飞牛原生 fpk）

WorkBuddy2API-Hub 1.6.19（飞牛原生 fpk）

本次发布对应上游 v1.6.19（并含其后的上游提交，上游没有发新版本号）。包名
WorkBuddy2API-Hub_1.6.19_all.fpk，appname 仍是 workbuddy2api —— 覆盖安装即可，
数据目录 /vol1/@appdata/workbuddy2api（账号、用量、设置）不变。

这版开始，发布不再经 CI：包是在维护者机器上用 scripts/build-fpk.sh 构建、
用 scripts/gh-release.py 上传的，所以下面这个附件与本机 dist/ 里的文件逐字节相同
（下载回来比过 sha256）。GitHub 上不再有任何自动构建/自动同步工作流。

文件与校验

文件	字节数	sha256
WorkBuddy2API-Hub_1.6.19_all.fpk	626248	e65dcb844df7ede523e990c33e3e661e27d6c73e0a9770592d76e006d610505d
WorkBuddy2API-Hub_1.6.19_all.fpk.sha256	99	—

校验：sha256sum -c WorkBuddy2API-Hub_1.6.19_all.fpk.sha256
包内 manifest：version = 1.6.19、display_name = WorkBuddy2API-Hub、service_port = 8788、
checksum = ff0742cf816e35077f5ce51f54de27f5（= 包内 app.tgz 的 md5）、39 个载荷文件。

安装 / 升级

1. 应用中心 → 手动安装 → 选本 Release 的 .fpk（原地升级/覆盖安装，端口仍是 8788）。
2. 升级前建议备份 /vol1/@appdata/workbuddy2api/（至少 accounts/ 与 usage/）。
3. 卸载会清掉数据目录（除非先把 wizard/uninstall 挪开），能覆盖安装就不要卸载。
4. 装完点应用中心的「打开」：应该免密直接进面板（飞牛已登录用户不再被问面板密码）。

本版包含

• 并入上游最新代码：v1.6.11 → v1.6.19 的全部更新，外加 v1.6.19 之后的 79 个提交
  （面板拆成「账号 / 任务与福利 / 数据看板」三页、Buddy 加油站签到按钮与状态卡片、
  上游 wb_upstream_pool.py/wb_agents.py/wb_updates.py 等新模块；本轮又并进 25 个：
  账号页可独立成一个页签并新增签到与活跃记录看板、所有数据表支持点表头排序、
  顶部页签可收起、更新检查设置卡、剩余用量优先调度（默认关）与超限页内轮转暖号回退、
  剩余用量估算第二/三批与限额联动）。
• 保留并重贴飞牛层：统一网关免密入口（socket peer 校验通过即登录，不再要求网关注入
  用户头，解决「飞牛里开着开着又要密码」）、--unix-socket/--base-path 挂载前缀、
  仅挂载态注入 <base href> 与 window.__WB_*、cockpit 兼容导出、主题/移动端、看板 token
  单位自动切换与「每 M tokens 积分」列、设置页「使用说明」。
• 修掉的真缺陷：AF_UNIX 上 TCP_NODELAY 让网关路径每个请求都失败；缺省直连被注入
  飞牛上下文（上游要求逐字节一致）；ETag 缺网关上下文分量（换用户会拿到 304 用上别人的注入页）；
  上游新 fmtTok 静默覆盖我们的精确 token 单位；包内嵌自指 fnpack.json 导致校验永久 1 条红。
• 发布机制：GitHub 上删掉全部自建工作流（只剩上游自带、只在 v* 触发的 release.yml），
  改成本地 scripts/build-fpk.sh + scripts/gh-release.py（runbook：docs/phase-g-local-release.md）。

验证数字

• bash scripts/verify-fpk.sh dist/WorkBuddy2API-Hub_1.6.19_all.fpk → 71 passed, 0 failed
  （tag 挂在 HEAD 上时；构建那一刻 HEAD 还没 tag，那时是 70/0）
• python3 tests/run_all.py --jobs 4 → 121 passed / 7 failed / 0 skipped。这 7 条红没有一条是本仓库引入的：
  • 6 条在纯上游 upstream/main（不含本仓库任何改动）上可逐条复现——
    _test_activity_history.js（loadActivityToday is not defined）、_test_page_nav.js、
    _test_settings_load.js、_test_settings_update_ui.js、_test_model_cooldowns.js、
    _test_run_all_encoding.py（它拿 _test_settings_load.js 当「已知必绿」的夹具，被上一条带红）。
    即上游这一版自己就带着 6 个红套件。本仓库不修上游的测试文件——改了下次并入必冲突。
  • 第 7 条是本仓库的静态验收套件 tests/_test_phase_e_verify.py：它按设计把「已发布资产 == 树」
    「HEAD 上的 tag」「设备 / 包一致性」钉成断言，每次合并并重发布后都要按新契约重钉一轮。
• 附件与本机 dist/ 文件 sha256 一致（e65dcb84…，下载回来复算过）

已知限制

• 构建不可复现：同一棵树两次构建的 .fpk 字节不同（载荷文件 mtime 进 tar），
  所以校验请以本 Release 的 sha256 为准，别用「重建一遍再比」。
• 设备上如果装的是更早那次发布的同版本包（Phase F 的 CI 构建），一般覆盖安装即可（同版本号能否安装未在真机验证）；
  实测差别只有 7 项：内容不同的 6 个载荷文件（dashboard.html、wb_proxy.py、wb_accounts.py、
  wb_scheduler.py、wb_tasks.py、wb_settings.py）＋旧包里多一个 server/fnpack.json
  （本包不再内嵌，它是自指的发布清单）。其余 33 个载荷文件逐字节相同。
• 自动同步/自动构建已按维护者要求删除：上游更新需要人工合并后再本地发布。
• 飞牛应用中心的「点击打开」流程与真机移动端观感仍需人工确认。

v1.6.17.1

WorkBuddy2API-Hub v1.6.17.1

飞牛（fnOS）原生应用包 + 网关免密修正版本。基于上游 v1.6.17（以及它之后的 6 个提交）构建，本层只加飞牛网关接入与打包，重复能力一律以上游实现为准。

这个版本有什么

1. 飞牛 fnOS 原生应用包

• 产出 WorkBuddy2API-Hub_1.6.17.1_all.fpk，可以直接在飞牛应用中心安装、升级、卸载（沙箱里按应用中心的真实目录形状与调用顺序演练过整条 install → start → 导入账号 → upgrade → stop → uninstall 路径）。
• 产品名统一为 WorkBuddy2API-Hub（App Center 显示名、看板标题、Release 标题、CI 产物名都叫这个），但应用标识 appname 仍是 workbuddy2api。
  • 这不是笔误：appname 决定应用目录 /vol1/@appcenter/workbuddy2api/、数据目录 /vol1/@appdata/workbuddy2api/、unix socket 路径和网关前缀 /app/workbuddy2api。改掉它等于另起一个新应用，老用户的数据会留在旧目录里读不到，入口地址也会变。所以「给人看的名」改了，「给系统看的标识」不动。

2. 应用中心统一网关里免密打开看板（口径修正）

应用中心把应用挂在前缀 /app/workbuddy2api 下、用 iframe 打开看板，请求走 app.sock。

• 旧行为的问题：只有当请求带上 X-Trim-Username 才被认为已登录，而这个头由飞牛的会话注入；会话老化后不再注入 → 已经登录飞牛的人被弹回面板口令框。
• 现在的口径：unix socket 上只要对端（peer uid）校验通过（uid 0 = 网关，或应用自身 uid）就视为已登录，不再要求 X-Trim-Username；该头只用来显示用户名，没带就只显示入口提示。
• 没有放松边界：直连 TCP 端口仍然要面板口令；伪造该头的非网关 uid 仍然被拒绝。
• 看板同时适配了挂载前缀：页面用 <base href> 与 window.__WB_BASE__ 把静态资源和接口请求都打在网关前缀上。

3. 看板增强

• token 单位按量级自动切换（K / M），大数字不再挤成一串。
• 模型矩阵新增「每 M tokens 积分」列，把积分消耗折算成可比单价，方便横向比模型。
• cockpit 兼容导出：POST /accounts/export，format=native|cockpit。cockpit 产物是裸数组 + snake_case OAuth 行，供外部工具直接消费；GET /accounts/export 保持原行为不变。

4. 上游整合

并入上游 v1.6.11 – v1.6.17 以及 v1.6.17 之后的 6 个提交（合并提交 9dff35f），包含 Claude Code 兼容、临期积分优先分派、用量统计性能、账号熔断降权、时序图与导航等改动。与上游重复的功能一律以上游实现为准。

文件与校验

项	值
文件	WorkBuddy2API-Hub_1.6.17.1_all.fpk（即本 Release 的附件）
旁置校验文件	WorkBuddy2API-Hub_1.6.17.1_all.fpk.sha256
payload	26 个文件：server/** 21 个（与仓库逐字节一致）+ ui/config、ui/images/64.png、ui/images/256.png、config/privilege、config/resource

校验：

sha256sum -c WorkBuddy2API-Hub_1.6.17.1_all.fpk.sha256

这里不写死 sha256，是因为每次构建的字节都不一样：tar 成员时间戳一变，app.tgz 与其在 manifest 里声明的 checksum 就跟着变。所以判据是 payload 而不是字节：自己在本机跑 scripts/build-fpk.sh 得到的包与 Release 附件 26 个文件逐文件 md5 完全一致，只有字节数与 checksum 不同——两边装出来的东西是同一个。本次发布件本身也跑过完整的包级验收：71 项断言全过（包身份、文件名 / manifest / 目录三处一致、payload 与仓库逐字节一致、网关免密的两种形态），Release 附件旁边的 .sha256 就是它的真实指纹。

安装 / 升级

1. 在飞牛应用中心里选择「手动安装」，上传 .fpk 即可。已经装过本应用（设备当前为 1.6.17.1，同版本覆盖安装走的也是同一条路径；更早的 1.6.10.x 直接覆盖升级）时，应用目录与数据目录都不变。
2. 覆盖安装前建议先备份数据目录 /vol1/@appdata/workbuddy2api/（账号池、用量、定价缓存、设置都在这里）。升级本身不会清数据，但升上去之后没有一键回退，备份是唯一的后悔药。
3. 卸载时卸载向导会问是否删除数据，默认保留——除非你明确要清空。
4. 装好后从应用中心打开，或直接访问统一网关入口（前缀 /app/workbuddy2api）。面板端口仍是 8788。

验证数字

• 测试套件：python3 tests/run_all.py --jobs 4 → 86 passed / 0 failed / 0 skipped（新增 tests/_test_release_pipeline.py，8 项：四段 tag 定版、CI 当时的混合 tag 集合仍按 HEAD tag 定版、只有 release tag 的 shallow clone 仍报该 tag、alpha 与无 tag 仍能报版本、构建 workflow 传 VERSION 并断言、同步 workflow 镜像上游 tag、冲突路径在 Issues 关闭时仍然大声失败）。
• 包级验收：bash scripts/verify-fpk.sh dist/WorkBuddy2API-Hub_1.6.17.1_all.fpk → 71 passed / 0 failed（含包身份三处一致、模块完整性、四个禁止目录、包内 server/** 与仓库逐字节一致，以及带/不带 X-Trim-Username 两种免密形态）。
• Phase E 独立验收清单（含平台预演与发布流水线复核）：PASS = 261 / FAIL = 0 / SKIP = 2（两条 SKIP 是「本机没有 AF_UNIX / 不是 root」这类环境项，非缺陷）。

已知限制

• 真机上的移动端渲染没有逐项验证：布局自适应用的是沙箱里的浏览器等价复现，窄屏观感请在真机上再看一眼。
• 每日同步此前没有成功跑过一次：2026-10-06 / 10-07 / 10-08 三次定时 run 全红，三次都是上游与飞牛层在同一批文件上真实冲突（README.md、dashboard.html、tests/run_all.py、wb_proxy.py）——按设计中止合并、交人裁决；而当时的冲突上报依赖 issue，仓库 Issues 是关的，gh issue create 直接失败，于是只剩一条没有任何解释的红 run。现在冲突路径不再依赖 Issues（见下节），但冲突本身仍然要人工合并：上游动到我们改过的文件，当天的同步就会停下，这正是「绝不在同步流程里自动解决冲突」的代价。
• 仓库 Issues 仍未启用（Lead 的 token 没有仓库设置权限，勾选由仓库所有者做）：在此之前冲突以 ::error:: 注解 + 此次 run 的 summary（含冲突文件清单与手工合并命令）报出，不会静默；勾上之后同一段代码会自动开始建 issue，不需要再改 workflow。
• 日志窗口维持上游的终端配色，未按看板主题适配。
• 版本号规则：上游出 v1.6.18 之后基线整体上移为 1.6.18.x，1.6.17.x 不会越过它。
• appname 不能改（见上），本版不提供改名迁移方案。

与上游的关系

本 fork 不是镜像。默认分支上除了上游代码，还带着飞牛这一层（fnos/**、网关免密与挂载前缀改动、打包脚本、看板增强），因此上游一旦改动这些文件就会产生冲突。

冲突绝不在同步流程里自动解决：任其失败、开/更新 issue 交给人裁决，宁可这条同步 run 红掉，也不推一个半合并的仓库出去。standing rule 是「重复能力上游优先，飞牛层只保留上游没有的部分」。

发布流水线与版本命名（本次重新发布 v1.6.17.1 起）

v1.6.17.1 这一版暴露了一个只看单机看不出来的问题：同一个提交在不同环境算出两个版本号。

• 事故：tag v1.6.17.1 在 CI 里构建出的包叫 1.6.10.3（Release 407525712，附件 WorkBuddy2API-Hub_1.6.10.3_all.fpk，411262 字节）。CI 日志原文 ==> building WorkBuddy2API-Hub (appname workbuddy2api) 1.6.10.3 (all) for ccrabit。
• 根因：scripts/build-fpk.sh 原来把版本派生自「本 checkout 能看到的最新上游三段 tag」。本机 fetch 过上游的 v1.6.17 所以算对；CI 全新 checkout 只看到 fork 自己的 tag（origin 上只有 v1.0.0 … v1.6.10、v1.6.10.1/.2 和我们的 v1.6.17.1），最新三段 tag 是 v1.6.10 → 第四位 3 → 1.6.10.3。这个号比设备已装的 1.6.17.1 还小，装了会被当成降级。
• 三条修复：
  1. scripts/build-fpk.sh：HEAD 上的四段 tag 就是版本号（release 模式第一优先，v1.6.17.1 → 1.6.17.1），不再问「本 checkout 看得到哪些远端 tag」；没有 tag 时才按旧规则派生，再退到 fnos/manifest 的 version=。alpha 模式行为不变。
  2. .github/workflows/build-fpk.yml：tag 触发时把 tag 显式作为 VERSION 传下去，并先跑 --print-version 与 tag 比对，不一致就 ::error:: + 非零退出，拒绝发布一个 tag 名不出来的包。
  3. .github/workflows/sync-upstream.yml：每次同步（不止发布那一次）把上游的三段 tag 全部镜像到 origin，这样任何 checkout 都能看到基线 tag；头部注释里那句「tag 与包版本总是一致」已改成它成立的前提。
• 顺带修：冲突路径原本只靠 gh issue create 报信，而仓库当时 Issues 是关的，于是 10-06 至 10-08 三次同步全红却一条 issue 都没有（GraphQL: Resource not accessible by integration (createIssue)）。现在这条路径不依赖 Issues 是否打开：先 gh api … --jq .has_issues 判断，开着就照旧建/更新 issue；关着（或建 issue 仍被拒）就输出 ::error:: 注解，并把冲突文件清单与手工合并命令写进该次 run 的 summary，然后照样非零退出。要拿回 issue 那一半，只需在 Settings → General → Features 里把 Issues 勾上，这一步会自动开始建 issue；至少不会再出现「红了但没人知道为什么」。
• 回归门：新增 tests/_test_release_pipeline.py，覆盖两种环境——① 复现 CI 当时的 tag 集合（三段 tag 只到 v1.6.10，另有 v1.6.10.1/.2，HEAD 上是 v1.6.17.1）：未修代码在此报 1.6.10.3，与 CI 日志逐字一致；② git clone --depth 1 --branch v1.6.17.1 的 shallow clone（除该 tag 外什么都看不见）：未修代码回落到 fnos/manifest 报 1.6.10。两种环境修后都必须报 1.6.17.1。另有静态断言盯住构建 workflow 的 VERSION 传递与相等断言、同步 workflow 的 tag 镜像、以及冲突路径的 has_issues / ::error:: / run summary / 中止前读取冲突路径。修脚本前该套件 6 红，修后 8 项全绿。
• 本次 Release 的处理：v1.6.17.1 这个 tag 被重指到修好流水线的提交，用修复后的流水线重新构建，并删掉那个 1.6.10.3 的错包附件。重指前核对过两件事：① 错包与本机包的 payload 26 个文件逐文件 md5 完全相同（差别只有 manifest 的 version/checksum 两行，以及 tar 成员时间戳带来的字节差），② 新旧提交在 dashboard.html、wb_proxy.py、fnos/**、pricing、LICENSE 上没有差异——所以这个 Release 里的代码和你设备上已经装的那份是同一份，重新下载不会改变行为。包名与版本号保持 1.6.17.1，不需要卸载重装。

本次发布件指纹（CI 构建产物）

项	值
文件	WorkBuddy2API-Hub_1.6.17.1_all.fpk
大小	411266 字节
sha256	836965e77b38c49d79b16cf4493ecf3a5d1b8a3b624d99198148f183761c6d98
manifest 里的 checksum（= 包内 app.tgz 的 md5）	417854c814df6a5ee64fc1d6f69039cc
构建	GitHub Actions Build the fnOS package，run 37894318599（v1.6.17.1 tag 触发）

这份发布件已跑完 71 项包级验收断言（0 failed），payload 的 26 个文件与本机 scripts/build-fpk.sh 构建出的包逐文件 md5 完全一致；附件的 .sha256 旁置文件与实际字节一致。

WorkBuddy2API v1.6.10.2

飞牛 OS 应用包（fpk，platform = all）。装到应用中心即可，也是 1.6.10.x 的就地升级包。

• 应用中心内嵌入口：ui/config 改成 iframe，走飞牛的网关 socket（app.sock + /app/workbuddy2api）。点桌面图标直接在应用中心里打开看板，已登录飞牛的用户免密码。身份头只在网关 socket 上、且对端确实是网关时才认，TCP 上伪造无效。
• 夜间模式：跟随系统、可手动切换并记住；运行日志窗口跟着主题走（不再固定黑底），深色下的行 hover 也调柔了。
• 手机适配：860/640/400px 重排，表单控件 16px（避免 iOS 聚焦缩放）。
• 看得懂的数字：token 数量自动换单位（K/M/B/T），精确值放在 tooltip；每个模型的明细小框里多一行「每 M tok 多少积分」。
• 设置页「使用说明」：API 地址、直连地址、应用中心地址，带复制按钮，端口取自服务端。

安装：飞牛 OS → 应用中心 → 手动安装 → 选中这个 fpk。校验完整性：

sha256sum -c workbuddy2api_1.6.10.2_all.fpk.sha256

另外，这个版本把 Windows 上的测试失败也修了（网关 socket 只在有 AF_UNIX 的平台上定义，导入不再抛异常），三平台 CI 全绿。

WorkBuddy2API v1.6.10.1

Full Changelog: v1.6.10...v1.6.10.1