The web UI's four headline tools (Editors, .odb, .odm, Package / JSON) are permanent nav stubs

[Mearman]

Split out of issue 932, which bundled this with the missing e2e config (fixed separately). This half is the actual product gap: src/routes/-Sidebar.tsx's PLANNED_ITEMS renders Editors, .odb, .odm, and Package / JSON as disabled "Coming soon" entries with no route behind any of them.

Each is its own real feature, not a config fix:

• Editors: some in-browser document editing surface, not just convert/preview.
• .odb browsing: OpenDocument Base file inspection.
• .odm rendering: OpenDocument Master document rendering.
• Package / JSON dump-restore: round-tripping a document's internal structure to/from JSON.

Filing as one issue since they share the same "nav stub with no route" shape and the same sidebar entry point, not because they're one unit of work -- each needs its own scoping pass before implementation.

Affected packages: web

[Mearman]

Scoping pass, grounded in the web package's actual architecture (TanStack file routes → src/rpc/router.ts procedures executed in src/workers/documents.worker.ts → hooks in src/hooks/ wrapping them, with PLANNED_ITEMS in -Sidebar.tsx rendering the four entries as disabled "Coming soon" tooltips). Each tool is one rpc procedure + worker handler + hook + route file + sidebar activation, sharing that same shape:

• Package / JSON (lightest — the natural first): two rpc procedures, dump (bytes+format → the document's ContentDocument JSON via documents.js's registry readers and document-schema.js's own Zod serialisation) and restore (JSON → bytes via buildDocumentBytes). A textarea/file-picker route. No engine work — everything it needs is already exported.
• .odb browsing: an rpc procedure wrapping odf.js's readOdbInventory + documents.js's existing .odb SQL table reading (the latter already powers document-mcp), rendering inventory + table grids. The writer side is not needed for browsing.
• .odm rendering: readOdm gives chapter hrefs only (chapters are external files by design — see odf.js's reader notes), so in-browser rendering of a master document means letting the user supply/open the linked .odt files too, or rendering the master's own structure with external-link placeholders. Needs that UX decision before implementation.
• Editors: the largest — an in-browser editing surface per format family. documents.js's live-view editors (src/edit/docx|odt|markdown) are the engine; the web UI has never had an editing surface at all. This is its own multi-day effort and should be its own issue once the other three land.

[github-actions]

🎉 This issue has been resolved in version 2.11.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀