[johnml1135]

Start here: src/SIL.Machine.Morphology.HermitCrab/MorphologicalRules/SynthesisAffixProcessAllomorphRuleSpec.cs, ApplyRhs: one block of code moved below a loop.

Status: stacked on #556 — merge in order #556 → #500 → #480 → #578.

Status: open since 2026-09-14. An automated review (claude) asks for changes: marking the last shape node after the loop moves that node from the wrapped morph to the zero-width rule, so the wrapped morph loses its last segment (F1); the fenos test passes if any one of 100 loads is right (F2); and test comments point at code absent from this repo (F3, F4). No CI check is red (claude-review was skipped; code-review/reviewable is pending).

When a zero-width rule (such as a copy-only CopyFromInput) wraps another rule's affix and both mark the same trailing shape node, the wrapped morpheme ID was dropped. ApplyRhs now marks the zero-width rule's last node after the loop that re-marks wrapped input morphs, so the wrapped ID sticks and the outer rule's ID sorts after it.

Reviewers arrive asking whether the regression test is deterministic. It is not: the fix makes the correct signature reachable in 41 of 100 fresh language loads in an earlier measurement, and 0 of 100 with the fix reverted. The rest trace to a separate, unfixed ordering defect (#506, open; #556 addresses its tie-boundary mechanism and is open). The question worth your time is F1: does the node move cost the wrapped morph its last segment in a case the tests do not cover?

Where to look:

• ApplyRhs: the outputNewMorph == null marking now runs after the loop. Pinned only by the tests below.
• IdentityRuleSignatureMorphDropTests: controls Fen_BareRootControl_IdentityWrapsRootDirectly_StableAndCorrect and Feno_NoIdentityRuleApplies_StableAndCorrect are deterministic. Fenos_IdentityWrapsOutermost_IsFlakyPendingASeparateOrderingDefect retries up to 100 fresh loads and passes on the first correct signature.

Not here: the ordering defect behind #506, which keeps the regression from passing on every attempt.

Verification: build, the HermitCrab tests, csharpier and the comment-hygiene script passed when the PR was opened; counts are not recomputed here and nothing was rerun for this description.

Next: author to answer F1 (with a test, or a reason the lost segment is harmless), then re-request review.

---

Reading this a year from now -- start here

ApplyRhs marks morphs on the output shape in two places: a fallback for rules with no new output morphs (truncation and zero-width rules), and a loop that re-marks each input morph the rule wraps. When a zero-width rule's own affix and an inner wrapped rule's affix end at the same trailing shape node, whichever call runs second keeps that node's morpheme ID. The fallback used to run first, so the outer rule's ID could overwrite or precede the wrapped rule's. Moving it after the loop makes the wrapped rule's ID stick and the outer rule's ID sort after it, matching the order IdentityRuleSignatureMorphDropTests expects.

Decisions, and why

The fenos test retries up to 100 fresh loads and passes on the first correct signature. Measured earlier: 41/100 correct with the fix, 0/100 with it reverted. Asserting every attempt would be red even with the fix; a single assertion would be flaky. Retry-until-first-success is the one assertion the data supports, and it goes red with the fix reverted. The cost is that it stays green if the fix works only once in 100 (F2).

Paths not taken

An earlier comment blamed BidirList's unseeded skip-list levels. The source does not support that: same-range annotations tie-break on Annotation.ListID, a call-order counter. The claim was removed.

Deferred

Making every fresh parse deterministic needs the ordering defect in #506 fixed first. Whether #556 is enough is not established; the cause of the per-run variation is not yet identified.

Surprising findings

An earlier revision reported "five green repetitions; suite 575 passed, one skipped, zero failed" and a seed experiment claiming 12/12 repeatability versus three unseeded outputs, attributed to forcing a fixed seed on BidirList's Random. Those numbers were not reproduced and the causal claim did not hold against the source; the 41/100 and 0/100 counts replace them.

🤖 Generated with Claude Code

---

This change is

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.57%. Comparing base (74ee09b) to head (857313b).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #500   +/-   ##
=======================================
  Coverage   74.57%   74.57%           
=======================================
  Files         453      453           
  Lines       38314    38314           
  Branches     5280     5280           
=======================================
+ Hits        28573    28574    +1     
  Misses       8576     8576           
+ Partials     1165     1164    -1     

☔ 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.

[claude]

Minor: F1. The wrapped morph now loses its last segment. MarkMorph re-parents node annotations (AnnotationList.Add calls node.Remove(false)), so marking Shape.Last after the loop moves that node from the wrapped morph to this zero-width rule. For fen + IDENT, the root morph keeps f e and IDENT takes n; for fenos, QTOP keeps no nodes. Before this change, the zero-width morph was the one left empty, which fits a rule that adds no segments. Traced through the code, not run.

[claude]

FYI: F2. This test passes if any one of 100 loads gives the right signature, so it stays green even if the fix works only 1 time in 100. AGENTS.md asks for deterministic fixtures. That is fine as a stopgap if this becomes an every-attempt assertion once #506 is fixed.

[claude]

FYI: F3. These comments point to code that does not exist in this repo: ConformanceMorpherFactory.Create and useMemoization here (the memo was removed in #522), and BatchCommand.BuildSignature at line 110. A grep over src and tests finds none of the three.

[claude]

FYI: F4. Measured: ... 41/100 ...; reverted, 0/100 records history and will go stale after the next change. .claude/skills/code-comments/SKILL.md rules out history in comments, and the PR body already has these numbers.

[claude]

1. Verdict: request changes.
2. Most important: F1 at src/SIL.Machine.Morphology.HermitCrab/MorphologicalRules/SynthesisAffixProcessAllomorphRuleSpec.cs:206. The reorder changes which morph loses the shared last node; it does not stop the loss. The wrapped morph now gives up its final segment (for example, the fen root keeps only fe). The next rule rebuilds morphs from each node's owning morph (line 151), so the shortened range would also reach the right-environment check in AllomorphEnvironment.cs:93 (unverified). A real fix probably needs a way to attach a zero-width morph without taking a node from the morph it wraps.
3. Counts: Critical 0, Important 1 (F1), Low 3 (F2-F4).
4. What I ran: dotnet test on the HermitCrab tests filtered to IdentityRuleSignatureMorphDropTests: 3 passed. The full HermitCrab test project: 153 passed, 0 failed. gh pr checks 500: both builds pass; the advisory comment-hygiene check passes, which is not the strict scan.
5. Not verified: I did not run F1. This session could not write a scratch program, so I traced it through Word.MarkMorph and AnnotationList.Add. I did not re-measure the 41/100 rate on the current base, which now includes Remove HermitCrab's analysis-cascade memo #522.

Public API, target frameworks, packages, and sillsdev/machine.py parity: None verified.

Findings: F1 new, unverified (traced, not run); F2 new; F3 new; F4 new.

Reviewed at 157c031