Limits and Next Steps

Limits and Next Steps

Limits

The most important limit concerns evidence rather than features: every test fixture is generated in code, and no file saved by Word itself has been through the server. Generated XML shows that the logic handles the structures the tests describe, whereas real Word output contains structures nobody thought to generate, such as smart tags, field codes, and content controls. Therefore the claim this repository can support is narrower than "reads any Word document", and a reader should hold it to that narrower claim until a real file has been tested.

The second limit is one of scope. The server reads the document body, including tables and text boxes, and it stops there.

Area	Limit
Parts read	Headers, footers, footnotes, and endnotes are not read
Comments	Counted, not read
Paragraph merges	Accepted text is per paragraph, so a tracked deletion of a paragraph mark does not merge the two paragraphs
Fields	Results are read as stored text and are not recalculated
Regular expressions	find_docx_term runs the caller's pattern with no time limit, so a pathological pattern can stall the server
File access	The server reads any path its process can read. Run it with an account that can reach only what the agent should see
Word counts	word_count_approx splits on whitespace, so it undercounts text with no spaces, such as Chinese or Japanese
Formats	Legacy .doc files do not open
Platforms	Tested on Windows with Python 3.12. Not tested on Linux or macOS

The file-access limit deserves emphasis. A read-only server is safe for the document, although it is not necessarily safe for the machine, because path is an argument the agent controls. An account with narrow permissions is the mitigation, and the server itself does not enforce one.

Next steps

These are ordered by how much each one would widen what the repository can honestly claim.

1. Test real Word files. A small set of files saved by Word, covering tracked changes, moves, tables, and text boxes, would close the largest gap in the evidence. Each would need to be an invented document, because no real document belongs in the repository.
2. Compare at scale with an independent reader. The pandoc check has been run on one sample only. Making it a repeatable test across a generated corpus would turn a one-off comparison into a standing one.
3. Read footnotes and endnotes. These parts can carry tracked changes of their own, and they are the most significant text the server ignores today.
4. Bound the regular expression. A time limit on find_docx_term would close the one known way to stall the server.
5. Handle paragraph merges. A tracked deletion of a paragraph mark should produce one merged paragraph, which would need a design for how para_index behaves when two paragraphs become one.
6. Count words for CJK text. A count that handles text with no spaces would make word_count_approx useful for Chinese and Japanese documents.

No dates are attached to these. Each would stay read-only, because that property is what makes the server simple to trust.