Skip to content

docs(docxdiff): PreserveInputRevisions models Word's Combine, not Compare (#867) [stack 1/9] - #912

Merged
JSv4 merged 1 commit into
mainfrom
docs/867-front-door-preserve-wording
Oct 4, 2026
Merged

JSv4 merged 1 commit into
mainfrom
docs/867-front-door-preserve-wording

Conversation

@JSv4

@JSv4 JSv4 commented Oct 3, 2026

Copy link
Copy Markdown
Owner

Why

Issue #867 reported that CLAUDE.md said the DocxCompare front door both pre-accepts and preserves input revisions, while the code only pre-accepts. The code is the intended behaviour. The decision was made and recorded in #845 (PR #886), which also fixed CLAUDE.md and the DocxCompare comments.

The same wrong claim was still in other places. It said that keeping each input's own tracked changes (PreserveInputRevisions) is "Word Compare's own behavior", and those places are what a caller actually reads:

  • the public XML documentation on DocxDiffSettings.PreserveInputRevisions (in IntelliSense);
  • the revisionsInInput note in the DocxDiffCompatibility catalog, which the API returns at runtime;
  • the npm (types.ts) and Python (types.py) docstrings ("Word-style");
  • ir_diff_engine.md and two sections of ooxml_corner_cases.md. One of those labelled preservation the Docxodus default, which it is not.

What changed

Wording only. Each place now says that preserving input revisions is what Word's Combine does. Word's Compare treats them as accepted, which is what PreAcceptInputRevisions and the DocxCompare front door do. No behaviour, setting, or default changes. Historical CHANGELOG entries are left as written; a later entry already notes the policy change.

Validation

  • dotnet build Docxodus/Docxodus.csproj: clean.
  • Existing tests already pin the decided behaviour, so no new tests were needed:
    • DocxCompareTests.FrontDoorPolicy_* asserts the front door leaves PreserveInputRevisions false.
    • DocxCompareOriginalPendingRevisionsTests pins the output.
  • grep for "Word-style", "Word-parity" and "Word's Compare" near preserve wording across the core, the bridges, the clients and the docs finds no remaining claim.

Adversarial review

One adversarial pass over the diff. It found the catalog note in DocxDiffCompatibility.cs, which is runtime-visible and repeated the claim; it is now fixed. It also checked that the old corner-cases heading isn't linked from anywhere before renaming it.

Closes #867

🤖 Generated with Claude Code

…pare (#867)

The front door was corrected with #845; the setting's own XML docs, its
compatibility-catalog note, the npm/Python docstrings and two corner-case
sections still called preservation Word's Compare behaviour.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CLAUDE.md says DocxCompare applies PreserveInputRevisions; the code applies only PreAcceptInputRevisions

1 participant