fix(ci): hypatia-scan.yml -- --exit-zero + GITHUB_TOKEN (hyperpolymath/hypatia#213)#32
Merged
Merged
Conversation
1 task
hyperpolymath
added a commit
that referenced
this pull request
May 14, 2026
Follow-up commit on PR #32. The Hypatia Neurosymbolic Analysis check has been failing because `erlef/setup-beam@2f0cc07b…` doesn't know how to map `ImageOS=ubuntu24` (only knows ubuntu18/20/22). Without the bootstrap, the `--exit-zero` change in this PR never gets exercised. Bumping the pin to `fc68ffb90438ef2936bbb3251622353b3dcb2f93` (matches the pin currently in hyperpolymath/hypatia upstream, dated 2026-03-30, adds ubuntu24 → ubuntu-24.04 mapping). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
hyperpolymath
added a commit
that referenced
this pull request
May 14, 2026
…repo#39) (#33) Mirrors hyperpolymath/rsr-template-repo#39. Same duplicate-heredoc bug — the orphan `BUILTIN_GLOBS = [` etc. on lines 274-428 escapes the heredoc and bash exits 127 after the (passing) first script. This is the immediate cause of the `antipattern-check` failure on stapeln main and on every open PR (including #32). ## Test plan - [ ] `RSR Anti-Pattern Check` workflow goes green on this branch and on main after merge. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
hyperpolymath
added a commit
that referenced
this pull request
May 14, 2026
The 6 A2ML manifests under verified-container-spec/.machine_readable/6a2/ and the 6 K9 templates/examples under .machine_readable/svc/k9/ were firing identity-field validation errors on every CI run, blocking #32 (and any other PR) from going green. Two parallel fixes: * A2ML: added `name = "verified-container-spec/<file>"` inside the [metadata] section of META, NEUROSYM, PLAYBOOK, AGENTIC (the 4 that lacked any top-level identity). STATE and ECOSYSTEM already had `project` / `name` respectively; left untouched. * K9 templates/examples: hoisted a `name = "k9-template/<level>"` or `name = "k9-example/<name>"` field to the top of each pedigree block, immediately after `schema_version`. Works around a brace-counting edge in hyperpolymath/k9-validate-action's pedigree-block detector: when `pedigree = {` opens, the validator doesn't count the opening brace from that line, so a subsequent `security = { ... },` closing brace prematurely terminates the validator's view of the pedigree block — making `metadata.name` invisible. The hoisted top-level `pedigree.name` is captured at depth 1 before any nested block, so it's seen regardless of the bug. The underlying bug is being addressed upstream in k9-validate-action#7. Both classes of error will also be self-suppressing once stapeln bumps its action pins to consume the new `paths-ignore` input being added in hyperpolymath/a2ml-validate-action#7 + hyperpolymath/k9-validate-action#7 (vendored / training-corpus paths default-skipped). The fixes here are belt-and-suspenders — independent of those upstream merges, so stapeln #32 can go green today rather than waiting on the dependency chain. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
hyperpolymath
added a commit
to hyperpolymath/k9-validate-action
that referenced
this pull request
May 14, 2026
… terminates view
When the validator detected the pedigree block start, it `continue`d
before counting that line's `{`. So depth started at 0 instead of 1,
and the next nested block's closing brace took depth back to 0 —
prematurely setting `in_pedigree=false`. Any field (name, version,
leash, signature) defined AFTER an inner block close was therefore
invisible to the validator, even when present in the file.
Repro: any K9 file where `metadata = { name = "…", …, }` is the LAST
top-level field in pedigree (the canonical RSR template shape). All 6
templates / examples in hyperpolymath/stapeln#32 hit this — the
`security = { … },` block prematurely closed pedigree before `metadata`
was reached.
Fix: drop the `continue` so the `pedigree = {` line falls through to
the brace counter. Depth now starts at 1 and tracks correctly.
Verified by mental-trace on `pedigree = { security = {…}, metadata =
{ name = … } }`:
pedigree-line: depth = 1, in_pedigree=true
security {: depth = 2
security }: depth = 1, line has `}` but depth > 0 → stay in pedigree
metadata {: depth = 2
name = …: captured at depth 2 inside pedigree → has_pedigree_name
metadata }: depth = 1
pedigree }: depth = 0 + `}` → in_pedigree=false
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…rpolymath/hypatia#213) The Hypatia Security Scan workflow exits 1 on any findings (>= medium) because lib/hypatia/cli.ex halts with System.halt(1). Under `set -e`, that short-circuits the step before jq/artifact-upload/PR-comment run. Mirrors hyperpolymath/hypatia#228: * pass GITHUB_TOKEN so the Dependabot rule stops warning * append --exit-zero so the downstream critical/high gate stays the explicit gate * bump actions/upload-artifact to v4.6.2 (ea165f8d) to match the estate-wide pin See hyperpolymath/hypatia#213 for the diagnosis. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Follow-up commit on PR #32. The Hypatia Neurosymbolic Analysis check has been failing because `erlef/setup-beam@2f0cc07b…` doesn't know how to map `ImageOS=ubuntu24` (only knows ubuntu18/20/22). Without the bootstrap, the `--exit-zero` change in this PR never gets exercised. Bumping the pin to `fc68ffb90438ef2936bbb3251622353b3dcb2f93` (matches the pin currently in hyperpolymath/hypatia upstream, dated 2026-03-30, adds ubuntu24 → ubuntu-24.04 mapping). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
The 6 A2ML manifests under verified-container-spec/.machine_readable/6a2/ and the 6 K9 templates/examples under .machine_readable/svc/k9/ were firing identity-field validation errors on every CI run, blocking #32 (and any other PR) from going green. Two parallel fixes: * A2ML: added `name = "verified-container-spec/<file>"` inside the [metadata] section of META, NEUROSYM, PLAYBOOK, AGENTIC (the 4 that lacked any top-level identity). STATE and ECOSYSTEM already had `project` / `name` respectively; left untouched. * K9 templates/examples: hoisted a `name = "k9-template/<level>"` or `name = "k9-example/<name>"` field to the top of each pedigree block, immediately after `schema_version`. Works around a brace-counting edge in hyperpolymath/k9-validate-action's pedigree-block detector: when `pedigree = {` opens, the validator doesn't count the opening brace from that line, so a subsequent `security = { ... },` closing brace prematurely terminates the validator's view of the pedigree block — making `metadata.name` invisible. The hoisted top-level `pedigree.name` is captured at depth 1 before any nested block, so it's seen regardless of the bug. The underlying bug is being addressed upstream in k9-validate-action#7. Both classes of error will also be self-suppressing once stapeln bumps its action pins to consume the new `paths-ignore` input being added in hyperpolymath/a2ml-validate-action#7 + hyperpolymath/k9-validate-action#7 (vendored / training-corpus paths default-skipped). The fixes here are belt-and-suspenders — independent of those upstream merges, so stapeln #32 can go green today rather than waiting on the dependency chain. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
hyperpolymath
force-pushed
the
fix/hypatia-213-scanner-flag
branch
from
7dc6223 to
5c79319
Compare
|
hyperpolymath
added a commit
to hyperpolymath/k9-validate-action
that referenced
this pull request
May 14, 2026
* feat: add paths-ignore input; default-skip vendored/fixture content Adopts the provenance-aware suppression pattern established by hyperpolymath/hypatia#243 and matched in hyperpolymath/a2ml-validate-action#7 for the K9 validator. Content-pattern validators must distinguish a target file from a vendored / fixture / training-corpus file that legitimately contains the very pattern being checked. This action was firing "Pedigree block missing 'name' field" on every K9 file in vendored project trees (e.g. verified-container-spec/ consumed by stapeln). The vendored files have their own pedigree declarations in their upstream context. New input `paths-ignore` (newline-separated, substring match), default-on with the canonical RSR vendored / fixture path set. Pass '' to disable. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix: count `pedigree = {` opening brace; nested-block close no longer terminates view When the validator detected the pedigree block start, it `continue`d before counting that line's `{`. So depth started at 0 instead of 1, and the next nested block's closing brace took depth back to 0 — prematurely setting `in_pedigree=false`. Any field (name, version, leash, signature) defined AFTER an inner block close was therefore invisible to the validator, even when present in the file. Repro: any K9 file where `metadata = { name = "…", …, }` is the LAST top-level field in pedigree (the canonical RSR template shape). All 6 templates / examples in hyperpolymath/stapeln#32 hit this — the `security = { … },` block prematurely closed pedigree before `metadata` was reached. Fix: drop the `continue` so the `pedigree = {` line falls through to the brace counter. Depth now starts at 1 and tracks correctly. Verified by mental-trace on `pedigree = { security = {…}, metadata = { name = … } }`: pedigree-line: depth = 1, in_pedigree=true security {: depth = 2 security }: depth = 1, line has `}` but depth > 0 → stay in pedigree metadata {: depth = 2 name = …: captured at depth 2 inside pedigree → has_pedigree_name metadata }: depth = 1 pedigree }: depth = 0 + `}` → in_pedigree=false Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Mirrors hyperpolymath/hypatia#228 in this consumer repo.
What was actually broken in
Hypatia Security ScanThe scanner halts with
System.halt(1)whenever findings exist at or above the severity threshold (lib/hypatia/cli.ex:158-160pre-#228). Under GitHub Actions' defaultset -e, that exit-1 short-circuits the workflow step beforejqaggregation,actions/upload-artifact, the PR comment, AND the explicit "Check for critical or high-severity issues" step.The previous
actions/upload-artifactSHA-bump sweep across the estate (41 PRs) was based on a wrong diagnosis -- the failing runs were not at action-resolve time. See hyperpolymath/hypatia#213 for the full root-cause writeup.Changes in this PR
GITHUB_TOKENto the scan step env so the Dependabot rule can query alerts (and stops emittingWarning: Dependabot alerts unavailable: GITHUB_TOKEN not set).--exit-zeroto thehypatia-cli.sh scan .invocation so findings-at-severity no longer short-circuits the step. The downstream "Check for critical or high-severity issues" step (already in this workflow) remains the explicit gate.actions/upload-artifactto v4.6.2 (ea165f8d65b6e75b540449e92b4886f43607fa02) to match the estate-wide pin.Notes
--exit-zerowas added in fix(cli): add --exit-zero flag + always-emit stderr summary (closes #213) hypatia#228 and is silently ignored by pre-#228 versions of the scanner (OptionParser strict mode places unknown flags ininvalidand the CLI discards that), so this PR is safe to merge in either order relative to #228.exit 1on findings is unchanged for shell / pre-commit users.🤖 Generated with Claude Code