ea 0.3.1 → 0.5.0

data/TODO.diagrams/79-architecture-backlog.md

@@ -0,0 +1,65 @@
+# TODO-D 79: Architecture improvements backlog
+
+## Status: open (rolling)
+
+A list of architecture / code-quality improvements surfaced while
+closing parity gaps. Each is shippable independently.
+
+## 1. Elements#build_context decomposition
+
+`Elements#build_context` (lib/ea/svg/ea_emitter/elements.rb) is
+~50 lines and growing. It now also resolves the off-canvas parent
+name, adding a new concern. Extract collaborators:
+
+  - `HeaderInputResolver` — gathers inputs for HeaderLines
+    (visually_nested, parent_name, umldi_keyword, bounds_width).
+  - `CompartmentInputResolver` — gathers attr_lines/op_lines/etc.
+
+Each returns a small Struct; `build_context` just assembles them
+into the RenderContext.
+
+## 2. RenderContext struct field count
+
+RenderContext carries 23 keyword fields. Some are mutually relevant
+(e.g., `attr_lines` and `geometry.attr_lines_count`). Consider
+grouping:
+
+  - `HeaderInput` struct (header_lines, off_canvas_parent_name)
+  - `CompartmentInput` struct (attr_lines, op_lines, enum_literals,
+    tagged_values, constraints, package_content_lines)
+
+Fewer top-level fields, clearer purpose per group.
+
+## 3. Phantom connector label boxes
+
+`DiagramBuilder::DEFAULT_LABEL_BOXES` is a constant in the builder.
+The geometry belongs on the synthesized DiagramConnector model
+field (e.g., `default_label_offsets: true`). Currently the
+`has_geometry_offsets` flag conveys this for one case; generalize.
+
+## 4. LayerSequencer dependency threading
+
+LayerSequencer takes `document:` and threads it to multiple
+collaborators (Labels, Elements). The collaborators individually
+re-fetch relationships from the document. A precomputed per-diagram
+"parent_index" (child_id → parent_id) built once at DiagramBuilder
+time would remove the per-render relationship scan.
+
+## 5. public_send in Qea::Repositories::BaseRepository
+
+`BaseRepository` uses `public_send(attr)` for dynamic attribute
+dispatch. This is intentional metaprogramming (the attribute name
+is data), not type-checking. But it's worth documenting with a
+comment so future readers don't mistake it for the forbidden
+private-send pattern.
+
+## 6. Spec coverage for new code
+
+New code added in TODO-D 71 (off-canvas parent ghost line):
+  - `Elements#off_canvas_parent_name_for` — no spec
+  - `Elements#parent_generalization_for` — no spec
+  - `Elements#parent_package_represented_on_diagram?` — no spec
+  - `HeaderLines` italic prepend — covered indirectly via existing
+    header_lines_spec.
+
+Add specs for the three Elements methods.

data/TODO.diagrams/80-basic-triangle-polygons.md

@@ -0,0 +1,51 @@
+# TODO-D 80: Basic.qea Generalization triangle markers as polygons
+
+## Status: open (initial hypothesis disproven)
+
+On 4 basic.qea diagrams ("Basic Class Diagram with Attributes",
+"Operations", "Receptions", "Attributes and Operations"), ref
+shows 2 extra triangle `<polygon>` markers per diagram that we
+emit as `<path>` arrows instead.
+
+## Per-diagram delta
+
+  - Attributes:    -2 polygons (and +2 paths)
+  - Operations:    -2 polygons (and +2 paths)
+  - Receptions:    -2 polygons (and +2 paths)
+  - Attributes+Operations: -2 polygons (and +2 paths)
+  - Multiplicities: -1 polygon
+  - Roles:         -1 polygon
+  - Package Dependencies: +3 polygons (over-render — likely
+    package_import marker issue)
+  - Domain Model:  +1 polygon
+
+Net basic polygon delta: -6.
+
+## Initial hypothesis (DISPROVEN)
+
+Tried: emit `:triangle` instead of `:arrow` for Association with
+direction="Unspecified".
+
+Result: Over-corrected. basic polygons went from -6 to +15 because
+many basic.qea "Unspecified" Associations DO want arrow markers,
+not triangles. The discriminator must be narrower.
+
+## Next investigation
+
+The 4 failing diagrams share: 2 Association connectors, both
+"Unspecified", connecting Class A → Class B.
+
+Inspect what distinguishes these from other "Unspecified"
+Associations on basic.qea that DO render arrows correctly.
+Possibilities:
+  - The connector's sourcecard/destcard (multiplicity)
+  - The connector's sourceaccess/destaccess
+  - The presence of a Name vs anonymous
+  - The t_diagramlinks geometry (Path=, SX/SY/EX/EY)
+
+## Related
+
+basic.qea path over-render (+6) is the mirror image — same 6
+markers counted as paths instead of polygons. Closing one closes
+the other.
+

data/TODO.diagrams/81-plateau-path-overrender.md

@@ -0,0 +1,53 @@
+# TODO-D 81: Plateau path over-render on ifc_3 (+3) and similar diagrams
+
+## Status: open
+
+Several plateau diagrams render extra short horizontal `<path>`
+elements (110-300px wide) that don't appear in EA's reference
+SVG. The paths look like compartment dividers but appear at
+positions where ref doesn't emit them.
+
+## Per-diagram delta
+
+  - ifc_3: +3 paths
+  - utility network: -4 paths (different issue — missing phantom
+    connector paths)
+  - GenericObject: -5 paths (same as utility network)
+  - cons_1: +2 paths
+  - bldg:Buildingの拡張属性（LOD4）: +2 paths
+  - bldg:Roomの拡張属性（LOD4）: +2 paths
+  - udx: +2 paths
+  - Urban Planning ADE2: +1 path
+  - CityObjectGroupの拡張属性: +1
+  - その他の構造物: +1
+  - 位置図_C09_2: +1
+
+## Pattern analysis (ifc_3)
+
+Our extra paths at the same x range (218-438), varying y:
+  - M 218 394 L 438 394
+  - M 218 438 L 438 438
+  - M 218 463 L 438 463
+  - M 218 507 L 438 507
+
+These look like 4 dividers in 4 different elements stacked
+vertically. Ref's element layout differs (different y values),
+suggesting our canvas/element y-offsets diverge from EA's.
+
+## Hypothesis
+
+Either:
+1. Our divider emission logic fires for elements that EA treats
+   as header-only (no divider).
+2. Our canvas y-offset is off for some diagrams, causing dividers
+   to land at "wrong" y values that don't match ref.
+
+## Next step
+
+For each affected diagram:
+1. Compare element bounds (our placement vs ref's).
+2. Compare divider_y values.
+3. Identify whether it's a positioning issue or a divider-logic
+   issue.
+
+This is the largest remaining path-delta contributor.

data/TODO.diagrams/82-appearance-canvas-offset.md

@@ -0,0 +1,54 @@
+# TODO-D 82: Plateau Appearance diagram — canvas offset mismatch
+
+## Status: open
+
+The "Appearance" diagram (BC1F7E00 / C31C1314 — there are 2
+versions) has 2 extra `<rect>` elements at positions that don't
+match EA's reference.
+
+## Symptom
+
+  Our rects:                Ref rects:
+    (35, 379) w=214 h=70      (35, 680) w=214 h=70
+    (45, 479) w=208 h=70      (45, 580) w=208 h=70
+
+Both elements (TransformationMatrix3x4 and TransformationMatrix2x2)
+are placed on the diagram (stereotype="dataType", 16 placed
+elements total). Ref renders them at y=580/680, we render at
+y=379/479 — a delta of ~200 px.
+
+## Root cause hypothesis
+
+My `BoundsCalculator` computes canvas min_y = -1169 (lowest
+element y -1154 minus MARKER_EXTENT 15). Reference's implied
+min_y = -1470 (calculated from element model y -830 + render y 680
++ inset 40).
+
+The 301-px difference suggests EA includes additional geometry
+(extended labels, image-bounds padding, or some other source) in
+its canvas bound computation that we don't.
+
+## Why fixing this is hard
+
+The BoundsCalculator is shared across all diagrams. A change here
+affects every diagram's canvas. If the missing bound source is
+diagram-specific (e.g., only DataType elements with certain
+styles trigger it), the fix would need conditional logic.
+
+## Likely related
+
+  - Polygon positions on Appearance also differ — triangles at
+    different anchors (might be connector endpoint mismatch
+    due to wrong canvas translate).
+  - Other diagrams with rect_delta > 0 may share the same offset
+    issue.
+
+## Next step
+
+1. Identify what additional geometry EA's bounds include for
+   Appearance. Candidates:
+     - Connector label box extents (LLB/LRT geometry)
+     - Element image_bounds vs logical bounds handling
+     - Phantom connector waypoint contributions
+2. Test by adding the candidate source to BoundsCalculator and
+   verifying the canvas min_y matches.

data/TODO.diagrams/83-3d-diagram-subtitle.md

@@ -0,0 +1,58 @@
+# TODO-D 83: 3D diagram subtitle over-render (3 phantom subtitles)
+
+## Status: open
+
+The "3D都市モデル応用スキーマと他のスキーマとの関係" diagram
+shows 4 placed packages:
+
+  - Inner "3D都市モデル" (parent: outer "3D都市モデル")
+  - i-UR (parent: Conceptual Models)
+  - CityGML2.0 (parent: Conceptual Models)
+  - gml (parent: Conceptual Models)
+
+EA reference renders 0 "(from X)" subtitles. Our code renders
+3 (the inner 3D都市モデル was suppressed by the name-match rule
+in commit cf3dcf2; the other 3 still over-render).
+
+## Compared to udx
+
+udx diagram shows 3 placed packages:
+
+  - 都市計画データ (parent: 3D都市モデル)
+  - i-UR (parent: Conceptual Models)
+  - CityGML2.0 (parent: Conceptual Models)
+
+EA reference renders 3 subtitles. So udx and 3D have similar
+structure but opposite subtitle behavior.
+
+## What differs
+
+The diagrams have similar PDATA/StyleEx (both Package type,
+HideParents=0). The ONLY visible difference: 3D includes a
+placed element (inner 3D都市モデル) whose parent shares its name
+with itself.
+
+## Hypothesis (untested)
+
+When ANY placed package has a parent whose name collides with
+another package's name in the diagram, EA suppresses all
+subtitle rendering for that diagram. The reasoning: name
+collisions confuse subtitle interpretation, so safer to omit.
+
+Alternatively: a flag in t_diagram or t_diagramobjects that
+we're not yet parsing.
+
+## Investigation block
+
+This rule cannot be safely derived from one example. Closing
+this gap requires either:
+1. Finding the rule from additional EA reference outputs (with
+   different package-name configurations).
+2. Reverse-engineering EA's source code for the subtitle logic.
+3. Per-diagram manual tuning (not scalable).
+
+## Related
+
+  - TODO-D 75: plateau text under-render (-36 / -37 after this
+    fix). The 3D diagram contributes +3 (or +4 pre-fix) to the
+    text count discrepancy.

data/TODO.diagrams/84-canvas-offset-mismatches.md

@@ -0,0 +1,61 @@
+# TODO-D 84: Per-diagram canvas-offset / positioning mismatches
+
+## Status: open (rolling)
+
+Multiple plateau diagrams have small per-shape deltas (1-5 shapes
+each) where my rendered positions differ from EA's reference.
+The shape COUNTS are correct, but specific shapes are at the wrong
+coordinates.
+
+## Affected diagrams (sample)
+
+  - utility network: -4 paths (canvas height off: ours 1156 vs ref 1156)
+  - GenericObject: -5 paths (canvas width off: ours 872 vs ref 772)
+  - ifc_3: +3 paths (frame dimensions match but divider y-positions off)
+  - Appearance: +2 rects (canvas height off by 36px)
+  - cons_1: +2 paths
+  - bldg:Buildingの拡張属性（LOD4）: +2 paths
+  - bldg:Roomの拡張属性（LOD4）: +2 paths
+
+## Common pattern
+
+Canvas dimensions or coordinate offsets differ by a small amount
+(10-300 px). Once the canvas offset differs, every shape's
+position shifts, producing both "extra" and "missing" paths at
+slightly different coordinates.
+
+## Likely root cause areas
+
+1. `BoundsCalculator` includes element + connector + marker +
+   package_tab points. EA may include ADDITIONAL geometry (label
+   boxes, image bounds extensions, etc.) that we miss.
+
+2. The MARKER_EXTENT padding (15 px) may differ from EA's actual
+   padding for certain connector/marker combinations.
+
+3. Element `image_bounds` handling: when an element has image
+   bounds below its logical bounds, my code includes those points.
+   EA may handle this conditionally.
+
+## Why this is hard to fix incrementally
+
+A change to BoundsCalculator affects EVERY diagram's canvas. A
+fix that improves one diagram may regress others. Requires
+identifying the precise missing bound source and applying
+conditionally.
+
+## Strategy
+
+1. Pick one diagram (e.g. Appearance).
+2. Reverse-engineer its canvas height from the reference.
+3. Identify what geometry would produce that canvas height.
+4. Add the missing bound source to BoundsCalculator.
+5. Verify no regression on other diagrams.
+
+Repeat for each affected diagram pattern.
+
+## Related
+
+  - TODO-D 82: Appearance-specific investigation
+  - TODO-D 81: path over-render investigation
+  - TODO-D 73: polygon under-render

data/TODO.diagrams/85-phantom-property-overrender.md

@@ -0,0 +1,95 @@
+# TODO-D 85: Phantom connector «property» over-render on selected diagrams
+
+## Status: open
+
+Several plateau diagrams over-render the «property» stereotype
+text (and associated role + multiplicity labels) for PHANTOM
+Aggregation connectors — synthesized when both endpoints are
+placed but no t_diagramlinks entry exists.
+
+## Per-diagram «property» delta
+
+| Diagram | Ours | Ref | Diff |
+|---|---|---|---|
+| indoor | 10 | 10 | 0 ✓ |
+| brid_1 | 12 | 11 | +1 |
+| CityGMLCore | 4 | 2 | +2 |
+| veg | 16 | 11 | +5 |
+
+## What's known
+
+- Phantom Aggregation connectors get `DEFAULT_LABEL_BOXES`
+  (LLT/LLB geometry) in `DiagramBuilder#build_phantom_connector`.
+- This geometry triggers `EndLabel#texts` to emit role +
+  «property» + multiplicity labels.
+- The `property_label?` check gates on direction
+  ("Source -> Destination" or "Destination -> Source" → render;
+  "Unspecified" / "Bi-Directional" → suppress).
+- On indoor, all 9 phantom Aggregations with non-empty
+  SourceRole correctly render «property» in ref.
+- On brid_1, 3 phantom Aggregations have non-empty SourceRole
+  but ref renders «property» for only 2 of them.
+
+## Discriminator candidates (untested)
+
+1. Source class stereotype — maybe «dataType» sources render
+   «property» but other stereotypes don't.
+2. Source class's attribute compartment visibility — maybe
+   sources with hidden attribute compartments don't render
+   «property» labels.
+3. Destination class's attribute compartment — similar.
+4. A specific t_connector flag (SourceAccess, DestAccess,
+   Pursposes, etc.) that we don't yet parse.
+5. Connector has a Style flag indicating label visibility.
+
+## Investigation update (2026-08-02)
+
+brid_1's over-render is NOT from phantom connectors — brid_1
+has 11 EXPLICIT t_diagramlinks for Aggregations. The over-render
+is from the role-fallback logic in `EndLabel#texts`:
+
+  Connector 424 (DataQualityAttribute -> _AbstractBridge):
+    - Geometry has LLT/LLB (source end) AND LRT (target end)
+    - SourceRole = "bridDataQualityAttribute"
+    - DestRole = empty
+
+  My code:
+    - Source end: LLT present + role present → renders role + «property»
+    - Target end: LRT present + role empty → FALLBACK to source role
+      → renders role + «property» AGAIN at LRT position
+
+  Ref:
+    - Source end: renders role + «property» (matches my code)
+    - Target end: NOTHING (despite LRT geometry present)
+
+## Tested fix (REVERTED)
+
+Tried restricting role fallback to only fire when text_box is
+also missing. Result: text delta went from -40 to -154 — the
+fallback is needed for many OTHER cases (114 valid labels rely
+on it).
+
+## The actual discriminator (needed)
+
+EA likely considers LRT geometry "stale" when:
+  - The geometry has unusual offset (e.g., OY=315 for connector
+    424, vs typical ±50)
+  - OR the connector's direction makes the target end non-navigable
+
+The "unusual offset" rule is fragile. A more principled rule
+would require parsing additional t_diagramlinks fields or
+comparing against EA's internal "dirty" flag.
+
+## Strategy
+
+For each affected diagram, identify which connectors have LRT
+geometry but no target role, and trace the LRT offset. If a
+threshold rule (e.g., |OY| > 100) cleanly separates valid from
+invalid, apply it.
+
+## Related
+
+  - TODO-D 75: plateau text under-render (current -40)
+  - TODO-D 81: plateau path over-render
+  - lib/ea/svg/ea_emitter/label/end_label.rb (property_label?)
+  - lib/ea/sources/qea/diagram_builder.rb (DEFAULT_LABEL_BOXES)

data/TODO.diagrams/86-foreign-package-rule.md

@@ -0,0 +1,62 @@
+# TODO-D 86: Foreign-package rule over-suppression (parent-ghost)
+
+## Status: open (rolling)
+
+The current `parent_package_represented_on_diagram?` check in
+`lib/ea/svg/ea_emitter/elements.rb` suppresses the off-canvas
+parent-class italic ghost line when ANY placed element shares
+the parent's package. This rule was added to fix the Building
+diagram's spurious _Feature/_AbstractGeometricAggregate ghosts.
+
+## Trade-off
+
+  | Rule state | Text delta | Effect |
+  |---|---|---|
+  | Rule ENABLED (current) | -40 | Some valid ghosts suppressed |
+  | Rule DISABLED | +60 | Some invalid ghosts rendered |
+
+Net: rule removes 100 ghosts total (60 invalid + 40 valid).
+
+## Hypotheses tested (all DISPROVEN)
+
+  1. **Package match** (current rule) — over-suppresses
+  2. **Parent name in diagram name** — too narrow
+  3. **Parent stereotype vs child stereotype** — all cases have
+     identical stereotypes, no discriminator
+  4. **Parent abstract flag** — both abstract and non-abstract
+     parents render on indoor; both don't on Building
+  5. **Parent's package_id is top-level** — all parents are
+     top-level; no discriminator
+
+## Valid vs invalid samples
+
+| Diagram | Child | Parent | Parent pkg | Renders in ref? |
+|---|---|---|---|---|
+| indoor | Room | _CityObject | core | YES |
+| indoor | _AbstractBuilding | _Site | core | YES |
+| tran_2 | TrafficVolumeAttribute | RoadAttribute | uro | YES |
+| bldg_1 | BuildingDetailAttribute | BuildingAttribute | uro | YES |
+| Building | Address | _Feature | gml | NO |
+| Building | _CityObject | _Feature | gml | NO |
+| Building | _Solid | _GeometricPrimitive | gml | NO |
+
+The discriminator between YES (render) and NO (suppress) cases
+is NOT in t_object, t_connector, or any field we currently parse.
+
+## Remaining candidates (untested)
+
+1. A per-element flag in t_diagramlinks or t_diagramobjects
+   (e.g., a per-element "show parent" flag).
+2. A diagram-level StyleEx flag we haven't decoded.
+3. The depth of the inheritance chain (immediate parent vs
+   grandparent).
+4. A Package-level attribute (e.g., "abstract package" vs
+   "concrete package").
+
+## Strategic block
+
+The discriminator requires either EA source access or
+significant reference-SVG triangulation. Each additional rule
+attempted in this conversation has either over-suppressed
+valid cases or under-suppressed invalid ones. The current rule
+is the best trade-off found.

data/TODO.diagrams/87-internal-tech-encryption.md

@@ -0,0 +1,80 @@
+# TODO-D 87: Reverse-engineer EA's InternalTechnologies encryption
+
+## Status: open (encryption scheme unidentified)
+
+EA's `InternalTechnologies/*.xml` files (66 files including
+`GML_Tech.xml`) are stored in an encrypted/compressed format.
+These contain stereotype icon definitions for built-in technologies
+(GML, UML, SysML, BPMN, etc.) — including the FeatureType icon
+needed for the polygon -4 parity gap.
+
+## File format analysis
+
+  - File: GML_Tech.xml, 3076 bytes
+  - First bytes: 30 c6 3c f8 e4 d6 4b fd e0 dd 36 f5 57 84 8d 7b
+  - NOT standard compression (zip/gzip/zlib headers absent)
+  - NOT valid XML
+
+## Hypotheses tested (all FAILED)
+
+| Approach | Result |
+|---|---|
+| Single-byte XOR (256 keys) | No valid `<?xml` start |
+| Multi-byte XOR assuming `<?xml version=` start | Key derives but doesn't repeat |
+| zlib inflate at offsets 0-63 with wbits -15/-14/15/31/47 | No valid output |
+| Byte rotation then zlib | No valid output |
+| Byte subtraction (delta 1-255) then zlib | No valid output |
+| XOR with position index | No valid output |
+| Position-reversed XOR | No valid output |
+| Add position modulo 256 | No valid output |
+
+## Byte frequency analysis
+
+Byte distribution at position mod 4 is fairly uniform (each byte
+value appears 7-9 times per position). This is consistent with
+**strong encryption** (AES, RC4, etc.) rather than simple XOR.
+
+## EA.exe binary analysis
+
+Located `MDGTechnology.cpp` debug tag at offset 0x4584684 in
+EA.exe. Found references to `CryptEncrypt`/`CryptDecrypt` Windows
+APIs and `aes_encrypt`/`aes_decrypt` SQL functions.
+
+Searched EA.exe (70MB binary) for plaintext GML technology
+content (`<MDG.Technology`, `ApplicationSchema`, `GML::FeatureType`,
+`FeatureType`) — **zero matches**. The plaintext is NOT embedded
+in the binary.
+
+Extracted 19MB `.rsrc` section via `wrestool`. Contains many
+`BSTRING` resources (UI strings, etc.) but none contain MDG
+technology XML.
+
+## Decryption options (none trivial)
+
+1. **Run EA via Wine** to call the COM API:
+   `Repository.GetTechnologyByClassID(...)` then export. Requires
+   CrossOver/Wine GUI session — non-trivial setup.
+
+2. **Ghidra/IDA disassembly** of MDGTechnology.cpp routine:
+   locate the decryption function, identify the algorithm and
+   hardcoded key. Requires reverse-engineering expertise and
+   10+ hours of analysis.
+
+3. **Debugger capture**: run EA under `winedbg`, set breakpoint
+   at file-read for GML_Tech.xml, trace until plaintext appears
+   in memory, dump it. Requires Wine debugging setup.
+
+4. **Side-channel acquisition**: ask Sparx Systems support for
+   the technology definition (they may provide it).
+
+## Recommendation
+
+The polygon -4 parity gap is small (4 missing stereotype
+decorator icons across 188 diagrams). The effort to reverse-
+engineer EA's encryption significantly exceeds the value of
+closing this gap.
+
+Recommend: DEFER this work until either:
+- A user provides plaintext MDG exports from EA
+- The `ea` gem adds Wine-based extraction as an optional feature
+- A security researcher publishes the EA encryption scheme

data/TODO.diagrams/EXAMPLES_STATUS.md

@@ -0,0 +1,88 @@
+# Examples parity report (2026-07-28)
+
+`rake svg:examples` benches every QEA in `examples/qea/` against
+its matching exports/Images directory.
+
+## Headline
+
+| Example | Matched | Perfect | Notes |
+|---------|---------|---------|-------|
+| simple  | 2/2     | **2**   | 100% parity |
+| ArcGISWorkspace_template | 5/6 | 5 | Workspace diagram has decorative icons |
+| basic   | 19/22   | 8       | Visibility icons + Object instance format missing |
+| test    | 1/2     | 1       | Test Model diagram needs visibility icons |
+
+**15 of 27 renderable example diagrams are at 100% parity.**
+
+## Per-example breakdown
+
+### simple.qea — 100% ✓
+
+```
+simple  2/2 matched
+  rect    ours=8  ref=8  delta=0
+  path    ours=3  ref=3  delta=0
+  polygon ours=12 ref=12 delta=0
+  text    ours=22 ref=22 delta=0
+```
+
+Both diagrams (`Simple Package Diagram`, `Simple Class Diagram`)
+render byte-identical element counts.
+
+### ArcGISWorkspace_template — 5/6 perfect
+
+Only `ArcGIS Workspace` diagram has deltas (-2 rect, -7 path).
+The 7 missing paths are decorative "data icon" paths (small
+horizontal lines + dots) inside one element's attribute
+compartment. Canvas height calc is also slightly off (641 vs 600).
+
+### basic.qea — 8/22 perfect, 19/22 within tolerance
+
+**Perfect diagrams:**
+- Package Contents
+- Package Dependencies
+- Package B
+- Basic Class Diagram with Multiplicities
+- Signals
+- Two Level Class Type Hierarchy with Attributes
+- Two Level Class Composition Hierarchy with Attributes
+- Composition with Substitution
+
+**Remaining gaps (concentrated in 3 areas):**
+
+1. **Visibility icons** (Test Model diagram in test.qea +
+   Package Imports + Object with Value Specifications in basic):
+   EA renders 3 elements per attribute row (outer rect 11x14 +
+   inner rect 11x4 + horizontal divider path). Implementing this
+   would close ~25 rects and ~15 paths across examples.
+
+2. **Object instance format** (Objects as Instances of Classes +
+   Object with Value Specifications): EA renders
+   `Object 01 / roleOne: Class A` and `attribute = value` slot
+   format. We render the qualified class name only.
+
+3. **Decorative data icons** (ArcGIS Workspace): "Hamburger menu"
+   icons (3 horizontal lines + dots). Specific to ArcGIS template.
+
+### test.qea — 1/2 perfect
+
+- `TestSchema` diagram: 100%
+- `Test Model` diagram: needs visibility icons + Package element
+  attribute rendering
+
+## How to run
+
+```
+bundle exec rake svg:examples
+```
+
+Outputs per-example bench in a single table. Run after every
+renderer change to catch regressions in any example.
+
+## Architecture
+
+The `rake svg:examples` task auto-discovers QEA files in
+`examples/qea/` and matches them with ref directories in
+`examples/exports/<name>/{images,Images}/`. Uses the existing
+`Ea::Svg::Parity::Suite` with `Ea::Sources::Qea::IdNormalizer`
+for diagram-id → SVG-filename resolution.