ea 0.4.0 → 0.5.0

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.

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.