deps: bump the dev-dependencies group across 1 directory with 14 updates

[dependabot]

Bumps the dev-dependencies group with 14 updates in the / directory:

Package	From	To
@testing-library/jest-dom	6.9.1	7.0.0
@types/node	25.9.5	26.1.2
@vitejs/plugin-react	6.0.3	6.0.5
docxodus	7.0.1	8.0.0
eslint	10.7.0	10.8.0
globals	17.7.0	17.8.0
jsdom	29.1.1	30.0.1
react	19.2.7	19.2.8
@types/react	19.2.17	19.2.18
react-dom	19.2.7	19.2.8
@types/react-dom	19.2.3	19.2.4
typescript	6.0.3	7.0.2
typescript-eslint	8.63.0	8.65.0
vite	8.1.4	8.2.0

Updates @testing-library/jest-dom from 6.9.1 to 7.0.0

Release notes

Sourced from @​testing-library/jest-dom's releases.

v7.0.0

7.0.0 (2026-07-20)

Features

• add toContainAnyBy* and toContainOneBy* query matchers (1e39089)

BREAKING CHANGES

• @​testing-library/dom is now a required peer dependency. The minimum supported Node.js version is now 22.

Repaired release for testing-library/jest-dom#731

v6.10.0

6.10.0 (2026-07-20)

Features

• add toContainAnyBy* and toContainOneBy* query matchers (#731) (cae44df)

Commits

• 1e39089 feat: add toContainAnyBy* and toContainOneBy* query matchers
• cae44df feat: add toContainAnyBy* and toContainOneBy* query matchers (#731)
• 55c07ce ci: switch release to npm trusted publishing (#726)
• 213256f docs: move toHaveSelection from the deprecated section (#717)
• See full diff in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for @​testing-library/jest-dom since your current version.

Updates @types/node from 25.9.5 to 26.1.2

Commits

• See full diff in compare view

Updates @vitejs/plugin-react from 6.0.3 to 6.0.5

Release notes

Sourced from @​vitejs/plugin-react's releases.

plugin-react@6.0.5

Fixed the react compiler preset filter to be linear (#1353)

The improved filter in v6.0.3 was non-linear and caused a performance regression (#1349). The filter was changed to be linear to avoid that.

plugin-react@6.0.4

Fixed $RefreshSig$ is not defined error when running vite dev with NODE_ENV=production

When running vite dev with NODE_ENV=production, the app errored with $RefreshSig$ is not defined. This error is now fixed.

Changelog

Sourced from @​vitejs/plugin-react's changelog.

6.0.5 (2026-07-30)

Fixed the react compiler preset filter to be linear (#1353)

The improved filter in v6.0.3 was non-linear and caused a performance regression (#1349). The filter was changed to be linear to avoid that.

6.0.4 (2026-07-22)

Fixed $RefreshSig$ is not defined error when running vite dev with NODE_ENV=production

When running vite dev with NODE_ENV=production, the app errored with $RefreshSig$ is not defined. This error is now fixed.

Commits

• 68c0cb8 release: plugin-react@6.0.5 (#1362)
• 555cdbc fix(react): make the react compiler preset filter linear (#1353)
• a00a9f8 fix(deps): update all non-major dependencies (#1327)
• f4b5498 release: plugin-react@6.0.4
• 7a40659 fix(react): $RefreshSig$ is not defined with NODE_ENV=production vite dev ...
• 98b32d4 fix(deps): update react 19.2.8 (#1298)
• 8ae5449 fix: babel-plugin-react-compiler cannot be imported when used in a framework ...
• f09ea01 fix(deps): update all non-major dependencies (#1282)
• See full diff in compare view

Updates docxodus from 7.0.1 to 8.0.0

Release notes

Sourced from docxodus's releases.

v8.0.0

Major release rolling up all changes accumulated since v7.1.0. Full details in CHANGELOG.md.

Highlights

• Visual header/footer editing region in the browser DocxEditor (#275, #293). Opt in with headerFooter: true and the editor docks a Header band above the body flow and a Footer band below it. Because header/footer stories live in their own OOXML parts outside the body, each band is composed per story paragraph via the session-attached RenderBlockHtml — the same renderer the post-edit incremental swap uses, so first paint and repaint cannot drift, and there is exactly one addressable node per story paragraph in both continuous and paginated mode. Story paragraphs are wired by the same wireBlock the body uses, so the whole existing ribbon works inside a band with no new command code, and only the edited band repaints. Band chrome adds a default/first page/even pages kind selector and a currentPage/totalPages page-number control.
• DocxDiff cross-paragraph token streams and gap-region streams (#291). A run of adjacent word-matched paragraph pairs now diffs as ONE token stream: retained words may cross pilcrow boundaries and paragraph marks are ¶INS/¶DEL stream tokens, so the output paragraph count follows the token-level interleave — the arrangement decoded from Word's own compare output. Generalized to replace regions without a full pair run. Markup-only; accept ≡ right / reject ≡ left holds pilcrow-exactly.
• DocxDiff: PreserveInputRevisions — Word-parity preservation of the inputs' own tracked changes. Word's Compare carries pre-existing revisions through into the compare output verbatim while diffing over the accepted view; this flag matches that, with NormalizeRevisionAuthors alongside it to collapse the output to a single revision author for renderers that color by author.
• DocxDiff: rejecting a redline now reproduces the original paragraph ORDER exactly (#288, #292). Content preservation always held, but a document with verbatim-duplicate paragraphs plus a nearby split/merge could rebuild the left side permuted. Order-monotonicity is now enforced once, globally, in IrBlockAligner.
• Paragraph fragmentation in the pagination viewer. An over-long paragraph can now split across a page boundary instead of falling whole onto the next page and leaving a visible gap. On by default for the paginateHtml() viewer entry point; off on the low-level API, and the editor's paginated mount explicitly opts out.
• DocxSession: SectionInfo.HeaderRefs/FooterRefs and EnsureHeaderFooterVisible. The refs report each w:headerReference/w:footerReference's w:type — and the stories that effectively apply, including ones inherited from a preceding section (ECMA-376 §17.6.17). EnsureHeaderFooterVisible sets w:titlePg / w:evenAndOddHeaders as a section-level operation, which is what a pre-existing first/even story needs to actually render.

Breaking changes

• DocxDiff is now the default primary redline path. Omitting the engine selection in the CLI, the WASM HTML bridge, the npm API/worker, and the browser test harness now routes to DocxDiff rather than WmlComparer. This is a behavior change for every caller that never passed an engine — output markup and revision granularity differ from the incumbent. Explicit ComparisonEngine.WmlComparer / --engine=wmlcomparer remains fully available and retains wire value 0, so pinning the previous behavior is a one-argument change.

Also fixed

• DocxSession: an EditResult's anchors now stay in the part the edit touched. Unids are content-addressed, so identical content in different package parts shares a unid (a document with empty default/first/even header stories does exactly that); every element→anchor reverse lookup resolved by bare unid and could name the wrong story, sending a following edit into the wrong part.
• DocxEditor: formatting a just-typed paragraph no longer silently does nothing — a selection span is now normalized into the space the commit actually stores, which the NBSP placeholder of an empty story previously overshot.
• DocxDiff: w:pPrChange presence, separator lexing/attachment, split-merge segmentation, and the replace-gap arrangement all follow the decoded Word-compare laws; carried-through parts are normalized to what Word emits.

v7.1.0

Minor release. Full details in CHANGELOG.md.

Added

• DocxSession: header / footer / page-number authoring (#236, #274). Three new methods close the header/footer gap in the mutation API: SetHeaderText(anchorId, HeaderFooterKind, markdown) / SetFooterText(...) create or replace a section's header/footer story (Default / First / Even, wiring w:titlePg / w:evenAndOddHeaders as needed), and InsertPageNumberField(anchorId, PageNumberField) appends a native Word PAGE / NUMPAGES complex field. Undo/redo reconciles header/footer part creation. Rippled through every layer: WASM DocxSessionBridge, npm DocxSession.{setHeaderText,setFooterText,insertPageNumberField}, stdio host, and docx-scalpel DocxSession.{set_header_text,set_footer_text,insert_page_number_field}.
• docx2html CLI: tracked-changes and story rendering flags (#269). New --track-changes, --no-render-moves, --render-comments, --render-footnotes, and --render-headers-footers flags map straight onto the existing WmlToHtmlConverterSettings, so a redline document can be previewed in a browser instead of being silently accepted. Defaults unchanged.

Changed

• DocxDiff.Consolidate: a contested relocation now honors the conflict policy on the placement (#233, #273). When reviewers move the same base block to different destinations, BaseWins keeps the block at its base position, FirstReviewerWins applies only the first reviewer's destination, and StackAll keeps the both-placements behavior. No content loss, reject ≡ base holds, and the conflict is still recorded.

Fixed

• Setting w:evenAndOddHeaders no longer corrupts word/settings.xml on documents whose settings part carries children the ordering table didn't know (w:hdrShapeDefaults / w:shapeDefaults); both call sites now share WordprocessingMLUtil.EnsureEvenAndOddHeaders, which never moves unknown settings children.
• DocxDiff: a single w:hyperlink whose entire anchor is replaced no longer fragments into per-token link elements (#232, #272). The coalescer now merges same-source-link fragments by their resolved target, while still keeping whole-anchor retargets split for the r:id remap.
• GetDocumentMetadata now detects section breaks nested inside tables and correctly ignores section properties inside text boxes (#51, #271).

Changelog

Sourced from docxodus's changelog.

[8.0.0] - 2026-07-29

Added

• Visual header/footer editing region in the browser DocxEditor (#275). Opt in with headerFooter: true and the editor docks a Header band above the body flow and a Footer band below it. Header/footer stories live in their own OOXML parts outside the body, so the bands are composed per story paragraph via the session-attached RenderBlockHtml (which already resolves hdr/ftr anchors) rather than being part of the body render — the same renderer used for the post-edit incremental swap, so there is no fidelity drift between first paint and repaint, and there is exactly one addressable DOM node per story paragraph in both continuous and paginated mode. Story paragraphs are wired by the same wireBlock the body uses, so they are ordinary editable blocks: the whole existing ribbon (bold/italic, alignment, font family and size, paragraph style) works inside a band with no new command code, and only the edited band repaints — the body is never remounted. Band chrome adds a kind selector (default / first page / even pages; selecting a kind with no part seeds an empty story so there is always something to type into) and a page-number control (currentPage → PAGE, totalPages → NUMPAGES). Choosing even surfaces the caveat that w:evenAndOddHeaders is document-global and governs footers too — even pages stop inheriting the Default stories — with a one-click "also create an even footer". When a body block is focused the bands follow its section, so a cover-page-plus-body document shows the stories that actually apply. New DocxEditorOptions.headerFooter (default false, so the editor's DOM is unchanged for existing consumers), new DocxEditor.setHeaderFooterKind/headerFooterKind/insertPageNumber, new module npm/src/editor-headerfooter.ts. Coverage: npm/tests/editor-headerfooter.spec.ts.
• DocxSession.EnsureHeaderFooterVisible(anchorId, HeaderFooterKind) — make a section's first/even stories actually render. Sets w:titlePg for First and the document-global w:evenAndOddHeaders for Even; Default needs no flag and is a successful no-op. Idempotent. SetHeaderText/SetFooterText already set these flags while writing content, which covers authoring a story from scratch — but not a document that already carries a first/even reference with the flag absent, which is exactly what Word leaves behind when "Different first page" / "Different odd & even pages" is switched back off. Editing such a pre-existing story through the anchor-addressed text ops otherwise produces a file whose header content is present but never rendered (confirmed against TestFiles/HC031-Complicated-Document.docx, whose six stories all carry references with neither flag). The flags belong to the section, not to a content write, so this is its own operation. Wired through DocxSessionOps → WASM DocxSessionBridge.EnsureHeaderFooterVisible → npm DocxSession.ensureHeaderFooterVisible and the stdio host (ensure_header_footer_visible) → docx-scalpel ensure_header_footer_visible. Coverage: DocxSessionTests.DS268.
• SectionInfo.HeaderRefs/FooterRefs — each w:headerReference/w:footerReference with its w:type. HeaderPartUris/FooterPartUris report which parts a section references but not which story kind each supplies, and the projection's hdr{N}/ftr{N} numbering is by part-collection order, which carries no kind information — so a client could not tell an existing document's Default story from its First or Even one. The new lists pair each reference's HeaderFooterKind with its part URI (an absent w:type reads as Default, per ECMA-376 §17.6.10). They report the stories that effectively apply: a section declaring no reference of a kind continues the previous section's (§17.6.17), and such entries come back with Inherited = true. That matters because a multi-section document typically defines its headers once in the first section — HC031-Complicated-Document.docx has four sections and only the first declares any — so own-references-only would report "no header" for most of the document and a caller acting on that would mint a redundant part and break the inheritance. HeaderPartUris/FooterPartUris keep their original meaning (own references only). Wired through DocxSessionJson → npm SectionInfo.headerRefs/footerRefs (HeaderFooterRef) and docx-scalpel SectionInfo.header_refs/footer_refs. Coverage: DocxSessionTests.DS265/DS266.
• DocxDiffSettings.CrossParagraphTokenDiff (default true) — the cross-paragraph word+pilcrow token stream decoded from Word's compare output. A run of adjacent word-matched paragraph pairs diffs as ONE token stream: retained words may cross pilcrow boundaries, paragraph marks are ¶INS/¶DEL stream tokens, and the output paragraph count follows the token-level interleave. The stream also spans a story-final one-sided tail, and the story-final pair retains only its common unit prefix plus adjacent-bigram recoveries. Markup-only (GetRevisions/GetEditScriptJson/Consolidate are unaffected); accept ≡ right / reject ≡ left holds pilcrow-exactly. Wired through the WASM bridge, npm, the stdio host, and docx-scalpel.
• Gap-region streams — the same stream generalized to replace regions without a full pair run. A zero-pair story-final region streams on ≥2 shared word units or on a single count-equal boundary construct (at most one per region, the matching phase ends there; a lone same-position function-word match never forms one); leading one-sided members join a following pair's stream; interior regions ship only on a construct (or an in-slot match plus a deleted member); one-sided section-break entries are transparent story-end metadata; fragments and whole-document rewrites stay with the replace-gap grammar. Includes the story-tail MERGE-SLOT law: a base surplus merges at the FIRST pair whose next-side tail residue shares an unmatched content word with the following base paragraph, displaced pairs re-slotting forward.
• PaginationOptions.fragmentParagraphs — ordinary paragraphs may now split across a page boundary in the read-only pagination viewer. Previously PaginationEngine always kept a paragraph whole, so a paragraph taller than the remaining page space fell entirely onto the next page, leaving a large blank gap at the bottom of the prior page — a visible divergence from how Word/PDF viewers flow text. PaginationEngine.tryFragmentParagraph now, for a simple text-only <p> (no keepWithNext/keepLines/page-break flags, no non-inline or pagination-sensitive descendants — objects, breaks, lists, tables, footnote markers, nested anchors, etc. all still fall back to the existing whole-block behavior), binary-searches DOM Range endpoints at whitespace/run boundaries to find the largest head fragment that fits the current page, clones it as the page-ending fragment (keeping the paragraph's id/data-anchor), and continues the remainder as a normal block on the next page (identity-free, so it can fragment again). Off by default on the low-level PaginationEngine/usePagination/PaginatedDocument (npm pagination.ts/react.ts) API; the convenience paginateHtml() read-only-viewer entry point turns it on by default. The in-browser DocxEditor's paginated mount explicitly opts out (fragmentParagraphs: false) since a continuation fragment has no addressable anchor of its own and the editor's block-editing model requires one. New npm/TS option fragmentParagraphs on PaginationOptions/PaginatedDocumentProps/usePagination. Coverage: npm/tests/pagination-paragraph-fragments.spec.ts.
• DocxDiffSettings.NormalizeRevisionAuthors — collapse every tracked-revision author in the output to a single author (default false). When PreserveInputRevisions is on, the inputs' own tracked changes ride through under their ORIGINAL author. Renderers that color tracked changes BY AUTHOR (LibreOffice) then show that preserved content in a SECOND color, while Word's compare output is single-author / one color — so a document whose source carried foreign-authored suggestions ("Online User" Google-Docs suggestions, etc.) renders in two colors versus Word's one. With this flag on, a byte→byte post-pass stamps settings.AuthorForRevisions onto the w:author of every tracked-revision element across all story parts (document, headers/footers, footnotes/endnotes, comments-part revisions — comment authors themselves are untouched), collapsing the output to one revision author. This normalizes the RENDER, not revision semantics: the accept ≡ right / reject ≡ left contract is unaffected (author is presentation metadata), and it does not touch Consolidate/N-way output (per-reviewer authors are intended there). Wired through the public DocxDiffSettings, the internal IrDiffSettings, and the stdio host (normalizeRevisionAuthors) + docx-scalpel (normalize_revision_authors). Coverage: DocxDiffAuthorNormalizationTests; documented in docs/ooxml_corner_cases.md.
• DocxDiffSettings.PreserveInputRevisions — Word-parity preservation of the inputs' own tracked changes (default false). Word's Compare PRESERVES tracked revisions already present in the input documents: the original author/date markup rides through into the compare output verbatim (verified against Word's compare output — an input carrying revisions by another author keeps them alongside the fresh compare revisions), while the text diff is computed over the accepted view. Our existing PreAcceptInputRevisions flattens them instead. With the new flag ON: no byte-level pre-accept runs (the LEFT package's carried-over parts — headers/footers, unchanged notes, styles, comments — keep their markup), and the markup renderer reaches back from its accepted working copy to the ORIGINAL right-body elements via an in-order alignment walk that models the document-level accept's paragraph-mark merges (a fully-deleted paragraph rides along in its group and vanishes again on accept). Content-EQUAL blocks emit the original element(s) verbatim; whole-block INSERTED content wraps only plain runs in this diff's w:ins, leaving foreign w:ins/w:del children, foreign paragraph-mark markers, and foreign row markers as-is — no same-kind wrapper ever nests. Preserved wrappers get fresh w:ids (no duplicate-id validator errors) and Word-extension attrs (w16du:dateUtc) are dropped. Note-scope preservation rides the same hooks: footnote/endnote definitions pair by id and their equal/inserted blocks preserve too. Char-precise paths (modify/format-only/split/merge/move, changed header/footer stories) still render over the accepted view — foreign markup there is flattened (v1 scope), as is the LEFT side's in deleted blocks. Round trip is one-sided exactly like Word: accept(output) ≡ accept(right) at text level; reject(output) ≠ left where foreign markup exists (rejecting a foreign deletion restores its text) — documented on the setting. When both flags are set, Preserve wins (pre-accept skipped). The DocxCompare engine-selector path (CLI --engine=docxdiff, WASM/npm selector) now opts in for Word parity. Foreign revisions ride through into the output with zero validator-error delta and an intact accept round trip. Coverage: DocxDiffPreserveInputRevisionsTests (equal-block ins/del preservation, modified-block schema cleanliness, insert-block preservation without nesting, fully-deleted-paragraph ride-along + fresh ids, clean-input byte-identity guard, precedence).

Changed

• DocxDiff: the WC-1450 parity case is adjudicated once, in the parity scoreboard, and pinned on engine truth (issue #289). IrSplitMergeTests.WC1450_compat_revisions_match_oracle_count was skipped on the belief that WC023's fully-duplicated prose (the same sample text in BOTH the leading body paragraphs AND the table cells, so no block content is uniquely anchorable) collapsed IrBlockAligner into a whole-body delete + re-insert. Investigation showed it does not: the body aligns to 5 Unchanged plus the table as ONE Modified pair, and IrTableDiffer resolves the table to exactly the authored edit — DeleteRow (the removed row), ModifyRow (the "Second " cell edit) and two EqualRows. The 2 revisions are that edit at the engine's row grain: a whole deleted row is ONE revision, which is what the WmlComparer oracle itself does for every other whole-row case in the corpus (WC-1140/1150/1460/1660/1670/1750/1760 pin it). Its 7 revisions here are not a finer reading of the same edit — it mis-aligns this fixture, reporting content as INSERTED that is unchanged on both sides, plus two null-text revisions. IrParityScoreboardTests already adjudicates WC-1450 as a documented coarser-grain deviation and ratchets the floor for it, so the second hard-count copy in IrSplitMergeTests was re-litigating a settled decision against a degenerate oracle. It is replaced by two un-skipped tests that pin what the engine actually says — the deleted row + the cell edit, and the block/row alignment shape that would regress if duplicate-content alignment ever did collapse. The stale "179/179 genuine passes, catalog EMPTY" claim in docs/architecture/ir_diff_engine.md is corrected to the scoreboard's real state (177 genuine + 2 documented deviations).
• DocxDiff is now the default primary redline path. Omitted engine selection in the CLI, WASM HTML bridge, npm API/worker, and browser test harness routes to DocxDiff. Explicit ComparisonEngine.WmlComparer / --engine=wmlcomparer remains available and retains wire value 0.

Fixed

• DocxSession: an EditResult's anchors now stay in the part the edit touched. Unids are content-addressed, so identical content in different package parts yields the same unid — a document with empty default/first/even header stories has one unid shared across several header parts, which is what Word writes. Every element→anchor reverse lookup resolved by bare unid and returned whichever part the projection indexed first, so an edit result named a different story; a caller that addressed the returned anchor next (as an editor does for its re-render and the following command) then wrote into the wrong part. Symptom: a page-number field aimed at the default footer landed in the even one. Fixed at a single owner — AnchorForUnid(unid, preferPartUri) plus PartUriOf/AnchorForElement, with all sixteen reverse lookups passing the part they touched. HtmlConversionOps.RenderBlockHtml's session-attached path likewise resolves through the anchor index before falling back to the unid scan, so a single-block re-render can no longer display a different part's block. Coverage: DocxSessionTests.DS267, HtmlConversionOpsTests.HCO080.
• DocxEditor: formatting a just-typed paragraph no longer silently does nothing. A block rendered with edge whitespace — an empty header/footer story renders as a lone NBSP placeholder — produces a selection span longer than the text the commit stores (serializeInlineMarkdown(...).trim() drops it, since JS trim() treats U+00A0 as whitespace). "Select all, then Bold" therefore asked ApplyFormat for one character past the committed end and the op was rejected out of range. The demo's format buttons preventDefault on mousedown precisely so the selection survives, which is the path that computes the span before syncBlock commits — the ordinary case, not an edge one. selectionSpanIn/blockSpanForSelection now normalize through a new trimmedSpan(), the span analogue of the existing trimmedSplitOffset().
• DocxDiff: rejecting a redline now reproduces the original document's paragraph ORDER exactly, not just its content (issue #288). DocxDiff.Compare guarantees accept ≡ right / reject ≡ left. Content preservation always held — the byte-level round-trip fuzzer never lost or duplicated a word in either direction — but in a narrow case the reject direction restored every paragraph in the WRONG ORDER. The trigger is a document containing verbatim-duplicate paragraphs plus a split/merge edit near one of them: duplicates never anchor (IrBlockAligner.BuildUniqueIndex keys on content that is unique on each side), so which occurrence pairs with which is settled by the in-gap refinement — and the split/merge containment scan, which runs after that refinement, could then form a group that STRADDLES the pairing it had already made. EmitEntries walks the right document, so the straddled pair emitted at its right position and the group at theirs, and reject rebuilt the two left blocks permuted. Every in-gap pass already enforces order-preservation against the pairings that existed when it ran; rather than teach each pass about the others, the invariant is now enforced once, globally: IrBlockAligner.EnforceInPlaceOrderMonotonicity keeps a maximum-weight strictly-increasing subsequence of the (left → right position) map over ALL left-owning units — 1:1 pairs and split/merge groups — and releases the rest to plain Deleted/Inserted (always reversible), weight = blocks kept paired so an ambiguous cut sacrifices the pairing holding the least content. It runs before cross-gap move detection, so a released pair that is genuinely a relocation comes straight back as a Moved — frequently a better reading than the in-place pairing it replaced (the fuzz repros all recover their split/merge groups AND gain a correct move). An already-monotone alignment (every corpus document) returns after one linear scan, untouched. Reproduced at seeds 184/760/1714 of 2000; clean at 2000 seeds after the fix. Coverage: IrAlignmentAsserts.AssertLeftOrderReconstructible (now asserted on every aligner test), IrBlockAlignerTests.Duplicate_paragraph_pairing_never_crosses_a_merge_group + Fully_duplicated_body_still_emits_left_blocks_in_left_order, and DocxDiffFuzzRoundTripTests, which now compares whole-body BLOCK SEQUENCES (its word-multiset checks are order-independent by design and could not see this) with the default sweep raised 50 → 250 seeds so the canonical repro is covered without the env knob.
• DocxDiff: the replace-gap paragraph arrangement follows Word's full structural grammar — insert-block-first emission with leading-ins hoists, fusion and live pilcrows only at a story's end, accept-side paragraph-mark coalescing treating an entirely-deleted table as transparent, and a virtual structural pair when the base story ends with a table.
• DocxDiff: in-gap paragraph pairing follows Word's positional-first matcher — same-slot pre-pairing with size-parity and competitor-evidence guards, story-tail surplus absorption, a shared content-word requirement for similarity pairs (any-overlap fallback for zero-content gaps), and top-down positional row pairing for wholly rewritten grown tables.
• DocxDiff: split/merge segmentation follows the merged-stream expansion arrangement — char-weighted anchors sliced at solid-match segments; ins-residue joins the preceding member, del-residue the following member, and trailing merge-insert residue the final member.
• DocxDiff: a story-final word-matched pair whose only retention is a single short-word sliver flushes to one whole ins+del rewrite (count, length, and fraction thresholds all required; interior pairs never flush).
• DocxDiff: separator lexing and attachment match Word's — ASCII : is always its own token (digit-interior included), whitespace/punctuation attach to retained anchors by the decoded separator laws, separators flanking a match ride with it across cell and slice boundaries, and lone matched punctuation is suppressed unless anchored.
• DocxDiff: w:pPrChange presence follows the surviving-pilcrow and comparison-fold laws — split/merge members with new pilcrows never carry one, the member owning the surviving pilcrow stamps history against its counterpart, default-equivalent w:jc and unresolvable w:pStyle fold out of the comparison, and shared pilcrows archive an empty <w:pPr/> when the base side had no properties.
• DocxDiff: carried-through parts are normalized to what Word emits — known-font declarations in an input word/fontTable.xml are rewritten to Word's stock metadata, and an imported right-side list instance gets its own fresh cloned w:abstractNum unless it is a surviving left list, so imported lists restart numbering instead of continuing a left list's counter.
• DocxDiff: the intra-paragraph token diff now resolves anchor ties by matched CHARACTER length, matching Word's compare tie-break. When two same-length common subsequences of content words exist, the previous Myers alignment kept whichever the greedy walk reached first (a token-count tie). Word instead keeps the subsequence covering the most characters — a distinctive long word ("strikethrough", 13 chars) is retained as the anchor over an incidental short one ("text", 4 chars), and a contiguous phrase is preferred over a scattered pair. IrTokenDiffer.ContentAnchors now selects the common subsequence maximizing total matched character length (CharWeightedLcs, an O(n·m) weighted-LCS with a deterministic prefer-left back-walk that degenerates to token count when all weights are 1), instead of the greedy Myers LCS. The accept ≡ right / reject ≡ left contract and the token-diff tiling invariants are preserved (verified by IrDiffFuzzTests). Coverage: IrTokenDifferTests.Repeated_words_with_distinct_tail (the tie-break regression pin).
• DocxDiff: the output now carries a synthesized word/fontTable.xml + word/webSettings.xml, matching Word's compare output — the single biggest redline-render-fidelity fix. Word's compare synthesizes both parts for every output document (the source documents rarely carry them). A fontTable declares each font's panose1/charset/family/pitch metrics, and that is exactly what LibreOffice consults to pick a substitute for a font it does not have installed (Aptos, Calibri, a raw CSS stack). When Word's redline carries a fontTable and ours does not, the two documents substitute the same absent font differently, so even a byte-identical body renders to different glyphs/metrics and a rendered redline diverges from Word's compare output. A new single-owner backfill (WordCompareFontTableBackfill, applied alongside the existing stock-theme and stock-docDefaults backfills) emits a fontTable listing Word's stock faces (Times New Roman/Aptos/Calibri/Aptos Display, with Word's exact metrics) plus every font the body or styles part actually references (unlisted fonts get a generic swiss/roman/modern descriptor keyed on the name; a raw CSS font stack such as "Roboto, sans-serif" is declared with Word's own <w:altName> = its primary family, which is what LibreOffice resolves for substitution), and an empty-bodied webSettings. Because the fontTable now carries the CSS stack's substitution metadata, the renderer no longer rewrites a shared stack to Arial (the old "reliable fallback" workaround, which diverged from Word — Word keeps the raw stack): the stack rides through verbatim and both sides substitute it identically. The accept ≡ right / reject ≡ left contract is untouched (these are font-metadata parts, not tracked-changes markup). Coverage: WordCompareFontTableBackfill, DocxDiffCssFontStackCompatibilityTests.
• DocxDiff: the output now backfills the canonical word/settings.xml children Word's compare synthesizes — chiefly compat/compatibilityMode, the second parts-fidelity render fix. Word's compare output synthesizes a canonical settings part for every document even when the source carries only an empty stub (verified against Word's compare output). The load-bearing element is compat/compatibilityMode: it selects LibreOffice's layout-engine emulation (Word 2007/2010/2013+), so when Word's redline carries one and ours does not, the two documents lay out under different engines and a rendered redline diverges from Word's compare output even on a byte-identical body — while characterSpacingControl/themeFontLang/clrSchemeMapping are inert against LibreOffice's defaults and are emitted purely for parity with what Word writes. A new single-owner backfill (WordCompareSettingsBackfill, applied alongside the stock-theme/docDefaults/fontTable backfills) ensures each canonical child exists, inserting it at its CT_Settings schema slot via a shared ordered-insert primitive (WordprocessingMLUtil.EnsureSettingsChildInOrder, the same slot-insert discipline as EnsureEvenAndOddHeaders — never a whole-part reorder). compatibilityMode follows Word's articulable rule (matches Word's compare output in the common cases): keep the ORIGINAL (left) document's value when present, otherwise the revised (right) document's, otherwise 12 (Word's default for an unmarked .docx) — so a genuine mode-15 document is never downgraded. The accept ≡ right / reject ≡ left contract is untouched (these are document-settings, not tracked-changes markup; verified by the round-trip fuzzer). Coverage: DocxDiffSettingsBackfillTests.
• DocxDiff: the output no longer carries orphaned comment definitions. The output's word/comments.xml is cloned from the LEFT/original document, and MergeRightCommentDefinitions adds the RIGHT's referenced comments — but nothing removed a LEFT comment whose annotated content the diff fully replaced, leaving no w:commentRangeStart/w:commentReference anywhere (not even inside a preserved w:del). Its w:comment definition dangled: e.g. a comment-dense document produced 10 comment definitions where Word's compare output emits 6 (4 unreferenced orphans). Word never emits such an orphan. A new pass (IrMarkupRenderer.PruneOrphanedComments, run right after NormalizeComments — the inverse of that pass's step (C), which drops markers with no definition) removes every w:comment referenced by no marker in any story (body + headers + footers), plus its commentsExtended/commentsIds threading entries (keyed by the comment paragraph's w14:paraId). Safe for the round trip: a definition is pruned only when NO marker references it, so neither accept nor reject can resurface the reference — a LEFT comment whose marker survives inside a w:del (so reject restores it) is kept. This carries no rendering impact (orphaned definitions carry no anchor and do not render), but it is a genuine content-fidelity correctness fix. Coverage: DocxDiffCommentPruneTests (orphan + threading-entry pruned; del-preserved marker kept).
• DocxDiff: the byte-level accept/reject round-trip content-preservation contract is now guarded by generative and pre-existing-revision tests. The core guarantee a consumer relies on — accept(Compare(left, right)) reproduces the RIGHT document's content and reject(...) the LEFT document's content, with nothing lost, duplicated, or mangled — was previously spot-checked only on a handful of hand-built pairs. Two additions pin it directly: a generative fuzzer (DocxDiffFuzzRoundTripTests) that, for each of N reproducible synthetic pairs (seed-count knob DOCXODUS_FUZZ_SEEDS, default 50), runs the full DocxDiff.Compare → RevisionProcessor.AcceptRevisions/RejectRevisions path and hard-asserts the accepted document's whole-body text (paragraphs and tables) equals the right input's and the rejected document's equals the left input's, order-independently (so a move/split reorder cannot mask a genuine drop); and DocxDiffInputRevisionsRoundTripTests, which pins the same contract for inputs that ALREADY carry un-accepted tracked changes and moves (the "redline of a redline" case, body + table cells), where the compared and preserved content is each side's accepted view. No external fixtures — all pairs are synthesized. Verified with zero content loss across thousands of seeds.
• DocxDiff: a residue paragraph pair sharing only ONE incidental word is now full-replaced (separate ins + del paragraph) like Word, not force-interleaved. When exactly one free left and one free right paragraph survive similarity pairing in a gap, the 1×1-residue rule paired them as Modified if they shared any word — so a dissimilar tail-paragraph rewrite that happened to share a lone common word (e.g. "… a standard readable font size …" vs "Medium-large font sizes …" sharing only "font") rendered as one mixed paragraph interleaved around that incidental "font", where Word emits a clean inserted paragraph + deleted paragraph (no anchor on the lone word). IrBlockSimilarity.ResidueForcePair now requires ≥ 2 shared content words to force the interleave (zero-overlap already stayed separate; the one-word-vs-one-word typo/renumber case — "Nested." → "Nexted." — is still exempt). This matches Word's interleave-vs-full-replace cutoff decoded from Word's compare output. The accept ≡ right / reject ≡ left contract is unaffected (the pair becomes a plain delete + insert, both round-trip trivially). Coverage: IrSplitMergeTests/IrAlignment* (residue classification).
• DocxDiff: a paragraph merge/split whose surviving paragraph ADDS text is reproduced as Word's cross-boundary interleave, not a whole-paragraph delete. When two base paragraphs fuse into one revised paragraph that also inserts new prose (e.g. "A." + "B spreads across the line." → "A which C. B spreads across the line, plus more."), Word deletes the paragraph mark and keeps each base paragraph's surviving words as retained anchors in that paragraph's slot. The IR merge/split containment scan (IrBlockAligner.DetectOneToManyInGap) only fired when the run covered ≥ 90 % of the surviving paragraph's content (SplitCoverageThreshold), so any merge that added substantial new text was vetoed — the extra base paragraph fell through to a whole-block delete and the shared anchors landed in the wrong paragraph versus Word. A new added-text acceptance path (MergeSplitAllowAddedText, default on) fires the merge/split when the run is genuinely retained (foreign slack ≤ SplitAddedTextMaxSlack) and the surviving paragraph is still substantially explained (coverage ≥ SplitAddedTextMinCoverage), waiving only the high singular-coverage requirement; the unchanged ≥2-phrase-member gate keeps it from gluing incidentally-overlapping paragraphs. FindQualifyingRun returns the coverage-path window eagerly (shortest-first, unchanged) but the added-text window only at maximum coverage, so a clean multi-member split still fires at its complete member count. Scoped conservatively to low-slack merges it can render faithfully — looser "messy" merges/splits (which need Word's global minimal-edit tie-break and split paragraph-property fidelity) are deliberately left for a follow-up. The accept ≡ right / reject ≡ left contract is preserved (the machinery is the existing IrSplitSegmenter/RenderMergeBlock path). Coverage: IrSplitMergeTests; documented in docs/ooxml_corner_cases.md.
• DocxDiff: a wholly-rewritten table row that gains a column keeps its base cells in their original columns. When a Modified table row shares no cell body with its counterpart (a full cell-for-cell rewrite) AND grows by a column, the ordinary-grid cell fill had no affinity to anchor on, so its cost-tie resolved to inserting the new cell at the FRONT — sliding every base cell one column right and scattering the deleted content into the wrong columns versus Word (which keeps the base cells in place and clean-inserts the new column). IrTableDiffer's cell-gap alignment now applies a small positional tie-break (a per-column-of-displacement affinity nudge, CellPositionalTieBreak, 10% of max affinity — more conservative than the row aligner's own locality prior, so any genuine cell-body affinity still dominates and only otherwise-tied rewritten rows are affected). Byte-identical wherever cell bodies carry real mutual affinity (the retained-cell-edit-plus-insert case is unchanged). Coverage: IrTableDifferTests.Wholly_rewritten_row_that_gains_a_column_keeps_base_cells_in_their_columns.
• DocxDiff: fixed-width tables render where Word's compare puts them — hairline cell-margin/indent inset backfill. A fixed-width table (w:tblW w:type="dxa") that declares no explicit cell margins used to reach the output unchanged, so a renderer applied its OWN default cell margin (LibreOffice ≈ 108 twips) which overflows the declared column widths and shifts every cell's text horizontally versus Word — the whole table "ghosts" against Word's redline. Word's compare output normalizes this: it materializes a hairline w:tblCellMar (left/right) plus a matching w:tblInd, the inset equal to the table's border width (a 0.5pt w:sz="4" border ⇒ 10 twips; w:sz is eighths of a point, 1pt = 20 twips). A new single-owner post-pass (WordCompareTableNormalizer, applied over the assembled body blocks so every table on every render path is treated identically) reproduces exactly that: for a fixed-width table with a derivable border width and no declared w:tblCellMar, it inserts the border-width inset as w:tblCellMar + w:tblInd in CT_TblPrBase schema order. AUTO-width tables (type="auto"), tables with no border, and tables that already declare cell margins are left untouched. Mirrors the existing docDefaults backfill (WordStockDocDefaults/DocxDiffDocDefaultsBackfillTests) — the whole engine goal is to reproduce Word's compare output, and a rendered redline is only faithful if its tables land where Word's do. The accept ≡ right / reject ≡ left contract is unaffected (the inset is a table property, not tracked-changes markup, and the round-trip is verified at body-text level). Coverage: DocxDiffTableCellMarginBackfillTests; documented in docs/ooxml_corner_cases.md.
• DocxDiff: content-anchored intra-paragraph token diff — interior shared words are retained instead of dropped. The Myers token diff previously keyed on ALL tokens including whitespace separators (which all share one match key), so a paragraph with many identical spaces spent its LCS budget on whitespace and DELETED+re-inserted interior shared content words — e.g. a lone "a" between two divergent phrases — scattering ins/del ink where Microsoft Word anchors on the content word and retains it in place. IrTokenDiffer.MyersSpans now runs the LCS over the NON-whitespace token subsequence (content anchors), then re-expands whitespace positionally per inter-anchor segment (a common whitespace prefix/suffix stays Equal; the middle is a clean Delete+Insert). This reproduces Word's whole-sentence-replace-with-retained-anchors shape on formatting-change documents. The accept ≡ right / reject ≡ left contract and the token-diff tiling invariants are preserved (verified by IrDiffFuzzTests); coverage in IrTokenDifferTests. Known limitation: on two low-similarity sentences that happen to share an incidental repeated word, the anchor can be retained where Word full-replaces.
• DocxDiff: FormatChanged runs spanning heterogeneous left formatting now restore each region's format on reject. When a FormatChanged token span covered LEFT source runs with different formatting (e.g. a bold run + an italic run) but a single RIGHT run, IrMarkupRenderer.BuildTokenOpContent stamped ONE w:rPrChange from the first left char, so rejecting restored the first format across the whole span and lost the second. It now splits each right-run slice at LEFT source-run format boundaries (SourceRunModel.FormatBoundaries), emitting one w:rPrChange per left-format region — reject ≡ left holds at the property-byte level. Byte-identical on single-uniform-run input. Coverage: DocxDiffWordShapeTests.IntraParagraphReplace_Reanchoring*.
• DocxDiff: an edited table bracketed by asymmetric blank paragraphs is no longer torn into a whole deleted + whole inserted table. When base and next differed in leading/trailing blank (whitespace-only) paragraphs around a table, a fungible blank got matched across the table and IrBlockAligner.ReleaseCrossingModifiedPairs released the whole table's Modified pairing into Deleted+Inserted — emitting two tables where Word keeps one table with native per-row w:trPr/w:ins|w:del markup. The crossing resolution is now weight-aware: a Modified structural pair crossed only by a fungible blank-spacer pair (IrBlockSimilarity.IsBlankSpacer) demotes that blank to Deleted+Inserted instead of releasing the heavier table; genuine reorders (crossing content-bearing blocks) still release as before. Byte-identical when no blank-spacer pair is present. Coverage: IrTableCrossingReleaseTests.
• DocxDiff: Word-shaped redline projection — a fidelity campaign aligned to Microsoft Word's own compare output. A coordinated set of renderer/aligner/consume-side changes that make DocxDiff's tracked-changes output render like Word's redline. All changes preserve the accept ≡ right / reject ≡ left contract; the edit script keeps its token grain — these are projection/consume-side changes:
  • Replace-gap grammar (RenderBlockOpsWordShaped): inserted blocks render BEFORE deleted ones within a delete+insert gap; the last inserted and first deleted paragraph share one w:p (the seam, deleted-side pPr + tracked mark, guarded against inline w:sectPr and page-break carriers); the deleted chain ends at a live terminator mark so accept ends the inserted text there.
  • Token-level coalescing (CoalesceTokenOpsWordShaped): a changed region inside a paragraph renders as ONE inserted region then ONE deleted region (interior whitespace consumed into both sides), never per-word del/ins alternation.
  • Aligner (IrBlockAligner): in-gap similarity pairing gains a locality prior (sim ≥ threshold + 0.3·displacement; kills cross-gap "word salad" while keeping high-similarity swapped edits); BlockSimilarityThreshold recalibrated 0.5 → 0.35 against Word's compare output; split/merge groups require ≥ 2 members; leftover gap tables pair positionally (k-th old merges into k-th new via the per-cell table diff).
  • Style definitions (TrackStyleDefinitionChanges): the output keeps the LEFT styles part (docDefaults/theme byte-identical to the original, as Word does) while styles whose RAW definitions differ get their current payload updated — pPr side at raw payloads, rPr side materialized from the resolved chain — with the old payload archived in a tracked w:rPrChange/w:pPrChange inside the definition; right-only styles copied, left-only styles survive.
  • Stories (RebindOrStripStoryReferences + EnsureStoryReference): header/footer references carried by right-cloned inline sectPrs are rebound to the output's own story parts (matched → the merged left part, right-only → the inserted part, else a pruned wholesale import); a matched story whose only left reference lived on a collapsed inline sectPr is re-attached instead of orphaned; w:titlePg/w:evenAndOddHeaders activate only when the revised document activates them; unresolvable references are dropped (OOXML inheritance).
  • Inputs: strict-conformance packages (ISO 29500 purl.oclc.org namespaces) are normalized to transitional at every entry point (StrictOoxmlNormalizer); DocxCompare's DocxDiff branch pre-accepts input revisions (WmlComparer/Word parity); dangling numId references get Word's synthesized decimal-multilevel numbering repair.
  • Robustness: cross-kind relationship-id collisions remap instead of throwing; RevisionProcessor accepts Word's paragraph-mark w:moveFrom sentinel like a deleted mark (no more spurious empty paragraph at every Word-authored move source; RP015 baselines regenerated — they had captured the old bug), and drops emptied hyperlink shells on accept/reject.
• DocxDiff: strict-conformance OOXML inputs (ISO/IEC 29500 purl.oclc.org namespaces) no longer fail with "Document has no w:body element". Word's "Strict Open XML Document" save format keeps every WML element in the strict namespace family, which the XDocument-based IR reader (and everything downstream) does not speak. A new internal StrictOoxmlNormalizer detects a strict main part (resolved through _rels/.rels, either conformance class's officeDocument relationship type) and rewrites every XML part and .rels stream to the transitional namespaces — including the extendedProperties → extended-properties rename and dropping Word's w:conformance="strict" root attribute — before any read, exactly as Word normalizes strict packages on open. Applied at every DocxDiff entry point (Compare/GetRevisions/GetEditScriptJson/the consolidate family) via the shared input-preparation hook; transitional inputs pass through untouched (same instance). The accept ≡ right / reject ≡ left contract holds whether one or both sides are strict. Regression coverage: DocxDiffStrictOoxmlTests (strict-left, strict-right, both-strict, self-compare identity, edit-script JSON).
• DocxDiff: a right-document r:id colliding with a left relationship of a DIFFERENT KIND no longer throws XmlException ("'rIdN' ID conflicts with the ID of an existing relationship"). IrMarkupRenderer.ImportHyperlinkAndExternalRelationships treated an id as free when no left hyperlink used it — but the id could name a left part relationship (comments.xml, an image, …), and recreating the right hyperlink/external relationship under that taken id makes System.IO.Packaging throw an exception type the guard didn't catch. The freeness test now consults ALL left relationship kinds (parts, hyperlinks, externals, data-part references) and the different-kind collision takes the existing fresh-id remap path (rIdRemap{n} + rewrite of the cloned r:ids), so the inserted content still resolves to the right-side target. Regression coverage: DocxDiffRelationshipRemapTests.
• RevisionProcessor: accepting/rejecting a ful...

  Description has been truncated

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.