fix(governance): reconcile hypatia baseline with current scanner ruleset

[hyperpolymath]

Cures the only red check on main: governance / Validate Hypatia Baseline.

Root cause

The reusable governance workflow runs hypatia at main HEAD, unpinned. Since the baseline was written, hypatia gained rule types the 285-entry baseline predates (missing_timeout_minutes, WF017 secret_action_without_presence_gate, codeql_missing_actions_language, expect_in_hot_path, unsafe_block, as_ptr, zig_ptr_cast, SD007, SD022) and dropped Belt/Js.* deprecated_api from high to medium, which breaks exact-severity baseline matching for 36 findings. 85 findings were failing the gate.

What this does

15 findings fixed in code rather than baselined:

• job-level timeout-minutes on server-boot-gate, fly-deploy, s4-loop, push-email-notify
• instant-sync.yml: gate the repository-dispatch step behind a FARM_DISPATCH_TOKEN presence check (WF017)
• codeql.yml: scan the actions language alongside javascript-typescript
• .claude/CLAUDE.md: reword the .scm-deprecation paragraph so it stops tripping SD007 on its own migration examples
• ffi/zig/src/{typell,overlay,boj}.zig: make error_buf sentinel-terminated ([N:0]u8) and drop the @ptrCast — writers always NUL-terminate, so the coercion is sound

70 findings baselined as 44 acknowledged entries (medium deprecated_api pending the ReScript→AffineScript migration, FFI-boundary unsafe_block/as_ptr/expect_in_hot_path debt, and two SD022 false positives that cite external-corpora paths).

Verification

Reproduced the CI job offline against hypatia 3b04900 using the exact governance-reusable.yml invocation (HYPATIA_FORMAT=json, BLOCKING_THRESHOLD=info, the same jq path relativisation, then apply-baseline.sh … blocking):

• before: 151 findings → 85 kept → exit 1
• after: 136 findings → 0 kept → exit 0

Zig changes pass semantic analysis on both the CI-pinned 0.14.0 and 0.16.0. All six modified workflows strict-parse as YAML.

Follow-up (not in this PR)

The scanner floats at hypatia main HEAD, so this gate can re-redden whenever hypatia adds rules — worth proposing a pinned scanner SHA upstream in standards.

[gitar-bot]

Code Review ✅ Approved

Reconciles the Hypatia governance baseline with current scanner rules by fixing 15 findings directly in code and baselining 70 remaining entries. No issues found.

Auto-approved and auto-merge armed: No blocking issues found.
Please see Auto-approve Docs for details on setting custom approval criteria. — merges when pipeline and required approvals pass.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[gitar-bot]

Gitar has auto-approved this PR and enabled auto-merge (configure)

[hyperpolymath]

Do not merge on a green board — every gate in this repo is dead

gh pr checks on this PR shows a single passing check (Gitar). That is not a green board: all 16 workflow runs on this branch are startup_failure, and a workflow that fails at startup registers no check run at all, so it cannot appear as missing.

gh run list --branch fix/governance-hypatia-baseline
pull_request  completed/startup_failure  Governance
pull_request  completed/startup_failure  Rust CI
pull_request  completed/startup_failure  CodeQL Security Analysis
... 16/16

It is repo-wide and predates this branch

main flipped wholesale on 2026-07-27 22:45. The run immediately before (834ee82, the Dependabot actions bump) produced real results — a normal mix of success and failure. Every run since (0823afc onward) is startup_failure, across all 34 workflows.

The commit correlation is misleading: 834ee82..0823afc touches only dogfood-gate.yml plus two new vendored scripts, which cannot break unrelated workflows.

What I ruled out

Hypothesis	Result
Invalid workflow YAML	No — all 33 files strict-parse; a minimal probe workflow (one SHA-pinned actions/checkout + echo) also startup_failured
Dependabot wrote unresolvable SHAs	No — every bumped SHA resolves; actions/checkout@3d3c42e5… is exactly the v7.0.1 tag
Billing / private-repo block	No — repo is public, enabled: true, not archived
Ruleset injecting a broken required workflow	No — no workflows rule in either ruleset
Account-wide outage	No — echidnabot CI is healthy right now; standards is only partly affected

The remaining difference

repo	allowed_actions	sha_pinning_required	state
echidna	selected	true	100% startup_failure
echidnabot	all	false	healthy
standards	selected	true	mixed

The repo-level Actions policy is the only variable left, and the minimal probe proves it is not about any individual action reference (github_owned_allowed is true, so actions/checkout is permitted).

I stopped here deliberately. Confirming it means toggling sha_pinning_required and re-running the probe, and I am not willing to weaken a security control on a public repo without the owner saying so — especially one that looks deliberately set to match estate SHA-pinning doctrine.

Consequence

All four PRs (#328–#331) report MERGEABLE / BLOCKED: the Base ruleset requires status checks that can never arrive while startup fails. Merging any of them today means merging with zero gates actually run.

#328 itself is verified independently — the hypatia gate was reproduced offline against scanner 3b04900 with the exact governance-reusable.yml invocation (136 findings, 0 kept, exit 0) — but that verification is mine, not CI's.

Suggested order once Actions are alive: land #328 first (so the baseline is in place), then #329/#330/#331, re-running the gates on each.