🟠 Estate CI-health backlog: public repos with independently-red CI

[hyperpolymath]

After the allow-list fix (27 repos) and billing (separate), the remaining stuck PRs are blocked by each repo's own red CI — real build/test/governance failures, not the dependency bump. Rebasing won't help; each needs per-repo repair (home: hypatia ci-health-sweep, #461).

Sampled failures: bofig (Build and test, Hypatia) · project-wharf (Analyze rust/actions, build, workflow linter) · double-track-browser (TypeScript Tests, language-policy) · coq-jr (language-policy, Well-Known, Validate Security Files).

Repos with stuck PRs (per-repo CI repair needed):

• nextgen-databases#34
• bebop-ffi#30
• bofig#103
• bofig#102
• bofig#101
• bofig#100
• bofig#99
• robot-vacuum-cleaner#67
• ochrance#36
• chimichanga#40
• php-aegis#46
• laminar#41
• project-wharf#56
• project-wharf#55
• project-wharf#54
• InvestigativeJournalist.jl#29
• TradeUnionist.jl#28
• manifesto#34
• hybrid-automation-router#53
• casket-ssg#31
• methodologies#29
• academic-workflow-suite#217
• double-track-browser#42
• asdf-tool-plugins#44
• ipv6-tools#25
• nickel-augmentation#27
• social-media-tools#41
• social-media-polygraph#44
• social-media-polygraph#43
• poly-observability-mcp#24
• coq-jr#45
• a2ml_gleam#32
• claude-gecko-browser-extension#49
• sanctify-php#49
• elixir-mcp-server#30
• chimichanga#39
• pow-the-game#52
• bgp-backbone-lab#55
• thunderbird-template-reloaded#86
• checky-monkey#41
• dotmatrix-fileprinter#20
• claude-gecko-browser-extension#48
• k9_gleam#17
• modshells#66
• format-registrations#19
• tree-sitter-a2ml#17
• squisher-corpus#27
• resource-record-fluctuator#39
• snapcreate#31
• social-media-polygraph#41

Note: ~33 of the burn-cut PRs opened this session are also gated on these same repo-CI issues (or billing).

[hyperpolymath]

📋 Status — 2026-06-21: the Hypatia-lane root cause is a central actions/cache SHA corruption (already fixed & merged)

Actioning the CI-health findings surfaced 2026-06-20/21. I have hypatia + standards write access (the reporting session did not, so it could only diagnose). Cross-ref nextgen-typing#69 ("out of scope — central").

(1) ROOT CAUSE — central actions/cache SHA corruption — ✅ FIXED & MERGED

The estate-wide scan / Hypatia Neurosymbolic Analysis failure at "Prepare all required actions":

Unable to resolve action actions/cache@d4373f267a887d77f9eb0683a479ec60b1fe5b2b
(unable to find version d4373f267a887d77f9eb0683a479ec60b1fe5b2b)

…is, as diagnosed, not in any consumer workflow. It was pinned once, centrally, in both Hypatia reusables in standards:

• .github/workflows/hypatia-scan-reusable.yml
• .github/workflows/governance-reusable.yml

d4373f… resolves to nothing upstream — it's a corruption of v4.2.2's real commit d4323d4….

It was already repaired and merged before I reached it: standards#394 (merged 2026-06-21 10:52Z, commit d72fe5a) re-pinned both reusables to the genuine v4.2.0 commit 1bd1e32a…, preserving the # v4.2.0 comment.

Independently verified this session via git ls-remote https://github.com/actions/cache:

SHA	upstream ref	resolves?
d4373f… (the corrupt pin)	(none)	✗ bogus
1bd1e32a… (the repair)	refs/tags/v4.2.0	✓
0057852b… ("most common")	v4 + v4.3.0	✓
27d5ce7f… (used across hypatia)	main + v5 + v5.0.5	✓

git grep d4373f… across standards + hypatia → 0 matches. hypatia's own workflows are clean (they pin actions/cache to the valid 27d5ce7f… # v5.0.5).

⚠️ Propagation caveat — necessary but not yet sufficient

Consumers pin these reusables by standards commit SHA, not @main (hypatia uses @5eb28d7d…; most repos @861b5e91…). The repair landed as a new standards HEAD (d72fe5a), so a consumer still pinned at a pre-#394 SHA keeps dereferencing the broken cache pin until it is re-enrolled to d72fe5a+. A consumer's lane therefore only goes green after re-enrollment (gitbot-fleet enroll-repos) — not automatically.

(2) governance / Check Workflow Staleness red — EXPECTED drift, not a new defect

standards/scripts/check-workflow-staleness.sh fails any consumer whose pinned reusable SHA ≠ current standards HEAD ("Workflow pins Hypatia reusable before cache/baseline-delay fix. Refresh to current standards SHA."). Because #394 advanced HEAD to d72fe5a, every consumer is stale by definition right now — this is precisely the signal that the re-enrollment pass is pending, the same root cause as (1) viewed from the propagation side.

Remediation = gitbot-fleet enroll-repos re-pin of consumers to d72fe5a+. That's out of scope for standards/hypatia (consumer repos and gitbot-fleet aren't in my access), so per the task I'm recording it here as expected post-#394 drift.

(3) nextgen-databases, pre-existing & repo-internal — recorded (out of scope to fix)

Both live in nextgen-databases (not standards/hypatia), so flagging with grounded fixes rather than touching them:

1. K9 pedigree — verisimdb/connectors/test-infra/deploy.k9.ncl → "Pedigree block missing 'name'". Confirmed against the schema: in standards/k9-svc/pedigree.ncl, Metadata.name | String is the only metadata field with no default, so it is mandatory. Fix: add metadata.name; per the canonical k9-svc/pandoc/container/deploy.k9.ncl sample, ideally also metadata.version + validation.pedigree_version and a leash level trust_level/security_level ∈ 'Kennel | 'Yard | 'Hunt (a shell-running deploy.k9.ncl is 'Hunt).
2. governance / Trusted-base reduction policy red — per standards/docs/TRUSTED-BASE-REDUCTION-POLICY.adoc + scripts/check-trusted-base.sh: an undocumented soundness-relevant escape hatch in a proof-bearing file. Disposition is per-repo — discharge, budget (// TRUSTED:), axiom (// AXIOM:), or a dated debt entry in nextgen-databases' docs/proof-debt.md.

Durable record

Full audit with the verification table + propagation analysis: standards/docs/audits/audit-hypatia-cache-sha-corruption-2026-06-21.adoc (+ .a2ml companion), filed as draft standards#396.

---

Net. The Hypatia-lane root cause (1) is fixed & merged (standards#394), independently verified. (2) is expected post-fix staleness drift awaiting a gitbot-fleet enroll-repos re-pin to d72fe5a+ (out of my scope). (3) is two pre-existing nextgen-databases-internal items for that repo's maintainers. Nothing here required (or received) an unverified fix.

---

Generated by Claude Code

[hyperpolymath]

▶️ Remaining action — propagate the fix via gitbot-fleet enroll-repos

The central root cause is fixed + merged (standards#394). The only step left to turn the estate green is to re-pin stale consumers — they pin the reusables by standards commit SHA (not @main), so they keep dereferencing the old workflow and show Check Workflow Staleness red until refreshed.

Target pin: current standards/main HEAD = 4ddc926 (contains actions/cache@1bd1e32a… # v4.2.0; re-resolve to current HEAD at run time).

Operation (same as the 2026-05-27 orphan re-pin sweep — Contents API + auto-merge squash):

1. Run gitbot-fleet enroll-repos to re-pin each stale consumer's .github/workflows:
   • hypatia-scan.yml → hypatia-scan-reusable.yml@4ddc926
   • governance.yml → governance-reusable.yml@4ddc926
2. Prioritise the observed-failing repos: nextgen-databases, KnotTheory.jl, nextgen-typing, plus the repo list above.
3. Verify on 2–3 samples: scan lane green + staleness check green; post the result here.

Not covered by this sweep (separate per-repo fixes in nextgen-databases):

• K9 pedigree — verisimdb/connectors/test-infra/deploy.k9.ncl needs metadata.name (+ version/pedigree_version + trust_level 'Hunt).
• governance / trusted-base red — undocumented escape hatch → entry in that repo's docs/proof-debt.md.

Note: this step cannot be driven from a session scoped only to hypatia/standards (which is where the diagnosis + audit #396 were done). It needs a session/agent scoped to gitbot-fleet (and the consumer repos). Cross-ref nextgen-typing#69.

---

Generated by Claude Code

[hyperpolymath]

⛔ enroll-repos re-pin is blocked — the propagation actuator (.git-private-farm Actions) is down

Picked this up from a session scoped to gitbot-fleet + .git-private-farm. The re-pin is fully scoped and ready, but it cannot run: the farm workflow that performs the Contents-API + auto-merge-squash sweep is failing at the infrastructure level. Reporting before any half-done state is created.

Target pin (confirmed)

standards/main HEAD = 4ddc926 (carries actions/cache@1bd1e32a… # v4.2.0, the #394 repair). stapeln + panoply are already pinned here — proof the target resolves.

Estate consumers enumerated (GitHub code search, both reusables)

SHA-stale = pinned SHA ≠ 4ddc926, excluding @main auto-trackers (already get the fix) and the 2 already at HEAD:

Reusable	refs	@main (skip)	already 4ddc926	SHA-stale to bump
governance-reusable.yml	225	62	2	~143
hypatia-scan-reusable.yml	197	0	2	~195

Old-SHA clusters (one farm run keys on one OLD_SHA, so this is ~17 dispatches):

• governance: 5a93d9d5→102, 861b5e91→30, d72fe5a→4, 5eb28d7d→2, 3b3549e2→2, +3 singletons (echidna, ephapax, valence-shell)
• hypatia-scan: 5a93d9d5→102, 915139d7→54, 97df762→16 (the 2026-05-27 orphan SHA still live), 6cd37728→12, 5eb28d7d→5, d72fe5a→3, +3 singletons (bunsenite, eclexia, vcl-ut)

Priority repos located: nextgen-typing both reusables @5a93d9d5; nextgen-databases governance @main (no re-pin) + hypatia-scan @915139d7; KnotTheory.jl both @5a93d9d5 (⚠️ this one was missed by paginated code-search and only found by targeted lookup — code-search pagination is lossy, so the final sweep needs a per-repo verification pass to catch stragglers).

The blocker — farm GitHub Actions are not allocating runners

I fired one validation dispatch into .git-private-farm sha-bump-propagate.yml (workflow_dispatch, nextgen-typing hypatia-scan 5a93d9d5→4ddc926). It failed in 6 s with no runner assigned (runner_id: 0, run 27914137962) — before any step ran. Inputs passed every validation gate; this is not an input/logic failure.

It is not isolated. Every .git-private-farm Actions run today dies the same way:

• 14+ Propagate (repository_dispatch) runs — all failure in 7–19 s
• scheduled Well-Known Standards, Estate CI-deadlock Audit, RustSec Audit, Forge Drift Detection — failure in 4–5 s
• OSSF Scorecard — startup_failure in 0 s

GitHub-hosted (ubuntu-latest) jobs failing in <20 s with no runner / startup_failure across unrelated workflows = Actions are administratively or financially blocked on the private farm repo (spending-limit / billing exhaustion, or Actions disabled). This is the "billing (separate)" blocker already noted on this issue — and it sits upstream of the re-pin: the estate's own propagation automation has been failing against it all day.

Net

• 0 consumers re-pinned, 0 verified. The single sample failed on infra, not on the change.
• The farm is the only estate-wide write path (consumers are out of this session's repo scope), so the sweep is blocked until farm Actions billing/runners are restored.
• Once restored, the sweep is ~17 workflow_dispatch calls into sha-bump-propagate.yml (one per reusable × old-SHA, all new_sha=4ddc926) + a re-search pass for stragglers + sample verification. I can re-fire immediately on the word that Actions are live again.

Out-of-scope items unchanged (K9 pedigree on nextgen-databases, trusted-base proof-debt) — not part of this sweep.

---

Posted by Claude Code (gitbot-fleet session). No changes were pushed; this is a blocker report.

---

Generated by Claude Code