Hypatia dogfooding job red estate-wide — unresolvable setup-beam pins (companion to hypatia-side fix)

[hyperpolymath]

Summary

The Hypatia Neurosymbolic Analysis (Dogfooding) job in hypatia-scan.yml has been failing on every run, independent of PR content — red on already-merged PRs (#58, #60) and every new PR (#62). This erodes CI signal estate-wide (real failures are masked by a permanently-red advisory job).

Why it is not the scan/findings

• The scan step runs hypatia-cli.sh scan . --exit-zero — findings cannot fail the step.
• The only gate ("Check for critical issues") is explicitly "Warn but don't fail — fix forward" and never calls exit 1.
• The job fails in ~12s consistently — too fast to have cloned/built the scanner. The failure is in an earlier step.

Root cause (high confidence)

The Setup Elixir for Hypatia scanner step pinned:

elixir-version: '1.19.4'
otp-version: '28.3'

These versions are not in the setup-beam index, so the step fails fast on every run.

Immediate fix

A standards-side fix is up as a draft PR (branch claude/fix-hypatia-dogfooding-pins): pins corrected to resolvable loose elixir 1.18 / otp 27. Verify those versions actually build the Hypatia scanner and bump deliberately if newer is required.

Permanent fix (so this never silently rots again)

Tracked upstream in hyperpolymath/hypatia (issue text drafted; out of this repo's scope to file from here):

1. Publish and own a supported-toolchain matrix (the OTP/Elixir versions the scanner builds against) as the single source of truth for downstream *-scan.yml workflows.
2. Add a CI smoke job in hypatia that runs setup-beam with that matrix + mix escript.build, so a toolchain-pin regression fails there, loudly — not as N red consumer repos.
3. Decide policy: keep the consumer dogfooding job hard-failing (fine once pins are valid) or mark it continue-on-error: true if it is meant to be advisory, so a tooling outage never masks real CI signal.

Acceptance criteria

• Dogfooding job green on an unrelated no-op PR.
• A bad toolchain pin is caught by a check in hypatia itself, not by red consumer repos.

---

Filed as the in-scope companion to the hypatia-side permanent fix. Inferred from CI timing + workflow logic; confirm via the Setup Elixir step output on any recent failing run.

[hyperpolymath]

Correction — original diagnosis falsified

The setup-beam version-pin theory in this issue (and the fix merged as #63) was a red herring. Verified by controlled tests on throwaway PR #65 (now merged → main):

Hypothesis	Test	Result
setup-beam pins 1.19.4/28.3 unresolvable	repinned to 1.18/27 (#63, on main)	job still fast-fails identically (~12s)
actions/checkout@34e114876b… (SHA unique to this workflow)	repinned to repo-wide de0fac2e… (#65, on main)	job still fast-fails identically (~12s)
any pinned action SHA yanked/invalid	verified erlef/setup-beam@fc68ffb…, actions/upload-artifact@ea165f8d…, actions/checkout@34e114876b… all exist upstream	all valid

Current state: main now has corrected setup-beam pins and the repo-wide checkout SHA, yet Hypatia Neurosymbolic Analysis (Dogfooding) still fails in ~12s, before any step produces output. Root cause is undetermined and cannot be progressed further without the actual run log — specifically the "Set up job" section plus the first failing step of any recent failing run (≈10 lines). Every log-free hypothesis has been tested and falsified; further blind changes would be thrashing.

Recommendation unchanged in spirit: the permanent fix still belongs upstream in hyperpolymath/hypatia (supported-toolchain matrix + a smoke job that builds the scanner), and the consumer dogfooding job should be made advisory (continue-on-error: true) so an undiagnosed tooling failure stops masking real CI signal estate-wide — mirroring what was done for AffineScript Verify. The setup-beam/checkout specifics above should be disregarded as causes.

---

Generated by Claude Code