[fas89]

Your hypothesis was right, and the thing that "did not fit" has a dull answer. It is also worse than a red badge: the gate was not failing visibly, it was absent.

The cause: confirmed

actionlint 1.7.12 on the merged file, nothing else to interpret:

.github/workflows/cli-consistency.yml:43:32: context "runner" is not allowed here.
available contexts are "github", "inputs", "matrix", "needs", "secrets",
"strategy", "vars". [expression]
   |
43 |       FORGE_CLI_CHANGELOG: ${{ runner.temp }}/forge-cli-CHANGELOG.md
   |                                ^~~~~~~~~~~

One finding across all four workflows, and it is the line you named. runner is not available to jobs.<job_id>.env, so GitHub rejected the workflow before creating a job.

Why the pull_request runs passed — it is not an asymmetry

They were testing a different file. Every run's head commit, checked for the offending line:

Run	Event	Result	runner.temp in its workflow file
13339f1b (#166 branch)	pull_request	success	0
9dd19536 (#167 branch)	pull_request	success	0
da80bcb7	push	failure	1
3eb4e004	push	failure	1
6ba10752 (main)	push	failure	1
751339b8 (main)	push	failure	1

docs/release-leftovers and docs/odps-odcs-export-fields were both cut from agenticstiger/main at 70409a4, before #165 merged, so their checkouts carried the pre-bug workflow. Their PR runs were green because there was nothing wrong with the file they ran. Every commit that actually contains the line failed, whatever the event. So: no push-versus-pull_request difference, no two-event resolution puzzle — just a coincidence of branch ages. Your hypothesis survives intact.

Two of those failures are themselves evidence. da80bcb7 and 3eb4e004 are branch commits, not main, and the push trigger is branches: [main] — yet both produced push-event runs. The branch filter could not be applied, because the workflow never got far enough to be filtered. Branches without the line produced no push run at all, as expected.

The part that matters more than the red badge

A startup failure produces no check run. Not a failing one — none. So the job did not appear on the check list at all:

PR	Verify docs match installed fluid CLI rows
#165 (introduced the bug)	0
#166	1, passing
#167	1, passing
#168	0

#168's full check list is ten rows — CodeQL ×4, the three link-check jobs, docs-pr-check build, and deploy's build and deploy — and the drift gate is not among them. Your "7 success, 1 skipped" was a complete read of an incomplete list, and the skip was link-check's External URLs leg, which skips on PRs by design. There was nothing to see.

So the gate has run zero times since da80bcb7 at 22:13 on 26 Oct, including on its own pull request. Not half a gate — none of one, on PRs as well as on main, for any branch cut after #165 merged.

The fix

The job-level env: block is gone. The step that writes the file resolves the path in the shell, where RUNNER_TEMP is an ordinary variable, and exports it for the steps that read it:

      - name: Fetch forge-cli's CHANGELOG
        run: |
          dest="${RUNNER_TEMP}/forge-cli-CHANGELOG.md"
          curl -sSfL --retry 3 --retry-delay 2 \
            -o "$dest" \
            https://raw.githubusercontent.com/Agenticstiger/forge-cli/main/CHANGELOG.md
          grep -qE '^## \[?[0-9]+\.[0-9]+\.[0-9]+' "$dest"
          echo "FORGE_CLI_CHANGELOG=$dest" >> "$GITHUB_ENV"

GITHUB_ENV rather than a step-level env: repeated on the three steps that read the variable: one definition, in the step that owns the file, so there is no expression left to get wrong and no job-level block to tempt the next person. The fetch step still runs before every reader (step 3 of 10; the readers are steps 7 and 9). A comment above it names the trap and what it cost.

Simulated the step verbatim with RUNNER_TEMP and GITHUB_ENV pointed at local paths: the fetch writes 5,732 lines, the grep guard matches, GITHUB_ENV gets the resolved path, and a later step that inherits it runs the sweep to OK … forge-cli newest release 0.23.0, reviewed through 0.23.0.

Stopping the next one

workflow-lint.yml runs actionlint over .github/workflows/**, from a workflow of its own so it survives the others being invalid — which matters here, because every other gate in this repo is a step inside a workflow, and a workflow that cannot start takes its own gate down with it. Nothing else in the repository could have seen this.

Self-tested both ways, the way the other gates here are:

$ actionlint .github/workflows/*.yml          # as committed
(clean)

$ # job-level env block put back verbatim
$ actionlint .github/workflows/*.yml
cli-consistency.yml:41:32: context "runner" is not allowed here. …
rc=1

Pinned to rhysd/actionlint:1.7.12, the version that reproduced the real failure. It has not run on a runner yet — this pull request is its first exercise. If the container invocation is wrong it fails this PR visibly, which is the opposite of the bug it guards, so I would rather find out here than pin something untested behind a green tick.

Verified locally

On python3.12 with data-product-forge[local]==0.23.0, with FORGE_CLI_CHANGELOG supplied the new way:

Command	Result
check_cli_docs.py (all 7 checks)	OK — 69 subcommands, 0.7.5 scaffold, contract pins, 1335 invocations, every version claim, 237 pages swept
check_providers.py	OK
gen_contract_reference.py --check	OK
actionlint over all five workflows	clean; exit 1 with the bug reintroduced

No docs content changed, so the build and link gates are untouched by this.

The trailers

Taken, and it was mine, not yours — you merged what I wrote. My stored note on this user's attribution preference said the PR footer was out but the commit trailer was fine. That was wrong: Agenticstiger/forge-cli's CLAUDE.md line 430 reads "Never add Co-Authored-By: Claude … trailers to commits (repo-wide preference)", and forge_docs has no instruction file of its own to override it. I have corrected the note so it covers both surfaces and cites that line, and this commit carries no trailer.

Agreed on not touching the four squashed commits on main — rewriting published history is the maintainer's call, not ours. Worth raising with them as a decision rather than leaving it implicit, since the alternative is that it stays.