docs(backlog): file #1481, a scoped secret scan that walks zero commits passes

[wshallwshall]

A required secret gate can report success having looked at nothing

Ledger-only. Files BACKLOG #1481; no code changes.

PR #977 (BACKLOG #1479) scopes the required gitleaks (secret scan) job with --log-opts. A range is a thing that can resolve empty, and an empty range makes the scanner report 0 commits scanned and exit 0 — a green tick, indistinguishable in the checks UI from a clean scan.

Measured on the CI-pinned 8.18.4 binary:

invocation	reported	exit
--log-opts HEAD (what 977 ships)	2 commits scanned	1, planted secret caught
--log-opts HEAD..HEAD (empty range)	0 commits scanned	0
no --log-opts (pre-977 default)	2 commits scanned	1

The shipped range is safe, which is why this is P3 and filed rather than fixed

--log-opts HEAD is a literal — not a base SHA, head ref, or PR number. Measured on a merge-commit HEAD shaped like a merge-queue commit (two parents): 2 commits scanned, secret caught, exit 1. It cannot resolve empty on any of the workflow's five triggers.

This row is about the next edit. 977's own comment records that an event-aware range was declined because three of five triggers carry no base SHA — the moment someone adds one, the range acquires the ability to be empty, and on those triggers it silently will be.

Why this is not bolted onto 977

977 is green and is unblocking a merge queue that has been frozen for hours. Adding speculative hardening would have cost a full CI cycle to defend against a future edit rather than a present defect, on a file another session is concurrently holding. The finding is real, so it is filed with its measurements rather than dropped.

Provenance

Raised by a peer session reviewing 977, which asked what the range evaluates to on a merge_group run and correctly named the failure mode as a silent pass, not a red. 977's stated posture was "if the merge-group run fails, that is the finding" — which covers the red case and not this one. The range turned out safe; the hazard it pointed at is real.

Checks

scripts/docs/backlog_status_check.py passes (680 items, one pre-existing advisory on #1426). All pre-commit hooks passed. No code touched, so no suite is implicated.

Expect a tail conflict with any other ledger append; it rebases for free.

🤖 Generated with Claude Code

[github-actions]

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

1. If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 978.
   That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
   before updating throws the label away and costs a round trip.
2. Read the diff.
3. gh pr edit 978 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.

Adding reviewed withdraws unread: the label event re-evaluates this pull request,
and so does the next completion of a watched workflow. Those are the two edges that clear it, so a
change neither of them reports -- converting to a draft, say -- can leave the label standing until one
of them next happens.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.

[github-actions]

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

1. If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 978.
   That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
   before updating throws the label away and costs a round trip.
2. Read the diff.
3. gh pr edit 978 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.

Adding reviewed withdraws unread: the label event re-evaluates this pull request,
and so does the next completion of a watched workflow. Those are the two edges that clear it, so a
change neither of them reports -- converting to a draft, say -- can leave the label standing until one
of them next happens.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.