ci(mutation): cut the heavy files into range shards, per-file break threshold

[dlamarre-dev]

Why

The nightly mutation run of 26 September was cancelled on the stego shard at the 120-minute job limit, at 158 of 159 mutants. It was already close to the limit before that:

night	stego	crypto
20 Sep (forced)	51 min, 358 mutants	63 min, 463 mutants
24 Sep (incremental)	116 min, 179 re-tested	66 min, 127 re-tested
26 Sep (incremental)	cancelled at 120, 158/159	106 min, 148 re-tested

(The 25 September failure was a different problem, the --json progress throttle, and #206 already fixed it.)

The mutant counts barely moved. The tests got slower: the gallery round trips re-encode every cover (SPEC §9.8) and price every carrier with UERD (§9.3.1). On its own, src/api/node/gallery.test.ts takes about 6 minutes locally. A surviving mutant runs every test that covers it, and a timeout waits 1.5× that long, so the cost per mutant went up about fivefold. Tonight's Sunday run is forced and would need 4 to 5 hours for stego.ts (479 mutants now) or crypto.ts.

What

• scripts/mutation-shards.ts: cuts files into line ranges (--mutate file:start-end). Each cut is named after a top-level declaration, not a line number. Stryker only mutates nodes that sit entirely inside the range, so a cut inside a function would silently drop the mutants that span it.
• plan job: resolves the anchors for the current commit and feeds the matrix (fromJSON).
• tests/mutation/shards.test.ts (runs in npm test on every PR): uses Stryker's own instrumenter to check that each file's ranges produce every mutant exactly once, and that the shards cover exactly the mutate list in stryker.config.mjs. I checked that it fails (476 ≠ 477) with a cut inside gateKek.
• Summary: sums the rows per file and gets the expected shard count from the plan.
• @stryker-mutator/instrumenter added as a devDependency, the same version as core (already installed as a transitive dependency; grouped by Dependabot with @stryker-mutator/*).

Shards: crypto ×4, stego ×5, vault ×2, reed-solomon ×2, codes (access, gf256, erasure) ×1 = 14. I placed the cuts using a cost model built from the stored reports. The test selection does not change, so the score still measures the same thing.

• Per-file break threshold: each shard runs with STRYKER_NO_BREAK, and the summary job fails if a file, summed across its shards, falls below 75. Without this, crypto-4 (randomIntBelow, 17 mutants, 76.47%) would fail the night on a single extra survivor.
• dryRunTimeoutMinutes 20 → 30 (dry runs measured at 9 to 15 min on the runner), and timeout-minutes 120 → 180.

Verification

• tsc, eslint, prettier, notices:check, claims:check and the new test are all green locally. The test fails as expected with a cut inside gateKek.
• First cold run with 11 shards (36264393968): 49 to 106 min per shard, with crypto-1 cancelled at 323/329 and stego-3 at 162/181 at 120 min. Timeouts set the floor: 9 to 21 per shard, about 15 to 20 min each. So I split those two ranges again (13 shards) and raised the limit to 180.
• Second cold run, 13 shards (36271471541): ✅ all passed, 15 to 109 min, except stego-1 at 135 (103 on the previous run, same code). I split it again at StreamReader (6 of its 12 timeouts), which makes 14 shards.
  • That run also exposed a counting bug: Stryker carries every stored incremental result into its report, even outside --mutate, so reed-solomon.ts was counted twice through codes (main's old cache) and some crypto ranges overlapped. Fix: the summary keeps only the mutants wholly inside each shard's planned range (MUTATION_SHARDS) and reports how many it dropped, and the cache moves to stryker-v3. Replayed on that run's artifacts: 88.91%; crypto 477, reed-solomon 177, stego 479, vault 448 (+1 RuntimeError), matching the instrumenter.
• Third cold run, 14 shards (36279181759): in progress.

🤖 Generated with Claude Code