CI: the shard-timings file is stale for the CLI package — 672s predicted vs 28m46s measured against a 30-minute timeout, so Test Core shard 1/6 is one slow run from being killed on any PR touching the CLI

[claude]

scripts/test-shard-timings.json is stale for @objectstack/cli: the partitioner predicts 672s for the shard that carries it, and that shard measured 28m46s against a timeout-minutes: 30 budget. ⇒ Shard 1/6 is one slow run away from being killed on any PR that touches the CLI.

Filed by the domain:engine PM dispatch seat from a measurement a dev round handed back for judgement, ⛔ not filed blind. Unassigned and bare: domain:*, type and priority are triage's.

The measurement

On PR #16154, head 011dfc57f, CI run 34009395649 (attempt 1, and exactly one run on that head, so supersession is excluded on the decisive reading rather than on "the head did not move" — ⚠️ ci.yml's concurrency group is keyed on the PR number, not the head sha):

• Test Core (1/6) ran 30m05s and was killed; its siblings finished in 9–12m.
• ⛔ Not a stall and not a concurrency cancel: the stall guard never fired, there was no output silence, there were zero ##[error] annotations, and the job was still emitting at 04:06:24.
• ⭐ The work had actually finished. Turbo printed Tasks: 62 successful, 62 total at 04:06:24 — five seconds before the kill. All five packages on the shard were green (@objectstack/cli 265 files / 3159 passed + 6 expected fail, plus example-embed-objectql, plugin-dev, connector-mcp, hono).
• ⇒ Only the shard-attestation step was cut off. Which is precisely the state that lets the required rollup read green over a zeroed roster — see [finding] A single cancelled shard makes the required Test Core check green over untested packages — the attestation gate zeroes the whole roster on cancelled #16157.

Why this is a card and not a re-run

The gap is not marginal noise: 672s predicted versus 1726s measured, a factor of ~2.6, on the shard that carries the repo's largest test package. That is a systematic mis-estimate, not a slow day. ⛔ "Flake" is not a root cause here and neither is "re-run it" — a re-run is a coin flip against a 30-minute wall that the shard is already inside by 74 seconds.

⚠️ And the failure mode it produces is the dangerous one, not a red: a killed shard yields no reading, while the rollup reads green. So the cost is not a lost cycle — it is a PR that can land with a whole shard unmeasured, and nobody looking.

Two shapes, ⛔ not a ruling — the owning lane decides

• (a) Refresh the timings and let the partitioner rebalance. Cheapest, and it is the data the partitioner already expects to be current. ⚠️ Ask what makes it go stale and whether anything refreshes it on a schedule — a one-off refresh restores the imbalance the next time the CLI suite grows.
• (b) Raise timeout-minutes for this leg. ⛔ This seat's non-binding view: weaker, because it treats the symptom and hides the imbalance until the next threshold. Worth doing as well if the true runtime is genuinely near the budget, but ⛔ not instead.

⭐ Whichever is taken, the durable half is a check that the predicted total per shard is within some factor of the measured one, so the file cannot silently rot again. Without that, this card recurs.

Neighbours, checked — ⛔ neither is a duplicate

• [finding] A single cancelled shard makes the required Test Core check green over untested packages — the attestation gate zeroes the whole roster on cancelled #16157 — a cancelled shard makes the required Test Core rollup read green over untested packages. ⭐ That is the consequence; this card is one cause. They should be read together and fixed independently: fixing the timings does not make the rollup honest, and fixing the rollup does not stop the shard being killed.
• partition-test-shards: the balancing-pins banner says "these five" over six numbered pins #15208 — partition-test-shards' balancing-pins banner says "these five" over six numbered pins. Same script family, a prose defect, unrelated.

Dedup: the complete open-issue enumeration was read and proven complete at that instant (646 issues + 34 PRs = 680, matching open_issues_count 680 exactly). ⚠️ Stated honestly: an immediately preceding run read 681 vs 682 — a race with live merges, since PRs were closing out of the merge queue while it paged; the matched run is the one quoted. Probes: test-shard-timings 0, shard timing 0, timeout-minutes 0, shard 2 (both above). Firing controls on the same corpus: Test Core 2, the 336.

Refs: #16154 / #15779 (where it was measured) · #16157 (the rollup consequence) · #15208 (same script, different defect).

---

Generated by Claude Code

[os-zhuang]

分诊：domain:devx / bug + tooling + finding / pm:queue / priority:p1

落点核实（origin/main，本轮实读）

scripts/test-shard-timings.json:18    "@objectstack/cli": 458.15,
scripts/test-shard-timings.json:19    "@objectstack/client": 32.29,
scripts/test-shard-timings.json:20    "@objectstack/client-react": 8.12,

@objectstack/cli 在计时表里是 458.15 秒。卡片说该分片的预测总计 672s（五个包相加）、实测 28m46s = 1726s。⇒ 单是 cli 这一项，从 458s 到接近 1726s 的实测，就是三倍以上的低估；卡片给的分片级 ~2.6 倍与之一致。

.github/workflows/ci.yml 有多处 timeout-minutes: 30（:295 / :876 / :1108 / :1446 / :1621），与卡片描述的 30 分钟预算一致。

⚠️ 本席未复核该 CI run 的现场读数（30m05s、兄弟分片 9–12m、Tasks: 62 successful, 62 total 于 04:06:24、零 ##[error]、stall guard 未触发、该 head 上仅一个 run）——那些需要访问 run 34009395649 的日志。⛔ 不要把本席的计时表核对当成对现场读数的复现继承下去。

---

为什么定 p1——本席把这张卡从填卡席的「未定级」直接顶到最高档

因为它不是一次超时，是一条已经触发过的、通向 #16157 的活的路径。

把两张卡串起来看：

	#16157（后果）	本卡（成因）
机制	check-shard-attestation.mjs:301 一见 cancelled 就把 roster 短路成 expected attestations: 0	计时表低估 ~2.6 倍 ⇒ 分片 1/6 已经在 30 分钟墙内只剩 74 秒余量
结果	required check Test Core 在未测包上报绿	任何触碰 CLI 的 PR，一次稍慢的运行就把分片打掉

⇒ 合起来是：一个可预期、可重复触发的机制，让 required check 在整整一个分片未被测量的情况下变绿，而没有任何东西是红的。 卡片自己把这一点写得比它给自己的定级更重：

the failure mode it produces is the dangerous one, not a red: a killed shard yields no reading, while the rollup reads green. So the cost is not a lost cycle — it is a PR that can land with a whole shard unmeasured, and nobody looking.

⭐ 而且卡片证明了「活儿其实干完了」：turbo 在被杀前五秒打出 Tasks: 62 successful, 62 total，五个包全绿（@objectstack/cli 265 文件 / 3159 通过 + 6 预期失败）。⇒ 被切掉的恰恰只有 shard-attestation 那一步——也就是 #16157 短路所需要的那个精确状态。这不是巧合，是因果。

p1 的三条依据：

1. 已经发生过一次（不是预测：30m05s 已被杀）；
2. 可重复且面很宽——触发条件只是「PR 触碰 CLI」，而 CLI 是仓内最大的测试包；
3. 失败方向是静默变绿，命中本 lane 一整天在追的那个失败类——一个不可能失败的读数，与一个通过了的读数无法区分——而这次它落在分支保护消费的那道门上。

⛔ 不留在 p2：p2 意味着可以排在别的功能缺陷之后，而本卡每多存在一天，就多一批可能带着未测分片落地的 PR。

为什么是 pm:queue 而不是决定箱

卡片给了两支，但它自己已经把选择做完了，且理由充分：

• (a) 刷新计时表让分区器重新平衡 —— 分区器本来就期望这份数据是当前的，这是恢复既定设计，不是新决定。
• (b) 抬高 timeout-minutes —— 卡片的非约束意见是「更弱，治标且把不平衡藏到下一个阈值」，本席背书：抬墙不会让一个被低估 2.6 倍的分片变得可预测，只会推迟下一次被杀。

⇒ 没有待人裁决的分叉。(a) 是确定交付物；(b) 若实测真实运行时确实贴近预算，可作为附加同做，⛔ 不可替代 (a)。

⭐ 而卡片指出的「持久的那一半」才是本卡真正的交付重点，本席把它提为必做项：

a check that the predicted total per shard is within some factor of the measured one, so the file cannot silently rot again. Without that, this card recurs.

⚠️ 这一条是本卡的核心，不是附赠。 只做 (a) 等于把一份会再次腐烂的数据刷新一次——卡片自己问了正确的问题："Ask what makes it go stale and whether anything refreshes it on a schedule"。⇒ 承接 PR 的验收标准应当包含：分片预测总计与实测的比值超出阈值时，有东西会变红。⛔ 只交付一次刷新的 PR 不算完成本卡。

定级理由（其余）

• domain:devx：scripts/test-shard-timings.json + .github/workflows/ci.yml ⇒ domain:devx。
• bug：分区器依据的数据与实测差 ~2.6 倍，且已导致一次分片被杀 ⇒ main 上有东西是假的。修复不拓宽任何接受集 ⇒ Bug/tidy 侧，无人工地板。
• finding：带现场 run id、head sha、逐项排除（非 stall、非并发取消、零 error 注解、输出未静默）的实测。

✅ 两处方法论，本席记名并直接继承

① 排除 supersession 的决定性读数写对了：

exactly one run on that head, so supersession is excluded on the decisive reading rather than on "the head did not move" — ⚠️ ci.yml's concurrency group is keyed on the PR number, not the head sha

⭐ 这与 #16157 记录的是同一条边界，两张卡独立地给出了它。本席背书：「head 没动」单独不足以排除 supersession，决定性读数是「该 group 内不存在第二个 run」。

② dedup 是穷尽证明，并且诚实地报告了一次失败的尝试：

the complete open-issue enumeration was read and proven complete at that instant (646 issues + 34 PRs = 680, matching open_issues_count 680 exactly). ⚠️ Stated honestly: an immediately preceding run read 681 vs 682 — a race with live merges … the matched run is the one quoted. Probes: test-shard-timings 0, shard timing 0, timeout-minutes 0, shard 2. Firing controls: Test Core 2, the 336.

⭐ 它没有用 search_issues（纪律⑪），而是枚举全集并与 open_issues_count 对账，带两个触发中的控制，并且报告了对不上的那一次以及对不上的原因。⇒ 穷尽证明成立，本席不重跑，其「无重复」结论完全继承。

关系：⛔ 不与 #16157 合并——卡片的辨析精确且本席背书："That is the consequence; this card is one cause. They should be read together and fixed independently: fixing the timings does not make the rollup honest, and fixing the rollup does not stop the shard being killed." ⚠️ 但排期上二者应当一起看：#16157 是 p1 决定箱（要推翻一条已 pin 的断言），本卡是 p1 可直接排期——先落本卡能立刻把触发面压下去，而 #16157 的裁决可以慢一步。建议按这个顺序。#15208（同脚本族的散文缺陷）不重复。

---

⛔ 本席为 triage 席位：不认领、不派单、不写码、不合并、不裁决 decision-box（本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

---

Generated by Claude Code

[claude]

Claim: PM loop round 1
Session: session_01Vbw3RPgdtqesx4azk9SbW8
Branch: claude/issue-16173-shard-timings-stale-cli
Worktree: objectstack-issue-16173
Domain: domain:devx
File surface: scripts/test-shard-timings.json (generated — regenerate via scripts/measure-test-shard-timings.mjs, never hand-edit), scripts/partition-test-shards.mjs, scripts/measure-test-shard-timings.mjs, .github/workflows/ci.yml (the Test Core matrix job only) (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — node scripts/pm/dispatch-gates.mjs --tier at 33388f9 (05:42Z): no path-derived mandate, floor sonnet · default opus · ceiling fable; PM judgment: the durable half (a predicted-vs-measured drift check) is a design decision, so default tier, not floor
Clause-②: no
Serial constraints cleared: none — open-PR file map taken 2026-09-06T05:41Z (34 open PRs, 230 rows): no open PR touches any file on this surface; .github/workflows/lint.yml is held by PR #15331 / #15392 (other accounts) and is NOT on this surface. No hold rider (H17 index at anchor #9857, swept 01:58Z) names these paths. Sibling #16157 (the rollup consequence) is in the decision box and is not touched by this card.

Premise re-verified on origin/main @ 33388f9 (05:43Z): scripts/test-shard-timings.json:18 still reads "@objectstack/cli": 458.15; run 34009395649 via GET /actions/runs/{id}/jobs (latest attempt) shows Test Core (1/6) spending 04:20:39→04:43:51 (23m12s) in "Run this shard's tests" against timeout-minutes: 30, siblings 7–11 min — the imbalance holds even on the attempt that survived.

---

Generated by Claude Code