Narrow S5, S7, S2 and S9 prose; record P1's and P2's undated decisions (#762)

docs/design/decisions/P1-lone-particle-fold.md

@@ -13,6 +13,7 @@ Examples read under the default order unless a line names another.
 - A particle chain inside the name is grouped and positioned like any other group, so `Juan de la Vega` under a family-first order reads family 'Juan', given 'de la Vega': what the never-given vocabulary forbids is the bare particle as a given name, not a name part that begins with one — 2026-08-16 #368 REVERSED.
 - The rule no longer carries the history of its given-position site: a particle where a family-first order puts the given name is not folded (`Mesnil de` family-first → given 'de'), kept as the rule's last Accepted bullet, the decision being decisions/P6's (Elsewhere below) — 2026-10-19 #761 (skeleton migration).
 - A bare particle has nothing to fold into and is a lone name word read by O5: `de` → given 'de' under the default order, family 'de' under a family-first one — 2026-10-19 (Derek), #761.
+- After a family comma the run takes the rest of that part, whatever order is declared, the comma having already fixed the surname (`Smith, de Mesnil Jean` → family 'Smith de Mesnil Jean' under all three orders) — 2026-08-18 #395, family comma.
 
 Elsewhere: a word of both the title and the particle vocabulary at the head (`St`, `Freiherr`, bare or period-marked) is rules/P4's exception and not this fold's site, the particle behind it being inside a name P2's chain makes (`St de Mesnil Jean` family-first → title 'St', family 'de Mesnil Jean') — decisions/P2's 2026-10-10 (Derek), #624 entry. The GIVEN position under a family-first order is no fold site (`Mesnil de` family-first → given 'de') — decisions/P6's 2026-08-30 #467 entry. Which particles are never-given is decisions/vocabulary-collisions' criterion, applied by #360 (2026-08-18), which moved `mc` and `ste` into the set.
 
@@ -63,6 +64,8 @@ the 2026-08-16 entries below. The survivor is the degenerate bare
 - 2026-10-19 #761 (skeleton migration) — the rule no longer carries the history of its second site. A never-given particle standing where a declared order puts the GIVEN name was a P1 site until #467, and dropping it was a correction rather than a narrowing: that slot holds what the caller DECLARED to be the given name, and the never-given vocabulary supplies a reading where position leaves the question open rather than vetoing one position has already given. The argument and its measurements are decisions/P6's 2026-08-30 #467 entry; rules/P1 keeps the reading itself in its last Accepted bullet, scoped to a family-first order (a particle in that given slot is not folded), with `Mesnil de` under FAMILY_FIRST as its example. The default-order reach's "by design" points at the 2026-09-07 #471 entry above, which the rule no longer restates.
 - 2026-10-19 (Derek), #761 — A BARE PARTICLE IS A LONE NAME WORD. The Accepted bullet said a bare "de" stays the given name, which held only under the default order: under either family-first order it reads family 'de'. Nothing folds a lone particle, so it reads as O5's convention reads any lone name word, and the bullet now says that, with the family-first example. No reading moved.
 
+- 2026-08-18 #395, family comma — AFTER A FAMILY COMMA THE FOLD TAKES THE REST OF THAT PART, WHATEVER ORDER IS DECLARED: the comma has already fixed the surname, so no positional read is left for an order to narrow (`Smith, de Mesnil Jean` → family 'Smith de Mesnil Jean' under all three orders). Decided with #395 (commit 4627604f, whose release note says a family comma is untouched "where the comma has already fixed the surname") and stated in rules/P1 since, but the #395 entry above never recorded it; this entry, written 2026-10-22 for #762, dates it from that commit so the Standing block can point at it.
+
 Declined:
 
 - A strict xfail asserting "de Mesnil" → family under FAMILY_FIRST (#359 review) — #359 deliberately left those semantics open, and a strict xfail decides the question by the back door.
@@ -75,4 +78,3 @@ Declined:
   positioned by the declared order — "Cher" reads given under GIVEN_FIRST — so "de la Vega" would read given="de la Vega" unless a further rule forced a particle-headed group into the family. Add that rule and [de Mesnil][Jean] yields the #364 reading anyway, so the deletion buys nothing and costs P4.
 
 Decided 2026-08-18 (was Open: [#360](https://github.com/derek73/python-nameparser/issues/360), which particles count as never-given): #360 applied the criterion at decisions/vocabulary-collisions and moved `mc` and `ste` into the set (from the may-be-given half), adding the Spanish/Portuguese articles; later vocabulary work extends the set under the same criterion (#604's Irish particles).
-

docs/design/decisions/P2-particles-join-forward.md

@@ -9,6 +9,7 @@ Examples read under the default order unless a line names another.
 - Where the name begins has one definition, assign's leading-title run, H2's unlisted abbreviations included, so `Xyz. van Johnson` reads as `Dr. van Johnson` does — 2026-08-22 #424.
 - The leading position is decided once, as the LAST title in assign's leading-title run, read as written before H3's give-back, that is also a particle, else the first piece past the run: `Freiherr St John Smith MA` → title 'Freiherr St', given 'John', family 'Smith', suffix 'MA' (default order); `Freiherr St van Berg MA` → title 'Freiherr St', family 'van Berg'; `Dr. Mc Mc` → given 'Dr.', suffix 'Mc Mc' (default order) — 2026-10-10 (Derek), #624.
 - Assign's re-read fallback, where group's joins leave no name word past the titles, stays, since it guards totality — 2026-10-10 (Derek), #624.
+- Particle groups are distributed across the middle and family fields rather than combined, the combined double-surname reading living in the surnames view (`Joao da Silva do Amaral de Souza` → middle 'da Silva do Amaral', family 'de Souza', surnames 'da Silva do Amaral de Souza') — 2026-08-16.
 - Suffix pieces are not skipped when the chain looks for the leading piece, since skipping them reads worse: `Ph.D. Van Johnson` → given 'Ph.D.', family 'Van Johnson'; `Dr. Ph. D. Van Johnson` → family 'Van Johnson' — 2026-10-19 #760.
 
 Elsewhere: the stop is S2's trailing run, read once after P3's joins and before the chain is made, counting the chain's own run as the one name word it will make (`John van der Berg V` → family 'van der Berg', suffix 'V'), the re-ask after the chain's merges running only where the run was not read there, and on a main segment the chain stops in front of a trailing title (`John van der Berg Prof.` → title 'Prof.', family 'van der Berg' under the default order) — decisions/S2's 2026-10-07 (Derek), #614 entry and decisions/H5's 2026-10-07 #614 entry, indexed here by this file's 2026-10-07 #614 cross-reference. A particle that is also suffix vocabulary heads the name word behind it before a family comma in any case (`SMITH VD MA, JOHN` → family 'SMITH VD MA') — decisions/P9's 2026-10-02 #573 entry. A bare ambiguous acronym written Title-case in a mixed-case name joins the chain (`John van der Berg Ma` → family 'van der Berg Ma') and one written in capitals ends it with no words to spare (`Freiherr von Berg MA` → family 'von Berg', suffix 'MA') — decisions/S6's 2026-09-14 #289 + #516 and 2026-09-15 (Derek) entries; the absorbed acronym reports `suffix-or-name`, and a word a particle run took (`anh van do`) reports nothing — decisions/S6's 2026-09-18, WHOLE-PR REVIEW ROUND entry; a one-letter numeral behind a title and a chain has no word to spare and joins the chain (`Freiherr von Richthofen V` → family 'von Richthofen V') — decisions/S10's 2026-10-17 (Derek), #718 entry. After a family comma the given part's chain stops where `tail_reading`'s run begins — decisions/H5's 2026-10-10 (Derek), #623 entry.
@@ -21,6 +22,7 @@ Open: none in this file.
   "Sir de Mesnil" grouped [Sir][de Mesnil] — a chain — and
   reported given="de Mesnil" with no family at all. After, "de" is the leading name piece, and a leading particle chains nothing (rule P4): the family reading comes from P1's fold, which is why P1's fold needed no change (its interacts: points here). Grouped today: [Sir] [de] [Mesnil].
 
+- 2026-08-16 — GROUP DISTRIBUTION IS LOAD-BEARING, the undated bullet below, dated for #762 on 2026-10-22 so the Standing block can point at it, by the commit that first recorded it (c2381f6b). No commit decided it: the split fields and the combined `surnames` view are v1's (9a3d187c, 2018), held by its Portuguese tests.
 - Group distribution is load-bearing, not incidental: the v1 Portuguese tests (test_portuguese_dos, test_portuguese_prefixes) require multiple particle groups to land across middle and family, while #132 wanted the combined double-surname reading — the same shape with opposing wants, which is why the combined reading lives in the surnames VIEW and the split in the fields.
 
 - 2026-08-22 #424 (its `John van der Berg Ma` and `Freiherr von Berg MA` readings superseded by decisions/S6's 2026-09-14 #289 and 2026-09-15 entries, its `Freiherr von Richthofen V` boundary by decisions/S10's 2026-10-17 #718, its read over the pieces as written and its re-ask by #614, and its leading scan stopping at the first title-particle by #624, below) — the chain stops where assign's trailing peel begins. The chain ran "until a trailing suffix begins" and asked with the suffix-piece test, which vetoes a bare `V` as an initial — the #401 question at a third site — so `John van der Berg V` read family 'van der Berg V' (1.4.0 read it so too: shipped since 1.x), and `John van der Berg Ma` read family 'van der Berg Ma' where 1.4.0 read suffix 'Ma' — a 2.0 regression on S2's other fork. Both now stop where `_trailing_start` says the run begins: the S2 peel (`_peel_trailing` over `_peel_walk`, shared with assign and P5's reserve since #425) read over the pieces as they stand from the first name piece, once per segment, kept as a length from the end that the chain's merges ahead of it do not move (the benchmark's `particles` shape is the guard). The chain takes both forks — its merges leave the acronym at least the three pieces the fork counted, so assign peels it after as the walk did before — where the maiden walk takes only the numeral (the M2 entry says why). The fork reads the piece before the numeral as it stands, so `John van der J. V` keeps family 'van der J. V', as `John J. V` reads the V as a name; and a numeral with a suffix behind it is not last in the walk, so `John van der Berg V Jr` keeps family 'van der Berg V'. No differential corpus name had either shape; the rules examples carry them — the numeral against every baseline, the acronym against 2.0.0 and 2.1.0. Two more sites were asking assign's question with a test of their own, both found by the reviews of this change. The walk's starting point and P4's leading-particle scan asked group's `title()`, which does not see H2's unlisted abbreviations — assign peels those as titles all the same — so `Xyz. van Johnson` chained where `Dr. van Johnson` did not (#367 had keyed the exception on the first piece of the name, by group's test), and `Xyz. van Berg MA` read family 'van Berg MA' on every 2.x tree — the chain had taken the acronym, as it took every acronym; the draft that stopped before it left assign two pieces where the fork had counted three, and MA became the family. Both ask assign's own test now — `_is_leading_title` and the period-abbreviation pattern moved down into group, with `_leading_titles` as the one definition of where the name begins: the chain's walk, the bound join's first name piece (the second docs review found that one still on group's test — `Xyz. abdul John Smith` joined nothing where `Dr. abdul John Smith` read given 'abdul John') and, through `_is_leading_title`, the scan and the PARTICLE_OR_GIVEN report — so `Xyz. van …` reads as `Dr. van …` does. `Esq. van Gogh`, a corpus name, moves with it (1.4.0 read family 'van Gogh' for both, as #367's rule records; its own rule at every baseline, and one for the P4 example). A particle of the unambiguous suffix vocabulary too (vd, mc) is a suffix piece to the peel: where it opens the trailing run the chain stops before it as before any suffix word and the peel takes it — `John Smith Mc V` reads suffix 'Mc, V' where master and 1.4.0 read family 'Mc V', a class the second docs review found unrecorded (2,554 of its 117,306 constructed names, an eighteen-word pool that puts the words in every position) — and where it continues a prefix run, the run takes it as a particle, so `John van Mc` keeps family 'van Mc', every baseline's reading and the one P6 chose for the shape after a comma. Both are Accepted under P2. The fork's count was the last thing the chain asked on its own authority, and the reviews found it wrong behind a title-and-particle word: #367 stops the leading-particle scan at `Freiherr`, `St`, `Do` — the name's own first piece — where assign's title peel steps over them, so the chain takes the name's first word, and the acronym the fork counted with three pieces met assign with two: `Freiherr von Berg MA` read given 'von Berg', family 'MA' (1.4.0's reading, as it happens; master read family 'von Berg MA'). So the chain asks the peel again over the pieces it leaves — `chain(tail)`, then `_trailing_start` over what it built, and a second run without the stop where the verdict changed, the snapshot being one copy per segment with a trailing run — and takes what assign will not peel: family 'von Berg MA'. The numeral cannot flip, a chain group never being initial-shaped, so `Freiherr von Richthofen V` keeps suffix 'V', and its chain, the one name piece left, reads as `Dr. Smith V` reads — where 1.4.0 and master read family 'von Richthofen V'; the code review asked for that boundary to be on record, and P2 carries it. #410 (2026-08-25) then moved the name half of both: a title with one name word behind it names the family whatever stands beside it, so the pair reads family 'von Richthofen' and family 'Smith' today, where each read `given` with no family when this entry was written. The boundary is unchanged — the chain still stops before the numeral, and the two names still read alike; only the field the one name piece lands in moved. This name is the fifth corpus name #410 moves, and the only one already classified, its ledger rule's `fields` spanning the narrower diff.