governance: Validate Hypatia Baseline red on main — the gate builds the scanner from a pin that predates our own fix for the class it fires on

[hyperpolymath]

Symptom

governance / Validate Hypatia Baseline is red on main and has been the only
real red there. Run 35783374301, job 106934294699, 38s (a real verdict, not a
startup death):

##[error]Gate failed: 5 unfiltered finding(s) at or above 'info'

A standing red on main is itself a detector-blinding condition: while it sits
there, nobody can tell a NEW gate failure from this one.

What the five findings are

n	rule	severity	location
3	security_errors / secret_detected	critical	lib/hypatia/scanner_suppression.ex:252
2	code_safety / zig_ptr_cast, zig_align_cast	high	ffi/zig/src/main.zig

Both clusters are false positives, and they fail for different reasons.

The three secrets: a detector matching the prose that describes it

Line 252 is a comment that documents the three @secret_patterns which match on
form alone — it spells out api_key = "...", secret = "...", password = "...".
All three patterns match the comment that documents them. Same family as the
RE005 defect in #834, where the rule "matched the prose arguing against the thing
it was looking for". Documenting a false-positive class creates instances of it.

The two Zig casts: the mandatory opaque-handle idiom

Already filed as #834. ffi/zig/src/main.zig declares pub const Handle = opaque {},
so recovering *HandleState requires exactly @ptrCast(@alignCast(handle)). The
rule matches a bare ~r/@ptrCast/ at :high and reports at main.zig:1 rather than
the cast site, so no per-line directive can reach it.

Root cause of the secrets half — the gate runs a scanner older than our own fix

The governance gate builds the scanner from a pinned commit and scans HEAD.
They are different commits.

• pin: 0e913426, 2026-09-06 (HYPATIA_PIN in hyperpolymath/standards
.github/workflows/governance-reusable.yml)
• scanned tree: main @ 8e8943f, 2026-09-22

bc8812e ("label-aware secret suppression", #782, 2026-09-14) is an ancestor of
main and is not an ancestor of the pin — verified with git merge-base --is-ancestor in both directions. The pinned lib/hypatia/scanner_suppression.ex
has 4 occurrences of the label/context-suppression identifiers; HEAD's has 12.

Our own cure for this exact false-positive class is in the repo and absent from
the scanner enforcing the gate.

This also constrains which cures are even possible: compiled-in suppression
(@default_exemptions, @training_corpus_paths) lives in the scanner and cannot
affect this gate. Only scanned-tree mechanisms can — .hypatia-ignore,
.hypatia-baseline.json, and inline # hypatia: allow directives.

Acceptance criteria

• governance / Validate Hypatia Baseline is green on main, with kept = 0
  (BLOCKING_THRESHOLD: info and the scanner emits only >= medium, so
  "kept" must reach zero — there is no headroom).
• The secrets cure is line-scoped, not file-scoped: a planted
  ghp_ + 36 chars elsewhere in lib/hypatia/scanner_suppression.ex still
  reddens the gate.
• The zig entries carry tracking_issue pointing at scanner: RE005 matches '|| true' inside comments; zig_ptr_cast/zig_align_cast flag the mandatory opaque-handle idiom #834 and are deleted
  when scanner: RE005 matches '|| true' inside comments; zig_ptr_cast/zig_align_cast flag the mandatory opaque-handle idiom #834 lands. They are acknowledged rule defects, not accepted debt.
• Each suppression is proven necessary by a mutant: removing it reddens the
  gate; restoring it greens it.

Structural follow-up (not this issue)

Bumping HYPATIA_PIN past bc8812e would cure the secrets half at the source,
but that pin is a required status check on ~120 caller repos, so it is a
cross-repo change with that blast radius. Filed separately against standards.

[hyperpolymath]

Cure is up as #856; the structural root cause promised above is now filed
against standards as hyperpolymath/standards#1014.

Split as stated: #856 cures hypatia with scanned-tree mechanisms only (a
line-scoped inline directive plus two baseline acknowledgements tracked to
#834), because those are the only mechanisms a consumer has while the pin
lags. #1014 carries the pin bump itself, which is a required status check on
~120 callers and needs a rollout rather than a commit.

This issue's acceptance criterion is green on main, so it stays open until
the post-merge run of Validate Hypatia Baseline is read.

[hyperpolymath]

Green on main — acceptance criterion met

governance / Validate Hypatia Baseline is success on main @ ecc56fa2
(check-run 106954722721, 21:58:22Z → 21:59:08Z, 46s).

The green is not vacuous. From the job log:

BLOCKING_THRESHOLD: info
[hypatia] scan complete: 3 findings >= medium (critical=0, high=2, medium=1, low=0, info=0); exit 1
"findings_kept": [],

• the scanner ran and found things — a pass with findings_kept: [] after
  three real findings, not a pass because nothing was scanned;
• critical=0 where the pre-fix control on this same gate read critical=3;
• BLOCKING_THRESHOLD: info with the scanner emitting only >= medium means
  there is no headroom — "kept" had to reach exactly zero, and did.

What cured it

Landed in #856 (squashed as ecc56fa2), two mechanisms, both necessarily in the
scanned tree rather than compiled into the scanner:

1. lib/hypatia/scanner_suppression.ex — a line-scoped # hypatia: allow
   directive over the comment that spells out the three form-only secret shapes.
   The prose describing the detector was matching the detector.
2. .hypatia-baseline.json — two acknowledgements (45 → 47) for the
   zig_ptr_cast / zig_align_cast findings on ffi/zig/src/main.zig, both
   carrying a note and a tracking_issue (scanner: RE005 matches '|| true' inside comments; zig_ptr_cast/zig_align_cast flag the mandatory opaque-handle idiom #834), so neither is anonymous
   debt.

⚠ Both entries must be deleted when #834 lands — that is in #834's
acceptance criteria.

Why a compiled-in fix could not have worked

The gate builds the scanner from pinned commit 0e913426 (2026-09-06) while
scanning the consumer tree at HEAD. Suppression added to @default_exemptions
after that pin is simply not in the binary doing the scanning. Verified:
bc8812e is an ancestor of main but not of the pin. Root cause of the
pin lag filed as hyperpolymath/standards#1014 (~120 callers).

State of main

75 success / 4 skipped / 3 failure. The three failures are the mirror jobs
(mirror-bitbucket, mirror-disroot, mirror-gitea) tracked in #845 and
blocked on owner key registration — no governance or test check is red.

Closing.

[hyperpolymath]

Correction to the census in my closing comment: that was read while two checks
were still in_progress. Now settled on main @ ecc56fa2:

80 success, 4 skipped, 3 failure (was reported as 75/4/3 + 2 in_progress).

The three failures are unchanged and are exactly the three owner-blocked mirror
jobs — mirror-bitbucket, mirror-disroot, mirror-gitea (#845). Both checks
that were pending resolved green, including Integration Tests and
Integration Status.

The acceptance criterion for this issue — governance / Validate Hypatia Baseline
green on main — is unaffected.