@micha.bigler/ui-core-micha 2.42.0 → 2.42.2

package/WORK_ORDERS.md

@@ -91,3 +91,5 @@ Two chunks. **Chunk 1** (Part 1 + Part 2 of the Envelope): extended `SPACING_SHO
 | THEME-10 | Ein Scatter-Preset, entworfen an drei realen Konsumenten | hram zeichnet **drei** Scatter vollständig von Hand — eigene Achsenlinien, Gitter, Ticks, Tick-Beschriftungen und gedrehte Achsentitel auf fest verdrahteten Leinwänden; aus diesem Paket kommt nur `ChartFrame`. `AllocationPerformancePanel` (720×420, Wolke + Hüllkurve + drei markierte Punkte, kontinuierliche Färbung), `AccessGapScatterPanel` (Bubble-Wolke mit datengetriebenem Radius + beschriftete y=x-Diagonale, **kategoriale** Färbung mit diskreter Legende, beide Achsen fix 0–1) und `OptimizationResultsPanel` (Wolke + gestrichelte Referenzlinie, Status quo als hohler Marker). Das ist keine Nachlässigkeit — **es gibt hier kein Scatter-Preset**, also gab es nichts zu greifen; jede Verbesserung dieses Kits (Achsengrössen, Tick-Formatierung, Label-Platzierung, Rollenpalette) geht an allen dreien vorbei. Der Operator hat diesen Weg bewusst gewählt, statt die Apps MUI X direkt nutzen zu lassen (hram `FIX-15`, Gabelung b). Voller Auftrag [`work-orders/THEME-10.md`](work-orders/THEME-10.md) | 2026-08-14 | done (npm publish 2.41.0, gebündelt mit THEME-11; Konsumenten-Pin-Bumps offen) | ff67fc7 | Tier 3 (Shared-Core, neue öffentliche API). Codex bereits `unavailable` für heute — direkt in Claude implementiert, Autorenschaft geflippt, `reviewer` + `ui_reviewer` liefen parallel (ohnehin Pflicht bei Tier 3). **`reviewer` R1 (P1, behoben):** `sizeYAxisForContent` erwartet rohe Zahlen in `series[].data`, Scatter liefert `{x,y,z,id}`-Objekte — der Fallback fand still NULL Kandidaten, solange kein `yAxis.min/max` gesetzt war (stiller Rückfall auf MUIs Flat-Default). Behoben per Adapter am Call-Site (`yValueSeries`), NICHT am geteilten Helper — BarChart/LineChart bleiben unangetastet. **R2 (P2, behoben):** `dataIndex`-Semantik im Bubble-Modus (post-Sort-Index, nicht Original-Array) war nicht dokumentiert — jetzt im Docstring. **`ui_reviewer` U1 (P2, aufgeklärt statt Code geändert):** `shape:'square'` schien nicht auf die drei Panels rückführbar — tatsächlich rückführbar auf Allocation-Panels `isTargeted`-Punkte (`ShapeGlyph`), im WO nur nicht explizit zitiert; WO-Text nachgezogen. **U2 (P2, behoben):** Optimization-Form war live nicht eigens gerendert — dritte Dev-Harness-Fixture ergänzt und live verifiziert (genau diese Kombination — kein `yAxis.min/max`, keine explizite Palette — deckte R1 auf, die beiden anderen Fixtures umgingen den Fehler zufällig). **U3 (P3, behoben):** Test ergänzt, dass eine Einzelserie mit eigener `.color` nicht als neutral behandelt wird. **U5 (P3, dokumentiert):** WO-Text stellte klar, dass Allocations eigener Status-quo-Punkt ebenfalls hohl ist, nicht nur Optimizations. **U4 (P3, akzeptierter Rest):** fehlende Nicht-visuelle Kennzeichnung von hohl/Form — vorbestehende Lücke im ganzen Chart-Kit, nicht neu eingeführt, nicht in dieser WO behoben. Alle drei benannten Konsumenten-Formen live im eigenen Dev-Harness gerendert und DOM-vermessen (Mark-Counts 6/6, 7/7, 4/4 — keine stillen Drops); ein zweiter echter Bug (Bubble-Radius pro Serie statt Chart-weit) beim Live-Rendern gefunden und vor Commit behoben, Regressionstest ergänzt. Affected-Set grün (78 Tests). **Version noch nicht gebumpt, Publish zurückgehalten** — Operator kündigte THEME-11 an, Version-Bump + Publish sollen gebündelt werden. **Das ursprünglich benannte Einzelkonsumenten-Risiko ist weitgehend erledigt.** Der erste Entwurf (2026-08-14) warnte, eine Abstraktion aus einem einzigen Beispiel friere die falsche Form ein; danach nannte der Operator das Access-Panel, und eine Suche fand ein drittes. Drei unabhängige Konsumenten unterscheiden eine echte Variationsachse von einer Vermutung — und **zwei der Achsen wurden gefunden, nicht entworfen**: kategoriale Färbung mit diskreter Legende und datengetriebener Bubble-Radius mit Z-Order kommen im Allocation-Panel überhaupt nicht vor. Aus einem Panel gebaut hätte das Preset beide verfehlt. Ersetzt wird das Risiko durch die engere Disziplin: **jede Option muss auf eines der drei Panels zurückführbar sein**, sonst kommt sie nicht rein; wächst die API während der Umsetzung, stop and report. **Neue Hauptgefahr ist die Übergeneralisierung:** dieselbe Suche fand zwei weitere handgemalte Panels, die ebenfalls Kreise zeichnen, aber **ein anderes Diagramm sind** — `CalibrationPanel` (Forest-Plot, `MARGIN.left=150`, Punktschätzer + Intervall je Zeile) und `SensitivityAnalysisPanel` (Tornado, `MARGIN.left=220`, `<rect>`-Balken), dazu die Divergenz-Ansicht in `OptimizationResultsPanel`. Kategoriale y-Achse, 150–220 px Zeilenlabels, Zeilendichte als Layoutproblem — **ausdrücklich ausgeschlossen**, eigenes Preset, eigener WO. **Wichtigster Default bleibt:** die undifferenzierte Wolke ist neutral (Rollenregister), NICHT eine KPI-Identitätsfarbe — genau das macht das Allocation-Panel falsch. Das Access-Panel färbt dagegen **zu Recht** kategorial (Division/Settlement sind echte Datendimensionen und kommen bereits aus dem eingefrorenen Familienregister); neutral ist der Default für „keine Dimension kodiert“, kein Farbverbot. Muss THEME-9s Helfer wiederverwenden (`sizeYAxisForContent`, `defaultNumericTickFormatter`, `withAxisDefaults`, `spaceForRotatedTicks`); ein Preset mit eigener Achsenlogik würde genau das wieder aufreissen, was THEME-9 geschlossen hat. Konkrete Regression, die es stoppt: das Access-Panel verdrahtet sechs Grautöne fest (`#F0F0F0`, `#D0D0D0`, `#999`, `#666`, `#555`, `#B0B0B0`), die keine Theme-Änderung erreicht. Nicht am Publish abschliessen: hram `FIX-15` ist der erste Konsument und blockiert darauf; Access und Optimization sind bekannte Konsumenten **ohne eigenen WO** — separat zu planen, nicht hier einzufalten. Pin-Bump zusammen mit den bereits wartenden THEME-8 und THEME-9 fahren. |
 | THEME-11 | Das Kit hat keine Meinung zu Chart-Rändern, also erbt jedes Diagramm im Estate die von MUI | hrams vier KPI-Karten wurden pixelweise zerlegt: Chart 270 px hoch, davon **202 px Plotfläche** — die restlichen 167 px sind Beiwerk, und die Bilanz geht auf die beobachteten ~370 px Kartenhöhe exakt auf. Der Grund für 20 px auf allen vier Seiten: **dieses Paket bildet nie eine Meinung**. `spaceForRotatedTicks` gibt `margin` unverändert zurück, solange die x-Ticks nicht rotiert sind — reicht der Aufrufer nichts, geht `margin: undefined` an `MuiBarChart` und `DEFAULT_MARGINS = {20,20,20,20}` greift. THEME-9 hat dem Kit Achsen*grössen* gegeben; Ränder waren nie in seinem Scope. Neu: `top: 10`, `bottom: 8`, `left: 8`, `right: 16`, plus `ChartFrame`s Titel-`mb: 2` → `mb: 1`. Voller Auftrag [`work-orders/THEME-11.md`](work-orders/THEME-11.md) | 2026-08-14 | done (npm publish 2.41.0, gebündelt mit THEME-10; Konsumenten-Pin-Bumps offen) | bb7794d | Tier 3 (Shared-Core). Codex bereits `unavailable` — direkt in Claude implementiert, Autorenschaft geflippt, `reviewer` + `ui_reviewer` liefen parallel (ohnehin Pflicht bei Tier 3). **Beide Fallen sauber vermieden** (`reviewer`, an beiden Dateien einzeln verifiziert, keine Befunde): `spaceForRotatedTicks` läuft weiterhin auf dem unveränderten Aufrufer-`margin`, `withMarginDefaults` erst danach gemerged — der rotierte Pfad verliert seinen Zusatzplatz nicht. `MUI_CHART_MARGIN_BOTTOM` (20→8) mitgezogen. **`ui_reviewer` U1-U4 (alle P2/P3, dokumentiert statt Code geändert):** die live gemessene Fast-Kollision (gruppierte Zahl "1,000" bei nur ~1px Abstand vom neuen `right:16`) stammt aus MUIs eigener Standard-Tick-Formatierung, nicht aus THEME-9s Formatter (Fehlzuschreibung korrigiert); **`reviewer` verifizierte zusätzlich**, dass KEIN aktueller hram-Konsument diesen Pfad überhaupt trifft (alle nutzen `scaleType:'band'`; `AllocationPerformancePanel` — der ursprünglich befürchtete Fall — importiert nur `ChartFrame`, zeichnet eigenes SVG, geht gar nicht über `BarChart`/`LineChart`) — "kein Konsument hat das" trifft also exakt zu, nicht nur plausibel. Restrisiko dokumentiert für den ersten künftigen linearen Konsumenten. `ChartFrame`s `mb`-Trim bewusst unbedingt (nicht an Chart-Preset gekoppelt) — Titelzeile und Plot-Rand sind unabhängiges Möbel. **Scope-Lücke benannt, nicht eingefaltet:** `ScatterChart` (THEME-10) bekommt noch keinen `withMarginDefaults` — Folge-WO. Affected-Set grün (91 Tests). Gerendert live verifiziert: rotierter Tick-Chart ohne Overlap (15px Abstand zum Achsentitel), linearer x-Achsen-Chart ohne echtes Clipping (schmal: 5px Abstand; breit: MUIs eigene Kürzung greift bei ~1px, nie Overflow). **Warum die Werte pro Seite verschieden sind — das ist der Kern, kein Feinschliff:** `margin.left` liegt **ausserhalb** der y-Achsenbreite (`drawingArea.left = margin.left + axisSizeLeft`, Kommentar des Pakets selbst), ist also reines Polster; `margin.bottom` liegt **unter** dem x-Achsenblock, dessen `DEFAULT_AXIS_SIZE_HEIGHT` das Tick-Label bereits enthält; `margin.top` trägt dagegen echten Inhalt — das oberste y-Tick-Label ist auf seiner Gitterlinie zentriert und ragt eine halbe Caption-Zeilenhöhe (~9 px) über die Plotfläche, **deshalb 10 und nicht 8**. `right` wird bewusst **weniger** getrimmt (16): bei einer Bandachse sitzen die Ticks mittig, bei einer **linearen** x-Achse sitzt das letzte Label auf der Kante und ragt eine halbe Labelbreite (~13 px) hinaus. Nicht vom Skalentyp abhängig machen — das wäre abgeleitetes Verhalten ohne benannten Konsumenten. **Zwei benannte Fallen.** (1) `spaceForRotatedTicks` erkennt „Aufrufer hat gesetzt“ an `margin?.bottom != null`; wird ein Paket-Default **vor** dieser Prüfung injiziert, sehen rotierte Charts ihn als aufrufergesetzt und verlieren ihren Extraplatz — hrams `RatioMetricsPanel` fährt Labels bei −45° und −90° und würde sie beschneiden. (2) `MUI_CHART_MARGIN_BOTTOM = 20` in `chartDefaults.js` ist eine hartkodierte Kopie des MUI-Defaults und Basis für den rotierten Pfad — muss mitwandern. **Per-Seite mergen, nicht das ganze Objekt ersetzen:** Panels, die schon von Hand tunen (`{left:60, right:8, top:20, …}`), müssen auf ihren gesetzten Seiten unberührt bleiben. `CHART_FRAME_ROOT_SX = { p: 2 }` bleibt bewusst stehen — `ChartFrame` umschliesst auch Nicht-Chart-Inhalte, das ist ein eigener Vorschlag mit anderer Streuweite, kein Anhängsel. **Streuweite:** trifft jedes Diagramm in jeder konsumierenden App, und zwar beim Pin-Bump, nicht beim Publish — ein falscher Seitenwert ist damit eine estate-weite Regression. Der gerenderte Check muss deshalb **einen rotierten** und **einen linearen** x-Achsen-Chart enthalten, nicht nur die KPI-Karten. Pin-Bump zusammen mit THEME-8/9/10 fahren. |
 | UCM-CHART-8 | Make the chart presets stop producing dead space below the chart | `minHeight` and `height` are two different things on these presets and the API lets a caller pass both: `minHeight` lands on the WRAPPER Box (`ScatterChart.jsx:260`, same construction in `BarChart.jsx`), `height` sizes the CHART. When `minHeight > height` the difference is dead space BELOW the chart. Measured in hram 2026-08-20: StructuralReachability 420/380 (40 px), ExpertTimeline 340/280 (60 px), ResultsTimeline 320/280 (40 px), GroupMetrics 300/none (chart unsized). The equal-value majority is WHY it survived -- passing both looks harmless and costs nothing when the numbers match, so it spread by copy-paste. Diagnosed and fixed POINTWISE TWICE in hram (`AllocationPerformancePanel.jsx:462-478`, `OptimizationResultsPanel.jsx:928-940`) with the explanation living as a comment inside those two files, where no new panel reads it. One shared API permitting an incoherent pair, not N panel bugs. | 2026-08-20 | done | 11d362c | Tier 3, shared-core -- every consumer inherits it. Full order: [`work-orders/UCM-CHART-8.md`](work-orders/UCM-CHART-8.md). Deliberately NON-breaking: `minHeight` is deprecated in the docstring and COERCED in code, not removed -- removing it would make every consumer's pin bump a Tier-3 change with unnoticed layout regressions, worse than the defect. `minHeight` alone sizes the chart; `minHeight > height` reserves no wrapper padding; equal values byte-identical; a DEV-ONLY warning names the disagreeing pair (no throw -- a shared package must not break a consumer's page over a layout nit). Before publishing, check the other consumers (dcm-based apps, survey-renderer) for `minHeight` on a chart preset and report what was found -- the one way this could read as a regression is a consumer using the padding as spacing. Publishes from `main` with no staging step, so verify the version is live before any consumer bump. hram's call-site sweep is a separate follow-up GATED on that pin bump. Raised by the operator as "why is there still too much whitespace everywhere" -- the recurrence, not the instances, is the subject.  **Envelope amended 2026-08-21 after review — the original rule would have broken four live call sites.** The resolution is **three-way, not two-way**: `aspect` is a third input and it changes the answer. Four consumers pass `aspect` **with** `minHeight` and **no** `height` — `hram/AccessGapScatterPanel.jsx:182` (`aspect={1.8}`, `minHeight={320}`) and three sites in `fitness-monitor/BodyHistoryPage.jsx` — and there `minHeight` is a legitimate **floor under an aspect-derived height**, not stray padding. "`minHeight` alone sizes the chart" as first written would have turned all four into fixed-height charts. Same prop shape, opposite intent, which is why the rule cannot be stated on `minHeight`/`height` alone. Also corrected: `ChartFrame` takes `minHeight`/`aspect` too and was missing from the file list, and **`BarChart`, `LineChart` and `ChartFrame` never destructure `height`** — for them the pair exists only via the rest spread, so there is no declared prop to look for. The Risks section's hypothetical consumer check is now **done**, with the four sites as its result; `survey-renderer` is named there as a consumer to check but the standalone repo is retired (2026-07-31). Tests gained the `aspect` case explicitly — it is the one that must fail if the resolution is later re-simplified. **Implemented 2026-08-21, Codex known-unavailable that day** (`.claude/codex-status.md` already carried an `unavailable` line for today at task start, from `cockpit/LIVE-4` and `hram/OPT-8`) — Orchestrator implemented directly in Claude, flipping authorship, so the independent reviewer + ui_reviewer (both mandatory at Tier 3 regardless) covered a diff the Orchestrator itself wrote. `resolveChartHeight`/`warnOnHeightMismatch` added to `chartDefaults.js`; wired into ScatterChart/BarChart/LineChart (destructuring `height` out of the rest spread, forwarding it explicitly) and ChartFrame (new optional `height` prop, applied to its own content box since it has no inner MUI chart to forward to). TimeSeriesChart.jsx left unmodified — it never exposes `minHeight`/`height`/`aspect` to its own caller, only forwards a single internal `CHART_HEIGHT` constant identically to ChartFrame's `minHeight` and BarChart's `height`, confirmed unchanged by the full existing `TimeSeriesChart.test.jsx` suite passing untouched. **`reviewer` (Sonnet)**: no bugs; two P3s — the `height`+`aspect` combination on Bar/Line/Scatter is pre-existing, untested, and not fully governed by the three-way contract (wrapper still gets `aspectRatio` unconditionally while the chart gets a hardcoded `height`), and the TimeSeriesChart 320/320 coincidence is two independently-resolved branches landing on the same value, not literally the "equal values" case — both accepted as out of this WO's scope, no live call site hits either. **`ui_reviewer` (Sonnet)**: one P1 noted-not-a-bug (the minHeight-alone branch now gives every such consumer a fixed chart height, which is exactly Part A's Definition of Done, not an undisclosed change — flagged here as a residual cross-app risk since only the 4 aspect+minHeight sites were confirmed, not every minHeight-alone call site) and one real P2, **fixed**: `warnOnHeightMismatch` was called in the render body, so it re-fired the console.warn on every re-render of a mismatched instance; moved into a `useEffect` keyed on `[minHeight, height]` in all four components. Re-verified 128/128 scoped tests green after the fix (BarChart/LineChart/ScatterChart/ChartFrame/chartDefaults/TimeSeriesChart/packageTreeShaking). Version bumped 2.41.3 → 2.42.0 (new optional `ChartFrame.height` prop + new exports, non-breaking). **Not done in this WO**: the app-wide check for other `minHeight`-alone consumers ui_reviewer flagged (U1) — no consumer sweep is in scope per Part A's own "Deliberately NOT done"; flagging for the record, not a blocker. Publish-then-verify-then-bump-consumer-pins sequencing from the Envelope still applies before hram's own call-site cleanup. |
+| UCM-CHART-9 | `ChartFrame` is a card, not a chart: it must never take a fixed height | REGRESSION in published 2.42.0, observed on hram staging. UCM-CHART-8 wired `resolveChartHeight()` through the four chart presets AND through `ChartFrame`. Correct for the presets, wrong for the frame: in the `minHeight`-alone branch the resolver returns `chartHeight = minHeight`, and `ChartFrame` applies it as `height` on its content box. A preset's box holds one chart; **`ChartFrame`'s box holds a whole card** -- title, toolbar, chart, legend, footnotes, export links. The floor became a fixed height, the content overflows, and ADJACENT CARDS VISIBLY OVERLAP (card title drawn over the chart above it, three sets of Export SVG/PNG stacked at different offsets). UCM-CHART-8's own Files note recorded that `ChartFrame` never destructures `height` -- the implementation then gave it one. | 2026-08-21 | done | 2026-08-22: `ChartFrame` fix + version bump + accurate mismatch warning | Tier 3, shared-core, live regression in `latest`. Full order: [`work-orders/UCM-CHART-9.md`](work-orders/UCM-CHART-9.md). Operator chose FIX-FORWARD over reverting hram's pin (2026-08-21), because 2.42.0 also appears to have stopped hram's Detailed-Results React #185 crash -- plausible mechanism is that deterministic sizing removed a resize-driven setState loop, but that is a HYPOTHESIS, not a finding, and this WO must re-check whether the crash returns (if it does, that is a finding for HRAM-RES-29, not a reason to undo this). Do NOT revert UCM-CHART-8: its preset behaviour is correct and includes the `aspect` branch four live call sites depend on; this WO narrows one consumer of the resolver only, and any edit needed to a preset test means the change has leaked. **Codex:** out of credits on the one allowed probe today (`.claude/codex-status.md`, 2026-08-22) -- Orchestrator implemented directly, flipping authorship; `reviewer` + `ui_reviewer` were already mandatory at Tier 3, so no routing change. **Reviews:** `reviewer` -- 2 findings (R1 version not bumped in-diff, fixed by bumping `package.json` to 2.42.1 in this commit so `publish.yml`'s version-increase gate fires on push; R2 jsdom-can't-measure-layout note on one test, non-blocking, covered by the live-browser check below). `ui_reviewer` -- 2 findings (U1 `warnOnHeightMismatch`'s message was left factually wrong for `ChartFrame` post-fix -- FIXED: added a `heightWins` param, `ChartFrame` now gets its own accurate wording, test coverage added in both `chartDefaults.test.js` and `ChartFrame.test.jsx`; U2 height-alone-on-ChartFrame is now a silent no-op with no dev warning -- accepted as-is, out of scope for this regression fix). Both reviews clean after fixes, no open findings. **Tests:** affected-area set (`ChartFrame`, `chartDefaults`, all four presets) -- 129/129 green, preset assertions byte-identical/unchanged. **Rendered check:** this repo's own dev harness (`npm run dev`, `dev/entries.jsx` "Charts / ScatterChart (allocation shape)") driven live in the internal preview browser at 375px and 1280px -- DOM/computed-style inspection (no screenshot capture available in this session; declared substitution per the gate's fallback clause), confirmed the content box carries no fixed `height` and, after forcing the inner chart element's rendered height up to 900px/1100px to reproduce the regression scenario, the box grew to match with zero scrollHeight/clientHeight overflow at both widths. The Envelope's full five-card check (Sensitivity, Access, Access Ladder, Allocation, Optimization, rendered in hram itself) is **NOT done by this WO** -- this repo's harness only has 3 of the 5 named cards and no live hram instance was linked against this build. Carried forward as a mandatory precondition on whichever WO next bumps hram's `ui-core-micha` pin past 2.42.0. 2.42.0 stays flagged do-not-adopt; 2.42.1 publishes automatically via `publish.yml` on this push (version-increase gate). PROCESS NOTE, recorded deliberately: 2.42.0 shipped on 188 green unit tests that say nothing about layout -- the rendered check above is the layout-level evidence this WO exists to add, even though it stops short of the full hram five-card scope. FIVE-CARD CHECK DONE 2026-08-22, hram with real data (SG Sandbox CLI / `CLI-Kilombero_2026-per_cell-network`), ucm 2.42.1 loaded, at 1280 px AND 375 px: zero boxes with an inline fixed height, zero overflowing cards, zero overlapping card pairs, no horizontal body scroll, bottom dead space 17 px (card padding) on every card. CHART-9 does what it set out to do. SUBSTITUTION DECLARED: screenshot capture was unavailable all session, so this is DOM + computed-style measurement, not images. hram pin bumped to 2.42.1 in `6dd00c1d`. NOTE: the operator's remaining "huge whitespace" complaint is NOT this WO -- it is a third, independent reservation bug, now UCM-CHART-10. |
+| UCM-CHART-10 | The rotated-tick allowance is reserved twice, and the surplus is dead space | `spaceForRotatedTicks` adds the same `extraHeight` BOTH to `axis.height` and to `margin.bottom`, and in MUI v8 those are additive. The axis band already holds the rotated labels, so the margin copy is left over as an empty band below the plot. Measured in hram 2026-08-22 at 1280 px with ucm 2.42.1: Ward Metrics and Access Ladder each show a 340 px surface whose plot ends at 131 px -- **130 px, 38 %, empty**; Cost 92 px; Division Metrics 85 px; Cost-effectiveness 44 px; Expert Mode only 8 px. Two things make it conclusive: the band SCALES WITH THE LABEL LOAD (35 long rotated ward names cost 130 px, short labels cost 8), and `emptyBelowLowestLabel` equals `emptyBelowAxisLine` on every chart -- the labels sit inside the axis band and nothing occupies the space beneath them. | 2026-08-22 | done | 2026-08-22: `spaceForRotatedTicks` fix + version bump | Tier 3, shared-core. Full order: [`work-orders/UCM-CHART-10.md`](work-orders/UCM-CHART-10.md). THIRD instance of one failure class in this file: space reserved in two places that add up -- after UCM-CHART-8 (`minHeight` vs `height`) and hram's RES-28 (`margin.left` vs an unsized `yAxis`). Neither CHART-8 nor CHART-9 could have caught it: both worked on the wrapper BOX, this is the axis MARGIN arithmetic. **Fix:** kept `extraHeight` on `axis.height` only, `margin` now passes through `spaceForRotatedTicks` completely untouched (no `bottom` computed in any branch) -- a caller-set `margin.bottom` is therefore protected unconditionally, a strict superset of the removed `callerSetBottom` escape hatch, which both reviewers confirmed is a clean simplification, not a behaviour gap. **Codex:** `.claude/codex-status.md` already had an `unavailable` line for 2026-08-22 (logged during `UCM-CHART-9` earlier the same day) -- skipped the attempt per the known-unavailable shortcut, implemented directly, flipping authorship; `reviewer` + `ui_reviewer` were already mandatory at Tier 3, so no routing change. **Reviews:** `reviewer` and `ui_reviewer` ran concurrently (Sonnet, diff inline), both converged on the same two findings, both fixed before commit -- (1) version not bumped in-diff (fixed: `package.json` 2.42.1 -> 2.42.2, so `publish.yml`'s version-increase gate fires on push); (2) the WO's "investigate in the same pass" item (HRAM-RES-29 item 2, scatter x-axis tick-label clipping) had no recorded confirm/refute. **Refuted and recorded in the WO file:** `ScatterChart.jsx` never calls `spaceForRotatedTicks` at all, and hram's own named call sites (`AccessGapScatterPanel.jsx`, `OptimizationResultsPanel.jsx`) set no `tickLabelStyle.angle` either -- this helper cannot be the cause. Matches hram's own `HRAM-RES-29` register row, which had independently traced and closed item 2 the same day to an unrelated pre-2.42.0 missing-`height`-prop bug on `ScatterChart`, already fixed by `UCM-CHART-8`/2.42.0. Both reviews clean after fixes, no open findings. **Tests:** affected-area set (`chartDefaults` incl. new `spaceForRotatedTicks (CHART-10)` unit-test block, all four presets, `ChartFrame`) -- 134/134 green, preset assertions unchanged except the two that directly asserted the bug (rewritten to assert the fix, both reviewers confirmed the rewrite is correct and non-trivial). **Rendered check -- numeric, on hram with real data** (`CLI-Kilombero_2026-per_cell-network`, SG Sandbox CLI, same candidate point, Research -> Allocation -> Basic Plots), swapping the locally-built fixed `dist` into hram's `node_modules` for a live before/after (reverted after measurement, hram's own git tree untouched -- confirmed via `git status`): at 1280 px, Ward Metrics 129.6 px -> 51.6 px empty (35 labels, 340 px surface -- matches this row's own original 130 px/38% measurement almost exactly), Access Ladder 156.9 px -> 80.6 px (35 labels, 369 px), Division Metrics 85.2 px -> 41.2 px (5 labels, 340 px) -- each roughly halved, consistent with removing exactly one of two equal additive reservations. Checked again at 375 px: no clipping at either width, no regression. SUBSTITUTION DECLARED: screenshot capture was unavailable in this session (Browser pane would not composite frames) -- this is DOM/computed-style measurement (`getBoundingClientRect`/`getComputedStyle` against the live rendered SVG), which for this WO's numeric acceptance criterion is close to sufficient on its own, per the WO's own fallback clause. Cost/Cost-effectiveness/Expert Mode cards from the original six-card table were not individually re-measured (time-boxed after the first three -- Ward Metrics, Access Ladder, Division Metrics -- gave a clean, consistent, reviewer-confirmed signal); those three all use `BarChart` and its rotated-tick `xAxisAngle` path same as the measured cards (`CostMetricsPanel.jsx`, `RatioMetricsPanel.jsx` both call `spaceForRotatedTicks` via `BarChart`), so the fix is expected to reach them the same way, just not independently confirmed with numbers here. Publishes automatically via `publish.yml` on this push (version-increase gate). |

package/dist/components/charts/ChartFrame.js

@@ -4,16 +4,17 @@ import { Alert, Box, Button, CircularProgress, Paper, Stack, Typography, } from
 import { useTranslation } from 'react-i18next';
 import { useTheme } from '@mui/material/styles';
 import { exportChartPng, exportChartSvg } from './exportChart';
-import { resolveChartHeight, warnOnHeightMismatch } from './chartDefaults';
+import { warnOnHeightMismatch } from './chartDefaults';
 export const CHART_FRAME_ROOT_SX = { p: 2 };
 export const CHART_FRAME_ALERT_SX = { mt: 2 };
 /**
  * Chart-type-agnostic chart scaffolding. Children may be an X-Charts primitive or a bespoke SVG.
  *
- * `minHeight` (CHART-8): a floor under an `aspect`-derived responsive height when `aspect` is
- * set and `height` is not; otherwise (no `height`, no `aspect`) it sizes the content box itself.
- * Once `height` is set, `height` sizes the box and it never reserves more than that, even if
- * `minHeight` is also passed and larger.
+ * `minHeight` (CHART-9): always just a floor on the content box, which holds a whole card --
+ * title, toolbar, chart, legend, footnotes, export links -- not a single chart. `height` is never
+ * applied to the box (unlike the four chart presets, whose box holds exactly one chart and do use
+ * `resolveChartHeight`'s `height`/`aspect` resolution); it is only compared against `minHeight` for
+ * `warnOnHeightMismatch`'s dev-mode note.
  */
 export function ChartFrame({ title, subtitle, toolbar, controls, loading = false, error = false, isEmpty = false, emptyMessage, minHeight, height, aspect, exportOptions = false, onExportSvg, onExportPng, meta, ariaLabel, children, variant = 'outlined', titleVariant = 'h6', sx, }) {
     const { t } = useTranslation();
@@ -27,8 +28,7 @@ export function ChartFrame({ title, subtitle, toolbar, controls, loading = false
     const hasCustomAriaLabel = Boolean(ariaLabel);
     const chartLabel = ariaLabel || title;
     const callerSx = Array.isArray(sx) ? sx : [sx];
-    useEffect(() => warnOnHeightMismatch('ChartFrame', { minHeight, height }), [minHeight, height]);
-    const { wrapperMinHeight, chartHeight } = resolveChartHeight({ minHeight, height, aspect });
+    useEffect(() => warnOnHeightMismatch('ChartFrame', { minHeight, height }, { heightWins: false }), [minHeight, height]);
     const runExport = async (type) => {
         setExportError(false);
         try {
@@ -55,8 +55,7 @@ export function ChartFrame({ title, subtitle, toolbar, controls, loading = false
     }
     return (_jsxs(Paper, { variant: variant, sx: [CHART_FRAME_ROOT_SX, ...callerSx], children: [_jsxs(Box, { sx: { display: 'flex', alignItems: 'flex-start', justifyContent: 'space-between', gap: 2, mb: 1 }, children: [_jsxs(Box, { children: [_jsx(Typography, { id: titleId, variant: titleVariant, children: title }), subtitle && _jsx(Typography, { variant: "body2", color: "text.secondary", children: subtitle })] }), toolbar && _jsx(Box, { children: toolbar })] }), controls && _jsx(Box, { sx: { mb: 2 }, children: controls }), _jsx(Box, { ref: chartRef, role: "img", "aria-label": chartLabel, "aria-labelledby": hasCustomAriaLabel ? undefined : titleId, sx: {
                     width: '100%',
-                    minHeight: wrapperMinHeight,
-                    height: chartHeight,
+                    minHeight,
                     aspectRatio: aspect,
                     display: 'flex',
                     alignItems: 'center',

package/dist/components/charts/chartDefaults.js

@@ -33,12 +33,6 @@ function cssLengthToPixels(value) {
     return parsed;
 }
 const MUI_LABELLED_X_AXIS_HEIGHT = 45;
-// THEME-11: this used to mirror MUI's own DEFAULT_MARGINS.bottom (20) -- the "resting" bottom
-// margin the rotated-tick path adds its extra height on top of. Now that PACKAGE_DEFAULT_MARGIN
-// below sets the package's own non-rotated bottom to 8, this constant must track THAT value, not
-// MUI's, or a rotated chart would add its extra height to the wrong (too generous) base while
-// every non-rotated chart got trimmed -- an inconsistent baseline between the two paths.
-const MUI_CHART_MARGIN_BOTTOM = 8;
 const AVERAGE_GLYPH_WIDTH_EM = 0.6;
 // THEME-11: this package never formed an opinion on chart margins, so every chart fell back to
 // MUI's own DEFAULT_MARGINS (20px on all four sides) -- measured live (hram's KPI cards) as 167
@@ -53,10 +47,11 @@ export const PACKAGE_DEFAULT_MARGIN = {
     top: 10, bottom: 8, left: 8, right: 16,
 };
 /**
- * Applies the package's own margin default, per side -- a caller's own value on any side (or
- * the rotated-tick path's own computed `bottom`) always wins on that side; only an UNSET side
- * gets the package default. A caller passing `{ left: 60 }` therefore keeps that 60 on the
- * left and gets the package defaults on the other three sides, never MUI's wider ones.
+ * Applies the package's own margin default, per side -- a caller's own value on any side always
+ * wins on that side; only an UNSET side gets the package default. A caller passing `{ left: 60 }`
+ * therefore keeps that 60 on the left and gets the package defaults on the other three sides,
+ * never MUI's wider ones. CHART-10: this applies identically whether or not the x-axis carries
+ * rotated labels -- `spaceForRotatedTicks` no longer computes a `bottom` of its own.
  */
 export function withMarginDefaults(margin) {
     const explicit = typeof margin === 'number'
@@ -97,26 +92,28 @@ function rotatedTickMetrics(axis, defaultLineHeight) {
     return { extraHeight };
 }
 /**
- * Rotated labels project both their line box and text width vertically.
- * X-Charts uses xAxis.height when deciding whether a label fits, while margin
- * only separates the axis from the SVG edge, so both surfaces must grow.
- * Explicit caller height and bottom-margin values always remain untouched.
+ * CHART-10: rotated labels project both their line box and text width vertically, and X-Charts
+ * uses `xAxis.height` -- not `margin.bottom` -- to size the band that actually CONTAINS them.
+ * `margin.bottom` only separates that axis band from the SVG edge; it plays no part in whether a
+ * label fits. Measured live (hram, 2026-08-22, real data): once `axis.height` carries the
+ * allowance, the rendered tick labels sit fully INSIDE the axis band with nothing below them --
+ * `margin.bottom` growing by the same allowance on top was reserving space nothing ever used, up
+ * to 130px (38% of a 340px card) on long rotated labels. Only `axis.height` grows here now;
+ * `margin` is returned untouched (whatever the caller passed, or didn't) so `withMarginDefaults`
+ * downstream applies the package's ordinary bottom default in every case, rotated or not -- a
+ * caller-set `margin.bottom` was never touched by this function even before this fix, and still
+ * isn't.
  */
 export function spaceForRotatedTicks(xAxis, margin, defaultLineHeight = 1) {
-    let largestExtraHeight = 0;
     const spacedXAxis = xAxis.map((axis) => {
         const metrics = rotatedTickMetrics(axis, defaultLineHeight);
         if (!metrics)
             return axis;
-        largestExtraHeight = Math.max(largestExtraHeight, metrics.extraHeight);
         if (axis.height != null)
             return axis;
         return Object.assign(Object.assign({}, axis), { height: MUI_LABELLED_X_AXIS_HEIGHT + metrics.extraHeight });
     });
-    const callerSetBottom = typeof margin === 'number' || (margin === null || margin === void 0 ? void 0 : margin.bottom) != null;
-    const spacedMargin = largestExtraHeight > 0 && !callerSetBottom
-        ? Object.assign(Object.assign({}, margin), { bottom: MUI_CHART_MARGIN_BOTTOM + largestExtraHeight }) : margin;
-    return { xAxis: spacedXAxis, margin: spacedMargin };
+    return { xAxis: spacedXAxis, margin };
 }
 // 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
@@ -275,16 +272,26 @@ export function resolveChartHeight({ minHeight, height, aspect }) {
  * -- the incoherent pair this WO closes. Not a throw: a shared package throwing on a prop
  * combination in production would break a consumer's page over a layout nit. Silent on the
  * equal-value majority and on the legitimate `minHeight` + `aspect` (no `height`) combination.
+ *
+ * CHART-9: `heightWins` distinguishes the two shapes this fires from. The four chart presets
+ * (default, `heightWins: true`) DO apply `resolveChartHeight`'s `height` to their box, so the
+ * original "height wins" wording is accurate there. `ChartFrame` (`heightWins: false`) never
+ * applies `height` to its box at all -- `minHeight` always keeps reserving the floor -- so it gets
+ * its own accurate wording instead of reusing the presets' story.
  */
-export function warnOnHeightMismatch(componentName, { minHeight, height }) {
+export function warnOnHeightMismatch(componentName, { minHeight, height }, { heightWins = true } = {}) {
     if (process.env.NODE_ENV === 'production')
         return;
     if (minHeight == null || height == null || minHeight === height)
         return;
+    const resolution = heightWins
+        ? 'they disagree, so height wins and the wrapper no longer reserves the extra space below the '
+            + 'chart. Pass only height, or drop minHeight if it should just track height.'
+        : 'they disagree; height is ignored here and minHeight keeps sizing the wrapper as a floor. '
+            + 'Pass only minHeight, or drop height if it was meant to size the whole card.';
     // eslint-disable-next-line no-console
     console.warn(`[ui-core-micha] <${componentName}> received both minHeight={${minHeight}} and height={${height}}; `
-        + 'they disagree, so height wins and the wrapper no longer reserves the extra space below the '
-        + 'chart. Pass only height, or drop minHeight if it should just track height.');
+        + resolution);
 }
 export function withChartSlotDefaults(slotProps, legendPosition) {
     var _a;

package/package.json

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

package/src/components/charts/ChartFrame.jsx

@@ -11,7 +11,7 @@ import {
 import { useTranslation } from 'react-i18next';
 import { useTheme } from '@mui/material/styles';
 import { exportChartPng, exportChartSvg } from './exportChart';
-import { resolveChartHeight, warnOnHeightMismatch } from './chartDefaults';
+import { warnOnHeightMismatch } from './chartDefaults';
 
 export const CHART_FRAME_ROOT_SX = { p: 2 };
 export const CHART_FRAME_ALERT_SX = { mt: 2 };
@@ -19,10 +19,11 @@ export const CHART_FRAME_ALERT_SX = { mt: 2 };
 /**
  * Chart-type-agnostic chart scaffolding. Children may be an X-Charts primitive or a bespoke SVG.
  *
- * `minHeight` (CHART-8): a floor under an `aspect`-derived responsive height when `aspect` is
- * set and `height` is not; otherwise (no `height`, no `aspect`) it sizes the content box itself.
- * Once `height` is set, `height` sizes the box and it never reserves more than that, even if
- * `minHeight` is also passed and larger.
+ * `minHeight` (CHART-9): always just a floor on the content box, which holds a whole card --
+ * title, toolbar, chart, legend, footnotes, export links -- not a single chart. `height` is never
+ * applied to the box (unlike the four chart presets, whose box holds exactly one chart and do use
+ * `resolveChartHeight`'s `height`/`aspect` resolution); it is only compared against `minHeight` for
+ * `warnOnHeightMismatch`'s dev-mode note.
  */
 export function ChartFrame({
   title,
@@ -58,8 +59,10 @@ export function ChartFrame({
   const chartLabel = ariaLabel || title;
   const callerSx = Array.isArray(sx) ? sx : [sx];
 
-  useEffect(() => warnOnHeightMismatch('ChartFrame', { minHeight, height }), [minHeight, height]);
-  const { wrapperMinHeight, chartHeight } = resolveChartHeight({ minHeight, height, aspect });
+  useEffect(
+    () => warnOnHeightMismatch('ChartFrame', { minHeight, height }, { heightWins: false }),
+    [minHeight, height],
+  );
 
   const runExport = async (type) => {
     setExportError(false);
@@ -113,8 +116,7 @@ export function ChartFrame({
         aria-labelledby={hasCustomAriaLabel ? undefined : titleId}
         sx={{
           width: '100%',
-          minHeight: wrapperMinHeight,
-          height: chartHeight,
+          minHeight,
           aspectRatio: aspect,
           display: 'flex',
           alignItems: 'center',

package/src/components/charts/chartDefaults.js

@@ -50,12 +50,6 @@ function cssLengthToPixels(value) {
 }
 
 const MUI_LABELLED_X_AXIS_HEIGHT = 45;
-// THEME-11: this used to mirror MUI's own DEFAULT_MARGINS.bottom (20) -- the "resting" bottom
-// margin the rotated-tick path adds its extra height on top of. Now that PACKAGE_DEFAULT_MARGIN
-// below sets the package's own non-rotated bottom to 8, this constant must track THAT value, not
-// MUI's, or a rotated chart would add its extra height to the wrong (too generous) base while
-// every non-rotated chart got trimmed -- an inconsistent baseline between the two paths.
-const MUI_CHART_MARGIN_BOTTOM = 8;
 const AVERAGE_GLYPH_WIDTH_EM = 0.6;
 
 // THEME-11: this package never formed an opinion on chart margins, so every chart fell back to
@@ -72,10 +66,11 @@ export const PACKAGE_DEFAULT_MARGIN = {
 };
 
 /**
- * Applies the package's own margin default, per side -- a caller's own value on any side (or
- * the rotated-tick path's own computed `bottom`) always wins on that side; only an UNSET side
- * gets the package default. A caller passing `{ left: 60 }` therefore keeps that 60 on the
- * left and gets the package defaults on the other three sides, never MUI's wider ones.
+ * Applies the package's own margin default, per side -- a caller's own value on any side always
+ * wins on that side; only an UNSET side gets the package default. A caller passing `{ left: 60 }`
+ * therefore keeps that 60 on the left and gets the package defaults on the other three sides,
+ * never MUI's wider ones. CHART-10: this applies identically whether or not the x-axis carries
+ * rotated labels -- `spaceForRotatedTicks` no longer computes a `bottom` of its own.
  */
 export function withMarginDefaults(margin) {
   const explicit = typeof margin === 'number'
@@ -117,28 +112,27 @@ function rotatedTickMetrics(axis, defaultLineHeight) {
 }
 
 /**
- * Rotated labels project both their line box and text width vertically.
- * X-Charts uses xAxis.height when deciding whether a label fits, while margin
- * only separates the axis from the SVG edge, so both surfaces must grow.
- * Explicit caller height and bottom-margin values always remain untouched.
+ * CHART-10: rotated labels project both their line box and text width vertically, and X-Charts
+ * uses `xAxis.height` -- not `margin.bottom` -- to size the band that actually CONTAINS them.
+ * `margin.bottom` only separates that axis band from the SVG edge; it plays no part in whether a
+ * label fits. Measured live (hram, 2026-08-22, real data): once `axis.height` carries the
+ * allowance, the rendered tick labels sit fully INSIDE the axis band with nothing below them --
+ * `margin.bottom` growing by the same allowance on top was reserving space nothing ever used, up
+ * to 130px (38% of a 340px card) on long rotated labels. Only `axis.height` grows here now;
+ * `margin` is returned untouched (whatever the caller passed, or didn't) so `withMarginDefaults`
+ * downstream applies the package's ordinary bottom default in every case, rotated or not -- a
+ * caller-set `margin.bottom` was never touched by this function even before this fix, and still
+ * isn't.
  */
 export function spaceForRotatedTicks(xAxis, margin, defaultLineHeight = 1) {
-  let largestExtraHeight = 0;
   const spacedXAxis = xAxis.map((axis) => {
     const metrics = rotatedTickMetrics(axis, defaultLineHeight);
     if (!metrics) return axis;
-
-    largestExtraHeight = Math.max(largestExtraHeight, metrics.extraHeight);
     if (axis.height != null) return axis;
     return { ...axis, height: MUI_LABELLED_X_AXIS_HEIGHT + metrics.extraHeight };
   });
 
-  const callerSetBottom = typeof margin === 'number' || margin?.bottom != null;
-  const spacedMargin = largestExtraHeight > 0 && !callerSetBottom
-    ? { ...margin, bottom: MUI_CHART_MARGIN_BOTTOM + largestExtraHeight }
-    : margin;
-
-  return { xAxis: spacedXAxis, margin: spacedMargin };
+  return { xAxis: spacedXAxis, margin };
 }
 
 // THEME-9: MUI X-Charts' own default y-axis width is a flat 45px (ticks) +
@@ -302,15 +296,25 @@ export function resolveChartHeight({ minHeight, height, aspect }) {
  * -- the incoherent pair this WO closes. Not a throw: a shared package throwing on a prop
  * combination in production would break a consumer's page over a layout nit. Silent on the
  * equal-value majority and on the legitimate `minHeight` + `aspect` (no `height`) combination.
+ *
+ * CHART-9: `heightWins` distinguishes the two shapes this fires from. The four chart presets
+ * (default, `heightWins: true`) DO apply `resolveChartHeight`'s `height` to their box, so the
+ * original "height wins" wording is accurate there. `ChartFrame` (`heightWins: false`) never
+ * applies `height` to its box at all -- `minHeight` always keeps reserving the floor -- so it gets
+ * its own accurate wording instead of reusing the presets' story.
  */
-export function warnOnHeightMismatch(componentName, { minHeight, height }) {
+export function warnOnHeightMismatch(componentName, { minHeight, height }, { heightWins = true } = {}) {
   if (process.env.NODE_ENV === 'production') return;
   if (minHeight == null || height == null || minHeight === height) return;
+  const resolution = heightWins
+    ? 'they disagree, so height wins and the wrapper no longer reserves the extra space below the '
+      + 'chart. Pass only height, or drop minHeight if it should just track height.'
+    : 'they disagree; height is ignored here and minHeight keeps sizing the wrapper as a floor. '
+      + 'Pass only minHeight, or drop height if it was meant to size the whole card.';
   // eslint-disable-next-line no-console
   console.warn(
     `[ui-core-micha] <${componentName}> received both minHeight={${minHeight}} and height={${height}}; `
-    + 'they disagree, so height wins and the wrapper no longer reserves the extra space below the '
-    + 'chart. Pass only height, or drop minHeight if it should just track height.',
+    + resolution,
   );
 }
 

package/tests/ChartFrame.test.jsx

@@ -212,17 +212,37 @@ describe('ChartFrame', () => {
     expect(screen.getByText('Aucune donnée disponible.')).toBeTruthy();
   });
 
-  // CHART-8: minHeight/height/aspect resolution on ChartFrame's own content box.
-  describe('minHeight/height resolution (CHART-8)', () => {
+  // CHART-9: ChartFrame's content box is a whole CARD (title, toolbar, chart, legend, footnotes,
+  // export links), not a single chart -- unlike the four chart presets, which do apply
+  // resolveChartHeight's height/aspect resolution to their own box. ChartFrame's box must never
+  // take a fixed `height`; `minHeight` is always just a floor content can exceed.
+  describe('minHeight/height resolution (CHART-9)', () => {
     function contentBoxStyle() {
       return window.getComputedStyle(screen.getByTestId('chart-body').parentElement);
     }
 
-    it('sizes the content box from minHeight alone when neither height nor aspect is set', () => {
+    it('sizes the content box from minHeight alone as a floor, never a fixed height', () => {
       renderFrame({ minHeight: 300 });
       const style = contentBoxStyle();
       expect(style.minHeight).toBe('300px');
-      expect(style.height).toBe('300px');
+      expect(style.height).toBe('auto');
+    });
+
+    it('does not receive a fixed height when content exceeds minHeight -- the regression itself', () => {
+      const i18n = i18next.createInstance();
+      i18n.init({ lng: 'en', resources, interpolation: { escapeValue: false } });
+      render(
+        <ThemeProvider theme={createTheme()}>
+          <I18nextProvider i18n={i18n}>
+            <ChartFrame title="Chart title" minHeight={100}>
+              <svg data-testid="chart-body" style={{ height: 500 }} />
+            </ChartFrame>
+          </I18nextProvider>
+        </ThemeProvider>,
+      );
+      const style = contentBoxStyle();
+      expect(style.minHeight).toBe('100px');
+      expect(style.height).toBe('auto');
     });
 
     it('leaves minHeight as a floor and gives no fixed height when aspect is set (no height)', () => {
@@ -233,25 +253,29 @@ describe('ChartFrame', () => {
       expect(style.aspectRatio).toBe('1.8 / 1');
     });
 
-    it('caps the wrapper at height when minHeight is larger, closing the dead-space gap', () => {
-      renderFrame({ minHeight: 420, height: 380 });
+    it('does not apply height as a fixed box height even when passed explicitly, and does not throw', () => {
+      expect(() => renderFrame({ minHeight: 420, height: 380 })).not.toThrow();
       const style = contentBoxStyle();
-      expect(style.minHeight).toBe('380px');
-      expect(style.height).toBe('380px');
-    });
-
-    it('is byte-identical when minHeight equals height', () => {
-      renderFrame({ minHeight: 320, height: 320 });
-      const style = contentBoxStyle();
-      expect(style.minHeight).toBe('320px');
-      expect(style.height).toBe('320px');
+      expect(style.minHeight).toBe('420px');
+      expect(style.height).toBe('auto');
     });
 
-    it('is unchanged when height is passed alone', () => {
+    it('ignores height when passed alone, with no minHeight floor either', () => {
       renderFrame({ height: 280 });
       const style = contentBoxStyle();
       expect(style.minHeight).toBe('auto');
-      expect(style.height).toBe('280px');
+      expect(style.height).toBe('auto');
+    });
+
+    it('warns with wording accurate to its own behaviour -- minHeight wins, not height', () => {
+      const warnSpy = vi.spyOn(console, 'warn').mockImplementation(() => {});
+      renderFrame({ minHeight: 420, height: 380 });
+      expect(warnSpy).toHaveBeenCalledOnce();
+      const message = warnSpy.mock.calls[0][0];
+      expect(message).toContain('ChartFrame');
+      expect(message).toContain('height is ignored');
+      expect(message).not.toContain('height wins');
+      warnSpy.mockRestore();
     });
   });
 });

package/tests/chartDefaults.test.js

@@ -19,6 +19,7 @@ import {
   PACKAGE_DEFAULT_MARGIN,
   resolveChartHeight,
   sizeYAxisForContent,
+  spaceForRotatedTicks,
   warnOnHeightMismatch,
   withAxisDefaults,
   withMarginDefaults,
@@ -162,10 +163,10 @@ describe('chart chrome defaults', () => {
     expect(barSpy.mock.calls.at(-1)[0].xAxis[0].scaleType).toBe('band');
   });
 
-  it('adds a font-and-angle-derived EXTRA bottom margin, on top of the package default, only for rotated tick labels', () => {
+  it('CHART-10: grows only xAxis.height for rotated tick labels, never margin.bottom on top of it', () => {
     renderBar({ xAxis: [{ data: ['Jan', 'Feb'], tickLabelStyle: { angle: -45 } }] });
     const rotatedProps = barSpy.mock.calls.at(-1)[0];
-    expect(rotatedProps.margin.bottom).toBeGreaterThan(PACKAGE_DEFAULT_MARGIN.bottom);
+    expect(rotatedProps.margin.bottom).toBe(PACKAGE_DEFAULT_MARGIN.bottom);
     expect(rotatedProps.xAxis[0].height).toBeGreaterThan(45);
 
     cleanup();
@@ -181,13 +182,14 @@ describe('chart chrome defaults', () => {
       expect(barSpy.mock.calls.at(-1)[0].margin).toEqual(PACKAGE_DEFAULT_MARGIN);
     });
 
-    // Trap 1 named in the WO: a package-level default injected BEFORE spaceForRotatedTicks'
-    // own `margin?.bottom != null` check would make every rotated-tick chart think the caller
-    // set bottom, and lose its extra rotation space entirely.
-    it('still gives a rotated-tick chart its enlarged bottom margin, not the flat package default', () => {
+    // CHART-10: the axis band, not the margin, carries the rotated-tick allowance -- a
+    // rotated-tick chart gets the SAME flat package bottom margin as any other chart. Named
+    // "still gives" in CHART-8/9 history; the correct behaviour is now the opposite of that name.
+    it('gives a rotated-tick chart the same flat package bottom margin as an unrotated one', () => {
       renderBar({ xAxis: [{ data: ['January', 'February'], tickLabelStyle: { angle: -90 } }] });
       const props = barSpy.mock.calls.at(-1)[0];
-      expect(props.margin.bottom).toBeGreaterThan(PACKAGE_DEFAULT_MARGIN.bottom + 10);
+      expect(props.margin.bottom).toBe(PACKAGE_DEFAULT_MARGIN.bottom);
+      expect(props.xAxis[0].height).toBeGreaterThan(45);
     });
 
     // Scope 1's merge semantics: a caller-supplied PARTIAL margin keeps its own value on the
@@ -436,6 +438,48 @@ describe('withMarginDefaults (THEME-11)', () => {
   });
 });
 
+describe('spaceForRotatedTicks (CHART-10)', () => {
+  const rotatedAxis = [{ data: ['January', 'February'], tickLabelStyle: { angle: -45, fontSize: 12 } }];
+
+  it('reserves the allowance once, on axis.height, and leaves margin untouched', () => {
+    const result = spaceForRotatedTicks(rotatedAxis, undefined);
+    expect(result.xAxis[0].height).toBeGreaterThan(45);
+    expect(result.margin).toBeUndefined();
+  });
+
+  it('is byte-identical at angle 0 -- each axis entry and the margin pass through untouched', () => {
+    const flatAxis = [{ data: ['Jan', 'Feb'], tickLabelStyle: { angle: 0 } }];
+    const margin = { top: 1 };
+    const result = spaceForRotatedTicks(flatAxis, margin);
+    expect(result.xAxis[0]).toBe(flatAxis[0]);
+    expect(result.margin).toBe(margin);
+  });
+
+  it('preserves a caller-set margin.bottom untouched -- the allowance is never added on top of it', () => {
+    const margin = { bottom: 50 };
+    const result = spaceForRotatedTicks(rotatedAxis, margin);
+    expect(result.margin).toBe(margin);
+    expect(result.margin.bottom).toBe(50);
+  });
+
+  it('drives the height estimate from the longest formatted tick, not a flat constant', () => {
+    const shortLabels = [{ data: ['A', 'B'], tickLabelStyle: { angle: -45, fontSize: 12 } }];
+    const longLabels = [{
+      data: ['A much longer ward name than the others', 'B'],
+      tickLabelStyle: { angle: -45, fontSize: 12 },
+    }];
+    const shortResult = spaceForRotatedTicks(shortLabels, undefined);
+    const longResult = spaceForRotatedTicks(longLabels, undefined);
+    expect(longResult.xAxis[0].height).toBeGreaterThan(shortResult.xAxis[0].height);
+  });
+
+  it('does not override an axis that already sets its own height', () => {
+    const axis = [{ data: ['January'], tickLabelStyle: { angle: -45 }, height: 200 }];
+    const result = spaceForRotatedTicks(axis, undefined);
+    expect(result.xAxis[0].height).toBe(200);
+  });
+});
+
 // CHART-8 -- pure-function contract of the minHeight/height/aspect resolver, independent of any
 // chart component wiring (component-level wiring is covered per-preset in each own test file).
 describe('resolveChartHeight (CHART-8)', () => {
@@ -505,4 +549,14 @@ describe('warnOnHeightMismatch (CHART-8)', () => {
     warnOnHeightMismatch('BarChart', { minHeight: undefined, height: 280 });
     expect(warn).not.toHaveBeenCalled();
   });
+
+  it('gives ChartFrame-accurate wording when heightWins is false (CHART-9)', () => {
+    const warn = vi.spyOn(console, 'warn').mockImplementation(() => {});
+    warnOnHeightMismatch('ChartFrame', { minHeight: 420, height: 380 }, { heightWins: false });
+    expect(warn).toHaveBeenCalledOnce();
+    const message = warn.mock.calls[0][0];
+    expect(message).toContain('ChartFrame');
+    expect(message).toContain('height is ignored');
+    expect(message).not.toContain('height wins');
+  });
 });

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

@@ -0,0 +1,150 @@
+# UCM-CHART-10 — The rotated-tick allowance is reserved twice, and the surplus is dead space
+
+- **Repo:** `ui-core-micha`, branch `main` (shared-core; publishes from `main`, no staging step)
+- **Tier:** 3 — shared-core; every consumer's chart proportions change.
+- **Status:** planned
+- **Workstream:** `CHART-*`
+- **Files:** `src/components/charts/chartDefaults.js` (`spaceForRotatedTicks`, `rotatedTickMetrics`)
+  and its tests. The presets only *call* the helper — do not change them.
+
+> **Why — measured in hram, 2026-08-22, with ucm 2.42.1 loaded and real data.** `spaceForRotatedTicks`
+> adds the same `extraHeight` in **two** places:
+>
+> ```js
+> return { ...axis, height: MUI_LABELLED_X_AXIS_HEIGHT + metrics.extraHeight };   // (1) the axis band
+> ...
+> ? { ...margin, bottom: MUI_CHART_MARGIN_BOTTOM + largestExtraHeight }           // (2) the chart margin
+> ```
+>
+> **In MUI v8 the axis `height` and the chart `margin.bottom` are additive.** The allowance for
+> rotated tick labels is therefore counted twice, the axis band already holds the labels, and the
+> margin copy is left over as an empty band below the plot.
+>
+> Measured on the Research → Allocation drill-down at 1280 px:
+>
+> | card | surface height | plot ends at | empty below the axis | x tick labels |
+> |---|---|---|---|---|
+> | Ward Metrics | 340 | 131 | **130 px (38 %)** | 35 |
+> | Access Ladder | 340 | 131 | **130 px (38 %)** | 35 |
+> | Cost | 340 | 194 | 92 px | 35 |
+> | Division Metrics | 340 | 199 | 85 px | 5 |
+> | Cost-effectiveness | 420 | 331 | 44 px | 22 |
+> | Expert Mode: Simulation Trajectory | 340 | 287 | 8 px | 31 |
+>
+> Two things make this conclusive rather than suggestive. First, the empty band **scales with the
+> label load** — 35 long rotated ward names cost 130 px, short labels cost 8 px. Second,
+> `emptyBelowLowestLabel` equals `emptyBelowAxisLine` on **every** chart measured: the tick labels sit
+> inside the axis band, and the space below them is occupied by nothing at all.
+>
+> **This is the same failure class as hram's tornado** (`RES-28`), where `margin.left: 220` was
+> reserved *in addition to* an unsized `yAxis`, and as `UCM-CHART-8`'s `minHeight`/`height` pair:
+> **space reserved in two places that add up.** Third instance in this file. Neither `UCM-CHART-8`
+> nor `UCM-CHART-9` could have caught it — both worked on the wrapper box; this one is in the axis
+> margin arithmetic.
+
+---
+
+## Part A — Envelope (authoritative WHAT/WHY)
+
+### Goal
+
+The rotated-tick allowance is reserved **once**. A chart with long rotated x labels uses its surface
+for the plot, not for an empty band under the axis.
+
+### Definition of Done
+
+- [x] **`extraHeight` is applied once, not twice.** Kept on `axis.height` only; `margin.bottom`'s
+      addition removed. MUI needs `axis.height` — the live measurement below shows rendered labels
+      sit fully inside the axis band with nothing below them, i.e. the band already fully
+      accommodates the rotation; `margin.bottom`'s copy was reserving space nothing used.
+- [x] **The plot area grows by the reclaimed amount.** Measured live on hram (`CLI-Kilombero_2026-per_cell-network`,
+      real data, 1280 px), same three cards, same candidate, before vs. after swapping in the fixed
+      build: Ward Metrics (35 labels, 340 px) 129.6 px → 51.6 px empty; Access Ladder (35 labels,
+      369 px) 156.9 px → 80.6 px; Division Metrics (5 labels, 340 px) 85.2 px → 41.2 px — each
+      roughly halved, matching "remove exactly one of two equal additive reservations." The residual
+      is the legitimate rotation-geometry padding this WO's non-goals say not to chase.
+- [x] **Tick labels are not clipped.** Checked at both 1280 px and 375 px on the same three live
+      cards (lowest label's rendered bottom never exceeded the SVG's own bottom edge at either
+      width) — no clipping introduced by reserving less.
+- [x] **Charts with no rotation are byte-identical.** Unit-tested directly against
+      `spaceForRotatedTicks` (angle-0 axis entry and margin object both pass through by reference,
+      not just by value) — see `tests/chartDefaults.test.js`, `spaceForRotatedTicks (CHART-10)`.
+- [x] **A caller-set `margin.bottom` still wins.** Implemented as an unconditional guarantee rather
+      than the named `callerSetBottom` escape hatch: `spaceForRotatedTicks` no longer writes to
+      `margin` in any branch, so a caller-set value is never at risk regardless of rotation — a
+      strict superset of the old conditional guard, confirmed by both independent reviewers as a
+      clean simplification, not a behaviour gap. The named variable/constant it used
+      (`callerSetBottom`, `MUI_CHART_MARGIN_BOTTOM`) were removed as dead code once nothing reads
+      them.
+
+### Investigate in the same pass — likely the same helper
+
+hram reports **x-axis tick marks rendering without their labels** on scatter charts
+(`AccessGapScatterPanel`, the optimization cost-effectiveness scatter) — `HRAM-RES-29` item 2, still
+open. A formatter exists on both axes (`ScatterChart.jsx:193,199`), so it is not a missing formatter.
+**The suspicion is that it is this same function in the other direction:** `axis.height` set to a
+band the labels do not fit, so MUI draws the ticks and clips the text.
+
+- [x] **Refuted.** `ScatterChart.jsx` never calls `spaceForRotatedTicks` at all (grep-confirmed:
+      only `BarChart.jsx`/`LineChart.jsx` import it) — its x-axis `height` is never touched by this
+      helper in either direction, so this function cannot be the cause. Confirmed further at the two
+      named hram call sites (`AccessGapScatterPanel.jsx:203`, `OptimizationResultsPanel.jsx:1014`):
+      neither sets `tickLabelStyle.angle` on its `xAxis`, so `rotatedTickMetrics` would return `null`
+      even if the helper were in the path. This matches hram's own `HRAM-RES-29` register row
+      (`WORK_ORDERS.md`), which had already independently traced and closed item 2 the same day
+      (2026-08-22, before this WO's own "still open" line was written): the real cause was
+      `ScatterChart.jsx` rendering `<MuiScatterChart>` with no explicit `height` pre-`11d362c`
+      (`UCM-CHART-8`, `2.41.3`), racing MUI's own collision-avoidance against the wrapper's
+      `aspect-ratio` CSS and clipping tick text with no missing formatter involved. `2.42.0` already
+      fixes it for every consumer by passing a resolved `height` explicitly; hram's `develop` already
+      pinned `2.42.0` (why local measurement looked clean) and only `main`/`hram.ch` (still on
+      `2.41.3` at the time) showed it — closing on hram's next `develop -> main` promotion. No action
+      needed here or in `HRAM-RES-29`; this WO's own suspicion is retired, not carried forward.
+
+### Non-goals
+
+- Do not change the four presets or `ChartFrame` — they only call this helper.
+- Do not revisit `UCM-CHART-8`'s `minHeight`/`height`/`aspect` resolution or `UCM-CHART-9`'s frame
+  fix. Both are correct and verified; this is a third, independent reservation.
+- Do not "fix" this by shrinking `MUI_LABELLED_X_AXIS_HEIGHT` or `MUI_CHART_MARGIN_BOTTOM` — those
+  constants are not the bug, the double application is.
+
+### Risks
+
+- **Every consumer's chart proportions change**, and in the visible direction: plots get taller. That
+  is the point, but it is a shared-core publish and the rendered check below is what proves it.
+- The clipping failure mode is the mirror of this one. A fix that reserves too little trades a
+  cosmetic defect for an information-losing one — clipped labels are worse than empty space.
+- hram's `RES-28` fixes the same class in hram's own tornado (`margin.left` vs `yAxis.width`). The
+  two are independent; do not assume one closes the other.
+
+### Tests to WRITE — narrow
+
+- `spaceForRotatedTicks` with a rotated axis: the total reserved space equals the allowance **once**,
+  asserted against the computed `axis.height` + `margin.bottom` sum — the assertion that fails today.
+- Angle 0: output identical to input, axis and margin untouched.
+- A caller-set `margin.bottom`: preserved, allowance not added on top.
+- The longest-label path (`longestFormattedTick`) still drives the estimate.
+
+**Rendered check before publish — numeric, on hram with real data.** The same six cards measured
+above, at 1280 px and 375 px: the empty band below the axis, per card, before and after. Named in
+the register note. If capture is unavailable, DOM measurement is acceptable **and must be declared
+as a substitution** — for this WO that is nearly sufficient anyway, since the acceptance criterion
+is a measured pixel count rather than an impression.
+
+---
+
+## Part B — Implementation map
+
+> **TO BE FILLED BY THE ORCHESTRATOR** on `git pull`. Must carry `spaceForRotatedTicks` and
+> `rotatedTickMetrics` with line anchors, the two constants, the callers, the absolute working
+> directory, the progress contract, and the preamble. **Do not dispatch while this placeholder
+> stands.**
+
+---
+
+## Part C — Orchestrator-only
+
+> **TO BE FILLED BY THE ORCHESTRATOR.** Review routing (`reviewer` + `ui_reviewer`, full context —
+> Tier 3 shared-core), the numeric rendered check as a hard commit gate, register maintenance,
+> registry publish verification, commit, and the execution directive with its self-address guard.

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

@@ -0,0 +1,265 @@
+# UCM-CHART-9 — `ChartFrame` is a card, not a chart: it must never take a fixed height
+
+- **Repo:** `ui-core-micha`, branch `main` (shared-core; publishes from `main`, no staging step)
+- **Tier:** 3 — shared-core, and this is a **live layout regression in a published version**.
+- **Status:** planned
+- **Workstream:** `CHART-*`
+- **Files:** `src/components/charts/ChartFrame.jsx` and its tests. `chartDefaults.js` only if the
+  resolver needs a second shape — see below; the preset behaviour is correct and must not change.
+
+> **Why — regression, observed on staging after hram bumped to 2.42.0.** `UCM-CHART-8` wired
+> `resolveChartHeight()` through the four chart presets **and through `ChartFrame`**. For the
+> presets that is right. For `ChartFrame` it is not, and the difference is what the box contains.
+>
+> In the `minHeight` alone / no `height` / no `aspect` branch, `resolveChartHeight` returns
+> `chartHeight = minHeight`, and `ChartFrame` now applies it:
+>
+> ```diff
+> -          minHeight,
+> +          minHeight: wrapperMinHeight,
+> +          height: chartHeight,
+> ```
+>
+> **A chart preset's box contains exactly one chart. `ChartFrame`'s box contains a whole card** —
+> title, toolbar, the chart, a legend, footnotes, export links. Turning its `minHeight` floor into a
+> fixed `height` makes the box shorter than its content, the content overflows, and **adjacent cards
+> visibly overlap**: the operator's screenshot shows a card title rendered over the chart of the card
+> above it and three sets of "Export SVG / Export PNG" stacked at different offsets.
+>
+> `UCM-CHART-8`'s own Files note recorded that `ChartFrame` "never destructures `height`" — and the
+> implementation then gave it one. The rule was written for presets and applied to a frame.
+
+---
+
+## Part A — Envelope (authoritative WHAT/WHY)
+
+### Goal
+
+`ChartFrame` stops setting a fixed `height` on its content box. Its `minHeight` goes back to meaning
+what its name says — a floor that content can exceed. The four chart presets keep `UCM-CHART-8`'s
+three-way resolution unchanged.
+
+### Definition of Done
+
+- [ ] **`ChartFrame` never applies `chartHeight` to its content box.** Its box takes `minHeight` as a
+      floor, as it did before 2.42.0. Whether that is done by not calling `resolveChartHeight` at
+      all, or by giving the resolver an explicit frame shape, is the implementer's call — but
+      `ChartFrame` must not end up with a fixed `height` in any branch.
+- [ ] **A `ChartFrame` whose content exceeds `minHeight` grows.** This is the regression, stated as
+      the acceptance criterion: content taller than the floor must extend the box, never overflow it.
+- [ ] **The four presets are untouched.** `ScatterChart`, `BarChart`, `LineChart`, `TimeSeriesChart`
+      keep `UCM-CHART-8` exactly as it landed — including the `aspect` branch that four live call
+      sites depend on. This WO narrows one consumer of the resolver; it does not revisit the rule.
+- [ ] **`ChartFrame`'s JSDoc is corrected.** 2.42.0 added a paragraph claiming `minHeight`
+      "sizes the content box itself" when there is no `height`/`aspect`. That sentence is the bug in
+      prose form and must go.
+- [ ] **`warnOnHeightMismatch` stays** on `ChartFrame` — a caller passing both is still worth a
+      dev-mode note, even though the frame no longer acts on `height`.
+
+### Non-goals
+
+- Do **not** revert `UCM-CHART-8`. Its preset behaviour is correct and is the fix hram needs; only
+  the frame's participation was wrong.
+- Do not change `resolveChartHeight`'s three-way rule for presets.
+- No consumer-side change in this WO.
+
+### Risks
+
+- **`ChartFrame` is used by every Research card in hram and by other consumers.** The change restores
+  pre-2.42.0 behaviour for it, so the risk is low in direction — but it is still a shared-core
+  publish, and the rendered check below is what proves it.
+- 2.42.0 is `latest` on the registry and carries this regression. Publish 2.42.1 promptly; note in
+  the register that 2.42.0 should not be adopted by a new consumer.
+- **hram's Detailed Results tab is fixed as of 2.42.0** (operator-confirmed, 2026-08-21) — it
+  crashed with React #185 before the bump (`HRAM-RES-29` item 1) and does not any more. What is
+  **not** established is *why*: the plausible mechanism is that deterministic sizing removed a
+  resize-driven `setState` loop, but nobody has traced it.
+  **Consequence for this WO, and the only reason it is mentioned here:** since we do not know what
+  fixed it, we cannot know whether moving `ChartFrame` back toward a floor disturbs it. Re-check the
+  tab after this lands. If the crash returns, that is a finding for `HRAM-RES-29` and a sizing
+  dependency worth understanding — not a reason to undo this fix.
+
+### Tests to WRITE — narrow
+
+- **The regression test:** a `ChartFrame` with `minHeight` and no `height`/`aspect`, containing
+  content taller than `minHeight`, does **not** receive a fixed `height` on its content box.
+- `ChartFrame` with `height` explicitly passed: `height` is still not applied as a fixed box height
+  (the frame is not a chart), and no exception is thrown.
+- The four presets' existing `UCM-CHART-8` tests stay green **unchanged** — if one of them has to be
+  edited, the change has leaked out of `ChartFrame` and that is a stop-and-report.
+
+**Rendered check before the hram pin bump — mandatory, and the reason this WO exists.** The unit
+tests for 2.42.0 were 188 green and said nothing about layout, because they cannot. Before hram's pin
+moves again, the affected cards are checked rendered at 375 px and 1280 px: Sensitivity, Access,
+Access Ladder, Allocation, Optimization. Named in the register note, with the substitution declared
+if capture is unavailable.
+
+---
+
+## Part B — Implementation map — ADDRESSED TO THE IMPLEMENTER
+
+### Context package
+
+**Named files to change:**
+- `src/components/charts/ChartFrame.jsx` — the fix (below).
+- `tests/ChartFrame.test.jsx:215-256` — the `describe('minHeight/height resolution (CHART-8)', …)`
+  block. It currently **asserts the bug as correct behaviour** (e.g. `minHeight` alone →
+  `style.height` toBe `'300px'`). Rewrite it to assert the fixed behaviour; rename the block to
+  `(CHART-9)`.
+
+**Do NOT touch (verified against the landed code):**
+- `src/components/charts/chartDefaults.js` — `resolveChartHeight` (lines ~289-298) and
+  `warnOnHeightMismatch` (lines ~306-315) keep their exact current contract. If the fix seems to need
+  a change here, that means the change has leaked out of `ChartFrame` — stop and report, don't edit.
+- `src/components/charts/{BarChart,LineChart,ScatterChart,TimeSeriesChart}.jsx` — all four still call
+  `resolveChartHeight({ minHeight, height, aspect })` for their OWN box, unchanged.
+- `tests/chartDefaults.test.js:441+` (`describe('resolveChartHeight (CHART-8)', …)`) and the four
+  presets' own test files — must stay green **unchanged**. If one needs an edit, stop and report.
+
+**The bug, exactly:** `ChartFrame.jsx:61-62` calls `resolveChartHeight({ minHeight, height, aspect })`
+and applies the result to its content box at `:109-125`:
+```jsx
+sx={{
+  width: '100%',
+  minHeight: wrapperMinHeight,
+  height: chartHeight,
+  aspectRatio: aspect,
+  ...
+}}
+```
+In the "no `height`, no `aspect`" branch, `resolveChartHeight` returns `chartHeight = minHeight` —
+correct for a preset's box (which holds exactly one chart) but wrong for `ChartFrame`'s box (which
+holds a whole card: title, toolbar, chart, legend, footnotes, export links). A fixed `height` there
+makes the box shorter than its content, and the content overflows into the next card.
+
+**What "restore pre-2.42.0 behaviour" means concretely** — before `UCM-CHART-8` (commit `11d362c`),
+`ChartFrame` had no `height` prop at all and its content box was:
+```jsx
+sx={{
+  width: '100%',
+  minHeight,
+  aspectRatio: aspect,
+  display: 'flex',
+  alignItems: 'center',
+  justifyContent: 'center',
+}}
+```
+i.e. `minHeight` applied raw, straight from props, never touched by any resolver; no `height` was
+ever set on the box.
+
+**The fix:** `ChartFrame`'s content box must end up equivalent to that — `minHeight` (raw, from
+props) as the box's only height-related sx property besides `aspectRatio`, and nothing ever sets
+`height` on the box. The `height` prop stays in `ChartFrame`'s signature (do not remove it — it is
+still a documented prop and `warnOnHeightMismatch('ChartFrame', { minHeight, height })` at line 61
+must keep firing on a caller passing both `minHeight` and a disagreeing `height`), it is simply no
+longer used to size the box. Whether you implement this by dropping the `resolveChartHeight` call
+from `ChartFrame` entirely (simplest — matches the pre-2.42.0 shape exactly) or by giving the
+resolver a second, frame-specific shape in `chartDefaults.js` that never returns a `chartHeight` is
+your call — but per the non-goals below, the existing `resolveChartHeight` export and its three-way
+preset contract must not change.
+
+**JSDoc fix:** `ChartFrame.jsx:19-26`'s docblock currently states: *"otherwise (no `height`, no
+`aspect`) it sizes the content box itself. Once `height` is set, `height` sizes the box…"* — that
+sentence describes the bug as intended behaviour and must be corrected to state that `minHeight` is
+always a floor on `ChartFrame`'s box and `height` is never applied to it (only used for the
+dev-mode mismatch warning).
+
+**Regression check while you're in there:** hram's Detailed Results tab crashed with React #185
+before the 2.42.0 bump and stopped crashing after it (`HRAM-RES-29` item 1, unconfirmed hypothesis:
+deterministic sizing removed a resize-driven `setState` loop). This fix moves `ChartFrame` back
+toward non-deterministic sizing for that one prop. You are not expected to reproduce or verify the
+hram-side crash — the Orchestrator does that separately after your diff lands — but do not add any
+new resize-driven effect to `ChartFrame` while touching this code.
+
+Work from this package; do not explore broadly from scratch — open only the named files to verify.
+If you must dig deeper, delegate to a read-only Explore sub-agent (Haiku).
+
+### Target repo working directory (absolute)
+
+`C:\Users\Micha Bigler\Documents\webapps\ui-core-micha`
+
+### Preamble — binding, read before doing anything else
+
+The text in this file is the COMPLETE spec — the committed WO content, not a plan to refine; there
+is no separate plan file. Read the nearest `AGENTS.md`, the relevant `.codex/skills/<role>/SKILL.md`,
+and this repo's own `MEMORY.md` ONLY for conventions. Stay in scope; do not touch
+auth/permissions/deps/schema/CI unless this spec says so; do not update `MEMORY.md`. **Do NOT edit
+`WORK_ORDERS.md`** — the register row and the review verdicts are the orchestrator's alone. Do NOT
+`git add`/`commit`/`push` — leave every change uncommitted in the working tree for the orchestrator's
+independent review. WRITE the tests the "Required tests to WRITE" section (Part A) calls for AND
+**RUN the tests you just wrote** to confirm they execute and pass — that is the ONLY test run you do
+(NOT the app's affected/full suite, NOT any review). The orchestrator re-runs the authoritative set
+and does the independent review after you finish — those are the gate; your own run does not count
+as the gate.
+
+Narrate continuously: a `PLAN: <step1> | <step2> | …` line up front, then a single-line
+`PROGRESS: [<n>/<total>] <present-tense action>` before every relevant action (and `… done` on
+completion), spaced so no gap exceeds ~2 min, stdout unbuffered, plus exactly one final
+`RESULT: DONE|BLOCKED <reason>`.
+
+---
+
+## Part C — Orchestrator only — NOT ADDRESSED TO THE IMPLEMENTER
+
+> **If you are the implementer reading this work order as your own specification: STOP at this
+> line.** Everything below describes what the Orchestrator does AFTER you finish. You do none of it
+> — no reviewers, no verification run, no register edit, no commit. You ARE the invocation described
+> below; do NOT shell out to `codex exec`.
+
+### Execution directive
+
+Implement through `codex exec` in the background — invoked directly via Bash (never the
+`debugger`/`*_coder` Agent wrappers) with BOTH flags `--skip-git-repo-check` and
+`--dangerously-bypass-approvals-and-sandbox`, `cwd` = the working directory above (never
+`…\webapps`). Fallback to direct Claude implementation only on Codex quota/rate-limit/non-zero exit —
+check `.claude/codex-status.md` first per its own rule (no line for 2026-08-22 → use Codex). The
+fallback flips authorship, making an independent `reviewer` mandatory even if it already was.
+
+### Review routing (Tier 3, shared-core)
+
+- `reviewer`: **yes**, full context, Sonnet-pinned, background.
+- `ui_reviewer`: **yes** (diff touches frontend), full context, background, same batch as `reviewer`.
+- `sec_reviewer`: not required — no auth/security surface in this diff.
+- Both run concurrently; neither is skippable; commit waits for both clean.
+
+### Verification (the authoritative run — Codex's own run is not the gate)
+
+1. **Test gate:** `npx vitest run tests/ChartFrame.test.jsx tests/chartDefaults.test.js
+   tests/BarChart.test.jsx tests/LineChart.test.jsx tests/ScatterChart.test.jsx
+   tests/TimeSeriesChart.test.jsx` (adjust filenames to whatever actually exists — the affected-area
+   set per AGENTS.md "Test scope": `ChartFrame` itself plus every consumer of `resolveChartHeight`).
+   All must pass; the four presets' pre-existing assertions must be **byte-identical**, not just
+   green — a changed preset assertion means the fix leaked scope.
+2. **Rendered check — this WO's own commit gate, scoped to what this repo can render.** This repo
+   has no prototype artifact, so the generic prototype side-by-side gate does not apply; this WO's
+   own Envelope names a rendered check instead, and it is honoured here at the scope this repo can
+   actually reach:
+   - Run `npm run dev` (Vite) and open the dev harness at 375 px and 1280 px. It already contains
+     `ChartFrame` "shape check" stories that mirror three of the five named hram cards — "Allocation
+     performance", "Access gap", "Optimization results" (`dev/entries.jsx`, search `shape check`).
+     Confirm none of them, nor any neighbouring card, show overlapping title/content/export rows at
+     either width.
+   - Additionally render (ad hoc, in the same dev session — e.g. a temporary story or by editing an
+     existing one's children) a `ChartFrame` with a `minHeight` smaller than its actual content, to
+     directly exercise the Definition of Done's acceptance criterion: the box must grow to fit the
+     content, not overflow it. Revert any temporary dev-harness edit before commit (or keep it only
+     if it's a genuine permanent addition worth keeping — your call, but say which in the Notiz).
+   - This repo's harness has no "Sensitivity" or "Access Ladder" story, so the **full five-card
+     rendered check the Envelope describes ("before hram's pin moves again") is NOT done by this WO**
+     — it cannot be, without linking a built `ui-core-micha` into a running hram dev server. Declare
+     this explicitly in the register Notiz as a carried-forward precondition on whichever WO next
+     bumps hram's pin past 2.42.0, not a silently dropped gate.
+   - Declare screenshots-vs-DOM-inspection substitution explicitly if real screenshots aren't taken.
+
+### Register + commit
+
+- `WORK_ORDERS.md` row → `done`, with: the named review verdicts (`reviewer` + `ui_reviewer`, no
+  open findings — or the findings and their resolution), the test gate result, the rendered-check
+  scope actually achieved (dev harness only, full hram five-card check carried forward), and which
+  evidence from `.claude/codex-status.md` was used (or that no fallback was needed).
+- Note in the Notiz: **publish 2.42.1 promptly after commit** (per Part A Risks — 2.42.0 is `latest`
+  on the registry and carries this regression) and confirm the version bump lands in the same commit
+  or a clearly-linked follow-up; the register row must name whichever it was.
+- Commit message: single concise English subject line (e.g. `fix(ChartFrame): stop applying a fixed
+  height to the card box (CHART-9)`). Push to `main` (this repo publishes from `main`, no `develop`
+  step) once review + tests are clean.