finding(ci): `Test (shard 1/4)` runs 18.0–19.6 min against its own `timeout-minutes: 20`, so a run that drifts 3% longer is CANCELLED — and the merge queue reads cancelled as failure and dequeues a PR whose tests passed

[os-try-charles]

⚠️ STAND-IN TRIAGE, declared. Graded by the domain:devx @ objectui execution seat (session_013VGeMu3p6qEFWR6K6GGLaW, R58) under 〈多仓协调〉规则 4's stand-in clause. Vacancy read, ⛔ not assumed: triage seat objectstack#6015 reads 🔴 空缺 in body and title, updated_at 2026-09-14T05:50:57Z, no later round-open marker. ⛔ I stop the moment that seat is taken.

The defect

.github/workflows/ci.yml:752 sets timeout-minutes: 20 on the Test (shard ${{ matrix.shard }}/4) job. Shard 1's test step alone now takes 18–19.6 minutes. When the job crosses 20 minutes GitHub marks it cancelled — and, in this workflow's own words at :616:

the merge queue cannot tell cancelled from failure, and a pull request that had passed was dequeued

⇒ a PR whose tests passed is ejected from the merge queue.

The live instance, measured end to end

PR objectui#9487, merge group gh-readonly-queue/main/pr-9487-56223c96ab…, CI run 34836062981:

step	conclusion	duration
Set up job → Install dependencies (7 steps)	success	33s
Run tests (shard 1/4)	⭐ success	1165s = 19m25s
Run built-artifact pins (dist project)	⛔ cancelled	14s

Job wall clock 11:01:28 → 11:21:42 = 20m14s. 33 + 1165 = 1198s, leaving the final step ≈2 seconds of budget before the 1200s ceiling; it got 14 and was killed.

⭐ The tests passed. The job died on the step after them. The other 18 gates in the same merge group were all green. The PR was removed_from_merge_queue at 11:22:13Z, 30 seconds after the cancel.

⭐ This is not a one-off — the distribution is flat against the wall

Shard 1's duration across the 14 most recent merge_group CI runs, read from the jobs API:

bucket	runs
18.0 – 19.6 min (within 0.4–2.0 min of the ceiling)	11
12.7 – 14.8 min (runs where the relevance gate dropped heavy work)	3
20.2 min → CANCELLED	1 — this incident

⚠️ UPDATED — this table was superseded within minutes of being written, and the correction makes it WORSE. The figures above are the 14-run merge_group sample taken at filing. Measured since:

reading	at filing	measured since
longest successful shard-1 run	19.6 min	⭐⭐ 19.98 min — objectui#9501, shard 1 1199.0 s, success (domain:spec seat 5665084735, re-verified by this seat)
margin at its thinnest	~24 s	⭐⭐ 1.0 SECOND
shard-1 vs its siblings, same commit	(not sampled)	1199 s vs 964 / 805 / 749 s — 234 s longer than the next-longest, started within 1 s of each other
ceiling kills observed	1 (merge_group)	2 — the second on the pull_request event (objectui#9496, run 34841254342), whose runner said verbatim "exceeded the maximum execution time of 20m0s"
which leg is tighter	(assumed merge_group)	⛔ pull_request — median margin 48 s vs 72 s; worst succeeding run 11 s

⇒ any run drifting ~0.08 % longer is killed. ⛔ This is not a flake; it is a ceiling the job has grown into.

⚠️⭐ This body has now been overtaken THREE times in three hours — longest-successful 19.6 → 19.9 → 19.98 min, thinnest margin ~24 s → ~6 s → 1.0 s. ⭐ That is not a documentation problem; it is this card's own thesis showing up in its own edit history: the margin is collapsing fast enough that any written figure is stale before the next reader arrives.

⚠️ ⭐ Leaving the stale numbers above visible on purpose: the domain:spec seat read this body and quoted 19.6 min / ~24 s (5664458485) while a comment five minutes newer carried 19.9 / ~6. That is this very lane's most-filed defect class (objectui#9493, objectui#9502, objectui#9505) occurring in a card written by the seat that filed all three. ⇒ the durable reading is the one the instrument prints, ⛔ never the one a card body remembers.

⭐ Why it is shard 1 and not any shard — the asymmetry is structural

:936 attaches an extra step to shard 1 only:

if: steps.relevant.outputs.should_run == 'true' && matrix.shard == 1

and the comment at :930 says so plainly — "Shard 1 only, and NOT sharded itself … the cost is one package build in one shard."

Meanwhile :731 records that vitest shards by hashing each test file's path, so shard 1 receives a statistically equal quarter of the tests and then does strictly more work on top. ⇒ shard 1 is the longest job by construction, and it is the one closest to the ceiling. In this incident the other shards finished in 10.5, 14.7 and 16.8 minutes.

⛔ The obvious fix is already ruled out — read this before proposing it

:641, the file's own standing ruling from the 2026-08-26 objectui#6571 incident:

⛔ Raising timeout-minutes: 20 is not the fix and was ruled out on the card: a larger ceiling only buys a longer hang, still ending in cancelled, and lifting a gate's ceiling weakens the gate.

⚠️ That prior incident is a different cause with the same symptom and must not be conflated: there, 21 real steps passed and a runner-generated Post Turbo Cache step hung for 13m09s; the fix was splitting cache restore/save. Here nothing hangs — the work simply no longer fits. The restore/save split is already in place and is not implicated.

⛔ Not objectui#9271 — do NOT fold them

	this card	objectui#9271
lane	PR / merge_group test matrix	the coverage lane (push to main/develop)
ceiling	job timeout-minutes: **20** (:752)	job timeout-minutes: **40** (:1008)
mechanism	job wall clock exceeds the job ceiling	a per-test --testTimeout leaves thresholds unevaluated
symptom	cancelled job ⇒ PR dequeued	gate blind, not red

In this very merge group Test (coverage) and Test (coverage shard …) were skipped, so objectui#9271's --testTimeout=60000 at :1123 cannot have contributed. ⚠️ I checked this specifically because it was my first suspicion and it was wrong.

What it costs

Per occurrence: the queue is blocked at the head for ~20 minutes, every lane behind it waits, the PR needs a full re-run, and the signal arrives as cancelled — which reads as a failure nobody can attribute without opening the jobs API. ⭐ The reviewer-visible story is "CI failed" on a PR whose tests passed.

Suggested acceptance

1. Shard 1's total work fits inside its ceiling with a stated margin, and the margin is measured rather than assumed.
2. ⛔ timeout-minutes: 20 is NOT raised (ruled out at :641), ⛔ no test is skipped, disabled or quarantined, ⛔ the relevance gate is not widened to drop work.
   ⭐ The direction that does not weaken anything: the shard-1-only Run built-artifact pins (dist project) step does not belong inside a sharded test job — it is not sharded, it runs once, and it is what pushes the longest shard over. Moving it to its own job removes the asymmetry without touching a single budget.
3. The fix is validated against the merge_group event, ⛔ not only pull_request — this incident's shard 1 passed on the PR page and died in the merge group.
4. Every zero carries a control proven able to return non-zero in the same command; name the population in words.

⭐ Mechanical re-grade trigger — raise to p1 the moment either holds

1. a second PR is dequeued by a cancelled shard job; or
2. the median shard-1 duration over the last 10 merge_group runs crosses 19.5 min.

⇒ p2 today because one landing was lost and it is recoverable by re-queueing; p1 immediately once (1) or (2) is measured.

---

Generated by Claude Code

[os-try-charles]

Claim: PM loop round R58
Session: session_013VGeMu3p6qEFWR6K6GGLaW
Branch: claude/issue-9499-shard1-ceiling
Worktree: objectui-issue-9499
Domain: domain:devx
File surface: .github/workflows/ci.yml — and ⚠️ determine first whether the repair actually lives there; if it needs a second file, stop and say so rather than widening on your own.
Container & model: M, mode:subagent, model: default judgment tier (opus) — the central judgement (what margin is defensible, and which repair buys it without weakening anything) is exactly this tier's.
Clause-②: no
Thread-read: this card's body (filed by this seat from the live incident)
Serial constraints cleared: all 14 open PRs enumerated; ⛔ none touches .github/workflows/ci.yml. Control: the same reader finds objectui#9488 touching .github/workflows/performance-budget.yml, so it does see workflow files. ⚠️ objectui#9488 is HELD and touches a different workflow file — ⛔ do not touch its branch.

---

⛔ Zone 1 — RULINGS, not re-openable by you

1. ⛔⛔ Do NOT raise timeout-minutes: 20. Ruled out in the file's own words at :641: "a larger ceiling only buys a longer hang, still ending in cancelled, and lifting a gate's ceiling weakens the gate." ⛔ Not negotiable, and ⛔ not "just to 25 while we investigate".
2. ⛔ Do NOT skip, disable, quarantine or continue-on-error any test, and ⛔ do not widen the relevance/exclusion gate so the shards run less work. "Make the gate do less" is not a repair.
3. ⛔ Do NOT touch the coverage lane (timeout-minutes: 40, its own --testTimeout). That is objectui#9271's, it is in the maintainer's decision box, and it was skipped in the incident's merge group so it is not implicated.

⭐ The goal, stated as a property rather than a patch

Shard 1's total work fits inside its ceiling with a MEASURED, STATED margin. The deliverable is the margin and the evidence for it — ⛔ not a particular edit.

⚠️ Do not assume my hypothesis is the whole fix — I have reason to think it is not. The card suggests moving the shard-1-only Run built-artifact pins (dist project) step (:936, matrix.shard == 1) out of the sharded job, because shard 1 gets an equal quarter of the tests (vitest shards by path hash, :731) and then does strictly more work. That removes a real asymmetry. But the arithmetic says it is probably not sufficient: shard 1's test step alone ran 1165s = 19m25s in the incident and 19.2m on objectui#9429's head. Against a 1200s ceiling that leaves ~35 seconds — which is not a margin, it is the same cliff one step back.

⇒ Measure the margin that repair actually buys before recommending it, and if it is thin, say so and propose what closes it.

⭐ Explicitly permitted, and ⛔ not gate weakening: raising the shard count (e.g. 4 → 6). The same tests run; only the wall clock per job falls. No threshold moves, no test is dropped, and the coverage lane is separately sharded (:742 notes it has been sharded the same 4 ways since objectui#5403 — ⚠️ check whether the two counts are coupled before changing either). If you take this route, say what it costs in runner minutes.

Zone 2 — PM assumptions (⭐ measure; ⛔ do not inherit)

• A. I assume Run built-artifact pins (dist project) can live outside the sharded job. ⛔ Unverified — it may depend on state the shard produced. Read what it does first. If it genuinely needs to be inside a test job, the asymmetry is structural and the repair is elsewhere; that is a finding, not a failure.
• B. I assume the shards are roughly balanced apart from that step. ⛔ Unverified. In the incident: shard 1 19m25s, shards 2/3/4 at 16.8 / 14.7 / 10.5 min. ⭐ That spread is wide — shard 4 is half of shard 1. Path-hash sharding balances file COUNT, not file COST. If the imbalance is the real story, the repair may be to shard by something better, and that is a more valuable answer than moving a step.

Acceptance

1. The margin, measured and stated in words, for shard 1 specifically, on both pull_request and merge_group.
2. ⚠️ Validated against merge_group, not only pull_request. The incident's shard 1 passed on the PR page and died in the merge group; :803's objectui#8857 note records the same asymmetry biting before. A green PR page is ⛔ not evidence here.
3. gates_weakened: NONE — and since this card is about a ceiling, state explicitly which ceilings/timeouts exist in the touched file before and after, and that none moved.
4. Every zero carries a control proven able to return non-zero in the same command; name every population in words.
5. ⚠️ A CI change affects every PR in the repo. Keep it minimal and say what could regress.

⭐ An explicitly acceptable outcome

⛔ Do not force a PR. If the measurement shows the repair is a structural change to how the suite is sharded — or that it needs a ruling about runner spend — then premise_still_valid: true + the measurement + a named fork with NO PR is a complete and welcome delivery. ⭐ "Here is why 19m25s is the real number and here is what would actually move it" is worth more than a patch that buys 35 seconds.

⛔ Deliver a DRAFT PR only if the repair is squarely inside this lane and the margin is proven. ⛔ Never flip ready, enqueue, or arm auto-merge. Post your structured JSON report as a comment on objectui#9499 first.

⛔ Never measure on the shared checkout /home/user/objectui. ⚠️ Your container may be a shallow clone; if so git log -S gives only false negatives and a git log -1 date may be just the shallow horizon. ⚠️ The job-log blob host has been refused for three sibling seats' egress — check yours rather than assuming, and note that the check-runs annotations and jobs API endpoints did work for this seat.

Commit trailer, exactly these two lines and no other attribution:

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013VGeMu3p6qEFWR6K6GGLaW

---

Generated by Claude Code

[os-try-charles]

⭐ A sharper number, measured live 20 minutes after this card was filed: the margin is ~6 seconds, not ~24

domain:devx @ objectui seat, 2026-09-14T11:55Z. Posting because it changes the card's own headline figure, and the dispatched dev should size the repair against this number rather than the one in the body.

objectui#9487's second queue attempt, merge group pr-9487-56223c96abdb0f, CI run 34838980238 (created 11:35:29Z). I watched Test (shard 1/4) live as it approached the ceiling:

11:54:52Z  shard1 = in_progress   19.4m     <- ceiling 20.0m
11:55:13Z  shard1 = in_progress   19.7m
11:55:29Z  shard1 = completed/success  19.9m

⇒ it cleared a 20.0-minute ceiling at 19.9 minutes. Every other job in the group was already green (shards 2/3/4 at 17.7 / 12.9 / 11.9 min, Type Check 1.9m, Build & E2E 1.1m).

What this does to the card's figures

figure	in the card body	measured now
longest successful shard-1 run	19.6 min	19.9 min
implied margin at the thinnest	~24 s	⭐ ~6 s
the same job, one attempt earlier	cancelled at 20m14s	—

⭐ The same commit, the same shard, twice, 34 minutes apart: 20m14s (cancelled) and 19.9m (success). ⛔ That is not a flake to be retried past — it is a job whose runtime distribution straddles its own ceiling, and which lands on either side essentially at random.

⛔ It also stops being only this card's problem

pr-9487 is at the HEAD of the merge queue, and pr-9494, pr-9429 and pr-9498 are each built speculatively on top of it. ⇒ when the head times out, that whole chain is rebuilt. Measured consequence: main did not advance between 10:55:40Z and 11:55Z — ⛔ an hour with no merges, for a repo with four PRs queued and CI green on all of them.

⇒ that is the "20 minutes of head-of-line blocking for every lane" line in the card body, now with a number against it.

⛔ What this does NOT change

• ⛔ timeout-minutes: 20 still may not be raised (ci.yml:641). A 6-second margin is an argument about the work, ⛔ not about the ceiling.
• ⛔ Trigger (1) has not fired — objectui#9487 was dequeued once, not twice, and it has now cleared. This card stays p2.
• ⭐ It strengthens the dispatch's warning that moving the shard-1-only step is probably not sufficient: at 19.9m for the job, the ~35s that step costs is the entire difference between the two attempts. Removing it would likely have made both attempts pass — and would still leave the next slow run on the wrong side of the line. The repair has to reduce the test time or spread it, not just shave the tail.

---

Generated by Claude Code

[claude]

os-dev-report
{
"issue": 9499,
"status": "needs_decision",
"branch": "claude/issue-9499-shard1-ceiling",
"pr": null,
"premise_still_valid": true,
"summary": "The card's premise holds and is now WORSE than filed: a SECOND ceiling kill happened while I was measuring. Both PM assumptions were tested; A is confirmed, B is falsified; the PM's own hypothesis is falsified quantitatively; and the repair the arithmetic points at is BLOCKED on a maintainer-only settings surface, which is why this returns needs_decision with a named fork and NO PR (the card's explicitly-acceptable outcome). NO FILE WAS EDITED: git diff against BASE 56223c9 and git status --porcelain (tracked paths) are both empty, so gates_weakened is NONE by construction. (1) MARGIN, MEASURED ON BOTH EVENTS. Population: the 14 most recent completed merge_group ci.yml runs (2026-09-14 07:30Z to 11:01Z, 56 shard jobs) and the 16 most recent completed pull_request runs (09:53Z to 12:02Z), of which 14 are full 4-shard runs after excluding 2 whole-run concurrency cancels. merge_group: shard-1 JOB median 1128 s, so the median margin against the 1200 s ceiling is 72 seconds (6.0 percent); the worst run that still SUCCEEDED was 1173 s, a margin of 27 seconds (2.2 percent); one ceiling kill (run 34836062981, the card's incident). pull_request: shard-1 JOB median 1152 s, margin 48 seconds (4.0 percent); worst SUCCEEDING run 1189 s, margin ELEVEN SECONDS (0.9 percent); one ceiling kill (run 34841254342 at 12:02Z today on PR objectui#9496, job 1205 s, Run tests (shard 1/4) SUCCEEDED at 1112 s and the job was killed during the dist-pins step). ⭐ CORRECTION TO THE CARD'S FRAMING: the pull_request leg is not the safer one. It is TIGHTER than merge_group on every statistic, and it fell off the cliff today too. Test (shard 1/4) is a required context (see (5)), so that cancel blocks objectui#9496 from merging exactly as a dequeue would. That is two ceiling kills in one morning across 28 full runs. Whether this satisfies the card's re-grade trigger 1 is the PM's call, stated precisely so it can be graded rather than assumed: trigger 1 says a SECOND PR DEQUEUED, and this second kill blocked a PR PRE-QUEUE instead of dequeuing it. Trigger 2 is NOT met: the median shard-1 duration over the last 10 merge_group runs is 1054 s (17.6 min) on the test step and 1140 s (19.0 min) on the job, both under 19.5 min. (2) THE PM's HYPOTHESIS IS FALSIFIED, WITH THE RIGHT NUMBER FOR THE STEP. The dist-pins step does not cost 14 s; 14 s is merely what the cancelled run got before it was killed. Measured across all 28 runs it costs 31 to 58 s, median 53 s on merge_group and 54 s on pull_request. Subtracting each run's OWN dist duration from its own shard-1 job: merge_group worst job 1214 -> 1200 s and median 1128 -> 1074 s, i.e. the card's incident is STILL AT ITS CEILING with about one second to spare and would still have been a coin flip; pull_request worst job 1205 -> 1147 s and median 1152 -> 1097 s, i.e. today's second kill WOULD have been avoided. So the repair prevents one of the two observed kills and not the other, and leaves the job running at 90 to 91 percent of its ceiling. It is a real 53-second improvement and it is not a margin. (3) ASSUMPTION A IS CONFIRMED BY RUNNING IT, not by reading it. pnpm test:dist is turbo run test:dist --filter=@object-ui/components; turbo.json gives that task dependsOn: [\"build\"] (the package's OWN build, not ^build) and cache: false, and the package script is OBJECTUI_DIST_PINS=1 vitest run --root ../.. --config vitest.config.mts --project dist, an env-gated project that exists only when that variable is set. I ran it in the fresh worktree where NO shard test had run and where packages/components/dist was ABSENT beforehand (that absence is the control: a green could not have come from a bundle somebody else built). Exit 0, 2 test files, 8 tests, and packages/components/dist exists afterwards. It consumes nothing a shard produces and CAN live in its own job. (4) ASSUMPTION B IS FALSIFIED: THE SHARDS ARE NOT BADLY IMBALANCED. pnpm exec vitest list --filesOnly collects 3122 specs today (dom 1846, unit 1143, @object-ui/console 99, dom-heavy 34). Replaying vitest 4.1.10's own BaseSequencer.shard() (sha1 of the root-relative path, sort by hex hash, slice equal ranges) over that live list gives 781/781/780/780 specs at 4 shards and 521/521/520/520/520/520 at 6 - the file-count spread is ONE SPEC at every shard count I tried, so count balance is already exact. The residual is cost tilt, and it is modest: the per-shard MEAN of the test step over the 14 merge_group runs is 997 / 902 / 909 / 833 s, so the worst shard runs 9.6 percent above the four-shard mean, not 30 percent. The incident's 19m25s-versus-10m30s spread is ONE RUN's realisation, not the structure: in run 34833069453 shard 1 was the FASTEST of the four. Shard 1 does draw slightly more of the expensive project (473 dom specs versus 448 on shard 4) but that composition difference does not explain the tilt either - shards 1 and 3 have near-identical composition (503 vs 501 dom-ish specs) and still differ by 88 s, so the tilt is idiosyncratic per-file cost clustering. A two-parameter per-project cost fit against the four shard means is DEGENERATE (it returns a negative cost for unit, because dom-count and unit-count are collinear at 781 specs per shard), so I am NOT reporting a per-project cost split - the CI data cannot identify one. (5) ⛔ THE BLOCKER, AND IT IS THE REASON THIS IS needs_decision. Raising the shard count is the only lever that reaches a defensible margin without weakening anything - and it RENAMES FOUR LIVE REQUIRED STATUS CHECKS. GET /repos/objectstack-ai/objectui/rules/branches/main returns a required_status_checks rule containing exactly: Lint, Type Check, Build & E2E, Test (shard 1/4), Test (shard 2/4), Test (shard 3/4), Test (shard 4/4), Build Docs, Changeset Declaration - with strict_required_status_checks_policy: true, and the merge_queue rule carrying check_response_timeout_minutes: 60. Change 4 to 6 and those four contexts are never produced again: every pull request in the repository blocks forever on a check that cannot report, and every merge-group build burns 60 minutes and fails. Only the maintainer can edit that ruleset (my token reads it but GET branches/main/protection answers 403 Resource not accessible by integration). ⚠️ This directly CONTRADICTS what the repository tells its own authors: scripts/dependabot-merge-gate.mjs says the required set is demonstrably not carrying the shards today and content/docs/guide/ci-cd-pipeline.md says it is a repository-settings surface nothing here can read. Both were true when written (the evidence was objectui#4959, where a merge happened while all four shards were in_progress) and both are false now - the ruleset's updated_at is 2026-08-24, after that reading. An author who trusts either sentence will re-shard and take the repository down. Filed separately below. (6) ⭐ THE ANSWER THE CARD ASKED FOR - WHY 19m25s IS THE REAL NUMBER AND WHAT WOULD ACTUALLY MOVE IT. Neither the dist step nor the shard imbalance is the story. The story is that THE SUITE IS GROWING EXPONENTIALLY. Test-file count on origin/main, counted with git ls-tree -r --name-only at six dated first-parent commits (the clone is NOT shallow - git rev-parse --is-shallow-repository is false, so this walk is sound): 267 at -90 days, 548 at -60, 1486 at -30, 2275 at -14, 2660 at -7, 3122 today. That is +17.4 percent per week over the last 7 days, +17.1 percent over 14 and +18.9 percent over 30 - consistent, compounding, roughly a doubling every 27 days. And cost tracks count almost exactly: the suite's total test-step time over the four shards, taken from CI on the same three dates, is 2546 s / 3344 s / 3614 s, i.e. 1.119 / 1.257 / 1.158 seconds per test file. ⇒ THE CEILING IS NOT BEING OVERRUN BY A STEP OR BY AN IMBALANCE. It is being overrun because a fixed 20-minute wall is standing in front of a suite that adds a sixth of itself every week. At that rate every shard count is a dated coupon: 6 shards buys 2.4 to 2.9 weeks of median headroom, 8 shards 3.9 to 4.3 weeks, 10 shards 4.9 to 5.4. ⇒ The durable repair is not a number, it is to STOP WELDING THE SHARD COUNT TO A MAINTAINER-ONLY SETTINGS SURFACE - see the fork.",
"tests": "NO CODE CHANGED, so there is no build, no typecheck and no gate run to report - git diff 56223c96abdb0f42d48916213da1d5537bd57bc1 and git status --porcelain (tracked paths) are both EMPTY, which is also the proof for gates_weakened: NONE. What was run is measurement. ⭐ CONTROLS, one per zero, each proven able to return non-zero in the SAME command. (a) REQUIRED-CONTEXT READ. GET /repos/objectstack-ai/objectui/rules/branches/main returns 5 rules including required_status_checks with the 9 contexts listed in summary (5). CONTROL, same command, same token, one argument changed: GET /rules/branches/zzz-no-such-branch-9499 returns 200 []. So the reader distinguishes a branch with rules from a branch with none, and the non-empty answer is a reading rather than a default. The same fact is corroborated by a second endpoint, GET /rulesets/11776024 (enforcement active, source_type Repository). (b) CEILING-KILL COUNT. My classifier separates a ceiling kill (ONE shard cancelled while its siblings passed) from a whole-run concurrency cancel (cancel-in-progress: true, all four cancelled together). It reports exactly 1 ceiling kill per event. CONTROL: the SAME classifier over the SAME rows reports 2 whole-run concurrency cancels on pull_request - run 34838928117 (all four shards cancelled at 726 to 728 s) and run 34833785958 (all four at 275 to 278 s) - and 0 on merge_group. It therefore both finds cancels and refuses to miscount them, so 1 is a measurement and not a blind reader. Had I not applied it, this report would have claimed 3 ceiling kills on pull_request and two of them would have been false. (c) ASSUMPTION A. pnpm test:dist in the fresh worktree: EXIT 0, Test Files 2 passed, Tests 8 passed, wall 14 s (local, with turbo cache hits on the dependency builds - the CI figure is the 31 to 58 s measured above, not this one). CONTROL: packages/components/dist did NOT exist before the command (asserted and printed before running) and DOES exist after, so the green cannot have come from a bundle the step did not build, which is the exact dependency the assumption was about. (d) THE SPEC POPULATION. pnpm exec vitest list --filesOnly exits 0 with 3122 lines; independently git ls-tree -r --name-only HEAD | grep -cE '\\.test\\.(ts|tsx)$|eslint-rules/.*\\.test\\.js$' also returns 3122 on the same commit - two unrelated readers agreeing. CONTROL that the tree walk is not answering a constant: the same expression returns 267, 548, 1486, 2275 and 2660 at the five older commits. (e) THE ci.yml TEST READERS. Per AGENTS.md line 399, git grep -l 'ci\\.yml' -- '**/__tests__/**' '**/*.test.*' enumerates 51 test files; narrowing to those that also mention shard / timeout-minutes / test:dist leaves 12, of which the load-bearing ones are scripts/__tests__/ci-cd-pipeline-doc.test.ts, scripts/__tests__/dependabot-merge-gate.test.ts and scripts/__tests__/merge-queue-reporting.test.ts. Both counts are non-empty, so the search is not silently matching nothing. ⛔ I did NOT run them, and that is deliberate and declared rather than skipped: I changed no file they read, so running them would measure origin/main, not my work. They are named because they are the COST of the fork - see open_questions. (f) THE PER-FILE FLOOR. The heaviest single test file observed is 23.8 s (packages/app-shell/src/views/metadata-admin/ResourceEditPage.serverRefusalGate.test.tsx), from a local vitest run I started and then STOPPED at 554 of 3122 files because its per-file metric excludes the per-file setup cost that actually dominates in CI; that number is therefore a LOWER bound on the floor over a PARTIAL population, stated as such. It is two orders of magnitude below the 1200 s ceiling, so no single file sets a floor that blocks any shard count in the 4-to-10 range. ⚠️ NOT MEASURED, with reasons. (i) Per-project cost split (what hoisting unit into its own job would buy): the CI fit is degenerate (see summary (4)) and the local vitest run --project unit I started to price it directly produced zero completed-file lines in 560 s and was stopped to give the shared container back. So the hoist unit variant in the fork is UNPRICED. (ii) Job logs: the Actions log blob host is refused for this seat too - productionresultssa16.blob.core.windows.net:443 connect_rejected - so every duration here comes from the jobs API step timestamps, which did work. (iii) No 6-shard run exists anywhere, so every K-not-equal-4 figure is a PROJECTION from the measured suite total, the measured per-run tilt inflated by sqrt(K/4) for the smaller file count, and the measured 28 s per-job setup - NOT a measurement. Its credibility is that the same model reproduces the K=4 reality it was not fitted to: predicted worst shard job 1077 s versus measured median 1128 s on merge_group, and 1156 s versus 1152 s on pull_request.",
"mcp_calls": "0 - no MCP GitHub tool was called. Every GitHub read went through the REST proxy with curl and the environment GITHUB_TOKEN.",
"api_writes": "2 - (1) git push -u origin claude/issue-9499-shard1-ceiling, the empty routing probe, which returned a new branch and no 403; (2) POST /repos/objectstack-ai/objectui/issues/9499/comments carrying this report. ⛔ No POST /pulls (no PR, deliberately), no labels write (nothing to label without a PR), no PATCH of any body.",
"open_questions": [
{
"question": "THE FORK. Shard 1 cannot be brought under its ceiling with a durable margin without raising the shard count, and raising it renames four LIVE required status checks (Test (shard 1/4) through Test (shard 4/4)), which only the maintainer can edit in the repository ruleset. Which route does the maintainer take, and does the seat get to do the workflow half?",
"options": [
"A. MOVE THE DIST-PINS STEP ONLY, no shard-count change. Measured value: 53 to 54 s. Median shard-1 job 1128 -> 1074 s (merge_group) and 1152 -> 1097 s (pull_request); prevents today's pull_request kill and does NOT prevent the card's merge_group incident (1214 -> 1200 s, one second under the ceiling). Renames nothing, so no ruleset edit. COST: 3 files, not 1 - .github/workflows/ci.yml, plus scripts/dependabot-merge-gate.mjs (the new job's context must be classified or dependabot-merge-gate.test.ts fails its partition assertion in the produced-but-unclassified direction), plus content/docs/guide/ci-cd-pipeline.md (ci-cd-pipeline-doc.test.ts pins the job table). Adds one check run to every PR in the repo. REGRESSION RISK: the new job pays its own 28 s checkout+install, so total runner time rises about 30 s per run while shard-1 wall clock falls 53 s. HORIZON at the measured +17.4 percent per week: about 0.4 weeks. ⇒ this is the patch the card warned against - it buys weeks-of-nothing.",
"B. RAISE THE SHARD COUNT TO 6 OR 8, with a coordinated maintainer ruleset edit. Projected worst shard job at 6: 759 s merge_group / 818 s pull_request, margins 37 and 32 percent; at 8: 598 / 647 s, margins 50 and 46 percent. RUNNER COST is the cheap part - +1.5 percent at 6 shards, +3.0 percent at 8, because sharding splits a suite whose cost is per-file and only the ~28 s per-job setup is duplicated. COST: the same 3 files as A plus scripts/check-required-check-set.mjs (WATCHED_CONTEXTS holds the four shard spellings) plus a maintainer ruleset edit. ⛔ ORDERING IS NOT FREE: the old contexts and the new ones can never both be satisfiable, so there is no ordering in which nothing blocks. The only safe sequence is - maintainer REMOVES the four shard contexts from required, the workflow PR merges, maintainer ADDS the new spellings. HORIZON: 2.4 to 2.9 weeks at 6, 3.9 to 4.3 at 8.",
"C. ⭐ UNWELD THE SHARD COUNT FROM THE RULESET, then B becomes a one-line change forever. Add one aggregator job (Test) with needs: [test] and if: always() that fails unless every shard concluded success, and make THAT the single required context in place of the four per-shard ones. The shards keep reporting their own check runs and keep fail-fast: false, so per-shard failure attribution is unchanged; they simply stop being names the ruleset knows. After this one maintainer edit the shard count is an ordinary workflow constant and every future re-shard is a pure PR. ⚠️ The trap this must be written against, named because it is how this class of aggregator goes silently green: a SKIPPED required check can count as success, so the aggregator must carry if: always() and assert each shard's result == 'success' explicitly rather than relying on needs alone. COST: the files in B, plus the ruleset edit, minus the need to ever do that ruleset edit again. ⇒ my recommendation, combined with B at 8 shards and with A folded in (moving the dist step is right on its own merits once someone is editing this job anyway - it is the one genuine structural asymmetry).",
"D. DO NOTHING about the shard count and re-grade the card. Defensible only if the maintainer expects the +17.4 percent per week growth to stop; at today's rate the shard-1 job crosses its ceiling on the median run within about a week on pull_request, and it has already crossed twice today."
],
"recommendation": "C plus B-at-8 plus A, in one change, because it is the only option whose value does not expire. A and B are the same kind of thing - a constant-factor division of a quantity that is multiplying by 1.174 every week - and they buy 0.4 and 3.9 weeks respectively. C costs one extra job and the SAME single maintainer ruleset edit that B already requires, and it converts every future occurrence of this card from needs_decision plus a settings change into a one-line pull request. ⛔ I did not open a PR for any of this: the workflow half of B and C is unlandable until the maintainer decides about the ruleset (merging it first is what blocks every PR in the repository), and A alone is the 53-second patch the card explicitly said is worth less than the measurement. If the maintainer picks C, this seat can deliver the workflow half the moment the ruleset order is agreed."
},
{
"question": "SECOND-ORDER, for the same decision. A 20-minute ceiling is an absolute standing in front of a suite growing +17.4 percent per week; even at 8 shards it is re-breached in about 4 weeks. Should the shard count be DERIVED from the suite size rather than hand-chosen - and if so, does that not require option C first, since a derived count cannot be a fixed set of required-context names?",
"options": [
"A. Hand-chosen count, revisited when it breaks (today's posture, which is what produced this card).",
"B. Hand-chosen count plus a report-only patrol that reds when the worst shard crosses, say, 70 percent of its ceiling - so the next occurrence is a scheduled repair rather than a dequeued PR.",
"C. Count derived at runtime from the collected spec count (option C above is a prerequisite - a derived count cannot be a fixed list of required-context spellings)."
],
"recommendation": "B now, on top of option C above, and C-here only if the growth rate holds for another month. B is cheap, changes no threshold, and converts this failure mode from a PR is dequeued and a human reads the jobs API to find out why into a gate said so first - which is the same repair shape the file already chose at :693 and :1626 for its cache steps."
}
],
"out_of_scope_findings": [
"to file (class a, reproducible with a named probe; dedupe words: required status checks / ruleset / rules-branches / shard contexts / dependabot-merge-gate) - TWO PLACES IN THE TREE TELL AUTHORS THE SHARD JOBS ARE NOT REQUIRED CHECKS, AND BOTH ARE FALSE TODAY. scripts/dependabot-merge-gate.mjs's header says the required set is demonstrably not carrying the shards today, and content/docs/guide/ci-cd-pipeline.md says it is a repository-settings surface nothing here can read. PROBE, one command: GET /repos/objectstack-ai/objectui/rules/branches/main returns a required_status_checks rule containing Test (shard 1/4) through Test (shard 4/4); CONTROL, same command on rules/branches/zzz-no-such-branch-9499, returns 200 []. Both sentences were true when written (objectui#4959: a merge landed while all four shards were in_progress) and the ruleset's updated_at is 2026-08-24, after that. This is AGENTS.md #9's exact shape - a derived-once claim that no longer re-derives - and the harm is not cosmetic: an author who trusts either sentence renames the shard jobs and every pull request in the repository blocks on a check that can never report. The repair is to point both at the endpoint instead of restating its answer. ⛔ Not fixed here: it is a different file from this card's surface and it is the premise of the ruling this card is returning for.",
"noted, not filed: the comment at .github/workflows/ci.yml:930 prices the shard-1-only dist-pins step as the cost is one package build in one shard with no figure; measured across 28 CI runs it is 31 to 58 s (median 53 s on merge_group, 54 s on pull_request). Not a defect - it never asserted a number, so there is nothing that has gone stale. Successor: whichever PR implements the fork above will be editing exactly this step, and the figure belongs in that PR rather than in a card of its own.",
"noted, not filed: the incident table on this card reads the dist-pins step as costing 14 s. It cost 14 s only because the job was killed during it; its real cost is the 31 to 58 s above. This matters because 14 s makes the PM's proposed repair look even thinner than it is, and 53 s is what it actually buys. Successor: the same PR; corrected in this report rather than filed, since the card is about to be re-graded anyway."
]
}

---

Generated by Claude Code

[os-try-charles]

⭐⭐ MEASUREMENT ACCEPTED · p2 → p1 · ⇒ needs-user-decision. ⛔ And THREE of my own claims on this card are refuted.

domain:devx @ objectui seat, session_013VGeMu3p6qEFWR6K6GGLaW, R58, 2026-09-14T12:4xZ. ⛔ No PR, by design — and that is the correct delivery, exactly as this card's dispatch said it would be.

---

⛔ First: what I got wrong, before anything I got right

1. ⛔ The card's incident table says the dist-pins step costs 14 s. It does not.

14 s is only what the killed run got before the axe fell. Measured across 28 CI runs: 31–58 s, median 53 s (merge_group) / 54 s (pull_request). Verified by me on today's second kill: that run's dist step completed success in 58 s.

⇒ my number made my own proposed repair look thinner than it is — it actually buys 53 s, not 14 — and I published it as a reading. It was an artefact of a truncated job.

2. ⛔ I framed pull_request as the safer leg. It is the TIGHTER one.

leg	median shard-1 job	median margin	worst succeeding run	that margin
merge_group	1128 s	72 s (6.0%)	1173 s	27 s
pull_request	1152 s	48 s (4.0%)	1189 s	⭐ 11 s

⇒ eleven seconds. And the pull_request leg fell off the cliff today too.

3. ⛔ My assumption B — "the shards are imbalanced" — is FALSIFIED.

Vitest's own BaseSequencer.shard() replayed over today's live spec list gives 781 / 781 / 780 / 780 at 4 shards — a one-spec spread, so count balance is already exact. Per-shard mean test-step time is 997 / 902 / 909 / 833 s ⇒ the worst shard is 9.6 % above the mean, ⛔ not 30 %. The incident's 19m25s-vs-10m30s spread was one run's realisation: in run 34833069453 shard 1 was the fastest of the four.

⭐ And the dev refused to over-claim where the data could not carry it: a per-project cost fit is degenerate (collinear at 781 specs/shard, returns a negative cost for unit), so no per-project split is reported. That refusal is worth more than a number would have been.

---

⭐ The trigger question — and it is mine to answer, so here it is

A second ceiling kill occurred at 12:02:24Z, run 34841254342, PR objectui#9496 (pull_request): shard-1 job 1205 s, Run tests succeeded at 1112 s, killed during the dist step. Verified by me.

My written trigger says: "a second PR is dequeued by a cancelled shard job." ⚠️ This one was blocked pre-queue, not dequeued — and the dev flagged the mismatch rather than quietly claiming the trigger, which is exactly right.

⇒ RULING: the trigger fires. Test (shard 1/4) is a required status check — I verified the ruleset myself — so a cancelled shard blocks that PR from merging exactly as a dequeue would. The harm the trigger was written to detect has now happened twice in one morning across 28 full runs.

⛔ My trigger's wording was too narrow, and that is my error, not a technicality to hide behind: I wrote "dequeued" because I believed the risk lived in the merge queue. It lives in both, and more tightly in the leg I called safer. ⇒ the trigger is amended to read: "a second PR is blocked from merging by a cancelled shard job, on either event."

⇒ priority:p2 → priority:p1.

---

⭐⭐ The answer the card actually asked for — and it is none of the things I proposed

The suite is growing exponentially.

Test files on main, counted at six dated first-parent commits in a verified non-shallow clone:

−90 d	−60 d	−30 d	−14 d	−7 d	today
267	548	1486	2275	2660	3122

+17.4 % per week (and +17.1 % / +18.9 % over 14 and 30 days — consistent, compounding, doubling every ~27 days). Cost tracks count almost exactly: 1.119 / 1.257 / 1.158 seconds per test file across three dates.

⇒ ⭐ The ceiling is not being overrun by a step, and not by an imbalance. It is a fixed 20-minute wall standing in front of a suite that adds a sixth of itself every week. Every shard count is a dated coupon: 6 shards buys 2.4–2.9 weeks, 8 buys 3.9–4.3, 10 buys 4.9–5.4.

⇒ my proposed repair (move the dist step) buys ≈0.4 weeks. It is the patch this card's own dispatch warned against, and the dev priced it instead of accepting it.

---

⛔ Why this ESCALATES rather than being ruled here

The only lever that reaches a defensible margin is raising the shard count — and that renames four LIVE required status checks. Verified independently by me:

required_status_checks: Lint · Type Check · Build & E2E ·
  Test (shard 1/4) · Test (shard 2/4) · Test (shard 3/4) · Test (shard 4/4) ·
  Build Docs · Changeset Declaration
strict_required_status_checks_policy: true      merge_queue check_response_timeout_minutes: 60

(CONTROL: the same endpoint on a branch with no rules returns [], so this is a reading.)

⛔ Change 4 → 6 and every pull request in the repository blocks forever on contexts that can never be produced again, and every merge-group build burns 60 minutes and fails. Only the maintainer can edit that ruleset (this seat's token reads it; branches/main/protection answers 403).

⚠️ ⛔ And the ordering is not free: the old and new context names can never both be satisfiable, so there is no sequence in which nothing blocks. The only safe order is maintainer removes the four → the workflow PR merges → maintainer adds the new spellings.

⇒ this hits the manual floor on two counts — a permissions/settings boundary this seat cannot touch, and an action that is destructive and hard to reverse if mis-ordered. ⛔ Ruling it here would be this seat deciding something it cannot execute and cannot undo. needs-user-decision.

The fork, as the maintainer will need it

	route	what it buys	cost
A	move the dist-pins step to its own job	53 s. Prevents today's pull_request kill; ⛔ does not prevent the merge_group incident (1214 → 1200 s, one second under)	3 files; no ruleset edit; horizon ≈0.4 weeks
B	raise shards to 6 or 8	margins 32–37 % at 6, 46–50 % at 8; runner cost only +1.5 % / +3.0 %	4 files + a maintainer ruleset edit; horizon 2.4–4.3 weeks
C ⭐	unweld the shard count from the ruleset: one aggregator job (needs: [test], if: always(), asserting each shard result == 'success') becomes the single required context in place of the four	every future re-shard becomes a one-line PR	same single ruleset edit as B — but only once, ever
D	do nothing, re-grade	—	defensible only if the +17.4 %/week growth is expected to stop

Dev's recommendation: C + B-at-8 + A in one change — because A and B are constant-factor divisions of a quantity multiplying by 1.174 weekly, and only C's value does not expire.

⚠️ A trap the dev named, and it is the one that would make C silently useless: a skipped required check can count as success, so the aggregator must carry if: always() and assert each shard's result explicitly, ⛔ never rely on needs alone.

This seat's view, offered and ⛔ not decided: C, because it is the only option that stops this card from recurring, and it costs the same single maintainer edit B already needs. ⛔ But the ruleset edit and its ordering are yours — and if you pick C, this seat can deliver the workflow half the moment the order is agreed.

⛔ A separate, sharper hazard found on the way — filed, not buried

Two places in the tree tell authors the shard jobs are NOT required checks, and both are false today. An author who trusts either one renames the shard jobs and takes the repository down. Filed as objectui#9502.

gates_weakened: NONE — by construction: git diff against base and git status --porcelain are both empty. Nothing was edited.

---

Generated by Claude Code