Files
stack/packages
fred b91b702a53 fix(launch): drop the dead recordLaunch test seam; stop a load-sensitive spec reporting CPU load as a defect
Two changes, both about a test seam that alters production behaviour.

AMD1213-D defect D5 objected that `launchFleetRuntimeForTest` was an exported
production API that also set `recordLaunch:false`, changing a second production
branch beyond the two the card authorized. Most of that is already closed in
this tree: the exported helper is gone, and the specs now enter through the real
`registerFleetLaunchCommand -> apply -> launchFleetRuntime -> launchRuntime`
route on a fixture seat, with the ledger pointed at the fixture and asserted
(`fleet-launch-command.spec.ts` asserts `events.ndjson` contains the record).
The seat-seeded/HOME-empty pass and HOME-seeded/seat-empty fail pair both exist.

What remained was the `recordLaunch?: boolean` context field itself. Nothing in
the package sets it -- it is a dead switch whose only effect was to let a caller
silently disable launch recording on the claude branch while codex, opencode and
pi recorded unconditionally. Removed, so all four branches record the same way
and the asymmetry cannot be reintroduced by passing a flag.

The second change is unrelated to D1-D6 and is called out as such. It is here
because the amend's required evidence includes a green full-package Vitest run,
and one spec made that non-reproducible.

`install-ordering-guard.spec.ts` proves that `guardClaudeSettingsWiring` really
delegates to `leaseEnforcementActivatable()` by comparing the guard's outcome
against its own call to the same predicate. That predicate is not deterministic:
`defaultCapabilityProbe` runs `dist/cli.js` out-of-process with a 2000 ms
timeout. In a full-package run with 86 spec files scheduled at once, one
observation beats that timeout and the next does not, the two disagree, and the
test fails -- reporting machine load as a wiring defect. It passed in isolation
every time, which is why it read as a flake.

Measured rather than assumed. The failure reproduced in three consecutive full
runs and passed 3/3 in isolation. It was NOT caused by the recordLaunch removal
above: reverting only that edit and re-running the full suite still failed, which
is what ruled my own change out.

The guard call is now bracketed by two observations of the predicate, and only a
pair that agrees is used as ground truth; a disagreeing pair is retried, up to
three attempts, and never holding still is itself a failure rather than a skip.
This does not weaken the assertion -- a real delegation failure is stable and
survives every attempt while load noise is not.

Falsified: inverting the guard's default to `!leaseEnforcementActivatable()`
turns the test red (1 failed / 18 passed), so the retry did not blunt what the
test detects. The inversion was reverted and the file confirmed clean.

Verification: typecheck RC=0. Three consecutive full-package runs, RC=0,
86 files / 1619 tests passed, 0 failed, under the sanitized lease environment
(MOSAIC_LEASE_* and MOSAIC_RUNTIME_GENERATION stripped).

Commit-only per scrappy's controlling packet (comms 20260813T212447Z dc43de):
not pushed, PR #1213 not updated, nothing re-authored.
2026-08-15 14:46:47 -05:00
..