@micha.bigler/ui-core-micha 2.31.0 → 2.31.1

package/WORK_ORDERS.md

@@ -24,6 +24,7 @@ prefixed ID; never reuse a bare flat number across workstreams.
 
 | ID | Titel | Beschreibung | Datum | Status | Commit(s) | Notiz |
 |---|---|---|---|---|---|---|
+| THEME-2 | Two defects from the THEME-1/CHART-6 landings: `warning.main` contrast, `grid` replacing instead of merging | Fixes `palette.warning.main` (`#C08A2C`, 3.038:1 on white — fails AA) to `#976100` (the existing `text` tone, ~5.2:1), `contrastText` to `#FFFFFF`; `warning.fill`/`.text`/`.fillText`/`.bg` unchanged. Adds a completeness-assertion rule checking every status channel's `.main` against `#FFFFFF` and `background.default` at 4.5:1. Fixes `BarChart`/`LineChart`'s `grid` prop silently replacing (not merging) a caller's partial grid object; the required audit of sibling object-valued defaults found a second live instance (`legendPosition`, same bug class) and fixed it too. `2.31.1` (patch). Full spec: [work-orders/THEME-2.md](work-orders/THEME-2.md). | 2026-08-10 | done | 7d5039f | Envelope authored by Expertenchat, both defects fully diagnosed up front (no design question). Preconditions (THEME-1 `2.30.0`, CHART-6 `2.31.0`) verified. Orchestrator filled the Implementation map with the exact current-state code pointers for both defects, then ran Codex (stdin invocation). Codex's own audit (per the WO's "close the mechanism" instruction) found the `legendPosition` partial-override bug beyond the named `grid` fix and fixed it too, exactly as the WO anticipated ("fix that too and say so"). **Independent `reviewer` (Sonnet) + `ui_reviewer` (Haiku) ran concurrently — both found NO findings**, including the reviewer's own hand-computed contrast check confirming `#976100` clears 4.5:1 against both `#FFFFFF` (~5.22:1) and `background.default` (~5.00:1). One thing the Orchestrator itself fixed (not a reviewer finding): a pre-existing THEME-1 regression test (`tests/createAppTheme.test.js`) asserted `palette[status].main === palette[status].fill` for all four status channels — THEME-2 deliberately breaks that equality for `warning` only (the whole point of the fix), so the assertion was updated to special-case `warning` against its new intended invariant (`main === text`, `contrastText === '#FFFFFF'`) while `success`/`error`/`info` keep the original assertion. Re-verified after the fix: 58/58 scoped + adjacent vitest tests green (`tests/themeCompleteness.test.js`, `tests/chartDefaults.test.js`, `tests/createAppTheme.test.js`, `tests/chartsPalette.test.js`, `tests/BarChart.test.jsx`, `tests/LineChart.test.jsx`, `tests/TimeSeriesChart.test.jsx`), `tsc -p tsconfig.build.json --noEmit` clean. **Two-width rendered side-by-side (DS-1 gate)** run in the dev harness's "Theme / Shared baseline" entry — the WO's own point was that no existing specimen exercised `.main` (the `StatusChip`'s `sx={{bgcolor:'...fill'}}` and the `MuiAlert` `standardWarning` override both bypass it), so a new Button/Chip/`Alert variant="filled"` specimen row was added and confirmed live at 375px and 1280px: the warning tone now renders visibly darker (brown, white text) than the still-unchanged lighter-amber `fill`-based chip beside it. The "Caller overrides" `LineChart` specimen's `grid` prop was also changed from a complete `{horizontal:true,vertical:true}` object (which wouldn't have visually proven the merge) to a genuinely partial `{vertical:true}` one — confirmed live at both widths showing BOTH grid directions post-fix. |
 | CHART-6 | Chart-chrome defaults in the three wrappers, plus two generic fixes hoisted up | Closes the chart-chrome default surface in `BarChart`/`LineChart`/`TimeSeriesChart`: baseline tick font size (from `theme.typography.caption`), a horizontal grid, `showMark:false` with a filled-marker fix when a caller opts markers back in, automatic bottom-margin growth for rotated tick labels, a new `legendPosition` prop (default bottom-start), and `TimeSeriesChart`'s own toolbar becoming the sole legend (MUI's redundant second legend removed). Hoists `chartLabels.js` (short granularity-aware tick-label formatters) and a generalised `yearTickInterval` from fitness-monitor. `2.31.0`. Full spec: [work-orders/CHART-6.md](work-orders/CHART-6.md). | 2026-08-10 | done | 6dedc62 | Envelope authored by Expertenchat (DS-4). Precondition (THEME-1 landed + published `2.30.0`) verified before start. Orchestrator filled the Implementation map with concrete MUI X-Charts source pointers (installed `8.29.2`, not the WO's stated `8.28.2` — flagged and verified against the actual installed source throughout), then ran Codex (stdin invocation, same as THEME-1). Codex implemented `src/components/charts/{chartDefaults,chartLabels,yearTickInterval}.js`, wired all three wrappers, wrote the 10 required tests, and used a wrapper-level `slots.mark` composition for the filled-marker fix (a deliberate, now-documented deviation from the WO's named `MuiMarkElement` theme-token mechanism — the wrapper-level fix applies to all 14 consumers immediately on this version bump, not only to apps that separately adopt `createAppTheme`). **Independent `reviewer` (Sonnet) + `ui_reviewer` (Haiku) ran concurrently.** `reviewer` found **R1 (P2)** — the marker-fill deviation from the WO's specified mechanism was undocumented; fixed with an explanatory code comment (functionally correct either way, this was a disclosure gap, not a bug). `ui_reviewer` found **U1 (P3)** — `SeriesToggleDot`'s 12px dot used hardcoded pixels instead of `theme.spacing()`; fixed. Both reviewers otherwise found the six highest-risk invariants (default-vs-caller-override merge order, filled markers, rotated-tick margin math, the double-legend fix, `yearTickInterval`'s generalisation, `skipAnimation` passthrough) correct and non-vacuously tested. **A third, more serious bug was found by the Orchestrator's own DS-1 two-width rendered check (not by either reviewer, since both are static-diff reviews)**: `withAxisDefaults` in `chartDefaults.js` only applied `defaults.scaleType` when the caller passed NO `xAxis`/`yAxis` array at all — a caller-supplied axis with `data` but no explicit `scaleType` (exactly what the new dev-harness "Chart defaults" `LineChart` specimen used) silently lost the wrapper's `'point'`/`'band'` scale default entirely, leaving MUI's scale undefined and every rendered line/point position `NaN` (`<path> attribute d: Expected number, "MNaN,...`, confirmed live via `read_console_messages` and only reproducible through a real MUI scale computation — a mocked prop-assertion test structurally cannot catch it, the same class of bug CHART-1/3/4/5 have each found before in this kit). Fixed by spreading `defaults` before `axis` in the per-axis merge (caller's own explicit `scaleType`, if any, still wins); a new regression test added (`tests/chartDefaults.test.js`, "keeps the default scaleType on a caller-supplied axis that does not set one"), confirmed against both `BarChart`'s `'band'` and `LineChart`'s `'point'` defaults. Re-verified after all three fixes: 44/44 scoped vitest tests green (10 new + 34 existing adjacent chart tests, no regressions), `tsc -p tsconfig.build.json --noEmit` clean. **Two-width rendered side-by-side (DS-1 gate)** run in the dev harness's "Theme / Shared baseline" entry (which now also carries the two new `LineChart` chart-chrome specimens per the WO's "at least one chart that set the props and one that did not" requirement) at 375px and 1280px — confirmed live: correct line rendering (post-fix), filled markers on the caller-override chart, horizontal grid, bottom-start vs. caller-chosen legend position, and rotated tick labels with adequate margin at 1280px. |
 | THEME-1 | Shared MUI theme baseline: `createAppTheme` factory + completeness assertion | Ships `createAppTheme(appConfig)` (palette-first merge of a fixed light-mode baseline with the app's own `palette`/`typography`/`components`; throws without `palette.primary`; throws on a function anywhere in `appConfig.components.*.styleOverrides`), an exported `assertThemeComplete` completeness assertion with an exemption arm and contrast checks (status text-on-own-tint, `controlBorder` on white + page background), a non-breaking chart-ramp fallback in `useNeutralChartPalette` (adopters get the theme's `dataSeries` ramp, non-adopters see byte-identical output), a new "Shared theme baseline" dev-harness entry, and `DESIGN.md` principles 1/8 reworded per the accepted policy change (ucm now ships a shared theme; the data-colour layer has a shared default). Full spec: [work-orders/THEME-1.md](work-orders/THEME-1.md). | 2026-08-10 | done | b329b39, 96992cf | Envelope authored by Expertenchat from the accepted reference sheet (`work-orders/assets/THEME-1-baseline-reference-sheet.html`, DS-2 decisions 1–23). Orchestrator filled the Implementation map, then ran Codex (stdin, not positional arg — the WO text exceeded Windows' command-line length limit via the npm shim, "Argument list too long"; `codex exec ... -` reading the WO from stdin is the working invocation for large WOs on this platform). Codex implemented `src/theme/{tokens,createAppTheme,themeCompleteness,index}.js`, wrote all 13 required tests + extended `tests/chartsPalette.test.js`, updated `src/index.js` exports, `DESIGN.md`, `package.json` (2.29.2→2.30.0, new `@fontsource/dm-sans` dependency — WO-scoped, no separate approval needed), and the dev harness. **Independent `reviewer` (Sonnet) + `ui_reviewer` (Haiku) ran concurrently. `ui_reviewer`: no findings.** `reviewer` found three, all confirmed real and fixed by the Orchestrator: **R1 (P2)** — MUI's `createTheme(options, ...args)` only runs palette augmentation on the FIRST argument; every later arg (how the baseline was layered in) is deep-merged raw, so `success`/`warning`/`error`/`info` — which had `text`/`fill`/`fillText`/`bg` but no `main`/`contrastText` — silently kept MUI's own stock hues for any standard `color="success"` usage. Verified live via a Node repro (`createTheme({...},{palette:BASELINE_PALETTE},{...})` on the pre-fix baseline produced `success.main:'#2e7d32'`, MUI's stock green, not the canonical `#1B8038`). Fixed: explicit `main`/`light`/`dark`/`contrastText` added to all four status channels (`light`/`dark` computed via MUI's own `lighten`/`darken` at the same 0.2/0.3 tonal offsets `augmentColor` uses), plus a new regression assertion in `tests/createAppTheme.test.js`. **R2 (P3)** — `controlBorder.focus` was derived to clear 3:1 only against `background.paper`, while `assertThemeComplete`'s own contrast check tests it against `#FFFFFF` and `background.default` — an app overriding either background could pass the derivation and still fail the assertion. Fixed: derivation now targets both surfaces. **R3 (P3)** — `MuiOutlinedInput`'s `variants` array was nested inside `styleOverrides.root` instead of as a sibling key; MUI never reads `variants` from inside `styleOverrides` (it's matched by `props` independently), so the entry was inert dead code, and it also meant the function-in-`styleOverrides` guard's own suggested escape hatch ("use MUI variants") was structurally unreachable from inside `styleOverrides`. Fixed: moved to the correct sibling placement; updated the one test and the one completeness-surface path that referenced the old (wrong) location. Re-verified after fixes: 15/15 scoped vitest tests green (`tests/createAppTheme.test.js`, `tests/themeCompleteness.test.js`, `tests/chartsPalette.test.js`), `tsc -p tsconfig.build.json --noEmit` clean. Orchestrator's own security/scope pass: no findings (only the WO-approved `@fontsource/dm-sans` dependency addition, no secrets, no scope creep). **Two-width rendered side-by-side (DS-1 gate)** run in the dev harness's new "Theme / Shared baseline" entry at 375px and 1280px — both screenshots confirm radius (3/8), no resting shadow on Paper/Card, correct status fill/text/bg tones, and the six-colour series ramp, consistent with the reference sheet. No app pin bumps in this WO — all 14 consumers pin exact versions and pick this up on their own adoption WO. |
 | CHART-5 | Dual y-axis + always-visible x-axis ticks on `TimeSeriesChart` | Opt-in second y-axis via a new per-series `axis: 'secondary'` field (backward-compatible, off by default) with auto-detected integer-only tick labels per axis group; deterministic x-axis `tickLabelInterval` so bucket labels never all vanish under MUI's default collision-avoidance (the live symptom: zero x-axis labels with 24 hourly buckets). Reverses CHART-2's deliberate "no second y-axis" choice on fresh operator instruction; `DESIGN.md` #8 updated to record the scoped exception. Full spec: [work-orders/CHART-5.md](work-orders/CHART-5.md). | 2026-08-07 | done | 839e6c5, 84c37ac, 0dd3bac, f4e5586, 4a12a71 | Operator-requested after seeing the shipped chart live: y-axis showed decimal ticks (0.2, 0.4, ...) for an integer user-count series sharing an axis with fractional hours; x-axis showed no time labels at all. **Codex out of credits, known up front** — implemented directly (author-flip, independent review mandatory). Independent `reviewer` + `ui_reviewer` ran concurrently: **`reviewer` found R1 (P1, real bug)** — used `yAxisKey` (removed in MUI X-Charts v7, per the installed v8.29.2's own CHANGELOG and `useBarPlotData.mjs` source, which reads `series[i].yAxisId`) instead of `yAxisId`; the WO explicitly asked to verify this passthrough against real MUI behaviour rather than assume, and the first pass didn't — the dual-axis feature would have silently plotted every series on the primary axis in production despite all mocked tests passing (a mocked-prop test structurally cannot catch a wrong-field-name bug, since it only checks whatever the code itself sets). Fixed (`yAxisKey` → `yAxisId`, verified against `node_modules` source directly, not just the mock) and the pre-existing `tests/BarChart.test.jsx` "dual axis" case corrected too (R2 — it used the same wrong field name and was cited by the WO as precedent, giving false confidence). **`ui_reviewer` found U1 (P1, real bug)** — `tickLabelInterval`'s `index % step === 0` systematically dropped the LAST x-axis bucket unless it landed exactly on a step boundary (e.g. 24 labels/step 3 → indices 0..21, never 23), exactly the failure mode the WO's own SCOPE C explicitly warned to check for; fixed by force-including `index === lastIndex`, with a new `it.each([24,12,7,1])` regression test, confirmed non-vacuous by reverting the fix. **U2 (P2)**: `DESIGN.md` #8's "Never dual-axis" now contradicted the shipped code — updated to record dual-axis as a scoped, opt-in exception (CHART-5) rather than a general rule change. U3 (P3, fixed `MAX_X_TICKS` under-displays low-density ranges e.g. 12 monthly buckets showing only 6) and U4 (P3, no UI indication of which axis a toggle's series plots against) both accepted, not fixed — informational, no code change. Re-verified after fixes: 31/31 scoped vitest tests (`TimeSeriesChart.test.jsx` + `BarChart.test.jsx`) green, `tsc` build clean. Published: ucm 2.29.0 (minor — new optional per-series field + prop, additive, no breaking change). **Third bug found post-publish (2.29.1 patch)**: after jg-ferien adopted it (ACT-7) the operator reported live that the secondary axis was "obviously there but invisible" and x-axis labels were still missing. Investigated by adding a new DX-1 harness entry (`dev/entries.jsx` `TimeSeriesChartEntry`, previously missing — this component had NEVER been visually verified in a real browser through CHART-2/3/4/5) and reading the real rendered DOM directly. X-axis confirmed working (9 evenly-spread labels for 24 buckets) — the live report was very likely a stale PWA service-worker cache on jg-ferien's side, not a code defect. Y-axis confirmed broken: only 1 of 2 `yAxis` entries rendered in the DOM. Root cause traced to the installed MUI X-Charts source (`defaultizeAxis.js`): `defaultPosition = index === 0 ? 'left' : 'none'` — every yAxis array entry past the first silently renders nothing unless given an explicit `position`, a class of bug no mocked-`BarChart` test can catch (the mock never runs MUI's own defaulting logic). Fixed by setting `position: 'left'`/`'right'` explicitly on the primary/secondary entries; independent `reviewer` traced the fix against the same MUI source and confirmed no second gating layer exists. Live-reverified in the dev harness after the fix: both axes render with independent scales (primary `0,1,2`; secondary `0.0,0.5,1.0,1.5,2.0`). 32/32 tests green, build clean. Published: ucm 2.29.1 (patch). **Fourth report, root cause NOT in ucm**: operator reported x-axis labels still empty even after 2.29.1. Extensive live investigation (scoped DOM queries, computed-style checks, a real-browser-DOM comparison against this repo's own dev harness in both dev and production-build mode, a DM-Sans-not-loaded font test) could not reproduce it anywhere in ucm with the exact real bucket data — ruled out: stale cache, MUI axis config, container width, dev-vs-prod build, font-loading timing. Root cause found via web search: a known, unfixed upstream MUI X-Charts bug (mui/mui-x#18768, duplicate of #18399) where insufficient measured space makes its `ellipsize` logic collapse an ENTIRE tick label to `''` instead of shortening it, confirmed live via a `<tspan>` with correct styling but zero text content — triggered by jg-ferien's verbose label format ("08/05, 10:00 AM", 16 chars) combined with its actual DM Sans font metrics (not reproducible with this repo's default Roboto-based harness). Fixed in jg-ferien (ACT-9: short, granularity-aware labels), not in ucm — `TimeSeriesChart` itself has no defect here, it's a host-side label-length choice interacting with an upstream MUI bug. This repo's DX-1 harness entry (`TimeSeriesChartEntry`) updated to model the correct short-label pattern so it doesn't teach the risky verbose format. |
@@ -57,5 +58,3 @@ prefixed ID; never reuse a bare flat number across workstreams.
 | AUTH-2 | Translate backend auth error codes (stop leaking raw codes) | ucm surfaces raw backend/allauth error **codes**, not text: `apiClient.jsx:107` extracts `err.code`, components do `t(err.code)`/`setErrorKey(err.code)`, but the catalogue has no entries → users see literal `email_password_mismatch` / `password_too_short`. Affects **all** rendering auth screens (login/change-pw/MFA/profile). Fix = add de/fr/en i18n entries **keyed by the enumerated codes** → the existing `t(err.code)` resolves, **zero component/app change**. Does NOT reach the delegating invitation `PasswordSetForm` (that's AUTH-1). Full spec: [work-orders/AUTH-2.md](work-orders/AUTH-2.md). | 2026-08-06 | done | 84387cf, 103a252 | Tier 2 (shared-core). Same Codex→Claude fallback and reviewer pairing as AUTH-1 (one combined diff, both WOs landed together). **Keying decided: raw-code (drop-in)**, per the WO's own stated preference — no operator request for the namespaced `i18nKey` alternative. **Codes enumerated by reading the installed allauth/Django source directly** (not guessed): `email_password_mismatch`/`username_password_mismatch`/`phone_password_mismatch` (`allauth/headless/account/inputs.py` `LoginInput.clean`), `too_many_login_attempts`/`invalid_login`/`account_inactive`/`enter_current_password` (`allauth/account/adapter.py` error_messages + `allauth/headless/account/inputs.py` `ChangePasswordInput.clean_current_password` — confirmed this genuinely means "wrong current password", not merely "field left blank"), `incorrect_code` (`allauth/mfa/**`), `password_too_short`/`password_too_common`/`password_entirely_numeric`/`password_too_similar` (Django `contrib/auth/password_validation.py`, matching dcm's `AUTH_PASSWORD_VALIDATORS` baseline). Added de/fr/en/**sw** (file's established 4-locale convention, honoured over the WO text's literal "de/fr/en"). **`ui_reviewer` + `reviewer`: no AUTH-2-specific findings** (both spot-checked the code spellings independently against the same installed packages; no key collisions with existing `Auth.*` keys; `authErrorCodeRendering.test.jsx` proves a mapped code renders human text via a real i18next instance and a genuinely-uncoded error still falls back to the existing generic `Auth.PASSWORD_CHANGE_FAILED`). Gate: shared with AUTH-1 — full suite 322/322, `tsc` clean. **Published version correction**: see AUTH-1's row — the 2.28.0 tag was skipped by a CI runner backlog and never published; verified present in the npm tarball from **2.28.1** onward (currently 2.29.1). Companion: AUTH-1. |
 | AUTH-3 | SignUpPage showed the access-code-specific success message for every signup mode | Operator-observed live bug 2026-08-07: open self-registration (no access code) showed "Falls der Zugangscode für dieses Projekt gültig ist, wurde ein Einladungslink an X gesendet" — nonsensical when there is no code at all. Root cause: `SignUpPage.jsx`'s `handleSubmit` hardcoded `Auth.INVITE_REQUEST_SUCCESS` for every mode (open/access-code/email-domain/QR) regardless of the backend's actual response. | 2026-08-07 | done | 599e73d, b4e1fe7 | No WO file — operator-reported bug, fixed directly, same convention as MSG-6c/MSG-6d/MSG-6j. Tier 2 (shared-core). **Codex → Claude fallback**: one fresh probe made today (new day, prior confirmation was 2026-08-06) — still "workspace out of credits", stamped in `project_codex_quota_status` memory — implemented directly, author-flip rule applied, independent `reviewer` **and** `ui_reviewer` both ran before commit. **Root cause confirmed against the actual backend** (`django-core-micha` `register_request` view + `validate_access_code_or_error`): every signup mode's success response already carries a mode-agnostic, accurate `code: "Auth.INVITE_SENT"`; an invalid access code is never silently accepted, it raises a distinct 400 (`Auth.ACCESS_CODE_INVALID_OR_INACTIVE`) — so the old key's "if valid…" ambiguity never matched backend reality for any mode, not just the ones reported. Fix: `setSuccessKey(res?.code || 'Auth.INVITE_SENT')`, using the backend's own code; no component/app change beyond this. **Both reviewers independently flagged the same P3**: switching away from the old key silently dropped the `{{email}}` confirmation (`Auth.INVITE_SENT` had none). Fixed before commit — extended `Auth.INVITE_SENT`'s text to include `{{email}}` in all 4 locales (safe: it had exactly one consumer, this call site, confirmed by grep). `Auth.INVITE_REQUEST_SUCCESS` is now dead/orphaned (both reviewers flagged as P3, tracked here, not removed — out of this fix's scope). Gate: `tests/SignUpPage.test.jsx` 13/13 (3 new, proving the backend code wins over the old hardcoded key, and the no-code fallback); full suite 342/342, `tsc` clean. |
 | SHELL-2 | AccountPage: from a horizontal tab strip to a grouped sidebar + mobile drawer | Measured live at 375 px on 2026-08-08 (running cockpit, host header neutralised so the numbers describe ucm alone): `AccountPage` does **not** break the layout -- all six sections render at document width 375. What fails is discoverability and the users table. The tab strip scroller is 343 px visible against 589 px of content with `overflow-x: auto`, 246 px of travel, and **`scrollButtons: 0`** -- Support and any consumer-injected section sit off screen with no arrow, no fade, no hint they exist (they do respond to a horizontal swipe, so this is a discoverability failure, not a reachability one -- unlike cockpit's own header tabs, which are `width: 0px` + `overflow: hidden` and genuinely unreachable). The users table renders 1045 px inside a 341 px `MuiTableContainer`; one third is visible and the `Aktionen` column sits ~700 px to the right. Adopts jg-ferien's `EventInfoPage` pattern (`SectionSwitcher.jsx`, driven from `EventInfoPage.jsx:1126-1159`) in **both** halves -- sticky grouped 280 px sidebar at `md`+, bottom drawer below `md` -- plus an in-page trigger bar, which the reference does not supply because jg's trigger lives in that app's own page header and `AccountPage` has none. | 2026-08-08 | blocked | | **Held back 2026-08-08 — reshaped into DS-11** (see `webapp-management/DESIGN_SYSTEM_PROGRAM.md`): do NOT implement this WO as written; the Envelope will be revised (open: keep the SHELL-2 ID or mint a new SHELL-* ID). Known corrections for the revision: publishing is version-gated, not per-push (this row's "publishes immediately" is imprecise), and the grouped-shell part becomes an inheritable ucm component with `AccountPage` as first consumer. Envelope: [work-orders/SHELL-2.md](work-orders/SHELL-2.md). Prototype: [work-orders/assets/SHELL-2-account-navigation.html](work-orders/assets/SHELL-2-account-navigation.html). Tier 2 (shared core) -- independent `reviewer` (Sonnet, full) **and** `ui_reviewer` concurrently, both mandatory before commit. **Operator decisions, settled 2026-08-08 and not to be renegotiated by implementer or reviewer:** both halves of the pattern, so the horizontal tab strip disappears **on desktop too** (asked explicitly, chosen deliberately, in full knowledge that 14 consumers inherit the desktop change on their next pin bump); fixed groups `Mein Konto` / `Verwaltung` / `Hilfe` / `Weitere`, with `extraTabs` gaining an **optional** `group` field, additive and backward compatible; no standalone "Uebersicht" entry above the groups (jg-ferien has one, `AccountPage` has no overview screen for it to point at, so none is invented); users table becomes a card list below `md` and stays a table at `md`+; the mobile trigger bar is the **sole** carrier of the current section name, so the section heading below it is **removed**, not merely undrawn -- desktop keeps its heading because it has no trigger bar. **Two contracts that must survive and are currently untested:** the `?tab=` URL contract incl. fallback to `profile` on an unknown *or* unpermitted value (`AccountPage.jsx:60`, `:180-186`) -- cockpit's `/user-management`, `/profile` and `/change-password` redirects all hang off it -- and the full `extraTabs` shape (`:146-155`), whose `label` may be a **function** and which supports `visible(context)`. `AccountPage` and `UserListComponent` have **zero tests today** (none of the 20 files under `tests/` touches either), so both test files are new, not extensions. **No staging net:** this repo has no `develop`; a push to `main` touching `src/**` or `package.json` publishes to npm immediately via `publish.yml`, so the independent review is the only gate and is not back-fillable. Version target `2.30.0` (minor -- `extraTabs` gains a public field; additive API is a minor under semver). Explicit non-goals: pagination/filtering for the user list, the sections' internal content, the six auth pages (measured clean at 375 px), and **cockpit's header** -- that toolbar is what inflates the document to 498 px on every route including `/account`, and it is a separate WO in the cockpit repo, sequenced after this one at the operator's choice. Carried-over trap from the reference: jg-ferien uses `env(safe-area-inset-bottom)` while its `index.html` omits `viewport-fit=cover`, so those insets resolve to zero there -- copy the padding, do not assume it does anything. |
-| THEME-1 | Shared MUI theme baseline: `createAppTheme` factory + completeness assertion | Every app theme sets a handful of values and leaves the rest at MUI's defaults, so implementations drift toward Material Design 2014 (uppercase buttons, 20px h6, 16px body, elevation shadows). The baseline was distilled from 13 prototype artifacts across 5 repos plus 5 app themes, and settled with the operator over two review rounds against a rendered reference sheet. | 2026-08-09 | planned | | Reference sheet (visual + token spec, live WCAG contrast checks): [work-orders/assets/THEME-1-baseline-reference-sheet.html](work-orders/assets/THEME-1-baseline-reference-sheet.html). Its canonical token table is the value source — the Envelope references it rather than restating the numbers. Envelope: [work-orders/THEME-1.md](work-orders/THEME-1.md) (authored 2026-08-10, Approval Gate #1 pending). Version target 2.30.0; DS-4 follows as 2.31.0. Program context: `webapp-management/DESIGN_SYSTEM_PROGRAM.md` (DS-2). |
-| CHART-6 | Chart-chrome defaults in the three wrappers + the two generic fixes hoisted up | The kit's `LineChart`/`BarChart`/`TimeSeriesChart` are ~18 lines of logic each and set no tick font, grid, margin or marker styling, so MUI X-Charts' own visual language shows through untouched. Hand discipline does not close it: hram, the exemplar, sets `tickLabelStyle.fontSize` at only 4 of 9 call sites. Also resolves `TimeSeriesChart`'s double legend and hoists fitness-monitor's label-collapse workaround (two consumers) plus `yearTickInterval`. | 2026-08-10 | planned | | Envelope: [work-orders/CHART-6.md](work-orders/CHART-6.md) (Approval Gate #1 pending). **Hard precondition: THEME-1 must land and publish as 2.30.0 first** — both touch `src/index.js` and `src/components/charts/`, and this repo publishes on every push. Version target 2.31.0. Legend auto-placement is deliberately out of scope (own strand — the in-plot overlay path is unverified in X-Charts 8.28.2). Program context: `webapp-management/DESIGN_SYSTEM_PROGRAM.md` (DS-4). |

package/dev/entries.jsx

@@ -77,6 +77,8 @@ function StatusChip({ label, tone }) {
   );
 }
 
+const MUI_STATUS_TONES = ['success', 'warning', 'error', 'info'];
+
 function ThemeBaselineEntry() {
   return (
     <Stack spacing={3}>
@@ -120,6 +122,25 @@ function ThemeBaselineEntry() {
         <StatusChip label="Stale" tone="stale" />
       </Stack>
 
+      <Stack spacing={1}>
+        <Typography variant="subtitle2">MUI status colours using palette main</Typography>
+        <Stack direction="row" spacing={1} useFlexGap flexWrap="wrap">
+          {MUI_STATUS_TONES.map((tone) => (
+            <Button key={tone} color={tone} variant="contained">{tone}</Button>
+          ))}
+        </Stack>
+        <Stack direction="row" spacing={1} useFlexGap flexWrap="wrap">
+          {MUI_STATUS_TONES.map((tone) => (
+            <Chip key={tone} color={tone} label={tone} />
+          ))}
+        </Stack>
+        <Stack direction="row" spacing={1} useFlexGap flexWrap="wrap">
+          {MUI_STATUS_TONES.map((tone) => (
+            <Alert key={tone} severity={tone} variant="filled">{tone}</Alert>
+          ))}
+        </Stack>
+      </Stack>
+
       <Stack direction="column" spacing={2} alignItems="flex-start" sx={{ '@container (min-width: 900px)': { flexDirection: 'row' } }}>
         <TextField label="Project name" defaultValue="Baseline harness" fullWidth />
         <FormControl fullWidth>
@@ -196,7 +217,7 @@ function ThemeBaselineEntry() {
             ]}
             xAxisLabel="Month"
             yAxisLabel="Cases"
-            grid={{ horizontal: true, vertical: true }}
+            grid={{ vertical: true }}
             legendPosition={{ vertical: 'top', horizontal: 'end' }}
             height={320}
           />

package/dist/components/charts/BarChart.js

@@ -15,13 +15,13 @@ import { Box } from '@mui/material';
 import { useTheme } from '@mui/material/styles';
 import { BarChart as MuiBarChart } from '@mui/x-charts/BarChart';
 import { useNeutralChartPalette } from './palette';
-import { DEFAULT_LEGEND_POSITION, spaceForRotatedTicks, withAxisDefaults, withChartSlotDefaults, } from './chartDefaults';
+import { DEFAULT_LEGEND_POSITION, spaceForRotatedTicks, withAxisDefaults, withChartSlotDefaults, withGridDefaults, } from './chartDefaults';
 /**
  * Responsive MUI X-Charts bar preset. xAxisLabel and yAxisLabel (including units) are required.
  * It supplies labelled axes, tooltips, and an automatic multi-series legend.
  */
 export function BarChart(_a) {
-    var { series = [], xAxisLabel, yAxisLabel, xAxis, yAxis, palette, minHeight, aspect, grid = { horizontal: true }, hideLegend = series.length <= 1, legendPosition = DEFAULT_LEGEND_POSITION, margin, slotProps } = _a, chartProps = __rest(_a, ["series", "xAxisLabel", "yAxisLabel", "xAxis", "yAxis", "palette", "minHeight", "aspect", "grid", "hideLegend", "legendPosition", "margin", "slotProps"]);
+    var { series = [], xAxisLabel, yAxisLabel, xAxis, yAxis, palette, minHeight, aspect, grid, hideLegend = series.length <= 1, legendPosition = DEFAULT_LEGEND_POSITION, margin, slotProps } = _a, chartProps = __rest(_a, ["series", "xAxisLabel", "yAxisLabel", "xAxis", "yAxis", "palette", "minHeight", "aspect", "grid", "hideLegend", "legendPosition", "margin", "slotProps"]);
     const theme = useTheme();
     const neutralPalette = useNeutralChartPalette();
     if (!xAxisLabel || !yAxisLabel) {
@@ -30,5 +30,5 @@ export function BarChart(_a) {
     const labelledXAxis = withAxisDefaults(xAxis, xAxisLabel, { scaleType: 'band', data: [] }, theme.typography.caption.fontSize);
     const labelledYAxis = withAxisDefaults(yAxis, yAxisLabel, { scaleType: 'linear' }, theme.typography.caption.fontSize);
     const rotatedTickSpace = spaceForRotatedTicks(labelledXAxis, margin, theme.typography.caption.lineHeight);
-    return (_jsx(Box, { "data-testid": "bar-chart-container", sx: { width: '100%', minHeight, aspectRatio: aspect }, children: _jsx(MuiBarChart, Object.assign({}, chartProps, { series: series, xAxis: rotatedTickSpace.xAxis, yAxis: labelledYAxis, colors: palette || neutralPalette.categorical, grid: grid, hideLegend: hideLegend, margin: rotatedTickSpace.margin, slotProps: withChartSlotDefaults(slotProps, legendPosition) })) }));
+    return (_jsx(Box, { "data-testid": "bar-chart-container", sx: { width: '100%', minHeight, aspectRatio: aspect }, children: _jsx(MuiBarChart, Object.assign({}, chartProps, { series: series, xAxis: rotatedTickSpace.xAxis, yAxis: labelledYAxis, colors: palette || neutralPalette.categorical, grid: withGridDefaults(grid), hideLegend: hideLegend, margin: rotatedTickSpace.margin, slotProps: withChartSlotDefaults(slotProps, legendPosition) })) }));
 }

package/dist/components/charts/LineChart.js

@@ -15,7 +15,7 @@ import { Box } from '@mui/material';
 import { useTheme } from '@mui/material/styles';
 import { LineChart as MuiLineChart, MarkElement as MuiMarkElement, } from '@mui/x-charts/LineChart';
 import { useNeutralChartPalette } from './palette';
-import { DEFAULT_LEGEND_POSITION, spaceForRotatedTicks, withAxisDefaults, withChartSlotDefaults, } from './chartDefaults';
+import { DEFAULT_LEGEND_POSITION, spaceForRotatedTicks, withAxisDefaults, withChartSlotDefaults, withGridDefaults, } from './chartDefaults';
 // Fixes MUI's hollow `background.paper`-filled marker (MarkElement.js's own
 // `styled()` default). CHART-6's WO named a `MuiMarkElement` theme-token
 // override in src/theme/tokens.js as the preferred mechanism, with a
@@ -35,7 +35,7 @@ function FilledMarkElement(_a) {
  * It supplies labelled axes, tooltips, and an automatic multi-series legend.
  */
 export function LineChart(_a) {
-    var { series = [], xAxisLabel, yAxisLabel, xAxis, yAxis, palette, minHeight, aspect, grid = { horizontal: true }, hideLegend = series.length <= 1, legendPosition = DEFAULT_LEGEND_POSITION, margin, slots, slotProps } = _a, chartProps = __rest(_a, ["series", "xAxisLabel", "yAxisLabel", "xAxis", "yAxis", "palette", "minHeight", "aspect", "grid", "hideLegend", "legendPosition", "margin", "slots", "slotProps"]);
+    var { series = [], xAxisLabel, yAxisLabel, xAxis, yAxis, palette, minHeight, aspect, grid, hideLegend = series.length <= 1, legendPosition = DEFAULT_LEGEND_POSITION, margin, slots, slotProps } = _a, chartProps = __rest(_a, ["series", "xAxisLabel", "yAxisLabel", "xAxis", "yAxis", "palette", "minHeight", "aspect", "grid", "hideLegend", "legendPosition", "margin", "slots", "slotProps"]);
     const theme = useTheme();
     const neutralPalette = useNeutralChartPalette();
     if (!xAxisLabel || !yAxisLabel) {
@@ -45,5 +45,5 @@ export function LineChart(_a) {
     const labelledYAxis = withAxisDefaults(yAxis, yAxisLabel, { scaleType: 'linear' }, theme.typography.caption.fontSize);
     const rotatedTickSpace = spaceForRotatedTicks(labelledXAxis, margin, theme.typography.caption.lineHeight);
     const defaultedSeries = series.map((item) => (Object.assign({ showMark: false, labelMarkType: 'square' }, item)));
-    return (_jsx(Box, { "data-testid": "line-chart-container", sx: { width: '100%', minHeight, aspectRatio: aspect }, children: _jsx(MuiLineChart, Object.assign({}, chartProps, { series: defaultedSeries, xAxis: rotatedTickSpace.xAxis, yAxis: labelledYAxis, colors: palette || neutralPalette.categorical, grid: grid, hideLegend: hideLegend, margin: rotatedTickSpace.margin, slots: Object.assign({ mark: FilledMarkElement }, slots), slotProps: withChartSlotDefaults(slotProps, legendPosition) })) }));
+    return (_jsx(Box, { "data-testid": "line-chart-container", sx: { width: '100%', minHeight, aspectRatio: aspect }, children: _jsx(MuiLineChart, Object.assign({}, chartProps, { series: defaultedSeries, xAxis: rotatedTickSpace.xAxis, yAxis: labelledYAxis, colors: palette || neutralPalette.categorical, grid: withGridDefaults(grid), hideLegend: hideLegend, margin: rotatedTickSpace.margin, slots: Object.assign({ mark: FilledMarkElement }, slots), slotProps: withChartSlotDefaults(slotProps, legendPosition) })) }));
 }

package/dist/components/charts/chartDefaults.js

@@ -2,6 +2,9 @@ export const DEFAULT_LEGEND_POSITION = {
     vertical: 'bottom',
     horizontal: 'start',
 };
+export function withGridDefaults(grid) {
+    return Object.assign({ horizontal: true }, grid);
+}
 export function withAxisDefaults(axes, label, defaults, tickFontSize) {
     const values = (axes === null || axes === void 0 ? void 0 : axes.length) ? axes : [defaults];
     return values.map((axis) => (Object.assign(Object.assign(Object.assign({}, defaults), axis), { tickLabelStyle: Object.assign({ fontSize: tickFontSize }, axis.tickLabelStyle), label: axis.label || label })));
@@ -76,5 +79,7 @@ export function spaceForRotatedTicks(xAxis, margin, defaultLineHeight = 1) {
     return { xAxis: spacedXAxis, margin: spacedMargin };
 }
 export function withChartSlotDefaults(slotProps, legendPosition) {
-    return Object.assign(Object.assign({}, slotProps), { tooltip: Object.assign({ trigger: 'axis' }, slotProps === null || slotProps === void 0 ? void 0 : slotProps.tooltip), legend: Object.assign({ position: legendPosition }, slotProps === null || slotProps === void 0 ? void 0 : slotProps.legend) });
+    var _a;
+    const position = Object.assign(Object.assign(Object.assign({}, DEFAULT_LEGEND_POSITION), legendPosition), (_a = slotProps === null || slotProps === void 0 ? void 0 : slotProps.legend) === null || _a === void 0 ? void 0 : _a.position);
+    return Object.assign(Object.assign({}, slotProps), { tooltip: Object.assign({ trigger: 'axis' }, slotProps === null || slotProps === void 0 ? void 0 : slotProps.tooltip), legend: Object.assign(Object.assign({}, slotProps === null || slotProps === void 0 ? void 0 : slotProps.legend), { position }) });
 }

package/dist/theme/themeCompleteness.js

@@ -219,7 +219,7 @@ export function calculateContrastRatio(foreground, background) {
     return (light + 0.05) / (dark + 0.05);
 }
 function contrastFindings(theme) {
-    var _a, _b, _c, _d, _e;
+    var _a, _b, _c, _d, _e, _f, _g;
     const findings = [];
     for (const status of STATUS_KEYS) {
         const tokens = (_a = theme.palette) === null || _a === void 0 ? void 0 : _a[status];
@@ -248,8 +248,24 @@ function contrastFindings(theme) {
         white: '#FFFFFF',
         page: (_c = (_b = theme.palette) === null || _b === void 0 ? void 0 : _b.background) === null || _c === void 0 ? void 0 : _c.default,
     };
+    for (const status of STATUS_KEYS) {
+        const main = (_e = (_d = theme.palette) === null || _d === void 0 ? void 0 : _d[status]) === null || _e === void 0 ? void 0 : _e.main;
+        if (!main)
+            continue;
+        for (const [surface, background] of Object.entries(backgrounds)) {
+            const ratio = calculateContrastRatio(main, background);
+            if (!Number.isFinite(ratio) || ratio < 4.5) {
+                findings.push({
+                    surface: `contrast.${status}.main-on-${surface}`,
+                    reason: Number.isFinite(ratio)
+                        ? `Expected at least 4.5:1; received ${ratio.toFixed(2)}:1.`
+                        : 'Contrast could not be calculated from the declared colours.',
+                });
+            }
+        }
+    }
     for (const state of ['main', 'hover', 'focus', 'error']) {
-        const colour = (_e = (_d = theme.palette) === null || _d === void 0 ? void 0 : _d.controlBorder) === null || _e === void 0 ? void 0 : _e[state];
+        const colour = (_g = (_f = theme.palette) === null || _f === void 0 ? void 0 : _f.controlBorder) === null || _g === void 0 ? void 0 : _g[state];
         if (!colour)
             continue;
         for (const [surface, background] of Object.entries(backgrounds)) {

package/dist/theme/tokens.js

@@ -62,7 +62,7 @@ export const BASELINE_PALETTE = {
         error: '#BF3227',
     },
     success: Object.assign(Object.assign({}, withMainShades('#1B8038', '#FFFFFF')), { text: '#35794A', fill: '#1B8038', fillText: '#FFFFFF', bg: '#E5F4E9' }),
-    warning: Object.assign(Object.assign({}, withMainShades('#C08A2C', '#212529')), { text: '#976100', fill: '#C08A2C', fillText: '#212529', bg: '#FBF0DC' }),
+    warning: Object.assign(Object.assign({}, withMainShades('#976100', '#FFFFFF')), { text: '#976100', fill: '#C08A2C', fillText: '#212529', bg: '#FBF0DC' }),
     error: Object.assign(Object.assign({}, withMainShades('#BF3227', '#FFFFFF')), { text: '#BF3227', fill: '#BF3227', fillText: '#FFFFFF', bg: '#FBEAE8' }),
     // The canonical sheet introduces no new info hue. These values reuse
     // MUI's own info.dark/main family while adding the shared status shape.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@micha.bigler/ui-core-micha",
-  "version": "2.31.0",
+  "version": "2.31.1",
   "main": "dist/index.js",
   "module": "dist/index.js",
   "repository": {

package/src/components/charts/BarChart.jsx

@@ -8,6 +8,7 @@ import {
   spaceForRotatedTicks,
   withAxisDefaults,
   withChartSlotDefaults,
+  withGridDefaults,
 } from './chartDefaults';
 
 /**
@@ -23,7 +24,7 @@ export function BarChart({
   palette,
   minHeight,
   aspect,
-  grid = { horizontal: true },
+  grid,
   hideLegend = series.length <= 1,
   legendPosition = DEFAULT_LEGEND_POSITION,
   margin,
@@ -62,7 +63,7 @@ export function BarChart({
         xAxis={rotatedTickSpace.xAxis}
         yAxis={labelledYAxis}
         colors={palette || neutralPalette.categorical}
-        grid={grid}
+        grid={withGridDefaults(grid)}
         hideLegend={hideLegend}
         margin={rotatedTickSpace.margin}
         slotProps={withChartSlotDefaults(slotProps, legendPosition)}

package/src/components/charts/LineChart.jsx

@@ -11,6 +11,7 @@ import {
   spaceForRotatedTicks,
   withAxisDefaults,
   withChartSlotDefaults,
+  withGridDefaults,
 } from './chartDefaults';
 
 // Fixes MUI's hollow `background.paper`-filled marker (MarkElement.js's own
@@ -40,7 +41,7 @@ export function LineChart({
   palette,
   minHeight,
   aspect,
-  grid = { horizontal: true },
+  grid,
   hideLegend = series.length <= 1,
   legendPosition = DEFAULT_LEGEND_POSITION,
   margin,
@@ -85,7 +86,7 @@ export function LineChart({
         xAxis={rotatedTickSpace.xAxis}
         yAxis={labelledYAxis}
         colors={palette || neutralPalette.categorical}
-        grid={grid}
+        grid={withGridDefaults(grid)}
         hideLegend={hideLegend}
         margin={rotatedTickSpace.margin}
         slots={{ mark: FilledMarkElement, ...slots }}

package/src/components/charts/chartDefaults.js

@@ -3,6 +3,10 @@ export const DEFAULT_LEGEND_POSITION = {
   horizontal: 'start',
 };
 
+export function withGridDefaults(grid) {
+  return { horizontal: true, ...grid };
+}
+
 export function withAxisDefaults(axes, label, defaults, tickFontSize) {
   const values = axes?.length ? axes : [defaults];
   return values.map((axis) => ({
@@ -97,6 +101,11 @@ export function spaceForRotatedTicks(xAxis, margin, defaultLineHeight = 1) {
 }
 
 export function withChartSlotDefaults(slotProps, legendPosition) {
+  const position = {
+    ...DEFAULT_LEGEND_POSITION,
+    ...legendPosition,
+    ...slotProps?.legend?.position,
+  };
   return {
     ...slotProps,
     tooltip: {
@@ -104,8 +113,8 @@ export function withChartSlotDefaults(slotProps, legendPosition) {
       ...slotProps?.tooltip,
     },
     legend: {
-      position: legendPosition,
       ...slotProps?.legend,
+      position,
     },
   };
 }

package/src/theme/themeCompleteness.js

@@ -275,6 +275,22 @@ function contrastFindings(theme) {
     white: '#FFFFFF',
     page: theme.palette?.background?.default,
   };
+  for (const status of STATUS_KEYS) {
+    const main = theme.palette?.[status]?.main;
+    if (!main) continue;
+    for (const [surface, background] of Object.entries(backgrounds)) {
+      const ratio = calculateContrastRatio(main, background);
+      if (!Number.isFinite(ratio) || ratio < 4.5) {
+        findings.push({
+          surface: `contrast.${status}.main-on-${surface}`,
+          reason: Number.isFinite(ratio)
+            ? `Expected at least 4.5:1; received ${ratio.toFixed(2)}:1.`
+            : 'Contrast could not be calculated from the declared colours.',
+        });
+      }
+    }
+  }
+
   for (const state of ['main', 'hover', 'focus', 'error']) {
     const colour = theme.palette?.controlBorder?.[state];
     if (!colour) continue;

package/src/theme/tokens.js

@@ -79,7 +79,7 @@ export const BASELINE_PALETTE = {
     bg: '#E5F4E9',
   },
   warning: {
-    ...withMainShades('#C08A2C', '#212529'),
+    ...withMainShades('#976100', '#FFFFFF'),
     text: '#976100',
     fill: '#C08A2C',
     fillText: '#212529',

package/tests/chartDefaults.test.js

@@ -121,6 +121,24 @@ describe('chart chrome defaults', () => {
     expect(props.slotProps.legend.position).toEqual(legendPosition);
   });
 
+  it('adds a caller-requested vertical grid to the default horizontal grid', () => {
+    renderLine({ grid: { vertical: true } });
+
+    expect(lineSpy.mock.calls.at(-1)[0].grid).toEqual({
+      horizontal: true,
+      vertical: true,
+    });
+  });
+
+  it('lets a caller switch off both grid directions explicitly', () => {
+    renderBar({ grid: { horizontal: false, vertical: false } });
+
+    expect(barSpy.mock.calls.at(-1)[0].grid).toEqual({
+      horizontal: false,
+      vertical: false,
+    });
+  });
+
   // Found live in the dev harness (not by this mocked test, which cannot
   // reproduce a real MUI scale computation): a caller-supplied xAxis with
   // `data` but no `scaleType` lost the wrapper's default scaleType entirely,
@@ -170,8 +188,21 @@ describe('chart chrome defaults', () => {
     });
 
     cleanup();
-    const requested = { vertical: 'middle', horizontal: 'end' };
+    const requested = { vertical: 'middle' };
     renderBar({ series: [{ data: [1] }, { data: [2] }], legendPosition: requested });
-    expect(barSpy.mock.calls.at(-1)[0].slotProps.legend.position).toEqual(requested);
+    expect(barSpy.mock.calls.at(-1)[0].slotProps.legend.position).toEqual({
+      vertical: 'middle',
+      horizontal: 'start',
+    });
+
+    cleanup();
+    renderBar({
+      series: [{ data: [1] }, { data: [2] }],
+      slotProps: { legend: { position: { horizontal: 'end' } } },
+    });
+    expect(barSpy.mock.calls.at(-1)[0].slotProps.legend.position).toEqual({
+      vertical: 'bottom',
+      horizontal: 'end',
+    });
   });
 });

package/tests/createAppTheme.test.js

@@ -17,11 +17,18 @@ describe('createAppTheme', () => {
     // MUI's createTheme(options, ...args) only augments the FIRST argument's
     // palette; every later arg is deep-merged raw, so a status entry missing
     // `main`/`contrastText` silently keeps MUI's stock hue for color="success"
-    // etc. -- main/contrastText must equal the canonical fill/fillText tones.
-    for (const status of ['success', 'warning', 'error', 'info']) {
+    // etc. -- main/contrastText must be explicitly set and clear AA as a
+    // foreground (THEME-2: `warning` deliberately breaks the main===fill
+    // pattern success/error/info follow -- amber cannot serve both a legible
+    // fill AND a legible foreground with one hex, so `warning.main` is the
+    // darker `text` tone instead, `warning.fill` stays the lighter amber for
+    // deliberate fill use).
+    for (const status of ['success', 'error', 'info']) {
       expect(theme.palette[status].main).toBe(theme.palette[status].fill);
       expect(theme.palette[status].contrastText).toBe(theme.palette[status].fillText);
     }
+    expect(theme.palette.warning.main).toBe(theme.palette.warning.text);
+    expect(theme.palette.warning.contrastText).toBe('#FFFFFF');
   });
 
   it('throws when palette.primary is missing', () => {

package/tests/themeCompleteness.test.js

@@ -60,4 +60,35 @@ describe('theme completeness', () => {
     expect(assertThemeComplete(theme).findings.map(({ surface }) => surface))
       .toContain('contrast.success.text-on-bg');
   });
+
+  it('requires every MUI status main to clear AA on white and the page background', () => {
+    const theme = createAppTheme({ palette: { primary: { main: '#8AB4F8' } } });
+
+    for (const status of ['success', 'warning', 'error', 'info']) {
+      expect(calculateContrastRatio(theme.palette[status].main, '#FFFFFF')).toBeGreaterThanOrEqual(4.5);
+      expect(calculateContrastRatio(
+        theme.palette[status].main,
+        theme.palette.background.default,
+      )).toBeGreaterThanOrEqual(4.5);
+    }
+
+    theme.palette.warning.main = '#C08A2C';
+    expect(assertThemeComplete(theme).findings.map(({ surface }) => surface)).toEqual(
+      expect.arrayContaining([
+        'contrast.warning.main-on-white',
+        'contrast.warning.main-on-page',
+      ]),
+    );
+  });
+
+  it('reports main contrast findings without hard-failing for a non-adopting app theme', () => {
+    const result = assertThemeComplete(createTheme());
+
+    expect(result.findings.map(({ surface }) => surface)).toEqual(
+      expect.arrayContaining([
+        'contrast.warning.main-on-white',
+        'contrast.warning.main-on-page',
+      ]),
+    );
+  });
 });

package/work-orders/THEME-2.md

@@ -0,0 +1,339 @@
+# THEME-2 — Two defects from the THEME-1/CHART-6 landings: `warning.main` contrast, and `grid` replacing instead of merging
+
+**Target repo:** `ui-core-micha` (branch `main` — this repo has no `develop`)
+**Tier:** 2 (shared core — `ui-core-micha` is named in AGENTS.md's Tier-2 forcing list)
+**Review:** independent `reviewer` **and** `ui_reviewer` — spawned concurrently, both mandatory before commit
+**Version target:** `2.31.1` (patch — one palette value corrected, one merge bug fixed, one assertion rule added; no API change)
+**Decision record:** `webapp-management/DESIGN_SYSTEM_PROGRAM.md` → "Open follow-ups from the two landings"
+
+Short-form WO: both defects are fully diagnosed and measured. There is no design question in either.
+
+---
+
+## A. Envelope
+
+### Goal
+
+Fix the two defects found after `THEME-1` (`96992cf`) and `CHART-6` (`6dedc62`) landed, and in each
+case close the **mechanism** rather than only the instance — both are the same failure class as
+something already fixed, which is why they recurred.
+
+### Defect 1 — `warning.main` fails AA as a foreground
+
+THEME-1's R1 fix gave every status channel an explicit `main`/`light`/`dark`/`contrastText` (correct
+— MUI was otherwise filling its stock hues for `color="success"` and friends). It put the **fill**
+tone in `main`. Measured against `#FFFFFF`:
+
+| Channel | `main` | as foreground | |
+|---|---|---|---|
+| success | `#1B8038` | 5.010 | passes |
+| error | `#BF3227` | 5.674 | passes |
+| **warning** | `#C08A2C` | **3.038** | **fails AA (4.5)** |
+
+`main`/`contrastText` pairs are all fine (warning 5.078 with dark ink). The failure is only when
+`main` is used as a **foreground on a light surface** — `<Typography color="warning.main">`,
+`color="warning"` on an icon, and an outlined warning chip, whose border and label both come from
+`main`.
+
+**Why warning specifically, and why this is not carelessness:** green and red can serve both roles
+with one value. Amber cannot. A legible amber **fill** needs dark text on it and must therefore stay
+light; a legible amber **text** must be dark. The two requirements pull in opposite directions.
+Warning is the one channel where "one hex for both roles" is impossible in principle — so the
+pattern that works for success and error had to break here.
+
+**Fix:** `warning.main` = `#976100` (the text tone already in the same token block, 5.216 on white),
+`contrastText` = `#FFFFFF`. The light amber stays available as `warning.fill` for deliberate fill
+use, unchanged.
+
+**Accepted visual consequence, stated so nobody treats it as a regression:** a filled
+`color="warning"` Button/Chip becomes a darker brown with white text instead of a lighter amber with
+dark text. That is the price of one token serving MUI's `main` contract, and it is the operator's
+call already recorded in the programme doc.
+
+**Close the mechanism, not just the value:** add an assertion rule that checks **every** status
+channel's `main` against `#FFFFFF` and `background.default` at 4.5:1. Without it the next channel
+added repeats this exactly — the existing contrast checks were designed before R1 introduced `main`,
+which is why they did not catch it.
+
+### Defect 2 — `grid` is replaced, not merged
+
+`LineChart` and `BarChart` declare `grid = { horizontal: true }` as a plain default parameter and
+pass it straight through. A caller writing `grid={{ vertical: true }}` — intending to *add* vertical
+lines — silently loses the horizontal ones.
+
+This is the same class as the `scaleType` bug the rendered gate caught during CHART-6: **a partial
+caller object erases a default.** `xAxis`, `yAxis`, `margin` and `slotProps` all go through merge
+helpers; `grid` alone does not.
+
+**Fix:** merge `grid` with the default the way the sibling props already do, so a caller adds to it
+rather than replacing it.
+
+**Close the mechanism:** audit the remaining object-valued props the wrappers default or forward
+(`slots`, `tickLabelStyle` and anything CHART-6 introduced) for the same replace-instead-of-merge
+shape, and state the result — either "all others already merge" or a named list. **Audit and report;
+do not refactor beyond `grid`** unless the audit finds another live instance, in which case fix that
+too and say so.
+
+### Non-goals / do not touch
+
+- The other status channels' `main` values — success and error measure fine and stay.
+- `warning.fill` / `warning.text` / `warning.bg` — unchanged.
+- The reference sheet's committed HTML artifact. It is the frozen spec of the accepted baseline;
+  `warning.main` is a channel the sheet never depicted (see Verification).
+- Anything in `CHART-6`'s scope beyond the `grid` merge and the audit.
+- No behaviour, permission or data-contract change.
+
+### Risks
+
+- **A palette value change is visible.** Any app already using `color="warning"` sees a darker
+  filled control. No app has an adoption WO yet, so the blast radius today is ucm's own harness — but
+  say it in the release note rather than let someone find it.
+- **Adding an assertion rule can turn a green suite red.** Safe today by the ratchet: the
+  completeness check is a hard failure only for an app whose adoption WO has landed, and none has.
+  It must stay that way — the new rule must not become hard for non-adopters.
+- **No staging net.** A push to `main` touching `src/**` publishes to npm at once; the independent
+  review is the only gate and is not back-fillable.
+- **The `grid` merge changes behaviour for any caller who passes a partial `grid` today.** That is
+  the point, but it means the rendered check should look at a chart that passes `grid` explicitly if
+  one exists.
+
+### Required tests to WRITE
+
+Narrow. Extend the existing files rather than adding new ones.
+
+**`tests/themeCompleteness.test.js`**
+
+1. Every status channel's `main` clears 4.5:1 against `#FFFFFF` **and** against
+   `background.default`. **Prove non-vacuity** by restoring `warning.main` to `#C08A2C` and
+   confirming this test fails — that is the whole point of the rule.
+2. The new rule reports, and does not hard-fail, for a theme belonging to an app without a landed
+   adoption WO (the ratchet stays intact).
+
+**`tests/chartDefaults.test.js`**
+
+3. A caller passing `grid={{ vertical: true }}` receives **both** `vertical: true` and the default
+   `horizontal: true`. **Prove non-vacuity** by reverting to the plain default parameter and
+   confirming the test fails.
+4. A caller passing `grid={false}` (or the documented way to switch the grid off entirely) still
+   gets no grid — merging must not make the default un-removable.
+
+Plus `tsc -p tsconfig.build.json --noEmit` clean.
+
+**No full-suite run.** Affected-areas set is the two test files above.
+
+### Verification
+
+- The rendered two-width side-by-side per DS-1, **and this time it must cover what changed**: the
+  harness needs a specimen row rendering `color="success|warning|error|info"` on **Button, Chip and
+  Alert** — the components where `main` actually resolves. It has none today, which is precisely why
+  the gate could not catch defect 1 the first time. Adding that row is part of this WO.
+- A chart specimen that passes a partial `grid`, to show the merge.
+
+### Preconditions
+
+- `THEME-1` (`2.30.0`) and `CHART-6` (`2.31.0`) landed and published.
+
+### Parity guardrail
+
+No behaviour, permission or data-contract change. One palette value moves deliberately and visibly;
+everything else must render identically.
+
+---
+
+## B. Implementation map
+
+*Filled by the Orchestrator on `git pull` — see AGENTS.md → "Work Order".*
+
+### Execution directive (read this first)
+
+> **If you are the implementer reading this work order as your own specification: this section is
+> NOT addressed to you.** It tells the Orchestrator how to invoke you. **You ARE that invocation —
+> do NOT shell out to `codex exec`.**
+>
+> 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`. **Pass the WO via stdin, not as a positional
+> argument** — `cat work-orders/THEME-2.md | codex exec --skip-git-repo-check
+> --dangerously-bypass-approvals-and-sandbox -` (a positional arg hits Windows' command-line length
+> limit on a WO this size — proven on THEME-1/CHART-6). Fallback to direct Claude implementation
+> only on Codex quota/rate-limit/non-zero exit.
+
+### Context package
+
+**Preconditions verified 2026-08-10:** `THEME-1` (`96992cf`) and `CHART-6` (`6dedc62`) are both
+landed on `main` and published (`2.30.0`, `2.31.0`).
+
+**Defect 1 — exact current state, verified in `src/theme/tokens.js:81-87`:**
+```js
+warning: {
+  ...withMainShades('#C08A2C', '#212529'),
+  text: '#976100',
+  fill: '#C08A2C',
+  fillText: '#212529',
+  bg: '#FBF0DC',
+},
+```
+`withMainShades(main, contrastText)` (defined near the top of `tokens.js`) sets `main`/`light`/`dark`/
+`contrastText` via MUI's own `lighten`/`darken` at 0.2/0.3 tonal offsets. **Fix:** change the call to
+`withMainShades('#976100', '#FFFFFF')` — reusing the existing `text` value as the new `main`, and
+`'#FFFFFF'` as `contrastText` (verify this actually clears 4.5:1 — the WO states 5.216 on white
+already for `#976100`, and `contrastText` white-on-`#976100` is the same ratio by symmetry). Leave
+`text`/`fill`/`fillText`/`bg` untouched — `fill` stays the lighter amber for deliberate fill use
+(THEME-1's own `MuiAlert` `standardWarning` styleOverride already reads `palette.warning.text`/`.bg`,
+NOT `.main`, so that specimen is unaffected by this change — see the harness note below for why a
+NEW specimen is needed to actually exercise `.main`).
+
+**Defect 1's assertion rule — add to `src/theme/themeCompleteness.js`'s `contrastFindings(theme)`
+function (~line 249).** Alongside the existing per-status `text`-vs-`bg` and `fillText`-vs-`fill`
+loops, add a third: for each `status` in `STATUS_KEYS` (`['success','warning','error','info',
+'stale']`, from `tokens.js`) that HAS a `.main` property (**`stale` does not** — it's a custom
+augmented namespace, never passed through MUI's `createPalette`/`augmentColor`, so
+`theme.palette.stale.main` is `undefined` — skip it, don't push a spurious finding for a channel
+that was never supposed to have one), check `calculateContrastRatio(tokens.main, '#FFFFFF')` and
+`calculateContrastRatio(tokens.main, theme.palette.background.default)`, both `>= 4.5`, pushing a
+`contrast.<status>.main-on-<white|page>` finding (matching the existing naming convention,
+`contrast.controlBorder.<state>-on-<surface>`) on failure. This is a REPORT via the existing
+`findings` array — `assertThemeComplete` never throws or hard-fails on its own (confirm this by
+reading the function; the "ratchet stays a report, not a hard fail for non-adopters" is structural
+here, not a flag to add — a consuming app's OWN test suite decides whether to assert
+`findings.length === 0`, ucm's export just returns data either way).
+
+**Defect 2 — exact current state, verified in `src/components/charts/BarChart.jsx:26` and
+`LineChart.jsx:43`:** `grid = { horizontal: true }` as a bare JS default parameter, then
+`grid={grid}` passed straight through (`BarChart.jsx:65`, `LineChart.jsx:88`) — a caller-supplied
+`grid` object REPLACES the default wholesale rather than merging per-key, unlike every sibling prop
+in this file (compare `withAxisDefaults`'s `tickLabelStyle` merge, `withChartSlotDefaults`'s
+`tooltip`/`legend` merge — both spread the default first, caller second, so the caller only
+overrides the keys it actually sets). **Fix:** add a `withGridDefaults(grid)` helper to
+`src/components/charts/chartDefaults.js` following the SAME pattern (`{ horizontal: true, ...grid }`
+— MUI's `grid` prop type is `Pick<ChartsGridProps, 'vertical'|'horizontal'>`, plain optional
+booleans, no special `false`/`true` shorthand at the type level, so spreading a caller's object
+after the default is sufficient: a caller wanting no grid at all passes
+`grid={{ horizontal: false, vertical: false }}` explicitly, which the spread correctly honours since
+it's a later key overriding an earlier one — do not add special-casing for a literal `grid={false}`
+unless you find MUI's actual runtime prop handling treats a boolean differently from the declared
+type, which the WO's own phrasing ("or the documented way to switch the grid off entirely") already
+anticipates might not be a literal `false`). Wire it into both `BarChart.jsx` and `LineChart.jsx`
+the same way the other `chartDefaults.js` helpers are used.
+
+**Defect 2's audit — read `src/components/charts/chartDefaults.js` in full and check each
+object-valued prop the wrappers default or forward against the same replace-vs-merge question:**
+- `withAxisDefaults`'s `tickLabelStyle: { fontSize: tickFontSize, ...axis.tickLabelStyle }` —
+  ALREADY merges correctly (default first, caller's own `tickLabelStyle` fields win per-key).
+- `withChartSlotDefaults`'s `{ ...slotProps, tooltip: {...}, legend: {...} }` — the outer
+  `...slotProps` spread preserves any OTHER slot key a caller sets (e.g. `slotProps.axisHighlight`),
+  and the `tooltip`/`legend` sub-objects are themselves merged default-first. ALREADY correct.
+- `LineChart.jsx`'s `slots={{ mark: FilledMarkElement, ...slots }}` — default first, caller's own
+  `slots` spread after, so a caller's own `slots.mark` wins and other slot keys survive. ALREADY
+  correct.
+- `spaceForRotatedTicks`'s `margin` handling is NOT a "default object caller can partially override"
+  shape at all (it only computes `margin.bottom` when rotation is detected AND the caller hasn't set
+  one) — not the same bug class, nothing to fix there, but confirm this reading is right by re-reading
+  the function rather than trusting this summary.
+**Verify each of these four independently rather than trusting this list — this map is a starting
+point for the audit, not a substitute for it.** If the audit finds anything actually broken beyond
+`grid`, fix it and say so explicitly in the PR/commit, per the WO's "fix that too and say so." If the
+audit confirms all four are already correct, state that explicitly too — "audited and confirmed
+correct" is a valid, expected outcome per the WO ("either... or a named list").
+
+**Harness — why a new specimen row is required, not optional (verified 2026-08-10):** the current
+`ThemeBaselineEntry` (`dev/entries.jsx`) has TWO status-colour specimens today, and NEITHER exercises
+`palette.<status>.main`:
+1. `StatusChip` (`dev/entries.jsx:71-78`) sets `sx={{ bgcolor: '${tone}.fill', color:
+   '${tone}.fillText' }}` directly — bypasses `.main` entirely by design.
+2. `<Alert severity="warning">` etc. (`dev/entries.jsx:136-140`) — THEME-1's `MuiAlert`
+   `styleOverrides.standardWarning` (`src/theme/createAppTheme.js`'s `createPaletteAwareComponents`)
+   already overrides the STANDARD variant's `color`/`backgroundColor` to `palette.warning.text`/
+   `.bg` directly, NOT `.main` — so this existing Alert row was already immune to defect 1 and would
+   not have caught it even now.
+   Add: a row of `<Button color="success|warning|error|info" variant="contained">` (MUI's contained
+   Button reads `palette[color].main` for its background and `.contrastText` for its label — this is
+   the most direct `.main` exposure in the kit), a row of native `<Chip color="warning">` (not
+   `StatusChip` — MUI's own `color` prop on `Chip`, filled variant, also reads `.main`/
+   `.contrastText` directly), and an `<Alert severity="warning" variant="filled">` (MUI's `filled`
+   Alert variant is NOT covered by THEME-1's `standardWarning`-only override, so it still resolves
+   `.main` — confirm this by checking `createPaletteAwareComponents`'s `alertStyles` only sets
+   `standard${Status}` keys, never `filled${Status}` or `outlined${Status}`). These three together
+   are what the WO's Verification section means by "Button, Chip and Alert — the components where
+   `main` actually resolves."
+
+**Chart specimen for the `grid` merge:** the existing "Caller overrides" `LineChart` specimen
+(`dev/entries.jsx`, added in CHART-6) already sets `grid={{ horizontal: true, vertical: true }}` — a
+COMPLETE object, which happens to already include `horizontal: true`, so it would not visibly
+demonstrate the bug even pre-fix. Change it to a genuinely PARTIAL grid, e.g. `grid={{ vertical:
+true }}` alone — pre-fix this would have shown ONLY vertical lines (losing the horizontal default);
+post-fix it must show both. This is the specimen the WO's Verification section calls for ("A chart
+specimen that passes a partial `grid`, to show the merge").
+
+### Named files to change
+
+- `src/theme/tokens.js` — the `warning` entry's `withMainShades(...)` call (line 82).
+- `src/theme/themeCompleteness.js` — `contrastFindings` (~line 249), add the `main`-vs-white/page
+  loop, skipping any `STATUS_KEYS` entry without a `.main`.
+- `src/components/charts/chartDefaults.js` — new `withGridDefaults` export.
+- `src/components/charts/BarChart.jsx:26,65`, `src/components/charts/LineChart.jsx:43,88` — wire in
+  `withGridDefaults`.
+- `dev/entries.jsx` — new Button/Chip/Alert `.main`-exercising specimen row; fix the existing
+  "Caller overrides" LineChart's `grid` prop to a genuinely partial object.
+- `package.json` — version `2.31.0` → `2.31.1` (patch).
+- `tests/themeCompleteness.test.js` — extend with the 2 required tests (main contrast + non-vacuity
+  proof by temporarily reverting `warning.main`; ratchet/report-not-hard-fail confirmation).
+- `tests/chartDefaults.test.js` — extend with the 2 required tests (partial-grid merge + non-vacuity
+  proof by temporarily reverting to the bare default parameter; grid-off-via-explicit-false-object
+  still works).
+
+### Do-not-touch / invariants
+
+- `success`/`error`/`info`/`stale` palette values — untouched, they measure fine.
+- `warning.fill`/`.text`/`.bg` — untouched.
+- The committed reference-sheet HTML artifact (`work-orders/assets/THEME-1-baseline-reference-sheet.html`)
+  — frozen spec, never depicted `warning.main` as a foreground, not touched by this WO.
+- Anything in CHART-6's scope beyond the `grid` merge and the audit — no new chart-chrome feature
+  work here.
+- No behaviour, permission, or data-contract change.
+
+### Pitfalls (verified against landed code 2026-08-10)
+
+- `withMainShades` is defined once near the top of `tokens.js` and used for
+  `success`/`warning`/`error`/`info` — changing ONLY the `warning` call site, not the helper itself
+  (the helper's `lighten`/`darken` derivation logic is correct and unrelated to this bug).
+- `STATUS_KEYS` includes `'stale'`, which has no MUI-augmented `.main` — a naive loop over all
+  `STATUS_KEYS` reading `tokens.main` will hit `undefined` for `stale`; guard it (`if (!tokens?.main)
+  continue`, matching the existing loop's `if (!tokens) continue` pattern one function up).
+- Don't confuse this WO's `contrastFindings` addition with `THEME_COMPLETENESS_SURFACES`'s existing
+  `STATUS_SURFACES` (`text`/`fill`/`fillText`/`bg` presence-vs-default check) — the new rule is a
+  CONTRAST check (numeric ratio), same family as the existing `contrast.<status>.text-on-bg` /
+  `contrast.controlBorder.*` findings, not a "surface is deliberately defined" presence check.
+
+### Target repo working directory (absolute)
+
+`C:\Users\biglmi\Documents\webapps\ui-core-micha`
+
+### Required tests to WRITE (Codex writes them; the Orchestrator runs them)
+
+Exactly the 4 tests enumerated in Envelope § "Required tests to WRITE" above, extending
+`tests/themeCompleteness.test.js` and `tests/chartDefaults.test.js` (no new files), plus
+`tsc -p tsconfig.build.json --noEmit` clean. Do not add more, do not run the full suite. Affected-areas
+set is exactly those two files.
+
+### Preamble (append verbatim)
+
+> The text above is the COMPLETE spec — the committed WO file's 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 the
+> app `MEMORY.md` ONLY for conventions. Stay in scope; do not touch auth/permissions/deps/schema/CI
+> unless the spec says so; do not update `MEMORY.md`. 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` section 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 + 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>`.
+
+### Mini-handover
+
+Repo: `ui-core-micha` (`C:\Users\biglmi\Documents\webapps\ui-core-micha`), branch `main`. WO:
+`work-orders/THEME-2.md`. Follow `orchestrate-codex`.