Repository navigation
Dr. Smith née Jones reports no family name — a maiden name suppresses the title-plus-one-word rule #410
Description
Adding a maiden name to a title-plus-surname name moves the surname into given and empties family:
Dr. Smith -> title='Dr.' family='Smith'
Dr. Smith née Jones -> title='Dr.' given='Smith' family='' maiden='Jones'
Same for the particle spelling, which is how it was found:
Freiherr von Richthofen -> title='Freiherr' family='von Richthofen'
Freiherr von Richthofen geb. Albrecht -> title='Freiherr' given='von Richthofen' family='' maiden='Albrecht'
The name plainly has a family name in both readings, and the maiden name is reported correctly. Only the family field is lost.
Why
rules.md#H1 reads a title followed by exactly one name word and nothing else as title-plus-family. It is gated on not others in _post_rules.py, and a token in Role.MAIDEN counts as others — so the presence of a maiden name makes H1 decline, and the surname falls through to the given slot.
The maiden name is not part of the name-proper the way a middle name is; it is a second name announced by a marker. H1's "nothing else" is meant to exclude further name words, and a maiden name arguably is not one.
Scope
Pre-existing, and unchanged by #399 — Dr. Smith née Jones behaves identically at 2.1.0. What #399 changed is reach: stopping the particle chain at the marker routes the canonical title-and-particle shape (Freiherr von Richthofen, named as such in _group.py) into the same gate for the first time. A review sweep put it at roughly 120 of 4800 constructed inputs.
Both the delimited and bare marker forms are affected, and all three name orders.
Worth deciding
Whether H1's others test should ignore Role.MAIDEN tokens, or whether a title-plus-one-word name that also carries a maiden name is genuinely outside H1's scope and should be reported some other way. rules.md#M2 gained interacts: P2, P3, P5, R2, M1 in #409 and does not name H1; if the answer is that they interact, that pointer should exist.
Activity
docs(maiden): point M2's accepted limits at the issues that track them
test(maiden): pin what the reorder's record claimed, from review
derek73 commentedon Aug 26, 2026
Measured before fixing (1.4.0 and 2.1.0 from PyPI wheels, master at b244c5a): this is not maiden-specific.
othersat_post_rules.py:177tests(SUFFIX, NICKNAME, MAIDEN), and all three suppress H1 identically:Dr. Smithlast='Smith'family='Smith'Dr. Smith née Jonesfirst='Smith'middle='née'last='Jones'given='Smith'family=''Dr. Smith PhDfirst='Smith'last='PhD'given='Smith'family=''Dr. "Smitty" Smithfirst='Smith'last=''given='Smith'family=''So the answer to "should H1's
otherstest ignoreRole.MAIDEN" is that it should not test roles at all: H1's rationale is that a title addresses by surname, which says nothing about what stands beside the name. The suffix and nickname flavors are fixed with it and need no separate issues.Two things worth recording for whoever reads this later. The v1 suite already carried the nickname reading as a strict xfail (
tests/test_nicknames.py::test_nickname_and_last_name_with_title), so the correct answer was written down and marked unreachable. And N3 moves without changing:'Smitty' Dr. Jonesdeclines N3's one-piece count as it always did, and H1 now names the family behind it —given 'Jones'through 2.1,family 'Jones'now. That interaction was carried by no test and no rule example, so nothing would have caught it; it is now an N3 example line.Fixed in #444.
docs(post_rules,decisions,release_log,differential): the toolkit revi…
docs(decisions): unwrap the new entries to the file's one-line-per-pa…
Merge pull request #444 from derek73/fix/410-h1-name-words
fix(differential,guards,decisions): the five defects the PR review co…
fix(post_rules,rules,decisions): H1 counts name words, not annotations
docs(decisions,release_log): record what H1's widening decided
docs(rules,release_log): point the one-word maiden shape at derek73#445
docs(decisions,release_log): record the lone-word rule
fix(differential,guards): narrow three 1.4.0 rules to the roles they …
feat(differential): over_declared_rules, the check for a rule wider t…