Skip to content

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

Merged
derek73 merged 10 commits into
masterfrom
fix/issue-828-670-family-first-fold
Nov 5, 2026
Merged

derek73 merged 10 commits into
masterfrom
fix/issue-828-670-family-first-fold

Conversation

@derek73

@derek73 derek73 commented Nov 5, 2026 •

Copy link
Copy Markdown
Owner

Under a family-first name order, rules/P1's fold takes two more pieces opening the name.

A lowercase ambiguous particle in a mixed-case name (#670, new rules/P11). The order has already settled that the opening slot is the family. The writing settles whether the particle is a one-word surname or the start of one.

name_order=FAMILY_FIRST before (2.0.0–2.8.0) now
van den Berg Cornelia family van, given den Berg Cornelia, reported family van den Berg, given Cornelia, no report
Le Van Thanh family Le unchanged (capitalized)
VAN GOGH VINCENT family VAN unchanged (one case)
le Van Thanh family le family le Van Thanh (accepted, rules/P11)

The default order is unchanged: van Gogh still reads given van. Folding a capitalized run of two or more particles (#670's third question) is declined, because Le Van Thanh is that shape. Both family-first orders are covered.

A particle chain behind a title-particle, cut as the run is (#828, rules/P1 and P4's Except). St de Mesnil Jean family-first gives family de Mesnil, given Jean, as Dr. de Mesnil Jean reads. Before, it gave family de Mesnil Jean.

The chain is left whole in three cases:

Measured

On 2026-11-04, against origin/master c620754. Recipes are in decisions/P1 and decisions/P11.

Also in the diff

  • When a report's other reading would join a chain the fold cuts, assemble now names the field that reading lands in (Freiherr von J. ma).
  • _state gains reported_suffix_fork and the private PAST_REACH_TAG, so post_rules' decline and assemble's alternative ask one predicate over the same words.
  • config_diff.py's expr: scope holds the three name orders. The recipes in decisions/P1 and decisions/P11 name FAMILY_FIRST and raised NameError as written; a test now holds the scope.
  • Rule examples that used lowercase van under family-first (O6, R11, P6) now use Van, which keeps what each example tests.
  • Docs: root AGENTS.md's particles paragraph, customize.rst, and the vocabulary-model 4h entry's head note.

Reviewed by a code review and a design-docs review, with each fix commit reviewed again (the first fix keyed the decline on suffix vocabulary and over-fired; it now reads the report), then a comment-accuracy review and a mutation-based test-coverage review. 3.11 and 3.15 suites and the serial benchmarks pass.

Synced with #1064's ranks (master e599289): three rows in test_family_first_fold_reads_the_writing_and_the_chain show the cut reaching Graf, Gräfin and Prinz, each failing on master. snapshot.jsonl, corpus_rules.jsonl and rules_budget.json are re-recorded; the snapshot gains no move from the ranks.

Closes #670
Closes #828

🤖 Generated with Claude Code

derek73 and others added 4 commits November 4, 2026 15:24
…ly-first name (#670, #828)

Under a family-first order rules/P1's fold now takes two more pieces
opening the name:

- an ambiguous particle written in lower case in a name of mixed case
  (new rules/P11): `van den Berg Cornelia` gives family 'van den Berg',
  given 'Cornelia', where it gave family 'van'; the particle-or-given
  report goes there. A capitalized one (`Le Van Thanh`) or a name in
  one case keeps its reading.
- a particle chain behind a title-particle (rules/P4's Except), cut as
  the run is: `St de Mesnil Jean` gives family 'de Mesnil', given
  'Jean', as `Dr. de Mesnil Jean` reads.

Assemble names the field a report's other reading takes behind the cut,
and a field-naming report whose words the cut parts reads "the name".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…#828, #670)

The code review found the family-first cut stranding a word group's
trailing read had decided against the whole chain (`St de Mesnil Jean
V` read middle 'V' under a report saying no word was left to spare):
the cut now declines where a word past the fold's reach carries suffix
evidence, the tags assemble reads a suffix's source by, moved to
_state as SUFFIX_EVIDENCE so both ask one question. The "the name"
wording that only those shapes reached goes with them.

The design review found P11 and H1 stating no precedence (`Sir van
Berg` folds, `Sir abu Bakar` stays H1's), P1's Then contradicted by a
boundary example and by its own ambiguous-particle sentence, the
vocabulary-model 4h entry still calling the reading unweighed, and a
customize.rst sentence its successor refuted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…in whole (#828)

The fix commit's review found the decline keyed on suffix-vocabulary
tags over-firing: `St de Mesnil Junior Jean`, `St de Mesnil Jean J. V`
and 4,840 of an 8,320-name grid kept the whole chain though the read
reported nothing about the word. The decline now asks whether a
suffix-or-name report names a word past the fold's reach
(`_state.reported_suffix_fork`), and assemble's alternative asks the
same predicate over the same words, marked by post_rules with a private
tag, skipping the report it names: the first fix's wider range misnamed
the field for `St Mc Mesnil VI`. `SUFFIX_EVIDENCE` returns to assemble.

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

The comment review found `_lead_folds`, `_family_settled`, the P1
citation block and `reported_suffix_fork` describing an earlier round's
mechanism or only the never-given site, and an unattributed quote. The
test review found three mutations of the alternative's computation that
no test caught (the PAST_REACH tag write, the all-particle chain guard,
`alone`'s lower bound) and no row for the suffix-comma shape: rows for
each, and a direct test with a recorded negative control for the
two-report shape the stand-in oracle cannot check.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@derek73 derek73 added this to the 3.0 milestone Nov 5, 2026
@derek73 derek73 self-assigned this Nov 5, 2026
derek73 and others added 6 commits November 4, 2026 17:06
)

CI's call-count band failed on Python 3.12-3.15 (294.0 calls/name
against a ceiling of 293.76): `_lead_folds` put a frame on every parse
to ask the never-given test it had always asked inline. The callers ask
it inline again and enter `_family_first_lead_folds` only under a
family-first order, so the reference row costs what master's does
(293.72 on 3.13, 312.72 on 3.11).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…#670)

Codecov's patch check found the helper's own order gate unreachable:
the fold site tests the order before calling it, so only H1's
`_family_settled` could reach the gate, and no input did. That caller
tests the order inline too, and the helper loses the dead branch.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…amily-first-fold

# Conflicts:
#	tests/v2/rules_budget.json
…amily-first-fold

# Conflicts:
#	nameparser/_pipeline/_assign.py
#	tests/v2/test_cases.py
…amily-first-fold

# Conflicts:
#	docs/release_log.rst
#	tests/v2/rules_budget.json
…#670)

The ranks #709 made title-particles reach the family-first cut, as
freiherr does: three rows, each failing on master at e599289. The
recipes in decisions/P1's #828 entry and decisions/P11's #670 entry
named FAMILY_FIRST in an expr:, which config_diff.py's scope did not
hold, so neither ran as written; the scope now holds the three orders,
with a test. Run under the fixed recipe, the 44 corpus names holding a
rank read alike in both trees.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@derek73
derek73 merged commit 0c37419 into master Nov 5, 2026
13 checks passed
@derek73
derek73 deleted the fix/issue-828-670-family-first-fold branch November 5, 2026 05:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

1 participant