The obvious reaction to 'a quiet runner reaches 5.3 us in 20 min while this laptop needs 5.5 h
for 30-42 us' is to kill the running session. Wrong, for two reasons now written down so the
decision is visible rather than inertial:

1. It answers a question the runner cannot. The +13.9 us class-1 pattern is a property of the
   LAPTOP's nine sign-kk pairs. sign-aa on ubuntu says there is no arm offset ON UBUNTU, where
   allocator, alignment, scheduler and a 23x tighter distribution all differ. Only the local
   sign-aa, at +-10 us, tests the hypothesis on the machine where the pattern was seen.
2. It is the like-for-like successor to v3b: same machine, same build, same rules, 17x the
   samples - the only way to tell whether v3b's readings were power-limited or environment-limited.

And aborting a pre-registered session on a preliminary that does not bear on its own validity is
the habit pre-registration exists to prevent: easy to justify each time, corrosive in aggregate.
The correct response is that the session AFTER this one moves machines.

Security Impact: none - documentation only.

Building on top of an old dist/ can fail with a missing dist/chunks
module. Document the clear-and-retry workaround next to the build
acceptance criterion so contributors in existing clones aren't blocked.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

TCE-72. The `test` job is the ONLY gate on test -> build -> provenance ->
cosign-sign -> pypi-publish, and it cannot see the thing that matters.

WHY IT COULD NOT FAIL FOR THE RIGHT REASON

It installs dev = ["pytest>=8"]. It never builds the pinned Falcon library,
never sets FALCON_DET1024_LIB, never sets TRELYAN_REQUIRE_KAT. So every lib-gated
test skips. Its anti-vacuity counter is

    grep -cE "^tests/.* (PASSED|FAILED)" pytest.log

which BY CONSTRUCTION CANNOT COUNT SKIPPED, and the ~50 lib-independent tests
clear its floor of 15 on their own. Measured in exactly that environment: 50
passed, 19 skipped, counter = 50. The counter is blind in both directions --
DELETING the 13 lib-gated tests outright would not change it.

So SLSA Build-L3 provenance and a Rekor-logged cosign signature were produced
without anything having verified signature byte-identity against the
on-chain-accepted goldens, runtime private-key zeroization, or worker-stdout
containment. To a downstream consumer "signed and attested" reads as vouched
for; it vouched only for where the bytes came from.

THE FIX: require ci.yml's byte-identity KAT to be green FOR THIS TAG

Cross-workflow `needs:` does not exist, so the new require-signature-kat job
asks the checks API directly: did the job that builds the PINNED Falcon source
and re-signs the committed goldens on Linux, macOS and Windows succeed for this
exact commit? build now needs [test, require-signature-kat].

Scoped to signature-kat on purpose rather than "every check green":
contract-drift is red by design until the redeploy, and coupling releases to
that is the maintainer's policy decision, not something to smuggle in via a gate.

REAL DATA CHANGED THE IMPLEMENTATION TWICE, which is the point of testing it

My first version counted legs and failed on any non-success. Run against a real
commit it was WRONG on both counts:

  * SIX legs, not three. A commit both pushed and open in a PR gets two workflow
    runs, so the 3-OS matrix appears twice.
  * one macos-latest leg carried conclusion "failure" from the EARLIER run while
    the later one succeeded. "Any non-success blocks" would have refused a
    release over a stale result -- as wrong as passing on nothing.

So it now reduces to the LATEST result per leg (sort -r on ISO-8601 started_at,
then first-wins per name), and separately requires all three OS legs to be
PRESENT -- a leg that was never scheduled is not a pass, and counting rows alone
would accept one green leg as though it were three.

Also: `gh api --slurp` is rejected together with `--jq`, so the filter runs
per page and must not group; grouping is done with sort+awk, which additionally
means this needs no external jq on the runner.

The `test` job now counts and prints SKIPPED, and its comment states plainly
what its counter cannot see and where that assurance actually comes from.

VERIFIED

  * the gate extracted FROM release.yml, run against live GitHub check-run data:
    stale macos failure correctly superseded, 3 legs green, EXIT=0
  * all four failure branches exercised with synthetic inputs:
      one leg FAILED        -> EXIT=1
      a leg MISSING         -> EXIT=1 (names the OS)
      no legs at all        -> EXIT=1 (says CI never ran on this commit)
      one leg still PENDING -> EXIT=1
  * bash -n clean; release.yml parses; needs chain confirmed

NOT VERIFIED HERE: no tag was pushed, so the job has not run inside Actions.
The gate logic is verified against the real API from this machine; the workflow
wiring is verified only by parsing.

Automatically generated by python-semantic-release