Discovery: implementation options for offline Office document support

[andrii-novikov]

QuickApps version

latest

What is the problem this feature will solve?

The offline Office documents epic (#487) has several viable implementations with very different cost, fidelity, security, and operational profiles. Committing to one without a structured comparison risks either an unusable result or a disproportionate investment — and, importantly, the two cheapest options are also the two with the worst failure modes.

Two distinct sub-problems are routinely conflated and must be separated explicitly:

• Generating a new document — straightforward in every option.
• Editing an existing document while preserving fidelity — hard. An OOXML file is a zip of XML parts, relationships, styles, media, layout rules, and comments. Edits that preserve the text routinely destroy the layout. This is the criterion that actually discriminates between the options.

What is the feature you are proposing to solve the problem?

A time-boxed discovery that produces a design doc under docs/designs/ (following docs/designs/template.md) with a recommendation, plus the follow-up child issues for the chosen option.

Options to evaluate (at minimum):

1. Internal toolset — python-docx / openpyxl / python-pptx in-process, behind a features.office_documents toggle alongside dial_files and web_fetch.
2. Code interpreter + skill — preinstall the libraries in the interpreter image and ship an office-documents skill carrying the recipes. Note the interpreter is session-based, so it can hold a document open across several edit calls.
3. External MCP document service — adopt an existing server (Office-PowerPoint-MCP-Server, ai-office-mcp, opendocswork-mcp, OfficeCLI) or expose a DIAL application over MCP — the same pattern as Code interpreter MCP service #422.
4. Format conversion round trip — MarkItDown/Pandoc to Markdown, edit with the existing text file tools, convert back.
5. Template filling — docxtpl/Jinja2 over a builder-supplied OOXML template; substitution only, styles never touched.
6. Self-hosted document engine — headless LibreOffice or equivalent.

Evaluation criteria:

• Fidelity when editing an existing styled document — the decisive criterion. Test against a real corporate template with headers/footers, styles, and embedded objects.
• Determinism and reproducibility of results across runs.
• Whether .xlsx formulas are recalculated (see the trap recorded in [EPIC] Offline Office document support (docx, xlsx, pptx) #487).
• Security — OOXML is untrusted zip-of-XML: zip bombs, XXE, formula injection. Where does parsing run, and is it sandboxed?
• Operational cost — a new service versus heavyweight dependencies in the app image, and request-path CPU/memory for large files.
• Fit with the no-code builder surface — how many tools, how well-named, how comprehensible to a non-developer.
• Effort, and dependencies on Preserve MCP session across tool calls #389 / Support agent-home-relative file references in MCP dial_url parameters #445 / [EPIC] Code interpreter as a standalone MCP application #424 / the interpreter image.
• Reusability by other DIAL agents, not only QuickApps.

Deliverables:

• Design doc in docs/designs/.
• A recommendation, explicitly including whether .xlsx should be scoped separately from .docx/.pptx.
• Child issues filed against [EPIC] Offline Office document support (docx, xlsx, pptx) #487 for the chosen path.

What alternatives have you considered?

• Skip discovery and implement the obvious option. Rejected: the two cheapest options have the worst failure modes. Markdown round-tripping silently destroys layout, and the code-interpreter route is non-deterministic because the model rewrites the code each time. Both demo well and fail on a customer's real template.
• Defer until the cloud-document path is decided. Rejected: the offline case is independent. Attachments and agent-home files exist regardless of whether a customer uses Google Workspace or Microsoft 365.
• A spike branch instead of a design doc. Rejected: the decisive criteria are fidelity and security, which require reasoning about untrusted-input handling and real-world styled documents rather than a prototype that works on a clean file.
• Pick per-format up front (e.g. templates for .docx, an engine for .xlsx). Not rejected — this is a plausible discovery outcome, but it should be a conclusion rather than a starting assumption.