zombie-mermaid 2.2.1 → 2.2.2

package/packages/mcp/LICENSE

@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2026 Craft Docs
+Copyright (c) 2026 Dustin Fadler
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/{src/mcp → packages/mcp/src}/server.ts

@@ -5,11 +5,12 @@
 // mechanical sequence-diagram semantic check, up as Model Context Protocol
 // tools. No rendering or checking logic lives here — see src/mcp/tools/*.ts
 // for the thin per-tool adapters, src/index.ts / src/ascii/index.ts for the
-// actual renderers, and src/sequence/activation-check.ts for the check.
+// actual renderers, and packages/mermaid-parser/src/sequence/activation-check.ts
+// for the check.
 // ============================================================================
 
 import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
-import { getPackageVersion } from '../package-info.ts'
+import { getPackageVersion } from '../../../src/package-info.ts'
 import { renderSvgInputShape, renderSvgHandler } from './tools/render-svg.ts'
 import {
   renderAsciiInputShape,
@@ -19,6 +20,10 @@ import {
   checkSequenceActivationsInputShape,
   checkSequenceActivationsHandler,
 } from './tools/check-sequence-activations.ts'
+import {
+  fixSequenceActivationsInputShape,
+  fixSequenceActivationsHandler,
+} from './tools/fix-sequence-activations.ts'
 
 /**
  * Build a zombie-mermaid MCP server exposing `render_mermaid_svg`,
@@ -99,5 +104,32 @@ export function createMcpServer(): McpServer {
     checkSequenceActivationsHandler,
   )
 
+  server.registerTool(
+    'fix_mermaid_sequence_activations',
+    {
+      title: 'Fix Mermaid sequence diagram activation balance',
+      description:
+        'Check a Mermaid sequence diagram for activation/deactivation ' +
+        'imbalance and, where mechanically safe, return a corrected ' +
+        'version: a dangling "activate X" (or "+" shorthand) with no ' +
+        'matching "deactivate X" gets one appended. An unmatched ' +
+        '"deactivate X" with nothing open is reported but not auto-fixed ' +
+        '(no safe, unambiguous edit exists without source-position ' +
+        'tracking). Returns a JSON report ({ ok, fixedDiagram, ' +
+        'fixesApplied, remainingIssues }) rather than rendering anything. ' +
+        'Mechanical and deterministic — no LLM judgment involved. Only ' +
+        'sequence diagrams are supported.',
+      inputSchema: fixSequenceActivationsInputShape,
+      annotations: {
+        title: 'Fix Mermaid sequence diagram activation balance',
+        readOnlyHint: true,
+        destructiveHint: false,
+        idempotentHint: true,
+        openWorldHint: false,
+      },
+    },
+    fixSequenceActivationsHandler,
+  )
+
   return server
 }

package/{src/mcp → packages/mcp/src}/tools/check-sequence-activations.ts

@@ -5,9 +5,10 @@
 // render tools: every "activate X" (or "+" arrow shorthand) in a Mermaid
 // sequence diagram must be closed by a matching "deactivate X" ("-"
 // shorthand) before the diagram ends. No LLM judge involved — see
-// src/sequence/activation-check.ts for the actual check, which reuses the
-// same activation-stack bookkeeping src/sequence/layout.ts already runs to
-// *draw* activation bars.
+// packages/mermaid-parser/src/sequence/activation-check.ts for the actual
+// check, which reuses the same activation-stack bookkeeping
+// packages/svg-renderer/src/sequence/layout.ts already runs to *draw*
+// activation bars.
 //
 // Why this tool, and why it isn't duplicating agentic-mermaid's `verify`
 // tool (github.com/adewale/agentic-mermaid): that tool's own docs describe
@@ -22,8 +23,10 @@
 import { z } from 'zod'
 import type { CallToolResult } from '@modelcontextprotocol/sdk/types.js'
 import { detectDiagramType, splitStatements } from '@zombie-mermaid/core'
-import { parseSequenceDiagram } from '../../sequence/parser.ts'
-import { checkActivationBalance } from '../../sequence/activation-check.ts'
+import {
+  parseSequenceDiagram,
+  checkActivationBalance,
+} from '@zombie-mermaid/mermaid-parser'
 
 export const checkSequenceActivationsInputShape = {
   diagram: z

package/packages/mcp/src/tools/fix-sequence-activations.ts

@@ -0,0 +1,77 @@
+// ============================================================================
+// zombie-mermaid MCP server — `fix_mermaid_sequence_activations` tool
+//
+// The "optionally proposes a fix" half of issue #539, complementing
+// `check_mermaid_sequence_activations` (which only reports issues). Reuses
+// packages/mermaid-parser/src/sequence/activation-fix.ts, which — see that
+// file's header — only auto-fixes DANGLING_ACTIVATION (a mechanically safe,
+// unambiguous append); UNMATCHED_DEACTIVATION comes back as a remaining
+// issue for a human (or a future LLM-based layer) to resolve rather than
+// risk an incorrect text edit.
+// ============================================================================
+
+import { z } from 'zod'
+import type { CallToolResult } from '@modelcontextprotocol/sdk/types.js'
+import { detectDiagramType } from '@zombie-mermaid/core'
+import { fixActivationBalance } from '@zombie-mermaid/mermaid-parser'
+
+export const fixSequenceActivationsInputShape = {
+  diagram: z
+    .string()
+    .min(1, 'diagram must not be empty')
+    .describe(
+      'Mermaid sequence diagram source text, e.g. "sequenceDiagram\\n  ' +
+        'activate A\\n  A->>B: hi". Must start with "sequenceDiagram" — ' +
+        'this tool does not check other diagram types.',
+    ),
+}
+
+export interface FixSequenceActivationsToolArgs {
+  diagram: string
+}
+
+/**
+ * MCP tool handler for `fix_mermaid_sequence_activations`. Parses the given
+ * source as a Mermaid sequence diagram, checks activation/deactivation
+ * balance, and returns a structured JSON result: `ok`, the (possibly
+ * unchanged) `fixedDiagram`, `fixesApplied` (human-readable descriptions),
+ * and any `remainingIssues` that couldn't be auto-fixed.
+ *
+ * Returns an MCP tool error (`isError: true`, not a thrown exception) both
+ * for invalid Mermaid syntax and for a non-sequence diagram, matching
+ * `check-sequence-activations.ts`'s error handling.
+ */
+export function fixSequenceActivationsHandler(
+  input: FixSequenceActivationsToolArgs,
+): CallToolResult {
+  try {
+    const diagramType = detectDiagramType(input.diagram)
+    if (diagramType !== 'sequence') {
+      return {
+        isError: true,
+        content: [
+          {
+            type: 'text',
+            text:
+              'This tool only fixes sequence diagrams (source must start ' +
+              `with "sequenceDiagram"); detected diagram type: "${diagramType}".`,
+          },
+        ],
+      }
+    }
+    const result = fixActivationBalance(input.diagram)
+    return {
+      content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
+    }
+  } catch (err) {
+    return {
+      isError: true,
+      content: [
+        {
+          type: 'text',
+          text: `Failed to fix diagram activations: ${err instanceof Error ? err.message : String(err)}`,
+        },
+      ],
+    }
+  }
+}

package/{src/mcp → packages/mcp/src}/tools/render-ascii.ts

@@ -8,8 +8,8 @@
 
 import { z } from 'zod'
 import type { CallToolResult } from '@modelcontextprotocol/sdk/types.js'
-import { renderMermaidASCII } from '../../ascii/index.ts'
-import type { AsciiRenderOptions } from '../../ascii/index.ts'
+import { renderMermaidASCII } from '@zombie-mermaid/ascii-renderer'
+import type { AsciiRenderOptions } from '@zombie-mermaid/ascii-renderer'
 
 export const renderAsciiInputShape = {
   diagram: z

package/{src/mcp → packages/mcp/src}/tools/render-svg.ts

@@ -8,7 +8,7 @@
 
 import { z } from 'zod'
 import type { CallToolResult } from '@modelcontextprotocol/sdk/types.js'
-import { renderMermaidSVG } from '../../index.ts'
+import { renderMermaidSVG } from '../../../../src/index.ts'
 import { THEMES } from '@zombie-mermaid/core'
 import type { DiagramColors } from '@zombie-mermaid/core'
 

package/packages/mermaid-parser/LICENSE

@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2026 Craft Docs
+Copyright (c) 2026 Dustin Fadler
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/{src → packages/mermaid-parser/src}/class/parser.ts

@@ -14,6 +14,7 @@ import {
   tryApplyClassDef,
   tryApplyCssClass,
   tryApplyStyleStatement,
+  type Statement,
 } from '@zombie-mermaid/core'
 
 // ============================================================================
@@ -39,6 +40,27 @@ import {
 //   note "text"  /  note for Animal "line1\nline2"
 // ============================================================================
 
+/**
+ * The set of relationship-arrow tokens `parseRelationship` recognizes,
+ * shared with the "does this line even look like a relationship attempt"
+ * check below so the two can't drift apart. Order matters for regex
+ * alternation (longer/more-specific tokens like `--|>` must be tried before
+ * the bare `--` fallback).
+ */
+const RELATIONSHIP_ARROW_SOURCE =
+  '<\\|--|<\\|\\.\\.|\\*--|o--|-->|--\\*|--o|--\\|>|\\.\\.>|\\.\\.\\|>|<--|<\\.\\.?|--'
+
+/**
+ * Matches a line that *contains* a relationship-arrow token somewhere, even
+ * if the overall shape (FROM/TO, cardinalities) doesn't parse. Used to
+ * scope the "malformed relationship" error (issue #761) to lines that
+ * already look like an attempt at this construct — mirroring the same
+ * "attempt, then validate" pattern #722 used for the ER and xychart-beta
+ * parsers, so a genuinely unrelated line (no arrow at all) still falls
+ * through silently rather than throwing on totally unrecognized syntax.
+ */
+const RELATIONSHIP_ARROW_MARKER = new RegExp(RELATIONSHIP_ARROW_SOURCE)
+
 /**
  * Parse a Mermaid class diagram.
  * Expects the first line to be "classDiagram".
@@ -55,7 +77,7 @@ import {
 // `noUncheckedIndexedAccess` can't see either guarantee, but removing the
 // `!` would only replace a proven-safe assertion with an unreachable guard.
 // Left as-is; no behavior change.
-export function parseClassDiagram(lines: string[]): ClassDiagram {
+export function parseClassDiagram(lines: Statement[]): ClassDiagram {
   const diagram: ClassDiagram = {
     classes: [],
     relationships: [],
@@ -74,9 +96,14 @@ export function parseClassDiagram(lines: string[]): ClassDiagram {
   // Track class body parsing
   let currentClass: ClassNode | null = null
   let braceDepth = 0
+  // Line the currently-open class body started on, for the unclosed-body
+  // error below (issue #761) — `currentClass`/`braceDepth` alone don't
+  // carry position.
+  let openClassLine: number | undefined
 
   for (let i = 1; i < lines.length; i++) {
-    const line = lines[i]!
+    const stmt = lines[i]!
+    const line = stmt.text
 
     // --- Inside a class body block ---
     if (currentClass && braceDepth > 0) {
@@ -84,6 +111,7 @@ export function parseClassDiagram(lines: string[]): ClassDiagram {
         braceDepth--
         if (braceDepth === 0) {
           currentClass = null
+          openClassLine = undefined
         }
         continue
       }
@@ -95,8 +123,18 @@ export function parseClassDiagram(lines: string[]): ClassDiagram {
         continue
       }
 
+      // A line that starts with `<<` but doesn't match the full
+      // `<<name>>` shape is an attempted annotation with broken syntax
+      // (e.g. a missing closing `>>`) rather than a member — surface that
+      // instead of silently mis-parsing it as a member named "<<foo" (#761).
+      if (line.startsWith('<<')) {
+        throw new Error(
+          `Line ${stmt.line}: Malformed class annotation "${line}" — expected "<<name>>" (e.g. "<<interface>>").`,
+        )
+      }
+
       // Parse member: visibility, name, type, optional parens for method
-      addMember(currentClass, line)
+      addMember(currentClass, line, stmt.line)
       continue
     }
 
@@ -155,6 +193,7 @@ export function parseClassDiagram(lines: string[]): ClassDiagram {
       const id = declareClass(classBlockMatch[1]!, classBlockMatch[2])
       currentClass = classMap.get(id) ?? null
       braceDepth = 1
+      openClassLine = stmt.line
       continue
     }
 
@@ -177,8 +216,14 @@ export function parseClassDiagram(lines: string[]): ClassDiagram {
       const annotMatch = body.match(/^<<(\w+)>>$/)
       if (cls && annotMatch) {
         cls.annotation = annotMatch[1]!
+      } else if (cls && body.startsWith('<<')) {
+        // Same broken-annotation-attempt case as the multi-line body
+        // branch above, just on the single-line form (#761).
+        throw new Error(
+          `Line ${stmt.line}: Malformed class annotation "${body}" — expected "<<name>>" (e.g. "<<interface>>").`,
+        )
       } else if (cls && body) {
-        addMember(cls, body)
+        addMember(cls, body, stmt.line)
       }
       continue
     }
@@ -189,7 +234,7 @@ export function parseClassDiagram(lines: string[]): ClassDiagram {
       // Make sure this isn't a relationship line (those have arrows)
       const rest = inlineAttrMatch[2]!
       if (!rest.match(/<\|--|--|\*--|o--|-->|\.\.>|\.\.\|>/)) {
-        addMember(ensureClass(classMap, inlineAttrMatch[1]!), rest)
+        addMember(ensureClass(classMap, inlineAttrMatch[1]!), rest, stmt.line)
         continue
       }
     }
@@ -209,6 +254,25 @@ export function parseClassDiagram(lines: string[]): ClassDiagram {
       diagram.relationships.push(rel)
       continue
     }
+
+    // A line containing a relationship-arrow token that still didn't parse
+    // above is a malformed/dangling relationship attempt — e.g. "Animal
+    // <|--" with no target, or an unsupported arrow shape — rather than an
+    // unrelated line that merely falls through. Scoped to lines that
+    // already look like an attempt (same "attempt, then validate" pattern
+    // #722 used for ER/xychart-beta) so genuinely unrecognized syntax with
+    // no arrow at all keeps falling through silently (#761).
+    if (RELATIONSHIP_ARROW_MARKER.test(line)) {
+      throw new Error(
+        `Line ${stmt.line}: Malformed class-diagram relationship "${line}". Expected "FROM ARROW TO" (optionally with cardinalities and a ": label"), e.g. "Animal <|-- Dog" or 'A "1" --> "*" B : label'. ARROW must be one of <|--, <|.., *--, o--, -->, --*, --o, --|>, ..>, ..|>, <--, <.., or --.`,
+      )
+    }
+  }
+
+  if (currentClass !== null) {
+    throw new Error(
+      `Line ${openClassLine}: Unclosed class body for "${currentClass.id}" — expected a closing "}" before the diagram ends.`,
+    )
   }
 
   diagram.classes = [...classMap.values()]
@@ -258,8 +322,8 @@ export function parseClassDiagram(lines: string[]): ClassDiagram {
 }
 
 /** Parse one member line and file it under the class's attributes or methods. */
-function addMember(cls: ClassNode, line: string): void {
-  const member = parseMember(line)
+function addMember(cls: ClassNode, line: string, lineNumber: number): void {
+  const member = parseMember(line, lineNumber)
   if (!member) return
   if (member.isMethod) {
     cls.methods.push(member.member)
@@ -351,6 +415,7 @@ export function parseGenericTypes(input: string): string {
 /** Parse a class member line (attribute or method) */
 function parseMember(
   line: string,
+  lineNumber: number,
 ): { member: ClassMember; isMethod: boolean } | null {
   const trimmed = line.trim().replace(/;$/, '')
   if (!trimmed) return null
@@ -369,6 +434,17 @@ function parseMember(
     rest = rest.slice(1).trim()
   }
 
+  // An attempted method signature with an opening "(" but no closing ")"
+  // at all can't be a genuine attribute either (an attribute name/type
+  // never legitimately contains a bare, unclosed paren) — surface it
+  // instead of silently parsing "eat(void" as a member literally named
+  // that (#761).
+  if (rest.includes('(') && !rest.includes(')')) {
+    throw new Error(
+      `Line ${lineNumber}: Malformed class member "${trimmed}" — unclosed "(" in a method signature. Expected e.g. "+eat() void" or "+eat(Food f) void".`,
+    )
+  }
+
   // Mermaid renders `List~Observer~` as `List<Observer>` (its own
   // `parseGenericTypes`). It's applied per field below — name, params and
   // return type separately, the way mermaid's ClassMember does — rather
@@ -440,7 +516,9 @@ function parseRelationship(line: string): ClassRelationship | null {
   // label separator that follows can't swallow it as a label of `::style`;
   // it's re-joined onto the id here and split off again by the caller.
   const match = line.match(
-    /^(\S+?)\s+(?:"([^"]*?)"\s+)?(<\|--|<\|\.\.|\*--|o--|-->|--\*|--o|--\|>|\.\.>|\.\.\|>|<--|<\.\.?|--)\s+(?:"([^"]*?)"\s+)?(\S+?)(?::::([\w][\w-]*))?(?:\s*:\s*(.+))?$/,
+    new RegExp(
+      `^(\\S+?)\\s+(?:"([^"]*?)"\\s+)?(${RELATIONSHIP_ARROW_SOURCE})\\s+(?:"([^"]*?)"\\s+)?(\\S+?)(?::::([\\w][\\w-]*))?(?:\\s*:\\s*(.+))?$`,
+    ),
   )
   if (!match) return null
 

package/{src → packages/mermaid-parser/src}/er/parser.ts

@@ -5,8 +5,11 @@ import type {
   ErRelationship,
   Cardinality,
 } from './types.ts'
-import { normalizeBrTags } from '@zombie-mermaid/core'
-import { toDirection } from '../parser.ts'
+import {
+  normalizeBrTags,
+  toDirection,
+  type Statement,
+} from '@zombie-mermaid/core'
 
 // ============================================================================
 // ER diagram parser
@@ -49,7 +52,7 @@ import { toDirection } from '../parser.ts'
 // concern from these `!`s) — `noUncheckedIndexedAccess` can't see either
 // guarantee, but removing the `!` would only replace a proven-safe
 // assertion with an unreachable guard. Left as-is; no behavior change.
-export function parseErDiagram(lines: string[]): ErDiagram {
+export function parseErDiagram(lines: Statement[]): ErDiagram {
   const diagram: ErDiagram = {
     entities: [],
     relationships: [],
@@ -61,7 +64,8 @@ export function parseErDiagram(lines: string[]): ErDiagram {
   let currentEntity: ErEntity | null = null
 
   for (let i = 1; i < lines.length; i++) {
-    const line = lines[i]!
+    const stmt = lines[i]!
+    const line = stmt.text
 
     // --- Inside entity body ---
     if (currentEntity) {
@@ -121,7 +125,7 @@ export function parseErDiagram(lines: string[]): ErDiagram {
     }
 
     // --- Relationship: `ENTITY1 cardinality1--cardinality2 ENTITY2 : label` ---
-    const rel = parseRelationshipLine(line)
+    const rel = parseRelationshipLine(line, stmt.line)
     if (rel) {
       // Ensure both entities exist
       ensureEntity(entityMap, rel.entity1)
@@ -197,33 +201,62 @@ function parseAttribute(line: string): ErAttribute | null {
  *
  * Full pattern example: CUSTOMER ||--o{ ORDER : places
  */
-function parseRelationshipLine(line: string): ErRelationship | null {
-  // Match: ENTITY1 <cardinality_and_line> ENTITY2 : label
-  const match = line.match(
-    /^(\S+)\s+([|o}{]+(?:--|\.\.)[|o}{]+)\s+(\S+)\s*:\s*(.+)$/,
+function parseRelationshipLine(
+  line: string,
+  lineNumber: number,
+): ErRelationship | null {
+  // Loosely match a line shaped like a relationship attempt: two bare
+  // tokens flanking a `--`/`..`-based marker, with an optional `: label`.
+  // A line with no such marker at all doesn't look like a relationship
+  // attempt and falls through silently (returns null), same as before —
+  // that part of the parser's leniency is unchanged.
+  //
+  // Everything that *does* match this shape is validated below and either
+  // returns a fully-parsed relationship or throws an actionable error.
+  // Before this pass, an invalid cardinality token or a missing/empty
+  // label silently dropped the *entire* line (both entities included)
+  // with zero indication anything was wrong — see issue #541 (parser
+  // error-message quality audit — this parser had zero throw sites before
+  // this pass).
+  const attempt = line.match(
+    /^(\S+)\s+(\S*(?:--|\.\.)\S*)\s+(\S+)\s*(?::\s*(.*))?$/,
   )
-  if (!match) return null
+  if (!attempt) return null
 
-  const entity1 = match[1]!
-  const cardinalityStr = match[2]!
-  const entity2 = match[3]!
-  // Strip surrounding quotes if present, then normalize br tags
-  const rawLabel = match[4]!.trim().replace(/^["']|["']$/g, '')
-  const label = normalizeBrTags(rawLabel)
+  const entity1 = attempt[1]!
+  const cardinalityStr = attempt[2]!
+  const entity2 = attempt[3]!
+  const hasLabel = attempt[4] !== undefined
+  const rawLabel = attempt[4]?.trim() ?? ''
 
-  // Split the cardinality string into left side, line style, right side
-  const lineMatch = cardinalityStr.match(/^([|o}{]+)(--|\.\.?)([|o}{]+)$/)
-  if (!lineMatch) return null
+  // Cardinality symbols on each side of the line style:
+  //   Left side (entity1):  ||  |o  }|  }o
+  //   Line:                 --  (identifying) or  ..  (non-identifying)
+  //   Right side (entity2): ||  o|  |{  o{
+  // `shapeMatch` only confirms the token is built from crow's-foot
+  // characters around a line-style marker — `parseLeftCardinality`/
+  // `parseRightCardinality` still reject a shape match that isn't one of
+  // the four valid two-character combinations per side (e.g. a lone "|").
+  const shapeMatch = cardinalityStr.match(/^([|o}{]*)(--|\.\.?)([|o}{]*)$/)
+  const cardinality1 = shapeMatch ? parseLeftCardinality(shapeMatch[1]!) : null
+  const cardinality2 = shapeMatch ? parseRightCardinality(shapeMatch[3]!) : null
 
-  const leftStr = lineMatch[1]!
-  const lineStyle = lineMatch[2]!
-  const rightStr = lineMatch[3]!
+  if (!cardinality1 || !cardinality2) {
+    throw new Error(
+      `Line ${lineNumber}: Invalid ER relationship cardinality "${cardinalityStr}" in "${line}". ` +
+        'Left side must be one of ||, |o, }|, }o; right side must be one of ||, o|, |{, o{ (e.g. "||--o{").',
+    )
+  }
 
-  const cardinality1 = parseLeftCardinality(leftStr)
-  const cardinality2 = parseRightCardinality(rightStr)
-  const identifying = lineStyle === '--'
+  if (!hasLabel || rawLabel.length === 0) {
+    throw new Error(
+      `Line ${lineNumber}: ER relationship "${entity1} ${cardinalityStr} ${entity2}" is missing a ": label" — expected e.g. "${entity1} ${cardinalityStr} ${entity2} : label".`,
+    )
+  }
 
-  if (!cardinality1 || !cardinality2) return null
+  // Strip surrounding quotes if present, then normalize br tags.
+  const label = normalizeBrTags(rawLabel.replace(/^["']|["']$/g, ''))
+  const identifying = shapeMatch![2] === '--'
 
   return { entity1, entity2, cardinality1, cardinality2, label, identifying }
 }

package/packages/mermaid-parser/src/index.ts

@@ -0,0 +1,48 @@
+// ============================================================================
+// @zombie-mermaid/mermaid-parser — per-type diagram parsers
+//
+// Class, ER, sequence, and XY chart diagrams have no shared generic model
+// the way flowcharts/state diagrams do (`MermaidGraph`, parsed by the
+// umbrella's own `src/parser.ts`). Both `svg-renderer` and `ascii-renderer`
+// import each type's parse function and types directly — confirmed by grep
+// (zombie-mermaid#624, umbrella #620, `monorepo-conversion-scoping.md`
+// finding 2) — so this package's public API is every per-type parse
+// function plus its types, not a single generic entry point.
+//
+// Each of `src/class/`, `src/er/`, `src/sequence/`, `src/xychart/` used to
+// mix this parser half (`parser.ts`, `types.ts`, and — per file, not
+// per-half-pair, see the scoping doc's addendum correction 3 —
+// `class/format.ts`, `sequence/box-color.ts`, `sequence/activation-check.ts`,
+// `xychart/colors.ts`) with a renderer half (`layout.ts`, `renderer.ts`) in
+// the same directory. The renderer half moved into
+// `packages/svg-renderer/src/<type>/` instead — see that package's `index.ts`
+// header for the reverse dependency this split introduces (`svg-renderer`
+// depends on this package for the positioned-diagram types and a handful of
+// parser-side helpers, an ordinary acyclic workspace shape per finding 2).
+//
+// This package depends only on `@zombie-mermaid/core` — verified: no file
+// below imports `elkjs`, `@zombie-mermaid/svg-renderer`, or anything from
+// the umbrella. `toDirection` moved here from the umbrella's `src/parser.ts`
+// (alongside `isDirection`, already `core` since #625) specifically so
+// `er/parser.ts` below could use it without importing the umbrella and
+// creating a cycle — see `packages/core/src/direction.ts`'s header.
+// ============================================================================
+
+export * from './class/parser.ts'
+export * from './class/types.ts'
+export * from './class/format.ts'
+
+export * from './er/parser.ts'
+export * from './er/types.ts'
+
+export * from './sequence/parser.ts'
+export * from './sequence/types.ts'
+export * from './sequence/box-color.ts'
+export * from './sequence/activation-check.ts'
+export * from './sequence/activation-fix.ts'
+
+export * from './xychart/parser.ts'
+export * from './xychart/types.ts'
+export * from './xychart/colors.ts'
+
+export * from './expanded-shapes.ts'

package/{src → packages/mermaid-parser/src}/sequence/activation-check.ts

@@ -4,9 +4,10 @@
 // A mechanical, deterministic semantic check: every `activate X` (or the
 // `+` arrow shorthand) must be closed by a matching `deactivate X` (or the
 // `-` shorthand) before the diagram ends. This doesn't need an LLM judge —
-// it's the same activation-stack bookkeeping src/sequence/layout.ts already
-// runs to *draw* activation bars (see its `activationStacks` map), reused
-// here to *report* imbalance instead of silently rendering around it.
+// it's the same activation-stack bookkeeping
+// packages/svg-renderer/src/sequence/layout.ts already runs to *draw*
+// activation bars (see its `activationStacks` map), reused here to *report*
+// imbalance instead of silently rendering around it.
 //
 // Motivation (issue #539, split from #536): research on LLM-generated
 // Mermaid sequence diagrams found they fail mostly on activation handling