Repository navigation
Case-table bookkeeping: 29 CJK honorific rows are classified single-issue where they depend on #271 too #324
Description
Activity
- added a commit that references this issue
on Aug 5, 2026 Part 2 (the wrong gate name) is fixed on master in 88ca0b3. Part 1 remains, and the issue is retitled to cover only it.
Recording that part 2's repro no longer reproduces. The issue argued the gate was misnamed because "before #320,
is_suffix_lenient("씨.")was alreadyTrueand씨.still went togiven". #320 has since landed and김민준, 씨.now gives suffix씨., so anyone trying that demonstration will not see it.The conclusion was right anyway, by a negative control instead:
김민준, 씨 → family 김민준, suffix 씨 김민준, 태호 → family 김민준, given 태호 ← default post-comma reading lenient_comma_suffixes=False → row unchanged ← so the lenient gate is not what admits it씨classifies withvocab:suffix+vocab:suffix-word, the structure isFAMILY_COMMA, and_group._is_suffix_piece(_group.py:72-79) diverts the single-token piece out of the given-name position.lenient_comma_suffixesis not on the path.Worth keeping in mind for part 1: the wrong name was plausible because both gates are real, both concern suffixes, and both sit on the post-comma side — the note described the mechanism that genuinely handles the neighbouring Latin case (
John Ingram, V). Checking these by reading will not separate them; flipping the policy the claim depends on will.Scope of what's left. 29 rows carry
classification="fix(#307)"or"fix(#308)"; 2 rows in the whole table use compound notation today, both in the nickname block. So this is not 29 typos — it is a convention that never propagated out of the block where it was invented. It wants a stated rule (every row whose asserted fields depend on #271's segmentation and its order flip getsfix(#271) + ...) applied as a sweep, with the dependency measured per row rather than assumed from the row's shape. Fixing rows one at a time creates a third inconsistency, which is why #320 declined to.- changed the title
[-]Case-table bookkeeping: compound classifications and one note naming the wrong gate[/-][+]Case-table bookkeeping: 29 CJK honorific rows are classified single-issue where they depend on #271 too[/+]on Aug 5, 2026 - added a commit that references this issue
on Aug 22, 2026
tools/differential/expected_since_1.4.0.tomldescribes the CJK honorific rules as compounding with the #271 order flip.tests/v2/cases.pylabels the same rows single-issue (fix(#307),fix(#308)).Compound notation exists and is already used —
feat(#273) + fix(#271), twice, in the nickname block for precisely this shape (one issue enables, #271 orders). So the honorific block is inconsistent with both the toml and its own table's precedent.Rows like
ko_honorific_ssi(김민준 씨) depend on #271's segmentation and family-first order to reach their asserted fields, and sayfix(#307)alone.fix(#271) + fix(#307)would be strictly more honest.This is a block-wide sweep rather than a one-row edit, which is why #320 left it alone rather than fixing one row into a different inconsistency.
Found during the #320 review. Does not affect behavior; it misleads a reader tracing why a row lands where it does.
Re-verified 2026-08-09 against
master(d910709)The count in the title is still exact, and the reasoning is now better supported than when filed.
fix(#307), 19 ×fix(#308).feat(#273) + fix(#271).ko_honorific_ssiasserts{family: 김, given: 민준, suffix: 씨}, and its own note now states the dependency the label omits — "the name still segments (suffix classification runs after the script_segment stage, which only ever saw 김민준)". Reachingfamily: 김/given: 민준requires Unspaced Chinese/Korean names: surnames constants + longest-match segmentation #271's hangul segmentation. The row documents in prose what itsclassification=field leaves out.Nothing enforces the correspondence between
cases.pyclassifications and ledgerissuestrings —tools/differential/README.mddescribes it as a convention, and no test checks it. So the sweep cannot break a ledger guard, and it is independent of #328 (which is about a ledger rule's reach exceeding its prose, a latent safety hole, rather than a label understating its dependencies).What was removed from this issue
A second item —
ko_honorific_after_comma's note namingis_suffix_lenientwhere the real gate is_group._is_suffix_piece— has been fixed and is dropped. The note now reads:It names the right gate, records that an earlier note was wrong, and measures the counterfactual. (
is_suffix_lenientdoes still exist, atnameparser/_pipeline/_assign.py:351— the old note named a real function, just not the one that decides this row.)