Reject a ledger rule that narrows by name and not by role

[derek73]

Closes #456. Found by the #455 review; the symmetric twin of #451's ban.

name_regex = "Smith"      # and no `fields`

Measured: such a rule claims 127 of 127 possible diff shapes on any name its regex reaches. It narrows by name and by nothing else.

Why #452 made this urgent rather than untidy

over_declared_rules skips a rule with no fields — correctly, since one declaring no roles cannot over-declare them. But that turns deleting the line into an opt-out: it is the cheapest way to silence an OVER-DECLARED failure and the most permissive thing that can be done to the rule, at the same time. The #372 failure mode, reached by following a gate error message.

The new message says exactly that, and warns against the obvious wrong correction — reaching for fields while dropping the regex lands on the shape #451 banned. The two bans are each other's trap.

Free to enforce

expected_since_1.4.0.toml: 70 rules, 0 without `fields`
expected_since_2.0.0.toml: 58 rules, 0 without `fields`
expected_since_2.1.0.toml: 51 rules, 0 without `fields`

All three still load. Same argument validate_rules already makes for #451's ban in its own docstring.

The symmetry is the point

validate_rules now rejects a rule carrying neither key, one carrying fields without name_regex (#451), and one carrying name_regex without fields (#456). After this, every ledger rule carries both, and the three rejections read as one rule with one reason: a rule narrows by name and by role, or it is not a rule.

Placement

At the END of the fields family, beside #451's. That matters: written under the neither-key check, #451's version pre-empted the three checks that buy precise messages for a malformed fields — an empty one reported the #451 message instead of "empty 'fields'". That was a #453 review finding, and this check has the same hazard in reverse.

The test fixture ripple, and one thing worth flagging

Twenty fixtures gained a fields. Intent is preserved in every one — they are ZZZ rules that match nothing whatever their roles, a "" rule that hits the sentinel check first, and Smith rules whose {family} diff the added roles still admit.

Nine of the twenty already carried a fields on the next concatenated line, and my first pass duplicated the key. tomllib caught it with Cannot overwrite a value; removed.

test_a_rule_with_a_regex_and_no_fields_or_both_stays_legal pinned this shape as legal when #451 landed. It is inverted rather than deleted, so the change of status is visible in the history rather than silent — a test quietly disappearing is how a decision stops being reviewable.

Verification

Proved able to fail: disabling the check fails the new test. tests/v2/ 5350 passed, 156 skipped, 1 xfailed. Gates 1.4.0 229/0, 2.0.0 194/0, 2.1.0 102/0, no OVER-DECLARED.

Decided, not deferred

No escape hatch for a "genuinely unbounded" rule — declined until one appears, the same call #452 made. dormant covers "explains nothing"; nothing covers "explains everything", and no such rule exists. If one ever does it should argue for a key the way dormant was argued for in #373, rather than finding one already built.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.64%. Comparing base (6ac31f4) to head (c856c33).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #457   +/-   ##
=======================================
  Coverage   98.64%   98.64%           
=======================================
  Files          45       45           
  Lines        3177     3177           
=======================================
  Hits         3134     3134           
  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.