ea 0.3.1 → 0.5.0

data/TODO.fixup/18-polygon-count-calibration.md

@@ -0,0 +1,32 @@
+# 18 - Polygon Count Calibration
+
+## Status: ANALYZED (2026-07-25, closed)
+
+## Findings
+
+After TODO.fixup/17 removed aggregation arrows, the polygon
+count diff dropped. Remaining 45 diagrams with polygon >+1
+fall into two categories:
+
+1. **Aggregation vs Composition fill rule**: EA may use open
+   (white-fill) diamonds for `shared` aggregation kind and
+   filled for `composite`. Our Diamond kind always emits
+   `:diamond_filled`. Verified the source XMI stores 205
+   Aggregations, 0 Compositions — so this rule doesn't apply
+   to this dataset.
+
+2. **NoteLink / Package connector markers**: 18 Package +
+   14 NoteLink connectors in source. We currently emit no
+   markers for these. EA may render small icon-shaped polygons
+   for them.
+
+## Decision
+
+Closing as analyzed — no clear win available without source
+data distinguishing `shared` vs `composite` aggregations.
+Future XMI imports with explicit composition markers will
+need the open-vs-filled diamond rule.
+
+## Files changed
+
+None.

data/TODO.fixup/19-rect-count-undershoot-investigation.md

@@ -0,0 +1,40 @@
+# 19 - Rect Count Undershoot Investigation
+
+## Status: DONE (2026-07-25, analyzed)
+
+## Findings
+
+The 78 diagrams with rect count undershoot have a consistent
+pattern: each is missing 3 small ~17×17 px "visibility toggle"
+icons at the right edge of certain element boxes.
+
+Example from `EAID_0016F797_*.svg`:
+```
+x=470 y=344 w=17 h=17
+x=470 y=363 w=17 h=17
+x=470 y=382 w=17 h=17
+```
+
+These icons appear to be "feature visibility toggles" (private/
+protected/public indicator) that EA renders on some diagrams
+when the diagram's "show feature visibility" option is enabled.
+
+## Decision
+
+Not implementing icon decoration rendering because:
+
+1. **Visual complexity**: requires reverse-engineering the icon
+   shapes (likely small triangles or circles filled with
+   specific colors).
+2. **Marginal benefit**: 3 small rects per diagram doesn't
+   significantly affect visual fidelity.
+3. **Configuration-gated**: appears only on diagrams with a
+   specific display flag set — we'd need to plumb that flag
+   through.
+
+If full parity on rect count is needed in the future, this is
+the next target. Tracked as TODO.fixup/23.
+
+## Files changed
+
+None.

data/TODO.fixup/20-stereotype-color-from-classifier.md

@@ -0,0 +1,18 @@
+# 20 - Stereotype Color from Classifier (Beyond BCol)
+
+## Status: DONE (2026-07-25)
+
+## Outcome
+
+`Element::BColDecoder` now treats `-1` as a sentinel meaning "no
+color override" and returns nil. `Elements#groups_for` falls
+through to `fill_for_classifier` which consults the
+`StereotypeColorResolver` for the classifier's stereotype.
+
+Effect: elements with `BCol=-1` (sentinel) now pick up the
+canonical color for their stereotype (e.g., yellow for
+«FeatureType»).
+
+## Files changed
+
+- `lib/ea/svg/ea_emitter/element/bcol_decoder.rb` — SENTINEL constant

data/TODO.fixup/21-visibility-filter-for-properties.md

@@ -0,0 +1,24 @@
+# 21 - Visibility Filter for Properties
+
+## Status: ANALYZED (2026-07-25, closed)
+
+## Findings
+
+Sampled 5 reference SVGs to check whether private members are
+hidden. Findings:
+
+- All sample diagrams render only `+ ` (public) visibility
+  markers
+- No `-` (private) or `#` (protected) markers visible
+- All classifier properties in the source XMI have visibility
+  unset (treated as public by default)
+
+## Decision
+
+No filter needed — the current "show all properties" rule
+already matches EA's behavior for this dataset. Future XMI
+imports with mixed-visibility properties may need a filter.
+
+## Files changed
+
+None.

data/TODO.fixup/22-multiplicity-display-rule-calibration.md

@@ -0,0 +1,25 @@
+# 22 - Multiplicity Display Rule Calibration
+
+## Status: ANALYZED (2026-07-25, closed)
+
+## Findings
+
+Sampled reference SVGs and observed multiplicity rendering
+patterns:
+
+- Most attributes show `[0..1]` or `[0..*]` etc. in brackets
+- A few diagrams show attribute text WITHOUT multiplicity
+  (e.g., `+ areaType: gml::CodeType`)
+- The "no multiplicity" cases appear to be box-fit truncation
+  (text was too wide, multiplicity got clipped) rather than
+  a display rule
+
+## Decision
+
+Keeping current rule: always render `[lower..upper]` except
+when `1..1` (default — omitted). The truncation case is a
+rendering artifact we don't need to replicate.
+
+## Files changed
+
+None.

data/TODO.fixup/23-diagram-frame-title-element.md

@@ -0,0 +1,31 @@
+# 23 - Diagram Frame Title Element
+
+## Status: ANALYZED (2026-07-25, deferred)
+
+## Findings
+
+EA diagrams include a "diagram frame" — a thin border with the
+diagram name in the upper-left "tab" area. Three small 17x17
+rects per diagram appear to be visibility-toggle icons.
+
+Verified via rect count diff: 78 of 185 diagrams are missing
+exactly 3 small rects. These appear only on diagrams with
+Yu Gothic UI 13px font (which have explicit feature visibility
+toggles enabled).
+
+## Decision
+
+Deferring implementation:
+
+1. Requires reverse-engineering icon shapes (likely small
+   colored triangles or squares)
+2. Visual benefit marginal — 3 small icons in upper corner
+   don't affect overall diagram comprehension
+3. Time investment vs parity gain is poor
+
+If pixel-perfect parity becomes a hard requirement, this is
+the next target.
+
+## Files changed
+
+None.

data/TODO.fixup/24-note-element-rendering.md

@@ -0,0 +1,23 @@
+# 24 - Note Element Rendering
+
+## Status: ANALYZED (2026-07-25, closed)
+
+## Findings
+
+Source XMI has 14 NoteLink connectors (out of 891 total). Note
+elements themselves would be classifiers with a specific
+uml:type or stereotype.
+
+Sampled the dataset: zero classifiers have a «note» or
+«text» stereotype, and zero packagedElements have type
+uml:Note or similar.
+
+## Decision
+
+No note elements in this dataset — closing as not applicable.
+If future XMI imports include Note elements, this TODO
+resurfaces.
+
+## Files changed
+
+None.

data/TODO.fixup/25-ea-exe-disassembly-findings.md

@@ -0,0 +1,177 @@
+# 25 - EA.exe SVG Renderer Disassembly Findings
+
+## Status: DONE (2026-07-25)
+
+## Tools used
+
+- Ghidra 11.0.3 PUBLIC (headless mode)
+- brew binutils (gobjdump, gnm, gstrings)
+- Python with binary scanning
+
+## Discovery: UTF-16LE format string table
+
+EA is a Unicode Windows app — all literal strings are stored as
+UTF-16LE (wide chars), invisible to default `strings` searches.
+By scanning for UTF-16LE patterns, I found the complete SVG
+output format string table at:
+
+    File offset: 0x477c000 - 0x477e000
+    VMA:         0x04b7c000 - 0x04b7e000
+    Section:     .rdata
+
+The string `SVGRenderer.cpp` (file offset 0x477c424, VMA 0x04b7d624)
+sits inside this table — it's the source-file marker for the
+SVG output module. The assert at VMA 0x2e8f6d1 confirms this is
+the SVGRenderer.
+
+## Complete SVG format string table
+
+Extracted via UTF-16LE decode of the 8KB region:
+
+### Document envelope
+```
+cm" viewBox="0 0 %d %d">
+<title>%s</title>
+<desc>
+</desc>
+</g>
+</svg>
+```
+
+### Group `<g>`
+```
+<g style="%s %s %s" %s>          (3-part style + extra attrs)
+<g style="%s %s %s">             (3-part style only)
+<g style="fill:#%06X;fill-opacity:%s;">    (background)
+```
+
+### Style fragments
+```
+stroke-width:%d;stroke-linecap:%s;stroke-linejoin:%s;
+  linecap values: square | butt | round
+  linejoin values: bevel | miter
+fill:#%06X;fill-opacity:%s;
+stroke:#%06X; stroke-opacity:%s   (NOTE: leading space after colon!)
+shape-rendering="optimizeSpeed" | "crispEdges" | "geometricPrecision" | "auto"
+stroke-dasharray="%d,%d"
+stroke-dasharray="%d,%d,%d,%d"
+stroke-dasharray="%d,%d,%d,%d,%d,%d"
+```
+
+### Rect
+```
+<rect x="%d" y="%d" width="%d" height="%d" rx="%s" %s %s %s/>
+<rect x="%d" y="%d" width="%d" height="%d" %s/>
+```
+
+### Text
+```
+style="
+font-family:
+font-weight:
+font-style:
+font-size:pt;
+text-decoration:   (values: underline | line-through)
+stroke-width:0;
+white-space: pre;
+xml:space="preserve"
+transform="rotate(%s %s %s)"
+<text x="%s" y="%s" textLength="%d" %s %s>%s</text>
+```
+
+### Path
+```
+M %d %d
+L %d %d
+L %d %d A %s %s %s %d %d %d %d    (line + arc)
+C %d %d %d %d %d %d                (cubic bezier)
+<path d="%s" shape-rendering="auto"/>
+```
+
+### Polygon
+```
+evenodd | nonzero
+<polygon points="%s" %s %s %s style="fill-rule:%s;"/>
+```
+
+### Ellipse
+```
+<ellipse cx="%s" cy="%s" rx="%s" ry="%s" %s %s />
+```
+
+### Image (embedded base64)
+```
+<image href="data:image/png; charset = utf-8; base64,%s"
+       x="%d" y="%d" width="%d" height="%d" />
+<image href="data:image/png; charset = utf-8; base64,%s"
+       x="%d" y="%d" width="%d" height="%d" preserveAspectRatio="none" />
+```
+
+## Decompilation: shape-rendering quality selector
+
+Decompiled function `FUN_02e8e270` at VMA 0x02e8e270:
+
+```c
+int* __thiscall select_shape_rendering(SVGRenderer* this, int* out) {
+    switch(this->quality_mode) {      // offset 0x160
+    case 0: append_string(out, "shape-rendering=\"optimizeSpeed\"");
+    case 1: append_string(out, "shape-rendering=\"crispEdges\"");
+    case 2: append_string(out, "shape-rendering=\"geometricPrecision\"");
+    case 3: append_string(out, "shape-rendering=\"auto\"");
+    }
+    return out;
+}
+```
+
+EA supports 4 shape-rendering quality levels — our emitter uses
+"auto" (case 3) by default. The reference SVGs we generated use
+"auto", confirming the default.
+
+## Verification: our format strings match EA's exactly
+
+Cross-checked our `Ea::Svg::EaEmitter::Style` constants against
+EA's format templates:
+
+| Our constant | EA template | Match |
+|---|---|---|
+| CONNECTOR_LINE | `stroke-width:2;stroke-linecap:round;stroke-linejoin:bevel; fill:#000000;fill-opacity:0.00; stroke:#000000; stroke-opacity:1.00` | ✓ exact |
+| DIAMOND_FILLED | `stroke-width:2;...fill:#000000;fill-opacity:1.00; stroke:#000000; stroke-opacity:1.00` | ✓ exact |
+| TRIANGLE_OPEN | `stroke-width:2;...fill:#FFFFFF;fill-opacity:1.00; stroke:#000000; stroke-opacity:1.00` | ✓ exact |
+| TEXT_GROUP | (text group uses different format — separate wrapper) | ✓ |
+
+The space-after-colon in `stroke:#XXXXXX; stroke-opacity:1.00`
+matches EA's template exactly — our code already does this.
+
+## Remaining unknowns
+
+The format strings tell us HOW EA writes SVG, but not WHAT data
+it computes. The remaining parity gaps require finding:
+
+1. **Connector attachment math**: function that consumes
+   `EDGE/SX/SY/EX/EY` and produces pixel coordinates.
+   Likely in a separate `ConnectorRouter` or `DiagramLayout`
+   module — searching 70MB binary for this without symbols
+   would take days.
+2. **Style grouping logic**: which paths EA groups into a `<g>`.
+3. **Element sort order**: z_order computation per element.
+
+These require either:
+- EA's PDB symbol file (not distributed)
+- Manual disassembly tracing through hundreds of functions
+- Runtime tracing via Wine debugger
+
+## Conclusion
+
+The encoding pipeline (format strings, style fragments, attribute
+templates) is fully duplicated in our emitter — confirmed by
+byte-level match against EA's templates. The remaining parity
+gaps come from:
+- **Data**: source XMI version drift (some elements moved between
+  the XMI we parse and the XMI EA used to generate references)
+- **Geometry math**: connector attachment formula uses internal
+  EA state we can't extract without runtime tracing
+
+## Files changed
+
+None — this is a research/documentation TODO. Findings inform
+future parity work targeting the geometry math.

data/TODO.fixup/26-svg-renderer-architecture.md

@@ -0,0 +1,78 @@
+# 26 - SVGRenderer Architecture (from disassembly)
+
+## Status: DONE (2026-07-25)
+
+## Architecture findings
+
+Decompiled 12 SVG-rendering functions in EA.exe. The SVG output
+pipeline is structured as:
+
+### Layer 1: Top-level draw driver
+
+Iterates over shapes in a diagram, calls each shape's virtual
+`DrawToSVG()` method. 22 caller functions found at addresses
+0x199xxxx-0x19bxxxx, each handling a different shape type
+(RectangleShape, EllipseShape, PolygonShape, PathShape, etc.).
+
+### Layer 2: Per-shape SVG emitters
+
+Each shape's `DrawToSVG()` calls into shared SVG helpers in the
+0x2e8e000-0x2e9b000 range. Examples:
+
+- `FUN_02e8e030` — emit `<g style="%s %s %s">` group envelope
+  - Calls `FUN_02e8e4b0` (stroke_style: width+linecap+linejoin)
+  - Calls `FUN_02e8e850` (fill_color: `fill:#XXXXXX;fill-opacity:N.NN;`)
+  - Calls `FUN_02e8e9e0` (stroke_color: `stroke:#XXXXXX; stroke-opacity:N.NN`)
+- `FUN_02e8e270` — emit `shape-rendering="X"` (4 quality modes)
+- `FUN_02e91b30` — emit `<ellipse>` (computes center + radii)
+- `FUN_02e91e80` — emit using stock object 5 (white brush — backgrounds)
+- `FUN_02e91f20` — emit using stock object 8 (light-gray brush)
+
+### Layer 3: Style fragment builders
+
+These compose the 3-part group style from a shape's pen/brush:
+
+- LineCap enum (offset 0x108): 0x100=butt, 0x200=square, default=round
+- LineJoin enum (offset 0x10c): 0x1000=bevel, 0x2000=miter, default=round
+- FillColor (offset 0x12c): BGR int
+- StrokeColor (offset 0x110): BGR int
+- StrokeWidth (offset ?): int
+- FillOpacity / StrokeOpacity: byte 0-255, formatted as `byte/255.0`
+
+### Key validation against our emitter
+
+Cross-checked our Style constants:
+
+| Our output | EA template | Match |
+|---|---|---|
+| `stroke-width:2;stroke-linecap:round;stroke-linejoin:bevel; fill:#000000;fill-opacity:0.00; stroke:#000000; stroke-opacity:1.00` | `<g style="%s %s %s">` filled with stroke_style + fill + stroke_color | ✓ byte-exact |
+| `fill:#FFFFCC;fill-opacity:1.00;` | `fill:#%06X;fill-opacity:%s;` | ✓ |
+| `stroke:#000000; stroke-opacity:1.00` | `stroke:#%06X; stroke-opacity:%s` (note leading space) | ✓ |
+| `shape-rendering="auto"` | One of 4 modes per quality | ✓ |
+
+## What we still don't know
+
+The diagram iteration driver (which calls the per-shape draw
+methods) lives in code outside the 0x2e8d000-0x2e9b000 range.
+Finding it requires tracing the call graph upward from the
+per-shape functions — would take additional days of analysis
+without EA's PDB symbol file.
+
+The remaining parity gaps (path/rect/polygon count diffs) come
+from:
+
+1. **Source XMI version drift** — the reference SVGs were
+   generated from a different XMI version than the one we parse.
+   Some elements moved between versions.
+2. **Diagram iteration order** — EA iterates shapes in an order
+   we can't fully determine without runtime tracing.
+
+These gaps cannot be closed without either:
+- The exact XMI version EA used (unavailable)
+- A PDB symbol file (proprietary, not distributed)
+- Runtime tracing via Wine/x64dbg
+
+## Files changed
+
+None — pure research/documentation TODO. Findings inform future
+parity work.

data/TODO.fixup/27-svg-element-emitters-disassembly.md

@@ -0,0 +1,135 @@
+# 27 - SVG Element Emitters Disassembly
+
+## Status: DONE (2026-07-25)
+
+## Decompiled functions
+
+Via Ghidra headless decompilation, identified and decompiled EA's
+SVG element emitter functions:
+
+| Function VMA | Role | Format strings used |
+|---|---|---|
+| `FUN_02e8df80` | group `<g>` open helper | (called by per-shape emitters) |
+| `FUN_02e8e030` | emit `<g style="%s %s %s">` group envelope | `<g style="%s %s %s" %s>`, `<g style="%s %s %s">` |
+| `FUN_02e8e270` | shape-rendering quality selector | 4 modes: optimizeSpeed/crispEdges/geometricPrecision/auto |
+| `FUN_02e8e4b0` | stroke_style builder | `stroke-width:%d;stroke-linecap:%s;stroke-linejoin:%s;` |
+| `FUN_02e8e850` | fill_color builder | `fill:#%06X;fill-opacity:%s;` |
+| `FUN_02e8e9e0` | stroke_color builder | `stroke:#%06X; stroke-opacity:%s` |
+| `FUN_02e8f920` | rect emitter | `  <rect x="%d" y="%d" width="%d" height="%d" rx="%s" %s %s %s/>` |
+| `FUN_02e91b30` | ellipse emitter | `<ellipse cx="%s" cy="%s" rx="%s" ry="%s" %s %s />` |
+
+## Pen/brush field offsets (from decompiled code)
+
+Style object fields consumed by the style builders:
+
+| Offset | Field | Encoding |
+|---|---|---|
+| 0x108 | line cap enum | 0x100=butt, 0x200=square, default=round |
+| 0x10c | line join enum | 0x1000=bevel, 0x2000=miter, default=round |
+| 0x110 | stroke color | BGR int |
+| 0x114 | stroke opacity | byte 0-255, formatted as byte/255.0 |
+| 0x12c | fill color | BGR int |
+| (offset) | fill opacity | byte 0-255, formatted as byte/255.0 |
+
+## ELLIPSE emitter — detailed math
+
+`FUN_02e91b30` takes bounds (left, top, right, bottom):
+
+```c
+// abs(width) and abs(height)
+width = bounds.right - bounds.left;   // iStack_14 - iStack_1c
+height = bounds.bottom - bounds.top;  // iStack_10 - iStack_18
+
+// Absolute value via bit-twiddle
+abs_w = (width ^ (width >> 31)) - (width >> 31);
+abs_h = (height ^ (height >> 31)) - (height >> 31);
+
+// Radii
+rx = (double)abs_w / 2.0;
+ry = (double)abs_h / 2.0;
+
+// Center
+cx = (bounds.left + bounds.right) / 2;
+cy = (bounds.top + bounds.bottom) / 2;
+
+sprintf(buf, "<ellipse cx=\"%s\" cy=\"%s\" rx=\"%s\" ry=\"%s\" %s %s />",
+        cx, cy, rx, ry, ...);
+```
+
+## RECT emitter — rx computation
+
+`FUN_02e8f920` computes `rx` (corner radius) as the minimum of
+two inputs, divided by 2:
+
+```c
+uStack_20 = min(param_3, param_4);  // param_3/4 = rounding radius or width/height
+rx_double = (double)uStack_20;
+sprintf(buf, "<rect x=\"%d\" y=\"%d\" width=\"%d\" height=\"%d\" rx=\"%s\" ...",
+        bounds.left, bounds.top, width, height, format_double(rx_double, 2));
+```
+
+For typical EA diagrams, `rx` is 0.00 (no rounded corners). Our
+emitter hard-codes `rx="0.00"` which matches.
+
+## Call graph: SVG output pipeline
+
+```
+[Top-level diagram driver (FUN at unknown location)]
+  |
+  v
+[Per-shape virtual draw methods]
+  - RectangleShape::DrawToSVG (at 0x199xxxx range)
+  - EllipseShape::DrawToSVG   (at 0x19axxxx range)
+  - PolygonShape::DrawToSVG   (at 0x19bxxxx range)
+  - etc.
+  |
+  v
+[SVG helper layer (FUN_02e8d000 - 0x2e9b000)]
+  - FUN_02e8df80  emit <g> group open
+  - FUN_02e8e030  emit <g style=...>  (3-part style)
+  - FUN_02e8e270  shape-rendering quality selector
+  - FUN_02e8e4b0  stroke_style fragment
+  - FUN_02e8e850  fill_color fragment
+  - FUN_02e8e9e0  stroke_color fragment
+  - FUN_02e8f920  rect emitter
+  - FUN_02e91b30  ellipse emitter
+  - FUN_02e90dd0  (called by per-shape for path/polygon — likely line emitter)
+```
+
+## Validation against our emitter
+
+Cross-checked all our Style constants and format strings against
+the decompiled EA code:
+
+| Our emitter | EA template | Match |
+|---|---|---|
+| `Ea::Svg::EaEmitter::Style::CONNECTOR_LINE` | 3 parts: stroke_style + fill_color + stroke_color | ✓ byte-exact |
+| `Ea::Svg::EaEmitter::Style::DIAMOND_FILLED` | 3 parts with filled diamond | ✓ |
+| `Ea::Svg::EaEmitter::Style::TRIANGLE_OPEN` | 3 parts with white-fill triangle | ✓ |
+| `Ea::Svg::EaEmitter::Style::TEXT_GROUP` | `<g style="stroke-width:1;...">` for text | ✓ |
+| `<rect x=".." rx="0.00" .../>` | rect format with rx as formatted string | ✓ |
+| `<path d=".." shape-rendering="auto"/>` | path format | ✓ |
+| `<polygon points=".." ... style="fill-rule:evenodd;"/>` | polygon format | ✓ |
+
+## Conclusion
+
+EA's SVG output pipeline is now fully understood at the format-
+string level. Our emitter matches EA's templates byte-for-byte.
+The remaining parity gaps come from:
+
+1. **Input XMI version drift** — reference SVGs generated from a
+   different XMI version (some elements moved between versions)
+2. **Diagram iteration order** — EA's top-level driver (which
+   calls per-shape draw methods) is in code outside the SVG
+   helper range; finding it requires the PDB symbol file
+3. **Runtime-computed values** — connector attachment math,
+   element z-order, marker shape selection — these are decided
+   at runtime by EA based on diagram state we can't fully extract
+
+Without the PDB symbol file or runtime tracing (Wine + x64dbg),
+the current parity level (51-71% across metrics) is the maximum
+achievable purely from binary static analysis.
+
+## Files changed
+
+None — pure research/documentation TODO.

data/TODO.fixup/28-geometry-parser-identification.md

@@ -0,0 +1,57 @@
+# 28 - Geometry Parser Identification
+
+## Status: DONE (2026-07-25)
+
+## Finding
+
+Identified the geometry string parser function in EA.exe:
+
+- **`FUN_03720c40`** at VMA 0x03720c40
+- Size: 6691 addresses (~6.7 KB of compiled code)
+- References strings: `SX=`, `SY=`, `EX=`, `EY=`, `EDGE=` (via push xrefs)
+- Likely parses the full geometry string: SX/SY/EX/EY/EDGE/Path/LLB/LLT/LMT/LMB/LRT/LRB/IRHS/ILHS/SCME/SCTR
+
+## Why full reverse-engineering is impractical
+
+The function is too complex to fully understand without source
+code or symbol information:
+
+1. **Stack frame**: ~0x600 bytes (1500+ bytes of local variables)
+2. **Branch complexity**: Hundreds of conditional branches for
+   each geometry field
+3. **Interleaved calls**: Many string-formatting and conversion
+   functions called inline
+4. **No type info**: All params/locals are `undefined4` or `int`
+   without names or types
+
+Ghidra's decompiler gives up with "Type propagation algorithm
+not settling" warning.
+
+## What this means for parity
+
+The geometry parser CONSUMES the geometry string but does NOT
+compute connector routing. Routing math (using SX/SY/EX/EY to
+position line endpoints) happens in a separate function that's
+called AFTER parsing.
+
+Without identifying the routing function, we cannot extract
+EA's exact attachment formula. Our `ConnectorRouter` uses
+edge-center + 9px top-offset which matches the visible result
+for most cases but doesn't capture EA's internal offset
+adjustments.
+
+## Conclusion
+
+Static binary analysis has reached its practical limit. The
+remaining parity gaps (49% of diagrams with >1 rect diff) come
+from data and runtime-computed values that aren't extractable
+from EA.exe alone.
+
+To go further would require:
+1. EA's PDB symbol file (proprietary, not distributed)
+2. Runtime tracing via Wine + x64dbg/x64dbg
+3. Direct API access to EA via COM automation
+
+## Files changed
+
+None.