CI 关键路径 frontend 半：workbench coverage 单点 7m35s = 墙钟 96%

[DeliciousBuding]

来源：round-65 主机侧 CI 关键路径实测（operator 明确要求「加速，别把时间浪费在等 PR」）。证据取自两次已完成的真实 run，非估算：

• Go-only PR：run 33674961074（chore/round-64-wave，HEAD=4a7af8c6 前一轮），19:42:55 → 19:51:31 = 8m36s
• Frontend-only PR：run 33676372418（fix/desktop-menu-i18n-forward），19:57:12 → 20:05:07 = 7m55s

仓库 TokenDanceLab/AgentHub = PUBLIC（gh repo view --json isPrivate = false）⇒ Actions 分钟不计费，用并行度换墙钟时间是纯收益，不需要在「省分钟」和「省等待」之间取舍。

关键路径实测拆解（Go-only PR，8m36s）

阶段	起→止	耗时	是否在关键路径
排队 + Detect changed paths	19:42:55 → 19:43:41	46s	✅（job 自身只跑 6s，其余是 runner 启动/排队）
go-hub-test (2)	19:43:44 → 19:48:35	4m51s	✅
go-hub-test (1)	19:43:44 → 19:46:27	2m43s	❌（早 2m08s 结束，白等）
go-hub（lint+ratchet+coverage merge+gosec+vet+staticcheck+依赖方向门）	19:48:38 → 19:51:23	2m45s	✅（串行挂在 test 之后）
backend-required	19:51:27 → 19:51:31	4s	✅

并行侧（同一时刻起跑、都早于关键路径结束）：go-edge-test 两 shard ≤2m52s、go-edge 1m34s、windows-go ≤2m45s、backend-integration 3m06s、backend-e2e ≤1m17s、docker 1m59s、govulncheck ≤29s。即：8m36s 里有 5m30s 完全由「hub 测试最慢 shard + hub 串行尾巴」两段决定，其余 20 多个 job 全程在等它俩。

关键路径实测拆解（Frontend-only PR，7m55s）

阶段	耗时
排队 + changes	~40s（job 自身 7s）
Frontend coverage baseline (@agenthub/workbench) 19:57:29 → 20:05:00	7m31s ← 唯一长杆
frontend-desktop (1/2)	3m43s / 3m36s
Native Windows frontend (desktop/web)	4m10s / 3m40s
Frontend (web) / Visual QA / stubbed E2E	≤1m46s
frontend-required	3s

Go 侧全部按 path filter 正确跳过（go-edge/go-hub/windows-go/backend-required 各 2-6s 报绿），说明路径过滤本身是健康的，问题只在两条长杆。

切片 1（收益最大、风险最低）：把 go-hub / go-edge 的静态检查从「测试之后」搬到「与测试并行」

现状 checks.yml:270-271 go-hub: needs: [changes, go-hub-test]，job 内顺序是：
Lint(golangci --timeout=5m) → verify-hub-lint-ratchet.py → ratchet 自测 → download-artifact(shard 覆盖率) → merge-coverprofiles.py → Coverage check (>=40%) → gosec → go vet → staticcheck。

其中只有 download/merge/coverage 三步真的需要 shard 产物；lint、ratchet、gosec、vet、staticcheck 一步都不需要，却被 needs 强行排在 4m51s 之后。

修法：拆成

• go-hub-static（needs: changes，与 go-hub-test 同时起跑）= checkout + setup-go + Lint + ratchet + ratchet 自测 + gosec + vet + staticcheck；
• go-hub（保留同名 required check，needs: [changes, go-hub-test, go-hub-static]）= 只做 download-artifact + merge + coverage 门 + 两个 fail-closed/skip 兜底 step，并断言 go-hub-static.result == success。

go-edge 同构处理（尾巴 1m34s，含 verify-orchestrator-deps.py + 自测）。

预期：Go PR 关键路径 46s + max(4m51s, ~2m45s) + ~25s ≈ 5m50s，净省 ~2m45s（-32%）。

切片 2：go-hub-test / go-edge-test 的 shard 轮询不均衡（注释自称 balanced，实测不 balanced）

checks.yml:213-215 注释原文：「packages from go list ./... are split round-robin (NR%2) — balanced and disjoint」。实测 hub：shard2 4m51s vs shard1 2m43s，差 2m08s ⇒ disjoint 成立、balanced 被推翻（与 #2246「注释声称被活代码推翻」同族，此处是被 CI 实测推翻）。

修法（择一，需实测后定）：

1. matrix.shard: [1,2,3] + NR % 3，同步改 merge-coverprofiles.py 调用处的 shard 文件名列表（当前硬编码 shard-1.out shard-2.out，见 checks.yml:334-339）；
2. 或保留 2 shard，但把已知重包显式钉到轻 shard（需要一个可复核的成本表，不接受拍脑袋）。

预期：hub 测试段 4m51s → ~3m20s，叠加切片 1 后 Go PR ≈ 4m30s（-49%）。

切片 3：frontend 长杆 @agenthub/workbench coverage baseline 7m31s

它是 frontend PR 的唯一长杆（第二名 3m43s）。需先定位耗时构成（vitest 全量 + coverage 转换 + 是否重复 build），再决定：按 test file 分 shard / 降低 coverage instrument 范围 / 复用已构建产物。本切片要求先出「耗时构成实测」再改，不接受未测量的优化。

验收（不可伪造）

1. 改动前后各取一次同类型真实 run（Go-only 一次、frontend-only 一次），在 issue 里贴 gh run view <id> --json jobs 的关键路径表（job 名 / startedAt / completedAt），证明 Go-only 总时长从 8m36s 降到 ≤6m00s（只做切片 1）或 ≤5m00s（切片 1+2）。
2. 7 个 required check 名一字不改：validate / go-edge / go-hub / windows-go / windows-frontend / backend-required / frontend-required；gh api .../branches/master/protection 前后 diff 为空（不需要也不允许动 branch protection）。
3. 三个兜底语义必须保留并各自有证据：path filter 未选中 → 报绿 no-op；changes job 自身失败 → fail-closed 报红；!cancelled() 让 skip 不阻塞保护。
4. 门禁全绿：python scripts/verify/verify-doc-ssot.py、bash scripts/verify/verify-commit-messages.sh、git diff --check；checks.yml 若被 docs/architecture/github-actions-ci-cd-policy.md 引用为 SSOT，同步更新该文档（verify-doc-ssot.py 会抓）。

负向约束

• enforce_admins: true：一旦 needs 图写错导致某个 required check 永不报结果，所有 PR 都会被永久阻塞且管理员无法绕过。因此本切片只能以 PR 形式验证，禁止直接 push master；PR 上必须先看到 7 个 check 全部报出结果再合并。
• 改 .github/workflows/checks.yml 会让 changes 的所有 filter 命中（desktop/web/shell/go/mobile/frontend/design_css 都把该文件列入），⇒ 该 PR 会跑全矩阵（实测两条关键路径并行，预计 ~9-10min，不是叠加）。这是一次性成本，但必须单独成 PR，不要和实现批混在一起，避免把 Go-only 快批拖成全矩阵。
• 不得为了提速删门（coverage 阈值、ratchet、gosec、staticcheck、Windows 合同、path filter fail-closed 一个都不能少）；只允许改执行顺序与并行度。
• 不得改 concurrency 组语义（cancel-in-progress: true 是「连推取消旧 run」的既有节流约定）。

依赖 / 排期

• 与 round-65（[整理] round-65 wave：edge 节点级配置面写路径无门(安全P1) + App.Version 可追溯 + edge/hub 契约一致性小批 + 3 条只读探索(前端UIUX / 性能并发DB网络 / 对外文档架构) #2250）无文件重叠（round-65 只碰 edge-server/**、hub-server/internal/app/**、.github/workflows/release.yml 的 3 行 ldflags）。
• 建议排在 [整理] round-65 wave：edge 节点级配置面写路径无门(安全P1) + App.Version 可追溯 + edge/hub 契约一致性小批 + 3 条只读探索(前端UIUX / 性能并发DB网络 / 对外文档架构) #2250 合并之后立刻单独成 PR（round-66 slice 0），因为它是后续每一轮的复利收益。

[DeliciousBuding]

切片 1 已合入 master：PR #2257 → squash 4ca8203e。本 issue 保持 OPEN 并收窄为「切片 2 + 切片 3 + 稳态验收回填」。

真实 run 证据（PR #2257 自己的 run 33685438788，全矩阵）

新 job 图按设计工作，串行尾巴已消失：

job	起→止	时长	改前同族实测
go-hub-static（与 shard 并行）	21:31:25 → 21:34:12	2m47s	原本串行挂在测试之后
go-hub-test (2)	21:32:41 → 21:37:28	4m47s	4m09s（#2255 run）
go-hub（聚合）	21:39:24 → 21:39:47	23s	2m52s（#2255）/ 2m45s（#2249）
go-edge-static	21:31:25 → 21:33:01	1m36s	—
go-edge（聚合）	21:34:18 → 21:34:37	19s	1m40s（#2255）/ 1m34s（#2249）
backend-required	21:39:51 → 21:39:56	5s	4s

⇒ 静态门禁 2m47s 已被 4m47s 的 shard 完全覆盖、不再决定关键路径；两个聚合 job 合计从 4m32s 降到 42s。与切片 1 用 step 级计时推演的 go-hub ≈20s / go-edge ≈20s 一致。

验收项 1 尚未达成（如实登记，不许当已完成）

原验收要求「Go-only 总时长从 8m36s 降到 ≤6m00s」。本 PR 的 run 不能作为该读数：改 checks.yml 命中 changes 的全部 filter ⇒ 跑全矩阵；且实测 go-hub-test (1) 直到 21:36:27 才起跑（比同批晚 ~5min），是新增 2 个 job 后的 runner 排队（切片 1 交付时已预告峰值并发 ~18 可能触档）。

⇒ 稳态读数必须由合并后第一个 Go-only PR 的真实 run 回填：贴 gh run view <id> --json jobs 的关键路径表，对比基线 8m36s（run 33674961074）与 #2255 的 8m36s。推演落点 ≈6m03s，卡在 ≤6m00s 之上约 3s ⇒ 若实测确实 >6m00s，就必须做切片 2 才能过线。

剩余两片（本 issue 从此只做这三件事）

切片 2：shard 重平衡。 又一组实测：go-hub-test (2) 4m47s vs (1) 2m53s（本 run，(1) 还含 ~5min 排队，纯执行时间需从 step 级取）；#2255 run 是 4m09s vs 2m43s；基线 run 是 4m51s vs 2m43s ⇒ 三次采样同向，checks.yml 注释自称 round-robin「balanced and disjoint」的 balanced 半句被稳定推翻（disjoint 成立）。修法与硬编码点见原 issue 切片 2（merge-coverprofiles.py 调用处当前硬编码 shard-1.out shard-2.out，改分片数必须同步）。要求先出可复核的成本表，不接受拍脑袋分片。

切片 3：frontend @agenthub/workbench coverage baseline 7m31s 长杆。 原样保留，仍要求「先出耗时构成实测再改」。

切片 1 未做但已定位的残留（不必单开 issue，随手可收）：

• actionlint 11 条 baseline 告警未修：go test $SHARD_PKGS 的 SC2086 不能加引号（靠 word splitting 展开包列表，加引号 = 改语义 = 可能破坏 shard 门）；其余 8 条在 frontend-mobile / real-e2e-stack / vuln-scan-js，与 CI 关键路径无关。
• go-*-static 里 step 级 if 与 job 级 if 同表达式，属刻意保留的冗余（让 diff 是纯移动、评审成本最低），运行时零成本。
• id: sa-cache 是既有死 id（全仓无 steps.sa-cache 引用），随 cache step 一起搬进 static job，未清理。
• org 的 Actions 并发档仍未查询（Free=20 / Pro=40 是文档口径推断）。

顺带修掉的一个既有 CI 诚实性漏洞（已随切片 1 合入）

改前 go-hub/go-edge 的 job 级 if: ${{ !cancelled() }} 让它在 shard 测试失败时照样运行，而 job 内从不检查 needs.go-*-test.result；go test -coverprofile 在测试失败时仍落盘 profile ⇒ Download + Merge + Coverage 三步全过 ⇒ required check 可能报绿，backend-required 只断言 go-hub/go-edge ⇒ 跟着绿。即「单元测试 shard 红了，7 个 required check 仍可能全绿」。改后由 TEST_RESULT / STATIC_RESULT 显式 fail-closed（!= success 即 exit 1，skipped 不算通过）。诚实边界：近 120 次 run 无 go-*-test 失败样本可实证，属结构性推论。

落地形态与门禁（主机核验）

• 写集 7 文件：checks.yml 主体 + docs/architecture/github-actions-ci-cd-policy.md（job 图 SSOT）+ 被迫的 scripts/verify/verify-ci-gates.py / 其自测 / quality-debt-baseline.json（不改则 required check validate 必红：verifier 按 job 名正则定位 step，baseline 的 soft gate 以 "go-edge: Lint" 为键）+ 主机追加的 docs/governance/verifier-map.md（4 行 job ID 过期，:81 的覆盖率合并行仍正确、一字未改）与 AGENTS.md:137（L0 分层行；仍 284 行 / 预算 300）。
• 被迫扩展的 3 个文件是改宿主、不减断言：verify-ci-gates.py 新增 6 条拆分契约断言（含「go-*-static 必须不含 download-artifact」防把覆盖率门也搬走、「聚合 job 必须绑定并断言两条 lane 结果」），自测 35 → 39 用例；baseline 只改 location 键，issue/owner/introduced_at/review_by 未动。
• 未删门、未降阈值：coverage ≥40%（hub）、edge per-package 70/60/55、两个 lint ratchet + 各自自测、gosec、vet、staticcheck、orchestrator 依赖方向门 + 自测、Windows 合同、path-filter fail-closed、!cancelled() 恒报兜底全部保留；concurrency 块与 changes filter 定义一字未动；7 个 required check 名一字未改，未查询也未修改 branch protection。
• 门禁实跑：actionlint findings 多重集与 pristine master 完全一致（11 条，零新增）｜verify-ci-gates.py ok + 自测 39 OK｜verify-doc-ssot.py ok（AGENTS 96 paths）｜verify-commit-messages.sh origin/master ok(3 commits)｜git diff --check clean｜合并后 git diff origin/master cb636c0e 为空 = 落地树与门禁树逐字节一致。

[DeliciousBuding]

验收项 1 回填：合并后第一个 Go-only PR 的稳态读数（主机实测，不是估算）

按本 issue 的要求，稳态收益只取「#2257 合并后第一个 Go-only PR」的真实 run。PR #2263（head 58dbeeee，改动只在 hub-server/**：internal/egress + internal/repository + internal/service/agent + internal/service/workspace + internal/handler + tests/integration）就是那一发。

run 33695705972（conclusion: success）：

run_started_at 2026-09-02T23:34:35Z → 最后一个 job 完成 23:39:19Z
= 总墙钟 4m44s

关键路径逐段（gh api .../runs/33695705972/jobs，只列非 skipped）：

job	起	止	时长	在关键路径上？
Detect changed paths	23:34:39	23:34:47	8s	是（前置）
go-hub-test (2)	23:34:50	23:38:44	3m54s	是（唯一长杆）
go-hub-test (1)	23:34:50	23:37:35	2m45s	否（与 (2) 并行）
go-hub-static	23:34:51	23:37:36	2m45s	否（#2251 切片 1 的成果：与 shard 并行，不再串行压在聚合 job 前面）
go-edge-test (2)	23:34:50	23:37:23	2m33s	否
go-edge-static	23:34:50	23:36:23	1m33s	否
Native Windows Go (hub-server)	23:34:50	23:37:36	2m46s	否
Backend integration (PG+Redis)	23:34:51	23:37:20	2m29s	否
go-edge（聚合）	23:37:27	23:37:50	23s	是（但已不是长杆）
go-hub（聚合）	23:38:48	23:39:13	25s	是
backend-required（聚合）	23:39:16	23:39:19	3s	是

与本 issue 记录的改前基线对照：

	改前（本 issue 原文）	改后（本次实测）
Go-only PR 总墙钟	8m36s	4m44s（−3m52s，−46%）
hub 最慢 shard	4m51s	3m54s
go-hub 串行尾巴	2m45s	25s
关键路径构成	shard + 串行静态门禁尾巴	只剩 shard 本身 + 两个 ~25s 聚合

验收判定

• 验收项 1（Go-only PR ≤ 6m00s）：PASS，且余量 1m16s。 本 issue 当初的预测是「~6m03s、可能压线」，实测比预测还好 1m19s——差异来自静态门禁拆出去之后 go-hub-static 与 shard 完全重叠（2m45s 全部藏在 3m54s 的 shard 后面），而预测里给它留了一部分串行残量。
• 切片 2（shard 重平衡）不再是验收必需项：关键路径上已经只剩 go-hub-test (2) 一根 3m54s 的长杆，两个 shard 是 3m54s vs 2m45s（差 1m09s）。重平衡理论上能再省 ~35s（把长杆压到 ~3m20s），代价是要重排包轮转并重测。主机裁决：暂不做，把它降级为「若将来 hub 测试继续增长再排」的候选，不占当前 backlog 优先级。
• 前端侧（本 issue 的另一半：workbench coverage 7m31s 单点）本轮未测，因为 fix(hub): PUT /web/custom-agents/:id 改窄列写+原子 not-deleted 守卫（不再静默销毁 output_schema、不再复活并发软删的行、不再给不存在的 id 插出幽灵行）+ 拆掉三颗「-count=2 必红」的进程内全局状态隐雷（egress 代理缓存 / 两处共享内存 SQLite 夹具） (#2253) #2263 是 Go-only、前端 job 全 skip。切片 3 仍缺「耗时构成实测」这个前置，状态不变。

[DeliciousBuding]

验收项 1 的另半边回填：frontend-only 真实 run（主机实测）

切片 1 只改 Go 侧 job，所以 frontend 路径既没被优化、也没被回归 —— 但验收项 1 要求「Go-only 一次、frontend-only 一次」同类型对照，此前只回填了 Go-only。现在补上。

取样：PR #2262（head 0aee64a8，10 个改动文件全在 app/desktop、app/shared、app/web 下，零 Go 改动），即切片 1（4ca8203e）合并之后的第一个 frontend-only PR。

run 33693800126（conclusion: success，24 个非 skipped job）：

总墙钟 = 7m53s (473s)

job	时长	在关键路径上？
Frontend coverage baseline (@agenthub/workbench)	7m35s	是（唯一长杆，几乎等于总墙钟）
Native Windows frontend (agenthub-desktop)	3m48s	否
Native Windows frontend (agenthub-web)	3m39s	否
frontend-desktop (2) / (1)	3m31s / 3m28s	否
Frontend coverage baseline (@agenthub/shared)	2m05s	否
Frontend (web)	2m01s	否
Web stubbed-hub E2E (path-filtered)	1m47s	否
Visual QA shell (web, path-filtered)	1m38s	否
Frontend coverage baseline (agenthub-web)	1m11s	否

与本 issue 原文记录的改前基线 7m31s 对照：7m53s 属同一量级（切片 1 未触碰任何 frontend job，差值在 runner 噪声内），而关键路径构成与本 issue 的预测逐字吻合：「frontend PR 由 workbench coverage 单点决定」——该单点今天实测 7m35s，占总墙钟的 96%，其余 23 个 job 全部藏在它后面。

判定与收窄

• 验收项 1（Go-only ≤6m00s）：PASS（前一条评论已用 run 33695705972 实测 4m44s，余量 1m16s）。
• 验收项 2/3/4：随切片 1 的 PR 落地（7 个 required check 名一字未改、branch protection 未动、三条兜底语义各自有证据、门禁全绿）。
• 切片 2（Go shard 重平衡）：主机裁决不做，降级为「hub 测试继续增长再排」。
• 本 issue 由此收窄为 frontend 半边：唯一剩下的活是把 Frontend coverage baseline (@agenthub/workbench) 这根 7m35s 的长杆拆开或并行化（本 issue 原文的估计是可降到 ~4m30s）。它自成一片写集（.github/workflows/checks.yml 的 frontend coverage matrix），与已落地的 Go 侧改动零重叠，可独立成 PR。标题已按此改写。

注意本 issue 的负向约束仍然适用：改 checks.yml 会让 changes 的所有 filter 命中 ⇒ 该 PR 跑全矩阵（~9-10min），必须单独成 PR，不要和实现批混。enforce_admins: true，所以只能以 PR 形式验证，且必须先看到 7 个 check 全部报出结果再合并。