[hyperpolymath]

Five checks here carry the 🔴 Gate: prefix and have never failed in 71–102 runs each (from the API's own lifetime failure count, not a sample). Reading them splits the five two ways — which is the useful result, because "never failed" on its own does not distinguish a broken gate from clean code.

Three were fake

Same template as haec — the files differ only in action-pin style (haec uses actions.lock, this repo inline SHAs), so the gate logic is byte-identical and the same fixes apply. Companion PR: hyperpolymath/haec#52.

Gate	What it actually did
🔴 Gate: Guix-only package policy	No exit 1 anywhere. A foreign lock file printed ⚠️ and passed.
🔴 Gate: Security policy present	Failed on secrets only. Weak crypto (MD5/SHA1) and plaintext HTTP printed ⚠️ and passed.
🔴 Gate: Code quality (fmt/lint/test)	continue-on-error: true on the EditorConfig step.

One was mislabelled rather than broken

🔴 Gate: Static analysis cannot fail three separate ways — it skips when its tools are absent, pipes findings through || true, and carries continue-on-error.

Two honest resolutions existed: make it able to fail, or stop calling it a gate. The second is correct here. panic-attack has a known false-positive problem (panic-attack#171), much of it firing on tests and benches rather than shipping code. Making that blocking would teach people to route around the gate, which is worse than the fake gate it replaces. Retiered to 🟡 CHECK: Static analysis.

Its header claimed "Required by branch protection rules." It is in no ruleset — verified against the API before renaming, because renaming a genuinely-required context strands it as a phantom that silently blocks every PR. (This repo's actual required contexts are governance, Hypatia, SonarCloud and analyze (actions, none).) The false comment is corrected.

The skips are no longer silent

::notice:: does not surface on the checks board, so an absent scanner looked identical to a clean scan. They are now ::warning::, and the step summary reads DID NOT RUN rather than "Skipped" — absence of evidence, not evidence of absence. The skip paths themselves stay, which is defensible now the check is advisory.

One was already honest

🔴 Gate: Trope conformance accumulates fail=1 across every consistency assertion and exits with it. Never failing here was clean code, not a broken gate. It needed proof, not repair — see below.

The proof, not the claim — standards R10

A gate that has never failed is indistinguishable from a gate that cannot fail. scripts/test-gate-falsifiability.sh settles it: each canary plants deliberately-wrong input and asserts the gate rejects it — the pass condition inverted.

PASS weak crypto (md5) is detected
PASS plaintext HTTP is detected
PASS hardcoded secret is detected
PASS foreign lock file is detected
PASS trope conformance rejects a missing vocabulary entry
PASS trope conformance accepts the unmodified tree (fixture copy is complete)

gate falsifiability canaries: 6/6

Two details worth the reading time:

Canary 5 runs the real gate. tests/check-vocabulary.sh derives its root from its own location, so the canary copies the tree to a temp directory, deletes vocabulary/p-fusing.adoc, and runs the actual script. A canary that re-encodes a gate's logic proves only that it agrees with itself.

Canary 6 is load-bearing, not decoration. Running the same real gate on a pristine copy guards the opposite error — a suite that always fires proves nothing — and it also proves the fixture copy is complete. If tree_copy omitted a file the gate reads, canary 5 would pass for the wrong reason and nothing else would notice.

The suite runs inside the quality gate, so falsifiability is re-checked on every PR rather than proved once and left to drift.

Expect red

These gates have been passing because they could not fail. Some of what they now catch will be real and long-standing — plaintext HTTP URLs and MD5 usages that predate this change. That is success, not regression, but worth expecting: the instinct when a 100-run-green gate turns red is to assume the change broke it.

One left for your decision

quality.yml still has continue-on-error: true on trufflehog, which is duplicated by this repo's dedicated secret-scanner.yml. Making a secret scanner blocking has real false-positive consequences, and deleting a security scan is equally consequential, so I changed neither. Same open question as haec#52.

Found during the 2026-08-05 estate CI/CD census. Companion standards PRs: #576 (CI signal discipline) and #577 (R10 canonical wrongness).

🤖 Generated with Claude Code

---

Correction to the evidence above, and a second fix

Opening this PR revealed the repo was repo-wide dead: all 20 workflows returned startup_failure in 0s, so the only check that ran was SonarCloud. Workflow-lockfile enforcement is active on this account and this repo had no .github/workflows/actions.lock; haec and trope-checker have one, and their workflows run. Added via gh actions-lock (which also normalised the inline SHA pins to tag refs recorded in the lockfile — my gate edits survive that rewrite unchanged).

This has a consequence for the finding that opened this PR, and it cuts against me. startup_failure is not counted by the API's ?status=failure query. So a repo whose CI never starts looks identical to a repo whose gates always pass — and the scan that flagged these gates used exactly that query.

Checking each gate's actual run history:

Workflow	success	startup_failure	verdict
quality.yml	14	86	"102 runs, 0 failures" substantially overstated — it mostly wasn't running, going back to June
security-policy.yml	95	2	ran, and never failed
guix-nix-policy.yml	95	2	ran, and never failed
static-analysis-gate.yml	98	2	ran, and never failed

So three of the four gates are exactly as described: they genuinely executed ~95–98 times and never once failed, because they could not. The Code quality claim is the one to discount — it was both fake (the continue-on-error) and largely not running. Both are fixed here, but the run-count evidence for it was weaker than I stated.

The quality.yml startup failures predate today's repo-wide death (they run back to June while the others show only 2), so that workflow has a separate, older problem which actions.lock may not resolve. Flagged rather than assumed fixed — worth re-checking once this PR's CI reports.

Estate-wide implication: the fake-gate census needs re-running with startup_failure counted, not just failure. Recorded in dev-notes/cicd-fake-gate-classification-2026-08-05.md.

[gitar-bot]

💡 Quality: Canaries 1-4 re-implement gate regexes instead of running the gate

Canaries c1–c4 hand-copy the security/guix grep patterns into the test rather than invoking the real workflow logic, so they only prove the copy agrees with itself — the exact anti-pattern the script's own header warns against and which c5/c6 avoid by running check-vocabulary.sh for real. If the workflow regex is later edited (e.g. the security HTTP check http://[^l][^o][^c] which already only matches URLs with a specific 3-char prefix and misses http://a.com), the canary keeps passing against its stale copy and gives false confidence. Consider factoring the gate greps into a shared script the canaries call, or at minimum add a comment flagging the drift risk.

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

[gitar-bot]

⚠️ This PR is blocked due to unresolved code review findings.

_{Configure merge blocking · Maintainers can dismiss this review.}

[gitar-bot]

Note

Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime.
Learn more

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Fixes broken red gates and retiers static analysis to advisory while adding a falsifiability test suite. Consider having canaries 1-4 invoke the real workflow scripts rather than re-implementing their regexes to avoid drift.

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.

💡 Quality: Canaries 1-4 re-implement gate regexes instead of running the gate

📄 scripts/test-gate-falsifiability.sh:25-39

Canaries c1–c4 hand-copy the security/guix grep patterns into the test rather than invoking the real workflow logic, so they only prove the copy agrees with itself — the exact anti-pattern the script's own header warns against and which c5/c6 avoid by running check-vocabulary.sh for real. If the workflow regex is later edited (e.g. the security HTTP check http://[^l][^o][^c] which already only matches URLs with a specific 3-char prefix and misses http://a.com), the canary keeps passing against its stale copy and gives false confidence. Consider factoring the gate greps into a shared script the canaries call, or at minimum add a comment flagging the drift risk.

🤖 Prompt for agents

Code Review: Fixes broken red gates and retiers static analysis to advisory while adding a falsifiability test suite. Consider having canaries 1-4 invoke the real workflow scripts rather than re-implementing their regexes to avoid drift.

1. 💡 Quality: Canaries 1-4 re-implement gate regexes instead of running the gate
   Files: scripts/test-gate-falsifiability.sh:25-39

   Canaries c1–c4 hand-copy the security/guix grep patterns into the test rather than invoking the real workflow logic, so they only prove the copy agrees with itself — the exact anti-pattern the script's own header warns against and which c5/c6 avoid by running check-vocabulary.sh for real. If the workflow regex is later edited (e.g. the security HTTP check `http://[^l][^o][^c]` which already only matches URLs with a specific 3-char prefix and misses `http://a.com`), the canary keeps passing against its stale copy and gives false confidence. Consider factoring the gate greps into a shared script the canaries call, or at minimum add a comment flagging the drift risk.

Options

Display: compact → Showing less information.

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

Compact

gitar display:verbose

---

Important

Your trial ends in 5 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.

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

[gitar-bot]

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

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[hyperpolymath]

CI status — all four gates green, three reds are pre-existing

Every workflow now runs (this repo was at 20/20 startup_failure when the PR opened) and the four gates this PR touches pass:

success  🔴 Gate: Code quality (fmt/lint/test)     ← incl. the R10 canary suite
success  🔴 Gate: Guix-only package policy
success  🔴 Gate: Security policy present
success  🟡 CHECK: Static analysis                  ← retiered
success  🔴 Gate: Trope conformance
success  🟡 Check: Governance metadata              ← was startup_failure
success  🟡 Check: Hypatia baseline security scan   ← was startup_failure
success  🟡 Check: Rust CI / Secret scan            ← were startup_failure
success  🟡 Check: Workflow security lint

Three checks remain red, all failing on main before this branch existed:

Check	on main (last 20)
🟡 Check: Estate rules	7 failure / 13 success
boj-build.yml	20 failure / 0 success
rsr-antipattern.yml	20 failure / 0 success

Not addressed here — out of scope for a gate-falsifiability PR, and each deserves its own diagnosis rather than being swept into this one. The two 20/20 failures in particular look like they have never worked.

Three things went wrong along the way, all mine, all now fixed

Recording them because each is a reusable trap rather than a one-off:

1. gh actions-lock displaces the SPDX header. It inserts its banner as line 1, and the workflow linter requires SPDX there — so the tool that cures startup_failure reddened all 25 workflow files in the same commit. Hoist SPDX back above the banner afterwards.
2. gh actions-lock skips reusable-workflow callers, so their uses: never reaches the lockfile and they stay startup_failure while everything else goes green. Hand-author an empty [] entry per caller. Two callers still failed after that, from permission escalation — a reusable requesting more than its caller grants is rejected before any job starts, which is why it presents as startup_failure with no log at all.
3. My canary planted a literal fake API key, and the repo's real secret scanner correctly reported it. A canonical-wrongness fixture is wrong on purpose, so every other scanner reads it as a genuine defect. The strings are now built at runtime.

The last one is now written into standards R10 as R10.7, along with R10.6 (assert valid input is accepted) and R10.8 (exercise the real check, not a copy of it) — metadatastician/standards#577.

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE