fix(replace): tracked span inside another author's insertion splits it Word-style

[kklimuk]

🤖 docx-cli triage

Replaces #15 (closed): a from-scratch, narrowly gated fix instead of the rewrite.

What was wrong

replace --track --author Editor (and edit --at pN:S-E --track) on text inside Reviewer A's pending <w:ins> left the replacement as a bare run inside A's insertion, so Word credited it to A. If A's insertion also held Reviewer B's nested <w:del> before the match, the cut slid left by its length and the wrong words were deleted:

$ docx replace nested.docx "disputed amount" "disputed sum" --track --author Editor
replace 1 occurrence replaced          # but "The Client may " was deleted, match untouched

What changed

• One gate, one new file. replaceSpanInParagraph gets a single early branch: under tracking, when a non-empty span lies wholly inside a <w:ins>/<w:moveTo> that is a direct child of the paragraph, it dispatches to src/core/find/replace-in-revision.tsx (new, ~250 lines). Every other input runs the existing code untouched.
• Different author: Word's shape. The cut becomes Editor's <w:del> nested inside A's insertion; the replacement is Editor's own <w:ins> as a sibling; A's tail continues in a copy with a fresh w:id (same author/date). Nested children (B's deletion, bookmarks, comment markers) keep their position and are never re-wrapped; a tail holding only markers isn't minted as a revision.
• Same author (your decision): no split, no <w:del>; the text is edited in place inside the existing <w:ins> (same id/date). Zero-width anchors in the cut (footnote/comment references, images, text-box anchors) survive; counted characters (a matched tab) go with the text; a comment range that opened in the cut brackets the replacement. Exact string match on w:author. An author's own <w:moveTo> takes the split path (moved text is relocated original text, not new words).
• revN pairing (cli/track-changes/groups.ts, +1 condition): a del+ins pair must share an author, so A's head insertion no longer pairs with Editor's nested deletion into one acting handle.

How it works

flowchart TD
  A[tracked span, all runs under one parent] --> B{parent is w:ins / w:moveTo directly in the paragraph?}
  B -- no --> C[existing code, byte-identical to main]
  B -- yes, other author --> D[nest Editor w:del in it · Editor w:ins beside it · tail copy with fresh id]
  B -- yes, same author, w:ins --> E[edit in place inside the insertion, keep anchors]

Loading

Verification

• Issue cases 1 and 2 now produce exactly the expected XML; read --accepted → "Fees are due. The Client may withhold disputed sum."; B's deletion byte-identical; all outputs pass docx validate. Same-author case → one insertion, may withhold a disputed sum.
• Golden comparison vs main: 18 commands × 36 fixtures (untracked/tracked replace, --all, span edits, empty-span inserts, --current/--baseline, hyperlinks) = 648 runs; 636 byte-identical, and all 12 differing runs are gated cases (tracked matches inside an existing insertion/move in tracked-changes, multi-tracked, tracked-moves). track-changes list over all fixtures: 72/72 identical.
• bun run check ✅ bun run test:unit ✅ (1740 tests, +16 new, no existing expectation changed).
• Three independent /code-review xhigh passes on the full diff: no regression against main found in any pass. Every finding inside the new path was fixed (anchors, moveTo, phantom tail, revN authors, counted characters, range ordering, page-break marker).

Pre-existing issues the reviews surfaced (deliberately NOT touched here)

Each can be its own issue; say which you want filed:

• rebuildContainer starts its offset walk at the first overlapping run, so an untracked replace whose match is not in a wrapper's first run (multi-run <w:ins>, multi-run <w:hyperlink>) still cuts the wrong words. This is the real root cause of the offset half of replace --track inside another author's pending insertion credits the new text to that author, and misses the target next to a nested deletion #13; the gated path computes the start correctly only for the tracked case.
• A tracked empty-span insert inside another author's insertion is still credited to them and emits an empty <w:del>.
• A tracked replace with an empty replacement mints an empty <w:ins> (lists as → ¶).
• A span crossing an insertion boundary gives both halves the same w:id (same family as Untracked replace across a hyperlink nested in another author's insertion corrupts text and duplicates w:id #16).
• track-changes list labels any text-less run-level revision as ¶ paragraph mark; accepting a nested deletion leaves an empty outer <w:ins> shell.
• No LibreOffice fixture for the new shape: adding one to multi-tracked.docx would change its toHaveLength(6) expectation.

Decisions for you

• Which of the pre-existing items above to file as issues (I'd start with the first).

Fixes #13

🤖 Generated with Claude Code

https://claude.ai/code/session_012GoxD36rnNfg6uArkVxtJL

---

Generated by Claude Code