Triage: 3 pre-existing red checks surfaced by the actions.lock cure (PR #566)

[hyperpolymath]

Summary

hyperpolymath/gitbot-fleet#566 carries the actions.lock desync cure from the estate campaign (hyperpolymath/standards#968). The lockfile change itself verifies clean. The checks listed below are pre-existing reds that only became visible once the cure revived the workflows that run them.

Per the standing stopping rule, a pre-existing red is an issue with acceptance criteria, not a merge blocker. This is that issue for this repo.

Failing checks (3)

GSBot build, tests and dependency security

• Determine whether GSBot build, tests and dependency security is fixed, retired, or accepted with a documented exemption. It may not stay undetermined.
• Record whether GSBot build, tests and dependency security is also red on main. If it is, it measures the estate, not this change, and nothing is required of this branch that its base does not satisfy.
• If fixed: the check is green on this PR head, and the fix is in the repo — not continue-on-error, not a demotion to a warning, not removal from the required set.

governance / Workflow security linter

Also red on main in several repos. Confirm whether this repo's main is red before treating it as a branch defect.

• Determine whether governance / Workflow security linter is fixed, retired, or accepted with a documented exemption. It may not stay undetermined.
• Record whether governance / Workflow security linter is also red on main. If it is, it measures the estate, not this change, and nothing is required of this branch that its base does not satisfy.
• If fixed: the check is green on this PR head, and the fix is in the repo — not continue-on-error, not a demotion to a warning, not removal from the required set.

governance / Validate Hypatia Baseline

One of four different check names the Hypatia scanner reports under across the estate. See standards#994 AC3 before renaming anything — a rename orphans every open PR that predates it.

• Determine whether governance / Validate Hypatia Baseline is fixed, retired, or accepted with a documented exemption. It may not stay undetermined.
• Record whether governance / Validate Hypatia Baseline is also red on main. If it is, it measures the estate, not this change, and nothing is required of this branch that its base does not satisfy.
• If fixed: the check is green on this PR head, and the fix is in the repo — not continue-on-error, not a demotion to a warning, not removal from the required set.

Acceptance criteria for closing this issue

• Every check above has a recorded determination (fix / retire / exempt).
• Any check determined fixed is green on a run of this repo's default branch.
• Any check determined retired is removed from the workflow and from the repo's required-check set in the same change.
• Any check determined exempt has the exemption written down with its reason and a review date.
• No check was closed by muting it. Repair or retire; never silence.

Context

• Campaign roll-up: actions.lock step-level desync: 39 repos with silently dead CI (startup_failure) standards#968
• Cross-cutting classes (this repo's reds are mostly instances of them): Cross-cutting governance reds surfaced by the actions.lock cure — 9 classes across 17 PRs (incl. a live gate for the retired A2ML) standards#994
• Lock policy + the pin bump that disarms the latent blocker: actions.lock policy: job-level reusable refs are reported, never required — and the pin bump that disarms the latent blocker standards#993

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm

[hyperpolymath]

Correction to the wording above

This issue states that "the lockfile change itself verifies clean." That claim needs narrowing,
because it is weaker than it reads.

1. Scope. It was verified on the branch as I left it. A concurrent actor has committed to this
   branch since. The verification does not cover those later commits — re-verify against the
   current head before relying on it.

2. The oracle is not authoritative either way. The check was gh actions-lock --verify-local,
   which is measured to be wrong in both directions: it reports a false STALE on job-level
   reusable-workflow refs (upstream ci(workflow): adopt hardened hypatia-scan from hyperpolymath/hypatia#237 (API-only retry) #129), and a false green on a tag-vs-SHA literal mismatch —
   the tool compares by resolved commit while GitHub compares by literal string. A clean
   --verify-local is therefore evidence, not proof.

The authoritative test is whether the workflows actually start. Run this against the full
40-character head SHA:

gh api repos/$R/commits/$FULL_40_CHAR_SHA/check-suites \
  --jq '.check_suites[]|"\(.app.slug)\t\(.conclusion)"' | sort | uniq -c

⚠ Two traps in that one command. gh run list --commit silently matches nothing when given a short
SHA — it reads exactly like "no failures". And a startup_failure creates no check run at all, so
statusCheckRollup shows only the third-party apps (gitguardian, sonarqubecloud, …) and a repo whose
every workflow is dead still reads as green. Separate the github-actions app from the third-party
apps before calling any rollup green. That trap produced a false green verdict on four other PRs in
this campaign today.

Nothing about the fix in this PR changes; only the strength of the claim does.

🤖 Generated with Claude Code

https://claude.ai/code/session_01X3hgXxWm6umMgZkjYyHnnm