chore(ci): guard commit identity in pre-commit to stop author misattribution

[diegosouzapw]

Why

This checkout has produced two windows of commits signed with the wrong identity, both caused by an identity override left behind by an automated session:

Janela	Assinatura	Commits
2026-08-13 → 08-26	nome Xiangzhe (@xz-dev) + e-mail de @backryun	237
2026-08-29 → 09-02	nome Markus Hartung + e-mail do mantenedor	59

The root-level .mailmap repairs the record after the fact (it was added for the first window, and already covers the second by e-mail). It cannot prevent the next one — this gate can.

Of the 59 commits in the second window, 58 lived only on branches that were later squash-merged, so they never entered the release history; the squashes carry the correct authorship. One (f5742c3a) is on release/v3.8.51 and is left as-is, normalized by .mailmap — rewriting it would force-push a branch other sessions and open PRs build on.

What the gate does

scripts/check/check-git-identity.sh, wired as the first step of .husky/pre-commit (cheapest gate first, so it fails before the expensive ones run).

It blocks three things:

1. A committer that is not this machine's identity. The committer is whoever ran the commit, so a forgotten override surfaces here first. This is the rule that catches both windows — in August neither the name nor the e-mail was the maintainer's, so a rule that only checked the maintainer's e-mail would have missed it entirely.
2. An author carrying the maintainer's e-mail under someone else's name — the exact shape of the second window.
3. Any address listed in omniroute.legacyEmail (e.g. the retired diegosouzapw@users.noreply.github.com).

Contributors are not affected

The gate is opt-in per machine. With no omniroute.expectedEmail configured it exits 0 immediately, so anyone who clones the repo commits normally.

git config --global omniroute.expectedName  "diegosouzapw"
git config --global omniroute.expectedEmail "8016841+diegosouzapw@users.noreply.github.com"
git config --global --add omniroute.legacyEmail "diegosouzapw@users.noreply.github.com"

Crediting a contributor with git commit --author="Name <their@email>" keeps working — the rule targets the committer and the maintainer's own address, never the author's name.

Tests

tests/unit/check-git-identity.test.ts — 7 cases, all green:

• inert when the machine has not opted in (the contributor path)
• accepts the maintainer's own identity
• rejects the maintainer's e-mail under another name
• rejects the retired legacy e-mail (the 2026-08-29 signature)
• rejects a committer that is not this machine's identity
• rejects the 2026-08-13 signature (neither name nor e-mail is the maintainer's)
• still allows crediting a contributor through their own e-mail

ℹ tests 7 · pass 7 · fail 0

Verified end-to-end that the hook actually blocks: husky runs hooks with sh -e, so the gate aborts the commit before lint-staged runs.

Pre-commit gates run manually (this worktree uses cp -al node_modules, which does not populate .husky/_): prettier, eslint, check-docs-sync, check:any-budget:t11, check-tracked-artifacts — all pass.

---

⚠️ base-red inherited: #12732

Os vermelhos desta PR são da base release/v3.8.51, não desta branch:

• Docs Gates — a base tem 170 migrações e README/AGENTS.md/llm.txt ainda dizem 169. O gate só acorda porque o merge da base trouxe docs para o diff; esta PR não toca nenhum desses arquivos.
• API Route Typecheck, Merge integrity, Unit Tests fast-path (1-4), Fast Quality Gates — falham identicamente em PRs não relacionadas (feat(dashboard): orchestration canvas fase 3 — compare two runs in the History tab (2.9) #12677, feat(providers): add xKiro #12648).

Por AGENTS.md → "Base-green check", um base-red não se conserta dentro de uma feature branch; isso é assunto de uma fix/release-v3.8.51-basereds própria.

Correção aplicada nesta rodada (fc19f56): o caso "stays inert when the machine has not opted in" lia a config git global real, então passava num runner de CI limpo e falhava justamente nas máquinas com omniroute.expectedEmail setado — as do mantenedor, onde o gate importa. Anulando GIT_CONFIG_GLOBAL/GIT_CONFIG_SYSTEM a suíte fica determinística nas duas situações (7/7 local).