docs: editing design (op-log, stable ids) + implementation plan

[andiwand]

🤖 Generated with Claude Code

Draft design doc capturing the decisions we made for in-browser editing of ODF/OOXML, why we took them, and a preliminary implementation plan. No code changes — docs/design/editing.md plus an index link.

Decisions (with rationale in the doc)

1. Architecture A — fat browser, replay-on-save over a live C++ model (B). A works offline and fits the one-shot translate/back_translate pipeline; write-side adapter work is identical either way, so B only buys drift-avoidance, which we handle with a conformance corpus.
2. JSON over the WebView message bridge, not HTTP (no localhost server / lifecycle).
3. Operation log, not a computed diff — ops are unambiguous and directly replayable.
4. Address by session-stable ElementIdentifier (data-odr-id), not DocumentPath. Session-stability reduces to append-only registry + tombstone deletes.
5. Op schema carries locations and ranges (id + anchor + offset), so inserts and inline formatting are expressible.
6. One-way, non-invertible, coalesced payload; undo/redo symmetry lives only in the browser where the inverse data is already local.
7. C++ replay is the authoritative validator — fail-fast, atomic save, version-stamped log, conformance corpus against JS/C++ drift.
8. Hand-rolled, model-first browser editor — no contenteditable-diffing, no JS framework dependency; budget for IME/composition and cross-block selection.

Plan

Phased: Phase 0 stable-id spike (linchpin) → Phase 1 op-log replay reworking html::edit → Phase 2 write-side adapter API for ODF/OOXML (the real cost) → Phase 3 browser editor → Phase 4 formatting UI.

Open questions listed at the end.