Custom tracked-changes XML engine replaced with docx-track-changes library wrapper
becker-charles proposes retiring Mike's 1,179-line bespoke tracked-changes implementation in favor of a ~370-line wrapper around the `docx-track-changes` library. The more consequential part is switching from fuzzy text-snippet matching to paragraph ID addressing, which eliminates the wrong-location problem when similar phrasing repeats in a document.
The custom tracked-changes engine in Mike does its own XML manipulation, pulling in fast-diff and fast-xml-parser to support it. becker-charles's proposal drops both dependencies and replaces the 1,179 lines with about 370 lines of glue around docx-track-changes.
The more interesting change is how edits are located in the document. The current approach fuzzy-matches on the edit snippet plus surrounding context. That works when the document text is unique but fails silently when similar phrasing repeats - the edit lands at the wrong paragraph. This PR mints stable paraId values the first time a document is read and persists them. Every accept/reject operation then addresses the target by that ID directly. A missing ID produces a clear error rather than a wrong-location silently applied.
A stale-preview bug is fixed alongside: the refetch key wasn't being bumped after accept/reject, so the preview pane showed old content. That fix rides as part of the same refactor.
The commits listed are empty (zero diffs recorded in this topic), so this is a proposal or a PR without landed commits. Treat with corresponding skepticism about its current state.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?