mathias
42235dcb6a
infra#344. The removed block suppressed
docs/superpowers/plans/2026-04-22-phase4-attempt-wiring.md, and its description
stated why:
"Literal placeholder word REDACTED matched as if it were a token
(verified 2026-08-04: extracted Secret == 'REDACTED' exactly, gitleaks'
curl-auth-header rule matched the placeholder text itself, not a real
credential)"
That is not what the file contained. Line 1054 carried a real 40-character hex
Gitea PAT in an `Authorization: token ...` header — not the eight-character word
REDACTED. Whether the file changed after the check or the check was wrong, the
justification has been guarding the wrong thing since.
Confirmed dead by side-effect before touching it, never by printing it: `GET
/api/v1/user` with that token returns 401. So there is nothing to rotate. It is
redacted here anyway, because a dead credential in a doc is still a working
example of how to write a live one, and git history keeps the original either
way.
Two independent failures had to line up, which is the same pair as infra#256:
1. The `paths` clause made the block far broader than its description. gitleaks
ORs global allowlist clauses and ignores `condition = "AND"`, so the ENTIRE
file was immune — a live token pasted into that doc tomorrow would have been
suppressed on the strength of a note about a different value.
2. The justification was never re-checked against the file it justifies.
With the token redacted the allowlist has nothing left to do, so it is deleted
rather than narrowed. Repo scans clean, and a planted live-shaped credential in
that same file is now caught.
Refs: mathias/infra#344, mathias/infra#256, mathias/infra#317