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

package/CHANGELOG.md

@@ -2,6 +2,31 @@
 
 Only notable, user-facing changes. Not every version — see `WORK_ORDERS.md` for the full history.
 
+## 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,7 @@ prefixed ID; never reuse a bare flat number across workstreams.
 
 | ID | Titel | Beschreibung | Datum | Status | Commit(s) | Notiz |
 |---|---|---|---|---|---|---|
+| 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,84 @@
-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.
+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',
+];
+// 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');
+// 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 +91,63 @@ 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]);
+    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 };
+}
+// 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)}`;
 }
-/** 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);
+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 +156,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.0",
   "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>

package/src/components/charts/exportChart.js

@@ -1,12 +1,88 @@
-function findSvg(chartContainer) {
-  const svg = 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.
+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',
+];
+
+// 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?.querySelector('svg.MuiChartsSurface-root') || 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');
+// 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' });
 }
 
@@ -21,26 +97,70 @@ function download(blob, filename) {
   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);
 }
 
-/** 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);
+// 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]);
+  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 };
+}
+
+// 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;
@@ -49,23 +169,37 @@ 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/src/i18n/chartsTranslations.ts

@@ -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/tests/ChartFrame.test.jsx

@@ -22,7 +22,9 @@ const resources = {
       'ChartFrame.EMPTY_DEFAULT': 'No data available.',
       'ChartFrame.ERROR_DEFAULT': 'The chart could not be loaded.',
       'ChartFrame.EXPORT_SVG_LABEL': 'Export SVG',
+      'ChartFrame.EXPORT_SVG_TOOLTIP': 'Scalable vector image of the chart alone, without the legend.',
       'ChartFrame.EXPORT_PNG_LABEL': 'Export PNG',
+      'ChartFrame.EXPORT_PNG_TOOLTIP': 'Image of the whole card area as shown, including the legend, size key, and footnotes.',
       'ChartFrame.EXPORT_ERROR': 'The chart could not be exported.',
     },
   },
@@ -32,7 +34,9 @@ const resources = {
       'ChartFrame.EMPTY_DEFAULT': 'Aucune donnée disponible.',
       'ChartFrame.ERROR_DEFAULT': 'Impossible de charger le graphique.',
       'ChartFrame.EXPORT_SVG_LABEL': 'Exporter en SVG',
+      'ChartFrame.EXPORT_SVG_TOOLTIP': 'Image vectorielle du graphique seul, sans la légende.',
       'ChartFrame.EXPORT_PNG_LABEL': 'Exporter en PNG',
+      'ChartFrame.EXPORT_PNG_TOOLTIP': 'Image de toute la zone de la carte, telle qu’affichée, légende, clé de taille et notes de bas de page comprises.',
       'ChartFrame.EXPORT_ERROR': 'Impossible d’exporter le graphique.',
     },
   },
@@ -162,6 +166,17 @@ describe('ChartFrame', () => {
     await vi.waitFor(() => expect(onExportPng).toHaveBeenCalledOnce());
   });
 
+  // UCM-CHART-17: the two formats now genuinely differ (chart-only vector vs. the whole card as
+  // shown) -- each button must say so, without silently renaming itself in the process (MUI
+  // Tooltip's default `aria-label` behaviour would do exactly that; `describeChild` avoids it).
+  it('describes what each export format contains without replacing the button\'s own accessible name', () => {
+    renderFrame({ exportOptions: true });
+    const svgButton = screen.getByRole('button', { name: 'Export SVG' });
+    const pngButton = screen.getByRole('button', { name: 'Export PNG' });
+    expect(svgButton.getAttribute('title')).toBe('Scalable vector image of the chart alone, without the legend.');
+    expect(pngButton.getAttribute('title')).toBe('Image of the whole card area as shown, including the legend, size key, and footnotes.');
+  });
+
   it('keeps the controls row rendered in the loading, error and empty states', () => {
     const controls = <button type="button">View selector</button>;
 

package/tests/exportChart.test.js

@@ -0,0 +1,184 @@
+// @vitest-environment jsdom
+import {
+  afterEach, beforeEach, describe, expect, it, vi,
+} from 'vitest';
+
+import { exportChartPng, exportChartSvg } from '../src/components/charts/exportChart';
+
+// UCM-CHART-17: a container shaped like `AccessGapScatterPanel` -- the chart's own MUI surface,
+// PLUS a second SVG (the hand-built size key) and an HTML legend beside it, exactly the shape that
+// broke "the first SVG" (scope item 3) and dropped the legend from every export (Part A, defect 2).
+function buildContainer() {
+  const container = document.createElement('div');
+  container.innerHTML = `
+    <div class="legend">Legend HTML</div>
+    <svg class="MuiChartsSurface-root" width="300" height="200">
+      <g><text class="MuiChartsAxis-tickLabel">Alpha</text></g>
+      <line class="MuiChartsAxis-line" x1="0" x2="300" y1="10" y2="10"></line>
+    </svg>
+    <svg class="size-key" width="40" height="40"><circle r="4"></circle></svg>
+  `;
+  document.body.appendChild(container);
+  return container;
+}
+
+describe('exportChartSvg (UCM-CHART-17)', () => {
+  afterEach(() => {
+    document.body.innerHTML = '';
+  });
+
+  it('resolves with its existing signature and returns a Blob', () => {
+    const container = buildContainer();
+    const blob = exportChartSvg(container, 'chart.svg');
+    expect(blob).toBeInstanceOf(Blob);
+    expect(blob.type).toBe('image/svg+xml;charset=utf-8');
+  });
+
+  // reviewer finding: MUI's ChartsSurface only ever carries a `viewBox` -- its real pixel size is
+  // CSS (`width: 100%`), which has nothing to resolve against once cloned out of the page. Without
+  // an explicit width/height a standalone viewer falls back to the SVG UA default (300x150), i.e.
+  // the wrong size regardless of how faithfully everything else is styled.
+  it('sets explicit width/height attributes on the exported SVG, not just the source viewBox', async () => {
+    const container = buildContainer();
+    const blob = exportChartSvg(container);
+    const text = await blob.text();
+    expect(text).toMatch(/<svg[^>]*\bwidth="\d+"/);
+    expect(text).toMatch(/<svg[^>]*\bheight="\d+"/);
+  });
+
+  // WO scope item 3: the legend sits BEFORE the chart's own svg in this fixture (as it does in
+  // `AccessGapScatterPanel`), and a second, unrelated SVG (the size key) sits after it -- "the
+  // first SVG" would grab neither of those correctly. `MuiChartsSurface-root` is the deliberate,
+  // non-positional signal.
+  it('takes the chart surface deliberately, not the first (or any other) SVG in the container', async () => {
+    const container = buildContainer();
+    const blob = exportChartSvg(container);
+    const text = await blob.text();
+    expect(text).toContain('MuiChartsSurface-root');
+    expect(text).toContain('Alpha');
+    expect(text).not.toContain('size-key');
+  });
+
+  // WO defect 1 + Unit tests: the clone must carry the RESOLVED style, not just the (rule-less,
+  // once serialised standalone) class name -- this is the whole point of the fix.
+  it('inlines computed styles for tick labels and axis strokes onto the cloned SVG', async () => {
+    const container = buildContainer();
+    const tickLabel = container.querySelector('.MuiChartsAxis-tickLabel');
+    tickLabel.style.fontFamily = 'DM Sans';
+    tickLabel.style.fill = 'rgb(10, 20, 30)';
+    const axisLine = container.querySelector('.MuiChartsAxis-line');
+    axisLine.style.stroke = 'rgb(200, 200, 200)';
+
+    const blob = exportChartSvg(container);
+    const text = await blob.text();
+    expect(text).toContain('font-family: &quot;DM Sans&quot;');
+    expect(text).toContain('fill: rgb(10, 20, 30)');
+    expect(text).toContain('stroke: rgb(200, 200, 200)');
+  });
+
+  it('does not gain the legend or size key -- true vector, chart only', async () => {
+    const container = buildContainer();
+    const blob = exportChartSvg(container);
+    const text = await blob.text();
+    expect(text).not.toContain('Legend HTML');
+  });
+
+  it('throws when the container has no SVG at all', () => {
+    const container = document.createElement('div');
+    document.body.appendChild(container);
+    expect(() => exportChartSvg(container)).toThrow(/does not contain an SVG/);
+  });
+});
+
+describe('exportChartPng (UCM-CHART-17)', () => {
+  let originalGetContext;
+  let originalToBlob;
+  let originalImage;
+
+  beforeEach(() => {
+    originalGetContext = HTMLCanvasElement.prototype.getContext;
+    originalToBlob = HTMLCanvasElement.prototype.toBlob;
+    // jsdom has no real canvas/image-decoding backend (`getContext('2d')` returns null, `Image`
+    // never fires `onload`) -- this stands in for the platform pipeline `exportChartPng` drives,
+    // to test its OWN plumbing (does it resolve, with the right Blob type, for the documented
+    // input shape), not visual output. Visual correctness is the WO's own explicit non-unit-test
+    // gate: open the exported files.
+    HTMLCanvasElement.prototype.getContext = vi.fn(() => ({
+      fillStyle: '',
+      fillRect: vi.fn(),
+      drawImage: vi.fn(),
+    }));
+    HTMLCanvasElement.prototype.toBlob = function toBlob(callback) {
+      callback(new Blob(['png-bytes'], { type: 'image/png' }));
+    };
+    originalImage = global.Image;
+    global.Image = class MockImage {
+      set src(value) {
+        this._src = value;
+        queueMicrotask(() => this.onload?.());
+      }
+
+      // eslint-disable-next-line class-methods-use-this
+      get src() {
+        return this._src;
+      }
+    };
+  });
+
+  afterEach(() => {
+    document.body.innerHTML = '';
+    HTMLCanvasElement.prototype.getContext = originalGetContext;
+    HTMLCanvasElement.prototype.toBlob = originalToBlob;
+    global.Image = originalImage;
+  });
+
+  // WO Unit tests: "the PNG path resolves for a container holding more than one SVG" -- the exact
+  // shape (chart surface + size key) that the pre-fix `findSvg`'s "first SVG" logic depended on
+  // being ordered correctly.
+  it('resolves with its existing signature for a container holding more than one SVG', async () => {
+    const container = buildContainer();
+    const blob = await exportChartPng(container, 'chart.png', '#ffffff');
+    expect(blob).toBeInstanceOf(Blob);
+    expect(blob.type).toBe('image/png');
+  });
+
+  // Risk section, confirmed live against a real browser (see `rasterize`'s own comment): a
+  // `blob:` object URL taints the canvas the moment the SVG carries a `<foreignObject>`, in every
+  // case tested, `toBlob` then throws regardless of content. A `data:` URI does not. Locking this
+  // in so a future edit reaching back for `URL.createObjectURL` here regresses to the taint, not
+  // just to a style change.
+  it('loads the container SVG as a data: URI, never a blob: URL, to avoid canvas tainting', async () => {
+    const container = buildContainer();
+    let capturedSrc;
+    global.Image = class CapturingImage {
+      set src(value) {
+        capturedSrc = value;
+        this._src = value;
+        queueMicrotask(() => this.onload?.());
+      }
+
+      // eslint-disable-next-line class-methods-use-this
+      get src() {
+        return this._src;
+      }
+    };
+    await exportChartPng(container, 'chart.png', '#ffffff');
+    expect(capturedSrc).toMatch(/^data:image\/svg\+xml/);
+  });
+
+  it('rejects when the container fails to rasterize', async () => {
+    global.Image = class FailingImage {
+      set src(value) {
+        this._src = value;
+        queueMicrotask(() => this.onerror?.());
+      }
+
+      // eslint-disable-next-line class-methods-use-this
+      get src() {
+        return this._src;
+      }
+    };
+    const container = buildContainer();
+    await expect(exportChartPng(container)).rejects.toThrow(/rasterize/);
+  });
+});

package/work-orders/UCM-CHART-17.md

@@ -0,0 +1,195 @@
+# UCM-CHART-17 — The two export buttons make two different promises; make them keep them
+
+## Part A — Envelope
+
+*Authored by the Expertenchat. Authoritative WHAT/WHY.*
+
+### Goal
+
+**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.
+
+### The defect, from the source
+
+`exportChart.js:7-11` clones the first `<svg>` in the container and serialises it raw:
+
+```js
+const svg = findSvg(chartContainer).cloneNode(true);
+svg.setAttribute('xmlns', 'http://www.w3.org/2000/svg');
+return new Blob([new XMLSerializer().serializeToString(svg)], …)
+```
+
+Three consequences, and they compound:
+
+1. **No styles are carried.** MUI X-Charts styles nearly everything through emotion CSS classes —
+   tick fonts and sizes, axis and grid colours, text fill, the theme's typography. The clone keeps
+   `class="MuiChartsAxis-tickLabel css-1abc"` and none of the rules behind it, so a standalone
+   viewer applies bare SVG defaults. This is the "graphically massively different" the operator
+   reported. **The PNG inherits it**, because it rasterises the same blob.
+
+2. **The legend is gone, and that is ours.** `findSvg` takes the *first* `<svg>`, i.e. the chart.
+   Since `HRAM-RES-39`/`HRAM-VIS-2`, consuming panels hide MUI's own legend and render a hand-built
+   one as **HTML** beside the chart, with the size key as a *second* SVG. Both sit outside the
+   exported element. **Before that consolidation, MUI's legend was inside the chart SVG and did get
+   exported** — unstyled, but present. Fixing a legend overlap silently degraded the export, and
+   nobody noticed because nobody opened an exported file.
+
+3. **"The first SVG" is fragile** regardless — a panel that renders any SVG ahead of the chart
+   exports the wrong element. It works today by accident of ordering.
+
+### The decision: two paths, two meanings
+
+The operator chose option C on 2026-08-25. The two buttons already promise different things and
+should stop pretending to be one mechanism:
+
+- **SVG — the chart, faithfully styled.** Keep the clone-and-serialise path, but **inline computed
+  styles onto the cloned nodes** before serialising. Stays true vector: scalable, editable in
+  Illustrator/Inkscape, chart only. It does **not** gain the legend, and that is correct for what
+  this format is for.
+- **PNG — the container, as seen.** Rasterise the whole `chartRef` node rather than the chart SVG, so
+  legend, size key and footnotes are in the file and the output matches the screen by construction.
+
+**Make the difference legible to the user, not only to us.** Two buttons that produce visibly
+different content need labels or tooltips saying so; today they read as one thing in two formats.
+
+### Scope
+
+**`src/components/charts/exportChart.js`**
+
+1. **Inline computed styles** into the SVG clone before serialisation. Walk the clone against the
+   live tree and write the resolved properties as inline style. Keep it to the properties that matter
+   for chart rendering rather than dumping every computed property — a full dump produces enormous
+   files and is its own defect.
+2. **Rasterise the container for PNG.** The `chartRef` node ChartFrame already passes
+   (`ChartFrame.jsx:138`) is the right root — it holds the chart plus everything the panel renders
+   beside it.
+3. **Stop relying on "the first SVG"** for the SVG path — take the chart deliberately, not
+   positionally.
+4. **Preserve the public signatures.** `exportChartSvg(container, filename)` and
+   `exportChartPng(container, filename, backgroundColour)` are consumed by `ChartFrame` and possibly
+   directly; the change is what they produce, not how they are called.
+
+**`src/components/charts/ChartFrame.jsx`** — labels or tooltips that distinguish the two outputs.
+Translated via the existing `chartsTranslations` path, not hard-coded.
+
+### Non-goals / do not touch
+
+- The chart presets, `resolveChartLayout`, the size scale, the axis bands.
+- Consuming apps. hram's six panels with `exportOptions` gain the fix through the pin bump; that is
+  a separate row.
+- Adding export to panels that do not have it (`HRAM-RES-43` did that for one panel in hram).
+
+### Risks
+
+- **A rasteriser is a new dependency in shared-core**, and this package currently has exactly one
+  runtime dependency (`@fontsource/dm-sans`). Adding a second is a real decision — check whether the
+  job can be done with the platform's own APIs first, and if a library is warranted, say why in the
+  WO's implementation record rather than just installing one.
+- **Canvas tainting.** DOM-to-canvas rasterisation routes through an SVG `foreignObject`; any
+  external image or font reference taints the canvas and `toBlob` throws. The existing PNG path
+  already has this exposure and may already be failing on it — worth checking before assuming the new
+  path introduces it.
+- **Fonts in the SVG.** Inlining computed styles records `font-family: "DM Sans"`, which a machine
+  without that font will substitute. Either embed the font or accept the substitution — but decide it
+  and write it down, because a silently substituted font is exactly the "looks different" complaint
+  this WO is fixing.
+- **Style inlining can bloat.** See scope item 1.
+- **This has no test that can see it.** A unit test can assert that a `style` attribute exists; it
+  cannot see that the file looks right. See verification.
+
+### Verification
+
+**Open the exported files.** That is the whole gate, and its absence is why this defect shipped: the
+SVG in a viewer and the PNG in an image viewer, both compared against the rendered panel.
+
+Do it for **two** panels with different shapes — one with a hand-built legend and size key
+(`AccessGapScatterPanel`), one without — because the legend behaviour is precisely what differs
+between the two export paths.
+
+Unit tests: the SVG clone carries inlined styles for tick labels and axis strokes; both entry points
+still resolve with their existing signatures; the PNG path resolves for a container holding more than
+one SVG.
+
+---
+
+## Part B — Implementation map
+
+`.claude/models.local.json` has no local override, so the default applies: `implementation.runtime`
+is `claude`/`sonnet` — the Orchestrator implemented directly, no Codex dispatch.
+
+**Dependency decision (risk section, and Part C's approval gate):** no library added. Checked
+first, per the WO's own instruction, and it held up: the platform's own `<foreignObject>` → `Image`
+→ `<canvas>` pipeline works for arbitrary DOM rasterisation with no dependency at all. The one
+obstacle — **confirmed live, not assumed** — is that Chrome taints the canvas on `toBlob`
+unconditionally the moment the source SVG contains a `<foreignObject>` with HTML content, even with
+zero external references (a minimal repro: a `<foreignObject>` holding one `<div>` with inline
+`color: red` styling and no images/fonts/external refs still throws `SecurityError: Tainted
+canvases may not be exported` when the SVG is loaded via `URL.createObjectURL`). The SAME SVG loaded
+via a `data:` URI instead does **not** taint the canvas — confirmed with an identical minimal repro,
+then re-confirmed end-to-end against the real `exportChartPng`/`ChartFrame` (real Chrome, via the
+dev harness). This is why the approval gate never triggered: the platform-only approach IS viable,
+it just needed the `blob:` → `data:` URI swap in `rasterize` (`exportChart.js`), documented inline
+there.
+
+**Canvas tainting on the PRE-FIX path:** checked per the risk section's own instruction ("may
+already be failing on it"). It was not — a plain SVG-only blob (no `foreignObject`) loaded via
+`URL.createObjectURL` does **not** taint the canvas; the exposure is specific to the `foreignObject`
+this WO's PNG path adds, not a pre-existing defect.
+
+**Verification (both real-browser, via the dev harness's module graph — `dev/entries.jsx` never
+committed a probe entry, all verification was done by dynamically rendering `ChartFrame` into a
+detached container and calling the real `exportChartSvg`/`exportChartPng`):**
+
+- Panel shape WITH a hand-built legend + size key (mirroring `AccessGapScatterPanel`: MUI's own
+  legend hidden, a `<div>` HTML legend with a coloured swatch, a second `<svg>` "size key" beside
+  the chart): PNG rasterised at 2x scale, no taint, and pixel-sampling the produced PNG at the
+  swatch's and size-key's known screen coordinates read back their EXACT source colours
+  (`rgb(25,118,210)` / `#1976d2` and `rgb(156,39,176)` / `#9c27b0`) — the legend and size key are
+  genuinely present in the raster, not just "no error thrown". SVG export of the same panel:
+  contains `MuiChartsSurface-root` (the chart), does NOT contain the legend's own text/markup —
+  chart-only as designed.
+- Panel shape WITHOUT a hand-built legend (plain `BarChart` inside `ChartFrame`): both exports
+  resolve cleanly, no regression for the common case.
+
+Context package used: `exportChart.js` (rewritten in full, was short), `ChartFrame.jsx:42-108`
+(the `runExport`/`exportOptions` wiring) and `:137-151` (`chartRef`, the export root — confirmed
+correct: it wraps `content` only, excluding the meta/export-button footer), `chartsTranslations.ts`
+(new `EXPORT_SVG_TOOLTIP`/`EXPORT_PNG_TOOLTIP` keys, all four locales).
+
+---
+
+## Part C — Orchestrator only
+
+> **STOP — everything below addresses the Orchestrator.**
+
+**Tier 3 · verification: opened files for two panel shapes, plus the unit tests above**
+
+Shared-core, and — depending on scope item 2's answer — a dependency addition, which is its own
+approval surface under Core Behaviour. If a library is needed, **stop and get the operator's
+approval for that specific dependency** before adding it; the approval given on 2026-08-25 was for
+the approach, not for a named package.
+
+- `reviewer` — the inlining's completeness and the taint/font questions.
+- `ui_reviewer` — whether the two buttons now read as two different things to a user.
+- `sec_reviewer` — not run; no auth, data or exposure surface.
+
+### Release
+
+**Minor → 3.3.0**, per the operator. The PNG's *content* changes (it now includes the legend and
+footnotes), so the CHANGELOG entry must **lead** with that, in the style `UCM-CHART-15` established:
+a consumer who bumps and finds their exported PNGs different should read why in the first line, not
+find it in a bullet.
+
+### Register
+
+Row `UCM-CHART-17`, both review notes, the published version, landing SHA(s) in a second commit
+before the push. Record what the opened files actually looked like — that evidence is the point.
+
+Consumer adoption (hram's pin bump) is a separate row; a shared-core fix that is published but not
+consumed is not finished.
+
+### Log
+
+- **2026-08-25** — Envelope authored after the operator reported exports producing graphically very
+  different plots. Diagnosed from source, not reproduced by the Expertenchat: the operator has seen
+  the files. Option C chosen — SVG stays vector and chart-only, PNG becomes what the screen shows.