Give decisions/P1, P2, P3, P6 and P7 a Standing block (#762)

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

@@ -1,14 +1,34 @@
 # P1 — lone particle fold
 
+## Standing
+
+Examples read under the default order unless a line names another.
+
+- The fold's site is read from the joining structure, a lone never-given particle PIECE opening the name, not from the roles assigned, so the fold holds under every name order (`de Mesnil` → family 'de Mesnil' under all three) — 2026-08 #359.
+- A title that is not also a particle does not move the opening position (the title-particles are P4's exception, Elsewhere below): `Sir de Mesnil` reads as `de Mesnil` does, family 'de Mesnil' under every order — 2026-08 #367.
+- Grouping is vocabulary's job and assignment the declared order's, the one reach of an order into grouping's question being the leading run's stopping point, below — 2026-08-16 #364, #365, #368; 2026-08-17.
+- Under the default order the leading run takes the rest of the name (`de Mesnil Jean`, `de la Cruz Juan Carlos` → all family), and that is the reading rather than a gap: a name order is a property of the data source, a never-given particle marks where a surname begins, and the remedy for a family-first listing is the declaration or the family comma — 2026-08-17; 2026-09-07 #471.
+- Under a family-first order the run takes the particles and ONE name unit and lays the rest out by the order (`de Mesnil Jean` → family 'de Mesnil', given 'Jean'), the declaration being evidence of where the surname ends — 2026-08-17.
+- The stop lives in the fold, reading the order assign actually used, and a unit is a particle chain, a conjunction join or a bound given-name pair read off the tags (`de la Vega y Santos Juan` family-first → family 'de la Vega y Santos') — 2026-08-18 #395.
+- 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.
+
+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.
+
+Open: none in this file. Reporting an ambiguity on the shapes neither order settles was left out of the 2026-09-07 #471 entry on purpose and is no open question here.
+
+## Log
+
 A lone PIECE is the whole test — deliberately narrower than "a never-given particle is never reported as the given name," which would be false (the over-broad invariant shipped to five sites before #361's review falsified it with three counter-examples). The counter-example set has since shrunk, and its shrinkage is the section's history: "Sir de Mesnil" fell to #367 (titles became transparent); "Juan de la Vega" under family-first — the whole chain in the given position — was called working-as-intended by
 #359, contested by #368, and is working-as-intended again as of
 the 2026-08-16 entries below. The survivor is the degenerate bare
 "de".
 
 - 2026-08 #359 — the opening site is read from joining structure (pieces), not from assigned roles, so the fold holds under every name_order. Before this, the role-only read let "de Mesnil" split under a family-first order.
 - 2026-08 #367 — titles are transparent to the fold: "Sir de Mesnil" now reads like "de Mesnil". Fixed by removing the title→particle chain in grouping, not by touching this rule.
-- 2026-08-16 (order-precedence keystone; #364, #365, #368) — the stage split is the decision, and the three issues are one question seen from three angles. GROUPING is vocabulary's job and is order-independent: a particle joins forward through consecutive particles and stops at the first non-particle, and no name_order moves that stopping point. ASSIGNMENT is name_order's job: groups take roles by the declared order. The bugs existed because the implementation runs the two in the opposite dependency — `assign` hands out positions from `_effective_order` and `post_rules` then inspects a fixed list of ROLES, so P1's fold sites and P2's chain had coverage that varied with the declared order by accident. Consequences, each recorded in its own right below: the fold takes only the particle's own group (#364); the middle position needs no third site once grouping is order-independent (#365); and #368 reverses.
-- 2026-08-16 #364 — the fold takes the particle RUN and the ONE name word it attaches to, not every remaining word.
+- 2026-08-16 (order-precedence keystone; #364, #365, #368) (its order-independence half superseded by 2026-08-17, below) — the stage split is the decision, and the three issues are one question seen from three angles. GROUPING is vocabulary's job and is order-independent: a particle joins forward through consecutive particles and stops at the first non-particle, and no name_order moves that stopping point. ASSIGNMENT is name_order's job: groups take roles by the declared order. The bugs existed because the implementation runs the two in the opposite dependency — `assign` hands out positions from `_effective_order` and `post_rules` then inspects a fixed list of ROLES, so P1's fold sites and P2's chain had coverage that varied with the declared order by accident. Consequences, each recorded in its own right below: the fold takes only the particle's own group (#364); the middle position needs no third site once grouping is order-independent (#365); and #368 reverses.
+- 2026-08-16 #364 (under the default order superseded by 2026-08-17, below, the one-word stop holding under a family-first order only) — the fold takes the particle RUN and the ONE name word it attaches to, not every remaining word.
   "de Mesnil Jean" is family="de Mesnil" plus given="Jean". Run,
   not particle: "de la Vega" is two particles onto one word, and an earlier wording here said "the particle", which its own example contradicted (rule-vs-decision-record review). Nothing ever argued for
   "takes everything"; it was the shape of v1's
@@ -23,7 +43,7 @@ the 2026-08-16 entries below. The survivor is the degenerate bare
   "van Mesnil Juan" gives given="van", middle="Mesnil",
   family="Juan". given="de" is the reading the vocabulary exists to forbid, and the fold is what prevents it. The all-orders agreement in P1 is deliberate and is W4's shape: a wholly-hangul name reads family="김" under every declared order because the script carries a signal the order does not override, and a leading never-given particle is the Latin-script analogue. decisions/O4 already draws the line — "Words no vocabulary has claimed read by position" — so name_order governs the unclaimed remainder, which is most inputs.
 
-- 2026-08-17 — SUPERSEDES the order-independence half of the 2026-08-16 order-precedence keystone entry above (#364, #365, #368). That entry says "no name_order moves that stopping point"; it may. Declaring FAMILY_FIRST or FAMILY_FIRST_GIVEN_LAST is precisely an assertion that what follows the family is NOT more surname, and a particle run's stopping point is exactly the question of where surname material ends — so the declaration is evidence about it, not merely about which slot the result lands in. The grouping/assignment split survives everywhere else; what is narrowed is the claim that the stopping point is one of the things order cannot touch.
+- 2026-08-17 (the reason it gives for the default-order reach superseded by 2026-09-07 #471, below) — SUPERSEDES the order-independence half of the 2026-08-16 order-precedence keystone entry above (#364, #365, #368). That entry says "no name_order moves that stopping point"; it may. Declaring FAMILY_FIRST or FAMILY_FIRST_GIVEN_LAST is precisely an assertion that what follows the family is NOT more surname, and a particle run's stopping point is exactly the question of where surname material ends — so the declaration is evidence about it, not merely about which slot the result lands in. The grouping/assignment split survives everywhere else; what is narrowed is the claim that the stopping point is one of the things order cannot touch.
   Concretely: under GIVEN_FIRST a leading particle run keeps joining to the end of the name. (This entry originally said that makes "de Mesnil Jean" read "exactly like pennie von bergen wessels — the same shape". Measured while implementing #395, that is false and is corrected here rather than left standing: pennie is the GIVEN name there, von is ambiguous so this fold can never fire on it, and the surname reading comes from P2's mid-name chain. What the real name does support is the weaker claim the argument needs — that a particle followed by several words can be all surname, "von Bergen Wessels" being one.) Under a family-first order the run stops after its first non-particle name word, because the caller has said the rest is given or middle.
   Accepted, and it is the cost that decided #364 three separate ways before this: "de la Vega Juan" under the DEFAULT order stays wholly a surname. A caller who means family "de la Vega" plus given "Juan" writes the comma. The mixed-language shapes are what make the greedy reading look wrong, and the parser cannot see language.
   Why the question kept thrashing, worth recording so a fourth attempt does not start from scratch: "how much does a leading particle run take" is a LANGUAGE judgement being forced through a POSITION heuristic, in a parser that has correctly refused to detect language (decisions/O4, rules.md's Not-in-scope). Every argument in the thread — `de`/`do` as Vietnamese surnames, `von` as German, `dos` as Portuguese — is really about which tradition the name belongs to. The order declaration is the one place a CALLER supplies that information instead of the parser guessing, which is why keying on it is better than any position rule we tried.