Triage: 4 residual red checks on main (@d309505b) — allowlist gap, 27 SPDX headers, SonarCloud new-code security rating

[hyperpolymath]

Measured on main @ d309505b on 2026-09-22. Filed under the standing stopping rule:
a scanner finding does not block a merge — it becomes an issue with acceptance criteria.

One issue, four items, acceptance criteria per item. Fixes go in separate PRs.

---

1. actions.lock is in sync with the workflow YAML — ✅ cure already open as #104

Status: resolved pending merge of #104. Recorded here for completeness because it was red
when this triage was taken.

The gate went red on main within five minutes of #101 merging. Concurrent commit b506eeda
(12:29:23Z) added .github/workflows/standards-pipeline.yml, which pins
hyperpolymath/standards/.github/workflows/ci-pipeline.yml@2eb9bb19…, and wrote that workflow's
lock entry as []. #101 merged at 12:34:39Z, so the gate it shipped caught the very next
desync — which is the behaviour it was built for.

Because standards-pipeline.yml triggers on pull_request + workflow_dispatch only, nothing
had been startup-killed yet. The next PR would have been the first.

#104 adds the dependency record with its 4 nested refs, closes 3 dangling edges
(haskell-actions/setup@6037f336, hyperpolymath/standards@571cc734, oven-sh/setup-bun@0c5077e5),
prunes 1 orphan, and ships the case-folding gate script.

Acceptance criteria

• fix(ci): lock the standards-pipeline reusable ref and close the lock #104 merges
• actions.lock is in sync with the workflow YAML is green on main
• gh actions-lock --verify-local exits 0 on a fresh clone of main

---

2. governance / Allowlist Preflight — one action not covered by the estate allowlist

Job log, verbatim:

GAP  step-security/harden-runner@v2.16.0   (add its owner/* or owner/repo@* pattern, or run set-allowed-actions.sh)
checked 21 `uses:` refs across .github/workflows — 1 not covered by the allowlist
##[error]Process completed with exit code 1.

step-security/harden-runner was introduced by concurrent commit dca455e. The allowlist it is
checked against is not in this repo — it lives in hyperpolymath/standards at
rhodium-standard-repositories/actions-allowlist/allowed-actions.json.

So this is one of two decisions, and it is an estate decision, not a repo one:

• (a) step-security/harden-runner is wanted estate-wide → add step-security/harden-runner@*
  to the standards allowlist. Every other estate repo then inherits the permission.
• (b) it is not → remove the uses: from this repo's workflow.

Acceptance criteria

• a decision recorded between (a) and (b), with the reason
• if (a): the pattern is present in allowed-actions.json on standards main
• governance / Allowlist Preflight is green on main
• the preflight reports 0 gaps, not merely a non-zero exit avoided

---

3. lint-workflows / Check SPDX Headers — 27 of 29 workflows have no SPDX header on line 1

Re-measured against the default branch via the contents API, not a working copy. The CI log
enumerates fewer files than this because its output is truncated; the true count is 27.

The 27:

codeql.yml              container-build.yml       dependabot-automerge.yml  dogfood-gate.yml
e2e.yml                 estate-rules.yml          governance.yml            guix-policy.yml
hypatia-scan.yml        instant-sync.yml          labels.yml                label-triage.yml
mirror.yml              openssf-compliance.yml    pages.yml                 push-email-notify.yml
quality.yml             release.yml               rhodibot.yml              runtime-policy.yml
rust-ci.yml             scorecard.yml             secret-scanner.yml        security-policy.yml
static-analysis-gate.yml wellknown-enforcement.yml workflow-linter.yml

Only lock-sync-gate.yml and standards-pipeline.yml comply.

⚠ Trap to avoid when fixing this. gh actions-lock prepends its own stamp above line 1
(# This workflow is managed by gh actions-lock.). Any fix that adds SPDX and then lets the lock
tool run will have the SPDX displaced off line 1 and this check will stay red. Add the header
after any lock regeneration, and assert head -1 afterwards.

Acceptance criteria

• all 27 files carry # SPDX-License-Identifier: MPL-2.0 as line 1 — byte 1, not line 2
• lint-workflows / Check SPDX Headers is green on main
• a re-run of gh actions-lock does not displace any of them (assert head -1 after the tool)

---

4. SonarCloud Code Analysis — Quality Gate failed on new code

From the check-run output on main:

Quality Gate failed
Failed conditions:
  C Security Rating on New Code   (required ≥ A)

Dashboard: https://sonarcloud.io/dashboard?id=hyperpolymath_cicd-squabbler&branch=main

⚠ Method note for whoever picks this up. A SonarCloud measure requested without
&pullRequest=N is the default branch, not a PR — the same metric has returned different
numbers unscoped vs scoped. This measurement is deliberately the default branch. Scope any
per-PR follow-up explicitly.

A "C on New Code" means at least one issue at severity ≥ major was introduced inside the new-code
period; it does not by itself say the repo is insecure overall. Enumerate the actual issues before
deciding — they may all be one class, and some may be false positives worth marking as such in
SonarCloud rather than changing code.

Acceptance criteria

• the failing issues enumerated by rule key and file, with a per-issue verdict (real / FP)
• real issues fixed; FPs resolved in SonarCloud with a reason, not silenced in code
• Security Rating on New Code is A
• SonarCloud Code Analysis green on main

---

Not in scope here

These were red before this triage and are already green again, fixed by #101:
governance / Actions lockfile verify, governance / Code quality + docs,
governance / Guix packaging policy.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm