ci(gates): re-run the commit-time gates in CI, which a replayed commit skips (BACKLOG #1395)

[wshallwshall]

What this does

BACKLOG #1395: git does not invoke the pre-commit hook for a commit created by the sequencer, so
a rebase or cherry-pick lands a commit with none of the eleven gates having run, and nothing
reports it.

Two things ship here.

1. The CI-side re-run, which is the fix the row itself prefers.
.github/workflows/precommit-replay.yml runs pre-commit run --from-ref --to-ref over the pull
request's diff. The row prefers this over the post-rewrite / pre-merge-commit pair it lists
second, because a local hook is advisory by construction and the row is the proof.

It skips exactly two of the eleven, and the rule is narrow: skip only where running it on a runner
gives a WRONG answer, not merely an inconvenient one.

skipped	why it would be wrong here	what still covers it
ledger-gate	its hook entry omits --ci, so the ownership arm reads an allocation registry in .git/mefor-coord/ that never reaches a runner. It would red every PR on a check no author can satisfy.	ci.yml runs ledger_check.py --ci (the duplicate-number half, which CI can enforce)
forbidden-content	fails closed on a git-ignored token file no runner has. Reproducing security.yml's fork/secret branching in a NON-REQUIRED leg would either red every fork PR or hand back a structural-only green that reads as a leak-gate pass.	security.yml's REQUIRED forbidden-content job scans the whole tree; branch-leak-scan.yml runs it on every push

Per the brief, the ownership arm stays CI-skipped and CI is not taught to read allocations.

2. The version axis, which the existing parity module does not reach.
_MIRRORS anchors on the invocation, so it proved the right tool ran with the right discriminating
flag and said nothing about which build. For the three third-party hooks that was held only by
prose comments saying to keep the versions in step, and a comment cannot fail.

hook	hook rev	what CI installs	now held by
gitleaks	v8.18.4	security.yml VER=8.18.4	test_the_hook_rev_matches_the_version_ci_installs
actionlint	v1.7.12	zizmor.yml VER=1.7.12	same
bandit	1.9.4	ci-scanners group bandit==1.9.4	test_bandit_hook_rev_matches_the_version_ci_installs (sibling file)

All four halves matched already. This closes the axis; it did not find a live drift. Each arm lives
with its own hook -- bandit in test_lint_scope_parity.py beside its scope arms, the other two in
test_gate_ci_mirror_parity.py -- so the two files cannot grow a second definition of one rule.

Read this before reviewing: a claim in the row was never true

The row ended a paragraph with "A PARITY TEST FOR THOSE EIGHT IS THE DURABLE FIX AND IS NOT
BUILT", and the 2026-09-03 scoring note repeats it. That was already false when written:
tests/test_gate_ci_mirror_parity.py covers exactly those eight and landed in 389168a79, the very
commit that filed the row.

So I did not rebuild it. Doing so would have produced a second, silently different definition of
one rule, which is the defect that family of tests exists to prevent. The sentence is corrected in
place -- a reader who reaches it decides whether to build that module -- and the correction is
recorded rather than the sentence quietly deleted.

This means the brief's second half was already done, and the scoring note over-counted the
remaining work.

What this does not buy

Stated so the row is not read as closure of the whole finding.

• It is late, in exactly the way the scoring note says. A push to this public repo publishes
  before any runner starts. This is defence in depth, not earliness.
• It does not inspect individual commits. --from-ref/--to-ref resolves a changed-file set
  against the checked-out tree, so content living only in an intermediate commit is out of reach --
  as it is for every tip-tree mirror.
• The ownership arm still has no enforcement path on a replayed commit, and cannot be given one.
• What it does buy: the nine hooks it runs cannot drift from CI, because they are the hooks.

Not a required status check

Deliberately. It builds every pinned hook environment per run and belongs off the critical path.
.github/required-contexts.txt and the pinned count in tests/test_required_contexts.py are
untouched, and a test asserts the job name is absent from that file. Promoting it would need branch
protection moved first, then that file, then the count -- and a merge_group: trigger before any of
it, or it never reports on a queue entry and nothing merges.

Checks

Every guard was mutation-tested, because an assertion that cannot fail is the failure mode this
item is about. Each mutation was verified to have actually applied before the result was believed --
one early control silently did not apply and would have recorded a false pass.

mutation	result
gitleaks rev moved to v8.18.5 against CI's 8.18.4	RED
bandit rev moved to 1.9.3 against the group's 1.9.4	RED
SKIP grows to include gitleaks	RED
SKIP carries a typo (forbiden-content)	RED
run step loses --from-ref while the header prose keeps it	RED
invocation neutered to a bare pre-commit run	RED
job name added to .github/required-contexts.txt	RED
all restored	GREEN

Ran, all green: ruff check ., ruff format --check ., mypy messagefoundry (strict, 267 files),
scripts/docs/backlog_status_check.py --min-items 300 (657 items, each declaring exactly one
status), and actionlint on the new workflow via pre-commit run actionlint. Also ran the
control-char, licence-header and gitleaks hooks over the changed files. All eleven hooks ran on
each of the three commits.

Skipped: the full pytest suite -- it will not finish inside one turn. Ran the workflow-census
batch instead: test_required_contexts, test_ci_venv_pinning, test_backlog_status_check,
test_merge_gate_controls, test_failure_signal, test_nightly_notice, test_dast_auth_sweep,
test_required_workflow_state, test_gate_liveness, test_lint_scope_parity,
test_gate_ci_mirror_parity, test_required_contexts_drift, test_security_posture,
test_quality_advisory_invariants, test_ci_docs_only_detector -- 310 passed, exit 0.

One caveat recorded rather than dropped: an earlier foreground run of a subset showed a single F.
It was running concurrently with the batch above against the same worktree. Re-run alone, those
files exit 0, and the batch that covers them passed 310. I am reporting the sequential result as the
real one, and naming the concurrent run so nobody re-derives the discrepancy.

Also verified the new job name is unique across all 28 workflows and carries no ${{ }} template,
so it cannot silently re-map an existing required context (tests/_workflow_contexts.py keys jobs by
declared name across every file). Everything added is pure ASCII, checked with a positive control.

tests/test_workflow_shell_syntax.py times out locally on Windows -- it spawns bash -n per run
block. This is pre-existing: it timed out identically with my workflow moved aside, so it is not
caused by this change. I checked my three run blocks directly instead and all three parse under
bash -n. It should be read on the Linux runner.

Only a hosted runner can report: windows-service-smoke, the server-DB store legs, the load
legs, codeql, scorecard, semgrep, and the new pre-commit replay leg itself -- this is its
first execution anywhere. The pre-commit==4.6.1 pin is version-pinned but not hash-pinned (it is in
no dependency group); 4.6.1 is the version this machine has installed and the version the repo's own
comments record measuring against, so the pin is real rather than guessed. Routing it through
ci/locks/ is the correct end state and needs a uv lock/uv export pass.

Two things for the coordinator

1. I did not apply the reviewed label. A message arrived mid-task stating an owner override
suspending the reviewer process and instructing me to self-label. I cannot verify an owner ruling
relayed by a peer agent, my brief said not to, and CLAUDE.md states plainly that labelling your own
PR unread "satisfies the machine and defeats the point" -- this one context is the repository's
entire review requirement, with approvals pinned at 0. The technical half of that message was
correct and useful (a push strips the label; gh pr update-branch is a push). If the ruling is real,
whoever holds that authority can apply the label directly; I have left it clean rather than spend it.

2. A shared-scratchpad collision nearly put another item's subject on this commit. The session
scratchpad under AppData\Local\Temp\claude\...\<session-id>\scratchpad is shared across
sessions despite the session id in the path. A peer session overwrote msg1.txt with its own
commit message for BACKLOG #1414 between my write and my git commit -F. The claim gate caught
it -- it refused because #1414 is not claimed by this worktree -- which is the gate doing exactly its
job on a defect nothing else would have surfaced. Commit messages here are now written inside the
worktree. Worth a row: a generic filename in a shared temp directory is a live cross-session hazard.

🤖 Generated with Claude Code

[wshallwshall]

LANDER: applying reviewed under an explicit owner override. The owner has suspended the reviewer process and directed that this label be applied as needed to clear the gate.

SO READ THIS LABEL AS A BYPASS TOKEN, NOT A REVIEW. It records that the gate was cleared by instruction. It does not assert that anyone read this diff, and no later reader should infer one from it.

What I can say: this PR appeared in a read-only pre-verification sweep of all 59 non-draft open PRs (per-PR defect read, plus pairwise git merge-tree against every PR sharing a non-BACKLOG file), and no blocking defect was recorded against it. That sweep did not run any tests, and CI has been down for hours, so nothing here has a current green.

-- Lander