Order declarations are authoritative: #471 declined, #384 on option 1 with the rotations gated

[derek73]

One principle, recorded once and applied twice: a name_order is a property of the data source, not of a string. The caller declares it to match how their records are written, and the declaration governs everything no vocabulary and no script license has already claimed (O4, W4).

#471 is declined by design. Under the default given-first order a string that opens with a never-given particle is a surname whose given name is absent, and surnames may be several words — Spanish double surnames above all — so the fold takes the rest of the name: de la Torre Vega is a surname-only string read right. de la Cruz Juan Carlos is a family-first listing under the wrong order, and the remedy is the declaration (FAMILY_FIRST already gives family de la Cruz, given Juan, middle Carlos) or the family comma. de la Family Family Given versus de la Family Given Given is undecidable under either order, which is what makes the comma the answer rather than a better heuristic. This supersedes the REASON the 2026-08-17 P1 entry gave for the same outcome ("the parser cannot see language"), not the outcome. rules.md#P1 gains the Accepted clause and two executable examples; de la Torre Vega joins the contract corpus and, at the 1.4.0 baseline only, the already-recorded initials-view class, so that gate's intentional count goes 367 → 368 with the claim recorded.

#384 resolves on option 1, and the code now matches it. The ru and tr_az patronymic rotations exist to restore the given-first reading a family-first listing hides, so under a declared family-first order the declaration decides. The design-docs review found the code was NOT scoped that way: the rotation reads whatever word sits in the family slot, which under FAMILY_FIRST is the first word, so a patronymic-derived surname fired it — ru + FAMILY_FIRST read Мицкевич Адам Юзеф as family Адам. The rotations are now gated on the order assign read (state.order, not policy.name_order, for the reason the P1 fold gives). Zero corpus names move at any baseline, and the corpora swept under both packs with FAMILY_FIRST declared show no difference either; the firing controls (Мицкевич Адам Юзеф, oglu Ahmad Vali Ali) are pinned under both family-first orders with the pre-gate 2.2.0 readings recorded as the negative control. Options 2 and 3 are declined with their real costs.

Gate: 368 / 263 / 175 / 37 intentional at 1.4.0 / 2.0.0 / 2.1.0 / 2.2.0, 0 unexplained, 0 radar unclassified. No release-note bullet: #471 changes no behavior, and the #384 gate moves no corpus name and no default-policy parse.

Closes #471
Closes #384

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.67%. Comparing base (8e6c483) to head (0b6a792).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #517   +/-   ##
=======================================
  Coverage   98.66%   98.67%           
=======================================
  Files          45       45           
  Lines        3232     3234    +2     
=======================================
+ Hits         3189     3191    +2     
  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.