What survives when a tool edits a reviewed Word document

ooxml-integrity 0.4.6, the published version the protocol froze, compares an edited file with its source. It reported every comment anchor and footnote reference python-docx lost and the malformed comments part, and missed what it did not model: the escaped bullets, the misattributed words, the title edited instead of the header. 0.4.7 adds warnings for the first two.

Most of its findings on correct edits were the requested change itself: accepting a revision lowers the revision count, an untracked header edit changes the header. 0.4.8 lets a caller declare such a change: a matching finding is then expected, and an expectation nothing matches is an error, because the requested change did not happen. With expectations taken from each task's declaration, flagged correct outputs fell from 130 to 12 of 537, each of those left a true report outside the oracle's scope, and caught damaged outputs rose from 59 to 63 of 69: the title edited instead of the header now shows.

A correct tracked edit loses nothing, so it draws no error to expect. 0.4.9 lists the tracked changes an edit added, per part of the document and author (FID012), and an expectation can require one in the header. Expecting that for every tracked task as well, caught damaged outputs rise to 65 of 69 and flagged correct outputs stay at 12: a tool that made its tracked edit in the document title instead of the header now fails too. Analysis, run with the published 0.4.8 and 0.4.9.

0.5.1 also reports a tracked replacement that deletes and inserts again more unchanged words than it changes (FID013): docx-cli edits a footnote by striking its whole text and inserting it again with one phrase changed, which nothing reported before because nothing is lost. With it, caught damaged outputs reach 67 of 69, and flagged correct outputs stay at 12. The two left are one tool's untracked edit of the wrong words inside another reviewer's pending insertion, in both captures.

0.7.0 reports a part declared with a content type its relationship does not allow (PKG010): the five Codex outputs Word refuses. They were already flagged for their unanchored reply, so the counts stay. Its fix command repairs both, and Word opens the copy with the reply in its thread.

0.8.0 lists the paragraphs an edit changed, with their text before and after (FID014), so a caller can expect the text the edit was asked to produce. Expecting each replacement's text, caught damaged outputs reach 69 of 69 and flagged correct outputs stay at 12: the untracked edit of the wrong words inside another reviewer's insertion, which no loss rule reports, now fails. A recheck of docx-cli 0.27.0 shows its fixes removed the escaped bullets and the misattributed tracked edit; that untracked edit is unchanged.

• The protocol and its 30 task declarations were frozen, with their hashes, before the first capture; later changes are dated amendments, made before the captures they affect.
• The first source is a synthetic contract; the second is a review record written by Word for Mac: two reviewers' comments, a threaded reply and tracked changes, including a deletion inside another reviewer's insertion.
• Each third-party document tool ran in its own container with no network, python-docx in the development environment. Each agent ran in a container whose only route out led to its model, with web tools off and no retries. Document tools were captured twice, agents five times, OpenCode once.
• The oracle reads both files into review facts and never imports the checker; a reference control that edits the XML the way Word does passes all 60 attempts.
• All captures, transcripts, receipts and the evaluation are in the evidence folder.

Limits: two documents, one version of each tool and model, and counts of attempts rather than independent documents. Only one output per kind of damage was opened, in one build of Word for Mac.