main-estate-audit.yml startup-dies from any caller: actions.lock is stale relative to its own uses: refs

[hyperpolymath]

Symptom

Calling the reusable estate audit from a metadatastician org repo produces a run that
never starts a job:

conclusion = failure     jobs.total_count = 0
run.name == run.path == .github/workflows/main-estate-audit.yml

It does not appear in the calling PR's check rollup, so it fails silently rather than
red — the workflow looks configured while never running.

Reproduced from metadatastician/large-language-michelangelo (PR #1 there), calling
main-estate-audit.yml@31b5b45a — a ref that resolves, at a commit where the file exists
and declares workflow_call.

Cause

The workflow_call contract is fine. The problem is inside the job. At 31b5b45a,
.github/workflows/main-estate-audit.yml contains 27 uses: refs, 26 of them unpinned
branch refs:

uses: hyperpolymath/cicd-suite/actions/required-files-check@main
uses: hyperpolymath/cicd-suite/actions/code-hygiene-check@main
uses: hyperpolymath/cicd-suite/actions/manifest-check@main
uses: hyperpolymath/cicd-suite/actions/idris2-abi-check@main
uses: hyperpolymath/cicd-suite/actions/zig-hexadeca-check@main
... 21 more

Only actions/checkout is SHA-pinned.

The org enforces sha_pinning_required. Under that policy a non-SHA ref is a startup
failure at 0s, which reports as no check rather than a failing one.

So the audit cannot run in any org repo that adopts it.

Why this one matters more than a normal pin problem

This is the workflow whose job is to audit the estate's compliance. As written it is itself
non-compliant with the estate's own pinning policy, and the failure mode is invisible: a repo
adopting it gets a workflow file, a green-looking PR, and no audit.

Suggested fix

Pin the 26 internal action refs to full commit SHAs.

Two cautions from experience elsewhere in the estate:

1. Pin to commit SHAs, not blob SHAs. A file's blob hash is also 40 hex characters and
   satisfies a naive pin gate while being unresolvable. Verify each with
   gh api repos/<owner>/<repo>/commits/<sha>.
2. The in-repo comment says these are @main deliberately, to test the actions from the
   current revision rather than older implementations on main. That intent is reasonable —
   but it is incompatible with sha_pinning_required for external callers. It may need
   splitting: a self-test workflow that uses ./actions/... local paths (which need no pin),
   and a separate published reusable that is fully SHA-pinned for callers.

Option 2 is likely the real fix, since local ./actions/... refs give the
test-this-revision behaviour without any pin at all.

[hyperpolymath]

Correction: I attributed this to the wrong cause. The real cause is actions.lock drift.

The symptom in the issue body is accurate and still reproduces. The diagnosis is wrong, and
so is the suggested fix — which would have made it worse. Leaving the body above intact as the
record of the mistake; this comment supersedes its "Cause" and "Suggested fix" sections.

What the run actually says

jobs.total_count == 0 proves startup death but says nothing about why. The reason is not in
the REST API at all — it is printed on the run's HTML page. Read unauthenticated from
https://github.com/metadatastician/large-language-michelangelo/actions/runs/34874844107/workflow
(the /workflow partial; the base run page does not carry it, and /annotations_partial
returned zero bytes), the annotation reads verbatim:

error parsing called workflow
: Invalid dependency lockfile "hyperpolymath/cicd-suite/.github/workflows/actions.lock@31b5b45a89c9c05b8d20d50fd3bee56f4959952e": workflow ".github/workflows/main-estate-audit.yml" references actions not present in the lockfile: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1, hyperpolymath/cicd-suite@main Run 'gh actions-lock' to regenerate the lockfile.
Invalid workflow file

Not a pinning-policy refusal. A lockfile parse failure, which fires before any policy layer
is reached.

The proof, and it is exact

.github/workflows/actions.lock at 31b5b45a contains:

    'actions/checkout@v7.0.1':
        ref: 'v7.0.1'
        commit: 'sha1-3d3c42e5aac5ba805825da76410c181273ba90b1'

and main-estate-audit.yml:25 contains:

      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

Same commit. Different spelling. Rejected. The lockfile is keyed on the literal ref string,
not on the resolved commit — so substituting a tag with the very SHA the lockfile itself records
for that tag produces a ref "not present in the lockfile".

The second missing key is hyperpolymath/cicd-suite@main, which is how the 26
hyperpolymath/cicd-suite/actions/<name>@main refs collapse. The lockfile does not carry it: for
this workflow it still lists hyperpolymath/deed-ecosystem@main and hyperpolymath/k9-ecosystem@main.
That is a lockfile generated before the workflow body was rewritten and never regenerated.

Why my suggested fix was actively harmful

The issue body says "pin the 26 internal action refs to full commit SHAs." Do not do that.
Changing a ref's spelling is precisely what broke actions/checkout. Pinning 26 more @main refs
without regenerating the lock would add 26 more keys absent from it.

The actual fix

gh actions-lock

in cicd-suite, committed in the same commit as any change to a uses: ref spelling. The
general rule this repo now needs as policy: in a repository carrying .github/workflows/actions.lock,
a ref-spelling change and a lockfile regeneration are one atomic edit. They cannot be separated,
because the failure when they are is invisible — no check run, no red, absent from the caller's
rollup entirely.

What I have NOT established

I have not shown that regenerating the lockfile makes this runnable from an org repo. The
lockfile check fires first, so everything behind it is untested. Specifically:

• metadatastician/large-language-michelangelo does enforce sha_pinning_required: true
  (measured this time, at the repo level — repos/.../actions/permissions; the org endpoint 403s
  without admin:org). Whether the 26 @main refs then survive that policy is unknown and
  untested, and I am not going to guess at it a second time.
• The actions allow-list is not a blocker here, which I can state positively:
  github_owned_allowed: true and patterns_allowed includes hyperpolymath/*, so both
  actions/checkout and hyperpolymath/cicd-suite/actions/* are permitted.

So: regenerating the lockfile is necessary. It may not be sufficient.

What survives from the original suggestion

Option 2 in the body — split into a self-test using local ./actions/... paths plus a separately
published, caller-facing reusable — still looks right structurally, and gains a second argument:
local ./actions/... refs need no lockfile entry at all, so the self-test half stops being
able to break this way. The published half still needs the lockfile rule attached to it.

Reference: https://gh.io/actions-lockfile.