A prose sentence beginning 'Word:' in the last paragraph is parsed as a trailer and blocks the commit

[MongLong0214]

What happened

A commit message whose body ends with an ordinary English sentence of the form Word: rest of sentence is
rejected. The word before the colon is read as a trailer key:

shape failed · references ok
5: unknown-key Live — got "Live", want "a key from SPEC §3 or X-<Name>"
commitlore: 1 violation (SPEC §6) — the message was not modified

The commit does not happen. I hit this on a real commit whose closing line was
Live: the delete now reaches State A, 9 markers to 8. — a sentence, not a trailer.

Reproduction — minimal, from scratch

CommitLore 0.8.2, macOS 15.3 (Darwin 25.3.0), git 2.x.

cd /tmp && rm -rf clrepro && mkdir clrepro && cd clrepro
git init -q . && git config user.email t@t.t && git config user.name t
cp /path/to/a/commitlore-wired-repo/.git/hooks/commit-msg .git/hooks/ && chmod +x .git/hooks/commit-msg
cp /path/to/a/commitlore-wired-repo/.commitlore-policy.json .

echo x > a.txt && git add a.txt
git commit -F - <<'MSG'
fix(#1): a subject line

Some ordinary prose body explaining the change and why it was made.

Live: the delete now reaches State A, 9 markers to 8.
MSG

Observed: shape failed, 5: unknown-key Live, commit refused.

Control — the same message with the final line rephrased so it does not start Word: commits cleanly:

Against the running application the delete now reaches State A, 9 markers to 8.

So the trigger is precisely the Word: prefix on the final paragraph, not the content.

Why this is worth changing

Git's own trailer rules do treat a trailing Key: value block as trailers, so parsing it that way is
defensible. The problem is the failure mode, not the parse:

1. It fires on prose that no one intended as metadata. Sentences starting Live:, Note:, Result:,
   Measured:, Warning: are common in engineering commit bodies.
2. The diagnostic points the wrong way. want "a key from SPEC §3 or X-<Name>" reads as "you used the
   wrong key", which invites the author to invent X-Live: rather than to realise the line was meant as a
   sentence. Something like "this line looks like prose; trailers must be the final block — rephrase, or
   separate it" would land the author on the right fix immediately.
3. It is only discoverable at commit time, after the whole message is written.

Suggested handling

Any of these would resolve it; the first is the smallest:

• Widen the diagnostic to name the prose case and the two ways out (rephrase, or move the real trailers
  below).
• Treat a candidate trailer line containing sentence-like content (spaces before the colon, a trailing
  period, mixed case after the colon) as prose rather than a malformed trailer.
• Only enforce key validity on lines in a block where every line parses as Key: value, which is closer
  to git's own interpretation of a trailer block.

Context

Found during live use on a real project (logic-pro-mcp). Not a blocker for me — rephrasing the sentence
worked — but it cost a commit cycle and the message did not point at the actual cause.