@zombie-mermaid/ascii-renderer 2.2.1

package/src/__tests__/ascii-er-unrelated-stem-separation-411.test.ts

@@ -0,0 +1,98 @@
+// ============================================================================
+// ASCII ER diagram regression test for issue #411:
+//
+// Two *unrelated* relationships' vertical stems can land on adjacent (not
+// identical) columns purely by coincidence — when that happens, nothing in
+// the rendered output distinguishes them, so a reader sees what looks like
+// one connector that inexplicably bends sideways partway down, rather than
+// two independent lines. This is different from #350 (content overwrite,
+// already fixed) and #351 (routing collisions/gutters, already fixed): no
+// character is ever corrupted here, the two stems just sit close enough to
+// be mistaken for each other.
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+describe('ASCII ER — unrelated relationship stems stay visually separated (issue #411)', () => {
+  it('keeps CUSTOMER→ADDRESS and PRODUCT→LINE_ITEM stems at least one column apart', () => {
+    // The exact repro from issue #411: CUSTOMER's own stem (toward ADDRESS)
+    // and PRODUCT/LINE_ITEM's own stem land on entity-center columns that
+    // are only 1 apart by coincidence (12-wide CUSTOMER vs. 11-wide
+    // PRODUCT, both starting at column 0 in their own row) — before the
+    // fix, that put a bare '│' from one relationship immediately beside a
+    // '┌'/'┼' from the other, with no blank column between them:
+    //
+    //   ┼                                     ╢○
+    //  ┌│appears_in ───── has ─────────────────┘
+    //  │└───────────────┐
+    //  ┼               ○╟
+    //
+    // ("appears_in" is PRODUCT→LINE_ITEM's own label; "has" is
+    // CUSTOMER→ADDRESS's own label — the two relationships have nothing to
+    // do with each other, so their stems must read as visually distinct.)
+    const ascii = renderMermaidASCII(
+      `erDiagram
+    CUSTOMER ||--o{ ORDER : places
+    ORDER ||--|{ LINE_ITEM : contains
+    PRODUCT ||--o{ LINE_ITEM : appears_in
+    CUSTOMER ||--o{ ADDRESS : has`,
+      { colorMode: 'none' },
+    )
+
+    // The pre-fix signature: PRODUCT/LINE_ITEM's corner immediately
+    // followed, with no gap, by CUSTOMER/ADDRESS's vertical stem.
+    expect(ascii).not.toContain('┌│appears_in')
+    expect(ascii).not.toContain('│└───────────────┐')
+
+    // A blank column now separates the two relationships' stems on every
+    // row where both are present.
+    expect(ascii).toContain('┌ appears_in')
+    expect(ascii).toContain('│ │ has')
+    expect(ascii).toContain('┼ └')
+  })
+
+  it('does not corrupt a corner glyph when escalating a jog to avoid an unrelated stem (issue #411 fix side effect)', () => {
+    // A denser diagram where two different vertical relationships'
+    // natural columns land close enough to trigger the #411 separation
+    // logic on both sides. Before a follow-up fix, the escalation could
+    // pick a "via" column identical to another relationship's own column,
+    // silently overwriting its corner glyph with a plain vertical bar.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+  STUDENT {
+    int id PK
+    string name
+    date dob
+    string grade
+  }
+  TEACHER {
+    int id PK
+    string name
+    string department
+  }
+  COURSE {
+    int id PK
+    string title
+    int teacher_id FK
+    int credits
+  }
+  ENROLLMENT {
+    int id PK
+    int student_id FK
+    int course_id FK
+    string semester
+    float grade
+  }
+  TEACHER ||--o{ COURSE : teaches
+  STUDENT ||--o{ ENROLLMENT : enrolled
+  COURSE ||--o{ ENROLLMENT : has`,
+      { colorMode: 'none' },
+    )
+
+    // TEACHER→COURSE's own corner, where its jog turns down into COURSE,
+    // must survive intact rather than being overwritten by
+    // STUDENT→ENROLLMENT's bypass column landing on the same cell.
+    expect(ascii).toContain('┌ teaches')
+  })
+})

package/src/__tests__/ascii-er-vertical-one-marker.test.ts

@@ -0,0 +1,110 @@
+// ============================================================================
+// ASCII ER diagram: a vertical relationship's "one" (`||`) cardinality
+// marker was completely invisible when it sat on the upper or lower entity.
+//
+// getCrowsFootChars() was written for horizontal use, where a '│'/'|' tick
+// is perpendicular to the horizontal line ('─'/'-') it crosses — that reads
+// correctly. The same function was reused verbatim for vertical markers,
+// where a '│'/'|' tick is instead *parallel* to the vertical connecting
+// line ('│'/'|'), so for "one" cardinality specifically the marker glyph
+// and the line-fill glyph were identical: drawing the marker produced no
+// visible change at all, not just a subtle one.
+//
+// The fix adds a `vertical` parameter to getCrowsFootChars, used only for
+// the 'one' case, so a vertical "one" marker renders as '┼'/'+' (crossing
+// the vertical line) instead of '│'/'|' (blending into it). 'zero-one',
+// 'many', and 'zero-many' are untouched — they already render distinctly
+// on the vertical axis.
+//
+// An earlier version of this fix used a bare '─'/'-' for the marker. That
+// made it visible, but a bare dash has no vertical extent, so it read as a
+// gap severing the line rather than a tick crossing it (the vertical line
+// stops at the row above the marker and resumes at the row below, with
+// nothing connecting through the marker's own cell). '┼'/'+' carry both
+// strokes, so the line reads as continuous with a crossing tick — the same
+// way '│'/'|' crosses the horizontal line in the non-vertical case.
+//
+// Found while reviewing PR #439's vertical-relationship example.
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+describe('ASCII ER vertical "one" cardinality marker (invisible-marker fix)', () => {
+  it('renders a distinct tick for the upper entity\'s "one" marker, not the invisible line glyph', () => {
+    // A connects to both B (horizontal) and C (vertical, forced by the
+    // 3-entity sqrt-based row layout) — the exact repro that surfaced the
+    // bug. Before the fix, A's vertical "one" marker toward C rendered as
+    // '│', identical to the plain connecting-line fill character, so
+    // nothing distinguished "here is A's cardinality marker" from "just
+    // more line".
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        A ||--o{ B : ab
+        A ||--o{ C : ac`,
+      { colorMode: 'none' },
+    )
+    const lines = ascii.split('\n')
+    // The marker sits flush against A's own border (#390's flush-marker
+    // change — merged after this test was first written, which shifted
+    // the vertical label off the marker's own row; the label's position
+    // is a separate geometric-midpoint calculation, not anchored to the
+    // marker — see the row-by-row check below instead of assuming they
+    // share a line).
+    const markerLineIndex = lines.findIndex((l) => /^\s*┼\s*$/.test(l))
+    expect(markerLineIndex).toBeGreaterThanOrEqual(0)
+    expect(lines[markerLineIndex - 1]).toContain('└───┘')
+
+    // The marker's own line must not be a lone '│' (the pre-fix, invisible
+    // rendering) or a bare '─' (an earlier fix attempt, which visually
+    // severs the line — see the header comment above).
+    expect(lines[markerLineIndex]).not.toMatch(/^\s*[│─]\s*$/)
+
+    // The line continues unbroken below the marker, through the label row.
+    expect(lines[markerLineIndex + 1]).toContain('│ ac')
+  })
+
+  it('renders distinct ticks at both ends when both entities have "one" cardinality', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        A ||--o{ B : ab
+        A ||--|| C : ac`,
+      { colorMode: 'none' },
+    )
+    // Two separate '┼' marker ticks: one at A's lower edge, one at C's
+    // upper edge, both distinct from the '│' line around them.
+    const lines = ascii.split('\n')
+    const tickLineIndexes = lines
+      .map((l, i) => (/^\s*┼\s*$/.test(l) ? i : -1))
+      .filter((i) => i >= 0)
+    expect(tickLineIndexes.length).toBe(2)
+    const [upperTick, lowerTick] = tickLineIndexes as [number, number]
+    // Upper tick flush against A's border, lower tick flush against C's
+    // (#390's flush-marker change), with the connecting line still
+    // reading as continuous — every row between the two ticks starts with
+    // the plain '│' line-fill character.
+    expect(lines[upperTick - 1]).toContain('└───┘')
+    expect(lines[lowerTick + 1]).toContain('┌───┐')
+    for (let i = upperTick + 1; i < lowerTick; i++) {
+      expect(lines[i]).toMatch(/^\s*│/)
+    }
+  })
+
+  it('renders the ASCII-mode equivalent ("+" instead of "|") for the vertical "one" marker', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        A ||--o{ B : ab
+        A ||--o{ C : ac`,
+      { colorMode: 'none', useAscii: true },
+    )
+    const lines = ascii.split('\n')
+    const markerLineIndex = lines.findIndex((l) => /^\s*\+\s*$/.test(l))
+    expect(markerLineIndex).toBeGreaterThanOrEqual(0)
+    expect(lines[markerLineIndex - 1]).toContain('+---+')
+    // The pre-fix invisible rendering used a lone '|' on the marker line;
+    // an earlier fix attempt used a bare '-', which visually severs the
+    // line (no vertical extent) — see the header comment above.
+    expect(lines[markerLineIndex]).not.toMatch(/^\s*[|-]\s*$/)
+    expect(lines[markerLineIndex + 1]).toContain('| ac')
+  })
+})

package/src/__tests__/ascii-label-line-terminal-fallback.test.ts

@@ -0,0 +1,168 @@
+/**
+ * Regression/coverage test for the deepest fallback tier of
+ * `determineLabelLine` (src/ascii/edge-routing.ts) — the one that runs when
+ * *no* segment is both wide enough for the label and clear of nodes, so it
+ * falls back to `clearLaterSegments` (non-terminal segments clear of
+ * nodes), then `clearSegments` (any segment clear of nodes, terminal or
+ * not), then finally every segment regardless.
+ *
+ * Exercises two branches #450's fix introduced that the rest of the suite
+ * never reaches on their own:
+ *
+ *  - A non-terminal segment (touching neither the source's nor the
+ *    target's own border) that still fails `clearOfNodes` because its
+ *    interior runs through an unrelated node's block — so
+ *    `!isTerminalSegment(s) && clearOfNodes(s.line)` evaluates the right
+ *    operand and gets `false` from it, rather than short-circuiting on a
+ *    terminal segment (the only case the rest of the suite happens to hit).
+ *  - `clearLaterSegments` ending up non-empty, so the ternary at
+ *    `determineLabelLine` uses it directly instead of falling through to
+ *    `clearSegments`.
+ *
+ * The two terminal segments are deliberately given a *larger* combined
+ * column width than the middle (non-terminal) one, all still under the
+ * label's length. This matters for the second test below: with the
+ * terminal exclusion removed (the mutation a sabotage check should catch),
+ * `clearLaterSegments` would include the terminal segments too, and being
+ * wider they'd win the width-descending sort — silently picking a
+ * box-border-adjacent segment instead of the safe middle one, the exact
+ * class of bug #450 was filed against. Equal widths would let the middle
+ * segment win the tie-break by filter order alone, masking that mutation.
+ *
+ * Constructed directly against `determineLabelLine` (bypassing the parser
+ * and full grid layout, following the same pattern as
+ * ascii-edge-routing-single-point-path.test.ts) so the exact segment/label
+ * widths and the blocked cell can be pinned precisely, rather than hoping
+ * some real diagram happens to hit this deep a fallback tier.
+ */
+import { describe, it, expect } from 'vitest'
+import { determineLabelLine } from '../edge-routing.ts'
+import { Down, gridKey } from '../types.ts'
+import type { AsciiEdge, AsciiGraph, AsciiNode } from '../types.ts'
+import { createGrid } from '../grid-occupancy.ts'
+
+function makeNode(name: string, x: number, y: number): AsciiNode {
+  return {
+    name,
+    displayLabel: name,
+    shape: 'rectangle',
+    index: 0,
+    gridCoord: { x, y },
+    drawingCoord: null,
+    drawing: null,
+    drawn: false,
+    styleClassName: '',
+    styleClass: { name: '', styles: {} },
+  }
+}
+
+function makeGraph(nodes: AsciiNode[]): AsciiGraph {
+  return {
+    nodes,
+    edges: [],
+    canvas: [],
+    roleCanvas: [],
+    grid: createGrid(),
+    columnWidth: new Map(),
+    rowHeight: new Map(),
+    subgraphs: [],
+    config: {
+      useAscii: false,
+      paddingX: 5,
+      paddingY: 5,
+      boxBorderPadding: 1,
+      graphDirection: 'TD',
+    },
+    offsetX: 0,
+    offsetY: 0,
+    bundles: [],
+  }
+}
+
+/**
+ * Shared path/width setup for both tests: a 3-segment path (0,0)-(2,0)-
+ * (5,0)-(8,0), where segment 1 (index 1, x=0..2, touching the source) and
+ * segment 3 (index 3, x=5..8, touching the target) are terminal, and
+ * segment 2 (index 2, x=2..5) is the only non-terminal one.
+ *
+ * Columns 0,1,2,5,6,7,8 are set to width 10 (terminal segments 1 and 3
+ * total 30 and 40 respectively); columns 3,4 stay at width 1 (segment 2
+ * totals 22, via its shared boundary columns 2 and 5). All three stay
+ * under the 60-character label below, so the primary and "any suitable
+ * segment" tiers both fail on width alone regardless of clearOfNodes.
+ */
+function makeAsymmetricWidthGraph(): { graph: AsciiGraph; edge: AsciiEdge } {
+  const from = makeNode('A', 0, 0)
+  const to = makeNode('B', 8, 0)
+  const graph = makeGraph([from, to])
+
+  for (const x of [0, 1, 2, 5, 6, 7, 8]) graph.columnWidth.set(x, 10)
+  for (const x of [3, 4]) graph.columnWidth.set(x, 1)
+
+  const edge: AsciiEdge = {
+    from,
+    to,
+    // 60 characters: wider than every segment's combined width above
+    // (the widest, segment 3, totals 40).
+    text: 'this label is deliberately far too long to ever possibly fit',
+    path: [
+      { x: 0, y: 0 },
+      { x: 2, y: 0 },
+      { x: 5, y: 0 },
+      { x: 8, y: 0 },
+    ],
+    labelLine: [],
+    startDir: Down,
+    endDir: Down,
+    style: 'solid',
+    hasArrowStart: false,
+    hasArrowEnd: true,
+  }
+
+  return { graph, edge }
+}
+
+describe('determineLabelLine terminal-segment-exclusion fallback tiers', () => {
+  it('falls back to clearSegments when the only non-terminal segment is blocked by an unrelated node', () => {
+    const { graph, edge } = makeAsymmetricWidthGraph()
+
+    // Block the middle (non-terminal) segment's sole interior cell with an
+    // unrelated node's occupied cell, so clearOfNodes reports it blocked —
+    // the only non-terminal segment available is then unusable, leaving
+    // clearLaterSegments empty and forcing the fallback to clearSegments
+    // (any segment clear of nodes, terminal or not).
+    graph.grid.add(gridKey({ x: 3, y: 0 }))
+    // A cell wedged between the two edge nodes stands in for that
+    // unrelated node's own footprint (not registered as a real AsciiNode —
+    // clearOfNodes only consults grid occupancy, not node identity).
+
+    expect(() => determineLabelLine(graph, edge)).not.toThrow()
+
+    // Falls back to a terminal segment (clearSegments), not the blocked
+    // middle one — confirms the cascade actually walked past the empty
+    // clearLaterSegments tier instead of using the blocked segment anyway.
+    const [p1, p2] = edge.labelLine
+    expect(p1).toBeDefined()
+    expect(p2).toBeDefined()
+    const usedMiddleSegment =
+      (p1!.x === 2 && p2!.x === 5) || (p1!.x === 5 && p2!.x === 2)
+    expect(usedMiddleSegment).toBe(false)
+  })
+
+  it('uses the non-terminal segment via clearLaterSegments even though the terminal segments are wider', () => {
+    const { graph, edge } = makeAsymmetricWidthGraph()
+
+    // Unlike the previous test, nothing blocks the middle (non-terminal)
+    // segment's interior this time, so clearLaterSegments ends up with
+    // exactly that one segment. The terminal segments are wider (30/40 vs
+    // 22) and would win a width-descending sort if they weren't excluded —
+    // this is what actually catches a mutation that drops the terminal
+    // exclusion from clearLaterSegments's filter (see this file's header).
+    expect(() => determineLabelLine(graph, edge)).not.toThrow()
+
+    const [p1, p2] = edge.labelLine
+    const usedMiddleSegment =
+      (p1!.x === 2 && p2!.x === 5) || (p1!.x === 5 && p2!.x === 2)
+    expect(usedMiddleSegment).toBe(true)
+  })
+})

package/src/__tests__/ascii-lane-search.test.ts

@@ -0,0 +1,207 @@
+// `findFreeLane` (src/ascii/lane-search.ts) is the search algorithm that
+// `er-diagram.ts`'s `chooseFreeRow` and `class-diagram.ts`'s
+// `findClearColumn` independently grew, extracted in issue #617.
+//
+// Two kinds of test here:
+//
+//  1. Direct unit tests pinning the contract — search order, inclusive
+//     bounds, the deliberately unbounded `preferred` probe, and the
+//     `undefined` return that each caller turns into its own fallback.
+//  2. Differential tests against verbatim copies of *both* pre-extraction
+//     loops, over randomized occupancy. The extraction's acceptance bar is
+//     byte-identical rendered output, and the rendered sample suite alone
+//     doesn't reach every branch of either original search — so the
+//     originals are kept here as reference implementations and the shared
+//     function is required to agree with them on every generated input.
+import { describe, it, expect } from 'vitest'
+import { findFreeLane } from '../lane-search.ts'
+
+describe('findFreeLane', () => {
+  it('returns the preferred lane when it is free', () => {
+    expect(findFreeLane(5, 0, 10, () => true)).toBe(5)
+  })
+
+  it('probes the preferred lane exactly once, before any bounds apply', () => {
+    const probed: number[] = []
+    // `preferred` sits outside [min, max] and is still tested — the ER
+    // caller depends on this for a gap too narrow to hold a candidate.
+    const result = findFreeLane(3, 10, 20, (c) => {
+      probed.push(c)
+      return c === 3
+    })
+    expect(result).toBe(3)
+    expect(probed).toEqual([3])
+  })
+
+  it('scans forward before backward at each distance', () => {
+    const probed: number[] = []
+    findFreeLane(5, 0, 10, (c) => {
+      probed.push(c)
+      return false
+    })
+    expect(probed.slice(0, 7)).toEqual([5, 6, 4, 7, 3, 8, 2])
+  })
+
+  it('prefers the nearer free lane, forward winning a tie', () => {
+    // Both 4 and 6 are free and equidistant from 5.
+    expect(findFreeLane(5, 0, 10, (c) => c === 4 || c === 6)).toBe(6)
+    // Backward-only: 4 is free, 6 is not.
+    expect(findFreeLane(5, 0, 10, (c) => c === 4)).toBe(4)
+    // A nearer backward lane beats a further forward one.
+    expect(findFreeLane(5, 0, 10, (c) => c === 3 || c === 9)).toBe(3)
+  })
+
+  it('treats min and max as inclusive bounds on outward candidates', () => {
+    expect(findFreeLane(5, 0, 7, (c) => c === 7)).toBe(7)
+    expect(findFreeLane(5, 0, 6, (c) => c === 7)).toBeUndefined()
+    expect(findFreeLane(5, 2, 10, (c) => c === 2)).toBe(2)
+    expect(findFreeLane(5, 3, 10, (c) => c === 2)).toBeUndefined()
+  })
+
+  it('never calls the occupancy check on an out-of-range candidate', () => {
+    const probed: number[] = []
+    findFreeLane(5, 4, 6, (c) => {
+      probed.push(c)
+      return false
+    })
+    expect(probed).toEqual([5, 6, 4])
+  })
+
+  it('returns undefined when nothing in range is free', () => {
+    expect(findFreeLane(5, 0, 10, () => false)).toBeUndefined()
+  })
+
+  it('returns undefined when the bounds leave no candidates at all', () => {
+    // min > max — ER's narrow-gap case, where only `preferred` is probed.
+    const probed: number[] = []
+    const result = findFreeLane(5, 6, 4, (c) => {
+      probed.push(c)
+      return false
+    })
+    expect(result).toBeUndefined()
+    expect(probed).toEqual([5])
+  })
+
+  it('searches far enough to reach whichever bound is further away', () => {
+    expect(findFreeLane(5, 0, 100, (c) => c === 100)).toBe(100)
+    expect(findFreeLane(95, 0, 100, (c) => c === 0)).toBe(0)
+  })
+})
+
+// --- Differential tests against the pre-extraction implementations -------
+
+/**
+ * Deterministic 32-bit LCG. A fixed seed keeps a failure reproducible;
+ * `Math.random` would make one impossible to re-run.
+ */
+function makeRng(seed: number): () => number {
+  let state = seed >>> 0
+  return () => {
+    state = (Math.imul(state, 1664525) + 1013904223) >>> 0
+    return state / 0x100000000
+  }
+}
+
+/** `chooseFreeRow`'s search loop, copied verbatim from before #617. */
+function legacyChooseRow(
+  startY: number,
+  endY: number,
+  isRowFree: (y: number) => boolean,
+): number {
+  const preferred = Math.floor((startY + endY) / 2)
+  if (isRowFree(preferred)) return preferred
+
+  const maxOffset = endY - startY
+  for (let d = 1; d <= maxOffset; d++) {
+    const below = preferred + d
+    if (below < endY && isRowFree(below)) return below
+    const above = preferred - d
+    if (above > startY && isRowFree(above)) return above
+  }
+  return preferred
+}
+
+/** `findClearColumn`'s search loop, copied verbatim from before #617. */
+function legacyClearColumn(
+  startX: number,
+  totalW: number,
+  isColumnClear: (x: number) => boolean,
+): number {
+  if (isColumnClear(startX)) return startX
+
+  for (let offset = 1; offset < totalW + 10; offset++) {
+    const rightX = startX + offset
+    if (isColumnClear(rightX)) return rightX
+    const leftX = startX - offset
+    if (leftX >= 0 && isColumnClear(leftX)) return leftX
+  }
+
+  return totalW + 2
+}
+
+describe('findFreeLane matches the implementations it replaced', () => {
+  it("reproduces chooseFreeRow's row search on randomized occupancy", () => {
+    const rng = makeRng(0x5eed_617)
+    for (let trial = 0; trial < 2000; trial++) {
+      const startY = Math.floor(rng() * 20)
+      const endY = startY + Math.floor(rng() * 20)
+      // Density spans "almost everything free" to "almost nothing free" so
+      // both the hit and the exhausted-fallback paths get exercised.
+      const density = rng()
+      const occupied = new Set<number>()
+      for (let y = startY - 5; y <= endY + 5; y++) {
+        if (rng() < density) occupied.add(y)
+      }
+      const isRowFree = (y: number): boolean => !occupied.has(y)
+
+      const preferred = Math.floor((startY + endY) / 2)
+      const extracted =
+        findFreeLane(preferred, startY + 1, endY - 1, isRowFree) ?? preferred
+
+      expect({ startY, endY, chosen: extracted }).toEqual({
+        startY,
+        endY,
+        chosen: legacyChooseRow(startY, endY, isRowFree),
+      })
+    }
+  })
+
+  it("reproduces findClearColumn's column search on randomized occupancy", () => {
+    const rng = makeRng(0xc01_5e5)
+    for (let trial = 0; trial < 2000; trial++) {
+      const totalW = 4 + Math.floor(rng() * 40)
+      const startX = Math.floor(rng() * totalW)
+      const density = rng()
+      // Only columns within the canvas can be blocked by a box — past the
+      // widest box every column is clear, which is why the original's
+      // `totalW + 2` fallback was unreachable in practice.
+      const blocked = new Set<number>()
+      for (let x = 0; x < totalW; x++) {
+        if (rng() < density) blocked.add(x)
+      }
+      const isColumnClear = (x: number): boolean => !blocked.has(x)
+
+      const extracted =
+        findFreeLane(startX, 0, startX + totalW + 9, isColumnClear) ??
+        totalW + 2
+
+      expect({ totalW, startX, chosen: extracted }).toEqual({
+        totalW,
+        startX,
+        chosen: legacyClearColumn(startX, totalW, isColumnClear),
+      })
+    }
+  })
+
+  it("reproduces findClearColumn's fallback when every column is blocked", () => {
+    // Not reachable through the real renderer (a column past the widest box
+    // is always clear), but the fallback is still wired up — so pin the
+    // agreement rather than leaving the branch untested.
+    const totalW = 12
+    const startX = 3
+    const neverClear = (): boolean => false
+    expect(
+      findFreeLane(startX, 0, startX + totalW + 9, neverClear) ?? totalW + 2,
+    ).toBe(legacyClearColumn(startX, totalW, neverClear))
+  })
+})