docs(rules): a conjunction-joined run is one name word

P3 already says a connective binds name words into one part; what it
did not say is how OTHER rules count that part. They count it as one.
The case that forced the question is #395, where P1's run must stop
"after the first name word" and would otherwise be free to stop
INSIDE a part P3 built, splitting "de la Vega y Santos Juan" between
"Vega" and "Santos".

The clause describes shipped behavior, not an aspiration: H1 counts
this way today, so the examples are the H1 pair —

    "Mr. Jack and Jill"  ->  family="Jack and Jill"
    "Mr. Jack Jill"      ->  given="Jack"          (boundary)

decisions.md#P3 records the clause and how it was nearly shipped as an
unexaminable one: the first draft asserted no rule could show it and
carried an Accepted note saying so, having reasoned about which rules
count rather than parsing a name.

Refs #395

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: derek73

docs/design/decisions.md

@@ -197,6 +197,7 @@ Open: [#348](https://github.com/derek73/python-nameparser/issues/348) applying C
 ### P3 — connectives
 
 - 2026-07-30 #267 — the four-word single-letter asymmetry: a bare Latin capital connective is vetoed as an initial while a Cyrillic capital joins. #267's closure ("v2.0 behaves this way by default … verify it was the right call") showed only the Cyrillic half; the Latin-capital veto was never separately adjudicated, which rules.md#P3 records as an Accepted consequence.
+- 2026-08-17 — a conjunction-joined run counts as ONE name word in every rule that counts them. Raised while bounding the leading particle run (#395): a run that stops "after the first name word" would otherwise be able to stop INSIDE a part P3 built, splitting "de la Vega y Santos Juan" between "Vega" and "Santos". This is not new behavior — H1 already counts this way, measured: "Mr. Jack and Jill" gives family="Jack and Jill" while "Mr. Jack Jill" gives given="Jack", family="Jill". What is new is that rules.md says so, which is what binds #395's implementation. Recorded because the first draft of the clause asserted that no rule could show it today and shipped an Accepted note to that effect; the shipped H1 pair was simply never run. Detector failure of the usual shape — reasoning about which rules count instead of parsing a name and looking.
 
 Open:
 [#383](https://github.com/derek73/python-nameparser/issues/383)

docs/design/rules.md

@@ -150,16 +150,25 @@ P3. Rationale: connective words ("y", "of the") bind name words into
     connective runs included — except a single-letter connective in
     a three-word name, which stays a name word, and a single-letter
     connective written as a bare Latin capital, which reads as an
-    initial and never joins.
+    initial and never joins. The joined part is ONE name word
+    wherever another rule counts them, so a rule taking "one name
+    word" takes the whole join and never half of it.
       "Juan y Eva Garcia"         →  given="Juan y Eva"
       "Jose E Maria Santos"       →  middle="E Maria"
       "Juan y Garcia"             →  middle="y"  · boundary
+      "Mr. Jack and Jill"         →  family="Jack and Jill"
+      "Mr. Jack Jill"             →  given="Jack"  · boundary
     Accepted: the initial veto is a LATIN shape — a Cyrillic
     capital joins ("И".isupper() is true, so this is not a
     Unicode-uppercase rule); #267's closure blessed the Cyrillic
     side, and whether the Latin-capital half should stand is #383.
       "Хосе И Мария Сантос"       →  given="Хосе И Мария"
-    history: decisions.md#P3 · implemented: nameparser/_pipeline/_group.py
+    H1 is the counting rule that shows the one-word clause today: a
+    title plus the join reads the whole join as the family, where the
+    same two words unjoined are two name words and H1 does not fire.
+    P1's leading run becomes the second once #395 lands — its run
+    must take the "Vega y Santos" join whole or stop before it.
+    history: decisions.md#P3 · interacts: H1, P1 · implemented: nameparser/_pipeline/_group.py
 
 P4. Rationale: a particle links forward from inside a name; at the
     very front there is no name yet to be inside.