Motir

Type · chore (CI configuration) · Parent · MOTIR-1464 · Repo · motir-core · Pairs with · MOTIR-3928 — neither alone moves CI by more than ~0.3 min

Why now, and not in MOTIR-3912

MOTIR-3912 put a cost-based bin-packer behind the Vitest legs and explicitly scoped the COUNT out: "it stays at 8. With the packer in place the count becomes a one-line dial, and turning it is a separate decision that wants a measurement of the balanced lane first — which this card produces and does not have."

That measurement now exists. On the combined run 33271194884 (the first carrying both MOTIR-3912 and MOTIR-3913):

And on MOTIR-3912's own verification run 33263282834, the packer's model was accurate where the runner was not degraded: leg 6 predicted 2529 s of assumed cost against 2466 s actual, a 0.98 ratio. So the dial can be turned on numbers rather than on hope.

The arithmetic

CI's two paths currently finish 11 seconds apart on run 33271194884 — bulk-1 at 19:46:33, Vitest coverage at 19:46:38, bulk-3 at 19:46:44:

• Vitest path — changes 0.5 + slowest leg 10.8 + coverage 1.2 = 12.5 min
• E2E path — changes 0.5 + build 4.4 + slowest bulk leg 8.2 = 13.1 min

MOTIR-3928 takes an E2E leg to ~5.3 min → E2E path ~10.2. This card is what stops Vitest becoming the new sole constraint at 12.5.

Per-leg worker time is ~1700 s (test + import + transform), which at 4 workers and the observed ~84% utilisation gives ~506 s of vitest run, plus ~75 s of setup and ~85 s of coverage post-run ⇒ the ~10.5 min observed. At 12 legs that worker time is ~1133 s ⇒ ~8.3 min a leg, ~9.5 min for the path. With MOTIR-3928 landing E2E at ~10.2, the two stay level and CI lands ~10.5 min.

Cost: fixed per-leg overhead is ~160 s (75 s setup + ~85 s coverage post-run), so 8 → 12 adds ~11 runner-minutes.

Acceptance criteria

1. VITEST_LEG_IDS is twelve legs and ci.yml's test matrix lists the same twelve — the existing guard cross-checks them, so this is one edit in two places that cannot drift.
2. The --shard=<leg>/N denominator moves with the count. tests/vitest-shard-plan.test.ts already asserts --shard=${{ matrix.leg }}/${VITEST_LEG_IDS.length}, so a missed denominator fails the guard rather than silently handing CostBalancedSequencer a count it declines (it falls back to Vitest's own sha1 slice on an unrecognised count — correct, and invisible).
3. On this PR's own run: twelve legs, none above ~9 min, summed Tests N passed equal to what eight legs report on the same SHA.
4. timeout-minutes: 75 is left alone unless something argues otherwise, and its comment is checked for a claim that the twelve-leg membership falsifies. The ceiling was never derived from the count — it clears Vitest (2/3)'s 47.5-minute healthy outlier on run 32959226187, and tests/ci-job-timeouts.test.ts pins it above that.
5. The cost table is NOT re-measured here. It is per-FILE and the packer re-runs over whatever leg count it is given, so twelve legs is a repartition of the same numbers.

Out of scope

• Re-measuring FILE_TEST_SECONDS. Refresh it when the MEDIAN drifts, not on a leg count change — and per MOTIR-3913's AC-3 finding, never chase a single run's noise.
• Going past 12. The fixed ~160 s per leg is a growing share; 12 → 16 buys progressively less for the same 11 runner-minutes a step. Re-argue it with a measurement if it ever looks worth it.
• The Vitest coverage phase (~85 s post-run per leg plus the 1.2 min merge job) and the build job's 4.1 min. Both are structural and bigger arguments than a dial.

Context refs

• tests/helpers/vitestShardPlan.ts — VITEST_LEG_IDS, the one edit.
• tests/helpers/vitestShardSequencer.ts — falls back to Vitest's own partition on a count it does not recognise, which is why AC 2 matters.
• tests/vitest-shard-plan.test.ts — the matrix/denominator cross-check.
• .github/workflows/ci.yml — the test matrix and its --shard step.
• Runs 33271194884 (combined) and 33263282834 (the packer's model-vs-actual).

Resolution: open.