Make the comma rules explain what they describe (#372)

[derek73]

The first of #372's confirmed over-claiming instances, resolved. Three commits: the narrowing, the rule the narrowing turned out to need, and the pin that would have caught the whole thing.

The bug

fix(comma-family)'s name_regex was a bare ,, reaching every comma in every script. It explained 8 corpus names; its prose — "lone post-comma piece routes to suffix/title, not first" — described one. The other seven were CJK glued-honorific names, winning on nothing but file order over rules that carry a name_regex and therefore share its precedence tier.

What it took

1. Anchor fix(comma-family) to Latin (34f573d), at the U+0250 threshold _is_latin_only already uses, anchored at both ends so a mixed-script name cannot match on its Latin half.

2. Give the seven a rule that describes them (e308987). Review caught that step 1 relocated the problem: the seven diff as {given, suffix} with family byte-identical — no order flip — while fix(cjk-comma-compound) exists for the union of comma routing and the family-first flip, which is why its fields include family. Its own comment says so. They landed there on a fields superset and file order: the same coincidence #372 was filed over, one rule along.

So fix(cjk-comma-honorific-peel) now names what actually happens — #312's honorific peeling off the post-comma given name into suffix — with fields = ["given", "suffix"]. The field list is what separates it from the compound rule, not its position: the union rows move family, outside these fields, so they cannot match it however early it sits.

3. Pin who explains what (45f74c8). _CROSS_RULE_WINNERS records classify()'s answer for the ten contested names, keyed by (name, diff shape), with the diff shapes measured against the 1.4.0 wheel rather than guessed.

Result

rule	claims	describes
fix(comma-family)	1 — Andrews, M.D.	Latin lone post-comma piece
fix(cjk-comma-honorific-peel)	7	the peel, no order flip
fix(cjk-comma-compound)	10	the union, family moves

fix(cjk-comma-compound) returned to exactly the 10 names it had before any of this — not aimed for, it fell out of drawing the boundary by fields.

Gates unmoved throughout: 108 intentional / 0 unexplained at 1.4.0, 90/0 at 2.0.0, 1/0 at 2.1.0. Suite 3218.

Why the pin earns its place

Every other guard measures a rule alone. _CORPUS_CLAIMS records what a regex reaches; the gate counts names. Neither can see which rule wins a contest — which is exactly how seven names sat on the wrong rule for months with every guard green.

Proven by mutation, both directions review identified:

• drop Hangul from the peel rule's class → three Korean names fall through to fix(suffix-routing), a fields-only catch-all about two-token Latin names. The gate stays 108/0 and reports nothing. Now caught.
• move the peel rule after the compound rule — a pure reorder, no regex or fields change. Measured across the whole suite: this is the only test that fails. _CORPUS_CLAIMS is order-blind by construction.

A failure here is not automatically a regression — a rule narrowed correctly may send its names somewhere better. It means someone has to look, which is the point.

Prose corrections

Three sites, all found by review. Two were invalidated by commit 1: fix(cjk-comma-compound) still said the {given,suffix} rows match fix(comma-family) "purely on file order", and fix(suffix-routing) still pointed at a note about a split that no longer exists. The third was inherited and wrong before this branch: '田中さん, V.' is not a parity row — it diffs {family, suffix} and reaches classify(), reading as parity only under Policy(lenient_comma_suffixes=False), which the corpora never use.

Still open on #372

fix(suffix-routing). It is the only fields-only rule, so giving it any regex moves it between precedence tiers and reshuffles globally — a different problem, worth its own measurement. Ambiguity reporting and the specificity floor remain declined on the evidence recorded in #373.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.51%. Comparing base (05f6661) to head (45f74c8).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #375   +/-   ##
=======================================
  Coverage   98.51%   98.51%           
=======================================
  Files          44       44           
  Lines        2895     2895           
=======================================
  Hits         2852     2852           
  Misses         43       43           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.