Rich text editing: choose Lexical over TipTap for the entry editor

**Target release: 1.0.0**

#11 rebuilds the entry editor as two panes with a version rail. Whenever a content type carries a rich text field, the console needs a real editor. `contenteditable` is a well-known tarpit — this is not a build-our-own candidate.

## Recommendation: `lexical` + `@lexical/react`

| | |
|---|---|
| Version | 0.50.0, last publish 2026-09-02 |
| Licence | MIT |
| Backed by | Meta |

## Why Lexical rather than TipTap

Both are MIT and both pass a tarball inspection — `@tiptap/react` 3.31.3 was checked and is clean (an initial grep showed 22 hits, all false positives: "subscriptions" as the observer pattern, inside sourcemaps). Neither has a runtime licence gate today. So this is not a Rule 2 failure under #39.

The difference is the **upsell path**, which is Rule 2's forward-looking half:

- **TipTap** keeps its editor MIT, and open-sourced 10 formerly-Pro extensions in 2025. But comments, document history, real-time collaboration and AI live in a paid Cloud platform, with plans from $49/mo and the free tier removed in 2026. Every one of those is a plausible barakoBrew feature. The risk is not that TipTap bills you for what you have — it is that the next feature you want is on the other side of the paywall, after you have built on their editor.
- **Lexical** has no commercial tier and no plausible route to one. Meta does not sell it; it exists because Meta uses it. There is nothing to be upsold into.

Given the explicit preference for avoiding paid-tier exposure even where it is not forced today, Lexical is the more consistent choice.

### The honest trade

Lexical is the harder library. It is lower level, its documentation is thinner, and more of the editor UI is yours to build. TipTap's ProseMirror foundation and larger extension ecosystem would get a working editor sooner. **You are buying independence with implementation effort**, and it is worth naming that rather than pretending the choice is free.

Labelled `question` because this is the one recommendation in the set where the trade is genuinely arguable, and it should be a decision rather than an inherited default. If time-to-ship on #11 matters more than the upsell exposure, TipTap is defensible — it is MIT, it is clean today, and it can be forked.

## Before either

**Check what the API actually stores.** If a rich text field is persisted as HTML, Markdown or a portable-text structure, that constrains the editor far more than this licence discussion does — a mismatch between the editor's document model and the stored format is where round-trip corruption comes from. Settle the storage format first; it may be a barakoCMS question.

Also confirm this is needed at all for 1.0.0. If no content type in practice carries rich text yet, this drops out of the redesign and becomes a later feature.

## Sanitisation

Whatever wins, output is rendered by consumers of the API, and #17 is about generating public-facing pages from Brew. barakoCMS's site had a changelog renderer that "drops raw HTML and allowlists link protocols", gated in CI, for exactly this reason. Rich text authored in the console is a stored-XSS surface — sanitisation is part of this work, not a follow-up.

Serves #11. Related to #17. Follows #39.