ci: a per-package suite-duration ratchet — a PR that makes a suite exceed its measured ceiling is red; ceilings rise only by ruling (maintainer-directed, growth constraint)

[claude]

Filed by the skills lane seat (session session_019RfFHiRCSs3JXLK4cwcfox, os-steve) on the maintainer's direction, 2026-09-07T02:5xZ. Surface owner stays domain:devx.

Authority (maintainer, verbatim, live PM chat 2026-09-07): 「同意你的建议，你负责执行派发所有可行的优化」. This card is the growth constraint of the long-term plan.

What

A per-package suite-duration ratchet: each package's measured test duration has a ceiling (the refreshed measurement plus headroom), a PR that makes a suite exceed it is red, and a ceiling is raised only by a ruling — the same rule the line and token ratchets already apply to the skill corpus.

Measured

• @objectstack/cli measured 458 s on 2026-08-24; the shard carrying it measured 28m46s two weeks later; nothing turned red on the PRs that made it slower. Test files grow by 35–89 a day (3,388 against 2,183 source files).
• The measurement exists per run (the turbo summaries; the per-file table from ci: every Test Core run publishes the slowest test files and packages beside their pinned weights (maintainer-directed, part B measurement) #16454).

Ruling

1. Ceilings live beside the timings file as a generated table (package → seconds), refreshed with it; headroom 25% over the refreshed measurement.
2. The check reads the shard's turbo summary after the tests run and reds when a package's duration exceeds its ceiling, naming the package and the slowest files from the per-file report; a ruledRaises-style record with a ruling reference raises a ceiling.
3. A package with no ceiling row (new package) is red, not skipped, until the next refresh gives it one (the H8 shape).

Serial

Blocked behind #16454 (W): the per-file report is its input and both land in the shard job's test step. Dispatched when W merges.

Refs #16173.

---

Generated by Claude Code

[claude]

Blocked-by: #16454

The per-file report is this card's input and both land in the shard test step; dispatched when W merges. Skills lane seat, 2026-09-07T02:5xZ.

---

Generated by Claude Code

[objectstack-fleet]

串行条件已满足 —— 本卡的「等上游」今天为假,维护者确认保留并可取

分诊席(session_01Tw7jnJinGHvoGSi8aFkhPJ),2026-09-23T02:44Z。本条是 devx 清理批的 B 组结论:维护者于 2026-09-23T02:44Z 就本组回「同意」,读作 ⛔ 不关、保留在队列、可取。

为什么本卡不在那批清理里

它带维护者直授(卡面逐字):「同意你的建议,你负责执行派发所有可行的优化」。⇒ 它不是一张自发的工装卡,是那套长期计划的增长约束那一半。裁决 #202 B 的工装规则 ⛔ 不用于一张带直授的卡。

⭐ 新读数:卡面写的串行阻塞已经解除,而卡面没有对账

卡面「Serial」段逐字:「Blocked behind #16454 (W): the per-file report is its input and both land in the shard job's test step. Dispatched when W merges.」评论 5564351304 也写着 Blocked-by: #16454。

实测(2026-09-23T02:44Z,origin/main = e99a14ceae):

读点	值
#16454	state=closed
它的产物在树上	.github/workflows/ci.yml:950 —— # ── Per-file test timings, captured for the aggregator (#16454) ───────

⇒ 输入已经在了。 卡面那句「Dispatched when W merges」的条件今天成立,⛔ 读卡面会以为还在等。本条即为该行对账 —— 这是 #19256 记的那种失败模式(裁决落在评论里、卡面继续主张相反的事)的反向处理:先对账,再让人取。

业务读数,一并记上(取卡的人不必重推)

• @objectstack/cli 量到 458 s(2026-08-24T00:00Z);两周后承载它的分片量到 28m46s,而让它变慢的那些 PR 没有一个变红。
• 测试文件 3,388 对源文件 2,183,日增 35–89 个。
• ⇒ CI 时长 = Actions 账单 + 每个人与每个 agent 的等待。今天没有任何东西在某个包变慢的那一刻报红,本卡装的就是那个刹车。

状态

pm:queue · priority:p2 · domain:devx 不变。⛔ 分诊 ⛔ 不认领、⛔ 不派发 —— 由 domain:devx 车道席按取卡全序取。

---

Generated by Claude Code

[objectstack-fleet]

Deferred at R2 dispatch, not shelved: known hazards · domain:devx seat 2 (session_01JAhu8u8QfBvRjVZDox7CP9) · 2026-10-01T04:08Z

⛔ Not a claim, and no label changes. The card stays pm:queue and any seat may take it in take order. This seat did not take it at R2 (marker 5924530366) for the reasons below; whoever takes it should read them first.

1. The ceilings would be derived from a stale dataset. This card sets each package's ceiling at "the refreshed measurement plus headroom".
   • On origin/main 8f784959cf, scripts/test-shard-timings.json still records @objectstack/cli at 458.15 s.
   • The comment in .github/workflows/ci.yml (about :888) cites 1231.52 s measured.
   • A ceiling built today would put the CLI at about 573 s, so every PR that runs the CLI suite would be red.
   • The scheduled refresh's PR chore(ci): refresh the Test Core shard-timings dataset #20388 has been open and unmerged since 2026-09-28T05:43Z. Re-read the CLI row after it lands, before deriving any ceiling.
2. A sibling reader already exists. 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 #16173 left an unwired --check-drift mode in scripts/partition-test-shards.mjs that reads the same .turbo/runs/ summary this card's check would read. Reuse its reader rather than writing a second one.
3. It is serial with ci: Test Core compares each shard's measured duration with its predicted weight — warning at 1.3x, red at 70% of the timeout (maintainer-directed, drift alarm) #16465 on the shard job's test step in ci.yml. ci: Test Core compares each shard's measured duration with its predicted weight — warning at 1.3x, red at 70% of the timeout (maintainer-directed, drift alarm) #16465 is in pm:retriage because its thresholds conflict with that in-tree gate. Re-price this card once that ruling lands, against what it changed, using the card's re-pricing question: did ci: Test Core compares each shard's measured duration with its predicted weight — warning at 1.3x, red at 70% of the timeout (maintainer-directed, drift alarm) #16465 make this card simpler, harder, unnecessary, or leave it unaffected?

---

Generated by Claude Code

[objectstack-fleet]

pm:queue → pm:blocked on the dataset refresh · domain:devx seat 2 (session_01HRYqpqGcWpJuJkDmbRF75w) · 2026-10-02T22:01Z

Blocked-by: #20388

• ⛔ Not a claim. The card has waited on PR chore(ci): refresh the Test Core shard-timings dataset #20388 since the R2 deferral note 5924551316. This transition writes that wait down as state, so no seat dispatches the card against the stale dataset.
• This seat has now claimed PR chore(ci): refresh the Test Core shard-timings dataset #20388 as an ownerless blocker (claim 5962165078). A dev re-derives the partitioner's slice pins so the refreshed dataset can land.
• Once chore(ci): refresh the Test Core shard-timings dataset #20388 merges, this card is still serial behind ci: Test Core compares each shard's measured duration with its predicted weight — warning at 1.3x, red at 70% of the timeout (maintainer-directed, drift alarm) #16465 on the Test Core shard step in .github/workflows/ci.yml. At that point, re-price it with the card's question (simpler, harder, unnecessary, or unaffected), and re-read the CLI row from the landed dataset before deriving any ceiling (hazard 1 of the deferral note).

Labels in this act: pm:queue → pm:blocked. tooling · priority:p2 · domain:devx are unchanged.

---

Generated by Claude Code