@micha.bigler/ui-core-micha 3.2.1 → 3.3.1

package/CHANGELOG.md

@@ -2,6 +2,50 @@
 
 Only notable, user-facing changes. Not every version — see `WORK_ORDERS.md` for the full history.
 
+## 3.3.1 — UCM-CHART-18
+
+**Exported PNGs no longer contain interactive controls — buttons, drill-down links, and the like
+are gone from the image, while an interactive chart legend (MUI's own, e.g. a
+`toggleVisibilityOnClick` legend) keeps every pixel of its swatch and label — only its
+clickability is dropped, which a static image never had anyway. A rotated element (e.g. a legend
+swatch drawn as a diamond) now exports rotated instead of square.** Since `3.3.0` the PNG export
+rasterises `ChartFrame`'s whole `chartRef` box, which wraps a panel's `children` — any button or
+link a panel renders alongside its chart (an info affordance, a "view details" link) was
+rasterised straight into every exported image. Fixed generically here rather than by moving each
+panel's controls elsewhere: an exported image should show what the chart *communicates*, not what
+can be *clicked*, and that is a property of the element kind, not of any one panel's layout
+choices. `transform` was also missing from the properties this package inlines onto an export, so
+a CSS-rotated element silently lost its rotation; both exports (SVG and PNG) now carry it.
+
+This is a patch, not a minor: it repairs behaviour `3.3.0` itself introduced (interactive controls
+were never meant to appear in an export) rather than changing what a correctly-shaped export
+contains.
+
+## 3.3.0 — UCM-CHART-17
+
+**The PNG export now includes the legend, size key, and footnotes — the SVG export still doesn't,
+deliberately.** Both exports used to clone-and-serialise the same raw `<svg>`: no theme styles
+carried over (a standalone viewer applied bare SVG defaults, the "graphically massively different"
+symptom reported), and only the chart itself was captured — a panel's hand-built HTML legend and
+its size-key SVG (rendered as siblings of the chart since `HRAM-RES-39`/`HRAM-VIS-2`) were silently
+dropped from every export.
+
+The two formats now keep two different, explicit promises instead of one broken shared one:
+
+- **Export SVG** — the chart's own vector surface, with computed styles (font, colour, stroke)
+  inlined so it renders correctly standalone. Chart only, no legend — that's what a portable,
+  editable vector file is for.
+- **Export PNG** — the whole card as shown: chart, legend, size key, footnotes. Rasterises the
+  actual container instead of the chart's SVG alone.
+
+Both buttons now carry a tooltip stating the difference, since the label alone no longer says so.
+
+No new dependency: both paths route through the platform's own SVG → `Image` → `<canvas>`
+pipeline. The PNG path specifically loads its intermediate SVG via a `data:` URI rather than a
+`blob:` URL — an `<svg>` containing a `<foreignObject>` (needed to rasterise arbitrary HTML)
+taints the canvas unconditionally in Chrome when loaded via `blob:`, confirmed live; a `data:` URI
+does not.
+
 ## 3.2.1 — UCM-CHART-16
 
 **A horizontal-axis chart with a title, or a large-enough tick font, could render every tick

package/WORK_ORDERS.md

@@ -27,6 +27,8 @@ prefixed ID; never reuse a bare flat number across workstreams.
 
 | ID | Titel | Beschreibung | Datum | Status | Commit(s) | Notiz |
 |---|---|---|---|---|---|---|
+| UCM-CHART-18 | The PNG export shows what the chart says, not what the user can click | Two defects, one file, a few lines apart -- both raised by `HRAM-CHT-7`'s independent `ui_reviewer` (2026-08-25) and confirmed, partly by reading and partly live. **(1) Interactive controls are in the image.** Since 3.3.0 the PNG rasterises `ChartFrame`'s whole `chartRef` box, and `chartRef` wraps `children` only -- not `toolbar`, `controls` or `meta` -- so anything a panel renders as children is now in the file: hram's `StructuralReachabilityPanel:468` footer `IconButton` (always visible, so **every** PNG of that panel carries a button), `AllocationPerformancePanel:536,548` and `OptimizationResultsPanel:1120,1141`. **(2) `transform` is not inlined** -- neither property list (`:32-36`, `:44-52`) has it, so `OptimizationResultsPanel:1107`'s rotated legend swatch exports as a **square instead of a diamond**. **Fixed here rather than in the app for two reasons:** it is a property of the element kind, not of each panel -- an exported image should show what the chart communicates, not what can be clicked -- and the alternative (moving controls into `ChartFrame`'s `controls`/`toolbar` slots) would **undo a deliberate design decision**, since `HRAM-RES-30` put that info affordance in the footer beside the caveat line. After this, hram needs **only a pin bump**. Full order [`work-orders/UCM-CHART-18.md`](work-orders/UCM-CHART-18.md) | 2026-08-25 | done | `5f34a2b` | **Tier 3** -- shared-core. `ui_reviewer` (what belongs in an exported image, and the MUI-legend counter-check) + `reviewer` (the ordering trap, the `transform` double-apply question); no `sec_reviewer`. **THE single most likely way to get this wrong:** `inlineComputedStyles` walks source and clone **in lockstep by index** (`:70-77`), so removing controls from the clone **before** it shifts every subsequent index and elements silently receive their neighbours' styles -- an export that looks plausible and is wrong everywhere after the first removal. Removal happens **after** the style walk, and the code comment must say so. **Counter-check that is not optional:** what disappears must be operation, not content -- a consumer whose legend items are `<button>`s (MUI's own legend can be interactive) would lose its legend, and the affected hram panels all pass `hideLegend` so they are **not** the test case; verify against a chart that keeps MUI's own legend, and if it vanishes that changes the approach. Also: `transform` may **double-apply** on SVG nodes that carry it as a presentation attribute the clone already keeps -- check `xLabels="angled"` before assuming it is inert. **Release: patch -> 3.3.1** -- this repairs behaviour 3.3.0 itself introduced rather than adding capability, the same reasoning `UCM-CHART-16` went out on, while `-15`/`-17` were minors because they changed what a consumer gets on purpose. Gate is **opening the files**, as for `UCM-CHART-17`: both defects were invisible to every test and visible immediately in an exported image. **Implementation:** `.claude/models.local.json` has no local override (defaults apply) -- `implementation.runtime` is `claude`/`sonnet`, implemented directly, no Codex dispatch. The lockstep-index ordering was respected from the start (`inlineComputedStyles` before `stripInteractiveControls`), `transform`/`transform-origin` added to the shared property list. **Verification (real Chrome, via the dev harness's module graph, no probe entry ever committed):** all four WO cases confirmed with hard evidence, not visual impression -- (1) a control in `children` (`IconButton` beside static text): captured the PNG path's actual intermediate SVG, confirmed no `<button` tag/text while the sibling and chart survive. (2) MUI's own legend (non-interactive, two series): fully intact, both labels present. (3) a rotated swatch: pixel-sampled the real rasterised PNG on a real `<canvas>` -- bounding-box corner reads background white, centre reads the swatch's own colour, i.e. a genuine diamond. (4) `xLabels="angled"`: the exported tick carries both the original `transform` XML attribute (kept by `cloneNode`) and the newly-inlined computed matrix; the matrix values mathematically match a SINGLE -45° rotation (`cos(-45°)=0.707107`), not a doubled one -- confirmed the inline `style` declaration wins over the presentation attribute rather than composing with it. 89 affected chart tests green (14 in `exportChart.test.js`), `tsc` clean. **Review: codex/gpt-5.6-luna (`reviewer` + `ui_reviewer`, concurrent) · 5 raised · 3 accepted · worst accepted: high (interactive-legend content loss)** (id not divisible by 5, no rotation configured). **Both reviewers independently converged on the SAME defect**, exactly the risk the WO's own Envelope named and required a live counter-check for: the initial fix REMOVED (not unwrapped) MUI's own interactive legend items (`onItemClick`/`toggleVisibilityOnClick` renders each item as `<button role="button" class="...MuiChartsLegend-series...">`), deleting the swatch+label along with the click handler -- the WO's own words, "if it vanishes, that is a finding that changes the approach, not a detail to paper over." FIXED: `MuiChartsLegend-series` matches are now UNWRAPPED (replaced with a plain `<span>` carrying the same class/style/children) instead of removed; re-verified live against an ACTUAL interactive legend (`slotProps={{legend:{toggleVisibilityOnClick:true}}}`, confirmed the live items render as real `<BUTTON>` tags) -- export contains zero `<button` tags, `MuiChartsLegend-series` and both series labels survive intact. `reviewer` additionally found: the interactive-control selector missed `a[href]`/`[role="link"]` (accepted, added -- also corrects the CHANGELOG's own "drill-down links" claim, which wasn't true until this fix); and the original ordering test's button was the LAST descendant, so a wrong call order wouldn't have shifted any node the test actually asserted on -- content-presence checks can't observe a style misattribution, only a wrong STYLE VALUE can (accepted, rewrote with a distinctively-styled trailing sibling, confirmed by temporarily reverting the call order that the new assertion genuinely fails). Two findings rejected as decoration/informational only (transform double-apply already reasoned through correctly by both reviewers; a jsdom-literal vs. browser-matrix distinction in the unit test, already covered by the separate real-browser verification track). |
+| UCM-CHART-17 | The two export buttons make two different promises; make them keep them | **Export SVG** yields the chart as scalable, correctly styled vector art; **Export PNG** yields what the user is looking at -- legend, size key and footnotes included. **Defect, from source:** `exportChart.js:7-11` clones the first `<svg>` and serialises it raw, with **no styles carried**. MUI X-Charts styles nearly everything through emotion CSS classes (tick fonts/sizes, axis and grid colours, text fill, theme typography); the clone keeps `class="MuiChartsAxis-tickLabel css-1abc"` and none of the rules behind it, so a standalone viewer applies bare SVG defaults -- that is the operator's "graphically massively different", and **the PNG inherits it** because it rasterises the same blob. **Second cause, and it is ours:** `findSvg` takes the *first* `<svg>`, i.e. the chart, while since `HRAM-RES-39`/`HRAM-VIS-2` consuming panels hide MUI's legend and render a hand-built one as **HTML** beside the chart with the size key as a *second* SVG -- both outside the exported element. **Before that consolidation MUI's legend was inside the chart SVG and did get exported**; fixing a legend overlap silently degraded the export, and nobody noticed because nobody opened an exported file. Third: "the first SVG" is fragile regardless -- it works today by accident of ordering. **Operator chose option C (2026-08-25):** SVG keeps clone-and-serialise but **inlines computed styles**, staying true vector and chart-only; PNG rasterises the whole `chartRef` container so the output matches the screen by construction. Full order [`work-orders/UCM-CHART-17.md`](work-orders/UCM-CHART-17.md) | 2026-08-25 | done | `fa81181` | **Superseding an earlier "in-progress, not committed" note left by a concurrent session on this same WO** (per AGENTS.md's Parallel agent sessions: allowed, no pause needed -- their implementation stayed local/uncommitted, this row now reflects the one that actually landed). **Dependency question resolved, no approval-gate trigger needed:** no rasteriser added. Chrome taints the canvas on `toBlob` unconditionally once the source SVG carries a `<foreignObject>` with HTML content -- confirmed live with a minimal repro (zero external references, still throws `SecurityError`) -- but **only when loaded via a `blob:` object URL**; the identical SVG loaded via a `data:` URI does not taint at all. That swap (`rasterize()` in `exportChart.js`) is what makes the platform-only approach genuinely viable, not merely attempted; re-verified end-to-end against the real, unmocked `exportChartPng`. Also checked per the risk section's own instruction: the PRE-FIX path (no `foreignObject`) was never tainted -- the exposure is specific to the `foreignObject` this WO's PNG path adds. **Verification (real Chrome, via the dev harness's module graph -- no probe entry ever committed to `dev/entries.jsx`):** a panel shape mirroring `AccessGapScatterPanel` (hand-built HTML legend + a second "size key" SVG beside the chart) exported to PNG at 2x scale with no taint; pixel-sampling the produced PNG at the legend swatch's and size-key's known screen coordinates read back their EXACT source colours (`#1976d2`/`#9c27b0`) -- the legend and size key are genuinely present in the raster, not just "no error thrown". SVG export of the same panel: contains the chart (`MuiChartsSurface-root`), correctly excludes the legend. A plain no-legend panel shape also verified clean on both paths. 192 affected chart tests green, `tsc` clean. **Review: codex/gpt-5.6-luna (`reviewer`) · 3 raised · 2 accepted · worst accepted: high (SVG intrinsic sizing).** (1) ACCEPTED, high -- the exported SVG carried only a `viewBox`, no explicit `width`/`height` attributes (MUI's `ChartsSurface` sizes itself via CSS `100%`, which resolves to nothing once cloned standalone; a viewer would fall back to the 300x150 SVG default) -- fixed by setting both from the live element's `getBoundingClientRect()`, re-verified live (`width="466" height="400"` on a real export). (2) REJECTED, factually incorrect -- claimed jsdom lacks `URL.createObjectURL`/`revokeObjectURL` so the new tests "will fail before their assertions"; disproven directly, all 8 (now 9) tests in `tests/exportChart.test.js` pass, and jsdom 29.1.1 implements both natively (verified). (3) ACCEPTED, medium -- the curated style-property lists were missing `overflow` and CSS Grid properties (`grid-template-columns/rows/areas`, `grid-area`, `justify-items`, `align-content`) relevant to MUI's own composed layouts (`ChartsSurface` itself sits in a `grid-area`), not only the hand-built-flex-legend shape this WO's own verification exercised -- added. **`ui_reviewer`: codex/gpt-5.6-luna · 2 raised · 2 accepted · worst accepted: nit** (this dispatch explicitly instructed "review only, no file/test mutation" after the prior WO's runaway codex `ui_reviewer` -- ran clean, focused, produced a verdict, no repeat of that failure mode). `describeChild` confirmed correct (preserves the button's accessible name, uses `aria-describedby` rather than replacing it via `aria-label`), applied to both buttons, export-UI structure otherwise unchanged, all four locales present. Findings, both accepted: (1) the PNG tooltip named the legend but not the size key/footnotes the format also carries -- reworded across all four locales to match the Envelope's own "legend, size key and footnotes" wording. (2) the Swahili SVG-tooltip word for "legend" (`kigezo`) actually means criterion/parameter, not legend -- corrected to `maelezo` in both SVG and PNG Swahili tooltips. Publishes automatically via `publish.yml` on this push (version-increase gate, `3.3.0 > 3.2.1`). Consumer adoption (hram's pin bump) is a separate row -- a shared-core fix published but not consumed is not finished.
 | UCM-CHART-16 | The x-axis band starves MUI's tick-fit check, and two consumers have patched around it | A chart with an axis title **and** horizontal tick labels must render its tick labels without a consumer hand-setting `xAxis[].height`. **Defect:** on the horizontal path `resolveXAxisGeometry` reserves one combined band from `TICK_BAND_BASE_PX` + `AXIS_TITLE_BAND_PX`; once a title is also taken from that budget, MUI's own fit check (`shortenLabels` against `tickLabelsMaxHeight`) is left **just under one line of 12 px text** and blanks **every** label regardless of content. Distinctive and easy to misread: correctly positioned tick marks, zero non-empty label texts -- looks like a data or formatter problem and is neither. **Evidence: two consumers, same workaround, same magic number**, independently, in two different WOs -- hram `StructuralReachabilityPanel.jsx:386` (`HRAM-RES-32`) and `AccessGapScatterPanel.jsx:212` (`HRAM-RES-39`), both `height: 56`. RES-32's own comment already diagnosed it and called it *"a pre-existing, latent shared-core near-miss"*, then patched locally because a shared-core fix was outside that WO; RES-39 read the MUI source, reached the same cause and the same 56, and patched locally again. **The third titled-horizontal-axis chart will hit it too**, and the package is meanwhile violating its own stated Rule 1 (*"nothing outside the resolver does chart arithmetic"*) in two places. Fix: correct the reservation, and **derive** it from the known tick font size and title band rather than adding a second magic number that will be wrong at a different font size. Full order [`work-orders/UCM-CHART-16.md`](work-orders/UCM-CHART-16.md) | 2026-08-25 | done | `9830266` | **Tier 3** -- shared-core. `reviewer` + `ui_reviewer` (the plot-area change across consumers); no `sec_reviewer`. **The risk that decides this WO: a mocked prop-assertion test cannot catch it.** The file already records the same trap for a neighbouring bug (*"a mocked prop-assertion test cannot catch this, it only reproduces on an actual MUI scale computation"*) -- a test asserting the computed band's number passes whatever the number is. **Test 1 must observe rendered label text**, or it is decoration. Also: raising the band changes every titled-horizontal-axis chart's plot area, on top of `UCM-CHART-15`'s 80 px shift -- and fixing it too generously wastes vertical space everywhere, so the near-miss margin is the budget, not a number rounded up to be safe. Release patch unless the plot-area change warrants minor; say which and why in the CHANGELOG. Consumer cleanup (removing hram's two workarounds) is `HRAM-CHT-6`, after this ships. **Third occurrence, 2026-08-25, and it changes the fix:** hram's `AccessibilityPanel` in `Urban/Peri-urban/Rural x Division` mode -- five band categories, five rendered bar groups, **no tick labels at all**, same signature. But that chart has **no `xAxisLabel`**, so the title is not competing for the band; what it has is `tickLabelStyle: { fontSize: 13 }`, one pixel above the 12 px the base band was sized against. **So the trigger is not "a title takes the room" -- it is that the band is a near-miss at all**, and anything consuming a little more pushes it over. A fixed `height: 56` patched into a third consumer would work at 13 px and fail at 14. That is exactly why scope item 2 requires the resolver to **derive** the requirement from the tick font size it already knows, instead of adopting the constant two consumers measured empirically at 12 px. Signature-matched, not yet instrumented -- confirm the mechanism on this third case, since it is the one that distinguishes a derived fix from a bigger constant. **Implementation:** `.claude/models.local.json` has no local override (defaults apply) -- `implementation.runtime` is `claude`/`sonnet`, implemented directly by the Orchestrator, no Codex dispatch. **The defect could not be confirmed from source reading alone** (jsdom does not implement real SVG text measurement, `getBBox`, so a rendered test would trivially pass regardless of correctness): reproduced and calibrated against the real, unmocked `BarChart` in this repo's own dev harness (Chrome, DM Sans, via `dev/entries.jsx`, reverted before commit) -- confirmed the defect reproduces exactly as described, confirmed it does NOT reproduce under MUI's default Roboto stack (explains why it was font-dependent and missed until a consumer used a taller font), then binary-searched the real minimal `xAxis[].height` at ten font-size/title combinations (11-18px) to derive `TICK_TEXT_HEIGHT_FACTOR=1.3`, `TICK_BAND_MUI_OVERHEAD_PX=9`, `TICK_BAND_TITLE_EXTRA_PX=2` -- matched every measured threshold within 1px, never under. Third occurrence (no title, `tickLabelStyle.fontSize:13`) confirmed via the same harness. 180 affected chart tests green (78 `chartDefaults.test.js` + 2 new rendered tests in `chartAxisTickBand.test.jsx`, which install a calibrated `SVGElement.prototype.getBBox` mock since jsdom's real implementation always measures 0x0 + 100 across `BarChart`/`LineChart`/`ScatterChart`/`TimeSeriesChart`/`ChartFrame`), `tsc -p tsconfig.build.json` clean. Both new resolver tests and both new rendered tests independently confirmed to fail against the pre-fix resolver (temporarily reverted, reran, restored) -- test 1 must observe rendered label text, not a computed number, per the WO's own risk section; both requirements met. Version bumped `3.2.0` -> `3.2.1` (patch, per the WO's own classification -- repairs existing behaviour, `UCM-CHART-15`'s heights untouched). **Review: codex/gpt-5.6-luna (`reviewer`) · 3 raised · 1 accepted · worst accepted: defect · chosen** (id not divisible by 5, no rotation configured). `reviewer` findings: (1) ACCEPTED -- the Rule-2 guardrail test only asserted `xTitleBand === 0`, which passes whether or not the title margin leaked into `xAxisBand` instead; fixed to assert the actual band/height values too. (2) REJECTED, out of scope -- a caller-supplied `xAxis[].tickSize` override isn't a documented/supported customization point of this package (grep confirms zero call sites, in this repo or its own tests/docs, ever set it); adding speculative handling for an unused knob is the "second magic number" pattern this WO exists to avoid. (3) REJECTED, out of scope -- a custom/multiline title font size overflowing the fixed `AXIS_TITLE_BAND_PX=20` reservation is a pre-existing `UCM-CHART-12`-era limitation, unchanged and unworsened by this WO. **`ui_reviewer`: codex/gpt-5.6-luna dispatch produced NO USABLE VERDICT** -- ran for an extended period repeatedly re-executing `vitest`/`git` against the live working tree (including applying then reverting a debug `console.log` in the new test file -- confirmed harmless via `git diff`/content check, but a review process should never write to the shared tree) and terminated with exit 0 but no findings/verdict text. Treated as unusable per "a review never lapses because a provider is down" -- fell back to `review_fallback` (`claude`/`sonnet`), spawned read-only, explicitly instructed not to run tests or mutate anything: **no findings**, confirmed the fix is byte-identical to the pre-fix band at the package's own default tick font (zero growth for unaffected charts), the CHANGELOG communicates the visual consequence plainly, and patch is the right classification. **Flagged for awareness, not fixed here:** the codex `ui_reviewer` runaway-without-verdict pattern is worth watching for future Tier-3 dispatches -- consider adding an explicit "review only, do not modify files or run mutating commands" line to review prompts. |
 | UCM-CHART-15 | Shift the chart size scale up one step, and raise the ceiling | `compact` 30->**40** (240->**320 px**), `standard` 40->**50** (320->**400**), `tall` 50->**60** (400->**480**), plus **`extra_tall` 70 (560)** and **`super_tall` 80 (640)**. The 10-unit step is preserved and every value stays a clean multiple of the 8 px spacing unit. **Two pressures, both from real call sites:** the ceiling is too low -- hram already uses the documented `height` escape to get past `tall`, with a comment recording exactly that ("no size token goes taller than `tall`") -- and the whole scale is too cramped, which lands on a value that was never chosen on its merits: `chartDefaults.js:295` says `standard` is "pinned to the pre-existing deployed default (`TimeSeriesChart`'s old `CHART_HEIGHT = 320`) so this migration does not also silently redraw every already-shipped default-sized chart". **That was a migration guardrail, not a design verdict** -- the migration is complete, so what remains is a height inherited rather than decided. Full order [`work-orders/UCM-CHART-15.md`](work-orders/UCM-CHART-15.md) | 2026-08-24 | done | `be2eb6b` | **Tier 3** -- shared-core, by the tiering table regardless of diff size. `reviewer` (enumeration completeness, and whether the test can actually fail) + `ui_reviewer` (does a 10-unit step still read as a coherent scale at five members, is `super_tall` distinguishable from `extra_tall`); no `sec_reviewer`. **Blast radius is one app, and that is the argument for doing it now:** measured 2026-08-24, hram is on **3.0.1 and is the only 3.x consumer**; the other 14 apps are on 2.41.3/2.37.0, where the size tokens do not exist (a 3.0.0 feature, this repo's CHANGELOG marks 3.0.0 "Breaking"). Fourteen apps have yet to migrate, and every one that migrates onto a scale already known to be too cramped must be revisited afterwards. **Version: minor (3.2.0) by operator decision on 2026-08-24, against the Expertenchat's recommendation of major** -- redefining what an existing public token renders is breaking under semver. Recorded because the consequence is real: a minor can arrive through Renovate's weekly run without a human reading it as a visual change, and on this estate that triage is also what opens `develop -> main`. **Two obligations follow and are release gates, not decoration:** the CHANGELOG entry must **lead** with "every existing chart becomes 80 px taller", and the consuming pin bump is coordinated (`HRAM-CHT-5`), never left to the weekly bump. **Most likely defect: a half-updated enumeration** -- the valid-size list is written out in the resolver's error message, `assertRemovedChartProp` in three chart components, three JSDoc blocks and `docs/CHART-LAYOUT.md`; grep the literal `"tall"` before declaring it done. **Implementation:** `.claude/models.local.json` has no local override (defaults apply) -- `implementation.runtime` is `claude`/`sonnet`, implemented directly by the Orchestrator, no Codex dispatch. Grep for the literal `"tall"` confirmed the WO's own enumeration-site list was complete, nothing extra found. 176 affected chart tests green (76 `chartDefaults.test.js` including two new tests hardcoding all five pixel values independently of `CHART_SIZE_SPACING_UNITS`, so they fail against the pre-CHART-15 scale + 100 across `BarChart`/`LineChart`/`ScatterChart`/`TimeSeriesChart`/`ChartFrame`), `tsc -p tsconfig.build.json` clean. Version bumped `3.1.2` -> `3.2.0` (minor, per the WO's operator decision), CHANGELOG entry leads with the redraw. **Review: codex/gpt-5.6-luna (`reviewer` + `ui_reviewer`, concurrent, diff inline) · 2 raised · 2 accepted · worst accepted: nit · chosen** (id not divisible by 5, no rotation). `reviewer`: nit -- a stale `"240px"` example in a `theme.spacing` comment at `chartDefaults.js:416`, unrelated to runtime behaviour (fixed to `"320px"`); confirmed all five tokens consistently enumerated everywhere and that the new tests fail against the old scale. `ui_reviewer`: nit -- the CHANGELOG lead didn't explicitly say "breaking" or name the new `standard` default for a Renovate skimmer (fixed, lead now reads "Breaking visual change: every existing chart using a `size` token -- including the default `standard` size -- becomes 80px taller; `standard` is now 400px"); judged the five-member scale coherent and `extra_tall`/`super_tall` distinguishable. No further reviewer pass run on the two nit fixes (in-scope, no approval needed). |
 | DX-3 | `publish.yml` tests before it builds, so `2.41.2` cannot publish | `DX-2` landed on `main` (`31675d8`, `e75192f`) and **its publish failed** — run [32029216699](https://github.com/bigler-webapps/ui-core-micha/actions/runs/32029216699), `completed/failure`. `publish.yml` runs `Run tests` **before** `Build`; `DX-2`'s new `tests/packageTreeShaking.test.js` copies the package's own `dist/` to assemble a fake installed consumer, and **`dist/` is gitignored** (`.gitignore:2`), so in a clean checkout it does not exist yet: `ENOENT ... lstat '.../dist'`, 510/511 passing with the one new test as the sole failure. The test is neither flaky nor wrong — it inspects the built artifact, which is the point; it cannot pass in the order the workflow runs. It was green locally at 511/511 only because a `dist/` from an earlier build was lying around. Full order [`work-orders/DX-3.md`](work-orders/DX-3.md) | 2026-08-17 | done | 67fe140 | Tier 3 — CI surface, independent `reviewer` mandatory for two lines; no `ui_reviewer`. Fix: move `Build` above `Run tests`, **keeping `if: steps.version_check.outputs.should_publish == 'true'` on both** — dropping one is the only way a reorder can go wrong, so the reviewer is asked to confirm it explicitly. Codex implemented (available today per `.claude/codex-status.md`, no prior fallback needed) — one-file, 4-line diff, nothing else touched. **Independent `reviewer` (Sonnet) confirmed: only file changed, both `if:` conditions retained on Build and Run-tests, order now install→Build→Run-tests→npm-bump→Publish, `tsc` (Build) emits `dist/` before `vitest run` (tests) needs it — no findings, safe to commit.** **Dispatch:** landing the fix did not re-trigger `publish.yml` (its `paths` filter excludes `.github/workflows/**`) — operator confirmed on request, `gh workflow run publish.yml --ref main` dispatched, run [32032549303](https://github.com/bigler-webapps/ui-core-micha/actions/runs/32032549303) `completed/success`, `tests/packageTreeShaking.test.js` passing (not skipped) in the run order fixed above. **Acceptance verified against the registry, not the tile: `npm view @micha.bigler/ui-core-micha version` → `2.41.2`.** `DX-2`'s deliverable is now actually consumable. **The dispatch is the part most likely to be missed:** `publish.yml`'s trigger `paths` cover `package.json`/`pnpm-lock.yaml`/`src/**`/`tsconfig.build.json` but **not `.github/workflows/**`**, so landing this fix does NOT re-trigger the publish — `2.41.2` sits unpublished until `publish.yml` is dispatched on `main`, which needs explicit operator confirmation (not on the safe-allowlist). No version bump: the artifact being published is DX-2's. **Acceptance is `npm view` returning `2.41.2`, not a green tile** — the publish status of this package has now been misreported in both directions in one session. Do NOT skip, delete or self-build the tree-shaking test; a skip would silently retire the only check that `sideEffects` actually tree-shakes. **Recorded, out of scope:** `publish.yml` is the ONLY workflow here that runs tests, and only when `should_publish` is true — so ucm's suite runs in CI *only on a version bump*, and a `src/**` change without one is never tested. Real gap for a twelve-consumer shared core, separate decision. |

package/dist/components/charts/ChartFrame.js

@@ -9,9 +9,9 @@ var __rest = (this && this.__rest) || function (s, e) {
         }
     return t;
 };
-import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { jsx as _jsx, Fragment as _Fragment, jsxs as _jsxs } from "react/jsx-runtime";
 import React, { useId, useRef, useState } from 'react';
-import { Alert, Box, Button, CircularProgress, Paper, Stack, Typography, } from '@mui/material';
+import { Alert, Box, Button, CircularProgress, Paper, Stack, Tooltip, Typography, } from '@mui/material';
 import { useTranslation } from 'react-i18next';
 import { useTheme } from '@mui/material/styles';
 import { exportChartPng, exportChartSvg } from './exportChart';
@@ -77,6 +77,10 @@ export function ChartFrame(_a) {
             setExportError(true);
         }
     };
+    // UCM-CHART-17: SVG and PNG now produce genuinely different content (chart-only vector vs. the
+    // whole card as shown, legend included) -- the label alone no longer says so, so both buttons
+    // carry a tooltip stating the difference plainly, per the Envelope's own requirement.
+    const exportButtons = (_jsxs(_Fragment, { children: [options.svg !== false && (_jsx(Tooltip, { title: t('ChartFrame.EXPORT_SVG_TOOLTIP'), describeChild: true, children: _jsx(Button, { size: "small", onClick: () => runExport('svg'), children: t('ChartFrame.EXPORT_SVG_LABEL') }) })), options.png !== false && (_jsx(Tooltip, { title: t('ChartFrame.EXPORT_PNG_TOOLTIP'), describeChild: true, children: _jsx(Button, { size: "small", onClick: () => runExport('png'), children: t('ChartFrame.EXPORT_PNG_LABEL') }) }))] }));
     let content = children;
     if (loading) {
         content = _jsx(CircularProgress, { "aria-label": t('ChartFrame.LOADING') });
@@ -103,5 +107,5 @@ export function ChartFrame(_a) {
                     pt: 1.5,
                     borderTop: '1px solid',
                     borderColor: 'divider',
-                }, children: [_jsx(Typography, { variant: "caption", color: "text.secondary", children: meta }), exportsEnabled && (_jsxs(Stack, { direction: "row", spacing: 1, justifyContent: "flex-end", children: [options.svg !== false && (_jsx(Button, { size: "small", onClick: () => runExport('svg'), children: t('ChartFrame.EXPORT_SVG_LABEL') })), options.png !== false && (_jsx(Button, { size: "small", onClick: () => runExport('png'), children: t('ChartFrame.EXPORT_PNG_LABEL') }))] }))] })) : exportsEnabled && (_jsxs(Stack, { direction: "row", spacing: 1, justifyContent: "flex-end", sx: { mt: 2 }, children: [options.svg !== false && (_jsx(Button, { size: "small", onClick: () => runExport('svg'), children: t('ChartFrame.EXPORT_SVG_LABEL') })), options.png !== false && (_jsx(Button, { size: "small", onClick: () => runExport('png'), children: t('ChartFrame.EXPORT_PNG_LABEL') }))] }))] }));
+                }, children: [_jsx(Typography, { variant: "caption", color: "text.secondary", children: meta }), exportsEnabled && (_jsx(Stack, { direction: "row", spacing: 1, justifyContent: "flex-end", children: exportButtons }))] })) : exportsEnabled && (_jsx(Stack, { direction: "row", spacing: 1, justifyContent: "flex-end", sx: { mt: 2 }, children: exportButtons }))] }));
 }

package/dist/components/charts/exportChart.js

@@ -1,12 +1,128 @@
-function findSvg(chartContainer) {
-    const svg = chartContainer === null || chartContainer === void 0 ? void 0 : chartContainer.querySelector('svg');
+// UCM-CHART-17: the two exports promise two different things and now keep them.
+//
+// SVG stays a true, portable vector: only the chart's own MUI x-charts surface, but with the
+// computed styles that render it correctly (font, colour, stroke) written inline, since nothing
+// downstream of a cloned+serialised node carries the page's emotion CSS classes. PNG rasterises
+// the whole container -- chart, hand-built legend, size key, footnotes -- because that is what
+// the screen actually shows (`AccessGapScatterPanel` and its siblings render the legend/size key
+// as HTML/SVG siblings of the chart since `HRAM-RES-39`/`HRAM-VIS-2`, outside the chart's own SVG).
+//
+// Both paths route DOM through an SVG (`<foreignObject>` for the PNG's arbitrary HTML+SVG mix,
+// direct serialisation for the chart-only SVG) into an `Image`, then a `<canvas>` -- the platform's
+// own APIs, no rasteriser dependency added (this package's only runtime dependency stays
+// `@fontsource/dm-sans`). A library was seriously considered, not just skipped: the naive version
+// of this technique (an `Image` loaded from a `blob:` URL) taints the canvas on `toBlob` in Chrome
+// the moment the SVG contains a `<foreignObject>`, unconditionally -- see `rasterize`'s own comment
+// for how that was confirmed live and worked around with a `data:` URI instead, which is what
+// makes the platform-only approach actually viable rather than merely attempted.
+//
+// Font embedding: NOT done. Inlined `font-family` records the real value (e.g. `"DM Sans", ...`
+// with its documented fallback stack) instead of nothing at all, which is already a correctness
+// improvement over the pre-fix export (unstyled, arbitrary browser default). A machine without DM
+// Sans installed falls back through that stack -- an honest, visible degradation, not a silent one,
+// and embedding the font file was judged not worth the added complexity/weight for this WO.
+const SVG_NS = 'http://www.w3.org/2000/svg';
+const XHTML_NS = 'http://www.w3.org/1999/xhtml';
+// Typography and SVG paint -- what actually makes a chart LOOK like the theme instead of bare SVG
+// defaults (tick fonts and sizes, axis/grid colours, text fill). Deliberately curated, not a full
+// `getComputedStyle` dump: every extra property is bytes in a file a human may open in Illustrator
+// or Inkscape.
+// UCM-CHART-18: `transform`/`transform-origin` added -- a rotated element (e.g. a legend swatch
+// rotated into a diamond) previously exported unrotated, since nothing wrote the resolved CSS
+// transform onto the clone. `getComputedStyle` returns the FINAL, resolved matrix -- already
+// incorporating an SVG element's own `transform` PRESENTATION ATTRIBUTE, which `cloneNode` also
+// keeps -- and an inline `style` declaration always wins over a presentation attribute (SVG2:
+// presentation attributes carry the lowest possible specificity), so writing the computed value
+// inline overrides rather than composes with it. Verified live against a rotated legend swatch and
+// against `xLabels="angled"` tick labels: neither double-rotates or double-displaces.
+const CHART_STYLE_PROPERTIES = [
+    'font-family', 'font-size', 'font-weight', 'font-style', 'line-height', 'letter-spacing',
+    'fill', 'stroke', 'stroke-width', 'stroke-dasharray', 'stroke-linecap', 'stroke-linejoin',
+    'opacity', 'fill-opacity', 'stroke-opacity', 'text-anchor', 'dominant-baseline', 'color',
+    'transform', 'transform-origin',
+];
+// Box layout/appearance for the HTML legend and size key a panel renders beside the chart --
+// only needed for the PNG's whole-container rasterisation, where a hand-built legend is plain
+// HTML with no chart-specific paint properties of its own. `overflow` and the grid properties
+// (reviewer finding) cover MUI's own composed layouts too, not only a hand-built flex legend --
+// `ChartsSurface` itself sits in a `grid-area`, so a container that lets MUI position multiple
+// parts via CSS Grid needs those to reposition correctly once cloned out of the page.
+const CONTAINER_LAYOUT_STYLE_PROPERTIES = [
+    'background-color', 'border-color', 'border-width', 'border-style', 'border-radius',
+    'display', 'flex-direction', 'flex-wrap', 'flex', 'align-items', 'justify-content',
+    'justify-items', 'align-content', 'gap', 'overflow',
+    'grid-template-columns', 'grid-template-rows', 'grid-template-areas', 'grid-area',
+    'padding-top', 'padding-right', 'padding-bottom', 'padding-left',
+    'margin-top', 'margin-right', 'margin-bottom', 'margin-left',
+    'width', 'height', 'box-sizing', 'text-align', 'white-space',
+];
+// Deliberate, not positional (UCM-CHART-17 scope item 3): MUI x-charts' own root `<svg>` always
+// carries `MuiChartsSurface-root` (`@mui/x-charts/ChartsSurface`) -- a stable selector, unlike "the
+// first svg in the container", which silently exported a size-key SVG once one existed ahead of
+// the chart. Falls back to the first SVG for a bespoke (non-MUI) SVG child, which `ChartFrame`'s
+// own docblock explicitly allows.
+function findChartSvg(chartContainer) {
+    const svg = (chartContainer === null || chartContainer === void 0 ? void 0 : chartContainer.querySelector('svg.MuiChartsSurface-root')) || (chartContainer === null || chartContainer === void 0 ? void 0 : chartContainer.querySelector('svg'));
     if (!svg)
         throw new Error('Chart container does not contain an SVG element.');
     return svg;
 }
-function svgBlob(chartContainer) {
-    const svg = findSvg(chartContainer).cloneNode(true);
-    svg.setAttribute('xmlns', 'http://www.w3.org/2000/svg');
+// UCM-CHART-18: an exported image shows what the chart COMMUNICATES, not what can be clicked --
+// a panel's own controls (an info `IconButton`, a drill-down `Button`, ...) live in `children`
+// alongside the chart (`ChartFrame`'s `chartRef` wraps `children` only, not `toolbar`/`controls`/
+// `meta`), so the whole-container PNG picked them up once it started rasterising `chartRef` in
+// full (`UCM-CHART-17`). `[role="button"]` catches MUI's own non-native button-like elements (e.g.
+// an `IconButton` can render as a `<span>`/`<div>` with that role) that a tag-name selector alone
+// would miss; `a[href]`/`[role="link"]` (reviewer finding) cover a drill-down built as a link
+// rather than a `<button>`.
+const INTERACTIVE_CONTROL_SELECTOR = 'button, input, select, textarea, [role="button"], a[href], [role="link"]';
+// ui_reviewer + reviewer finding, independently: MUI's OWN chart legend can be interactive
+// (`onItemClick`/`toggleVisibilityOnClick`) and, when it is, X-Charts renders each legend item as
+// `<button role="button" class="...MuiChartsLegend-series...">`, WRAPPING the series swatch and
+// label -- that markup IS the legend's explanatory content, not chrome, and the WO's own risk
+// section says exactly this: "if it vanishes, that is a finding that changes the approach, not a
+// detail to paper over." A blanket `.remove()` would delete the swatch+label along with the click
+// handler. Unwrapped instead: replace the interactive element with a plain, non-interactive one
+// carrying the SAME class/style/children, so the legend keeps every pixel of content while losing
+// only its clickability (irrelevant anyway -- a rasterised PNG has no click handlers regardless).
+const MUI_INTERACTIVE_LEGEND_ITEM_SELECTOR = '.MuiChartsLegend-series';
+function stripInteractiveControls(clone) {
+    clone.querySelectorAll(INTERACTIVE_CONTROL_SELECTOR).forEach((node) => {
+        if (node.matches(MUI_INTERACTIVE_LEGEND_ITEM_SELECTOR)) {
+            const unwrapped = document.createElement('span');
+            unwrapped.className = node.className;
+            const style = node.getAttribute('style');
+            if (style)
+                unwrapped.setAttribute('style', style);
+            while (node.firstChild)
+                unwrapped.appendChild(node.firstChild);
+            node.replaceWith(unwrapped);
+            return;
+        }
+        node.remove();
+    });
+}
+// Walks `sourceRoot` and `cloneRoot` in lockstep (both traversed in the same, deterministic
+// document order, since `cloneRoot` is a structural copy of `sourceRoot`) and writes each node's
+// RESOLVED style for `properties` onto the clone as an inline `style` attribute. This is what
+// carries the page's emotion CSS classes (which the clone keeps by name but not by rule) into a
+// standalone file that has no access to that stylesheet.
+function inlineComputedStyles(sourceRoot, cloneRoot, properties) {
+    const sourceNodes = [sourceRoot, ...sourceRoot.querySelectorAll('*')];
+    const cloneNodes = [cloneRoot, ...cloneRoot.querySelectorAll('*')];
+    sourceNodes.forEach((sourceNode, index) => {
+        const cloneNode = cloneNodes[index];
+        if (!cloneNode || cloneNode.nodeType !== Node.ELEMENT_NODE)
+            return;
+        const computed = window.getComputedStyle(sourceNode);
+        const declarations = properties
+            .map((property) => `${property}: ${computed.getPropertyValue(property)}`)
+            .join('; ');
+        const existing = cloneNode.getAttribute('style');
+        cloneNode.setAttribute('style', existing ? `${existing}; ${declarations}` : declarations);
+    });
+}
+function svgToBlob(svg) {
     return new Blob([new XMLSerializer().serializeToString(svg)], { type: 'image/svg+xml;charset=utf-8' });
 }
 function download(blob, filename) {
@@ -19,23 +135,71 @@ function download(blob, filename) {
     anchor.remove();
     URL.revokeObjectURL(url);
 }
-/** Serializes the first SVG rendered inside a chart container and downloads it. */
-export function exportChartSvg(chartContainer, filename = 'chart.svg') {
-    const blob = svgBlob(chartContainer);
-    download(blob, filename);
-    return blob;
+// The chart's own surface, faithfully styled -- true vector, chart only. Does not gain the
+// legend/size key rendered beside it; that is correct for what this format is for (Part A).
+function chartSvgBlob(chartContainer) {
+    const svg = findChartSvg(chartContainer);
+    const clone = svg.cloneNode(true);
+    inlineComputedStyles(svg, clone, CHART_STYLE_PROPERTIES);
+    // reviewer finding: MUI's ChartsSurface only ever gives the root <svg> a `viewBox` -- its actual
+    // pixel size comes from CSS (`width: 100%; height: 100%` against the page's own layout), which
+    // has nothing to resolve against once cloned out to a standalone file. Without an explicit
+    // width/height a standalone viewer falls back to the SVG UA default (typically 300x150).
+    const rect = svg.getBoundingClientRect();
+    clone.setAttribute('width', Math.ceil(rect.width) || svg.clientWidth || 1);
+    clone.setAttribute('height', Math.ceil(rect.height) || svg.clientHeight || 1);
+    clone.setAttribute('xmlns', SVG_NS);
+    return svgToBlob(clone);
+}
+// The whole container, as seen -- chart plus everything the panel renders beside it, via an SVG
+// `<foreignObject>` wrapping a styled clone of the container's actual DOM. Standard platform
+// technique for DOM rasterisation without a library: the intermediate SVG is never downloaded, only
+// decoded into an `Image` and drawn onto a `<canvas>`.
+function containerSvgBlob(chartContainer) {
+    const rect = chartContainer.getBoundingClientRect();
+    const width = Math.ceil(rect.width) || chartContainer.scrollWidth || 1;
+    const height = Math.ceil(rect.height) || chartContainer.scrollHeight || 1;
+    const clone = chartContainer.cloneNode(true);
+    inlineComputedStyles(chartContainer, clone, [...CHART_STYLE_PROPERTIES, ...CONTAINER_LAYOUT_STYLE_PROPERTIES]);
+    // UCM-CHART-18 scope item 2, deliberately AFTER inlineComputedStyles, never before:
+    // inlineComputedStyles walks `chartContainer` and `clone` IN LOCKSTEP BY INDEX
+    // (`sourceNodes[i]` <-> `cloneNodes[i]`, both from `querySelectorAll('*')`). Removing nodes from
+    // the clone first would shift every subsequent index out of alignment with the still-intact
+    // source tree, so elements downstream of the first removal would silently receive a DIFFERENT
+    // element's computed style -- wrong, but not obviously wrong, since the result still looks like a
+    // styled export.
+    stripInteractiveControls(clone);
+    clone.setAttribute('xmlns', XHTML_NS);
+    const svg = document.createElementNS(SVG_NS, 'svg');
+    svg.setAttribute('xmlns', SVG_NS);
+    svg.setAttribute('width', width);
+    svg.setAttribute('height', height);
+    svg.setAttribute('viewBox', `0 0 ${width} ${height}`);
+    const foreignObject = document.createElementNS(SVG_NS, 'foreignObject');
+    foreignObject.setAttribute('width', '100%');
+    foreignObject.setAttribute('height', '100%');
+    foreignObject.appendChild(clone);
+    svg.appendChild(foreignObject);
+    return { svg, width, height };
 }
-/** Rasterizes the first SVG rendered inside a chart container at two-times scale and downloads it. */
-export function exportChartPng(chartContainer, filename = 'chart.png', backgroundColour) {
-    const source = svgBlob(chartContainer);
+// UCM-CHART-17 risk section, confirmed live (not assumed): an SVG containing a `<foreignObject>`
+// taints the canvas on `toBlob` in Chrome -- unconditionally, even with zero external references
+// (verified: a foreignObject holding nothing but plain styled text already triggers
+// `SecurityError: Tainted canvases may not be exported`) -- but ONLY when the image is loaded via
+// a `blob:` object URL. The identical SVG loaded via a `data:` URI does not taint the canvas at
+// all. This is why the SVG-only export (`chartSvgBlob`, no foreignObject) can keep using
+// `URL.createObjectURL` for its own download, while the PNG path's `Image` source specifically
+// must be a `data:` URI. No rasteriser dependency needed once this is accounted for.
+async function svgToDataUri(svg) {
+    const svgString = await svgToBlob(svg).text();
+    return `data:image/svg+xml;charset=utf-8,${encodeURIComponent(svgString)}`;
+}
+async function rasterize(svg, width, height, backgroundColour) {
+    const dataUri = await svgToDataUri(svg);
     return new Promise((resolve, reject) => {
-        const url = URL.createObjectURL(source);
         const image = new Image();
         image.onload = () => {
             try {
-                const svg = findSvg(chartContainer);
-                const width = Number(svg.getAttribute('width')) || svg.clientWidth || 1;
-                const height = Number(svg.getAttribute('height')) || svg.clientHeight || 1;
                 const canvas = document.createElement('canvas');
                 canvas.width = width * 2;
                 canvas.height = height * 2;
@@ -44,24 +208,36 @@ export function exportChartPng(chartContainer, filename = 'chart.png', backgroun
                 context.fillRect(0, 0, canvas.width, canvas.height);
                 context.drawImage(image, 0, 0, canvas.width, canvas.height);
                 canvas.toBlob((blob) => {
-                    URL.revokeObjectURL(url);
                     if (!blob) {
                         reject(new Error('Unable to create PNG export.'));
                         return;
                     }
-                    download(blob, filename);
                     resolve(blob);
                 }, 'image/png');
             }
             catch (error) {
-                URL.revokeObjectURL(url);
                 reject(error);
             }
         };
         image.onerror = () => {
-            URL.revokeObjectURL(url);
-            reject(new Error('Unable to load chart SVG for PNG export.'));
+            reject(new Error('Unable to rasterize chart container for PNG export.'));
         };
-        image.src = url;
+        image.src = dataUri;
     });
 }
+/** Serializes the chart's own SVG surface, styles inlined, and downloads it. */
+export function exportChartSvg(chartContainer, filename = 'chart.svg') {
+    const blob = chartSvgBlob(chartContainer);
+    download(blob, filename);
+    return blob;
+}
+/**
+ * Rasterizes the whole chart container -- chart, legend, size key, footnotes, everything the panel
+ * renders beside the chart -- at two-times scale and downloads it.
+ */
+export async function exportChartPng(chartContainer, filename = 'chart.png', backgroundColour) {
+    const { svg, width, height } = containerSvgBlob(chartContainer);
+    const blob = await rasterize(svg, width, height, backgroundColour);
+    download(blob, filename);
+    return blob;
+}

package/dist/i18n/chartsTranslations.js

@@ -23,12 +23,29 @@ export const chartsTranslations = {
         en: 'Export SVG',
         sw: 'Hamisha SVG',
     },
+    // UCM-CHART-17: the two formats now genuinely differ (SVG = chart only, vector; PNG = the whole
+    // panel as shown, legend included) -- the label alone no longer says so, the tooltip does.
+    'ChartFrame.EXPORT_SVG_TOOLTIP': {
+        de: 'Skalierbare Vektorgrafik des Diagramms allein, ohne Legende.',
+        fr: 'Image vectorielle du graphique seul, sans la légende.',
+        en: 'Scalable vector image of the chart alone, without the legend.',
+        sw: 'Picha ya vekta inayoweza kubadilishwa ukubwa ya chati pekee, bila maelezo.',
+    },
     'ChartFrame.EXPORT_PNG_LABEL': {
         de: 'PNG exportieren',
         fr: 'Exporter en PNG',
         en: 'Export PNG',
         sw: 'Hamisha PNG',
     },
+    // ui_reviewer finding: the original wording named the legend but not the size key/footnotes
+    // the PNG also carries -- named explicitly now, matching the Envelope's own Goal wording
+    // ("legend, size key and footnotes").
+    'ChartFrame.EXPORT_PNG_TOOLTIP': {
+        de: 'Bild des ganzen Kartenbereichs, wie angezeigt, inklusive Legende, Grössenschlüssel und Fussnoten.',
+        fr: 'Image de toute la zone de la carte, telle qu’affichée, légende, clé de taille et notes de bas de page comprises.',
+        en: 'Image of the whole card area as shown, including the legend, size key, and footnotes.',
+        sw: 'Picha ya eneo lote la kadi kama linavyoonyeshwa, ikijumuisha maelezo, kifunguo cha ukubwa, na maelezo ya chini.',
+    },
     'ChartFrame.EXPORT_ERROR': {
         de: 'Das Diagramm konnte nicht exportiert werden.',
         fr: 'Impossible d’exporter le graphique.',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@micha.bigler/ui-core-micha",
-  "version": "3.2.1",
+  "version": "3.3.1",
   "main": "dist/index.js",
   "module": "dist/index.js",
   "sideEffects": [

package/src/components/charts/ChartFrame.jsx

@@ -6,6 +6,7 @@ import {
   CircularProgress,
   Paper,
   Stack,
+  Tooltip,
   Typography,
 } from '@mui/material';
 import { useTranslation } from 'react-i18next';
@@ -107,6 +108,32 @@ export function ChartFrame({
     }
   };
 
+  // UCM-CHART-17: SVG and PNG now produce genuinely different content (chart-only vector vs. the
+  // whole card as shown, legend included) -- the label alone no longer says so, so both buttons
+  // carry a tooltip stating the difference plainly, per the Envelope's own requirement.
+  const exportButtons = (
+    <>
+      {options.svg !== false && (
+        // `describeChild`: the tooltip DESCRIBES the button, it must not REPLACE its accessible
+        // name -- MUI's default (`aria-label` = title) would silently rename "Export SVG" to
+        // whatever the tooltip says, breaking both the button's own identity and every existing
+        // `getByRole('button', { name: 'Export SVG' })` query.
+        <Tooltip title={t('ChartFrame.EXPORT_SVG_TOOLTIP')} describeChild>
+          <Button size="small" onClick={() => runExport('svg')}>
+            {t('ChartFrame.EXPORT_SVG_LABEL')}
+          </Button>
+        </Tooltip>
+      )}
+      {options.png !== false && (
+        <Tooltip title={t('ChartFrame.EXPORT_PNG_TOOLTIP')} describeChild>
+          <Button size="small" onClick={() => runExport('png')}>
+            {t('ChartFrame.EXPORT_PNG_LABEL')}
+          </Button>
+        </Tooltip>
+      )}
+    </>
+  );
+
   let content = children;
   if (loading) {
     content = <CircularProgress aria-label={t('ChartFrame.LOADING')} />;
@@ -173,31 +200,13 @@ export function ChartFrame({
           <Typography variant="caption" color="text.secondary">{meta}</Typography>
           {exportsEnabled && (
             <Stack direction="row" spacing={1} justifyContent="flex-end">
-              {options.svg !== false && (
-                <Button size="small" onClick={() => runExport('svg')}>
-                  {t('ChartFrame.EXPORT_SVG_LABEL')}
-                </Button>
-              )}
-              {options.png !== false && (
-                <Button size="small" onClick={() => runExport('png')}>
-                  {t('ChartFrame.EXPORT_PNG_LABEL')}
-                </Button>
-              )}
+              {exportButtons}
             </Stack>
           )}
         </Box>
       ) : exportsEnabled && (
         <Stack direction="row" spacing={1} justifyContent="flex-end" sx={{ mt: 2 }}>
-          {options.svg !== false && (
-            <Button size="small" onClick={() => runExport('svg')}>
-              {t('ChartFrame.EXPORT_SVG_LABEL')}
-            </Button>
-          )}
-          {options.png !== false && (
-            <Button size="small" onClick={() => runExport('png')}>
-              {t('ChartFrame.EXPORT_PNG_LABEL')}
-            </Button>
-          )}
+          {exportButtons}
         </Stack>
       )}
     </Paper>