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

package/CHANGELOG.md

@@ -2,6 +2,25 @@
 
 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,

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-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). |

package/dist/components/charts/exportChart.js

@@ -27,10 +27,19 @@ const XHTML_NS = 'http://www.w3.org/1999/xhtml';
 // 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
@@ -58,6 +67,41 @@ function findChartSvg(chartContainer) {
         throw new Error('Chart container does not contain an SVG element.');
     return 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
@@ -117,6 +161,14 @@ function containerSvgBlob(chartContainer) {
     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);

package/package.json

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

package/src/components/charts/exportChart.js

@@ -29,10 +29,19 @@ const XHTML_NS = 'http://www.w3.org/1999/xhtml';
 // 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 --
@@ -62,6 +71,42 @@ function findChartSvg(chartContainer) {
   return 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
@@ -125,6 +170,14 @@ function containerSvgBlob(chartContainer) {
 
   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');

package/tests/exportChart.test.js

@@ -83,6 +83,29 @@ describe('exportChartSvg (UCM-CHART-17)', () => {
     expect(text).not.toContain('Legend HTML');
   });
 
+  // UCM-CHART-18 scope item 3: a rotated element (e.g. a legend swatch rotated into a diamond)
+  // must export rotated -- `transform` was missing from the inlined properties entirely. Applied
+  // via a STYLESHEET rule, not an inline style directly on the source node -- `cloneNode` copies
+  // an element's own inline `style` ATTRIBUTE verbatim regardless of what `inlineComputedStyles`
+  // does, which would make a test that sets `tickLabel.style.transform` pass whether or not
+  // `transform` is actually in the inlined property list (exactly the "asserts a number, proves
+  // nothing" trap the WO's risk section warns about) -- a class-based rule is only ever picked up
+  // through `getComputedStyle`, so it genuinely exercises `inlineComputedStyles`.
+  it('inlines the resolved transform onto the cloned chart surface', async () => {
+    const container = buildContainer();
+    const style = document.createElement('style');
+    style.textContent = '.rotated-probe { transform: rotate(45deg); transform-origin: 20% 30%; }';
+    document.head.appendChild(style);
+    const tickLabel = container.querySelector('.MuiChartsAxis-tickLabel');
+    tickLabel.classList.add('rotated-probe');
+
+    const blob = exportChartSvg(container);
+    const text = await blob.text();
+    document.head.removeChild(style);
+    expect(text).toMatch(/transform:\s*rotate\(45deg\)/);
+    expect(text).toMatch(/transform-origin:\s*20%\s*30%/);
+  });
+
   it('throws when the container has no SVG at all', () => {
     const container = document.createElement('div');
     document.body.appendChild(container);
@@ -132,6 +155,28 @@ describe('exportChartPng (UCM-CHART-17)', () => {
     global.Image = originalImage;
   });
 
+  // Captures the actual intermediate SVG `exportChartPng` builds (intercepting the `Image` src it
+  // loads, per `rasterize`'s own data:-URI choice -- see the taint-avoidance test above) and
+  // decodes it back to markup, so a test can inspect exactly what got serialised rather than only
+  // whether the call resolved.
+  async function captureExportedMarkup(container, backgroundColour = '#ffffff') {
+    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', backgroundColour);
+    return decodeURIComponent(capturedSrc.replace(/^data:image\/svg\+xml;charset=utf-8,/, ''));
+  }
+
   // 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.
@@ -166,6 +211,90 @@ describe('exportChartPng (UCM-CHART-17)', () => {
     expect(capturedSrc).toMatch(/^data:image\/svg\+xml/);
   });
 
+  // UCM-CHART-18 defect 1: `chartRef` wraps `children` only, so a panel's own controls (e.g. an
+  // info `IconButton` in the footer) are inside what gets rasterised. An exported image should
+  // show what the chart communicates, not what can be clicked. The button is placed BEFORE a
+  // later, unrelated sibling (reviewer finding: the original fixture had the button as the LAST
+  // descendant, so a "strip before inline" ordering regression would still have left every
+  // asserted node's index aligned and the test would have passed either way) -- `After the button`
+  // is what actually exercises the lockstep-index trap the WO names as the single most likely way
+  // to get this wrong.
+  it('drops interactive controls from the whole-container PNG, keeping non-interactive siblings both before and after it', async () => {
+    const container = buildContainer();
+    // The distinctive colour on `#after-button`, applied via a stylesheet rule (so it is only
+    // ever picked up through `getComputedStyle`, never copied verbatim by `cloneNode`), is what
+    // actually exercises the lockstep-index trap: content-presence assertions alone pass whether
+    // or not the button is removed before or after inlining (removing a node shifts which style
+    // string lands on which SURVIVING element, but every surviving TEXT NODE is still there
+    // either way) -- only checking that THIS specific element carries THIS specific colour proves
+    // its index wasn't shifted onto a neighbour's style by an out-of-order removal.
+    const style = document.createElement('style');
+    style.textContent = '#after-button { color: rgb(1, 2, 3); }';
+    document.head.appendChild(style);
+    const footer = document.createElement('div');
+    footer.innerHTML = '<span>Caveat note</span><button type="button">More about these caveats</button><span id="after-button">After the button</span>';
+    container.appendChild(footer);
+
+    const svgMarkup = await captureExportedMarkup(container);
+    document.head.removeChild(style);
+    expect(svgMarkup).not.toContain('<button');
+    expect(svgMarkup).not.toContain('More about these caveats');
+    expect(svgMarkup).toContain('Caveat note');
+    const afterButtonMatch = svgMarkup.match(/<span id="after-button"[^>]*style="([^"]*)"/);
+    expect(afterButtonMatch).not.toBeNull();
+    expect(afterButtonMatch[1]).toContain('color: rgb(1, 2, 3)');
+  });
+
+  it('drops an anchor-based drill-down link, keeping its non-interactive siblings', async () => {
+    const container = buildContainer();
+    const footer = document.createElement('div');
+    footer.innerHTML = '<a href="/details">View details</a><span>Static note</span>';
+    container.appendChild(footer);
+
+    const svgMarkup = await captureExportedMarkup(container);
+    expect(svgMarkup).not.toContain('<a ');
+    expect(svgMarkup).not.toContain('View details');
+    expect(svgMarkup).toContain('Static note');
+  });
+
+  // Risk section counter-check: MUI's own chart legend can itself be interactive -- this must
+  // remove OPERATION, not CONTENT. A legend built from non-interactive markup (as every affected
+  // hram panel's hand-built legend is, per the WO) must survive completely intact.
+  it('keeps a non-interactive legend fully intact -- removes operation, not content', async () => {
+    const container = buildContainer();
+    // the fixture's own `.legend` div ("Legend HTML") already carries no button/input/role --
+    // confirm it survives the same export that strips the footer's button above.
+    const svgMarkup = await captureExportedMarkup(container);
+    expect(svgMarkup).toContain('Legend HTML');
+  });
+
+  // reviewer + ui_reviewer finding, independently: MUI's own chart legend, when interactive
+  // (`onItemClick`/`toggleVisibilityOnClick`), renders each item as `<button role="button"
+  // class="...MuiChartsLegend-series...">` wrapping the swatch+label -- that markup IS the
+  // legend's content. A blanket removal would delete it along with the click handler; this is the
+  // WO's own risk section made concrete, and it must be UNWRAPPED (content kept, button-ness
+  // dropped), not removed.
+  it('unwraps an interactive MUI legend item instead of removing it -- keeps the swatch and label', async () => {
+    const container = buildContainer();
+    const legendUl = document.createElement('ul');
+    legendUl.className = 'MuiChartsLegend-root';
+    legendUl.innerHTML = `
+      <li data-series="opened">
+        <button type="button" role="button" class="MuiChartsLegend-series">
+          <span class="MuiChartsLegend-mark" style="background-color: rgb(25, 118, 210);"></span>
+          <span class="MuiChartsLegend-label">Opened</span>
+        </button>
+      </li>
+    `;
+    container.appendChild(legendUl);
+
+    const svgMarkup = await captureExportedMarkup(container);
+    expect(svgMarkup).not.toContain('<button');
+    expect(svgMarkup).toContain('MuiChartsLegend-series');
+    expect(svgMarkup).toContain('MuiChartsLegend-mark');
+    expect(svgMarkup).toContain('Opened');
+  });
+
   it('rejects when the container fails to rasterize', async () => {
     global.Image = class FailingImage {
       set src(value) {

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

@@ -0,0 +1,200 @@
+# UCM-CHART-18 — The PNG export shows what the chart says, not what the user can click
+
+## Part A — Envelope
+
+*Authored by the Expertenchat. Authoritative WHAT/WHY.*
+
+### Goal
+
+The whole-container PNG export contains the chart and everything that **explains** it, and none of the
+controls that **operate** it. And a rotated element exports rotated.
+
+### Two defects, one file, a few lines apart
+
+Both raised by `HRAM-CHT-7`'s independent `ui_reviewer` on 2026-08-25 and confirmed — partly by
+reading, partly live in the running app.
+
+**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`. Anything a
+panel renders as children is now in the file. In hram:
+
+- `StructuralReachabilityPanel.jsx:468` — the footer "More about these caveats" `IconButton`, always
+  visible, so **every** PNG of that panel carries a button.
+- `AllocationPerformancePanel.jsx:536,548` — the drill-down `Button`, and `ResearchDrilldownPanel`
+  itself when open, both inside the `<ChartFrame>` children.
+- `OptimizationResultsPanel.jsx:1120,1141` — the same shape on the frontier chart.
+
+**2. `transform` is not inlined.** `CHART_STYLE_PROPERTIES` (`:32-36`) and
+`CONTAINER_LAYOUT_STYLE_PROPERTIES` (`:44-52`) do not list it, so
+`OptimizationResultsPanel.jsx:1107`'s rotated legend swatch exports as a **square instead of a
+diamond**.
+
+### Why this is fixed here and not in the consuming app
+
+The alternative was moving each panel's controls out of `children` into `ChartFrame`'s `controls` /
+`toolbar` slots, which sit outside `chartRef`. That was rejected, 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. Solved generically here, it also holds for every
+  consumer nobody has looked at.
+- **It would undo a deliberate design decision.** `StructuralReachabilityPanel`'s info affordance sits
+  in the **footer**, beside the caveat line, because `HRAM-RES-30` put it there. Hoisting it into the
+  toolbar to dodge an export defect would trade a design choice for a workaround.
+
+After this, hram needs **only a pin bump** — `HRAM-CHT-8` becomes a consumer row, not a rebuild of
+three panels.
+
+### Scope
+
+`src/components/charts/exportChart.js`
+
+1. **Drop interactive controls from the container clone** in `containerSvgBlob` (`:120`) — `button`,
+   `input`, `select`, `textarea`, `[role="button"]` at minimum. The SVG path is unaffected: it
+   exports the chart surface, which holds no HTML controls.
+
+2. **Do it *after* `inlineComputedStyles`, never before.** That function walks source and clone
+   **in lockstep by index** (`:70-77`, `sourceNodes[index]` ↔ `cloneNodes[index]`). Removing nodes
+   from the clone first shifts every subsequent index, so elements silently receive their
+   neighbours' styles — an export that looks plausible and is wrong everywhere after the first
+   removal. **This is the single most likely way to get this WO wrong.**
+
+3. **Add `transform` (and `transform-origin`) to the inlined properties.**
+
+### Non-goals / do not touch
+
+- The SVG export path, `findChartSvg`, the `data:`-URI decision, the taint workaround —
+  `UCM-CHART-17`, done and verified.
+- `ChartFrame`'s slot structure. `chartRef` wrapping `children` only is correct; the fix is what the
+  rasteriser does with them.
+- The consuming panels. hram's adoption is `HRAM-CHT-8`.
+
+### Risks
+
+- **The lockstep-index trap.** Scope item 2. Name it in the code comment too, not only here.
+- **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 to this change. 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 is a finding that changes the approach, not a detail to paper
+  over.
+- **`transform` may double-apply on SVG nodes.** An SVG element can carry `transform` as a
+  *presentation attribute*, which the clone already keeps, while `getComputedStyle` returns the
+  resolved CSS transform. Writing that inline could compose with the attribute and move the element
+  twice. Check on a chart with rotated tick labels (`xLabels="angled"`) before assuming it is inert.
+- Removing nodes changes layout if anything sized around them — a flex row that held a button now
+  has one fewer item. Expected, but look at it rather than assuming it is invisible.
+
+### Verification
+
+**Open the files.** Same gate as `UCM-CHART-17`, and for the same reason — both of these defects were
+invisible to every test and visible immediately in an exported image.
+
+1. A PNG of a panel with a control in `children`: the control is gone, everything else is where it
+   was.
+2. A PNG of a chart that keeps **MUI's own legend**: the legend is still there. This is the
+   counter-check for the risk above, and it is not optional.
+3. A rotated element exports rotated — the diamond is a diamond.
+4. A chart with `xLabels="angled"`: tick labels are not doubly rotated or displaced.
+
+Unit tests: the clone contains no `button` after export; a non-interactive sibling at the same depth
+survives; `transform` appears in the inlined declarations.
+
+---
+
+## 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.
+
+Implemented exactly per scope: `transform`/`transform-origin` added to `CHART_STYLE_PROPERTIES`
+(shared by both export paths); a new `INTERACTIVE_CONTROL_SELECTOR`
+(`button, input, select, textarea, [role="button"]`) and `stripInteractiveControls` helper, called
+in `containerSvgBlob` strictly **after** `inlineComputedStyles` (the lockstep-index trap named in
+the WO) — verified by temporarily reverting the ordering-safe call and confirming the new tests
+fail, then restoring.
+
+**Verification (real Chrome, via the dev harness's module graph — no probe entry committed to
+`dev/entries.jsx`, all four cases rendered via direct script injection into detached containers):**
+
+1. Control in `children` (an `IconButton` beside a `<span>` caveat note, mirroring
+   `StructuralReachabilityPanel`'s footer affordance): captured the PNG path's actual intermediate
+   SVG (intercepting `Image.src`) and confirmed no `<button` tag and no button text present, while
+   the sibling text and the chart itself both survive.
+2. MUI's own legend (two-series `BarChart`, no `hideLegend`): confirmed live that MUI's legend
+   renders as `<ul>/<li>/<div>/<span>` (no `button`/`role="button"` in it), then confirmed both
+   series labels ("Opened", "Resolved") and the `MuiChartsLegend-root` class survive the export
+   fully intact.
+3. Rotated element: a 24x24px swatch with `transform: rotate(45deg)`, exported to PNG and
+   pixel-sampled on a real `<canvas>` — the swatch's own bounding-box corner reads back as
+   background white, its centre as the swatch's own red, i.e. a genuine diamond (clipped corners),
+   not an unrotated square.
+4. `xLabels="angled"` (7 long category labels): the exported tick `<text>` carries BOTH its
+   original `transform="rotate(-45, 30, 9)"` XML presentation attribute (kept by `cloneNode`) AND
+   the newly-inlined `style="transform: matrix(0.707107, -0.707107, 0.707107, 0.707107, ...)"`.
+   The matrix values are exactly `cos(-45°)=0.707107, sin(-45°)=-0.707107` — a SINGLE 45° rotation,
+   not a doubled/composed one (which would show different values, e.g. matching -90°) — confirming
+   the inline `style` declaration wins over the presentation attribute (SVG2: presentation
+   attributes carry the lowest specificity) rather than composing with it. Tick text still renders
+   non-blank.
+
+Context package used: `exportChart.js` in full (short, already read start to finish),
+`ChartFrame.jsx:137-151` (`chartRef` — re-confirmed it wraps `children` only).
+
+**Post-review correction, both reviewers converging independently on the same gap the WO's own
+risk section named:** the initial `stripInteractiveControls` removed EVERY matched element
+outright, including MUI's own chart legend when it is interactive
+(`onItemClick`/`toggleVisibilityOnClick`) — X-Charts renders each legend item as
+`<button role="button" class="...MuiChartsLegend-series...">` wrapping the series swatch and
+label, so a blanket removal deleted the legend's content along with its click handler. This is
+EXACTLY the WO's own risk section, made concrete: "if it vanishes, that is a finding that changes
+the approach, not a detail to paper over." Fixed by UNWRAPPING `MuiChartsLegend-series` matches
+(replace with a plain `<span>` carrying the same class/style/children) instead of removing them —
+content survives, only the (irrelevant, in a static image) clickability is dropped. Re-verified
+live against a REAL interactive legend (`slotProps={{ legend: { toggleVisibilityOnClick: true } }}`,
+confirmed the live legend items render as actual `<BUTTON>` tags): the export contains zero
+`<button` tags, but `MuiChartsLegend-series` and both series labels survive intact. `INTERACTIVE_
+CONTROL_SELECTOR` also broadened to `a[href]`/`[role="link"]` (reviewer finding — a drill-down
+built as a link, not only a `<Button>`, is equally out of place in an export).
+
+Also fixed a genuine test-coverage gap the reviewer found: the original ordering test's `<button>`
+was the LAST descendant in its fixture, so a "strip before inline" regression would not have shifted
+any node the test actually asserted on — content-presence checks can't observe a style
+misattribution at all, only a missing/wrong STYLE VALUE can. Rewrote it with a distinctively-styled
+sibling AFTER the button (stylesheet-driven colour, not an inline style `cloneNode` would copy
+regardless) and confirmed, by temporarily reverting the call order, that the new assertion actually
+fails when the order is wrong (the button's own style — `border-style: none`, `text-align: center`
+— leaks onto the trailing sibling).
+
+---
+
+## Part C — Orchestrator only
+
+> **STOP — everything below addresses the Orchestrator.**
+
+**Tier 3 · verification: opened files for the four cases above, plus the unit tests**
+
+Shared-core, by the tiering table regardless of diff size.
+
+- `ui_reviewer` — what belongs in an exported image, and the MUI-legend counter-check.
+- `reviewer` — the ordering trap and the `transform` double-apply question.
+- `sec_reviewer` — not run; no auth, data or exposure surface.
+
+### Release
+
+**Patch → 3.3.1.** This repairs behaviour 3.3.0 itself introduced — the whole-container PNG was never
+meant to carry buttons — rather than adding capability. `UCM-CHART-16` (a repair) went out as a patch
+on the same reasoning, while `-15` and `-17` were minors because they changed what a consumer gets on
+purpose. The CHANGELOG should still say plainly that exported PNGs no longer contain controls; a
+consumer who liked the button in their image deserves to find out by reading, not by looking.
+
+### Register
+
+Row `UCM-CHART-18`, both review notes, the published version, landing SHA(s) in a second commit
+before the push. Record what the opened files looked like, including the MUI-legend counter-check.
+
+Consumer adoption is `HRAM-CHT-8`, which this WO reduces to a pin bump.
+
+### Log
+
+- **2026-08-25** — Envelope authored. The operator chose the shared-core fix over moving controls in
+  three hram panels, so that the rule holds for every consumer and `HRAM-RES-30`'s footer placement
+  survives.