ea 0.4.0 → 0.5.1

data/TODO.diagrams/19-connector-sx-sy-routing.md

@@ -0,0 +1,27 @@
+# 19 - Connector Source/Target Edge Routing from SX/SY/EX/EY
+
+## Status: DONE (2026-07-23)
+
+## Outcome
+
+`ConnectorRouter` now accepts `source_delta` and `target_delta`
+(defaulting to [0,0]). `DiagramBuilder#compute_waypoints` passes
+SX/SY/EX/EY from the parsed geometry to the router, which applies
+them as deltas to the edge-attachment point.
+
+`ExtensionGeometryParser.Placement` already exposed `sx`, `sy`,
+`ex`, `ey` — just plumbs them through.
+
+## Remaining diff
+
+Waterway connectors still show ~20 px y-offset vs EA reference
+(643 vs 663). The SX/SY deltas are small (-21 to 150) and don't
+account for this gap. EA likely uses a different attachment
+formula (not strict edge center) — possibly offset by half
+font-height or other rendering consideration. Deferred to deeper
+reverse-engineering.
+
+## Files changed
+
+- `lib/ea/svg/connector_router.rb` — source_delta / target_delta support
+- `lib/ea/sources/xmi/diagram_builder.rb` — passes deltas to router

data/TODO.diagrams/19-replace-respond-to-with-is-a.md

@@ -0,0 +1,31 @@
+# TODO-D 19: Replace respond_to? with is_a? (encapsulation)
+
+## Problem
+
+`Ea::Svg::EaEmitter::Labels#connector_stereotype` uses
+`respond_to?(:stereotype)`:
+
+```ruby
+def connector_stereotype(connector)
+  rel = model_index ? model_index[connector.relationship_ref] : nil
+  stereotype = rel&.respond_to?(:stereotype) ? rel.stereotype : nil
+  return nil if stereotype.nil? || stereotype.to_s.empty?
+  "«#{stereotype}»"
+end
+```
+
+`respond_to?` is duck-typing that hides type errors until runtime.
+Per the project rules: use `is_a?` for type checks, or design the
+type hierarchy so the check isn't needed.
+
+## Fix
+
+`Ea::Model::Relationship` (base class) now declares `stereotype` as
+an attribute. All concrete relationship subclasses inherit it. So
+the check should be `rel.is_a?(Ea::Model::Relationship)`.
+
+## Acceptance
+
+- No `respond_to?` calls in `lib/`.
+- Connector stereotype labels still render correctly.
+- Specs pass.

data/TODO.diagrams/20-split-labels-emitter.md

@@ -0,0 +1,56 @@
+# TODO-D 20: Split Labels emitter into MECE collaborators
+
+## Problem
+
+`Ea::Svg::EaEmitter::Labels` currently handles three distinct
+responsibilities:
+
+1. Connector midpoint stereotype labels (e.g. «import»).
+2. End-label role + «property» + multiplicity rendering.
+3. Geometry box parsing and position resolution.
+
+These change for different reasons:
+
+- Midpoint rendering changes when EA's connector stereotype
+  conventions change.
+- End-label rendering changes when role-name / multiplicity
+  rules change.
+- Box parsing changes when the QEA geometry format changes.
+
+MECE violation: the three concerns overlap inside one class. OCP
+violation: adding a new label kind (e.g. connector name above the
+midpoint) requires editing Labels rather than registering a new
+collaborator.
+
+## Fix
+
+Introduce a small LabelRenderer registry:
+
+```
+Ea::Svg::EaEmitter::Label
+  ├─ EndLabel    (role + «property» + mult at LLT/LRT boxes)
+  ├─ MidpointLabel (stereotype at path midpoint)
+  └─ Registry    (dispatch by relationship kind / connector flag)
+```
+
+`Labels#texts_for` becomes:
+
+```ruby
+def texts_for(connector)
+  points = waypoint_pairs(connector)
+  return [] if points.size < 2
+
+  Label::Registry.for(connector, model_index: model_index)
+                 .flat_map { |r| r.texts(connector, points) }
+end
+```
+
+Each renderer is independently testable. New label kinds are added
+by registering, not by editing Labels (OCP).
+
+## Acceptance
+
+- Three discrete classes; each has its own spec.
+- No behavior change (parity text overlap ≥ 87%).
+- Existing labels spec still passes.
+- New midpoint label spec covers the «import» path.

data/TODO.diagrams/20-visibility-glyph-font-encoding.md

@@ -0,0 +1,27 @@
+# 20 - Visibility Glyph Font (Plus Sign in Monospace)
+
+## Status: DONE (2026-07-23)
+
+## Outcome
+
+Three text-encoding fixes:
+1. Visibility marker now emits as `+ ` (with trailing space) —
+   matches EA's text content exactly.
+2. Namespace separator in type names converted to `::` (UML
+   standard) — `gml:CodeType` → `gml::CodeType`.
+3. Abstract class names no longer get double underscore when the
+   source name already starts with `_` (e.g. `_Feature` stays
+   `_Feature`, not `__Feature`).
+
+## Remaining gap
+
+Text counts overshoot ref on diagrams where the source classifier
+has more `ownedAttribute` entries than EA displays. EA truncates the
+visible attribute list (likely a per-diagram display filter or box-
+size fit), while we render every property. This is a content-
+filtering concern, not an encoding concern — deferred.
+
+## Files changed
+
+- `lib/ea/svg/ea_emitter/elements.rb` — `abstract_name`,
+  `namespace_double_colon`, `split_visibility` updates

data/TODO.diagrams/21-aggregation-navigability-arrow.md

@@ -0,0 +1,21 @@
+# 21 - Aggregation Navigability Arrow at Part End
+
+## Status: DONE (2026-07-23)
+
+## Outcome
+
+`Markers#marker_specs` for Aggregation/Composition now returns TWO
+Specs:
+- Diamond polygon at whole end
+- Arrow path at part end
+
+Document interleaves line + diamond + arrow per aggregation
+connector (via `count_for` API + `pair_per_connector`).
+
+Waterway path count: 15 → 21 (ref=20, within ±1).
+Bridge polygon+path counts now within ±2 of ref.
+
+## Files changed
+
+- `lib/ea/svg/ea_emitter/markers.rb` — `marker_specs` returns Array, `count_for` API
+- `lib/ea/svg/ea_emitter/document.rb` — `pair_per_connector` interleave

data/TODO.diagrams/21-auto-generated-legend-block.md

@@ -0,0 +1,65 @@
+# TODO-D 21: Auto-generated legend block
+
+## Problem
+
+EA renders a "凡例" (Legend) block in many diagrams that contain
+color-coded stereotype elements. The block contains:
+
+- A rounded-corner container rect (`rx=3`)
+- 3 color swatch rects (`17×17`)
+- A bold 12pt #003060 title "凡例"
+- Three 9pt #003060 lines naming the source packages
+
+Reference SVG example (EAID_0016F797):
+
+```xml
+<rect x="485" y="368" width="194" height="120" rx="3.00"/>
+<rect x="495" y="398" width="17" height="17"/>  <!-- swatch 1 -->
+<rect x="495" y="417" width="17" height="17"/>  <!-- swatch 2 -->
+<rect x="495" y="436" width="17" height="17"/>  <!-- swatch 3 -->
+<text x="546.00" y="387.00" font-weight:700 font-size:12pt>凡例</text>
+<text x="517.00" y="410.00">GMLに定義されたクラス</text>
+<text x="517.00" y="429.00">CityGMLに定義されたクラス</text>
+<text x="517.00" y="448.00">i-URに定義されたクラス</text>
+```
+
+The block is NOT modeled in the QEA schema. There is no "Legend"
+Object_Type, no t_lists row, no StyleEx flag tied to it.
+
+## Investigation Notes
+
+- 27 Note objects in the QEA, none contains "凡例".
+- 5 Text objects in the QEA, all empty Note field.
+- The legend titles and swatch colors vary per diagram but follow
+  a fixed vocabulary: GML, CityGML, i-UR.
+- The color swatches are the stereotype fill colors of elements
+  visible in the diagram (e.g. FFCFFF for CityGML, CCFFCC for GML).
+
+## Hypothesis
+
+EA's "Diagram Legend" feature is a built-in diagram decoration
+that auto-generates when:
+
+1. The diagram contains elements whose stereotype maps to a
+   known "package source" (GML, CityGML, i-UR).
+2. The user has placed a Legend UI element (which EA serializes
+   somewhere we haven't found yet — possibly t_image or a binary
+   blob).
+
+Without reverse-engineering EA.exe's legend code path or finding
+the serialization, replicating this verbatim is high-risk.
+
+## Status
+
+Deferred. Pinned in the parity report (TODO.diagrams/
+17-remaining-parity-gaps.md) as a known ~448-text gap.
+
+## Acceptance (when picked up)
+
+- Locate the legend serialization in the QEA (table + column).
+- Model `Ea::Model::Legend` with `position`, `title`, `entries`
+  (each entry: color + label).
+- Build `Ea::Svg::EaEmitter::Legend` renderer producing the
+  container rect + swatch rects + texts.
+- Specs cover: empty legend, single-entry, three-entry.
+- Parity text overlap climbs above 90%.

data/TODO.diagrams/22-ghost-element-discriminator.md

@@ -0,0 +1,57 @@
+# TODO-D 22: Ghost element discriminator
+
+## Problem
+
+EA renders some elements as "ghosts": smaller font (7pt), gray
+text (#595959), no attribute/operation/tag compartments. The
+discriminator is unclear.
+
+## Empirical Observations
+
+| Diagram            | Element                    | ObjectStyle                                          | Rendered as |
+|--------------------|----------------------------|------------------------------------------------------|-------------|
+| 位置図C0301        | _UrbanFunction             | NSL=0;LCol=-1;...font=Yu Gothic UI;...               | Full        |
+| 位置図C0301        | MultiSurface               | NSL=0;BFol=-1;...fontsz=0;bold=0;... (no font=)      | Ghost       |
+| CityGMLCore        | _Feature                   | NSL=0;BCol=-1;BFol=-1;LCol=-1;LWth=-1;fontsz=0;...   | Ghost       |
+| urf_4              | _UrbanFunction             | NSL=0;BFol=-1;LCol=-1;fontsz=0;bold=0;... (no font=) | **Full**    |
+| 都市計画決定情報   | _UrbanFunction             | NSL=0;LCol=-1;bold=0;... (no font=)                  | Ghost       |
+
+The presence or absence of `font=` is **not** the discriminator
+(urf_4 elements lack `font=` but render full attributes).
+
+`BCol` value is **not** the discriminator (urf_4 has explicit
+BCol=16777215; MultiSurface in 位置図C0301 has BCol=13434828).
+
+Classifier `package_id` vs diagram `package_id` is **not** the
+discriminator (urf_4 cross-package elements get full attrs;
+CityGMLCore cross-package elements get ghost).
+
+## Hypothesis To Test
+
+1. **Diagram-level "is reference" flag**: maybe EA marks diagrams
+   that only show snapshots of an external model. The discriminator
+   could be `t_diagram.SPT=1` (already 1 in all observed diagrams)
+   combined with another flag.
+
+2. **Element-level "Link" semantics**: maybe elements placed as
+   "links" rather than embedded get ghost styling. The QEA may
+   encode this in t_diagramlinks.Path or t_object.Documentation
+   style flags we haven't parsed.
+
+3. **t_objectstatistics or t_objectproperties**: an explicit "ghost
+   mode" tagged value.
+
+## Status
+
+Deferred. Without EA.exe disassembly or empirical testing inside
+the EA GUI, the rule cannot be confidently derived.
+
+## Acceptance (when picked up)
+
+- Open the QEA in EA GUI, toggle the "Link" vs "Embed" property
+  on an element, observe the rendered SVG, and identify the QEA
+  field that changes.
+- Implement a `ghost?` predicate on `Ea::Model::DiagramElement`
+  using the discovered field.
+- Wire through `Elements` emitter to apply ghost styling.
+- Specs cover both ghost and full paths.

data/TODO.diagrams/22-style-based-path-grouping.md

@@ -0,0 +1,28 @@
+# 22 - Style-Based Path Grouping
+
+## Status: DONE (2026-07-23)
+
+## Outcome
+
+`Connectors` emitter now supports `group_by_style:` constructor
+option. When true, consecutive connectors with the same line style
+are merged into a single `<g>` element with multiple `<path>` kids
+(matching EA's encoding for diagrams with many similarly-styled
+connectors).
+
+Default behavior remains per-entity grouping (one `<g>` per
+connector) to preserve z-order interleaving with markers.
+
+## Usage
+
+```ruby
+# Default: per-entity groups (current behavior)
+Connectors.new(diagram, canvas: canvas)
+
+# EA-style grouped:
+Connectors.new(diagram, canvas: canvas, group_by_style: true)
+```
+
+## Files changed
+
+- `lib/ea/svg/ea_emitter/connectors.rb` — `group_by_style` option + `grouped_groups`

data/TODO.diagrams/23-marker-polygon-deduplication.md

@@ -0,0 +1,47 @@
+# TODO-D 23: Marker polygon deduplication rules
+
+## Problem
+
+EA's rules for emitting polygon markers when multiple connectors
+share an endpoint are non-obvious.
+
+## Empirical Observations
+
+Aggregate across 188 reference SVGs:
+- Total polygons: 1485
+- Exact-duplicate polygons (same points string): **536** (36%)
+
+EA duplicates polygon markers in many cases but not always. The
+discriminator is unclear.
+
+## Experiments Tried
+
+| Strategy                    | Polygon delta | Within-tol |
+|-----------------------------|---------------|------------|
+| Anchor-based dedup (current)| -166 (-11.2%) | 123/188 (65.4%) |
+| No dedup                    | +257 (+17.3%) | 139/188 (73.9%) |
+| Exact-body dedup            | +247 (+16.6%) | 141/188 (75.0%) |
+
+Both "no dedup" and "exact-body dedup" improve within-tolerance
+diagram count (+13%) but introduce polygon overshoot. Anchor-based
+dedup has best polygon delta but lower diagram-tol rate.
+
+## Hypothesis To Test
+
+EA likely has per-marker-per-connector emission for `Path=`-routed
+connectors (each visible link emits its own markers) but deduplicates
+markers that share an anchor AND belong to connectors sharing a
+common segment.
+
+The QEA stores a `Path=` field on t_diagramlinks; connectors that
+share the same visual path are co-rendered. We currently treat
+each t_diagramlinks row independently.
+
+## Acceptance (when picked up)
+
+- Correlate polygon duplicates with shared `Path=` values.
+- Implement per-diagram `grouped:` mode selection in Markers.
+- Specs cover: distinct anchors (no dedup), shared anchor + shared
+  path (dedup), shared anchor + distinct path (no dedup).
+- Polygon delta within ±20 (currently -166).
+- Within-tolerance diagrams ≥ 75% (currently 65.4%).

data/TODO.diagrams/23-multiplicity-label-positioning.md

@@ -0,0 +1,29 @@
+# 23 - Diagram-Level Multiplicity Label Positioning
+
+## Status: DONE (2026-07-23)
+
+## Outcome
+
+Refactored `Ea::Svg::EaEmitter::Labels` to emit per-end role name +
+multiplicity using LLB (left label box) / LLT (left label text) and
+RLB / RLT offsets from the connector geometry.
+
+Uses UML convention: the role visible at one end of the connector is
+the property owned by the OPPOSITE classifier. So LLT (near source)
+shows the target-end property; RLT (near target) shows the source-
+end property.
+
+Each label emits as TWO `<text>` elements matching EA's encoding:
+one for the role name (`+roleName`) and one for the multiplicity
+(`0..1`).
+
+## Files changed
+
+- `lib/ea/svg/ea_emitter/labels.rb` — full rewrite with model_index,
+  association_ends, label_position, role_text, multiplicity_text
+- `lib/ea/svg/ea_emitter/document.rb` — passes `model_index` to Labels
+
+## Outcome metrics
+
+Text count mean abs diff dropped from 20 → 14 across 185 diagrams.
+Waterway: 92 → 103 (ref=113). CityFurniture: 24 → 30 (ref=34).

data/TODO.diagrams/24-marker-anchor-structural.md

@@ -0,0 +1,35 @@
+# TODO-D 24: Track marker anchors structurally
+
+## Problem
+
+`Ea::Svg::EaEmitter::Markers#anchor_key` parses the SVG string the
+class itself just emitted in order to deduplicate entries by their
+anchor point:
+
+```ruby
+def anchor_key(body)
+  match = body.match(/polygon points="(-?[\d.]+)\s+(-?[\d.]+)|path d="M (-?[\d.]+)\s+(-?[\d.]+)/)
+  return body unless match
+  ...
+end
+```
+
+This is fragile:
+
+- Round-trip through string parsing for data we already had
+  structurally.
+- Regex assumes EA's exact SVG attribute ordering and whitespace.
+- Hard to test in isolation (must build the body string first).
+
+## Fix
+
+Add `anchor` to the `Entry` struct. Capture it when the entry is
+built (we already have `tip` at that point). Dedup on
+`Entry#anchor` rather than re-parsing the body.
+
+## Acceptance
+
+- `Entry` struct carries `[x, y]` anchor.
+- `anchor_key` method removed; dedup uses `Entry#anchor` directly.
+- Markers specs continue to pass.
+- Parity polygon delta unchanged.

data/TODO.diagrams/24-track-marker-anchors-structurally.md

@@ -0,0 +1,66 @@
+# TODO-D 24: Track marker anchors structurally (DONE)
+
+## Before
+
+`Markers#anchor_key` parsed the rendered SVG string with regex to
+extract the marker's anchor coordinates:
+
+```ruby
+def anchor_key(body)
+  match = body.match(/polygon points="(-?[\d.]+)\s+(-?[\d.]+)|path d="M (-?[\d.]+)\s+(-?[\d.]+)/)
+  return body unless match
+  x = (match[1] || match[3]).to_f.round
+  y = (match[2] || match[4]).to_f.round
+  [x, y]
+end
+```
+
+That mixes "data" (the anchor) with "presentation" (the rendered
+string), and it parses the same SVG twice. Re-introducing the
+anchor as a Ruby value fixes both.
+
+## After
+
+`Markers::Entry` is now a Struct that carries the anchor alongside
+the body, with hash/eql? defined so `Array#uniq` collapses by
+anchor without touching the SVG:
+
+```ruby
+Entry = Struct.new(:style_key, :body, :anchor, keyword_init: true) do
+  def hash
+    anchor.hash
+  end
+
+  def eql?(other)
+    other.is_a?(Entry) && anchor == other.anchor
+  end
+end
+```
+
+`entries_for` computes the anchor once when building the Entry:
+
+```ruby
+def anchor_for(spec)
+  tx, ty = translate_point(spec.anchor)
+  [tx.round, ty.round]
+end
+```
+
+## Benefits
+
+- **Performance**: one anchor computation per marker instead of
+  a regex match per dedup pass.
+- **Type safety**: anchor is a `[Integer, Integer]` pair, not a
+  parsed fragment of a String.
+- **Encapsulation**: rendered SVG never re-parsed.
+- **Testability**: `Entry#eql?` is unit-testable in isolation.
+
+## Tests
+
+- `spec/ea/svg/ea_emitter/markers_entry_spec.rb` covers anchor
+  equality, deduplication, and false-positive guards.
+
+## Bench
+
+Unchanged: rect -221, path -280, polygon -6, text -601,
+overlap 64.5%. The refactor is behavior-preserving.

data/TODO.diagrams/24-truncate-properties-to-fit-box.md

@@ -0,0 +1,24 @@
+# 24 - Truncate Properties to Fit Box (Match EA Display)
+
+## Status: DONE (2026-07-23)
+
+## Outcome
+
+Discovered the actual rule: EA hides properties that are navigable
+ends of an association (those are rendered as connector lines, not
+as attribute text). This is NOT box-fit truncation — it's a content
+filter based on property semantics.
+
+## Implementation
+
+1. Added `association_id` field to `Ea::Model::Property` (non-nil
+   when the property is a navigable end of an Association).
+2. `Ea::Sources::Xmi::PropertyBuilder` captures `attr.association`.
+3. `Ea::Svg::EaEmitter::Elements#displayable_properties` rejects
+   properties with `association_id` set.
+
+## Files changed
+
+- `lib/ea/model/property.rb` — `association_id` attribute + JSON mapping
+- `lib/ea/sources/xmi/property_builder.rb` — populate `association_id`
+- `lib/ea/svg/ea_emitter/elements.rb` — `displayable_properties` filter

data/TODO.diagrams/26-phantom-general-parent-rendering.md

@@ -0,0 +1,59 @@
+# TODO-D 26: Phantom general-parent rendering
+
+## Problem
+
+The reference SVGs contain class headers (`_AbstractGeometricAggregate`,
+`_CityObject`, `_FeatureCollection`, etc.) that do NOT appear in
+`t_diagramobjects` for the diagram. ~150 missing text instances
+across the plateau dataset.
+
+## Empirical Rule (partial)
+
+When a class is placed in a diagram, EA also displays its
+generalization parent if the parent isn't already in the diagram.
+
+Validation across 188 diagrams:
+
+- Total parent-checks: 241
+- Parent rendered in SVG: 129 (53.5%)
+
+53.5% match suggests the rule is "right idea, wrong details." Other
+factors:
+
+- Per-element font/style override may suppress phantom rendering
+  when the parent's style isn't explicit
+- The discriminator may be tied to AttPkg / SuppressFOC flags
+- EA may only render one level up the generalization chain
+
+## Implementation Sketch
+
+Add `phantom_generalizations_for(diagram, model_index)` returning
+phantom DiagramElements with synthetic bounds (placed near their
+child). Render them through the existing `groups_for` path so they
+participate in the same compartment math, color resolution, etc.
+
+```ruby
+def ordered_elements
+  placed = (diagram.elements || []).sort_by { |e| e.z_order || 0 }
+  placed + phantom_elements(placed)
+end
+
+def phantom_elements(placed)
+  placed_ids = placed.map(&:model_element_ref)
+  parents = placed_ids.flat_map { |id| generalizations_of(id) }.uniq - placed_ids
+  parents.map { |pid| phantom_diagram_element(pid) }
+end
+```
+
+The hard part is positioning: EA computes phantoms at coordinates
+we cannot derive without GUI testing or sample-data correlation.
+
+## Acceptance
+
+- Render general-parent phantoms for at least the cases where the
+  rule applies cleanly.
+- Phantom bounding box is plausible (within canvas extents).
+- Parity text overlap climbs to ~90%+.
+- Specs cover: parent not in diagram (phantom added), parent
+  already in diagram (no duplicate), phantom appears in correct
+  sub-layer.

data/TODO.diagrams/27-path-grouping-mode-detection.md

@@ -0,0 +1,43 @@
+# TODO-D 27: Per-diagram path grouping mode detection
+
+## Problem
+
+EA emits connector paths in two styles:
+
+1. **Grouped** — All same-style paths joined into one `<g>` block
+   (matches what we currently do in `LayerSequencer#merge_layers_by_style`).
+2. **Per-connector** — Each connector path in its own `<g>` block.
+
+Some diagrams use one mode, others use the other. We always use
+grouped, contributing to the -181 path delta.
+
+## Investigation
+
+Tested in StyleEx flags — no obvious "grouped" toggle. EA's
+emit-mode decision appears to be runtime/export-time, not stored in
+the QEA.
+
+## Empirical Observations
+
+- Grouped-style diagrams: 0 to 5 path-delta diagrams (most match)
+- Per-connector-style diagrams: 10-30 path-delta (we're missing 10-30
+  `<g>` wrappers)
+
+The discriminator might be:
+
+- Diagram export-time option set in EA GUI at export
+- Per-diagram count threshold (more connectors → per-connector)
+- User preference cached in some EA-specific location we can't access
+
+## Status
+
+Deferred. Without empirical access to EA's export preferences or a
+binary blob in the QEA, the mode detection is speculative.
+
+## Acceptance (when picked up)
+
+- Identify the QEA field or runtime condition that controls grouping.
+- Implement a per-diagram detector.
+- Wire into LayerSequencer: `grouped: detect_grouped_mode(diagram)`.
+- Specs cover: small diagrams → grouped, large diagrams → per-connector.
+- Path delta within ±20 of zero.

data/TODO.diagrams/28-architecture-cleanup-batch.md

@@ -0,0 +1,47 @@
+# TODO-D 28-31: Architectural cleanup batch
+
+## Completed (this session)
+
+### 28. Canvas promoted to proper class
+
+`lib/ea/svg/ea_emitter/canvas.rb` was a `Struct.new + do ... end`
+block. Promoted to an explicit class with `attr_reader` for the
+four bound fields. Public API is now named rather than implicit;
+the type stays immutable.
+
+8 new specs cover `translate_x`, `translate_y`, `.coord`,
+immutability, and the existing `.from` factory.
+
+### 29. OpenStruct removed
+
+`elements.rb#translate_bounds` returned an `OpenStruct.new`. This
+required `require "ostruct"` at the top of the file and obscured
+the return type.
+
+Now returns `Ea::Model::Bounds.new` directly — the existing model
+value object — and the `require "ostruct"` line is removed. Type
+flows cleanly through the pipeline (model → renderer).
+
+### 31. Specs for under-tested components
+
+- `spec/ea/svg/ea_emitter/canvas_spec.rb` — added `translate_x`,
+  `translate_y`, `.coord`, and immutability specs.
+- `spec/ea/svg/ea_emitter/layer_spec.rb` — new file (10 specs).
+- `spec/ea/svg/ea_emitter/background_spec.rb` — new file (3 specs).
+
+## Deferred
+
+### 30. Decompose Elements groups_for
+
+`Elements#groups_for` is ~100 lines of linear rendering steps.
+Two previous attempts to extract a helper method broke 5+ specs
+due to complex parameter threading (model_element vs classifier
+distinction, Optional bounds, theme plumbing).
+
+The method reads as a recipe: each step adds one output string.
+Linear recipes are easier to read as one method than as a chain
+of helper calls with overlapping parameter lists.
+
+Deferred until a structural refactor (e.g. a Compartments
+collaborator that holds rendering state) is justified by a new
+requirement.