[objectstack-fleet]

Requested by Elon · project thread

Part of #25870. This PR carries two steps: (1) wall-based bin placement, and (2) the refreshed dataset with the CLI cut into 4 slices. #25870 stays open, because its acceptance is measured on 3 consecutive spec-touching PRs after landing. The prediction below is not that measurement.

Supersedes #25960. It carries the shard-timings-refresh lane's commit 92343f5 (chore(ci): refresh the Test Core shard-timings dataset) unchanged. That refresh cannot land alone, because pin 3c refuses it at 3 slices (step 2).

Diagnosis — which of the three, with run ids

The long shards are always the three that carry a @objectstack/cli file-level slice. Read from gh api …/runs/N/jobs step timings on 56 pull_request runs (2026-10-25 18:54Z – 2026-10-26 05:44Z), and from the slice leg's own Duration / turbo Time: lines on the 18 slice-shard jobs of six packages/spec-touching runs.

The slowest shard on a spec-touching PR breaks down like this (minutes):

run (spec PR)	slowest	setup	closure	whole-package leg	cli slice leg (turbo Time:)
40274911131 (#25903)	5/8 28.8	~1.5	6.0	5.7	15.4
40271593540 (#25944)	4/8 28.1	~1.5	5.5	3.4	17.3
40269339195 (#25813)	4/8 28.5	~1.5	5.6	3.4	17.5
40266487909 (#25903)	5/8 28.5	~1.5	5.9	5.6	15.4
40263851511 (#25813)	3/8 26.8	~1.5	6.3	4.5	14.3
40261969569 (#25830)	3/8 25.7	~1.5	6.0	4.3	13.6

(whole-package leg = Run this shard's tests minus the slice leg's turbo Time:.)

Three causes, all real, in this order of size:

1. The cli slice leg itself, 13.6–17.5 min. vitest cuts the CLI by file COUNT (BaseSequencer.shard: sha1 of the path, then equal-count chunks), so the three slices are not equal: across the six runs they measured 518–1047 s, the heaviest ~1.27× the mean (~820 s). Total cli 2406–2542 s against a pinned 2899 s (0.83–0.88×).
2. The dependency closure, 5.5–6.3 min, against 0.4–1.0 min on shards that skip declarations. @objectstack/cli is in ci.yml's DTS_READERS, so every slice shard builds the whole cli closure WITH .d.ts, and a PR run reads no remote cache, so that build is cold (ci.yml: local cold closure 5m59s with declarations, 1m24s without).
3. A whole-package leg of 2.2–5.7 min run before the slice — the partitioner's doing. partition() balanced bins by their SUM of predicted seconds. A slice runs serially after the four-wide whole leg, so the step is ~ wholeSum / 2.9 + slice (the ci(test-shards): widen Test Core from 6 to 8 shards once @objectstack/spec is file-sharded — the "6 is enough" arithmetic predates the cli slices (full-battery slowest shard ≈ 1937 s → ≈ 1452 s) #25376 wall model). Balancing sums filled every slice shard up to the mean with ~900 s of whole packages: predicted step 1277 s on the three slice shards against 643 s on the other five (committed dataset, full list).

Stale weights are not the cause: on the refreshed dataset (#25960, the shard-timings-refresh lane's 2026-10-26 output) the sum-placed split still predicts 1107 s on the slice shards against 518 s elsewhere — the same 2.1× gap.

Step 1: wall-based placement (cause 3)

In scripts/partition-test-shards.mjs, with no workflow or package edit:

• partition() places bins by load — the wall model in whole-package seconds, a slice counting WHOLE_LEG_PARALLELISM (2.9, the ci(test-shards): widen Test Core from 6 to 8 shards once @objectstack/spec is file-sharded — the "6 is enough" arithmetic predates the cli slices (full-battery slowest shard ≈ 1937 s → ≈ 1452 s) #25376 constant, reused rather than re-derived) times its weight. A list with no slice is placed by exactly the same additions and comparisons as before, so every non-sliced run (and the nightly, which slices every package on every shard) gets a byte-identical split.
• total stays the plain sum, so the density cap and the drift report mean what they meant. refineToCap() keeps load in step with total.
• balanceOf() also reports the walls; pin 2 grades the wall ratio (with a slice in the split the sums are unequal by design); new pin 2b is a fixture where sum-placement and wall-placement differ.
• The shard log prints the predicted walls under the bins line.

Predicted test steps, full list (turbo ls, dogfood excluded), via planRun():

dataset	before (slice shards / others)	after (slice shards / others)
committed (2026-10-23)	1277 s / 643 s	966 s / 830 s
#25960 refresh (2026-10-26)	1107 s / 518 s	899 s / 642 s

Measured-based expectation for the six spec runs above: removing the whole-package leg takes the slowest shard from 25.7–28.8 min to ~22.3–25.1 min. The other five shards absorb the moved packages (their slowest was 17.5 min; +~2.5 min of four-wide work each).

Step 2: the refreshed dataset, and the CLI at 4 slices

The refresh (92343f5, 14 runs, newest 40272142430) measures @objectstack/cli at 2697.45s. Pin 3c (sliceCountProblems, the serial-floor derivation of #22075) then refuses 3 slices:

n	one slice	vs the heaviest other serial task (@objectstack/metadata-protocol 670.12s; spec and runtime run as two tasks)	limit 1.3x = 871.16s
3	899.15s	1.34x	refused: "Raise it to 4" (this is #25960's red, job 121437007857)
4	674.36s	1.01x	meets, and 3 does not, so 4 is the smallest

So the change is FILE_SHARDED_PACKAGES cli 3 → 4, with PREVIOUS_FILE_SHARDED_PACKAGES set to the outgoing {cli: 3} per the map's own rule, so the refresh lane still decodes the 3-slice summaries retained from before the change. The docblocks carry the new derivation table. The bin-sum floor and the wall model agree on this dataset, and no ratio or bound moved. Predicted test-step walls on the full list are 738s on all 8 shards (max/mean 1.00x), and every bin is within the density cap.

Predicted from measurement, not from the model. vitest's BaseSequencer.shard (sha1 of the path relative to the package root, sorted, equal-count chunks) reproduced locally over vitest list --filesOnly (506 files) matches run 40274911131's three slice jobs file for file: 169/169/168 files on jobs 121415631670/…679/…708. From those jobs' per-file times, with the wall taken as 0.39 × the per-file sum (vitest's Duration over its tests sum on the same jobs: 0.403/0.381/0.390):

split	predicted slice walls	measured (vitest Duration)	heaviest / mean
3 ways	789 / 691 / 926 s	812.65 / 673.01 / 921.52 s	1.15
4 ways	487 / 616 / 673 / 630 s	—	1.12

The heaviest slice falls 27%. Applied to the six spec runs (slowest = setup ~1.5 + that run's cold DTS closure + ~1.1 min of whole leg, the wall model's 738 − 674 s, + 0.727 × that run's heaviest slice):

run (spec PR)	slowest before	predicted after both steps
40274911131 (#25903)	28.8	19.8
40271593540 (#25944)	28.1	20.7
40269339195 (#25813)	28.5	20.9
40266487909 (#25903)	28.5	19.7
40263851511 (#25813)	26.8	19.3
40261969569 (#25830)	25.7	18.5

That gives 18.5–20.9 min, with three of six at or under 20. The cost: a fourth shard now builds the CLI's DTS closure (~5.8 min cold). The 738s walls above count test time only, not that build. The per-file read of 5/8 lacks 11 files that print before the 5,000-line log tail; their 172.2s (vitest tests minus the captured sum) is spread evenly over them.

If the readings stay above ~20 min

What is left on a slice shard is the cold DTS closure (5.5–6.3 min) plus the heaviest slice. The next steps, neither taken here:

• B. Declarations only where a slice reads them. Three CLI test files read built .d.ts. With the split now reproducible, a slice holding none of them could build DTS-off (~1 min instead of ~5.8). This edits ci.yml, so it is Tier H.
• C. Weight-balanced CLI slices (a sequencer splitting by measured file time): heaviest/mean 1.12 → ~1.0. It needs a per-file weight source that the dataset does not carry today.

Acceptance notes

• Deliberate leftovers in .github/workflows/ci.yml (Tier H, untouched): the Test Core header still says each slice is "placed at its PLAIN weight so every bin keeps the whole-package split's density", and its "3 slices" wording (the drift-step comment, "a shard carrying one of its 3 slices is predicted a third of that"; the timeout history) is now stale. Correcting either makes a PR Tier H, so both are left for whichever step edits ci.yml. The partitioner's own headers carry the corrected statements.
• Slice shards now come out as shards 1–4 on the full list (LPT places the heaviest loads first). Shard numbers carry no meaning beyond the per-shard Turbo seed key.

Tests

• node scripts/partition-test-shards.mjs --self-test at b323410 → self-test OK (75 measured packages -> 78 shard items, 8 shards, predicted test-step walls 738/738/738/738/738/738/738/739s, max/mean 1.00x <= 1.3x, …, file-level slices: @objectstack/cli x4).
• Step 1 revert proof (scripts/ablation-replace.mjs, bin choice back to total, on the committed dataset): the self-test reds with balance: at 8 shards the slowest predicted test step is 1.45x the mean (1277s vs 881s). Restored blob == HEAD, and git diff HEAD is empty.
• Step 2 revert proof: the refreshed dataset with cli at 3 reds pin 3c with @objectstack/cli: sliced 3 ways at 2697.45s, one slice is 899s -- past 1.3x the heaviest other serial task (670s, so 871s) … Raise it to 4. (the same red as chore(ci): refresh the Test Core shard-timings dataset #25960's job 121437007857).
• scripts/test-shard-timings.json is byte-identical to 92343f5 (git diff 92343f5b b3234103 -- scripts/test-shard-timings.json is empty).
• Sibling self-tests are green at b323410: measure-test-shard-timings (decodes through both maps), check-test-completeness, ci/select-shard-timings-run, nightly-tiers, check-test-suite-ceilings, ci/select-shard-packages.selftest.sh.

Gates

• Local derived set at b323410 (node scripts/pm/dispatch-gates.mjs --commands, merge-base origin/main cdd4eea): all 35 families exit 0. The --ran reconciliation reads 35 derived famil(ies) accounted for — 35 run, 0 NOT-MEASURED. Step 1 alone (8ca31e0) ran its 33 families the same way.
• Everything else (Lint & Repo Gates, Test Core, …) belongs to CI and is read from this PR's check-runs.

Clause-②: no
Metadata-protocol: none

🤖 Generated with Claude Code

https://claude.ai/code/session_01NPH84ZP1jWcst3tpRwfrJL

---

Generated by Claude Code

[objectstack-fleet]

席位核对

Verdict: ACCEPT at head ec177ae84c75d8991ce06b0b4008cb97344902ae. This lands the cheapest step only. #25870 stays open for the remaining gap.

Checklist

• PR shape: draft → main, first line Part of #25870. That is correct, because the predicted slowest shard (~22–25 min) does not meet the card's ≤ ~20 min. No closing keyword sits next to any card number.
• Scope: one file, scripts/partition-test-shards.mjs (+134/−15). It does not touch a workflow, a package or the dataset. skip-changeset is correct for CI tooling.
• check-governed-merges --pr 25968: NOT governed, 149 lines, so this is an ordinary landing.
• Contract review: not triggered. It touches no packages/spec/src/**, the PR says Clause-② no, and there is no narrowing.
• Rules from the dispatch order are kept. No test is skipped or quarantined, and no timeout is raised. The shard count is unchanged. The wall model and WHOLE_LEG_PARALLELISM = 2.9 are reused from ci(test-shards): widen Test Core from 6 to 8 shards once @objectstack/spec is file-sharded — the "6 is enough" arithmetic predates the cli slices (full-battery slowest shard ≈ 1937 s → ≈ 1452 s) #25376, not re-derived.

Gate readings at head ec177ae

• 34 success, 16 skipped, 0 failing.
• Lint & Repo Gates, TypeScript Type Check, Test Core (all 8 shards) and Governed Surface Queue Guard are success.
• The skipped checks are UI and opt-in jobs filtered out by path.

Seat's own readings, in a detached worktree at ec177ae

• node scripts/partition-test-shards.mjs --self-test → self-test OK (… predicted test-step walls 966/966/966/830/830/830/829/829s, max/mean 1.10x …).
• Revert proof: I set the bin choice back to total, and the self-test fails with balance: … slowest predicted test step is 1.45x the mean (1277s vs 881s). The worktree was restored afterwards, with an empty diff.
• The PR says a list with no slice gets a byte-identical split. I tested that with 900 random slice-free lists (5–80 packages each, at 3, 6 and 8 shards), comparing partition() at the head against origin/main. 0 lists differed.
• Diagnosis: the PR body has the per-run table (6 spec-touching runs with ids). Stale weights are ruled out by numbers from the chore(ci): refresh the Test Core shard-timings dataset #25960 refresh dataset, which the card asked for.

Deviations / follow-ups (named, not fixed here)

• The Test Core header in ci.yml still says a slice is "placed at its PLAIN weight". That is now stale, and correcting it makes a PR Tier H. It goes with whichever next step edits ci.yml.
• Next on ci(test-shards): Test Core's two slowest shards set every core PR's wall clock at ~28 min (5.6 min dependency build + ~20 min tests) while the other six finish in 7–17 — re-derive the cli slicing and shard balance on post-merge readings #25870, after landing: take readings from 3 consecutive pull_request runs that touch packages/spec. Then the seat decides between A (4 cli slices with a wall-based slice-count derivation, scripts-only), B and C, as listed in the PR body.

---

Generated by Claude Code

[objectstack-fleet]

席位核对 (delta re-review)

Verdict: ACCEPT at head b32341039f093b50bbe98b7f38ae7e568921cb07. This replaces the ACCEPT given at ec177ae8. Step 1 (wall placement) is unchanged since that review. This review covers step 2 only.

The delta

• Merge 83c7ea2a brings in origin/main cdd4eea9. That includes ci: run main's full battery every 4 hours and CodeQL daily (maintainer ruling Q6 = C) #25969, which touches a different hunk of the partitioner, and the merge is clean.
• b389ba08 is the shard-timings refresh lane's commit 92343f5b (chore(ci): refresh the Test Core shard-timings dataset #25960), cherry-picked. git diff 92343f5b b3234103 -- scripts/test-shard-timings.json is empty, so the dataset is still generator output and has no hand edits.
• b3234103 changes FILE_SHARDED_PACKAGES cli from 3 to 4 and sets PREVIOUS_FILE_SHARDED_PACKAGES to {cli: 3}. That follows the file's outgoing-map rule, set in the same PR. The retention wording now matches ci: run main's full battery every 4 hours instead of hourly (CI and Lint schedules), and CodeQL daily instead of on every push to main (maintainer ruling Q6 = C) #25771.
• The PR's file list is scripts/partition-test-shards.mjs and scripts/test-shard-timings.json. check-governed-merges --pr 25968 reports NOT governed, 826 lines, under the 3000 threshold.

Gate readings at head b323410

• 37 success, 16 skipped (UI and opt-in jobs, path-filtered), 0 failing.
• This PR's own Test Core is not a ci(test-shards): Test Core's two slowest shards set every core PR's wall clock at ~28 min (5.6 min dependency build + ~20 min tests) while the other six finish in 7–17 — re-derive the cli slicing and shard balance on post-merge readings #25870 reading: it touches scripts only, so its list is small.

Seat's own readings at b323410, in a detached worktree

• --self-test → self-test OK (… 78 shard items, 8 shards, predicted test-step walls 738/738/738/738/738/738/738/739s, max/mean 1.00x …, file-level slices: @objectstack/cli x4).
• Revert proof: with cli set back to 3, pin 3c turns red with the same text chore(ci): refresh the Test Core shard-timings dataset #25960 showed in CI (sliced 3 ways at 2697.45s, one slice is 899s -- past … 871s … Raise it to 4.). The worktree was restored afterwards, with an empty status.
• This also clears chore(ci): refresh the Test Core shard-timings dataset #25960's red "Shard partitioner self-test" (Lint · CI, release & engine gates), because the refreshed weights cannot land at cli ×3.

Still open on #25870 (named, not done here)

• The PR predicts the slowest shard at 18.5–20.9 min on the six spec runs it lists. The prediction comes from a reproduction of vitest's sha1 split, file for file, against run 40274911131. The card's acceptance is a measurement, though: 3 consecutive spec-touching pull_request runs after landing.
• The ci.yml Test Core header ("PLAIN weight", "3 slices") is stale. It is a deliberate leftover, because correcting it makes a PR Tier H.

---

Generated by Claude Code