@helping-ai-workflow/md2doc 3.4.2 → 3.6.0

package/lib/editor/wave-ui.js

@@ -9,9 +9,10 @@
  * inlined as a plain <script>, not bundled, so a bare require() here would be
  * undefined in the browser — every dependency arrives as a parameter instead
  * (`opts.codec`, `opts.geometry`, `opts.createStore`, `opts.wavedrom`,
- * `opts.document`). That is also why this file names no global of its own: the
- * layer that knows which `document` and which engine build are in play is
- * client.js, and it is the only one that should be deciding.
+ * `opts.document`, `opts.draw`, `opts.panels`). That is also why this file
+ * names no global of its own: the layer that knows which `document` and which
+ * engine build are in play is client.js, and it is the only one that should be
+ * deciding.
  *
  * FIVE things this file is not allowed to get wrong, each of them a ruling from
  * Tasks 1-5 rather than a preference:
@@ -57,12 +58,71 @@
 
   const SVGNS = 'http://www.w3.org/2000/svg';
 
-  /** The brush palette, exactly the set the spec names, in that order. */
-  const BRUSHES = ['0', '1', 'x', 'z', 'p', 'n', 'h', 'l', 'u', 'd', '='];
+  /**
+   * The brush palette, exactly the set the spec names, in that order.
+   *
+   * v3.5.0 Task 10 widened this from 11 to 22: `P`/`N` (explicit-edge
+   * clocks — see the arrow measurement in `drawLane`'s isClock branch),
+   * `2`-`9` (bus levels beyond the plain `=`, already understood by
+   * `brickOf` and `codec.levelsOf` but never offered as a brush), and `|`
+   * (the gap marker) placed last because it is not a level at all —
+   * `codec.levelsOf('=.|')` measured it as "carry the previous level", so
+   * painting it does not change what a cycle shows, only that it shows a
+   * discontinuity.
+   */
+  const BRUSHES = ['0', '1', 'x', 'z', 'p', 'n', 'P', 'N', 'h', 'l', 'u', 'd',
+    '=', '2', '3', '4', '5', '6', '7', '8', '9', '|'];
+
+  /**
+   * Whether a `KeyboardEvent.key` value both PICKS and PAINTS a brush —
+   * `handleDrawingKey` (below `enterDrawing`) tests this exact call, not a
+   * copy of it, so the admission rule and what the keyboard can actually
+   * reach cannot drift apart the way the module's own prologue warns about
+   * (rule 3: two beliefs about the same thing is the failure this batch
+   * keeps producing). Named and exported on its own so a test can pin
+   * "every brush is keyboard-reachable" against the real rule instead of a
+   * re-implementation of it — see `wave-codec.test.js`'s
+   * `isBrushKey`-roster assertion.
+   *
+   * `key.length === 1` is what actually excludes navigation: every
+   * `BRUSHES` entry is one character, while `ArrowLeft`/`ArrowRight`/
+   * `ArrowUp`/`ArrowDown`/`Home`/`End` are multi-character key NAMES, so
+   * `BRUSHES.indexOf(key)` is already `-1` for all six regardless of this
+   * length check — it is kept anyway so that invariant is spelled out at
+   * the point of use rather than left to rely on `BRUSHES` never growing a
+   * multi-character entry by mistake. Deliberately NOT keyed on
+   * `ev.shiftKey`: v3.5.0 Task 10 added `P`/`N` (and `|` sits next to `\`
+   * on a US layout) to `BRUSHES`, and all three are typed WITH Shift on an
+   * ordinary keyboard, so a shiftKey exclusion here would make them
+   * mouse-only — see Task 10's fix-round report for the full reasoning on
+   * why dropping it does not reopen the Shift+arrow risk the old comment
+   * named (that risk is excluded above, by `nav`, on `key` identity, not on
+   * `ev.shiftKey`).
+   */
+  function isBrushKey(key) {
+    return typeof key === 'string' && key.length === 1 && BRUSHES.indexOf(key) !== -1;
+  }
 
   /** Drawing sizes. Handed to `wave-geometry` so the hit test and the paint
-   *  cannot drift; nothing here re-derives a row position. */
-  const SIZES = { laneHeight: 34, cycleWidth: 48, nameColWidth: 0 };
+   *  cannot drift; nothing here re-derives a row position.
+   *
+   *  v3.6.0 Task 6: nameColWidth was 0 — the canvas always supported a name
+   *  column (`wave-geometry.DEFAULTS` carried 40), the UI was just passing 0.
+   *  120px: the canvas needs to say what a lane is called, not lean on the
+   *  rail beside it. Task 8 re-measures this against the longest lane name in
+   *  the repo's fixtures and may change it — this value is not re-derived
+   *  here.
+   *
+   *  v3.6.0 Task 8 — MEASURED: the longest `name:` fixture across
+   *  test/editor-journey.test.js, test/wave-codec.test.js and
+   *  test/wave-geometry.test.js is 12 chars (`he said "hi"`). Rendered as an
+   *  SVG `<text>` at 11px (`wave-draw.js`'s `.ed-wave-lane-label`) it measures
+   *  54.9px in the app's default sans-serif stack and 79.5px in the worst
+   *  case tried (monospace) — both comfortably under the 110px a top-level
+   *  (depth 0) name gets (`nameColWidth 120 - NAME_GAP 10`), so 120 stays.
+   *  See task-8-report.md for the full measurement (puppeteer,
+   *  `getComputedTextLength`). */
+  const SIZES = { laneHeight: 34, cycleWidth: 48, nameColWidth: 120 };
 
   /**
    * The index the preview is rendered under, and why it is not 0.
@@ -89,52 +149,6 @@
   const PREVIEW_INDEX = 9000;
   const PREVIEW_ID_PREFIX = 'md2doc-wave-preview-';
 
-  /**
-   * What wavedrom 3.5.0 actually draws for one level, by its own brick id.
-   *
-   * Every row was MEASURED in this session against the pinned engine, by
-   * rendering `wave: 'z' + c + c` (the `z` anchors the char so it is never at
-   * cycle 0) and reading the second half-brick of each cycle out of the
-   * rendered SVG's `<use xlink:href="#…">` list:
-   *
-   *     0 000   1 111   x xxx   z zzz   u uuu   d ddd
-   *     h 111   l 000   H 111   L 000
-   *     p nclk  P nclk  n pclk  N pclk
-   *     = vvv-2  2 vvv-2  3 vvv-3 … 9 vvv-9
-   *     anything else  xxx      (measured with 'Q' and 'ä')
-   *
-   * So this is not a re-implementation of the engine's level model — `levelsOf`
-   * is that, and it lives in the codec. This is the last step: which PICTURE
-   * the engine paints for a level it has already decided. Keeping it in
-   * production code rather than in the test is deliberate: the drawing has to
-   * make exactly this decision anyway (an `h` lane is drawn high, an `=` lane
-   * is drawn as a bus), and a copy of it living only in a test would be a
-   * second belief about the engine with nothing pinning it to the first.
-   */
-  function brickOf(level) {
-    if (typeof level !== 'string' || level.length === 0) return 'xxx';
-    if (level === '0' || level === 'l' || level === 'L') return '000';
-    if (level === '1' || level === 'h' || level === 'H') return '111';
-    if (level === 'z') return 'zzz';
-    if (level === 'u') return 'uuu';
-    if (level === 'd') return 'ddd';
-    if (level === 'p' || level === 'P') return 'nclk';
-    if (level === 'n' || level === 'N') return 'pclk';
-    if (level === '=') return 'vvv-2';
-    if (level >= '2' && level <= '9') return 'vvv-' + level;
-    return 'xxx';
-  }
-
-  /** A brick that draws a whole clock period and therefore never merges with
-   *  its neighbour: two `p` cycles are two clock periods, not one long one. */
-  function isClock(brick) {
-    return brick === 'nclk' || brick === 'pclk';
-  }
-
-  function isBus(brick) {
-    return brick.slice(0, 4) === 'vvv-';
-  }
-
   /**
    * Whether `el` is inside the editor's serialisation surface.
    *
@@ -152,28 +166,6 @@
     return false;
   }
 
-  /**
-   * A plain, unfrozen copy of a document.
-   *
-   * The store's documents are deep-frozen — that is what stops a stray write
-   * from corrupting an undo entry — and wavedrom's renderer WRITES INTO the
-   * source object it is handed. Under this file's strict prologue that is a
-   * throw, so the preview gets its own copy every time. Bounded by the codec's
-   * own nesting ceiling so a pathological document cannot run the stack out
-   * here either.
-   */
-  function plainCopy(value, depth) {
-    if (depth > 64 || value === null || typeof value !== 'object') return value;
-    if (Array.isArray(value)) {
-      const out = [];
-      for (let i = 0; i < value.length; i++) out.push(plainCopy(value[i], depth + 1));
-      return out;
-    }
-    const out = {};
-    for (const key of Object.keys(value)) out[key] = plainCopy(value[key], depth + 1);
-    return out;
-  }
-
   /** Line and column of a byte offset, 1-based — what a parse failure has to
    *  say beyond its own message for the offset to mean anything to a person. */
   function whereIs(text, offset) {
@@ -182,59 +174,14 @@
     return { line: lines.length, column: lines[lines.length - 1].length + 1 };
   }
 
-  /**
-   * The group titles in the lane tree, each with the span of display rows it
-   * covers.
-   *
-   * A group title occupies NO ROW — measured in Task 2 against the pinned
-   * engine, and `wave-geometry` is built on it. What it occupies is horizontal
-   * space in the name column, so that is where this puts it: a label in the
-   * lane list's rail, spanning its lanes' rows. Drawing it as a row of its own
-   * would put the lane list one row out of step with the waveform beside it for
-   * every lane below the group, which is exactly the class of silent
-   * disagreement this batch keeps producing.
-   *
-   * The span is derived from the lanes' own paths — `layout.lanes[i].path` is
-   * the codec's — so a group with no lanes under it has no span and is not
-   * shown here; it is not addressable through the bridge either.
-   */
-  function groupSpansOf(doc, layout) {
-    const byKey = new Map();
-    for (let i = 0; i < layout.lanes.length; i++) {
-      const path = layout.lanes[i].path;
-      // Every proper ancestor between `signal` and the lane itself is a group.
-      for (let cut = 2; cut < path.length; cut++) {
-        const prefix = path.slice(0, cut);
-        const key = JSON.stringify(prefix);
-        const seen = byKey.get(key);
-        if (seen === undefined) {
-          byKey.set(key, { path: prefix, depth: cut - 1, from: i, to: i });
-        } else {
-          seen.to = i;
-        }
-      }
-    }
-    const out = [];
-    for (const span of byKey.values()) {
-      const container = valueAt(doc, span.path);
-      const title = Array.isArray(container) && typeof container[0] === 'string'
-        ? container[0] : null;
-      if (title === null) continue;   // an untitled group has nothing to show
-      out.push({ path: span.path, title: title, depth: span.depth,
-        from: span.from, to: span.to });
-    }
-    out.sort(function (a, b) { return a.from - b.from || a.depth - b.depth; });
-    return out;
-  }
-
-  function valueAt(doc, path) {
-    let node = doc;
-    for (const seg of path) {
-      if (node === null || typeof node !== 'object') return undefined;
-      node = node[seg];
-    }
-    return node;
-  }
+  // `plainCopy`, `groupSpansOf`, `directFirstLaneOf` and `valueAt` used to
+  // live here. v3.6.0 Task 2 moved `plainCopy` and `directFirstLaneOf` to
+  // `wave-panels.js` with the rendering functions that were their only
+  // callers (and Task 14 then deleted `directFirstLaneOf` outright, with the
+  // per-row 解散群組 button that was its one caller); `groupSpansOf` and
+  // `valueAt` moved to `wave-geometry.js` per ruling R9, since both
+  // `wave-panels.js` and `wave-draw.js` need them and that module is the one
+  // place both already depend on.
 
   /** The labels a lane's `data` supplies, one per explicit value cycle. */
   function labelsOf(lane) {
@@ -285,9 +232,63 @@
       throw new Error('wave-ui: the overlay may not be mounted inside .content ' +
         '(its children are serialised back into the user markdown)');
     }
+    // `opts.draw` (wave-draw.js's `createDrawer`) arrives as a parameter like
+    // every other dependency here, per this file's own header comment — a
+    // bare `require('./wave-draw.js')` would be undefined in the browser,
+    // where wave-ui.js is injected as a plain <script> with no shim of its
+    // own (see lib/editor/server.js). Missing it fails LOUD rather than
+    // quietly drawing nothing: a diagram with no drawing layer behind it must
+    // never look like a diagram that simply has nothing to draw.
+    if (!opts.draw) {
+      throw new Error('wave-ui: opts.draw (wave-draw.js\'s createDrawer) is required');
+    }
+    // v3.6.0 Task 2: `opts.panels` (wave-panels.js's `createPanels`) is the
+    // toolbar/lane-rail/right-hand-panels counterpart to `opts.draw` just
+    // above, arriving as a parameter for the identical reason — no shim for
+    // a bare `require('./wave-panels.js')` in the browser injection path.
+    if (!opts.panels) {
+      throw new Error('wave-ui: opts.panels (wave-panels.js\'s createPanels) is required');
+    }
 
     const store = opts.createStore(opts.source);
 
+    /**
+     * v3.6.0 Task 13: the 原始碼 panel's whole reason to exist — the exact
+     * bytes 保留並關閉 would write right now, not a re-serialisation made
+     * for display. The SAME `store.toPatch()` path `afterStoreMoved` already
+     * runs after every gesture (`lastPatch`, below), recomputed fresh here
+     * rather than reusing that cached value: this can be asked before the
+     * very first gesture, while `lastPatch` is still `null`.
+     *
+     * A refusal is shown as a sentence, not thrown — the same "say what it
+     * cannot do" rule `renderUnmodelled` and the unreadable-source panel
+     * both already follow, rather than crashing a panel over a state the
+     * user can act on (undo one step, or make a smaller change).
+     */
+    function sourceText() {
+      const patch = store.toPatch();
+      return patch.ok === true ? patch.text
+        : '（這個改動目前沒辦法只改幾個位元組寫回去：' + patch.reason + '）';
+    }
+    // Test-visible, same convention `client.js` already uses for its own
+    // `window.__edTest*` probes: a plain global a Puppeteer test can call
+    // directly, assigned through `d.defaultView` rather than a bare
+    // `window` reference — this file names no global of its own (see its
+    // header) and is reachable from node with a fake `opts.document`, where
+    // a bare `window` would throw.
+    const probeWin = d.defaultView;
+    if (probeWin) probeWin.__edWaveSourceProbe = sourceText;
+
+    const drawer = opts.draw.createDrawer({
+      d: d,
+      geometry: geometry,
+      codec: codec,
+      SIZES: SIZES,
+      SVGNS: SVGNS,
+      BRUSHES: BRUSHES,
+      labelsOf: labelsOf,
+    });
+
     const overlay = d.createElement('div');
     overlay.className = 'ed-wave-overlay';
     overlay.setAttribute('role', 'dialog');
@@ -302,15 +303,32 @@
     // closing.
     let brush = '1';
     let clip = null;
-    let selection = null;        // {laneIndex, from, to} — the cycles a gesture acts on
+    // v3.6.0 Task 14: `{laneIndex, laneTo, from, to}` — THE selection, and
+    // the only one this dialog has. `laneIndex`..`laneTo` (inclusive,
+    // normalised so `laneTo >= laneIndex`) is the lane range the 訊號/群組
+    // sections act on; `from`..`to` is the cycle range on `laneIndex` that
+    // the 週期 section and the brushes act on. An ordinary selection has
+    // `laneTo === laneIndex`; only Shift+click on the rail widens it.
+    //
+    // Every producer writes all four keys. That is deliberate rather than
+    // "absent means single lane": this repo has already paid for one value
+    // whose two ends disagreed about what `undefined` meant (wavedrom's own
+    // `captext` vs `ticktock`), and a reader here does
+    // `i >= laneIndex && i <= laneTo` with no second rule to remember.
+    let selection = null;
     let drag = null;             // live pointer drag, never pushed until mouseup
     let gestures = 0;
     let lastPatch = null;
     // Where the keyboard should end up after the NEXT repaint, when that is not
-    // simply "wherever it was". A move button is the case that needs it: the
-    // control the user pressed belongs to a row, and after the move the lane
-    // they are pushing around is at a different row — so pressing ▲ twice has
-    // to move the same lane twice, not two different ones.
+    // simply "wherever it was". A gesture that MOVES a lane is the case that
+    // needs it: whatever the keyboard was on belongs to a row, and after the
+    // move the lane the user is pushing around sits at a different row — so
+    // Alt+↓ twice has to move the same lane twice, not two different ones.
+    // (v3.6.0 Task 16 re-pointed this sentence: it used to name the rail's
+    // per-row ▲, which Task 14 removed; `moveSelectedLane` now carries the
+    // same fact and nominates the moved lane's own name field. The narrative
+    // further down about what ▲/▼ USED to do is a record of a past version
+    // and is deliberately left as it was.)
     let focusOverride = null;
     // Where the KEYBOARD is on the drawing: one cell, and the keyboard's whole
     // equivalent of the pointer. Null until the keyboard has actually entered
@@ -321,6 +339,102 @@
     // never end up pointing at different cells: painting with `1` after a click
     // paints the cell that was clicked.
     let cursor = null;
+    // The `edge` array entry the inspector row edits — the codec's ORIGINAL
+    // index into `doc.edge`, exactly what `geometry.edgeLayout` reports as
+    // `index` (NOT the filtered array position; a dangling entry ahead of it
+    // is skipped there and would otherwise shift everything after it out of
+    // step). Null means no edge is selected, and that is the whole of the
+    // inspector row's visibility rule — see `renderEdgeBar`. `render()`
+    // clamps it to null the moment the edge it names stops being drawable
+    // (deleted, or its entry no longer parses), so a stale index can never
+    // reach `renderEdgeBar` or a shape/label commit.
+    let selectedEdge = null;
+    // v3.6.0 Task 13 fix round 3: the PREVIOUS render's `selectedEdge`, so
+    // `render()` below can tell "just became selected" (null -> a number)
+    // apart from "still selected, repainting for some other reason" (a
+    // number -> the same or a different number) — see the comment at that
+    // check for why the distinction matters.
+    let lastSelectedEdge = null;
+    // v3.5.0 Task 7: the edge-CREATION gesture's own state, shared verbatim
+    // by the pointer and the keyboard — one state machine, two input sources.
+    // `edgeMode` is explicit rather than inferred from "is a key held" or "is
+    // the mouse button down", for the same reason the brush canvas keeps
+    // `drag` as its own variable instead of asking `ev.buttons`: a painting
+    // drag and an edge-creation drag must never be read as each other, and a
+    // named mode is what lets `onCanvasDown` choose between them up front.
+    //   'idle'     — the 關聯線 button is off; every press paints or selects.
+    //   'armed'    — pressed once; the NEXT thing (a press, or a cell plus
+    //                Enter) marks the start of a line.
+    //   'dragging' — the mouse is down after that press; every move only
+    //                repaints a preview, the document is untouched.
+    // `pendingFrom` is the marked start cell, `{at, cell}` in the same two
+    // numbers `codec.ensureNode`/`geometry.cellRect` already take — the
+    // codec's flattened lane index and the cycle inside it. It is cleared
+    // only when `setEdgeMode` moves all the way back to 'idle': going back to
+    // 'armed' after a drop that produced nothing (rule 1 below) deliberately
+    // LEAVES it standing, so a keyboard user who marked a start and then
+    // pressed Enter over an empty row does not have to re-mark it — the next
+    // Enter still means "finish from where I already stood".
+    let edgeMode = 'idle';
+    let pendingFrom = null;
+    // v3.6.0 Task 11: which transition anchor the pointer is nearest while
+    // armed — `{laneIndex, cell}`, `geometry.boundaryAt`'s own field names,
+    // never converted to `cellFromEvent`'s `cycle` (see that function's own
+    // comment). Cleared whenever `edgeMode` leaves 'armed' for any reason
+    // (idle or dragging) so a stale hot dot never survives past the state
+    // that produced it — set alongside `edgeMode` in `setEdgeMode` itself,
+    // the one place that already keeps every other edge-gesture mark
+    // (`pendingFrom`) in sync with it.
+    let hoverBoundary = null;
+    /** The one place `edgeMode` changes. Keeps the arm button's own visual
+     *  state, the overlay's `data-wave-edgemode` (what a test or a future
+     *  task reads instead of reaching into this closure) and the "is a start
+     *  cell marked" invariant all moving together. */
+    function setEdgeMode(next) {
+      edgeMode = next;
+      edgeBtn.setAttribute('aria-pressed', next === 'idle' ? 'false' : 'true');
+      edgeBtn.classList.toggle('is-on', next !== 'idle');
+      overlay.setAttribute('data-wave-edgemode', next);
+      if (next === 'idle') pendingFrom = null;
+      // v3.6.0 Task 11: the hover dot only ever means anything while
+      // 'armed' (dragging repaints its own hot dot via `onCanvasMove`'s
+      // `at`, computed fresh every move) — leaving 'armed' for either
+      // neighbour state without clearing this would let a stale hot dot
+      // from the last hover survive into a repaint nothing is tracking it
+      // for any more.
+      if (next !== 'armed') hoverBoundary = null;
+    }
+    // v3.5.0 Task 8: dragging either END of the SELECTED edge to another
+    // cell. `{index, end, at, cell} | null` — `index` is the same original
+    // `doc.edge` index `selectedEdge` names (a drag can only start from that
+    // edge's own drawn handle, see `onCanvasDown`), `end` is `'from'` or
+    // `'to'`, and `at`/`cell` are the live drop target, `null` until the
+    // first `pointermove` lands on a real cell.
+    //
+    // Unlike `edgeMode`/`pendingFrom` — two separate variables that Task 7
+    // spent three fix rounds re-synchronising after one could go stale while
+    // the other stood — this is ONE variable that is both "is a drag
+    // happening" and "what does it know so far". There is no second flag to
+    // fall out of step with it: `onCanvasMove`/`onCanvasUp` test this value
+    // itself, so nulling it is the whole of cancelling the gesture, in one
+    // place, atomically. It still has to be threaded through the same two
+    // places Task 7's marks are, though, because the hazard those rounds
+    // found is not particular to `pendingFrom` — it is "a mark naming a lane
+    // outlives the document that lane numbering was valid in":
+    //   - `carryMarks` below carries `at` by lane IDENTITY, exactly like
+    //     `pendingFrom.at`, for the same reason: a structural undo/redo can
+    //     land while this drag is in flight (the keyboard stays live while a
+    //     mouse button is held — Ctrl+Z does not care what the mouse is
+    //     doing), and a raw row number surviving that would let the eventual
+    //     drop's `moveEdgeEnd` bounds-check successfully against a lane the
+    //     user was never actually pointing at.
+    //   - `render()`'s own `selectedEdge` clamp is widened to drop this too:
+    //     `index` can only ever be reached from `selectedEdge`'s own drawn
+    //     handle, so the two may never disagree — a drag whose edge stops
+    //     being drawable (deleted, or its selection cleared by that same
+    //     mid-drag undo) has to die with it rather than commit a move onto
+    //     whatever entry now happens to sit at that array position.
+    let endpointDrag = null;
     // The document the marks' lane numbers are numbers INTO.
     //
     // `cursor` and `selection` name a ROW, and a row number means a different
@@ -344,6 +458,14 @@
     // a rename field ran `close('escape')` and threw the WHOLE session away,
     // which is the most expensive answer available to「我改名改到一半不想改了」.
     let groupRename = null;
+    // v3.5.0 Task 11: the bus data-label field while it is open — this
+    // dialog's OTHER sub-panel, same shape as `groupRename` above (a
+    // `{cancel, retire}` pair) and layered the same way in `onKeyDown`'s
+    // Escape handling. Unlike the rail's rename field, this one's node lives
+    // beside the canvas SVG that `renderCanvas` rebuilds on every cursor
+    // move, not only on a structural edit — so `retire()` is called from
+    // THERE, not only from `render()` (see `renderCanvas`'s own first line).
+    let dataEdit = null;
 
     // ── the modal focus model ─────────────────────────────────────────────
     //
@@ -461,6 +583,7 @@
       if (closed) return;
       closed = true;
       drag = null;
+      endpointDrag = null;
       if (overlay.parentNode) overlay.parentNode.removeChild(overlay);
       d.removeEventListener('keydown', onKeyDown, true);
       d.removeEventListener('mousemove', onCanvasMove, true);
@@ -530,6 +653,27 @@
         // user had made, and the one Ctrl+Z that takes a discard back is not
         // something the keystroke announces.
         if (groupRename !== null) { groupRename.cancel(); return; }
+        // v3.5.0 Task 11: the bus data-label field, this dialog's OTHER
+        // text sub-panel — same layering reason as `groupRename` just
+        // above: without this, Escape typed while labelling a bus value
+        // discarded the whole editing session instead of just the field.
+        if (dataEdit !== null) { dataEdit.cancel(); return; }
+        // v3.5.0 Task 7: the armed/dragging edge gesture is this dialog's
+        // OTHER sub-panel-shaped thing — not a text field, but still a
+        // half-done action standing in front of the dialog's own Escape.
+        // Cancelling it never touches the document (rule 2: nothing was
+        // written yet), so there is no undo step to leave behind either.
+        if (edgeMode !== 'idle') { setEdgeMode('idle'); render(); return; }
+        // v3.5.0 Task 8: a third sub-panel-shaped thing, same rule — the
+        // document is untouched during an endpoint drag (rule 3), so
+        // cancelling it is nulling the one variable that both is and knows
+        // the drag, then a repaint. The mousemove/mouseup listeners are left
+        // attached exactly as `edgeMode`'s own cancel above leaves them:
+        // `onCanvasUp` unconditionally removes both at its very first line
+        // whenever the button eventually comes up, so a stray move in
+        // between finds `endpointDrag === null`, falls through every other
+        // branch and repaints nothing — no listener leak, no second rule.
+        if (endpointDrag !== null) { endpointDrag = null; render(); return; }
         close('escape');
         return;
       }
@@ -548,6 +692,114 @@
         next.focus();
         return;
       }
+      /**
+       * v3.6.0 Task 16: the dialog's four Alt+arrow chords.
+       *
+       *   Alt+↑ / Alt+↓   move the SELECTED LANE up or down the list.
+       *   Alt+← / Alt+→   move the CELL CURSOR to the next transition, while
+       *                   the 關聯線 gesture is armed.
+       *
+       * Alt is this dialog's "the arrow key, but coarser" modifier, and the
+       * two halves are honestly not the same KIND of operation — vertically
+       * it acts on the document (a lane changes place, `commit` runs),
+       * horizontally only on the cursor (nothing is written). What they share
+       * is that each is the larger-grained reading of the arrow beneath it,
+       * and that neither is reachable any other way from the keyboard.
+       *
+       * Alt+←/→ arrived here in fix round 3, moved off plain ←/→. See the
+       * long comment in `handleDrawingKey` for what that binding cost (T9b:
+       * a jump can only land on a transition, so it left several cells with
+       * no keyboard route at all, and the keyboard could no longer reproduce
+       * the mouse's edge byte for byte). This branch is the only home
+       * available to it: the call to `handleDrawingKey` below is gated on
+       * `!ev.altKey`, so no Alt-modified key can reach that function, and
+       * re-opening that gate is how `Ctrl+Z` routing would get disturbed.
+       *
+       * ALL FOUR ARE CLAIMED DIALOG-WIDE, including the two that then refuse.
+       * `Alt+←`/`Alt+→` is Back/Forward in a desktop browser, and an
+       * unclaimed one inside a modal editing session is a keystroke that can
+       * navigate the whole session away. Claiming it — `preventDefault()` in
+       * the capture phase, on every target inside this overlay — is the
+       * direction that reduces that risk whichever way a given browser
+       * behaves. MEASURED, and the measurement is INCONCLUSIVE rather than
+       * reassuring: this repo's headless Chrome does not fire back-navigation
+       * on a CDP-synthesised `Alt+ArrowLeft` at all — verified on a bare page
+       * with no key handler of any kind, history length 3, document unchanged
+       * — so the harness cannot answer the question either way, and a real
+       * desktop browser is where it would have to be confirmed. The cost of
+       * claiming it is one: Option+←/→ word navigation inside a lane's name
+       * field, a single-line input, stops working.
+       *
+       * Task 14 took the rail's per-row ▲/▼ off — one pair per lane, none of
+       * which fit in the slimmed row — and left the handle's drag-and-drop
+       * as the only way to reorder a lane at all. A gesture that exists only
+       * under a pointer is the gap v3.5.0 Task 10 spent a whole task closing
+       * on this same surface, so it does not get to reopen here. The
+       * reference fork never had a second door either: its shortcut parser
+       * returns null the moment it sees `altKey`, so `moveLane` is
+       * drag-only there. Ours has two doors and both go through the SAME
+       * `codec.moveLane`, with display positions — the rail's own drop
+       * handler in `wave-panels.js` is the other one — rather than growing a
+       * second opinion about lane order.
+       *
+       * The LANE half is claimed here rather than inside `handleDrawingKey`
+       * for two reasons that are both load-bearing. `handleDrawingKey`
+       * accepts exactly two targets (the canvas and the dialog) and returns
+       * false on anything else, while the place a person reordering lanes
+       * actually sits is the lane's own NAME FIELD — which is where
+       * `moveSelectedLane`'s `focusOverride` puts them and keeps them, so
+       * Alt+↓ twice moves the same lane twice instead of two different ones.
+       * And the call to it just below is gated on `!ev.altKey`, so an
+       * Alt-modified key cannot reach it at all.
+       *
+       * Above the `!(ctrl||meta) || alt` gate further down, which returns on
+       * any Alt key: everything Alt-modified this dialog claims has to be
+       * claimed before that line.
+       *
+       * TWO THINGS THE CONDITION DELIBERATELY DOES NOT SAY, both v3.6.0 Task
+       * 16 fix round 1, both documented rather than guarded:
+       *
+       * `ev.shiftKey` is not tested, so **Alt+Shift+↑/↓ moves the lane too**.
+       * That is the same shape `isBrushKey` settled on (see its own comment
+       * at the top of this file): keying an admission rule on Shift is what
+       * blocked `P`/`N`/`|` from the keyboard entirely in v3.5.0 Task 10.
+       * There is no second meaning for Shift here — a lane move has no range
+       * to extend — so the extra modifier is harmless rather than ambiguous,
+       * and refusing it would only make the key stop working for anyone
+       * whose hand is still on Shift from a Shift+click on the rail.
+       *
+       * No sub-panel gate either. A press taken while the rail's rename
+       * field or the bus data-label field is open moves the lane and lets
+       * the repaint retire that field, dropping whatever was half-typed in
+       * it — exactly what `Ctrl+Z` already does there (see `render()`'s own
+       * first line, and `renderCanvas`'s). Both text sub-panels behave the
+       * same way and neither wedges the keyboard: `moveSelectedLane` has
+       * already written `focusOverride`, so `dataEdit.retire`'s own
+       * `focusOverride === null` claim never fires and `restoreFocus` lands
+       * on a real element. Standing this gesture behind the sub-panels the
+       * way Escape does is a design call this task did not take.
+       */
+      if (store.ok === true && ev.altKey === true && !ev.ctrlKey && !ev.metaKey &&
+          (ev.key === 'ArrowUp' || ev.key === 'ArrowDown' ||
+           ev.key === 'ArrowLeft' || ev.key === 'ArrowRight')) {
+        ev.preventDefault();
+        ev.stopPropagation();
+        if (ev.key === 'ArrowUp' || ev.key === 'ArrowDown') {
+          moveSelectedLane(ev.key === 'ArrowUp' ? -1 : 1);
+          return;
+        }
+        // Armed only, and it REFUSES OUT LOUD otherwise rather than becoming
+        // a silent no-op. `jumpTransition` writes `hoverBoundary`, which
+        // `setEdgeMode` documents as meaningful only while 'armed' — a jump
+        // taken while idle would leave a hot dot behind that nothing is
+        // tracking, and it would light up the moment the user did arm.
+        if (edgeMode !== 'armed') {
+          panels.say('先按「關聯線」武裝，Alt+←／→ 才有轉態點可以跳');
+          return;
+        }
+        jumpTransition(ev.key === 'ArrowRight' ? 1 : -1);
+        return;
+      }
       // The drawing's own keys, claimed here rather than on the canvas element
       // so they are decided in the same place — and in the same phase — as
       // Escape, Tab and undo/redo. Deliberately BELOW those three (a cell
@@ -577,14 +829,14 @@
         ev.preventDefault();
         ev.stopPropagation();
         if (store.undo()) afterStoreMoved('undo');
-        else say('沒有可以復原的動作');
+        else panels.say('沒有可以復原的動作');
         return;
       }
       if (key === 'y' || (key === 'z' && ev.shiftKey)) {
         ev.preventDefault();
         ev.stopPropagation();
         if (store.redo()) afterStoreMoved('redo');
-        else say('沒有可以重做的動作');
+        else panels.say('沒有可以重做的動作');
       }
     }
     d.addEventListener('keydown', onKeyDown, true);
@@ -668,13 +920,101 @@
     marksDoc = store.doc;
 
     // ── toolbar ───────────────────────────────────────────────────────────
+    //
+    // v3.6.0 Task 12: eight captioned `.ed-wave-tool-group` sections
+    // (週期/電位/訊號/群組/關聯線/歷史/匯出/檔案) instead of the two flat bars
+    // this used to be. See `wave-panels.js`'s `toolGroup()` for why each
+    // caption sits to the LEFT of its buttons rather than above them.
     const toolbar = d.createElement('div');
-    toolbar.className = 'ed-wave-toolbar';
+    toolbar.className = 'ed-wave-toolbar ed-wave-tools';
     panel.appendChild(toolbar);
 
+    // v3.6.0 Task 2/12: the toolbar/right-hand-panels/lane-rail factory.
+    // Called here, right after `panel` exists, which is BEFORE several
+    // elements its OTHER returned functions need (`metaBar`'s own fields,
+    // the edge inspector, `laneCol`, the preview host, `status`). `deps` is
+    // the same object referenced below at each of those elements' own
+    // creation — see `deps.metaBar =` etc. — and `wave-panels.js`'s own
+    // header explains why that is not a reorder. `actions` is the callback
+    // bag for the `wave-ui.js`-owned state a moved function still needs to
+    // read or write; see that same header for what each entry is for and
+    // why `close` is not among them (nothing that moved calls it).
+    const deps = {
+      d: d,
+      geometry: geometry,
+      codec: codec,
+      SIZES: SIZES,
+      actions: {
+        commit: commit,
+        render: render,
+        selectionSet: function (value) { selection = value; },
+        focusOverrideGet: function () { return focusOverride; },
+        focusOverrideSet: function (key) { focusOverride = key; },
+        groupRenameGet: function () { return groupRename; },
+        groupRenameSet: function (value) { groupRename = value; },
+        sourceText: sourceText,
+      },
+      overlay: overlay,
+      panel: panel,
+      PREVIEW_INDEX: PREVIEW_INDEX,
+      PREVIEW_ID_PREFIX: PREVIEW_ID_PREFIX,
+      wavedrom: opts.wavedrom,
+    };
+    const panels = opts.panels.createPanels(deps);
+
+    // v3.6.0 Task 15: the shared `NOT_YET_WIRED` title that used to stand
+    // here went out with its last three holders — 匯出's SVG / PNG /
+    // 複製 WaveJSON. Every button this toolbar builds now does something,
+    // and nothing is created disabled to make a section's shape look real.
+
+    // ── 週期 ──────────────────────────────────────────────────────────────
+    const cycleGroup = panels.toolGroup('週期');
+    toolbar.appendChild(cycleGroup);
+    panels.toolButton('ed-wave-cycle-insert', '插入 cycle',
+      '在選取的位置插入一個 cycle（每一條 lane 同時加寬，不會有人掉隊）', function () {
+        const at = selection === null ? 0 : Math.min(selection.from, selection.to);
+        commit('insert-cycle', function (doc) { return codec.insertCycles(doc, at, 1); });
+      }, cycleGroup);
+    panels.toolButton('ed-wave-cycle-delete', '刪除 cycle',
+      '刪掉選取的 cycle（每一條 lane 同時變窄）', function () {
+        if (selection === null) { panels.say('先選一段 cycle 再刪'); return; }
+        const from = Math.min(selection.from, selection.to);
+        const count = Math.abs(selection.to - selection.from) + 1;
+        commit('delete-cycle', function (doc) { return codec.deleteCycles(doc, from, count); });
+      }, cycleGroup);
+    panels.toolButton('ed-wave-cycle-copy', '複製',
+      '把選取的 cycle 從每一條 lane 上拷一份', function () {
+        if (selection === null) { panels.say('先選一段 cycle 再複製'); return; }
+        const from = Math.min(selection.from, selection.to);
+        const count = Math.abs(selection.to - selection.from) + 1;
+        clip = codec.copyCycles(store.doc, from, count);
+        panels.say('複製了 ' + count + ' 個 cycle');
+        render();
+      }, cycleGroup);
+    panels.toolButton('ed-wave-cycle-paste', '貼上（插入）',
+      '把剪貼簿插進選取的位置', function () { pasteAt('insert'); }, cycleGroup);
+    panels.toolButton('ed-wave-cycle-paste-over', '貼上（覆蓋）',
+      '用剪貼簿蓋掉選取位置起算的那幾個 cycle', function () { pasteAt('overwrite'); }, cycleGroup);
+
+    function pasteAt(mode) {
+      if (clip === null) { panels.say('剪貼簿是空的'); return; }
+      const at = selection === null ? 0 : Math.min(selection.from, selection.to);
+      commit('paste-' + mode, function (doc) {
+        return codec.pasteCycles(doc, at, clip, mode);
+      });
+    }
+
+    // ── 電位 ──────────────────────────────────────────────────────────────
+    //
+    // v3.6.0 Task 12: this section WRAPS the existing brush bar — the 22
+    // brush buttons are still built inline by this same loop, with
+    // `drawer.levelIcon` glyphs (Task 10) — `panels.toolButton` is not used
+    // for them, so only the container they land in is new here.
+    const brushGroup = panels.toolGroup('電位');
+    toolbar.appendChild(brushGroup);
     const brushBar = d.createElement('div');
     brushBar.className = 'ed-wave-brushes';
-    toolbar.appendChild(brushBar);
+    brushGroup.appendChild(brushBar);
     const brushButtons = [];
     for (const ch of BRUSHES) {
       const b = d.createElement('button');
@@ -682,7 +1022,21 @@
       b.className = 'ed-wave-brush';
       b.setAttribute('data-brush', ch);
       b.setAttribute('data-focus-key', 'brush-' + ch);
-      b.textContent = ch;
+      // v3.6.0 Task 10: the glyph is built by `drawer.levelIcon` — the SAME
+      // brick-drawing code `renderCanvas` paints the diagram with, not a
+      // second hand-drawn set (see wave-draw.js's own `levelIcon` comment).
+      // `panels.toolButton` is NOT used for these buttons: brush buttons are
+      // built here, inline, not through that helper, so wiring the icon
+      // where `toolButton` lives would put glyphs on the cycle-operation
+      // buttons instead and leave every brush bare. The character stays on
+      // the button too, as a caption next to the icon rather than instead
+      // of it — a user who already knows the wavedrom letter should not
+      // have to relearn a picture-only toolbar.
+      b.appendChild(drawer.levelIcon(ch));
+      const cap = d.createElement('span');
+      cap.className = 'ed-wave-brush-char';
+      cap.textContent = ch;
+      b.appendChild(cap);
       b.addEventListener('click', function () {
         brush = ch;
         paintBrushState();
@@ -690,6 +1044,76 @@
       brushBar.appendChild(b);
       brushButtons.push(b);
     }
+    /**
+     * The toolbar sections that act on `selection`, repainted from it.
+     *
+     * v3.6.0 Task 14. Called from `render()`, from `repaintDrawing()`, and
+     * from every INLINE `drawer.renderCanvas` site in this file — which is
+     * not a set of duplicate calls. `render()` is the slow path; every other
+     * one of them both writes `selection` and reads it back out of the
+     * drawer's own clamp, and none of them rebuilds the toolbar. Wired only
+     * into `render()`, these buttons kept whatever state the LAST full
+     * repaint left them in.
+     *
+     * Two rescues used to hide most of that, and fix round 1 is the gesture
+     * where both are shut at once:
+     *
+     *   - `onCanvasUp`'s `commit('paint', …)` re-renders — but `commit`
+     *     returns false without calling `afterStoreMoved` when the gesture
+     *     changed nothing, and pressing a cell that already holds the
+     *     brush's own value changes nothing.
+     *   - `onCanvasDown`'s `canvas.focus()` fires the drawer-wired
+     *     `enterDrawing` → `repaintDrawing` — but only when the canvas did
+     *     not already have the keyboard, i.e. never on the second press in
+     *     a row.
+     *
+     * MEASURED, both symptoms: (a) open the dialog (no selection, 刪除
+     * disabled), walk to a lane with the arrow keys, and 刪除 was still
+     * disabled although the lane was selected and highlighted on both the
+     * rail and the canvas; (b) press req's cycle 2, then ack's cycle 4 —
+     * `data-insert-at`/`data-lands-in` stayed on 2/`bus` while the button,
+     * which reads the LIVE `selection`, would have inserted at 4 outside
+     * every group. (b) is the worse of the two: it is this task's own
+     * contract — the button says which container it is about to use BEFORE
+     * it is pressed — broken by the button itself.
+     *
+     * So it is called at every writer of the state it paints, not at the
+     * one whose symptom was reported. The rail's own `.is-selected` is a
+     * separate, pre-existing staleness on those same inline paths (they do
+     * not call `panels.renderLanes` either) and is deliberately NOT fixed
+     * here.
+     *
+     * 新增 and 空白列 stay enabled with nothing selected — that case has a
+     * real answer of its own (position 0; see `signalInsertAt`) — and they
+     * publish WHERE the insert lands before they are pressed, which is the
+     * property the rail's per-row ＋ used to carry in `data-lands-in` and
+     * its tooltip. The other three need a lane named, and 解散群組 needs
+     * that lane to be inside a group; a button that looks pressable and
+     * then answers「先選一條 lane」is the affordance this batch is
+     * removing, not reproducing.
+     */
+    function paintSelectionState(doc, layout) {
+      const insertAt = signalInsertAt(layout);
+      const insertLanding = panels.landingOf(doc, insertAt);
+      const insertWhere = insertLanding.title === null
+        ? '群組外' : '群組「' + insertLanding.title + '」裡';
+      for (const b of [signalAddBtn, signalBlankBtn]) {
+        b.setAttribute('data-insert-at', String(insertAt));
+        b.setAttribute('data-lands-in',
+          insertLanding.title === null ? '' : insertLanding.title);
+      }
+      signalAddBtn.title = '在選取的 lane 後面加一條（沒有選取就加在最前面）—— 會落在' + insertWhere;
+      signalBlankBtn.title = '在選取的 lane 後面插入一個空白列（WaveJSON 的 {}，' +
+        '用來空出間距；刪除跟刪一般的 lane 一樣）—— 會落在' + insertWhere;
+      signalDeleteBtn.disabled = selection === null;
+      signalCopyBtn.disabled = selection === null;
+      groupBtn.disabled = selection === null || selection.laneTo === selection.laneIndex;
+      groupDissolveBtn.disabled = selection === null ||
+        !laneIsInGroup(layout, selection.laneIndex);
+      overlay.setAttribute('data-wave-lane-range', selection === null ? ''
+        : selection.laneIndex + ',' + selection.laneTo);
+    }
+
     function paintBrushState() {
       for (const b of brushButtons) {
         b.classList.toggle('is-on', b.getAttribute('data-brush') === brush);
@@ -697,114 +1121,796 @@
       overlay.setAttribute('data-wave-brush', brush);
     }
 
-    const cycleBar = d.createElement('div');
-    cycleBar.className = 'ed-wave-cycleops';
-    toolbar.appendChild(cycleBar);
+    // ── 訊號 ──────────────────────────────────────────────────────────────
+    //
+    // v3.6.0 Task 14: these four came off the lane rail, where every row
+    // carried its own copy and none of them fit (see `wave-panels.js`'s
+    // `laneRow`). One copy each, here, acting on `selection` — the same mark
+    // the 週期 section and the brushes read, not a second one kept only for
+    // them.
+    //
+    // WHERE an insert lands is `laneInsertPath`'s asymmetry and cannot be
+    // argued away: an insert at a group's first lane joins that group, an
+    // insert just past its last lane does not. So the button says which
+    // container it is about to use BEFORE it is pressed — `data-lands-in`
+    // and the tooltip, both refreshed by `paintSelectionState` below on
+    // every repaint, full or fast — and the status line says it again
+    // after. That is the property the rail's per-row ＋ used to carry,
+    // moved rather than dropped.
+    const signalGroup = panels.toolGroup('訊號');
+    toolbar.appendChild(signalGroup);
 
-    function toolButton(cls, label, hint, fn) {
-      const b = d.createElement('button');
-      b.type = 'button';
-      b.className = cls;
-      b.setAttribute('data-focus-key', cls);
-      b.textContent = label;
-      b.title = hint;
-      b.addEventListener('click', fn);
-      cycleBar.appendChild(b);
-      return b;
+    /**
+     * Where 新增 / 空白列 put their new lane: right after the selection, and
+     * at the very top when there is nothing selected.
+     *
+     * "After the selection" is `laneTo + 1`, not `laneIndex + 1`: with a
+     * whole range picked, adding below the range is the only reading that
+     * does not silently cut it in half.
+     *
+     * The no-selection answer is 0 rather than the end, and that is the one
+     * choice here that is not obvious. The rail used to carry a ＋ at every
+     * position — one per row plus a tail — so every insert position from 0
+     * to n was reachable in one press. One button that only ever inserts
+     * AFTER something cannot offer position 0 at all: there is no lane to
+     * be after. Pairing "after the selection" with "0 when there is no
+     * selection" restores the full range — 0 with nothing picked, k+1 with
+     * lane k picked, the end with the last lane picked — and it costs one
+     * surprising default instead of one unreachable position. The button
+     * says which it is about to do before it is pressed (`data-lands-in`
+     * and the tooltip), so the surprise is visible rather than discovered.
+     */
+    function signalInsertAt(layout) {
+      const l = layout === undefined || layout === null
+        ? geometry.layoutOf(store.doc, SIZES) : layout;
+      if (selection === null) return 0;
+      return Math.min(selection.laneTo + 1, l.lanes.length);
     }
 
-    toolButton('ed-wave-cycle-insert', '插入 cycle',
-      '在選取的位置插入一個 cycle（每一條 lane 同時加寬，不會有人掉隊）', function () {
-        const at = selection === null ? 0 : Math.min(selection.from, selection.to);
-        commit('insert-cycle', function (doc) { return codec.insertCycles(doc, at, 1); });
-      });
-    toolButton('ed-wave-cycle-delete', '刪除 cycle',
-      '刪掉選取的 cycle（每一條 lane 同時變窄）', function () {
-        if (selection === null) { say('先選一段 cycle 再刪'); return; }
-        const from = Math.min(selection.from, selection.to);
-        const count = Math.abs(selection.to - selection.from) + 1;
-        commit('delete-cycle', function (doc) { return codec.deleteCycles(doc, from, count); });
-      });
-    toolButton('ed-wave-cycle-copy', '複製',
-      '把選取的 cycle 從每一條 lane 上拷一份', function () {
-        if (selection === null) { say('先選一段 cycle 再複製'); return; }
-        const from = Math.min(selection.from, selection.to);
-        const count = Math.abs(selection.to - selection.from) + 1;
-        clip = codec.copyCycles(store.doc, from, count);
-        say('複製了 ' + count + ' 個 cycle');
-        render();
-      });
-    toolButton('ed-wave-cycle-paste', '貼上（插入）',
-      '把剪貼簿插進選取的位置', function () { pasteAt('insert'); });
-    toolButton('ed-wave-cycle-paste-over', '貼上（覆蓋）',
-      '用剪貼簿蓋掉選取位置起算的那幾個 cycle', function () { pasteAt('overwrite'); });
+    function addLaneFromToolbar(name, lane) {
+      const at = signalInsertAt();
+      const landing = panels.landingOf(store.doc, at);
+      const where = landing.title === null ? '群組外' : '群組「' + landing.title + '」裡';
+      // Straight into the new lane's own name field — it is what the user
+      // types next, and on a spacer (no name to type) there is nothing
+      // else on that row to land on either. The lane arrives at display
+      // position `at`, so that is the key.
+      focusOverride = 'lane-name-' + at;
+      const added = commit(name, function (doc2) { return codec.addLane(doc2, at, lane); });
+      // fix round 1 (F6): the whole prefix per branch, not one concatenation
+      // with a shared 落在. The two bases this replaced differ by exactly one
+      // space — `say('新增的 lane 落在' + …)` has it because the phrase ends
+      // in a Latin word (so does 複製's message further down), and
+      // `say('空白列落在' + …)` does not because it ends in a CJK one. A
+      // single shared suffix has to get one of them wrong.
+      const lead = lane.wave === undefined ? '空白列落在' : '新增的 lane 落在';
+      if (added) panels.say(lead + where);
+    }
 
-    function pasteAt(mode) {
-      if (clip === null) { say('剪貼簿是空的'); return; }
-      const at = selection === null ? 0 : Math.min(selection.from, selection.to);
-      commit('paste-' + mode, function (doc) {
-        return codec.pasteCycles(doc, at, clip, mode);
+    const signalAddBtn = panels.toolButton('ed-wave-signal-add', '新增',
+      '在選取的 lane 後面加一條（沒有選取就加在最前面）', function () {
+        addLaneFromToolbar('add-lane', { name: '', wave: 'x' });
+      }, signalGroup);
+    // v3.5.0 Task 13: WaveDrom's own blank row, `{}`. There is deliberately
+    // no dedicated "remove spacer" control: a spacer is a lane like any
+    // other, so 刪除 below removes it exactly as it removes anything else.
+    const signalBlankBtn = panels.toolButton('ed-wave-signal-blank', '空白列',
+      '在選取的 lane 後面插入一個空白列（WaveJSON 的 {}，用來空出間距；刪除跟刪一般的 lane 一樣）',
+      function () { addLaneFromToolbar('add-spacer', {}); }, signalGroup);
+    const signalDeleteBtn = panels.toolButton('ed-wave-signal-delete', '刪除',
+      '刪掉選取的那幾條 lane（如果群組因此空掉，群組也會一起走）', function () {
+        if (selection === null) { panels.say('先選一條 lane 再刪'); return; }
+        const lo = selection.laneIndex;
+        const hi = selection.laneTo;
+        const n = hi - lo + 1;
+        // The rows about to stop existing are exactly the ones the marks
+        // name, so the selection goes FIRST — a selection naming cycles on
+        // a lane that is about to disappear is stale the instant `commit`
+        // runs, and that staleness is what `carryMarks` exists to prevent
+        // everywhere else.
+        selection = null;
+        // The rows about to vanish are also where the keyboard is allowed to
+        // land, and the button the user pressed is about to disable itself
+        // (no selection left), so naming a destination here is not a nicety:
+        // `restoreFocus`'s fallback would otherwise be a disabled button.
+        // Display position `lo` is whatever lane inherits the place the
+        // deleted range occupied — on a document emptied down to nothing the
+        // key simply is not there and `restoreFocus` falls back to the
+        // dialog, which is the right answer for「there is no row left」.
+        focusOverride = 'lane-name-' + lo;
+        // Bottom-up: every removal renumbers the rows BELOW it, so taking
+        // the highest index first leaves the ones still to go untouched.
+        //
+        // fix round 1: an earlier draft of this comment claimed a top-down
+        // loop would delete a DIFFERENT set of lanes. It would not, and the
+        // claim is withdrawn rather than reworded — checked against the
+        // codec over five ranges, group-spanning ones included: deleting
+        // `lo` n times and deleting hi..lo give the identical document,
+        // because whatever shifts into `lo` is the next member of a
+        // CONTIGUOUS range. What bottom-up actually buys is that each index
+        // still means the lane it meant when the range was measured, so the
+        // loop stays correct if a range that is not contiguous ever reaches
+        // it; top-down would be silently relying on the contiguity.
+        const removed = commit('remove-lane', function (doc2) {
+          let out = doc2;
+          for (let k = hi; k >= lo; k -= 1) out = codec.removeLane(out, k);
+          return out;
+        });
+        if (removed) panels.say('已刪掉 ' + n + ' 條 lane —— Ctrl+Z 可以拿回來');
+      }, signalGroup);
+    const signalCopyBtn = panels.toolButton('ed-wave-signal-copy', '複製',
+      '複製選取的 lane，接在它後面（data 等欄位一起複製；node 錨點不會跟著複製，' +
+      '避免兩條 lane 搶同一個字母）', function () {
+        if (selection === null) { panels.say('先選一條 lane 再複製'); return; }
+        // One lane, the range's first: `duplicateLane` copies one lane and
+        // lands it at `at + 1`, and a loop over a range would interleave
+        // each copy with the original it renumbers. The range's own far end
+        // is left alone rather than guessed at.
+        const at = selection.laneIndex;
+        const landing = panels.landingOf(store.doc, at + 1);
+        const where = landing.title === null ? '群組外' : '群組「' + landing.title + '」裡';
+        focusOverride = 'lane-name-' + (at + 1);
+        const didDup = commit('duplicate-lane', function (doc2) {
+          return codec.duplicateLane(doc2, at);
+        });
+        if (didDup) panels.say('複製的 lane 落在' + where);
+      }, signalGroup);
+
+    /**
+     * v3.6.0 Task 16: move the selected lane one row up (`step === -1`) or
+     * down (`step === 1`) — the keyboard's half of the rail handle's drag,
+     * reached by Alt+↑ / Alt+↓ in `onKeyDown`.
+     *
+     * ONE lane, the range's first, exactly as 複製 just above: `moveLane`
+     * moves one lane, and a loop over a range would renumber each member out
+     * from under the next. The range's far end is collapsed rather than
+     * guessed at, so what moved and what is selected afterwards are the same
+     * one lane.
+     *
+     * Both ends of the list REFUSE OUT LOUD instead of silently doing
+     * nothing. A key that does nothing and says nothing is, to the person
+     * pressing it, indistinguishable from a key this dialog never bound —
+     * and the status line is where every other refusal in here already goes.
+     *
+     * WHERE THE MARKS END UP. They are collapsed onto the moved lane BEFORE
+     * the commit, at its OLD row, and `carryMarks` — this file's single
+     * mechanism for "a mark follows its lane", by lane identity through
+     * `wave-store.laneTrace` — is what carries them to the new row.
+     * Re-pointing them by hand afterwards would cost a second `render()`
+     * (the one inside `commit` has already run and already consumed
+     * `focusOverride`) and would stand a second belief about where the lane
+     * went beside the trace's, which is the shape of defect this batch has
+     * paid for repeatedly. MEASURED in a real browser on the journey
+     * fixture, both from the trace alone: Alt+↓ on the lane selected at row
+     * 0 with no cell cursor yet took `data-wave-lane-range` 0,0 → 1,1 and
+     * left `data-wave-cursor` empty (no cursor is invented for a gesture
+     * that never entered the drawing); Alt+↑ with the cell cursor sitting on
+     * the moved lane at row 2 took `data-wave-cursor` 2,0 → 1,0 and
+     * `data-wave-lane-range` 2,2 → 1,1.
+     *
+     * The invariant 訊號's 刪除 quietly depends on — a non-null `selection`
+     * always names a lane that exists, so its `commit` always returns true —
+     * survives every exit here. The two refusals leave `selection` exactly
+     * as they found it. The commit path writes `{laneIndex: at, laneTo: at}`
+     * with `at` an index `renderCanvas`'s clamp has already vouched for, and
+     * a move changes no lane's EXISTENCE, so whether `carryMarks` then
+     * traces it to `to` (both ends of a collapsed range trace together) or
+     * drops it to null for want of an injected `laneTrace`, what is left is
+     * either a real row or nothing at all — never a row number with no lane
+     * under it.
+     */
+    function moveSelectedLane(step) {
+      if (selection === null) { panels.say('先選一條 lane 再搬'); return; }
+      const layout = geometry.layoutOf(store.doc, SIZES);
+      const at = selection.laneIndex;
+      const to = at + step;
+      if (to < 0) { panels.say('這已經是第一條 lane 了，沒有更上面的位置'); return; }
+      if (to >= layout.lanes.length) {
+        panels.say('這已經是最後一條 lane 了，沒有更下面的位置');
+        return;
+      }
+      selection = { laneIndex: at, laneTo: at, from: selection.from, to: selection.to };
+      // The lane arrives at row `to`, so the keyboard goes to the field it
+      // arrives in — the same rule the rail's own `drop` handler follows,
+      // and the whole reason `focusOverride` exists (see its declaration).
+      focusOverride = 'lane-name-' + to;
+      const didMove = commit('move-lane', function (doc2) {
+        return codec.moveLane(doc2, at, to);
       });
+      // v3.6.0 Task 16 fix round 1: SAY WHICH CONTAINER IT LANDED IN.
+      //
+      // `moveLane` may cross a group boundary — `laneInsertPath`'s asymmetry,
+      // which the whole 訊號 section already announces before and after every
+      // insert. MEASURED against the real codec on the journey fixture:
+      // Alt+↓ on `clk` at row 0 moves it INTO the group `bus`
+      // (`["clk",["bus",…]]` → `[["bus",["req","clk","dat"]],…]`), and the
+      // flattened name order is the only thing that changes on screen. Before
+      // this, the single word the user got back was `afterStoreMoved`'s
+      // generic「已寫回：move-lane」, so the one case in this function that
+      // re-parents a lane was also its quietest — while BOTH refusals spoke.
+      //
+      // Asked of the document AFTER the move, unlike 複製 above, which asks
+      // before because its lane does not exist yet. `laneInsertPath(doc, to)`
+      // means "in front of whichever lane sits at `to`, in THAT lane's own
+      // container", and after the move the lane at `to` is the moved one — so
+      // its answer is the moved lane's own container, including the
+      // group's-first-lane edge. Verified against the codec for all four
+      // moves the journey scenario makes: bus / 群組外 / bus / bus.
+      //
+      // ONE shared lead — `'搬動的 lane 落在'` — with only the container name
+      // branching. That is what the line below does, and the whole of what it
+      // needs to do.
+      //
+      // fix round 2 (N2) WITHDRAWS the claim that stood here ("the whole
+      // prefix per branch rather than one shared 落在, the same rule
+      // 新增/空白列 above record"), which said the opposite of the code
+      // directly beneath it. That rule exists because 新增 and 空白列 are TWO
+      // gestures sharing ONE handler whose leads differ by a space —
+      // `'新增的 lane 落在'` ends in a Latin word, `'空白列落在'` in a CJK one
+      // — and this function has no such axis: one gesture, one lead. The
+      // space after `lane` here is that typographic rule on its own, and the
+      // 群組外 / 群組「…」裡 tail is the identical two-way split 複製 uses.
+      if (didMove) {
+        const landing = panels.landingOf(store.doc, to);
+        panels.say('搬動的 lane 落在' +
+          (landing.title === null ? '群組外' : '群組「' + landing.title + '」裡'));
+      }
     }
 
-    const undoBtn = toolButton('ed-wave-undo', '復原', '退回上一個動作', function () {
-      if (!store.undo()) { say('沒有可以復原的動作'); return; }
+    // ── 群組 ──────────────────────────────────────────────────────────────
+    const groupGroup = panels.toolGroup('群組');
+    toolbar.appendChild(groupGroup);
+    // Wrap the selected lane range into one new group. The codec is the one
+    // that decides contiguity — this button does not pre-filter what is
+    // selectable, it only decides whether there is enough of a selection to
+    // bother trying, so the refusal message the user actually needed
+    // ("these lanes are not next to each other") comes from `commit`'s own
+    // status line rather than being silently swallowed here.
+    //
+    // v3.6.0 Task 14: the range is `selection`'s, not a second mark's — so
+    //「選起來的那幾條」names the same highlight the canvas and the Lane
+    // panel are showing, rather than a second one only this button could
+    // see. Shift+click on the rail is the one gesture that WIDENS it;
+    // Shift+↑/↓ on the canvas still collapses onto the lane it lands on
+    // (see `moveCursor`), which is why the tooltip names the rail and not
+    // the keyboard.
+    //
+    // The group is created with an EMPTY label and the rename field is
+    // opened immediately — the same affordance 新增 gives a brand new lane
+    // (empty `name`, keyboard straight into the field) — rather than a
+    // placeholder string the user has to notice and clear.
+    const groupBtn = panels.toolButton('ed-wave-group-make', '建立群組',
+      '把選起來的那幾條連續 lane 包成一個新群組（在左邊的 lane 列表上 Shift+點選一段）',
+      function () {
+        if (selection === null || selection.laneTo === selection.laneIndex) {
+          panels.say('先選至少兩條連續的 lane，才有東西可以群組');
+          return;
+        }
+        const ats = [];
+        for (let k = selection.laneIndex; k <= selection.laneTo; k += 1) ats.push(k);
+        const minAt = ats[0];
+        const committed = commit('group-lanes', function (doc2) {
+          return codec.groupLanes(doc2, ats, '');
+        });
+        if (!committed) {
+          panels.say('這幾條 lane 不連續（或選取已經失效），WaveJSON 的群組只能是連續的一段');
+          return;
+        }
+        // The commit above already repainted with the (now stale) highlight
+        // showing; one more repaint clears it before handing the keyboard to
+        // the rename field, the same two-step `renameGroup` itself already
+        // is — a rebuild first, then the sub-panel laid over what it built.
+        selection = null;
+        render();
+        const layout = geometry.layoutOf(store.doc, SIZES);
+        const spans = geometry.groupSpansOf(store.doc, layout);
+        for (const span of spans) {
+          if (span.from === minAt) { panels.renameGroup(span); break; }
+        }
+      }, groupGroup);
+    // v3.6.0 Task 14: 解散 the group the selected lane is a DIRECT member
+    // of. The lanes it held stay exactly where they were; only the wrapping
+    // array and its title go. `ungroupLanes`'s own docstring explains why
+    // "direct" is the only thing a display position can name — and why a
+    // group built entirely out of sub-groups therefore has no lane that
+    // names it, which is exactly the case `laneIsInGroup` below reports as
+    // "nothing to dissolve here" by disabling this button.
+    const groupDissolveBtn = panels.toolButton('ed-wave-group-dissolve', '解散群組',
+      '解散選取的 lane 所屬的那個群組（裡面的 lane 都留著，只是不再是一組）', function () {
+        if (selection === null) { panels.say('先選一條群組裡的 lane'); return; }
+        const at = selection.laneIndex;
+        // The lane at `at` survives ungrouping at the same display position
+        // (`ungroupLanes`: the flattened order and count never change), so
+        // its own name field is exactly where the keyboard should land.
+        focusOverride = 'lane-name-' + at;
+        const done = commit('ungroup', function (doc2) { return codec.ungroupLanes(doc2, at); });
+        if (!done) panels.say('這條 lane 不在任何群組裡');
+      }, groupGroup);
+
+    /**
+     * Whether display position `at` is a direct member of some group —
+     * `ungroupLanes`'s own precondition, asked of the layout rather than
+     * re-derived. A lane sitting straight under `signal` has a path of
+     * length 2 (`['signal', k]`); anything longer is inside at least one
+     * group.
+     */
+    function laneIsInGroup(layout, at) {
+      if (at < 0 || at >= layout.lanes.length) return false;
+      return layout.lanes[at].path.length > 2;
+    }
+    // ── 關聯線 ────────────────────────────────────────────────────────────
+    const edgeGroup = panels.toolGroup('關聯線');
+    toolbar.appendChild(edgeGroup);
+    // v3.5.0 Task 7: arm the edge-creation gesture. One-shot in the sense
+    // that a drag which PRODUCES an edge disarms it (`finishEdgeDrag` below);
+    // pressing the button itself is a plain toggle, so a change of mind
+    // before ever pressing on the canvas costs one more click, not Escape.
+    const edgeBtn = panels.toolButton('ed-wave-edge-arm', '關聯線',
+      '按一下武裝，然後從一格拖到另一格畫出關聯線（Escape 取消）', function () {
+        setEdgeMode(edgeMode === 'idle' ? 'armed' : 'idle');
+        // v3.6.0 Task 11: the transition dots (and their removal) are the
+        // only on-canvas evidence arming happened — `setEdgeMode` above
+        // only touches the button/overlay attributes, so without this the
+        // dots would not appear until some OTHER repaint happened to run
+        // first (the next cursor move, say), which is not "the instant you
+        // press the button".
+        render();
+      }, edgeGroup);
+    setEdgeMode('idle');
+
+    // ── 歷史 ──────────────────────────────────────────────────────────────
+    const historyGroup = panels.toolGroup('歷史');
+    toolbar.appendChild(historyGroup);
+    const undoBtn = panels.toolButton('ed-wave-undo', '復原', '退回上一個動作', function () {
+      if (!store.undo()) { panels.say('沒有可以復原的動作'); return; }
       afterStoreMoved('undo');
-    });
-    const redoBtn = toolButton('ed-wave-redo', '重做', '再做一次剛剛復原掉的動作', function () {
-      if (!store.redo()) { say('沒有可以重做的動作'); return; }
+    }, historyGroup);
+    const redoBtn = panels.toolButton('ed-wave-redo', '重做', '再做一次剛剛復原掉的動作', function () {
+      if (!store.redo()) { panels.say('沒有可以重做的動作'); return; }
       afterStoreMoved('redo');
-    });
+    }, historyGroup);
 
-    // head / foot — the document-level fields this drawing can honour.
-    //
-    // `config.hscale` USED to be a third field here and has been removed. The
-    // drawing does not model `hscale`, `period` or `phase` at all (zero
-    // occurrences in wave-codec, wave-geometry or this file), and measured
-    // against the pinned engine each of them changes what the engine paints
-    // while leaving the drawing exactly as it was:
+    // ── 匯出 ──────────────────────────────────────────────────────────────
     //
-    //     {wave:'0101'}                 engine 8 half-bricks   drawing 4 cycles
-    //     {wave:'0101', period:2}       engine 16              drawing 4, unchanged
-    //     {wave:'0101', phase:0.5}      engine 7               drawing 4, unshifted
-    //     {wave:'0101'} config.hscale:2 engine 16              drawing 4, unchanged
+    // v3.6.0 Task 15: the three buttons Task 12 created as shape.
     //
-    // Shipping a CONTROL for a property the canvas ignores is the worst of the
-    // three options: it invites the user to make the two pictures disagree and
-    // then shows them a confident wrong one. Modelling the three properly is
-    // not a change this file may make on its own either — cycle width lives in
-    // `wave-geometry`, which is closed and whose arithmetic Task 3 pinned, and
-    // a half-model here would be a SECOND belief about cycle geometry in the
-    // same tree, which is the exact failure this batch keeps producing.
+    // THE SOURCE IS THE PREVIEW'S SVG, never the canvas. The preview is the
+    // ENGINE'S OWN OUTPUT, so what a user exports is the same picture the
+    // rendered document shows; exporting the canvas would export this file's
+    // second implementation of that picture — the one precondition 3 in this
+    // module's header exists to stop from becoming a second belief on screen.
     //
-    // So: the control is gone, and a document that carries any of the three is
-    // told so out loud by `renderUnmodelled()` below rather than drawn wrongly
-    // in silence.
-    const metaBar = d.createElement('div');
-    metaBar.className = 'ed-wave-meta';
-    toolbar.appendChild(metaBar);
-
-    function metaField(cls, label, placeholder) {
-      const wrap = d.createElement('label');
-      wrap.className = 'ed-wave-metafield';
-      const text = d.createElement('span');
-      text.textContent = label;
-      wrap.appendChild(text);
-      const input = d.createElement('input');
-      input.type = 'text';
-      input.className = cls;
-      input.setAttribute('data-focus-key', cls);
-      input.placeholder = placeholder;
-      wrap.appendChild(input);
-      metaBar.appendChild(wrap);
-      return input;
+    // Every browser global the three need — `XMLSerializer`, `Blob`, `URL`,
+    // `Image`, `setTimeout`, `navigator` — is reached through `probeWin`
+    // (`d.defaultView`, declared beside `sourceText` above), never as a bare
+    // identifier: this file is require-able in node against a fake
+    // `opts.document` (see its header) and names no global of its own.
+
+    /**
+     * The preview's SVG, serialised so that it still draws OUTSIDE this page.
+     *
+     * The plain `serializeToString(svg)` that this obviously wants to be is a
+     * trap, and a quiet one. `renderPreview` renders with `notFirstSignal`
+     * true whenever a WaveDrom skin is already on the page — which is ALWAYS
+     * in the flow that reaches this editor, because the entry affordance only
+     * appears over a rendered diagram — so the preview SVG carries neither the
+     * skin's `<defs>` nor its `<style>`. MEASURED on this repo's own wave
+     * fixture: the preview SVG is 5057 bytes with 51 `<use>` elements, 0
+     * `<defs>` and 0 `<style>`, every one of those 51 pointing at an id that
+     * lives in a DIFFERENT SVG on the page. Serialised as-is it opens as half
+     * a picture — the whole clock lane and every brick shape gone, all text in
+     * the browser's default font — and it opens that way without erroring, so
+     * a check that the file was written, or that the click did not throw, sees
+     * nothing at all. Rasterised: 1409 non-white pixels of 54000 against 5693
+     * for the self-contained file.
+     *
+     * So: clone the preview, and if the clone has no `<defs>` of its own,
+     * prepend a CLONE of the page skin's `<style>` and `<defs>`.
+     */
+    function exportSvgText() {
+      const host = deps.previewHost;
+      const svg = (host === null || host === undefined) ? null : host.querySelector('svg');
+      if (svg === null || svg === undefined) return '';
+      const clone = svg.cloneNode(true);
+      if (clone.querySelector('defs') === null) {
+        // `#socket` is the skin's own first entry, asked for INSIDE a
+        // WaveDrom-rendered SVG's defs — the identical question, asked the
+        // identical way, that `renderPreview` asks to decide whether to emit a
+        // skin at all. Two different answers to "is the skin on this page"
+        // would be exactly the disagreement that leaves this export broken.
+        const socket = d.querySelector('svg.WaveDrom defs #socket');
+        const skin = socket === null ? null : socket.closest('svg');
+        if (skin !== null) {
+          const defs = skin.querySelector('defs');
+          const style = skin.querySelector('style');
+          // CLONED, never moved. These nodes are what every diagram ON THE
+          // PAGE draws from; an export that took them would blank the whole
+          // document behind the dialog the first time anyone pressed 匯出.
+          if (defs !== null) clone.insertBefore(defs.cloneNode(true), clone.firstChild);
+          if (style !== null) clone.insertBefore(style.cloneNode(true), clone.firstChild);
+        }
+      }
+      return new probeWin.XMLSerializer().serializeToString(clone);
+    }
+
+    function downloadBlob(blob, filename) {
+      const url = probeWin.URL.createObjectURL(blob);
+      const a = d.createElement('a');
+      a.href = url;
+      a.download = filename;
+      d.body.appendChild(a);
+      a.click();
+      a.remove();
+      // revoke 延後一拍：立刻 revoke 會讓某些瀏覽器在下載開始前就失去來源。
+      probeWin.setTimeout(function () { probeWin.URL.revokeObjectURL(url); }, 1000);
     }
 
-    const headInput = metaField('ed-wave-head-text', 'head', '上方標題');
-    const footInput = metaField('ed-wave-foot-text', 'foot', '下方標題');
+    function exportSvg() {
+      const text = exportSvgText();
+      if (text === '') { panels.say('預覽還沒畫出來，沒有東西可以匯出'); return; }
+      downloadBlob(new probeWin.Blob([text], { type: 'image/svg+xml' }), exportName('svg'));
+      panels.say('已匯出 ' + exportName('svg'));
+    }
 
-    headInput.addEventListener('change', function () { commitBanner('head', headInput.value); });
-    footInput.addEventListener('change', function () { commitBanner('foot', footInput.value); });
+    function exportPng() {
+      const text = exportSvgText();
+      if (text === '') { panels.say('預覽還沒畫出來，沒有東西可以匯出'); return; }
+      const svg = deps.previewHost.querySelector('svg');
+      const w = Number(svg.getAttribute('width'));
+      const h = Number(svg.getAttribute('height'));
+      // A zero-sized canvas is not an error to `toBlob`: it hands back a
+      // perfectly valid, perfectly empty PNG. Refuse it in words rather than
+      // let the user save a file that is a picture of nothing.
+      if (!(w > 0) || !(h > 0)) {
+        panels.say('預覽的尺寸讀不出來，PNG 匯不出去');
+        return;
+      }
+      const img = d.createElement('img');
+      img.onload = function () {
+        const cv = d.createElement('canvas');
+        cv.width = w; cv.height = h;
+        const ctx2 = cv.getContext('2d');
+        // The SVG's own background rect is white, but only over its own box;
+        // painting white first means a PNG dropped into a dark-themed document
+        // does not show that document's background through the margins.
+        ctx2.fillStyle = '#ffffff';
+        ctx2.fillRect(0, 0, w, h);
+        ctx2.drawImage(img, 0, 0);
+        cv.toBlob(function (blob) {
+          if (blob === null) { panels.say('PNG 轉檔失敗'); return; }
+          downloadBlob(blob, exportName('png'));
+          panels.say('已匯出 ' + exportName('png'));
+        }, 'image/png');
+      };
+      img.onerror = function () { panels.say('PNG 轉檔失敗'); };
+      // A data URI, not an object URL: an SVG loaded into an `<img>` renders
+      // in the browser's secure static mode either way, and a data URI needs
+      // no revoke to pair with it on a path that can end in `onerror`.
+      img.src = 'data:image/svg+xml;charset=utf-8,' + encodeURIComponent(text);
+    }
+
+    function exportJson() {
+      // `sourceText()`, not a second serialisation: this is the same walk of
+      // `store.toPatch()` that the 原始碼 panel shows and that 保留並關閉
+      // would write, so what lands on the clipboard can never disagree with
+      // either of them.
+      const text = sourceText();
+      const clip = probeWin.navigator && probeWin.navigator.clipboard;
+      if (clip && typeof clip.writeText === 'function') {
+        clip.writeText(text).then(function () {
+          panels.say('WaveJSON 已複製到剪貼簿');
+        }, function () {
+          panels.say('複製失敗，可以從右欄的原始碼面板手動選取');
+        });
+        return;
+      }
+      panels.say('這個瀏覽器不給用剪貼簿，可以從右欄的原始碼面板手動選取');
+    }
+
+    /**
+     * 檔名：markdown 檔名 + block 序號 + 副檔名。
+     *
+     * `opts.fileLabel` IS the source, and the caller has to pass it. The
+     * sentence that used to stand here — that `d.title` is "the same answer by
+     * another road", because md2doc writes `path.basename(src, '.md')` into
+     * `<title>` — was false the moment anyone edited anything. client.js owns
+     * the page title while a session is open and decorates it:
+     * `document.title = (documentIsDirty() ? '● ' : '') + baseTitle`. MEASURED
+     * on this repo's wave fixture, one lane-copy before pressing 匯出:
+     * `document.title` is `'● doc'` and the export lands as
+     * `●-doc-wave-1.svg`. The marker survives the sanitiser (`●` is not in its
+     * class, and stripping leading `-` runs does not reach it), and it only
+     * appears for a user who actually edited — so an export tried straight
+     * after opening gives the clean name and hides it.
+     *
+     * The fix is not to strip `'● '` here. That would put client.js's
+     * decoration format into a second file, and the next change to the marker
+     * would rot it silently. client.js passes `baseTitle` instead — the title
+     * as it was BEFORE it began decorating, which is the one value in this
+     * system that is exactly the markdown file's basename.
+     *
+     * `d.title` therefore stays only as a last resort for a host that passes
+     * no `fileLabel` at all (today there is none). It is NOT equivalent: it is
+     * whatever that host has written into the title by the time 匯出 is
+     * pressed.
+     *
+     * The sanitiser is not cosmetic: a filename with a `/` in it would
+     * otherwise reach `a.download` as a path separator.
+     */
+    function exportName(ext) {
+      const raw = String(opts.fileLabel || d.title || 'wave');
+      const label = raw.replace(/[\\/:*?"<>|\s]+/g, '-').replace(/^-+|-+$/g, '') || 'wave';
+      return label + '-wave-' + Number(opts.blockIndex || 0) + '.' + ext;
+    }
+
+    const exportGroup = panels.toolGroup('匯出');
+    toolbar.appendChild(exportGroup);
+    panels.toolButton('ed-wave-export-svg', 'SVG',
+      '把預覽那張圖存成 SVG 檔（含 WaveDrom 的 skin，離開這一頁也畫得出來）',
+      exportSvg, exportGroup);
+    panels.toolButton('ed-wave-export-png', 'PNG',
+      '把預覽那張圖存成 PNG 檔（白底，尺寸跟預覽一樣）',
+      exportPng, exportGroup);
+    panels.toolButton('ed-wave-export-wavejson', '複製 WaveJSON',
+      '把右欄原始碼面板上那份 WaveJSON 複製到剪貼簿',
+      exportJson, exportGroup);
+
+    // ── 檔案 ──────────────────────────────────────────────────────────────
+    //
+    // v3.6.0 Task 12: both wired now, unlike every disabled section above —
+    // neither waits on a later task. 保留並關閉 runs the SAME commit path the
+    // header's 關閉 button already runs (`close('commit')`); 放棄 is new:
+    // before this, discarding an edit was keyboard-only (Escape), so a
+    // pointer user had no way to abandon one. `close`'s own contract makes
+    // "anything that is not `'escape'` is a commit" the default, so wiring
+    // 放棄 is one line.
+    const fileGroup = panels.toolGroup('檔案');
+    toolbar.appendChild(fileGroup);
+    panels.toolButton('ed-wave-file-close', '保留並關閉',
+      '保留這次編輯並關閉（跟標題列的「關閉」是同一個動作）', function () {
+        close('commit');
+      }, fileGroup);
+    panels.toolButton('ed-wave-file-discard', '放棄',
+      '放棄這次編輯（跟 Esc 是同一個動作；按一次 Ctrl+Z 可以拿回來）', function () {
+        close('escape');
+      }, fileGroup);
+
+    // head / foot / hscale — the document-level fields the 文件 panel
+    // exposes, plus (below, in the Lane panel) a per-lane period/phase.
+    //
+    // v3.6.0 Task 8 fix round 2: the sentence that used to stand here —
+    // "the drawing does not model `hscale`, `period` or `phase` at all
+    // (zero occurrences in wave-codec, wave-geometry or this file)" — went
+    // false at Task 4 and nobody caught it until a review two tasks later.
+    // `wave-geometry.js`'s `layoutOf` reads a lane's own `period`/`phase`
+    // into `originX`/`cycleWidth`, and `hscaleOf(cfg)` reads `config.hscale`
+    // globally; `wave-draw.js` uses those per-lane values for every brick's
+    // x-coordinate. That is real modelling, not zero occurrences.
+    //
+    // v3.6.0 Task 9 fix round 2 (ruling R30) then closed the half that was
+    // still open when the paragraph above was written: the shared cycle grid
+    // and the ruler are DIAGRAM-wide and now derive from the same
+    // `hscale`-scaled diagram pitch the bricks are painted at, so they move
+    // with `period` and `config.hscale` too. `test/wave-draw.test.js` pins
+    // both fixtures value-by-value against the engine's own render —
+    // `period: 4` draws the engine's 17 ticks (0..16), not `cycles + 1`;
+    // `hscale: 2` draws them 96 apart (48 × 2), the case whose tick COUNT is
+    // unchanged and whose pitch is the only tell.
+    //
+    // So as of Task 18 `panels.renderUnmodelled()` no longer fires for any of
+    // the three: they are modelled, and saying otherwise is now the false
+    // statement. See that function's own block comment.
+    //
+    // v3.6.0 Task 13: a CONTROL for these three is back — `config.hscale`
+    // here, `period`/`phase` in the Lane panel below — because what made
+    // shipping one "the worst of the three options" (see the Task 8 comment
+    // this replaces) was a control that INVITES the two pictures to
+    // disagree while showing a confident wrong one. Relocating the fields
+    // into named, individually-labelled panel rows does not change that risk
+    // by itself. What closed it is Tasks 4 and 9 actually MODELLING the
+    // three — in `wave-geometry.js`'s `layoutOf`/`hscaleOf` and
+    // `wave-draw.js`'s diagram pitch, the one place cycle geometry is
+    // allowed to live, so this file never grew a second belief about it.
+    // A control that sets a value the canvas then draws is not the failure
+    // the Task 8 comment was guarding against.
+    const headInput = panels.metaField(
+      'ed-wave-head-text', 'head', '上方標題', 'head.text', panels.sections.document);
+    const headTickInput = panels.metaField('ed-wave-head-tick', 'head.tick',
+      '起始刻度，例如 0', 'head.tick', panels.sections.document);
+    const headTockInput = panels.metaField('ed-wave-head-tock', 'head.tock',
+      '半格刻度起始值，例如 0', 'head.tock', panels.sections.document);
+    const headEveryInput = panels.metaField('ed-wave-head-every', 'head.every',
+      '每幾格顯示一次刻度', 'head.every', panels.sections.document);
+    const footInput = panels.metaField(
+      'ed-wave-foot-text', 'foot', '下方標題', 'foot.text', panels.sections.document);
+    // v3.5.0 Task 13, fix round 1: the ruler fields — the COMPLETE set, not
+    // the three Task 13's own brief happened to name. Measured directly
+    // against the pinned engine rather than recalled: `renderMarks` in
+    // `node_modules/wavedrom/lib/render-marks.js` calls
+    // `ticktock(lane, 'head', 'tick', ...)`, `ticktock(lane, 'head', 'tock',
+    // ...)`, `ticktock(lane, 'foot', 'tick', ...)` and
+    // `ticktock(lane, 'foot', 'tock', ...)` — all four, not just
+    // `head.tick`/`foot.tock` — and inside `ticktock` itself,
+    // `cxt[ref1].every` is read off whichever of `head`/`foot` `ref1` is, so
+    // `every` applies under BOTH, not only `head`. That is eight keys —
+    // `{head, foot} × {text, tick, tock, every}` — of which the first Task
+    // 13 round shipped five (`head.text`/`foot.text` from v3.4.0, plus
+    // `head.tick`/`head.every`/`foot.tock`). The three missing ones
+    // (`head.tock`/`foot.tick`/`foot.every`) are added here so the set is
+    // complete rather than an arbitrary subset a user cannot predict — "why
+    // can I put a tick above the diagram but not below it" is exactly the
+    // shape of bug five-of-eight invites.
+    //
+    // Labels are the literal WaveJSON PATH (`head.tick`, not bare `tick`),
+    // not just the leaf key the first round used — with only one of
+    // tick/tock/every ever existing under `head` (and the mirror one under
+    // `foot`), a bare leaf label could not be confused for its sibling; with
+    // all four now under both, `tick` alone would leave two fields on screen
+    // both labelled `tick` with no way to tell which of them draws above the
+    // diagram and which below. `head`/`foot` on the two `.text` fields stay
+    // bare, since those never had a same-named sibling to begin with.
+    // Grouped head-then-foot in DOM order (four fields, then four fields)
+    // rather than the first round's ad hoc growth order, for the same
+    // readability reason. v3.6.0 Task 13: head/tick/tock/every are now
+    // created ABOVE, before `footInput`, so the document panel's DOM order
+    // is the full `head.*` group followed by the full `foot.*` group —
+    // `test/editor-journey.test.js`'s five-panel scenario pins this exact
+    // order.
+    const footTickInput = panels.metaField('ed-wave-foot-tick', 'foot.tick',
+      '下方起始刻度，例如 0', 'foot.tick', panels.sections.document);
+    const footTockInput = panels.metaField('ed-wave-foot-tock', 'foot.tock',
+      '下方半格刻度起始值，例如 0', 'foot.tock', panels.sections.document);
+    const footEveryInput = panels.metaField('ed-wave-foot-every', 'foot.every',
+      '下方每幾格顯示一次刻度', 'foot.every', panels.sections.document);
+    // v3.6.0 Task 13: the document panel's ninth field — see the block
+    // comment above for why a control for this is back at all.
+    const hscaleInput = panels.metaField('ed-wave-config-hscale', 'hscale',
+      '整份圖的水平縮放倍率（config.hscale，1-100 的整數；空白＝不設定）',
+      'config.hscale', panels.sections.document);
+    // Published for `panels.renderMeta`'s lazy read, same reason as
+    // `deps.headInput` etc. below — see `wave-panels.js`'s own header for
+    // why these stay a lazy `deps` read rather than a return value.
+    deps.headInput = headInput;
+    deps.footInput = footInput;
+    deps.headTickInput = headTickInput;
+    deps.headTockInput = headTockInput;
+    deps.headEveryInput = headEveryInput;
+    deps.footTickInput = footTickInput;
+    deps.footTockInput = footTockInput;
+    deps.footEveryInput = footEveryInput;
+    deps.hscaleInput = hscaleInput;
+
+    headInput.addEventListener('change', function () { panels.commitBanner('head', 'text', headInput.value); });
+    footInput.addEventListener('change', function () { panels.commitBanner('foot', 'text', footInput.value); });
+    headTickInput.addEventListener('change', function () { panels.commitBanner('head', 'tick', headTickInput.value); });
+    headTockInput.addEventListener('change', function () {
+      panels.commitBanner('head', 'tock', headTockInput.value);
+    });
+    headEveryInput.addEventListener('change', function () { panels.commitBanner('head', 'every', headEveryInput.value); });
+    footTickInput.addEventListener('change', function () {
+      panels.commitBanner('foot', 'tick', footTickInput.value);
+    });
+    footTockInput.addEventListener('change', function () { panels.commitBanner('foot', 'tock', footTockInput.value); });
+    footEveryInput.addEventListener('change', function () {
+      panels.commitBanner('foot', 'every', footEveryInput.value);
+    });
+    hscaleInput.addEventListener('change', function () {
+      panels.commitConfigField('hscale', hscaleInput.value);
+    });
+
+    // ── the Lane panel: period / phase for the currently selected lane ─────
+    //
+    // v3.6.0 Task 13: new. "Selected lane" here is the CYCLE selection's own
+    // `laneIndex` (`selection`, below) — this dialog has never had a
+    // separate "selected lane" concept, and inventing a second one only for
+    // these two fields would be a second belief about what "selected" means
+    // in the same file. Disabled whenever `selection` is null; see
+    // `panels.renderLaneField`'s own comment for the render side.
+    const lanePeriodInput = panels.metaField('ed-wave-lane-period', 'period',
+      '先選一段 cycle 才能設定', 'period', panels.sections.lane);
+    const lanePhaseInput = panels.metaField('ed-wave-lane-phase', 'phase',
+      '先選一段 cycle 才能設定', 'phase', panels.sections.lane);
+    deps.lanePeriodInput = lanePeriodInput;
+    deps.lanePhaseInput = lanePhaseInput;
+    lanePeriodInput.addEventListener('change', function () {
+      if (selection === null) return;
+      panels.commitLaneField(selection.laneIndex, 'period', lanePeriodInput.value);
+    });
+    lanePhaseInput.addEventListener('change', function () {
+      if (selection === null) return;
+      panels.commitLaneField(selection.laneIndex, 'phase', lanePhaseInput.value);
+    });
+
+    // ── the edge inspector row ──────────────────────────────────────────
+    //
+    // Same rule as `renderUnmodelled` below: HIDDEN, with no box on screen at
+    // all, unless `selectedEdge` names one — `renderEdgeBar` is what flips
+    // `edgeBar.hidden` and it is only ever called from `render()`, so the two
+    // can never disagree. Built once here, like `headInput`/`footInput`
+    // above; `render()` repaints its VALUES on every pass through
+    // `renderEdgeBar`, and the usual `data-focus-key` / `restoreFocus` pair
+    // is what keeps a half-typed label from losing the caret on that repaint.
+    const edgeBar = d.createElement('div');
+    edgeBar.className = 'ed-wave-edgebar';
+    edgeBar.hidden = true;
+    // v3.6.0 Task 13: the 關聯線 panel's body, not the toolbar — see
+    // `wave-panels.js`'s `sections` for why the container is available
+    // synchronously here.
+    panels.sections.edge.appendChild(edgeBar);
+
+    const shapeWrap = d.createElement('label');
+    shapeWrap.className = 'ed-wave-metafield';
+    const shapeWrapText = d.createElement('span');
+    shapeWrapText.textContent = '形狀';
+    shapeWrap.appendChild(shapeWrapText);
+    const shapeSel = d.createElement('select');
+    shapeSel.className = 'ed-wave-edge-shape';
+    shapeSel.setAttribute('data-focus-key', 'ed-wave-edge-shape');
+    for (const s of codec.EDGE_SHAPES) {
+      const o = d.createElement('option');
+      o.value = s;
+      o.textContent = s;
+      shapeSel.appendChild(o);
+    }
+    shapeSel.addEventListener('change', function () {
+      if (selectedEdge === null) return;
+      commit('edge-shape', function (doc) {
+        const cur = codec.parseEdge((doc.edge || [])[selectedEdge]);
+        if (cur === null) return doc;
+        return codec.updateEdge(doc, selectedEdge,
+          { from: cur.from, to: cur.to, shape: shapeSel.value, label: cur.label });
+      });
+    });
+    shapeWrap.appendChild(shapeSel);
+    edgeBar.appendChild(shapeWrap);
+
+    const edgeLabelWrap = d.createElement('label');
+    edgeLabelWrap.className = 'ed-wave-metafield';
+    const edgeLabelWrapText = d.createElement('span');
+    edgeLabelWrapText.textContent = '標籤';
+    edgeLabelWrap.appendChild(edgeLabelWrapText);
+    const edgeLabelInput = d.createElement('input');
+    edgeLabelInput.type = 'text';
+    edgeLabelInput.className = 'ed-wave-edge-label';
+    edgeLabelInput.setAttribute('data-focus-key', 'ed-wave-edge-label');
+    edgeLabelInput.placeholder = '這條線的標籤';
+    edgeLabelInput.addEventListener('change', function () {
+      if (selectedEdge === null) return;
+      commit('edge-label', function (doc) {
+        const cur = codec.parseEdge((doc.edge || [])[selectedEdge]);
+        if (cur === null) return doc;
+        return codec.updateEdge(doc, selectedEdge,
+          { from: cur.from, to: cur.to, shape: cur.shape, label: edgeLabelInput.value });
+      });
+    });
+    edgeLabelWrap.appendChild(edgeLabelInput);
+    edgeBar.appendChild(edgeLabelWrap);
+
+    const edgeDeleteBtn = d.createElement('button');
+    edgeDeleteBtn.type = 'button';
+    edgeDeleteBtn.className = 'ed-wave-edge-delete';
+    edgeDeleteBtn.setAttribute('data-focus-key', 'ed-wave-edge-delete');
+    edgeDeleteBtn.textContent = '刪除這條線';
+    edgeDeleteBtn.title = '刪掉這條關聯線（連帶清掉沒有其他 edge 再用的 anchor 字母）';
+    edgeDeleteBtn.addEventListener('click', function () {
+      if (selectedEdge === null) return;
+      const at = selectedEdge;
+      // Cleared BEFORE `commit`, not after: `commit` repaints synchronously,
+      // and `removeEdge` shifts every later entry's index down by one — so an
+      // index cleared only after `commit` returns would let `render()`'s
+      // clamp see a DIFFERENT edge that happens to have landed on the same
+      // number, and silently keep the inspector open on it.
+      selectedEdge = null;
+      commit('edge-remove', function (doc) {
+        return codec.pruneNodes(codec.removeEdge(doc, at));
+      });
+    });
+    edgeBar.appendChild(edgeDeleteBtn);
+    // Published for `panels.renderEdgeBar`'s lazy read, same reason as
+    // `deps.metaBar` above.
+    deps.edgeBar = edgeBar;
+    deps.shapeSel = shapeSel;
+    deps.edgeLabelInput = edgeLabelInput;
 
     // The "this drawing is not showing you everything" notice. Empty, and with
     // no box on screen, for the documents that carry none of the three.
@@ -821,19 +1927,18 @@
     noSignal.className = 'ed-wave-unmodelled ed-wave-nolanes';
     noSignal.hidden = true;
     toolbar.appendChild(noSignal);
+    // Published for `panels.renderUnmodelled`'s lazy read, same reason as
+    // `deps.headInput` etc. above.
+    deps.unmodelled = unmodelled;
+    deps.noSignal = noSignal;
 
-    function commitBanner(which, value) {
-      commit(which, function (doc) {
-        const had = doc[which];
-        if (value === '' && (had === undefined || had === null)) return doc;
-        const next = Object.assign({}, doc);
-        next[which] = Object.assign({}, (had !== null && typeof had === 'object') ? had : {});
-        next[which].text = value;
-        return next;
-      });
-    }
-
-    // ── body: lane list | drawing | preview ───────────────────────────────
+    // ── body: lane list | drawing | right-hand column ──────────────────────
+    //
+    // v3.6.0 Task 13: the body's third column USED to be `previewWrap`
+    // directly; it is now `panels.side`, the five-section right-hand column
+    // built inside `createPanels()` (see `wave-panels.js`'s own comment
+    // above `side`/`sections`), and `previewWrap` moves one level deeper,
+    // into `panels.sections.preview`.
     const body = d.createElement('div');
     body.className = 'ed-wave-body';
     panel.appendChild(body);
@@ -841,6 +1946,9 @@
     const laneCol = d.createElement('div');
     laneCol.className = 'ed-wave-lanes';
     body.appendChild(laneCol);
+    // Published for `panels.renderLanes`/`panels.renameGroup`'s lazy read,
+    // same reason as `deps.headInput` etc. above.
+    deps.laneCol = laneCol;
 
     const canvasWrap = d.createElement('div');
     canvasWrap.className = 'ed-wave-canvas-wrap';
@@ -860,7 +1968,15 @@
     // This preview belongs to neither.
     previewHost.id = PREVIEW_ID_PREFIX + PREVIEW_INDEX;
     previewWrap.appendChild(previewHost);
-    body.appendChild(previewWrap);
+    panels.sections.preview.appendChild(previewWrap);
+    // Published for `panels.renderPreview`'s lazy read, same reason as
+    // `deps.headInput` etc. above.
+    deps.previewWrap = previewWrap;
+    deps.previewHost = previewHost;
+
+    // The right-hand column itself, appended once — the position the old
+    // `previewWrap` occupied directly in `body`.
+    body.appendChild(panels.side);
 
     const status = d.createElement('div');
     status.className = 'ed-wave-status';
@@ -869,11 +1985,9 @@
     // the one place that has to be announced rather than merely painted.
     status.setAttribute('role', 'status');
     panel.appendChild(status);
-
-    function say(text) {
-      status.textContent = text;
-      overlay.setAttribute('data-wave-status', text);
-    }
+    // Published for `panels.say`'s lazy read, same reason as `deps.metaBar`
+    // above.
+    deps.status = status;
 
     // ── the one road from a gesture to the document ───────────────────────
     /**
@@ -898,7 +2012,7 @@
       if (closed) return false;
       const changed = store.apply(name, fn);
       if (!changed) {
-        say('這個動作沒有改變任何東西');
+        panels.say('這個動作沒有改變任何東西');
         return false;
       }
       gestures++;
@@ -932,10 +2046,51 @@
       if (marksDoc === nextDoc) return;
       const before = marksDoc;
       marksDoc = nextDoc;
-      if (before === null || (cursor === null && selection === null)) return;
+      // Fix round 2: `pendingFrom` joins the guard's own "is there anything
+      // to carry" question — widened rather than given a second guard of
+      // its own, so there stays ONE call to `opts.laneTrace` and ONE
+      // `rowOf` built from it, not a second belief about the lookup living
+      // next to the first. Reachable with `cursor`/`selection` both null:
+      // the keyboard's `armed` state is not locked to a document capture
+      // the way a mouse drag is, so a user can mark a start cell with
+      // Enter, delete every lane from the toolbar (which nulls `cursor`/
+      // `selection` in `renderCanvas`'s own clamp but left `pendingFrom`
+      // alone before this fix), add lanes back past the stale index, and
+      // finish the gesture — silently anchoring an edge to a lane the
+      // trace never actually confirmed, because the lookup below was
+      // skipped entirely while `pendingFrom` was the only mark still
+      // standing. `ensureNode` bounds-checks against whatever document is
+      // in hand at THAT moment, not against the one `pendingFrom` was
+      // marked in, so a stale-but-back-in-range index is silently valid to
+      // it — this file's worst failure class, wrong data written with
+      // nothing on screen that explains it.
+      // v3.5.0 Task 8: `endpointDrag` widens this same guard rather than
+      // getting one of its own, for the identical reason `pendingFrom` did
+      // in fix round 2 — one call to `opts.laneTrace`, one `rowOf`, not a
+      // second belief about the lookup. Reachable with the other three all
+      // null: a keyboard undo/redo reached WHILE a mouse button is down
+      // dragging an endpoint is exactly the same shape of gap `pendingFrom`
+      // closed — the pointer holds no document capture of its own, only
+      // this variable's `at` does.
+      // v3.6.0 Task 14: `selection` carries the rail's lane range itself
+      // now, so these three are the whole list again — there is no fourth
+      // set of row numbers standing beside them to ask about.
+      if (before === null ||
+          (cursor === null && selection === null && pendingFrom === null &&
+           endpointDrag === null)) {
+        return;
+      }
       const trace = typeof opts.laneTrace === 'function'
         ? opts.laneTrace(before, nextDoc) : null;
-      if (trace === null) { cursor = null; selection = null; return; }
+      // No `laneTrace` injected: "I no longer know where you were" applies
+      // to `pendingFrom` exactly as it already does to `cursor`/`selection`
+      // — dropped, not guessed at. `endpointDrag` joins them: a drag naming
+      // a lane nothing here can still vouch for is the same hazard either
+      // way.
+      if (trace === null) {
+        cursor = null; selection = null; pendingFrom = null; endpointDrag = null;
+        return;
+      }
       // Structural or not: a content operation traces as the identity, so this
       // is a no-op for a paint without having to know that it is one.
       const rowOf = function (was) {
@@ -949,10 +2104,79 @@
         if (at !== null) cursor = { laneIndex: at, cycle: cursor.cycle };
       }
       if (selection !== null) {
-        const at = rowOf(selection.laneIndex);
-        if (at !== null) {
-          selection = { laneIndex: at, from: selection.from, to: selection.to };
-        }
+        // v3.6.0 Task 14, tightened in fix round 1: BOTH ends of the lane
+        // range are retraced, independently, and an end the trace cannot
+        // vouch for is DROPPED rather than left on a stale number. That is
+        // the member-by-member rule the retired lane multi-select used
+        // ("an entry that cannot be traced is removed"), applied to a pair.
+        //
+        // Round 0 put this whole block inside `if (rowOf(laneIndex) !== null)`,
+        // which reads like a guard and is not one: when the range's FIRST
+        // lane was the one that vanished, nothing ran and BOTH numbers were
+        // left standing. `renderCanvas`'s clamp does not save it — that
+        // only pulls `laneTo` down to the last row and never collapses a
+        // range — so 建立群組 and 訊號's 刪除 acted on a span the user never
+        // selected. Reachable in three gestures: insert a lane, Shift-select
+        // from it downwards, undo the insert.
+        //
+        // What survives, by case:
+        //   both ends traced → the traced range (re-normalised: a reorder
+        //                      can swap which end is lower)
+        //   one end traced   → collapsed onto that end — the one lane still
+        //                      vouched for
+        //   neither traced   → collapsed onto `laneIndex`'s OLD number. The
+        //                      number is kept because `laneIndex` doubles as
+        //                      a screen position `renderCanvas` re-clamps and
+        //                      `cursor`'s own "land on whoever took the
+        //                      place" instinct is right for that; the SPAN is
+        //                      not kept, so a structural op can at worst
+        //                      touch that one row, never a range.
+        const near = rowOf(selection.laneIndex);
+        const far = rowOf(selection.laneTo);
+        const a = near !== null ? near : (far !== null ? far : selection.laneIndex);
+        const b = far !== null ? far : a;
+        selection = {
+          laneIndex: Math.min(a, b), laneTo: Math.max(a, b),
+          from: selection.from, to: selection.to,
+        };
+      }
+      // `pendingFrom` is a mark of the exact same shape as `cursor` (a row
+      // number plus a cycle), carried the same way — by lane IDENTITY
+      // through this same trace, not by raw row number (see the guard
+      // above for why it must reach here even when `cursor`/`selection`
+      // cannot). It deliberately does NOT copy cursor's "leave the number
+      // alone when untraceable" half, though: `cursor` gets away with that
+      // because `renderCanvas` re-clamps it into range on every repaint, and
+      // because a cursor landing on "whatever now occupies that visual
+      // position" after its own lane vanished is the right instinct for a
+      // position marker. `pendingFrom` has no such clamp anywhere, and it is
+      // not a position — it is a lane the user already committed to as one
+      // fixed end of an edge. Fix round 2: leaving it at a stale raw index
+      // is exactly the hazard the coordinator's review walked to the end —
+      // delete the marked lane, add unrelated lanes back until the count
+      // passes the stale number again, and `ensureNode` would bounds-check
+      // successfully against a lane the user never chose. So an untraceable
+      // `pendingFrom` is DROPPED here, the same as `trace === null` above
+      // drops it wholesale — never left standing on a number nothing
+      // vouches for.
+      if (pendingFrom !== null) {
+        const at = rowOf(pendingFrom.at);
+        pendingFrom = at === null ? null : { at: at, cell: pendingFrom.cell };
+      }
+      // `endpointDrag.at` is a mark of the exact same shape as
+      // `pendingFrom.at` — a lane the user is currently pointing a live
+      // gesture at, not a position `renderCanvas` re-clamps on every
+      // repaint — so it is carried the same way and dropped the same way
+      // when the lane it named cannot be traced. Left alone while `at` is
+      // still `null` (mousedown fired, no `pointermove` has landed on a
+      // real cell yet): there is no row number there yet to go stale.
+      // `index`/`end`/`cell` are not row numbers and need no retracing
+      // here — `index` is guarded separately by `render()`'s widened
+      // `selectedEdge` clamp (the drag dies with the selection it drags).
+      if (endpointDrag !== null && endpointDrag.at !== null) {
+        const at = rowOf(endpointDrag.at);
+        endpointDrag = at === null ? null
+          : { index: endpointDrag.index, end: endpointDrag.end, at: at, cell: endpointDrag.cell };
       }
     }
 
@@ -965,9 +2189,9 @@
       lastPatch = store.toPatch();
       render();
       if (lastPatch.ok === true) {
-        say('已寫回：' + name);
+        panels.say('已寫回：' + name);
       } else {
-        say('這個改動沒辦法只改幾個位元組寫回去：' + lastPatch.reason);
+        panels.say('這個改動沒辦法只改幾個位元組寫回去：' + lastPatch.reason);
       }
       if (typeof opts.onGesture === 'function') {
         opts.onGesture({ name: name, patch: lastPatch, store: store });
@@ -977,6 +2201,192 @@
     // ── painting ──────────────────────────────────────────────────────────
     let canvas = null;
 
+    /**
+     * v3.6.0 Task 13 fix round 4: keep the CURRENTLY selected edge's own
+     * drawn handles clear of the expanded side rail — by narrowing the
+     * RAIL, never by moving the canvas.
+     *
+     * Diagnosed against a real page before writing this (see task-13-
+     * report.md, fix round 4), and the first two things tried both failed
+     * against that diagnosis before this one was chosen:
+     *
+     *   1. Hypothesis (mine and the reviewer's, both wrong): the expand
+     *      reflows the canvas mid-gesture, so a point resolved before it
+     *      goes stale. MEASURED false — `.ed-wave-canvas`'s own
+     *      `getBoundingClientRect()` is IDENTICAL before, during and after
+     *      the whole gesture. Nothing moves.
+     *   2. First fix tried: scroll the canvas horizontally to carry the
+     *      handle out from under the rail (`canvasWrap.scrollLeft`), the
+     *      same technique `pointInCanvas` uses in the test suite. MEASURED
+     *      to do nothing on the fixture that actually fails: a short
+     *      document's drawn content is NARROWER than the wrap's own
+     *      `clientWidth`, so `scrollWidth === clientWidth` — there is no
+     *      scrollABLE range at all, and setting `scrollLeft` past 0 is
+     *      silently clamped straight back to 0. The rail's expansion does
+     *      not add any scrollable width to the wrap (it is an absolutely
+     *      positioned overlay, outside the wrap's own box model), so a
+     *      short document can never be scrolled clear of it.
+     *
+     * The actual defect both of those diagnosed correctly but did not fix
+     * is occlusion, not displacement: the expanded rail is `position:
+     * absolute`, OPAQUE, `z-index: 3`, painted ON TOP of the canvas at a
+     * narrow viewport (round 1's own deliberate design — the rail overlays
+     * rather than squeezes, so the canvas keeps its width-budget win).
+     * `elementFromPoint` at the handle's own coordinates resolved to a
+     * `<span>` INSIDE the rail, not the handle — because the rail is what
+     * is actually painted there now, regardless of scroll position.
+     *
+     * So this narrows the rail instead: its `width` (normally 340px, the
+     * CSS default) is set only as far down as needed to keep the selected
+     * edge's rightmost handle clear, floored at `MIN_WIDTH` so the panel
+     * never shrinks to something unusable. `right: 0` stays anchored (the
+     * CSS is untouched), so shrinking width moves the rail's LEFT edge
+     * right, away from the handle, while the canvas itself never moves at
+     * all — satisfying the same invariant the "reflow mid-gesture"
+     * hypothesis was chasing (`.ed-wave-canvas`'s rect never changes
+     * between a press and its release) for a different, correct reason.
+     *
+     * Recomputed from scratch on every call (the leading `style.width =
+     * ''` is not an optimization to skip) rather than only on a change of
+     * `selectedEdge` — an unrelated repaint can still move a lane's own
+     * geometry (hscale, a resize) while the SAME edge stays selected, and
+     * a stale width would either pointlessly over-narrow the rail or,
+     * worse, under-narrow it and silently reopen the exact defect this
+     * exists to close.
+     *
+     * Selecting an edge is very often immediately followed by dragging the
+     * very handle selection just exposed — it is the ONLY way to adjust an
+     * endpoint (`onCanvasDown`'s drag-start branch only ever fires for the
+     * SELECTED edge's own handle), so select-then-drag is not an edge
+     * case, it is the whole mechanism this protects.
+     *
+     * v3.6.0 final fix (M2): every handle is measured against the WRAP's own
+     * visible rect before it is allowed to move anything. `.ed-wave-canvas-
+     * wrap` is `overflow: auto`, and `getBoundingClientRect()` on a child it
+     * has scrolled or clipped out of sight still returns a full viewport
+     * rect for a box that is painted NOWHERE — this repo's own documented
+     * trap, which the test helper `pointInCanvas` already applies and this
+     * function did not. Two things follow, and both are load-bearing:
+     *
+     *   - A handle with no intersection with the wrap's rect is SKIPPED
+     *     outright. It cannot be overlapped by the rail, because it is not
+     *     on screen to overlap.
+     *   - A handle that is only PARTLY visible contributes the right edge of
+     *     its visible part (`min(r.right, wrapRect.right)`), not its full
+     *     rect's right. Clamping alone would not do: a fully clipped handle
+     *     clamps to `wrapRect.right`, which is the largest value in the
+     *     whole calculation and would narrow the rail harder than the real
+     *     defect did. The skip is what makes the clamp safe.
+     *
+     * MEASURED on the fixture `test/wave-rail-clearance.test.js` now carries
+     * (24 cycles, `edge: ['a~>b']` from cycle 1 to cycle 20, a real press on
+     * the drawn `.ed-wave-edge-hit` stroke), at 1000x900 — the viewport this
+     * whole version exists for, since `.ed-wave-side[data-expanded]` is
+     * `position: absolute` below 1100px:
+     *
+     *     to-handle right 1332.2   wrap right 970   visible false
+     *     before: side.style.width '160px'  rendered 160px  label input 23px
+     *     after:  side.style.width ''       rendered 340px  label input 203px
+     *
+     * The rail was being collapsed to its floor by a handle drawn 362px
+     * past the clip. The edge-shape `<select>` measures 50px in BOTH states
+     * and is deliberately NOT quoted as a symptom — it is a fixed-width
+     * control, so it survives the squeeze that guts the `<input>` beside it,
+     * and quoting it would read as damage that was never there.
+     *
+     * The wrap's border box is used for that visibility test rather than its
+     * padding box, matching `pointInCanvas`'s own visibility check (which
+     * reserves the padding box for scroll ARITHMETIC). The wrap carries
+     * padding and no border, and content is visible inside padding, so the
+     * two boxes are the same rect here anyway.
+     *
+     * Where this genuinely does nothing, stated as the code behaves rather
+     * than as round 4 hoped: an inline width IS still applied at a wide
+     * viewport — MEASURED 160px at 1280x900 and 198px at 1600x900 on that
+     * same 24-cycle document before this fix, i.e. the old "no inline width
+     * is ever applied at a wide viewport" claim was simply false. It was
+     * harmless there for a DIFFERENT reason than the one claimed:
+     * `.ed-wave-side`'s `flex: 0 0 340px` beats an inline `width` for a flex
+     * item's main size, so the rendered column stayed 340px regardless. The
+     * same mechanism covers the collapsed 28px rail (`flex: 0 0 28px`), so a
+     * leftover inline style from a PRIOR expansion cannot keep it
+     * artificially wide. Only the `position: absolute` expanded state below
+     * 1100px takes the inline width for real — which is exactly why that is
+     * the state the defect showed up in.
+     *
+     * Residual, accepted limit — and it IS reached, including by this
+     * function's own test fixture. When `bodyRight - rightmost - MARGIN`
+     * falls below `MIN_WIDTH`, this clamps to `MIN_WIDTH` rather than
+     * shrinking further, and the selected handle stays covered by the rail.
+     *
+     * MEASURED at HEAD on `MEDIUM_MD` — the 12-cycle fixture in
+     * `test/wave-rail-clearance.test.js`'s own scenario 2 — at 1000x900:
+     *
+     *     to-handle 888.2–900.2, painted and not clipped at all
+     *     bodyRight 970 -> fits = 970 - 900.2 - 4 = 65.8  (< MIN_WIDTH)
+     *     side.style.width '160px', so the rail's left edge lands at 810
+     *     => 90.2px of the handle is still under the rail, and
+     *        `elementFromPoint` at the handle's own centre returns a
+     *        `<span>` INSIDE `.ed-wave-side`, not the handle
+     *
+     * It needs no contrived fixture: 16 cycles with the `to` end at cycle
+     * 12, at 970x900, leaves 166.4px of overlap the same way.
+     *
+     * The sentence that stood here — "a small residual overlap in a
+     * genuinely too-narrow-to-satisfy-both-at-once case … which no fixture
+     * here produces" — was therefore wrong three times: the overlap is most
+     * of the handle rather than small, the case is ordinary rather than
+     * genuinely-too-narrow, and the fixture that produces it shipped in the
+     * SAME commit as the sentence denying it. It is recorded rather than
+     * quietly replaced because it is this batch's signature defect (a true
+     * piece of code with a false sentence beside it) landing inside the
+     * delivery that exists to fix that defect — one clause after the
+     * warning that "no fixture here reaches it" is a claim about fixtures,
+     * never about what a user can reach.
+     *
+     * Why it is accepted rather than fixed here: below 1100px the rail is
+     * `position: absolute` and `bodyRight === wrapRight` (MEASURED: both
+     * 970 above), so a handle drawn near the right-hand end of a wide
+     * diagram cannot be cleared by narrowing the rail AT ALL — no width
+     * satisfies both, and `MIN_WIDTH` is the floor precisely so the panel
+     * does not become unusable while trying. Clearing it needs a different
+     * mechanism (scroll the wrap, or anchor the overlay to the other edge),
+     * which is a design change and not a bound to re-tune.
+     *
+     * One more thing this does not do, in the opposite direction, and it
+     * behaves identically before and after the fix above so it is not a
+     * regression: the wrap has no scroll listener, so scrolling AFTER an
+     * edge is selected does not re-run the verdict. MEASURED on the
+     * 24-cycle fixture at 1000x900 — `scrollLeft = 356` brings the `to`
+     * handle back to 964.2–976.2, i.e. painted and squarely under the rail,
+     * while `side.style.width` stays `''` from the reading taken at
+     * `scrollLeft 0`. That is the only measurable way the new
+     * skip-what-the-wrap-clipped rule can be wrong, and it is a STALE
+     * verdict rather than a wrong one.
+     */
+    function clearSelectedEdgeOfSide() {
+      panels.side.style.width = '';
+      if (selectedEdge === null) return;
+      const bodyRight = body.getBoundingClientRect().right;
+      const wrapRect = canvasWrap.getBoundingClientRect();
+      let rightmost = null;
+      for (const end of ['from', 'to']) {
+        const h = d.querySelector('.ed-wave-edge-handle[data-edge-index="' +
+          selectedEdge + '"][data-edge-handle="' + end + '"]');
+        if (h === null) continue;
+        const r = h.getBoundingClientRect();
+        if (r.right <= wrapRect.left || r.left >= wrapRect.right) continue;
+        if (r.bottom <= wrapRect.top || r.top >= wrapRect.bottom) continue;
+        const painted = Math.min(r.right, wrapRect.right);
+        if (rightmost === null || painted > rightmost) rightmost = painted;
+      }
+      if (rightmost === null) return;
+      const MARGIN = 4;
+      const MIN_WIDTH = 160;
+      const fits = bodyRight - rightmost - MARGIN;
+      if (fits < 340) panels.side.style.width = Math.max(MIN_WIDTH, Math.round(fits)) + 'px';
+    }
+
     /**
      * Repaint everything, and give the keyboard cursor back where it was.
      *
@@ -1008,13 +2418,101 @@
       const before = focusMark();
       const doc = store.doc;
       const layout = geometry.layoutOf(doc, SIZES);
-      renderLanes(doc, layout);
-      renderCanvas(doc, layout);
-      renderPreview(doc);
-      renderMeta(doc);
-      renderUnmodelled(doc);
+      // Clamped BEFORE `renderCanvas`/`renderEdgeBar` read it, and against
+      // `edgeLayout`'s own filtered list rather than `doc.edge.length` — an
+      // edge whose anchor letter went missing is still an array element (so
+      // a length check would miss it) but `edgeLayout` already will not draw
+      // it, and an inspector row pointed at an edge nothing on screen shows
+      // is exactly the stale-selection defect `carryMarks` above exists to
+      // avoid for lanes.
+      if (selectedEdge !== null && !edgeIsDrawable(doc, layout, selectedEdge)) {
+        selectedEdge = null;
+      }
+      // v3.5.0 Task 8: `endpointDrag.index` can only ever be reached from
+      // `selectedEdge`'s own drawn handle (see `onCanvasDown`), so the two
+      // may never disagree — checked with `!==` rather than "is `index`
+      // still drawable" on its own, because that would let a drag survive a
+      // mid-drag undo that DESELECTS the edge without deleting it (the
+      // clamp above nulls `selectedEdge` on its own timing). A drag that
+      // outlives the selection it was dragging is exactly the class of
+      // hazard Task 7 paid three rounds to close for `pendingFrom`/
+      // `edgeMode`; this is the same rule applied to this task's own mark.
+      if (endpointDrag !== null && endpointDrag.index !== selectedEdge) {
+        endpointDrag = null;
+      }
+      panels.renderLanes(doc, layout, { selection: selection });
+      // v3.6.0 Task 13: the Lane panel's period/phase — same `selection` mark
+      // `renderLanes` above already reads for the CYCLE highlight, not a
+      // second "selected lane" concept.
+      panels.renderLaneField(doc, layout, { selection: selection });
+      const wds = {
+        cursor: cursor,
+        selection: selection,
+        pendingFrom: pendingFrom,
+        endpointDrag: endpointDrag,
+        selectedEdge: selectedEdge,
+        overlay: overlay,
+        canvasWrap: canvasWrap,
+        dataEdit: dataEdit,
+        enterDrawing: enterDrawing,
+        onCanvasDown: onCanvasDown,
+        onCanvasHover: onCanvasHover,
+        edgeMode: edgeMode,
+        hoverBoundary: hoverBoundary,
+      };
+      canvas = drawer.renderCanvas(canvas, doc, layout, wds);
+      cursor = wds.cursor;
+      selection = wds.selection;
+      panels.renderEdgeBar(doc, { selectedEdge: selectedEdge });
+      // v3.6.0 Task 13 fix round 3: selecting an edge is an action whose
+      // ENTIRE feedback surface is the 關聯線 panel just painted above —
+      // at a narrow viewport (<1100px) that panel sits inside the
+      // collapsed rail, where every one of its controls renders at zero
+      // size (`wave-panels.js`'s `section()` docstring and `lib/md2doc.js`'s
+      // `.ed-wave-side` media query: `data-open` is the SECTION's own
+      // toggle state and says nothing about whether the RAIL is currently
+      // showing it). Left alone, a narrow-viewport user who selects an edge
+      // gets no hint that the only surface to edit or delete it exists at
+      // all. So this expands the rail — but only on the TRANSITION into
+      // having a selection (`lastSelectedEdge === null`, checked against
+      // the PREVIOUS render, not "selectedEdge !== null" on its own):
+      // expanding on every repaint would fight a user who deliberately
+      // collapses the rail back (the fix-round-1 button) while still
+      // working on the same selected edge — the very next keystroke would
+      // pop it back open. Firing once, at the moment of selection, is the
+      // honest response without becoming a second one-way door.
+      //
+      // Lane/cycle selection does NOT get the same treatment, by deliberate
+      // choice, not oversight: unlike an edge, selecting a lane already has
+      // visible feedback OUTSIDE the side column — `renderLanes` highlights
+      // the row (`.is-selected`) and the canvas itself draws the cycle
+      // selection — so a narrow-viewport user who selects a lane is never
+      // left looking at nothing the way an edge-select would leave them.
+      if (selectedEdge !== null && lastSelectedEdge === null) {
+        panels.expandSide();
+      }
+      lastSelectedEdge = selectedEdge;
+      // v3.6.0 Task 13 fix round 4: re-checked on EVERY render while an
+      // edge is selected, not only on the transition that just (maybe)
+      // expanded the rail above — see `clearSelectedEdgeOfSide`'s own
+      // comment for the mechanism. Unlike `expandSide()`, this has no
+      // "only once" concern: it recomputes and resets from scratch each
+      // call, so it stays correct across switching directly from one
+      // selected edge to another, an unrelated repaint moving the SAME
+      // edge's own handle (a resize, an hscale change), or the rail
+      // collapsing back (where it correctly clears its own inline style).
+      clearSelectedEdgeOfSide();
+      panels.renderPreview(doc);
+      panels.renderMeta(doc);
+      panels.renderUnmodelled(doc, layout);
+      // v3.6.0 Task 13: the 原始碼 panel. Repainted every pass, like every
+      // other panel above — cheap (one `store.toPatch()`, already run once
+      // per gesture by `afterStoreMoved`) and it means the panel can never
+      // show a patch older than what is on screen.
+      panels.renderSource();
       undoBtn.disabled = !store.canUndo();
       redoBtn.disabled = !store.canRedo();
+      paintSelectionState(doc, layout);
       overlay.setAttribute('data-wave-gestures', String(gestures));
       overlay.setAttribute('data-wave-lanes', String(layout.lanes.length));
       overlay.setAttribute('data-wave-cycles', String(layout.cycles));
@@ -1025,6 +2523,16 @@
       restoreFocus(before);
     }
 
+    /** Whether `geometry.edgeLayout` would still draw the edge at `index` —
+     *  the same test the drawing itself applies, asked rather than repeated. */
+    function edgeIsDrawable(doc, layout, index) {
+      const edges = geometry.edgeLayout(doc, layout);
+      for (const e of edges) {
+        if (e.index === index) return true;
+      }
+      return false;
+    }
+
     /** What has the keyboard now, as something that survives a rebuild. */
     function focusMark() {
       const el = d.activeElement;
@@ -1046,6 +2554,16 @@
       const want = focusOverride !== null ? focusOverride : (mark === null ? null : mark.key);
       focusOverride = null;
       if (want === null) return;
+      // v3.6.0 Task 14: "did not come back" includes "came back DISABLED".
+      // `.focus()` on a disabled control is inert — the fact T6h pinned for
+      // the rail's ▲ at the top of the list — and the toolbar is now where
+      // the gestures that disable their own button live: 訊號's 刪除 empties
+      // the selection, so the very button the user pressed is disabled by
+      // the repaint that press caused. Found-but-inert fell straight through
+      // to `document.body`, which is the state this whole function exists to
+      // prevent, and which turns the next Backspace into「delete the
+      // selected blocks」.
+      const inert = function (node) { return node === null || node.disabled === true; };
       let el = overlay.querySelector('[data-focus-key="' + want + '"]');
       // A named destination the repaint did not bring back. It happens: a
       // group's key is its first lane's row number, so inserting a lane above
@@ -1054,10 +2572,10 @@
       // where the keyboard actually was, and failing that to the dialog
       // itself. Never to nothing: nothing is `document.body`, and this whole
       // task is about not ending there.
-      if (el === null && mark !== null && mark.key !== want) {
+      if (inert(el) && mark !== null && mark.key !== want) {
         el = overlay.querySelector('[data-focus-key="' + mark.key + '"]');
       }
-      if (el === null) {
+      if (inert(el)) {
         if (!overlay.contains(d.activeElement)) panel.focus();
         return;
       }
@@ -1070,689 +2588,185 @@
       } catch (e) { /* not a text field */ }
     }
 
-    function renderMeta(doc) {
-      const h = doc.head;
-      const f = doc.foot;
-      headInput.value = (h !== null && typeof h === 'object' && typeof h.text === 'string')
-        ? h.text : '';
-      footInput.value = (f !== null && typeof f === 'object' && typeof f.text === 'string')
-        ? f.text : '';
-    }
-
-    /**
-     * Say out loud which properties of this document the drawing is not
-     * showing.
-     *
-     * `config.hscale`, and a lane's `period` / `phase`, all change what the
-     * engine paints and none of them is modelled here (see the toolbar comment
-     * for the measurements). Drawing a confident picture that ignores them is
-     * the failure this whole overlay is arranged to avoid, so a document that
-     * carries any of them says so, names them, and points at the preview —
-     * which IS faithful, because it is the engine.
-     */
-    function renderUnmodelled(doc) {
-      const found = [];
-      const cfg = doc.config;
-      if (cfg !== null && typeof cfg === 'object' && cfg.hscale !== undefined) {
-        found.push('config.hscale');
-      }
-      for (const path of codec.lanePaths(doc)) {
-        const lane = valueAt(doc, path);
-        if (lane === null || typeof lane !== 'object') continue;
-        if (lane.period !== undefined && found.indexOf('period') === -1) found.push('period');
-        if (lane.phase !== undefined && found.indexOf('phase') === -1) found.push('phase');
-      }
-      overlay.setAttribute('data-wave-unmodelled', found.join(' '));
-      unmodelled.hidden = found.length === 0;
-      unmodelled.textContent = found.length === 0 ? '' :
-        '這份文件用了 ' + found.join('、') +
-        '，左邊的手繪波形不表現它們（寬度與相位會不一樣）——以右邊的 WaveDrom 預覽為準。';
-
-      // …and the bigger version of the same honesty. This editor edits
-      // `signal:` and nothing else, so a `reg:` or `assign:` block opens a
-      // canvas with no lanes on it: `lanePaths()` is empty, `addLane()` hands
-      // the document straight back, and pressing ＋ produced one status line
-      //「這個動作沒有改變任何東西」— true, and no explanation at all. An
-      // editor that looks broken is worse than one that says what it cannot
-      // do, and the notice above is the precedent: the drawing already tells
-      // the user which properties it is not showing them.
-      const kinds = [];
-      for (const key of ['reg', 'assign']) {
-        if (doc[key] !== undefined) kinds.push(key + ':');
-      }
-      const noLanes = codec.lanePaths(doc).length === 0;
-      overlay.setAttribute('data-wave-nolanes', noLanes ? '1' : '0');
-      noSignal.hidden = !noLanes;
-      noSignal.textContent = !noLanes ? '' :
-        (kinds.length === 0
-          ? '這個區塊裡沒有 signal:，所以沒有可以編輯的 lane。'
-          : '這個區塊用的是 ' + kinds.join(' / ') +
-            '，這個編輯器只編輯 signal: 的 lane。') +
-        '右邊的 WaveDrom 預覽仍然是引擎畫的原圖；要改這個區塊請用「⠿ → MD 原始碼」。';
-    }
-
     /**
-     * The lane list.
+     * The in-place editor for one bus cell's `data` label — this dialog's
+     * OTHER sub-panel, same `{cancel, retire}` shape as `renameGroup` just
+     * above and opened the same two ways every other gesture in this file
+     * is: a pointer press (`onCanvasDown`) or the keyboard's own Enter
+     * (`handleDrawingKey`), both of which have already asked
+     * `codec.dataSlotOf` before calling this, so `slot` below is never
+     * recomputed from a belief of its own about which cycles consume one.
      *
-     * Rows are `layout.laneHeight` tall and in `layout.lanes` order, so row k
-     * here and row k of the drawing are the same lane by construction rather
-     * than by a second traversal that could disagree.
-     */
-    function renderLanes(doc, layout) {
-      laneCol.textContent = '';
-      const rows = d.createElement('div');
-      rows.className = 'ed-wave-lane-rows';
-      rows.style.height = layout.height + 'px';
-      laneCol.appendChild(rows);
-
-      // Group titles first, so they sit UNDER the rows in paint order and a
-      // lane's own controls stay clickable over them.
-      for (const span of groupSpansOf(doc, layout)) {
-        const tag = d.createElement('button');
-        tag.type = 'button';
-        tag.className = 'ed-wave-group';
-        tag.setAttribute('data-focus-key', 'group-' + span.from);
-        tag.textContent = span.title;
-        tag.title = '群組「' + span.title + '」——點一下改名';
-        tag.setAttribute('data-group-from', String(span.from));
-        tag.setAttribute('data-group-to', String(span.to));
-        tag.style.top = (span.from * layout.laneHeight) + 'px';
-        tag.style.height = ((span.to - span.from + 1) * layout.laneHeight) + 'px';
-        tag.style.left = ((span.depth - 1) * 16) + 'px';
-        tag.addEventListener('click', function () { renameGroup(span); });
-        rows.appendChild(tag);
-      }
-
-      for (let i = 0; i < layout.lanes.length; i++) {
-        rows.appendChild(laneRow(doc, layout, i));
-      }
-      // The tail insert. `laneInsertPath(doc, laneCount)` goes on the end of
-      // `signal` itself, which is what makes the group asymmetry visible here
-      // rather than surprising afterwards.
-      rows.appendChild(insertButton(doc, layout.lanes.length, layout, true));
-    }
-
-    function laneRow(doc, layout, i) {
-      const row = d.createElement('div');
-      row.className = 'ed-wave-lane-row';
-      row.setAttribute('data-lane', String(i));
-      row.style.top = (i * layout.laneHeight) + 'px';
-      row.style.height = layout.laneHeight + 'px';
-      row.style.paddingLeft = (layout.lanes[i].depth * 16) + 'px';
-      if (selection !== null && selection.laneIndex === i) row.classList.add('is-selected');
-
-      row.appendChild(insertButton(doc, i, layout, false));
-
-      const name = d.createElement('input');
-      name.type = 'text';
-      name.className = 'ed-wave-lane-name';
-      name.setAttribute('data-focus-key', 'lane-name-' + i);
-      const lane = layout.lanes[i].lane;
-      name.value = typeof lane.name === 'string' ? lane.name : '';
-      name.addEventListener('change', function () {
-        commit('rename', function (doc2) { return codec.renameLane(doc2, i, name.value); });
-      });
-      row.appendChild(name);
-
-      const up = d.createElement('button');
-      up.type = 'button';
-      up.className = 'ed-wave-lane-up';
-      up.setAttribute('data-focus-key', 'lane-up-' + i);
-      up.textContent = '▲';
-      up.title = '往上移一格';
-      up.disabled = i === 0;
-      up.addEventListener('click', function () {
-        // The button this lane arrives at, EXCEPT at the top, where `lane-up-0`
-        // is disabled and `.focus()` on it is inert — measured, walking a lane
-        // to the top with three ▲ put the cursor on `lane-up-2`, `lane-up-1`
-        // and then BODY, which is the state F7 exists to prevent and the fourth
-        // press then did nothing at all. At the top the cursor goes to the one
-        // control on that row that is never disabled there: ▼.
-        focusOverride = i - 1 === 0 ? 'lane-down-0' : 'lane-up-' + (i - 1);
-        commit('move', function (doc2) { return codec.moveLane(doc2, i, i - 1); });
-      });
-      row.appendChild(up);
-
-      const down = d.createElement('button');
-      down.type = 'button';
-      down.className = 'ed-wave-lane-down';
-      down.setAttribute('data-focus-key', 'lane-down-' + i);
-      down.textContent = '▼';
-      down.title = '往下移一格';
-      down.disabled = i === layout.lanes.length - 1;
-      down.addEventListener('click', function () {
-        // Mirror of ▲ above: `lane-down-<last>` is disabled, so the bottom row
-        // hands the cursor to ▲ instead.
-        focusOverride = i + 1 === layout.lanes.length - 1
-          ? 'lane-up-' + (i + 1) : 'lane-down-' + (i + 1);
-        commit('move', function (doc2) { return codec.moveLane(doc2, i, i + 1); });
-      });
-      row.appendChild(down);
-
-      const del = d.createElement('button');
-      del.type = 'button';
-      del.className = 'ed-wave-lane-remove';
-      del.setAttribute('data-focus-key', 'lane-remove-' + i);
-      del.textContent = '✕';
-      del.title = '刪掉這條 lane（如果群組因此空掉，群組也會一起走）';
-      del.addEventListener('click', function () {
-        selection = null;
-        // The row this button belongs to is about to stop existing, so the
-        // keyboard goes to the ＋ that occupies that position instead — the
-        // one control at that spot that survives every removal, tail included.
-        focusOverride = 'lane-add-' + i;
-        commit('remove-lane', function (doc2) { return codec.removeLane(doc2, i); });
-      });
-      row.appendChild(del);
-      return row;
-    }
-
-    /**
-     * Where a lane inserted at display position `index` would actually land,
-     * asked of the bridge rather than guessed.
-     *
-     * This is constraint 4 made visible. `laneInsertPath` puts an insert at a
-     * group's FIRST lane inside that group, and an insert at the position just
-     * past its LAST lane outside it — a group can be joined at its head and
-     * never at its tail. That asymmetry is not something a label can argue
-     * away, so the label states it: the button says which container it will
-     * land in, before it is pressed, and the status line says it again after.
-     */
-    function landingOf(doc, index) {
-      const path = codec.laneInsertPath(doc, index);
-      if (path === null) return { path: null, title: null };
-      const container = path.slice(0, path.length - 1);
-      const held = valueAt(doc, container);
-      const title = Array.isArray(held) && typeof held[0] === 'string' ? held[0] : null;
-      return { path: path, title: title };
-    }
-
-    function insertButton(doc, index, layout, isTail) {
-      const b = d.createElement('button');
-      b.type = 'button';
-      b.className = isTail ? 'ed-wave-lane-add ed-wave-lane-add-tail' : 'ed-wave-lane-add';
-      b.textContent = '＋';
-      b.setAttribute('data-insert-at', String(index));
-      b.setAttribute('data-focus-key', 'lane-add-' + index);
-      const landing = landingOf(doc, index);
-      const where = landing.title === null ? '群組外' : '群組「' + landing.title + '」裡';
-      b.setAttribute('data-lands-in', landing.title === null ? '' : landing.title);
-      b.title = '在這裡加一條 lane —— 會落在' + where;
-      if (isTail) {
-        b.style.top = (layout.lanes.length * layout.laneHeight) + 'px';
-      }
-      b.addEventListener('click', function () {
-        // Straight into the new lane's name field: it is what the user is going
-        // to type next, and it is the only control the new row introduces.
-        focusOverride = 'lane-name-' + index;
-        const added = commit('add-lane', function (doc2) {
-          return codec.addLane(doc2, index, { name: '', wave: 'x' });
-        });
-        if (added) say('新增的 lane 落在' + where);
-      });
-      return b;
-    }
-
-    /**
-     * The rail's rename field: this dialog's one sub-panel.
-     *
-     * The field is INSERTED beside its tag and the tag is hidden, rather than
-     * the two being swapped, and taking it down again touches only those two
-     * nodes. That is not tidiness. Taking it down used to mean a full
-     * `render()` — a rebuild of the entire rail — and a rebuild that runs
-     * inside a `blur` handler destroys the element the user is in the middle
-     * of pressing. Measured before this: open the field, then press any rail
-     * button; the mousedown blurred the field, the rail was rebuilt, the
-     * mouseup landed on a fresh element so no `click` ever fired, the press
-     * did nothing at all, and the keyboard ended on `document.body` inside a
-     * modal with no visible cursor.
+     * Positioned with `geometry.cellRect` — the exact numbers the keyboard
+     * cursor and the pointer's own hit test already share — offset by
+     * `canvas.offsetLeft`/`offsetTop` rather than the wrap's own padding
+     * written out as a constant: the field is a plain sibling of the SVG
+     * inside `.ed-wave-canvas-wrap` (now `position: relative`, see
+     * `lib/md2doc.js`), so reading the SVG's OWN measured offset is what
+     * keeps the two from drifting apart if that padding ever changes.
+     *
+     * Unlike `renameGroup`'s field, this one's node sits beside a canvas
+     * `renderCanvas` rebuilds on every cursor move — see that function's own
+     * first line for why `retire()` has to be called from there too, not
+     * only from `render()`.
      */
-    function renameGroup(span) {
-      const rows = laneCol.querySelector('.ed-wave-lane-rows');
-      const tag = rows === null ? null
-        : rows.querySelector('.ed-wave-group[data-group-from="' + span.from + '"]');
-      if (tag === null) return;
+    function openDataEdit(laneIndex, cycle) {
+      if (canvas === null) return;
+      const layout = geometry.layoutOf(store.doc, SIZES);
+      const row = layout.lanes[laneIndex];
+      const lane = row === undefined ? null : row.lane;
+      const slot = lane === null ? null : codec.dataSlotOf(lane, cycle);
+      if (slot === null) return;
+      const box = geometry.cellRect(layout, laneIndex, cycle);
+      if (box === null) return;
+      // A press or an Enter that lands on a second bus cell while the field
+      // is still open on the first one: the open field never got the blur
+      // that a plain click elsewhere would have given it (the keyboard's
+      // Enter path never moves focus at all), so it is cancelled here,
+      // by hand, before this one opens. Unsaved text in the first field is
+      // discarded — the same trade `renameGroup` makes for its own field on
+      // every route that is not `finish()` itself.
+      if (dataEdit !== null) dataEdit.cancel();
+
+      const current = labelsOf(lane)[slot];
+      const startValue = typeof current === 'string' ? current : '';
 
       const input = d.createElement('input');
       input.type = 'text';
-      input.className = 'ed-wave-group-input';
-      input.setAttribute('data-focus-key', 'group-input-' + span.from);
-      input.value = span.title;
-      input.style.top = tag.style.top;
-      input.style.left = tag.style.left;
-
-      /** The field off, the tag back — and nothing else in the rail touched.
-       *  A no-op for both once a repaint has taken them away. */
+      input.className = 'ed-wave-data-input';
+      input.setAttribute('data-focus-key', 'data-input-' + laneIndex + '-' + cycle);
+      input.value = startValue;
+      input.style.left = (canvas.offsetLeft + box.x) + 'px';
+      input.style.top = (canvas.offsetTop + box.y) + 'px';
+      input.style.width = box.width + 'px';
+      input.style.height = box.height + 'px';
+
+      /** The field off. A no-op once a repaint has already taken it away. */
       const takeDown = function () {
         if (input.parentNode !== null) input.parentNode.removeChild(input);
-        if (d.contains(tag)) tag.hidden = false;
       };
-      /** The tag this field was covering, or — when a repaint has replaced it
-       *  and moved it (a group's `from` is its first lane's row, so an insert
-       *  above it renumbers the key) — whatever now carries that key, and
-       *  failing that the dialog itself. Never nothing: nothing is
-       *  `document.body`. */
-      const focusTag = function () {
-        const live = d.contains(tag) ? tag
-          : overlay.querySelector('[data-focus-key="group-' + span.from + '"]');
-        if (live !== null) live.focus();
-        else panel.focus();
-      };
-      /** Whether the keyboard is IN the field right now. False on the `blur`
-       *  path — the browser has already moved it by then — which is how the
-       *  two are told apart without asking which device did anything. */
+      /** Whether the keyboard is IN the field right now. False on the
+       *  `blur` path — the browser has already moved it by then. */
       const holdsKeyboard = function () { return d.activeElement === input; };
 
       const finish = function () {
-        // Once. `change` and `blur` both fire for a field committed with Enter,
-        // and every teardown below is a blur too. Whoever gets here first owns
-        // the gesture; the latch is also how the other two say "not you".
-        if (groupRename === null) return;
-        groupRename = null;
+        // Once. `blur` and this file's own explicit Enter handler can both
+        // reach here for the one commit (Enter removes the field, which
+        // fires a `blur` of its own) — the latch is the same "whoever gets
+        // here first owns the gesture" rule `renameGroup.finish` uses.
+        if (dataEdit === null) return;
+        dataEdit = null;
         const hadKeyboard = holdsKeyboard();
         const value = input.value;
         takeDown();
-        if (value === span.title) {
-          // Nothing to write, so nothing to repaint — the tag is already back.
-          // The keyboard is only moved when it was in the field: on the mouse
-          // path the browser is already carrying it to the control that was
-          // pressed, and that control is still there to receive it now that
-          // this path no longer rebuilds the rail.
-          if (hadKeyboard) focusTag();
+        if (value === startValue) {
+          // Nothing to write, so nothing to repaint — `canvas` is already
+          // the element it was before this field opened.
+          if (hadKeyboard) canvas.focus();
           return;
         }
-        // A real commit, so a real repaint — and the keyboard has to be named
-        // if it would otherwise be lost. `focusOverride` is left alone when a
-        // caller has already made a more specific promise.
-        if (focusOverride === null &&
-            (hadKeyboard || !overlay.contains(d.activeElement))) {
-          focusOverride = 'group-' + span.from;
+        // The keyboard is only NAMED when it would otherwise be lost — same
+        // condition `renameGroup.finish` uses: either this field had it, or
+        // whatever DOES have it right now is not even inside the overlay
+        // (both mean the coming repaint would otherwise leave it on
+        // `document.body`). `focusOverride` already set by someone else's
+        // more specific promise is left alone.
+        if (focusOverride === null && (hadKeyboard || !overlay.contains(d.activeElement))) {
+          focusOverride = 'canvas';
         }
-        commit('rename-group', function (doc2) {
-          return replaceAt(doc2, span.path.concat([0]), value);
+        commit('data-label', function (doc) {
+          return codec.setDataAt(doc, laneIndex, slot, value);
         });
       };
-      // The rail is about to be rebuilt underneath this field by somebody
-      // else's repaint — an undo, a redo, any gesture that reaches `render()`
-      // while it is open. Both nodes go with that rebuild, so there is nothing
-      // to take down; what matters is dropping the latch and naming where the
-      // keyboard lands, because `group-input-<n>` will not exist afterwards and
-      // focus would be left on a node that is no longer in the document — which
-      // is the wedge that lost every subsequent keystroke.
+      /** The canvas is about to be rebuilt underneath this field by
+       *  `renderCanvas` — an undo, a redo, any gesture that repaints while
+       *  it is open. The node goes with that rebuild; what matters is
+       *  dropping the latch and naming where the keyboard lands, exactly
+       *  the same reason `renameGroup.retire` exists. */
       const retire = function () {
-        if (groupRename === null) return;
-        groupRename = null;
-        if (focusOverride === null && holdsKeyboard()) {
-          focusOverride = 'group-' + span.from;
-        }
+        if (dataEdit === null) return;
+        dataEdit = null;
+        if (focusOverride === null && holdsKeyboard()) focusOverride = 'canvas';
       };
-      // Escape's half of the layering: the field goes, the name does not
-      // change, the session stands, and the keyboard goes back to the tag the
-      // field was covering — never to `document.body`, which is the state the
-      // whole of this task exists to make unreachable. No repaint at all: the
-      // tag was never destroyed.
+      /** Escape's half: the field goes, the label does not change, the
+       *  session stands, and the keyboard goes back to the drawing — never
+       *  to `document.body`. No repaint: the canvas was never touched. */
       const cancel = function () {
-        if (groupRename === null) return;
-        groupRename = null;
+        if (dataEdit === null) return;
+        dataEdit = null;
         takeDown();
-        focusTag();
+        canvas.focus();
       };
-
+      // The explicit commit key: Enter. Left to a plain native `change`
+      // event the way `renameGroup`'s field is would depend on whether this
+      // browser fires `change` for a lone text input on Enter alone, which
+      // is not a promise this file makes elsewhere — asked for outright
+      // instead, the same way Escape is asked for explicitly one level up
+      // in `onKeyDown` rather than left to a default.
+      input.addEventListener('keydown', function (ev) {
+        if (ev.key !== 'Enter') return;
+        ev.preventDefault();
+        ev.stopPropagation();
+        finish();
+      });
       input.addEventListener('change', finish);
       input.addEventListener('blur', finish);
-      tag.hidden = true;
-      rows.insertBefore(input, tag);
-      // Three facts, and only the three that are read: that a rename is
-      // standing (this being non-null), how to take it down on purpose, and how
-      // to let go of it when a repaint takes it down for us. A copy of the span
-      // or of the field itself would be a second record of something the
-      // closure above already holds.
-      groupRename = { cancel: cancel, retire: retire };
+      canvasWrap.appendChild(input);
+      dataEdit = { cancel: cancel, retire: retire };
       input.focus();
       input.select();
     }
 
     /**
-     * A copy of `doc` with one scalar replaced, for the two fields the codec's
-     * lane operations do not cover (a group's own title).
-     *
-     * Structure-sharing everywhere it does not have to copy, so the store's
-     * lane-identity bookkeeping still sees every untouched lane as the same
-     * object — `remapOrigins` answers a content edit by position and a
-     * structural one by identity, and a wholesale clone here would make an
-     * ordinary rename look like a structural change.
+     * Where a press or an Enter on cycle `cycle` of `lane` should open the
+     * data-label field — or whether it must refuse the gesture outright
+     * instead of letting it fall through to an ordinary paint.
+     *
+     * v3.5.0 Task 11 fix round 1: a cycle INSIDE a bus run that itself owns
+     * no slot (`codec.dataSlotOf` answers `null` — a `.` continuation or a
+     * `|` gap) used to fall straight through to the paint-arming code with
+     * nothing catching it. Reviewer-traced: the press silently repainted
+     * that continuation with whatever brush was current, turning it into a
+     * fresh EXPLICIT value cycle and shifting every LATER label in the lane
+     * one slot to the right — silent data corruption, not an inert click,
+     * because the box this cycle sits inside is exactly what this task now
+     * invites the user to press.
+     *
+     * `isBus(brickOf(...))` is the same test `drawLane` uses to decide
+     * whether a cycle is a bus box at all for the PICTURE, asked here to
+     * decide it for the GESTURE — so a plain non-bus cycle (`0`, `1`, `x`, a
+     * clock, …) is untouched and keeps painting exactly as it always has;
+     * only a cycle INSIDE a bus box is ever diverted. Walking backward for
+     * the owning cycle stops the moment the resolved LEVEL changes — two
+     * adjacent bus runs of the identical value (`2.2.` — measured against
+     * `codec`'s own doc comment: two separate labels, not one) must not
+     * have a later cycle resolve into the EARLIER run's slot.
+     *
+     * Returns:
+     *   `{cycle, slot}` — open the field for THIS cycle's slot: either
+     *                      `cycle` itself owns one, or the walk back to its
+     *                      run's owning explicit cycle found one.
+     *   `'blocked'`      — inside a bus box, but no owning cycle exists (a
+     *                       leading repeater with nothing to continue —
+     *                       MEASURED, `levelsOf` draws such a lane as `x`,
+     *                       so this should be unreachable in practice, but
+     *                       the check is kept rather than assumed so a
+     *                       future change to that rule fails LOUD here
+     *                       rather than silently reaching paint again).
+     *                       Callers must refuse the gesture on this answer,
+     *                       never fall through.
+     *   `null`           — not a bus box; ordinary behaviour is unaffected.
      */
-    function replaceAt(node, path, value) {
-      if (path.length === 0) return value;
-      const seg = path[0];
-      const child = replaceAt(node[seg], path.slice(1), value);
-      if (Array.isArray(node)) {
-        const out = node.slice();
-        out[seg] = child;
-        return out;
-      }
-      const out = Object.assign({}, node);
-      out[seg] = child;
-      return out;
-    }
-
-    /**
-     * The hand-drawn waveform.
-     *
-     * Every cycle's picture comes from `codec.levelsOf` through `brickOf`, and
-     * from nowhere else — constraint 3. The levels and the bricks are both
-     * published on the element (`data-levels-N`, `data-bricks-N`) so the
-     * agreement with the preview beside it is something a test can measure
-     * rather than something this comment can promise: the preview's own SVG
-     * names its bricks in its `<use xlink:href="#…">` list.
-     */
-    function renderCanvas(doc, layout) {
-      // Every repaint REPLACES the canvas element, so a canvas that had the
-      // keyboard loses it to `document.body` the instant it is detached —
-      // exactly the state F7 and T6h exist to prevent, and here it would fire
-      // on every arrow key. `render()`'s own `data-focus-key` restore covers
-      // the full-repaint path; this covers the three that call renderCanvas
-      // directly (a drag's two, and the keyboard's own), so the property holds
-      // for the canvas no matter which road the repaint came down.
-      const hadFocus = canvas !== null && d.activeElement === canvas;
-      // The cursor is an index pair, and the document under it can get shorter:
-      // deleting cycles or removing the bottom lane leaves it pointing past the
-      // end. Clamped HERE, where the layout that decides what "past the end"
-      // means is already in hand — so nothing downstream ever has to ask.
-      if (cursor !== null) {
-        if (layout.lanes.length === 0 || layout.cycles === 0) {
-          cursor = null;
-        } else {
-          cursor = {
-            laneIndex: Math.max(0, Math.min(cursor.laneIndex, layout.lanes.length - 1)),
-            cycle: Math.max(0, Math.min(cursor.cycle, layout.cycles - 1)),
-          };
-        }
-      }
-      // …and `selection` with it, which is the other half of the same fact and
-      // was left out of the first cut. Measured before this: Shift-select four
-      // cycles, press 刪除 cycle, and a one-cycle document was left with the
-      // cursor on cycle 1, no visible box, 複製 reporting「複製了 4 個 cycle」
-      // and 貼上（插入）growing the document back to five. The toolbar was
-      // acting on a range the drawing no longer had anywhere to put.
-      //
-      // The two axes are not treated alike, and that is the point: a CYCLE
-      // range that overshoots is the same range in a shorter document, so it
-      // clamps; a LANE that is gone is not a lane the user can have meant, so
-      // the selection goes rather than silently moving to whichever lane
-      // inherited the index. (`lane ✕` already nulls it on its own path; this
-      // catches the undo/redo of that.)
-      //
-      // It does NOT catch every route, and the earlier wording here said it
-      // did. MEASURED: `＋` at 0, drag-select cycles 1-3 on the new lane 0,
-      // then Ctrl+Z — the selection box and the rail highlight both stay on
-      // row 0, which is now `clk`. The trace-derived marks above fix the
-      // CURSOR for that case; the selection is still carried by row number,
-      // so it lands on whoever inherited the row. The cost is confined to the
-      // highlight and to where the next Shift+arrow anchors, because every
-      // cycle operation is document-wide — but it is a real gap, not a
-      // covered one.
-      if (selection !== null) {
-        if (layout.lanes.length === 0 || layout.cycles === 0 ||
-            selection.laneIndex < 0 || selection.laneIndex >= layout.lanes.length) {
-          selection = null;
-        } else {
-          selection = {
-            laneIndex: selection.laneIndex,
-            from: Math.max(0, Math.min(selection.from, layout.cycles - 1)),
-            to: Math.max(0, Math.min(selection.to, layout.cycles - 1)),
-          };
-        }
-      }
-      canvasWrap.textContent = '';
-      canvas = d.createElementNS(SVGNS, 'svg');
-      canvas.setAttribute('class', 'ed-wave-canvas');
-      // In the Tab cycle, and therefore in the focus trap, like every other
-      // control in here: the drawing is this dialog's main surface and was the
-      // one thing in it a keyboard could not reach.
-      canvas.setAttribute('tabindex', '0');
-      canvas.setAttribute('data-focus-key', 'canvas');
-      canvas.setAttribute('aria-label',
-        '波形繪圖區：方向鍵移動游標，Shift+左右鍵選一段 cycle，' +
-        '按電位字元（' + BRUSHES.join(' ') + '）塗上去');
-      const width = Math.max(layout.width, SIZES.cycleWidth);
-      canvas.setAttribute('width', String(width));
-      canvas.setAttribute('height', String(Math.max(layout.height, layout.laneHeight)));
-      canvas.setAttribute('viewBox', '0 0 ' + width + ' ' +
-        Math.max(layout.height, layout.laneHeight));
-      canvas.setAttribute('data-lane-count', String(layout.lanes.length));
-      canvas.setAttribute('data-cycle-count', String(layout.cycles));
-
-      // cycle grid
-      for (let c = 0; c <= layout.cycles; c++) {
-        const g = d.createElementNS(SVGNS, 'line');
-        g.setAttribute('class', 'ed-wave-grid');
-        g.setAttribute('x1', String(c * layout.cycleWidth));
-        g.setAttribute('x2', String(c * layout.cycleWidth));
-        g.setAttribute('y1', '0');
-        g.setAttribute('y2', String(layout.height));
-        canvas.appendChild(g);
-      }
-
-      for (let i = 0; i < layout.lanes.length; i++) {
-        drawLane(canvas, layout, i);
-      }
-
-      if (selection !== null) {
-        const from = Math.min(selection.from, selection.to);
-        const to = Math.max(selection.from, selection.to);
-        const box = d.createElementNS(SVGNS, 'rect');
-        box.setAttribute('class', 'ed-wave-selection');
-        box.setAttribute('x', String(from * layout.cycleWidth));
-        box.setAttribute('y', String(selection.laneIndex * layout.laneHeight));
-        box.setAttribute('width', String((to - from + 1) * layout.cycleWidth));
-        box.setAttribute('height', String(layout.laneHeight));
-        canvas.appendChild(box);
-      }
-
-      // The keyboard's cell, drawn last so it is over the selection tint and
-      // over the trace. Its geometry comes from `wave-geometry.cellRect` — the
-      // inverse of the hit test the pointer uses — so the cell the cursor is
-      // DRAWN on and the cell an edit lands in cannot drift apart.
-      let cursorCell = '';
-      if (cursor !== null) {
-        const cell = geometry.cellRect(layout, cursor.laneIndex, cursor.cycle);
-        if (cell !== null) {
-          cursorCell = cursor.laneIndex + ',' + cursor.cycle;
-          const cur = d.createElementNS(SVGNS, 'rect');
-          cur.setAttribute('class', 'ed-wave-cursor');
-          cur.setAttribute('data-ed-wave-cursor', '');
-          cur.setAttribute('data-cell', cursorCell);
-          cur.setAttribute('x', String(cell.x));
-          cur.setAttribute('y', String(cell.y));
-          cur.setAttribute('width', String(cell.width));
-          cur.setAttribute('height', String(cell.height));
-          canvas.appendChild(cur);
-        }
-      }
-      // The same value on the overlay: what a scenario reads when the rect is
-      // not the thing under test. It is assigned INSIDE the branch that draws
-      // the rect and defaults to empty, so "there is no rect" and "the overlay
-      // says none" are one decision rather than two that happen to agree —
-      // they did not, in the first cut: this line read `cursor` directly, so a
-      // cursor the clamp had not caught published a cell that `cellRect`
-      // refused to give a rectangle to, and a build with the clamp removed
-      // reported `{cell: null, published: "5,4"}`.
-      overlay.setAttribute('data-wave-cursor', cursorCell);
-
-      canvas.addEventListener('mousedown', onCanvasDown);
-      // Tabbing onto the drawing is an entry like any other, so it puts the
-      // cursor on screen rather than leaving a focused surface with no visible
-      // cursor in it. Re-entrant only once: `enterDrawing()` repaints, the
-      // repaint re-focuses the new canvas and fires this again, and by then
-      // `cursor` is set.
-      canvas.addEventListener('focus', function () {
-        if (cursor === null) enterDrawing();
-      });
-      canvasWrap.appendChild(canvas);
-      if (hadFocus) canvas.focus();
-    }
-
-    function drawLane(svg, layout, i) {
-      const row = layout.lanes[i];
-      const lane = row.lane;
-      // An ABSENT `wave` and an EMPTY one are two different pictures, and
-      // collapsing them into one was the regression the previous round shipped
-      // on the very axis it was fixing. MEASURED against the pinned engine,
-      // second half-brick per cycle:
-      //
-      //     {name:'a', wave:''}   ["xxx","xxx"]   ONE x cycle
-      //     {name:'a'}            []              NOTHING
-      //     {}       (spacer)     []              NOTHING
-      //     {name:'a', wave:1234} []              NOTHING
-      //     {name:'a', wave:null} []              NOTHING
-      //
-      // and in a mixed diagram the engine simply emits no bricks for that row:
-      // `{signal:[{a,'0101'},{},{b,'1010'}]}` is 16 uses, i.e. 2 lanes × 4 × 2.
-      // So the rule is exactly "a lane draws cycles only when `wave` is a
-      // string"; `''` is a string, which is why it gets its one cycle, and
-      // `{}` — the canonical WaveDrom blank-row spacer — gets none.
-      //
-      // The empty-string case is not a corner either: `deleteCycles` covering
-      // every cycle sets every lane's wave to `''`, two clicks away.
-      const hasWave = typeof lane.wave === 'string';
-      const wave = hasWave ? lane.wave : '';
-      const cells = hasWave ? codec.expandWave(wave) : [];
-      const levels = !hasWave ? [] : (wave === '' ? ['x'] : codec.levelsOf(cells));
-      const bricks = levels.map(brickOf);
-      // Which cycles carry the engine's discontinuity marker. `levelsOf`
-      // deliberately erases `|` — it answers what a cycle SHOWS, and a gap
-      // shows whatever is in front of it — so the marker has to be read off the
-      // cells. Measured: `01|10` renders one `<use xlink:href="#gap">` at
-      // translate(100), which is the centre of cycle 2, the `|` cycle.
-      const gaps = [];
-      for (let c = 0; c < cells.length; c++) {
-        if (cells[c].held !== true && cells[c].ch === '|') gaps.push(c);
-      }
-      // `data-wave-<i>` cannot carry the difference between "no `wave` key" and
-      // `wave: ''` — both are the empty string — and that difference is exactly
-      // what the engine draws differently, so it gets its own attribute.
-      svg.setAttribute('data-haswave-' + i, hasWave ? '1' : '0');
-      svg.setAttribute('data-wave-' + i, wave);
-      svg.setAttribute('data-levels-' + i, levels.join(''));
-      svg.setAttribute('data-bricks-' + i, bricks.join(' '));
-      svg.setAttribute('data-gaps-' + i, gaps.join(' '));
-
-      const hi = row.y + 7;
-      const lo = row.y + row.height - 9;
-      const mid = (hi + lo) / 2;
-      const cw = layout.cycleWidth;
-      const labels = labelsOf(lane);
-      // Which cycles carry a `data` label: the explicit value cycles, in order.
-      // `levelsOf` repeats a bus's level through its continuation cycles, so the
-      // label belongs to the cycle that STARTS the run, which is what the run
-      // grouping below already knows.
-      let labelSlot = 0;
-
-      // Runs of one picture. Clock bricks never merge — each `p` cycle is a
-      // whole clock period, and a merged run would draw one long one.
-      const runs = [];
-      for (let c = 0; c < bricks.length; c++) {
-        const last = runs.length === 0 ? null : runs[runs.length - 1];
-        if (last !== null && last.brick === bricks[c] && !isClock(bricks[c])) last.to = c;
-        else runs.push({ brick: bricks[c], from: c, to: c });
-      }
-
-      function bandOf(brick) {
-        if (brick === '111' || brick === 'uuu') return [hi, hi];
-        if (brick === '000' || brick === 'ddd') return [lo, lo];
-        if (brick === 'zzz') return [mid, mid];
-        return [hi, lo];
-      }
-
-      for (let r = 0; r < runs.length; r++) {
-        const run = runs[r];
-        const x0 = run.from * cw;
-        const x1 = (run.to + 1) * cw;
-        const brick = run.brick;
-        if (isBus(brick)) {
-          const poly = d.createElementNS(SVGNS, 'polygon');
-          const s = Math.min(6, cw / 4);
-          poly.setAttribute('class', 'ed-wave-bus ed-wave-bus-' + brick.slice(4));
-          poly.setAttribute('points',
-            (x0 + s) + ',' + hi + ' ' + (x1 - s) + ',' + hi + ' ' +
-            x1 + ',' + mid + ' ' + (x1 - s) + ',' + lo + ' ' +
-            (x0 + s) + ',' + lo + ' ' + x0 + ',' + mid);
-          svg.appendChild(poly);
-          const text = labels[labelSlot];
-          if (typeof text === 'string' && text !== '') {
-            const t = d.createElementNS(SVGNS, 'text');
-            t.setAttribute('class', 'ed-wave-buslabel');
-            t.setAttribute('x', String((x0 + x1) / 2));
-            t.setAttribute('y', String(mid + 4));
-            t.setAttribute('text-anchor', 'middle');
-            t.textContent = text;
-            svg.appendChild(t);
-          }
-          labelSlot++;
-        } else if (brick === 'xxx') {
-          const rect = d.createElementNS(SVGNS, 'rect');
-          rect.setAttribute('class', 'ed-wave-x');
-          rect.setAttribute('x', String(x0));
-          rect.setAttribute('y', String(hi));
-          rect.setAttribute('width', String(x1 - x0));
-          rect.setAttribute('height', String(lo - hi));
-          svg.appendChild(rect);
-        } else if (isClock(brick)) {
-          const xm = (x0 + x1) / 2;
-          const p = d.createElementNS(SVGNS, 'path');
-          p.setAttribute('class', 'ed-wave-line ed-wave-clock');
-          p.setAttribute('d', brick === 'nclk'
-            ? 'M' + x0 + ',' + lo + ' L' + x0 + ',' + hi + ' L' + xm + ',' + hi +
-              ' L' + xm + ',' + lo + ' L' + x1 + ',' + lo
-            : 'M' + x0 + ',' + hi + ' L' + x0 + ',' + lo + ' L' + xm + ',' + lo +
-              ' L' + xm + ',' + hi + ' L' + x1 + ',' + hi);
-          svg.appendChild(p);
-        } else {
-          const y = bandOf(brick)[0];
-          const line = d.createElementNS(SVGNS, 'line');
-          line.setAttribute('class', brick === 'uuu' || brick === 'ddd'
-            ? 'ed-wave-line ed-wave-weak' : 'ed-wave-line');
-          line.setAttribute('x1', String(x0));
-          line.setAttribute('x2', String(x1));
-          line.setAttribute('y1', String(y));
-          line.setAttribute('y2', String(y));
-          svg.appendChild(line);
-        }
-
-        // The edge into this run. Clock bricks draw their own.
-        if (r > 0 && !isClock(brick) && !isClock(runs[r - 1].brick)) {
-          const a = bandOf(runs[r - 1].brick);
-          const b = bandOf(brick);
-          const top = Math.min(a[0], a[1], b[0], b[1]);
-          const bot = Math.max(a[0], a[1], b[0], b[1]);
-          if (bot > top) {
-            const edge = d.createElementNS(SVGNS, 'line');
-            edge.setAttribute('class', 'ed-wave-edge');
-            edge.setAttribute('x1', String(x0));
-            edge.setAttribute('x2', String(x0));
-            edge.setAttribute('y1', String(top));
-            edge.setAttribute('y2', String(bot));
-            svg.appendChild(edge);
-          }
-        }
-      }
-
-      // The gap marker, last so it sits over the trace it interrupts. The
-      // engine draws one per `|`; drawing none made the two pictures disagree
-      // on a lane whose levels agreed exactly, which is the quietest form of
-      // the disagreement this overlay exists to surface.
-      for (const c of gaps) {
-        const xm = (c + 0.5) * cw;
-        const mark = d.createElementNS(SVGNS, 'path');
-        mark.setAttribute('class', 'ed-wave-gap');
-        mark.setAttribute('d',
-          'M' + (xm - 5) + ',' + (lo + 3) + ' L' + (xm + 1) + ',' + (mid) +
-          ' L' + (xm - 5) + ',' + (hi - 3) +
-          ' M' + (xm - 1) + ',' + (lo + 3) + ' L' + (xm + 5) + ',' + (mid) +
-          ' L' + (xm - 1) + ',' + (hi - 3));
-        svg.appendChild(mark);
+    function resolveBusTarget(lane, cycle) {
+      const slot = codec.dataSlotOf(lane, cycle);
+      if (slot !== null) return { cycle: cycle, slot: slot };
+      const levels = codec.levelsOf(typeof lane.wave === 'string' ? lane.wave : '');
+      if (!drawer.isBus(drawer.brickOf(levels[cycle]))) return null;
+      for (let i = cycle - 1; i >= 0 && levels[i] === levels[cycle]; i--) {
+        const s = codec.dataSlotOf(lane, i);
+        if (s !== null) return { cycle: i, slot: s };
       }
+      return 'blocked';
     }
 
     // ── the keyboard on the drawing ───────────────────────────────────────
@@ -1776,6 +2790,17 @@
      * brush is on. Everything else the dialog can do is a real `<button>` or
      * `<input>` that Tab already reaches.
      *
+     * That sentence has NO exceptions and no mode-dependence, which is a
+     * property v3.6.0 Task 16 briefly broke and fix round 3 restored. Round 0
+     * bound the transition jump over plain ←/→ while the 關聯線 gesture was
+     * armed, so the keymap above became false for two keys at a state this
+     * function itself decides — and, worse than the documentation problem,
+     * several cells stopped being reachable from the keyboard at all (T9b).
+     * Round 3 moved that jump to Alt+←/→, which cannot arrive here: the call
+     * site is gated on `!ev.altKey`. So every Alt chord this dialog has —
+     * Alt+↑/↓ for the lane, Alt+←/→ for the jump — is claimed one level up in
+     * `onKeyDown` and is deliberately NOT part of this keymap.
+     *
      * Two targets are accepted, and only two:
      *   the canvas  — the surface itself, `tabindex="0"`, so it is in the Tab
      *                 cycle and in the focus trap like every other control.
@@ -1801,20 +2826,97 @@
         enterDrawing();
         return true;
       }
+      // v3.6.0 Task 16 fix round 3: THE ARROWS ARE PER-CELL IN EVERY STATE,
+      // and the transition jump no longer lives here.
+      //
+      // Round 0 bound the jump over plain ← / → while armed. A jump can only
+      // ever land on a transition, so that removed the keyboard's only
+      // cell-precise positioning on the one surface that needs it: on
+      // `p....` (transitions `[0]`) cell 1 became unreachable, and on
+      // `0.1.0` (`[0,2,4]`) cells 1 and 3 did. Home/End do not rescue it —
+      // they reach the two ends and nothing in between. T9b in
+      // `test/editor-journey.test.js` is the invariant that caught it: the
+      // keyboard's Enter/Enter route must write a BYTE-IDENTICAL source to
+      // the mouse drag, and the mouse aims at exactly those cells. MEASURED
+      // with the jump bound here — mouse `node: '.a'` / `node: '...b'`
+      // against keyboard `node: 'a'` / `node: '....b'`: different cells,
+      // different file, invariant gone.
+      //
+      // The jump is a convenience; per-cell movement is the primitive
+      // underneath it, and a convenience may not be bound over a primitive
+      // when that leaves no way back to it. So the jump moved to Alt+←/→,
+      // claimed in `onKeyDown` beside Alt+↑/↓ — see that branch for why that
+      // is the only home available to it (this function cannot be reached
+      // with Alt held) and for what Alt means across the four arrows.
       if (nav) {
         ev.preventDefault();
         ev.stopPropagation();
         moveCursor(key, ev.shiftKey === true);
         return true;
       }
+      // v3.5.0 Task 7: the keyboard's two-step version of the drag, ahead of
+      // the plain Enter-paints case below so an armed Enter never falls
+      // through to it. First Enter marks `cursor` as `pendingFrom` (arrows
+      // above already moved it, exactly as a mouse press would have);
+      // second Enter — from wherever the cursor walked to since — is the
+      // SAME `finishEdgeDrag` the mouse's `onCanvasUp` calls, so the three
+      // no-op drops and the one-armed-if-nothing-happened rule are decided
+      // in that one place, not re-decided here.
+      if (edgeMode === 'armed' && key === 'Enter' && cursor !== null) {
+        ev.preventDefault();
+        ev.stopPropagation();
+        if (pendingFrom === null) {
+          pendingFrom = { at: cursor.laneIndex, cell: cursor.cycle };
+          panels.say('起點已標記，移到終點再按一次 Enter');
+          render();
+        } else {
+          finishEdgeDrag(cursor.laneIndex, cursor.cycle);
+        }
+        return true;
+      }
+      // v3.5.0 Task 11: Enter on a cell inside a bus box opens that box's
+      // label field instead of painting over it with the brush — the
+      // keyboard's own version of the pointer's click below in
+      // `onCanvasDown`. `resolveBusTarget` is the SAME resolution
+      // `onCanvasDown` uses (fix round 1: a cursor resting on a `.`/`|`
+      // continuation inside a run used to fall straight through to
+      // `paintAtCursor()` below with nothing catching it — the identical
+      // silent-corruption hazard the pointer path had, closed the same way
+      // here rather than only on the mouse), so the two input devices can
+      // never disagree about which cells are labellable or where a press
+      // on a continuation actually lands. Placed AFTER the armed-edge Enter
+      // above (arming an edge outranks opening a label field — the same
+      // press cannot mean both) and BEFORE the generic Enter-paints case
+      // below, which it must pre-empt.
+      if (key === 'Enter' && cursor !== null) {
+        const dlLayout = geometry.layoutOf(store.doc, SIZES);
+        const dlRow = dlLayout.lanes[cursor.laneIndex];
+        const dlLane = dlRow === undefined ? null : dlRow.lane;
+        if (dlLane !== null) {
+          const dlTarget = resolveBusTarget(dlLane, cursor.cycle);
+          if (dlTarget === 'blocked') {
+            ev.preventDefault();
+            ev.stopPropagation();
+            panels.say('這一格接在某個 bus 值後面，但看不出屬於哪一個，沒有欄位可以編輯。');
+            return true;
+          }
+          if (dlTarget !== null) {
+            ev.preventDefault();
+            ev.stopPropagation();
+            cursor = { laneIndex: cursor.laneIndex, cycle: dlTarget.cycle };
+            openDataEdit(cursor.laneIndex, dlTarget.cycle);
+            return true;
+          }
+        }
+      }
       // A brush character both PICKS the brush and paints with it. Picking
       // without painting would need a second keystroke to do the thing the
       // user already said, and the toolbar's own brush buttons are still there
-      // for「選起來待會再用」. `ev.shiftKey` is excluded so a shifted key can
-      // never paint: with Shift the browser reports `H`, not `h`, and a brush
-      // table that quietly lower-cased it would make Shift+arrow's neighbour
-      // keys destructive.
-      if (!ev.shiftKey && BRUSHES.indexOf(key) !== -1) {
+      // for「選起來待會再用」. `isBrushKey` is the admission rule — see its
+      // own comment (this file's top) for why it is not keyed on
+      // `ev.shiftKey` (v3.5.0 Task 10 fix round 1: that used to block
+      // `P`/`N`/`|`, all typed with Shift, from the keyboard entirely).
+      if (isBrushKey(key)) {
         ev.preventDefault();
         ev.stopPropagation();
         brush = key;
@@ -1859,9 +2961,16 @@
      * ONE lane, a run of cycles — is exactly what a cursor plus Shift can
      * describe. A pointer press already collapses it to the pressed cell; a
      * plain arrow does the same, and Shift+←/→ keeps the anchor it was made
-     * with. Shift+↑/↓ collapses: a selection that spanned two lanes is not a
-     * thing this document model has, so pretending with a highlight would be
-     * the drawing telling the user something the codec cannot honour.
+     * with. Shift+↑/↓ collapses the CYCLE range onto the lane it lands on.
+     *
+     * v3.6.0 Task 14 narrowed what that sentence claims. It used to say a
+     * two-lane selection was not a thing this document model had; that is
+     * no longer true — `selection.laneIndex`..`laneTo` is a lane range, and
+     * 建立群組 / 訊號's 刪除 act on it. What is still true is that the
+     * cycle range belongs to ONE lane (`laneIndex`), so an arrow key that
+     * changes lanes has no cycle anchor left to extend from. Widening the
+     * LANE range from the keyboard is a gesture this dialog does not have
+     * yet; the rail's Shift+click is the one that makes it.
      */
     function moveCursor(key, extend) {
       const layout = geometry.layoutOf(store.doc, SIZES);
@@ -1880,15 +2989,103 @@
       const sameLane = lane === cursor.laneIndex;
       cursor = { laneIndex: lane, cycle: cyc };
       if (extend && sameLane && selection !== null && selection.laneIndex === lane) {
-        selection = { laneIndex: lane, from: selection.from, to: cyc };
+        selection = { laneIndex: lane, laneTo: lane, from: selection.from, to: cyc };
       } else {
-        selection = { laneIndex: lane, from: cyc, to: cyc };
+        selection = { laneIndex: lane, laneTo: lane, from: cyc, to: cyc };
       }
       repaintDrawing(layout);
       scrollCursorIntoView(layout);
       sayCursor(layout);
     }
 
+    /**
+     * v3.6.0 Task 16: while armed, walk the cursor between this lane's
+     * TRANSITIONS — `dir === 1` rightwards, `dir === -1` leftwards. Reached
+     * by **Alt+←/→**, claimed in `onKeyDown`; fix round 3 moved it off plain
+     * ←/→, which it had been bound over.
+     *
+     * What Alt+← / Alt+→ is for is picking the cell an edge will anchor to,
+     * and an edge anchors at a transition. Walking one cycle at a time makes
+     * a user press the key eight times to cross an eight-cycle flat run and
+     * land on seven cells they cannot usefully aim at.
+     *
+     * It is an ADDITION to per-cell movement, never a replacement for it —
+     * that distinction is the whole of fix round 3. Plain ←/→ still walks one
+     * cell in every state, armed included, because a jump can only land on a
+     * transition and any cell that is not one would otherwise have no
+     * keyboard route at all. The POINTER could always drop an endpoint
+     * anywhere along a flat run (hanging a label in the middle of a bus needs
+     * exactly that); after round 3 the keyboard can too, which is what T9b
+     * pins byte for byte.
+     *
+     * Which cells count is `geometry.transitionsOf`'s answer, the SAME one
+     * `wave-draw.js` paints the dots from, so a key can never stop somewhere
+     * the drawing did not put a dot. It is not re-derived here, and it is not
+     * "a cycle whose level differs from the one before" — see that function's
+     * own docstring for why that is a different (and wrong) rule.
+     *
+     * THE TWO ENDS CLAMP, and that has one consequence worth stating because
+     * it looks backwards for one press: the armed cursor only ever rests on a
+     * transition, so → with nothing further right goes to the RIGHTMOST
+     * transition and ← with nothing further left goes to the leftmost. When
+     * the cursor was parked to the right of every transition — arming does
+     * not move it, so that is reachable in one step — the first → therefore
+     * snaps LEFT, onto the rightmost anchor. Every press after that is a
+     * no-op at the same cell. Pinned both ways in `test/editor-journey.test.js`.
+     *
+     * `selection` is collapsed onto the landing cell exactly as `moveCursor`'s
+     * own non-extend branch does it: `paintAtCursor` paints `selection`'s run
+     * whenever it belongs to the cursor's lane, so a jump that left a stale
+     * run standing would make the next brush key paint a stretch of cycles
+     * the cursor is no longer anywhere near. Alt+Shift+←/→ does NOT extend
+     * the selection — an edge endpoint is one cell, so a jump has no range to
+     * grow. Plain Shift+←/→ still extends, exactly as it always did; round 3
+     * gave that back by taking the jump off the unmodified arrows.
+     *
+     * Ends in the same three calls `moveCursor` does, for the same reason: no
+     * document content changed, so this is a repaint of the drawing and the
+     * rail, not a `render()` that would also rebuild the preview to paint the
+     * identical picture.
+     */
+    function jumpTransition(dir) {
+      const layout = geometry.layoutOf(store.doc, SIZES);
+      if (layout.lanes.length === 0 || layout.cycles === 0) return;
+      // Arriving is not choosing — the same rule `moveCursor` and
+      // `enterDrawing` already state. A first keystroke that both entered
+      // the drawing and jumped somewhere would never show the user which
+      // cell it started counting from.
+      if (cursor === null) { enterDrawing(); return; }
+      const lane = cursor.laneIndex;
+      const cells = geometry.transitionsOf(store.doc, lane);
+      // A lane with nothing to anchor to: WaveDrom's `{}` spacer is the
+      // fixture case, and a lane whose wave is all continuations is the
+      // other. Neither is an error, and neither may move the cursor to a
+      // cell this rule says it is not allowed to rest on.
+      if (cells.length === 0) {
+        panels.say('這條 lane 上沒有轉態點可以停，關聯線接不上去');
+        return;
+      }
+      const now = cursor.cycle;
+      let next;
+      if (dir > 0) {
+        next = cells.find(function (c) { return c > now; });
+        if (next === undefined) next = cells[cells.length - 1];
+      } else {
+        const before = cells.filter(function (c) { return c < now; });
+        next = before.length === 0 ? cells[0] : before[before.length - 1];
+      }
+      cursor = { laneIndex: lane, cycle: next };
+      selection = { laneIndex: lane, laneTo: lane, from: next, to: next };
+      // `cell`, not `cycle`: `hoverBoundary` carries `geometry.boundaryAt`'s
+      // own field names all the way to `drawTransitions`, which compares
+      // `.cell` — the two spellings are deliberately different and a mix-up
+      // fails silently there, as that function's own comment says.
+      hoverBoundary = { laneIndex: lane, cell: next };
+      repaintDrawing(layout);
+      scrollCursorIntoView(layout);
+      sayCursor(layout);
+    }
+
     /** Paint the cursor's run with the current brush: one gesture, one
      *  `commit`, exactly like the pointer's `mouseup`. The range comes from
      *  `selection` when it belongs to the cursor's own lane — which every
@@ -1930,7 +3127,7 @@
       const to = selection === null ? cursor.cycle : Math.max(selection.from, selection.to);
       const span = (selection !== null && selection.laneIndex === cursor.laneIndex && to > from)
         ? '，選了 cycle ' + (from + 1) + '–' + (to + 1) : '';
-      say('游標：' + name + ' cycle ' + (cursor.cycle + 1) + span);
+      panels.say('游標：' + name + ' cycle ' + (cursor.cycle + 1) + span);
     }
 
     /** The lane list and the drawing, repainted together and without touching
@@ -1941,8 +3138,29 @@
     function repaintDrawing(layout) {
       const l = layout === undefined || layout === null
         ? geometry.layoutOf(store.doc, SIZES) : layout;
-      renderLanes(store.doc, l);
-      renderCanvas(store.doc, l);
+      panels.renderLanes(store.doc, l, { selection: selection });
+      const wds = {
+        cursor: cursor,
+        selection: selection,
+        pendingFrom: pendingFrom,
+        endpointDrag: endpointDrag,
+        selectedEdge: selectedEdge,
+        overlay: overlay,
+        canvasWrap: canvasWrap,
+        dataEdit: dataEdit,
+        enterDrawing: enterDrawing,
+        onCanvasDown: onCanvasDown,
+        onCanvasHover: onCanvasHover,
+        edgeMode: edgeMode,
+        hoverBoundary: hoverBoundary,
+      };
+      canvas = drawer.renderCanvas(canvas, store.doc, l, wds);
+      cursor = wds.cursor;
+      selection = wds.selection;
+      // AFTER the drawer, which is what clamps `selection` into the document
+      // it just drew — reading it before would arm a button against a range
+      // the drawing has already refused.
+      paintSelectionState(store.doc, l);
     }
 
     /**
@@ -1990,11 +3208,262 @@
     function onCanvasDown(ev) {
       if (ev.button !== 0) return;
       const layout = geometry.layoutOf(store.doc, SIZES);
+      // v3.5.0 Task 7: armed edge-creation claims the press outright, before
+      // the edge-select / deselect / paint dispatch below ever runs — the
+      // whole point of arming is that the NEXT press starts the drag, so it
+      // must not be shadowed by "did this land on an existing edge" or "did
+      // this land on a cell to paint". A press that misses every lane
+      // (`at === null`, e.g. the canvas's own padding) leaves the button
+      // armed rather than eating it for nothing: missing the diagram is not
+      // the same as aiming at the wrong cell, but the recovery is the same —
+      // try the press again.
+      if (edgeMode === 'armed') {
+        const at = cellFromEvent(ev, layout);
+        if (at === null) return;
+        ev.preventDefault();
+        pendingFrom = { at: at.laneIndex, cell: at.cycle };
+        setEdgeMode('dragging');
+        // The keyboard follows the pointer here for the same reason it does
+        // in the paint path below: `cursor` is the ONE notion of "where is
+        // the other end right now" that the mouse move handler, the preview
+        // line and (on the keyboard's own path) `handleDrawingKey` all read,
+        // so drag and keystroke can never disagree about the live endpoint.
+        cursor = { laneIndex: at.laneIndex, cycle: at.cycle };
+        canvas.focus();
+        render();
+        d.addEventListener('mousemove', onCanvasMove, true);
+        d.addEventListener('mouseup', onCanvasUp, true);
+        return;
+      }
+      // v3.5.0 Task 8: a press on the SELECTED edge's own handle starts an
+      // endpoint drag, ahead of the plain select/deselect dispatch a few
+      // lines down — that dispatch's own `edgeHitAt` would otherwise see the
+      // exact same press and read it as "re-select the edge that is already
+      // selected", which is a real answer but the wrong one for a press ON
+      // its handle. Recomputed fresh here (`geometry.edgeLayout`, not a
+      // cached list) for the same reason `cellFromEvent`/`edgeHitAt`
+      // already are — a press can never be judged against a layout
+      // `renderCanvas` has moved on from.
+      //
+      // Scoped to `handle.index === selectedEdge` on purpose:
+      // `geometry.edgeHandleAt` answers for EVERY edge's endpoints
+      // regardless of selection (see its own comment), but `renderEdges`
+      // only ever DRAWS handles on the selected one — a press near a
+      // DIFFERENT edge's endpoint has no handle on screen to have landed on,
+      // and falls through to the ordinary select-by-path/point dispatch
+      // below exactly as it always has.
+      if (selectedEdge !== null) {
+        const edges = geometry.edgeLayout(store.doc, layout);
+        const box = canvas.getBoundingClientRect();
+        const handle = geometry.edgeHandleAt(edges, ev.clientX - box.left, ev.clientY - box.top);
+        if (handle !== null && handle.index === selectedEdge) {
+          ev.preventDefault();
+          // Fix round 1, item 1: a self-loop (`from === to`) puts both ends
+          // at the exact same pixel, so `geometry.edgeHandleAt`'s own
+          // `['to', 'from']` iteration always resolves the press to `'to'` —
+          // there is no position this file (or the user) can use to tell
+          // the two apart, and inferring one would just be a guess dressed
+          // up as an answer. What was missing was not a fix, it was the
+          // honest half: before this, the press silently moved `'to'` with
+          // nothing on screen saying that is what happened, or that `'from'`
+          // was never reachable at all.
+          const dragged = edges.filter(function (e) { return e.index === handle.index; })[0];
+          if (dragged !== undefined && dragged.edge.from === dragged.edge.to) {
+            panels.say('這是一條 self-loop（起點跟終點在同一格），兩端的把手疊在同一個位置：' +
+              '只有拖得到的這一端可以搬，另一端目前搬不到。');
+          }
+          endpointDrag = { index: handle.index, end: handle.end, at: null, cell: null };
+          canvas.focus();
+          // Fix round 1, item 2: without a repaint here the press looks
+          // inert until the first `pointermove` — `.is-drag-source` (set
+          // from this same `endpointDrag`, read by `renderEdges`) would not
+          // fade the dragged edge until then, unlike the sibling
+          // `edgeMode === 'armed'` branch above, which repaints immediately
+          // on its own press. `renderCanvas`, not the full `render()`: this
+          // state change touches only the canvas SVG (the faded path; the
+          // dashed landing preview has nothing to draw yet since `at` is
+          // still `null`) — `selectedEdge` is unchanged, so the edge
+          // inspector row and the lane list are both already showing exactly
+          // what they should, and paying for `renderLanes`/`renderEdgeBar`
+          // again would be the same needless cost the existing
+          // `hadSelectedEdge`-gated branch further down in this function
+          // already avoids.
+          const wds = {
+            cursor: cursor,
+            selection: selection,
+            pendingFrom: pendingFrom,
+            endpointDrag: endpointDrag,
+            selectedEdge: selectedEdge,
+            overlay: overlay,
+            canvasWrap: canvasWrap,
+            dataEdit: dataEdit,
+            enterDrawing: enterDrawing,
+            onCanvasDown: onCanvasDown,
+            onCanvasHover: onCanvasHover,
+            edgeMode: edgeMode,
+            hoverBoundary: hoverBoundary,
+          };
+          canvas = drawer.renderCanvas(canvas, store.doc, layout, wds);
+          cursor = wds.cursor;
+          selection = wds.selection;
+          // The toolbar reads `selection`; this repaint can change it (fix round 1).
+          paintSelectionState(store.doc, layout);
+          d.addEventListener('mousemove', onCanvasMove, true);
+          d.addEventListener('mouseup', onCanvasUp, true);
+          return;   // 不塗、不選格
+        }
+      }
+      // v3.5.0 Task 11 fix round 2 (widened in round 3): a press that lands
+      // on the label's own mark — the `<text>` when the run has a label, or
+      // (round 3) the small `<circle class="ed-wave-buslabel-empty">`
+      // `drawLane` draws in its place when the run has none — opens the
+      // data-label field instead of arming a paint drag, rather than merely
+      // somewhere inside the box the mark sits in. Round 1 gated this on
+      // the CELL (`codec.dataSlotOf`/`resolveBusTarget` alone, asked off
+      // the pressed cycle with no regard to what was actually under the
+      // pointer) and that was reviewer-verified to be its own regression:
+      // T6b paints `N` onto a bus cell with the mouse, and painting a
+      // bus cell is exactly what twenty-two brushes exist for — a gesture
+      // that swallows every press anywhere in the box leaves the user no
+      // pointer route to repaint one at all. The string is what a press on
+      // its mark means to change, so the mark is the target; a press
+      // anywhere else in the SAME box — the polygon, its bevelled ends, a
+      // held continuation's own cell — falls straight through to the
+      // ordinary paint dispatch below exactly as it always has, ROUND 1's
+      // fix included: that fix's `resolveBusTarget` still runs, just gated
+      // on the mark hit rather than on cell membership, so a press on the
+      // label of a merged run still resolves to the run's owning explicit
+      // cycle regardless of which cycle's pixels the mark happens to
+      // straddle (see `resolveBusTarget`'s own comment — its answer is the
+      // same whichever cycle a press on that shared mark geometrically
+      // lands on). Both marks carry the SAME `ed-wave-buslabel` class —
+      // round 3's placeholder ADDS `ed-wave-buslabel-empty` on top of it
+      // rather than replacing it — so this check needed no change at all
+      // to cover the empty case; it was already asking for the class, not
+      // for an element type. `.ed-wave-buslabel`'s `pointer-events:
+      // visiblePainted` (`lib/md2doc.js`) plus paint order — each mark is
+      // appended AFTER its box's `<polygon>` in `drawLane`, so it sits on
+      // top and wins the hit test in its own footprint — is what makes the
+      // two targets disjoint instead of the mark being invisibly swallowed
+      // by the polygon underneath it.
+      //
+      // final review finding 4: this block moved AHEAD of `edgeHitAt` below
+      // (it used to run after it), and its condition now asks
+      // `busLabelHitAt` instead of testing `ev.target` directly.
+      //
+      // Gating `edgeHandleAt` on `selectedEdge` (the change in `edgeHitAt`
+      // itself, above) stops a PHANTOM, undrawn handle from claiming a press
+      // by pure coordinate math — but MEASURED against a real page, that
+      // alone does not make this block reachable: `renderEdges` draws
+      // `.ed-wave-edge-hit` (a 10px-wide, invisible-but-hit-testable stroke,
+      // `pointer-events: stroke`) AFTER every lane's own content, so for any
+      // edge whose endpoint lands on a bus cell, that invisible stroke
+      // paints ON TOP of the cell's `.ed-wave-buslabel` mark. `ev.target` —
+      // the browser's own topmost-element answer — is `path.ed-wave-edge-
+      // hit` at that pixel regardless of source order in THIS function:
+      // moving this block ahead of `edgeHitAt` does not change what
+      // `ev.target` IS, only when it gets asked. Reordering plus the
+      // original `ev.target` check was tried first and measured to still
+      // fail — `elementFromPoint` at the labelled cell's own centre resolved
+      // to the hit path, not the label, exactly as before.
+      //
+      // `busLabelHitAt` answers a different question: not "what is the
+      // TOPMOST element here" but "is there a bus-label mark ANYWHERE in the
+      // stack of elements under this press", via `elementsFromPoint`
+      // (plural) — the standard way to see past one hit-testable layer
+      // sitting on top of another at the same point. That is a real,
+      // measured difference in outcome, not a matter of code order.
+      if (busLabelHitAt(ev) !== null) {
+        const busAt = cellFromEvent(ev, layout);
+        if (busAt !== null) {
+          const busLane = layout.lanes[busAt.laneIndex].lane;
+          const busTarget = resolveBusTarget(busLane, busAt.cycle);
+          // `resolveBusTarget` should never actually answer `null` here —
+          // the label only ever exists over a cycle the codec itself calls
+          // a bus level — but the check is kept rather than assumed, same
+          // reasoning as the `'blocked'` branch just below it.
+          if (busTarget === 'blocked') {
+            ev.preventDefault();
+            panels.say('這一格接在某個 bus 值後面，但看不出屬於哪一個，沒有欄位可以編輯。');
+            return;
+          }
+          if (busTarget !== null) {
+            ev.preventDefault();
+            const busHadSelectedEdge = selectedEdge !== null;
+            selectedEdge = null;
+            cursor = { laneIndex: busAt.laneIndex, cycle: busTarget.cycle };
+            selection = {
+              laneIndex: busAt.laneIndex, laneTo: busAt.laneIndex,
+              from: busTarget.cycle, to: busTarget.cycle,
+            };
+            canvas.focus();
+            if (busHadSelectedEdge) render();
+            else {
+              const wds = {
+                cursor: cursor,
+                selection: selection,
+                pendingFrom: pendingFrom,
+                endpointDrag: endpointDrag,
+                selectedEdge: selectedEdge,
+                overlay: overlay,
+                canvasWrap: canvasWrap,
+                dataEdit: dataEdit,
+                enterDrawing: enterDrawing,
+                onCanvasDown: onCanvasDown,
+                onCanvasHover: onCanvasHover,
+                edgeMode: edgeMode,
+                hoverBoundary: hoverBoundary,
+              };
+              canvas = drawer.renderCanvas(canvas, store.doc, layout, wds);
+              cursor = wds.cursor;
+              selection = wds.selection;
+              // The toolbar reads `selection`; this repaint can change it (fix round 1).
+              paintSelectionState(store.doc, layout);
+            }
+            openDataEdit(busAt.laneIndex, busTarget.cycle);
+            return;
+          }
+        }
+      }
+      // An edge — its endpoint handle first (it sits ON TOP of the cell it
+      // anchors to, and a selected edge's handle must win the press even
+      // though the cell underneath is perfectly paintable), then its path —
+      // is asked BEFORE the cell/brush dispatch below (but AFTER the bus
+      // label block above — see its own comment for why that one now goes
+      // first). A hit selects and returns without arming `drag`: this
+      // dispatch draws and selects edges; a press on the SELECTED edge's own
+      // handle never reaches here at all (see the drag-start branch above),
+      // so this remains a plain select — it does not itself drag anything.
+      const edgeHit = edgeHitAt(ev, layout);
+      if (edgeHit !== null) {
+        ev.preventDefault();
+        selectedEdge = edgeHit;
+        canvas.focus();
+        render();
+        return;
+      }
+      // A press that hit neither an edge's handle nor its path deselects
+      // whatever WAS selected. The inspector row is the only visible sign a
+      // selection exists, and a selection that outlives a click elsewhere
+      // would let a later 刪除這條線 act on an edge the user has stopped
+      // looking at. This is IN ADDITION to the paint gesture below, on the
+      // very same press — not instead of it.
+      const hadSelectedEdge = selectedEdge !== null;
+      selectedEdge = null;
       const at = cellFromEvent(ev, layout);
-      if (at === null) return;
+      if (at === null) {
+        // Missed the diagram entirely (e.g. the canvas's own padding). Only
+        // the deselect, if there was one to make, needs a repaint; nothing
+        // else here changed.
+        if (hadSelectedEdge) render();
+        return;
+      }
       ev.preventDefault();
       drag = { laneIndex: at.laneIndex, from: at.cycle, to: at.cycle };
-      selection = { laneIndex: at.laneIndex, from: at.cycle, to: at.cycle };
+      selection = {
+        laneIndex: at.laneIndex, laneTo: at.laneIndex,
+        from: at.cycle, to: at.cycle,
+      };
       // The keyboard follows the pointer, for two reasons that are really one:
       // the two cursors may not disagree about which cell is current, and
       // `preventDefault()` above suppresses the focus a press would otherwise
@@ -2002,12 +3471,131 @@
       // then pressing `1` would paint wherever the keyboard had been left.
       cursor = { laneIndex: at.laneIndex, cycle: at.cycle };
       canvas.focus();
-      renderCanvas(store.doc, layout);
+      // The common case — no edge was selected — keeps the cheap
+      // `renderCanvas`-only repaint this always did. A full `render()` is
+      // only paid on the transition that actually needs it: hiding the
+      // inspector row, which lives in the toolbar `renderCanvas` never
+      // touches.
+      if (hadSelectedEdge) render();
+      else {
+        const wds = {
+          cursor: cursor,
+          selection: selection,
+          pendingFrom: pendingFrom,
+          endpointDrag: endpointDrag,
+          selectedEdge: selectedEdge,
+          overlay: overlay,
+          canvasWrap: canvasWrap,
+          dataEdit: dataEdit,
+          enterDrawing: enterDrawing,
+          onCanvasDown: onCanvasDown,
+          onCanvasHover: onCanvasHover,
+          edgeMode: edgeMode,
+          hoverBoundary: hoverBoundary,
+        };
+        canvas = drawer.renderCanvas(canvas, store.doc, layout, wds);
+        cursor = wds.cursor;
+        selection = wds.selection;
+        // The toolbar reads `selection`; this repaint can change it (fix round 1).
+        paintSelectionState(store.doc, layout);
+      }
       d.addEventListener('mousemove', onCanvasMove, true);
       d.addEventListener('mouseup', onCanvasUp, true);
     }
 
     function onCanvasMove(ev) {
+      if (endpointDrag !== null) {
+        // Same abandoned-button recovery as the two drags below: the button
+        // came up somewhere this page never heard about.
+        if (ev.buttons === 0) { onCanvasUp(); return; }
+        const layout = geometry.layoutOf(store.doc, SIZES);
+        const at = cellFromEvent(ev, layout);
+        // A move that strays off the diagram leaves `at`/`cell` exactly
+        // where they last were, same recovery as `edgeMode === 'dragging'`
+        // below and for the same reason: the drop target the user is
+        // currently over is still the last cell the pointer was actually on
+        // top of, not "nowhere".
+        if (at !== null) {
+          endpointDrag = { index: endpointDrag.index, end: endpointDrag.end,
+            at: at.laneIndex, cell: at.cycle };
+        }
+        // `hoverBoundary` is left alone here: `drawTransitions` only ever
+        // draws while `edgeMode !== 'idle'` (see its own guard, unchanged
+        // by this task), and an endpoint drag never moves `edgeMode` away
+        // from 'idle' (it is a wholly separate gesture from edge-creation —
+        // see `endpointDrag`'s own declaration comment), so there is no dot
+        // on screen for a hot mark to name here. `cellFromEvent` still
+        // snaps this drag's OWN drop target to the nearest anchor via
+        // `boundaryAt` — that part of Task 11 applies regardless — this is
+        // only about the separate hover-dot chrome.
+        // The document is untouched during the drag (rule 3): this repaints
+        // the preview only, never a `commit`.
+        const wds = {
+          cursor: cursor,
+          selection: selection,
+          pendingFrom: pendingFrom,
+          endpointDrag: endpointDrag,
+          selectedEdge: selectedEdge,
+          overlay: overlay,
+          canvasWrap: canvasWrap,
+          dataEdit: dataEdit,
+          enterDrawing: enterDrawing,
+          onCanvasDown: onCanvasDown,
+          onCanvasHover: onCanvasHover,
+          edgeMode: edgeMode,
+          hoverBoundary: hoverBoundary,
+        };
+        canvas = drawer.renderCanvas(canvas, store.doc, layout, wds);
+        cursor = wds.cursor;
+        selection = wds.selection;
+        // The toolbar reads `selection`; this repaint can change it (fix round 1).
+        paintSelectionState(store.doc, layout);
+        return;
+      }
+      if (edgeMode === 'dragging') {
+        // Same abandoned-button recovery as the paint drag below: the button
+        // came up somewhere this page never heard about.
+        if (ev.buttons === 0) { onCanvasUp(); return; }
+        const layout = geometry.layoutOf(store.doc, SIZES);
+        const at = cellFromEvent(ev, layout);
+        // A move that strays off the diagram leaves `cursor` — and so the
+        // preview line — exactly where it last was, rather than snapping the
+        // line away: the drop target the user is currently over is still the
+        // last cell the pointer was actually on top of.
+        if (at !== null) {
+          cursor = { laneIndex: at.laneIndex, cycle: at.cycle };
+          // v3.6.0 Task 11: the hot dot keeps following the drag once it
+          // starts, rather than freezing at whatever it last showed during
+          // the pre-press hover (or never lighting up at all, if the drag
+          // started from a keyboard Enter with no hover first) — same
+          // `cycle`-to-`cell` conversion as `onCanvasHover`, at this same
+          // boundary.
+          hoverBoundary = { laneIndex: at.laneIndex, cell: at.cycle };
+        }
+        // The document is untouched during the drag (rule 2): this repaints
+        // the preview line only, never a `commit`.
+        const wds = {
+          cursor: cursor,
+          selection: selection,
+          pendingFrom: pendingFrom,
+          endpointDrag: endpointDrag,
+          selectedEdge: selectedEdge,
+          overlay: overlay,
+          canvasWrap: canvasWrap,
+          dataEdit: dataEdit,
+          enterDrawing: enterDrawing,
+          onCanvasDown: onCanvasDown,
+          onCanvasHover: onCanvasHover,
+          edgeMode: edgeMode,
+          hoverBoundary: hoverBoundary,
+        };
+        canvas = drawer.renderCanvas(canvas, store.doc, layout, wds);
+        cursor = wds.cursor;
+        selection = wds.selection;
+        // The toolbar reads `selection`; this repaint can change it (fix round 1).
+        paintSelectionState(store.doc, layout);
+        return;
+      }
       if (drag === null) return;
       // The button came up somewhere this page never heard about — outside the
       // window, or over the browser's own chrome. Without this the drag stays
@@ -2022,16 +3610,53 @@
       // The lane is fixed by the press: a drag that strays onto a neighbour is
       // still painting the lane it started on.
       drag.to = at.cycle;
-      selection = { laneIndex: drag.laneIndex, from: drag.from, to: drag.to };
+      selection = {
+        laneIndex: drag.laneIndex, laneTo: drag.laneIndex,
+        from: drag.from, to: drag.to,
+      };
       // The drag's live end is where the cursor is, so a paint continued with
       // Shift+←/→ after the button comes up carries on from the same cell.
       cursor = { laneIndex: drag.laneIndex, cycle: drag.to };
-      renderCanvas(store.doc, layout);
+      const wds = {
+        cursor: cursor,
+        selection: selection,
+        pendingFrom: pendingFrom,
+        endpointDrag: endpointDrag,
+        selectedEdge: selectedEdge,
+        overlay: overlay,
+        canvasWrap: canvasWrap,
+        dataEdit: dataEdit,
+        enterDrawing: enterDrawing,
+        onCanvasDown: onCanvasDown,
+        onCanvasHover: onCanvasHover,
+        edgeMode: edgeMode,
+        hoverBoundary: hoverBoundary,
+      };
+      canvas = drawer.renderCanvas(canvas, store.doc, layout, wds);
+      cursor = wds.cursor;
+      selection = wds.selection;
+      // The toolbar reads `selection`; this repaint can change it (fix round 1).
+      paintSelectionState(store.doc, layout);
     }
 
     function onCanvasUp() {
       d.removeEventListener('mousemove', onCanvasMove, true);
       d.removeEventListener('mouseup', onCanvasUp, true);
+      if (endpointDrag !== null) {
+        finishEndpointDrag();
+        return;
+      }
+      if (edgeMode === 'dragging') {
+        // `cursor` is never null here: `onCanvasDown` set it to the press
+        // cell before this drag was ever armed, and every move since then
+        // only ever moved it to another real cell (see `onCanvasMove`
+        // above). The null-safe form costs nothing and matches the
+        // `finishEdgeDrag`/`codec.ensureNode` contract exactly rather than
+        // asserting a fact this file does not have to assert.
+        finishEdgeDrag(cursor === null ? null : cursor.laneIndex,
+          cursor === null ? null : cursor.cycle);
+        return;
+      }
       if (drag === null) return;
       const g = drag;
       drag = null;
@@ -2040,53 +3665,347 @@
       });
     }
 
-    /** Pointer coordinates in the drawing's own space, then the codec's cell. */
+    /**
+     * The end of an endpoint drag on the SELECTED edge — one `commit`, so one
+     * undo step, matching every other gesture in this file (constraint 5).
+     *
+     * Unlike `finishEdgeDrag` below, this has no keyboard-driven twin and
+     * takes no parameters: there is no second input device sharing `cursor`
+     * to aim it, so everything the drop needs already lives in `endpointDrag`
+     * itself, read and cleared in the same first two lines the same way
+     * `finishEdgeDrag` clears `pendingFrom`'s owning mode up front.
+     *
+     * `drag.at === null` means the pointer never landed on a real cell for
+     * the whole gesture (pressed the handle, released off the diagram or
+     * without ever moving) — nothing to drop onto, so this only repaints to
+     * take the (already absent) preview line off screen and does not call
+     * `commit` at all; a `commit` with a non-integer `at` would just be
+     * `codec.moveEdgeEnd`'s own bounds check refusing it one function later
+     * for no benefit.
+     *
+     * Every other landing — including the three no-ops `moveEdgeEnd` itself
+     * refuses (dropping back on the end's own cell, dropping on the cell
+     * holding the edge's OTHER end, and an out-of-range target) — reaches
+     * `commit` exactly once and is judged by `commit`'s own return value,
+     * the same "one test of did-anything-change" rule `finishEdgeDrag`
+     * documents at length below: nothing here re-derives any of those three
+     * checks, that would be a second belief about the same refusal living
+     * next to `moveEdgeEnd`'s own.
+     */
+    function finishEndpointDrag() {
+      const drag = endpointDrag;
+      endpointDrag = null;
+      if (drag === null) return;
+      if (drag.at === null) { render(); return; }
+      commit('edge-move', function (doc) {
+        return codec.moveEdgeEnd(doc, drag.index, drag.end, drag.at, drag.cell);
+      });
+      render();
+    }
+
+    /**
+     * The end of an edge-creation gesture, reached from both input devices —
+     * the mouse's `onCanvasUp` above and the keyboard's second Enter in
+     * `handleDrawingKey` below. Constraint 4: one function, not two
+     * histories of the same decision.
+     *
+     * `at`/`cell` name the drop cell, or `null`/`null` when the gesture did
+     * not land on any lane at all. Nothing below special-cases the no-op
+     * drops rule 3 lists — dropping back on the start cell, dropping on a
+     * row with no waveform (a spacer — a group's own title is never a row
+     * to drop on in the first place: `codec.isLane` rejects the title
+     * string, so `flattenLanes` never allocates one, and there is no
+     * coordinate here to mis-hit), dropping on the cell that already holds
+     * this edge's OTHER end, and — fix round 1 — repeating the exact same
+     * drag a second time:
+     *
+     *   - a spacer's row IS a real, hittable cell (`geometry.cellAt` answers
+     *     it like any other), but `codec.ensureNode`'s own lane-local bound
+     *     refuses it: an empty `wave` reads as zero cells, so no cycle is
+     *     ever in range. The "missed the diagram entirely" case
+     *     (`at === null`) falls through the SAME check for a different
+     *     reason — neither `at` nor `cell` is an integer `ensureNode`'s
+     *     bounds test accepts;
+     *   - the start cell and the drop cell landing on the same anchor —
+     *     whether because they truly are the same cell, or because the drop
+     *     cell is wherever this edge's other end already lives — is exactly
+     *     `a.letter === b.letter` below;
+     *   - a repeat of this exact gesture between the same two cells would,
+     *     without the check below, silently push a byte-identical second
+     *     `doc.edge` entry — two arrows drawn exactly on top of each other,
+     *     indistinguishable on screen, plus a second undo step for nothing
+     *     visible (MEASURED against the real store: drag (0,1)->(0,3) twice,
+     *     `doc.edge` becomes `["a~>b","a~>b"]`). Refused here rather than
+     *     before `commit`, same as the other three: an entry with the same
+     *     four fields (`from`, `to`, `shape`, `label`) already in `doc.edge`
+     *     makes this call's own output redundant. This is narrower than
+     *     "refuse any second edge between these two anchors" — two
+     *     DIFFERENT annotations between the same pair (`a~>b setup` next to
+     *     `a-b hold`) are legitimate and stay possible; only a verbatim
+     *     repeat of THIS gesture's own fixed output (`shape: '~>'`,
+     *     `label: ''`) is refused.
+     *
+     * So there is one test of "did anything change", not four: `commit`'s
+     * own return value. A refused/no-op commit pushes no undo step (`commit`
+     * already guarantees that) and — rule 1 — leaves the gesture `'armed'`
+     * rather than disarming it, because the user pressed the button and got
+     * nothing for it; a real edge disarms back to `'idle'`. Either way this
+     * repaints once more on its own, because `commit` only repaints when it
+     * changed something, and the pending-line preview has to come off the
+     * screen in the no-op case too.
+     *
+     * Fix round 3: `pendingFrom === null` on entry is no longer read as
+     * "nothing to do" and left at that. `carryMarks` can now drop
+     * `pendingFrom` to `null` on its own (round 2, both when a structural
+     * change makes it untraceable and when no `laneTrace` is injected at
+     * all) WITHOUT touching `edgeMode` — before round 2 the only code path
+     * that ever nulled `pendingFrom` was `setEdgeMode('idle')` itself, so
+     * the two could never come apart. Reached from `onCanvasUp` while
+     * `edgeMode === 'dragging'` (the mouse button was down when the
+     * document changed out from under it), leaving `edgeMode` untouched
+     * here would strand it at `'dragging'` forever: `onCanvasMove` and
+     * `onCanvasUp` both check that mode FIRST, so every later paint drag's
+     * `mousemove`/`mouseup` would be swallowed by this function instead of
+     * painting, silently and with no error. So this resyncs the mode to
+     * the mark it depends on before doing anything else.
+     */
+    function finishEdgeDrag(at, cell) {
+      if (pendingFrom === null) { setEdgeMode('idle'); render(); return; }
+      const from = pendingFrom;
+      const changed = commit('edge-add', function (doc) {
+        const a = codec.ensureNode(doc, from.at, from.cell);
+        if (a.letter === null) return doc;
+        const b = codec.ensureNode(a.doc, at, cell);
+        if (b.letter === null) return doc;
+        if (a.letter === b.letter) return doc;   // same anchor both ends
+        const dup = (b.doc.edge || []).some(function (entry) {
+          const e = codec.parseEdge(entry);
+          return e !== null && e.from === a.letter && e.to === b.letter &&
+            e.shape === '~>' && e.label === '';
+        });
+        if (dup) return doc;   // byte-identical repeat of this gesture
+        return codec.addEdge(b.doc, { from: a.letter, to: b.letter, shape: '~>', label: '' });
+      });
+      setEdgeMode(changed ? 'idle' : 'armed');
+      render();
+    }
+
+    /**
+     * Pointer coordinates in the drawing's own space, then the codec's cell.
+     *
+     * v3.6.0 Task 11: while an edge gesture is live — `edgeMode !== 'idle'`
+     * (armed, marking a start; or dragging, aiming the other end) or an
+     * `endpointDrag` is in flight — the target is the ANCHOR the engine
+     * actually draws the line to, not the cell under the pointer.
+     * `geometry.boundaryAt` rounds to the nearest one; `geometry.cellAt`
+     * floors to the cell the pointer is over. Painting still wants the
+     * floor: the brush's target is the cell you are over, and unifying the
+     * two here is exactly the regression this task exists to prevent (see
+     * `boundaryAt`'s own comment in `wave-geometry.js`).
+     *
+     * `boundaryAt` returns `{laneIndex, cell}`; every caller of this
+     * function already destructures `{laneIndex, cycle}` from `cellAt`'s
+     * shape, so the field is renamed HERE, at the one place the two
+     * definitions meet, rather than letting a `cell` leak into a `cycle`
+     * slot downstream.
+     */
     function cellFromEvent(ev, layout) {
       if (canvas === null) return null;
       const box = canvas.getBoundingClientRect();
-      return geometry.cellAt(layout, ev.clientX - box.left, ev.clientY - box.top);
+      const x = ev.clientX - box.left;
+      const y = ev.clientY - box.top;
+      if (edgeMode !== 'idle' || endpointDrag !== null) {
+        const b = geometry.boundaryAt(layout, x, y);
+        return b === null ? null : { laneIndex: b.laneIndex, cycle: b.cell };
+      }
+      return geometry.cellAt(layout, x, y);
     }
 
-    // ── the preview ───────────────────────────────────────────────────────
     /**
-     * The engine's own rendering of the very same document.
+     * Pure hover, no button down, nothing committed — which anchor the
+     * pointer is nearest while armed and not yet dragging, purely so
+     * `drawTransitions`'s hot dot can light up before the user presses.
      *
-     * This is the check on the drawing, which is the only reason it is on
-     * screen. It is rendered from a plain copy because wavedrom writes into the
-     * source object it is handed and the store's documents are frozen.
+     * A canvas-own listener rather than the document-level
+     * `onCanvasMove`/`onCanvasUp` pair: those two are only added once a
+     * drag actually starts (`onCanvasDown`'s 'armed' and endpoint-drag
+     * branches), so a plain hover before the first press has nothing else
+     * watching it. Once a drag IS live, `onCanvasMove`'s own branches
+     * already repaint on every move and set `hoverBoundary` themselves
+     * (below), so this steps out of the way rather than doing the same
+     * work under a second name — the `edgeMode !== 'armed'` guard covers
+     * both: `edgeMode === 'dragging'` fails it directly, and an
+     * `endpointDrag` never moves `edgeMode` away from 'idle' in the first
+     * place (it is a wholly separate gesture from edge-creation), so it
+     * fails the same guard too.
      */
-    function renderPreview(doc) {
-      const engine = opts.wavedrom;
-      if (engine === null || engine === undefined ||
-          typeof engine.RenderWaveForm !== 'function') {
-        previewHost.textContent = '（這一頁沒有載入 WaveDrom，預覽從缺）';
-        previewWrap.setAttribute('data-wave-preview', 'absent');
-        return;
+    function onCanvasHover(ev) {
+      if (edgeMode !== 'armed') return;
+      const layout = geometry.layoutOf(store.doc, SIZES);
+      const at = cellFromEvent(ev, layout);
+      const next = at === null ? null : { laneIndex: at.laneIndex, cell: at.cycle };
+      const same = (hoverBoundary === null && next === null) ||
+        (hoverBoundary !== null && next !== null &&
+          hoverBoundary.laneIndex === next.laneIndex && hoverBoundary.cell === next.cell);
+      if (same) return;
+      hoverBoundary = next;
+      const wds = {
+        cursor: cursor,
+        selection: selection,
+        pendingFrom: pendingFrom,
+        endpointDrag: endpointDrag,
+        selectedEdge: selectedEdge,
+        overlay: overlay,
+        canvasWrap: canvasWrap,
+        dataEdit: dataEdit,
+        enterDrawing: enterDrawing,
+        onCanvasDown: onCanvasDown,
+        onCanvasHover: onCanvasHover,
+        edgeMode: edgeMode,
+        hoverBoundary: hoverBoundary,
+      };
+      canvas = drawer.renderCanvas(canvas, store.doc, layout, wds);
+      cursor = wds.cursor;
+      selection = wds.selection;
+      // The toolbar reads `selection`; this repaint can change it (fix round 1).
+      paintSelectionState(store.doc, layout);
+    }
+
+    /**
+     * The `doc.edge` index the press landed on, or `null`.
+     *
+     * Two questions, in order, both against `geometry.edgeLayout(store.doc,
+     * layout)` computed fresh here — the same recompute-don't-cache rule
+     * `cellFromEvent`/`geometry.cellAt` already follow, so a press can never
+     * be judged against a layout `renderCanvas` has moved on from:
+     *
+     *   1. `geometry.edgeHandleAt` — a handle is a small rect centred on an
+     *      endpoint, asked in the SAME layout-local space `cellFromEvent`
+     *      uses (the canvas's own `getBoundingClientRect()`). v3.6.0 Task 6:
+     *      `SIZES.nameColWidth` is 120, not 0 — but `ev.clientX - box.left`
+     *      still needs nothing added or subtracted for it, because the name
+     *      column's width is already baked into every cell's own `originX`
+     *      (`wave-geometry.layoutOf`), the same layout-local coordinate
+     *      `geometry.edgeHandleAt`/`cellAt` read. One coordinate space, not
+     *      two reconciled by an offset — a nonzero name column moves where
+     *      cycle 0 STARTS in that space, it does not add a second term on
+     *      top of it. final review finding 4: trusted when it names the
+     *      edge that is actually SELECTED — `renderEdges` only DRAWS a
+     *      handle on the selected edge, so its answer for any OTHER edge is a
+     *      rectangle with nothing on screen, and letting that phantom
+     *      rectangle claim the press is what used to swallow a bus label's
+     *      press whenever the label's cell doubled as an unselected edge's
+     *      endpoint (see `onCanvasDown`'s `busLabelHitAt` check, which now
+     *      runs before this function is even called, for the other half of
+     *      that fix). A press within a handle-sized target of the SELECTED
+     *      edge's own endpoint still selects it rather than painting the
+     *      cell under it. final review re-review, item 1: ALSO trusted when
+     *      the named edge is a self-loop (`from === to`), selected or not —
+     *      a self-loop's `pathFor` output is a zero-length path (every
+     *      command's endpoint equals its start), which Chrome gives no hit
+     *      area at all, so #2 below can never find one; the handle is the
+     *      only thing a self-loop can ever be selected by, and a self-loop
+     *      the user hand-writes into the markdown must stay selectable and
+     *      deletable even before it has ever been clicked once.
+     *   2. The `<path class="ed-wave-edge-hit">` twin `renderEdges` layers
+     *      over each visible edge, read back through `document.elementFromPoint`
+     *      at the press's SCREEN coordinates (no conversion needed — that is
+     *      what `elementFromPoint` already takes).
+     */
+    function edgeHitAt(ev, layout) {
+      if (canvas === null) return null;
+      const edges = geometry.edgeLayout(store.doc, layout);
+      if (edges.length === 0) return null;
+      const box = canvas.getBoundingClientRect();
+      const handle = geometry.edgeHandleAt(edges, ev.clientX - box.left, ev.clientY - box.top);
+      // final review finding 4: only trust the handle answer when it names
+      // the edge that is actually SELECTED — the same scoping the
+      // endpoint-drag branch in `onCanvasDown` already applies, for the same
+      // reason (see its comment): `renderEdges` only ever DRAWS a handle on
+      // the selected edge, so `geometry.edgeHandleAt`'s answer for any OTHER
+      // edge index is a rectangle with nothing on screen at all. Before this,
+      // that undrawn rectangle still won the press here — a bus label whose
+      // cell happened to double as an unselected edge's endpoint could never
+      // open its label editor, because this branch claimed the press first.
+      // An edge stays selectable regardless: the fall-through below still
+      // hit-tests every edge's own 10px `.ed-wave-edge-hit` path.
+      //
+      // final review re-review, item 1: EXCEPT a self-loop (`from === to`),
+      // which this "an edge stays selectable regardless" promise does not
+      // actually cover — MEASURED regression, not a hypothetical: `pathFor`
+      // degenerates to a zero-length path for every shape family when
+      // `from === to` (every `L`/`C` command's endpoint equals its start),
+      // and Chrome gives a zero-length, butt-cap path NO hit area at all —
+      // `elementsFromPoint` returns nothing there, so the `.ed-wave-edge-hit`
+      // fallback below can never find it either. The phantom handle this
+      // finding gates off was the ONLY thing that could ever select a
+      // self-loop that has never been selected before (`selectedEdge` is set
+      // from exactly this function's return value, nowhere else) — a
+      // self-loop the user hand-writes into the markdown (the UI itself
+      // never creates one; `finishEdgeDrag` refuses a same-letter drag) would
+      // otherwise be permanently unselectable and undeletable by mouse. So a
+      // handle match is trusted when it is drawn (`handle.index ===
+      // selectedEdge`, as before) OR when the edge it names is a self-loop —
+      // a self-loop's handle is the one hit target it has, selected or not.
+      if (handle !== null) {
+        if (handle.index === selectedEdge) return handle.index;
+        const named = edges.filter(function (e) { return e.index === handle.index; })[0];
+        if (named !== undefined && named.edge.from === named.edge.to) return handle.index;
       }
-      try {
-        // `notFirstSignal` means "the skin is already on this page, do not
-        // emit it again". True whenever a WaveDrom render has already run here,
-        // which is always in the flow that reaches this editor — the entry
-        // affordance only appears over a RENDERED diagram. The fallback to
-        // `false` is for the page where it somehow has not: emitting the skin
-        // is only wasteful, while omitting one that is not there leaves every
-        // `<use>` unresolvable and the preview blank, which is the one state
-        // this panel may never be in.
-        // `socket` is a bare, global, un-namespaced id that the engine's own
-        // skin `<defs>` defines — so ask for it INSIDE a WaveDrom-rendered SVG's
-        // defs rather than anywhere on the page. A document carrying inline
-        // HTML with `id="socket"` would otherwise convince this that the skin is
-        // present on a page where no diagram had rendered, and the preview would
-        // come up blank: the one state this panel may never be in.
-        const skinOnPage = d.querySelector('svg.WaveDrom defs #socket') !== null;
-        engine.RenderWaveForm(PREVIEW_INDEX, plainCopy(doc, 0),
-          PREVIEW_ID_PREFIX, skinOnPage);
-        previewWrap.setAttribute('data-wave-preview', 'ok');
-        previewWrap.setAttribute('data-wave-preview-skin', skinOnPage ? 'shared' : 'own');
-      } catch (e) {
-        previewHost.textContent = 'WaveDrom 畫不出這份文件：' + String(e && e.message);
-        previewWrap.setAttribute('data-wave-preview', 'failed');
+      if (typeof d.elementFromPoint !== 'function') return null;
+      const el = d.elementFromPoint(ev.clientX, ev.clientY);
+      const hitPath = el !== null && el !== undefined && typeof el.closest === 'function'
+        ? el.closest('.ed-wave-edge-hit') : null;
+      if (hitPath === null || !canvas.contains(hitPath)) return null;
+      const idx = hitPath.getAttribute('data-edge-index');
+      return idx === null ? null : Number(idx);
+    }
+
+    /**
+     * The `.ed-wave-buslabel` mark under a press, or `null` — final review
+     * finding 4.
+     *
+     * NOT `ev.target`: `renderEdges` draws `.ed-wave-edge-hit` (invisible,
+     * `pointer-events: stroke`, 10px wide) AFTER every lane's own content, so
+     * whenever an edge's endpoint lands on a bus cell, that stroke paints ON
+     * TOP of the cell's own label mark — `ev.target` at that pixel is the
+     * edge-hit path, never the label underneath it, and no amount of
+     * reordering the CALLS in `onCanvasDown` changes that, because `ev.target`
+     * is the browser's own topmost-element answer, decided at dispatch time
+     * by paint order, not by which `if` this file happens to ask first.
+     * MEASURED against a real page: moving the bus-label check ahead of
+     * `edgeHitAt` while still reading `ev.target` left the label unreachable,
+     * identically to before.
+     *
+     * `document.elementsFromPoint` (plural — distinct from the singular
+     * `elementFromPoint` `edgeHitAt` above reads) answers a different
+     * question: the WHOLE stack of elements under the point, in z-order, not
+     * only the topmost one. Walking it for a `.ed-wave-buslabel` finds the
+     * mark even when something else is painted over it, which is exactly
+     * this finding's fix. The walk stops at `canvas` itself so a label-shaped
+     * class elsewhere in the document (outside the canvas this press is
+     * even inside) can never match.
+     *
+     * Falls back to the old `ev.target`-only check when `elementsFromPoint`
+     * is not available at all (older engines) — that keeps every OTHER bus
+     * label (the overwhelming majority, which do not sit under an edge's
+     * endpoint) working exactly as it always has; only the overlap case this
+     * finding is about stays unfixed on such an engine.
+     */
+    function busLabelHitAt(ev) {
+      function isLabel(el) {
+        return el !== null && el !== undefined && typeof el.classList === 'object' &&
+          el.classList !== null && el.classList.contains('ed-wave-buslabel');
       }
+      if (typeof d.elementsFromPoint === 'function') {
+        const stack = d.elementsFromPoint(ev.clientX, ev.clientY);
+        for (const el of stack) {
+          if (isLabel(el)) return el;
+          if (el === canvas) break;
+        }
+        return null;
+      }
+      return isLabel(ev.target) ? ev.target : null;
     }
 
     // Mounted BEFORE the first paint, not after: the preview is rendered by the
@@ -2101,8 +4020,24 @@
     render();
     // The opening line described a pointer and only a pointer, which is how a
     // surface ends up with no keyboard: the instructions never mentioned one.
-    say('選一個電位，然後在波形上按住拖過去；或直接按方向鍵進波形，' +
-      'Shift+左右鍵選一段，再按電位字元塗上去。');
+    //
+    // v3.6.0 Task 16 fix round 1 applies that same reasoning to this task's
+    // own gesture. Reordering a lane became keyboard-reachable here, and the
+    // only place that said so was a HOVER tooltip on the rail's drag handle
+    // — a `<span>` with deliberately no focus key, i.e. the one surface a
+    // keyboard user can never read. This is a one-shot line, not the
+    // per-move announcement `sayCursor` owns, so a hint belongs in it (see
+    // `sayCursor`'s own docstring for why the same hint may NOT go there).
+    //
+    // fix round 3 re-points the last clause. Round 1 wrote it as an EXCEPTION
+    // ("武裝關聯線之後，左右鍵改成在轉態點之間跳") because round 0's binding
+    // really did change what two keys this same sentence had just promised.
+    // Round 3 moved the jump to Alt+←/→, so the promise above holds in every
+    // state and the clause is now an extra key rather than a retraction.
+    panels.say('選一個電位，然後在波形上按住拖過去；或直接按方向鍵進波形，' +
+      'Shift+左右鍵選一段，再按電位字元塗上去。' +
+      'Alt+↑／Alt+↓ 把選取的 lane 往上下搬；' +
+      '武裝關聯線之後，Alt+左右鍵可以在轉態點之間跳。');
 
     return {
       el: overlay,
@@ -2115,10 +4050,9 @@
 
   return {
     createWaveEditor: createWaveEditor,
-    brickOf: brickOf,
-    groupSpansOf: groupSpansOf,
     mountedInsideContent: mountedInsideContent,
     BRUSHES: BRUSHES,
+    isBrushKey: isBrushKey,
     SIZES: SIZES,
   };
 });