ea 0.3.1 → 0.4.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: cf343d41c80cffbd277dd67bf172d0c947ddae898f51dacc1a2fffc3af871b0a
-  data.tar.gz: b554c52026c03c0a431e31140f840fedd495fae447b738c4d9fda4fae30c9eda
+  metadata.gz: b401faad5f11e5b2504e50cabd3ee86dd4939bd8639c4c046b3fd9963408a116
+  data.tar.gz: fe36564c5f8d52281a35e1fa49c7f1231a42f941b92e8e5895623e18d6f32ddf
 SHA512:
-  metadata.gz: bdec06da4470d865e75c52cbe8c5bec83ae4f242b223e98b436e5c244e8dcf8fd3c9a03bfe3f1ef3eedd9d2443fa52c21544755e8ff9cb3c5e698ee0a4b685f3
-  data.tar.gz: 5db5b284986bd79b3c1165f491d95cb6a5b9cd88d0bcdcab116e77abd92ebd84b267c8f3614850fa669d544085eca6eba52a6eea45c992e42439aa0b38803194
+  metadata.gz: 7cd10052a2b16998cab3bde33d0874f605e6d8f767adefc710c7080ced3a39d76e3e0fb262b3931483d19cbfc35ff9715928f0d7d5f4dda22d95be693b0455a8
+  data.tar.gz: 87d9150c1840ca118fe264b5b1cf2c01bf09ba5d7eb2c5f5cf5a3aedd3c27bc4a07ea86ac9e7d1636bd2ebf835b012c049bc535e76edbdf412b28152ae7e4b68

data/TODO.diagrams/01-xmi-extension-elements-parsing.md

@@ -0,0 +1,67 @@
+# 01 - Parse XMI Extension Elements Block
+
+## Status: DONE (2026-07-21)
+
+## Problem
+
+EA's XMI stores diagram placement data inside an `<xmi:Extension>`
+block, under `<elements>/<element>` rows. Each row carries:
+
+- `geometry="Left=X;Top=Y;Right=X2;Bottom=Y2;imgL=..;imgT=..;imgR=..;imgB=..;"`
+  (pixel bounds + image bounds with 25 px padding)
+- `subject="EAID_..."` (the model element this placement refers to)
+- `seqno="N"` (z-order)
+- `style="BCol=<int>;font=<name>;fontsz=<int>;bold=0;italic=0;LWth=<int>;.."`
+  (EA packed style)
+
+For connectors, the same row shape carries:
+- `geometry="SX=..;SY=..;EX=..;EY=..;EDGE=N;$LLB=..;$LLT=..;LRT=..;LRB=..;Path=;"`
+- `style="Mode=3;SOID=<source DUID>;EOID=<target DUID>;Color=-1;LWidth=2;"`
+
+Our `Ea::Sources::Xmi::DiagramBuilder` currently reads only the
+UML-DI `<owned_element>/<bounds>` tree, which doesn't include any
+of this rich placement/style data. Result: SVG rendering from XMI
+sources is missing colors, fonts, bend routing, label positions,
+and proper element placement.
+
+## Approach
+
+Extend the XMI source adapter to walk the `<xmi:Extension>`
+block's `<elements>` rows for each diagram. Build a parallel
+`Ea::Model::DiagramElement` per row, populating:
+
+- `bounds` from `Left/Top/Right/Bottom`
+- `model_element_ref` from `subject` (resolved to model id)
+- `style` hash including `BCol`, `font`, `fontsz`, `bold`, `italic`,
+  `LWth`, `LCol` (line color)
+- A new `image_bounds` field carrying the `imgL/imgT/imgR/imgB`
+  padded bounds (EA's visual box, vs. the logical bounds)
+
+For connector rows, build `Ea::Model::DiagramConnector` with:
+- `relationship_ref` from `subject`
+- Source/target resolved via `SOID`/`EOID` → DUID → placed element
+- Waypoints computed from the SX/SY/EX/EY deltas + the source and
+  target element edge centers (matching EA's rendering math)
+- Style hash with `Color`, `LWidth`, `Mode`
+
+## Files
+
+- `lib/ea/sources/xmi/extension_elements.rb` (new — walks the
+  extension block, returns typed rows)
+- `lib/ea/sources/xmi/extension_geometry_parser.rb` (new — parses
+  `geometry="..."` packed string into a typed struct)
+- `lib/ea/sources/xmi/extension_style_parser.rb` (new — parses
+  `style="..."` packed string into a typed struct)
+- `lib/ea/sources/xmi/diagram_builder.rb` (updated — uses
+  extension data when present, falls back to umldi otherwise)
+- `lib/ea/model/diagram_element.rb` (extended — add
+  `image_bounds` field)
+- `spec/ea/sources/xmi/extension_*_spec.rb`
+
+## Verification
+
+- Unit specs: parse a known geometry/style string, assert typed
+  struct matches.
+- Integration: load `plateau_all_packages_export.xmi`, find diagram
+  `EAID_0016F797_...`, assert every placed element has bounds +
+  style populated.

data/TODO.diagrams/02-diagram-element-rich-model.md

@@ -0,0 +1,61 @@
+# 02 - Rich DiagramElement / DiagramConnector Model
+
+## Status: DONE (2026-07-21, folded into TODO 03)
+
+## Problem
+
+The current `Ea::Model::DiagramElement` carries only `bounds` and
+an untyped `style` hash. EA's renderer needs:
+
+- `image_bounds` (the imgL/imgT/imgR/imgB padded rect — distinct
+  from the logical Left/Top/Right/Bottom rect)
+- `background_color` (decoded from `BCol` BGR integer → RGB hex)
+- `font_family`, `font_size`, `font_bold`, `font_italic`
+- `line_color`, `line_width`
+- `z_order` (seqno)
+- `label_inset` (the offset from the bounds origin where text
+  should start; EA convention is x+5, y+17 for the first line)
+
+For `DiagramConnector`:
+- `source_anchor`, `target_anchor` (which edge of the source/target
+  element the line attaches to — top/right/bottom/left)
+- `source_duid`, `target_duid` (so the renderer can resolve back to
+  placed elements without re-walking the model)
+- `label_boxes` (the four LRT/LRB/LLT/LLB label rectangles with
+  their text content decoded)
+
+## Approach
+
+Extend the existing types (don't replace — backward compat for the
+QEA adapter which doesn't populate these yet):
+
+- `DiagramElement`: add `image_bounds`, `background_color`,
+  `font_family`, `font_size`, `font_bold`, `font_italic`,
+  `line_color`, `line_width`, `z_order`
+- `DiagramConnector`: add `source_anchor`, `target_anchor`,
+  `source_duid`, `target_duid`, `label_boxes` (collection)
+
+The QEA adapter populates these from its `objectstyle` packed
+string (existing `DiagramStyleParser`); the XMI adapter populates
+them from the `<xmi:Extension>/<elements>` style attribute.
+
+The renderer reads the typed fields directly — no more parsing at
+render time.
+
+## Files
+
+- `lib/ea/model/diagram_element.rb`
+- `lib/ea/model/diagram_connector.rb`
+- `lib/ea/model/label_box.rb` (new)
+- `lib/ea/sources/qea/diagram_builder.rb` (populate the new fields)
+- `lib/ea/sources/qea/diagram_style_parser.rb` (extend to typed
+  accessors, not just a hash)
+- `spec/ea/model/diagram_element_spec.rb`
+- `spec/ea/model/diagram_connector_spec.rb`
+
+## Verification
+
+- Round-trip: model JSON includes all new fields; deserialize
+  preserves them.
+- QEA adapter spec: every placed element has a non-nil
+  `background_color`.

data/TODO.diagrams/03-ea-style-svg-emitter.md

@@ -0,0 +1,70 @@
+# 03 - EA-Style SVG Emitter
+
+## Status: DONE (2026-07-21) (depends on 02)
+
+## Problem
+
+The current `Ea::Svg::Renderer` emits minimal SVG: header,
+background rect, then per-element `<g class="element">` groups
+with the box + label inside. EA's SVG output is structurally
+different:
+
+1. DOCTYPE declaration (SVG 1.0)
+2. Root `<svg>` with `width="Xcm" height="Ycm"` and
+   `viewBox="0 0 W H"`
+3. `<title></title>` (empty)
+4. `<desc>Created with Enterprise Architect (Build: 1628) 2</desc>`
+5. Background `<g style="fill:#FFFFFF;..."><rect .../></g>`
+6. For each element, TWO `<g>` blocks:
+   a. Shape `<g>` with `style="...fill:COLOR;..."` containing the
+      `<rect>`
+   b. Text `<g>` with `style="fill:#000000;..."` containing all
+      `<text>` labels for that element
+7. Divider line as `<g><path d="M x y L x2 y2"/></g>`
+8. Connector paths as separate `<g>` blocks per path segment
+9. Arrow markers as `<g><polygon .../></g>`
+10. Connector labels as a final `<g>` block of `<text>`
+
+The output is layered by visual category, not by element. Our
+current emitter layers by element, mixing shapes and text in one
+`<g>`.
+
+## Approach
+
+Rewrite the emitter to follow EA's layering. Each render phase
+emits one or more `<g>` blocks in the canonical order:
+
+1. `Ea::Svg::EaEmitter::Background`
+2. `Ea::Svg::EaEmitter::Elements` (one shape `<g>` + one text `<g>`
+   per element, in z-order)
+3. `Ea::Svg::EaEmitter::Dividers` (one `<g>` per divider line)
+4. `Ea::Svg::EaEmitter::Connectors` (one `<g>` per path)
+5. `Ea::Svg::EaEmitter::Markers` (filled / open polygons)
+6. `Ea::Svg::EaEmitter::Labels` (all text labels last)
+
+Each emitter is a single-responsibility class. The orchestrator
+calls them in order.
+
+The existing `Ea::Svg::Renderer` stays as a thinner alternative
+(useful for diagrams without full style data, e.g. from QEA
+sources with sparse style). The new `EaEmitter` is the default
+when full EA-style data is available.
+
+## Files
+
+- `lib/ea/svg/ea_emitter.rb` (orchestrator)
+- `lib/ea/svg/ea_emitter/background.rb`
+- `lib/ea/svg/ea_emitter/elements.rb`
+- `lib/ea/svg/ea_emitter/dividers.rb`
+- `lib/ea/svg/ea_emitter/connectors.rb`
+- `lib/ea/svg/ea_emitter/markers.rb`
+- `lib/ea/svg/ea_emitter/labels.rb`
+- `lib/ea/svg/ea_emitter/canvas.rb` (computes cm dimensions + viewBox)
+- `spec/ea/svg/ea_emitter/*_spec.rb`
+
+## Verification
+
+- Byte-level structural diff against EA's reference SVG for one
+  diagram. We don't require pixel-perfect match (font rendering
+  differences), but the element layering, group structure, and
+  attribute presence should match.

data/TODO.diagrams/04-connector-routing-from-soid-eoid.md

@@ -0,0 +1,55 @@
+# 04 - Connector Routing via SOID/EOID Resolution
+
+## Status: DONE (2026-07-21, folded into TODO 03)
+
+## Problem
+
+EA connector geometry stores only bend deltas (SX/SY/EX/EY) and
+the EDGE code (which side of the element the line attaches to).
+The actual line endpoints are computed by EA's renderer at draw
+time, by looking up the source and target element placements via
+their DUIDs (style `SOID` and `EOID`).
+
+Our current QEA adapter computes waypoints from the connector's
+Start_Object_ID/End_Object_ID via the model. That works but
+ignores the EDGE hint, producing lines that always start at the
+element center instead of the correct edge.
+
+## Approach
+
+In both the QEA and XMI source adapters, when building a
+DiagramConnector:
+
+1. Resolve source and target placements via SOID/EOID (XMI) or
+   Start_Object_ID/End_Object_ID (QEA).
+2. Read the `EDGE` field (1=top, 2=right, 3=bottom, 4=left,
+   5..8 = diagonal variants).
+3. Compute the source connection point as the center of the
+   chosen edge on the source element.
+4. Apply the SX/SY delta to get the first bend.
+5. Apply the EX/EY delta from the target edge center to get the
+   second bend.
+6. Compute the target connection point as the center of the
+   chosen edge on the target element.
+
+Emit exactly 2-4 waypoints: source edge → first bend → second
+bend → target edge. This matches EA's typical "L" or "Z" routing.
+
+For connectors without EDGE or SOID/EOID, fall back to straight
+line between element centers.
+
+## Files
+
+- `lib/ea/sources/qea/diagram_builder.rb`
+- `lib/ea/sources/xmi/diagram_builder.rb`
+- `lib/ea/svg/edge_anchor.rb` (computes edge center given bounds +
+  EDGE code)
+- `spec/ea/svg/edge_anchor_spec.rb`
+
+## Verification
+
+- Spec: source element with EDGE=1 produces a source point at the
+  top edge center.
+- Spec: connector with both bends produces 4 waypoints.
+- Visual: connector lines visually attach to element edges, not
+  centers.

data/TODO.diagrams/05-marker-rendering-per-relationship-type.md

@@ -0,0 +1,49 @@
+# 05 - Marker Rendering Per Relationship Type
+
+## Status: DONE (2026-07-21, folded into TODO 03)
+
+## Problem
+
+EA renders different arrow markers based on the connector's
+semantic type:
+
+- **Association** (navigable): filled triangle at target
+- **Generalization**: open triangle at target (white fill, black
+  stroke)
+- **Realization**: open triangle at target + dashed line
+- **Dependency**: open arrow at target + dashed line
+- **Aggregation** (source): open diamond at source
+- **Composition** (source): filled diamond at source
+
+Our current renderer emits a filled triangle at target regardless
+of relationship type, plus a diamond for aggregations. The
+distinction between open and filled markers matters visually.
+
+## Approach
+
+Add a `MarkerResolver` that maps a relationship type + end
+(source/target) to a marker shape:
+
+- `:filled_triangle`, `:open_triangle`, `:filled_diamond`,
+  `:open_diamond`, `:open_arrow`, `:none`
+
+Each shape is rendered as a 4-point `<polygon>` with the
+appropriate fill color.
+
+The marker anchor is the END of the polyline (target) or the
+START (source). The marker is rotated to align with the line's
+direction at that end.
+
+## Files
+
+- `lib/ea/svg/marker_resolver.rb`
+- `lib/ea/svg/marker_shapes.rb` (one class per shape)
+- Update `lib/ea/svg/ea_emitter/markers.rb`
+- `spec/ea/svg/marker_resolver_spec.rb`
+
+## Verification
+
+- Spec: Association → filled triangle at target.
+- Spec: Generalization → open triangle at target.
+- Spec: Composition → filled diamond at source + filled triangle
+  at target.

data/TODO.diagrams/06-connector-labels.md

@@ -0,0 +1,49 @@
+# 06 - Connector Labels (Role Names + Multiplicities)
+
+## Status: DONE (2026-07-21, folded into TODO 03)
+
+## Problem
+
+EA renders labels on connectors at four canonical positions:
+
+- `LLB` (lower-left, near source) — source role name
+- `LLT` (upper-left, near source) — source multiplicity
+- `LRB` (lower-right, near target) — target role name
+- `LRT` (upper-right, near target) — target multiplicity
+
+Each label has CX/CY (size), OX/OY (offset from the connector
+endpoint), plus font/style flags.
+
+Our current renderer emits no connector labels at all. The
+information is in the XMI geometry string but never extracted.
+
+## Approach
+
+Extend the XMI adapter's geometry parser to also extract the four
+label boxes, each as an `Ea::Model::LabelBox` with:
+
+- `role` (:source_name, :source_multiplicity, :target_name,
+  :target_multiplicity)
+- `text` (decoded from the model's relationship ends)
+- `offset_x`, `offset_y` (from OX/OY)
+- `width`, `height` (from CX/CY)
+
+The emitter renders each label as `<text>` at the appropriate
+offset from the connector endpoint.
+
+For QEA sources, the same data is in the connector's `SourceRole`
+and `DestRole` notes + cardinality fields.
+
+## Files
+
+- `lib/ea/model/label_box.rb`
+- `lib/ea/sources/xmi/extension_geometry_parser.rb` (extend)
+- `lib/ea/svg/ea_emitter/labels.rb` (extend)
+- `spec/ea/sources/xmi/extension_geometry_parser_spec.rb`
+- `spec/ea/svg/ea_emitter/labels_spec.rb`
+
+## Verification
+
+- Spec: known geometry string yields 4 label boxes with correct
+  offsets.
+- Visual: connector labels appear at the same positions as EA.

data/TODO.diagrams/07-canvas-size-and-viewbox.md

@@ -0,0 +1,39 @@
+# 07 - Canvas Size + viewBox Computation
+
+## Status: DONE (2026-07-21, folded into TODO 03)
+
+## Problem
+
+EA's root `<svg>` element declares `width="Xcm" height="Ycm"` and
+`viewBox="0 0 W H"`. The cm dimensions are computed from the
+union of all element `image_bounds` (the padded bounds), with
+~25 px padding around the canvas. The viewBox is in pixel units.
+
+Our current renderer computes a viewBox from the union of element
+bounds + connectors, but doesn't emit cm dimensions.
+
+## Approach
+
+`Ea::Svg::EaEmitter::Canvas` computes:
+
+1. Union of all element `image_bounds` (NOT logical bounds — EA's
+   canvas size is based on the visual padding).
+2. Adds 10 px outer margin.
+3. Emits viewBox = "min_x min_y width height".
+4. Emits width/height in cm as `width / 28.346` (72 DPI conversion).
+
+The canvas module is also responsible for translating the
+coordinate space if min_x/min_y are non-zero (EA's convention is
+to keep the viewBox starting at 0,0 by translating all elements).
+
+## Files
+
+- `lib/ea/svg/ea_emitter/canvas.rb`
+- `spec/ea/svg/ea_emitter/canvas_spec.rb`
+
+## Verification
+
+- Spec: known element set produces expected viewBox and cm
+  dimensions.
+- Visual: SVG opens in a viewer at the same physical size as EA's
+  output.

data/TODO.diagrams/08-visual-regression-harness.md

@@ -0,0 +1,34 @@
+# 08 - Visual Regression Harness
+
+## Status: DONE (2026-07-21)
+
+## Problem
+
+"Matches EA's SVG" is a fuzzy target. We need an automated way to
+detect regressions and measure fidelity.
+
+## Approach
+
+A spec that:
+
+1. Loads `plateau_all_packages_export.xmi`.
+2. For each diagram in the XMI's extension block, locates the
+   matching EA reference SVG in
+   `mn-samples-plateau/sources/001-mds/xmi-images/`.
+3. Renders our SVG for the same diagram.
+4. Compares structurally (canonicalized XML diff ignoring
+   whitespace and attribute order).
+5. Reports: which diagrams match exactly, which have structural
+   differences, which have only attribute differences.
+
+Not a hard-fail spec; produces a report we can track over time.
+Once fidelity is high enough, tighten to a hard threshold.
+
+## Files
+
+- `spec/ea/svg/visual_regression_spec.rb`
+- `spec/support/svg_canonicalizer.rb`
+
+## Verification
+
+- Run produces a report; not asserting 100% match initially.

data/TODO.diagrams/09-cli-render-all-diagrams.md

@@ -0,0 +1,25 @@
+# 09 - CLI: Render All Diagrams from a Source
+
+## Status: DONE (2026-07-21)
+
+## Problem
+
+`ea svg NAME FILE` renders one named diagram. For batch
+regeneration of all diagrams (e.g. plateau-model deploy), we need
+a way to render every diagram in a source file.
+
+## Approach
+
+Add `ea svg --all FILE [--output-dir=PATH]` mode. Iterates every
+diagram in the model, names the output file by diagram id (e.g.
+`EAID_0016F797_....svg`).
+
+## Files
+
+- `lib/ea/cli/command/svg.rb` (extend)
+- `spec/ea/cli/svg_command_spec.rb`
+
+## Verification
+
+- `ea svg --all plateau.xmi --output-dir=/tmp/svgs` produces one
+  SVG per diagram.

data/TODO.diagrams/10-stereotype-color-config.md

@@ -0,0 +1,29 @@
+# 10 - Stereotype Color Configuration (QEA fallback)
+
+## Status: DONE (2026-07-21)
+
+## Problem
+
+When the source is QEA, the element's BCol is often the default
+white. EA picks stereotype-based colors at render time when BCol
+is not set. Our renderer currently hard-codes a stereotype →
+color map, which is fragile.
+
+## Approach
+
+Externalize the stereotype → color map to a YAML configuration
+file (`config/stereotype_colors.yml`). Users can override per
+project.
+
+The XMI source carries BCol directly from EA, so the config only
+applies when BCol is missing (QEA sources without style data).
+
+## Files
+
+- `config/stereotype_colors.yml`
+- `lib/ea/svg/stereotype_color_resolver.rb`
+- `spec/ea/svg/stereotype_color_resolver_spec.rb`
+
+## Verification
+
+- Custom YAML overrides default map.

data/TODO.diagrams/11-elkrb-auto-layout-integration.md

@@ -0,0 +1,53 @@
+# 11 - ElkRb Auto-Layout Integration
+
+## Status: TODO (post-PR #24)
+
+## Problem
+
+The current Ea::Svg::EaEmitter renders diagrams from the placement
+data captured by the source adapter (QEA's t_diagramobjects /
+t_diagramlinks, XMI's <xmi:Extension>/<elements>). When the source
+doesn't carry placement data — or when the user wants to re-layout
+an existing diagram — there's no fallback.
+
+Eclipse Layout Kernel (ELK) is the standard auto-layout library for
+node-link diagrams (UML class diagrams, flowcharts, etc.). `elkrb`
+is a pure-Ruby implementation in `/Users/mulgogi/src/claricle/elkrb/`.
+
+## Approach
+
+Build an `Ea::Layout::ElkAdapter` that:
+
+1. Translates an `Ea::Model::Document` (or a subset — packages,
+   classifiers, relationships) into elkrb's `Graph` / `Node` /
+   `Edge` model.
+2. Runs the chosen elkrb algorithm (`Layered` for class diagrams
+   is the Sugiyama-style default; `Force` for organic; `Stress`
+   for high-quality).
+3. Reads back the computed positions and writes them into an
+   `Ea::Model::Diagram` (with DiagramElement bounds and
+   DiagramConnector waypoints computed by elkrb's edge router).
+
+Then the standard `Ea::Svg::EaEmitter` renders the layout-posed
+diagram just like an EA-authored one. No renderer changes needed.
+
+CLI surface:
+- `ea layout FILE [--algorithm=layered|force|stress]` — runs
+  auto-layout, emits a JSON of computed positions
+- `ea svg NAME FILE --layout=auto` — runs layout then renders
+
+## Files
+
+- `lib/ea/layout.rb` (namespace)
+- `lib/ea/layout/elk_adapter.rb`
+- `lib/ea/layout/document_to_graph.rb`
+- `lib/ea/layout/graph_to_diagram.rb`
+- `lib/ea/cli/command/layout.rb`
+- `spec/ea/layout/*_spec.rb`
+
+## Verification
+
+- Spec: known small document → elk graph → known layout output.
+- Spec: QEA fixture with no placement data → auto-layout produces
+  non-overlapping positions.
+- Spec: round-trip — auto-layout, render to SVG, no errors.

data/config/stereotype_colors.yml

@@ -0,0 +1,15 @@
+# Stereotype → fill color map. Used by Ea::Svg when an element's
+# BCol is missing (e.g. QEA sources without style data, or XMI
+# elements whose BCol defaulted).
+#
+# Format: <stereotype_lowercase>: "#RRGGBB"
+# Hex colors must be CSS-compatible (uppercase).
+featuretype: "#FFFFCC"  # yellow
+feature: "#FFFFCC"
+type: "#CCFFCC"         # green
+datatype: "#FFCCFF"     # pink
+basictype: "#FFCCFF"
+codelist: "#FFCCFF"
+enumeration: "#FFCCFF"
+union: "#F0E68C"        # khaki
+adeelement: "#F5F5DC"   # beige

data/lib/ea/cli/app.rb

@@ -88,7 +88,13 @@ module Ea
       desc "svg NAME FILE", "Render a diagram from QEA/XMI to standalone SVG"
       option :output, **OUTPUT_OPTION,
              desc: "Output path (default: <basename>.<diagram>.svg)"
-      def svg(name, file)
+      option :mode, type: :string, default: "ea",
+                    desc: "Output mode: ea (default, matches EA SVG structure) | thin (compact)"
+      option :all, type: :boolean, default: false,
+                   desc: "Render every diagram in the source file (NAME ignored)"
+      option :output_dir, type: :string,
+                          desc: "Directory for --all output (default: <basename>.svgs/)"
+      def svg(name = nil, file = nil)
         Command::Svg.new(name: name, file: file, **symbolize(options)).call
       end
 

data/lib/ea/cli/command/svg.rb

@@ -5,15 +5,29 @@ require "fileutils"
 module Ea
   module Cli
     module Command
-      # `ea svg NAME FILE [--output=PATH]`
+      # `ea svg NAME FILE [--output=PATH] [--mode=ea|thin]`
+      # `ea svg --all FILE [--output-dir=PATH] [--mode=ea|thin]`
       #
-      # Renders a single diagram from a QEA or XMI file into a
-      # standalone SVG using the umldi content (placed element
-      # bounds + connector waypoints) captured in Ea::Model::Diagram.
+      # Renders one (NAME) or every (--all) diagram from a QEA or
+      # XMI file into standalone SVG using the umldi content
+      # (placed element bounds + connector waypoints) captured in
+      # Ea::Model::Diagram.
+      #
+      # Default emitter is EaEmitter::Document which mirrors EA's SVG
+      # structure (DOCTYPE, layered groups, EA-style markers). Pass
+      # --mode=thin for the simpler Renderer output.
       class Svg < Base
         def call
+          return render_all if options[:all]
+
+          render_one
+        end
+
+        private
+
+        def render_one
           diagram = find_diagram
-          svg = Ea::Svg::Renderer.new(diagram,
+          svg = emitter_for_mode.new(diagram,
                                        model_index: document.index_by_id).render
 
           output_path = resolve_output_path(diagram)
@@ -23,7 +37,37 @@ module Ea
           formatter.render([[output_path]], columns: [:written_to])
         end
 
-        private
+        def render_all
+          out_dir = options[:output_dir] || default_output_dir
+          FileUtils.mkdir_p(out_dir)
+          paths = document.diagrams.map do |diagram|
+            svg = emitter_for_mode.new(diagram,
+                                         model_index: document.index_by_id).render
+            path = File.join(out_dir, "#{diagram.id}.svg")
+            File.write(path, svg)
+            path
+          end
+
+          formatter.render(paths.map { |p| [p] }, columns: [:written_to])
+        end
+
+        def default_output_dir
+          base = File.basename(file_path, ".*")
+          dir = File.dirname(file_path)
+          File.join(dir, "#{base}.svgs")
+        end
+
+        def emitter_for_mode
+          case (options[:mode] || :ea).to_sym
+          when :ea
+            Ea::Svg::EaEmitter::Document
+          when :thin
+            Ea::Svg::Renderer
+          else
+            raise Ea::Cli::UnsupportedFormat,
+                  "Unknown svg mode: #{options[:mode]}"
+          end
+        end
 
         def document
           @document ||= build_model_document