Fold a lowercase particle and a title-particle's chain opening a family-first name (#670, #828)

AGENTS.md

@@ -220,7 +220,7 @@ The compiled sets, read by `Lexicon` (mostly as the `_sets` field of the same na
 
 - titles — `TITLES` (every title reading; prenominals), `GIVEN_NAME_TITLES` (the readings with `addresses = "given"`, e.g. "Sir", which treat the following name as given, not family — a subset of the title readings by construction, though not of `TITLES`: a word that may also be a given name, such as `king` or `sheikh`, compiles to `TITLES_AMBIGUOUS` instead) and `AFTER_GIVEN_TITLES` (the salutation readings with `after_given = true`, read as the title where one ends the given part after a family comma, rules/H8, #835 — a subset by construction); `TITLE_ABBREVIATIONS` (the title readings with `abbreviation = true`, `maj`, which rules/H5's trailing chain takes with its period where the word is in `TITLES_AMBIGUOUS`, and on a style rules/H9 gives the article before it as a partner, #999; private, like the kind sets 3.0 added); `TITLES_AMBIGUOUS` (a title reading beside a `given` one, derived, compiled INSTEAD of into `TITLES`: a title only inside a title phrase, rules/H9, #752 phase 2i), `TITLE_MODIFIERS` and `TITLE_STYLES` (by kind) and `TITLE_PHRASES` (the two-word phrases `attaches` makes)
 - suffixes — `SUFFIX_ACRONYMS` (suffix readings with `acronym = true`, matched with every period removed, e.g. "M.D.") and `SUFFIX_WORDS` (the rest, e.g. "Jr."), disjoint because a word has one suffix kind; `SUFFIX_ACRONYMS_AMBIGUOUS` (an acronym reading on a word with a `given` or `family` reading, derived since 2026-10-25: the build refuses the phase 1 flag `may_be_name`); `SUFFIX_WORDS_AMBIGUOUS` (its word twin, a generation or agnomen reading, or a credential written as a word, on a word with a name reading, `fils`, `junior`, `júnior`, the agnomens and `kc`, `pc` and `dl`, gated by the count, rules/S11, since 2026-10-25, the credentials since 2026-10-30, #965, Junior since #1039) with `AGNOMENS` inside it (the `agnomen` kind) and `TITLE_CASE_NAME_WORDS` beside it (the readings written `title_case_is_name`, `fils`, `père`, `kc`, `pc`, `dl`, whose writing leans, Title case to the name; any other gated word's writing never leans, #1039); and `GLUED_HONORIFICS` (#308, `attached`), the subset of `SUFFIX_WORDS` the peel may split off the END of a name token — a separate, harsher bar, since the glued position has no writer-drawn boundary to lean on, and each word refused it carries `excluded = { attached = … }`
-- particles — `PARTICLES` (family-name particles, e.g. "de", "van") and `NON_GIVEN_NAME_PARTICLES`, the curated subset that is *never* a standalone given name (the particles whose word has no `given` reading, each stating `may_be_given = false`; a `given` reading on the word is what makes a particle possibly given, the phase 1 flag `may_be_given = true` refused since 2026-10-25). What the subset licenses is rules/P1's fold in `post_rules` (the "rule 1b" of older issue comments — decisions/legacy-rule-numbers maps the old numbers), and the fold has ONE site: the piece that OPENS the name. A lone never-given particle there, with at least one more name word behind it, starts the family. Titles do not move the opening position (rules/P4), so `Sir de Mesnil` reads family `de Mesnil` under every `name_order`, as `de Mesnil` does. How far the fold reaches depends on the order the name was read under: by default it takes the rest of the name (`de Mesnil Jean` → family `de Mesnil Jean`); under either family-first order it takes the particle run plus ONE name unit and lays the rest out by the order (`de Mesnil Jean` → family `de Mesnil`, given `Jean`); after a family comma it takes the rest of that part whatever the order (`Smith, de Mesnil Jean` → family `Smith de Mesnil Jean`). The leading particle stays a lone piece for the fold to find — `group` does not chain it forward, and the fold walks the particles after it itself — so `de la Vega` reads family `de la Vega` under all three orders. The GIVEN position is not a site. It was a second one until #467, which removed it because under a family-first order that slot holds what the caller DECLARED to be the given name: `Mesnil de` under `FAMILY_FIRST` or `FAMILY_FIRST_GIVEN_LAST` reads given `de`, family `Mesnil`. Nor is a particle inside the name: `Juan de la Vega` under a family-first order reads family `Juan`, given `de la Vega`, with no ambiguity recorded — what the vocabulary forbids is the bare particle as a given name, not a name part that begins with one. A bare `de` has nothing to fold into and is placed by position like any one-word name: given `de` by default, family `de` under both family-first orders. A leading particle OUTSIDE the set is left to position — `van Gogh` is given `van`, family `Gogh` by default and family `van`, given `Gogh` under both family-first orders — and records a `PARTICLE_OR_GIVEN` ambiguity under all three; a never-given particle opening the name records none (`de Mesnil`), and neither does an ambiguous one inside it (`Vincent van Gogh`). The internal `Lexicon._sets.particles_ambiguous`, the particles holding a `given` reading, is its complement within `PARTICLES`, so the two mark OPPOSITE sets — see the flip warning in `docs/migrate.rst` before translating either
+- particles — `PARTICLES` (family-name particles, e.g. "de", "van") and `NON_GIVEN_NAME_PARTICLES`, the curated subset that is *never* a standalone given name (the particles whose word has no `given` reading, each stating `may_be_given = false`; a `given` reading on the word is what makes a particle possibly given, the phase 1 flag `may_be_given = true` refused since 2026-10-25). What the subset licenses is rules/P1's fold in `post_rules` (the "rule 1b" of older issue comments — decisions/legacy-rule-numbers maps the old numbers), and the fold has ONE site: the piece that OPENS the name. A lone never-given particle there, with at least one more name word behind it, starts the family. Titles do not move the opening position (rules/P4), so `Sir de Mesnil` reads family `de Mesnil` under every `name_order`, as `de Mesnil` does. How far the fold reaches depends on the order the name was read under: by default it takes the rest of the name (`de Mesnil Jean` → family `de Mesnil Jean`); under either family-first order it takes the particle run plus ONE name unit and lays the rest out by the order (`de Mesnil Jean` → family `de Mesnil`, given `Jean`); after a family comma it takes the rest of that part whatever the order (`Smith, de Mesnil Jean` → family `Smith de Mesnil Jean`). The leading particle stays a lone piece for the fold to find — `group` does not chain it forward, and the fold walks the particles after it itself — so `de la Vega` reads family `de la Vega` under all three orders. Behind a title-particle (`St`, `Freiherr`, P4's Except) it does chain, and under a family-first order the fold cuts that chain as it cuts a run (`St de Mesnil Jean` → family `de Mesnil`, given `Jean`, #828). The GIVEN position is not a site. It was a second one until #467, which removed it because under a family-first order that slot holds what the caller DECLARED to be the given name: `Mesnil de` under `FAMILY_FIRST` or `FAMILY_FIRST_GIVEN_LAST` reads given `de`, family `Mesnil`. Nor is a particle inside the name: `Juan de la Vega` under a family-first order reads family `Juan`, given `de la Vega`, with no ambiguity recorded — what the vocabulary forbids is the bare particle as a given name, not a name part that begins with one. A bare `de` has nothing to fold into and is placed by position like any one-word name: given `de` by default, family `de` under both family-first orders. A leading particle OUTSIDE the set is left to position — `Van Gogh` is given `Van`, family `Gogh` by default and family `Van`, given `Gogh` under both family-first orders — and records a `PARTICLE_OR_GIVEN` ambiguity under all three, save one written in lower case in a mixed-case name under a family-first order, which the fold takes and which records none (`van Gogh` → family `van Gogh`, rules/P11, #670); a never-given particle opening the name records none (`de Mesnil`), and neither does an ambiguous one inside it (`Vincent van Gogh`). The internal `Lexicon._sets.particles_ambiguous`, the particles holding a `given` reading, is its complement within `PARTICLES`, so the two mark OPPOSITE sets — see the flip warning in `docs/migrate.rst` before translating either
 - bound given names — `BOUND_GIVEN_NAMES` (`bound_given` readings, e.g. "abdul", "abu"; one that is also a particle needs a `given` reading, a build check); a group-stage rule joins the first non-title piece to its following piece before roles are assigned, reserving a family word unless a family comma has already fixed it or a given-name title stands ahead (#369, rules/P5) (ported from v1's `_join_bound_first_name`)
 - given names written short — `GIVEN_NAME_ABBREVIATIONS` (#789, a `given` reading carrying `same_as`, the full name: "chas", "wm", Filipino "ma"), the given names written short that rules/H2's shape yields to; nothing else reads it
 - names a given name's second half reads — `PARTICLE_GIVEN_NAMES` (#704, a `given` reading written `after_particle`: "carmen", "ángeles", the Spanish words a compound given name writes behind a particle, which rules/P10 reads as a middle name in `María del Carmen García`, by default), `SAINT_PARTICLES` (the `saint` kind, `san`, `santa`, `st`, `ste`, `sta`, `sto`, whose run P10 refuses, `Santa María` being a surname) and `SHARED_NAMES` (#704, a name reading written `shared`: Sikh "kaur", "singh", which rules/O6 and O7 neither take nor complete and P10 does not complete, `Kaur del Carmen García`), private; each is read through classify's tags or the lexicon in `_post_rules`

docs/customize.rst

@@ -1001,10 +1001,13 @@ consulted at all:
   every ``name_order``. ``"de Mesnil"`` is family ``de Mesnil`` under
   both family-first orders exactly as it is by default, not family
   ``de`` with ``Mesnil`` given — a word that can never be a given name
-  leaves the order nothing to decide. Only the never-given set does
-  this: ``"van Gogh"`` reads family ``van``, given ``Gogh`` under a
-  family-first order, because ``van`` *can* be a given name and so
-  leaves a real question to answer.
+  leaves the order nothing to decide. A particle that *can* be a
+  given name does this only under a family-first order, and only
+  written in lower case beside capitals (since 3.0): ``"van Gogh"``
+  reads family ``van Gogh`` there, while ``"Van Gogh"`` reads family
+  ``Van``, given ``Gogh``, its capital leaving a real question to
+  answer. Under the default order the particle is the given name in
+  both spellings.
 - **A lone name word beside a given-name title** is the given name in
   every ``name_order`` (since 2.5): ``"Sir John"`` reads given ``John``
   under both family-first orders, as it does by default, while

docs/design/decisions/H1-title-and-one-name-word.md

@@ -8,7 +8,7 @@
 - Where a run stands before the one name word, that run addresses; a run behind the word decides its field only when none stands before, and a run written around a nickname is one run: `Sir John Prof.` → given 'John', `Dr. Smith Sir.` → family 'Smith', `Smith Sir.` → given 'Smith', `Dr. 'Smitty' Sir John` → given 'John' — 2026-09-08 #489; 2026-09-09 #316.
 - `prince` and `princess` are given-name titles and `lord` and `lady` are not, decided rather than deferred, since the text does not say which rank a bearer holds: `His Royal Highness Prince Harry` → given 'Harry' (the bare `Prince Harry` reads given 'Prince' in the default order since 2026-10-27, `prince` being a title only inside a title phrase, decisions/H9), `Lord Byron` → family 'Byron', `His Excellency Lord Duncan` → family 'Duncan' — 2026-09-10 #519.
 - H1 decides the field of the one name word before a comma with no given name after it, and of the one name word of a name read family-first: `Mary II, Dame` → given 'Mary' (`Elizabeth II, Queen` until 2026-10-27, when `queen` became a title only inside a title phrase, decisions/H9), `Smith, Sir` → given 'Smith' with the family empty, `Sir John` and `Pope Francis` given under every order — 2026-10-18 #720.
-- A particle surname keeps the family where something settled it, a comma (`van der Berg, Sir`, `Van, Sir`) or P1's fold asked of the leading name piece (`Sir de Mesnil`); an ambiguous particle no comma settled reads given (`Sir Abu Bakar`, `Sir Van` family-first; `Sheik Abu Bakar` until 2026-10-27, decisions/H9, which under the family-first orders now reads the word as the family and the particle given by position), and so does a never-given one the fold does not take (`St Sir de Mesnil` under every order) — 2026-10-18 #720.
+- A particle surname keeps the family where something settled it, a comma (`van der Berg, Sir`, `Van, Sir`) or P1's fold asked of the leading name piece (`Sir de Mesnil`); an ambiguous particle no comma settled reads given (`Sir Abu Bakar`, `Sir Van` family-first; a lowercase one in a mixed-case name its writing settles, rules/P11's precedence, `Sir van Berg` family-first → family 'van Berg', decisions/P11's 2026-11-04 (Derek), #670 entry; `Sheik Abu Bakar` until 2026-10-27, decisions/H9, which under the family-first orders now reads the word as the family and the particle given by position), and so does a never-given one the fold does not take (`St Sir de Mesnil` under every order) — 2026-10-18 #720.
 
 Elsewhere: the graf class, a title word borne as a name but rarely as its first word shipping as a title (`Greve Anna` → title 'Greve', family 'Anna'), is decisions/salutation-titles' 2026-10-04 #606 bundle; the renunciate class, the given-name titles of traditions that drop the surname (`Swami Vivekananda` → given 'Vivekananda'), is decisions/indic-honorifics' 2026-09-06 #346/#344/#343 bundle.