Context
Discovered during peer review of #142 ([120.7] author config wiring).
The new inferStartingRevisionIdState helper in packages/docx-mcp/src/session/manager.ts is used to seed the session's RevisionIdState so AI-emitted revisions don't collide with pre-existing revision IDs in the document. It scans only document.xml today — not side parts.
The gap
Per ECMA-376, revision IDs (w:id on <w:ins>/<w:del>/*PrChange/etc.) are conceptually unique across the whole package, not per-story. Today:
- Session opens a document where
comments.xml already contains <w:ins w:id="500"> from a prior reviewer.
inferStartingRevisionIdState scans document.xml only, finds max=10, starts the session at id=11.- AI calls
add_comment with ctx → commentReference run wrapped in <w:ins w:id="11"> lands in document.xml. Fine so far.
- Eventually after ~490 more AI edits, the counter hits
id=500. Now comments.xml has TWO revisions with w:id=500. Invalid OOXML.
For typical sessions with <100 edits, this is a non-issue. For long-running sessions on heavily-reviewed third-party documents, it's a real risk.
Proposal
Pre-load all word/*.xml side parts when seeding RevisionIdState:
word/comments.xmlword/footnotes.xmlword/endnotes.xmlword/commentsExtended.xmlword/people.xml (if it has w:id attributes)
The helper signature is already variadic (`inferStartingRevisionIdState(...docs: Document[])`) so the caller just needs to pass the side-part documents.
The blocker: side parts are loaded via zip.readText(...) which is async. Making getRevisionContextForSession async cascades to all 10 Table A MCP tools (each becomes `await getRevisionContextForSession(session)`).
Acceptance criteria
inferStartingRevisionIdState is called with all available side-part Documents.- A regression test opens a document with `comments.xml` containing a high `w:id` (e.g., 500) and asserts the session starts at id > 500.
- The async cascade through
getRevisionContextForSession and the 10 MCP tools is mechanical (each becomes async-aware).
- Existing tests stay green.
Related
Context
Discovered during peer review of #142 ([120.7] author config wiring).
The new
inferStartingRevisionIdStatehelper inpackages/docx-mcp/src/session/manager.tsis used to seed the session'sRevisionIdStateso AI-emitted revisions don't collide with pre-existing revision IDs in the document. It scans onlydocument.xmltoday — not side parts.The gap
Per ECMA-376, revision IDs (
w:idon<w:ins>/<w:del>/*PrChange/etc.) are conceptually unique across the whole package, not per-story. Today:comments.xmlalready contains<w:ins w:id="500">from a prior reviewer.inferStartingRevisionIdStatescansdocument.xmlonly, findsmax=10, starts the session atid=11.add_commentwith ctx →commentReferencerun wrapped in<w:ins w:id="11">lands indocument.xml. Fine so far.id=500. Nowcomments.xmlhas TWO revisions withw:id=500. Invalid OOXML.For typical sessions with <100 edits, this is a non-issue. For long-running sessions on heavily-reviewed third-party documents, it's a real risk.
Proposal
Pre-load all
word/*.xmlside parts when seedingRevisionIdState:word/comments.xmlword/footnotes.xmlword/endnotes.xmlword/commentsExtended.xmlword/people.xml(if it has w:id attributes)The helper signature is already variadic (`inferStartingRevisionIdState(...docs: Document[])`) so the caller just needs to pass the side-part documents.
The blocker: side parts are loaded via
zip.readText(...)which is async. MakinggetRevisionContextForSessionasync cascades to all 10 Table A MCP tools (each becomes `await getRevisionContextForSession(session)`).Acceptance criteria
inferStartingRevisionIdStateis called with all available side-part Documents.getRevisionContextForSessionand the 10 MCP tools is mechanical (each becomes async-aware).Related