@helping-ai-workflow/md2doc 2.12.0 → 3.0.0

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);
@@ -2558,6 +2875,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 +4000,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
@@ -6229,8 +6592,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 +6907,46 @@
   // 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 (they are NOT mirror images — see below):
+  //   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 LEFT EDGE coincides with the table's LEFT border, so the
+  //     whole grip is INSIDE the table. This is spec §4.2 hit-test
+  //     conflict 2's ruling, landed in S4 T1.
+  //
+  // Why the row axis had to break the symmetry. The block's own gutter ⠿
+  // hangs outside the content box at [blockLeft-22, blockLeft-4], and a
+  // table block's own table starts AT blockLeft, 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.
+  //
+  // An earlier revision (v2.10.1) already tried the inset and was reverted,
+  // because a 20px grip inside a cell whose left padding is 14px sits on
+  // that cell's TEXT. That is fixed on the CSS side this time rather than by
+  // giving the grip back its outside half: lib/md2doc.js pads the first
+  // column to --ed-te-cell-pad-left (the grip's own width plus the gutter
+  // pair's breathing gap) in EDIT MODE ONLY. The ⠿ ↔ grip clearance that
+  // remains is exactly that same breathing-gap token — see the edit-mode
+  // :root block in lib/md2doc.js, which spells both tokens out; this file
+  // deliberately does not name them, because test/editor-client.test.js
+  // forbids the retired hover-gutter class name as a bare substring and the
+  // token names contain it. Neither edge is written down twice, so the two
+  // cannot drift apart again — drift is what produced this defect (the CSS
+  // comment claiming "an 8px gap" was describing v2.11.0's pair 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
@@ -6635,12 +7025,16 @@
   // 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 (the two axes DIVERGED in S4 T1, §4.2 conflict 2): the
+  // COLUMN grip still straddles the table's TOP border, half above / half
+  // below, so the corridor-crossing bug described above still applies to it
+  // exactly as originally described and pointInColGripZone() still covers
+  // the outside-the-border corridor. The ROW grip is now entirely INSIDE the
+  // table (its left edge on the table's left border), so a pointer
+  // travelling from a cell to it never leaves the table and there is no
+  // corridor to cross — pointInRowGripZone() is the padded grip rect alone.
+  // See its own comment for why the old formula was deleted rather than
+  // left in place to evaluate to the empty set.
   //
   // 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 +7047,30 @@
   // 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 — and the two axes diverged when §4.2
+  // conflict 2 moved the row grip inside the table (S4 T1):
+  //   pointInColGripZone() still 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 still straddles the top border, so that corridor is still real.
+  //   pointInRowGripZone() is now the padded grip rect ALONE. Its corridor
+  //     was the strip between the grip's own LEFT edge and the table's LEFT
+  //     border; with the grip's left edge ON that border the strip is empty,
+  //     and §4.6 explicitly warns that leaving the formula in place would
+  //     make it (and the two scenarios downstream of it) silently vacuous
+  //     rather than red. It is deleted rather than left to read as if it did
+  //     something. Nothing is lost: the corridor existed because a pointer
+  //     travelling from a cell to a border-straddling grip had to leave the
+  //     table on the way, and a grip that is entirely inside the table has no
+  //     such approach — the pointer goes cell -> grip, and the
+  //     `target.closest('.ed-te-grip-row')` early return at the top of
+  //     updateTableEdgeGrips() covers the moment it arrives. The observable
+  //     change is that leaving the table on the left now hides the row grip
+  //     immediately, at the anchor row's own height as well as at any other
+  //     row's; the scenario named below asserts both halves, because "hidden
+  //     at another row's height" alone is true of any geometry once the
+  //     corridor is gone.
   // 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 +7090,17 @@
   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;
+    // §4.2 衝突 2（S4 T1）之後 row grip 整個落在表格內側，左緣就壓在表格
+    // 左邊界上，所以舊的走廊公式 `x >= gr.left && x <= tableRect.left` 塌成
+    // 空集合。§4.6 已經預告過這件事：留著它不會變紅，只會變成空測。這裡
+    // 直接刪掉，keep-zone 只剩 grip 自己的 padded rect。
+    // 走廊本來只為了一件事存在——指標從儲存格走向一個跨在邊界上的 grip
+    // 時必定會先離開表格；grip 內移之後那條路徑整段都在表格內（先是
+    // 儲存格，接著是 grip 自己，由 updateTableEdgeGrips() 開頭那個
+    // `target.closest('.ed-te-grip-row')` 早退接手），所以沒有走廊可走。
+    // 對使用者可見的差別是：從左側離開表格會立刻收掉 row grip，錨定那一
+    // 列的高度也不例外。
+    return pointInPaddedRect(x, y, rowGrip.getBoundingClientRect(), TE_GRIP_ZONE_PAD_PX);
   }
 
   function pointInColGripZone(x, y) {
@@ -6717,9 +7129,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 +7167,11 @@
     // 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 LEFT EDGE on the table's left border, i.e.
+    // entirely inside the table (spec §4.2 hit-test conflict 2, landed
+    // S4 T1 — see the geometry note above buildTableGrip() for the
+    // measurement that forced it), 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,13 +7180,19 @@
       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
-      // `hidden = false` assignment below takes effect.
-      const gw = rowGrip.offsetWidth || 20;
+      // 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. There is no width
+      // fallback any more, and that is the point: the left edge is the
+      // table's own border, so the grip's WIDTH is not an input to its
+      // position at all. It used to be (`tableRect.left - gw / 2`), which
+      // meant the CSS width and this literal `20` had to agree for the
+      // gutter clearance to hold — exactly the drift §4.2 conflict 2 is
+      // about. The width now lives in one place only, the
+      // --ed-te-grip-row-w token in lib/md2doc.js.
       const gh = rowGrip.offsetHeight || 28;
-      rowGrip.style.left = (tableRect.left - gw / 2) + 'px';
+      rowGrip.style.left = tableRect.left + 'px';
       rowGrip.style.top = (r.top + r.height / 2 - gh / 2) + 'px';
       rowGrip.hidden = false;
     } else {
@@ -7124,6 +7546,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 +8370,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 +8403,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 +8484,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 +8553,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 +8572,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 +9221,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 +9601,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);
     });