standards needs its own .github/workflows/actions.lock — lockfile enforcement 0s-startup-fails every downstream reusable caller

[hyperpolymath]

Problem

GitHub's workflow-lockfile enforcement now rejects runs as 0-second startup_failures (no jobs, no logs, no check runs — error only on the run HTML page) for workflows that aren't covered by .github/workflows/actions.lock.

Repos have been cured individually with gh actions-lock (proven: echidna #341, haec #46, and today metadatastician/chronicles-of-slavia#59 — 10+ workflows went from 0s startup_failure to green in one commit).

But workflows that call this repo's reusables cannot be cured downstream. On chronicles-of-slavia, after its lockfile landed, exactly the seven reusable-caller workflows still 0s-fail:

• rust-ci, governance, secret-scanner, scorecard, mirror, hypatia-scan, boj-build — all uses: hyperpolymath/standards/.github/workflows/*@412a703…

The enforcement needs the called repo to carry its own lockfile before caller runs can start. Until standards ships one, every downstream wrapper in the estate (~6 reusables × dozens of repos) stays dead regardless of per-repo remediation.

Fix

gh extension install github/gh-actions-lock   # if not present
gh actions-lock                                # in this repo; commit the result

Gotchas from the estate remediation memory: verify no dtolnay/rust-toolchain refs get semver-narrowed (dtolnay reads the toolchain from the REF), and if an SPDX-header linter checks line 1, move the # This workflow is managed by gh actions-lock. marker to line 2 (it inserts itself as line 1; chronicles hit exactly this, fixed in metadatastician/chronicles-of-slavia@1d0dffd).

🤖 Generated with Claude Code

[hyperpolymath]

Update from the chronicles-of-slavia remediation (metadatastician/chronicles-of-slavia#61): caller-side lockfile coverage for reusables IS achievable by hand — the enforcement accepts entries of the form hyperpolymath/standards@<sha> in the caller's workflows: section, with a uses: transitive list on the dependency entry naming every action the called reusables use at that ref (portable verbatim from this repo's own actions.lock). With that in place, Rust CI and Secret Scanner produced the first successful runs of their existence on the caller side.

Two upstream items this surfaced:

1. governance-reusable.yml's embedded workflow-security linter is lockfile-unaware — it requires inline 40-hex SHAs on every uses: and therefore fails any consumer that adopted gh actions-lock (whose model is tag-form refs + lockfile-authoritative SHAs). Chronicles' local linter got a lockfile-aware pin check in fix(ci): adopt gh-actions-lock lockfile — cures repo-wide 0s startup_failure metadatastician/chronicles-of-slavia#59 (ref covered by actions.lock counts as pinned; subpaths normalized to repo level) — the same patch belongs in the reusable.

2. gh actions-lock v0.1.6 does not model reusable-workflow deps at all (scans callers, reports nothing to pin) — worth an upstream feature request or an estate wrapper, since every consumer repo will need these hand-authored entries until then.

[hyperpolymath]

Closed — the premise no longer holds.

This issue states that standards has no .github/workflows/actions.lock, and
that this 0s-startup-fails every downstream reusable caller.

Re-measured 2026-08-07:

$ gh api repos/hyperpolymath/standards/contents/.github/workflows/actions.lock --jq '.size'
10567

The lockfile exists (10,567 bytes, blob f74064c3) and covers 38 workflow
files. standards main over the last 30 runs: 21 success, 2 failure,
7 cancelled — not the zero-job startup-failure pattern this issue describes.

Landed via the lockfile adoption chain (#570 / #571 / #572 / #574).

The residual failures on main are separate defects with their own causes; they
are not "no lockfile", which is what this issue tracks.