@helping-ai-workflow/md2doc 2.10.1 → 2.11.1

package/lib/md2doc.js

@@ -175,23 +175,98 @@ try {
   process.exit(1);
 }
 
-// Render one list token into per-li ed-block HTML.
-// biRef is a shared box { v: <int> } that advances through blocks[] in the
-// same DFS order as blockmap.js pushListItemBlocks:
+// S1: render one list token into a FLAT sequence of per-li ed-block HTML.
+// There is NO <ul>/<ol> container and no <li> — every list item, at every
+// depth, is a top-level `<div class="ed-block" data-block-type="li">` sibling
+// of every other block, and nesting is carried by `data-indent` alone.
+//
+// `biRef` is a shared box that advances through blocks[] in the same DFS order
+// as blockmap.js pushListItemBlocks:
 //   1. Push the item's own block.
 //   2. Recurse into that item's nested child lists, left-to-right.
 //   3. Move on to the next sibling item.
-// RULING F-L: use marked.Parser.parseInline ONLY when the item is tight
-// (!item.loose) AND its own non-list tokens are exactly one 'text' token.
+// The ONLY change from the pre-S1 nested renderer is WHERE the child HTML
+// lands — as a sibling in the same output array, never inside the parent's
+// element.
+//
+// RULING F-L is unchanged: use marked.Parser.parseInline ONLY when the item is
+// tight (!item.loose) AND its own non-list tokens are exactly one 'text' token.
 // In every other case emit marked.parser(ownTokens) so that loose items keep
 // their <p> wrapper — list-md.js detects loose items by the <p> and flags them
-// as unsupported per-li (spec §8). Stripping the <p> would cause silent
-// data-shape corruption on the first edit.
-function renderEditModeList(listToken, blocks, biRef) {
-  const tag = listToken.ordered ? 'ol' : 'ul';
-  const startAttr = (listToken.ordered && listToken.start && listToken.start !== 1)
-    ? ` start="${listToken.start}"` : '';
-  const items = listToken.items.map((item) => {
+// unsupported per-li (spec §8). Stripping the <p> would be silent data-shape
+// corruption on the first edit.
+//
+// The marker's TEXT is deliberately NOT written into the HTML: a `.ed-li-marker`
+// span is emitted empty and CSS draws the bullet / ordinal / checkbox, so
+// renumbering a run never has to redraw the DOM. Two hooks exist purely for
+// that CSS (they have no consumer inside this function, and none in this
+// task — see the S1 plan's controller note R1):
+//   * `style="--ed-indent:<indent>"` — the indent custom property.
+//   * `data-run-start="1"` on the FIRST block of every run — where an ordered
+//     list's CSS counter must reset.
+// `data-run-start` uses spec §3.8's run rule, and it is the SAME rule
+// lib/editor/list-md.js's serializeBlocks() applies when it restarts an
+// ordinal: a run starts when the previous block is not an li, OR is shallower,
+// OR is at the same depth with a different data-list-type. Deeper items never
+// break the run they are nested under, which is why `types` (the last list
+// type seen AT EACH DEPTH) is consulted rather than the immediately previous
+// block — a nested item sitting between two same-depth items must not make a
+// list-type change invisible. If this and serializeBlocks() ever disagree, the
+// symptom is wrong ordinals or a wrong commit range.
+//
+// THIRD hook, and a spec gap this task had to close: `data-list-start="1"` on
+// the first block of EVERY marked list token, at every depth. Spec §3.8's three
+// operational rules cannot separate two ADJACENT lists of the same type —
+// `marked.lexer('- a\n* c\n')` returns TWO list tokens (a bullet-char change
+// starts a new list, blank line or not) whose blocks are all
+// data-indent="0" data-list-type="ul", i.e. indistinguishable to rules (a),
+// (b) and (c). Before flattening, the two <ul> roots carried that distinction;
+// afterwards nothing did, and a run scan merged them — re-markering and
+// re-flowing a list the user never touched. The renderer is the only place
+// that still knows where marked's token boundaries were, so it stamps them,
+// and the client's run scan treats the attribute as rule (d): a run never
+// crosses a data-list-start AT ITS OWN DEPTH.
+//
+// "Every token", not "every TOP-LEVEL token": the same delimiter-change shape
+// nests. `- a / (2sp)1. x / (2sp)1) y / - d` is an outer ul plus TWO nested ol
+// tokens, and stamping only the outer one renumbered `1) y` to `2. y`.
+// listRunOf() spans the outermost run PLUS its subtrees, so a nested token
+// boundary is always inside a span serializeBlocks() is handed — the earlier
+// claim that a cross-list span could never reach it was wrong.
+function liRunStartsHere(runState, b) {
+  const prev = runState.prevLi;
+  const isStart = !prev || b.indent > prev.indent || runState.types[b.indent] !== b.listType;
+  for (let k = runState.types.length - 1; k > b.indent; k--) runState.types[k] = undefined;
+  runState.types[b.indent] = b.listType;
+  runState.prevLi = b;
+  return isStart;
+}
+
+// A new list TOKEN closes every run open at its own depth or deeper, and
+// leaves the shallower ones alone — the depths ABOVE a nested sublist are
+// still inside the same enclosing list, so `- a / (2sp)1. x / - d` must not
+// treat `- d` as opening a new top-level run.
+function resetLiRunStateAtDepth(runState, indent) {
+  runState.types.length = Math.min(runState.types.length, indent);
+}
+
+// Rule (c): any non-li block terminates every open run, at every depth.
+function resetLiRunState(runState) {
+  runState.prevLi = null;
+  runState.types = [];
+}
+
+function renderEditModeList(listToken, blocks, biRef, out) {
+  const parts = out || [];
+  // EVERY list token begins a new list, at whatever depth it sits: close the
+  // runs open at that depth and below (never the shallower ones — see
+  // resetLiRunStateAtDepth) so this token's first block is stamped, then stamp
+  // it. The token's depth is its first item's block indent; the render walk and
+  // blockmap.js consume blocks[] in lockstep, so blocks[biRef.v] is that block.
+  let listStart = true;
+  const firstBlock = blocks[biRef.v];
+  resetLiRunStateAtDepth(biRef, firstBlock ? firstBlock.indent : 0);
+  listToken.items.forEach((item) => {
     const b = blocks[biRef.v++];
     const ownTokens = item.tokens.filter((tk) => tk.type !== 'list');
     let inner;
@@ -201,22 +276,44 @@ function renderEditModeList(listToken, blocks, biRef) {
       inner = marked.Parser.parseInline(ownTokens[0].tokens);
     } else {
       // Loose item or non-standard own-token shape: use marked.parser, which
-      // emits block-level HTML (including <p> for loose items).  The <p>
+      // emits block-level HTML (including <p> for loose items). The <p>
       // presence is load-bearing for list-md.js's loose-item detection.
-      inner = marked.parser(ownTokens);
+      // Trimmed because the surface is `white-space: pre-line` (see the CSS):
+      // marked pretty-prints a trailing "\n" after the closing tag, which is
+      // insignificant to every serializer (list-md.js drops it via isBlankText)
+      // but would render as a phantom blank line inside the item.
+      inner = marked.parser(ownTokens).trim();
     }
-    const check = b.listType === 'task'
-      ? `<span class="ed-li-check" data-checked="${b.checked ? 1 : 0}" role="checkbox" aria-checked="${b.checked}"></span>`
+    // The receiving half of list-md.js's SETEXT ESCAPE (see
+    // escapeSetextHazard() there): an empty list item that is the first child
+    // of a deeper nesting is written to disk as `- <U+200B>`, because a bare
+    // `-` on that line is a setext H2 underline for the parent's own text and
+    // destroys both blocks. The zero-width space is the serializer's, not the
+    // user's, so it is taken back off here — the surface renders EMPTY, which
+    // is what keeps the next keystroke from landing next to an invisible
+    // character and writing it back out inside the user's own text.
+    if (/^\u200b+$/.test(inner)) inner = '';
+    const check = b.task
+      ? `<span class="ed-li-check" data-checked="${b.checked ? 1 : 0}" role="checkbox" aria-checked="${!!b.checked}"></span>`
       : '';
+    const runStart = liRunStartsHere(biRef, b) ? ' data-run-start="1"' : '';
+    const listStartAttr = listStart ? ' data-list-start="1"' : '';
+    listStart = false;
+    parts.push(
+      `<div class="ed-block" data-block-id="${b.id}" data-block-type="li"` +
+      ` data-list-type="${b.listType}" data-task="${b.task ? 1 : 0}" data-indent="${b.indent}"` +
+      runStart + listStartAttr + ` style="--ed-indent:${b.indent}">` +
+      `<span class="ed-li-marker" aria-hidden="true"></span>` + check +
+      `<div class="ed-li-text">${inner}</div>` +
+      `</div>`
+    );
     // Recurse into nested child lists AFTER this item's block (matches
-    // pushListItemBlocks order: own block → nested lists → next sibling).
-    const children = item.tokens.filter((tk) => tk.type === 'list')
-      .map((ct) => renderEditModeList(ct, blocks, biRef)).join('\n');
-    return `<li class="ed-block" data-block-id="${b.id}" data-block-type="li"` +
-      ` data-list-type="${b.listType}" data-indent="${b.indent}">` +
-      check + `<div class="ed-li-text">${inner}</div>` + children + '</li>';
+    // pushListItemBlocks order: own block -> nested lists -> next sibling).
+    // The child HTML is pushed into the SAME array, as a SIBLING.
+    item.tokens.filter((tk) => tk.type === 'list')
+      .forEach((ct) => renderEditModeList(ct, blocks, biRef, parts));
   });
-  return `<${tag}${startAttr}>\n${items.join('\n')}\n</${tag}>`;
+  return parts.join('\n');
 }
 
 async function renderMarkdown(mdText, srcPath, opts = {}) {
@@ -616,6 +713,29 @@ ${itemsHtml}
       return inlineImagesInHtmlChunk(baseHtml.apply(this, arguments));
     };
 
+    // Spec §3.12 — a markdown HARD BREAK and a literal '<br>' the source spelled
+    // out by hand both reach the DOM as an identical <br> element, and
+    // lib/editor/inline-md.js sees only the DOM. So editing ANY block holding a
+    // hard break degraded it to a literal '<br>' and cost the file a line
+    // (measured, list AND paragraph: '- a··' / '  b ~t' -> '- a<br>b \~t').
+    //
+    // THIS LAYER is the only place the two are still distinguishable: marked
+    // lexes a hard break as a `br` token, which arrives here, and a literal
+    // '<br>' as an inline `html` token, which goes to renderer.html above
+    // (verified: marked.lexer('x  \ny')[0].tokens -> ['text','br','text'] while
+    // marked.lexer('x<br>y')[0].tokens -> ['text','html','text']). That
+    // separation holds because `breaks: false` is pinned in the setOptions()
+    // call below — under breaks:true every single newline would arrive here too
+    // and the marker would stop meaning "hard break".
+    //
+    // Edit mode only: reader and PDF output must stay byte-identical, and the
+    // attribute has no reader-side meaning. The Shift+Enter literal-'<br>'
+    // round-trip contract is untouched by construction — such a <br> never
+    // passes through this function.
+    if (opts.editMode) {
+      renderer.br = function() { return '<br data-hard-break="1">'; };
+    }
+
     renderer.code = function(token) {
       // token is either a string (old API) or {text, lang} object (new API)
       const lang = (typeof token === 'object') ? (token.lang || '') : (arguments[1] || '');
@@ -774,13 +894,17 @@ ${itemsHtml}
       // using the same renderer/options set above.
       const tokens = marked.lexer(mdPre);
       const parts = [];
-      const biRef = { v: 0 };
+      // `v` is the block cursor; `prevLi`/`types` are the §3.8 run state the
+      // flat list renderer above threads through its own recursion (see
+      // liRunStartsHere()).
+      const biRef = { v: 0, prevLi: null, types: [] };
       for (const t of tokens) {
         if (t.type === 'space') continue;
         if (t.type === 'list') {
           parts.push(renderEditModeList(t, blocks, biRef));
           continue;
         }
+        resetLiRunState(biRef); // §3.8 rule (c): a non-li block ends every run
         const b = blocks[biRef.v++];
         const inner = marked.parser([t]);
         parts.push(
@@ -788,6 +912,14 @@ ${itemsHtml}
           inner + '</div>'
         );
       }
+      // Development-time alignment guard: the render walk and blockmap.js's
+      // pushListItemBlocks must consume blocks[] in lockstep. A mismatch means
+      // the two DFS orders have drifted apart, which silently mis-attributes
+      // every subsequent block id — far better to fail loudly here.
+      if (biRef.v !== blocks.length) {
+        throw new Error('edit-mode render consumed ' + biRef.v +
+          ' blocks but the block map has ' + blocks.length);
+      }
       bodyHtml = parts.join('\n');
     } else {
       bodyHtml = marked.parse(mdPre);
@@ -939,6 +1071,220 @@ ${itemsHtml}
   });
 </script>`;
 
+  // Edit-mode-only layout: give the block gutter (⠿ / ＋) its own room.
+  //
+  // The stylesheet above is SHARED by reader HTML, PDF export and edit mode,
+  // so a bare `.content { padding-left }` there would shift every rendered
+  // document — not wanted. This chunk is emitted ONLY when opts.editMode is
+  // set, and it is a ruleset of its OWN (never merged into the existing
+  // `.content { min-width: 0; flex: 1 1 auto; }` block, which
+  // test/md2doc.test.js matches verbatim).
+  //
+  // Why it exists: the gutter buttons hang OUTSIDE the content box, and the
+  // table row grip straddles the table's left border (half of it outside
+  // too — see the .ed-te-grip-row comment above). Without real padding the
+  // two fight over the same few pixels, which is what forced the earlier
+  // (now reverted) "inset the row grip into the table" hack that ended up
+  // covering the first cell's text. 56px of content padding plus moving the
+  // gutter buttons out (⠿ to left:-36px, ＋ to left:-54px) separates them
+  // properly: the gutter pair occupies [contentLeft-40, contentLeft-4]
+  // (v2.11.1; it was [contentLeft-54, contentLeft-18] until spec §4.2's own
+  // numbers were restored) and the 20px-wide row grip straddles contentLeft at
+  // [contentLeft-10, contentLeft+10] — an 8px gap, and the grip's inner half
+  // stays within the cell's own 14px padding, so it never touches cell text.
+  // (The padding was 48px until §4.2's hit-test conflict 1 was fixed; see the
+  // .content rule in editModeLayoutCss below for why it is 56px now.)
+  // S1 Task 5: the ordered-list ordinal is drawn by a CSS counter, and the
+  // flat DOM took away the one thing a real <ol> gave for free — a counter
+  // SCOPE per nesting level. Every li is a sibling of every other li now, so a
+  // single shared counter has no way to leave the outer run's value alone
+  // while a nested run counts: `1. / (nested) 1. / 2. / 2.` would render its
+  // last item as "3.", because the nested run's reset landed in the same
+  // scope. One counter PER DEPTH fixes it — the nested run resets ed-ol-1 and
+  // never touches ed-ol-0 — and `data-indent` is the right key because it is
+  // the attribute client.js keeps in step with the model (setBlockIndent()).
+  //
+  // Reset happens on `data-run-start`, which the renderer stamps per spec
+  // §3.8 and client.js re-derives after a structural key (refreshRunStarts()).
+  // `counter-reset: n 0` then `counter-increment: n` on the same element is
+  // resolved reset-then-increment, so a run's first item is 1.
+  //
+  // Depths beyond MAX get no counter of their own and no fallback rule — there
+  // is no depth-agnostic ordered rule below this loop — so their ::before
+  // computes to `none` and the marker renders BLANK (measured at indent 10 and
+  // 11). A missing ordinal beats a wrong one, and real markdown does not nest
+  // that far; raise ED_OL_MAX_DEPTH if it ever does.
+  const ED_OL_MAX_DEPTH = 9;
+  let edOlCounterCss = '';
+  for (let d = 0; d <= ED_OL_MAX_DEPTH; d++) {
+    const sel = '.ed-block[data-block-type="li"][data-indent="' + d + '"]';
+    edOlCounterCss +=
+      '\n  ' + sel + ' { counter-increment: ed-ol-' + d + '; }' +
+      '\n  ' + sel + '[data-run-start="1"] { counter-reset: ed-ol-' + d + ' 0;' +
+      ' counter-increment: ed-ol-' + d + '; }' +
+      '\n  .ed-block[data-list-type="ol"][data-indent="' + d + '"] > .ed-li-marker::before' +
+      ' { content: counter(ed-ol-' + d + ') "."; }';
+  }
+
+  const editModeLayoutCss = `
+  /* 56px, not 48px — spec §4.2's hit-test conflict 1 (gutter vs
+     .sidebar-splitter), which was the one of its three that never got a
+     guard. .sidebar-splitter's right edge IS .content's border-box left edge
+     (they are adjacent flex items), so the gutter pair at
+     [contentLeft-54, contentLeft-18] hung 6px back over the splitter's own
+     drag zone at 48px of padding. Measured at 1400x900: splitter [324, 356],
+     .ed-insert [350, 368], elementFromPoint(354, ＋'s own y) === button
+     .ed-insert, and a real pointer drag started at x=352 or x=354 left the
+     sidebar at 300px instead of resizing it to 420 — while x=336 and x=348
+     both worked. Worse, .ed-insert is only 20px tall and li rows carried none
+     at all before S2, so the dead zone was striped both vertically and within
+     a row: the same x resized the sidebar or silently opened an insert menu
+     depending on which pixel row the user grabbed.
+
+     8 more pixels of padding move the pair to [contentLeft-54,
+     contentLeft-18] = [splitterRight+2, splitterRight+20], i.e. entirely
+     inside the content column with 2px of clearance. (v2.11.1 pulled the pair
+     further in, to spec §4.2's own [contentLeft-40, contentLeft-4] — the
+     clearance is 16px at this padding rather than 2px. The padding stays at
+     56px: nothing asks for the text column to move, and this measurement is
+     the one the §4.2 conflict-1 guard is written against.) The 20px table row grip
+     still straddles contentLeft at [contentLeft-10, contentLeft+10], so its
+     8px gap to ⠿ is unchanged. Guarded by the elementFromPoint(splitter.right
+     - 2, y) assertion §4.2 asks for, in
+     test/editor-client-runtime.test.js. */
+  .content { padding-left: 56px; }
+
+  /* S1: every block is one full-width row, whatever its type or depth. The
+     indent is a property of the item's own MARKER, never of its box, so all
+     the hover outlines match and — the load-bearing part — the absolutely
+     positioned .ed-handle / .ed-insert keep one origin and therefore one
+     vertical axis. Putting the indent on the .ed-block itself (padding or
+     margin) drags that origin along with it and breaks exactly the promise
+     this layout exists to make.
+
+     flex, not grid: the child count varies (marker, optional .ed-li-check,
+     text), and a fixed grid track list would push a plain item's text into
+     the column a task item's checkbox occupies. */
+  .ed-block[data-block-type="li"] {
+    display: flex; align-items: baseline; column-gap: 6px;
+  }
+  /* width, NOT min-width: the marker box is FIXED, so "10." and up overflow
+     into the gutter instead of widening the column and pushing their own row's
+     text 2-3px right of items 1-9. That is what a real <ol> does, and it is
+     what keeps every item's text on one left edge.
+
+     "display: flex; justify-content: flex-end" is what makes that overflow go
+     LEFT, and it is not interchangeable with "text-align: right". Once the
+     content is wider than the box, text-align has nothing left to distribute:
+     the line box is already full, so the glyphs grow from the box's LEFT edge
+     rightward, across the 6px column-gap and onto the item's own text.
+     Measured with the old rule at 15px on a 120-item list: the marker box is
+     [72, 90] and .ed-li-text starts at 96, while marker.scrollWidth reports 21
+     at item 10 and 29 at item 100 — i.e. ink out to x=101, five pixels INTO
+     the text, which a screenshot reads back as "100item 100". Font-dependent
+     in degree only (under DejaVu Sans it collides at two digits, a 10-item
+     list), never in direction.
+
+     A flex container overflows toward its START side when justified to the
+     end — the same "overflow goes the other way" property that safe/unsafe
+     alignment exists to talk about — so the ink now grows leftward into the
+     gutter, which is where the space is. The guard is
+     "marker.scrollWidth === marker.clientWidth" (scrollWidth counts END-side
+     overflow only, so left overflow is invisible to it by construction) in
+     test/editor-client-runtime.test.js; asserting .ed-li-text's left edge does
+     NOT catch this, because the box is fixed and that edge never moves. */
+  .ed-block[data-block-type="li"] > .ed-li-marker {
+    flex: 0 0 auto;
+    margin-left: calc(var(--ed-indent, 0) * 1.6em);
+    width: 1.2em;
+    display: flex; justify-content: flex-end;
+    color: #6b7280; -webkit-user-select: none; user-select: none;
+  }
+  /* min-width: 0 so an unbreakable token inside an item cannot widen the row
+     past its siblings — that would break the equal-width guarantee above. */
+  .ed-block[data-block-type="li"] > .ed-li-text { flex: 1 1 auto; min-width: 0; }
+  /* column-gap already provides the marker/checkbox separation. */
+  .ed-block[data-block-type="li"] > .ed-li-check { flex: 0 0 auto; margin-right: 0; }
+  .ed-block[data-list-type="ul"] > .ed-li-marker::before { content: "\\2022"; }${edOlCounterCss}
+  /* A BULLETED task item's checkbox IS its marker, so the • is suppressed and
+     the marker box collapses (the indent lives on its margin and survives).
+     An ORDERED task item keeps its number — that is what GFM renders — and
+     the counter rules above outrank this one on specificity for ol, so
+     scoping this to ul is what keeps the two cases apart. */
+  .ed-block[data-list-type="ul"][data-task="1"] > .ed-li-marker { width: 0; }
+  .ed-block[data-list-type="ul"][data-task="1"] > .ed-li-marker::before { content: none; }
+
+  /* D6: ＋ immediately left of ⠿, on the same row, no gap — replacing the
+     stacked layout the shared stylesheet still declares (see .ed-insert
+     there, and why it had to stack before the gutter existed). The 48px of
+     content padding above is what buys the room: the pair occupies
+     [contentLeft-54, contentLeft-18], which with 56px of padding sits wholly
+     inside the content column (2px clear of .sidebar-splitter's right edge —
+     see the padding rule's own comment for the measurement), so ＋ never
+     reaches a negative viewport x and never covers the splitter. The 20px
+     table row grip still straddles contentLeft at
+     [contentLeft-10, contentLeft+10] - an 8px gap, unchanged. */
+  /* Stated ONCE, as tokens, because §4.2's three numbers are not independent:
+     the gutter is exactly two buttons wide plus the deliberate right-hand
+     breathing gap, and the hover zone below is exactly the gutter. Writing any
+     of them as a second literal is how the corridor comes back. */
+  :root {
+    --ed-gutter-btn: 18px;
+    --ed-gutter-gap: 4px;
+    --ed-gutter-w: calc(var(--ed-gutter-btn) * 2 + var(--ed-gutter-gap));
+  }
+  .ed-handle {
+    left: calc(-1 * (var(--ed-gutter-btn) + var(--ed-gutter-gap))); top: 0;
+    width: var(--ed-gutter-btn);
+  }
+  .ed-insert {
+    left: calc(-1 * var(--ed-gutter-w)); top: 0;
+    width: var(--ed-gutter-btn);
+  }
+  /* v2.11.1: the gutter's HOVER ZONE, and it is the reason the pair could move
+     back to spec §4.2's own numbers at all.
+
+     Both buttons are revealed by .ed-block:hover, and :hover is true only
+     over the block's border box or over one of the buttons themselves. At
+     -36/-54 that left the band [blockLeft-18, blockLeft) belonging to neither:
+     measured at 1400x900, elementFromPoint() returned main.content for
+     x 394..411, and a real pointer walking out of the text at 100 px/s held
+     the ⠿ at opacity 0 for 16 consecutive frames (~270 ms) — the cursor is
+     between the text and the ⠿ and the ⠿ is not there. Conforming to §4.2
+     ([contentLeft-40, contentLeft-4], the ＋ and ⠿ flush, 4px of breathing
+     room on the right) narrows that band to the 4px gap but does not close it:
+     with the pair moved and this rule taken back out, a 2px-per-frame walk
+     across the same row measured 0.06 / 0.49 / 0.53 at three of its 23 stops —
+     a flicker instead of a disappearance, but still the ⠿ dimming under the
+     cursor that is travelling to it. Geometry alone cannot close it, because §4.2's 4px gap is
+     deliberate (5.3 item 3a's elementFromPoint must land ON the ⠿).
+
+     Two more holes have the same shape and the same cure: the buttons are 20px
+     tall at top:0 while an li row is 24.75px, so the bottom ~4.75px of EVERY
+     row is an empty gutter; and a 61.5px heading's vertical centre is 20px
+     below the bottom of its own ⠿, so moving left from the middle of a heading
+     never reached anything at all.
+
+     One absolutely-positioned pseudo-element spanning the whole gutter for the
+     block's whole height makes :hover continuously true from the text out
+     past the ＋, at every Y. Its width is the --ed-gutter-w token the pair's
+     own offsets are built from, so the two cannot drift apart — if they do,
+     the corridor comes straight back.
+     .ed-block is already position:relative, and position: absolute keeps
+     this out of the li row's flex flow. It is deliberately NOT
+     pointer-events: none: that would stop it being hit-tested, which is the
+     entire mechanism. It therefore also changes what a click in the band
+     hits (main.content -> the block), which wireBlockSelection() in
+     lib/editor/client.js compensates for explicitly — see the
+     clientX-vs-block-rect guard just above its "clicked outside any block"
+     branch. (No backticks in this comment: it lives inside a JS template
+     literal.) */
+  .ed-block::before {
+    content: ""; position: absolute;
+    left: calc(-1 * var(--ed-gutter-w)); top: 0;
+    width: var(--ed-gutter-w); height: 100%;
+  }`;
+
   const html = `<!DOCTYPE html>
 <html lang="en">
 <head>
@@ -1704,8 +2050,24 @@ ${itemsHtml}
      output, same precedent as the lightbox selectors above. */
   .ed-block { position: relative; cursor: pointer; }
   .ed-block:hover { outline: 1px dashed #b0b0b0; }
-  .ed-li-text { display: block; min-height: 1em; }
-  li.ed-block { cursor: text; }
+  /* white-space: pre-line is LOAD-BEARING, not styling — do not relax it.
+     A hard-wrapped ("lazy continuation") list item's own content contains a
+     real newline, and its .ed-li-text is an editing host. Under the default
+     white-space:normal Chromium NORMALISES that newline to a space on the
+     FIRST keystroke (measured: "alpha\ncont" -> "alphaZ cont"), so the item's
+     source wrapping is destroyed by any edit and cannot be round-tripped —
+     which is what forced an earlier revision to refuse such items outright and
+     make ~22% of real list items read-only. pre-line (not pre-wrap) is the
+     narrowest fix: newlines become significant, while runs of spaces still
+     collapse exactly as before, so nothing about a single-line item changes.
+     (No backticks in this comment: it lives inside a JS template literal.) */
+  .ed-li-text { display: block; min-height: 1em; white-space: pre-line; }
+  /* S1: a list item is a flat <div class="ed-block" data-block-type="li">,
+     never an <li> — the selector follows the DOM. The marker's own glyph /
+     ordinal, the --ed-indent indent and the run-scoped ordered counter are
+     Task 5's and live in editModeLayoutCss (edit-mode only), fed by the hooks
+     renderEditModeList() emits here. */
+  .ed-block[data-block-type="li"] { cursor: text; }
   .ed-li-check { display: inline-block; width: 14px; height: 14px; margin-right: 6px;
     border: 1px solid #8a8a8a; border-radius: 3px; vertical-align: middle; cursor: pointer; }
   .ed-li-check[data-checked="1"] { background: #3b82f6; border-color: #3b82f6; }
@@ -1749,23 +2111,38 @@ ${itemsHtml}
   .ed-block:hover .ed-handle,
   .ed-handle:focus { opacity: 1; }
   .ed-handle:hover { background: rgba(0, 0, 0, 0.08); }
-  /* The ⠿ handle's small menu: heading ± / MD 原始碼 / close. Dark
-     translucent pill, bordered icon buttons — same visual language as
-     .ed-seltb below. */
+  /* The ⠿ handle's menu: 轉換成 › / 建立副本 / 刪除 / MD 原始碼 (spec §3.7).
+     Dark translucent panel, bordered rows — same visual language as
+     .ed-seltb below.
+
+     S2: flex-direction is COLUMN, and that is behaviour rather than styling.
+     The panel now carries word labels instead of the old ±/✕ glyphs, and a
+     row of four CJK labels is wider than the content column on a narrow
+     window — the last item scrolls out of reach. A stacked panel is also what
+     lets 轉換成 grow a submenu beside its OWN row rather than below the whole
+     bar. test/editor-client-runtime.test.js asserts the computed
+     flex-direction and that every button shares one left edge. */
   .ed-handle-menu {
     position: absolute; top: -4px; left: -4px; z-index: 6;
-    display: flex; align-items: center; gap: 4px;
-    padding: 4px 6px; border-radius: 8px;
+    display: flex; flex-direction: column; align-items: stretch; gap: 2px;
+    padding: 4px; border-radius: 8px;
     background: rgba(16, 18, 21, 0.92); color: #e6edf3;
     box-shadow: 0 2px 8px rgba(0, 0, 0, 0.25);
   }
   .ed-handle-menu-btn {
-    min-width: 28px; height: 26px; padding: 0 8px;
+    min-width: 132px; height: 26px; padding: 0 10px;
     border: 1px solid rgba(255, 255, 255, 0.25); border-radius: 6px;
     background: rgba(255, 255, 255, 0.08); color: inherit;
     font: inherit; font-size: 12px; line-height: 1;
-    white-space: nowrap; cursor: pointer;
-  }
+    text-align: left; white-space: nowrap; cursor: pointer;
+  }
+  /* The 轉換成 submenu carries BOTH classes, so it inherits every rule above
+     and only overrides the horizontal offset. It is a CHILD of the menu, and
+     the menu is itself position:absolute, so the menu's own padding box is
+     this element's containing block and left:100% lands it flush against
+     the menu's right edge. Source order matters: equal specificity with
+     .ed-handle-menu's own left:-4px, so this rule must stay AFTER it. */
+  .ed-handle-submenu { left: 100%; margin-left: 4px; }
   .ed-handle-menu-btn:hover { background: rgba(255, 255, 255, 0.18); }
   .ed-handle-menu-btn[hidden] { display: none; }
   /* §10-gap fix: block-level INSERT — the ＋ button sits NEXT TO the ⠿
@@ -1778,7 +2155,17 @@ ${itemsHtml}
      layout — measured directly). A second 18px-wide button placed FURTHER
      left (e.g. left:-44px) would land at a NEGATIVE viewport x and be
      unreachable/unclickable outside the visible page. The brief's own
-     wording allows this ("left gutter, above or beside it"). */
+     wording allows this ("left gutter, above or beside it").
+
+     S1 Task 5 (D6): edit mode now overrides BOTH buttons to sit side by side
+     (v2.11.1, spec §4.2's own numbers: ＋ at left:-40px, ⠿ at left:-22px,
+     both top:0, plus a .ed-block::before hover zone spanning the pair) — see
+     editModeLayoutCss.
+     That became possible only once .content gained 48px of edit-mode padding;
+     the stacked geometry declared here is what any NON-edit render would use,
+     and those never emit .ed-block at all, so it is inert there. Kept rather
+     than deleted because it is the correct fallback if the gutter padding is
+     ever conditioned differently. */
   .ed-insert {
     position: absolute; left: -22px; top: -22px; width: 18px; height: 20px;
     display: flex; align-items: center; justify-content: center;
@@ -1866,10 +2253,13 @@ ${itemsHtml}
      affordance) with two real, adequately-sized (>=18x24px) click/drag
      targets. '.ed-te-grip-row' is a vertical 6-dot handle shown at the LEFT
      EDGE of the hovered row -- every row, the HEADER included (spec 3.10:
-     the header is draggable too), and sitting just INSIDE the table's left
-     border rather than outside it, because the space outside belongs to the
-     block's own gutter; '.ed-te-grip-col' is a horizontal 6-dot handle shown
-     just ABOVE the hovered column (every column). Dots are plain <span>s laid out via CSS grid with
+     the header is draggable too), STRADDLING the table's left border (its
+     centreline ON that border), which is the same rule '.ed-te-grip-col'
+     uses on the table's TOP border -- one geometry for both axes, no
+     per-row-type special case. The block's own gutter is kept clear of it by
+     the edit-mode-only layout chunk emitted near the end of this stylesheet,
+     not by insetting the grip; '.ed-te-grip-col' is a horizontal 6-dot
+     handle shown just ABOVE the hovered column (every column). Dots are plain <span>s laid out via CSS grid with
      place-content: center, so the dot cluster stays compact/centered
      regardless of the button's own (larger, hit-target-sized) box — no
      images, no background gradients. '.ed-te-grip-dragging' is EITHER
@@ -1946,6 +2336,7 @@ ${itemsHtml}
     background: #fff; color: #b00020; border: none; border-radius: 4px;
     padding: 4px 12px; cursor: pointer; font-weight: bold;
   }
+${opts.editMode ? editModeLayoutCss : ''}
 </style>
 ${usesMath ? buildKatexStyleTag() : ''}
 </head>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@helping-ai-workflow/md2doc",
-  "version": "2.10.1",
+  "version": "2.11.1",
   "description": "Markdown → HTML / PDF renderer with WaveDrom, Mermaid, and Graphviz support",
   "keywords": [
     "markdown",
@@ -36,7 +36,7 @@
   },
   "scripts": {
     "preinstall": "node scripts/preinstall.js",
-    "test": "node test/md2doc.test.js && node test/blockmap.test.js && node test/images.test.js && node test/scroll-anchor.test.js && node test/lightbox.test.js && node test/lightbox-anno.test.js && node test/lightbox-anno-style.test.js && node test/reader-panels.test.js && node test/cli.test.js && node test/code-operator.test.js && node test/render-api.test.js && node test/lineops.test.js && node test/editmode-render.test.js && node test/editmode-wavedrom-reinit.test.js && node test/editor-server.test.js && node test/cli-edit.test.js && node test/open-viewer.test.js && node test/editor-client.test.js && node test/editor-client-runtime.test.js && node test/roundtrip.test.js && node test/byte-stability.test.js && node test/editor-server-throw.test.js && node test/editor-reader-rebind.test.js && node test/inline-md.test.js && node test/table-md.test.js && node test/gate-compat.test.js && node test/history.test.js && node test/list-md.test.js"
+    "test": "node test/md2doc.test.js && node test/blockmap.test.js && node test/images.test.js && node test/scroll-anchor.test.js && node test/lightbox.test.js && node test/lightbox-anno.test.js && node test/lightbox-anno-style.test.js && node test/reader-panels.test.js && node test/cli.test.js && node test/code-operator.test.js && node test/convert-md.test.js && node test/render-api.test.js && node test/lineops.test.js && node test/indent-clamp.test.js && node test/editmode-render.test.js && node test/editmode-wavedrom-reinit.test.js && node test/editor-server.test.js && node test/cli-edit.test.js && node test/open-viewer.test.js && node test/editor-client.test.js && node test/editor-client-runtime.test.js && node test/roundtrip.test.js && node test/byte-stability.test.js && node test/editor-server-throw.test.js && node test/editor-reader-rebind.test.js && node test/inline-md.test.js && node test/table-md.test.js && node test/gate-compat.test.js && node test/history.test.js && node test/list-md.test.js"
   },
   "repository": {
     "type": "git",