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

package/CHANGELOG.md

@@ -2,6 +2,49 @@
 
 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
+label blank.** The x-axis tick band reserved a flat, font-size-independent floor; MUI's own
+internal fit check (`shortenLabels`, against `tickLabelsMaxHeight`) blanks every tick label the
+moment the real rendered text is even slightly taller than that floor leaves room for once MUI's
+own tick/gap overhead — and, when a title shares the same band, its own gap too — is subtracted.
+Correctly positioned tick marks with zero visible label text is the exact, easy-to-misread
+signature; two hram consumers had independently patched around it with the same empirically
+measured `height: 56` before this was traced to its shared-core cause.
+
+The band is now derived from the actual tick font size (and whether an axis title shares it)
+instead of the flat floor, matching MUI's real fit check rather than only its generic default.
+Patch, not minor: this repairs existing behaviour — the SAME size tokens render at the SAME
+heights (`UCM-CHART-15` is untouched) — the only change is the flat tick band growing by a few
+pixels on charts that were previously either mis-sized or silently blanking their labels. The
+rotated-tick path (`xLabels: "angled"`) is unaffected.
+
 ## 3.2.0 — UCM-CHART-15
 
 **Breaking visual change: every existing chart using a `size` token — including the default

package/WORK_ORDERS.md

@@ -27,6 +27,8 @@ prefixed ID; never reuse a bare flat number across workstreams.
 
 | ID | Titel | Beschreibung | Datum | Status | Commit(s) | Notiz |
 |---|---|---|---|---|---|---|
+| UCM-CHART-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. |
 | DX-2 | Declare `sideEffects` so consumers can tree-shake the kit | `package.json` has **no `sideEffects` field** and no `exports` map, so a bundler must assume every module can have an import side effect and cannot drop unused exports — twelve consumers ship the whole kit whatever they import. Measured, not theorised: `hram/THEME-2` switched from three named bundles to the full aggregate and the built size changed by **−11 bytes**. Full order [`work-orders/DX-2.md`](work-orders/DX-2.md) | 2026-08-12 | done | 31675d8 | Tier 3. Codex implemented (available today, no prior fallback needed). **Array form used, not blanket `false`** — the per-module audit found exactly one real import-time side effect group: font CSS. `src/theme/createAppTheme.js` and `src/theme/index.js` both used to `import '@fontsource/dm-sans/*.css'` at module scope; isolated into a new `src/theme/fonts.js`, declared in the `sideEffects` array (both `src/`/`dist/` forms) alongside `index.js`, `theme/index.js`, `theme/createAppTheme.js`, and `notifications/serviceWorker/sw.js` (a genuine `addEventListener` side effect, conservatively listed even though it isn't reachable from `src/index.js` — consumers import it directly). `uiCoreTranslations`'s aggregate-object construction relocated verbatim from `src/index.js` into `src/i18n/uiCoreTranslations.js` (no shape/value change) so the entry module carries no non-trivial logic beyond its own font import. New test `tests/packageTreeShaking.test.js` builds two throwaway consumer bundles against the real `dist/` output via Vite and asserts translations actually tree-shake. **Independent `reviewer` (Sonnet) redid the module-by-module audit from scratch** (walked theme/, auth/apiClient, notifications/realtime, messaging/, onboarding/, i18n/ for CSS imports, `document`/`window`/`self` mutation, axios interceptors, WebSocket construction, i18next `.use()/.init()`) and independently ran `pnpm run build` + the new test — **verdict: classification correct and complete, no missed side effect, safe to commit.** One non-blocking finding, addressed: **`src/index.js`'s font import is unconditional, so `@fontsource/dm-sans` CSS ships in every consumer's bundle regardless of import — it does NOT tree-shake**, and the reviewer flagged that the reported byte delta could be misread as covering the whole entry when it is translations-only. Added a one-line comment at `src/index.js:3` documenting the font/`sideEffects`-array coupling so a future edit can't decouple them silently (the exact false-negative hazard this WO exists to prevent). **Re-measured delta** (built `dist/`, minified, real bundler, supersedes both `I18N-1`'s `+28,943 B`/`+7,327 B` source-reachability figure and `THEME-2`'s `−11 bytes` no-tree-shaking baseline): auth-only **62,294 B raw / 17,653 B gzip** vs. aggregate **90,395 B raw / 25,045 B gzip** → **+28,101 B raw / +7,392 B gzip, translations only — font CSS is a separate, always-shipped, non-tree-shakeable cost not included in this number.** Written into `I18N-2`'s note below. Scoped tests: `pnpm run build` green, new test green, **full existing suite 511/511 green** (WO called for the existing suite as the scoped run, not full-estate). No rendered gate (nothing renders). Version bumped to `2.41.2` (patch by scope, per the WO). **Correction (2026-08-17): the publish failed** — `publish.yml` runs tests before build, and this WO's own new tree-shaking test needs `dist/` (gitignored), so it cannot pass on a clean checkout; registry stayed at `2.41.1`. Fix + re-publish tracked in `DX-3`. |

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/chartDefaults.js

@@ -144,6 +144,28 @@ export const PACKAGE_DEFAULT_MARGIN = {
 // PACKAGE_DEFAULT_MARGIN breathing-room, applied here for the same reason (a hard 0px gap reads
 // as clipped even when nothing is actually cut off).
 const ROTATED_TICK_CLEARANCE_PX = 8;
+// UCM-CHART-16: the FLAT (angle 0) tick band used to be the unconditional TICK_BAND_BASE_PX
+// regardless of the actual tick font size -- fine for MUI's own generic default, but MUI's
+// internal fit check (`shortenLabels`, against `tickLabelsMaxHeight`) blanks EVERY tick label the
+// moment the real rendered text is even slightly taller than what that flat floor leaves room
+// for once MUI's own tick/gap overhead (and, when an axis title shares the band, its own gap) is
+// subtracted. `TICK_BAND_BASE_PX` alone was a near-miss with essentially no margin at any font
+// size above whatever MUI itself implicitly assumed -- two hram consumers independently patched
+// around it with the same empirically-measured `height: 56`, and a third, titleless case broke at
+// a tick font just 1px above the untitled default.
+//
+// These three constants are DERIVED, not guessed: binary-searched against the real, unmocked
+// `BarChart` rendered in this repo's own dev harness (`dev/entries.jsx`'s `chart-probe` entry,
+// Chrome, this package's own DM Sans default -- the taller of the two fonts checked; MUI's Roboto
+// fallback needs visibly less and was never the trigger) at tick font sizes 11-18px, with and
+// without an axis title:
+//   required flat tickBand   ~= ceil(fontSize * TICK_TEXT_HEIGHT_FACTOR) + TICK_BAND_MUI_OVERHEAD_PX
+//   required tickBand+title  ~= that, plus TICK_BAND_TITLE_EXTRA_PX, plus AXIS_TITLE_BAND_PX
+// matched every measured threshold exactly or over by at most 1px, never under, across ten
+// font-size/title combinations -- see UCM-CHART-16's work order for the full measurement table.
+const TICK_TEXT_HEIGHT_FACTOR = 1.3;
+const TICK_BAND_MUI_OVERHEAD_PX = 9;
+const TICK_BAND_TITLE_EXTRA_PX = 2;
 // THEME-9: MUI X-Charts' own default y-axis width is a flat 45px (ticks) +
 // 20px (label, if present) = 65px regardless of what the ticks actually say
 // -- confirmed against @mui/x-charts' own DEFAULT_AXIS_SIZE_WIDTH /
@@ -373,8 +395,18 @@ function resolveXAxisGeometry(axis, xLabelsMode, defaultLineHeight, measureTextW
         const needsRotation = dataCount > AUTO_ROTATE_TICK_COUNT && labelWidthPx > AUTO_ROTATE_LABEL_WIDTH_PX;
         angle = needsRotation ? -45 : 0;
     } // "horizontal" always stays at angle 0
-    if (angle === 0)
-        return { tickBand: TICK_BAND_BASE_PX, angle: 0 };
+    if (angle === 0) {
+        // UCM-CHART-16: derive the flat band from the actual tick font size instead of the
+        // unconditional floor -- `axis?.label` is the SAME signal `resolveChartLayout` uses to decide
+        // whether an axis title also shares this band (`xTitleBand`), so a titled axis reserves the
+        // extra room its own gap costs, precisely where the near-miss was.
+        const hasTitle = Boolean(axis === null || axis === void 0 ? void 0 : axis.label);
+        const flatTickBand = fontSize > 0
+            ? Math.ceil(fontSize * TICK_TEXT_HEIGHT_FACTOR) + TICK_BAND_MUI_OVERHEAD_PX
+                + (hasTitle ? TICK_BAND_TITLE_EXTRA_PX : 0)
+            : TICK_BAND_BASE_PX;
+        return { tickBand: Math.max(TICK_BAND_BASE_PX, flatTickBand), angle: 0 };
+    }
     // Rotation is a visual instruction independent of whether a font size is knowable here -- an
     // "angled" axis still rotates even when `fontSize` can't be resolved (no theme fallback given),
     // it just can't project a tighter band than the floor without one.

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/docs/CHART-LAYOUT.md

@@ -15,13 +15,15 @@ chartHeight === plotHeight + xAxisBand + xTitleBand + legendBand
 ```
 
 - `xAxisBand` — the tick row. Zero when the axis has no visible tick content (an empty `data`
-  array, or every formatted tick is a blank string). Non-zero otherwise: a flat baseline for
-  horizontal labels, or a measured/estimated projection for rotated ones (same measurement
-  mechanism as before — a real DOM measurement when available, a per-glyph estimate otherwise).
-  The flat baseline (25px) and the title addition (20px) are MUI X-Charts' own
-  `DEFAULT_AXIS_SIZE_HEIGHT`/`AXIS_LABEL_DEFAULT_HEIGHT` constants, not a re-estimate — the plain
-  unrotated/untitled case renders pixel-identical to before this WO, even though the resolver now
-  sets `axis.height` explicitly where MUI used to fill it in implicitly.
+  array, or every formatted tick is a blank string). Non-zero otherwise: for horizontal labels, a
+  floor of 25px (MUI X-Charts' own `DEFAULT_AXIS_SIZE_HEIGHT`) scaled up from the actual tick font
+  size once it needs more room than that floor leaves MUI's own internal fit check — a flat floor
+  alone was a near-miss with essentially no margin at any font size above whatever MUI itself
+  implicitly assumed (`UCM-CHART-16`); or a measured/estimated projection for rotated ones (same
+  measurement mechanism as before — a real DOM measurement when available, a per-glyph estimate
+  otherwise). The title addition (20px, `AXIS_LABEL_DEFAULT_HEIGHT`) grows by a further few pixels
+  when an axis title shares the tick row's band, matching the extra gap MUI itself reserves
+  between the two.
 - `xTitleBand` — the axis title. Zero unless the x-axis carries a `label`.
 - `legendBand` — one row for the legend. Zero when `hideLegend` is set.
 - `plotHeight` is the residual: `chartHeight` minus the three bands above.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@micha.bigler/ui-core-micha",
-  "version": "3.2.0",
+  "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/chartDefaults.js

@@ -153,6 +153,29 @@ export const PACKAGE_DEFAULT_MARGIN = {
 // as clipped even when nothing is actually cut off).
 const ROTATED_TICK_CLEARANCE_PX = 8;
 
+// UCM-CHART-16: the FLAT (angle 0) tick band used to be the unconditional TICK_BAND_BASE_PX
+// regardless of the actual tick font size -- fine for MUI's own generic default, but MUI's
+// internal fit check (`shortenLabels`, against `tickLabelsMaxHeight`) blanks EVERY tick label the
+// moment the real rendered text is even slightly taller than what that flat floor leaves room
+// for once MUI's own tick/gap overhead (and, when an axis title shares the band, its own gap) is
+// subtracted. `TICK_BAND_BASE_PX` alone was a near-miss with essentially no margin at any font
+// size above whatever MUI itself implicitly assumed -- two hram consumers independently patched
+// around it with the same empirically-measured `height: 56`, and a third, titleless case broke at
+// a tick font just 1px above the untitled default.
+//
+// These three constants are DERIVED, not guessed: binary-searched against the real, unmocked
+// `BarChart` rendered in this repo's own dev harness (`dev/entries.jsx`'s `chart-probe` entry,
+// Chrome, this package's own DM Sans default -- the taller of the two fonts checked; MUI's Roboto
+// fallback needs visibly less and was never the trigger) at tick font sizes 11-18px, with and
+// without an axis title:
+//   required flat tickBand   ~= ceil(fontSize * TICK_TEXT_HEIGHT_FACTOR) + TICK_BAND_MUI_OVERHEAD_PX
+//   required tickBand+title  ~= that, plus TICK_BAND_TITLE_EXTRA_PX, plus AXIS_TITLE_BAND_PX
+// matched every measured threshold exactly or over by at most 1px, never under, across ten
+// font-size/title combinations -- see UCM-CHART-16's work order for the full measurement table.
+const TICK_TEXT_HEIGHT_FACTOR = 1.3;
+const TICK_BAND_MUI_OVERHEAD_PX = 9;
+const TICK_BAND_TITLE_EXTRA_PX = 2;
+
 // THEME-9: MUI X-Charts' own default y-axis width is a flat 45px (ticks) +
 // 20px (label, if present) = 65px regardless of what the ticks actually say
 // -- confirmed against @mui/x-charts' own DEFAULT_AXIS_SIZE_WIDTH /
@@ -389,7 +412,18 @@ function resolveXAxisGeometry(axis, xLabelsMode, defaultLineHeight, measureTextW
     angle = needsRotation ? -45 : 0;
   } // "horizontal" always stays at angle 0
 
-  if (angle === 0) return { tickBand: TICK_BAND_BASE_PX, angle: 0 };
+  if (angle === 0) {
+    // UCM-CHART-16: derive the flat band from the actual tick font size instead of the
+    // unconditional floor -- `axis?.label` is the SAME signal `resolveChartLayout` uses to decide
+    // whether an axis title also shares this band (`xTitleBand`), so a titled axis reserves the
+    // extra room its own gap costs, precisely where the near-miss was.
+    const hasTitle = Boolean(axis?.label);
+    const flatTickBand = fontSize > 0
+      ? Math.ceil(fontSize * TICK_TEXT_HEIGHT_FACTOR) + TICK_BAND_MUI_OVERHEAD_PX
+        + (hasTitle ? TICK_BAND_TITLE_EXTRA_PX : 0)
+      : TICK_BAND_BASE_PX;
+    return { tickBand: Math.max(TICK_BAND_BASE_PX, flatTickBand), angle: 0 };
+  }
   // Rotation is a visual instruction independent of whether a font size is knowable here -- an
   // "angled" axis still rotates even when `fontSize` can't be resolved (no theme fallback given),
   // it just can't project a tighter band than the floor without one.