ci(test-core): force the sliced test leg to execute, not replay

[os-try-charles]

Fixes #18671

Second flight on this card: the first one pinned the contradiction and named the mechanism (verdict (A), comment 5736428716). This one measures the three named repairs and implements the one the measurement picks.

The defect, in one line

CI runs two legs of the same task in one job. The whole-package leg is pnpm turbo run test test:repo $FILTERS ...; the file-level slice leg is pnpm turbo run test "--filter=$PKG" --only ... -- "--shard=$SLICE". --only drops the dependency tasks out of the run graph and out of the task hash with them, so the slice leg's hash carries only the package's own files plus the hand-declared $TURBO_ROOT$ inputs. A slice that IS in the shard's affected set can therefore match a main-seeded cache entry across the very change that put it in that set. Run 34746808828 did exactly that: Cached: 1 cached, 1 total, 73ms >>> FULL TURBO, replaying a log a main push run had produced ~15 minutes earlier on a commit that did not contain the PR under test — while all six shards reported success, check-test-completeness graded the replay OK and the shard attestation said "ran to completion".

What changed

One line in .github/workflows/ci.yml, plus the comment above it that carries the readings:

-  set -- pnpm turbo run test "--filter=$PKG" --only --concurrency=4 --summarize --log-order=stream -- "--shard=$SLICE"
+  set -- pnpm turbo run test "--filter=$PKG" --only --force --concurrency=4 --summarize --log-order=stream -- "--shard=$SLICE"

turbo.json is unchanged. Nothing else is touched.

The measurement that picked it

Three repairs were named by the first flight, verbatim: (1) TURBO_FORCE on that leg; (2) make the shard a task-declared env so --only is not needed at all; (3) drop --only and pay back the closure-rebuild cost that #16395 removed.

Does the affected task actually execute? Measured on this tree, turbo 2.10.10, on @objectstack/service-cache — a package whose test task has the same shape (dependsOn: ["^build"]) and which depends on @objectstack/spec. Sequence: build the closure passthrough-free (as the job's own preceding step does), run the slice leg once to seed the cache, then append one line to packages/spec/src/ui/view.zod.ts, rebuild the closure, and run each variant. The mutation was proven on disk (marker count 0 to 1; blob 9051f93e... to 4edcf771...) and restored under a trap, verified by an empty git diff HEAD.

variant	tasks	turbo's own line	verdict
--only + passthrough (before)	1	Cached: 1 cached, 1 total / 81ms >>> FULL TURBO / cache hit, replaying logs	NOT RUN — defect reproduced
--only --force (this PR)	1	Cached: 0 cached, 1 total / 1.15s / cache bypass, force executing	runs
no --only, passthrough kept (repair 3)	6	Cached: 0 cached, 6 total / 1m54.963s	runs, and rebuilds the closure
no --only, no passthrough (repair 2's shape)	6	Cached: 5 cached, 6 total / 1.512s	runs, closure replays

All four rows ran the same suite; only the first one did not.

What it costs, re-measured today at @objectstack/cli's real scale, --dry=json against a cache the passthrough-free closure build had just filled (59 build tasks in the plan, of which 57 execute — @objectstack/console and @objectstack/refd-timer-testkit declare no build script, so they appear in the plan and never run):

plan	tasks	cache
--only + passthrough (before, and with --force)	1	1 MISS (the test)
no --only, passthrough kept (repair 3)	60	60 MISS
no --only, no passthrough (repair 2)	60	57 HIT / 3 MISS (the test + the two script-less tasks)

So repair 3 re-executes 57 real build tasks that the job's preceding step had just made replayable. Executing that closure here measured 5m11.262s at --concurrency=2 on a shared container, against 60ms >>> FULL TURBO for the same command when its hashes are left alone (that 60ms is the control: the closure is replayable, and only the passthrough stops it being replayed). These are shared-box seconds, not idle-box seconds; the ratio is the durable half. CI runs --concurrency=4 on a 4-vCPU runner and the job stands against a 30-minute wall.

The slice leg's own execution cost — which repairs 1, 2 and 3 all pay, because it is the cost of actually testing — is @objectstack/cli at 458.15s whole-package (scripts/test-shard-timings.json, measuredAt: 2026-08-24, median across six green merge_group run summaries), sliced 1/2 across shards 5/6 and 6/6, which run in parallel. On pull_request and merge_group the shard's package set IS the affected set (scripts/ci/select-shard-packages.sh), so a slice is scheduled only when it is affected and a replay there is wrong by construction — this is not new CI time, it is CI time the job was skipping.

Repair 2 is out of this PR's file surface, and that is why it is not implemented. It needs the shard to reach vitest without a run-level passthrough. vitest 4.1.11 reads no VITEST_SHARD (the env vars it reads are enumerable in its dist; shard is not among them), so the value has to be plumbed through a vitest config file — test: { shard: process.env.OS_TEST_SHARD } in packages/cli/vitest.config.ts, plus an OS_TEST_SHARD entry in turbo.json's test task env. The dispatch's surface is ci.yml and turbo.json only, so this stops here and is reported rather than widened. Two things worth knowing if it is picked up: it is the cheapest correct shape (the closure replays, 57 HIT above) and it makes the hash honest rather than only the execution; but the sliced set is data-driven (scripts/partition-test-shards.mjs weights by measured duration), so a newly-sliced package without the config line would silently run its whole suite on both shards, and no gate would say so.

What this does not fix

--force makes the leg execute; it does not make the hash honest. The slice leg's hash stays blind to its dependency closure, so nothing in this repo fails when a slice leg's hash stops moving for an upstream source change. The first flight proposed exactly that pin and it is deliberately out of scope here: it would red main on the day it lands unless it lands with a repair, and its natural home is lint.yml, which is held behind an open PR in another lane.

⛔ Merging

.github/workflows/** is outside the PM seat's arming channel: auto_merge answers HTTP 422 there, every time. This PR merges by a human. That 422 is a channel fact, not a tool fault — it is not to be retried, and this PR is not to be undrafted or armed by an agent seat.

Local verification

Gate families derived on this tree with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack .github/workflows/ci.yml turbo.json — 46 commands. Results are in the report on the card.

No changeset: nothing published moves. .github/workflows/ci.yml appears in no package's files[].

---

Generated by Claude Code