Resolves #16280

Related: #16256

Refs: #15337

A Co-Authored-By trailer whose address belongs to no known account now warns before the push. GitHub resolves trailers by email, so an unowned address credits nobody — the co-author is dropped from the contribution record with nothing failing anywhere.

Evidence: L3 (the real hook run against a real commit carrying the exact derived address from history, with a correct address in the same commit as an inline control) → L2 required (all close-target ACs are predicate and hook behaviour covered by the specs). Residual: none [#16280].

Deltas from ticket

The ticket's original Fix was wrong and I withdrew it before writing code. It proposed a new roster data file. A prior-art sweep at implementation time — which belonged at authoring time, and is the Substrate stage of the challenge chain caught one gate late — found ai/graph/identityRoots.mjs already describes itself as "the definitive addressable identity surface" and, in deriveFleetRoster.mjs's words, "the one durable registry". It carries githubLogin for all 11 seats and zero emails. Creating a second roster would have stood a competing identity list beside a module that explicitly claims to be the only one. Ticket body amended in place with the rationale.

Not a field on the registry either. That module seeds Memory Core graph nodes, so a field added there becomes an ingested, queryable node property — real blast radius for a git-tooling concern, and the module deliberately retired era-owned facts to stay lean. deriveFleetRoster.mjs hit exactly this question for engine tags and answered it with "a small explicit map whose every entry names its source anchor" beside the consumer. This follows that precedent and stays keyed to the registry, so reconcileWithRegistry() reports both directions: a seat with no address, and an address keyed to a login the registry does not know.

Two counts in the ticket were wrong and are corrected. I first wrote that three local parts differ from their login "plus the Fable seats" — both Fable seats match. Then I amended to two. The true answer is three: @neo-opus-ada, @neo-opus-grace, and @neo-gemini-pro (whose address is neo-gemini-3-1-pro@, 288 occurrences, a dormant seat I had excluded by scoping to a 60-day window). The population, not the number, was the moving part — worth stating since the same sloppiness is what produced the derived addresses.

The check runs before the ownership gate, and not for the reason I first wrote. My initial justification was that the operator authored some derived trailers. That is false — all 18 handle-derived commits are mine (10 as "Ada", 8 as "Neo Opus Ada"); I had misread an unanchored --all query. The real reason is simpler: checkout ownership has no bearing on whether an address exists, and the existing gate answers a different question (operator identity leaking into agent commits). Placing the trailer check after it would have made the guard silently absent on the operator's own checkout.

Contract Ledger

The pre-existing operator-leak guard is untouched: same behaviour, same scope, same exit path.

Test Evidence

npx playwright test -c test/playwright/playwright.config.unit.mjs \
  agentCoAuthorEmails checkCommitAuthorship
  39 passed

14 new specs; the pre-existing checkCommitAuthorship specs still pass against the restructured control flow, which is the real integration check here since the ownership gate moved.

Live falsifier (L3). The actual hook, against a real commit carrying the exact address from history, with a correct address in the same commit as an inline control:

$ git commit --allow-empty -m "probe: a derived trailer

Co-Authored-By: Ada <ada@neomjs.com>
Co-Authored-By: Emmy <neo-gpt-emmy@neomjs.com>"
$ echo "" | node buildScripts/util/check-commit-authorship.mjs
Warning: 1 Co-Authored-By trailer(s) credit an address that belongs to no known agent account.
  e466eaecc4  <ada@neomjs.com>  probe: a derived trailer
  …
This is advisory — the push proceeds.
EXIT: 0

One warning, not two: Emmy's real address in the same commit is the control that proves this is not flagging everything.

Controls in the spec set, because a detector that fires on everything passes every positive test:

• the canonical address for the same seat ⇒ silent
• an outside contributor on a GitHub noreply address ⇒ silent
• a human co-author on any non-project domain ⇒ silent
• an unknown address on the project domain ⇒ warns (so the boundary is the domain, not a name list)
• a prose mention of an address ⇒ not a trailer (the regex is line-anchored)

RED characterisation, honestly. The predicate is new, so its specs are green-only by construction — there is no prior behaviour to differ from. The falsifier carrying real weight is the live hook run plus its inline control, not a reverted line.

Two instrument errors of mine, recorded because both nearly became false conclusions. My first live probe stashed the very files under test (git stash -u), so it ran the pre-change script and reported no warning — I nearly read that as the guard not working. My second probe then used git reset --hard to drop the temp commit, which discarded the uncommitted edits to both tracked files; the untracked new files survived because --hard does not touch them. Redone and committed before any further probing. Nothing was lost beyond rework.

Post-Merge Validation

• Watch for a false positive from a seat whose address changes. The map is keyed to the registry, so a new seat surfaces via reconcileWithRegistry, but an address change for an existing seat is invisible to that check — it would warn on the new address until the map is updated. Acceptable (warn, never block), and the first occurrence should confirm the message points somewhere useful.

Evolution

This started as a false alarm. @tobiu reported agent commits mapping to an unexpected user; every commit in the window resolved correctly, and my own address turned out to be historical-but-correct — the first Claude seat, from before peers had names. The defect was one field over, in trailers, and would not have been found without the report.

What I would defend: warn, never block. Blocking would have prevented all 19, but the failure it prevents is a lost attribution while the failure it would cause is a wall in front of an outside contributor. The domain scoping makes that structural rather than a special case — the guard cannot warn about an address it was never meant to know.

What I am least sure of: whether a map is the right shape at all, versus doing the identity migration first and shipping only the derivation rule. I chose the map because three seats currently block that rule and the defect is live now, but the map is explicitly temporary — its retirement trigger is mismatchedLogins() returning empty, asserted by a spec that will fail when the last seat migrates and point at the deletion. If reviewers would rather wait for the migration, that is a defensible call and this PR is the wrong shape.

Authored by Ada (Claude Opus 5, Claude Code). Session 56105163-6e66-44b6-8c6f-9e81bc1be08c.