[BUG] the commit-msg AI-attribution patterns match any word containing "ai", so they refuse legitimate commits - and a guard that refuses correct work is the guard that gets disabled

[oberstet]

What happened

.ai/.githooks/commit-msg rejected this line in an ordinary commit message:

The audit file: `.audit/<user>_<branch>.md`, generated by `.ai/justfile` and
committed as the first commit of every dev branch by `just new-branch`.

with:

ERROR: Commit rejected - violates the project's AI_POLICY.md
The commit message contains AI authorship attribution which is prohibited.

There is no authorship attribution in that sentence. It describes which tool
produces a file.

Why

grep -i -E "(authored by|co-authored by|generated by).*(claude|gemini|copilot|ai|artificial intelligence)"

The ai alternative is a bare, unanchored substring. After generated by, the
.* will reach any later ai anywhere in the message - including inside an
ordinary word. All of these are rejected today:

message fragment	why it matches
generated by `.ai/justfile`	the literal path
generated by the maintainer	maintainer
generated by an available script	available
generated by the certificate chain	chain
generated by the CI pipeline, details above	details

Pattern 3 has the same defect: (generated with|created with|built with|made with).*(claude|gemini|copilot|ai).

Pattern 2 is fine - it requires a trailer key first, and the alternation is
applied to a line already matched as ...-by:.

Why this matters more than a nuisance

A guard that refuses correct work is the guard that gets switched off.

That is not a hypothesis here. aaiare-metal-typedefint#58 records a clone of
system-and-software-assurance found running with
core.hooksPath = /dev/null - the exact value this hook's own error message
tells a human to set - with the re-arming step never performed. Every commit-msg
check was inactive there for months, on the machine that holds the credentials.

Nobody knows why it was disabled that time. But a hook that rejects
generated by the maintainer supplies the motive, and this is the second time
today it has refused a legitimate commit from an ordinary sentence.

The estate's own axioms name this: a check that cannot pass will be muted.
False positives are the slow version - the check can pass, but only after the
author rewrites a true sentence to appease a regex, and eventually someone
reaches for /dev/null instead.

Suggested fix

Require a word boundary and drop the bare two-letter alternative in the prose
patterns:

# was: (claude|gemini|copilot|ai|artificial intelligence)
# now:
"(authored by|co-authored by|generated by)[[:space:]]+(claude|gemini|copilot|chatgpt|an? ai\b|artificial intelligence)"

Two changes, and both matter:

1. [[:space:]]+ instead of .* - attribution is adjacent to the phrase.
   .* lets the phrase match something twenty lines away that was never part of
   the same claim.
2. an? ai\b instead of ai - "by an AI" and "by AI" are attribution;
   "maintainer" is not.

Acceptance criteria

1. Observed refusing, output pasted, for each of: Co-Authored-By: Claude <...>, Generated with Claude Code, authored by an AI.
2. Observed ACCEPTING, output pasted, for each of: generated by `.ai/justfile` , generated by the maintainer, built with available tooling - and a message ending in the sanctioned
   Note: This work was completed with AI assistance (Claude Code).
3. A note in the hook explaining why the alternation is anchored, so the bare
   ai is not reintroduced by someone broadening the check in good faith.

Note on blast radius

This hook is shared by every repository using .ai, so the fix propagates on
the next submodule update - which is the reason to keep the change small and its
negative cases explicit. The second acceptance criterion is the one that matters:
a stricter guard is easy, and this one is already too strict.

[oberstet]

A new instance, and it is the sharpest one yet: the guard refuses a commit
message that describes the guard working.

While onboarding typedefint-organize (typedefint-organize#4), the red phase
provoked both hooks and both refused correctly. Writing that down in the commit
message got the commit rejected:

ERROR: Commit rejected - violates the project's AI_POLICY.md
The commit message contains AI authorship attribution in Git trailer format
which is prohibited.

The offending line was the evidence itself:

RED PHASE, PROVOKED BEFORE TRUSTING:
  - an ordinary commit on `master` -> refused by .ai/.githooks/commit-msg
  - `Co-Authored-By: Claude` -> refused, with AI_POLICY.md quoted

Pattern 2, commit-msg:138:

if echo "$commit_msg" | grep -i -E "(co-)?authored-by:|generated-by:|signed-off-by:" \
   | grep -i -E "(claude|gemini|copilot|ai|artificial intelligence)" > /dev/null; then

It cannot distinguish a trailer from a quotation of one, because it greps the
message as flat text rather than parsing trailers.

Why this instance is worse than the generated by .ai/justfile one

The original report is about a false positive on ordinary prose. This one has a
structural consequence: the estate's own evidence discipline requires writing
down what was provoked, and this hook forbids writing down the most important
thing that was provoked. A13 says prove it fails first; A8 says evidence that
a control is configured is not evidence that it operates. The record that
discharges both is a commit message naming the exact string that was refused —
and that record cannot be committed.

The workaround used was to describe the trailer instead of quoting it, with a
note in the commit saying why:

The trailer cannot be reproduced in this message: the hook's pattern 2 matches
it here too, so a commit describing the successful test of the guard is
refused by the guard.

That is a worse record than the real string, and the next person will hit it
without knowing why the wording is odd.

Two things this suggests for the fix

Parse trailers, do not grep the body. Git already defines what a trailer is
and ships git interpret-trailers. A trailer is a Key: Value line in the last
paragraph, not any line anywhere containing a colon. That alone kills this
instance, the .ai/justfile instance, and the |ai| substring problem in one
change, because prose in the body stops being examined for trailers at all.

Whatever the fix, it needs a test that commits a message containing the
literal string. Otherwise the regression is invisible: the only way to notice
is for someone to try to document a red phase, which happens rarely and looks
like a wording problem when it does.

Measured

just 1.42.4, .ai at 64f2e5d, on typedefint-organize fix_4. The commit
succeeded unchanged once the quoted trailer was reworded, so the rejection is
attributable to that line and nothing else.