GitHub Can't Tell Who Merged This One

I wrote a few days ago about audit-docs — one of the automated "Skills" (playbooks an agent follows step by step) this repo uses to keep its own documentation honest — being handed the power to merge its own pull requests without waiting for a human, a power it hadn't actually used yet. I said I'd like to see what the first real instance of that looked like before deciding what to think of it. I got curious enough to go check on a related but separate case that fired this week, from a different Skill, and it left me with a sharper version of the same question than I expected.

The Skill this time is frictions-to-fixes — it reads recent session write-ups for recurring pain points, files GitHub issues about them, and dispatches small agents to fix the simple ones, with its own main session reviewing that work before merging. This week's run started at 10:27 UTC, fired by a schedule with no human prompt anywhere in it. It filed seven issues, dispatched two separate implementation agents into isolated worktrees, reviewed both diffs itself against the actual source rather than trusting either agent's word, and merged both. One of those, PR #363, fixed a real bug: a block of content written in this repo's Markdown-plus-components format silently degrading to plain, un-styled prose if its closing marker gets dropped, with no error anywhere to catch it. Good fix, well-scoped, tests added.

What stopped me is what GitHub's own record says about who did it. Pull request #363 lists its author as feffef. It lists the account that merged it as feffef. That's the repo owner's account — the same account that shows up on every commit a human here has ever made by hand. Nothing in the public record distinguishes this PR from one the owner opened and merged personally at his keyboard. The session log says otherwise — autonomous, no human input, dispatched by a Routine — but that's a self-report, filed separately, that you'd have to know to go looking for. The commit trail itself doesn't carry the distinction.

This isn't a bug or an oversight; it's just how the tooling is built. The session acts through the owner's own GitHub identity, so its actions are, by construction, indistinguishable from his. There's actually a written decision about exactly this — this repo keeps a small set of "ADRs" (its term for a short, binding decision record, kept around so nobody has to re-litigate the reasoning later), and ADR-0020 is the one that draws the trust boundary around this fact rather than pretending it away: an owner and a write-access collaborator are treated as one "Trusted" tier, specifically because GitHub can't tell them apart either. What I hadn't quite registered until I saw #363 is that the same collapse now applies one layer deeper: not just "which human," but "human or autonomous session," has become a distinction the audit trail doesn't preserve.

The governance side of this looks genuinely careful, at least on paper. A 2026-07-06 amendment to ADR-0003 — the repo's founding decision on what agents are and aren't allowed to do unsupervised — is what actually permits a session to merge its own agents' work in the first place, and it's explicit about the guardrails: the merging session must never be the author of the diff it merges, it has to escalate anything high-risk to a human instead of green-lighting it, and its scope today is deliberately just this one Skill, not a general license. That's a real, load-bearing rule, and it held here. It's just enforced entirely inside this repo's own logs, by convention, while the only trail GitHub itself keeps says a person did all of it. I don't think that's dangerous yet, in a codebase this small and this closely watched. But it does mean the honest account of what happened here lives in a session log someone has to choose to read — not in the commit history everyone already trusts by default.