Skip to content

Label the CJK honorific rows for the issues they depend on - #363

Merged
derek73 merged 1 commit into
masterfrom
claude/issue-324-compound-classifications
Aug 9, 2026
Merged

Label the CJK honorific rows for the issues they depend on#363
derek73 merged 1 commit into
masterfrom
claude/issue-324-compound-classifications

Conversation

@derek73

@derek73 derek73 commented Aug 9, 2026

Copy link
Copy Markdown
Owner

Closes #324.

29 rows carried fix(#307) or fix(#308) alone while the ledger describes the same shapes as compounding with #271, and cases.py has had compound notation since #273 for exactly this pattern — one issue enables, #271 orders.

Which rows, measured

The issue warned that a blind sweep would fix one row into a different inconsistency, which is why #320 left it alone. So the dependency is measured, not assumed: re-parse each row with script_orders and segment_scripts removed — the documented way to restore 2.0's reading — then remove the HAN entry, the HANGUL entry and hangul segmentation one at a time.

rows whose asserted fields change 26 → compound with fix(#271)
rows unaffected 3 → left single-issue
rows depending on the HIRAGANA entry 0#272 appears nowhere

That last row is worth stating, because the Japanese cases look like #272 and are not: 田中 さん and 山田太郎様 key on HAN order — the name pieces are Han, and the kana is only the honorific being peeled.

The three exemptions are now deliberate

Each is a row whose note already explained why it differs; each now says so in the sweep's terms, so a future reader finds the reason in the row rather than re-deriving it:

  • latin_stem_glued_kana_honorific (Andersonさん) and latin_stem_glued_hangul_honorific (Anderson선생님) — a Latin remainder never reaches the order table
  • ko_honorific_after_comma (김민준, 씨) — the comma decides the family before segmentation would

One departure from the issue text

The issue's example string is fix(#271) + fix(#307); this uses fix(#307) + fix(#271), matching the two existing feat(#273) + fix(#271) rows. Those read causally — what creates the shape, then what orders it — and the issue's actual argument is consistency with that precedent. Easy to flip if you'd rather have #271 lead.

Scope

Labels only. classification is consumed by nothing but pytest failure messages, and nothing cross-checks it against the ledger's issue values (tools/differential/README.md calls the correspondence a convention; no test enforces it), so the sweep cannot break a guard.

Full suite 3096 passed; mypy and ruff clean; differential harness clean at 0 unexplained.

🤖 Generated with Claude Code

29 rows carried fix(#307) or fix(#308) alone while the ledger describes
the same shapes as compounding with #271, and cases.py has had compound
notation since #273 for exactly this pattern -- one issue enables, #271
orders.

Which rows, and against which issue, is measured rather than assumed.
Re-parsing each row with script_orders and segment_scripts removed --
the documented way to restore 2.0's reading -- and then removing the
HAN entry, the HANGUL entry and hangul segmentation one at a time:

  26 rows change      -> compound with fix(#271)
   3 rows do not      -> left single-issue
   0 rows depend on the HIRAGANA entry, so #272 appears nowhere

That last one is worth stating because the Japanese rows look like #272
cases and are not: 田中 さん and 山田太郎様 key on HAN order, since the
name pieces are Han and the kana is only the honorific being peeled.

The three exempt rows are the ones whose notes already explained why
they are different, and each now says so in the sweep's terms:
latin_stem_glued_kana_honorific and its hangul twin leave a LATIN
remainder, which never reaches the order table; ko_honorific_after_comma
has a comma, which decides the family before segmentation would.
Recording that is the point -- a future sweep that sees 26 compound and
3 single-issue rows should find the reason in the row, not re-derive it.

Ordering is fix(#307) + fix(#271), matching the two feat(#273) +
fix(#271) rows rather than the issue's example string, which proposes
the reverse. The existing pair reads causally -- what creates the shape,
then what orders it -- and the issue's own argument is consistency with
that precedent.

Nothing consumes these strings but pytest failure messages, and nothing
cross-checks them against the ledger's `issue` values, so the sweep
cannot break a guard.
@derek73 derek73 added the docs Documentation fixes and updates label Aug 9, 2026
@derek73 derek73 self-assigned this Aug 9, 2026
@derek73 derek73 added this to the v2.2 milestone Aug 9, 2026
@codecov

codecov Bot commented Aug 9, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.50%. Comparing base (fe4fc8d) to head (0ec6106).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #363   +/-   ##
=======================================
  Coverage   98.50%   98.50%           
=======================================
  Files          44       44           
  Lines        2883     2883           
=======================================
  Hits         2840     2840           
  Misses         43       43           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@derek73
derek73 merged commit 3a4ad24 into master Aug 9, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Documentation fixes and updates

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Case-table bookkeeping: 29 CJK honorific rows are classified single-issue where they depend on #271 too

1 participant