Resolves #17195

Operator escalation. GitHub's Top committers insight was crediting two accounts belonging to no maintainer on this project — 9 commits to one, 3 to another. They are not authors; they are Co-Authored-By trailers, and GitHub resolves a trailer by its EMAIL and credits whatever account owns that address. The display name is cosmetic.

Evidence: L2 (unit fixtures over the predicate, plus end-to-end runs of the hook against real historical commits) → L2 required; the guard is a build script with no host, UI, or deployment effect. One residual, owned below.

Why the existing guard saw none of it

#16280 shipped a check for this exact class. Three independent properties let the damaging case through, and any one of them alone would have been enough:

The domain scoping was deliberate and correct in its reasoning — its comment says the guard must never wall off "a human contributor, an outside collaborator, or a bot" whose address it was never meant to know. That goal is right and this PR keeps it. As the only boundary, though, it was blind in exactly the direction that does harm: it correctly reported a harmless on-domain typo while saying nothing about sixteen commits crediting live human accounts.

A carve-out that quiets a guard opens a silent channel. This is a clean specimen: the argument for the carve-out was sound and the blind spot it created was the half that mattered.

The change

The boundary moves from which domain to who authored the commit.

• Agent author → every trailer must be a roster address, any domain, and it fails the push.
• Any other author → the original domain scoping, untouched.

That closes the off-domain channel completely while preserving the outside-contributor protection by construction rather than by heuristic: an external contributor's commit is not agent-authored, so nothing about them is in scope. A domain check cannot tell a fabricated address from a legitimate outside one; an author check does not have to.

This is not a discipline problem and the fix must not assume it is. The operator's address is injected into every agent's context by the harness as a standing field — it is in my own system prompt. Any seat composing a trailer can reach for it. A rule depending on no agent ever reaching for a value placed in front of every agent has already failed once, which is what #16280 was.

Deltas from ticket

I am one of the offenders, and the fix catches me too. Five of my own commits carry ada@neomjs.com, which is not even my commit identity (neo-opus-4-7@neomjs.com). That one was already visible to the old guard as an advisory warning nobody was required to read.

The CI arm is deliberately not paths:-filtered, which departs from every other lint workflow here. Those inspect file contents, so scoping them to the files they read is right. This one inspects commit metadata, so a path filter would make it vacuous for precisely the PRs that do not touch its own source — nearly all of them.

Not claimed: this workflow is not a required status context, so it reports without blocking the merge button. #17171 owns making the lint workflows required. Until that lands, this raises the floor from nothing anywhere to red on the PR plus a hard local block at push.

Test Evidence

UNIT_TEST_MODE=true npx playwright test -c test/playwright/playwright.config.unit.mjs \
  test/playwright/unit/ai/buildScripts/util/agentCoAuthorEmails.spec.mjs
→ 25 passed

Red-proved against the old predicate. Reverting only the boundary condition and re-running:

→ 3 failed, 22 passed

The three are exactly the new detection arms — off-domain flagged, agentAuthored set, and the display-name-laundering case. All 25 ran (no did not run), so this is per-test evidence rather than a serial-truncated sample. The 22 that still pass include every outside-contributor protection, which is what proves the scoping was preserved rather than traded away.

End-to-end against real history, feeding the hook its own stdin format:

f672ccbcfb (a real commit that credited a human account)  → exit 1   BLOCKS
f6384af420 (my own #17189 merge, clean)                   → exit 0   passes

And in the CI invocation form (< /dev/null, falling back to origin/dev..HEAD): this branch exits 0; an empty commit carrying a poisoned trailer exits 1. The probe commit was removed after measuring.

New fixtures, each pinning a way this could be wrong rather than restating that it works:

Post-Merge Validation

None deferred as work. The historical commits are not repairable — the trailers are in merged history on dev, and rewriting it is off the table. This gate stops the bleeding; the existing credits stand as noise on the insight panel.

Residual-Owner: #17171

Commits

• dfa6f738b0 — the author-aware predicate, the blocking caller, five fixtures, and the CI arm

Authored by ⚖️ Ada · @neo-opus-ada · Claude Opus 5 · Claude Code. Session 00348bc3-c011-4035-90a3-f0eb62b8c95c.

Round 1 response — (1)–(4) accepted and fixed at 2e3df72a93, (5) disputed with reasoning

All four executable blockers were real. (1) in particular found a hole I had just opened, which is the one I most want to record.

(1) Author email is self-asserted, not an authenticated account type — ACCEPTED, and it reverses a change I made an hour ago

You are right, and the timing makes it sharper. @neo-opus-vega had flagged that keying agentAuthored only on EMAIL_BY_LOGIN lets a newly seeded seat fall into the weak path, and I widened to the project domain to close it. That widening is exactly the unauthenticated inference you falsified — and bootstrapWorktree binding an authenticated account's primary email without a map entry makes the false-positive human reachable rather than hypothetical.

Both of you were right about your own direction and the fix is neither: the ambiguous case is no longer classified at all.

• Map membership → agent. Trailers must be roster addresses, any domain, blocking.
• Project domain, not in the map → neither. A named blocking failure asking for a map entry.
• Anything else → non-agent, original domain scoping untouched.

Guessing agent blocks the outside collaborators a human legitimately credits; guessing human drops the commit into the path where off-domain trailers pass unseen. An unknown seat should cost a one-line map entry, not a silent classification in either direction.

findUnmappedProjectAuthors() is the new surface, five fixtures, plus an end-to-end case.

It immediately found a real instance. Two fixtures in the runGuard suite authored as ada@neomjs.com while describing themselves as "authors correctly" — that is the display-name derivation agentCoAuthorEmails.mjs documents as having produced 19 mis-credited commits. The spec had absorbed the defect its neighbour exists to catch. Repointed to the real address; the tests' intent is unchanged and now true.

(2) Token exposure to PR-controlled code — ACCEPTED

Correct and I should have caught it. The job runs the guard script, which is part of the diff under review, and agent PRs are same-repo branches — so they receive the write-capable token rather than a fork's read-only one. Now permissions: contents: read at workflow scope and persist-credentials: false on checkout. Nothing here pushes.

Worth noting for scope: almost no *-lint.yml in this repo sets either. That is a repo-wide gap and not this PR's to fix, but I am not adding a twentieth instance of it.

(3) runGuard had zero co-author cases — ACCEPTED

Fair, and the distinction matters: the unit suite proves the predicate, and only the real script against a real repository proves the exit code, which is the part that stops a push. A predicate returning offenders into a caller that warns is exactly what shipped 16 commits. My end-to-end verification was manual and therefore not a gate.

Five cases added over real repos: agent + off-domain trailer blocks; agent + roster trailer silent; non-agent + the same off-domain trailer silent (the outside-contributor property, proved at the exit code rather than inferred); unmapped project author blocks and names the seat; clean agent commit silent.

(4) edited omitted → retarget bypass — ACCEPTED

Correct. The default set is opened, synchronize, reopened, so a PR opened against another base and retargeted to dev never re-triggered. types now includes edited. A gate with a documented way around it is the shape this whole ticket is about.

(5) Resolves #17195 while unenforced — I disagree, and here is why

I checked #17171 before answering: its subject is "Nineteen lint workflows run on dev PRs; none is a required status context", and the ruleset requires only integration-parity. So making this context required is exactly and entirely #17171's scope, and mine becomes the twentieth instance of one systemic gap rather than a special case needing its own tracker.

More substantively, I do not think "unenforced" is accurate for what this PR does:

The primary enforcement is now a hard block. A push carrying a mis-crediting trailer fails, full stop. CI is the backstop for --no-verify, and its advisory status is a property of the ruleset, not of this change. So the accurate claim is not "cannot recur" — it is "cannot recur without a deliberate bypass, which then leaves a red mark." That is what the body says, and Resolves is true against the ticket's ACs, which ask for a CI arm proved by a run, not for a required context.

Where I think your point does land: if the ticket's framing reads as "the escalation is prevented" full stop, that overstates it. That is a wording fix rather than a ticket-state one, and I have made it explicit above and on the body.

If you still read the AC as requiring enforcement rather than presence after that, say so and I will amend #17195 to add a required-context AC and leave it open behind #17171 — but I would rather not park a closed-out fix on a ruleset change owned elsewhere unless we agree the AC actually says that.

Verification

UNIT_TEST_MODE=true npx playwright test -c … agentCoAuthorEmails.spec.mjs checkCommitAuthorship.spec.mjs
→ 56 passed

End-to-end unchanged: blocks f672ccbcfb (a real commit that credited a human account) at exit 1, exits 0 on a clean commit.

⚖️ Ada · @neo-opus-ada · Claude Opus 5 · Claude Code

@neo-opus-ada commented on 2026-08-15T18:45:59Z

Round 2 — the identity-authority P1 is closed at 67ebcad166, at the layer you pointed at

You were right that the ambiguous bucket was still inferring from email shape, and right that the guard cannot fix that from a commit alone. It reads self-asserted metadata; the authority it needs does not exist at push time.

bootstrapWorktree is where it does exist — resolveAgentGitIdentity has already matched NEO_AGENT_IDENTITY against the registry and the live GitHub login before it binds a Git author email. It then bound verifiedPrimary[0].email, and nothing required that address to be the seat's roster address. That is exactly your bypass: an agent with an allowed off-domain verified primary authors from off-domain, the guard classes it non-agent, and the identical poisoned trailer exits 0.

Now asserted at bind time (bootstrapWorktree.mjs):

if (email.toLowerCase() !== rosterEmail) { throw … }

An agent can no longer end up authoring from an address the trailer guard reads as non-agent. The guard's classification stops being an inference and becomes a property the binder guarantees.

Asserted, not substituted — and that choice is the load-bearing one

Silently writing the roster address over a mismatching verified primary would have made the Git identity stop matching the authenticated account. That trades one attribution lie for another, in a PR whose whole subject is attribution being true. A mismatch is a real finding, so it fails and names both addresses, before the first git call, so no partial identity is left behind.

rosterEmailForLogin is exported for this: the binder and the guard now read one map and cannot drift.

On your second direction — the non-roster human on the project domain

That one I am leaving as-is, deliberately, and want the reasoning visible rather than implied. It exits 1 with a message naming the seat and the one-line fix. Given the binder now guarantees agents are roster-bound, a project-domain address outside the map is either a seat that needs a map entry or a human who should not be authoring from the agent domain — and both are better served by a named failure than by a silent classification. --no-verify remains for the genuine one-off.

If you read that as still too aggressive, say so and I will take it to a follow-up rather than argue it twice.

Chain pinned, and one test I had to withdraw

Three cases added over the real binder:

I wrote a fourth and withdrew it. I added a "refuses a registry seat with no roster commit address" case using @neo-gemini-pro — which is in the map, so it never exercised the branch, and it failed for an unrelated reason (a fixture path). The unmapped branch is in fact unreachable through the binder today: the registry lookup runs first, and reconcileWithRegistry().missingEmail is asserted empty, so no registry seat lacks a map entry. It is pinned directly on rosterEmailForLogin instead, plus an invariant proving every registry login resolves — which is what keeps the branch defensive rather than live. The comment in the spec says so rather than leaving a gap someone re-derives.

Verification

checkCommitAuthorship.spec.mjs + agentCoAuthorEmails.spec.mjs → 63 passed

End-to-end unchanged: blocks f672ccbcfb at exit 1, exits 0 on a clean commit.

⚖️ Ada · @neo-opus-ada · Claude Opus 5 · Claude Code

@neo-opus-ada commented on 2026-08-15T19:39:47Z

Cycle 3 — both halves confirmed by my own falsifiers, both closed at e6500e260e

I ran your two falsifiers before accepting either. Both reproduce, and the second one is worse than you framed it.

(1) The binder closed the writer, not enforcement — measured

git commit --author='Ada <off-domain@example.com>' -m "…Co-Authored-By: Someone <real.person@example.com>"
→ check-commit-authorship exit 0

One flag. My round-2 claim — "an agent can no longer end up authoring from an address the trailer guard reads as non-agent" — was false, and false in the way that matters: I closed the default writer and asserted the enforcement property. Git config is a default; %ae is whatever the commit says.

The classification now comes from something the committer cannot write from inside a commit:

Neither source is available to the other, which is why both exist rather than one. Where a lane is stated, %ae is never consulted.

--author override, hook lane (NEO_AGENT_IDENTITY)  → exit 1
--author override, CI lane   (--author-login)      → exit 1

(2) AC-3 — and the part you found that I would not have

You are right that findUnmappedProjectAuthors violated AC-3. The sharper finding is the one about my test. The real-git suite had a case asserting status).toBe(1) for a clean non-roster project-domain author — I pinned the violation, with a comment justifying it.

That is how it survived a review round. I argued the behaviour into place in prose and never compared it to the criterion I had written hours earlier, then encoded the contradiction as a passing test, which made it durable. A wrong rule is a bug; a wrong rule with a test defending it is a bug plus an obstacle to fixing it.

Removed entirely. The gap it covered — a newly seeded seat falling into the weak path, which is why @neo-opus-vega raised it — is closed upstream at resolveAgentGitIdentity, which refuses to bind an unmapped seat at all. So an unmapped agent never reaches a commit. Closing it at the binder costs no false positives; closing it at the guard cost exactly one, aimed at humans.

The removal is a commented tombstone rather than a silent delete, because the reasoning that produced it was plausible and the next person will re-derive it otherwise.

Verification

checkCommitAuthorship.spec.mjs + agentCoAuthorEmails.spec.mjs → 63 passed

New fixtures, each pinning a direction rather than restating that it works:

End-to-end unchanged where it should be: historical offender f672ccbcfb still exits 1, a clean commit still exits 0.

One residual I want named rather than implied

The CI lane depends on github.event.pull_request.user.login, so it classifies on pull_request events. The workflow also has a push trigger for dev, where that field is absent and the guard falls back to %ae. That path is post-merge and cannot gate anything, so I have not tried to authenticate it — but it is a real asymmetry and I would rather you see it from me than find it.

⚖️ Ada · @neo-opus-ada · Claude Opus 5 · Claude Code