ci(0.7.1g1P2): authority-transport non-vacuity floor instead of a frozen count

[GionaGranchelli]

Base

c4d3c84a28ea8991f667f6cfddf771994557f927 — the current epic tip, which still carries two authority-transport tests.

Why

PR #476 adds a third authority-transport test to MutationPopulationAdmissionIntegrationTest: the T7 discriminator that runs the real verifyMutationRatchet under RECORDED_EVOLUTION with a fresh nested PIT measurement. That is the class where such evidence belongs, so the count legitimately grew — and the anti-vacuity step in mutation-authority-integration.yml failed on its own contract, not on a failing test. The job's own echo:

executed=3 failures=0 errors=0
::error::expected exactly 2 authority-transport tests, got 3

The step is named "Assert the proof was not vacuous", which is a minimum-execution invariant, not a frozen suite cardinality. This PR makes the code say what the name says.

Change (workflow only, one file)

-          [ "$executed" = "2" ] || { echo "::error::expected exactly 2 authority-transport tests, got $executed"; exit 1; }
+          [ "$executed" -ge 2 ] || { echo "::error::expected at least 2 authority-transport tests, got $executed"; exit 1; }

plus the adjacent comment, which now records that this is a floor rather than a cardinality. The step name is unchanged, so no check identity churns.

Why a floor and not = 3

The workflow PR must be independently testable against the epic it targets, which still has two tests until #476 merges. = 3 would fail against its own base, defeating the point of separating the workflow change at all. Sequence: this PR green on its own → merge → rebase #476 → three tests → the same floor stays green.

Verification on this exact base (independent, as required)

Local equivalent of the workflow's own commands, then the step's logic replayed verbatim:

./gradlew :build-logic:canonicalProbeIntegrationTest \
  --tests '*MutationPopulationAdmissionIntegrationTest*' --rerun-tasks
→ TASK_RC=0
report: TEST-dev.tramai.build.quality.MutationPopulationAdmissionIntegrationTest.xml (exactly one match)
executed=2 failures=0 errors=0
cases: "the real ratchet rejects an authorization retained after its own consumption",
       "the real ratchet measures the candidate, consumes the base authorization and passes"

simulating the step:
  executed=2 (actual):        old [ = 2 ]  PASS   new [ -ge 2 ]  PASS
  executed=1 (hypothetical):  old FAIL            new FAIL
  executed=0 (hypothetical):  old FAIL            new FAIL
  failures/errors guard: PASS

CONCLUSION: new guard on the current epic base: PASS (independent)

The executed=1 and executed=0 rows are the point: the step still fails loudly when the task selects nothing, which is the entire reason it exists.

• verifyChangePolicy -PchangePolicyBase=c4d3c84a… — PASSED, class ci-workflow

Scope

Workflow-only, per .github/AGENTS.md rule 5. No production code, no tests, no gate semantics weakened — only an over-fitted equality replaced by the invariant the step is named for.

Known limitation, accepted

A floor no longer detects a deletion of one transport case purely from cardinality. An exact count was a poor proxy for identity anyway — = 3 proves three tests ran, not that T7 ran. If T7 ever needs independent CI pinning, the right form is asserting a named testcase is present in the XML, not freezing the class total. Not doing that now; T1–T19 coverage is tracked as its own ledger.

[GionaGranchelli]

Two corrections to this PR description and its commit message, recorded rather than silently edited:

1. Change class. The body and commit say ci-workflow. The actual gate output was verifyChangePolicy PASSED — 1 changed file(s), change class: runtime-behaviour, no policy violations. The detector classified a .github/workflows/** change as runtime-behaviour; the gate passed either way and no violation exists. Flagging it because the artifact should match what the tool actually said, and because the classification is worth a look if ci-workflow is meant to be detected for workflow-only diffs.

2. Typo in the commit message. The verification block reads PRESSERVE FAIL under BOTH guards; the intended text was still FAIL under BOTH guards. The measured result is unchanged: executed=1 and executed=0 fail under both the old equal-count guard and the new floor.

[Copilot]

Copilot review overview

🟢 Approval recommended

The single-line workflow change correctly replaces an over-fitted exact-count check with the minimum-execution floor the step name describes, holds on the current base, and introduces no concrete defects.

Review effort: Balanced
Findings: None

What changed in this PR

This PR relaxes a single assertion in the mutation-authority-integration.yml CI workflow. The "Assert the proof was not vacuous" step previously required that the MutationPopulationAdmissionIntegrationTest class run exactly 2 tests. Because the step's purpose is to guarantee the authority-transport proof actually executed (a Gradle test task that selects nothing is green), the correct invariant is a minimum-execution floor, not a frozen suite cardinality. This unblocks the incoming PR #476, which legitimately adds a third authority-transport test (the T7 discriminator), while keeping the step green on the current epic base that still has two tests.

Changes:

• Replaced the exact-count check [ "$executed" = "2" ] with a floor check [ "$executed" -ge 2 ] and updated the error message to "expected at least 2".
• Updated the adjacent comment to document that this is a non-vacuity floor rather than a fixed cardinality.

File	Description
.github/​workflows/​mutation-authority-integration.yml	Changes the vacuity guard from an exact = 2 test count to a -ge 2 floor and clarifies the explanatory comment.

I verified that MutationPopulationAdmissionIntegrationTest currently defines exactly two class-level @Test methods, so the -ge 2 floor passes on this base, and that the empty/non-numeric $executed case still fails loudly through the || branch. No references to the former "exactly 2" expectation exist elsewhere in the repo. The change is scoped to a single workflow file with no production, test, or gate-semantics changes beyond the acknowledged (and intentional) loss of deletion detection by raw cardinality.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.