[objectstack-fleet]

Requested by Elon · project thread

Part of #25870. The card stays open until its after-landing reading: the first 10 full merge-queue Test Core builds with no load-shaped red.

Clause-②: no
Metadata-protocol: none

What

This is the second attempt at #25870, after #25968 was reverted by #26077. It keeps only the parts of #25968 that did not cause the merge-queue reds. Two files change.

• scripts/test-shard-timings.json: the 2026-10-26 refresh (14 runs, newest 40272142430). The file is byte-identical to the one ci(test-shards): place Test Core bins by predicted wall, and cut the CLI into 4 slices on the refreshed dataset #25968 carried (git diff f36f6190 HEAD -- scripts/test-shard-timings.json is empty).
• scripts/partition-test-shards.mjs:
  • FILE_SHARDED_PACKAGES cli 3 → 4, and PREVIOUS_FILE_SHARDED_PACKAGES = {cli: 3}, so the refresh lane can still decode the 3-slice summaries it retains. The derivation table for 4 sits next to the map.
  • Placement does not change. partition() stays the plain-sum LPT. There is no wall model and no loadOf/wallOf.
  • New pin 3d in --self-test (WHOLE_LEG_CAP_SECONDS, LOAD_SENSITIVE_APART, wholeLegProblems()), described below.

No .github/** edit, so this is not Tier H, and no governed path is touched.

Why

• cli ×4 has to be on main before the 2026-11-02 05:30Z weekly refresh. With the 10-26 weights, pin 3c refuses cli ×3: one slice is 899.15 s, which is past 1.3 × @objectstack/metadata-protocol's 670.12 s = 871.16 s ("Raise it to 4"). If this does not land first, the refresh bot's PR goes red.
• ci(test-shards): place Test Core bins by predicted wall, and cut the CLI into 4 slices on the refreshed dataset #25968 failed because of its placement. The weights and the slice count were not the problem. The wall model moved the whole packages off the slice shards, which left four shards with ~2141 s of four-wide work each, and put objectql and plugin-security on the same shard. Full queue builds then went red 5 times in 27, every time on a load-sensitive test (Merge queue: full Test Core builds go red 5 of 27 since #25968's shard layout, and each ejection rebuilds every entry behind it #26074, and the post-mortem 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, comment 6414712442). Keeping plain-sum placement with the refreshed weights makes every whole-package shard lighter than it is on main today.

Shard table: planRun() on the full list

These numbers come from turbo ls --output=json at 365fe5e with --exclude @objectstack/dogfood, run through planRun() exactly as ci.yml calls it. "whole" is the shard's whole-package seconds with the package count in brackets. "slice" is the CLI slice's seconds. "step" is the #25376 wall model (whole / 2.9 + slice), included for reference only.

shard	main (plain sum, 10-23 dataset, cli ×3)	this PR (plain sum, 10-26 dataset, cli ×4)
1/8	1866 (6) · step 643	1499 (16) · step 517
2/8	1866 (11) objectql · 643	1501 (10) · 518
3/8	900 (8) + cli 1/3 966 · 1276	826 (9) + cli 1/4 674 · 959
4/8	900 (9) + cli 2/3 966 · 1276	827 (9) + cli 2/4 674 · 959
5/8	899 (8) + cli 3/3 966 plugin-security · 1276	826 (9) + cli 3/4 674 · 959
6/8	1866 (10) · 643	826 (9) + cli 4/4 674 plugin-security · 959
7/8	1868 (11) · 644	1501 (10) objectql · 518
8/8	1866 (19) · 643	1500 (10) · 517

The dispatch set three conditions, and all three hold:

• Every whole-package shard is at or below today's ~1866 s. The heaviest is 1501 s, against 1868 s on main.
• objectql (7/8) and plugin-security (6/8) are on different shards. plugin-security sits on a slice shard with 826 s of whole-package work, as it did before ci(test-shards): place Test Core bins by predicted wall, and cut the CLI into 4 slices on the refreshed dataset #25968 (899 s).
• No shard's whole sum is above the pre-ci(test-shards): place Test Core bins by predicted wall, and cut the CLI into 4 slices on the refreshed dataset #25968 mean of 1866 s.

Bin totals are 1499–1501 s (max/mean 1.00×), inside the 2697.45 s density cap. #25968's layout for comparison: 186/185/185/185 + 674 s slices, and 2141/2139/2141/2142 s whole.

Pin 3d: the whole-package leg cap and the load-sensitive pair

Pins 2–3c grade bin sums and slice counts, and #25968's 2141 s layout passed all of them. Pin 3d grades what actually broke, on the committed dataset's full list as CI splits it:

• WHOLE_LEG_CAP_SECONDS = 1868: no shard's whole-package sum (slices excluded) may exceed 1868 s. That figure is the heaviest whole leg the queue has run green: shard 7/8 of the plain-sum layout on the 2026-10-23 dataset, red 0 times in 19 full builds before ci(test-shards): place Test Core bins by predicted wall, and cut the CLI into 4 slices on the refreshed dataset #25968 and 0 in 10 after ci(test-shards): revert Test Core to the plain-sum layout and the 2026-10-23 dataset (undo #25968) #26077. 2141 s is the figure that went red. The pin's comment says that raising the cap needs a merge-queue red-rate reading, not a balance figure, and that the remedy for a refresh that outgrows the cap is a wider matrix or a finer slice.
• LOAD_SENSITIVE_APART = [objectql, plugin-security]: these two may never be whole on the same shard. They are the two packages whose tests went red under load in Merge queue: full Test Core builds go red 5 of 27 since #25968's shard layout, and each ejection rebuilds every entry behind it #26074. The third red was a CLI slice, and a slice runs alone after its shard's whole leg. If either package disappears from the split, the pin goes red instead of passing on a pair it no longer grades.

The battery has 5 cases: the committed-dataset grade, which first proves the split's whole-leg sums add up to the dataset's whole seconds, and 4 fixtures (pass, pair together, over cap, member missing). The battery roster floor goes from 15 to 16.

Tests

• node scripts/partition-test-shards.mjs --self-test at HEAD: self-test OK (75 measured packages -> 78 shard items, 8 shards, max/mean 1.00x <= 1.3x, floor 1169s, bins 1499.31/1501.21/1499.98/1500.86/1499.98/1500.12/1501.22/1500.45s within the 2697.45s density cap, whole legs 1499/1501/826/827/826/826/1501/1500s within 1868s, file-level slices: @objectstack/cli x4).
• Ablation: the pin catches ci(test-shards): place Test Core bins by predicted wall, and cut the CLI into 4 slices on the refreshed dataset #25968's placement. I put ci(test-shards): place Test Core bins by predicted wall, and cut the CLI into 4 slices on the refreshed dataset #25968's load-based partition() (slice × 2.9) back in temporarily and turned off pin 2, which on main already reds it at 1.43×. Pin 3d then reds with shard 5/8 carries 2141s … 6/8 2139s … 7/8 2141s … 8/8 2142s of whole packages, past the 1868s cap and @objectstack/objectql and @objectstack/plugin-security share shard 7/8. That is ci(test-shards): place Test Core bins by predicted wall, and cut the CLI into 4 slices on the refreshed dataset #25968's layout reproduced. After the ablation the file was restored and cmp confirms it matches.
• Ablation: cli ×3 on the refreshed dataset reds pin 3c with sliced 3 ways at 2697.45s, one slice is 899s … Raise it to 4. Restored afterwards, cmp clean.
• Sibling self-tests are green: measure-test-shard-timings (decodes through both maps), check-test-completeness, ci/select-shard-timings-run, ci/select-shard-packages.selftest.sh (32 cases).

Gates

• node scripts/pm/dispatch-gates.mjs --commands (merge base 365fe5e): all 35 derived families exit 0. dispatch-gates.mjs --ran reconciles: 35 derived, 35 run, 0 NOT-MEASURED.
• Serial check before pushing: none of the 36 other open PRs on this repo touches scripts/partition-test-shards.mjs or scripts/test-shard-timings.json. I checked each with git diff --name-only origin/main...pull/N/head.
• Everything else is left to this PR's CI.

Acceptance notes

• After landing (the reading 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 waits on): read the first 10 full Test Core merge_group builds the way Merge queue: full Test Core builds go red 5 of 27 since #25968's shard layout, and each ejection rebuilds every entry behind it #26074's 13:35Z reading did. Any load-shaped red means stop and report, and a revert is on the table. Also: the slowest spec-touching pull_request shard on 3 readings, for information. The original goal was ≤ ~20 min. The predicted slice-shard step falls from 1276 s to 959 s, but the cold DTS closure (~5.8 min) still comes on top of that.
• Left alone because it is Tier H: ci.yml's Test Core comments still say "3 slices" (the drift-step comment and the timeout history). Correcting them would make this PR Tier H. They are for whichever step edits ci.yml next.
• The pin grades the dataset's full list, which is what a full queue build runs. A pull_request or partial merge_group run splits its own smaller list, which can put the two packages together on lighter shards. That was already true on the green layout, so this PR does not change it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CLvWYcHLpbpu8X8PvozD7F

[objectstack-fleet]

席位核对

Verdict: ACCEPT at head 6e20eda8e1c2ddc2035d4273b650d68d7d80842f. This is not governed: check-governed-merges --pr 26186 reports 0 of 2 paths on the register, and the size is 791 changed lines, under 3000. Ordinary queue landing applies, and the seat flips it now.

Against the dispatch order (dispatch-25870-retry.md)

• Placement is a plain sum. The wall model that ci(test-shards): place Test Core bins by predicted wall, and cut the CLI into 4 slices on the refreshed dataset #25968 used and ci(test-shards): revert Test Core to the plain-sum layout and the 2026-10-23 dataset (undo #25968) #26077 reverted is gone.
• The dataset is the 10-26 refresh. scripts/test-shard-timings.json is byte-identical to f36f6190.
• @objectstack/cli is sliced ×4, and PREVIOUS_FILE_SHARDED_PACKAGES = { '@objectstack/cli': 3 } records the step.
• ci.yml is untouched (2 files changed).
• The two load-sensitive packages, @objectstack/objectql and @objectstack/plugin-security, are pinned to separate shards (LOAD_SENSITIVE_APART).
• Every whole-package leg is capped at WHOLE_LEG_CAP_SECONDS = 1868. wholeLegProblems() enforces this, and the self-test asserts it.

Seat's own reading at the head (detached worktree)

• node scripts/partition-test-shards.mjs --self-test exits 0 with this output:
  75 measured packages -> 78 shard items, 8 shards, max/mean 1.00x <= 1.3x, bins 1499.31/1501.21/1499.98/1500.86/1499.98/1500.12/1501.22/1500.45s, whole legs 1499/1501/826/827/826/826/1501/1500s within 1868s, file-level slices: @objectstack/cli x4.

Gates at head 6e20eda

• 37 success and 20 skipped.
• The one failure row is job 121652694439, "Part-of PR must not also close its card". That run read the 15:05Z body, which still had a closing keyword. The body was reworded through a relay issue_patch, and the re-run on the edited event (job 121654491671) passed at this same head. The current body has no closing keyword.

After landing (owed on #25870)

• Read the next 10 full merge-queue Test Core builds.
• Acceptance: no load-shaped red, meaning a timeout on a load-sensitive test. One such red sends the placement back for review before the 11-02 timings refresh.
• 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 stays open until that reading is posted.

---

Generated by Claude Code