"The decoration engine doing triple duty isn't a nice bonus. It's the whole reason CodeMirror was chosen."
Three Features, One Primitive
Step back and look at the three jobs together. Live Preview: compute ranges, attach marks (and replace decorations that hide tokens). Voice underline: compute ranges, attach a mark and a hover note. CMD+K: attach a widget holding a proposal, mutate on accept. Three features that look completely unrelated — a renderer, a linter, an AI editor — collapse to the same shape: compute ranges over the source, attach decorations, mutate only when the user commits. One primitive, learned once, powering the entire soul layer.
Live Preview ranges -> marks + replacements (render the look)
Voice underline ranges -> marks + a hover note (flag voice issues)
CMD+K a widget proposal -> one accept edit (stage an AI rewrite)
# Different inputs. Same decoration primitive. That's the win.
Where a Rich-Text Model Pulls Apart
Now imagine building the same three features on a rich-text tree (Tiptap over ProseMirror, or Lexical). Be fair to it first: ProseMirror has decorations too — inline ones that style a range and widget ones that insert UI, none of them mutating the document — so a voice underline and a pending CMD+K proposal could share that primitive there as well. The split comes from the model underneath. Live Preview isn't even a concept on a tree: the tree is the rendered form, and there is no Markdown source left to reveal on the active line, so "show source with a rendered look" fights the model. And every position the other two features compute is a tree position, which has to be translated back to the Markdown file you actually store. Two of the three jobs fit; the job that made Rekindle feel like Rekindle doesn't, and everything pays a translation tax.
The Reuse Is the Architecture
This is why 'one mechanism, three jobs' is a load-bearing decision, not a happy accident. CodeMirror was chosen because its decoration-over-source primitive makes all three soul features the same shape. The soul features — live voice, inline AI, every decoration-borne UI — ride one mechanism you build and debug once (margin-Pippa herself rides the bind; that's track 6). That's the family's first pillar, Reuse, expressed as an editor-core choice: don't pick the substrate with the most features; pick the one whose single primitive your features already share. When the reuse is that deep, it stops being an optimization and becomes the architecture.