ea 0.4.0 → 0.5.1

data/TODO.diagrams/65-path-coordinate-frame.md

@@ -0,0 +1,62 @@
+# TODO-D 65: Path coordinate frame mismatch (y-axis sign)
+
+## Status: open
+
+Elements render at the wrong vertical position because
+`bounds_from_rect` interprets `RectTop` as the math-convention
+y (negative, larger=lower) when EA actually stores it as the
+negation of the screen-space y (negative, larger=higher).
+
+The bench's shape_delta_total doesn't catch this because counts
+match — but per-path coordinate comparison shows every ref path
+is "missing" from our output (coordinate values differ).
+
+## Evidence (plateau QEA, "Bridge" diagram)
+
+Raw EA rect for `_CityObject`:
+- RectLeft=611, RectTop=-64, RectRight=941, RectBottom=-186
+
+Reference SVG renders `_CityObject` text at `y=73`.
+
+Our model produces `bounds.y = -186` (taking `min(RectTop, RectBottom)`).
+After canvas translation we render at `y > 1000` (bottom of canvas).
+
+The correct interpretation is:
+- screen-y of element's top edge = `-RectTop = 64`
+- height = `RectTop - RectBottom = -64 - (-186) = 122`
+
+With a small offset (33 in basic.qea, 9 in plateau Bridge) we'd
+match the reference's text baseline.
+
+## Approach
+
+Update `DiagramBuilder#bounds_from_rect`:
+
+```ruby
+def bounds_from_rect(obj_row)
+  left = obj_row.rectleft || 0
+  right = obj_row.rectright || 0
+  top = obj_row.recttop || 0
+  bottom = obj_row.rectbottom || 0
+  Ea::Model::Bounds.new(
+    x: [left, right].min,
+    y: -[top, bottom].max,  # flip y-axis
+    width: (right - left).abs,
+    height: (bottom - top).abs
+  )
+end
+```
+
+Then rework `Canvas#translate_y` and `BoundsCalculator` to use
+positive y values consistently. The current min_y computation
+also needs to flip.
+
+This is a large change — needs careful re-verification against
+basic.qea and test.qea to avoid regressing the 24/24 currently
+matched.
+
+## Impact
+
+Doesn't change counts (and so won't move the bench needle), but
+makes the visual output match EA positionally. Required before
+we can claim "100% identical to QEA->SVG" in any visual sense.

data/TODO.diagrams/67-path-coordinate-frame.md

@@ -0,0 +1,62 @@
+# TODO-D 67: Path coordinate frame (y-axis sign)
+
+## Status: open
+
+Elements render at the wrong vertical position because
+`bounds_from_rect` interprets `RectTop` as the math-convention
+y (negative, larger=lower on screen) when EA actually stores
+it as the negation of the screen-space y.
+
+The bench's shape_delta_total doesn't catch this because counts
+match — but per-path coordinate comparison shows every ref path
+is "missing" from our output (coordinate values differ).
+
+## Evidence (plateau QEA, "Bridge" diagram)
+
+Raw EA rect for `_CityObject`:
+- RectLeft=611, RectTop=-64, RectRight=941, RectBottom=-186
+
+Reference SVG renders `_CityObject` text at `y=73`.
+
+Our model produces `bounds.y = -186` (taking `min(RectTop, RectBottom)`).
+After canvas translation we render at `y > 1000` (bottom of canvas).
+
+The correct interpretation is:
+- screen-y of element's top edge = `-RectTop = 64`
+- height = `RectTop - RectBottom = -64 - (-186) = 122`
+
+With the canvas's positive offset (40 frame inset + diagram-specific),
+we match the reference's text baseline.
+
+## Approach
+
+Update `DiagramBuilder#bounds_from_rect`:
+
+```ruby
+def bounds_from_rect(obj_row)
+  left = obj_row.rectleft || 0
+  right = obj_row.rectright || 0
+  top = obj_row.recttop || 0
+  bottom = obj_row.rectbottom || 0
+  Ea::Model::Bounds.new(
+    x: [left, right].min,
+    y: -[top, bottom].max,  # flip y-axis
+    width: (right - left).abs,
+    height: (bottom - top).abs
+  )
+end
+```
+
+Then rework `Canvas#translate_y` and `BoundsCalculator` to use
+positive y values consistently. The current min_y computation
+also needs to flip.
+
+This is a large change — needs careful re-verification against
+basic.qea and test.qea to avoid regressing the 184/188 currently
+matched.
+
+## Impact
+
+Doesn't change counts (and so won't move the bench needle), but
+makes the visual output match EA positionally. Required before
+we can claim "100% identical to QEA->SVG" in any visual sense.

data/TODO.diagrams/68-inherited-attributes.md

@@ -0,0 +1,65 @@
+# TODO-D 68: Association-derived virtual properties (phantom attributes)
+
+## Status: open (discriminator unresolved)
+
+EA renders some association SourceRole values as virtual
+"property" attributes inside the source classifier's attribute
+compartment. For example, ImplicitGeometry has 4 associations to
+CityFurniture with SourceRoles lod1..4ImplicitRepresentation.
+EA renders "+lod1ImplicitRepresentation" inside ImplicitGeometry's
+attribute compartment on every diagram where ImplicitGeometry is
+placed with an expanded attribute compartment.
+
+## Investigation findings
+
+The phantom attributes come from t_connector.SourceRole on
+Association and Aggregation connectors. In the plateau QEA:
+- 206 Aggregations have SourceRoles
+- 172 Associations have SourceRoles
+
+Not all SourceRoles render as virtual attributes. The discriminator
+that gates rendering has NOT been identified. Adding all 378
+SourceRoles as properties causes massive over-rendering (text
+delta: +20,000). The correct subset is much smaller.
+
+### What was tried
+
+1. **All SourceRoles as properties**: text +20k — far too many.
+   The vast majority of SourceRoles do NOT render in EA output.
+
+2. **Only when connector NOT on current diagram**: incorrect —
+   on the ImplicitGeometry diagram, the lod* connectors ARE on
+   the diagram AND the phantom attrs still show.
+
+3. **Only for GML stereotypes (Type/FeatureType)**: promising
+   but not all "Type" stereotyped classifiers show SourceRole
+   attrs on every diagram. CityGMLCore shows ImplicitGeometry
+   WITHOUT the lod texts (element is in collapsed mode).
+
+### What's known
+
+- SourceRoles render ONLY when the element's attribute compartment
+  is visible AND expanded (has NSL/font settings in ObjectStyle).
+- The position of phantom attr texts in the ref SVG is OUTSIDE
+  any element rect (floating) on some diagrams, suggesting EA
+  places them at connector-label positions rather than inside
+  the attribute compartment.
+- Multiple phantom attrs at the same position suggests overlap
+  rendering (all at same x,y) which is characteristic of connector
+  end-labels, not attribute-compartment lines.
+
+### Next steps
+
+1. Investigate whether the phantom attrs are actually connector
+   LABELS (from $LLB/$LLT geometry) rather than attribute
+   compartment lines. The position (412, 473) doesn't match any
+   element's attribute compartment area.
+
+2. Check if the phantom attrs come from a per-diagram setting
+   like "Show inherited/association attributes" flag in the
+   t_diagram StyleEx or PDATA.
+
+3. If they ARE attribute-compartment lines (not labels),
+   identify the precise subset of SourceRoles that EA renders
+   (maybe only when the connector's DestRole is empty AND the
+   SourceRole matches a naming convention).

data/TODO.diagrams/69-package-anchor-conditional.md

@@ -0,0 +1,29 @@
+# TODO-D 69: Package anchor marker conditional rendering
+
+## Status: completed
+
+The «import» connector's package_anchor marker (4-point closed
+trapezoid at the source end) was rendered unconditionally,
+causing 9 phantom paths on the plateau "Urban Planning ADE2"
+diagram.
+
+## Root cause
+
+EA's t_diagramlinks.Geometry string carries explicit SX/SY/EX/EY
+offset fields when the connector has been explicitly configured
+with edge-attachment offsets. When SX/SY are absent, the
+connector is auto-routed and EA suppresses the package_anchor
+marker.
+
+## Fix
+
+Added `has_geometry_offsets` boolean to DiagramConnector model.
+DiagramBuilder sets it by checking whether the raw Geometry
+string contains "SX=". PackageImport marker returns [] when
+false.
+
+## Verification
+
+- basic.qea Package Imports: SX=0;SY=0 present -> marker renders
+- plateau Urban Planning ADE2: SX/SY absent -> no marker
+- Urban Planning ADE2 delta dropped from 9 to 0 → matched

data/TODO.diagrams/70-mdg-technology-support.md

@@ -0,0 +1,68 @@
+# TODO-D 70: MDG Technology Support
+
+## Status: Phases 1 & 2 complete; Phase 3 deferred
+
+EA's MDG (Model Driven Generation) technologies bundle UML
+profiles, reference models, and toolbox definitions in a single
+XMI file. When EA loads an MDG, the MDG's classes/attributes/
+stereotypes become available to all models — including inherited
+attribute rendering when a classifier's stereotype maps to an
+MDG-defined metaclass.
+
+## Architecture (shipped)
+
+```
+Ea::Mdg                                    # standalone namespace
+  ├─ Document         # one MDG file's parsed model
+  │    ├─ ClassifierEntry  (id, name, package_name, properties)
+  │    ├─ PropertyEntry    (name, type_name, visibility, mult)
+  │    └─ GeneralizationEntry (specific_id, general_id)
+  ├─ Loader           # XMI parser → Document
+  └─ Registry         # multi-MDG lookup, ancestor walking
+```
+
+Integration:
+
+- `Ea::Sources::Qea::Adapter.from_path(path, mdg_registry: nil)`
+- When `mdg_registry:` is wired, `ClassifierBuilder#properties_for`
+  merges MDG-inherited attributes into the classifier's property
+  list.
+- Backward-compatible: omitting `mdg_registry:` preserves prior
+  behavior exactly.
+
+## Verified against reference MDG files
+
+- `MDG ISO19103.xml` (12 classifiers, 5 packages)
+- `ISO 19103 Edition 1 XML.xml` (62 classifiers, 68 generalizations,
+  properties under UML:Classifier.feature)
+- Ancestor walk yields correct inherited properties
+  (e.g. UnitsList → StandardUnits → 11 properties)
+
+## What's still needed for plateau parity
+
+The plateau phantom attributes (`+lod1ImplicitRepresentation`
+on `ImplicitGeometry`, `+boundedBy` on `_CityObject`, etc.) come
+from a **CityGML/GML MDG** that is not in the user's
+`~/src/lutaml/xmi/references/ImplementationModels/` directory.
+
+To close those specific gaps:
+1. Obtain the CityGML/GML MDG technology XML file.
+2. Pass it via `mdg_registry:` when loading the plateau QEA.
+3. The classifier's `Type` stereotype will resolve to the MDG's
+   `Type` class, and its ancestor properties will merge in.
+
+This is data-availability, not architecture. The plumbing works.
+
+## Phase 3 (deferred)
+
+- Stereotype definition extraction (UML:Profile/Stereotype) for
+  applying tagged values from MDG stereotype definitions.
+- CLI subcommand: `ea mdg list` / `ea mdg show <name>`.
+- Toolbox definition parsing (for future toolbox rendering).
+
+## Test coverage
+
+- `spec/ea/mdg/loader_spec.rb` (6 specs)
+- `spec/ea/mdg/registry_spec.rb` (8 specs)
+- `spec/ea/sources/qea/mdg_integration_spec.rb` (3 specs)
+- Total: 17 new specs; full suite 1839 examples, 0 failures.

data/TODO.diagrams/71-off-canvas-parent-ghost.md

@@ -0,0 +1,45 @@
+# TODO-D 71: Off-canvas parent class ghost line in element header
+
+## Status: completed (2026-08-01)
+
+EA prepends the off-canvas parent classifier's name as an italic
+line at the top of a placed element's header when ALL of:
+
+1. The diagram's HideParents PDATA flag is 0 (default).
+2. The placed element has a Generalization to a parent NOT placed
+   on the current diagram.
+3. No other element from the parent's package is placed on the
+   diagram (EA treats the parent's package as "represented").
+
+e.g. on the indoor diagram (HideParents=0), Room's parent
+_CityObject (in the "core" package, off-canvas, no other core
+elements placed) renders as an italic "_CityObject" line above
+Room's own header. On Building (HideParents=1), no parent ghosts
+render at all.
+
+## Implementation
+
+  - RelationshipBuilder populates Generalization.specific_id and
+    .general_id (child + parent GUIDs).
+  - Diagram model gains show_parents attribute; DiagramBuilder
+    parses HideParents= from t_diagram.PDATA.
+  - RenderContext carries off_canvas_parent_name; Elements resolves
+    it via document.relationships + model_index + diagram.elements.
+  - HeaderLines prepends [name, :italic] when the value is non-nil.
+  - LayerSequencer threads `document:` to Elements.
+
+## Plateau QEA impact
+
+  - Before: text delta -98 (98 texts missing vs ref)
+  - After:  text delta -36 (62 texts closed)
+  - 188/188 diagrams matched.
+
+## Remaining gap (-36)
+
+The foreign-package rule is slightly too aggressive — some diagrams
+(tran_2, urf_urbanFunction) render parent ghosts for parents in
+"represented" packages. Removing the foreign-package check
+over-corrects to +60 (over-render). The true discriminator is
+narrower than "package represented" but broader than just
+HideParents. Defer to a future investigation if a clearer signal
+(e.g., a t_object flag, MDG stereotype pattern) is identified.

data/TODO.diagrams/72-basic-attr-divider-paths.md

@@ -0,0 +1,39 @@
+# TODO-D 72: Spurious per-attribute divider paths on basic.qea outlier
+
+## Status: open
+
+basic.qea diagram "Two Level Class Composition Hierarchy with
+Attributes" (4FC1D352-...) over-renders 16 short horizontal <path>
+elements that the EA reference does not emit.
+
+## Symptom
+
+  - rect:  ours=18  ref=18  (matches)
+  - path:  ours=50  ref=34  (+16 overshoot)
+  - polygon: ours=17 ref=17 (matches)
+  - text:  ours=102 ref=102 (matches)
+
+## Pattern of the extra paths
+
+All 16 extras are short 110px-wide horizontal lines at evenly
+spaced y coordinates that line up with attribute rows:
+
+  - M 661 66 L 771 66
+  - M 661 152 L 771 152
+  - M 661 238 L 771 238
+  - M 487 66 L 597 66
+  - M 487 152 L 597 152
+  - ... (12 more at the same y values across 4 element columns)
+
+## Hypothesis
+
+We render per-attribute separator lines between each attribute row.
+EA only emits a single header→content divider plus the element rect
+outline; attribute rows are NOT visually separated by horizontal
+lines in EA's encoding.
+
+## Next step
+
+Audit Compartment::Attributes and DividerRenderer for any per-row
+line emission. The fix is to suppress row separators and keep only
+the header divider.

data/TODO.diagrams/73-plateau-polygon-gap.md

@@ -0,0 +1,69 @@
+# TODO-D 73: Plateau polygon under-render (-4)
+
+## Status: partially investigated (2026-08-02)
+
+Across 188 plateau diagrams, we render 4 fewer `<polygon>` elements
+than EA's reference SVG. Per-diagram deltas:
+
+  - Appearance (BC1F7E00, C31C1314): -2 each
+  - CityGMLCore (88D0CB44): -1
+  - 都市計画決定情報の概要 (8FD488EF): -1
+  - 立体的な範囲、区域界、品質属性 (1321F39B): -1
+  - 都市施設 (C96CBC24): -1
+  - 3D都市モデル応用スキーマと他のスキーマとの関係 (DFBB1072): +3
+  - udx (6481E2CC): +1
+
+## Investigation update (2026-08-02)
+
+For 都市施設 / 都市計画決定情報 / 立体的な範囲: each missing
+polygon is a small 4-point DIAMOND inside an element body.
+
+Example (都市施設):
+  `<polygon points="323 401 328 411 333 401 328 391" ...>`
+  Inside a `<g>` with fill="#FAF1EC" stroke="#69738C"
+
+These colors (#FAF1EC, #69738C) are NOT standard aggregation
+diamond colors (#FFFFFF fill, #000000 stroke). They appear to be
+**stereotype decorator icons** — small symbolic icons EA renders
+inside element bodies when a stereotype provides a custom icon.
+
+## Follow-up investigation (2026-08-02)
+
+Found EA installation at:
+  ~/Library/Application Support/CrossOver/Bottles/
+    Enterprise Architect 16.x/drive_c/Program Files/Sparx Systems/EA/
+
+Located stereotype-related files:
+  - Config/GML/GMLStereotypes.xml — only stereotype ALIASES, no icons
+  - MDGTechnologies/*.xml — many MDG files, none reference icons
+  - TemplateResources161.dll — likely contains compiled icon resources
+  - t_stereotypes table — empty Metafile BLOBs for FeatureType
+
+Found element-style flag `HideIcon=0` on FeatureType elements on
+都市施設 — confirmed EA DOES intend to show an icon.
+
+## Discriminator puzzle
+
+On 都市施設, ALL 21 placed FeatureType elements have HideIcon=0.
+But ref renders the diamond icon for only 1 of them
+(CollectiveFacilitiesForReconstruction — the largest element).
+
+The discriminator is NOT:
+- HideIcon flag (all elements have it = 0)
+- Stereotype (all are FeatureType)
+- Element size (icon position is element-relative)
+
+Hypotheses for the actual discriminator:
+1. The element is "selected" or "active" in the source QEA
+2. The element is the diagram's "subject" (a per-diagram flag)
+3. The icon is part of a legend/key, not per-element
+
+## Implementation needed
+
+To close this gap requires either:
+1. Reverse-engineering EA's stereotype decorator icon logic
+2. Parsing the EMF BLOB from t_image (1 image, 69KB)
+3. Extracting icon resources from EA.exe / TemplateResources161.dll
+
+Even then, the discriminator for WHICH elements get icons is
+unclear from available data.

data/TODO.diagrams/74-plateau-rect-gap.md

@@ -0,0 +1,22 @@
+# TODO-D 74: Plateau rect over-render (+4)
+
+## Status: open
+
+Across 188 plateau diagrams, we render 4 more `<rect>` elements
+than EA's reference SVG. Per-diagram deltas are spread thin.
+
+## Likely causes
+
+1. **Phantom connector label boxes**: my phantom connector code
+   synthesizes label boxes (LLB/LLT) that may render extra rects.
+2. **Element rect for hidden elements**: elements that should be
+   filtered (e.g., via element_filter) but still render their
+   bounding rects.
+3. **Compartment background rects**: extra rects for compartments
+   that EA suppresses in certain modes.
+
+## Next step
+
+Identify the 4 specific diagrams with rect_delta > 0 and inspect
+the actual `<rect>` content vs ref. Likely a per-diagram PDATA
+flag mismatch.

data/TODO.diagrams/75-plateau-text-gap.md

@@ -0,0 +1,39 @@
+# TODO-D 75: Plateau text under-render (-36)
+
+## Status: open (partial — closed 62 of original -98 in TODO-D 71)
+
+Across 188 plateau diagrams, we render 36 fewer `<text>` elements
+than EA's reference SVG. Top undershoot diagrams:
+
+  - tran_2 (-4): missing 2× RoadAttribute, 1× TransportationComplex,
+    1× _TransportationObject, 1× TrafficAreaAttribute
+  - urf_urbanFunction (-4): similar pattern
+  - 12 diagrams at -3 each
+  - many at -2
+
+## Root cause
+
+The foreign-package rule in `off_canvas_parent_name_for` is too
+aggressive. It suppresses parent ghosts when ANY placed element
+shares the parent's package, but EA actually renders ghosts in
+this case for diagrams like tran_2 and urf_urbanFunction.
+
+The discriminator is narrower than "package represented" — possibly
+related to whether the parent is in a base library (gml) vs a user
+package (uro, tran), or some other property of the parent class.
+
+## What was tried
+
+1. **Just HideParents flag**: closed -98 to +60 (over-rendered 60).
+2. **HideParents + foreign-package check**: closed +60 to -36
+   (under-rendered 36).
+
+The truth is between these. Narrower discriminator needed.
+
+## Deferred
+
+Requires identifying the precise EA rule. Could be:
+- A t_object flag on the parent (e.g., is it generic/template)
+- The parent's package being a "base library" (gml vs user model)
+- A specific stereotype pattern (e.g., base GML stereotypes)
+- Connector-level metadata we're not yet reading

data/TODO.diagrams/76-basic-poly-path-gaps.md

@@ -0,0 +1,41 @@
+# TODO-D 76: basic.qea polygon under-render (-6) and path over-render (+6)
+
+## Status: open
+
+After the aggregation arrow fix (TODO-D 73), basic.qea reached
+22/22 diagrams matched within tolerance, but two aggregate deltas
+remain:
+
+  - polygon: ours=95, ref=101 (-6)
+  - path: ours=208, ref=202 (+6)
+
+## Per-diagram pattern
+
+  - Package Dependencies (0EDEA6EF): polygon +3
+  - Basic Class Diagram with Attributes (4F421236): polygon -2
+  - Basic Class Diagram with Operations (2AAB709F): polygon -2
+  - Basic Class Diagram with Receptions (4DBDAB9E): polygon -2
+  - Basic Class Diagram with Attributes and Operations (D2FA55D3): polygon -2
+  - Basic Class Diagram with Multiplicities (78030266): polygon -1
+  - Basic Class Diaram with Roles (6E95B74E): polygon -1
+  - Domain Model (E325B9D8): polygon +1
+
+## Likely cause (Basic Class Diagram family)
+
+For the 4 diagrams with polygon=-2, we're missing 2 small triangle
+polygon markers per diagram. These are likely Generalization arrow
+triangles that we suppress somewhere.
+
+The +3 polygon overshoot on "Package Dependencies" is likely a
+package-import marker (anchor shape) that EA omits.
+
+## Path over-render (+6)
+
+After the aggregation arrow fix, the +16 path over-render on the
+outlier closed (to 0). The remaining +6 paths are likely from
+similar marker issues on the diagrams above.
+
+## Next step
+
+For each affected diagram, compare our markers vs ref's markers.
+Identify which marker emission is incorrect.

data/TODO.diagrams/77-basic-text-overrender.md

@@ -0,0 +1,40 @@
+# TODO-D 77: basic.qea text over-render (+2)
+
+## Status: open
+
+basic.qea's two diagrams overshoot text by 1 each:
+
+  - Classes: +1
+  - Composition with Substitution: +1
+
+## Composition with Substitution diff
+
+  Ours has:
+    +1 "Class B.3" (split qualified name part)
+    +1 "Class B.2"
+    +1 "Class B.1"
+    +1 "«property»" (spurious property stereotype)
+
+  Ref has:
+    +1 "Class B::Class B.1" (single qualified name line)
+    +1 "Class B::Class B.2"
+    +1 "Class B::Class B.3"
+
+So our qualified-name wrap is incorrectly splitting "Class B::X"
+into two lines for these nested classes. The qualified name should
+render as ONE line per element, not as "Class B::" + "X".
+
+The spurious "«property»" text appears to come from a connector
+SourceRole label that we render but ref doesn't on this diagram.
+
+## Classes diff
+
+Need to identify what specific text differs on the Classes diagram.
+
+## Next step
+
+1. Inspect why qualified-name wrap triggers for "Class B::Class B.X"
+   (likely a width estimation mismatch).
+2. Identify the connector whose SourceRole produces "«property»"
+   and apply the right suppression (similar to aggregation arrow
+   fix — only render on specific directions).

data/TODO.diagrams/78-headerlines-ocp-refactor.md

@@ -0,0 +1,65 @@
+# TODO-D 78: Refactor HeaderLines into provider chain (OCP)
+
+## Status: open (architecture improvement)
+
+The current `HeaderLines.for` accepts a growing list of kwargs:
+
+```ruby
+def for(classifier,
+        diagram_package_id: nil,
+        visually_nested: false,
+        umldi_keyword: nil,
+        bounds_width: nil,
+        font_size: 9,
+        off_canvas_parent_name: nil)  # added in TODO-D 71
+  ...
+end
+```
+
+Adding the off-canvas parent line required:
+1. A new kwarg on `for`
+2. New logic inside `for` to prepend the line
+3. Threading the value from `Elements#build_context` through `RenderContext`
+
+This is OCP-violating: each new header line variant (e.g., "realized
+interfaces", "template parameters", "constraint summary") would
+require modifying `HeaderLines.for` again.
+
+## Proposed refactor
+
+Convert `HeaderLines` into a chain of line providers, each
+contributing 0+ lines to the header. New line types = new provider
+class, registered into the chain (no modification of existing
+code).
+
+```ruby
+module Element
+  module HeaderLineProvider
+    ALL = [
+      StereotypeLine,        # «FeatureType» line (when present)
+      ParentClassLine,       # italic off-canvas parent (TODO-D 71)
+      QualifiedNameLine,     # the bold class name (with optional wrap)
+    ].freeze
+
+    def self.lines_for(classifier, context:)
+      ALL.flat_map { |provider| provider.lines_for(classifier, context) }
+    end
+  end
+end
+```
+
+Where `context` is a small Struct carrying the inputs each provider
+may need (diagram_package_id, visually_nested, off_canvas_parent_name,
+bounds_width, font_size, etc.).
+
+## Benefit
+
+Adding a new line type (e.g., "interface signatures" on Interface
+classifiers) becomes a single new provider class — `HeaderLines.for`
+never changes.
+
+## Migration
+
+Incremental: extract one provider at a time, starting with the
+off-canvas parent line (the most recent addition). Each extraction
+is independently shippable.