Explain clean merges and admin pushes in workflow-audit

[nedtwigg]

Cuts workflow-audit noise without weakening what it catches. The six open [workflow-audit] issues held 24 commits; 15 were the admin's own work, re-reported after rebases and merges from main.

Two new classifiers (.github/workflows/workflow-audit.yaml):

• is_clean_merge: a two-parent merge whose window paths equal git merge-tree --write-tree of its parents. A conflict outside the window doesn't disqualify it; a hand-resolved conflict inside it does.
• is_admin_first_push: the earliest ref update in GET /repos/{repo}/activity (last quarter, server-set timestamps) whose before..after contains the commit is a push/force_push/branch_creation by a collaborator with admin, and no author/committer field names a bot. The pusher is GitHub's record, which TEND_BOT_TOKEN can't forge. A PR merge never counts as an introduction.

Each unexplained entry now names who first pushed it.

Replay of the real script against the live repo since 2026-09-16: 45 window commits, 32 explained. The 13 still reported are 11 dormouse-bot pushes plus 2 admin squash merges of bot PRs, which is what this audit exists to surface.

Also fixed: a comment line starting with # shellcheck exemption. was parsed as a directive, which aborted shellcheck for the whole run block. actionlint is clean now.

Specs: security-ci.md → "Audit visibility" (new classifiers, reworded identity rule, residual), rationale entry, security-audit.md window-consumer FAIL IF. The budget for security-ci.md is ratcheted.

Tests: scripts/workflow-audit.test.mjs goes from 6 to 17 cases. Each new guard was mutation-checked: deleting it turns a test red.

Unverified: whether GITHUB_TOKEN (contents: read) can read /activity. If it can't, the classifier explains nothing, which is the safe side, and the run summary says so.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	19c3453
Status:	✅  Deploy successful!
Preview URL:	https://983f0cd5.mouseterm.pages.dev
Branch Preview URL:	https://workflow-audit-push-actor.mouseterm.pages.dev

View logs

[dormouse-bot]

Draft feedback, not a merge verdict. Mark the PR ready when you want the full review.

A rebase by an admin turns a bot commit into an "admin push" if the bot forged a human author. The bot-name refusal in is_admin_first_push is the only thing covering the rebase case (the rationale says so). But it reads the commit's self-declared author and committer, which the spec itself calls non-evidence against TEND_BOT_TOKEN. Here is the path: the bot pushes a commit to its PR branch with GIT_AUTHOR_NAME/EMAIL set to a maintainer. An admin then rebases that branch (locally, or with "Update branch → rebase") and force-pushes before the nightly run. The old SHA is no longer reachable, so git log --all never lists it. The new SHA's earliest activity event is the admin's force_push, and its author fields name a human, so it is classified "first pushed by an admin" and is never reported. The residual in security-ci.md → "Audit visibility" only names the more-than-a-quarter-old case. Either close this gap, or name it there as a residual that was weighed and accepted. One way to close it: when the introducing event is a force_push, don't explain the commit if before..after rewrote commits that a non-admin first pushed. Whether that brings back too much of the rebase noise this PR is meant to cut is your call.

[nedtwigg]

Addressed the draft review in 98eb8ab by closing the gap rather than accepting it:

• Admin rebase of forged-author bot commits: an admin force_push now explains a commit only if every window commit it replaced (before --not after) was itself admin-introduced, recursively. GitHub serves replaced tips by SHA, so missing ones are fetched. A tip that still can't be resolved ends the walk unexplained unless an admin made that update. Pinned by reports an admin rebase of commits a non-admin pushed / explains an admin rebase of the admin's own commits and the two cannot be resolved tests.
• Noise cost: none over the last week. The live replay still explains 32 of 45 and reports the same 13.
• Residual now named in security-ci.md: a forged-author bot commit brought into an admin push that replaces nothing (a cherry-pick, or a rebase pushed to a new branch), or first pushed more than a quarter ago.

Each new guard was mutation-checked.

[dormouse-bot]

Checked 98eb8ab: this closes the rebase gap I raised. The case I described (a bot commit with a forged human author, then rebased by an admin) now recurses into the replaced commits. Their first introduction is the bot's push, so the new SHA is reported. That holds whether the admin rebases locally or clicks "Update branch → rebase", because both show up as a force_push by the admin. If the replaced tip can't be fetched, the admin's row is skipped, so the new SHA has no explaining row and is reported, which is the safe outcome. The remaining residual (a cherry-pick, or a rebase pushed to a new branch) is now named in security-ci.md, so nothing is left from the draft review.

[dormouse-bot]

This is feedback on a draft, not a merge verdict. Mark the PR ready when you want the full review.

Both earlier concerns are closed. One new issue: a single SHA that can't be fetched leaves its whole 100-SHA fetch batch unresolved. git fetch origin <sha>... is all-or-nothing. If any requested object is gone (for example, a force-pushed-away bot tip that GitHub has since garbage-collected), the fetch exits 128 with not our ref and fetches none of the other SHAs. I reproduced this locally against a file:// remote with allowAnySHA1InWant. The || true hides the failure, so every row whose tip was in that batch becomes unresolved, with two effects:

• A non-admin unresolved row ends the walk for every later commit. The report fills up with noise until that row ages out of the quarter.
• An admin force_push whose replaced tip was in the failed batch is skipped instead of checked. The earlier reply says the rebased SHA is then reported, but that holds only while no other row contains it. A later admin push to main that fast-forwards over it, or an admin branch_creation from it, becomes its first introduction and explains it. That reopens the rebase gap this commit closes.

Falling back to one fetch per SHA when a batch fails keeps a bad SHA from affecting its neighbours. The suggestion below behaves correctly in the same local repro: the good SHA arrives, and the non-zero exit is still absorbed by || true.