refactor(steps): give every step its own packaging, benchmark, docs, and tested contract

[DevilTea]

Closes #134. Phase 4's remainder is #135.

Every built-in step becomes one self-contained unit that carries its own implementation, tests,
benchmark, and documentation — and the docs site, the performance gate, and the completeness gates all
read from those units instead of from a second hand-maintained copy.

Phase 1 — one canonical step shape

The standard is written down in .claude/skills/valchecker-dev/references/step-unit.md and enforced by
pnpm steps:complete, applied to all 114 steps with no behaviour change. Fifteen auxiliary test files
folded into their step's suite; twenty-two implementation files reordered; four steps de-prefixed. The
sorted multiset of it/test/describe title lines under steps/ is identical before and after, and
so is the total assertion count — that is the no-behaviour-change evidence, checked independently of
the agents that did the work.

The ordering rule is an allow-list: only erased syntax may precede PluginDef. An adversarial
review of the first version closed four ways past the rules, each now with a test named after it — a
.types.test.ts holding only runtime assertions, a one-line helper re-admitting a folded suite, a
namespace without declare smuggling a value above PluginDef, and a cross-step test whose family
was also a step name.

scripts/generate-bench-files.ts is deleted: nothing referenced it, and its output would have been
rejected by the gate that recommended it.

Phase 2 — per-step benches drive Performance Impact

benchmarks/src/scenarios/* is no longer measured by the impact gate. It stays as the unit of
performance-comparison.yml and of check-benchmark-coverage.ts, because a competitor's spelling of
the same work cannot live inside a step's own bench file.

A step declares cells as data through stepBench('<step>', [cells]). One declaration, two drivers:
stepBench() calls vitest's describe/bench for the local pnpm bench loop and pushes the
resolved cells into a registry; the gate imports the same file in a plain Node process under two
resolution hooks — vitest to a no-op shim, and the '../..' each bench file already had to the dist
build under test — then reads the registry. There is no second copy to drift, and the measured artefact
is the 186 KB bundle rather than TypeScript source.

Cells: 341 → 245. Async cells 1 → 12, collectAllIssues cells 0 → 9, message cells 0 → 2,
JavaScript baselines 9 → 0. The old suite was not fit to be measured: object, strictObject and
looseObject all benched an empty shape, so the child-execute loop never iterated; bigint and
symbol had no success cell at all; 31 steps constructed the schema inside the timed region.

pnpm bench:cells enforces the contract by driving the cells, not by reading them — every cell
produces the issue codes it declares, every step has a success cell, every issue-owning step has a cell
producing its own code, construction is outside the timed region (AST-checked), and the import
allow-list holds. What it cannot decide, its messages say: whether an input is representative, whether
a batch measures work worth measuring.

The gate now shards four ways and merges before the verdict. The "deliberately NOT sharded"
rationale is replaced with the measurements that refute it: 55m12s of measurement against ~40s of
non-shardable fixed cost, so four shards is ~28.5 minutes.

Classification is interval-based. severeScenarios used to require row.stable, so an alarming but
imprecise cell was a silent pass — #124 named that failure mode and treated it by buying precision.
Now cleared / regression / severe / inconclusive are decided against the confidence interval,
stabilityThreshold is a reported diagnostic, and the group aggregate runs over decisive rows.

Two CI null runs (before == after) validated this with a real counter-example: run A classified
construct/tuple as a regression at −5.32% with pairedRme 3.12% — stable, precise, and false.
Its interval spans −5%, so the new rule returns inconclusive. The same runs measured a 32% flip
rate in the stable verdict between identical runs, which is why it is no longer the decision input.

Phase 3 — the API reference is composed from the steps

Each step owns a <name>.doc.md opening with a <!-- step-doc --> block declaring category,
section, summary. Category is declared, never inferred, and a step with no entry, an unknown
category, or a section no template offers fails loudly — a step silently missing from the site with a
green gate is the failure this phase exists to remove.

pnpm docs:api / docs:api:update mirror the api:surface pair and run inside pnpm verify. Six
pages, the catalog, and the sidebar region are generated; the non-step prose lives in six templates.

A whole-corpus audit classified all 798 prose units of the old 1,629-line reference: 532 verbatim,
237 reworded, 28 deliberately dropped, 1 lost and restored. Review risk concentrates in the 51 steps
that previously had only a bullet, whose entries are newly written.

step-completeness no longer scans the site. It reads each step's own entry, which is a stronger rule
than the one it replaces — that one could be satisfied by a page saying the step does not exist.

Phase 4 — partial, stopped to conserve budget

Refuted repository-wide by mutation sweeps: all 110 owned issue codes are genuinely asserted, all 92
customMessage paths, all 92 payload shapes. The epic's central suspicion — an issue code appearing in
a string that never reaches an assertion — does not hold anywhere.

Real defects fixed, each with the regression test that proves it:

• array() and tuple() re-read value.length on their asynchronous paths while the synchronous entry
  points snapshot it, so a child mutating the array it was validating extended its own traversal;
• map() and set() misreported firstIndex once collectAllIssues collected past a failed entry;
• isOneOf accepted undefined against a candidate list excluding it — found by mutation, not reading;
• two unpunctuated public default messages, the only two in the library;
• isRecoverableFailure deleted: git shows it was introduced uncalled and never had a caller.

Refuted rather than fixed: tuple's rest-schema TypeError does not escape the result type (the
core catches it and reports core:unknown_exception), and getter-counting cases already existed.

Mutant triage finished for three slices — 82 distinct mutants, about four fifths real, nearly all now
killed. That corrects the "~1/3 real" estimate in #135, along with two claims of mine withdrawn in
dcbfa80: see below.

Two withdrawn claims, and the process failure behind one

dcbfa80 withdraws a changelog entry and a source comment that measurement does not support.

The looseObject "defect" never existed. main has i < keysLen; the i <= keysLen I fixed was a
live mutation from a concurrent audit sweep, captured into eef3199 by my own
git add packages/internal/src over a shared checkout. Restoring it left the file identical to main.
The lesson is in the tooling, not the judgement: a mutation harness and a broad git add must not share
a working tree.

The record claim — a finite key domain collecting past an internal issue — does not reproduce. It
returns one internal issue on both paths; a second appears only when a recoverable issue preceded it,
which is the documented contract.

Verification

pnpm verify — exit 0: 9/9 quality gates, 147 test files / 2292 tests, per-file coverage policy
passed, api-surface matches, 27 documentation pages compile, docs site builds.
pnpm typeperf — all deterministic compiler-complexity metrics within budget.

Not validated: the sharded workflow end to end. The matrix, artifact names, merge wiring, and
download glob have local equivalents only — no CI run has exercised them, and this pull request's own
Performance Impact run is the first. Bundle-size is unchecked.

Known remainder

• The targeted retry pass is not built. compareResults emits inconclusiveScenarios, but nothing
  re-runs them, so an inconclusive cell is reported and not resolved.
• measured N / added M / removed K is not printed unconditionally; unmeasurable cells are named, but
  added/removed counts against the baseline are not computed.
• The compare job's summary lost its before/after SHA table when the jobs were split.
• benchmarks/README.md still describes scenarios as the impact unit.
• Phase 2 extended the verdict decision in two places and flagged both as its reading rather than the
  decision's letter: improvements count as decisive in the group aggregate, and inconclusive gets its
  own verdict but does not fail the job.
• Phase 4's audit remainder, the dead code at intersection.ts:522-532, two cross-step tests that do
  not discriminate what they claim, and one product decision about live re-yield in map/set are all
  in test: finish the step and core audit stopped part-way in #134 #135.

🤖 Generated with Claude Code

---

Update — hardening pass after external review

An external review of the phase 2 design was recorded on #134 and evaluated. Six items landed. This
section supersedes the "Verification" and "Known remainder" lists above where they disagree.

Two of the review's points reversed decisions recorded earlier in #134, and both reversals were
accepted with the reason stated:

• The group verdict no longer filters to decisive rows. Filtering to rows whose own measurement
  happened to be decisive conditions the aggregate on the measurement outcome — cells with larger
  effects or lower noise are likelier to survive the filter, so the group estimate was biased toward
  the rows most likely to trigger it. The group is now its own estimator: per repetition, the scoped
  cells' log-ratios are averaged into G_r, and the Student-t interval is formed across repetitions.
• The retry does not pool. Adding samples until an interval stops straddling a boundary is optional
  stopping, and "precision target, pre-declared" does not escape it once the set being extended is
  chosen by the first result. It is now two fixed stages — a 5-repetition screen for every selected
  cell, then an independent fixed confirmation batch for candidate regression, severe, and
  boundary-inconclusive rows — judged from the confirmation batch rather than from a pool.

Also landed: one coherent estimator (the interval was centred on the mean of paired ratios while
the reported and severe-triggering point estimate was their median — two estimators, one decision; now
a single log-ratio estimator), compare/report decoupled from the build under test (the catalog is a
hashed artifact; compare loads no production code and runs build: 'false'), the Windows
generated-reference mismatch fixed at the boundary where the difference enters, counterbalancing
confirmed to have survived the shard rewrite and now gated so the next rewrite cannot drop it, and
measured N / added M / removed K printed unconditionally.

The two-stage gate earned its keep on its first real run

json/invalid-json screened as severe at −21.86% and came back cleared at +0.44% in the
independent confirmation batch. Under the previous single-pass gate that would have failed the build.

An accepted regression, and the mechanism that records it

The map()/set() firstIndex correction in this pull request costs roughly 12–15% on
map/collect-all and set/collect-all. It lands only where collectAllIssues is on and an entry has
already failed — the success path is unchanged — and the owner accepted it rather than blocking the
correctness fix on optimizing the buffered path. set/collect-all measured −15.13% and −32.37% across
two screens, so the direction is solid and the magnitude is not.

benchmarks/src/accepted-regressions.mjs records it at both levels, with bounds taken from measurement
rather than picked: a bound tighter than the gate's own run-to-run spread fails on noise instead of on a
change. The group warm/failure/all is acknowledged at −12% because the accepted cells carry it —
set/collect-all −4.25pp and map/collect-all −0.88pp of the measured −6.40%.

It is an acknowledgement, not a suppression. The reported value stays the true one, an acknowledged row
appears in the summary as acknowledged with its bound, and severeGroups still reports the trigger
as measured — a separate unacknowledgedSevereGroups is what fails the gate. Rot is checked in both
directions: an entry whose cell or group the screen reports cleared fails, so the list shrinks as the
code improves; an entry naming something the catalog does not declare fails; and a group entry whose
member cells are all unacknowledged fails, so it cannot outlive the per-cell reasons it rests on.

Staleness deliberately does not read the confirmation batch — one batch clearing a cell the screen
called severe is this gate's noise diagnostic, not evidence a cost is gone.

Two limits are documented rather than left implicit: an acknowledgement cannot tell an accepted cost
from a regression someone got tired of, and a group bound cannot tell whether the cost is still the
accepted one.

The rejected alternative, recorded so it is not re-litigated

Excluding acknowledged cells from the group aggregate was rejected. It would condition the aggregate on
which cells someone previously forgave — the same defect the decisive-row filter had — and shrinking the
denominator would dilute a new regression landing in that group instead of catching it. The argument
is in the module.

Verification, superseding the list above

Every check on this pull request passes, including the full impact chain end to end: preflight, four
measure shards, compare, four confirm-measure shards, and verdict
(run 30547023911). That is the
evidence the earlier body listed as missing — the matrix, artifact names, merge wiring, and download
glob had local equivalents only, and those local equivalents are exactly what missed both original
failures.

pnpm verify exits 0. Windows now passes; it did not before.

What still remains

• The compare job's before/after SHA table, lost when the jobs were split.
• benchmarks/README.md still describes scenarios as the impact unit.
• Optimizing the buffered path in map/set, which would let both acknowledgement entries be deleted —
  and the orphan rot check means deleting the cell entries forces the group entry out with them.
• Phase 4's audit remainder, the dead code at intersection.ts:522-532, two cross-step tests that do
  not discriminate what they claim, and one product decision about live re-yield in map/set — all in
  test: finish the step and core audit stopped part-way in #134 #135, along with an external recommendation to replace the hand-rolled mutation harness with StrykerJS.
  Deliberately not in this pull request.

[DevilTea]

GPT 5.6 sol — review of 4321be4

The hardening pass addressed the major issues I raised on #134: the row estimator is coherent, group estimation no longer conditions on decisive rows, confirmation is independent rather than pooled, compare is data-only, counterbalancing is preserved, and the full workflow now runs green end to end.

I still would not merge this HEAD yet. I see two remaining properties where the Performance Impact gate can make a stronger claim than the evidence supports; both are called out inline.

1. Catalog deletion/rename is still invisible to the advertised added / removed audit. Candidate-owned definitions are the right measurement apparatus, but they cannot simultaneously tell us what the candidate deleted from the apparatus. That needs a separate static base-vs-head catalog diff.
2. A blocking group CI currently ignores cross-runner heterogeneity. The latest green run itself mixed EPYC 7763 and EPYC 9V74 shards. Pairing cancels machine scale for a cell, but a CPU-dependent candidate/base ratio becomes a fixed shard effect; the CI across repetitions cannot see it. A triggered group therefore needs whole-group confirmation on one runner, or it should remain review-only on hosted sharded runners.

Non-blocking cleanup before calling #134 complete: please also sweep the remaining comments/docs that still describe the pre-hardening semantics (for example the workflow header's old decisive/stable-row group explanation, step-bench.ts saying the group trigger needs decisive cells, and the old pooled-retry comment in impact-verdict.mjs). Benchmark methodology comments are part of the maintenance contract here, and stale rules are particularly risky after a redesign this large.

I am submitting this as COMMENT rather than REQUEST_CHANGES because the connected GitHub identity is the PR author; semantically, I consider the two inline P1 findings merge-blocking.

[DevilTea]

Both P1 findings are addressed on 0faf780. Every check on this pull request passes, including the full impact chain (run 30564818047).

P1 — catalog deletion is now visible, from a static diff

scripts/bench-catalog-diff.ts enumerates each revision with git ls-tree, reads each file with
git show <ref>:<path>, and parses the stepBench() call with the TypeScript AST — the same
read-a-revision-as-text idiom inert-change.ts already uses. Three things establish that it executes
no build: a test asserts its import graph reaches only typescript and node:*, never
benchmarks/src/cells/ (which is what registers the loader hook resolving '../..' to a dist); it
runs against main, a revision whose dist this checkout cannot build; and it needs no
VALCHECKER_DIST_URL.

The screen comparison passes --require-catalog-diff and fails outright when the diff is absent, so
the wiring is itself checkable rather than something a reader has to notice. Runtime presence is now
named candidate-only / baseline-only and never conflated with catalog membership. The confirmation
comparison measures a subset and audits nothing, so it prints no catalog line at all rather than an
n/a that reads as "the audit did not happen".

On this pull request the diff reports added 245 / removed 0 alongside 114 unreadable-file
problems, because the base is main where no bench file uses stepBench() yet — an incomplete diff
reported as incomplete rather than as "everything was added".

P1 — a triggered group is confirmed on one runner, and your reasoning turned out to be measurable

Accepted, with the correction stated: the coordinator had earlier argued a cross-shard aggregate was
safe because each cell's paired ratio is machine-cancelled, and framed the residual as
heteroscedasticity. That was wrong for the reason you gave — a cell keeps its shard for all five
repetitions, so a runner-dependent effect on its ratio is a fixed effect across r, shifting every
G_r equally and contributing zero variance. The interval cannot widen for it.

Your finding then proved itself empirically, through the acknowledgement machinery rather than by
argument. Across three runs the same group reported −3.93% inconclusive, −6.40% regression with
interval [−7.1%, −5.7%], and −3.44% cleared. Under the interval scheme cleared and regression
cannot both describe one quantity, so the between-run variation exceeds the within-run interval. Those
three readings are recorded in the module.

A triggered group is now remeasured in full on one runner and blocks only if that batch also
classifies it a regression, read from the artifacts — a confirmation that ran sharded, or that did not
cover every cell of the group, cannot support blocking whatever the workflow intended. The budget is
45 of the job's 60 minutes at a measured 2.33 s per cell-run, so:

group	cells	single-runner cost	treatment
warm/failure/all	9	5.5 min	confirmed, may block
warm/async/success	12	4.7 min	confirmed
warm/failure/library-default	95	36.9 min	confirmed
warm/success	124	50.2 min	review, not blocking, with the arithmetic printed

So your fallback applies exactly where the arithmetic forces it, and nowhere else.

The same argument made the rot rule symmetric

Your finding has a consequence for the accepted-regression mechanism that only surfaced when the rot
check fired: blocking required single-runner confirmation while staleness accepted a cross-shard
screen, so an acknowledged group could neither exist nor be removed without failing on some runs. If a
cross-shard screen cannot support blocking a group, it cannot support un-acknowledging one either.

Staleness now requires the same evidence as blocking — a group retires only on a single-runner
confirmation, a cell only when the screen and the confirmation agree — and where the evidence is
missing the check reports unassessed by name, which is neither a pass nor a failure. Acknowledged
cells and groups are always queued into the confirmation batch, because otherwise no entry could ever
produce the evidence needed to retire it and the rot check would be decoration.

The same reasoning applies to cells, which we had expected it would not: a cell also keeps its shard
across repetitions, so a cleared screen is a single reading. The risk is much smaller, but the fix
costs two cells in the batch, so it is symmetric rather than justified as a weaker rule.

Where a bounded acknowledgement cannot be falsified — a group too large to confirm on one runner —
review is the honest treatment, and that is now stated in the module, the README, the skill
reference, and the changelog rather than left to be discovered.

Non-blocking sweep

Corrected: the workflow header's group argument (which asserted the now-known-false "no statistic for a
between-machine term to enter" — the coordinator's own mistaken reasoning, committed), step-bench.ts
on "two decisive cells", impact-verdict.mjs's pooled-retry comment, and the README sentence you
quoted. Each says what the mechanism now does and why the old claim was wrong. A test written for this
also caught a live reporting bug: the renderer returned early with no cell rows and hid the group
section entirely.

What the gate reported on this run

verdict regression over 60 of 245 standard scenarios
cells measured 60, candidate-only 0 / baseline-only 0
[confirm] verdict review (screen regression): 0 reproduced, 14 not reproduced, 0 unresolved
[confirm] accepted regression: map/collect-all — measured -13.53%, accepted to -25%
[confirm] accepted regression: set/collect-all — measured -30.73%, accepted to -45%
[confirm] rot check not assessed: warm/failure/all — the single-runner confirmation reports it
          inconclusive, which neither confirms the accepted cost nor shows it gone

Fourteen screen regressions, none reproduced, so a screen regression resolved to review on
independent evidence rather than blocking. pnpm verify exits 0; 149 harness tests and 11
static-catalog tests pass.

[DevilTea]

GPT 5.6 sol — second review of 0faf780

I re-reviewed the current HEAD rather than carrying the previous findings forward. The two earlier P1s are substantively addressed: the runtime presence counts are now separated from a static catalog instrument, and a blocking group now requires a whole-group single-runner confirmation. The latest Performance Impact run also exercises that new path end to end.

I found three follow-on issues in the hardening implementation, all called out inline. I would fix them before merging because each changes whether the gate is allowed to make or withhold a blocking claim:

1. --require-catalog-diff currently requires the artifact to exist but does not require the audit to be complete. The latest green run proves this path can stay green with problems populated.
2. Group confirmability is computed from the union of group cells and unrelated row/acknowledgement confirmations, so unrelated work can make an individually confirmable severe group fail open to review.
3. Accepted-regression bounds are still judged from the deepest point estimate seen in either stage, bypassing the interval semantics and independent-reproduction rule the rest of the gate now uses.

One non-blocking follow-up after these: the static catalog audit currently diffs IDs only. group, batch, and async are measurement-contract fields too (the runtime catalog hash already treats them that way), so reporting metadata changes would make apparatus edits much easier to audit. I would not hold this PR solely for that if the three inline findings are fixed.

Because the connector is acting as the PR author, this is submitted as COMMENT; semantically the three inline findings are merge-blocking for me.

[DevilTea]

All three findings are addressed on e74e196. Every check passes, including the full impact chain (run 30594089941).

P1-a — completeness is in the contract, and the escape route is closed

check-bench-cells.ts now requires a literal cell name, which closes exactly the hole you found: a computed name passed the quality gate, made the static reader unable to parse the head, and left the required check green. bench:catalog-diff exits non-zero on a fatal problem, a head problem is always fatal, and a base problem is fatal too — with one explicit, named migration case for the all-legacy base. compare --require-catalog-diff refuses an artifact carrying a fatal problem rather than merely checking the file exists.

The follow-up condition is a test rather than a comment: isLegacyBaselineOnly cannot fire once baseCells > 0, and stops tolerating the legacy base the moment the base declares any cell pins that. So the toleration expires by construction when this pull request merges; nobody has to remember.

CI evidence: the compare line now reads cells measured 245, candidate-only 0 / baseline-only 0, catalog added 245 / removed 0 — the static audit and the runtime counts side by side and never conflated.

P1-b — group confirmability no longer depends on unrelated work

Each confirmed group gets its own single-runner batch sized by its own cells. Rows keep the sharded batch, and acknowledged cells ride with the rows, since they need no single runner and must not consume a group's budget. unrelated row confirmations cannot cost a group its confirmability puts 130 unrelated rows beside a two-cell group: the rows shard four ways, the group keeps its own batch, and nothing is downgraded.

Visible in this run as two separate comparisons — 69 cells for the rows and 9 for warm/failure/all on its own runner.

P1-c — the bound uses the gate's own semantics

Each stage's interval is classified against -maxRegressionPercent: wholly worse is a breach, wholly inside is within bound, spanning it is unassessed. A breach requires both batches, so your −60% screen followed by a cleared confirmation is unassessed rather than a red gate — and an acknowledgement can no longer make the gate stricter than having none.

The bounds did not move, and the arithmetic is on the record: map's widest interval [−18.2%, −10.9%] against 25%, the group's [−7.1%, −5.7%] against 12%, and set's widest [−42.9%, +26.1%] against 45% — inside by 2.1pp. All classify within under the stricter reading. The consequence is recorded rather than smoothed: on a noisier run set/collect-all will report unassessed instead of acknowledged. That blocks nothing, and widening the bound to make it read as acknowledged would be widening an acknowledgement to suit a measurement.

Two process failures worth stating, since they bear on how much the local evidence is worth

Fixing P1-b broke compare with a TypeError — the plan's shape changed and the CLI branch that formats it was not updated. The tests missed it because they call the planner directly on the assumption that the CLI is a thin I/O shell; it was not, since formatting a plan is logic about the plan. planSummaryLines() now lives beside the planner, so a shape change fails a test instead of a job.

Two smaller ones, both the same class: a mapfile in the verdict job that the local bash 3.2 cannot run, so that snippet was unverifiable locally rather than merely unverified — now replaced and exercised under 3.2 against the real plan; and, earlier, a GNU seq dependency. The honest summary is that a local check already built was twice not re-run after a later change. Where the local equivalent could not exist at all, it has been replaced by one that can.

Non-blocking metadata audit

Not done, and recorded on #134 with the reasoning rather than squeezed in unverified: the static reader would need per-field diffing and the report a vocabulary for a metadata change as distinct from an addition or removal. It is worth pairing with the base-problems rule above, which only becomes reliable once this pull request merges.

What the gate reported

verdict regression over 69 of 245 standard scenarios     (rows, sharded)
verdict regression over  9 of 245 standard scenarios     (warm/failure/all, one runner)
[confirm] verdict review (screen regression): 0 reproduced, 36 not reproduced, 0 unresolved
[confirm] accepted regression: set/collect-all — measured -32.38%, accepted to -45%
[confirm] rot check not assessed: warm/failure/all — the single-runner confirmation reports it
          inconclusive, which neither confirms the accepted cost nor shows it gone

Thirty-six screen regressions, none reproduced, so a screen regression resolved to review on independent evidence. 155 harness tests and 14 static-catalog tests pass; pnpm verify exits 0.

[DevilTea]

GPT 5.6 sol — re-review of e74e196

The previous three findings were materially addressed: the static catalog audit now fails on unreadable head/current catalogs with an explicit one-time legacy-base exception; group confirmation is scheduled independently per group on one runner; and accepted-regression bounds are now interval-based with a reproduced-breach rule. The latest PR run (30594089941) also exercises the new fan-out end to end: four screen shards, 69 row-confirmation cells over four shards, a separate 9-cell warm/failure/all group batch, and a green final verdict.

I still would not merge this HEAD yet. I found two remaining P1 properties and one P2 workflow bug, called out inline:

1. An unassessed acceptance can still fall through to ordinary severe/group blocking. The bound logic itself is now conservative, but the final verdict only exempts accepted.acknowledged; when the bound spans in one batch, the row/group becomes unacknowledged and the normal reproduced-severe path can fail even though no reproduced bound breach exists.
2. The static contract diff audits cell identity but not group membership. Moving an existing cell between gate groups changes the load-bearing severe-group contract while still reporting zero catalog additions/removals; the runtime comparison cannot detect that history because the candidate apparatus supplies the group to both sides.
3. The confirmation budget is still hard-coded to five repetitions. PR runs are five, but workflow_dispatch accepts a larger runs value and the actual confirmation jobs use it. The planner can therefore admit a group as a <45-minute single-runner batch that then exceeds the 60-minute job timeout.

The old inline threads being outdated is consistent with the fixes; I am not repeating those old findings. As before, this is submitted as COMMENT because the connected GitHub identity is the PR author; semantically the two P1 findings are merge-blocking, while the P2 should be fixed before treating manual dispatch as reliable.

[DevilTea]

All three findings are addressed on 28a9cfc. Every check passes, including the full impact chain.

P1-1 — acceptance state is now independent of ordinary regression state

You were right that this was P1-c's pattern in a new place. An entry now exempts its cell or group from the ordinary rules whatever its bound turned out to say; only the acceptance list itself can fail on it — a reproduced breach, a stale entry, a malformed one. Rows resolve as acknowledged or acceptance-unassessed, and neither enters severeClaims.

Tests are your cases exactly: at cell level, a screen severe at [−60%, −20%] spanning a 45% bound with a confirm severe at [−35%, −25%] wholly within it resolves acceptance-unassessed and blocks nothing; at group level, a cross-shard screen spanning the bound with a single-runner confirmation within it stays out of unacknowledgedSevereGroups. A control asserts that a reproduced breach still blocks, so the exemption is not unconditional.

P1-2 — the static diff audits id → group

Accepted, and the escalation was right: this is the same structural argument that justified a static instrument at all, since the apparatus supplies each cell's group to both measured sides and they therefore agree on the new group by construction.

staticCatalog retains every cell's group including baseline. The diff carries changed: [{ id, baseGroup, headGroup, gateEffect }] and the report prints catalog added M / removed K / regrouped C with a named section. A baseline transition is labelled as having entered or left the gate, so an accompanying addition or deletion reads as a move rather than as two unrelated events. Tests cover a cell moved out of warm/failure/all under an unchanged id reporting added 0 / removed 0 / regrouped 1, and both baseline transitions.

batch and async remain deferred on #134, since only group is load-bearing for a blocking verdict.

P2 — the planner prices the batch the workflow will run

repetitions comes from screen.runCounts.baseline and is refused when the two sides disagree. The test asserts your figures: 100 cells fit at five repetitions and do not at ten, where the planner's own model gives 79.7 minutes.

An independent review of the surface none of these rounds has covered

Separately, the four runtime behaviour changes in this pull request — the only ones in 413 files — were reviewed independently, since all three of your passes have been on the gate rather than on the library. The reviewer could not fault any of the four, and the evidence is worth recording:

• map/set materialization was probed exhaustively over 625 Set and 2,401 Map orderings of failure, duplicate and identity, including key-only, value-only and simultaneous failures and duplicates on both sides of a failure. NaN and signed-zero probes pass; native Map and Set canonicalize a stored -0 to +0 and the duplicate metadata retains the original index.
• The five siblings a stopped audit had left unexamined — record, intersection, strictObject, looseObject, object — carry no sync/async divergence of the array/tuple class: each snapshots its key set or property count at construction.
• isRecoverableFailure never had a production caller, was never exported from core/index.ts, and appears in no API surface.
• Run against pre-fix source, the four regression cases fail and one passes; against this branch all five pass.

One process note

After the three fixes above, the new tests passed but pnpm verify exited 2 on a tsc error: StaticCatalog gained a field and a hand-built object in bench-catalog-ids.test.ts did not follow, which vitest runs but never typechecks. That is the third instance this session of a local check not being re-run after a later change, and the only reason it did not reach CI is a standing instruction to re-run everything rather than only what is new.