[HackTuah]

This workflow was added alongside the OpenSSF badge work and has never run once. Four startup_failure results, no job, no log, and the message "This run likely failed because of a workflow file issue."

The file was not the issue

• actionlint passes it.
• All three pinned commits resolve (ossf/scorecard-action v2.4.4, github/codeql-action, actions/checkout).
• Three stripped-down copies pushed to a throwaway branch failed identically — including one that was nothing but a checkout and the action, with no workflow-level permissions block and no other triggers.

The cause

The repository's Actions policy:

{"allowed_actions": "selected"}
{"github_owned_allowed": true,
 "patterns_allowed": ["erlef/setup-beam@*", "mlugg/setup-zig@*"],
 "verified_allowed": false}

ossf/scorecard-action is neither GitHub-owned nor was it listed, so the run was refused before a job existed. Every other action in this tree lives under actions/ or github/, which is why nothing else ever hit it. The allow-list has since been corrected to include ossf/scorecard-action@*.

What this change does

workflow_dispatch. A run that ends in startup_failure cannot be re-run, and the only other triggers were a push to the default branch and a weekly schedule — so every attempt to diagnose this cost a commit on main. A workflow that cannot be triggered on demand is a workflow that cannot be tested, which is how it stayed broken from the day it landed.

The diagnosis, in a comment at the top of the file. The next action added from a new owner will hit the same wall, and the message GitHub gives points at the wrong file. Adding an action from a new owner to any workflow in this repository requires adding it to the allow-list, or the workflow silently never starts.

Evidence

mix test test/workflows_test.exs — 3 passed (every action still pinned to a 40-character commit SHA; both workflows still parse as YAML). The full gate runs on this PR.