diff --git a/.claude/skills/resume-ckeditor/SKILL.md b/.claude/skills/resume-ckeditor/SKILL.md
new file mode 100644
index 000000000000..18be2d51a584
--- /dev/null
+++ b/.claude/skills/resume-ckeditor/SKILL.md
@@ -0,0 +1,51 @@
+---
+name: resume-ckeditor
+description: Resume the long-running "retire CKEditor / unify Undo" project (BL-6681). Use when the user says "/resume-ckeditor", "resume the ckeditor work", "continue retiring ckeditor", or picks that project back up after an interruption (sleep, token exhaustion, days off).
+---
+
+# Resume the CKEditor-retirement project (BL-6681)
+
+This is a deliberately long-running project spanning many sessions and many rebases against a
+moving `master`. Its state lives in `docs/retire-ckeditor/`, not in any session's memory.
+
+## Do this, in order
+
+1. **Read the state.**
+   - `docs/retire-ckeditor/PROGRESS.md` — the live log, current phase, and next actions. Start here.
+   - `docs/retire-ckeditor/PLAN.md` — the staged plan (Stages 0–6). Authoritative for *what* to
+     do. §11 records what BL-6681 itself asks for, and what on it is already obsolete.
+   - `docs/retire-ckeditor/REVIEW-NOTES.md` — findings already verified and decisions already
+     made. **Do not re-litigate anything settled there.** If you think a settled point is wrong,
+     say so explicitly to the user rather than quietly changing course.
+   - `docs/retire-ckeditor/BEHAVIOR-INVENTORY.md` if it exists — the behaviours that must survive.
+
+2. **Orient in git.** `git status`, `git log --oneline -15`, and note the current branch. Because
+   the plan deliberately avoids long-lived branches, you may well be on `master` with nothing in
+   flight; that is the normal resting state between stages, not a sign something was lost.
+
+3. **Check for drift.** Other work lands on `master` continuously. Before continuing a stage,
+   confirm the files it touches still look the way the plan assumes — the plan cites specific
+   `file:line` locations, and those move. If a citation has gone stale, fix the plan text as part
+   of the work; a plan nobody trusts is worse than no plan.
+
+4. **Continue from the next unchecked item** in PROGRESS.md's "Next actions". Confirm with the
+   user which stage to work on if more than one is plausible.
+
+5. **Before ending the session** (or when you sense you are running low on context), update
+   `PROGRESS.md`: what you did, what you learned, the branch/PR, and a revised "Next actions".
+   Do this even if the work is half-finished — especially then.
+
+## Ground rules for this project
+
+- **New code goes in new files** (`bookEdit/undo/`, `bookEdit/textEditor/`). Edits to existing
+  files should be one-line dispatches wherever possible, and as late in the plan as possible.
+  This is the project's whole defence against rebase pain.
+- **Don't keep a long-lived branch.** Each stage is designed to be its own small, green,
+  flag-inert PR onto `master`.
+- **Deletion commits (Stage 5) are regenerated, never rebased.** If one conflicts, throw it away
+  and redo it mechanically.
+- Build and test through the wrappers, never bare `dotnet`/`vite` — `build/agent-dotnet.sh` and
+  `build/agent-vite.sh` — because the developer usually has a Bloom running via `./go.sh`. See
+  `AGENTS.md`. Never run the full `pnpm build`.
+- To see a change in the running Bloom, just edit the source (the Vite dev server pushes it in)
+  and observe via the `run-bloom` skill. No build.
diff --git a/docs/retire-ckeditor/BEHAVIOR-INVENTORY.md b/docs/retire-ckeditor/BEHAVIOR-INVENTORY.md
new file mode 100644
index 000000000000..3a77441197b4
--- /dev/null
+++ b/docs/retire-ckeditor/BEHAVIOR-INVENTORY.md
@@ -0,0 +1,268 @@
+# Behaviour inventory — what must still work after CKEditor is gone
+
+Stage 0 of [PLAN.md](PLAN.md). This is the acceptance criteria for the whole project.
+
+## What is and isn't listed here
+
+Listed: behaviours **at risk from this project** — implemented by CKEditor, or implemented in code
+we will move or rewrite. Each row cites where it lives today and, where the code says so, the ticket
+that caused it.
+
+Not listed: behaviours of `.bloom-editable` handling that CKEditor is not involved in and that we
+are not moving. `BloomField.ManageField` is called from `SetupElements` regardless of CKEditor, so
+its arrow-key, backspace and paragraph-maintenance behaviours (BL-786, BL-933, BL-952, BL-2274,
+BL-7061, BL-16518 …) stay exactly where they are. They are not in scope and listing them would
+dilute the rows that matter.
+
+**A ticket number in the `Ticket` column means the code cites it**, not that we have read the
+ticket. Where the code's account of a ticket looks wrong, the row says so.
+
+## How to use it
+
+- `Verify` says how each row gets checked: **unit** (vitest), **live** (running Bloom over CDP via
+  the `run-bloom` skill), or **manual** (a human tester; feed these to the `add-test-ideas` skill).
+- Rows marked **⚠ capture first** must have today's actual behaviour recorded in a
+  `PASTE-DROP-BASELINE.md` *before* any code changes, because the row is a guarantee whose failure is
+  silent and the config string alone doesn't tell us what really happens. **That file does not exist
+  yet** — producing it is an open Stage 0 item (see PROGRESS.md), and deliberately so: it has to be
+  captured against a running Bloom, not written from the config.
+- Rows marked **✗ must NOT survive** are current behaviour we intend to *remove*. They are here so
+  nobody faithfully reimplements a workaround for a problem that no longer exists.
+
+---
+
+## A. Text selection toolbar (CKEditor service 1)
+
+| # | Behaviour | Today | Ticket | Verify |
+|---|---|---|---|---|
+| A1 | Selecting text in a `.bloom-editable` shows a floating toolbar; deselecting hides it | `attachToCkEditor` `selectionCheck` | | live |
+| A2 | Toolbar offers bold, italic, underline, superscript, text colour, remove-formatting, hyperlink — and **not** cut/copy/paste/undo/redo/anchor/strike/subscript/background-colour | `config.js` `removeButtons` | | manual |
+| A3 | Toolbar is positioned above the text box, moved down if it would go off-screen | `attachToCkEditor` `selectionCheck` | | manual |
+| A4 | Toolbar never appears for a field with `bloom-userCannotModifyStyles` (on the field or an ancestor up to `.marginBox`), but such a field is still editable and pasteable | `attachToCkEditor` `alwaysHideToolbar` | BL-14947 | live |
+| A5 | No toolbar for a field whose computed `cursor` is `not-allowed` | `attachToCkEditor` early return, `bloomEditing.ts:1952` | | live |
+| A6 | No flash of the toolbar during page load, nor when moving between two fields that both have selections | `hideAllCKEditors` body class | BL-12448 | manual |
+| A7 | Colour-picker panel does not re-open by itself on every subsequent selection | `attachToCkEditor` hides `.cke_panel` | | manual |
+| A8 | Toolbar button tooltips are localized | `localizeCkeditorTooltips` | | manual |
+| A9 | Text colour choices come from Bloom's text palette | `getHexColorsForPalette(BloomPalette.Text)` | | manual |
+
+**Deliberate improvement:** the new toolbar should use Bloom's existing `colorPickerDialog` instead
+of CKEditor's colour panel (§4.5), which supersedes A7 and A9 rather than reproducing them.
+
+## B. Formatting commands
+
+| # | Behaviour | Today | Ticket | Verify |
+|---|---|---|---|---|
+| B1 | Bold / italic / underline / superscript apply and un-apply over a selection, including one spanning several paragraphs | CKEditor `basicstyles`; `<strong>`/`<em>`/`<u>`/`<sup>` | | unit + live |
+| B2 | Bold produces `<strong>`, italic `<em>`, underline `<u>`, superscript `<sup>` — the tags the talking-book code expects to see inside a sentence | `audioRecording.ts:3727-3730` | | unit |
+| B3 | Text colour produces a **bare** `<span style="color:…">` with no class or id | `config.js` colorbutton | | unit |
+| B4 | Ctrl+Space ("clear formatting") strips only `b,strong,i,em,u,sup,sub,font,span` | `config.js removeFormatTags`, `bloomEditing.ts:291-299` | | unit |
+| B5 | Clear-formatting **preserves any `<span>` carrying a class or id** — audio segments (`audio-sentence`, `bloom-highlightSegment`) and `bloom-linebreak` | `attachToCkEditor` `addRemoveFormatFilter` | | unit |
+| B6 | Clear-formatting does **not** strip `class`/`style`/`align`/`lang` from elements it keeps (e.g. paragraphs merely spanned by the selection) | `config.js removeFormatAttributes = ""` | | unit |
+| B7 | F6 wraps the selection in `<sup>`; F7 → `<h1>`; F8 → `<h2>`; Ctrl+Alt+0 → `<p>`; Ctrl+Alt+1 → `<h1>`; Ctrl+Alt+2 → `<h2>` | `AddEditKeyHandlers` | | live |
+| B8 | Ctrl+R / Ctrl+L / Ctrl+E right/left/centre justify | `AddEditKeyHandlers` | | live |
+| B9 | Shift+Enter inserts `<span class="bloom-linebreak"></span>` plus a ZWNJ if needed, and leaves the caret **after** it | `BloomField.InsertLineBreak` | BL-3009 | unit + live |
+| B10 | The caret is never left *inside* a `bloom-linebreak` span | `BloomField.EnsureCaretNotInsideLineBreakSpan`, on selection change | | unit |
+| B11 | An **empty** `span.bloom-linebreak` survives round-tripping and is not stripped as an empty element | `CKEDITOR.dtd.$removeEmpty.span = 0` | BL-3009 | unit |
+| B12 | Typing a URL then a space/enter turns it into a live link | `autolink` plugin | BL-6845 | live |
+| B13 | `.bloom-editable` divs get `spellcheck="false"` — no red squiggles | `config.disableNativeSpellChecker` | BL-12205 | live |
+| B14 | Hyperlink button opens the link-target chooser and wraps the selection in `<a href>`; failure on a complex selection shows the `EditTab.HyperlinkPasteFailure` message | `BloomField` `setupHyperlink` command | | manual |
+
+**Decision (§10 q2):** B14's dialog and flow are kept exactly as-is.
+
+## C. Paste and drop filtering — the silent-failure guarantee
+
+**⚠ Every row in this section must be captured first** (§4.8). The permitted vocabulary today is
+`p br em i strong sup u; b{font-weight}; a[!href]; span{font-variant,color}`
+(`config.js:119-120`); everything else, attributes included, is dropped.
+
+| # | Behaviour | Today | Ticket | Verify |
+|---|---|---|---|---|
+| C1 | Pasting a **table** does not produce a table | `pasteFilter` | | ⚠ capture, then unit + live |
+| C2 | Pasting nested **`<div>`s** does not produce divs — importantly, a div copied from another Bloom book must not arrive with its **id**, which would duplicate an id in this book | `pasteFilter` | BL-3899 | ⚠ capture, then unit + live |
+| C3 | Pasting an **`<iframe>`**, `<script>`, `<style>`, `<object>` or `<embed>` produces none of them | `pasteFilter` | | ⚠ capture, then unit |
+| C4 | Pasting an **`<img>`** does not embed the image in the text | `pasteFilter` | | ⚠ capture, then live |
+| C5 | Pasting arbitrary styled `<span>` soup from a real web page keeps only `font-variant` and `color` | `pasteFilter` | BL-4775, BL-12357 | ⚠ capture, then unit |
+| C6 | Pasting `<a href>` keeps the link; other attributes on it are dropped | `pasteFilter` `a[!href]` | | ⚠ capture, then unit |
+| C7 | **Dropping** any of C1–C6 from outside Bloom is filtered the same way as pasting | CKEditor's clipboard plugin routes `drop` through the same filter, `ckeditor.js:622` | | ⚠ capture, then live |
+| C8 | Dragging a canvas element from the toolbox onto a page still works (Bloom's own internal drag, custom `text/x-bloom-canvas-element` type) | `CanvasElementManager.ts:2069-2088` | BL-7958 (Linux) | live |
+| C9 | Pasting **plain** text with several lines produces several paragraphs | `reconstituteParagraphsOnPlainTextPaste` | BL-9961 | unit |
+| C10 | Bloom's own code can still write markup the paste filter would reject (audio spans with ids, `bloom-linebreak`, canvas elements) — the filter applies **only** at the clipboard/drop boundary | `config.allowedContent = true` alongside a restrictive `pasteFilter` | BL-3899 / BL-3976 (the first fix filtered everything and broke this) | unit |
+
+## D. Paste transforms
+
+These move to the new `pasteHandler.ts` essentially unchanged (§6 Stage 3), except D8.
+
+| # | Behaviour | Today | Ticket | Verify |
+|---|---|---|---|---|
+| D1 | `<b>`/`<i>` from other sources become `<strong>`/`<em>`; a Google-Docs `<b style="font-weight:normal">` does **not** paste as bold | `BloomField.fixPasteData` | BL-8711 | unit |
+| D2 | Attribute-less `<span>` elements from Word are removed (they broke aeneas audio splitting) | `BloomField.removeUselessSpanMarkup` | BL-12861 | unit |
+| D3 | `\v 12` (Standard Format verse markers) become superscripts | `BloomField.convertStandardFormatVerseMarkersToSuperscript` | | unit |
+| D4 | `bloom-linebreak` spans in pasted HTML are normalized, and any content wrongly inside one is moved out | `BloomField.normalizeBloomLineBreakSpans`, `EditableDivUtils.normalizeBloomLineBreakSpansInElement` | | unit |
+| D5 | Pasting into a **Sentence**-mode recording div copies the audio files under **new** guid ids, so ids are not duplicated | `BloomField.copyAudioFilesWithNewIdsDuringPasting` | | live |
+| D6 | Pasting into a **TextBox**-mode recording div strips all audio span markup | `BloomField.removeAudioSpanMarkupDuringPasting` | | unit |
+| D7 | The first pasted `<p>` is unwrapped so the paste joins the current paragraph rather than starting a new one; any placeholder paragraph used to force a following break is removed afterwards | `BloomField` paste / `afterPaste` `.removeMe` | | unit + live |
+| D8 | Small caps and text colour survive a copy-paste **within** Bloom | `BloomField.restoreHtmlMarkupIfNecessary` | BL-12357 | ⚠ see below |
+
+**D8 cannot be ported as-is.** It works by detecting CKEditor-internal copies via
+`dataTransfer.getData("cke/id")` and compensating for CKEditor's *own* stripping of spans from
+`dataValue`. With CKEditor gone, nothing stamps `cke/id` and nothing strips the spans, so the
+transform is meaningless as written — and the problem may not exist at all once `pasteHandler.ts`
+reads raw `clipboardData`. **Verify against the BL-12357 repro; do not port.**
+
+## E. Clipboard: cut, copy, paste plumbing
+
+| # | Behaviour | Today | Ticket | Verify |
+|---|---|---|---|---|
+| E1 | The toolbar Copy button copies the selection; with no selection it copies the active canvas element's whole text, trimmed of trailing whitespace | `bloomEditing.copyImpl` | BL-14051 | live |
+| E2 | The toolbar Cut button removes the selection and it is undoable as **one** step | `cutSelectionImpl` via `undoManager.save/lock` | | live |
+| E3 | The toolbar Paste button inserts at the selection, as one undo step | `pasteImpl` | | live |
+| E4 | Pasting onto a canvas element that is *selected but not being text-edited* replaces its **entire** content, then updates the element's auto-height and reschedules toolbox markup | `pasteImpl` canvas branch | BL-14004 | live |
+| E5 | Ctrl+V with an image on the clipboard pastes the image onto the canvas rather than into the text | `pasteHandler` + `editView/paste` API | BL-15123 | manual |
+| E6 | Paste into an `<input>`/`<textarea>` (e.g. a canvas-element label) uses default browser behaviour | `pasteHandler` early return | | live |
+| E7 | Cut/copy/paste **buttons' enabled state** tracks whether there is a selection and what is on the clipboard | `WebView2Browser.UpdateEditButtonsAsync` | | live |
+
+**Scope (§10 q3):** clipboard work here is a **seam only**. The new `clipboard.ts` must produce both
+`text/html` and `text/plain` and keep the write behind one interface, but still writes from JS — so
+the BL-16459 data-loss-on-cut problem is *not* fixed here. See §4.9 and PR #8140 before touching it.
+
+**✗ Must NOT survive:** the duplicate Ctrl+V `keydown` handler at `bloomEditing.ts:1764-1770`,
+which exists only because CKEditor swallows `paste` inside editables. Once it doesn't, the
+document-level `paste` listener fires normally. Verify, then delete.
+
+## F. Getting clean HTML out of an editable
+
+| # | Behaviour | Today | Ticket | Verify |
+|---|---|---|---|---|
+| F1 | Saved HTML contains no zero-width-space "filling char" (U+200B) | `getData()` + `removeCkEditorFillingChars` | BL-12391, BL-16490 | unit |
+| F2 | U+200C (ZWNJ) and U+200D (ZWJ) **are preserved** — they are legitimate in some scripts, and `InsertLineBreak` deliberately inserts a ZWNJ | `removeCkEditorFillingChars` removes only U+200B | | unit |
+| F3 | Saved HTML contains no `cke_*` classes, `cke_bm_*` bookmark spans, `data-cke-saved-href`, or injected HTML comments | JS + C# scrubbing | BL-4775, BL-16065 | unit (C#) |
+| F4 | A paragraph containing only a `<br>` is not silently turned into one containing `&nbsp;` | `fixUpEmptyishParagraphs` | | unit |
+| F5 | Reader-tools markup rewriting an editable's `innerHTML` does not leave an orphaned filling char behind that corrupts word matching | `doCkEditorCleanup` strips before comparing | BL-16490 | unit |
+
+**✗ Should become unnecessary:** F1, F3, F4 and F5 are all artifacts of CKEditor. After Stage 5 the
+"clean HTML" of an editable should be `innerHTML` plus a minimal normalizer. **The C#-side scrubbers
+stay** (as `LegacyCkEditorCleanup`) because books already on disk contain these artifacts — that is a
+different requirement from the browser producing them.
+
+## G. Selection survival across DOM rewrites
+
+The reason CKEditor bookmarks exist. Being replaced by offset-based anchors (§4.3).
+
+| # | Behaviour | Today | Ticket | Verify |
+|---|---|---|---|---|
+| G1 | Typing in a box with a reader tool active leaves the caret where the user put it, though the markup around it was rewritten | `createBookmarks`/`selectBookmarks` in `toolbox.ts` | BL-3900 | live |
+| G2 | With an **async** `updateMarkupAsync` tool, keystrokes arriving during the await do not go to a wrong position | double bookmark save/restore | BL-10133 | live |
+| G3 | Longpress (the character map) is not broken by markup updates, and its replacement of the preceding letter still works | keydown-not-keypress; `isLongPressEvaluating` guard | BL-3900, BL-5215 | manual |
+| G4 | Caret survives the reader-tools `innerHTML` rewrite | `readerToolsModel` caret offset + `makeSelectionIn` | | unit |
+| G5 | Caret position is restored correctly around `<br>` elements | `makeSelectionIn`'s `divBrCount` | | unit |
+| G6 | **Reader violation highlights survive typing** — over-long sentences/words and non-decodable words stay highlighted as you type, rather than flashing off at every pause | `textHighlightManager.ts` / `readerHighlights.ts`, `::highlight()` over live Ranges; `editMode.less:1074-1100` | BL-16558 | live (see note) |
+| G7 | **The Talking Book current-sentence highlight survives the same way** | `audioTextHighlightManager`, `editMode.less:1145` | BL-16558 | live |
+
+**G6/G7 are new since this inventory was first written, and they change G1's premise.** Reader
+markup no longer rewrites the DOM to show violations — it paints `::highlight()` pseudo-elements
+over **live `Range` objects**. So:
+
+- The old worry "markup rewrites the DOM around the caret" is now *less* true for reader tools, and
+  the new worry is the reverse: **anything that rebuilds an editable's text nodes collapses those
+  Ranges and the highlights silently vanish.** That is what BL-16558 fixed by making `cleanUpNbsps`
+  write `innerHTML` only when it actually changed something, and by moving `updateMarkup()` to after
+  it.
+- This binds our work directly: a Tier 1 undo restores `editable.innerHTML` (PLAN §4.11), which will
+  collapse them. The restore must repaint. **The failure mode is silent** — no error, undo looks
+  fine, the highlights are just gone.
+- `toolbox.ts` says outright that the ordering here is not unit-testable and must be checked by
+  "*typing in a Leveled Reader book and watching the over-long sentences stay highlighted*". Treat
+  that as the acceptance test for G6.
+
+**✗ Must NOT survive — a bug to fix, not preserve:** the bookmark approach makes the markup routine
+see `"hous"`-marker-`"e"` while the user fixes a letter mid-word, so reader markup is briefly wrong
+(`toolbox.ts:1521-1528` documents this against itself). An offset-based anchor doesn't perturb the
+DOM, so **G1 should get strictly better**.
+
+## H. Undo and Redo
+
+| # | Behaviour | Today | Ticket | Verify |
+|---|---|---|---|---|
+| H1 | The Undo button is enabled exactly when something can be undone | `workspaceBundle.canUndo()` polled from C# | | live |
+| H2 | `canUndo()` stays cheap — C# polls it on a timer; expensive work makes the button flicker | `WebView2Browser.cs:963-996` | | unit |
+| H3 | Undo reverses text edits, coalesced into sensible units rather than one per keystroke | CKEditor `undoManager` | | live |
+| H4 | Undo reverses a cut and a paste as single steps | `undoManager.save/lock` | | live |
+| H5 | Undo reverses origami (Change Layout) changes, and **Ctrl+Y redoes them** | `origamiUndo`/`origamiRedo`, own `keydown.origami` | | live |
+| H6 | Undo reverses an image replacement, restoring src, copyright, creator, licence and crop | `ImageUndoManager` | BL-16330 | live |
+| H7 | With a reader tool active, Undo restores the *pre-markup* text rather than re-applying stale markup — i.e. reader-tools undo takes precedence over CKEditor's | `handleUndo` order; `shouldHandleUndo` | | live |
+| H8 | Undoing an image operation is offered only when the active element is an image container | `canUndoImageOperation` | | unit |
+| H9 | Undo state is dropped when the page changes | `clearImageOperationUndoOnPageChange` | | unit |
+
+**New behaviour this project adds** (not regressions to guard, but acceptance criteria):
+
+| # | New behaviour | Plan |
+|---|---|---|
+| H10 | One ordered stack: operations undo in the order performed, across text, images, layout and structure | §4.1, Stage 1 |
+| H11 | **Deleting a canvas element is undoable** | Stage 2b |
+| H12 | **Deleting a page is undoable**, restoring it at its original index with correct page numbering | Stage 2a |
+| H13 | Ctrl+Z / Ctrl+Y work anywhere in the page, not only in layout mode | Stage 4 |
+| H14 | Redo works for everything undoable that has a `redo` (entries without one act as a redo floor) | §4.1, §10 q1 |
+| H15 | The browser's own undo can never diverge from Bloom's stack | §4.4 `beforeinput` fence |
+| H16 | Undo of typing is fast — no page reload, no C# round-trip | §4.11 Tier 1 |
+| H17 | One undo step per user gesture — no operation records two entries | §4.13 nesting |
+
+## I. Startup: things that must still work once the async races are gone
+
+These rows exist because Stage 5 **deletes** the workarounds. The behaviour must survive their
+removal.
+
+| # | Behaviour | Workaround being deleted | Ticket | Verify |
+|---|---|---|---|---|
+| I1 | The format gear ("cog") appears on the focused text box and is not eaten during page setup | `StyleEditor.AttachToBox`'s `instanceReady` wait | | live |
+| I2 | A tool's saved state is applied to a freshly loaded page and is not overwritten by editor init | `doWhenCkEditorReady` | BL-12381 | live |
+| I3 | Placeholder text set during page load survives | `PlaceholderProvider`'s `instanceReady` re-set | | live |
+| I4 | Game prompt text set programmatically is not reverted | `GamePromptDialog.tsx:422-427` ordering | | live |
+| I5 | Longpress works on editables after page setup | post-init `activateLongPressFor` re-attach | | live |
+| I6 | Talking-book highlight does not vanish or flash during page setup | `setHighlightSession` counter | BL-15300; **originally BL-6681 itself** | live |
+| I7 | Off-screen page processing (`external/process-book`) still works — it runs with CKEditor absent today, which is why the flag-on path is already viable | `BookProcessor` strips the script tag | | unit (C#) |
+
+**On I6:** the race that opened BL-6681 — CKEditor asynchronously resetting a `.bloom-editable` and
+clobbering the highlight class — is **already gone**, because the highlight moved out of the DOM into
+`AudioTextHighlightManager`. Do not go looking for it. `setHighlightSession` guards a different thing
+("*newPageReady fires twice*") that may not be CKEditor's fault at all: **measure before deleting**.
+
+## J. Fields that deliberately get no rich-text editor
+
+| # | Behaviour | Today | Verify |
+|---|---|---|---|
+| J1 | Only fields matching `ckeditableSelector` get an editor: `bloom-content1/2/3`, `bloom-contentNational1/2`, and **`Equation-style`** — all requiring `contenteditable="true"` | `utils/shared.ts:16-19` | unit |
+| J2 | A field whose computed cursor is `not-allowed` gets no editor | `attachToCkEditor` early return | live |
+
+**✗ Do not port:** `bootstrap()`'s BL-3125 guard skipping fields containing a `.bloom-canvas`
+(`bloomEditing.ts:1216`) is **dead code** — `this` is `undefined` in a strict-mode module function,
+so `$(this).find(...)` is always empty, and canvas-element editables do get an editor via
+`CanvasElementManager.addEventsToFocusableElements`. Also note `toolbox.ts:1530-1537`'s claim that
+ArithmeticTemplate boxes get no editor is **false**; see J1.
+
+## K. Focus, bubbles and incidental wiring
+
+| # | Behaviour | Today | Ticket | Verify |
+|---|---|---|---|---|
+| K1 | The focused field's hint tooltip sits above Source Bubbles; on blur it drops back | `WireToCKEditor` focus/blur qtip class juggling | BL-11745 | manual |
+| K2 | If the user deletes all text in a `bloom-copyFromOtherLanguageIfNecessary` field, `data-user-deleted="true"` is set so text is not copied back in later | `WireToCKEditor` `change` handler | BL-13779 | live |
+| K3 | Every editable ends up containing at least one `<p>` | `BloomField.EnsureParagraphsPresent` | BL-6721 | unit |
+| K4 | Elements marked `bloom-preventRemoval` inside an editable cannot be removed by Ctrl+A Del | `PreventRemovalOfSomeElements` via `execCommand("undo")` | | live |
+
+**K4 needs a new implementation, not a port.** It currently *allows* the deletion and then calls
+`document.execCommand("undo")` to reverse it — using the very browser undo stack we are fencing off
+(§4.4). Replace with a `beforeinput` guard: reject any `delete*` whose `getTargetRanges()` covers a
+`.bloom-preventRemoval` element.
+
+---
+
+## Cross-cutting acceptance criteria
+
+| # | Criterion |
+|---|---|
+| X1 | Everything above holds with the flag **off** (CKEditor present) and **on** (CKEditor not even loaded) |
+| X2 | `pnpm test`, `pnpm lint`, `pnpm typecheck` and `build/agent-vite.sh` green in both states |
+| X3 | The C# suite green via `build/agent-dotnet.sh` |
+| X4 | No listener leak: after N page setup/teardown cycles the page's listener count is unchanged (CDP `DOMDebugger.getEventListeners`, §4.10). **This fails today** |
+| X5 | Page load is no slower than the Stage 0 baseline, and expected to be faster |
+| X6 | Books saved by the new path open correctly in the previous Bloom version's editor (no new markup it can't handle) |
+| X7 | Soak: a talking-book book, a decodable/leveled reader book, a drag-activity book, an RTL book, and a book with an image embedded in a text field |
diff --git a/docs/retire-ckeditor/PLAN.md b/docs/retire-ckeditor/PLAN.md
new file mode 100644
index 000000000000..512b953d239c
--- /dev/null
+++ b/docs/retire-ckeditor/PLAN.md
@@ -0,0 +1,1113 @@
+# Retiring CKEditor from Bloom's edit mode (BL-6681)
+
+**Status:** plan, reviewed once (see [REVIEW-NOTES.md](REVIEW-NOTES.md)), BL-6681's own content
+folded in (§11), not yet started. Live state in [PROGRESS.md](PROGRESS.md).
+
+## 1. Goals
+
+1. **Remove CKEditor 4** (a 2015-era, hand-patched, 1.5 MB vendored copy) from Bloom's edit
+   mode, replacing it with our own code. No replacement library.
+2. **Give Bloom one consistent Undo stack.** Today there are five poorly-coordinated undo
+   mechanisms. We want a single, ordered stack covering changes to the current page, plus
+   "undo delete page" as the one deliberate cross-page exception. Priority is on operations
+   that are *hard to reverse by hand* (delete a canvas element, delete a page) over ones that
+   are easy (add a canvas element — just delete it).
+3. **Simplify page loading and toolbox init**, most of whose complexity exists only to work
+   around CKEditor mutating the DOM asynchronously during startup.
+4. Do it in a way that survives **many rebases** over a long calendar period.
+
+Non-goals (out of scope, but the design must not obstruct them): widening undo beyond the current
+page; undo across a Bloom restart; a rich-text editor usable outside Bloom's edit mode; the C#
+multi-format clipboard write that would close BL-16459 (§10 q3). **Redo is in scope** — Ctrl+Y only,
+no toolbar button (§10 q1).
+
+### Target environment
+
+Edit mode runs only in WebView2 (currently minimum 112, `WebView2Browser.kMinimumWebView2Version`).
+Raising that minimum is permitted but should stay on **standard** platform APIs, because Bloom
+is expected to be ported to a Mac browser component later. Everything this plan needs
+(`beforeinput` / `InputEvent.getTargetRanges`, `Range`, `Selection`,
+`ClipboardEvent.clipboardData`, `MutationObserver`) is Chrome 60-era or older, so **no version
+bump is required**. Recorded here so nobody spends the budget.
+
+## 2. What CKEditor is doing for us today
+
+Bloom does not use CKEditor as a document editor. The `.bloom-editable` divs arrive from C#
+already `contenteditable="true"`; the browser does the typing. `CKEDITOR.inline(element)` is
+attached (`bloomEditing.ts` `attachToCkEditor`, `BloomField.WireToCKEditor`) for these
+services:
+
+| # | Service | Where it's consumed |
+| --- | --- | --- |
+| 1 | Floating selection toolbar: bold / italic / underline / superscript / text colour / remove-format / hyperlink | `attachToCkEditor` `selectionCheck`, `localizeCkeditorTooltips`, `editMode.less` `.cke_float`, `hideAllCKEditors` (BL-12448) |
+| 2 | A text-edit **undo stack** we drive from our own Undo button | `editablePage.ts` `ckeditorCanUndo`/`ckeditorUndo`, `workspaceRoot.handleUndo` |
+| 3 | **Paste/drop content filtering** — a strict **allow-list** (`config.pasteFilter`) that keeps users from introducing HTML Bloom's own UI could never create. See §4.8; this is a safety guarantee, not a nicety. | `config.js:119-120`; CKEditor's clipboard plugin also routes **drop** through it |
+| 3b | **Paste transforms** — the `paste`/`afterPaste` events themselves | `BloomField.WireToCKEditor` (SFM verse markers, audio-span id regeneration, small-caps preservation, first-`<p>` unwrapping), `bloomEditing.pasteImpl` |
+| 4 | `getData()` — "clean" HTML, notably without the ZWSP *filling char* | `EditableDivUtils.doCkEditorCleanup`, `audioRecording.cleanUpCkEditorHtml` |
+| 5 | **Bookmarks** (`createBookmarks(true)`) for selection save/restore across DOM rewrites | `toolbox.ts` keystroke pipeline, `readerToolsModel.doMarkup`, `EditableDivUtils.restoreSelectionFromCkEditorBookmarks` |
+| 6 | `key` event, to intercept Shift+Enter | `BloomField.WireToCKEditor` → `InsertLineBreak` |
+| 7 | `insertText`; `undoManager.lock/save` for atomic multi-step edits | `bloomEditing.cutSelectionImpl`, `pasteImpl` |
+| 8 | `change` event, used for the BL-13779 `data-user-deleted` tracking on `bloom-copyFromOtherLanguageIfNecessary` fields | `BloomField.ts:244-252` |
+| 9 | `focus`/`blur`, used to juggle qtip z-order between hint tooltips and Source Bubbles (BL-11745) | `BloomField.ts:345-366` |
+| 10 | `selectionChange` → `EnsureCaretNotInsideLineBreakSpan` | `BloomField.ts:259-261` |
+| 11 | `addCommand`/`ui.addButton` for the **SetupLink** hyperlink button | `BloomField.ts:368-415` |
+| 12 | Odds and ends: `autolink` plugin (BL-6845); `disableNativeSpellChecker` → `spellcheck="false"` (BL-12205); `CKEDITOR.dtd.$removeEmpty.span = 0` so empty `span.bloom-linebreak` survives (BL-3009); `removeFormat` with a filter protecting structural spans; colour-palette caching | `config.js`, `attachToCkEditor` |
+
+And one thing it does **to** us rather than for us, which belongs in the same table because the
+new editor must decide what to do instead:
+
+| # | Interference | Evidence |
+| --- | --- | --- |
+| 13 | CKEditor `preventDefault()`s `copy` and `cut` inside a `.bloom-editable` and swallows `paste`, so Bloom's document-level `paste` listener never fires there. Bloom compensates with a **duplicate Ctrl+V `keydown` handler** whose comment says so outright. | `bloomEditing.ts:1752-1770` ("*The pasteHandler does not get invoked … probably because some CkEditor code intercepts it and prevents default*"); recorded again on BL-6681 from the BL-16459 investigation |
+
+### What it costs us
+
+**Startup-race workarounds** — all of these exist *only* because CKEditor mutates the DOM
+asynchronously after `CKEDITOR.inline()` returns:
+- `toolbox.ts` `doWhenCkEditorReady` / `doWhenCkEditorReadyCore` (~65 lines, with its own
+  listener-remover bookkeeping, BL-12381).
+- `StyleEditor.AttachToBox`'s `instanceReady` dance (~35 lines) — the format-gear icon must
+  wait because CKEditor replaces an empty div's content with `<p><br></p>` and eats the icon.
+- `PlaceholderProvider.ts` re-applies placeholder text on `instanceReady`.
+- `GamePromptDialog.tsx:422-427` must finish setting content *before*
+  `refreshCanvasElementEditing`, "because by the end of the process, the text gets set back to
+  what it was".
+- `bloomEditing.bootstrap` re-runs `activateLongPressFor` after wiring editors because
+  "CKEditor initialization can replace editable nodes".
+- `CommonApi.cs:110` — a GET fires during page init "probably hooking up CkEditor, an
+  unwanted...".
+
+**Artifact scrubbing**
+- ZWSP filling char: `EditableDivUtils.removeCkEditorFillingChars` (BL-12391, BL-16490),
+  `PublishHelper.cs:382`.
+- `cke_bm_*` bookmark spans: `EditableDivUtils.isNodeCkEditorBookmark` /
+  `fixUpEmptyishParagraphs` / `safelyReplaceContentWithCkEditorData`,
+  `toolbox.ts setCkeditorBookmarkContent` + `cleanUpNbsps`, `jquery.text-markup.ts` `ckeRegex`,
+  `BookData.IsCkEditorBookmarkSpan` + `NormalizeEditableInnerXml` (BL-16065).
+- `cke_*` classes in saved HTML: `HtmlDom.RemoveCkEditorMarkup`.
+- `data-cke-saved-href`: `HtmlDom.CleanupAnchorElements`.
+- `<br>` before `</p>`: `XmlHtmlConverter.cs` regex (BL-2557).
+- HTML comments injected on paste: `toolbox.removeCommentsFromEditableHtml` (BL-4775).
+- Caret normalization suspected in TBT fragment splitting (`Book.cs:1334`).
+- `BookProcessor.cs:179-182` strips the `<script>` tag so off-screen page processing works.
+- `BloomServer.cs:1041` special-cases `ckeditor/skins/flat/icons`; `ProjectContext.cs:597`
+  registers the skin folder.
+
+### Two pieces of dead or misleading code — do not port
+
+- **The BL-3125 `.bloom-canvas` guard is dead.** `bloomEditing.ts:1216`'s
+  `if ($(this).find(".bloom-canvas").length) return;` never fires: `bootstrap` is a
+  strict-mode module function called as `bootstrap()`, so `this` is `undefined` and
+  `$(undefined).find(...)` is empty. Canvas-element editables *do* get CKEditor, via
+  `CanvasElementManager.addEventsToFocusableElements` (`CanvasElementManager.ts:951`). Verify
+  and delete.
+- **`toolbox.ts:1530-1537`'s comment is stale.** It claims ArithmeticTemplate / numeric boxes
+  get no editor "because the logic that invokes WireToCKEditor is looking for classes like
+  bloom-content1". Not so: `utils/shared.ts:16-19` explicitly includes
+  `.Equation-style[contenteditable='true']` in `ckeditableSelector`, added for that very
+  template. The **real** "no editor" case is `attachToCkEditor`'s early return for elements
+  with `cursor: not-allowed` (`bloomEditing.ts:1952`). Preserve that; don't preserve a
+  behaviour that doesn't exist.
+
+## 3. Current Undo: five mechanisms
+
+`workspaceRoot.handleUndo()` / `canUndo()` consult them in a fixed order:
+
+| Mechanism | What it really is | Notes |
+| --- | --- | --- |
+| `origamiCanUndo`/`origamiUndo` (`origami.ts:262-294`) | A stack of **jQuery `clone(true)` copies of `.marginBox`** — DOM plus attached handlers and data — restored with `replaceWith` | Only while Change Layout mode is active. Has its **own** `keydown.origami` Ctrl+Z/Ctrl+Y handler on `html` (`origami.ts:139-146`), and its own Redo. Safe today partly *because* layout mode strips `contentEditable` (`origami.ts:132`), so there are no live CKEditor instances to orphan. |
+| `toolboxWindow.canUndo/undo` → `readerToolsModel` | A per-editable **text-typing** undo: `{html, text, caretOffset}` snapshots, seeded on focus (`noteFocus`, :557-568, from `decodableReaderTool.tsx:155`) and pushed on every markup-changing keystroke inside `doMarkup` (:753-764) | Gated on `shouldHandleUndo()` — `currentMarkupType !== None` (:570). It is consulted *before* CKEditor **deliberately**: when a reader tool is active it must shadow CKEditor's undo, which would restore stale decodable/leveled markup. Not "reader-setup changes". |
+| `imageOperationCanUndo`/`imageOperationUndo` (`ImageUndoManager.ts`) | Restores an image's `src` / copyright / crop | Clean two-phase prepare/commit; already page-id-scoped; gated on the active element being an image container. |
+| `ckeditorCanUndo`/`ckeditorUndo` | `CKEDITOR.currentInstance.undoManager`, **per editable div** | An "implementation secret". Ordering across boxes is already wrong. |
+| Browser-native undo | Invisible | Called directly in `BloomField.PreventRemovalOfSomeElements` (`BloomField.ts:810-825`); also fed implicitly by every `document.execCommand("insertHTML"/"formatBlock"/"justify*"/"insertText")` in `bloomEditing.ts` and `GamePromptDialog.tsx`, and by plain typing in any contenteditable. |
+
+Two corrections to the folklore:
+- `workspaceRoot.ts:125`'s "*See also Browser.Undo; if all else fails we ask the C# browser
+  object to Undo*" is **stale** — no such fallback exists in the WebView2 code. The Undo
+  button's enabled state comes purely from `workspaceBundle.canUndo()` returning `"yes"`
+  (`WebView2Browser.CanUndoAsync`, polled on a timer from `UpdateEditButtonsAsync`).
+- `config.undoStackSize = 0` in `config.js` claims to prevent a crash; CKEditor 4 reads
+  `config.undoStackSize || 20`, so it silently means 20. Don't preserve the intent blindly.
+
+**Not undoable at all today:** deleting a canvas element, deleting a page, style changes, most
+toolbox operations — i.e. precisely the hard-to-reverse things.
+
+## 4. Design decisions
+
+### 4.1 Undo entries are data, interpreted at undo time
+
+Two architectures were considered: a command/inverse-op stack (precise, memory-light, but every
+operation must be taught to undo itself) and a snapshot stack (uniform, covers operations
+nobody enumerated). **Use snapshots as the default entry type, with inverse-op entries where a
+snapshot is too blunt.**
+
+The critical constraint, which shapes the contract: the page iframe's JS context dies not only
+on page *change* but on same-page **reloads** — ctrl+wheel zoom regenerates the page
+(`bloomEditing.ts:1268`), origami exit posts `saveChangesAndRethinkPageEvent`
+(`origami.ts:193`), and several tools navigate. An entry that closes over page-frame DOM or
+functions therefore becomes a live grenade: `undo()` would mutate a detached document or throw.
+
+So **snapshot entries must be pure data**, interpreted at undo time by a restore function that
+re-acquires the current page frame via `getEditablePageBundleExports()`:
+
+```ts
+export interface IUndoEntry {
+    label: string;                  // "Delete canvas element" — tooltips, logging
+    pageId: string | undefined;     // undefined = survives page change (delete-page)
+    kind: "pageSnapshot" | "subtreeSnapshot" | "custom";
+    undo(): void | Promise<void>;   // for "custom" only; snapshot kinds carry data instead
+    redo?(): void | Promise<void>;
+}
+```
+
+Closure-bearing (`custom`) entries are permitted only for **workspace-owned** operations —
+delete-page being the main one — never for page-frame DOM. In addition to clearing page-scoped
+entries when the page id changes, **re-validate or clear on page-frame unload/load**;
+`switchContentPage` (`workspaceRoot.ts:135-186`) already has the hook points.
+
+Bound the stack by **entry count** (~50). Skip byte accounting until something proves it
+necessary; 50 page-HTML strings is single-digit MB worst case.
+
+**Redo is in scope (§10 q1), so the stack is index-based, not pop-based.** Keep `entries[]` plus a
+`currentIndex`: undo steps the index back, redo steps it forward, and any new push truncates
+everything above the index (so typing after an undo discards the redo branch — standard, expected
+behaviour). Two things keep the cost genuinely small:
+
+- **Capture the "after" state lazily, at undo time**, not at commit time: when undoing a snapshot
+  entry, first capture the *current* state as that entry's redo state, then restore the before
+  state. So nothing extra is paid on the common path — every typing transaction — and the cost
+  falls only where the user actually undoes. Not a new idea: `origamiUndo` already does exactly
+  this (`origami.ts:288-292` stashes a fresh clone before decrementing).
+- **`redo?()` stays optional, so Redo can arrive per entry kind.** An entry without it acts as a
+  floor — `canRedo()` is false when the next entry can't redo. That lets delete-page redo (the one
+  case needing real C# work: deleting the page again) be deferred without blocking the rest.
+
+`canUndo()` must stay **synchronous and cheap** — C# polls it on a timer
+(`WebView2Browser.cs:963-996`, with a reentrancy guard that returns `true` on overlap). A
+`canUndo` that walks entries or touches layout will make the Undo button flicker.
+
+### 4.2 The stack lives in the workspace frame
+
+The page iframe is destroyed on page change; the workspace frame is not. So `theOneUndoStack`
+lives in the **workspace** bundle alongside `handleUndo`, and delete-page entries
+(`pageId: undefined`) survive naturally rather than being bolted on. Page-frame code pushes via
+the established cross-frame pattern (`getWorkspaceBundleExports().pushUndoEntry(...)` — note
+the real export name, see `origami.ts:204`).
+
+Corollary for delete-page: the entry **must not** be constructed in the page frame, which is
+being torn down at that moment. C# initiates the delete, so C# (or the workspace frame on C#'s
+behalf) pushes the entry.
+
+### 4.3 Selection anchors, not DOM bookmarks
+
+Avoiding CKEditor-style bookmark spans is realistic, but be honest about what exists: Bloom has
+the **consume** side (`EditableDivUtils.makeSelectionIn`, which already takes a `divBrCount` for
+disambiguating around `<br>`s) and a partial **capture** side
+(`getElementSelectionIndex`, `editableDivUtils.ts:30-46`, which returns only a character offset
+and resolves the editable via `$(anchorNode).closest("div")`). Nothing computes `brCount` /
+`atStart` on capture — in-tree callers pass `-1` (`readerToolsModel.ts:587-592`). **The capture
+function is new code and needs hard testing.**
+
+```ts
+export interface ISelectionAnchor {
+    editable: IEditableLocator; // structural: page-relative index, or translationGroup index + lang
+    textOffset: number;         // characters of text content before the caret
+    brCount: number;            // line-break elements to step past after that offset
+    atStart: boolean;           // tie-break at a node boundary
+}
+```
+
+Locate the editable **structurally**, not by `id`: ordinary `.bloom-editable` divs have no
+`id` (only the talking-book tool assigns them, `audioRecording.ts:1380, 3681`), and after a
+restore or reload the element object is new anyway.
+
+Why this beats bookmarks — and the case got **stronger** while this plan was being written.
+Originally: the bookmark approach's own documented bug is that inserting a marker mid-word makes
+the markup routine see `"hous"`-marker-`"e"`, so reader markup is temporarily wrong while you fix
+a letter. An offset anchor doesn't perturb the DOM, so dropping bookmarks fixes that, and it
+deletes the whole `fixUpEmptyishParagraphs` / `safelyReplaceContentWithCkEditorData` /
+`setCkeditorBookmarkContent` / `cleanUpNbsps`-bookmark-emptying family plus the `cke_bm_`
+scrubbing on the C# side.
+
+**Then BL-16558 landed on master (2026-08), and it raises the stakes.** The decodable and leveled
+reader tools no longer rewrite the DOM to show violations at all: they paint with the CSS Custom
+Highlight API — `::highlight()` pseudo-elements over **live `Range` objects**
+(`bookEdit/js/textHighlightManager.ts`, `readerHighlights.ts`, styles at `editMode.less:1074-1100`).
+Talking Book's current-sentence highlight works the same way (`editMode.less:1145`). The
+consequence, which BL-16558 had to fix for `cleanUpNbsps`, is general:
+
+> **Any code that rebuilds an editable's text nodes silently collapses every live Range pointing
+> into them, and the highlights vanish.**
+
+That makes DOM-mutating bookmarks actively hostile to the current architecture, not merely
+inelegant — inserting and removing marker spans around the caret is exactly the kind of node
+churn those Ranges cannot survive. It also imposes a new obligation on *our* work; see §4.11.
+
+Defer range (non-collapsed) anchors: every identified consumer needs only a caret. And for the
+*snapshot* case specifically there's a simpler trick — inject a caret marker into the captured
+HTML **string** (not the live DOM, so none of the bookmark downsides apply) and strip it on
+restore. Offsets then only have to serve the toolbox-markup case.
+
+### 4.4 Build on `beforeinput`, and fence off native undo
+
+For the new editor the modern primitive is `beforeinput`/`input` (with
+`InputEvent.getTargetRanges()`), not `keydown`/`keypress`. It fires uniformly for typing, paste,
+drop, IME commit, autocorrect **and the browser's own undo**, and `inputType` says which. That
+gives one place to open/close typing transactions, one place to substitute our own DOM op, and
+correct behaviour under composition (suspend DOM meddling between `compositionstart` and
+`compositionend`) — important for the languages Bloom serves, and an area where the current
+`keydown` code has had trouble (BL-3900, BL-5215 with longpress).
+
+**Native undo does not go away when CKEditor does.** Plain typing in a contenteditable feeds
+Chromium's own undo stack, and today CKEditor's undo plugin is what intercepts Ctrl+Z inside a
+box. If native undo ever fires, the DOM changes outside our stack and the two histories
+diverge. So the new editor **must** intercept `beforeinput` with `inputType`
+`historyUndo`/`historyRedo`, `preventDefault()`, and route to the shared stack. This is
+correctness, not polish, and it is the replacement for `BloomField.PreventRemovalOfSomeElements`'s
+`document.execCommand("undo")` too: block any `delete*` whose `getTargetRanges()` covers a
+`.bloom-preventRemoval` element, rather than letting the deletion happen and undoing it.
+
+### 4.5 Own the inline-formatting engine; stop using `execCommand`
+
+Bold/italic/underline/superscript/colour/remove-format become a pure DOM function over a
+`Range` (`inlineFormat.ts`) rather than `document.execCommand`. Reasons: `execCommand` is
+deprecated; it is inconsistent between engines (`BloomField.InsertLineBreak`'s comment
+documents exactly this biting Bloom during the WebView2 migration); and it silently writes to a
+browser undo stack we can't inspect — one of the five mechanisms we're eliminating. A pure
+function is also the most testable piece of this project.
+
+For colour, use Bloom's **existing** `colorPickerDialog` (already exposed cross-frame as
+`workspaceBundle.showColorPickerDialog`) instead of CKEditor's `colorbutton` panel. That is a
+UX improvement, and it deletes the palette-caching hack and the `labelForDefaultColor`
+plumbing in `attachToCkEditor`.
+
+### 4.6 Typing transactions
+
+One undo entry per keystroke is useless. Close the current transaction on a word boundary
+(space / punctuation / Enter), a caret move or focus change, an idle timeout (~1 s), or any
+non-typing command. This approximates CKEditor's `undoManager` and matches user expectation. A
+transaction holds the snapshot taken when it opened; closing it commits that entry.
+
+### 4.7 `getData()` replacement
+
+Once CKEditor is gone there is no filling char, no bookmark span and no injected comment, so an
+editable's "clean HTML" is `div.innerHTML` plus a small normalizer (`getCleanHtml`). That one
+fact deletes services 4 and 5 above and most of the artifact-scrubbing list.
+
+### 4.8 Paste and drop sanitizing is a safety guarantee — default-deny
+
+**This is the requirement most likely to be lost by accident**, because CKEditor provides it in
+one config line and its absence is invisible until a user pastes a table into a book. State it
+plainly:
+
+> The user must not be able to introduce HTML structures that Bloom's own UI could not have
+> created. Tables, `div`s, `iframe`s, images, ids, classes and arbitrary span styles pasted from
+> a web page are hard or impossible to edit or delete through Bloom's UI, and may not survive
+> Bloom's own processing.
+
+There is a second rationale already written into `config.js:107-112`, worth preserving because
+Stage 5 deletes that file:
+
+> *"…by letting people paste things that cannot be duplicated by a user doing a translation, are
+> we leading people to expect formatting in Bloom that translators will not actually be able to
+> replicate? Therefore for now we're limiting pasting to things that a translator could also
+> do."*
+
+Four things the new `pasteSanitizer.ts` must get right:
+
+1. **Allow-list, not deny-list.** Today's whole permitted vocabulary is
+   `p br em i strong sup u; b{font-weight}; a[!href]; span{font-variant,color}` — everything
+   else is dropped, attributes included. Reproduce that shape: enumerate what's allowed and
+   discard the rest, so a tag nobody thought of fails closed. Note the two annotations carry
+   real history and are in tension: BL-4775 removed `span` entirely ("so that you can't paste
+   spans"), then BL-12357 had to allow `span{font-variant,color}` back for small caps and text
+   colour. The sanitizer is where that tension lives; don't loosen either without reading both
+   tickets.
+2. **Sanitize on the boundary only, never as a DOM invariant.** CKEditor sets
+   `config.allowedContent = true` *and* a restrictive `pasteFilter`, and the split is
+   deliberate: the first attempt at BL-3899 (duplicate ids from pasted divs) filtered *all*
+   content and broke BL-3976. Bloom's own code legitimately writes markup the sanitizer would
+   reject — `audio-sentence` spans with ids, `bloom-linebreak`, canvas elements. So the filter
+   applies to incoming clipboard/drop payloads and nothing else.
+3. **Cover `drop`, not just `paste`.** Verified: CKEditor's clipboard plugin attaches its own
+   `drop` listener and routes drops through the *same* filter as pastes
+   (`ckeditor.js:622`, `attachListener(…"drop"…)` → `{dataTransfer, method:"drop"}`). Bloom's
+   only drop handling of its own is for internal canvas-element drags via a custom
+   `text/x-bloom-canvas-element` type (`CanvasElementManager.ts:2069-2088`), which does nothing
+   for externally-dropped HTML. **So this protection is currently invisible and would disappear
+   silently.** The new editor must handle `drop` (or `beforeinput` with
+   `inputType: "insertFromDrop"`) through the same sanitizer as paste.
+4. **Rich formats other than `text/html`.** Chromium normalizes Word/RTF clipboard content to
+   `text/html` before it reaches the page, so one HTML sanitizer should cover those flavours —
+   but *verify* rather than assume, and decide explicitly what to do when only `text/rtf` or an
+   unknown flavour is on offer (recommended: fall back to `text/plain`, never attempt to parse
+   an unknown format).
+
+Because its absence is silent, this needs **adversarial tests**, not just happy-path ones: paste
+a table, a nested `div`, an `iframe`, a `<script>`, an `<img>`, a styled `<span>` soup from a real
+web page, and a block copied from another Bloom book (the BL-3899 duplicate-id case) — and drop
+each of those too. Every one of these belongs in the Stage 0 inventory with an expected outcome.
+
+### 4.9 Clipboard ownership — the requirement BL-6681 actually records
+
+BL-6681's most load-bearing content today is a 2026 comment from the BL-16459 investigation,
+which names the question a replacement must answer:
+
+> Can Bloom supply the clipboard payload (rich *and* plain) and be told whether the write
+> succeeded?
+
+The problem it comes from: when another program briefly holds the Windows clipboard, Ctrl+X
+deletes the selected text **and** the clipboard write silently fails, so the text is gone from
+both places. The obvious fix — copy first, delete only if the copy succeeded — was built
+(PR #8140) and withdrawn, because Bloom's own cut can put only **plain text** on the clipboard,
+so every cut of a phrase containing bold, a link or an inline picture lost the formatting. So
+Bloom still leaves Ctrl+X to the browser and cannot protect the text.
+
+Hard-won measurements recorded there, which constrain any design:
+- **Chromium never reports a clipboard failure to Javascript at all** — `writeText` resolves,
+  `execCommand` returns `true`, `readText` returns `""`. So a JS-only cut can never be safe.
+- A .NET clipboard *read* also doesn't fail while another program holds the clipboard (OLE
+  serves a cached copy); only **writes** fail honestly. So the success signal has to come from
+  a C# write.
+- Windows' "HTML Format" needs a byte-offset header that .NET does **not** write for you. That
+  header is the substance of the multi-format work, not the plumbing.
+- The withdrawn branch is deliberately preserved: `origin/BL-16459-clipboard-failure-reporting`,
+  with findings in PR #8140's comments. Read it before re-deriving any of this.
+
+What this plan therefore commits to: the new editor **owns `cut` and `copy`** on
+`.bloom-editable` (it must anyway, to replace service 13 above), and structures them so the
+payload is produced as *both* `text/html` and `text/plain` and handed to whoever writes it —
+rather than calling `navigator.clipboard.writeText` and hoping. That makes a safe cut
+*possible*; whether we also build the C# multi-format write is a scope question — now decided as seam-only (§10 q3).
+Getting this seam right costs nothing now and is expensive to retrofit, so it goes in the
+`clipboard.ts` design from the start even if BL-16459 stays a separate ticket.
+
+### 4.10 Page-scoped handler lifetime — the prerequisite for snapshot restore
+
+Snapshot restore replaces DOM elements, so anything attached to them dies with them. This is the
+substance of risk 2, and it needs a design rather than a per-case scramble.
+
+#### What's actually attached
+
+Counted across the page frame: **~40 `addEventListener` sites and ~50 jQuery `.on()` sites** in
+about 25 files, plus jQuery-UI `draggable`/`resizable`, `qtip`, `nicescroll`, `longPress`,
+Comical, and **17 observer sites** (`MutationObserver`, `ResizeObserver`). So no single function
+knows them all, and no single function ever should.
+
+Three of those groups behave quite differently, which is the key to the design:
+
+| Kind | Re-attachment behaviour |
+| --- | --- |
+| `addEventListener` with a **stable module-level function reference** | **Already idempotent.** The DOM spec makes a second `add` with the same (type, listener, capture) a no-op. Bloom exploits this deliberately — `CanvasElementManager.addEventsToFocusableElements` carries the comment "*Don't use an arrow function as an event handler here. These can never be identified as duplicate event listeners, so we'll end up with tons of duplicates*". |
+| Property assignment (`el.onclick = …`, `container.ondrop = …`) | Idempotent by construction — assignment replaces. |
+| jQuery `.on()`, and any arrow function / bound method / fresh closure | **Duplicates on every call.** Needs explicit `.off()` or namespaced events. |
+| Observers, jQuery-UI plugins, qtip, Comical | Neither: they need explicit `disconnect()` / `destroy()`, and a *new* observer per call is a leak. |
+
+#### An existing bug this uncovered — worth its own ticket
+
+`SetupElements` takes a *container* and is already called re-entrantly on subtrees
+(`CanvasElementManager.ts:1007` in `refreshCanvasElementEditing`, `imageDescription.tsx:336`).
+But it calls `AddEditKeyHandlers(container)` (`bloomEditing.ts:727`), and two of that function's
+handlers are attached to **`document`**, not to the container: the Ctrl+Space clear-formatting
+handler (`:291`) and the Ctrl+R/L/E justify block (`:301`). It also attaches per-editable
+`keydown` handlers via jQuery `.on()` (F6/F7/F8, Ctrl+Alt+0/1/2, show-invisibles), which
+duplicate for any editable inside a re-set-up container.
+
+So **handlers already accumulate on every canvas-element refresh**, before this project adds any
+restore path. Most of the duplicated commands are near-idempotent (`justifyright` twice looks
+like once), which is presumably why nobody has noticed; F6's
+`insertHTML("<sup>" + selection + "</sup>")` is the one that looks likely to misbehave visibly.
+Found by code reading, **not reproduced** — so Stage 0 should attempt a repro and file it
+separately. It is a real bug independent of CKEditor, and it is the best possible evidence that
+this area needs the design below rather than more discipline.
+
+#### The design: distributed registration, centralized invocation, teardown by signal
+
+The tension in "one function that knows all the handlers" versus "each client contributes its
+own" dissolves if you centralize the **invocation** and distribute the **knowledge**:
+
+```ts
+// new file, e.g. bookEdit/pageSetup/pageScope.ts
+export interface PageScope {
+    readonly page: HTMLElement;
+    readonly signal: AbortSignal;      // aborted when this page instance goes away
+    addCleanup(fn: () => void): void;  // observers, qtip, jQuery-UI, Comical
+}
+type PageContributor = (scope: PageScope) => void;
+export function registerPageContributor(name: string, fn: PageContributor): void;
+export function setUpPage(page: HTMLElement): PageScope;  // runs every contributor
+export function tearDownPage(scope: PageScope): void;     // abort, then run cleanups LIFO
+```
+
+- **Distributed knowledge.** Each module calls `registerPageContributor("canvasElements", …)` at
+  import time, in its own file. `setUpPage` knows nobody. Adding a feature means one registration
+  in the file that owns it — no central list to edit, and therefore no central list to forget.
+- **Teardown by signal, not by idempotency.** `addEventListener(type, fn, { signal })` means one
+  `controller.abort()` removes *every* listener in the scope at once. Restore becomes
+  `tearDownPage(old)` → mutate DOM → `setUpPage(new)`.
+
+That second point is why this beats the "idempotent re-run" framing in the original question.
+Idempotency requires every handler to *be* dedupable, which forbids arrow functions and closures
+and relies forever on the discipline the comment in `CanvasElementManager` is pleading for. A
+signal-scoped teardown makes closures and arrow functions **safe**, so the easy way to write a
+handler becomes the correct way. That is the only durable answer to "error-prone if someone
+forgets": don't ask people to remember — make the default right.
+
+Observers hang off the same scope via `addCleanup(() => obs.disconnect())`, so they get the same
+one-call teardown without `pageScope.ts` knowing what they observe.
+
+#### On the delegation alternative
+
+Delegation (listen on the root, inspect `event.target`) has one real virtue the objections
+don't cancel: a handler on a node that is never replaced is *inherently* immune to DOM
+replacement. But it cannot be the whole answer, for a reason beyond the stated objections:
+**many relevant events don't bubble** — `focus`/`blur` (Bloom already uses `focusin`/`focusout`
+for this reason), `load`, `error`, `mouseenter`/`mouseleave` — and observers can't be delegated
+at all. So the rule is:
+
+- **Delegate on the page root** (not `document`) for handlers that are about a *class* of
+  element, need no capture phase and no per-element state. Naturally restore-proof.
+- **Direct listeners with `{ signal }`** for everything else.
+
+Delegating on `document` rather than the page root is what produced the accumulation bug above,
+so the distinction is not pedantic.
+
+#### Enforcement, since convention alone won't hold
+
+1. **An ESLint rule** for page-frame files: `addEventListener` must pass a `signal`, and jQuery
+   `.on()` is banned. A custom rule is a few dozen lines and converts a discipline into a build
+   failure. This is the main answer to "someone forgets".
+2. **A leak test in the live-Bloom harness.** JS can't enumerate listeners, but CDP can
+   (`DOMDebugger.getEventListeners`). Assert that after N setup/teardown cycles the page's
+   listener count is unchanged. That is a direct regression test for this whole bug class — and
+   it would fail today.
+3. **A dev-mode warning** when `setUpPage` runs while a previous scope has not been torn down.
+
+#### The cross-frame half, which a page-frame registry cannot reach
+
+Several observers live in the **toolbox** frame watching page-frame elements: `motionTool`,
+`GameTool`, `audioRecording` (`highlightIntegrityObserver`, `visibilityObserver`),
+`PlaceholderProvider`, `StyleEditor`, `BloomSourceBubbles`. No page-frame registry can own those.
+They already have `disconnect()` logic driven by page-change hooks, so the answer is to reuse the
+hook that already exists for exactly this purpose: `applyToolboxStateToPage()`, which
+`switchContentPage` calls after a page load (`workspaceRoot.ts:164-170`). **Snapshot restore must
+call it too.** Treat "the page DOM was replaced under you" as indistinguishable from "a new page
+loaded", because for every one of these clients it is.
+
+#### Consequence for sequencing — and a stronger case for the reload fallback
+
+Migrating ~90 attachment sites is not a prerequisite we want to put in front of undo. So:
+
+- `pageScope.ts` is a **new file that can land early** and be adopted module by module, each
+  adoption a small independent commit. Ideal for the rebase strategy.
+- **Tier 1 restore needs no contributors at all** (§4.11) — handlers live on the `.bloom-editable`
+  div, which survives an `innerHTML` replacement. Typing undo is unaffected by any of this.
+- **Tier 2 narrow-subtree restore** needs only the contributors touching that subtree — a handful.
+- **Tier 3 turns out to be empty** (§4.11): origami keeps its own working in-place clone restore,
+  delete-page is a C# mechanism, style undo is deferred. So no generic full-page restore gets
+  built, and **`pageScope` is not a prerequisite for undo at all.**
+
+That is the happy outcome: `pageScope` is worth doing for its own reasons — the accumulation bug,
+and a clean lifetime for the new editor's handlers — but it no longer gates anything, so it can be
+adopted at whatever pace suits, module by module.
+
+### 4.11 Restore cost tiers — typing undo must never reload the page
+
+Reloading a page is currently slow enough that using it for *every* undo would be a visible
+regression on the most frequent undo of all: typing. So restore cost must be tiered by **how much
+of the page the operation actually touched**, with the expensive path reserved for the rare
+structural case. The `kind` field on `IUndoEntry` (§4.1) exists for this.
+
+| Tier | Scope | How restore works | Cost |
+| --- | --- | --- | --- |
+| **1 — editable** | Typing, inline formatting, paste or cut within one `.bloom-editable` | Restore `editable.innerHTML` + `ISelectionAnchor`. Nothing else. | Instant, no C# round-trip |
+| **2 — subtree** | Delete / duplicate / modify a canvas element, image swap | Restore the `.bloom-canvas` subtree's HTML, then `refreshCanvasElementEditing` — the existing path used when adding a canvas element | Fast, no reload |
+| **3 — page** | Anything touching page structure | Install the snapshot into the live DOM, then re-run normal page init (§4.10). **In place — no navigation.** | Moderate; and see below: this tier may be empty |
+
+> **⚠ New obligation from BL-16558 (§4.3): every tier must repaint live-Range highlights.**
+> Because the reader tools and Talking Book now draw their highlights as `::highlight()`
+> pseudo-elements over live `Range`s, restoring `editable.innerHTML` — Tier 1's whole mechanism —
+> rebuilds the text nodes and collapses those Ranges, so the highlights disappear with no error.
+> So a Tier 1/2 restore must, after writing the HTML, ask the highlight owners to repaint:
+> `textHighlightManager` for the reader violations and `audioTextHighlightManager` for the current
+> audio sentence. Add this to `reinitializePageAfterRestore()`'s contract, and note the same trap
+> applies to the toolbox-markup anchor path — which is precisely why BL-16558 had to move
+> `updateMarkup()` to *after* `cleanUpNbsps`. **The symptom is silent**: undo appears to work and the
+> highlights are simply gone until something else repaints them.
+
+**Tier 1 is verified safe and already has a working precedent in-tree.** No event handlers are
+attached to nodes *inside* editables — they attach to the `.bloom-editable` div itself, which
+survives an `innerHTML` replacement (checked: no `addEventListener` / `.on()` on `audio-sentence`,
+`bloom-highlightSegment` or `bloom-linebreak`). And `readerToolsModel.undo()`
+(`readerToolsModel.ts:574-591`) *already* restores `activeElement.innerHTML` and reselects at a
+caret offset. So the cheapest tier is not new machinery — it is the existing reader-tools undo,
+generalized and given a proper caret anchor.
+
+That is the substantive reason not to reach for page snapshots by default: **typing and formatting
+undo, the overwhelming majority of undos, never leave the page frame.**
+
+#### Tier 3 restores in place. Navigation is rejected, for the reason you'd expect
+
+An earlier draft of this plan offered "reload the page without saving" as Tier 3's first
+implementation. That was wrong, and the reason is worth recording so nobody proposes it again.
+
+**If we navigate, the document the iframe loads is generated by C# from the book DOM — so the book
+DOM must already hold the undone state.** The only route into the book DOM is the save's merge
+phase: `UpdateBookDomFromBrowserPageContent` → `Book.UpdateDomFromEditedPage`
+(`EditingModel.cs:1760-1766`), which strips the editing UI, propagates the data-div through
+`BookData`, recomputes feature requirements, and decides full-versus-partial save. We could skip
+asking the browser for content (we already hold the HTML) and skip the disk write
+(`SaveThen(skipSaveToDisk: true)` already exists, `EditingModel.cs:220, 451`) — but **not the
+merge.** So "reload without saving" is really "a save minus two of its three phases", and the merge
+it keeps is plausibly the expensive part, not the disk write it drops. It buys much less than it
+appeared to, while adding a whole-book data-div propagation to every undo.
+
+So **Tier 3 does what you described: make the live document what we want from the snapshot, then run
+the normal init as if we had navigated.** No C#, no navigation, no save.
+
+One incidental finding worth keeping, since it inverts a natural assumption: the save/reload
+coupling runs the *opposite* way from the intuition. Saving does not exist to enable the reload —
+**saving forces the reload**, because the save path leaves the page stripped and invalid for
+editing (`State.SavedAndStripped`, whose comment reads "*The page has been saved; in the process,
+we stripped various UI elements from it, so it's not in a valid state for editing. We hope to fix
+this one day (BL-13502)*", `EditingStateMachine.cs:16-21`). Nothing requires a disk write before
+navigating. That is why BL-13502 keeps surfacing below as the same knot.
+
+#### Tier 3 may be empty — don't build it until something needs it
+
+Enumerate what would actually land there:
+
+- **Origami layout changes** — origami already restores in place, with no reinit at all, and it
+  works today: `origamiRoot.replaceWith(clone)` where the clone is a jQuery `clone(true)`. Two
+  properties make that sound, and both should be recorded because a well-meaning refactor could
+  break them: layout mode strips `contentEditable` (`origami.ts:132`), so there is no editing UI to
+  resurrect; and origami attaches its own UI handlers exclusively through jQuery (`.click()` at
+  `origami.ts:404-457`), which is exactly what `clone(true)` preserves. **Keep this mechanism**,
+  adapted as a custom `IUndoEntry` so it joins the shared stack's ordering. Note that migrating
+  origami to `addEventListener` would silently break its undo, since `clone(true)` does not copy
+  raw listeners.
+- **Delete page** — C#-side, and navigation happens regardless because the page list changes. A
+  different mechanism entirely (Stage 2a), not a page snapshot.
+- **Style changes** — deferred (§6 Stage 2c).
+
+That leaves nothing requiring a *generic* full-page restore. So: **do not build one.** If something
+later needs it, the mechanism is the in-place one above, and it will need `pageScope` (§4.10)
+adoption for the contributors it touches.
+
+Consequence: `pageScope` stops being a prerequisite for undo. It remains worth doing on its own
+merits — the handler-accumulation bug, and giving the new editor's own handlers a clean lifetime —
+but the undo work no longer waits on a ~90-site migration, and neither does it need the
+reload path.
+
+#### The sharp edge that survives: an in-flight save
+
+Independent of tiering. An undo arriving while the state machine is in `SavePending` must not let
+the in-flight save merge content we are discarding — the hazard `DiscardInFlightSave()`
+(`EditingStateMachine.cs:367`) was built for on the external-process path. Either discard or defer;
+decide deliberately and test it. This is the concrete form of risk 5, and Tier 1 undos are frequent
+enough that the interleaving will be exercised constantly.
+
+#### Measure before optimizing
+
+The hypothesis that most of the reload cost is disk persistence plus HTML↔XML conversion is
+plausible but unmeasured, and the alternative — page-DOM regeneration plus browser parse and
+`bootstrap()` — would not be helped by skipping the save. Bloom has a performance-log feature
+(`performance/PerformanceLogPage.tsx`); use it to attribute the time across: browser-side
+serialize → HTML→XML → disk write → page-DOM regeneration → browser parse + `bootstrap`. Do this
+in Stage 0, since it also sets the baseline for judging whether the project made page loads
+faster.
+
+Two things worth knowing before that measurement:
+
+- **This project should make page loads faster regardless.** A reload currently waits on
+  CKEditor's async init, and on the workarounds that exist to wait for it (§2). Removing them
+  removes work from every page load, not just from undo.
+- **BL-13502 would decouple save from reload generally.** If the save path stopped leaving the
+  page invalid, `SaveThen` would no longer have to navigate at all — which would make Tier 3
+  cheap and would benefit far more than undo. Out of scope here, but it is the same knot, and
+  worth noting on that ticket that undo is another reason to want it.
+
+### 4.12 The feature flag: an experimental-feature checkbox, latched by a body class
+
+Testers need to turn the new editor on and off, so a `localStorage` switch (an earlier draft's
+choice) is wrong — it needs devtools. Bloom already has exactly the right mechanism, and using it
+also produces a *stronger* test than a JS-side flag would.
+
+**The switch: `ExperimentalFeatures`.** `ExperimentalFeatures.cs` keeps a token list in
+`Settings.Default.EnabledExperimentalFeatures` (per user, persisted across restarts), surfaced as
+checkboxes in **Collection Settings → Advanced** (`AdvancedSettingsPanel.tsx` +
+`CollectionSettingsDialog.cs`) and readable from JS via `app/enabledExperimentalFeatures`
+(`AppApi.cs:47-52`). Add `kNewTextEditor = "new-text-editor"` alongside `kAppBuilder` and
+`kAiImageEditing`. Testers get a checkbox in a dialog they already know, in the place Bloom already
+puts this kind of thing — which is better than a Help-menu item, since it needs no new menu, no new
+localization surface, and gives testers one place to look.
+
+**Plus an environment-variable override for developers and automated tests:**
+`BLOOM_NEW_TEXT_EDITOR=1`, read in the same C# place, winning over the setting. There is ample
+precedent (`BLOOM_AI_EDITOR_URL`, `BloomWV2Path`, `BloomSandbox`), and the canvas e2e specs launch
+Bloom themselves, so they need a switch that doesn't involve clicking through a dialog.
+
+**How the page frame reads it — synchronously, latched per page load.** `useNewTextEditor()` is
+called once per editable from `attachToCkEditor`, so it must be synchronous; the experimental-
+features API is async, and reintroducing an async-init ordering problem in *this* project would be
+absurd. Instead, let C# decide at page-generation time, in `Book.AddJavaScriptForEditing` — the
+same method that currently adds the CKEditor script tag (`Book.cs:621-629`):
+
+- flag on → **don't add the `lib/ckeditor/ckeditor.js` script tag at all**, and
+  `dom.RawDom.AddClassToBody("bloom-newTextEditor")` (the `AddClassToBody` helper already exists;
+  `Book.cs:1864` uses it for `template`).
+- `useNewTextEditor()` is then just
+  `document.body.classList.contains("bloom-newTextEditor")` — synchronous, no fetch, no ordering.
+
+Two properties fall out of doing it this way, both valuable:
+
+1. **The flag is automatically stable for the lifetime of a page load.** This matters more than it
+   sounds: if the flag could change mid-page you could get some editables on the CKEditor path and
+   some on the new one, which would be an unholy mess to debug. Latching it in the generated HTML
+   makes that impossible by construction, and a setting change simply takes effect on the next page
+   load.
+2. **With the flag on, CKEditor is not merely unused — it is not loaded.** That is a far stronger
+   test of the new path than leaving it loaded and bypassed, and it means the flag-on build cannot
+   accidentally lean on CKEditor for something we forgot to replace.
+
+**And the integration is already largely de-risked**, because "CKEditor is absent" is an existing
+supported mode: `BookProcessor` strips the script tag for off-screen page processing, so guards are
+already in place at every one of the main integration points —
+`bloomEditing.bootstrap` (`:1214`), `StyleEditor.AttachToBox` (`:1210-1211`),
+`toolbox.doWhenCkEditorReadyCore` (`:995`), and `editablePage.ckeditorCanUndo` (`:315`). With the
+flag on, those guards already do the right thing; the Stage 3 dispatches become "*also* start the
+new editor" rather than "skip CKEditor".
+
+**The XLF entry is cheap, with one scheduling constraint.** The checkbox label is a localizable
+string, and every existing experimental checkbox is localized via `useL10n` (e.g.
+`CollectionSettingsDialog.AdvancedTab.Experimental.AppBuilder`), so add one following
+`.github/skills/xlf-strings/SKILL.md` — including asking which priority file it belongs in. It gets
+`translate="no"`, which is that skill's default for new entries anyway, so **no translator effort is
+spent on it and removing it later costs nothing.**
+
+The constraint that follows: **the flag must be gone before the Bloom release carrying it goes
+beta**, because that is when strings get picked up for translation. After that point the entry is no
+longer freely removable (the skill's rule: never change the ID or source of a translated entry).
+This is the one hard calendar deadline in the whole project — note it in Stage 5.
+
+### 4.13 `runUndoable` must nest from day one
+
+`deleteCanvasElement`'s background-image branch already records its own image undo
+(`CanvasElementManager.ts:2755-2770`: `prepareUndoForImageOperation` … 
+`commitPendingImageOperationUndo`). Naïvely wrapping `deleteCurrentCanvasElement` in
+`runUndoable` would then produce **two** entries for one gesture, so the first Ctrl+Z
+half-undoes. Nested wrapping will keep happening as call sites accrete, so specify the
+semantics in `undoTypes.ts` up front: a depth counter, outermost entry wins, inner pushes are
+no-ops.
+
+## 5. Rebase strategy
+
+1. **Almost all new code in new directories** — `src/BloomBrowserUI/bookEdit/undo/` and
+   `src/BloomBrowserUI/bookEdit/textEditor/`. New files never conflict.
+2. **Don't keep a long-lived branch.** The real defence against repeated rebasing is not to
+   rebase: land a dozen small PRs on `master`, each green, each inert behind a flag.
+3. **Integration points into existing files are one-line dispatches** wherever possible:
+
+   ```ts
+   export function attachToCkEditor(element) {
+       if (useNewTextEditor()) return attachBloomTextEditor(element);   // ← the whole edit
+       ...existing body unchanged...
+   }
+   ```
+   Note the dispatch goes *inside* `attachToCkEditor`, so its two call sites (`bloomEditing.ts:1226`,
+   `CanvasElementManager.ts:951`) need no edit at all.
+4. **One exception, and it needs a prep commit.** The toolbox keystroke pipeline
+   (`toolbox.ts:1509-1607`) interleaves `createBookmarks`, `removeCommentsFromEditableHtml`, the
+   async-updateMarkup double-bookmark dance (BL-10133), `cleanUpNbsps`, and `selectBookmarks`.
+   Swapping bookmarks for anchors there rewrites ~100 lines of the most delicate keystroke code
+   in the app, inside a churn-prone file. So do a **mechanical, behaviour-preserving prep commit
+   early** (Stage 0): extract the save-selection / restore-selection bracket into two small
+   functions with a clean seam. Then the eventual change swaps one function body instead of
+   performing open-heart surgery mid-project.
+5. **The flag is read in exactly one function**, `useNewTextEditor()`, in one new file — a
+   synchronous body-class check, set by C# at page-generation time from an
+   `ExperimentalFeatures` token (with an env-var override). See **§4.12** for why, and for what
+   falls out of it.
+6. **All deletion is last** (Stage 5), in a few mechanical commits. Never rebase those —
+   regenerate them.
+7. **Avoid the churn-prone files** until late: `bloomEditing.ts` (2092 lines),
+   `CanvasElementManager.ts` (3224), `toolbox.ts`, `audioRecording.ts` (5121),
+   `StyleEditor.ts` (2627).
+8. Keep [PROGRESS.md](PROGRESS.md) current so an interrupted session resumes cleanly.
+
+## 6. Stages
+
+Stages 1–2 deliver the Undo improvements **without touching CKEditor at all**, and are ordered
+by user value per unit of risk. If the project stalls, Bloom is still better off.
+
+### Stage 0 — Inventory, safety net, and the one prep commit
+
+*New files, plus one behaviour-preserving refactor.*
+
+- `docs/retire-ckeditor/BEHAVIOR-INVENTORY.md`: every behaviour that must survive, traced to
+  the code and to the ticket its comment cites — BL-2484, BL-2557, BL-2746, BL-3009, BL-3125,
+  BL-3899, BL-3900, BL-3976, BL-4775, BL-5215, BL-6721, BL-6845, BL-10133, BL-11745, BL-12205,
+  BL-12357, BL-12381, BL-12391, BL-12448, BL-13779, BL-14004, BL-14051, BL-14947, BL-16065,
+  BL-16330, BL-16490. Each row becomes a vitest case or a manual test idea. Include the
+  easily-missed ones: the BL-13779 `data-user-deleted` hook, the BL-11745 qtip z-order juggling,
+  `EnsureCaretNotInsideLineBreakSpan` on selection change, the SetupLink hyperlink command, the
+  `cursor: not-allowed` no-editor case, and `PreventRemovalOfSomeElements`.
+- **The paste/drop sanitizing rows are the most important ones in the inventory** (§4.8), because
+  losing that protection is invisible rather than obviously broken. Write them as adversarial
+  cases with expected outcomes — table, nested `div`, `iframe`, `<script>`, `<img>`, real-web-page
+  `<span>` soup, and a block copied from another Bloom book (BL-3899 duplicate ids) — each one
+  **pasted and dropped**. Capture today's actual behaviour for each before changing anything, so
+  the new sanitizer is measured against reality rather than against the config string.
+- Characterization tests pinning the pure-ish functions before they move.
+- **The toolbox prep commit** from §5.4.
+- **Attempt to reproduce the handler-accumulation bug** described in §4.10 (repeated
+  `refreshCanvasElementEditing` → duplicate `document` keydown handlers and duplicate
+  per-editable jQuery handlers; F6 is the likeliest visible symptom). If it reproduces, file it
+  as its own card and fix it separately — it predates this project. Either way, add the CDP
+  listener-count leak test from §4.10, which should fail before the fix and pass after.
+- **Measure where page-reload time actually goes** (§4.11), using the existing performance-log
+  feature: browser-side serialize → HTML→XML → disk write → page-DOM regeneration → browser parse
+  + `bootstrap`. This decides how much Tier 3 really costs, and doubles as the baseline for
+  showing that removing CKEditor made page loads faster.
+
+Exit criteria: inventory reviewed; `pnpm test` green; prep commit demonstrably behaviour-neutral.
+
+### Stage 1 — One entry point, no conversions
+
+*New:* `bookEdit/undo/UndoStack.ts`, `undoTypes.ts`, `runUndoable.ts`, plus specs.
+
+- `UndoStack` in the workspace bundle: push / undo / **redo** / canUndo / **canRedo** /
+  clearForPage / clearOnPageFrameReload. Index-based with truncate-on-push (§4.1), count-bounded,
+  `canUndo` and `canRedo` both O(1).
+- `workspaceRoot.canUndo`/`handleUndo` become thin delegations (two small edits, one file). Redo
+  needs no C# counterpart — it is reached only by Ctrl+Y (§10 q1), so it stays entirely in JS.
+- **Wrap all four existing mechanisms as legacy providers in their current priority order.**
+  No conversions, no behaviour change. This preserves the deliberate reader-tools-before-CKEditor
+  precedence (§3) for free. Redo has no legacy providers to wrap — origami's is the only Redo that
+  exists, and it keeps working via its own handler until Stage 4 converts it. (Note
+  `readerToolsModel.redo()` at `:609` appears to be **unreachable** — nothing exports or calls it;
+  worth a moment's check, but it is deleted in Stage 5 regardless.)
+- `runUndoable(label, fn)` with the nesting semantics of §4.13.
+
+Rationale for doing *no* conversions here: the four existing mechanisms are contextually
+exclusive in practice (origami only in layout mode, reader undo only with an active markup tool,
+image undo only on an image container), so their relative *ordering* only starts to matter once
+text edits enter the shared stack — which is Stage 3. Converting them now would mean maturing
+the riskiest new machinery (in-place snapshot restore) in the worst possible environment: a page
+with live CKEditor instances (see Stage 3's note on `reinitializePageAfterRestore`).
+
+Exit criteria: one entry point; `pnpm test` green; no user-visible change.
+
+### Stage 2 — The undos the user actually wants
+
+**2a — Undo delete page.** The highest value-per-risk item in the plan; independent of
+CKEditor, of the page frame, and of snapshot restore. Can ship even before Stage 1 settles.
+- *New C# file* `src/BloomExe/Edit/DeletedPageUndoManager.cs`: a session-only stack of
+  `{ pageXml, index, pageId }`, plus an `edit/undoDeletePage` endpoint.
+- Capture **inside the `SaveThen` callback, after the save completes** — `EditingModel.DeletePage`
+  wraps the delete in `SaveThen(..., forceFullSave: true)` (`EditingModel.cs:590-624`), so
+  capturing earlier would snapshot a page missing the user's last edits.
+- Restore must mirror what `Book.DeletePage` (`Book.cs:4110-4132`) tears down: re-insert at the
+  saved index (clamped to the current page count), then `UpdatePageNumberAndSideClassOfPages`,
+  `_pageListChangedEvent.Raise`, `InvokeContentsChanged`, and navigate to the restored page.
+- The matching front-end entry (`pageId: undefined`, `kind: "custom"`) is pushed **by C# into
+  the workspace bundle**, not by the page frame — which is being torn down at that moment.
+- Depth: keep every deletion in the session (capped ~10). The shared stack already provides
+  ordering, so depth costs nothing extra.
+
+**2b — Undo delete canvas element.** Do *not* use a whole-page snapshot. Preferred: an
+inverse-op / narrow-subtree entry that re-inserts the element's `outerHTML` into its
+`.bloom-canvas` and calls the **existing, battle-tested** `refreshCanvasElementEditing` — the
+same path used when adding or duplicating a canvas element
+(`CanvasElementManager.ts:974-1010`; `GamePromptDialog.tsx:428-437` depends on it). The inverse
+of `deleteCanvasElement` (`CanvasElementManager.ts:2747-2799`) tells us what's needed:
+`Comical.update`, `removeDetachedTargets`, `normalizeCoverImageDesignation`.
+
+Two things to verify before committing to the inverse-op, because they are the reason this
+isn't trivial: (i) `Comical.deleteBubbleFromFamily` removes the element from a bubble family —
+confirm the family can be re-linked from the restored `data-bubble` spec alone; (ii) a
+drag-activity **target** removed by `removeDetachedTargets` must come back too. If either
+proves messy, fall back to a **`.bloom-canvas`-subtree snapshot** restored through
+`refreshCanvasElementEditing` — still far narrower than a page snapshot.
+
+Also honour §4.13: the background-image branch already records an image undo, so the wrapper
+must not double-record.
+
+**2c** *(deferred, documented not built)*: undo for style changes — a snapshot of
+`userModifiedStyles` would cover it, and the entry contract already allows it.
+
+Exit criteria: deleting a page and deleting a canvas element are both undoable; page
+renumbering and navigation are correct after undo; exactly one entry per gesture.
+
+### Stage 3 — The new text editor, behind a flag, off by default
+
+*New directory* `bookEdit/textEditor/`, built roughly in this order:
+
+| File | What |
+| --- | --- |
+| `inlineFormat.ts` | Pure `Range`→DOM formatting engine: bold, italic, underline, superscript, colour, remove-format. **Do this first and test it hard.** Must preserve structural spans (`audio-sentence`, `bloom-highlightSegment`, `bloom-linebreak`) exactly as today's `addRemoveFormatFilter` does. |
+| `selectionApi.ts` | `getSelectionAnchor` / `restoreSelectionAnchor` (§4.3 — the capture side is new code), `getCleanHtml(div)`. |
+| `pasteSanitizer.ts` | **Default-deny allow-list** replacing `config.pasteFilter` (§4.8) — the project's main safety guarantee, applied to **both paste and drop**. Pure function, so it can be tested adversarially. Build it early (right after `inlineFormat.ts`) rather than late: it is the one piece whose absence is silent. |
+| `clipboard.ts` | Owns `cut` and `copy` on `.bloom-editable`, replacing CKEditor's interception (service 13). Produces the payload as **both** `text/html` and `text/plain` and keeps the write behind one seam, so a safe cut (§4.9) becomes possible. Read `origin/BL-16459-clipboard-failure-reporting` and PR #8140 first. Also subsumes `bloomEditing.cutSelectionImpl`, which currently uses `undoManager.lock/save` to make the cut one undo step. |
+| `pasteHandler.ts` | Owns the `paste` event **and** the C#-initiated `pasteClipboard` entry point. Must cover *both* existing paths: normal insert-at-selection, and `pasteImpl`'s replace-whole-content path for a canvas element that is selected but not being text-edited (`bloomEditing.ts:1792-1842`: `setData("<p><p>")` + `insertText` under an undo lock, then `updateAutoHeight()` + `scheduleMarkupUpdateAfterPaste()`). Calls the BloomField transforms; pushes **one** undo entry. |
+| `typingTransactions.ts` | `beforeinput`-driven coalescing (§4.6), composition-aware, plus the `historyUndo`/`historyRedo` fence (§4.4). |
+| `keyCommands.ts` | Shift+Enter → `span.bloom-linebreak`; F6/F7/F8; Ctrl+Alt+0/1/2; justify; Ctrl+Space (remove-format); Ctrl+B/I/U. Replaces every `execCommand` call **in the page frame** (`readerSetup.ui.ts:454` lives in the reader-setup dialog and is out of scope). |
+| `autolink.ts` | Word-boundary URL detection (BL-6845). |
+| `FormatToolbar.tsx` | React floating toolbar replacing `.cke_float`, positioned from the selection rect, localized directly (so `localizeCkeditorTooltips` dies), hidden for `bloom-userCannotModifyStyles` (BL-14947). Hosts the SetupLink hyperlink button. |
+| `BloomTextEditor.ts` | Per-editable attach/detach. **Synchronous** — no `instanceReady`, no async DOM rewrite. Also owns the BL-13779 content-changed hook, the BL-11745 qtip z-order handling, and `EnsureCaretNotInsideLineBreakSpan` on `selectionchange`. |
+| `useNewTextEditor.ts` | The one flag read: `document.body.classList.contains("bloom-newTextEditor")` (§4.12). Synchronous by design. |
+
+Plus four small additive edits outside the new directory, all covered by §4.12: a
+`kNewTextEditor` token in `ExperimentalFeatures.cs`; a checkbox in `AdvancedSettingsPanel.tsx` +
+`CollectionSettingsDialog.cs`; and in `Book.AddJavaScriptForEditing` (`Book.cs:621-629`), skip the
+CKEditor script tag and add the body class when the flag is on. That last one is the whole
+mechanism, and it means the flag-on build never loads CKEditor at all.
+
+Also in Stage 3, now that the flag-on path has no CKEditor instances to resurrect:
+`PageSnapshot.ts` + a single `reinitializePageAfterRestore()`, used by every snapshot entry.
+
+> **Why snapshot restore waits for Stage 3.** Restoring `.marginBox` innerHTML while CKEditor is
+> live orphans every `div.bloomCkEditor` expando (`BloomField.ts:419`), which costs more than a
+> missing toolbar: `doCkEditorCleanup` iterates `div.bloomCkEditor` (`editableDivUtils.ts:350`)
+> and `getBodyContentForSavePage` calls it (`bloomEditing.ts:1483`), so the **save path would
+> silently skip cleanup** for restored divs. Restoring under live CKEditor would mean re-running
+> `attachToCkEditor` and waiting out the very `instanceReady` dance this project exists to kill.
+
+Integration dispatches (one line each, added as late as possible): `attachToCkEditor`,
+`doWhenCkEditorReady`, `StyleEditor.AttachToBox`'s gate,
+`EditableDivUtils.doCkEditorCleanup` / `restoreSelectionFromCkEditorBookmarks`,
+`audioRecording.cleanUpCkEditorHtml`, `ckeditorCanUndo`/`ckeditorUndo`, and the
+`toolbox.ts` selection bracket extracted in Stage 0.
+
+**One transform that cannot simply be moved.** `BloomField.restoreHtmlMarkupIfNecessary`
+(`BloomField.ts:425-456`, BL-12357 small caps) works by detecting CKEditor-internal copies via
+`dataTransfer.getData("cke/id")` and compensating for CKEditor's *own* span-stripping of
+`dataValue`. With CKEditor gone, nothing stamps `cke/id` and nothing strips the spans, so the
+transform is meaningless as written — and the problem it solves may simply not exist when
+`pasteHandler.ts` reads raw `clipboardData`. **Verify against the BL-12357 repro; don't port.**
+Everything else in the paste pipeline (verse markers, audio-id copying, `<p>` unwrapping) moves
+unchanged.
+
+With the flag on, text edits push onto the **same** stack as everything else — the payoff of the
+whole project. At that point the reader-tools and CKEditor legacy providers become redundant
+(shared-stack snapshots capture markup too) and are deleted in Stage 4/5.
+
+Exit criteria: with the flag on, the behaviour inventory passes; `pnpm test`, `pnpm lint`,
+`pnpm typecheck`, `build/agent-vite.sh` and the C# suite green with the flag both off and on.
+
+### Stage 4 — Flip the default and soak
+
+- Flip `useNewTextEditor()` to true; the old path stays reachable by flag through the dev period
+  only (we control both ends and don't owe legacy support).
+- Delete the reader-tools and CKEditor legacy providers. Retire origami's private `keydown.origami`
+  handler, moving **both** Ctrl+Z and Ctrl+Y onto the shared global handler — origami's Redo must
+  keep working across this change, so convert its entry (Stage 4's first optional cleanup) in the
+  same commit that removes its handler, not after.
+- Optional cleanups, neither of which depends on anything in Stage 3 — so either may be pulled
+  forward into Stage 1 if convenient: convert origami's `clone(true)` stack to shared **custom**
+  entries (**keeping the clone** — it carries the jQuery-bound handlers that make its in-place
+  restore work, §4.11), and convert `ImageUndoManager` commits to shared entries.
+- Real-book soak testing: a talking-book book, a decodable/leveled reader book, a drag-activity
+  book, an RTL book, and a book with an image embedded in a text field.
+
+### Stage 5 — Delete (mechanical; regenerate rather than rebase)
+
+- `src/BloomBrowserUI/lib/ckeditor/**` (1.5 MB) and `typings/ckeditor/`.
+- C#: `Book.cs:629` `AddJavascriptFile` (and the dead commented `:578` line);
+  `ProjectContext.cs:597` skin path; `BloomServer.cs:1041` icon special-case;
+  `BookProcessor.cs:179-182` script-strip.
+- CSS: `.cke_*` rules in `editMode.less`, `audioRecording.less`, `qtipOverrides`; the whole
+  `hideAllCKEditors` mechanism (BL-12448 becomes moot — our toolbar simply isn't rendered until
+  we want it).
+- TS: `localizeCkeditorTooltips`, `updateCkEditorButtonStatus`, `doWhenCkEditorReady*`,
+  `removeCommentsFromEditableHtml` (BL-4775 was a CKEditor artifact), `setCkeditorBookmarkContent`
+  and `cleanUpNbsps`'s bookmark-emptying, `removeCkEditorFillingChars`, `fixUpEmptyishParagraphs`
+  and `safelyReplaceContentWithCkEditorData` (verify first), `ckeRegex` in
+  `jquery.text-markup.ts`, `PlaceholderProvider`'s `instanceReady` branch,
+  `StyleEditor.AttachToBox`'s gate, `bootstrap`'s dead BL-3125 guard and the post-init
+  `activateLongPressFor` re-attach.
+- The **duplicate Ctrl+V `keydown` handler** (`bloomEditing.ts:1764-1770`), which exists only
+  because CKEditor swallows `paste` inside editables. Once it doesn't, the document-level
+  `paste` listener fires normally. Verify that before deleting — this is exactly the kind of
+  workaround whose removal is the payoff.
+- Renames: `ckeditableSelector` → `richTextEditableSelector`, `attachToCkEditor` →
+  `attachBloomTextEditor`, and the `ckeditorCanUndo`/`ckeditorUndo` cross-frame exports.
+- **The flag itself** (§4.12): the `kNewTextEditor` token, the Advanced-tab checkbox and its XLF
+  entry, the `BLOOM_NEW_TEXT_EDITOR` override, the body class and `useNewTextEditor()`.
+  **⚠ This must happen before the release carrying the flag goes beta**, while the XLF entry is
+  still `translate="no"` and therefore freely removable (§4.12). It is the project's only hard
+  calendar deadline.
+  Deliberately *not* doing: clearing the obsolete token from users' saved settings. There is
+  precedent for it (`MigrateFromOldSettings` does `SetValue("webView2", false)`), but the flag never
+  ships beyond in-house testers, so a handful of stale tokens in their settings is harmless and not
+  worth the migration code.
+- Specs encoding CKEditor artifacts: `editableDivUtilsSpec.ts`, `toolboxSpec.ts`,
+  `audioRecordingSpec.ts`, `jquery.text-markupSpec.js`.
+- **Keep, but relabel, the legacy-book cleanups.** Books on disk contain `cke_*` classes,
+  `cke_bm_*` spans, `data-cke-saved-href`, ZWSPs and `<br></p>`. Move `HtmlDom.RemoveCkEditorMarkup`,
+  `BookData.IsCkEditorBookmarkSpan`, `XmlHtmlConverter`'s `<br></p>` regex and `PublishHelper`'s
+  ZWSP scrub into one new `LegacyCkEditorCleanup` class, documented as migration-only, and leave
+  the call sites. Removing them is a separate future decision (§10 "Still genuinely open").
+
+### Stage 6 — Reap the simplification
+
+With the CKEditor references gone, the async-init scaffolding has no reason to exist:
+`doWhenPageReady` becomes trivial, `SetupElements` no longer races anything, and the
+`requestPageContentDelay` bookkeeping can probably shrink. Do this as a **separate** pass with
+its own review, not smuggled into Stage 5, because it changes real page-load ordering.
+
+Also examine, but do **not** assume deletable: `audioRecording.setHighlightSession`
+(`audioRecording.ts:198-202`), a superseding counter for overlapping page-setup rounds
+("*newPageReady fires twice*", BL-15300 highlight flash). It is the surviving relative of the
+race that originally opened BL-6681 (see §11), but "newPageReady fires twice" is not obviously
+CKEditor's doing. Measure before touching it.
+
+## 7. Test strategy
+
+- **Vitest / jsdom** for everything pure or static-DOM-shaped: `inlineFormat`, `pasteSanitizer`,
+  `ISelectionAnchor` round-trips, `getCleanHtml`, `autolink`, `UndoStack` bounds / page-scoping /
+  nesting, `PageSnapshot` capture.
+- **Not testable in jsdom:** `typingTransactions.ts` and `keyCommands.ts`. jsdom has no native
+  editing behaviour and does not emit `beforeinput` or support `getTargetRanges()`. These can
+  only be verified against a live WebView2 — budget for the CDP harness rather than for faking
+  `InputEvent`s.
+- **C# tests** through `build/agent-dotnet.sh` for `DeletedPageUndoManager` and
+  `LegacyCkEditorCleanup`.
+- **Live-Bloom verification** via the `run-bloom` / `bloom-automation` skills: attach over CDP,
+  exercise a page, read the DOM back. The dev server pushes `.ts`/`.tsx` edits into a running
+  Bloom, so most iteration needs no build.
+- **Manual test ideas** per stage via the `add-test-ideas` skill, posted on the tracker card.
+- A dev-only harness page for the formatting engine (nested formatting, partial selections
+  crossing element boundaries, RTL, structural spans) pays for itself early.
+- **`pasteSanitizer` deserves the most aggressive test suite in the project**, because it is a
+  pure string→string function guarding a safety property (§4.8) whose failure is silent. Treat it
+  the way one treats a sanitizer: adversarial corpus, fail-closed assertions (assert on what
+  *survives*, so an unlisted tag can't slip through by nobody having written a case for it), and
+  a real captured clipboard payload from a live web page rather than hand-written tidy HTML. The
+  drop path needs the live-WebView2 harness, since `DataTransfer` is not meaningfully
+  constructible in jsdom.
+
+## 8. Risks, ranked
+
+1. **Inline-formatting engine correctness.** Nesting, selections crossing element boundaries,
+   RTL, Bloom's structural spans. *Mitigation:* pure functions, heavy unit tests, a dev harness
+   page, and shipping behind the flag long before it's default.
+2. **Snapshot restore re-initialization.** Restoring HTML must leave canvas elements, Comical,
+   qtips and talking-book highlighting working. Origami is precedent for the *concept* only —
+   it restores a `clone(true)` (handlers and data included) in layout mode where
+   `contentEditable` has been stripped, so it is not precedent for the innerHTML restore path.
+   *Mitigation:* the handler-lifetime design in **§4.10** is the prerequisite, not an
+   afterthought — including calling `applyToolboxStateToPage()` so the toolbox frame's observers
+   recover. Land `reinitializePageAfterRestore()` in Stage 3 where no CKEditor instances need
+   resurrecting. **Mostly dissolved by tiering (§4.11)**: typing and formatting undo restore one
+   editable's `innerHTML` and reinit nothing; canvas-element undo restores one subtree through the
+   existing `refreshCanvasElementEditing`; origami keeps its own working clone restore; delete-page
+   is a separate C# mechanism. Nothing left needs a generic full-page reinit, so **don't build
+   one.** Navigation-based restore was considered and rejected — it would require the book DOM to
+   already hold the undone state, whose only route in is the save's merge phase (§4.11).
+3. **Silently losing paste/drop sanitizing.** Ranked this high not because it is hard but
+   because it is **invisible**: nothing fails, no test goes red, and the damage arrives later as
+   a user's book containing a pasted table that Bloom's UI cannot edit or delete. Drop is the
+   sharper edge of the two, since Bloom has no drop filtering of its own at all today and
+   CKEditor has been quietly covering it (§4.8 point 3). *Mitigation:* adversarial inventory
+   rows captured **before** any change, a pure sanitizer built early, and both paths tested.
+4. **Native browser undo diverging from our stack.** Addressed by the `beforeinput`
+   `historyUndo`/`historyRedo` fence (§4.4); listed here because forgetting it is silent and
+   corrupting rather than obvious.
+5. **Save interleaving.** Snapshot → save → undo → save must end with the restored HTML on
+   disk. Page-scoped clearing and page-frame-reload invalidation must be exactly right. The
+   sharpest case: an undo arriving while the state machine is in `SavePending` must not let the
+   in-flight save merge content we are discarding — `DiscardInFlightSave()`
+   (`EditingStateMachine.cs:367`) exists for this shape of problem; decide discard-vs-defer
+   deliberately and test it (§4.11).
+6. **IME / longpress / complex scripts.** The current `keydown` code has a history here
+   (BL-3900, BL-5215). `beforeinput` plus composition-awareness is the fix, but it needs testing
+   with a real IME and with the longpress character map.
+7. **Paste fidelity.** The BloomField transforms encode hard-won behaviour. Move them unchanged
+   and test against the inventory — except BL-12357, which cannot be moved unchanged (Stage 3).
+   Distinct from risk 3: that one is about letting *too much* through, this one about mangling
+   what we do let through.
+8. **Talking-book audio files vs undo — mostly benign, one path to check.** Support-file cleanup
+   runs only from `Book.BringBookUpToDate` (`Book.cs:1112`) and publish/upload paths
+   (`BookStorage.CleanupUnusedSupportFiles`, `BookStorage.cs:2623-2632`), **not** on page save.
+   So within an edit session, files referenced by restored spans still exist. The remaining
+   exposure is the talking-book tool's *explicit* delete / re-record actions; scope the
+   investigation to that path only.
+9. **Cross-frame lifetime.** Settled in §4.1–4.2 (data-not-closure entries, invalidate on
+   page-frame reload, C# pushes the delete-page entry). Keep it settled.
+
+## 9. Follow-ups this design makes cheap
+
+- **A visible Redo button.** Redo itself is in scope, but Ctrl+Y-only (§10 q1). A toolbar button is
+  where the remaining cost sits: there is **no Redo plumbing in C# at all** today — no
+  `RedoCommand`, no `SetEditingCommands` parameter, nothing in the `updateEditButtons` websocket
+  payload, no icon, no XLF entry. All of that is separable and can be added later without touching
+  the stack.
+- **Undo labels in the UI** — "Undo Delete Page" as the button tooltip.
+- **Wider undo scope** — style changes, book-level operations, multi-page undo all plug in as new
+  entry types without touching the stack.
+
+## 10. Decisions
+
+Everything here is settled. Recorded with the reasoning so a later session doesn't reopen it; see
+also [REVIEW-NOTES.md](REVIEW-NOTES.md).
+
+1. **Redo: in scope, extended rather than dropped — but Ctrl+Y only, no toolbar button.**
+   Origami has a Redo today, and removing it while unifying the stacks would be a small regression
+   for layout-mode users. The cost is small provided we take the two cheap routes in §4.1: an
+   index-based stack, and capturing the redo state lazily at undo time (origami's existing trick),
+   so nothing is paid per keystroke. Ctrl+Y is a JS-only key handler, matching origami's current
+   affordance exactly and needing **zero C# plumbing** — which matters, because Bloom has no Redo
+   plumbing whatsoever today (no `RedoCommand`, no `updateEditButtons` field, no icon, no XLF
+   entry). A visible button is deferred to §9 and can arrive later without touching the stack.
+   `redo?()` stays optional, so delete-page redo — the one case needing real C# work — can also come
+   later, acting as a redo floor until it does.
+2. **Hyperlink UI: keep the current `showLinkTargetChooserDialog` flow exactly.** The new
+   `FormatToolbar.tsx` hosts the same button invoking the same dialog. No behaviour change.
+3. **Clipboard (BL-16459): seam only.** `clipboard.ts` produces rich **and** plain payloads and
+   keeps the write behind one interface, but still writes from JS, so a genuinely safe cut remains
+   impossible and BL-16459 stays open — much cheaper to close later, because the seam is the part
+   that is expensive to retrofit (§4.9). Explicitly **not** doing the C# multi-format write or the
+   "HTML Format" byte-offset header in this project.
+4. **Delete-page undo keeps every deletion in the session**, capped at ~10 (§6 Stage 2a).
+5. **The flag** is an `ExperimentalFeatures` checkbox in Collection Settings → Advanced plus a
+   `BLOOM_NEW_TEXT_EDITOR` env-var override, latched into the page by a body class (§4.12). Its XLF
+   entry is `translate="no"`, so removal is free — **but must happen before that release goes beta**,
+   the project's one hard calendar deadline. Deliberately *not* clearing the obsolete token from
+   testers' settings.
+
+### Still genuinely open
+
+- **Legacy cleanup lifetime** — leave the C# CKEditor-artifact scrubbers
+  (`LegacyCkEditorCleanup`) in place indefinitely, or schedule a one-time book migration? Not
+  urgent: nothing in Stages 0–5 depends on the answer, and keeping them is safe. Decide when Stage 5
+  lands.
+
+## 11. What BL-6681 itself says
+
+Worth recording, because the ticket's title ("Remove ckeditor?") is much broader than its
+original content, and a future reader will otherwise misjudge what it is asking for.
+
+**It was opened in 2018 about one specific bug**, not as a general proposal: the talking-book
+`audioCurrent` highlight would vanish, because CKEditor's load code asynchronously re-set a
+`.bloom-editable` to its original value and clobbered the class another part of the code had
+just written — last write wins (repro on BL-6654). Two mitigations were in place: setting the
+highlight several times, and recovering by resetting it to the first element.
+
+**That root cause is already gone — by rearchitecture, not by being fixed.** The highlight is
+now tracked in `this.highlightedElement` / `AudioTextHighlightManager` rather than by marking the
+DOM; `audioRecording.ts:2711-2715` only strips `ui-audioCurrent` defensively, for "*older Bloom
+versions that used DOM marking*". So the ticket's founding symptom is **not** a driver for this
+project, and nobody should go looking for it. Its surviving relative is `setHighlightSession`
+(Stage 6).
+
+**A 2018 comment observed** that CKEditor "is not designed at all to be able to handle
+cross-iframe stuff", while Bloom's toolbox iframe must modify the editable-page iframe — and that
+`onload` and its callbacks fire three times, once per frame, so the timing controls may be
+waiting on the wrong events. Useful background for the Stage 6 page-load simplification.
+
+**A 2018 comment asked for exactly the inventory in §2** — "*It would help to list just what
+it's doing for us*", offering character formatting and paste safety and a question mark. §2 is
+that list, eight years later, and it is longer than anyone expected.
+
+**The 2026 comment is the load-bearing one** — the clipboard requirement, now §4.9 and §10 q3.
diff --git a/docs/retire-ckeditor/PROGRESS.md b/docs/retire-ckeditor/PROGRESS.md
new file mode 100644
index 000000000000..e97c905517d5
--- /dev/null
+++ b/docs/retire-ckeditor/PROGRESS.md
@@ -0,0 +1,669 @@
+# CKEditor retirement — progress log
+
+**Ticket:** BL-6681. **Plan:** [PLAN.md](PLAN.md). **Settled decisions:** [REVIEW-NOTES.md](REVIEW-NOTES.md).
+
+To resume after an interruption, issue **`/resume-ckeditor`** (see
+`.claude/skills/resume-ckeditor/SKILL.md`). Equivalent plain-English prompt:
+*"Read docs/retire-ckeditor/PROGRESS.md and continue from the next unchecked item."*
+
+## Current state
+
+**Phase: Stage 0 preflighted and open as a draft PR.**
+**PR [#8153](https://github.com/BloomBooks/BloomDesktop/pull/8153)** (draft), branch
+**`BL-6681-stage0-inventory`**, pushed and rebased onto master. Card linked; QA test-ideas posted;
+Devin consultation logged. All of PLAN.md §10 is decided except the Stage-5 legacy-cleanup lifetime,
+which blocks nothing.
+
+**Not yet merged, and three Stage 0 verification items are deliberately still open** — they are
+carried, not forgotten: the paste/drop baseline, the handler-accumulation repro, and the page-reload
+timing baseline, plus G2/G6/G7 below. None of them block this PR, because it changes no behaviour in
+those areas.
+
+Stage 0 checklist (PLAN.md §6):
+
+- [x] Planning docs committed (`b7e849c62`)
+- [x] `BEHAVIOR-INVENTORY.md` — sections A–K plus cross-cutting X1–X7 (`c435b9708`)
+- [x] Characterization tests for the selection functions (`07f4500a8`) — 10 tests, passing,
+      falsification-checked. Covers inventory G4/G5.
+- [x] Environment unblocked: `vp`/`volta` PATH untangled, `init.sh` clean, `output/browser`
+      repopulated. Full front-end suite green: **591 passed**.
+- [x] `toolbox.ts` selection-bracket prep commit (`2707d98a8`) — §5.4 done
+- [ ] Capture the paste/drop baseline (rows C1–C7, incl. **C7 drop**): needs a running Bloom
+- [ ] Handler-accumulation repro (§4.10) + the X4 listener-leak test: needs a running Bloom
+- [ ] Page-reload timing baseline (§4.11): needs a running Bloom
+- [x] Rebased onto `origin/master` (was 64 behind; one conflict in `toolbox.ts`, resolved). Now 0
+      behind. Typecheck clean, 63 tests green.
+- [x] **G1 verified, both halves.** Automated: `verifyCaretPreservation.mjs` PASS (caret at the right
+      offset, bookmarks consumed, no ZWSP). Manual, by John: decodable reader open, "real typing
+      seems fine" — the case automation couldn't reach, and the check `toolbox.ts` itself prescribes.
+- [ ] **G2** (async markup path / BL-10133 — where the prep commit made its one deliberate behaviour
+      change) and **G3** (longpress) still unverified
+- [ ] **G6/G7** (new, from BL-16558): reader and Talking Book highlights are live Ranges and must
+      survive typing — and our restore paths must repaint them
+
+> ## ⚠ Toolchain: use `vp`, never Volta
+>
+> `ReadMe.md` "Building" is authoritative: install [vite-plus (`vp`)](https://vite.plus), which reads
+> `.node-version` (**24.13.0**) and `packageManager`, then run `./init.sh`. Volta was dropped
+> *because it does not fully support pnpm*.
+>
+**RESOLVED as of 2026-08-05.** `node` is 24.13.0 and `pnpm` 11.5.2, both served by `vp`, while
+`volta` still works for the maintenance worktrees. How it was untangled, since the intermediate
+states were each misleading:
+>
+> 1. **Volta's shim dir was in *Machine* PATH**, and Windows evaluates Machine before User, so vp's
+>    User-scope `~/.vite-plus/bin` could never win. No User-PATH reordering can fix that; the Machine
+>    entry has to go. Removed by the developer via elevated System-PATH edit.
+> 2. **That broke more than node.** Every binary in `%LOCALAPPDATA%\Volta\bin` is a shim whose entire
+>    body is `volta run "$(basename $0)" "$@"` — so with `volta.exe` off PATH, `pnpm`, `pnpx`,
+>    `reviewable` (used by the `reviewable-replies` skill), `nx`, `nx-cloud` and
+>    `chrome-devtools-mcp` all died with "volta: command not found". This is what made `init.sh`
+>    report it could not find volta. **Note for future advice: that directory is not "harmless
+>    because it contains no node" — its shims need `volta.exe`.**
+> 3. **`vp` does not put `pnpm` on PATH.** `vp env doctor` lists its shims as node, npm, npx,
+>    corepack, vpx, vpr — no pnpm. vp runs pnpm internally for its own subcommands (`vp install`),
+>    but `init.sh` calls bare `pnpm`. Fixed with the corepack that vp ships:
+>    ```sh
+>    corepack enable pnpm --install-directory ~/.vite-plus/bin
+>    ```
+>    which honours each package.json's `packageManager` (11.5.2 in `src/BloomBrowserUI`; in the repo
+>    root, which has no such field, bare `pnpm` reports corepack's own default — harmless, since
+>    `init.sh` cds into the package directories first).
+> 4. **Restored `volta` without letting it win**, by putting `C:\Program Files\Volta\` in **User**
+>    PATH (appended, so after `~/.vite-plus/bin`) rather than Machine. Verified resolution order:
+>    `node` → vp 24.13.0, `pnpm` → vp 11.5.2, `volta` → 2.0.2 available; `reviewable`, `nx` and
+>    `chrome-devtools-mcp` working again.
+>
+> Net effect: `vp` governs this repo, `volta` remains usable for the four maintenance worktrees
+> (`Version6.1`/`origin-Version6.1` node 16.14.0, `Version6.2` 22.11.0, `Version6.3` 22.21.1, all
+> yarn-era), and nothing has to be uninstalled.
+>
+> **Traps, recorded so nobody repeats them:**
+> - **Never `volta install`/`volta pin`** for this repo. The stale yarn-era `volta` field frozen in
+>   `output/browser/package.json` makes it look like a Volta project; it isn't.
+> - **Never remove `%LOCALAPPDATA%\Volta\bin` from PATH** while any `volta install`-ed global tool is
+>   still wanted — see (2).
+> - `CI=true` / `confirmModulesPurge=false` make pnpm skip its "remove node_modules?" prompt. That is
+>   destructive and normally wrong. It *was* used deliberately once here, for the repair install
+>   below, having first confirmed nothing was running — purging was the point.
+>
+> **What the repair actually was:** `node_modules` held **react-dom 17.0.2** where `package.json` and
+> the lockfile both require **18.3.1**, so anything importing `react-dom/client` failed to *load* —
+> breaking `bloomFieldSpec.ts`, `toolboxSpec.ts`, `ImageUndoManagerSpec.ts` and blocking Bloom
+> itself. `CI=true vp install` in `src/BloomBrowserUI` fixed it (1m41s). Its `prepare` step also set
+> `core.hooksPath -> .githooks` automatically.
+>
+> **Git hooks:** a stale **husky v4** hook in `.git/hooks/` hard-codes `packageManager=yarn` and was
+> running because `core.hooksPath` was unset, so commits failed with a yarn lockfile error. Now fixed
+> (and `vp install`'s `prepare` keeps it fixed). If it recurs in another clone/worktree:
+> `git config core.hooksPath .githooks` — **not** `--no-verify`.
+
+## Log
+
+### 2026-08-04 — survey, plan, review round 1
+
+Surveyed the whole CKEditor surface: `attachToCkEditor` / `BloomField.WireToCKEditor`,
+`config.js`, the bookmark & filling-char machinery in `editableDivUtils.ts` and `toolbox.ts`,
+the startup-race workarounds in `toolbox.ts` / `StyleEditor.ts` / `PlaceholderProvider.ts` /
+`GamePromptDialog.tsx`, and the C#-side artifact scrubbing in `HtmlDom`, `BookData`,
+`XmlHtmlConverter`, `PublishHelper`, `BookProcessor`, `BloomServer`, `ProjectContext`. Mapped
+the five existing undo mechanisms and how `workspaceRoot.handleUndo`/`canUndo` arbitrate.
+
+Wrote [PLAN.md](PLAN.md), had Fable review it against the real source, verified every finding
+independently, and revised. The material changes from the review are recorded in
+[REVIEW-NOTES.md](REVIEW-NOTES.md); the two that changed the shape of the plan were:
+
+- **Undo entries must be data, not closures** — the page iframe's JS context dies on same-page
+  reloads (zoom, origami exit), so closure-bearing entries would mutate detached documents.
+- **Stages 1–2 re-cut** — snapshot restore now waits for Stage 3, because restoring innerHTML
+  under live CKEditor orphans `div.bloomCkEditor`, and since `doCkEditorCleanup` iterates that
+  expando the **save path would silently skip cleanup** for restored divs. Delete-page and
+  delete-canvas-element moved earlier, since they're what the user actually asked for and are
+  independent of that machinery.
+
+### Findings worth remembering (all folded into the plan)
+
+- `bootstrap()`'s BL-3125 `.bloom-canvas` guard (`bloomEditing.ts:1216`) is **dead code** —
+  `this` is `undefined` in a strict-mode module function, so `$(this).find(...)` is always empty.
+  Canvas-element editables do get CKEditor via `CanvasElementManager.addEventsToFocusableElements`.
+- `toolbox.ts:1530-1537`'s comment that ArithmeticTemplate boxes get no editor is **wrong**;
+  `.Equation-style[contenteditable='true']` is in `ckeditableSelector` (`utils/shared.ts:16-19`).
+  The real no-editor case is `cursor: not-allowed` (`bloomEditing.ts:1952`).
+- `workspaceRoot.ts:125`'s "*see also Browser.Undo*" C# fallback comment is **stale** — no such
+  fallback exists in the WebView2 code.
+- `config.undoStackSize = 0` doesn't disable the stack; CKEditor 4 reads
+  `config.undoStackSize || 20`, so it silently means 20.
+- The toolbox "undo" is a per-editable **text-typing** undo, not a reader-setup undo, and its
+  precedence over CKEditor's is deliberate.
+- Support-file cleanup runs only from `Book.BringBookUpToDate` and publish/upload paths, not on
+  page save — so undo restoring audio spans is largely safe within a session.
+
+### 2026-08-04 (later) — BL-6681 read and folded in
+
+`$YOUTRACK_BOT` is now set and authenticates as `Bot`. Read the ticket and its five comments.
+Two findings changed the plan; both were verified in the code first.
+
+- **A clipboard requirement the plan had missed entirely** → new §4.8, new `clipboard.ts` in
+  Stage 3, new open question §10 q4. The 2026 comment from the BL-16459 investigation states the
+  test a replacement must pass: *can Bloom supply the clipboard payload (rich and plain) and be
+  told whether the write succeeded?* Chromium never reports clipboard write failure to JS, and a
+  .NET clipboard *read* doesn't fail either (OLE serves a cached copy), so only a C# **write**
+  gives an honest success signal — which is why a JS-only safe cut is impossible. PR #8140 built
+  the copy-then-delete fix and withdrew it because Bloom's own cut can only write plain text, so
+  every cut lost bold/links/inline pictures. Branch
+  `origin/BL-16459-clipboard-failure-reporting` is deliberately preserved; **read it before
+  re-deriving any of this.**
+- **A CKEditor interference the plan had missed** → new §2 table row 13. CKEditor
+  `preventDefault()`s copy/cut inside `.bloom-editable` and swallows paste, which is why a
+  duplicate Ctrl+V `keydown` handler exists at `bloomEditing.ts:1764-1770`. Its own comment says
+  as much. Deletable in Stage 5 once CKEditor is gone.
+
+Also recorded the ticket's history in **§11**, because its title is much broader than its
+original content and would otherwise mislead a future reader:
+
+- BL-6681 was opened in 2018 about **one bug** — the talking-book `audioCurrent` highlight
+  vanishing because CKEditor's async load re-set a `.bloom-editable` and clobbered a class
+  (repro BL-6654) — not as a general proposal to remove CKEditor.
+- **That root cause is already gone**, by rearchitecture: the highlight now lives in
+  `AudioTextHighlightManager` / `this.highlightedElement`, and `audioRecording.ts:2711-2715`
+  only strips `ui-audioCurrent` defensively for "older Bloom versions that used DOM marking".
+  So the founding symptom is **not** a driver for this project. Don't go hunting for it.
+- The surviving relative is `setHighlightSession` (`audioRecording.ts:198-202`, BL-15300), a
+  superseding counter for overlapping page-setup rounds. Flagged in Stage 6 as *measure before
+  touching* — "newPageReady fires twice" is not obviously CKEditor's fault.
+- A 2018 comment noted CKEditor "is not designed at all to handle cross-iframe stuff" while
+  Bloom's toolbox iframe must modify the page iframe, and that `onload` fires three times, once
+  per frame. Useful background for the Stage 6 page-load simplification.
+
+### 2026-08-04 (later still) — paste/drop filtering promoted to a first-class requirement
+
+John pointed out that CKEditor's filtering of pasted HTML wasn't visible in the plan's inventory.
+It *was* there, but buried inside a "paste pipeline" table row as if it were an implementation
+detail, with no statement of why it matters. Fixed, and the investigation turned up a real gap:
+
+- New **§4.8**, with the rationale in John's terms (users must not be able to introduce
+  structures Bloom's UI could never create and that are hard to edit or delete) **and** the
+  second rationale already written in `config.js:107-112` about not promising translators
+  formatting they can't replicate. Preserved because Stage 5 deletes that file.
+- **Verified gap: drop is currently filtered only by CKEditor.** Its clipboard plugin attaches
+  its own `drop` listener and routes drops through the same filter as pastes
+  (`ckeditor.js:622`). Bloom's own drop handling covers only internal canvas-element drags via a
+  custom `text/x-bloom-canvas-element` type (`CanvasElementManager.ts:2069-2088`) and does
+  nothing for externally-dropped HTML. **So this protection is invisible today and would vanish
+  silently.** The new sanitizer must cover `insertFromDrop` as well as paste.
+- Recorded the `allowedContent = true` + restrictive `pasteFilter` split as deliberate: the first
+  attempt at BL-3899 filtered all content and broke BL-3976. So the sanitizer applies at the
+  clipboard/drop boundary only — never as a DOM invariant, or it would reject Bloom's own markup.
+- Recorded the BL-4775 ↔ BL-12357 tension: BL-4775 removed `span` from the filter entirely,
+  BL-12357 had to allow `span{font-variant,color}` back for small caps and colour.
+- Promoted to **risk 3** (renumbering the rest), moved `pasteSanitizer.ts` earlier in Stage 3,
+  and added adversarial inventory rows to Stage 0 — to be captured against *today's* behaviour
+  before anything changes.
+
+Lesson for the remaining planning: a guarantee that fails **silently** needs its own inventory
+row and its own risk entry, not a mention inside a row about something else.
+
+### 2026-08-04 (later still, 2) — event-handler lifetime designed; an existing bug found
+
+John asked what re-attaches event handlers, observers and the like after a snapshot restore, and
+whether we need either an idempotent central setup function or document-level delegation. Counted
+the real landscape first: **~40 `addEventListener` sites, ~50 jQuery `.on()` sites across ~25
+files, 17 observer sites**, plus jQuery-UI `draggable`/`resizable`, `qtip`, `nicescroll`,
+`longPress` and Comical. Answer written up as **§4.10**.
+
+The design: distributed registration, centralized invocation, **teardown by `AbortSignal`**.
+Each module calls `registerPageContributor(...)` in its own file; `setUpPage`/`tearDownPage`
+know none of them; every listener takes `{ signal }` so one `abort()` removes them all, and
+observers hang off the same scope via `addCleanup`. This is deliberately *not* the
+"idempotent re-run" framing of the question: idempotency requires every handler to be dedupable
+(no arrow functions, no closures — the discipline `CanvasElementManager.ts:943-945` is pleading
+for), whereas signal-scoped teardown makes closures safe, so the easy way to write a handler
+becomes the correct way. Enforcement by ESLint rule plus a CDP `DOMDebugger.getEventListeners`
+leak test, because convention alone won't hold.
+
+**Existing bug found while checking whether `SetupElements` is idempotent — it isn't.**
+`SetupElements(container)` is already called re-entrantly on subtrees
+(`CanvasElementManager.ts:1007` in `refreshCanvasElementEditing`, `imageDescription.tsx:336`),
+but it calls `AddEditKeyHandlers(container)` (`bloomEditing.ts:727`), two of whose handlers attach
+to **`document`** rather than the container (`:291` Ctrl+Space clear-formatting, `:301`
+Ctrl+R/L/E justify), and which also attaches per-editable `keydown` handlers via jQuery `.on()`.
+So handlers accumulate on every canvas-element refresh, today, with no restore path involved.
+Most duplicated commands are near-idempotent, which likely explains why it went unnoticed; F6's
+`insertHTML("<sup>"+selection+"</sup>")` is the plausible visible symptom.
+**Found by code reading, not reproduced.** Attempt a repro in Stage 0 and file it as its own
+card — it is independent of CKEditor and is the best evidence that this area needs the §4.10
+design rather than more discipline. *Not yet filed in YouTrack.*
+
+Two further consequences recorded:
+
+- **The cross-frame half can't be solved by a page-frame registry.** `motionTool`, `GameTool`,
+  `audioRecording`, `PlaceholderProvider`, `StyleEditor` and `BloomSourceBubbles` all observe
+  page-frame elements from the *toolbox* frame. Reuse the hook that already exists for this:
+  `applyToolboxStateToPage()` (`workspaceRoot.ts:164-170`). Restore must call it — "the DOM was
+  replaced under you" is indistinguishable from "a new page loaded" for every one of these.
+- **This strengthens the case for reload-based restore.** A real page load re-runs everything and
+  needs zero migration of ~90 attachment sites. Recommended posture: ship full-page undo that
+  way, treat in-place restore as a later optimization gated on `pageScope` adoption. Undo is not
+  latency-critical, and it decouples undo from a large refactor. `pageScope.ts` is a new file
+  that can land early and be adopted module by module — one small independent commit each.
+
+### 2026-08-04 (later still, 3) — restore cost tiers; reload-without-save confirmed feasible
+
+John noted that page reload is slow, so using it for every undo would be a visible regression for
+small undos like typing, and asked whether an undo could reload without forcing a save. Both
+points now in **§4.11**.
+
+**Tiering (the more important half).** Restore cost is keyed to how much the operation touched:
+
+- **Tier 1 — one editable** (typing, inline formatting, paste/cut in a box): restore
+  `editable.innerHTML` + caret anchor. No reload, no C# round-trip. **Verified handler-safe** —
+  nothing attaches handlers to nodes *inside* editables (no `addEventListener`/`.on()` on
+  `audio-sentence`, `bloom-highlightSegment`, `bloom-linebreak`); they live on the
+  `.bloom-editable` div, which survives an `innerHTML` replacement. And there is already a working
+  precedent: `readerToolsModel.undo()` (`readerToolsModel.ts:574-591`) does exactly this. So the
+  cheapest tier is the existing reader-tools undo, generalized with a proper caret anchor.
+- **Tier 2 — one `.bloom-canvas` subtree**: restore subtree HTML + `refreshCanvasElementEditing`.
+  No reload.
+- **Tier 3 — page-structural** (essentially origami layout): full reinit, reload-based first.
+
+So the overwhelming majority of undos never leave the page frame, and Tier 3's cost is acceptable
+because it is rare. This also shrinks risk 2 considerably.
+
+**Reload-without-save: yes, and the coupling runs the opposite way from the intuition.** Saving
+does not exist to enable the reload — saving *forces* it, because the save path strips UI elements
+and leaves the page invalid for editing (`State.SavedAndStripped`, `EditingStateMachine.cs:16-21`,
+BL-13502). Nothing requires a disk write before navigating. Findings:
+
+- `SaveThen(skipSaveToDisk: true)` already exists and already skips the disk write
+  (`EditingModel.cs:220, 451`).
+- For undo, even the `requestPageContent` round-trip is unnecessary — we already hold the HTML.
+  So Tier 3 wants a narrower entry point than anything today: *install this HTML as page X in the
+  book DOM, don't ask the browser, don't write to disk, then navigate.* Remaining cost: one
+  HTML→XML conversion plus the navigation.
+- Undo should deliberately **not** write to disk — the disk copy is already whatever it was, Bloom
+  saves on page change, and an undo shouldn't create a save point.
+- **Sharp edge:** an undo arriving during `SavePending` must not let the in-flight save merge the
+  content being discarded. `DiscardInFlightSave()` (`EditingStateMachine.cs:367`) exists for this
+  shape of problem. Folded into risk 5; decide discard-vs-defer deliberately.
+- **BL-13502 is the same knot.** If saving stopped leaving the page invalid, `SaveThen` wouldn't
+  need to navigate at all, making Tier 3 cheap and helping far more than undo. Out of scope, but
+  worth noting on that ticket that undo is another reason to want it.
+
+**Measure, don't guess** — added to Stage 0. The disk-plus-conversion hypothesis is plausible but
+unmeasured, and the alternative (page-DOM regeneration + browser parse + `bootstrap`) wouldn't be
+helped by skipping the save. Bloom's existing performance-log feature can attribute the time, and
+the same measurement gives the baseline for showing that removing CKEditor made page loads faster —
+a reload currently waits on CKEditor's async init.
+
+### 2026-08-04 (later still, 4) — Tier 3 corrected: in place, and probably empty
+
+John queried the Tier 3 proposal, correctly spotting that it conflated two mechanisms and
+hand-waved the hard part: *if we navigate, the document comes from C# out of the book DOM, so how
+does the undone state get in there apart from a Save?* It doesn't. **§4.11's Tier 3 was wrong and
+is rewritten.**
+
+- The only route into the book DOM is the save's merge phase —
+  `UpdateBookDomFromBrowserPageContent` → `Book.UpdateDomFromEditedPage`
+  (`EditingModel.cs:1760-1766`) — which strips the editing UI, propagates the data-div through
+  `BookData`, recomputes feature requirements and decides full-vs-partial. We can skip asking the
+  browser for content and skip the disk write, but **not the merge**. So "reload without saving" is
+  "a save minus two of its three phases", and the phase it keeps (whole-book data-div propagation)
+  is plausibly costlier than the disk write it drops. **Rejected.**
+- Tier 3 now does what John described: install the snapshot into the live document, then run normal
+  page init. No C#, no navigation, no save.
+- Kept one incidental finding because it inverts a natural assumption: the coupling runs the
+  opposite way — saving *forces* the reload, since the save path leaves the page stripped and
+  invalid for editing (`State.SavedAndStripped`, BL-13502). Nothing requires a disk write before
+  navigating.
+
+**And Tier 3 is probably empty, so don't build a generic full-page restore.** Enumerated what would
+land there: origami layout (already restores in place and works — `origamiRoot.replaceWith(clone)`,
+sound because layout mode strips `contentEditable` at `origami.ts:132` **and** origami attaches all
+its UI handlers via jQuery `.click()` at `origami.ts:404-457`, which is exactly what `clone(true)`
+preserves — so **keep it**, and note that migrating origami to `addEventListener` would silently
+break its undo); delete-page (C#-side, navigates anyway); style changes (deferred). Nothing left.
+
+**Knock-on: `pageScope` (§4.10) is no longer a prerequisite for undo.** Still worth doing for the
+handler-accumulation bug and for the new editor's own handler lifetime, but it gates nothing, so it
+can be adopted module by module at any pace. Also means the origami and `ImageUndoManager`
+conversions in Stage 4 depend on nothing in Stage 3 and could be pulled forward to Stage 1.
+
+### 2026-08-04 (later still, 5) — the feature flag redesigned so testers can use it
+
+John pointed out that a `localStorage` switch needs devtools, so testers can't use it, and asked
+about an environment variable or a temporary Help-menu item. Bloom already has the right mechanism.
+Now **§4.12**.
+
+- **`ExperimentalFeatures`** (`ExperimentalFeatures.cs`) keeps tokens in
+  `Settings.Default.EnabledExperimentalFeatures`, persisted per user, surfaced as checkboxes in
+  **Collection Settings → Advanced** (`AdvancedSettingsPanel.tsx` + `CollectionSettingsDialog.cs`).
+  Add `kNewTextEditor`. Better than a Help-menu item: no new menu, one place testers already know.
+- **Plus `BLOOM_NEW_TEXT_EDITOR=1`** for developers and the canvas e2e specs, which launch Bloom
+  themselves. Precedent: `BLOOM_AI_EDITOR_URL`, `BloomWV2Path`, `BloomSandbox`.
+- **The page frame reads it synchronously from a body class**, because `useNewTextEditor()` runs
+  per editable and the experimental-features API is async — reintroducing an async-init ordering
+  problem in *this* project would be absurd. So C# decides in `Book.AddJavaScriptForEditing`
+  (`Book.cs:621-629`): flag on → skip the CKEditor script tag **and**
+  `AddClassToBody("bloom-newTextEditor")` (helper already exists, used for `template` at
+  `Book.cs:1864`).
+
+Two good properties fall out, neither of which the localStorage plan had:
+
+1. **The flag is latched per page load by construction**, so you can never get a page with some
+   editables on the CKEditor path and some on the new one. A setting change takes effect at the
+   next page load.
+2. **With the flag on, CKEditor is not loaded at all** — a far stronger test than loading it and
+   bypassing it, since the flag-on build then cannot lean on CKEditor for anything we forgot.
+
+**And the integration is already largely de-risked:** "CKEditor is absent" is an existing supported
+mode, because `BookProcessor` strips the script tag for off-screen page processing. Guards are
+already present at all four main integration points — `bloomEditing.bootstrap:1214`,
+`StyleEditor.AttachToBox:1210-1211`, `toolbox.doWhenCkEditorReadyCore:995`,
+`editablePage.ckeditorCanUndo:315`. With the flag on they already do the right thing, so the Stage 3
+dispatches become "*also* start the new editor" rather than "skip CKEditor".
+
+**John's decisions on the two costs I flagged:**
+
+- **XLF:** the entry gets `translate="no"` — which is the `xlf-strings` skill's default for new
+  entries anyway ("*Always mark new entries `translate="no"` unless instructed otherwise*"), so no
+  translator effort is spent and later removal is free. **But this creates the project's one hard
+  calendar deadline: the flag must be removed before the release carrying it goes beta**, since that
+  is when strings are picked up for translation and the skill then forbids changing an entry's ID or
+  source. Flagged with a ⚠ in Stage 5.
+- **Don't clear the obsolete setting.** The flag never ships beyond in-house testers, so a handful of
+  stale tokens is harmless and not worth migration code. The `SetValue("webView2", false)` precedent
+  is noted in the plan as deliberately *not* followed, so a later reader doesn't "fix" it.
+
+### 2026-08-04 (later still, 6) — last three open questions answered; §10 is now "Decisions"
+
+- **Hyperlink UI: keep as-is.** `FormatToolbar.tsx` hosts the same button invoking the same
+  `showLinkTargetChooserDialog`. No behaviour change.
+- **Clipboard: seam only.** `clipboard.ts` produces rich+plain payloads behind one interface but
+  still writes from JS; BL-16459 stays open. Explicitly *not* doing the C# multi-format write or the
+  "HTML Format" byte-offset header. Added to the non-goals in §1.
+- **Redo: in scope, extended rather than dropped — Ctrl+Y only, no toolbar button.** John was
+  inclined to extend it if cheap, so I priced it first:
+  - There is **no Redo plumbing in C# at all** today — no `RedoCommand`, no `SetEditingCommands`
+    parameter, nothing in the `updateEditButtons` payload, no icon, no XLF entry. So a *button* is
+    where the real cost is; Ctrl+Y is a JS-only handler needing none of it, and matches origami's
+    existing affordance exactly.
+  - Two cheap routes keep the stack cost near zero (now in §4.1): **index-based** stack with
+    truncate-on-push, and **capturing the redo state lazily at undo time** rather than at commit
+    time — so nothing is paid per keystroke, only when the user actually undoes. That lazy trick is
+    already in the codebase: `origamiUndo` stashes a fresh clone before decrementing
+    (`origami.ts:288-292`).
+  - `redo?()` stays optional, so an entry without it acts as a redo floor. Delete-page redo (the one
+    case needing real C# work) can therefore be deferred without blocking anything.
+  - Sequencing constraint added to Stage 4: origami's `keydown.origami` handler must be retired in
+    the *same commit* that converts its entry, or its Redo breaks in between.
+  - Incidental: `readerToolsModel.redo()` (`:609`) appears **unreachable** — nothing exports or
+    calls it. Noted in Stage 1; deleted in Stage 5 regardless.
+
+§10 is retitled from "Open questions" to "Decisions", with reasoning kept inline so a later session
+doesn't reopen settled ground. **One genuinely open item remains**, and it blocks nothing: whether
+the C# `LegacyCkEditorCleanup` scrubbers stay indefinitely or get a one-time book migration. Decide
+when Stage 5 lands.
+
+### 2026-08-04 — Stage 0 started
+
+Branch `BL-6681-stage0-inventory` off `master` at `2ca9f2f08c`.
+
+**Environment fix needed first.** The first commit failed: a stale **husky v4** `pre-commit` hook in
+`.git/hooks/` (installed 2026-01-29 from a *different* worktree, `…/BloomDesktop.worktrees/Version6.3`)
+hard-codes `packageManager=yarn`, and yarn then died on the pnpm workspace. The repo has already
+replaced husky with its own `.githooks` dispatcher, but `core.hooksPath` was unset in this clone, so
+git was falling back to the stale hooks. Fixed the documented way (`.githooks/README.md`, "How to
+enable it (per clone)"):
+
+```sh
+git config core.hooksPath .githooks
+```
+
+The dispatcher then correctly routed to `src/BloomBrowserUI/.vite-hooks/pre-commit` and the checks
+passed. **Worth knowing for other clones/worktrees** — the symptom is a yarn lockfile error on
+commit, and the fix is one git-config line, not `--no-verify`.
+
+**`BEHAVIOR-INVENTORY.md` written.** Sections A–K plus cross-cutting X1–X7. Design choices in it
+worth keeping:
+
+- It covers only behaviours **at risk** — implemented by CKEditor or in code we will move. It
+  deliberately excludes `BloomField.ManageField`'s CKEditor-independent behaviours (BL-786, BL-933,
+  BL-952, BL-2274, BL-7061, BL-16518 …), which stay exactly where they are; listing them would dilute
+  the rows that matter.
+- Rows are tagged **⚠ capture first** (all of section C — paste/drop filtering) and
+  **✗ must NOT survive** (workarounds we intend to delete, so nobody faithfully reimplements them).
+  The ✗ rows are: the duplicate Ctrl+V keydown handler, the CKEditor artifact scrubbers on the
+  *browser* side (C# ones stay for legacy books), the mid-word bookmark bug, and `bootstrap()`'s dead
+  BL-3125 guard.
+- Four rows need a *new* implementation rather than a port, each with the reason: **D8** (BL-12357
+  small caps — depends on `cke/id`, meaningless without CKEditor), **K4** (`bloom-preventRemoval` —
+  currently uses `execCommand("undo")`, the very stack we're fencing off), **A7/A9** (colour panel —
+  superseded by Bloom's own colour dialog), and **G1** (should get strictly *better*, since offset
+  anchors don't perturb the markup).
+- H10–H17 record the project's *new* undo behaviour as acceptance criteria, separate from H1–H9's
+  no-regression rows.
+- X4 ("no listener leak") **fails today** — stated as such, so it reads as a known-red criterion
+  rather than a passing one.
+
+### 2026-08-04 — Stage 0 part 2: characterization tests, then blocked
+
+**Found that existing coverage was much better than the plan assumed.** Inventory rows D1–D3, D5,
+D6, B9, B10 and K3 are already tested in `bloomFieldSpec.ts`; F1, F2 and F4 in
+`editableDivUtilsSpec.ts`. So rather than duplicating them, hunted for the genuine gap.
+
+**The gap that mattered: `makeSelectionIn`'s `divBrCount`.** Nothing in the app passes anything but
+`-1` for it (`readerToolsModel.ts:587-592`, `toolbox.ts`), yet §4.3's new selection anchors depend on
+exactly that `<br>`-stepping behaviour. So it was completely unpinned. Now covered by
+`bookEdit/js/editableDivUtilsSelectionSpec.ts` — 10 tests over the offset round-trip, counting across
+inline markup, `divBrCount` 0/1/2-with-only-one-`<br>`, the not-at-a-boundary case, and `atStart`
+either way.
+
+**All 10 passed first run, which for characterization tests is a reason for suspicion, not
+satisfaction.** So I falsified deliberately: changed the `divBrCount`-1 expectation from 2 to 99 and
+confirmed it failed with `expected 2 to be 99`. The assertions genuinely observe the DOM rather than
+passing vacuously. Reverted, re-confirmed green.
+
+**A design finding the tests forced out:** both functions hard-code
+`parent.window.document.getElementById("page")` and operate on that iframe's window, which is why the
+test harness has to build such an iframe. The replacement `selectionApi.ts` should take a
+document/root instead — testable, and reusable outside the page frame. Recorded in the spec's header
+comment and in the commit message.
+
+**Then hit the environment wall** (see the boxed warning at the top). The remaining three Stage 0
+items all need either `toolboxSpec.ts` to run or Bloom to launch, and both need a working
+`node_modules`.
+
+I initially misdiagnosed this as "upgrade Node via Volta"; John pointed at `ReadMe.md`, which says
+to install `vp` (vite-plus) and notes Volta was dropped precisely because it doesn't fully support
+pnpm. The boxed warning now records the documented path and the two traps. **Lesson: check
+`ReadMe.md`'s Building section before reasoning about toolchain state from what happens to be
+installed** — the machine had Volta on PATH and no `vp`, which looks like a Volta project until you
+read the docs.
+
+Deliberately **did not** press on with the `toolbox.ts` prep commit: it refactors the most delicate
+keystroke code in the app, its own spec can't currently load, and doing that unverified is exactly
+the wrong trade. Better to stop and ask.
+
+### 2026-08-05 — environment fixed, prep commit done
+
+**Environment.** John installed `vp` and ran `init.sh`, but `react-dom` was still 17.0.2 — `init.sh`'s
+backgrounded `pnpm install` had evidently failed under Volta's Node. Ran `CI=true vp install` in
+`src/BloomBrowserUI` directly (nothing running, verified first); react-dom is now 18.3.1 with
+`./client` exported, and the previously-unloadable specs pass. Full suite: **591 passed, 5 skipped**.
+
+The residual PATH finding is in the boxed warning: Volta still wins for bare `node` and *cannot* be
+outranked by User-PATH reordering, because Machine scope always precedes User scope. So all project
+commands go through `vp`.
+
+**Prep commit `2707d98a8` — `markupSelectionPreservation.ts`** (§5.4). Extracted the
+save/restore-selection bracket out of `handleKeyboardInput` into four functions —
+`boxParticipatesInMarkup`, `saveSelectionForMarkup`, `restoreSelectionAfterMarkup`,
+`restoreAndResaveSelectionForMarkup` — keeping the CKEditor-bookmark implementation exactly as it
+was. The saved value is typed `unknown[]` so callers can't peek; the planned replacement stores a
+character offset instead. Now the anchor swap changes four function bodies and leaves the pipeline
+alone.
+
+Two things worth carrying forward:
+
+- **One deliberate behaviour difference**, commented at the site and in the commit message. The async
+  path previously called `createBookmarks` unguarded; had the editor reported no selection there it
+  would have thrown inside an async function nobody awaits — an unhandled rejection leaving the pass
+  half-done, comments already stripped and marker spans possibly still in the DOM. It now abandons
+  the pass cleanly, which is what the first save has always done.
+- **Corrected a long-wrong comment.** It claimed ArithmeticTemplate number boxes get no editor
+  "because the logic that invokes WireToCKEditor is looking for classes like bloom-content1".
+  `ckeditableSelector` explicitly includes `.Equation-style`, added for that very template. The real
+  no-editor case is `cursor: not-allowed`. (Same error the inventory caught in the plan's own §2.)
+
+**Verification gap to close:** `toolboxSpec.ts` covers only `cleanUpNbsps` and
+`removeCommentsFromEditableHtml`, not the keystroke pipeline, so this refactor has **no direct test
+coverage**. It rests on the typecheck, lint, the full suite, and a strictly mechanical diff. Inventory
+rows **G1–G3** must be verified live before the PR — that is now an explicit checklist item.
+
+### 2026-08-05 — live session: caret seam verified, harder half still open
+
+Bloom launched cleanly from this worktree (HTTP 8089, CDP 8091). Two obstacles worth recording,
+because both will recur:
+
+- **The `2 EFL Books` collection is a Team Collection and Bloom is *Disconnected*,** so its books
+  cannot be checked out — the Edit tab and "EDIT THIS BOOK" are both `aria-disabled`. Selecting a
+  book is not enough. **Workaround that works: create a new book from a template**; new books are
+  local, so the disconnected-TC block doesn't apply, and Edit becomes enabled immediately. (The
+  alternative — switching to a non-TC collection such as `English Books` — means driving Bloom's
+  WinForms collection chooser, which CDP can't reach, or restarting with different settings.)
+- **A Basic Book's toolbox offers only Talking Book and "More…"**, and both stayed
+  `visible: false` even after toggling `#pure-toggle-right`; no `audio-sentence` spans appeared, so
+  `updateMarkup` never ran. The reader tools need a **Decodable Reader** or **Leveled Reader** book.
+
+**What is verified.** `docs/retire-ckeditor/verifyCaretPreservation.mjs` (kept in the repo so the
+next session doesn't rebuild it) types a character mid-word and checks where the caret lands. Run
+twice independently, **PASS** both times:
+
+| Check | Result |
+| --- | --- |
+| Text after typing `z` at offset 4 of "house" | `housze` ✓ |
+| Caret character-offset afterwards | **5** — immediately after the typed character ✓ |
+| Leftover `cke_bm_*` bookmark spans | **0** — the restore ran and consumed them ✓ |
+| Stray ZWSP filling chars | **0** ✓ |
+
+That exercises the wiring of all four extracted functions on the synchronous path, and confirms the
+bookmark lifecycle still balances. It is real evidence the prep commit didn't break the pipeline.
+
+**What is NOT verified — do not let this be forgotten.** With no tool active, `updateMarkup` never
+runs, so the DOM is *unchanged* between save and restore. That is the easy half. Still open:
+
+- **G1 proper** — caret survival while markup actually rewrites the DOM around it (the case
+  bookmarks exist for at all).
+- **G2** — the async-markup path and BL-10133 (keystrokes during the `await` must not land at the
+  wrong position). This is the branch where the prep commit made its one deliberate behaviour
+  change, so it deserves direct attention.
+- **G3** — longpress interaction (BL-3900, BL-5215).
+
+**To finish it:** create a book from the **Decodable Reader** template (not Basic Book), open the
+toolbox, activate the reader tool, then re-run the harness — it already prints the span counts
+needed to confirm markup ran. My initial expectation string in the harness was wrong (`houzse` for
+`housze`, an off-by-one in my own arithmetic, not a defect in Bloom); it is corrected in the
+committed version.
+
+**Leftover to clean up:** creating the test book left `Book-121f7932` in
+`Documents/Bloom/2 EFL Books/`. Harmless, but it is mine, not the developer's.
+
+### 2026-08-05 (later) — rebased onto master; BL-16558 changes two premises
+
+**Drift was real and immediate.** Master had moved **64 commits** ahead, and three files this stage
+touches had changed: `toolbox.ts`, `bloomEditing.ts`, `BloomField.ts`. Rebased onto `origin/master`;
+one conflict, in `toolbox.ts`, in exactly the region the prep commit refactored. Resolved by keeping
+master's change and re-wording only my trailing comment. Now **0 behind master**; typecheck clean;
+`toolboxSpec.ts` (7 tests now — master added two), `editableDivUtilsSelectionSpec.ts` and
+`bloomFieldSpec.ts` all green, 63 tests.
+
+Worth noting for the project's rebase strategy: this is the first stage, it sat unpushed for part of
+one day, and it already collided. The plan's "land small PRs promptly, don't keep a long-lived
+branch" (§5.2) is not theoretical — **get Stage 0 onto master.**
+
+**BL-16558 (on master) invalidates two premises and adds a requirement.** The decodable and leveled
+reader tools no longer rewrite the DOM to show violations: they paint `::highlight()` pseudo-elements
+over **live `Range` objects** (`bookEdit/js/textHighlightManager.ts`, `readerHighlights.ts`, styles
+at `editMode.less:1074-1100`). Talking Book's current-sentence highlight is the same
+(`editMode.less:1145`). Consequences, now folded into the plan and inventory:
+
+1. **§4.3's case against bookmarks got stronger, not weaker.** DOM-mutating marker spans are now
+   actively hostile: inserting and removing nodes around the caret is exactly the churn live Ranges
+   cannot survive. Previously the argument was "bookmarks briefly confuse the markup"; now it is
+   "bookmarks would break the highlight architecture".
+2. **New obligation on our restore paths (§4.11).** A Tier 1 undo restores `editable.innerHTML`,
+   which rebuilds the text nodes and **collapses every live Range**, so the highlights vanish —
+   with no error. `reinitializePageAfterRestore()` must repaint via `textHighlightManager` and
+   `audioTextHighlightManager`. This is exactly why BL-16558 had to move `updateMarkup()` to after
+   `cleanUpNbsps` and make the latter write `innerHTML` only when it changed something.
+3. **New inventory rows G6/G7**, with the acceptance test `toolbox.ts` itself prescribes: type in a
+   Leveled Reader book and watch the over-long sentences stay highlighted.
+
+**G1 proper is now verified — by John, manually.** He switched to a non-TC collection, opened a
+decodable reader, and reports "real typing seems fine". That is precisely the check master's own
+comment asks for, and it covers the case automation could not reach (a reader tool active, markup
+running). Combined with the automated harness result, the prep commit is verified on both halves.
+**G2 (async path / BL-10133) and G3 (longpress) remain unverified.**
+
+## Next actions
+
+All of Stage 0's code work is done. What remains needs a **running Bloom** — do it in one session
+(`run-bloom` skill), on branch `BL-6681-stage0-inventory`:
+
+1. **Finish rows G1–G3.** The seam's wiring is verified; the DOM-rewriting case is not (see the
+   2026-08-05 entry). Create a book from the **Decodable Reader** template, open the toolbox,
+   activate the reader tool, and re-run `node docs/retire-ckeditor/verifyCaretPreservation.mjs
+   <cdpPort>` — it already reports the span counts that show whether markup ran. Then G2 (async
+   path / BL-10133, where the prep commit made its one deliberate behaviour change) and G3
+   (longpress). Remember: a disconnected Team Collection blocks editing existing books, so make a
+   new one; and `toolboxIsShowing()` gates markup, so the pane must genuinely be open.
+2. **Capture the paste/drop baseline** → `PASTE-DROP-BASELINE.md`, rows C1–C7. Use a **real web-page
+   clipboard payload**, not hand-written tidy HTML. Do it before any further code change — this is the
+   row-set whose failure is silent. Include **C7 (drop)**, the row CKEditor has been covering
+   invisibly.
+3. **Handler-accumulation repro** (§4.10): drive `refreshCanvasElementEditing` repeatedly and watch
+   for duplicate `document` keydown handlers via CDP `DOMDebugger.getEventListeners`; F6 is the
+   likeliest visible symptom. File its own card if it reproduces. Add the X4 listener-leak test either
+   way — it should fail before any fix.
+4. **Page-reload timing baseline** (§4.11) with the performance-log feature.
+
+Then: open the Stage 0 PR via `preflight`.
+
+Note: launching Bloom uses `./go.sh`. If it fails with missing types like `PodcastUtilities` or
+`IDevice` (CS0246), this worktree lacks its C# dependencies — run `./init.sh` (see `AGENTS.md`).
+
+Later, not Stage 0:
+- Before designing `clipboard.ts`, read PR #8140 and `origin/BL-16459-clipboard-failure-reporting`.
+- Optional, offered but not done: comment on **BL-13502** that undo is another reason to want
+  save/reload decoupled.
+
+### 2026-08-05 (later still) — Stage 0 preflighted; PR #8153 open as draft
+
+**PR:** https://github.com/BloomBooks/BloomDesktop/pull/8153 (draft). Branch pushed, card linked,
+QA test-ideas comment posted, Devin consultation logged.
+
+Reviewer outcomes at HEAD `178269d78`:
+
+| Reviewer | Outcome |
+| --- | --- |
+| Local review (light, 1 subagent) | Clean — no correctness problems. It mutation-tested the new spec (neutering `selectAtOffset` fails 9 of 10 tests) and raised one accuracy note, which was fixed. |
+| Devin | **Re-review clean** — 0 bugs, 0 investigate flags, 8 informational. Three informational items acted on; the rest declined with reasons, recorded in the PR consultation log. |
+| CI (`pr-automation`) | pass |
+| CodeRabbit | see the run's final report |
+
+**Three things Devin's informational tier caught that were worth fixing** — a reminder that the
+lowest-signal tier is not always noise:
+
+1. The committed harness hard-coded `repoRoot = "C:/github/BloomDesktop"`, so it only ran in the
+   checkout it was written in. Now derived from `import.meta.url`.
+2. **The extraction has two deliberate behaviour differences, not one.**
+   `restoreSelectionAfterMarkup` re-reads the editor and no-ops if it has gone, where the old code
+   sat inside `if (ckeditorOfThisBox)` and would have thrown. Unreachable in practice
+   (`bloomCkEditor` is assigned once and never cleared) but real, and now documented on the
+   function. Notable because this branch already corrects two *other* comments in the same pipeline
+   that misled by overstating — a third would have been poor form.
+3. The inventory pointed at `PASTE-DROP-BASELINE.md` as if it existed.
+
+**G3 (longpress) is now verified too** — John spot-checked it manually and reports it basically
+works. So of the G rows, G1 and G3 are verified, and **G2 (async markup path / BL-10133) is the one
+still open**, along with the new G6/G7 highlight rows.
diff --git a/docs/retire-ckeditor/REVIEW-NOTES.md b/docs/retire-ckeditor/REVIEW-NOTES.md
new file mode 100644
index 000000000000..b98f191c858e
--- /dev/null
+++ b/docs/retire-ckeditor/REVIEW-NOTES.md
@@ -0,0 +1,98 @@
+# Review notes on the CKEditor-retirement plan
+
+Round 1 review by Fable (Claude), 2026-08-04, against the first draft of [PLAN.md](PLAN.md).
+Every finding below was independently verified against the source before being accepted or
+rejected. This file exists so a later session knows *why* the plan says what it says, and
+doesn't re-litigate settled points.
+
+## Accepted — factual corrections to the draft
+
+| Finding | Verification | Where it landed |
+| --- | --- | --- |
+| The draft said `Equation-style` / ArithmeticTemplate boxes get no editor. They **do**: `utils/shared.ts:16-19` includes `.Equation-style[contenteditable='true']` in `ckeditableSelector`, added for that template. The real no-editor case is `attachToCkEditor`'s `cursor: not-allowed` early return (`bloomEditing.ts:1952`). The comment at `toolbox.ts:1530-1537` claiming otherwise is stale. | Confirmed in `shared.ts` | §2 "dead or misleading code", Stage 0 inventory |
+| The draft called the toolbox undo "reader-setup changes". It is really a **per-editable text-typing** undo: `{html, text, caretOffset}` seeded on focus (`readerToolsModel.ts:557-568`) and pushed inside `doMarkup` (:753-764), gated on `shouldHandleUndo()` (:570). | Confirmed by reading both ranges | §3 table |
+| Consequently `handleUndo` consulting toolbox **before** CKEditor is deliberate, not arbitrary — when a reader tool is active it must shadow CKEditor's undo, which would restore stale markup. | Follows from the above | §3, Stage 1 rationale |
+| Origami's undo is a jQuery `clone(true)` — DOM *plus handlers and data* — not an innerHTML snapshot, and it is safe partly because layout mode strips `contentEditable` (`origami.ts:132`). So it is not a drop-in precedent for innerHTML restore. | Confirmed at `origami.ts:262-294`, :132 | §3 table, Risk 2, Stage 4 |
+| `deleteCanvasElement`'s background-image branch already records an image undo (`CanvasElementManager.ts:2755-2770`), so wrapping the delete would double-record. | Confirmed | §4.8, Stage 2b |
+| Support-file cleanup runs only from `Book.BringBookUpToDate` (`Book.cs:1112`) and publish/upload paths (`BookStorage.cs:2623-2632`), **not** on page save — so the audio-file risk is much smaller than the draft assumed. | Confirmed by tracing `CleanupUnusedSupportFiles` call sites | Risk 7 (downgraded and scoped) |
+| The cross-frame export is `getWorkspaceBundleExports`, not `getWorkspaceExports`. | Confirmed (`origami.ts:204`) | §4.2 |
+| `ISelectionAnchor` keyed on `editableId` won't work: ordinary `.bloom-editable` divs have no `id` (only talking-book assigns them, `audioRecording.ts:1380, 3681`). | Confirmed | §4.3 — structural locator instead |
+| The draft overstated the existing selection machinery. `makeSelectionIn` is the *consume* side; `getElementSelectionIndex` returns only an offset and in-tree callers pass `divBrCount = -1`. The capture side is new code. | Confirmed (`editableDivUtils.ts:30-46`, `readerToolsModel.ts:587-592`) | §4.3 |
+
+## Accepted — design changes
+
+1. **Undo entries must be data, not closures.** The page iframe's JS context dies on same-page
+   reloads too (ctrl+wheel zoom `bloomEditing.ts:1268`, origami exit `origami.ts:193`), so
+   page-id-scoped clearing alone leaves entries closing over a dead document. Snapshot entries
+   are now pure data interpreted at undo time; closures are permitted only for workspace-owned
+   operations; clearing also keys on page-frame unload/load. → §4.1
+2. **Native browser undo must be actively fenced.** Plain typing feeds Chromium's undo stack and
+   Ctrl+Z inside an editable triggers it; today CKEditor intercepts that. The new editor must
+   `preventDefault()` on `beforeinput` with `inputType` `historyUndo`/`historyRedo`. This is
+   also the replacement for `BloomField.PreventRemovalOfSomeElements`'s `execCommand("undo")`
+   (`BloomField.ts:810-825`) — block the deletion rather than undoing it. → §4.4, Risk 3
+3. **Re-cut Stages 1–2.** The draft spent Stage 1 converting three mechanisms that already work
+   (delivering nothing the user asked for) while forcing in-place snapshot restore to mature on a
+   page full of live CKEditor instances. The decisive detail: restoring innerHTML orphans
+   `div.bloomCkEditor` (`BloomField.ts:419`), and because `doCkEditorCleanup` iterates that
+   expando (`editableDivUtils.ts:350`) and `getBodyContentForSavePage` calls it
+   (`bloomEditing.ts:1483`), the **save path would silently skip cleanup** for restored divs.
+   So: Stage 1 now wraps all four mechanisms as legacy providers with no conversions; delete-page
+   and delete-canvas-element move to Stage 2; `PageSnapshot` lands in Stage 3; conversions become
+   optional Stage 4 cleanups.
+4. **Delete canvas element uses an inverse-op / narrow subtree, not a page snapshot**, reusing
+   the existing `refreshCanvasElementEditing` path. Two things flagged to verify first: Comical
+   bubble-family re-linking, and restoring a drag-activity target. → Stage 2b
+5. **`runUndoable` needs nesting semantics from day one** (depth counter, outermost wins). → §4.8
+6. **Delete-page capture must happen inside the `SaveThen` callback** (`EditingModel.cs:590-624`),
+   and restore must re-raise `_pageListChangedEvent` / `InvokeContentsChanged` and navigate, not
+   just renumber. The front-end entry is pushed by C#, since the page frame is being torn down.
+   → Stage 2a
+7. **The toolbox keystroke pipeline is the one place "one-line dispatch" fails**
+   (`toolbox.ts:1509-1607`, ~100 lines of the app's most delicate code). Added a mechanical
+   behaviour-preserving prep commit in Stage 0 that extracts the save/restore-selection bracket,
+   so the eventual change swaps a function body. → §5.4
+8. **The flag is a `localStorage` dev switch.** A URL parameter is not zero-touch: the page
+   iframe's `src` comes from C# via `switchContentPage`. → §5.5
+9. **`canUndo()` must stay synchronous and O(1)** — C# polls it on a timer with a reentrancy
+   guard (`WebView2Browser.cs:963-996`); expensive work there makes the button flicker. → §4.1
+
+## Accepted — missed dependencies now in scope
+
+- `WireToCKEditor` services the draft omitted: the BL-13779 `change`-event `data-user-deleted`
+  tracking (`BloomField.ts:244-252`); BL-11745 qtip z-order juggling on focus/blur (:345-366);
+  `selectionChange` → `EnsureCaretNotInsideLineBreakSpan` (:259-261); the SetupLink hyperlink
+  command and button (:368-415). → §2 table rows 8–11, Stage 3 `BloomTextEditor.ts` /
+  `FormatToolbar.tsx`
+- **BL-12357 small caps cannot be ported unchanged.** `restoreHtmlMarkupIfNecessary`
+  (`BloomField.ts:425-456`) detects CKEditor-internal copies via `dataTransfer.getData("cke/id")`
+  and compensates for CKEditor's own span-stripping. With CKEditor gone, nothing stamps `cke/id`
+  and nothing strips the spans, so the transform is meaningless as written and the problem may
+  vanish. Verify against the repro. → Stage 3
+- **The second paste path**: `pasteImpl`'s replace-whole-content branch for a canvas element that
+  is selected but not being text-edited (`bloomEditing.ts:1792-1842`), plus the C#-initiated
+  `pasteClipboard` entry point as distinct from the DOM `paste` event. → Stage 3 `pasteHandler.ts`
+- **jsdom cannot test the `beforeinput` layer** — no native editing behaviour, no
+  `getTargetRanges()`. `typingTransactions.ts` and `keyCommands.ts` need the live-WebView2 CDP
+  harness. → §7
+- `readerSetup.ui.ts:454`'s `execCommand` is in the reader-setup dialog, not the page frame —
+  scoped out. → Stage 3 `keyCommands.ts`
+
+## Accepted — cuts
+
+- **Stage 1c (convert reader-tools undo) deleted.** It is a text-typing undo, so converting it
+  would require typing transactions to exist first — out of order. It becomes a legacy provider
+  and is deleted in Stage 4/5 when shared-stack snapshots subsume it.
+- **Byte-budget accounting on the stack** — dropped; a count cap (~50) suffices.
+- **`ISelectionAnchor.focusOffset` / range support** — deferred; every identified consumer needs
+  only a caret. Added the reviewer's neat alternative for the snapshot case: inject a caret
+  marker into the captured HTML *string*, which has none of the bookmark-span downsides.
+- **Open question "delete-page depth"** — answered in the plan rather than asked: keep every
+  deletion in the session, capped ~10.
+
+## Confirmed as already correct
+
+The Stage 0 behaviour inventory (which would itself have caught the `Equation-style` error), the
+dev harness page, doing `inlineFormat` first, consolidating the C# scrubbers into
+`LegacyCkEditorCleanup` rather than deleting them, and keeping Stage 6 as a separately-reviewed
+pass.
diff --git a/docs/retire-ckeditor/verifyCaretPreservation.mjs b/docs/retire-ckeditor/verifyCaretPreservation.mjs
new file mode 100644
index 000000000000..732e67d3f368
--- /dev/null
+++ b/docs/retire-ckeditor/verifyCaretPreservation.mjs
@@ -0,0 +1,183 @@
+// BL-6681 Stage 0 live-verification harness: does the caret survive the markup pipeline?
+// Inventory rows G1/G2 (docs/retire-ckeditor/BEHAVIOR-INVENTORY.md).
+//
+// USAGE (needs a running Bloom on the Edit tab with a text box on the current page):
+//   node .github/skills/bloom-automation/launcherControl.mjs --ensure-running --wait-ready --json
+//   node docs/retire-ckeditor/verifyCaretPreservation.mjs <cdpPort>
+//
+// WHAT IT COVERS. In toolbox.ts's handleKeyboardInput, the
+// saveSelectionForMarkup / restoreSelectionAfterMarkup bracket runs on EVERY keystroke in an
+// editable (after the 500ms debounce), regardless of whether a tool is active — the tool check
+// only gates the updateMarkup call between them. So typing mid-word and checking the caret
+// afterwards exercises the wiring of the seam extracted in commit 2707d98a8, and confirms the
+// bookmark spans are consumed rather than left in the DOM.
+//
+// WHAT IT DOES *NOT* COVER, and how to extend it. With no tool active, updateMarkup never runs,
+// so the DOM is unchanged between save and restore — which is the easy half. The case bookmarks
+// actually exist for is markup rewriting the DOM around the caret. To reach it you need a book
+// whose toolbox offers a reader tool: a **Decodable Reader** or **Leveled Reader** book, not a
+// Basic Book. In a Basic Book the toolbox offers only Talking Book and "More...", both of which
+// stayed invisible even after toggling #pure-toggle-right, and no audio-sentence spans appeared,
+// so updateMarkup did not run. Also remember toolbox.toolboxIsShowing() gates markup, so the
+// toolbox pane has to be genuinely open, not merely toggled.
+import { createRequire } from "node:module";
+import path from "node:path";
+import url from "node:url";
+
+// Derive the repo root from this file's own location (docs/retire-ckeditor/), so the harness works
+// from any checkout or worktree rather than only the one it was written in.
+const repoRoot = path.resolve(
+    path.dirname(url.fileURLToPath(import.meta.url)),
+    "../..",
+);
+const ctDir = path.join(
+    repoRoot,
+    "src/BloomBrowserUI/react_components/component-tester",
+);
+const req = createRequire(path.join(ctDir, "package.json"));
+const { chromium } = req("playwright");
+
+const cdpPort = process.argv[2] || "8091";
+const browser = await chromium.connectOverCDP(`http://localhost:${cdpPort}`);
+
+const mainPage = (() => {
+    for (const c of browser.contexts())
+        for (const p of c.pages())
+            if (
+                p.url().includes("/bloom/") &&
+                !p.url().includes("toolboxcontent")
+            )
+                return p;
+    return undefined;
+})();
+if (!mainPage) throw new Error("no Bloom main page");
+
+const pageFrame = mainPage.frames().find((f) => f.name() === "page");
+if (!pageFrame) {
+    console.log(
+        "FRAMES:",
+        mainPage.frames().map((f) => `${f.name()}|${f.url().slice(0, 80)}`),
+    );
+    throw new Error("no 'page' frame");
+}
+console.log("page frame url:", pageFrame.url().slice(0, 90));
+
+// Pick the first visible bloom-editable we can type into.
+const info = await pageFrame.evaluate(() => {
+    const eds = Array.from(
+        document.querySelectorAll(
+            ".bloom-editable.bloom-visibility-code-on[contenteditable='true']",
+        ),
+    );
+    return eds.map((e, i) => ({
+        i,
+        lang: e.getAttribute("lang"),
+        cls: (e.className || "")
+            .split(" ")
+            .filter((c) => c.startsWith("bloom-content"))
+            .join(","),
+        text: (e.textContent || "").trim().slice(0, 40),
+        hasCkEditor: !!e.bloomCkEditor,
+    }));
+});
+console.log("editables:", JSON.stringify(info, null, 1));
+
+const target = info.find((e) => e.hasCkEditor);
+if (!target) {
+    console.log(
+        "RESULT: no editable has a CKEditor attached — cannot exercise the pipeline here",
+    );
+    await browser.close();
+    process.exit(3);
+}
+console.log(`using editable index ${target.i} (lang=${target.lang})`);
+
+const sel = `.bloom-editable.bloom-visibility-code-on[contenteditable='true']`;
+
+// --- Step 1: put a known word in the box -------------------------------------------------
+await pageFrame.evaluate(
+    ({ s, idx }) => {
+        const ed = document.querySelectorAll(s)[idx];
+        const p =
+            ed.querySelector("p") ||
+            ed.appendChild(document.createElement("p"));
+        p.textContent = "house";
+    },
+    { s: sel, idx: target.i },
+);
+await mainPage.waitForTimeout(300);
+
+// --- Step 2: click in, then place the caret between "hous" and "e" (offset 4) ------------
+await pageFrame.locator(sel).nth(target.i).click();
+await mainPage.waitForTimeout(400);
+
+const placed = await pageFrame.evaluate(
+    ({ s, idx }) => {
+        const ed = document.querySelectorAll(s)[idx];
+        const textNode = ed.querySelector("p").firstChild;
+        const r = document.createRange();
+        r.setStart(textNode, 4);
+        r.setEnd(textNode, 4);
+        const g = window.getSelection();
+        g.removeAllRanges();
+        g.addRange(r);
+        return { text: ed.textContent, anchorOffset: g.anchorOffset };
+    },
+    { s: sel, idx: target.i },
+);
+console.log("caret placed:", JSON.stringify(placed));
+if (placed.anchorOffset !== 4) {
+    console.log("RESULT: FAILED SETUP — could not place caret at offset 4");
+    await browser.close();
+    process.exit(4);
+}
+
+// --- Step 3: type a character mid-word, then wait out the 500ms markup debounce ----------
+await mainPage.keyboard.type("z");
+console.log("typed 'z' at offset 4; waiting 1500ms for the markup pass...");
+await mainPage.waitForTimeout(1500);
+
+// --- Step 4: observe where the caret ended up and what the text is -----------------------
+const after = await pageFrame.evaluate(
+    ({ s, idx }) => {
+        const ed = document.querySelectorAll(s)[idx];
+        const g = window.getSelection();
+        // Character offset of the caret within the editable, counting text only.
+        let offset = -1;
+        if (g && g.anchorNode && ed.contains(g.anchorNode)) {
+            const r = g.getRangeAt(0).cloneRange();
+            r.setStart(ed, 0);
+            offset = r.toString().length;
+        }
+        return {
+            text: ed.textContent,
+            html: ed.innerHTML,
+            caretCharOffset: offset,
+            anchorIsInsideEditable: !!(
+                g &&
+                g.anchorNode &&
+                ed.contains(g.anchorNode)
+            ),
+            leftoverBookmarkSpans:
+                ed.querySelectorAll("[id^='cke_bm_']").length,
+            zeroWidthSpaces: (ed.innerHTML.match(/\u200B/g) || []).length,
+        };
+    },
+    { s: sel, idx: target.i },
+);
+console.log("AFTER:", JSON.stringify(after, null, 1));
+
+// Caret at offset 4 in "house" sits between "hous" and "e", so typing "z" gives "housze"
+// and the caret should end up at offset 5, immediately after the character just typed.
+const pass =
+    after.text === "housze" &&
+    after.caretCharOffset === 5 &&
+    after.leftoverBookmarkSpans === 0 &&
+    after.zeroWidthSpaces === 0;
+console.log(
+    pass
+        ? "RESULT: PASS — text 'housze', caret at offset 5, no leftover bookmark spans, no ZWSP"
+        : `RESULT: FAIL — expected text 'housze' caret 5 bookmarks 0 zwsp 0; got text '${after.text}' caret ${after.caretCharOffset} bookmarks ${after.leftoverBookmarkSpans} zwsp ${after.zeroWidthSpaces}`,
+);
+
+await browser.close();
diff --git a/src/BloomBrowserUI/bookEdit/js/editableDivUtilsSelectionSpec.ts b/src/BloomBrowserUI/bookEdit/js/editableDivUtilsSelectionSpec.ts
new file mode 100644
index 000000000000..f4528e717f65
--- /dev/null
+++ b/src/BloomBrowserUI/bookEdit/js/editableDivUtilsSelectionSpec.ts
@@ -0,0 +1,216 @@
+import { describe, it, expect, beforeEach, afterAll } from "vitest";
+import { EditableDivUtils } from "./editableDivUtils";
+
+// CHARACTERIZATION TESTS — see docs/retire-ckeditor/BEHAVIOR-INVENTORY.md rows G4/G5.
+//
+// These pin the behaviour of EditableDivUtils.makeSelectionIn / getElementSelectionIndex, which
+// predate CKEditor and which the CKEditor-retirement project intends to build its bookmark-free
+// selection anchors on (PLAN.md 4.3). They are pinned *before* that work starts because:
+//
+//  - makeSelectionIn's `divBrCount` parameter has no in-tree caller that passes anything but -1
+//    (readerToolsModel.ts and toolbox.ts both pass -1), so the <br>-stepping behaviour the new
+//    anchors will depend on is currently exercised by nothing at all; and
+//  - getElementSelectionIndex only ever produces a plain character offset, so the round-trip these
+//    tests establish is the contract the new capture side has to preserve.
+//
+// NOTE on the harness: both functions hard-code `parent.window.document.getElementById("page")` and
+// operate on that iframe's window, because in the real app the edited page lives in an iframe with
+// that id. So these tests must build such an iframe rather than using the ambient document. That
+// hard-coding is itself worth recording: the replacement selection API should take a document/root
+// instead, which is both testable and reusable outside the page frame.
+
+let pageIframe: HTMLIFrameElement;
+
+/** The document inside our stand-in for the app's page iframe. */
+function pageDoc(): Document {
+    return pageIframe.contentWindow!.document;
+}
+
+/**
+ * Put the given HTML inside a .bloom-editable in the page iframe and return that div.
+ * Returns the div from the *iframe's* document, so ranges built on it are valid there.
+ */
+function makeEditable(innerHtml: string): HTMLElement {
+    const doc = pageDoc();
+    doc.body.innerHTML = `<div class="bloom-editable" contenteditable="true">${innerHtml}</div>`;
+    const div = doc.body.firstElementChild as HTMLElement;
+    if (!div || !div.classList.contains("bloom-editable")) {
+        throw new Error(
+            "Test setup failed: could not create the .bloom-editable in the page iframe",
+        );
+    }
+    return div;
+}
+
+/** Where the selection actually ended up, as (nodeText, offset), for asserting precisely. */
+function currentSelection(): { text: string | null; offset: number } | null {
+    const sel = pageIframe.contentWindow!.getSelection();
+    if (!sel || !sel.anchorNode) return null;
+    return { text: sel.anchorNode.textContent, offset: sel.anchorOffset };
+}
+
+describe("EditableDivUtils selection round-trip (characterization)", () => {
+    beforeEach(() => {
+        // A fresh iframe per test: a stale selection in a reused document is a classic source of
+        // tests that pass only in a particular order.
+        document.getElementById("page")?.remove();
+        pageIframe = document.createElement("iframe");
+        pageIframe.id = "page";
+        document.body.appendChild(pageIframe);
+
+        // Sanity-check the harness itself before any test relies on it. Without this, a jsdom
+        // limitation would show up as a confusing assertion failure inside the function under test.
+        if (!pageIframe.contentWindow) {
+            throw new Error(
+                "Test setup failed: the #page iframe has no contentWindow",
+            );
+        }
+        if (typeof pageIframe.contentWindow.getSelection !== "function") {
+            throw new Error(
+                "Test setup failed: this DOM implementation has no getSelection() in the iframe",
+            );
+        }
+    });
+
+    afterAll(() => {
+        document.getElementById("page")?.remove();
+    });
+
+    it("makeSelectionIn puts the caret at the requested character offset in a simple paragraph", () => {
+        const div = makeEditable("<p>Hello world</p>");
+        const para = div.firstElementChild as HTMLElement;
+        expect(para.textContent).toBe("Hello world"); // sanity check the fixture
+
+        const made = EditableDivUtils.makeSelectionIn(para, 5, -1, true);
+
+        expect(made).toBe(true);
+        const sel = currentSelection();
+        expect(sel).not.toBeNull();
+        // It should have drilled down to the text node, not stopped at the paragraph.
+        expect(sel!.text).toBe("Hello world");
+        expect(sel!.offset).toBe(5);
+    });
+
+    it("getElementSelectionIndex reads back the offset that makeSelectionIn set", () => {
+        const div = makeEditable("<p>Hello world</p>");
+        const para = div.firstElementChild as HTMLElement;
+
+        // Sanity check: with no selection in the div yet, the index must not already be what we
+        // are about to assert, or the test would pass without makeSelectionIn doing anything.
+        expect(EditableDivUtils.getElementSelectionIndex(div)).not.toBe(7);
+
+        EditableDivUtils.makeSelectionIn(para, 7, -1, true);
+
+        expect(EditableDivUtils.getElementSelectionIndex(div)).toBe(7);
+    });
+
+    it("getElementSelectionIndex counts characters across inline markup, ignoring the tags", () => {
+        // This is the property that makes an offset-based anchor better than a DOM bookmark:
+        // the offset is over the *text*, so wrapping spans don't shift it.
+        const div = makeEditable("<p>abc<strong>def</strong>ghi</p>");
+        const para = div.firstElementChild as HTMLElement;
+        expect(para.textContent).toBe("abcdefghi"); // sanity check
+
+        EditableDivUtils.makeSelectionIn(para, 5, -1, true);
+
+        // Offset 5 is inside the <strong>; the index is still counted over the whole text.
+        expect(EditableDivUtils.getElementSelectionIndex(div)).toBe(5);
+    });
+
+    it("makeSelectionIn returns false when there is no text node to land in", () => {
+        const div = makeEditable("<p></p>");
+        const para = div.firstElementChild as HTMLElement;
+        expect(para.textContent).toBe(""); // sanity check
+
+        expect(EditableDivUtils.makeSelectionIn(para, 0, -1, true)).toBe(false);
+    });
+
+    describe("divBrCount — the <br>-stepping nothing in the app currently exercises", () => {
+        it("with divBrCount 0, the caret lands in the container before the following node", () => {
+            // Note this is the documented meaning: when offset equals the length of a child, and
+            // divBrCount >= 0, the caret goes in `node` itself at a child index rather than
+            // drilling into a text node.
+            const div = makeEditable("<p>ab<br>cd</p>");
+            const para = div.firstElementChild as HTMLElement;
+            expect(para.childNodes.length).toBe(3); // text, br, text — sanity check
+
+            const made = EditableDivUtils.makeSelectionIn(para, 2, 0, true);
+
+            expect(made).toBe(true);
+            const sel = currentSelection();
+            expect(sel).not.toBeNull();
+            // The anchor is the paragraph itself, positioned by child index.
+            expect(sel!.text).toBe("abcd");
+            expect(sel!.offset).toBe(1);
+        });
+
+        it("with divBrCount 1, the caret steps past one <br>", () => {
+            const div = makeEditable("<p>ab<br>cd</p>");
+            const para = div.firstElementChild as HTMLElement;
+
+            const made = EditableDivUtils.makeSelectionIn(para, 2, 1, true);
+
+            expect(made).toBe(true);
+            const sel = currentSelection();
+            expect(sel).not.toBeNull();
+            expect(sel!.text).toBe("abcd");
+            // Stepped over the <br>, so one child index further along than the divBrCount 0 case.
+            expect(sel!.offset).toBe(2);
+        });
+
+        it("with divBrCount 2 but only one <br> present, it stops at the <br> it has", () => {
+            // Pins the "ask for more <br>s than exist" case, which a restored anchor can hit if the
+            // DOM changed between capture and restore.
+            const div = makeEditable("<p>ab<br>cd</p>");
+            const para = div.firstElementChild as HTMLElement;
+
+            const made = EditableDivUtils.makeSelectionIn(para, 2, 2, true);
+
+            expect(made).toBe(true);
+            const sel = currentSelection();
+            expect(sel).not.toBeNull();
+            expect(sel!.offset).toBe(2);
+        });
+
+        it("divBrCount is ignored when the offset is not at a child boundary", () => {
+            const div = makeEditable("<p>ab<br>cd</p>");
+            const para = div.firstElementChild as HTMLElement;
+
+            EditableDivUtils.makeSelectionIn(para, 1, 1, true);
+
+            const sel = currentSelection();
+            expect(sel).not.toBeNull();
+            // Landed inside the first text node, so it drilled down and ignored the <br> request.
+            expect(sel!.text).toBe("ab");
+            expect(sel!.offset).toBe(1);
+        });
+    });
+
+    describe("atStart — which side of a node boundary the caret prefers", () => {
+        it("atStart true puts the caret at the start of the following node", () => {
+            const div = makeEditable("<p><em>ab</em><strong>cd</strong></p>");
+            const para = div.firstElementChild as HTMLElement;
+            expect(para.textContent).toBe("abcd"); // sanity check
+
+            EditableDivUtils.makeSelectionIn(para, 2, -1, true);
+
+            const sel = currentSelection();
+            expect(sel).not.toBeNull();
+            // Offset 2 is the boundary; atStart true prefers the *following* node's text.
+            expect(sel!.text).toBe("cd");
+            expect(sel!.offset).toBe(0);
+        });
+
+        it("atStart false puts the caret at the end of the preceding node", () => {
+            const div = makeEditable("<p><em>ab</em><strong>cd</strong></p>");
+            const para = div.firstElementChild as HTMLElement;
+
+            EditableDivUtils.makeSelectionIn(para, 2, -1, false);
+
+            const sel = currentSelection();
+            expect(sel).not.toBeNull();
+            expect(sel!.text).toBe("ab");
+            expect(sel!.offset).toBe(2);
+        });
+    });
+});
diff --git a/src/BloomBrowserUI/bookEdit/toolbox/markupSelectionPreservation.ts b/src/BloomBrowserUI/bookEdit/toolbox/markupSelectionPreservation.ts
new file mode 100644
index 000000000000..b02ad105902c
--- /dev/null
+++ b/src/BloomBrowserUI/bookEdit/toolbox/markupSelectionPreservation.ts
@@ -0,0 +1,119 @@
+/// <reference path="../../typings/ckeditor/ckeditor.d.ts" />
+
+// Preserving the user's caret while a tool rewrites the markup around it.
+//
+// This module exists to give that job a seam. It is deliberately a *pure extraction* of what
+// toolbox.ts's keystroke pipeline (handleKeyboardInput) has always done, with no behaviour change,
+// so that the CKEditor-retirement project (BL-6681) can swap the implementation without operating
+// on the most delicate code in the app. See docs/retire-ckeditor/PLAN.md 4.3 and 5.4, and inventory
+// rows G1-G5.
+//
+// TODAY'S IMPLEMENTATION uses CKEditor "bookmarks": a dummy span is inserted at the caret, and
+// selecting the bookmark later both restores the caret and removes the span. That has a known cost,
+// documented at the call site for years: while the span is in the DOM the markup routine sees it as
+// a word break, so fixing a letter mid-word makes the reader tools briefly mis-analyse the word
+// ("hous"-bookmark-"e"). It is corrected when the user clicks away.
+//
+// THE PLANNED IMPLEMENTATION records the caret as a character offset into the editable's text
+// instead, which perturbs nothing and therefore fixes that mis-analysis rather than preserving it.
+// When that lands, only the four functions below change; toolbox.ts should not need to.
+
+/**
+ * An opaque record of where the caret was. Callers must not inspect it — that is the whole point
+ * of the seam. Today it holds CKEditor bookmark objects.
+ */
+export interface SavedMarkupSelection {
+    // Deliberately unknown[]: callers must treat this as opaque, and the planned replacement stores
+    // something quite different (a character offset, not DOM markers).
+    bookmarks: unknown[];
+}
+
+/** The editor object CKEditor attaches to each editable div, if it attached one. */
+function getEditorOfBox(editableDiv: HTMLElement): CKEDITOR.editor | undefined {
+    return (editableDiv as HTMLElement & { bloomCkEditor?: CKEDITOR.editor })
+        .bloomCkEditor;
+}
+
+/**
+ * Whether this box participates in markup at all.
+ *
+ * Normally every editable box has a rich-text editor attached, so this is true. Boxes without one
+ * are treated as not needing markup: the caller skips the whole update for them.
+ *
+ * (The comment this replaced claimed such boxes are the ArithmeticTemplate number boxes, "because
+ * the logic that invokes WireToCKEditor is looking for classes like bloom-content1 that are not
+ * present in ArithmeticTemplate". That explanation is wrong: ckeditableSelector in utils/shared.ts
+ * explicitly includes .Equation-style, added for that very template. The real case of a box with no
+ * editor is one whose computed cursor is `not-allowed`, which attachToCkEditor skips. Behaviour is
+ * unchanged either way; only the explanation is corrected.)
+ */
+export function boxParticipatesInMarkup(editableDiv: HTMLElement): boolean {
+    return !!getEditorOfBox(editableDiv);
+}
+
+/**
+ * Remember where the caret is, before the markup is rewritten.
+ *
+ * Returns undefined if the caret could not be recorded, which today means the editor reported no
+ * selection — the caller should abandon this markup pass entirely (we may be changing pages).
+ *
+ * Only call this when boxParticipatesInMarkup() is true.
+ */
+export function saveSelectionForMarkup(
+    editableDiv: HTMLElement,
+): SavedMarkupSelection | undefined {
+    const editor = getEditorOfBox(editableDiv);
+    if (!editor) {
+        return undefined;
+    }
+    const selection = editor.getSelection();
+    if (!selection) {
+        return undefined; // may be changing pages?
+    }
+    // There is also createBookmarks2(), which avoids actually inserting anything. That has the
+    // advantage that changing a character in the middle of a word would let the whole word be
+    // evaluated by the markup routine. However, testing showed that the cursor then doesn't
+    // actually go back to where it was: it gets shifted to the right.
+    return { bookmarks: selection.createBookmarks(true) };
+}
+
+/**
+ * Put the caret back where saveSelectionForMarkup() found it.
+ *
+ * Note that with today's implementation this also removes the marker spans from the DOM, so it must
+ * be called exactly once per save, and the saved value must not be reused afterwards.
+ *
+ * Behaviour note: this re-reads the editor and no-ops if it has gone, whereas the pre-extraction
+ * code sat inside `if (ckeditorOfThisBox)` and so would have thrown. Unreachable in practice —
+ * `bloomCkEditor` is assigned once per div (BloomField.WireToCKEditor) and never cleared — but the
+ * difference is real, so it is written down rather than left to be rediscovered.
+ */
+export function restoreSelectionAfterMarkup(
+    editableDiv: HTMLElement,
+    saved: SavedMarkupSelection,
+): void {
+    const editor = getEditorOfBox(editableDiv);
+    if (!editor) {
+        return;
+    }
+    editor.getSelection().selectBookmarks(saved.bookmarks);
+}
+
+/**
+ * Restore the caret and immediately record it again, returning the new record.
+ *
+ * Needed only on the asynchronous-markup path. There, the rest of the update happens after an
+ * await, which may be after the next keystroke has been processed; if we left fixing the selection
+ * until then, the caret would be briefly visible in the wrong place and — much worse — intervening
+ * keystrokes would go to that wrong position (BL-10133). So the caret is put right immediately, and
+ * recorded afresh for the restore that follows the actual markup change.
+ *
+ * Returns undefined under the same conditions as saveSelectionForMarkup().
+ */
+export function restoreAndResaveSelectionForMarkup(
+    editableDiv: HTMLElement,
+    saved: SavedMarkupSelection,
+): SavedMarkupSelection | undefined {
+    restoreSelectionAfterMarkup(editableDiv, saved);
+    return saveSelectionForMarkup(editableDiv);
+}
diff --git a/src/BloomBrowserUI/bookEdit/toolbox/toolbox.ts b/src/BloomBrowserUI/bookEdit/toolbox/toolbox.ts
index 72281f5f7f91..38cbe5e7b9d5 100644
--- a/src/BloomBrowserUI/bookEdit/toolbox/toolbox.ts
+++ b/src/BloomBrowserUI/bookEdit/toolbox/toolbox.ts
@@ -14,6 +14,12 @@ import {
     getPageIframeBody,
 } from "../../utils/shared";
 import { GameTool } from "./games/GameTool";
+import {
+    boxParticipatesInMarkup,
+    restoreAndResaveSelectionForMarkup,
+    restoreSelectionAfterMarkup,
+    saveSelectionForMarkup,
+} from "./markupSelectionPreservation";
 import { isLongPressEvaluating } from "../longPressShared";
 import { getFeatureStatusAsync } from "../../react_components/featureStatus";
 import { showRequiresSubscriptionDialogInAnyView } from "../../react_components/requiresSubscription";
@@ -1507,18 +1513,10 @@ function handlePageEditing(
             return;
         }
 
-        // the hard thing about all this is preserving the user's insertion point while we change the actual
-        // html out from under them to add/remove markup.
-        // ckeditor specific discussion: http://stackoverflow.com/questions/16835365/set-cursor-to-specific-position-in-ckeditor
-        // This "bookmark" approach makes that easy:
-        // We insert a dummy element where the insert point is. Later when we do the markup,
-        // we'll find the bookmark again, put the selection there, and remove this element.
-        // The problem with this approach is that when the user is fixing an existing word, the markup
-        // will see our bookmark as a word-breaking element. For example, if I type "houze" and go
-        // to fix that z, the markup routine is going to see "hous"-bookmark-"e". When the user
-        // clicks away, the markup will be redone and fixed. So this is a known tradeoff; we get
-        // more reliable insertion-point-preservation, at the cost of some temporarily inaccurate
-        // markup.
+        // The hard thing about all this is preserving the user's insertion point while we change the
+        // actual html out from under them to add/remove markup. That job — and the known tradeoff
+        // in how it is currently done — now lives in markupSelectionPreservation.ts, so that it can
+        // be reimplemented without touching this pipeline. See BL-6681.
         const selNode = selection ? selection.anchorNode : null;
         const editableDiv = selNode
             ? $(selNode).parents(".bloom-editable")[0]
@@ -1526,25 +1524,14 @@ function handlePageEditing(
         // In 3.9, this is null when you press backspace in an empty box; the selection.anchorNode is itself a .bloom-editable, so
         // presumably we could adjust the above query to still get the div it's looking for.
         if (editableDiv) {
-            const ckeditorOfThisBox = (
-                editableDiv as HTMLElement & { bloomCkEditor?: CKEDITOR.editor }
-            ).bloomCkEditor;
-            // Normally every editable box has a ckeditor attached. But some arithmetic template boxes are
-            // intended to contain numbers not needing translation and don't get one...because the logic
-            // that invokes WireToCKEditor is looking for classes like bloom-content1 that are not present
-            // in ArithmeticTemplate. Here we're presuming that if a block didn't get one attached,
-            // it's not true vernacular text and doesn't need markup. So all the code below is skipped
-            // if we don't have one.
-            if (ckeditorOfThisBox) {
-                let ckeditorSelection = ckeditorOfThisBox.getSelection();
-                if (!ckeditorSelection) {
+            // Normally every editable box has a rich-text editor attached, and so participates in
+            // markup. If a block didn't get one, we presume it isn't true vernacular text and
+            // doesn't need markup, so all the code below is skipped.
+            if (boxParticipatesInMarkup(editableDiv)) {
+                let savedSelection = saveSelectionForMarkup(editableDiv);
+                if (!savedSelection) {
                     return; // may be changing pages?
                 }
-                // there is also createBookmarks2(), which avoids actually inserting anything. That has the
-                // advantage that changing a character in the middle of a word will allow the entire word to
-                // be evaluated by the markup routine. However, testing shows that the cursor then doesn't
-                // actually go back to where it was: it gets shifted to the right.
-                let bookmarks = ckeditorSelection.createBookmarks(true);
 
                 // For some reason, we have cases, mostly (always?) on paste, where
                 // ckeditor is inserting tons of comments which are messing with our parsing
@@ -1569,11 +1556,26 @@ function handlePageEditing(
                         // it now, and then again after actually changing the markup, which might move the selection again.
                         // (This is why we don't allow updateMarkupAsync to modify the DOM, except by means of
                         // the function it returns, which is executed synchronously with fixing the selection.)
-                        ckeditorOfThisBox
-                            .getSelection()
-                            .selectBookmarks(bookmarks);
-                        ckeditorSelection = ckeditorOfThisBox.getSelection();
-                        bookmarks = ckeditorSelection.createBookmarks(true);
+                        const resaved = restoreAndResaveSelectionForMarkup(
+                            editableDiv,
+                            savedSelection,
+                        );
+                        // One of two deliberate differences from the pre-extraction code (the other
+                        // is noted on restoreSelectionAfterMarkup), and it is a narrow one. That
+                        // code did restore-then-re-save here, both steps
+                        // dereferencing getSelection() unguarded. The restore is still unguarded
+                        // (see restoreSelectionAfterMarkup), so a null selection there still throws
+                        // exactly where it used to. What this guard covers is only the case where
+                        // the restore's getSelection() succeeds and the immediately following
+                        // re-save's returns null: previously that threw inside an async function
+                        // nobody awaits, so the pass died half-done -- comments already stripped,
+                        // marker spans possibly left in the DOM -- via an unhandled rejection.
+                        // Abandoning the pass cleanly is the same outcome without the wreckage, and
+                        // is how the first save above has always behaved.
+                        if (!resaved) {
+                            return;
+                        }
+                        savedSelection = resaved;
 
                         const actualUpdateFunc =
                             await activeTool.updateMarkupAsync();
@@ -1620,13 +1622,12 @@ function handlePageEditing(
                     activeTool.updateMarkup();
                 }
 
-                //set the selection to wherever our bookmark node ended up
+                //put the caret back where it was before all of the above
                 //NB: in BL-3900: "Decodable & Talking Book tools delete text after longpress", it was here,
                 //restoring the selection, that we got interference with longpress's replacePreviousLetterWithText(),
                 // in some way that is still not understood. This was fixed by changing all this to trigger on
                 // a different event (keydown instead of keypress).
-                // Note: causing the bookmarks to be selected actually removes the bookmark spans.
-                ckeditorOfThisBox.getSelection().selectBookmarks(bookmarks);
+                restoreSelectionAfterMarkup(editableDiv, savedSelection);
             }
         }
         // clear this value to prevent unnecessary calls to clearTimeout() for timeouts that have already expired.