@helping-ai-workflow/md2doc 2.12.0 → 3.0.1

package/lib/editor/client.js

@@ -174,6 +174,291 @@
     return { lines: r.lines, blocks, op, newStartLine };
   }
 
+  // ── S4 Task 3: relocating ONE block's lines (spec §4.5) ────────────────
+  //
+  // A move is ONE commitRangeEdit over
+  // `min(source, destination) .. max(source, destination)`. UndoStack's op is
+  // `{startLine, endLine, before, after}` — a SINGLE contiguous line range,
+  // with no notion of a source and a destination — so a move written as
+  // "removal here, insertion there" is two ops and two Ctrl+Z, which §3.4
+  // forbids. For a block that is not a li there is nothing to re-serialize:
+  // the lines are relocated VERBATIM, so nothing can be re-escaped and no
+  // marker arithmetic is involved.
+  //
+  // THE BLANK-LINE RULE, which the plan left to this task to define:
+  //
+  //   1. The block's own lines move byte-for-byte.
+  //   2. At the seam it LEAVES, the blank run that surrounded it is absorbed
+  //      and replaced by exactly ONE blank line — or by none when the block
+  //      was at the start or the end of the file.
+  //   3. At the seam it LANDS in, one blank line is emitted on each side of
+  //      it whose neighbouring line is not already blank.
+  //
+  // Neither existing helper is the right tool, and the plan says so:
+  // commitRangeRemoval() absorbs exactly one adjacent blank and
+  // commitBlockInsertion() always adds a leading one. Each is HALF of a move
+  // and the halves do not compose — the pair leaves the document one
+  // separator short at the seam that was left and one long at the seam that
+  // was landed in, and it is two undo ops.
+  //
+  // CONSEQUENCE, measured against marked.lexer + blockmap.buildBlockMap on
+  // every fixture in test/editor-client-runtime.test.js's T3 section before
+  // any byte was pinned: in a document whose blocks are separated by exactly
+  // one blank line — everything this editor's own serializer emits — a move
+  // is a PERMUTATION OF THE FILE'S LINES. Same lines, same count, same
+  // separators.
+  //
+  // The one exception, and it is deliberate: a document that already jams two
+  // blocks onto adjacent lines ('# A\n# B\n# C\n') has no blank at the
+  // landing seam to carry, so rule 3 CREATES one and the count goes up. It
+  // has to. MEASURED: 'paraA\n# H\n\nparaB\n' with paraA appended and no
+  // blank emitted is '# H\n\nparaB\nparaA\n', which marked.lexer answers as
+  // ONE paragraph — the move would have eaten a block. The count moves only
+  // in that direction, and only at a seam that had no separator to begin
+  // with.
+  //
+  // The final '' of a file that ends in a newline is the TERMINATOR, not a
+  // blank separator; `contentLen` below is what keeps rule 2 from eating the
+  // file's last newline when the block being moved is the last one.
+  //
+  // Pure: takes and returns plain data, and lives in the node-visible core
+  // beside the other commit helpers.
+  function planBlockMove(lines, blocks, src, dest) {
+    const isBlank = (s) => s !== undefined && s !== null && s.trim() === '';
+    const contentLen = lines.length - (lines.length && lines[lines.length - 1] === '' ? 1 : 0);
+    let above = 0;
+    while (src.startLine - 1 - above >= 1 && isBlank(lines[src.startLine - 2 - above])) above++;
+    let below = 0;
+    while (src.endLine + 1 + below <= contentLen && isBlank(lines[src.endLine + below])) below++;
+    // The source's own extraction range: its lines plus the whole blank run on
+    // either side of it. What goes BACK at that seam is rule 2's single blank,
+    // and only when the seam has a block on both sides of it.
+    const ds = src.startLine - above;
+    const de = src.endLine + below;
+    const srcFill = (ds >= 2 && de < contentLen) ? [''] : [];
+    const blockLines = lines.slice(src.startLine - 1, src.endLine);
+    // `dest === null` is the {mode:'append'} target: the insertion point is
+    // one line past the last block's last line.
+    const ins = dest ? dest.startLine
+      : (blocks.length ? blocks[blocks.length - 1].endLine + 1 : contentLen + 1);
+    // Dropped where it already is. `ins === ds` is "on my own top edge";
+    // `ins === de + 1` is "on the seam immediately below me" — visually the
+    // same place, and the byte no-op the drag's own release-where-you-started
+    // case depends on. Every other `ins` inside the extraction range is a
+    // blank line, which no block's startLine can name.
+    if (ins >= ds && ins <= de + 1) return null;
+    const prevLine = ins >= 2 ? lines[ins - 2] : null;
+    const nextLine = ins <= lines.length ? lines[ins - 1] : null;
+    const lead = (prevLine !== null && !isBlank(prevLine)) ? [''] : [];
+    const trail = (nextLine !== null && !isBlank(nextLine)) ? [''] : [];
+    const payload = lead.concat(blockLines, trail);
+    // ONE range, covering both seams. Everything between them is carried
+    // through untouched — which is what makes this a single undo op instead
+    // of a removal and an insertion.
+    if (ins > de + 1) {
+      const after = srcFill.concat(lines.slice(de, ins - 1), payload);
+      const newStart = ds + srcFill.length + (ins - 1 - de) + lead.length;
+      return { startLine: ds, endLine: ins - 1, after: after,
+        newRange: { startLine: newStart, endLine: newStart + blockLines.length - 1 } };
+    }
+    const after = payload.concat(lines.slice(ins - 1, ds - 1), srcFill);
+    const newStart = ins + lead.length;
+    return { startLine: ins, endLine: de, after: after,
+      newRange: { startLine: newStart, endLine: newStart + blockLines.length - 1 } };
+  }
+
+  // The commit half. `op === null` with `noop` set means the block was
+  // released where it already was — a BYTE no-op, not a failure, and
+  // deliberately distinct from commitRangeEdit()'s own unchanged-text
+  // `op: null` so a caller can tell "nothing to do" from "somebody handed me
+  // a range that produced the same text".
+  function commitBlockMove(state, src, dest) {
+    const plan = planBlockMove(state.lines, state.blocks, src, dest);
+    if (!plan) {
+      return { lines: state.lines, blocks: state.blocks, op: null, noop: 'same-position' };
+    }
+    const r = commitRangeEdit(state, plan.startLine, plan.endLine, plan.after.join('\n'));
+    r.newRange = plan.newRange;
+    return r;
+  }
+
+  // ── S4 Task 4: the pure half of a LIST ITEM's move (spec §4.5) ─────────
+  //
+  // A li's lines CANNOT be relocated the way planBlockMove() relocates every
+  // other block's — verbatim. Markers and ordinals are RUN-GLOBAL: '3. charlie'
+  // moved to the head of its run has to come back as '1. charlie' with
+  // everything behind it renumbered, and its indent prefix is a column count
+  // measured against the marker widths standing above it. So a li's move is
+  // expressed the way duplicateListItems() expresses a duplicate — as a
+  // REORDERED SPAN ARRAY handed to serializeBlocks(), committed over the run's
+  // own line range as ONE commitRangeEdit (§3.4: one gesture, one undo op).
+  // These two functions are the parts of that reasoning with no DOM in them.
+
+  // The span order after "the `count` members starting at `from` go
+  // immediately before the member at `insertAt`". `insertAt` names a slot in
+  // the array BEFORE the removal — it comes straight from the drop target's
+  // `before-block N` — so a DOWNWARD move is decremented by the WHOLE count
+  // and an upward one is not decremented at all: the same `insertAt` means two
+  // different slots depending on the direction, which is the whole reason this
+  // is a named function with its own test rather than a splice pair at the
+  // call site.
+  //
+  // S4 Task 6 widened it from one member to `count`, in place rather than
+  // beside: §4.5's 「grip 在選取集合內 → 整批搬」 is the SAME arithmetic and a
+  // second copy of an off-by-one is the 「不得另寫一條」 shape §3.6 has already
+  // ruled against twice. The single-item case is `count === 1` and its whole
+  // test table was migrated onto this signature unchanged.
+  //
+  // `null` means the order would be UNCHANGED, which is a byte no-op and not a
+  // failure: every `insertAt` from `from` to `from + count` inclusive is the
+  // SET'S OWN FOOTPRINT — `from` is "released on my own top edge",
+  // `from + count` is "released on the seam immediately below me", and the
+  // slots in between name a position INSIDE the set, which is not a reorder of
+  // the span but a shuffle of members that are travelling together. Visually
+  // they are all the same place, and they are the case the drag's own
+  // release-where-you-started gesture depends on. An out-of-range index, an
+  // empty set and a set that runs off the end answer `null` too; there is no
+  // order any of them could name.
+  function reorderSpanRange(length, from, count, insertAt) {
+    if (!(length > 0) || !(count > 0)) return null;
+    if (!(from >= 0) || from + count > length) return null;
+    if (!(insertAt >= 0) || insertAt > length) return null;
+    if (insertAt >= from && insertAt <= from + count) return null;
+    const rest = [];
+    const moved = [];
+    for (let i = 0; i < length; i++) {
+      if (i >= from && i < from + count) moved.push(i); else rest.push(i);
+    }
+    const at = insertAt > from ? insertAt - count : insertAt;
+    return rest.slice(0, at).concat(moved, rest.slice(at));
+  }
+
+  // ── S4 Task 6: the LINE RANGE a batch move relocates (spec §3.3, §4.5) ──
+  //
+  // §3.3's operand set is CONTIGUOUS in block order — resolveGutterOperands()
+  // refuses a gap before anything reaches here — so its members' lines plus
+  // the separators standing between them are ONE contiguous run, which is
+  // exactly what planBlockMove() relocates verbatim. That is the whole reason
+  // a batch move is the SAME single commitRangeEdit a one-block move is, and
+  // therefore the same single Ctrl+Z (§3.4).
+  //
+  // Named rather than written as an object literal at the call site because
+  // the set reaches the bytes through this one expression and nothing else: an
+  // endLine taken from any member but the LAST leaves the rest of the set
+  // standing where it was while its head travels, and the blank-line rules
+  // then re-emit separators around both halves — a document the user never
+  // asked for, from a one-token typo. A pure function is a mutation a test can
+  // kill in a millisecond instead of a browser round trip.
+  function spanMoveRange(recs) {
+    if (!recs || !recs.length) return null;
+    return { startLine: recs[0].startLine, endLine: recs[recs.length - 1].endLine };
+  }
+
+  // §4.5's INDENT SEAM, asked of the span AS IT WOULD BE COMMITTED.
+  //
+  // Markdown indent is only ever RELATIVE (indent-clamp.js's own opening
+  // sentence): an item's depth exists solely because a shallower item stands
+  // above it. serializeBlocks() rebuilds its marker-width stack as it walks the
+  // array, from empty — so a span whose FIRST block claims `data-indent="1"`
+  // emits that block at column 0, and the DOM and the file then disagree about
+  // the nesting. A move creates exactly that by lifting an item out from above
+  // its own child.
+  //
+  // The bound is deliberately the one indent-clamp.js's `boundAt()` computes
+  // — the previous li's indent + 1, and 0 when there is no previous li or the
+  // previous block is not one — so the predicate and the clamp cannot drift.
+  //
+  // S4 Task 7 KEPT it and moved it to AFTER the clamp. Asked of the raw
+  // reordered span it refused 1425 of the 4067 legal drops; the clamp now
+  // answers 1411 of those, and what this still refuses is the 14 no
+  // removal-clamp can reach — a batch whose last member is shallower than the
+  // block it lands before, i.e. the INSERTION half of the move. See
+  // performListItemDrop() for the single site and BLOCK_MOVE_ORPHAN_MESSAGE
+  // for the family and the sweep behind those numbers.
+  function spanIndentsAreAnchored(items) {
+    let prevLi = null;
+    for (let i = 0; i < (items || []).length; i++) {
+      const it = items[i] || {};
+      if (it.type !== 'li') { prevLi = null; continue; }
+      const indent = typeof it.indent === 'number' ? it.indent : 0;
+      if (indent > (prevLi === null ? 0 : prevLi + 1)) return false;
+      prevLi = indent;
+    }
+    return true;
+  }
+
+  // ── S4 Task 5: the CROSS-BOUNDARY seam predicate (spec §4.5) ──────────
+  //
+  // §4.5's ruling, made by the user on 2026-09-01 and implemented rather than
+  // re-opened: a cross-boundary move is REFUSED with a banner in 3.0.0 and the
+  // capability deferred to 3.1.0, whose first step is amending the spec with
+  // the blank-line rule for a run/non-run seam. This function is the whole of
+  // "which moves cross a boundary" for a block that is NOT a list item; a li
+  // source has its own, narrower question (its destination must be a slot in
+  // its own §3.8 run) and answers it in performListItemDrop().
+  //
+  // A move touches TWO seams and they need DIFFERENT rules. That asymmetry is
+  // the task's finding, and every row below is a marked.lexer measurement:
+  //
+  //   DESTINATION — where the block LANDS. An insertion can only ever SPLIT;
+  //   it has no way to merge two lists. So the only thing it can break is a
+  //   run it lands INSIDE, and the question is exactly "are these two
+  //   neighbours members of ONE run":
+  //     '# Doc\n\npara\n\n- a\n- b\n\ntail\n' with `para` spliced
+  //       between the items -> list(1) | paragraph | list(1): one two-item run
+  //       became two one-item runs, and the blanks rule 3 emits either side
+  //       are §4.3's looseness trap. REFUSED.
+  //     '# Doc\n\n- a\n\n1. b\n\ntail\n' with `para` spliced at the
+  //       same-looking seam -> heading | ul(1,tight) | paragraph |
+  //       ol(1,tight) | paragraph. Nothing merged, nothing loosened, because
+  //       these were already two lists. ACCEPTED — this is Task 3's
+  //       deliberate over-refusal, and narrowing it is what Task 5 owed.
+  //
+  //   SOURCE — where the block LEAVES. A removal MERGES, and it CANNOT be
+  //   narrowed with anything the block model carries. Every one of these
+  //   leaves ONE list with `loose === true`, i.e. every item renders as a <p>,
+  //   serializeBlocks() reports 'P' for each, and the whole run degrades
+  //   read-only with no banner:
+  //     '- a'      | para | '- b'        ->  '- a\n\n- b\n'
+  //     '1. a'     | para | '2. b'       ->  '1. a\n\n2. b\n'
+  //     '- [ ] a'  | para | '- [x] b'    ->  '- [ ] a\n\n- [x] b\n'
+  //     '- a'      | para | '  1. a1'    ->  '- a\n\n  1. a1\n'
+  //   The last one is why the obvious narrowings are all wrong. blockmap
+  //   reports those two items as (indent 0, listType 'ul') and (indent 0,
+  //   listType 'ol') — DIFFERENT runs AND different list types, so every fact
+  //   the model exposes says "two lists, safe", while the file says loose.
+  //   What decides it is the two-space prefix on a raw line, which no block
+  //   attribute carries and which the client cannot lex (render is a server
+  //   round trip; there is no lexer in the browser). The mirror over-refusal
+  //   is '- a' | para | '* b' -> '- a\n\n* b\n', measurably TWO tight
+  //   lists and still refused, because the discriminator there is the bullet
+  //   CHARACTER — another raw byte the model does not carry. Recorded in §4.5
+  //   as a deliberate over-refusal for 3.1.0, not as a correctness claim.
+  //
+  // `srcSeam` / `destSeam` are `{prev, next}`; each side is null when there is
+  // no such block or it is not a li, and otherwise `{runKey}` — the
+  // `data-block-id` of the FIRST member of listRunOf(), which is §3.4 rule 2's
+  // scope, so a nested child and its parent answer the SAME key. A null
+  // runKey (a run the DOM could not answer) counts as "same": an unknown seam
+  // refuses rather than guesses, because the guess that goes wrong corrupts a
+  // list and corrupting a list is not undoable.
+  //
+  // Returns 'source' | 'destination' | null. When both seams object the
+  // SOURCE one is reported: it is the objection that holds wherever the user
+  // aims next, so it is the one worth telling them about.
+  //
+  // Pure, and exported, because the enumeration it encodes is a table of
+  // measurements — a gesture-level test can only reach a handful of its rows.
+  function blockMoveSeamRefusal(srcSeam, destSeam) {
+    const s = srcSeam || {};
+    const d = destSeam || {};
+    if (s.prev && s.next) return 'source';
+    if (d.prev && d.next &&
+        (d.prev.runKey === null || d.next.runKey === null ||
+         d.prev.runKey === d.next.runKey)) return 'destination';
+    return null;
+  }
+
   // ── T8 review MEDIUM-1: the one correct way to undo a failed render ─────
   // Six sites in this file share the shape "commit optimistically, re-render,
   // and if the render failed put `lines` back". The inlined version of that
@@ -222,7 +507,7 @@
   }
 
   if (typeof module === 'object' && module.exports) {
-    module.exports = { extractBlockSource, commitEdit, commitRangeEdit, commitRangeRemoval, commitListBlockRemoval, commitBlockInsertion, rollbackFailedRender, headingDepthOf, withHeadingDepth };
+    module.exports = { extractBlockSource, commitEdit, commitRangeEdit, commitRangeRemoval, commitListBlockRemoval, commitBlockInsertion, planBlockMove, commitBlockMove, reorderSpanRange, spanMoveRange, spanIndentsAreAnchored, blockMoveSeamRefusal, rollbackFailedRender, headingDepthOf, withHeadingDepth };
     return; // node: pure core only
   }
 
@@ -635,6 +920,11 @@
     // ago was just destroyed by the innerHTML replacement above.
     hideTableEdgeMenu();
     cancelTeDrag();
+    // S4 Task 2: same belt-and-braces reasoning for an in-flight ⠿ block drag —
+    // the innerHTML replacement above just detached every block the gesture's
+    // ordinal refers to. Nothing was mutated by the drag, so there is nothing
+    // to revert; the state simply must not survive the render.
+    cancelBlockDrag();
     // Final-review Finding 5b (Important): same belt-and-braces reasoning
     // again for the ⠿ gutter menu — `toggleGutterMenu()` appends the ONE
     // shared `gutterMenu` node as a CHILD of whichever block it's open for
@@ -1357,29 +1647,56 @@
   // computes it with spanMinIndent(). A member that is not in `spanEls` aborts
   // the whole clamp rather than clamping a subset — a partial op set makes rule
   // 2's scope start in the wrong place, which is a silent wrong answer.
-  function applyIndentClamp(spanEls, opBlockEl, opOldIndent, opts) {
-    if (!indentClamp || !spanEls || !spanEls.length) return;
+  // S4 Task 7 split this in two WITHOUT changing what any existing caller does:
+  // computeIndentClamp() answers the clamp, applyIndentClamp() writes it, and
+  // the four callers that existed before this task still call the latter and
+  // still see exactly the answer they saw. The reason for the split is the ⠿
+  // DROP, and it is not a stylistic one: every other caller clamps a span it
+  // has already decided to commit, while the drop still has ONE refusal left
+  // after the clamp (see performListItemDrop()). Writing `data-indent` on a
+  // gesture that then refuses leaves a half-clamped DOM behind — the same
+  // "the screen and the model disagree" failure the clamp exists to prevent,
+  // produced by the clamp itself. So the drop asks first and writes only once
+  // it knows it is committing.
+  //
+  // `null` is "no answer at all": no clamp module, an empty span, or an
+  // operated element that is not IN the span. That last one abandons the whole
+  // clamp rather than clamping a subset — a partial op set makes rule 2's scope
+  // start in the wrong place, which is a silent wrong answer. Every caller
+  // treats `null` as "leave every indent alone", which is what the pre-split
+  // function did by returning early.
+  function computeIndentClamp(spanEls, opBlockEl, opOldIndent, opts) {
+    if (!indentClamp || !spanEls || !spanEls.length) return null;
     const opEls = Array.isArray(opBlockEl) ? opBlockEl : [opBlockEl];
     const opIndex = [];
     for (let k = 0; k < opEls.length; k++) {
       const at = spanEls.indexOf(opEls[k]);
-      if (at < 0) return;
+      if (at < 0) return null;
       opIndex.push(at);
     }
-    if (!opIndex.length) return;
+    if (!opIndex.length) return null;
     const model = spanEls.map((el, i) => ({
       id: i, // index-as-id: the span IS the universe here
       type: el.getAttribute('data-block-type') === 'li' ? 'li' : 'other',
       indent: Number(el.getAttribute('data-indent')) || 0,
     }));
-    indentClamp.clampIndents(model, opIndex, opOldIndent, opts || {}).forEach((r) => {
-      const el = spanEls[r.blockId];
-      if (el && (Number(el.getAttribute('data-indent')) || 0) !== r.indent) {
-        setBlockIndent(el, r.indent);
+    return indentClamp.clampIndents(model, opIndex, opOldIndent, opts || {})
+      .map((r) => ({ el: spanEls[r.blockId], indent: r.indent }))
+      .filter((r) => !!r.el);
+  }
+
+  function writeIndentClamp(answer) {
+    (answer || []).forEach((r) => {
+      if ((Number(r.el.getAttribute('data-indent')) || 0) !== r.indent) {
+        setBlockIndent(r.el, r.indent);
       }
     });
   }
 
+  function applyIndentClamp(spanEls, opBlockEl, opOldIndent, opts) {
+    writeIndentClamp(computeIndentClamp(spanEls, opBlockEl, opOldIndent, opts));
+  }
+
   function placeCaretAtEnd(el) {
     const range = document.createRange();
     range.selectNodeContents(el);
@@ -1692,6 +2009,30 @@
       '<path d="M6.6 7.2v4.2"/><path d="M9.4 7.2v4.2"/>',
     // MD 原始碼 — angle brackets: source, not prose.
     code: '<path d="M6 3.6L2 8l4 4.4"/><path d="M10 3.6L14 8l-4 4.4"/>',
+    // ── v3.0.1: one icon per 轉換成 target ────────────────────────────────
+    // Keys are CONVERT_TARGETS[].id verbatim; openConvertSubmenu() looks them
+    // up by that id, so a rename on either side must be made on both.
+    // 文字 — a paragraph pilcrow, drawn rather than typed so it inherits the
+    // same stroke weight as every sibling icon.
+    text: '<path d="M9 2.5H6.2a2.7 2.7 0 0 0 0 5.4H9"/><path d="M9 2.5v11"/><path d="M11.8 2.5v11"/>',
+    // 標題 1–6 — an "H" plus the level, as two strokes and a numeral bar set.
+    h1: '<path d="M3 3v10"/><path d="M8 3v10"/><path d="M3 8h5"/><path d="M11.5 6.5l1.5-1v7.5"/>',
+    h2: '<path d="M3 3v10"/><path d="M8 3v10"/><path d="M3 8h5"/><path d="M11 6.6a1.6 1.6 0 0 1 2.7 1.1c0 1.4-2.7 2.6-2.7 5.3h3"/>',
+    h3: '<path d="M3 3v10"/><path d="M8 3v10"/><path d="M3 8h5"/><path d="M11 5.8h2.7l-1.6 2.6a1.8 1.8 0 1 1-1.3 3"/>',
+    h4: '<path d="M3 3v10"/><path d="M8 3v10"/><path d="M3 8h5"/><path d="M13 5.8v7.2"/><path d="M13 10.7h-2.6l2.2-4.9"/>',
+    h5: '<path d="M3 3v10"/><path d="M8 3v10"/><path d="M3 8h5"/><path d="M13.5 5.8h-2.6v2.8a1.9 1.9 0 1 1-.5 3.6"/>',
+    h6: '<path d="M3 3v10"/><path d="M8 3v10"/><path d="M3 8h5"/><path d="M13.4 6.2a1.9 1.9 0 0 0-3 1.5v3.2a1.8 1.8 0 1 0 3.1-1.3 1.8 1.8 0 0 0-3.1 1.3"/>',
+    // 項目符號列表 — three dots with three rules.
+    ul: '<circle cx="3.2" cy="4.2" r="1"/><circle cx="3.2" cy="8" r="1"/><circle cx="3.2" cy="11.8" r="1"/>' +
+      '<path d="M6.4 4.2h7.4"/><path d="M6.4 8h7.4"/><path d="M6.4 11.8h7.4"/>',
+    // 編號列表 — the same three rules led by 1/2/3 strokes.
+    ol: '<path d="M2.2 3.4l1-.6v2.8"/><path d="M2 8.2a1 1 0 0 1 1.7.7c0 .9-1.7 1.6-1.7 2.4h1.9"/>' +
+      '<path d="M2.1 11.4h1.6l-1 1.1a1 1 0 1 1-.7 1.2"/>' +
+      '<path d="M6.4 4.2h7.4"/><path d="M6.4 8.6h7.4"/><path d="M6.4 12.9h7.4"/>',
+    // 待辦清單 — a checked box.
+    task: '<rect x="2.2" y="2.6" width="10.8" height="10.8" rx="2.4"/><path d="M5.2 8.2l2.1 2.1 3.8-4"/>',
+    // 引用 — a quote bar plus two shortened rules.
+    quote: '<path d="M3 3.4v9.2"/><path d="M6.4 5.4h7.2"/><path d="M6.4 8h7.2"/><path d="M6.4 10.6h4.6"/>',
   };
   function menuIconMarkup(name) {
     return '<svg class="ed-menu-icon" viewBox="0 0 16 16" width="16" height="16" ' +
@@ -1874,7 +2215,13 @@
       const b = document.createElement('button');
       b.type = 'button';
       b.className = 'ed-handle-menu-btn';
-      b.textContent = t.label;
+      // v3.0.1: the submenu carries icons too. Without them its labels start
+      // at the button's own padding while the parent menu's start past a 16px
+      // icon, so the two levels' text does not share a vertical line — the
+      // exact defect the user reported. `.ed-handle-menu-btn` is already a
+      // flex row with a gap, so an icon plus a text node is all it takes.
+      b.innerHTML = menuIconMarkup(t.id);
+      b.appendChild(document.createTextNode(t.label));
       b.setAttribute('aria-label', 'Convert to ' + t.id);
       b.addEventListener('click', (e) => {
         e.stopPropagation();
@@ -2558,6 +2905,48 @@
   const BATCH_GAP_MESSAGE = '選取範圍不連續，無法整批操作';
   const BATCH_MIXED_MESSAGE = '選取範圍同時含有清單項目與其他區塊，無法整批操作';
   const BATCH_MULTIRUN_MESSAGE = '選取範圍跨越兩個清單，無法整批操作';
+  // S4 Task 5: the ⠿ drag's cross-boundary refusals, one per CAUSE.
+  //
+  // Task 3 raised all of these with a single provisional constant
+  // (BLOCK_MOVE_LIST_SEAM_MESSAGE, '區塊搬移不能跨越清單邊界') and said THIS task
+  // owned the final wording. They are three different problems with three
+  // OPPOSITE remedies, so one sentence for all of them sends two thirds of
+  // the users to fix the wrong end of their own gesture:
+  //   * the SOURCE seam — the block cannot leave where it is, because the two
+  //     lists it stands between would join into one loose run. No destination
+  //     helps; the remedy is not to move it (or to move something else).
+  //   * the DESTINATION seam — the block cannot go INSIDE a list. The remedy
+  //     is to aim somewhere else, which is the exact opposite advice.
+  //   * OUT OF RUN — a list item may only move among its own §3.8 siblings.
+  //     The remedy is to stay inside its own list.
+  // Naming follows the BATCH_*_MESSAGE convention above. None of the three is
+  // a substring of another, of §4.3's own gate message, or of
+  // BLOCK_MOVE_ORPHAN_MESSAGE below — which is what lets a test assert WHICH
+  // refusal fired rather than that some banner mentioning 清單 appeared.
+  const BLOCK_MOVE_SOURCE_SEAM_MESSAGE = '移走這個區塊會讓上下兩串清單接在一起，無法搬移';
+  const BLOCK_MOVE_DEST_SEAM_MESSAGE = '無法把區塊放進清單項目之間';
+  const BLOCK_MOVE_OUT_OF_RUN_MESSAGE = '清單項目只能在所屬清單內搬移';
+  // S4 Task 7: what is LEFT of Task 4's indent refusal, and it is 14 drops out
+  // of 4067. §4.5's clamp is now performed (performListItemDrop() runs the
+  // removal half of the move through clampIndents()'s `{ removed: true }`),
+  // which answers every SOURCE-side orphan. What no removal-clamp can reach is
+  // the INSERTION half: a BATCH whose last member is SHALLOWER than the block
+  // it lands before leaves that block with no parent chain above it, at the
+  // NEW index, and §3.4 has no rule for that seam. MEASURED over every legal
+  // indent array of length 2..6 and depth 0..3, every operand-set size and
+  // every destination the run gate admits: 4067 drops, 1425 refused by Task
+  // 4's predicate, 14 still unanchored after the clamp — every one of them a
+  // multi-block set breaking at the block immediately after the landed set.
+  // (test/editor-client.test.js re-runs that sweep and pins all three numbers.)
+  //
+  // RE-WORDED with the narrowing, and the wording is the point: Task 4's
+  // 「搬移後子項目會失去上層項目，暫時無法搬移到這裡」 said "temporarily", which
+  // was true while the capability was missing and is a lie now that it is not.
+  // What is left is a DESTINATION objection with the same remedy
+  // BLOCK_MOVE_DEST_SEAM_MESSAGE has — aim somewhere else — so it says which
+  // end of the gesture is at fault. Still not a substring of any other refusal
+  // in this file, which is what lets a test assert WHICH one fired.
+  const BLOCK_MOVE_ORPHAN_MESSAGE = '落點的子項目會失去上層項目，無法搬移到這裡';
   // 轉換成's own refusals are NOT declared here. They are per block TYPE, and
   // they are the same ruling §3.7 applies to a single block's ⠿ — so they live
   // with that predicate, in BATCH_CONVERT_WITHHELD_MESSAGES above
@@ -3641,6 +4030,10 @@
     hideTableGrips();
     hideTableEdgeMenu();
     cancelTeDrag();
+    // S4 Task 2: and an in-flight ⠿ block drag, for the same reason — this
+    // resolution is about to commit and re-render whichever block it holds an
+    // ordinal into.
+    cancelBlockDrag();
     if (!burst) return true;
     // §10-gap fix (review): this burst's block's "pristine" window (see
     // `pristineInsert`'s own comment) closes right here, the moment its
@@ -3823,7 +4216,16 @@
     // S1 removed the pre-per-li 'list' branch that lived here: blockmap has not
     // emitted type:'list' blocks since Phase 4, so no startBurst() call could
     // produce blockType === 'list' and the branch was already dead code.
-    const result = burst.blockType === 'table' ? tableMd.serializeTable(burst.editEl)
+    // v3.0.1: hand the serializer the table's CURRENT source lines so it can
+    // reuse the author's own column widths instead of flattening the whole
+    // table to minimal form over a one-cell edit. extractBlockSource() is the
+    // same helper the raw editor prefills from, so "what the file says" has
+    // exactly one definition.
+    const tableBlockRec = burst.blockType === 'table'
+      ? blocks.find((b) => b.id === burst.blockId) : null;
+    const result = burst.blockType === 'table'
+      ? tableMd.serializeTable(burst.editEl,
+          tableBlockRec ? extractBlockSource(lines, tableBlockRec) : null)
       : inlineMd.serializeInline(burst.editEl);
     if (result.unsupported.length > 0) {
       // Degrade-never-lose (same contract as Phase 2's openWysiwygEditor()
@@ -5105,16 +5507,29 @@
   function indentListItem(blockEl) {
     const self = liAttrs(blockEl);
     if (!self) return false;
-    // Rule (d): the first item of a LIST has nothing above it to nest under.
-    // Without this the §3.4 clamp would happily read the previous list's last
-    // item as "the previous block" and indent this one underneath it, merging
-    // two lists the user never asked to join. Pre-S1 this fell out of
-    // `previousElementSibling` being null inside the item's own <ul>.
-    if (self.listStart) return false;
     const all = allBlockEls();
     const i = all.indexOf(blockEl);
     if (i < 0) return false;
     const prev = liAttrs(all[i - 1]);
+    // Rule (d), narrowed (v3.0.1). The old rule was `if (self.listStart)
+    // return false` — the first item of a LIST has nothing above it to nest
+    // under. That over-refused: a bullet outdented to indent 0 directly
+    // BELOW an ordered item is a listStart (a ul following an ol) whose
+    // previous block is a perfectly good parent, and the user could never
+    // indent it back. The half that still has to be refused is the one the
+    // old rule was really aimed at: two list tokens the user kept apart with
+    // a BLANK LINE. Indenting the second one makes listRunOf() span both,
+    // and re-serializing that span swallows the blank line — a rewrite of
+    // lines nobody touched, which is the one thing this editor must never do.
+    // Contiguity is a fact about the FILE, so it is read off `blocks`, not
+    // guessed from the DOM.
+    if (self.listStart) {
+      if (!prev) return false;
+      const prevRec = blockRecOf(all[i - 1]);
+      const selfRec = blockRecOf(blockEl);
+      if (!prevRec || !selfRec) return false;
+      if (prevRec.endLine + 1 !== selfRec.startLine) return false;
+    }
     const max = prev ? prev.indent + 1 : 0;
     const next = Math.min(self.indent + 1, max);
     if (next === self.indent) return false;
@@ -5191,22 +5606,39 @@
 
   // How far ONE member may move, as a magnitude (0 or 1), never a signed
   // delta. `dir` is +1 (Tab) or -1 (Shift+Tab). The ceiling restates
-  // indentListItem()'s own single-item rule — the list-start clause included,
-  // so a set that opens a list cannot nest itself under the previous list's
-  // last item — and the floor is outdentListItem()'s (indent 0 cannot rise).
-  // Both read PRE-move indents, which is §3.4's global convention ("the
-  // operated block's indent" always means the value before the operation), and
-  // it is what makes the minimum below well-defined: every member is measured
-  // against the document as it stands, not against members already moved.
+  // indentListItem()'s own single-item rule, v3.0.1's narrowed list-start
+  // clause included: a listStart member still refuses UNLESS the block
+  // immediately before it (by file line, via blockRecOf — same contiguity
+  // check, same code shape as indentListItem()'s, kept in that shape
+  // deliberately so the two stay in visible agreement) is a contiguous list
+  // item, in which case it has real head-room like any other item. Before
+  // v3.0.1 this was unconditional (`if (self.listStart) return 0;`) —
+  // batch Tab on a listStart block was refused outright, matching
+  // indentListItem()'s then-unconditional refusal. Narrowing ONE of the two
+  // without the other silently reintroduces the single-item defect on the
+  // batch axis: a listStart item directly below a contiguous ordered item,
+  // selected as part of a batch, would stay refused even though the very
+  // same block indents fine on its own. The floor is outdentListItem()'s
+  // (indent 0 cannot rise), untouched by this narrowing. Both read PRE-move
+  // indents, which is §3.4's global convention ("the operated block's
+  // indent" always means the value before the operation), and it is what
+  // makes the minimum below well-defined: every member is measured against
+  // the document as it stands, not against members already moved.
   function memberIndentHeadroom(el, dir) {
     const self = liAttrs(el);
     if (!self) return 0;
     if (dir < 0) return self.indent > 0 ? 1 : 0;
-    if (self.listStart) return 0;
     const all = allBlockEls();
     const i = all.indexOf(el);
     if (i < 0) return 0;
     const prev = liAttrs(all[i - 1]);
+    if (self.listStart) {
+      if (!prev) return 0;
+      const prevRec = blockRecOf(all[i - 1]);
+      const selfRec = blockRecOf(el);
+      if (!prevRec || !selfRec) return 0;
+      if (prevRec.endLine + 1 !== selfRec.startLine) return 0;
+    }
     const max = prev ? prev.indent + 1 : 0;
     return Math.max(0, Math.min(1, max - self.indent));
   }
@@ -5260,7 +5692,30 @@
       // segment delta for the blocks below instead of N independent clamps, and
       // its rule 1 then walks the operated blocks in document order so each is
       // measured against the member above it that the same pass just settled.
-      applyIndentClamp(run, liEls, oldIndent);
+      //
+      // v3.0.1 (review round 1 follow-up): `run` above is batchRunOf()'s
+      // PRE-mutation snapshot — the exact same staleness handleLiKeydown()'s
+      // single-item Tab branch had before its own v3.0.1 fix (see that
+      // call's comment). For a single-member batch on a listStart item whose
+      // ceiling memberIndentHeadroom() has just narrowed (a bullet directly
+      // below a contiguous ordered item), the pre-mutation run is `[liEls[0]]`
+      // alone — batchRunOf() never walked backward past the list-start
+      // boundary, because before this fix nothing could ever cross it. With
+      // no anchor IN the span, applyIndentClamp()'s rule 1 has nothing to
+      // bound the indent the forEach above just wrote against, and clamps it
+      // straight back to 0 — silently undoing the write, MEASURED directly:
+      // narrowing memberIndentHeadroom() alone left the covering test RED.
+      // A FRESH listRunOf(liEls[0]) call here — taken after the write above —
+      // walks back from the NEW indent and finds the real parent, exactly
+      // like the post-mutation `liveRun = listRunOf(liEls[0])` a few lines
+      // below (the COMMIT span) already does; using the same fresh call for
+      // the clamp keeps the two consistent, same reasoning as
+      // handleLiKeydown()'s Tab branch. Provably identical to the old stale
+      // `run` for every case where no member was ever a list-start
+      // (listRunOf() slices by INDEX RANGE, and neither the range's
+      // start/end index nor the elements between them shift when only
+      // already-run-member indents change).
+      applyIndentClamp(listRunOf(liEls[0]), liEls, oldIndent);
     });
     // Re-derived AFTER the mutation, like the caret Tab's: an indent change can
     // move a block between runs.
@@ -5491,7 +5946,26 @@
       const oldIndent = Number(li.getAttribute('data-indent')) || 0;
       const changed = mutateListRun(() => {
         if (!(e.shiftKey ? outdentListItem(li) : indentListItem(li))) return false;
-        applyIndentClamp(run, li, oldIndent);
+        // v3.0.1: `run` above is a PRE-mutation snapshot, captured while `li`
+        // still had its OLD indent. That is fine for outdentListItem() — the
+        // clamp's model rereads every element's CURRENT data-indent off the
+        // DOM, so it self-corrects regardless of which elements the snapshot
+        // names — but indentListItem() can now move a rule-(d) list-start
+        // item (a bullet directly below an ordered item, say) whose own
+        // pre-mutation run is `[li]` alone: nothing shallower ever preceded
+        // it, because runBlocksOf() stops at a list-start by design. With no
+        // anchor IN the span, applyIndentClamp()'s rule 1 has nothing to
+        // bound the indent this call just wrote against, and clamps it
+        // straight back to 0 — silently undoing the write. A FRESH
+        // listRunOf(li) call here — taken after the write above — walks back
+        // from li's NEW indent and finds the real parent, exactly like the
+        // post-mutation `run = listRunOf(li)` a few lines below (the COMMIT
+        // span) already does; using the same fresh call for the clamp keeps
+        // the two consistent. Provably identical to the old stale `run` for
+        // every case where li was never a list-start (listRunOf() slices by
+        // INDEX RANGE, and neither the range's start/end index nor the
+        // elements between them shift when only li's own indent changes).
+        applyIndentClamp(listRunOf(li), li, oldIndent);
         return true;
       });
       if (!changed) return true;
@@ -6063,8 +6537,12 @@
   function tableIdentityOf(tableEl) {
     const headerRow = tableEl ? headerRowOf(tableEl) : null;
     if (!headerRow) return null;
-    return allRowsOf(tableEl).length + '
' +
-      Array.prototype.slice.call(headerRow.cells).map((c) => c.textContent).join('');
+    // The two delimiters are written as ESCAPES, not as literal control
+    // bytes. They used to be literal, which made grep classify this whole
+    // 9643-line file as binary and SILENTLY TRUNCATE its output — a real
+    // investigation was misled by it. The runtime value is identical.
+    return allRowsOf(tableEl).length + '\x01' +
+      Array.prototype.slice.call(headerRow.cells).map((c) => c.textContent).join('\x00');
   }
   async function ensureTableBurstOpen(tableEl) {
     if (currentBurst && currentBurst.blockType === 'table' && currentBurst.editEl === tableEl) return tableEl;
@@ -6229,8 +6707,9 @@
   // grips below are the fix: real, adequately-sized (≥18×24px) elements the
   // user can actually see and aim for. Both grips are overlay elements
   // `position: fixed`-appended to document.body — never DOM CHILDREN of a
-  // contenteditable cell, even though the row grip's inner half visually
-  // overlaps one (it straddles the table's left border; see the geometry
+  // contenteditable cell, even though the row grip visually overlaps one
+  // (since §4.2 conflict 2 landed in S4 T1 it sits ENTIRELY inside the first
+  // column, within that cell's own widened left padding; see the geometry
   // note in the "Notion-style row/column grip handles" section below). So —
   // unlike the old zones, which
   // sat INSIDE an already-permanently-contenteditable cell and needed the
@@ -6543,20 +7022,59 @@
   // listener (wired near the bottom of this file) that already drives
   // updateTableInsertBubbles() — see its own comment for the coalescing
   // contract this reuses.
-  // Review fix (P0-a) + user acceptance (uniform geometry): neither grip is
-  // separated from the table, and both use the SAME rule — the grip's own
-  // CENTRELINE coincides with the table border it belongs to, so its hit
-  // rect straddles that border by half its own size on each side. COLUMN
-  // grip: centred on the table's TOP edge. ROW grip: centred on the table's
-  // LEFT edge. An earlier revision insetted the row grip fully INSIDE the
-  // table to dodge the block's own gutter ⠿; that was reverted — the ⠿
-  // occupies only the block's top ~20px while a row grip sits at its own
-  // row's mid-height, so the two never actually intersect, and the inset put
-  // the grip on top of the first cell's TEXT (user-acceptance defect). The
-  // gutter is given its own room in CSS instead (`.content { padding-left }`
-  // plus `.ed-handle/.ed-insert { left: -36px }`, both edit-mode-only — see
-  // lib/md2doc.js), so the straddling grip reaches only into the first
-  // cell's PADDING, never its text.
+  // Geometry, per axis (v3.0.1: they are mirror images again):
+  //   COLUMN grip: its CENTRELINE coincides with the table's TOP border, so
+  //     its hit rect straddles that border by half its own height on each
+  //     side (P0-a).
+  //   ROW grip: its CENTRELINE coincides with the table's LEFT border, so
+  //     its hit rect straddles that border by half its own width on each
+  //     side — same shape as the column grip, restored in v3.0.1 (spec §4.2
+  //     hit-test conflict 2).
+  //
+  // History: why the row axis briefly broke the symmetry, and how that was
+  // undone. The block's own gutter ⠿ hangs outside the content box, and a
+  // table block's own table starts at that same left edge, so a row grip
+  // centred on the table's left border occupied [blockLeft-10, blockLeft+10]
+  // and overlapped the ⠿'s right 6px. Both are position: fixed / absolutely
+  // positioned overlays and the grip is a document.body child at z-index 7,
+  // so the grip won that hit test whenever it was showing — which is
+  // whenever the pointer had recently been over a table cell. MEASURED on
+  // v2.12.0 at 1400x900 with the row grip parked on the HEADER row (the only
+  // row whose 28px-tall grip reaches the ⠿'s own top-20px band):
+  // elementFromPoint() walked across the table block's ⠿ at its vertical
+  // centre answered .ed-handle for x 390..401 and the ROW GRIP for x
+  // 402..407. S4 makes the ⠿ a drag handle, so those 6px would have started
+  // a table ROW drag instead of a block move.
+  //
+  // S4 T1 (v2.12.0) fixed that by INSETTING the grip instead — its left edge
+  // on the table's left border, entirely inside the table, no more straddle.
+  // That broke the row/column symmetry (the column grip still straddles the
+  // table's top border, because nothing of the page's own chrome lives up
+  // there) and was reported as a v3.0.1 visual regression. An even earlier
+  // revision (v2.10.1) had already tried an inset like it and been reverted,
+  // because a 20px grip inside a cell whose left padding is 14px sits on
+  // that cell's TEXT — S4 T1 avoided repeating that by widening the first
+  // column's own edit-mode padding to clear the inset grip.
+  //
+  // v3.0.1 undoes the inset rather than re-tuning it: the row grip goes back
+  // to straddling the border (this file's change, see updateTableEdgeGrips()
+  // below), and the ⠿/＋ pair itself moves further LEFT instead (a shift
+  // token declared alongside the gutter's own tokens in lib/md2doc.js) — the
+  // overlap is removed at its SOURCE, not by moving the grip out of the
+  // ⠿'s way. That also means the first column's edit-mode padding widening
+  // is gone: the grip's straddling half (10px) fits inside the column's
+  // default 14px padding on its own, so v2.10.1's original defect does not
+  // come back. Neither the ⠿'s right edge nor the grip's left edge is
+  // written down as a literal on either side of the gap between them — see
+  // the shift-token comment in lib/md2doc.js's edit-mode :root block, which
+  // this file deliberately does not name (test/editor-client.test.js forbids
+  // the retired hover-gutter class name as a bare substring and the token
+  // name contains it) — so the two cannot drift apart the way v2.11.0's pair
+  // position once did (the CSS comment claiming "an 8px gap" was describing
+  // that stale position, which v2.11.1 replaced).
+  // test/editor-client-runtime.test.js asserts BOTH directions: every pixel
+  // of a block's ⠿ answers that ⠿ (row grip hidden and showing), and the row
+  // grip's own centre answers the row grip.
   // Either way the grip's hit rect DOES overlap the insert bubble's hit
   // rect (the bubble extends TB_BUBBLE_SIZE/2 = 9px past the edge on its
   // own axis). Non-intersection via rect separation is no longer possible
@@ -6572,6 +7090,19 @@
   // reported overlap corner AND verifies the z-index ordering directly —
   // re-verify it if either the grip's or bubble's z-index ever changes.
 
+  // --ed-te-grip-row-w, read once and cached. The token is the single source
+  // of truth for the grip's width (lib/md2doc.js declares it); parsing it here
+  // means the JS never carries a second copy of the number.
+  let gripRowWidthCache = null;
+  function gripRowWidthPx() {
+    if (gripRowWidthCache !== null) return gripRowWidthCache;
+    const raw = getComputedStyle(document.documentElement)
+      .getPropertyValue('--ed-te-grip-row-w');
+    const n = parseFloat(raw);
+    gripRowWidthCache = Number.isFinite(n) && n > 0 ? n : 20;
+    return gripRowWidthCache;
+  }
+
   function buildTableGrip(cls, ariaLabel) {
     const b = document.createElement('button');
     b.type = 'button';
@@ -6635,12 +7166,18 @@
   // gripCenter(), which jump straight to the grip's own coordinates) could
   // ever land on it; a real mouse gesture could not.
   //
-  // Current geometry (uniform, both axes): BOTH grips straddle their own
-  // table border — the row grip half outside / half inside the table's LEFT
-  // border, the column grip half above / half below its TOP border. So the
-  // corridor-crossing bug described above applies to BOTH of them exactly as
-  // originally described, and both keep-zones below cover the corresponding
-  // outside-the-border corridor.
+  // Current geometry (v3.0.1 restored the row axis to mirror the column
+  // axis — see the "Notion-style row/column grip handles" section comment
+  // above for the S4 T1 detour into an inset row grip and how it was
+  // undone): BOTH grips straddle their own border again, the COLUMN grip
+  // half above / half below the table's TOP border and the ROW grip half
+  // outside / half inside the table's LEFT border. The corridor-crossing
+  // bug described above therefore applies to BOTH axes' straddling shape in
+  // principle, and pointInColGripZone() still covers the column's
+  // outside-the-border corridor exactly as before. pointInRowGripZone()
+  // deliberately does NOT get an equivalent corridor formula back, even
+  // though the straddle is back — see its own comment for why the padded
+  // grip rect alone is still sufficient.
   //
   // Review fix (Important, first pass over-permissive): the first version of
   // this fix kept a grip visible while the pointer was ANYWHERE within the
@@ -6653,14 +7190,28 @@
   // SPECIFIC shown grip's own anchor (pointInRowGripZone()/
   // pointInColGripZone() below) instead of the whole table.
   //
-  // What each keep-zone covers TODAY: both keep the ORIGINAL corridor shape,
-  // mirrored per axis. pointInRowGripZone() is the union of (the row grip's
-  // own rect, padded by TE_GRIP_ZONE_PAD_PX for sub-pixel rounding) and (the
-  // straight strip between the grip's own LEFT edge and the table's LEFT
-  // border, y clamped to the anchor ROW's own vertical extent, padded).
-  // pointInColGripZone() is the same with the axes swapped: the strip
-  // between the grip's own top edge and the table's top border, x clamped to
-  // the anchor COLUMN's own horizontal extent, padded.
+  // What each keep-zone covers TODAY:
+  //   pointInColGripZone() keeps the ORIGINAL corridor shape: the union of
+  //     (the column grip's own padded rect) and (the straight strip between
+  //     the grip's own TOP edge and the table's top border, x clamped to the
+  //     anchor COLUMN's own horizontal extent, padded). The column grip
+  //     straddles the top border, so that corridor is real.
+  //   pointInRowGripZone() is the padded grip rect ALONE, no corridor term —
+  //     kept that way through the v3.0.1 straddle restoration on purpose,
+  //     not left behind by accident. A pointer travelling from inside a body
+  //     cell to the row grip's own centre (which sits exactly on the
+  //     table's left border) never has to leave the table's horizontal
+  //     extent on the way there, so the padded rect alone already covers
+  //     every REAL (non-teleporting) approach this file's own test suite
+  //     exercises — see "table grips: the row grip straddles the table's
+  //     left border again…" in test/editor-client-runtime.test.js. That is
+  //     narrower than the column axis's guarantee (nothing approaches the
+  //     row grip from further out along the table's own left edge the way a
+  //     pointer can approach the column grip from above it), which is why
+  //     the two functions are allowed to stay asymmetric even though the
+  //     grips' shapes are not. If a future report finds a real pointer path
+  //     that does need a corridor term here, that is a new, separate defect
+  //     — not evidence this reasoning was wrong when it was written.
   // A pointer outside either grip's own zone is a genuine exit and still
   // hides the grip via hideTableGrips(), same as before. Neither fix touches
   // either grip's size or z-index, so the click-priority guarantee (bubble
@@ -6680,15 +7231,33 @@
   function pointInRowGripZone(x, y) {
     if (rowGrip.hidden || !gripRowTableEl || !gripRowEl ||
       !document.body.contains(gripRowEl) || !document.body.contains(gripRowTableEl)) return false;
-    const gr = rowGrip.getBoundingClientRect();
-    if (pointInPaddedRect(x, y, gr, TE_GRIP_ZONE_PAD_PX)) return true;
-    // grip 跨在表格左邊界上，所以「從儲存格走向 grip」必定經過邊界外側的
-    // 那半個 grip 寬度。走廊＝從 grip 自己的左緣到表格左緣，垂直方向夾在
-    // 所錨定那一列的上下緣（加 TE_GRIP_ZONE_PAD_PX 的次像素寬容）。
-    const rowRect = gripRowEl.getBoundingClientRect();
-    const tableRect = gripRowTableEl.getBoundingClientRect();
-    return x >= gr.left && x <= tableRect.left &&
-      y >= rowRect.top - TE_GRIP_ZONE_PAD_PX && y <= rowRect.bottom + TE_GRIP_ZONE_PAD_PX;
+    // v3.0.1 恢復跨界：row grip 的中心線重新落在表格左邊界上（不再是
+    // S4 T1 那個左緣頂在邊界上、整個縮進表格內側的做法）。與 ⠿ 的重疊
+    // 改在源頭解決——往左再位移的是頁面 gutter 的 ⠿/＋ 那一對按鈕本身
+    // （多移動一個位移 token，宣告在 lib/md2doc.js 的編輯模式 :root 區
+    // 塊，此檔案依慣例不直接引用其名稱），不是移動 grip。
+    //
+    // 走廊公式沒有跟著補回來，是刻意維持的範圍決定，不是漏掉：
+    // TE_GRIP_ZONE_PAD_PX=4 的 padded rect 涵蓋 [tableLeft-14,
+    // tableLeft+14]（grip 本身 20px 寬、跨在邊界上是 [tableLeft-10,
+    // tableLeft+10]，外加 4px 緩衝）。指標從儲存格內側走向 grip 中心
+    // （正好落在 tableLeft）的整段路徑，x 一律 >= tableLeft，從未離開
+    // 表格的水平範圍，所以「儲存格 -> grip」這條測試套件唯一驗證過的
+    // 真實（非瞬移）路徑，本來就不需要走廊公式。哪天真的量到一條需要
+    // 走廊的真實路徑（例如從表格左側、gutter 那一側靠近），那是新的、
+    // 獨立的缺陷，不代表這裡當初的推論錯了。
+    //
+    // 誠實記一筆巧合，不要誤讀成保證：⠿ 的右緣恰好落在 tableLeft-14，
+    // 與這個 padded rect 的左緣相觸、不重疊——這是 TE_GRIP_ZONE_PAD_PX
+    // 這個寫死的 4，與 lib/md2doc.js 那個 4px 呼吸間距 token 兩個各自
+    // 獨立宣告出來的巧合，不是誰推導誰的保證。任一邊數值改動，觸點都
+    // 可能變成 1px 縫隙或重疊，沒有任何型別檢查會抓到。這是既有狀態，
+    // 不是本次修正引入或修掉的東西。
+    //
+    // 對使用者可見的差別：離開表格左側不再等於立刻收掉 row grip——padded
+    // rect 本身就已經探出表格邊界 14px，所以指標要離開這整個 padded rect
+    // （水平或垂直）才會真的收掉，錨定那一列的高度也不例外。
+    return pointInPaddedRect(x, y, rowGrip.getBoundingClientRect(), TE_GRIP_ZONE_PAD_PX);
   }
 
   function pointInColGripZone(x, y) {
@@ -6717,9 +7286,10 @@
   function updateTableEdgeGrips(x, y, target) {
     // Both grips are `position: fixed` overlays appended to document.body
     // (same as the hover-insert bubbles) rather than descendants of the
-    // table — both PAINT half outside it (the column grip straddling the top
-    // border, the row grip straddling the left border). So the moment the
-    // real pointer crosses from a cell onto
+    // table — the column grip PAINTS half outside it (straddling the top
+    // border) and the row grip paints inside the first column (§4.2
+    // conflict 2). Either way neither is a table descendant, so the moment
+    // the real pointer crosses from a cell onto
     // the grip itself, `target` is the grip and is no
     // longer inside any '.ed-block[data-block-type="table"]' or 'th, td'.
     // Without this guard, that transition would hit the "nothing found"
@@ -6754,8 +7324,12 @@
     // Row grip: every row, including the header — the first row of a
     // markdown table IS the header, so any row must be draggable to the
     // top to become it. ONE position rule for all of them (user acceptance:
-    // 「grip 位置都一樣」) — centred on the table's left border, vertically
-    // centred on its own row; no header special case. The
+    // 「grip 位置都一樣」) — its CENTRELINE on the table's left border, i.e.
+    // straddling it half outside / half inside the table, restored in
+    // v3.0.1 (spec §4.2 hit-test conflict 2 — see the geometry note above
+    // buildTableGrip() for the S4 T1 detour into an inset grip and how it
+    // was undone), vertically centred on its own row; no
+    // header special case. The
     // one exception is a header-only table (no body rows): its single row
     // is thead's only row, and dragging it away would empty the thead —
     // serializeTable() would degrade it and the user's table would vanish
@@ -6764,12 +7338,20 @@
       gripRowTableEl = tableEl;
       gripRowEl = rowEl;
       const r = rowEl.getBoundingClientRect();
-      // Fallback dims match .ed-te-grip-row's own CSS width/height exactly
-      // (20x28) — offsetWidth/Height read 0 while `hidden` (display: none)
-      // is still true on the FIRST show of a hover session, before the
+      // Fallback height matches .ed-te-grip-row's own CSS height exactly
+      // (28) — offsetHeight reads 0 while `hidden` (display: none) is still
+      // true on the FIRST show of a hover session, before the
       // `hidden = false` assignment below takes effect.
-      const gw = rowGrip.offsetWidth || 20;
       const gh = rowGrip.offsetHeight || 28;
+      // v3.0.1: back to STRADDLING the table's left border (the S4 T1 inset
+      // was a workaround for the ⠿ hit-test overlap; the ⠿/＋ pair has
+      // since moved further left via a CSS shift token in lib/md2doc.js,
+      // which removes the overlap at its source). The width is read from the
+      // token rather than written as a literal here: offsetWidth reads 0
+      // while `hidden` is still true on the first show of a hover session,
+      // and a hard-coded fallback is exactly the CSS/JS drift the token
+      // exists to prevent.
+      const gw = rowGrip.offsetWidth || gripRowWidthPx();
       rowGrip.style.left = (tableRect.left - gw / 2) + 'px';
       rowGrip.style.top = (r.top + r.height / 2 - gh / 2) + 'px';
       rowGrip.hidden = false;
@@ -7124,6 +7706,820 @@
     currentBurst.history.snap('drag-col');
   }
 
+  // ── S4 Task 2: dragging a BLOCK by its ⠿ handle (spec §4.5) ─────────────
+  // The gesture SKELETON only — threshold, capture, drop-target computation,
+  // the indicator, and every cancellation path. THE DROP IS A NO-OP; Tasks
+  // 3-7 add the commits. §4.5 says to reuse the table row drag's skeleton
+  // above, and this does, including its central invariant:
+  //
+  //     NOTHING IN THE DOM IS MUTATED DURING A DRAG. Only the indicator moves.
+  //
+  // That is the whole reason cancelBlockDrag() can be called unconditionally
+  // from Escape / pointercancel / window blur / the next pointerdown /
+  // rerenderAll() / resolveBurst() with nothing to revert — see
+  // cancelTeDrag()'s own comment for the same argument on the row axis. It
+  // also means no `class=""` residue can reach a burst's zero-edit guard (the
+  // row path had to strip one by hand, because it DIMS the dragged <tr>; this
+  // gesture deliberately dims nothing, so the question never arises). Even the
+  // ⠿ menu, which lives as a CHILD of its block and would therefore be a
+  // content mutation to close, is left alone until the gesture is over.
+  // S4 Task 2b: the drag-cursor class, on `document.documentElement`. Named
+  // once so the add, the remove and lib/md2doc.js's rule cannot drift apart.
+  const BLOCK_DRAGGING_CLASS = 'ed-block-dragging';
+  const blockDropIndicator = document.createElement('div');
+  blockDropIndicator.className = 'ed-block-drop-indicator';
+  blockDropIndicator.hidden = true;
+  document.body.appendChild(blockDropIndicator);
+
+  // The drop-target candidates: the document's block sequence, in document
+  // order. MEASURED on this branch (1400x900, a doc mixing paragraphs, a
+  // heading, a list run with a nested item, a same-line-nest PHANTOM, a
+  // fenced code block and a table): every single `.ed-block` is a DIRECT
+  // child of `contentEl` — S1 flattened the <ul>/<ol> containers away — so
+  // allBlockEls() already IS that sequence, with no nesting to flatten and no
+  // second, overlapping y-range sitting inside another candidate's box.
+  // Named rather than inlined because Tasks 3-7 re-resolve against it.
+  function blockDropCandidates() {
+    return allBlockEls();
+  }
+
+  // Nearest block-drop target for `clientY` — a discriminated union:
+  //   {mode: 'before-block', blockIndex, y} | {mode: 'append', y}
+  // `blockIndex` is an ORDINAL into blockDropCandidates(); never a
+  // `data-block-id` (blockmap.js renumbers 0..n-1 on every render, so a
+  // captured id names the target's NEIGHBOUR after any commit that changes
+  // the block count) and never a node (a mid-gesture commit detaches them).
+  //
+  // spec §4.6 replaced the table's `{beforeRow, y}` with exactly this shape,
+  // because a null `beforeRow` had been overloaded to mean "append". That
+  // ruling is followed here rather than nearestColDropTarget()'s flat
+  // `{index, x}`, which is the one place it was never applied.
+  //
+  // There is no 'above-header' counterpart: a table's first row IS its
+  // header, so promoting a row to first place needed its own mode; the
+  // document has no such distinguished first block, and `before-block 0`
+  // already says "become the new first block".
+  function nearestBlockDropTarget(clientY) {
+    const els = blockDropCandidates();
+    for (let i = 0; i < els.length; i++) {
+      const r = els[i].getBoundingClientRect();
+      if (clientY < r.top + r.height / 2) {
+        return { mode: 'before-block', blockIndex: i, y: r.top };
+      }
+    }
+    const last = els[els.length - 1];
+    const rect = last ? last.getBoundingClientRect() : contentEl.getBoundingClientRect();
+    return { mode: 'append', y: rect.bottom };
+  }
+
+  // The in-flight ⠿ gesture, or null between gestures — the block-axis
+  // counterpart of `tePointer`. `sourceIndex` is the ORDINAL of the pressed
+  // block AT PRESS TIME, which is the table drop's own rule ("convert the
+  // pressed node to an ordinal first, re-resolve in the live DOM at drop
+  // time"): between the press and the release, resolveGutterOperands()'s
+  // switchAwayFrom() may commit some other dirty burst, re-render, and detach
+  // every node in the document. `dragging` flips true once
+  // TE_DRAG_THRESHOLD_PX is crossed; `dropTarget` is the union above, filled
+  // in by updateBlockDropIndicator() as the pointer moves.
+  let blockDragState = null;
+
+  // Arms the gesture for a press on a ⠿. Returns TRUE when it owns this
+  // pointer, so the `pointerdown` listener below can stop before it reaches
+  // beginShiftClickSelection()/armBlockSelDrag().
+  //
+  // Running FIRST is required and is also free: `.ed-handle` is a member of
+  // ED_SEL_GESTURE_CHROME, so armBlockSelDrag()'s very first line already
+  // returned for exactly this target (and beginShiftClickSelection()'s does
+  // too) — which is why a press on the ⠿ recorded NO pointer state at all
+  // before this task. Nothing about a press anywhere else changes.
+  //
+  // No preventDefault() here, deliberately. wireBlockSelection()'s delegated
+  // `mousedown` preventDefault() on `.ed-handle` is what keeps a dirty
+  // burst's focus intact across a ⠿ press — without it the press blurs the
+  // burst, the blur commits, the commit re-renders, the button is detached
+  // between mousedown and mouseup and the `click` never fires at all (the
+  // swallowed-first-click defect that fix exists for). Cancelling
+  // `pointerdown` additionally suppresses the compatibility `mousedown` in
+  // some engines, i.e. the very event that fix lives on. updateBlockDrag()
+  // does the preventDefault() instead, once the gesture is definitely a drag.
+  function armBlockDrag(e) {
+    const handleEl = e.target && e.target.closest ? e.target.closest('.ed-handle') : null;
+    if (!handleEl) return false;
+    const blockEl = handleEl.closest('.ed-block');
+    if (!blockEl) return false;
+    const index = blockDropCandidates().indexOf(blockEl);
+    if (index < 0) return false;
+    blockDragState = {
+      pointerId: e.pointerId,
+      sourceIndex: index,
+      // Carried for Tasks 3-7's own re-resolution cross-check only; the
+      // ORDINAL above is the identity, for the renumbering reason spelt out
+      // on `blockDragState`.
+      sourceBlockId: blockEl.getAttribute('data-block-id'),
+      startX: e.clientX, startY: e.clientY,
+      dragging: false,
+      dropTarget: null,
+      captureEl: null,
+    };
+    return true;
+  }
+
+  // Repositions the singleton line onto the current drop target. All four
+  // dimensions are written on every move — the node is this gesture's alone
+  // (see the class comment in lib/md2doc.js for why it is not the table's),
+  // but the content column can be resized by a sidebar drag or a window
+  // resize between two frames, so a partially-written box would leave a stale
+  // width behind.
+  function updateBlockDropIndicator(clientY) {
+    const target = nearestBlockDropTarget(clientY);
+    blockDragState.dropTarget = target;
+    const els = blockDropCandidates();
+    const spanEl = target.mode === 'append' ? els[els.length - 1] : els[target.blockIndex];
+    const r = spanEl ? spanEl.getBoundingClientRect() : contentEl.getBoundingClientRect();
+    blockDropIndicator.style.left = r.left + 'px';
+    blockDropIndicator.style.width = r.width + 'px';
+    blockDropIndicator.style.top = (target.y - 1) + 'px';
+    blockDropIndicator.style.height = '3px';
+  }
+
+  // Capture on documentElement at ENGAGE time, not at press time — the S3
+  // selection drag's reasoning (captureBlockSelDrag()) applies verbatim here
+  // and the table's does not. A press on a ⠿ that turns out to be a plain
+  // click must not be interfered with AT ALL: it has to reach `click` and open
+  // the menu. And the pressed node is a per-block button that rerenderAll()
+  // and openRawEditor()'s restore() both re-create, so capturing on it would
+  // pin a node the gesture can outlive.
+  function captureBlockDrag(e) {
+    const el = document.documentElement;
+    if (el && typeof el.setPointerCapture === 'function') {
+      try { el.setPointerCapture(e.pointerId); blockDragState.captureEl = el; }
+      catch (err) { /* not capturable here — the buttons/blur/cancel guards still apply */ }
+    }
+  }
+
+  function releaseBlockDragCapture(st) {
+    if (st && st.captureEl && typeof st.captureEl.releasePointerCapture === 'function') {
+      try { st.captureEl.releasePointerCapture(st.pointerId); } catch (err) { /* already released */ }
+    }
+  }
+
+  function updateBlockDrag(e) {
+    if (!blockDragState || e.pointerId !== blockDragState.pointerId) return;
+    if (tePointer) return; // a grip gesture owns this pointer
+    // The browser can simply never deliver a pointerup (released over browser
+    // chrome, over another window). The next move with no button held is the
+    // only signal left that the gesture is over — the same guard
+    // updateBlockSelDrag() carries, for the same reason.
+    // S4 Task 3: endBlockDrag() is async now. Deliberately not awaited here —
+    // `updateBlockDrag` is called from a `pointermove` listener that cannot
+    // await, and this branch is the last-resort recovery for a pointerup the
+    // browser never delivered. The teardown inside it is synchronous either
+    // way; only the drop's own commit trails.
+    if (typeof e.buttons === 'number' && e.buttons === 0) { endBlockDrag(); return; }
+    if (!blockDragState.dragging) {
+      const dx = e.clientX - blockDragState.startX, dy = e.clientY - blockDragState.startY;
+      if (Math.hypot(dx, dy) < TE_DRAG_THRESHOLD_PX) return;
+      blockDragState.dragging = true;
+      captureBlockDrag(e);
+      blockDropIndicator.hidden = false;
+      // S4 Task 2b (user request, 2026-09-01): the ONLY feedback the source
+      // block gets. `.ed-handle` is `opacity: 0` off-hover, so from the moment
+      // the pointer leaves the block there is nothing under the cursor but the
+      // indicator line. The ruling is a `cursor: grabbing` class on
+      // `document.documentElement` — OUTSIDE `contentEl`, so the "mutate
+      // nothing in the content DOM during a drag" invariant this whole gesture
+      // rests on still holds, and every cancellation path stays unconditional.
+      // The table drag's `ed-te-row-dragging` dim is deliberately NOT the
+      // model: it dims a node INSIDE the content, and the burst's zero-edit
+      // guard compares `contentEl`'s innerHTML, so the residue it leaves had
+      // to be stripped by hand.
+      //
+      // ⚠ CORRECTED (S4 review round, 2026-09-01). The earlier wording here
+      // and in §4.5 said documentElement AVOIDS that `class=""` residue. It
+      // does not. classList.add() on an element with no `class` attribute
+      // CREATES one and remove() only empties its value — measured in the same
+      // Chromium: `<html class="">` after every engaged drag, every time. The
+      // residue is not avoided, it is RELOCATED: `<html>` is a node nothing in
+      // this file compares, `contentEl.innerHTML` is a string the zero-edit
+      // guard reads on every commit. The ruling is unchanged (the cost really
+      // is zero); only its stated reason was wrong.
+      document.documentElement.classList.add(BLOCK_DRAGGING_CLASS);
+      // Nothing else is touched here. The table's hover chrome (insert
+      // bubbles, grips) is hidden by the rAF `mousemove` gate below, which is
+      // where the row drag and the S3 selection drag both do it too; and the
+      // ⠿ / ＋ menus are left alone until endBlockDrag(), because closing one
+      // detaches a node from INSIDE a block and would break the
+      // "nothing is mutated during a drag" invariant this whole gesture rests
+      // on.
+    }
+    e.preventDefault();
+    updateBlockDropIndicator(e.clientY);
+  }
+
+  // Shared teardown. Both exits below go through it, so a future drop added
+  // to endBlockDrag() can never be reached from a cancellation path.
+  function teardownBlockDrag() {
+    if (!blockDragState) return null;
+    const st = blockDragState;
+    blockDragState = null;
+    releaseBlockDragCapture(st);
+    blockDropIndicator.hidden = true;
+    // S4 Task 2b: removed HERE and nowhere else. T2 routed endBlockDrag() and
+    // cancelBlockDrag() through this one function precisely so a later
+    // addition inherits all five abort paths (pointerup, Escape,
+    // pointercancel, window blur, the next pointerdown / every re-render) for
+    // free. Unconditional on `.dragging`: classList.remove() of a class that
+    // was never added is a no-op, and a gesture that ended before the
+    // threshold never added it.
+    document.documentElement.classList.remove(BLOCK_DRAGGING_CLASS);
+    // A gesture that became a drag owns its own trailing `click`: released
+    // outside every block it would reach wireBlockSelection()'s
+    // switchAwayFrom(); released back over the ⠿ it started on it would OPEN
+    // THE MENU the user was not asking for. Same one-shot flag the S3
+    // selection drag sets, re-armed to false by the next pointerdown so a
+    // gesture whose click never arrives cannot swallow a later one.
+    if (st.dragging) blockSelClickSuppressed = true;
+    return st;
+  }
+
+  // The `pointerup` half. S4 Task 3 makes the drop REAL for a single block
+  // that is not a list item; Tasks 4-7 widen it. The teardown above is
+  // synchronous and happens FIRST, so the gesture is already over (indicator
+  // down, capture released, `ed-block-dragging` off <html>) before a single
+  // byte is considered — nothing the commit does can leave drag state behind.
+  //
+  // ASYNC, and the `pointerup` listener awaits it: the drop resolves an open
+  // burst and re-renders, and a fire-and-forget promise would let a test (or
+  // the next gesture) observe the document between the release and the
+  // commit's own /api/render.
+  async function endBlockDrag() {
+    const st = teardownBlockDrag();
+    if (!st || !st.dragging) return;
+    // The menus are closed AFTER the gesture rather than at engage: closing
+    // one detaches a node from inside a block, and mutating nothing during a
+    // drag is what makes every cancellation path above unconditional.
+    closeGutterMenu();
+    closeInsertMenu();
+    await performBlockDrop(st);
+  }
+
+  // ── S4 Task 3: the drop (spec §4.5) ───────────────────────────────────
+  // Everything up to here has been chrome. This is where the ⠿ drag writes
+  // bytes, through the pure commitBlockMove() above: ONE commitRangeEdit over
+  // the min..max span, hence exactly one Ctrl+Z.
+  //
+  // The pressed block is named by ORDINAL, never by node and never by id —
+  // the table drop's own rule. `blockmap.js` renumbers ids 0..n-1 on every
+  // render, so a captured id names the target's NEIGHBOUR after any commit
+  // that changes the block count, and every node in the document is detached
+  // by a re-render. The ordinal is resolved in the LIVE DOM here, before
+  // resolveGutterOperands() is allowed to commit anything.
+  //
+  // The DESTINATION needs the same protection and gets it one step earlier:
+  // its identity is captured BEFORE resolveGutterOperands(), whose
+  // switchAwayFrom() may commit some other block's dirty burst and re-render.
+  // reresolveBlockEl() then proves the block sitting at that start line
+  // afterwards really is the same one, exactly as the source's own re-resolve
+  // does; when it cannot, the gesture is DROPPED with a banner rather than
+  // completed against a block the user did not point at.
+  async function performBlockDrop(st) {
+    const target = st.dropTarget;
+    // ⚠ S4 Task 6 audited this for §3.6 (「靜默不動作是缺陷」) and it is the one
+    // silent exit in this function that NO GESTURE CAN REACH: performBlockDrop()
+    // is called only from endBlockDrag()'s `st.dragging` branch, engaging sets
+    // `dragging` and then calls updateBlockDropIndicator(), which assigns
+    // `dropTarget` UNCONDITIONALLY from nearestBlockDropTarget() — and that
+    // function has no null answer at all, falling through to
+    // `{mode:'append'}` when no block's mid-line is below the pointer. Kept as
+    // a defensive guard, not as a behaviour.
+    if (!target) return; // engaged but never moved onto a target — nothing to do
+    const els = blockDropCandidates();
+    const sourceEl = els[st.sourceIndex];
+    const destEl = target.mode === 'append' ? null : (els[target.blockIndex] || null);
+    if (!sourceEl || (target.mode !== 'append' && !destEl)) {
+      showBanner(DROPPED_GESTURE_MESSAGE, null, null);
+      return;
+    }
+    const destIdentity = destEl ? captureBlockIdentity(destEl) : null;
+    // ...and the SAME question resolveGutterOperands() asks about the source,
+    // asked about the destination, BEFORE the commit that answers it.
+    //
+    // S4 review round (2026-09-01), MEDIUM: a drop onto a block with an open
+    // DIRTY burst was ALWAYS refused. Measured on
+    // '# Doc\n\nalpha\n\nbravo\n\ncharlie\n' — type ' EDITED' into
+    // `charlie`, drag `alpha` onto charlie's top edge — and the answer was
+    // '文件已更新，請重試這個操作' with the edit committed and the move not.
+    //
+    // It is an ASYMMETRY, not a race, and it could not be anything else:
+    // reresolveBlockEl()'s fingerprint is the block's SOURCE, and the commit
+    // that changed that source is this drop's OWN resolveGutterOperands() →
+    // switchAwayFrom(). The fingerprint is therefore GUARANTEED to miss. The
+    // source side has had reresolveBlockElAfterSelfCommit() for exactly this
+    // since S2; this is its destination-side counterpart, gated the same way
+    // — on ownsOpenSession() read BEFORE the commit, because `currentBurst` is
+    // gone afterwards — so reresolveBlockEl() keeps its fingerprint for
+    // everybody else. Deliberately NOT a widening of that function: S2's own
+    // note says the narrowed variant exists precisely so no other caller loses
+    // the fingerprint.
+    const destSelfSession = destEl ? ownsOpenSession(destEl) : false;
+    // The shared gutter preamble — identity capture, switchAwayFrom(), the
+    // re-resolve after a commit that re-rendered, the no-source-line refusal
+    // and §3.3's membership. Not re-implemented here: 「不得另寫一條」.
+    const operands = await resolveGutterOperands(sourceEl);
+    if (!operands) return;
+    let liveDestEl = destEl;
+    if (destEl && !document.body.contains(destEl)) {
+      liveDestEl = reresolveBlockEl(destIdentity) ||
+        (destSelfSession ? reresolveBlockElAfterSelfCommit(destIdentity) : null);
+      if (!liveDestEl) { showBanner(DROPPED_GESTURE_MESSAGE, null, null); return; }
+    }
+    // ── S4 Task 6: THE OPERAND SET (spec §4.5, §3.3, §3.6) ────────────────
+    // §4.5: 「grip 在選取集合內 → 整批搬（3.3 的成員資格規則）」. Up to Task 5
+    // this read `if (operands.batch) return;` — the last two SILENT shapes in
+    // the drag path, which §3.6 calls a defect in so many words
+    // (「靜默不動作是缺陷」). From here down `opEls` is a span of one OR MORE
+    // blocks and every path takes it whole; nothing loops over it, for the
+    // reason convertBlockViaMenu() states — a commit between two members
+    // re-renders and invalidates every id in between.
+    const opEls = operands.els;
+    const opRecs = operands.recs;
+    // ── the FIRST home position, and it is shared by every kind and size ──
+    // A drop that lands where the block already is is a silent byte no-op —
+    // NOT a refusal and NOT a dropped gesture. It has to be answered before
+    // every gate, and MEASURED, because the gates get it wrong on their own:
+    // `before-block <sourceIndex>` — released on the block's own top edge,
+    // which is exactly what the drag's "released where it started" scenario
+    // drives — makes the destination the SOURCE, and the destination's index
+    // in the source-less array below is then -1, i.e. the
+    // '文件已更新，請重試這個操作' banner, for a gesture in which nothing
+    // whatsoever went wrong. Caught by driving a real gesture and reading the
+    // banner back; the byte assertions could not see it, because the file is
+    // untouched either way. For a SET the same question is membership: any
+    // member's top edge is the set's own footprint. The li path below has a
+    // SECOND home position of its own — see performListItemDrop().
+    if (liveDestEl && opEls.indexOf(liveDestEl) !== -1) return;
+    const shape = spanListKinds(opEls);
+    // §3.6's 2026-08-31 ruling, and the EXISTING banner: 「混合 span 一律拒絕」.
+    // A mixed span would need a blank-line rule at the run/non-run seam — the
+    // li half has to stay tight while the non-li half has to keep its
+    // separators, and inside ONE commit range those two demands conflict. §3.6
+    // records that the spec does not have that rule and that inventing it in
+    // the last stage repeats the §3.4 marker-width error, so this refuses with
+    // 建立副本 / 刪除 / 轉換's own message rather than a fifth move message.
+    //
+    // DELIBERATELY ABOVE the second home position, which is the one place this
+    // function departs from Task 3's "answer a home position before every
+    // gate" rule, and the departure is the point: a seam objection depends on
+    // where the user AIMED, so refusing a put-it-back gesture with one would
+    // be a banner for a gesture in which nothing went wrong. MIXED is a
+    // property of the SET — it gives the same answer at every destination, so
+    // there is no aim that would have worked and saying so is the honest
+    // outcome. (The drop-on-a-member case is already out, above.)
+    if (shape.anyLi && !shape.allLi) { refuseStructuralListEdit(BATCH_MIXED_MESSAGE); return; }
+    // S4 Task 4 / Task 6: a li source has its own path. Its lines cannot be
+    // relocated verbatim (markers and ordinals are run-global), so the whole
+    // run is re-serialized in the new span order instead — still ONE
+    // commitRangeEdit, still one Ctrl+Z. `shape.allLi` rather than the first
+    // member's type: a set is all-li or it is mixed, and mixed is already out.
+    // Everything below this line is the non-li move.
+    if (shape.allLi) {
+      await performListItemDrop(opEls, liveDestEl);
+      return;
+    }
+    // ── the SECOND home position, still before every gate ──────────────
+    // `before-block <sourceIndex + 1>` — the seam immediately below, the same
+    // position on screen — is a no-op planBlockMove() answers null for, but
+    // the list-seam gate below would have refused it OUT LOUD first whenever
+    // the block sits between two list items. (The first home position is
+    // answered above, before the li branch, because both kinds share it.)
+    const live = blockDropCandidates();
+    // The set's own two edges. `si` is its FIRST member and `sj` its LAST —
+    // the source seam is what stands OUTSIDE those, and asking `si + 1` for it
+    // would name the set's second member on any set of more than one.
+    const si = live.indexOf(opEls[0]);
+    const sj = live.indexOf(opEls[opEls.length - 1]);
+    const rest = live.filter((el) => opEls.indexOf(el) === -1);
+    const di = liveDestEl ? rest.indexOf(liveDestEl) : rest.length;
+    if (si < 0 || sj < 0 || di < 0) { showBanner(DROPPED_GESTURE_MESSAGE, null, null); return; }
+    // §3.3's set is contiguous in block order — resolveGutterOperands()'s own
+    // gate — so its members' lines plus the separators between them are ONE
+    // range, which is what makes a batch move the same single commitRangeEdit
+    // (and the same single Ctrl+Z) a one-block move is. See spanMoveRange().
+    const srcRec = spanMoveRange(opRecs);
+    const destRec = liveDestEl ? blockRecOf(liveDestEl) : null;
+    if (!srcRec || (liveDestEl && !destRec)) {
+      showBanner(DROPPED_GESTURE_MESSAGE, null, null);
+      return;
+    }
+    // A destination that owns no source line has an INVERTED range, and its
+    // startLine names the line its OWNER occupies — inserting there would put
+    // the block inside somebody else's territory.
+    //
+    // ⚠ S4 Task 6 MEASURED that this is REACHABLE, and that Task 3's comment
+    // here ("unreachable while the seam gate below holds") was wrong. It said
+    // so on the grounds that every no-line phantom this model produces is a
+    // li — true, and beside the point: the seam gate refuses a destination
+    // whose BOTH neighbours are li of one run, and a phantom's upper
+    // neighbour is very often not a li at all. Driven as a real gesture on
+    // '# Doc\n\npara\n\n- - b\n- c\n\ntail\n' (blockmap:
+    // heading{1,1} | para{3,3} | li{5,4} PHANTOM | li{5,5} | li{6,6} |
+    // para{8,8}): the phantom has a box of its own (measured top 190,
+    // bottom 215 at 1400x900), so nearestBlockDropTarget() names it like any
+    // other block; `rest[di - 1]` is the PARAGRAPH, so blockMoveSeamRefusal()
+    // answers null; and planBlockMove() answers a REAL plan for it
+    // ('# Doc\n\npara\n\ntail\n\n- - b\n- c\n'), so it is not a home
+    // position either. Dragging `tail` onto that phantom therefore did
+    // nothing, wrote nothing and said nothing — §3.6's 「靜默不動作是缺陷」,
+    // and the third silent shape this task owed on top of the two the plan
+    // named.
+    //
+    // The banner is the DESTINATION seam's, not a fifth constant: the line
+    // this drop names belongs to the phantom's own nested item, so the block
+    // really would land between an item and its sublist, which is exactly
+    // what 無法把區塊放進清單項目之間 says. The remedy it gives (aim
+    // somewhere else) is the correct one.
+    if (destRec && destRec.endLine < destRec.startLine) {
+      refuseStructuralListEdit(BLOCK_MOVE_DEST_SEAM_MESSAGE);
+      return;
+    }
+    // The second home position (see above): `null` means "already there".
+    // Asked BEFORE the seam gate so a put-it-back gesture is silent rather
+    // than refused. planBlockMove() is pure, so asking twice costs nothing.
+    if (!planBlockMove(lines, blocks, srcRec, destRec)) return;
+    // Both seams MEASURED with marked.lexer, not reasoned about:
+    //   destination — '# Doc\n\npara\n\n- a\n- b\n\ntail\n' with `para`
+    //     spliced between the two items lexes as list(1 item) | paragraph |
+    //     list(1 item): ONE two-item run became TWO one-item runs, and the
+    //     blank lines rule 3 emits are §4.3's looseness trap;
+    //   source — '# Doc\n\n- a\n\npara\n\n- b\n' with `para` lifted out
+    //     leaves '- a\n\n- b\n', which lexes as ONE list, loose === TRUE.
+    //     Every item then renders as <p>, serializeBlocks() reports 'P' for
+    //     each, and the whole run degrades read-only WITH NO BANNER.
+    // S4 Task 5 NARROWED the destination half of this and deliberately left
+    // the source half wide; blockMoveSeamRefusal()'s own header carries the
+    // full enumeration and the measurement behind every row of it. The short
+    // version: an insertion can only SPLIT, so the destination only has to
+    // refuse a seam INSIDE one run; a removal MERGES, and the model does not
+    // carry the raw bytes (the bullet character, the leading two spaces) that
+    // decide whether two runs about to become adjacent stay two lists.
+    //
+    // The descriptor is built from listRunOf() — §3.4 rule 2's scope — so a
+    // nested child and its parent answer the same run key, which is what
+    // stops "a paragraph dropped between an item and its own sublist" from
+    // reading as a boundary between two separate lists.
+    const seamDesc = (el) => {
+      if (!el || !el.getAttribute || el.getAttribute('data-block-type') !== 'li') return null;
+      const r = listRunOf(el);
+      return { runKey: r.length ? r[0].getAttribute('data-block-id') : null };
+    };
+    const seamRefusal = blockMoveSeamRefusal(
+      { prev: seamDesc(live[si - 1]), next: seamDesc(live[sj + 1]) },
+      { prev: seamDesc(rest[di - 1]), next: seamDesc(rest[di]) });
+    if (seamRefusal === 'source') {
+      refuseStructuralListEdit(BLOCK_MOVE_SOURCE_SEAM_MESSAGE);
+      return;
+    }
+    if (seamRefusal === 'destination') {
+      refuseStructuralListEdit(BLOCK_MOVE_DEST_SEAM_MESSAGE);
+      return;
+    }
+    const result = commitBlockMove({ lines, blocks, stack }, srcRec, destRec);
+    // commitRangeEdit()'s own unchanged-text answer, or a refused inverted
+    // range. Neither pushed an op, so there is nothing to render or roll back.
+    //
+    // ⚠ S4 Task 6 audited this too, and corrected Task 3's claim that neither
+    // is reachable. The inverted-range half is not (planBlockMove() has
+    // already answered a real plan). The UNCHANGED-TEXT half is: MEASURED on
+    // 'same\n\nsame\n\ntail\n' with the first paragraph moved past the
+    // second, planBlockMove() answers a genuine plan and the text it produces
+    // is the file byte-for-byte, because the two blocks are identical. That
+    // is a real byte no-op — the document after the gesture IS the document
+    // before it — so it stays silent for Task 3's own reason. A banner here
+    // would tell a user that a move they can SEE succeeded had failed.
+    if (!result.op) return;
+    const prevLines = lines;
+    lines = result.lines;
+    // §3.3's collapse, declared IMMEDIATELY before the render and never
+    // earlier: the moved block's range in the NEW document, which is where a
+    // standing selection must end up. declareCollapse()'s own `if
+    // (blockSelection)` guard is what stops this single-block gesture from
+    // INVENTING a selection when none was standing.
+    declareCollapse(result.newRange);
+    const okRender = await safeRerenderAll();
+    if (!okRender) {
+      lines = rollbackFailedRender({ lines, stack }, result, prevLines);
+    }
+  }
+
+  // ── S4 Task 4: the drop of a LIST ITEM, inside its own run (spec §4.5) ──
+  //
+  // Task 3's drop returned SILENTLY for a li. §3.6 is explicit that
+  // 「靜默不動作是缺陷」, so after this function a li drag either MOVES or
+  // refuses WITH A BANNER; the only silent outcome left is a home position,
+  // which is Task 3's own ruling (a drop where the block already is is a byte
+  // no-op, not a refusal) and is answered in two places here.
+  //
+  // THE SHAPE IS duplicateListItems()'s, and the recon named it as the only
+  // existing path that already expresses a reorder as ONE commit:
+  //   * capture `presetRange` BEFORE mutating — runRangeOfBlocks() takes the
+  //     FIRST and LAST members of the array it is handed on the written
+  //     assumption that the array is in DOCUMENT order, which the reordered
+  //     span is not;
+  //   * build the REORDERED SPAN ARRAY (serializeBlocks() emits in array
+  //     order, and rebuilds its width/counter/type stacks as it walks — the
+  //     output is entirely determined by that order);
+  //   * mutateListRun() to move the node, with the focusout suppressed;
+  //   * commitListStructure(span, …, {presetRange, carryOver}), where
+  //     `carryOver` is bystanderCarryOver(span) — built AFTER the reorder and
+  //     BEFORE `blocks` is rebuilt — so every block's ORIGINAL bytes are
+  //     replayed by id and nothing is re-escaped ('~5px' would otherwise come
+  //     back '\~5px'). Only the marker and the leading columns are re-stated,
+  //     which is exactly §3.8's renumbering and §3.4's colDelta.
+  // One commitRangeEdit inside commitListStructure() is one undo op, which is
+  // §3.4's requirement for one gesture.
+  //
+  // `data-list-start` is a POSITION property, not an item property. It is the
+  // only carrier of "marked's lexer opened a list token here" (§3.8 rule (d))
+  // and serializeBlocks() resets its ordinal counter on it, so a reorder that
+  // changes which item stands FIRST has to carry it across — the mirror image
+  // of duplicateListItems() stripping it from a copy. MEASURED, on
+  // '1. alpha / 2. bravo / 3. charlie' with charlie dragged to the head:
+  // without the transfer the attribute stays on `alpha`, which is now the
+  // span's SECOND block, and the run comes back
+  // '1. charlie / 1. alpha / 2. bravo'.
+  //
+  // SCOPE — and it is exactly the task's title, "within its own run". The
+  // destination must be a slot between the item's own §3.8 RUN SIBLINGS, or
+  // the slot immediately past the last of them. Everything else is a
+  // cross-boundary move: out of the list entirely, into a nested sublist, into
+  // a different run. Task 5 owns that enumeration and the ruling it implements
+  // is already made — refused with a banner in 3.0.0 — so they are refused
+  // here with Task 5's own constant rather than half-implemented.
+  //
+  // S4 Task 6 widened `liEl` to `liEls` — §3.3's operand set, one OR MORE list
+  // items in document order. The whole function is the same commit: the set is
+  // contiguous in block order (resolveGutterOperands()'s gate), and `run` is a
+  // contiguous slice of the document (listRunOf()'s own contract), so the
+  // members occupy CONSECUTIVE slots of `run` and "move them" is one call to
+  // reorderSpanRange() with a count instead of two paths.
+  async function performListItemDrop(liEls, destEl) {
+    const liEl = liEls[0];
+    const lastLiEl = liEls[liEls.length - 1];
+    // §3.4 rule 2's scope, and the span commitListStructure() re-serializes:
+    // the OUTERMOST run reachable from this item plus every descendant of its
+    // members. Not the item's own sibling run — a span that STARTS at indent 2
+    // has no width recorded for depths 0 and 1 and would be emitted with no
+    // indent prefix at all, i.e. committing it would de-nest the whole thing.
+    const run = listRunOf(liEl);
+    const srcIdxs = liEls.map((el) => run.indexOf(el));
+    const srcIdx = srcIdxs[0];
+    if (srcIdx < 0) { showBanner(DROPPED_GESTURE_MESSAGE, null, null); return; }
+    // A member outside the grip's own commit span means the set straddles TWO
+    // runs — contiguity in `blocks` does not imply one run, because two
+    // adjacent runs separated by a delimiter change ('- a' / '1. b') are
+    // adjacent blocks with no phantom between them. Same answer
+    // convertBlockViaMenu() gives, through the same message: the commit
+    // re-serializes ONE run's line range and a member outside it would be
+    // rewritten by a range that does not cover it.
+    if (srcIdxs.indexOf(-1) !== -1) { refuseStructuralListEdit(BATCH_MULTIRUN_MESSAGE); return; }
+    // ...and they must be CONSECUTIVE slots of it. Guaranteed today by
+    // spanIsContiguous() plus listRunOf() returning a contiguous slice, and
+    // checked anyway rather than asserted in prose: reorderSpanRange() takes a
+    // `from` and a `count`, so a gap here would silently drag a NON-member
+    // along with the set.
+    for (let k = 1; k < srcIdxs.length; k++) {
+      if (srcIdxs[k] !== srcIdxs[k - 1] + 1) { refuseStructuralListEdit(BATCH_GAP_MESSAGE); return; }
+    }
+    const all = blockDropCandidates();
+    // ── the SECOND home position ───────────────────────────────────────
+    // `before-block <sourceIndex + 1>` is the seam immediately below the item,
+    // which is the same place on screen as its own top edge. For an item WITH
+    // CHILDREN that next block is its own first child, and "before my own
+    // first child" is precisely where it already is; for the run's LAST item
+    // it is the block AFTER the run, which must be read as "already there"
+    // and not as a boundary crossing. Answered before every gate, for Task 3's
+    // reason: a refusal here would be a banner for a gesture in which nothing
+    // went wrong.
+    const afterSrcEl = all[all.indexOf(lastLiEl) + 1] || null;
+    if (destEl ? destEl === afterSrcEl : all[all.length - 1] === lastLiEl) return;
+    // ── §4.3's run-wide gate ───────────────────────────────────────────
+    // 「轉換／建立副本／刪除／拖曳一律在 mutation 前走
+    // listRunSupportsStructuralEdit()」. There is no shared helper — the four
+    // existing call sites each make the call themselves — so this one does
+    // too. Its input is §3.4 rule 2's scope, which is exactly what listRunOf()
+    // returns. Ahead of every OTHER refusal, the convention convertBlockViaMenu()
+    // states: a run that cannot be structurally edited at all must say so,
+    // rather than report whichever narrower objection is asked next.
+    //
+    // `columnOnly` is the honest option, and it is the same argument
+    // insertBlockBelow()'s li path and the rule-2 merge already make: a
+    // reorder rewrites NO item's CONTENT and NO item's LINE COUNT. The only
+    // bytes that move in any member are its marker and its leading columns —
+    // §3.8's renumbering, applied to a replayed bystander as §3.4's colDelta —
+    // which is the criterion listRunSupportsStructuralEdit() documents.
+    // Without it a single hard-wrapped item anywhere in the run would veto
+    // every drag, which on this repo's own CHANGELOG.md is every run (80.6% of
+    // its list items are hard-wrapped).
+    if (!listRunSupportsStructuralEdit(run, null, { columnOnly: true })) {
+      refuseStructuralListEdit();
+      return;
+    }
+    // ── the destination must be a slot in the item's OWN §3.8 run ──────
+    // `sibs` is that run: the same-depth members listRunOf() walked out from.
+    // The two legal shapes are "before sibling S" and "past the last
+    // sibling's whole subtree" — the latter being the ONLY way to name the
+    // end of a run that something follows, since the drop target can only ever
+    // name a block, and the block it names there is outside the run.
+    const sibs = runBlocksOf(liEl);
+    const lastSib = sibs[sibs.length - 1];
+    const sibTail = subtreeBlocksAfter(lastSib, Number(lastSib.getAttribute('data-indent')) || 0);
+    const runEndEl = sibTail.length ? sibTail[sibTail.length - 1] : lastSib;
+    const afterRunEl = all[all.indexOf(runEndEl) + 1] || null;
+    let insertAt = -1;
+    if (destEl === null) {
+      // The {mode:'append'} target is "after the document's last block", so it
+      // names the end of this run only when the run ends the document.
+      if (afterRunEl === null) insertAt = run.indexOf(runEndEl) + 1;
+    } else if (sibs.indexOf(destEl) !== -1) {
+      insertAt = run.indexOf(destEl);
+    } else if (destEl === afterRunEl) {
+      insertAt = run.indexOf(runEndEl) + 1;
+    }
+    // All four out-of-run shapes land here: a slot between two non-li, a
+    // DIFFERENT run, the middle of a run of another list type, and the
+    // {mode:'append'} target when a block follows the run. Task 5 gave them
+    // their own message — the remedy is "stay inside your own list", which
+    // neither seam message says.
+    if (insertAt < 0) { refuseStructuralListEdit(BLOCK_MOVE_OUT_OF_RUN_MESSAGE); return; }
+    // `null` is the order-is-unchanged answer — the two home positions above
+    // reach this by another road (an item whose next block is a sibling), and
+    // it stays SILENT for the same reason.
+    const order = reorderSpanRange(run.length, srcIdx, srcIdxs.length, insertAt);
+    if (!order) return;
+    // Captured BEFORE the reorder, and this is the whole reason duplicateListItems()
+    // captures it too: runRangeOfBlocks() reads the first and last members of
+    // the ARRAY, and the reordered span's first member is not the run's first
+    // line.
+    const range = runRangeOfBlocks({ lines, blocks, stack }, run);
+    if (!range) { showBanner(DROPPED_GESTURE_MESSAGE, null, null); return; }
+    const span = order.map((i) => run[i]);
+    // ── THE SEAM TASK 7 OWNS — §4.5's indent clamp ─────────────────────
+    //
+    // §4.5: the moved item keeps its own `data-indent` (nothing here writes
+    // one) and 「子項留在原地（依 3.4 位移夾取）」 — the children it leaves
+    // behind are re-anchored by §3.4.
+    //
+    // THE MEASUREMENT THIS IS BUILT ON, and it is the correction of Task 4's.
+    // Task 4 measured that handing `applyIndentClamp()` the REORDERED span
+    // clamps nothing — true, and for a reason that names its own remedy:
+    // rule 2's scope starts after the operated block's NEW index, while the
+    // orphans are left behind at its OLD one. A move IS a REMOVAL at the old
+    // index plus an INSERTION at the new one, so the orphans are the removal's
+    // business and `{ removed: true }` — the mode the ⠿ delete has used since
+    // S1 — is exactly the right question, asked of `run` in DOCUMENT order
+    // (which it still is: nothing has touched the DOM yet). `clampIndents()`
+    // reports no indent for a removed block, so the travelling members' own
+    // depths are never rewritten by this; the reorder below then re-inserts
+    // them at the destination unchanged. NOTHING in indent-clamp.js changed,
+    // no new mode, no §3.4 amendment.
+    //
+    // Two things the sweep settled that prose could not (every legal indent
+    // array of length 2..6 and depth 0..3 × every operand-set size × every
+    // destination the gate above admits = 4067 drops; the pin is in
+    // test/editor-client.test.js):
+    //
+    //  1. §4.5 also says the moved block is 「落點使其非法時夾到合法值」. That
+    //     has NO reachable case: 0 of the 4067 leave the moved block's own
+    //     indent illegal, because the destination gate above only ever admits
+    //     a slot among its own same-depth siblings and the block standing
+    //     before such a slot can always parent it. If that gate is ever
+    //     widened (3.1.0) this becomes owed — and rule 1 of clampIndents()
+    //     already answers it, on the span, at the new index.
+    //  2. The clamp does not answer everything. 14 of the 4067 stay
+    //     unanchored, all of them BATCH sets whose last member is SHALLOWER
+    //     than the block they land before — the INSERTION half, at the new
+    //     index, for which §3.4 has no rule. Those keep Task 4's refusal,
+    //     narrowed to them and re-worded with it.
+    //
+    // ORDER MATTERS: compute, judge, and only then write. A refusal that has
+    // already written `data-indent` leaves a half-clamped DOM behind on a
+    // gesture that wrote no bytes — the same screen/model disagreement the
+    // clamp exists to prevent, produced by the clamp itself.
+    const clamp = computeIndentClamp(run, liEls, spanMinIndent(liEls), { removed: true });
+    const clamped = new Map();
+    (clamp || []).forEach((r) => { clamped.set(r.el, r.indent); });
+    if (!spanIndentsAreAnchored(span.map((el) => ({
+      type: el.getAttribute('data-block-type') === 'li' ? 'li' : 'other',
+      indent: clamped.has(el) ? clamped.get(el)
+        : (Number(el.getAttribute('data-indent')) || 0),
+    })))) {
+      refuseStructuralListEdit(BLOCK_MOVE_ORPHAN_MESSAGE);
+      return;
+    }
+    // S4 review round (2026-09-01): this WRITE is load-bearing, and it took a
+    // measurement to show it. Deleting the line left all 39 S4 scenarios green
+    // — the four T7 ones named after the clamp included — because every one of
+    // them moves a SINGLE item, and for `count === 1` the write can never
+    // change a byte: serializeBlocks() rebuilds its width stack as it walks
+    // (`widths.length = indent + 1` after every block), so an over-deep
+    // `data-indent` is emitted at its anchor's own column, which is the column
+    // the clamp would have written. Re-run over the whole 4067-drop space with
+    // the real serializeBlocks() on both sides: 0 single-item drops differ, 53
+    // BATCH drops differ on a `ul` and 123 on an `ol`. The smallest is indents
+    // 0,0,1,2,1 with {1,2} moved past the run — without the write the orphan
+    // that kept its departed parent's depth is ADOPTED by a block the user
+    // never touched, which is rule 3's own worked failure. Pinned as bytes by
+    // the RV2 runtime scenario and as counts in test/editor-client.test.js.
+    writeIndentClamp(clamp);
+    const sibsAfter = span.filter((el) => sibs.indexOf(el) !== -1);
+    mutateListRun(() => {
+      // `data-list-start` follows the run's HEAD, not the item — see this
+      // function's own header for the measured '1. charlie / 1. alpha' that
+      // dropping this produces. Only the moved item can change which sibling
+      // stands first, so this is the only pair that can need it; a NESTED
+      // run's own list-start belongs to a member nothing moved and is left
+      // exactly where it is.
+      if (sibsAfter[0] !== sibs[0] && sibs[0].getAttribute('data-list-start') === '1') {
+        sibs[0].removeAttribute('data-list-start');
+        sibsAfter[0].setAttribute('data-list-start', '1');
+      }
+      // `insertAt` indexes `run`, which is still in document order at this
+      // point — the DOM has not been touched yet. `insertAt === run.length`
+      // cannot be the moved item's own slot (that is the home position, out
+      // above), so the reference node is safe to read off the run's last
+      // member.
+      const refEl = insertAt < run.length ? run[insertAt] : run[run.length - 1].nextSibling;
+      // In the set's OWN order, each before the same reference node: that
+      // leaves them consecutive and in document order at the destination,
+      // which is what reorderSpanRange() already said the span would be. A
+      // loop that inserted each before the PREVIOUS one would reverse the set.
+      liEls.forEach((el) => { el.parentNode.insertBefore(el, refEl); });
+    });
+    // AFTER the reorder and BEFORE `blocks` is rebuilt, which is the window
+    // bystanderCarryOver() documents. No `mutatedEl`: nothing in this span had
+    // its CONTENT rewritten — the map is what keeps every member byte-
+    // identical to the file, the moved one included.
+    const carryOver = bystanderCarryOver(span);
+    // §3.3's collapse, declared immediately before the render inside
+    // commitListStructure(). declareCollapse()'s own `if (blockSelection)`
+    // guard is what stops this single-block gesture from INVENTING a
+    // selection when none was standing; when one WAS, resolveGutterOperands()
+    // has already collapsed it onto this item, so it has to follow the item
+    // to its new lines.
+    declareCollapse(movedLiRangeAfterReorder(span, liEls, carryOver, range));
+    await commitListStructure(span, null, false,
+      { presetRange: range, carryOver: carryOver });
+  }
+
+  // The moved item's line range in the run AS IT IS ABOUT TO BE COMMITTED.
+  //
+  // Deliberately NOT runLineOfBlock(), and this is a measurement that
+  // contradicts the obvious reuse: that function derives the run's start line
+  // with runRangeOfBlocks(runEls), which takes the FIRST member of the array —
+  // correct for every existing caller, whose array is in document order, and
+  // wrong here by construction, because the reordered span's first member is
+  // whichever item was just moved to the head. The rest of its arithmetic is
+  // reproduced: `lineMeta` carries one entry per EMITTED line naming the block
+  // that owns it, so a block's range is the run of entries bearing its id —
+  // counted, never assumed to be one, because a hard-wrapped item replays
+  // several.
+  //
+  // S4 Task 6: `liEls` is §3.3's operand set, one or more. The members travel
+  // together and stay consecutive, so their emitted lines are one contiguous
+  // run and the answer is the FIRST line of the first member to the LAST line
+  // of the last — which is exactly §3.3's 「操作結果所涵蓋的行區間」. Taking
+  // the first member's range alone would collapse a three-block drag onto one
+  // tinted block.
+  function movedLiRangeAfterReorder(span, liEls, carryOver, range) {
+    const ids = liEls.map((el) => el.getAttribute('data-block-id'));
+    if (ids.indexOf(null) !== -1) return null;
+    const { lineMeta } = listMd.serializeBlocks(span, { carryOver: carryOver || null });
+    let first = -1;
+    let last = -1;
+    lineMeta.forEach((m, i) => {
+      if (ids.indexOf(m.blockId) === -1) return;
+      if (first < 0) first = i;
+      last = i;
+    });
+    if (first < 0) return null;
+    return { startLine: range.startLine + first, endLine: range.startLine + last };
+  }
+
+  // Unconditional teardown of the in-flight ⠿ gesture — called from FIVE
+  // places, exactly mirroring cancelTeDrag()'s own list: the Escape
+  // prologue's first rungs, `pointercancel`, window `blur`, the defensive
+  // clear at the top of the next `pointerdown`, and every re-render path
+  // (rerenderAll() / resolveBurst()). Nothing was mutated, so there is
+  // nothing to revert and no state this is unsafe to be called from — the
+  // null-out is unconditional on `blockDragState` being set and is NOT gated
+  // on `.dragging`, which is the review fix cancelTeDrag() carries too (a
+  // burst resolution landing during the pressed-but-pre-threshold window used
+  // to leave the table's state pointing at a row rerenderAll() was about to
+  // detach).
+  function cancelBlockDrag() {
+    teardownBlockDrag();
+  }
+
   document.addEventListener('pointerdown', (e) => {
     if (e.button !== 0) return;
     if (e.target.closest && e.target.closest('.ed-te-menu')) return; // the menu's own buttons handle themselves
@@ -7134,6 +8530,10 @@
     // capture) BEFORE starting a new one, so a stuck drag can never survive
     // into the next gesture and a fresh pointerdown always starts clean.
     if (tePointer) cancelTeDrag();
+    // S4 Task 2: same defensive reasoning again for the ⠿ block drag — a prior
+    // gesture whose pointerup/pointercancel never arrived must not survive into
+    // this one. Nothing was mutated, so this is always a clean no-op teardown.
+    if (blockDragState) cancelBlockDrag();
     // S3 Task 4: same defensive reasoning one line up, for the block-selection
     // press — and the flag that suppresses a gesture's own trailing click is
     // re-armed here so a gesture whose click never arrived cannot swallow the
@@ -7163,6 +8563,26 @@
       // still wins" true by construction: a second, competing pointerdown
       // listener would have to re-derive the hit test, and would race this
       // one's menu dismiss above depending on registration order.
+      // S4 Task 2 (spec §4.5): the ⠿ drag arms HERE, ahead of both selection
+      // entries, and claims the pointer when it owns it. It has to run before
+      // armBlockSelDrag(), whose first line returns for `.ed-handle` (a member
+      // of ED_SEL_GESTURE_CHROME) — which is why a press on the ⠿ recorded no
+      // pointer state at all before this task. beginShiftClickSelection()
+      // returns for the same target, so ordering it above the Shift branch too
+      // changes nothing for any press that is not on a ⠿: armBlockDrag()
+      // returns false for every other target and falls straight through.
+      //
+      // S4 review round (2026-09-01) — RECORDED, because nobody had. It DOES
+      // change one thing for a press that IS on a ⠿: armBlockDrag() reads no
+      // modifier, so Shift / Ctrl / Alt + ⠿ now starts a drag, where before S4
+      // it did nothing at all until release. KEPT, deliberately: the table's
+      // row and column grips take the pointer with no modifier check either
+      // (see the `if (!hit)` branch's else, below), so a ⠿ that behaved
+      // differently would be the surprise; neither §3.3 nor §4.5 gives a
+      // modified ⠿ press a meaning of its own; and a modified press that never
+      // crosses the threshold still opens the menu, so nothing was taken away.
+      // Pinned by the RV5 scenario in test/editor-client-runtime.test.js.
+      if (armBlockDrag(e)) return;
       if (e.shiftKey) { beginShiftClickSelection(e); return; }
       armBlockSelDrag(e);
       return;
@@ -7224,12 +8644,30 @@
     updateBlockSelDrag(e);
   });
 
+  // S4 Task 2: the ⠿ block drag's own pointermove. Registered alongside the
+  // other two rather than folded into either: the table drag's listener bails
+  // on `!tePointer` (the state this one runs in) and the selection drag's bails
+  // on `!blockSelDrag` (likewise). updateBlockDrag()'s own first lines are the
+  // symmetric bail.
+  document.addEventListener('pointermove', (e) => {
+    updateBlockDrag(e);
+  });
+
   document.addEventListener('pointerup', async (e) => {
     // S3 Task 4: recon hazard 2 — there is no `mouseup` listener anywhere in
     // this file, so the block-selection drag ends on the pointer events, the
     // same skeleton the table drag uses. Before the `!tePointer` bail: a
     // selection drag is armed precisely when no grip gesture is in flight.
     endBlockSelDrag();
+    // S4 Task 2: and the ⠿ block drag's. Same placement reasoning as the line
+    // above — a block drag is armed precisely when no grip gesture is in
+    // flight, so it must be ended before the `!tePointer` bail.
+    // S4 Task 3: AWAITED, now that the drop writes. endBlockDrag()'s own
+    // teardown runs synchronously (an async function body runs to its first
+    // await), so the `tePointer` branch below is not reordered around any
+    // state it reads; what the await buys is that the commit and its
+    // re-render are complete before this handler returns.
+    await endBlockDrag();
     if (!tePointer) return;
     const st = tePointer;
     releaseTeCapture(st);
@@ -7275,6 +8713,9 @@
   // actually moved mid-drag, only the indicator line).
   document.addEventListener('pointercancel', () => {
     cancelTeDrag();
+    // S4 Task 2: the same abort ends a ⠿ block drag. Nothing was mutated (only
+    // the indicator moved), so this is the same unconditional cleanup.
+    cancelBlockDrag();
     // S3 Task 4: the same abort ends a block-selection drag. The selection it
     // has built so far STANDS (§4.4: nothing but Escape and a plain click
     // clears) — what must not survive is the live drag, or the next stray
@@ -7291,6 +8732,9 @@
   // when no gesture is in flight, so this is safe to fire on every blur.
   window.addEventListener('blur', () => {
     cancelTeDrag();
+    // S4 Task 2: same again for the ⠿ block drag — an undeliverable pointerup
+    // is an undeliverable pointerup whichever gesture is holding it.
+    cancelBlockDrag();
     // S3 Task 4: §4.4 says window blur does NOT clear the selection — but the
     // drag in flight when focus left is exactly as undeliverable-pointerup as
     // a row drag's, so it is torn down here too.
@@ -7937,6 +9381,11 @@
     // closeGutterMenu() first, so gutterMenuBlockEl is null by then.
     if (e.key === 'Escape') {
       if (tePointer && tePointer.dragging) { e.preventDefault(); cancelTeDrag(); return; }
+      // S4 Task 2: the ⠿ block drag gets the same first rung, and for the same
+      // reason — Escape-during-a-drag is a distinct gesture from
+      // Escape-reverts-the-burst, and the drag must be the one that answers.
+      // Mutually exclusive with the rung above (one pointer, one gesture).
+      if (blockDragState && blockDragState.dragging) { e.preventDefault(); cancelBlockDrag(); return; }
       if (teMenuKind || teHighlightEls.length) { e.preventDefault(); hideTableEdgeMenu(); return; }
       if (gutterMenuBlockEl || insertMenuBlockEl) {
         e.preventDefault();
@@ -8312,6 +9761,20 @@
         hideTableGrips();
         return;
       }
+      // S4 Task 2: and a third, in the same shape, for the ⠿ block drag —
+      // without it this listener would keep repainting the ＋ bubbles and
+      // repositioning the grips onto whatever row the cursor is dragging
+      // across, on top of the drop indicator, every frame of the gesture. Both
+      // are HIDDEN rather than merely left un-recomputed, so anything already
+      // showing from the frame before the threshold was crossed cannot linger
+      // stale. Unlike the table gate above there is no "active grip" to spare:
+      // the drag's own handle is a per-block button that the pointer has
+      // already left, and the indicator is the whole of the feedback.
+      if (blockDragState && blockDragState.dragging) {
+        hideTableInsertBubbles();
+        hideTableGrips();
+        return;
+      }
       updateTableInsertBubbles(tbMoveX, tbMoveY, tbMoveTarget);
       updateTableEdgeGrips(tbMoveX, tbMoveY, tbMoveTarget);
     });