Zero-job startup_failure on every cross-owner reusable caller: CI creates no jobs, so required 'scan / gitleaks' can never report #141

What is happening

Every workflow in this repository whose job calls a reusable workflow owned by another account ends its run before any job exists:

Workflows that use only actions/* steps (Dogfood Gate, Code Quality, Estate Rules, Lock Sync Gate, OpenSSF Compliance, Static Analysis Gate, Runtime Policy, Workflow Security Linter, CodeQL) pass every time.

Consequence: zero jobs means zero check runs, so none of this appears in a PR check list. scan / gitleaks is a required status check on main, produced by Secret Scanner — so it can never report, and no pull request can be merged through the normal path. That is not a hostile check; it is a check that never starts.

When it started

• Rust CI: last success 2026-10-22T00:34Z; first startup_failure after that.
• Secret Scanner: on main, ran (conclusion failure, jobs existed) at 2026-10-25T19:41Z; from 2026-10-25T19:49Z onwards, startup_failure with 0 jobs.

2026-10-25 is also the date the estate repointed these callers from hyperpolymath/standards to metadatastician/standards (see the comment in .github/workflows/standards-pipeline.yml). The repository hyperpolymath/standards now redirects to metadatastician/standards — verified today:

$ gh api --include repos/hyperpolymath/standards
HTTP/2.0 200 OK
{"full_name":"metadatastician/standards","id":1116521501,"owner":{"login":"metadatastician","type":"Organization"}}

The caller (hyperpolymath/cicd-squabbler) is owned by a user; the callee is now owned by an organization. Cross-owner reusable-workflow calls are refused at startup unless the caller's Actions posture admits them.

Ruled out

• The pinned files exist. All six reusables resolve at 8e48b1caade08a552646adeab66558ac43b4360d, sizes 1.5–25 kB.
• The called repository moved, and the callers already use the canonical name. No repoint is outstanding (this is the inverse of Zero-job startup failures as first-class classes; chains resolves canonical upstream names #140's moved-coordinate class).
• The lockfile is not the cause. Lock Sync Gate is green (actions.lock is in sync and transitively closed, including the creusot.yml entry added in Zero-job startup failures as first-class classes; chains resolves canonical upstream names #140).
• Not a missing input/secret. No caller passes an undeclared input; the caller-declared secrets match what mirror-reusable.yml declares.
• Not the same failure in other repos using the old name. hyperpolymath/docmatrix's rust-ci.yml, still calling hyperpolymath/standards/…, also produces a 0-job failure. So this is not "the new name is refused, the old one works" — it is every cross-owner reusable call.

What it most likely is (needs an admin token to confirm)

One of two Settings-level postures, both of which are checked against the written owner/repo:

1. Actions → General → Access: "Allow owner actions and reusable workflows" rather than "Allow all", which refuses a callee in a different account (metadatastician) at startup; or
2. allowed_actions=selected with a patterns_allowed list that has no pattern covering metadatastician/standards@*.

I cannot read either. Every permissions endpoint refuses this token:

$ gh api repos/hyperpolymath/cicd-squabbler/actions/permissions
{"message":"Resource not accessible by integration","status":"403"}
$ … /actions/permissions/access          → 403
$ … /actions/permissions/selected-actions → 403

administration: read is required, and the token here is a GitHub App installation token without it.

Fix (owner action, either is enough)

A. Admit the callee — Settings → Actions → General → Access: Allow all actions and reusable workflows; or keep selected and add the pattern metadatastician/standards@* to patterns_allowed. Keep sha_pinning_required=true; the callers are already full-SHA pinned, so nothing is weakened.

B. Or make caller and callee the same owner — move these workflows into a repository owned by the same account as the reusable, which is the posture before 2026-10-25.

Then confirm with:

gh run list --workflow rust-ci.yml --limit 3
# expect: success/failure with jobs > 0, never startup_failure with 0 jobs

Why this matters beyond CI hygiene

This is exactly the second class #140 makes first-class: a coordinate refused by the caller's allow-list, dying with zero jobs, creating no check run, therefore invisible in every PR check list — and here it is silently blocking every merge in this repository while the board reads green.

squabble zero-job is the command built to name this per run (repo, workflow, coordinate as written, canonical target, required allow-list pattern). It reports Unattributed with the probe failure quoted, rather than inventing a cause, when it cannot read the posture — which is precisely the evidence trail this issue needed and could not get.

Follow-up

Once the posture is readable, squabble zero-job . --limit 30 on this repository should name metadatastician/standards@* as the required pattern for each of these runs. Until then this issue is the record.