`m10_2_perf` and `m10_11_perf` were dark for TWO independent reasons,
and only one of them is this lane's headline subject:
1. They are `crdt`-gated, and nothing in the workflow enabled the
feature, so they were never compiled.
2. Even setting `crdt` aside, no job named them. Grepping ci.yml for
`--test` yielded exactly four suites: acceptance, m4_acceptance,
m5_perf_acceptance, m6_perf_acceptance. Their `#[ignore]` is
deliberate; their absence from every workflow was not.
Fixing both here is a deliberate scope call, taken with the second cause
named rather than absorbed: leaving it would ship a lane headlined "the
dark tests now run" with 7 still dark, and the remedy is one job block,
not a second investigation.
The two suites are NOT the same kind of thing, and the job says so
because a future reader will otherwise assume "perf gates" means
"budgets":
* m10_11_perf asserts one budget — cross-frontend propagation p99
under 50ms. Measured 1.47ms locally, a ~34x margin, so a red here
is a regression rather than runner noise.
* m10_2_perf asserts NOTHING. Six benches that print throughput
numbers, the baselines M10.2's 391x unicode finding and v0.2+
optimization work compare against.
Including a suite that cannot fail a budget needs its own
justification, so the workflow states it: `run_workload` drives 30
seconds of randomized mixed edits against both the v0.1 and CRDT buffer
paths, and nothing else in the corpus exercises a sustained randomized
CRDT workload. Its value here is soak and panic detection, not gating.
The comment explicitly warns against "fixing" it later by adding
throughput assertions, which is how perf jobs become flaky on shared
runners.
Per framing Q#CC3 and §1.3a, `tests/m10_10_perf.rs` is deliberately NOT
touched: it is a CI-default regression tripwire with generous bounds,
not a bench, and adding `#[ignore]` to give it a job would have shipped
a coverage reduction inside a coverage lane. It is recovered by the
plain crdt leg in the next commit instead.
Observed execution, local release build 2026-08-01: m10_2_perf 79s
(6 passed), m10_11_perf 5s (1 passed). The 25-minute ceiling matches
m5-perf-gates and is set by the cold-cache release build, not the ~85s
of tests — the reasoning the file already applies to its other perf
jobs.
Verified: ci.yml parses, 9 jobs, every one carrying timeout-minutes.
Both suites pass locally under the exact commands the job runs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Levi Neuwirth
06abbacc70