@zombie-mermaid/ascii-renderer 2.2.6 → 3.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zombie-mermaid/ascii-renderer",
-  "version": "2.2.6",
+  "version": "3.0.0",
   "license": "MIT",
   "description": "ASCII and Unicode box-drawing renderer for zombie-mermaid diagrams.",
   "repository": {
@@ -35,7 +35,7 @@
     "LICENSE"
   ],
   "dependencies": {
-    "@zombie-mermaid/core": "2.2.6",
-    "@zombie-mermaid/mermaid-parser": "2.2.6"
+    "@zombie-mermaid/core": "3.0.0",
+    "@zombie-mermaid/mermaid-parser": "3.0.0"
   }
 }

package/src/__tests__/ascii-decision-lr-box-start.test.ts

@@ -14,7 +14,7 @@
  */
 import { describe, it, expect } from 'vitest'
 import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
-import { findOrphanedJunctions } from '../validate.ts'
+import { findOrphanedJunctions } from './validate.ts'
 import { readdirSync, readFileSync } from 'node:fs'
 import { join, dirname } from 'node:path'
 import { fileURLToPath } from 'node:url'

package/src/__tests__/ascii-er-attribute-column-order-1134.test.ts

@@ -0,0 +1,69 @@
+// ============================================================================
+// ASCII ER diagram: attribute columns render as type/name/keys (issue #1134)
+//
+// formatAttribute (src/ascii/er-diagram.ts) used to build "PK type name" —
+// keys, then type, then name — but real mermaid's SVG lays attribute
+// columns out left-to-right as type/name/keys (confirmed against the SVG's
+// attribute-type/attribute-name/attribute-keys x-coordinates in the
+// form-judge report on issue #1119). This file pins the corrected order.
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+describe('ASCII ER attribute columns render as type/name/keys (issue #1134)', () => {
+  it('renders a single-key attribute as "type name KEY", not "KEY type name"', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        ORDER {
+          int id PK
+        }`,
+      { colorMode: 'none' },
+    )
+    expect(ascii).toContain('int id PK')
+    expect(ascii).not.toContain('PK int id')
+  })
+
+  it('renders a multi-key attribute\'s keys joined and trailing, e.g. "type name PK,FK"', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        LINE_ITEM {
+          int product_id PK FK
+        }`,
+      { colorMode: 'none' },
+    )
+    expect(ascii).toContain('int product_id PK,FK')
+    expect(ascii).not.toContain('PK,FK int product_id')
+  })
+
+  it('renders a keyless attribute with no reserved key-column padding', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        CUSTOMER {
+          string name
+        }`,
+      { colorMode: 'none' },
+    )
+    // The pre-#1134 format always reserved a fixed-width 3-space key
+    // prefix ('   ') even when an attribute had no key at all — a keyless
+    // attribute now renders with nothing but its own type/name text, so
+    // the entity's box no longer wastes 3 columns it never needed.
+    expect(ascii).toContain('string name')
+    expect(ascii).not.toContain('   string name')
+  })
+
+  it('keeps a mix of keyed and keyless attributes readable in the same entity', () => {
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        CUSTOMER {
+          string name PK
+          string email UK
+          int age
+        }`,
+      { colorMode: 'none' },
+    )
+    expect(ascii).toContain('string name PK')
+    expect(ascii).toContain('string email UK')
+    expect(ascii).toContain('int age')
+  })
+})

package/src/__tests__/ascii-er-corner-glyphs.test.ts

@@ -57,17 +57,29 @@ describe('ASCII ER relationship routing draws a corner glyph at each turn (issue
     // the detour line, rather than inset into the detour's own row the
     // way the old inset positioning did. Checked separately below instead
     // of assuming they share a row.
-    expect(ascii).toContain('└─────────────── tracks ────────────┘')
+    //
+    // The detour line used to have "tracks" (MIDDLE_ENTITY--FIFTH_ENTITY's
+    // own label, a *different*, vertical relationship) embedded directly in
+    // its dashes, with no separator — the same label-lands-on-a-foreign-line
+    // defect issue #1119 fixes. "tracks" now relocates to its own row next
+    // to its own marker instead.
+    expect(ascii).toContain('└─────────────────│─────────────────┘')
     const lines = ascii.split('\n')
     const detourLineIndex = lines.findIndex((l) =>
-      l.includes('└─────────────── tracks ────────────┘'),
+      l.includes('└─────────────────│─────────────────┘'),
     )
     expect(detourLineIndex).toBeGreaterThan(0)
     // MIDDLE_ENTITY's "tracks" marker ('┼', flush against its own border)
     // sits on the row immediately above the detour line.
     expect(lines[detourLineIndex - 1]).toMatch(/┼/)
+    // "relates_to" (this detour's own label) sits on the row right below it.
+    expect(lines[detourLineIndex + 1]).toContain('relates_to')
     expect(ascii).toContain('relates_to')
     expect(ascii).toContain('tracks')
+    // "tracks" renders next to its own bottom marker ('○╟'), not spliced
+    // onto the unrelated detour line above.
+    const tracksLine = lines.find((l) => l.includes('tracks'))
+    expect(tracksLine).toContain('○╟')
     expect(ascii).not.toMatch(/[a-z]+[─│┊╌][a-z]+/)
   })
 
@@ -155,8 +167,19 @@ describe('ASCII ER relationship routing draws a corner glyph at each turn (issue
     // from a single shared-center bypass to two side-by-side ones; the
     // corner glyphs at the bypass's own turns are still there, just at the
     // updated column.
-    expect(ascii).toContain('┌─│──────────────────┘')
-    expect(ascii).toContain('○╟─────────────────┘')
+    //
+    // These two exact substrings shifted again with issue #1134's ER
+    // attribute-column reorder (type/name/keys instead of keys/type/name):
+    // A/D/G's boxes carry no keyed attributes here, so the old format's
+    // fixed-width key prefix ('   ' when absent) padded every attribute
+    // line by 3 unused columns; the reordered format only emits a key
+    // suffix when a key actually exists, so these now-narrower boxes shift
+    // the bypass's free-column search enough to change both jog rows'
+    // exact shape — each jog's two corners now land on the very same row
+    // (self-contained '┌'...'┘' runs) rather than sharing a row with a
+    // marker glyph the way the pre-#1134 geometry did.
+    expect(ascii).toContain('┌─────────────────────────┘')
+    expect(ascii).toContain('┌────────────────────┘')
     expect(ascii).toContain('ag')
   })
 

package/src/__tests__/ascii-er-relationship-label-corruption-350.test.ts

@@ -451,8 +451,18 @@ describe('ASCII ER relationship routing — multi-row obstruction (CodeRabbit fo
       (l, i) => l.includes('┌') && lines[i + 1]?.includes('│ D'),
     )
     expect(dTopIdx, 'expected to find D’s top-border row').toBeGreaterThan(-1)
-    const dTopLine = lines[dTopIdx]!
-    const afterDBox = dTopLine.slice(dTopLine.indexOf('┐') + 1)
-    expect(afterDBox).toMatch(/[│╢╟○]/)
+    // Issue #1134 reordered ER attribute columns to type/name/keys, dropping
+    // the old format's fixed-width key prefix ('   ' when an attribute had
+    // no key) that every one of A/D/G's keyless attribute lines used to pay
+    // for unconditionally. That narrows all three boxes here enough that the
+    // "ag" bypass no longer needs to jog laterally past D on D's own
+    // top-border row — it now clears D vertically, with its downward-turn
+    // marker landing in the gap row directly above D's box instead. That gap
+    // row is still unambiguously outside D's box (which starts at dTopIdx),
+    // so a connector/marker character there is the same proof as before:
+    // the line was actually routed around D, not silently guarded away
+    // inside it (setCGuarded would leave no trace at all in that case).
+    const gapLine = lines[dTopIdx - 1]!
+    expect(gapLine).toMatch(/[│╢╟○┌└]/)
   })
 })

package/src/__tests__/ascii-er-relationship-overwrite.test.ts

@@ -322,4 +322,111 @@ describe('ASCII ER relationship draws do not overwrite existing text (issue #392
     expect(row![idx - 1]).toBe(' ')
     expect(row![idx + 'authors'.length]).toBe(' ')
   })
+
+  it('renders the "includes" line solid at its crossing with "ships-via", not dashed (issue #1145)', () => {
+    // Real catalog sample ("ER: Mixed Identifying & Non-Identifying").
+    // PRODUCT--LINE_ITEM ("includes", solid — identifying) and
+    // ORDER--SHIPMENT ("ships-via", dashed — non-identifying, detoured
+    // beneath LINE_ITEM which sits between ORDER and SHIPMENT in the same
+    // row) route through the same cell: ships-via's horizontal detour fill
+    // crosses directly through includes' vertical stem just below
+    // LINE_ITEM. setCGuarded now refuses to let a dashed write land on an
+    // already-drawn solid glyph there, so "includes" renders solid at the
+    // crossing rather than picking up ships-via's dash.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        ORDER ||--|{ LINE_ITEM : contains
+        ORDER ||..o{ SHIPMENT : ships-via
+        PRODUCT ||--o{ LINE_ITEM : includes
+        PRODUCT ||..o{ REVIEW : receives`,
+      { colorMode: 'none' },
+    )
+
+    const lines = ascii.split('\n')
+    // ships-via's detour fill sits one row below LINE_ITEM's own
+    // zero-many marker ('╢○', for "includes") — anchoring on that marker
+    // (unambiguous: it's only ever drawn once, at LINE_ITEM's own bottom
+    // edge) rather than searching for a '└...┘' corner pair directly,
+    // since every entity box's own border also has solid corners and a
+    // naive substring search can match those instead (they're a different
+    // row, but a row can contain more than one corner pair).
+    const markerRowIdx = lines.findIndex((l) => l.includes('╢○'))
+    expect(markerRowIdx).toBeGreaterThanOrEqual(0)
+    const detourRow = lines[markerRowIdx + 1]!
+    const detourStart = detourRow.indexOf('└╌')
+    const detourEnd = detourRow.indexOf('╌┘') + 1
+    expect(detourStart).toBeGreaterThanOrEqual(0)
+
+    // includes' own vertical stem (solid '│') crosses this same row exactly
+    // once, between the detour's two corners — that crossing cell must
+    // read as solid, not dashed.
+    const crossingIdx = detourRow.indexOf('│', detourStart)
+    expect(crossingIdx).toBeGreaterThan(detourStart)
+    expect(crossingIdx).toBeLessThan(detourEnd)
+    expect(detourRow[crossingIdx]).toBe('│')
+
+    // And the fill on either side of that crossing is still ships-via's own
+    // dashed glyph — the fix only protects the one style-conflicting cell,
+    // it doesn't let the solid write bleed into its neighbors.
+    expect(detourRow[crossingIdx - 1]).toBe('╌')
+    expect(detourRow[crossingIdx + 1]).toBe('╌')
+  })
+
+  it('never lets a later-drawn dashed relationship line overwrite an earlier solid one at their crossing (issue #1145)', () => {
+    // Same geometry as the sample above (same entities, same connections,
+    // same declaration/draw order — contains, ships-via, includes,
+    // receives), but with which relationship is solid vs. dashed flipped:
+    // "ships-via" is now identifying (solid, "--") and "includes" is now
+    // non-identifying (dashed, ".."). `rel.identifying` only selects which
+    // glyph set a relationship draws with — it doesn't affect any routing
+    // decision (obstruction detection, jog-row search, detour placement) —
+    // so this renders with the exact same cell layout as the original
+    // sample, just with the two relationships' styles swapped. That makes
+    // it a clean, order-preserving way to flip *which* style the
+    // later-drawn relationship carries, without perturbing the routing
+    // itself the way reordering the relationships outright would.
+    //
+    // ships-via (now solid) is still drawn before includes (now dashed) —
+    // same relationship order as above — so before the fix, includes'
+    // later dashed write unconditionally overwrote ships-via's
+    // already-drawn solid detour fill at their crossing cell, opening a
+    // single-character dashed gap in an otherwise solid line: exactly the
+    // "solid stem ends up showing a dashed glyph, purely from draw order"
+    // defect the issue describes. The fix refuses that overwrite, so the
+    // detour fill must now be solid all the way across, with no dashed
+    // character breaking it.
+    const ascii = renderMermaidASCII(
+      `erDiagram
+        ORDER ||--|{ LINE_ITEM : contains
+        ORDER ||--o{ SHIPMENT : ships-via
+        PRODUCT ||..o{ LINE_ITEM : includes
+        PRODUCT ||..o{ REVIEW : receives`,
+      { colorMode: 'none' },
+    )
+
+    const lines = ascii.split('\n')
+    // Same anchor as the test above: ships-via's detour fill sits one row
+    // below LINE_ITEM's zero-many marker. Anchoring there (rather than
+    // searching for a '└...┘' pair directly) avoids a false match against
+    // an entity box's own solid border elsewhere in the render — with the
+    // fill itself now solid too (styles swapped for this test), a naive
+    // substring search matches ORDER's own box border instead of the
+    // detour row.
+    const markerRowIdx = lines.findIndex((l) => l.includes('╢○'))
+    expect(markerRowIdx).toBeGreaterThanOrEqual(0)
+    const detourRow = lines[markerRowIdx + 1]!
+    const detourStart = detourRow.indexOf('└─') // index of the '└' corner
+    const detourEnd = detourRow.indexOf('─┘') + 1 // index of the '┘' corner
+    expect(detourStart).toBeGreaterThanOrEqual(0)
+    // Everything strictly between the two corners.
+    const fill = detourRow.slice(detourStart + 1, detourEnd)
+
+    // No dashed glyph ('┊', includes' own now-dashed vertical stem's
+    // style) may appear anywhere inside the solid detour fill.
+    expect(fill).not.toContain('┊')
+    // And the fill is unbroken solid line across its whole span (not, say,
+    // silently dropped to a blank gap instead of dashed — the crossing
+    // cell must still carry a line glyph, just the solid one).
+    expect(fill).toBe('─'.repeat(fill.length))
+  })
 })

package/src/__tests__/ascii-er-stray-connectors.test.ts

@@ -200,10 +200,15 @@ describe('ASCII ER — relationships routed without colliding (issue #351)', ()
     // occupancy before choosing a jog row. Found by a differential search
     // over random small diagrams comparing the old (narrow) and fixed
     // (label-span-widened) occupancy ranges; this is the minimal case that
-    // reproduces it deterministically — DDDD--CCC's jog lands on a row
-    // that BB--A's own label already used, and without the widened check
-    // DDDD--CCC's own label ends up prefixed with a stray "│" bled through
-    // from BB--A's vertical stem.
+    // reproduces it deterministically — DDDD--CCC's jog used to land on the
+    // exact row BB--A's own label ("l1") already used, splicing the two
+    // together into one unbroken run ("l1longerlabelhere2") with no
+    // separator at all.
+    //
+    // Since #1119's fix (a label search also avoids a *different*
+    // relationship's own line, not just its own), DDDD--CCC's label
+    // relocates to its own row instead of sharing BB--A's — so the two
+    // no longer read as a single spliced word.
     const ascii = renderMermaidASCII(
       `erDiagram
         DDDD ||--o{ A : x0
@@ -211,14 +216,15 @@ describe('ASCII ER — relationships routed without colliding (issue #351)', ()
         DDDD ||--o{ CCC : longerlabelhere2`,
       { colorMode: 'none' },
     )
+    expect(ascii).toContain('longerlabelhere2')
+    expect(ascii).toContain('l1')
+    expect(ascii).not.toContain('l1longerlabelhere2')
     const lines = ascii.split('\n')
     const labelLine = lines.find((l) => l.includes('longerlabelhere2'))
     expect(labelLine).toBeDefined()
-    const idx = labelLine!.indexOf('longerlabelhere2')
-    // The characters immediately before the label must be plain fill dashes,
-    // not a stray "│" bled through from an unrelated relationship's
-    // vertical stem sharing this row.
-    expect(labelLine!.slice(Math.max(0, idx - 3), idx)).not.toContain('│')
+    // The label itself must render as one intact, uninterrupted word — not
+    // split by a stray line character routed through its middle.
+    expect(labelLine).not.toMatch(/longer[─│┊╌]/)
   })
 })
 

package/src/__tests__/ascii-sequence-activation.test.ts

@@ -0,0 +1,171 @@
+// ============================================================================
+// ASCII sequence diagrams — activation bars on lifelines (issue #1133)
+//
+// Mermaid overlays a highlighted rectangle on a lifeline while a participant
+// is actively processing a call, driven by standalone `activate`/`deactivate`
+// statements or the `+`/`-` arrow shorthand (`A->>+B` / `A-->>-B`). The
+// parser already models both forms (`SequenceDiagram.activations` and
+// `Message.activate`/`Message.deactivate` — see mermaid-parser's
+// sequence/types.ts) and the SVG renderer already draws the bars
+// (svg-renderer's sequence/layout.ts), but the ASCII renderer drew every
+// lifeline as a uniform `│` regardless of activation state.
+// ============================================================================
+
+import { describe, it, expect } from 'vitest'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+
+describe('ASCII sequence diagrams – activation bars (issue #1133)', () => {
+  it('draws a double-line glyph on the recipient lifeline for +/- shorthand activation', () => {
+    const result = renderMermaidASCII(
+      `
+sequenceDiagram
+  participant Client
+  participant Server
+  Client->>+Server: request
+  Server-->>-Client: response`,
+      { useAscii: false },
+    )
+
+    expect(result).toBe(
+      [
+        '┌────────┐    ┌────────┐   ',
+        '│ Client │    │ Server │   ',
+        '└────┬───┘    └────┬───┘   ',
+        '     │             │       ',
+        '     │   request   │       ',
+        '     │─────────────▶       ',
+        '     │             ║       ',
+        '     │  response   ║       ',
+        '     ◀╌╌╌╌╌╌╌╌╌╌╌╌╌║       ',
+        '     │             │       ',
+        '┌────┴───┐    ┌────┴───┐   ',
+        '│ Client │    │ Server │   ',
+        '└────────┘    └────────┘   ',
+      ].join('\n'),
+    )
+  })
+
+  it('uses the ASCII-fallback glyph (‖) in useAscii mode', () => {
+    const result = renderMermaidASCII(
+      `
+sequenceDiagram
+  participant Client
+  participant Server
+  Client->>+Server: request
+  Server-->>-Client: response`,
+      { useAscii: true },
+    )
+
+    const lines = result.split('\n')
+    expect(lines.some((l) => l.includes('‖'))).toBe(true)
+    expect(result).not.toContain('║')
+  })
+
+  it('draws the same bar for standalone activate/deactivate statements', () => {
+    const result = renderMermaidASCII(
+      `
+sequenceDiagram
+  participant A
+  participant B
+  A->>B: hello
+  activate B
+  B->>A: world
+  deactivate B`,
+      { useAscii: false },
+    )
+
+    expect(result).toBe(
+      [
+        ' ┌───┐      ┌───┐   ',
+        ' │ A │      │ B │   ',
+        ' └─┬─┘      └─┬─┘   ',
+        '   │          │     ',
+        '   │  hello   │     ',
+        '   │──────────▶     ',
+        '   │          ║     ',
+        '   │  world   ║     ',
+        '   ◀──────────║     ',
+        '   │          │     ',
+        ' ┌─┴─┐      ┌─┴─┐   ',
+        ' │ A │      │ B │   ',
+        ' └───┘      └───┘   ',
+      ].join('\n'),
+    )
+  })
+
+  it('keeps a nested self-activation active across the outer activation without a distinct nesting glyph', () => {
+    // B activates itself while already active (A->>+B, then B->>+B on the
+    // same actor): the lifeline stays marked active continuously from the
+    // outer activate through the outer deactivate, including the nested
+    // span — this renderer intentionally doesn't offset nested activations
+    // sideways the way the SVG renderer does (no spare column per lifeline
+    // without reflowing spacing), so nesting depth isn't visually distinct.
+    const result = renderMermaidASCII(
+      `
+sequenceDiagram
+  participant A
+  participant B
+  A->>+B: outer
+  B->>+B: inner
+  B-->>-B: inner done
+  B-->>-A: outer done`,
+      { useAscii: false },
+    )
+
+    expect(result).toBe(
+      [
+        ' ┌───┐           ┌───┐                 ',
+        ' │ A │           │ B │                 ',
+        ' └─┬─┘           └─┬─┘                 ',
+        '   │               │                   ',
+        '   │     outer     │                   ',
+        '   │───────────────▶                   ',
+        '   │               ║                   ',
+        '   │               ├───┐               ',
+        '   │               ║   │ inner         ',
+        '   │               ◀───┘               ',
+        '   │               ║                   ',
+        '   │               ├╌╌╌┐               ',
+        '   │               ║   │ inner done    ',
+        '   │               ◀╌╌╌┘               ',
+        '   │               ║                   ',
+        '   │  outer done   ║                   ',
+        '   ◀╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌║                   ',
+        '   │               │                   ',
+        ' ┌─┴─┐           ┌─┴─┐                 ',
+        ' │ A │           │ B │                 ',
+        ' └───┘           └───┘                 ',
+      ].join('\n'),
+    )
+  })
+
+  it('keeps an unbalanced activate (no matching deactivate) active through to the lifeline end', () => {
+    const result = renderMermaidASCII(
+      `
+sequenceDiagram
+  participant A
+  participant B
+  A->>+B: call
+  B->>A: reply`,
+      { useAscii: false },
+    )
+
+    expect(result).toBe(
+      [
+        ' ┌───┐      ┌───┐   ',
+        ' │ A │      │ B │   ',
+        ' └─┬─┘      └─┬─┘   ',
+        '   │          │     ',
+        '   │  call    │     ',
+        '   │──────────▶     ',
+        '   │          ║     ',
+        '   │  reply   ║     ',
+        '   ◀──────────║     ',
+        '   │          ║     ',
+        ' ┌─┴─┐      ┌─┴─┐   ',
+        ' │ A │      │ B │   ',
+        ' └───┘      └───┘   ',
+      ].join('\n'),
+    )
+  })
+})

package/src/__tests__/ascii-shape-diamond.test.ts

@@ -1,5 +1,5 @@
 import { describe, it, expect } from 'vitest'
-import { diamondRenderer } from '../shapes/diamond.ts'
+import { diamondRenderer } from '../shapes/index.ts'
 import { canvasToString } from '../canvas.ts'
 import type { ShapeRenderOptions } from '../shapes/types.ts'
 

package/src/__tests__/ascii-shape-rounded.test.ts

@@ -1,5 +1,5 @@
 import { describe, it, expect } from 'vitest'
-import { roundedRenderer } from '../shapes/rounded.ts'
+import { roundedRenderer } from '../shapes/index.ts'
 import { canvasToString } from '../canvas.ts'
 import type { ShapeRenderOptions } from '../shapes/types.ts'
 

package/src/__tests__/ascii-shapes-circle.test.ts

@@ -1,5 +1,5 @@
 import { describe, it, expect } from 'vitest'
-import { circleRenderer } from '../shapes/circle.ts'
+import { circleRenderer } from '../shapes/index.ts'
 import { canvasToString } from '../canvas.ts'
 import type { ShapeRenderOptions } from '../shapes/types.ts'
 

package/src/__tests__/ascii-shapes-hexagon.test.ts

@@ -1,5 +1,5 @@
 import { describe, it, expect } from 'vitest'
-import { hexagonRenderer } from '../shapes/hexagon.ts'
+import { hexagonRenderer } from '../shapes/index.ts'
 import { canvasToString } from '../canvas.ts'
 import type { ShapeRenderOptions } from '../shapes/types.ts'
 

package/src/__tests__/ascii-shapes-special.test.ts

@@ -150,6 +150,41 @@ describe('cylinder shape [(text)]', () => {
     expect(out).toMatch(/'-+'/)
   })
 
+  it('draws a rim line distinguishing it from a plain rounded node (issue #1119)', () => {
+    // The actual flowchart drawing path (drawNode -> drawBoxWithGridDimensions
+    // in draw-boxes.ts) draws every node shape as a plain bordered rectangle
+    // with shape-specific corner glyphs — it never calls cylinderRenderer
+    // (exercised only in isolation, above), and cylinder's corners are
+    // identical to rounded's own (see corners.ts's SHAPE_CORNERS), so a
+    // cylinder rendered in a real flowchart used to be indistinguishable
+    // from a rounded node — a weekly form-judge audit flagged this exact
+    // regression (#1119). drawBoxWithGridDimensions now draws a rim line
+    // just inside the top and bottom border for 'cylinder' specifically,
+    // using the extra height getShapeDimensions already reserves for it.
+    const src = `flowchart TD
+  A(Rounded)
+  B[(Database)]`
+    const out = renderMermaidASCII(src, { useAscii: false })
+    const lines = out.split('\n')
+    const topBorderLineIdx = lines.findIndex((l) => l.includes('╭'))
+    const topBorderLine = lines[topBorderLineIdx]!
+    const roundedX = topBorderLine.indexOf('╭')
+    const roundedEndX = topBorderLine.indexOf('╮', roundedX)
+    const databaseX = topBorderLine.indexOf('╭', roundedX + 1)
+    const databaseEndX = topBorderLine.indexOf('╮', databaseX)
+    expect(roundedX).toBeGreaterThanOrEqual(0)
+    expect(databaseX).toBeGreaterThan(roundedEndX)
+
+    // Row just inside the top border: Rounded's own interior span is blank
+    // (no rim); Database's is a solid rule between its vertical borders.
+    const rimRow = lines[topBorderLineIdx + 1]!
+    const roundedRimSpan = rimRow.slice(roundedX + 1, roundedEndX)
+    expect(roundedRimSpan.trim()).toBe('')
+    const databaseRimSpan = rimRow.slice(databaseX + 1, databaseEndX)
+    expect(databaseRimSpan.length).toBeGreaterThan(0)
+    expect(databaseRimSpan).toMatch(/^─+$/)
+  })
+
   it('computes extra height for the curved top/bottom rows', () => {
     const dims = cylinderRenderer.getDimensions('DB', unicodeOpts)
     expect(dims.gridRows[0]).toBe(2)

package/src/__tests__/ascii-validate.test.ts

@@ -8,10 +8,8 @@ import {
   DIAGONAL_CHARS,
   hasDiagonalLines,
   findDiagonalLines,
-  assertNoDiagonals,
   findOrphanedJunctions,
-  hasOrphanedJunctions,
-} from '../validate.ts'
+} from './validate.ts'
 
 describe('DIAGONAL_CHARS', () => {
   it('exposes ascii, unicode, and combined character sets', () => {
@@ -90,35 +88,6 @@ describe('findDiagonalLines', () => {
   })
 })
 
-describe('assertNoDiagonals', () => {
-  it('does not throw when there are no diagonals', () => {
-    expect(() => assertNoDiagonals('┌───┐\n│ A │\n└───┘')).not.toThrow()
-  })
-
-  it('throws with position details when diagonals are found', () => {
-    expect(() => assertNoDiagonals('a / b')).toThrow(
-      /Diagonal lines detected\. .*Found 1 diagonal character\(s\):\n\s*Line 1, Col 3: '\/'/s,
-    )
-  })
-
-  it('includes the context string in the error message when provided', () => {
-    expect(() => assertNoDiagonals('a / b', 'my-diagram')).toThrow(
-      /Diagonal lines detected in "my-diagram"\./,
-    )
-  })
-
-  it('omits the context clause when no context is provided', () => {
-    try {
-      assertNoDiagonals('a / b')
-      throw new Error('expected assertNoDiagonals to throw')
-    } catch (err) {
-      const message = err instanceof Error ? err.message : String(err)
-      expect(message).toContain('Diagonal lines detected. ')
-      expect(message).not.toContain(' in "')
-    }
-  })
-})
-
 describe('findOrphanedJunctions', () => {
   it('returns an empty array when there are no junction characters', () => {
     expect(findOrphanedJunctions('┌───┐\n│ A │\n└───┘')).toEqual([])
@@ -208,13 +177,3 @@ describe('findOrphanedJunctions', () => {
     ])
   })
 })
-
-describe('hasOrphanedJunctions', () => {
-  it('returns false when there are no orphaned junctions', () => {
-    expect(hasOrphanedJunctions('┌───┐\n│ A │\n└───┘')).toBe(false)
-  })
-
-  it('returns true when at least one orphaned junction is found', () => {
-    expect(hasOrphanedJunctions(' ┬ ')).toBe(true)
-  })
-})

package/src/__tests__/ascii.test.ts

@@ -9,7 +9,7 @@
  */
 import { describe, it, expect } from 'vitest'
 import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
-import { hasDiagonalLines, DIAGONAL_CHARS } from '../validate.ts'
+import { hasDiagonalLines, DIAGONAL_CHARS } from './validate.ts'
 import { readdirSync, readFileSync } from 'node:fs'
 import { join, dirname } from 'node:path'
 import { fileURLToPath } from 'node:url'