[zurfyx]

Description

While the editor composes (IME) in a line, a collaborator's insert into that
line is applied to Yjs but held back from the editor (Hidden); a change
applied during a local update is likewise not read until after it (Unread,
#9784). A commit that moved the list item holding that content (down its
list, to another list, nested), made locally or by an app's code in the
update of a remote change's read (#9788), wrote the move as a delete and a
write of the editor's view, which lacks it:

• held or unread content inside a shared node that moved with the line (an
  inline container, a block node holding the line) was deleted with it, on
  every client;
• held or unread text in a moved line stayed at the old place and, once read,
  showed glued to the next line (Rtail).

Now:

• A container write keeps the items of the units (lines, block nodes) and
  inline containers that hold content the editor does not show where they
  match one in the container (Writer#$heldKeys): the moved unit keeps its
  items, and the units it passed are written again instead. Exact: nothing
  hidden is copied, so held formats, held inline nodes and held line markers
  stay as stored, with no duplicate or resurrected delete.
• Units written at a unit boundary next to a kept unit go before a held or
  unread format that opens a run over it (Cursor#heldBoundary), not inside
  that run.
• A commit that moves held content to another container (a line into or out
  of a block node, a block node into another, an inline container to another
  line) cannot keep its items: it is not written, is read again, and reports
  UNSUPPORTED_EDIT_WARNING with a new data.reason, 'composing-move',
  once per refused commit (YBinding#refusesHeldMove, on the local commit
  path and in $writeReadEdits). The move is undone locally and nothing held
  is lost.

Unchanged and out of scope: what a change not read yet inserted into a unit
moved to another container stays under the concurrent move limits (D48, D49);
text composed in a node moved into a new line elsewhere, its old line removed,
leaves the held content at the old place, where it shows once the hold ends,
as after Enter. Recorded as D112 in DECISIONS.md; y.md's Moves limit, Input
method composition note and warnings table are updated, and so are
YUnsupportedEditData (TypeScript and Flow) and the
UNSUPPORTED_EDIT_WARNING JSDoc.

Changeset

.changeset/lexical-y-composed-move-keeps-held-text.md ([fix], with a
Verify: paragraph naming the new warning reason).

A commit that adds characters (decided by insertionFree, a pure module shared with the identity binding), or one made while a change applied during it is not read yet (D108), is never refused (what is typed is never dropped, and a deferred change is never read twice): it is written as any other, and held content is lost where the write cannot keep it, as on main.

Review rounds added (each with cells that fail on the commit before it):

• a commit that reorders, in one container, two units that each hold content the editor does not show (held, or inserted by a change not read yet, also in a host's named slots) is refused the same way: a write can keep only one of them;
• a unit also holds pending content where a change not read yet deleted one of its items or set or removed one of its attributes, so rewriting a passed line never brings back what such a change deleted; a commit not refused because it adds characters is written without keeping any unit;
• a commit that removes a node stored as a shared node of its own (an inline container, a block node, a slot's value) holding held content while the text being composed stays (its children moved into a new node) is refused; a line's block type change is not;
• a paragraph a change not read yet inserted is no unit the document had: neither the writer nor the reorder check counts its content toward the next line (a split of a line still counts as that line's);
• where the cursor writes whole units at a boundary, it does not stop at a format inside content the editor does not show (a paragraph a change not read yet appends), and stops again after the end of such a paragraph;
• a paragraph a change not read yet inserted between two lines a kept line passes ends up next to the kept line (recorded in D112 and y.md);
• the move check finds a slot's host through the slot, and counts a block node holding its text (a collapsible's title) as inside itself, so ordinary edits there are not refused.

Test plan

New regression file packages/lexical-y/src/__tests__/unit/regressions/ComposedMovePendingText.test.ts (168 cases, three peers, checked against a fresh reader, gc on and off).

Before

pnpm exec vitest run --project unit packages/lexical-y/src/__tests__/unit/regressions/ComposedMovePendingText.test.ts on main (dfe058a), first commit's cells (later cells fail on the commit before them, see each commit):

 FAIL  |unit| .../ComposedMovePendingText.test.ts > held back in an inline container, the line holding it moved > moved to another list, text (gc true, ids 1,2,3)
Expected: "list[bullet](listitem("tail")) / paragraph("sep") / list[number](listitem("other") listitem(test_composed_span("aRbc")))"
Received: "list[bullet](listitem("tail")) / paragraph("sep") / list[number](listitem("other") listitem(test_composed_span("abc")))"

 FAIL  |unit| .../ComposedMovePendingText.test.ts > held back while composing, the list item holding it moved > moved down its list, text (gc false, ids 1,2,3)
AssertionError: expected 'list[bullet](listitem("Rtail") listit…' to be 'list[bullet](listitem("tail") listite…'

 FAIL  |unit| .../ComposedMovePendingText.test.ts > held back while composing, moved by an app in a remote read > into a block node (gc true, ids 1,2,3)
Expected: "aRbc"
Received: "list[bullet](listitem("R"{1} "tail")) / paragraph("sep!") / list[number](listitem("other")) / test_box(paragraph("in box") list[number](listitem("abc")))"

 Test Files  1 failed (1)
      Tests  104 failed (104)

After

At the head of this pull request:

$ pnpm exec vitest run --project unit packages/lexical-y/src/__tests__/unit/regressions/ComposedMovePendingText.test.ts
      Tests  168 passed (168)
$ LEXICAL_Y_GC=1 pnpm exec vitest run --project unit packages/lexical-y/src/__tests__/unit/regressions/ComposedMovePendingText.test.ts
      Tests  168 passed (168)
$ pnpm exec vitest run --project unit packages/lexical-y packages/lexical/
 Test Files  383 passed | 2 skipped (385)
      Tests  22673 passed | 379 expected fail | 131 skipped (23183)
$ LEXICAL_Y_GC=1 pnpm exec vitest run --project unit packages/lexical-y
 Test Files  271 passed | 2 skipped (273)
      Tests  20025 passed | 382 expected fail | 131 skipped (20538)

tsc, Flow, ESLint, Prettier and check-changesets are clean. Browser and E2E suites were not run.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
lexical	Ready	Preview	Nov 5, 2026 11:33am UTC
lexical-playground	Ready	Preview	Nov 5, 2026 11:33am UTC

[meta-code-review]

AI review status for this pull request.

Review status	Updated
🟢 Reviewed (for maintainers only)	Nov 5, 2026, 11:51 AM UTC

[pkg-pr-new]

lexical

npm i https://pkg.pr.new/lexical@9791

@lexical/a11y

npm i https://pkg.pr.new/@lexical/a11y@9791

@lexical/clipboard

npm i https://pkg.pr.new/@lexical/clipboard@9791

@lexical/code

npm i https://pkg.pr.new/@lexical/code@9791

@lexical/code-core

npm i https://pkg.pr.new/@lexical/code-core@9791

@lexical/code-prism

npm i https://pkg.pr.new/@lexical/code-prism@9791

@lexical/code-shiki

npm i https://pkg.pr.new/@lexical/code-shiki@9791

@lexical/compiler

npm i https://pkg.pr.new/@lexical/compiler@9791

@lexical/devtools-core

npm i https://pkg.pr.new/@lexical/devtools-core@9791

@lexical/dragon

npm i https://pkg.pr.new/@lexical/dragon@9791

@lexical/eslint-plugin

npm i https://pkg.pr.new/@lexical/eslint-plugin@9791

@lexical/extension

npm i https://pkg.pr.new/@lexical/extension@9791

@lexical/fast-check

npm i https://pkg.pr.new/@lexical/fast-check@9791

@lexical/file

npm i https://pkg.pr.new/@lexical/file@9791

@lexical/hashtag

npm i https://pkg.pr.new/@lexical/hashtag@9791

@lexical/headless

npm i https://pkg.pr.new/@lexical/headless@9791

@lexical/history

npm i https://pkg.pr.new/@lexical/history@9791

@lexical/html

npm i https://pkg.pr.new/@lexical/html@9791

@lexical/internal

npm i https://pkg.pr.new/@lexical/internal@9791

@lexical/link

npm i https://pkg.pr.new/@lexical/link@9791

@lexical/list

npm i https://pkg.pr.new/@lexical/list@9791

@lexical/mark

npm i https://pkg.pr.new/@lexical/mark@9791

@lexical/markdown

npm i https://pkg.pr.new/@lexical/markdown@9791

@lexical/mdast

npm i https://pkg.pr.new/@lexical/mdast@9791

@lexical/offset

npm i https://pkg.pr.new/@lexical/offset@9791

@lexical/overflow

npm i https://pkg.pr.new/@lexical/overflow@9791

@lexical/plain-text

npm i https://pkg.pr.new/@lexical/plain-text@9791

@lexical/react

npm i https://pkg.pr.new/@lexical/react@9791

@lexical/rich-text

npm i https://pkg.pr.new/@lexical/rich-text@9791

@lexical/selection

npm i https://pkg.pr.new/@lexical/selection@9791

@lexical/table

npm i https://pkg.pr.new/@lexical/table@9791

@lexical/tailwind

npm i https://pkg.pr.new/@lexical/tailwind@9791

@lexical/text

npm i https://pkg.pr.new/@lexical/text@9791

@lexical/utils

npm i https://pkg.pr.new/@lexical/utils@9791

@lexical/y

npm i https://pkg.pr.new/@lexical/y@9791

@lexical/yjs

npm i https://pkg.pr.new/@lexical/yjs@9791

commit: a9288a6

[meta-code-review]

Thanks for the careful fix and the 104-case matrix. Keeping the held unit for moves within a container and refusing cross-container moves reads well, and the new cases fail on main and pass on this branch.

One issue to fix before merge

• Composing inside a named slot now loses keystrokes (packages/lexical-y/src/internal/Binding.ts, the inside helper in $movesHeld, around line 4310). node.getParents() stops at a slot boundary: a slot value has no __parent, and only isAttached() follows __slotHost. So for a line inside a slot (for example the playground's pull quote quote slot, or a component's shadow-root body), inside(line, host) returns false and the commit is refused as a 'composing-move' although nothing moved. To reproduce: A composes in abc inside a slot, B inserts R (held back), A types x. On main every client ends with axRbc; on this branch x is dropped from A's editor and the document (aRbc), and a 'composing-move' warning fires. A plain paragraph and a table cell behave correctly. Walking n.getParent() ?? $getSlotHost(n) in inside fixes it, and the 104 new cases still pass with that change.
• Writer#$heldKeys' add (packages/lexical-y/src/internal/Write.ts, around line 2231) walks getParent() the same way, so a slot host is never treated as held. The same walk there would let a host moved within its container keep the held content in its slot.

Suggestions (non-blocking)

• packages/lexical-y/AGENTS.md (Testing) asks @lexical/y tests to draw their inputs from src/__tests__/catalog/, which includes named-slot hosts. A no-move case (a held collaborator change plus one composed keystroke, asserting the keystroke is stored on every peer) over the catalog's container shapes would have caught the issue above.
• A refused move re-reads the composed line while the browser's composition is still open. One collab-Y E2E check (pnpm run test-e2e-collab-y-chromium), or a recorded manual check, would show what the input method does there.

[meta-code-review]

getParents() stops at a slot boundary (a slot value has no __parent; only isAttached() follows __slotHost), so for a line inside a named slot this returns false against the host's unit and the commit is refused as a 'composing-move' although nothing moved. Composing in a slot line while a collaborator's change is held then drops each keystroke (axRbc on main, aRbc here). Walking n.getParent() ?? $getSlotHost(n) fixes it, and the 104 new cases still pass.

[meta-code-review]

Same slot boundary here: getParent() stops at the slot value, so a slot host is never added to the held keys and a move of it within its container still rewrites the held content in its slot. The getParent() ?? $getSlotHost(n) walk would cover it.

[zurfyx]

Thanks. In e891a0d: inside in $movesHeld and add in Writer#$heldKeys walk a node's parent or the host of the slot it fills; cells held back in a slot, an edit that moves nothing out (a keystroke in the composed text, an edit elsewhere, the host moved in its container) fail on the previous head. The same commit also refuses two other shapes review found (a reorder of two lines that each hold pending text; a replacement of an inline container or block node holding held text) with cells. On the catalog dimension and an E2E check of a refused move with an open IME composition: noted; I'll report what I can run.

[meta-code-review]

Following __slotHost in inside and in Writer#$heldKeys fixes the named-slot cases, and the new reorder and replacement refusals come with cells that fail on main. One shape still trips the refusal.

One issue to fix before merge

• Composing in a block element that holds its text directly loses keystrokes (packages/lexical-y/src/internal/Binding.ts, inside in $movesHeld, lines 4400-4417, checked at line 4468). A block element stored as a shared node of its own with inline children (the playground's CollapsibleTitleNode, or an app's ElementNode block that is not a line class) is both the inline container one level down and the unit holding it one level up, under the same key. inside(key, key) starts at the node's parent and never compares the node itself, so it returns false and every commit is refused as 'composing-move' although nothing moved. To reproduce: A composes in a collapsible title Details, B inserts ¶ (held back), A types §. On main every client ends with D§¶etails; on this branch § is refused, taken out of A's editor and never stored (D¶etails on every client and a fresh reader), and the warning fires. Moving the collapsible within the root is refused the same way. Returning true when key === above fixes both (the move then keeps ¶), the 128 cases in ComposedMovePendingText.test.ts still pass with it, and a title moved out of its collapsible is still refused by moves(u).

Suggestions (non-blocking)

• packages/lexical-y/AGENTS.md (Testing) asks @lexical/y tests to draw their inputs from src/__tests__/catalog/. A cell built from the catalog's collapsible/open shape would pin the fix above.
• $reordersHeld (Binding.ts, line 4351) counts the items of a whole paragraph that a change not read yet inserted toward the next existing line. With Y.applyUpdate inside editor.update inserting a paragraph before bb and typing into cc, moving bb to the end in that update is refused with 'composing-move', while main stores the move with nothing lost. No text is lost, but an app sees a valid move refused, with a reason that names a composition.
• While anything is held, $reordersHeld walks every block container on each commit: a composed keystroke in a 4000-paragraph document goes from about 0.95 ms to 1.5 ms. Skipping the walk when only a composition hold is active (it normally covers one line) would avoid it.
• The Test plan's Before/After output is for the first commit's 104 cases; the file now has 128. AGENTS.md ("Commits and Pull Requests") asks for the real output of the command at the current head.
• y.md's Moves limit (packages/lexical-website/docs/collaboration/y.md, line 1092 on) says a block holding a change the editor does not show yet "is never the one rewritten"; a reorder of two such blocks is refused instead, which the Input method composition note and the warnings table say but the Moves limit does not.
• A refused move is read back while the input method is still composing. One collab-Y E2E (pnpm run test-e2e-collab-y-chromium) or a recorded manual check would show what the browser does there.

[meta-code-review]

inside(key, key) is false: the walk starts at the node's parent and never compares the node itself. A block element stored as a shared node of its own with inline children (the playground's CollapsibleTitleNode, or an app's ElementNode block that is not a line class) is the inline container one level down and the unit one level up under the same key, so the check at line 4468 refuses every commit while a collaborator's change to it is held: each composed keystroke is dropped (main stores it), and a move of the block within its container is refused. With this change the 128 cases in ComposedMovePendingText.test.ts still pass, and a block moved to another container is still refused by moves(u).

Suggested change

	const inside = (key: NodeKey, above: NodeKey): boolean => {
	const inside = (key: NodeKey, above: NodeKey): boolean => {
	if (key === above) {
	return true;
	}

[meta-code-review]

Non-blocking: items of a whole paragraph that the unread change inserted (its end is not in cs.units) are counted toward the next existing unit here. A change applied inside the update that inserts a paragraph before bb and types into cc makes a move of bb to the end look like a reorder of two held lines, so it is refused with 'composing-move', although main stores that move with nothing lost. Counting only items inside units the binding already has would avoid it.

[zurfyx]

Thanks. In 4ad4f2e: inside counts a node as inside itself (a collapsible title is both the inline container and the unit), and $reordersHeld closes a unit at the end of a paragraph the editor does not show yet, so a move past a paragraph a change not read yet inserted is stored; while only a composition holds content it walks only the containers it holds content in. Cells for both fail on the previous head. y.md's Moves limit now names the reorder refusal; the PR body's Test plan shows the output at the head. A catalog-driven matrix and a collab E2E run of a refused move with an open composition are not in this PR.

[meta-code-review]

This looks good to me. Following inside for a block that holds its own text (the collapsible title) and closing a paragraph that a not-yet-read change inserted both come with regression cells, and the Test plan now shows the output at the head. Everything below is optional and non-blocking.

Optional suggestions

• A line that the not-yet-read change splits is rewritten again (packages/lexical-y/src/internal/Write.ts, isNewEnd, lines 2264-2268, and the matching reset in $reordersHeld, packages/lexical-y/src/internal/Binding.ts, lines 4374-4386). A split of an existing line also inserts a new end item, after that line's own text, so the text before it is no longer attributed to the line. Repro: B types X into aabb and splits it after aXa; A applies that update inside an editor.update that moves the line to the end. With the commit before this one every client ends with mid / tail / aXa / bb; at this head, as on main, it ends with X / mid / tail / aabb, while y.md's Moves limit says a block holding a change the editor does not show yet "is never the one rewritten". Closing the run at an inserted end only when nothing between the previous known end and it is content the document already had (a wholly inserted paragraph) keeps both behaviours: with that condition the 138 cases still pass and the split keeps aXa / bb. packages/lexical-y/AGENTS.md (Testing) asks for a regression cell per fix, so one for this shape would pin it.
• y.md's Moves limit and one refusal disagree (packages/lexical-y/src/internal/Binding.ts, lines 4401-4411). $reordersHeld compares the held units' order with isBefore, so moving one of two lines that both hold a not-yet-read change into a box counts as a reorder and is refused with 'composing-move'; nothing is lost. packages/lexical-website/docs/collaboration/y.md (lines 1100-1103) says such a move is stored with the change lost or at the old position. One clause in y.md, or skipping units whose container changed, would align them.
• Catalog-drawn cells. packages/lexical-y/AGENTS.md (Testing) asks @lexical/y tests to draw their inputs from src/__tests__/catalog/. Over the catalog's shapes (a composed keystroke, and a move of each shape's block in the root) nothing is refused and every held insert is kept at this head, so a few catalog-driven cells would cheaply pin that.
• Cost while a composition holds a change. $reordersHeld (Binding.ts, line 4305) runs on every local commit during a hold; for a line in the root its container list includes the root, and holds recurses into every block node. A composed keystroke in a 4000-paragraph document goes from about 0.8 ms to 1.2 ms while a change is held, and is unchanged otherwise. Deriving the held units from the held items upward, as $movesHeld and Writer#$heldKeys already do, would make it proportional to what is held.
• Real-browser check of a refused move. A refused move is read back while the input method is still composing. One collab-Y E2E run (pnpm run test-e2e-collab-y-chromium, listed in AGENTS.md) or a recorded manual check would show what the browser does there.

[meta-code-review]

Optional: a split of an existing line also inserts an end item the not-yet-read change owns, after the line's own text, so this stops the walk before the line's original end and the line is no longer kept. B types X in aabb and splits after aXa, applied inside the update that moves the line: every client ends with X / mid / tail / aabb, as on main, where the commit before this one kept aXa / bb. Closing here only when nothing between the previous known end and this one is content the document already had would keep both cases (the same condition fits the reset in $reordersHeld).

[meta-code-review]

Optional: isBefore compares document order, so a held unit moved into another container after the other held unit counts as a reorder and the update is refused with 'composing-move'. y.md's Moves limit says such a cross-container move is stored (the change lost or at the old position). Either document this case or skip units whose container changed.

[zurfyx]

Thanks. In 4b450dd: an inserted end closes the content before it only when nothing between it and the previous known end is content the editor shows (endsNewUnit), so a split line keeps aXa / bb when moved (cell fails on the previous head); y.md's Moves limit now says the reorder refusal also covers one of the two blocks moving to another container. Not in this PR: catalog-driven cells, the walk-cost refinement while a composition holds a change (about 0.4 ms per keystroke at 4000 paragraphs, only during a hold), and a collab E2E run of a refused move.

[meta-code-review]

This looks good to me. The split-line case from the last round now keeps aXa / bb, and a regression cell covers it. Caching endsNewUnit keeps the results the same and makes a long run of inserted paragraphs cheap again. Everything below is optional and non-blocking.

Optional suggestions

• An unread paragraph between the lines a held line passes ends up next to the moved line (packages/lexical-y/src/internal/Write.ts, lines 2059-2066). Keeping the held line's items rewrites the lines it passes. A paragraph that the same not-yet-read change inserted between two of those lines is not rewritten, so it stays beside the kept line. Repro: B types X into aa and inserts new between cc and dd; A applies that update inside an editor.update that moves aa to the end. Every client ends with bb / cc / dd / aXa / new, where main gives Xbb / cc / new / dd / aa. Nothing is lost, but neither y.md's Moves limit nor D112 mentions it. packages/lexical-y/AGENTS.md (Decisions) asks for accepted limits to be recorded in both, so a clause plus a cell would pin it. Alternatively, $reordersHeld could refuse this shape, as it already does for two held lines.

• Two walks are quadratic in a large paste into one line. They are unitOf in $movesHeld (packages/lexical-y/src/internal/Binding.ts, lines 4476-4484) and the walk in $heldKeys (packages/lexical-y/src/internal/Write.ts, lines 2273-2279). Each held or unread item walks right to its unit's end, so items that all sit in one line repeat the same walk.

  • A collaborator's 1600-line paste into the middle of the line being composed is held, per y.md's Input method composition note. While it waits, each composed keystroke takes about 40 ms, against under 2 ms on main.
  • A not-yet-read 1600-paragraph paste into a line, applied in an update that inserts a paragraph, takes about 350 ms, against about 45 ms on main.

  Remembering the unit for every item a walk passes (a Map<Item, Unit | undefined> filled along the walk) brings both back to main's cost with the same results. A cell like regressions/Scaling.test.ts would keep it there.

• Evidence for the cost-only commit. packages/lexical-y/AGENTS.md (Testing) asks a refactor to show that it stores the same bytes. The commit "Walk a run of paragraphs a change not read yet inserts once" says "Same results, same bytes", but its Test plan shows only the regression run; a short byte comparison would document it. The catalog-driven cells from the same section are still open, as you noted.

• Real-browser check of a refused move. The collab-Y E2E specs pass at this head, but none moves the composed line while a peer's change waits. One spec (pnpm run test-e2e-collab-y-chromium, listed in AGENTS.md) or a recorded manual check would show what the input method does when the refused move is read back.

[meta-code-review]

Optional: every held item walks from here to its unit's end, so a collaborator's large paste into the composed line (held whole) makes each composed keystroke quadratic. With 1600 held lines that is about 40 ms per keystroke, against under 2 ms on main. Caching the unit for each item passed (a Map<Item, Unit | undefined> filled along the walk) keeps the results and restores main's cost.

[meta-code-review]

Optional: same pattern as unitOf in $movesHeld. Since an unread split's ends are no longer new ends, every item of a not-yet-read paste into a line walks to the line's original end. A 1600-paragraph paste applied in an update that inserts a paragraph takes about 350 ms, against about 45 ms on main. A per-item memo of the unit found fixes it.

[meta-code-review]

Optional: when the kept unit passes other lines, they are rewritten, but a paragraph that the same not-yet-read change inserted between two of them is not. It ends up beside the kept line: aXa / bb / cc / new / dd with aa moved to the end gives bb / cc / dd / aXa / new on every client. Worth a clause in y.md's Moves limit and D112, plus a cell, or a refusal like the one for two held lines.

[zurfyx]

Thanks. In 09c886d: the unit found for each held or unread item is remembered for every item a walk passes (Writer#$heldKeys, $movesHeld), so a large held paste no longer makes each composed keystroke walk its line per item; the unread paragraph between passed lines is recorded in D112 and y.md with a cell. The same commit fixes a placement bug our session lane found (a paragraph an update appends landed inside a formatted paragraph a change not read yet appends: the boundary stop now ignores formats past unseen content), with a cell that fails on the previous head and passes on main. On the cost-only commit's bytes: the reviewer's 60 ordinary-move pairs and the unread corpus are byte-identical before and after.

[meta-code-review]

This looks good to me. Moving the line being composed now keeps a collaborator's held-back text on every client. Moves that cannot keep it are refused and read back with a clear 'composing-move' reason. Since the last round, a large held paste no longer slows composed keystrokes, and the unread-paragraph placement is documented. Everything below is optional and non-blocking, though the first item is worth fixing before merge.

Optional suggestions

• After an unread paragraph, written lines land inside a collaborator's format run again (packages/lexical-y/src/internal/Cursor.ts, lines 549-555 and 744-750). passed is set once the cursor steps over unseen content and is never cleared. So when a paragraph that a change not read yet inserted comes right before a format that change opens over the next line, the cursor no longer stops at that format. Repro: B inserts new before aa and bolds aa, and A applies that update inside an editor.update that moves aa to the end. Every client ends with bb and cc bold (new / bb / cc / aa), while the previous commit gave new / bb / cc / aa. That contradicts D112's "not inside it". Resetting passed after the end item of a unit the change inserted fixes it, and the whole @lexical/y unit run still passes with it:

  passed =
    isEndItem(r) && isUnreadInsert(r) ? false : passed || this.passesUnseen(r);

  packages/lexical-y/AGENTS.md (Testing) asks every bug fix to land with a regression cell, so a cell for this shape would pin it.
• The new memo never hits for items of an unread new paragraph (packages/lexical-y/src/internal/Write.ts, lines 2280-2283; packages/lexical-y/src/internal/Binding.ts, lines 4484-4487). undefined means both "not walked yet" and "no unit", which is what an unread new paragraph resolves to. So each of its items walks to its end again. A change not read yet that appends one paragraph of 2000 formatted runs, applied inside an update that inserts a paragraph, takes about 400 ms, against about 20 ms on main. unitAt.has(end) restores main's cost, and the cells still pass.
• Real-browser check of a refused move. The collab-Y E2E jobs pass, but none moves the composed line while a peer's change waits. One spec (pnpm run test-e2e-collab-y-chromium, listed in AGENTS.md) or a recorded manual check would show how the input method copes when a refused move is read back mid-composition. You have already said this is out of scope here.

[meta-code-review]

Optional, but worth fixing before merge: passed is never cleared, so after a paragraph that a change not read yet inserted, a format that change opens over the next line is no longer a boundary. Example: B inserts new before aa and bolds aa, and A applies it inside an update that moves aa to the end. Every client ends with bb and cc bold. Clearing it after an unread unit end fixes that and keeps the new cell passing:

passed =
  isEndItem(r) && isUnreadInsert(r) ? false : passed || this.passesUnseen(r);

The same applies at line 750.

[meta-code-review]

Optional: undefined is both "not walked yet" and the stored "no unit" (the walk stopped at an unread new paragraph's end), so items of such a paragraph never hit the memo. One unread paragraph of 2000 formatted runs applied inside an update takes about 400 ms here, against about 20 ms on main. if (unitAt.has(end)) { unit = unitAt.get(end); break; } fixes it; unitOf in Binding.ts (line 4484) has the same pattern.

[zurfyx]

Thanks. In 0333d0b: the end of a unit a change not read yet inserted resets passed (cell: B inserts new before aa and bolds it, A moves aa to the end; only aa is bold, fails on the previous head), and the unit memo uses unitAt.has so items in no unit are remembered too.

[meta-code-review]

Thanks for the careful work here. The new regression file clearly separates the fix (its cells fail on main and pass at this head), and keeping a unit within its container while refusing a move to another one reads well. One issue should be fixed before merge; the rest are optional.

Must fix: a passed line's unread deletion or attribute change is undone

packages/lexical-y/src/internal/Binding.ts:4319: $reordersHeld's holds counts only content that a change not read yet inserted. When the same change deletes text, or sets marker attributes, in a line that the kept line passes, the reorder is not refused. Writer#$heldKeys then keeps the moved line, and the passed lines are rewritten from the editor's view, which still shows what the change deleted. Repro, in the shape of the inserted by a change not read yet in two lines, reordered cells: B types X into aa and changes the next line; A applies B's update inside its own editor.update() and moves aa to the end.

B's change to the passed line	main	this PR
deletes one b of bbb	Xbb / cc / aa	bbb / cc / aXa
removes paragraph bb	X / cc / aa	bb / cc / aXa
makes bb a heading	heading("Xbb") / ...	paragraph("bb") / ...
checks list item bb	listitem[x]("Xbb") ...	listitem[ ]("bb") ...

Every peer and a fresh reader agree, with gc on or off, and nothing is warned. Preventing a rewrite from bringing back what such a change deleted is what D108 in packages/lexical-y/DECISIONS.md is for, and D112 calls the keep exact, with no resurrected delete, yet the rewritten passed lines bring one back. Suggested fix: also count a unit as holding when an unread change deleted one of its items or set an attribute on its end item, so that the reorder is refused as it is for two units holding inserts. Then add these shapes as cells in ComposedMovePendingText.test.ts (packages/lexical-y/AGENTS.md: every bug fix lands with a regression test).

Optional suggestions

• packages/lexical-y/src/internal/Write.ts:2062: heldWeight keeps the held unit whatever it passes. Moving the composed line from the top to the bottom of 200 paragraphs rewrites all 199 passed lines (7,431 bytes, against 38 on main), and a third peer's concurrent typing in any of them ends up as a line of its own after the kept one. D112 accepts rewriting the passed side; consider bounding it (refuse once the passed units outweigh the kept one), or saying in y.md's Moves limit what happens to concurrent typing in passed lines.
• The changeset's Verify: paragraph could mention that same effect on passed lines.
• The catalog-driven cells (packages/lexical-y/AGENTS.md: "Test the input space") and a collab-Y E2E run with a real composition are already noted as follow-ups.

The TypeScript and Flow types for the new 'composing-move' reason, the changeset and the docs updates look good.

[meta-code-review]

Must fix: holds counts only content a change not read yet inserted. A passed line whose unread change deleted text (or removed the paragraph, or set a marker attribute such as a heading type or a check) is not counted, so the reorder is not refused, and the write rewrites that line from the editor's view: B's deletion of a b in bbb comes back as bbb / cc / aXa on every peer, where main gives Xbb / cc / aa. Counting a unit as holding when an unread change deleted one of its items, or set an attribute on its end item, would refuse it like two units holding inserts.

[meta-code-review]

Optional: this weight keeps the held unit whatever it passes. Moving the composed line from the top to the bottom of 200 paragraphs rewrites all 199 passed lines (7,431 bytes, against 38 on main), and a third peer's concurrent typing in a passed line ends up as a line of its own after the kept one. Consider refusing once the passed units outweigh the kept one, or documenting it in y.md's Moves limit.

[zurfyx]

Thanks. In 2ca6a5f: $reordersHeld counts a unit as holding where an unread change deleted one of its items or set/removed one of its attributes, so your four shapes are refused (cells for each, with and without typing in the same update, fail on the previous head). Per the design decision for this class, a commit that adds characters is never refused; such a commit is now written with no unit kept (Writer#pins), exactly as on main, so it cannot bring back a deletion either. On the passed-side cost: y.md's Moves limit and the changeset now say that concurrent typing in a passed line lands next to the kept line; bounding the rewrite is left out of this PR.

[meta-code-review]

Thanks, this looks good. The regression file tells the fix apart from main (it fails there and passes here with gc on and off), and the refusal path, D112 and the y.md limits fit together. Everything below is optional and non-blocking.

1. Concurrent edits in a passed block node (packages/lexical-y/src/internal/Write.ts:2069). When a unit holding held or unread content is kept, every unit it passes is written again. For a passed line, a collaborator's concurrent typing lands next to the kept line, as y.md says. A passed block node (a box, a table), though, is copied whole, and a collaborator's concurrent edit inside it is lost. Repro with three peers:

• A composes in abc while B's R is held back.
• C, offline, types Z into a boxed paragraph inbox.
• A moves its line to the end, past the box.

On main every client ends with paragraph("R") / test_box(paragraph("inZbox")) / …. Here they end with test_box(paragraph("inbox")) / paragraph("tail") / paragraph("aRbc"). The D108 path does the same with no composition. packages/lexical-y/AGENTS.md asks for accepted limits to be recorded in DECISIONS.md and in y.md's Limits. Right now y.md Moves (lines 1096-1099), D112 and the changeset's last Verify: sentence say concurrent typing in a passed block lands next to the kept one. Please either document the block-node case, or skip the keep when the passed run contains a block node.

2. A refused commit drops non-text content (packages/lexical-y/src/internal/Binding.ts:8819). addsCharacters compares only text nodes. An update that inserts an inline equation and moves the composed line into a box is therefore refused whole, and the equation disappears. Counting any node the update made as an insertion would keep to the rule's intent. Otherwise, mention it next to the "adds characters" rule in y.md.

3. Docs: unwraps. The cell held back in an inline container, unwrapped into the text before it expects a refusal. So removing an inline element around the composed text (a comment mark, say) is undone while a change waits. y.md's Input method composition note, the warnings table, the UNSUPPORTED_EDIT_WARNING / YUnsupportedEditData JSDoc and D112 cover a replacement and a move to another line, but not an unwrap.

4. Tests and cost.

• The two insertionFree cost cells (InsertionFree.test.ts:156 and :169) never reach MAX_STEPS. The first returns at the made-node precheck, and the second at MAX_RUNS (the trailing z run makes 9 runs). 8 one-character runs with 8 made nodes that each fit every run does reach the budget.
• The budget limits assignments, not work: each full assignment re-checks every changed text, so a 20,000-character changed text takes about 2.7 s before the search gives up. Checking each changed node once for its four run combinations (none, left, right, both) before the search would bound it.
• packages/lexical-y/AGENTS.md asks for inputs drawn from src/__tests__/catalog/. Table cells (named in y.md and the changeset), links and comment marks as holders are not covered yet.
• AGENTS.md's Testing Strategy keeps behaviour that needs a real browser out of the node tier. A collab Y E2E run (pnpm run start:y, then pnpm run test-e2e-collab-y-chromium) of a refused move during a real IME composition would show how the immediate re-read behaves.

5. Small wording.

• $reordersHeld's JSDoc still says such a commit "is not written" (Binding.ts:4337).
• D112 and Binding.ts:4305 / :8810 describe insertionFree as shared with "the identity binding", but no other binding in this repository imports InsertionFree.ts.
• The comment at ComposedMovePendingText.test.ts:380 puts the "with typing: written" explanation above the unwrap describe.

[meta-code-review]

Optional: this weight keeps a held unit over every passed one, so a passed block node (box, table) is copied whole and a collaborator's concurrent edit inside it is lost. With three peers (A composing in abc with B's R held, C typing Z into a boxed inbox, A moving its line past the box), main keeps inZbox and this branch ends with test_box(paragraph("inbox")) on every client. Consider skipping the keep when the passed run holds a block node, or documenting it in D112 and y.md's Moves limit.

[meta-code-review]

Optional: for a passed block node (a box or a table) the whole node is written again, so what a collaborator types in it at the same time is lost, not placed next to the kept block. The changeset's last Verify: sentence says the same thing and could be corrected too.

[meta-code-review]

Optional: only TextNode text is compared, so a refused commit also drops non-text content it made. An inline equation inserted in the same update as a move into a box disappears. Counting any node the update made as an insertion would keep the never-drop intent.

[meta-code-review]

Nit: the trailing ['z', 'z'] makes 9 runs, so this returns on MAX_RUNS ("9 runs of removed text") without searching, and the previous cell returns at the made-node precheck. Neither reaches MAX_STEPS. 8 one-character runs with 8 made nodes that each fit every run would.

[meta-code-review]

Nit: since pinsOff, a commit that adds characters or is made while a change is unread is written (with no unit kept), so this invariant no longer holds as stated.