docs(backlog): file the zizmor self-repository red on cla.yml (BACKLOG #1457)

[wshallwshall]

Files BACKLOG #1457. One item, no code, no fix -- the remedy is deliberately left open because guessing it is the dangerous move.

What it records

zizmor is red on this repository and nothing will clear it on its own.

Dependabot's #891 bumped zizmor==1.29.0 to 1.30.0 in ci/locks/ci-scanners.lock. That release added the self-repository audit, which fires one LOW on .github/workflows/cla.yml:102 -- the vendored local action is uses: ./.github/actions/cla-assistant-lite. The job exits 12 on any finding.

The part worth filing

The gate ran on the bump and was merged past. #891's own run 33945900593 finished at 04:57:02Z with 1 low, 0 medium, 0 high and exit code 12. The pull request merged at 21:02:26Z, sixteen hours later.

That is not a bypass, and the item says so plainly. Read from the server: zizmor (GitHub Actions static analysis) is not among the thirteen required contexts, autoMergeRequest was null, and the merge was ordinary. An advisory check went red and nobody was obliged to stop. The finding is a gate whose redness costs nothing, not misconduct.

What was measured, and on what

main has not run zizmor since the bump -- its last run is 2026-09-05T09:35:09Z at b9d204e38, green, predating the merge. So "main is red" is not yet observed. What is observed is stronger than a guess and the item states it as exactly what it is:

main's pinned scanner	origin/main:ci/locks/ci-scanners.lock reads zizmor==1.30.0
main's cla.yml	blob a4d4e1e98a5c2bcd255b615b93ec8c440aed2f03
the branch that ran it	PR 901, same blob, byte-identical -- run 33992002941
result	the same single LOW

So main's own scanner has already been run against main's own file. The remaining step is that the 06:00 UTC cron uses those same two inputs. The item names the one query that closes it rather than asserting the outcome.

Why no fix is proposed

zizmor's help says "use '$/...' instead of './...'" and marks it auto-fixable. That syntax was not verified against GitHub's documentation by this filing, and the item quotes it as the tool's claim rather than repeating it as fact. Verifying it is listed as the research.

And cla.yml is the worst file in the repository to guess at. cla is a required context, the workflow runs on pull_request_target, and a pull_request_target workflow cannot be tested by the pull request that changes it -- the edit lands on main untested, and if it is wrong the repair is itself gated by the check it broke. That deadlock happened here on PR 621 and needed an administrator. scripts/quality/workflow_local_action_check.py exists because of it.

Three ends are named as non-equivalent: adopt the syntax if real, suppress with a reason in .github/zizmor.yml as four dangerous-triggers entries already are, or accept it as a residual beside the archived-uses entry that already covers this same file at cla.yml:44.

One stale line found in passing

.github/workflows/zizmor.yml's header says a bump PR touching only pyproject.toml and the lock "never ran this gate", citing PR #66. The pull_request trigger now carries paths: [".github/**", "ci/locks/ci-scanners.lock"], so #891 did run it, and did fail it. Recorded in the item; not edited here, because that file is zizmor.yml and this PR is a backlog filing.

Checks

• parse_items from backlog_status_check.py, as an ADDED/LOST set difference against origin/main: 1 added (#1457), 0 lost, 0 status changes, #1457 parses open
• number allocated with scripts/coord/alloc.ps1 -Kind backlog, never grepped
• pre-commit: ledger gate, backlog ledger parse, forbidden-content, control characters, secrets -- all pass

Related: #901 carries this red and is not its cause; its comment thread has the same attribution. The two are independent and can merge in either order.

Generated with Claude Code

[wshallwshall]

Superseded by #940, which merged at 11:52 CT as 89b2574c. This pull request's row (BACKLOG #1457) is on main now, byte-identical to what was filed here.

Closed by the Lander, not rejected. Eight ledger-only pull requests were consolidated into one so that nine filings cost one merge cycle rather than eight. Under strict branch protection each of these would have re-dirtied the other seven.

The consolidation merged each branch rather than cherry-picking, so every number arrived carried by a real merge parent, and it re-applied only this branch's own sections onto main's current file. That mattered: taking any of these branches wholesale would have silently reverted #1426, #1440, #1454, #1455 and #1456. Final state verified at 443 rows against a target computed before building, 678 additions and zero deletions, no duplicate numbers.

Nothing here needs re-filing.