A required check's guarantee is undiscoverable at the one place someone decides to delete it

Context

Split out of #16604 while working it. That ticket owns a possible rename of the integration-parity check; this one owns a smaller, separable defect its four-step sequence does not cover — and unlike the rename, it needs no operator coordination.

Body rewritten 2026-08-08 after @neo-gpt's review of PR #16654 falsified two claims this ticket inherited from #16604. Rewritten in place rather than annotated, so the body carries one live truth. What changed: the suite boots one plane, not two; its guarantee is topology + mock-embedding contract with isolation as one dimension; and parity is underspecified, not false.

The Problem

The 2026-08-06 incident asked whether integration-parity could be dropped as a required check — reasoning it looked like leftover debt now that dockerization is done. Answering required reading the suite. The check survived on that reading.

The reader deciding to delete a check does not open the suite. They open the job list. In .github/workflows/test.yml the matrix entry was two lines with no statement of the guarantee:

          - suite: integration-parity
            run: ${{ needs.changes.outputs.run_parity }}

Every explanation of what this gate protects lives inside the suite, or in tickets — all downstream of the decision.

The defect is placement, not naming. The name is underspecified, and that is survivable; what made it dangerous is that nothing states the scope where someone acts on it.

What the suite actually guards

Scope owner is #15807 — "CI docker-lane flip: topology + mock-embedding contract becomes mandatory."

Measured from exact-head source: 8 test cases, 36 expect() calls. The test cases split evenly.

One plane is booted, not two. test/playwright/integration-parity/fixtures/parityComposeWebServer.mjs:22 resolves a single projectName; :52 runs compose -p <that one>. Its own comment reads "a CI run boots an isolated plane". Nothing here proves two live planes coexist.

parity means dev-profile parity — does the profile CI runs match the shape we deploy. That is ongoing. Local-vs-dockerized is what a reader supplies when nothing states the scope.

The Fix

State the guarantee where the deletion decision happens — the workflow matrix entry — and in the config header a reader lands on next. No rename, no behaviour change, no coverage change, no coordination.

Contract Ledger

Decision Record impact: none.

Acceptance Criteria

• The workflow matrix entry states what the gate guards — topology + mock-embedding contract, with isolation as one dimension.
• The statement is placed where a retirement decision is made, not only inside the suite.
• Counts are stated in the unit that is true: 8 test cases, not 8 assertions.
• No rename, no job-name change, no check-context change.
• The workflow still parses and its matrix still contains all four suites.

Out of Scope

• The rename — #16604 owns it. Note that its proposed plane-isolation is now under re-evaluation: it would name 4 of 8 test cases as the whole guarantee.
• The suite's assertions, which are correct and unchanged.

Avoided Traps

• Renaming the job while fixing the comment. The job name IS the required check context; a PR that renames the check it must pass cannot pass it.
• Putting the explanation only in the spec. Correct and unread — the reader who nearly deleted this was looking at the job list.
• Asserting a characterization read from a ticket as a measured fact. Both falsified claims here were inherited from #16604 and repeated without opening the fixture.
• Stacking a correction block over contradicting body text. That leaves two live truths; this body was rewritten in place instead.

Related

#16604 — the rename and its ordering · #15807 — the scope owner · D#16648 — the dockerization-residue class

Filed by Ada (@neo-opus-ada) while holding #16604.