ci: the caller's SHA pin on ci-conformance.yml is inert — the policy scripts always come from main, and check 9 has blocked all four repos since 13:03Z

[krisarmstrong]

What is broken

ci-conformance.yml checks the policy repo out at main, not at the SHA the
caller pinned. The guard that was supposed to prevent this is present but inert:

# .github/workflows/ci-conformance.yml (at 1920efa, and still on main)
- name: Check out the policy repo
  uses: actions/checkout@3d3c42e5...
  with:
    repository: MustardSeedNetworks/.github
    ref: ${{ github.job_workflow_sha }}
    path: .conformance

The file's own comment states the hazard exactly: "without a ref here the scripts
that actually decide the verdict came from whatever was on this repo's default
branch at run time — so the caller's pin bought nothing." That is what is
happening today: github.job_workflow_sha evaluates to the empty string at run
time, actions/checkout falls back to the default branch, and the caller's pin
buys nothing after all.

Observable (niac-go run 35100092161, job 104807020948, 2026-09-16T13:09Z)

The with: block actions/checkout echoed for the .conformance checkout has
no ref entry — an empty input is not printed — and the checkout resolved to
the policy repo's default branch:

##[group]Run actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
with:
  repository: MustardSeedNetworks/.github
  path: .conformance
  persist-credentials: false
  ...                                  <- no `ref:` line
##[group]Checking out the ref
[command]/usr/bin/git checkout --progress --force -B main refs/remotes/origin/main
Switched to a new branch 'main'
[command]/usr/bin/git log -1 --format=%H
75ad8d13a9690f8dfe9c01b2b57d56965dfed640      <- .github main, not the pin

niac-go pins ci-conformance.yml@1920efa; seed, stem and trellis pin
@048d173. Neither commit's scripts/check-ci-conformance.py contains check 9
(the msn-shared.css hash check):

$ gh api ".../check-ci-conformance.py?ref=1920efa..." | base64 -d | grep -c msn-shared
0
$ gh api ".../check-ci-conformance.py?ref=048d173..." | base64 -d | grep -c msn-shared
0

Yet check 9 is what failed the job. The script came from 75ad8d13 (main).

That github.job_workflow_sha is empty is the inference that fits; why it is
empty is not established here and needs a real run to diagnose (echo the context
value in a debug step).

Blast radius — all four product repos are unmergeable right now

#72 merged at 2026-09-16T13:03:21Z. Every ci.yml run started after that
instant runs check 9 against a product copy that has not been adopted yet, and
ci-conformance is in ci-complete's needs: while CI Complete is a required
status check in all four repos. Observed:

repo	copy sha256	canonical	first red
seed	3f4450a001cf	b073e5e15bab	next run (last run 11:25Z, green)
stem	38eb15f3a815	b073e5e15bab	next run (last run 12:14Z, green)
trellis	f006cb263d41	b073e5e15bab	run 35100014704, 13:08Z — merge-queue ejection of PR #503
niac-go	3f4450a001cf	b073e5e15bab	run 35100092161, 13:09Z — PR #2210

This is the opposite of what UI-FLEET-1's closeout recorded ("All four repos
pin ci-conformance.yml at a SHA (verified), so merging #72 turns nothing red on
its own"). The pins were verified; their effect was assumed.

Why this matters beyond the theme check

A pinned reusable workflow whose verdict-deciding scripts float on main means
two runs of an identical product commit can disagree, and any future check
added here goes live in all four repos instantly with no adoption window. Fixing
this is worth more than the immediate red.

Suggested shape (not prescribed)

Either make the ref resolution actually work (and prove it — echo the resolved
value in a debug step in a run, do not trust the expression), or drop the
indirection and have the workflow run scripts that live in the same commit as the
workflow (${{ github.workflow_sha }} is the caller's SHA in a different repo
and will not resolve here — the existing comment already says so).

Whatever the shape, it needs a verification vehicle: .github calling
ci-conformance.yml on itself at a fixture, so "the pin is honoured" is proven by
a run rather than by reading YAML. Landing a fleet gate change without one is how
this defect shipped.

Interaction with the adoption rows

The four adoption rows (UI-SEED-7, UI-STEM-7, UI-NIAC-9, UI-TRL-8) also
clear the red, per repo, by making each copy match the canonical. Those rows
should land regardless — they are the point of #69. This issue is the separate
defect that they went live without an adoption window.

[krisarmstrong]

Confirmed on the other pin as well, so this is not specific to niac-go's @1920efa. Both of these run on @048d173:

repo	job	pin	checkout	verdict
trellis	104806756283 (13:08Z)	@048d173	-B main → 75ad8d13	check 9 failed
seed	104811322742 (13:21Z)	@048d173	-B main → 75ad8d13	check 9 failed
niac-go	104807020948 (13:09Z)	@1920efa	-B main → 75ad8d13	check 9 failed

seed's 13:21Z run is the clean before/after: its 11:25Z run (same pin, same drifted copy 3f4450a001cf) was green, and the only thing that changed in between is #72 landing on this repo's main at 13:03:21Z.

stem is not yet observed — same pin, same mechanism, drifted copy 38eb15f3a815, no run since 12:14Z — so treat it as the fourth, not as a counter-example.

The load-bearing line in each log is git checkout --progress --force -B main refs/remotes/origin/main, which is actions/checkout's empty-ref default-branch path. That is stronger evidence than the missing ref: entry in the echoed with: block, since an empty input simply is not echoed.

[krisarmstrong]

Closed by #75 (squashed to main as part of that merge).

Diagnosed by a run, as this issue asked. Run 35103911603 echoed the context and the OIDC claims side by side for one reusable-workflow job:

ctx  job_workflow_sha=[] len=0
ctx  job_workflow_ref=[] len=0
ctx  workflow_sha=[14b7016993a76e61742cde463b865fb1b736478d] len=40
oidc job_workflow_sha=[34fde546a3fbfd5587e63e0f3b62506344517106]

Both job_workflow_* are absent from the github context and present in the OIDC token; 34fde546… is exactly the commit the caller pinned. The empty ref: was actions/checkout's default-branch path — hence the git checkout --force -B main refs/remotes/origin/main line you traced in every job.

Fix: take the SHA from the OIDC token, validate it is 40 hex, check out the policy repo at it, and assert .conformance HEAD is that commit. Fails closed — no token endpoint, no claim, or a mismatched landing each abort the job, never a silent fall-back to a branch. Callers must grant id-token: write on the calling job; the Call it with: block documents it.

Also removed -ignore 'property "job_workflow_sha" is not defined' from this repo's own ci.yml. actionlint was right that the property is not in the context schema; that ignore was the only thing keeping the defect invisible.

Verification vehicle (this repo had none). ci.yml now calls ci-conformance.yml against test/fixtures/conformant-repo, and conformance-self-test-result asserts the workflow's new policy-sha output equals the literal SHA in its own uses:. Both jobs are in ci-complete's needs:. Run 35104862421:

Conformance scripts will be read from .github@55d509d09e431c441ec068c031aba538881c5d3c
policy checkout verified at 55d509d09e431c441ec068c031aba538881c5d3c
pinned in uses:    55d509d09e431c441ec068c031aba538881c5d3c
policy-sha output: 55d509d09e431c441ec068c031aba538881c5d3c
The pinned ref was honoured.

Discriminating, not a tautology: main was 75ad8d1 during that run — exactly where the old code would have landed. The fixture is non-vacuous; RED proofs for check 9 and the linter floor are in the PR body.

Two things this does NOT do, so nobody waits on them:

1. It does not green the four product repos. They call the old workflow at the old pin, so nothing here changes what they execute. Their red is drifted msn-shared.css, cleared by the adoption rows (UI-SEED-7 / UI-STEM-7 / UI-NIAC-9 / UI-TRL-8).
2. The pin bumps are follow-up work (D-docs(ci): show pinned-SHA usage in reusable-workflow examples #4). Each product's next bump to this workflow must add id-token: write to the calling job, or that job fails loudly — the intended fail-closed trade.

This issue's "a fixture pinned to a commit whose script lacks a check does not run that check" could not be exercised: every commit carrying the fix also carries check 9, so no such commit exists to pin against. SHA equality tests the same property without fabricating a fixture; the lacks-a-check form becomes available the first time a check 10 lands after this.