V-L3-F1: prune CI noise — identify load-bearing vs governance workflows

[hyperpolymath]

Context

~20 workflows in this repo; most are governance scaffolding. The actually load-bearing ones for the Rust crate are: rust-ci, codeql, dependabot, release. Governance workflows shouldn't block the development flow.

What to do

• Identify the load-bearing set vs governance set.
• Move governance workflows into a reusable workflow library (probably in hyperpolymath/standards) and call them as a single wrapper from here.
• Confirm with gh pr checks that the count of required checks drops to a manageable handful.

Acceptance

• Required-check count documented
• Optional-check noise visible but not blocking

[hyperpolymath]

Workflow audit — results

23 workflows classified:

• Load-bearing (kept standalone): rust-ci, codeql, dependabot-automerge, release
• Repo-specific gates (kept): dogfood-gate, static-analysis-gate
• Security/plumbing — side-effecting or already no PR noise (kept): secret-scanner, hypatia-scan, scorecard, scorecard-enforcer, mirror, instant-sync, boj-build, casket-pages, rhodibot
• Portable governance → moved to shared reusable bundle: quality, guix-nix-policy, npm-bun-blocker, ts-blocker, security-policy, rsr-antipattern, wellknown-enforcement, workflow-linter

Key finding

main has no branch protection → 0 required status checks. Nothing currently blocks PRs; the "drop required-check count" goal was already satisfied at zero. The actual problem was per-PR visual / CI-minute noise from ~8 duplicated governance workflows.

Done

• Created reusable workflow_call bundle (the issue's prerequisite — standards had no reusable library before): feat(ci): reusable governance workflow bundle (verisimiser#59) standards#81 (6 consolidated jobs; rsr-antipattern is a superset of the npm-bun/ts blockers so they were de-duplicated, not just relocated).
• Replaced the 8 local copies with one wrapper caller: chore(ci): prune CI noise — single governance wrapper (#59) #107. Net 23 → 15 workflows.

Acceptance

• Required-check count documented: 0 (no branch protection)
• Optional-check noise visible but not blocking: governance now one non-blocking wrapper

Follow-up (separate items, not done here)

• Estate-wide rollout of the wrapper to other repos.
• Optional: enable branch protection requiring just rust-ci + codeql so the "required handful" is enforced rather than merely absent.

[hyperpolymath]

Estate rollout + branch-protection decision

Wrapper rollout (pilot-first, as scoped)

repo	PR	governance copies removed
verisimiser	#107	8
rsr-template-repo	hyperpolymath/rsr-template-repo#52	8 (future repos inherit the wrapper)
modshells	hyperpolymath/modshells#45	8
affinescript	hyperpolymath/affinescript#147	8

Reusable bundle: hyperpolymath/standards#81. Idempotent rollout script retained for the follow-up batch.

Target sets for the follow-up fan-out:

• Wrapper rollout ≈ 44 repos carrying rsr-antipattern.yml, minus aggregates (developer-ecosystem, repos-monorepo, hyperpolymath-archive) and standards.
• Fan-out gated on: standards#81 merged + ≥1 pilot caller observed green (proves the reusable workflow before propagating estate-wide).

Branch protection — decision: defined but deliberately deferred

Scope chosen: Rust repos only (91 repos carry rust-ci.yml).

Investigating the actual check contexts surfaced two footguns + a blocker:

• rust-ci does not run on workflow-only PRs (verified on fix(ci): CodeQL language-aware detection (pilot for estate sweep) #105 and chore(ci): prune CI noise — single governance wrapper (#59) #107 — no cargo check (stable) check produced). Requiring it would permanently block every CI-maintenance PR, including the four rollout PRs above.
• cargo test (…) context is MSRV-version-dynamic; codeql analyze (…) is language-dynamic — requiring either bricks PRs on routine MSRV/language changes.
• Only stable contexts: cargo check (stable) (rust-ci) + detect (codeql).

Decision: enable, but only after standards#81 and the wrapper PRs merge, using exactly:

gh api -X PUT repos/hyperpolymath/<repo>/branches/main/protection \
  -F required_status_checks.strict=false \
  -F 'required_status_checks.contexts[]=cargo check (stable)' \
  -F 'required_status_checks.contexts[]=detect' \
  -F enforce_admins=false -F required_pull_request_reviews= -F restrictions=

Enabling it now would self-brick the rollout — so it is sequenced, not skipped.

Separate finding (out of #59 scope): rust-ci.yml has no paths filter yet does not trigger on workflow-only PRs — worth its own issue; it's the root cause of the brick risk above.

[hyperpolymath]

Estate-wide rollout complete

Following the dogfood-drift remediation, the governance-wrapper rollout (this issue's follow-up) and a prerequisite root-cause fix are now done.

1. Governance wrapper rollout

Per-repo governance scaffolding was a drift engine (standards-centralised policy). Replaced estate-wide with one governance.yml calling hyperpolymath/standards/.github/workflows/governance-reusable.yml@main:

• 301 repos — one atomic per-repo commit (Git Data API) deleting all local governance copies + adding the wrapper per workflow-dir. Authoritative git-tree enumeration of all 352 account repos (not lossy code-search).
• ~4,573 governance files removed, ~892 wrappers added (monorepos get a wrapper per workflow-dir).
• ephapax — required signed commits + PR (ruleset), so landed as chore(ci): replace per-repo governance copies with shared bundle wrapper (#59) ephapax#81 (8 web-flow-signed commits) instead of direct push.
• Held back (policy): 14 ReScript/v-lang repos + subpaths — asdf-tool-plugins,developer-ecosystem idaptik-rescript13-staging,poly-observability-mcp rescript-dom-mounter,rescript-ecosystem rescript-evangeliser,rescript-string-power rescript-tea,rescript-vite v-graphql,v-grpc v-rest,zotero-tools — and rescript/v subpaths in developer-ecosystem/asdf-tool-plugins/hyperpolymath-archive. These need separate handling (the earlier hands-off override was scoped only to the trivial dogfood one-liner; this is a structural change).
• 20 forks/archived skipped; 16 repos had no governance workflows.

2. rust-ci root cause (branch-protection prerequisite)

The "optional branch protection requiring rust-ci + codeql" follow-up was blocked: rust-ci was failing instantly because rust-ci.yml had a duplicated top-level concurrency: key (invalid workflow → no run, no logs). Fixed in commit 04bd688. At fix time the entire verisimiser Actions queue was externally stalled (all workflows queued, runner backlog), so the fix could not be verified and branch protection was deliberately not applied (requiring an un-runnable check would brick all PRs).

3. Branch protection — deferred & scheduled

A one-time scheduled routine (trig_01EGtNQNseGGjxDBS4DUXmEY, fires 2026-05-18 02:40 UTC) will: verify rust-ci is green, then enable branch protection on main requiring cargo check (stable) + detect + analyze (rust) (enforce_admins). If rust-ci still can't run, it re-reports for re-scheduling; if rust-ci fails for code reasons, it protects with codeql-only and flags rust-ci.

Outstanding

• 14 hands-off rescript/v repos + subpaths — governance wrapper not yet applied (separate, policy-gated).
• ephapax#81 — open PR, awaiting its checks/merge.
• Branch protection — automated for 2026-05-18.

[hyperpolymath]

@hyperpolymath — scheduled branch-protection check ran:

CASE C — Actions queue still stalled. No branch protection applied.

Check date / time: 2026-05-18 ~02:42 UTC

Latest main commit: 642e1e1 ("fix(ci): bump a2ml/k9-validate-action pins to canonical")

Findings: All 11 active check runs on the HEAD of PR #114 (the latest merge to main) remain in status: queued with no completed_at. They were enqueued on 2026-05-17T07:13:51Z — over 24 hours ago — and no runner has picked them up. This includes:

Check	Status
cargo check (stable) (rust-ci)	queued
detect	queued
governance / * (5 jobs)	queued
Hypatia neurosymbolic scan	queued
Hypatia Neurosymbolic Analysis	queued
panic-attack assail	queued

Only automerge completed (conclusion: skipped), which runs without a runner.

Action taken: Branch protection on main was not enabled. Requiring a status check that can never complete would brick every PR. The prerequisite from the original decision (rust-ci must be verifiably green before branch protection is applied) is not yet met.

Root cause: External GitHub Actions runner backlog — not a workflow-YAML or code defect. The rust-ci fix (commit 04bd688, duplicate concurrency: block removed) is already on main and is structurally correct; it simply hasn't had a chance to run.

Required follow-up: This reminder needs to be re-armed for ~24 hours from now (target: 2026-05-19 ~02:00 UTC). When the queue clears and cargo check (stable) completes successfully, re-run the branch-protection check to apply CASE A protection (required checks: cargo check (stable), detect, analyze (rust); enforce_admins: true).

---

Generated by Claude Code