CI: governance + hypatia-scan red on main — 104 Hypatia findings vs empty baseline

[hyperpolymath]

Summary

main has been failing two workflows on every push since #392 (2026-06-20):

• governance / Validate Hypatia Baseline
• scan / Hypatia Neurosymbolic Analysis

Both fail with the identical result:

[hypatia] scan complete: 104 findings >= medium (critical=60, high=33, medium=11, low=0, info=0); exit 1

Root cause

The Hypatia CLI exits 1 whenever the repo has any ≥medium finding, and .hypatia-baseline.json is empty (3 bytes), so the baseline job fails on any finding. This is a repo-wide condition, independent of any single PR.

Evidence

• main runs of hypatia-scan.yml + governance.yml are failure for Ci/gitleaks self hosted fix #393–docs(audits): record central actions/cache SHA corruption + #394 repair #396; last green was feat(rsr): direct capability declaration primary; preset optional #392.
• Re-observed on PR ci(staleness): tolerate in-window reusable pins + wire deliberate bump path #397 (commits e29c303 / f01ace5 / 6fcc7dd) — that PR's own gate (Check Workflow Staleness) passed; only these two pre-existing jobs were red. Surfaced during ci(staleness): tolerate in-window reusable pins + wire deliberate bump path #397; not caused by it.

Options (needs owner decision)

1. Triage/clear the 104 findings (60 critical first).
2. Regenerate the baseline so known findings are recorded (scripts/apply-baseline.sh) and only new findings fail.
3. Make the scan advisory (fix-forward / continue-on-error) until the backlog is cleared.

Notes

• Orthogonal to the merged ci(staleness): tolerate in-window reusable pins + wire deliberate bump path #397 (workflow-staleness window).
• Dup-check via the search API was rate-limited when filing; please close as duplicate if an equivalent issue already exists.

[hyperpolymath]

Full triage complete (#521). Hypatia's first completed run on standards surfaced 195 findings; a 24-agent triage → adversarial-verify workflow classified and re-checked every one:

• 129 FALSE_POSITIVE — mirror double-reports (Hypatia reusable SARIF converter can re-upload code-scanning mirror findings #378), guarded/infallible unwraps, benchmark expect(), XML-namespace http:// URIs, public credential-less CORS discovery manifests, .envrc {{placeholder}} exports, idiomatic CString FFI as_ptr, doc-only historical directory references.
• 23 REAL_DEBT — tracked with expiry (2026-10-21) + a tracking issue, owned elsewhere (TS→AffineScript [campaign] Unnecessarily-JavaScript → AffineScript estate migration (UMBRELLA) #254, product evictions [carve-out 2/9] Evict k9-svc/ implementations → k9-ecosystem; dedupe k9-svc/actions/validate → k9-validate-action #491/[carve-out 3/9] Evict protocol implementations (avow, axel, consent-aware-http, mcp-repo-guardian, repo-guardian-fs); keep spec text #492/[carve-out 5/9] Evict lol/ (corpus crawler product) → own repo #494/[carve-out 7/9] Delete/archive scaffold junk & session detritus at the canon root #496, third-party [carve-out 4/9] rhodium-standard-repositories/ cleanup: de-vendor satellites/, merge templates into rsr-template-repo, delete the lying .gitmodules #493, proof debt Epic: estate proof-debt remediation (2026-05-18 reconciled audit) #124, the scorecard.yml naming reconciliation).
• 43 FIX_NOW — 5 fixed in this PR (job timeouts + push-email removal), 3 real bugs routed to their proper campaigns (a latent Zig off-by-one → fix the ~230× shim at its boj-server source, not the copy; an avow demo XSS → product eviction [carve-out 3/9] Evict protocol implementations (avow, axel, consent-aware-http, mcp-repo-guardian, repo-guardian-fs); keep spec text #492), and 35+ that are all one underlying security item deliberately left blocking (see below).

Result: .hypatia-baseline.json, 118 entries (96 permanent FP + 22 tracked). Adding it activates the previously-skipped validate-hypatia-baseline job on this repo.

The baseline gate is intentionally RED: a small number of critical findings correspond to one security item that must be remediated at its provider (out-of-band, owner action) rather than suppressed — a baseline must never silence a live-credential alarm. Details are in the PR and have been raised with the owner directly. Local filter test: 150 suppressed / 45 kept; not yet re-run against HEAD's fresh scan (Elixir scanner not buildable here) — CI is the real check.

[hyperpolymath]

Status: triage + baseline deliverable is done and merged (#521); one item keeps this open.

All 195 findings from Hypatia's first completed run were triaged and adversarially verified (24-agent triage → refute pass): 129 FALSE_POSITIVE, 23 REAL_DEBT, 43 FIX_NOW. Shipped .hypatia-baseline.json — 118 entries (96 permanent false-positives + 22 tracked-with-expiry pointing at the owning campaigns: #254, #491–#496, #124, #378). 5 FIX_NOW findings were fixed outright (job timeouts + push-email-notify.yml removal). Of the 52 secret findings, the 12 .envrc {{placeholder}} false-positives are baselined.

Why this stays open: the remaining 40 secret findings correspond to a single credential finding that must be remediated at its source rather than suppressed — it is deliberately left unbaselined so the gate stays honest, and is being handled directly with the owner (see #521). That is why the Hypatia / Governance gate is currently red. This issue closes when that credential is revoked + purged, at which point the gate goes green on its own.

[hyperpolymath]

2026-08-25 — original premise is dead; one credential is all that is left

.hypatia-baseline.json is now 46,370 bytes / 118 entries (PR #521), not the 3-byte empty file this issue was filed against.

Hypatia Security Scan is still failure on main as of 2026-08-24T21:30Z — deliberately, per this issue's own 2026-07-27 comment. Nothing else keeps it red. Revoke and purge the credential behind the 40 unbaselined findings and this closes itself.

Labelled needs-owner and listed in #637 — it is a decision, not backlog.

Verified 2026-08-25 against live GitHub, not local checkouts.

[hyperpolymath]

Re-verified 2026-08-26 — the premise of this issue is now stale, and a different fault is what keeps main red

The credential story no longer holds

• scan / Hypatia Neurosymbolic Analysis is not failing. Seven consecutive success runs on main since 2026-08-25T22:02:36, through 2026-08-26T17:44. The 2026-08-25T10:15 comment above predates that flip by ~12 hours.
• The hypatia/security_errors/secret_detected family — the "~40 unbaselined secret findings" named here as the sole remaining blocker — is at 0 open / 52 fixed (full state census via the code-scanning API).
• Current open Hypatia alerts are 74, all hypatia/implementation_inside_canon/HYP-S009 — a canon-boundary rule, not a secret rule.

⚠️ One caveat I cannot close: fixed state alone does not distinguish credential actually rotated from the file moved and Hypatia stopped looking. If the revocation was never performed, it still needs doing — but it is not what is gating this check.

What is actually red: governance.yml is in startup_failure

Zero jobs, no logs, no annotations, on every run since 2026-08-24T21:23. Because the workflow never starts, governance / Validate Hypatia Baseline — the job this issue is about — never runs at all. Its pass/fail state is currently unobservable, not failing.

This also has estate-wide consequence: it is 2 of the 8 required contexts on ruleset Optimus-Branch that never report, which is why every PR to this repo sits at BLOCKED with all reported checks green. The full phantom set (confirmed by three independent methods — check-runs API, commit-status API, and the PR's own statusCheckRollup):

Dependabot                                  Idris2 — a2ml proofs
Gitar                                       K9-SVC contractile validation
governance / Code quality + docs            Scan for hand-authored JavaScript/TypeScript
governance / Validate Hypatia Baseline      Trust pipeline summary

What I ruled OUT for the startup_failure — so nobody repeats it

All measured on standards today. Each of these is a known estate cause and none of them applies:

candidate cause	result
lockfile mode 1 — no actions.lock	❌ present
lockfile mode 2 — workflow has no entry	❌ '.github/workflows/governance.yml': [] exists
lockfile mode 3 — entry under-declares	❌ the reusable's entry lists exactly its 5 actions
lockfile mode 4 — version drift	❌ check-lockfile-drift.sh → clean — 41 workflow(s) checked
YAML unparseable	❌ both caller and reusable yaml.safe_load cleanly
caller lacks actions: read	❌ caller grants actions: read + contents: read
reusable escalates permissions	❌ reusable declares the same two
Actions allowlist rejection	❌ disproved by paired control — see below

The allowlist theory looked strong and is wrong. The repo does have allowed_actions: "selected" with patterns_allowed: [] (only GitHub-owned + verified creators), and governance-reusable.yml does use two non-verified owners. But the discrimination fails in both directions: erlef appears in a dead reusable (governance) and a live one (hypatia-scan); hyperpolymath appears in dead (changelog) and live (codeql); and 6 of the 7 dead workflows use no third-party actions at all.

Structure does not discriminate either — rust-ci.yml (dead) and deno-ci.yml (alive) are the same shape: contents: read, one job, calling a local reusable.

The seven in startup_failure: governance, changelog, readme-derive, rust-ci, pages, casket-pages, and their reusables.

Two moves that can actually close this

1. Read the web-UI banner. Per prior estate experience this failure class states its reason only in the run page banner — invisible to REST and GraphQL. One paste from the owner has beaten hours of API probing before. Run: https://github.com/hyperpolymath/standards/actions/workflows/governance.yml
2. Bisect on fix(governance): enforce live Actions policy #622. The flip at 2026-08-24T21:23 is contemporaneous with PR fix(governance): enforce live Actions policy #622 "fix(governance): enforce live Actions policy". Check whether all six dead callers flipped at that commit; if so, revert it on a branch and open a draft PR — if governance / … reports there, fix(governance): enforce live Actions policy #622 is confirmed as cause.

Net for this issue: revoking the credential alone will not turn this gate green, and the numbers in the thread above should not be used to rule on it.