@micha.bigler/ui-core-micha 2.39.0 → 2.39.1

package/WORK_ORDERS.md

@@ -80,3 +80,5 @@ Two chunks. **Chunk 1** (Part 1 + Part 2 of the Envelope): extended `SPACING_SHO
 | AUTH-4 | The account user list on a phone | Gives `UserListComponent` a card layout below `md` — one card per user, email as the title, the two boolean columns as labelled chips, role select and delete in a divided footer, plus a sort control that replaces the column headers the table loses. Above `md` the table is byte-identical. Prototype: [assets/AUTH-4-user-list-card.html](work-orders/assets/AUTH-4-user-list-card.html). Full spec: [work-orders/AUTH-4.md](work-orders/AUTH-4.md). | 2026-08-11 | planned | | Split out of DS-11 by operator decision; fix class chosen by operator (card list, over sticky-first-column and priority-hide). Envelope only (Approval Gate #1 pending). **Authored and parked by operator decision 2026-08-11 — not queued.** It is built on demand, not as SHELL-5's successor; a fresh session should not dispatch it without the operator saying so. When it does run, it runs **after** `SHELL-5` (same screen, different half). The point of this row is that the measurements above are already done, so nobody re-measures. Prototype in scope, so the two-width rendered gate applies. **Measured 2026-08-11 in cockpit** at `innerWidth` 411 (the mobile preset gives 411, not 375): table **1053px inside a 325px container**, container `overflow-x: auto` and **the document does not overflow** — so it is not a broken layout but a desktop table on a phone, with Role and Actions, the two things the screen exists for, entirely outside the view. **The cheap fix was tested and rejected:** 253px of the width is `New` (90) + `Successful Login` (163), both default-on props that `AccountPage` already forwards and cockpit simply left on — but the four remaining columns are 800px against 325px, so configuration cannot fix it. Column defaults deliberately NOT flipped: that would be a silent estate-wide change. SHELL-2's 1045px from 2026-08-08 still holds (+8px), so THEME-4/5 did not move the density. **Four prototype decisions are load-bearing:** email as title with a muted placeholder when the name is absent (verified: a 47-char address wraps to two lines in a 357px card without overflow); the icon-only flags become labelled chips **because a Tooltip is unreachable on a touch pointer**, so that data is effectively absent today; role and delete in a footer behind a divider with the full 44px target; and a **sort control**, because a card list has no column headers — without it the mobile view silently loses a desktop capability. `extraColumns` render as label/value rows with **no new required field**; `extraRowActions` beyond three must collapse into an overflow menu. Reached via `AccountPage`, which **at least ten apps mount**, and ucm has no staging net. |
 | SHELL-6 | A controlled `SectionNav` with no way to open must not render a trigger | In `mode="mobile"` the built-in trigger renders unconditionally (`SectionNav.jsx:246`), while `handleTriggerClick` calls `onOpen?.()` — so a consumer driving `open` itself without `onOpen` gets a button that is visible, focusable and does nothing. Render the trigger only when a click can open the drawer: uncontrolled, or controlled **and** `onOpen` supplied. Plus the component's **render matrix** written into its doc comment. Full spec: [work-orders/SHELL-6.md](work-orders/SHELL-6.md). | 2026-08-11 | done | f119b70 | **Unblocks `jg-ferien/NAV-37`** (`blocked`, `c627d7b`), same shape as `SHELL-3`→`SHELL-4`. **Operator chose the semantics fix over a `showTrigger` prop** — a prop would leave the dead button as the default for every controlled consumer who has not heard of it, turning a defect into a configuration option; a focusable control that performs no action is wrong on its own terms. Fix: `const canOpenTrigger = !isControlled || Boolean(onOpen)`, wrapping only the `<ButtonBase>` trigger — `children` and `<Drawer>` keep rendering unconditionally in every case. Render-matrix doc comment added above the component per the WO's own framing ("not optional documentation; it is the artefact whose absence caused the defect"). `AccountPage`, the only shipped consumer, is uncontrolled and renders identically. Version `2.37.0` → `2.37.1` (patch, defect fix, no API change). **Codex left the diff uncommitted and did not touch this file, as instructed** — fourth consecutive WO where the explicit warning held. **Required test 1's non-vacuity confirmed**: Codex's own landing note states the new regression test was run against the pre-fix code and failed (dead trigger still in the DOM), then passed after the one-line fix — the Orchestrator did not re-verify this specific claim by checking out the prior commit, but both independent reviewers separately read the old-vs-new JSX and found the claim plausible/consistent. **Orchestrator's own verification:** scoped tests 47/47 green, `tsc` clean. Independent `reviewer` + `ui_reviewer` (Sonnet, both mandatory) ran concurrently — **both came back clean, no findings, no fix required.** `reviewer` confirmed the condition is keyed correctly (not on `open`'s value, avoiding the trap the WO's own test 3 exists to catch), `children`/`Drawer` stay unconditional, desktop path untouched, and the render-matrix comment matches the Envelope's table exactly. `ui_reviewer` confirmed the trigger's removal is genuine (conditional JSX unmount, not a CSS-hidden trick left in the accessibility tree/tab order) and no restyle occurred as a side effect; noted two non-blocking residual observations, not fixed: a hypothetical layout-shift if a consumer dynamically toggled `onOpen` on/off at runtime (no current or planned consumer does this), and `resolvedEyebrow`/`resolvedTitle` computed unconditionally even when unused (harmless). No rendered gate needed per the WO's own reasoning — the change is a DOM absence fact, not an appearance, and the test suite is the correct instrument. |
 | THEME-6 | An app-side check for `sx` values the theme already gives | `THEME-4` made shadowing mechanical for the kit's own components; apps have no equivalent — cockpit alone carries **464 `sx` props across 37 files** (measured 2026-08-11). Adds an exported, source-level, **report-only** check an app calls from its own suite, plus the cockpit count. Full spec: [work-orders/THEME-6.md](work-orders/THEME-6.md). | 2026-08-11 | done | 637d262 | DS-18's app-side half. **Codex → Claude fallback**: Codex ran out of workspace credits mid-task (first-hand failure this session, stamped today) — the Orchestrator implemented directly. Author-flip rule applied: independent `reviewer` (Sonnet, mandatory regardless of tier) ran against the Orchestrator's own diff; `ui_reviewer` correctly not spawned, per the WO's own text, since nothing renders. New export `reportRedundantThemeValues(sources, { theme })` in `src/theme/themeCompleteness.js`, reusing existing primitives (`getPath`, `sameValue`, `jsxOpeningTag`, `topLevelSxValue`, `BASELINE_STYLED_MUI_COMPONENTS`, `expandShorthandProperty`) rather than rebuilding them. Attribution by JSX tag name only (root-slot styleOverrides only), literal string/number sx values only — no template literals, identifiers, spreads, or `component={...}` resolution, the bound written open per the WO's instruction. **A real, verified discrepancy in the Envelope's own grounding, corrected here rather than silently chased:** the cited cockpit examples (`borderColor: 'divider'` ×2, `bgcolor: 'background.paper'` ×3, `borderRadius: 1` ×3) all live on `<Box component="button">` in `cockpit/frontend/src/cockpit/ChatView.jsx:75,82,95` — confirmed by direct inspection — which the check's own stated tag-name attribution method cannot catch (`Box` isn't a themed tag, and `component={...}` resolution is explicitly out of scope). The check was NOT widened to chase these numbers. **Run against cockpit's real source** (`cockpit/frontend/src`, 50 `.jsx` files, `theme.js` excluded from the sources passed per the WO's app-side-exclusion instruction — `reportOffPaletteColours`'s own skip pattern left untouched): **27 findings, all `MuiButton.textTransform`, across 4 files** (`BoardView.jsx`, `KnowledgeView.jsx`, `SettingsView.jsx`, one more) — cockpit's buttons redundantly set `sx={{ textTransform: 'none' }}`, matching the baseline's own `MuiButton.styleOverrides.root.textTransform`. This is the honest, real result, reported as a correction to the Envelope's stale grounding, not a match to it. Independent `reviewer` found one real **P2, fixed**: numeric sx values for `borderRadius` and spacing-shorthand aliases were compared raw against the theme's already-resolved CSS value, but MUI actually multiplies a bare number by `theme.shape.borderRadius`/`theme.spacing()` before rendering (e.g. `borderRadius: 8` in sx renders as `8 × shape.borderRadius`, not `8`) — comparing the two raw numbers could produce a **false positive**, exactly the failure mode the WO's own Risks section names as the one to avoid. Fixed by skipping numeric-value comparison entirely for `borderRadius` and every spacing alias (`MUI_NUMERIC_SCALE_PROPERTIES`), erring toward a false negative (the accepted lower bound) rather than a false positive; two regression tests added (the specific false-positive case, plus a corrected version of the "component the theme doesn't style" test, which had used an off-list tag rather than exercising the intended undefined-styleOverride branch — also a reviewer note, fixed). Re-verified: cockpit's 27/27 findings unchanged by the fix (all string-valued `textTransform`, not numeric). Scoped tests 37/37 green, `tsc` clean. Version `2.37.1` → `2.38.0` (minor, new exported API). No rendered gate — static/logic change, no fix shipped anywhere (report-only, per the WO's explicit non-goal). |
+| THEME-7 | Guidance: a series slot that collides with an app's own accent | The baseline ships six `dataSeries.categorical` colours and no guidance for the case where a slot sits too close to something the consuming app owns. Measured case, not hypothesis (hram `IMARA-2`, frozen 2026-08-13, Lab ΔE calibrated against that operator's own rejected pair at ΔE 16.6): series 1 `#3D5A99` vs hram's primary `#2F4F96` = **ΔE 7.2**, and series 3 `#2E8F8A` vs hram's DALYs identity `#1F7A72` = **ΔE 8.3** (same hue, one lightness step). hram resolved both app-side by dropping slot 1 and replacing slot 3 with a navy. This WO adds the missing guidance to `DESIGN.md` and the token docs — how to check an accent against the palette, and why a colliding slot should be DROPPED rather than nudged — plus an explicit decide-and-record on whether to ship anything beyond guidance (ΔE helper / documented extension sequence / nothing). **Explicitly not a defect report: the six shipped values stay unchanged**, since they are correct for any app without a muted-indigo accent or a teal domain identity. Full order [`work-orders/THEME-7.md`](work-orders/THEME-7.md) | 2026-08-13 | planned |  | Tier 3 (shared-core surface) though documentation-led; independent `reviewer` mandatory. Raised by the hram/Imara design-language work at the operator's explicit instruction to take the finding upstream rather than keep it app-local. Stated limitation to keep in the text: the guidance derives from ONE app's experience and its threshold is calibrated on one operator's judgement — a starting point, not a standard. |
+| THEME-8 | Touch-Ziel des Selects sitzt am falschen Element und drückt den Text aus der Mitte | `src/theme/tokens.js` setzt die Touch-Mindesthöhe (40, im `@media (any-pointer: coarse)`-Zweig 44) auf `MuiSelect.styleOverrides.**select**` — also auf das INNERE Element, das MUIs variantenabhängiges Padding trägt. Beim `standard`-Select ist dieses Padding oben-verankert (`1px 24px 5px 0`), der Zusatzraum landet komplett unten, der Text reitet oben. **Von den sechs Komponenten mit Touch-Ziel (`MuiButton`, `MuiIconButton`, `MuiSelect`, `MuiCheckbox`, `MuiFormControlLabel`, `MuiTextField`) ist `MuiSelect` die EINZIGE, die einen Nicht-Root-Slot adressiert** — eine Inkonsistenz in der Baseline selbst, keine Designentscheidung. **Live gemessen** (hram, Administration → Users, Select in einer Tabellenzelle): heute 0 px über / 0 px unter dem Text (Inneres auf 44 px gestreckt); nach Verschieben der Regel auf die Wurzel **9 px / 9 px** — exakt zentriert, weil `MuiInputBase-root` bereits `display:flex; align-items:center` ist. Voller Auftrag [`work-orders/THEME-8.md`](work-orders/THEME-8.md) | 2026-08-14 | done (npm publish; consumer pin bumps still open) | ae0745d | Tier 3 (Shared-Core). Codex out of credits (2026-08-14, `.claude/codex-status.md`), Orchestrator implemented directly — authorship flip made `reviewer` + `ui_reviewer` mandatory (already required at Tier 3): both ran, no blocking findings. `reviewer`: config-level test doesn't render/measure the DOM (P3, accepted — Envelope's own proof is the live measurement, already done), no version bump at review time (P2, resolved by 2.39.0→2.39.1 in the same commit). `ui_reviewer`: MuiSelect's coarse branch still hand-writes `{minHeight:44}` instead of the shared `coarseHitArea` helper (P3, pre-existing, not introduced here). Both independently traced MUI source (`Select.js`/`InputBase.js`) and confirmed the root-slot fix reaches the right DOM node and centres via the inherited flex layout. No live browser re-render done (Claude-Code preview-scoping override: small/medium frontend change, code reasoning + tests suffice). **Wert bleibt 40/44 — nur der Anker ist falsch.** Verstärkt auf Touch-Geräten: der `coarse`-Zweig greift auch auf Laptops mit Touchscreen (Operator-Rechner meldet `any-pointer: coarse`), dort 44 statt 40 px — gleicher Fehler, 4 px grösser. **Estate-weite Sichtveränderung**: alle konsumierenden Apps bekommen re-zentrierte Selects; in den Release Notes nennen. **Nicht am npm-Publish abschliessen** — die Pin-Bumps der Konsumenten (zuerst hram, wo es gefunden wurde) gehören dazu. Gefunden beim Messen einer vermeintlichen hram-Regression; die App-seitige Schwester ist hram FIX-11 (anderer Fehler, gleiche Felder). |

package/dist/theme/themeCompleteness.js

@@ -45,8 +45,8 @@ const COMPONENT_SURFACES = [
     componentPath('MuiTooltip', 'defaultProps.slotProps.transition.timeout.enter'),
     componentPath('MuiTooltip', 'defaultProps.slotProps.transition.timeout.exit'),
     componentPath('MuiSelect', 'defaultProps.variant'),
-    componentPath('MuiSelect', 'styleOverrides.select.minHeight'),
-    componentKeyLeaf('MuiSelect', 'styleOverrides.select', '@media (any-pointer: coarse)', 'minHeight'),
+    componentPath('MuiSelect', 'styleOverrides.root.minHeight'),
+    componentKeyLeaf('MuiSelect', 'styleOverrides.root', '@media (any-pointer: coarse)', 'minHeight'),
     componentPath('MuiCheckbox', 'styleOverrides.root.color'),
     componentKeyLeaf('MuiCheckbox', 'styleOverrides.root', '@media (any-pointer: coarse)', 'minHeight'),
     componentKeyLeaf('MuiCheckbox', 'styleOverrides.root', '@media (any-pointer: coarse)', 'minWidth'),

package/dist/theme/tokens.js

@@ -209,7 +209,7 @@ export const BASELINE_STATIC = {
         MuiSelect: {
             defaultProps: { variant: 'outlined' },
             styleOverrides: {
-                select: {
+                root: {
                     minHeight: 40,
                     boxSizing: 'border-box',
                     '@media (any-pointer: coarse)': { minHeight: 44 },

package/package.json

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

package/src/theme/themeCompleteness.js

@@ -73,8 +73,8 @@ const COMPONENT_SURFACES = [
   componentPath('MuiTooltip', 'defaultProps.slotProps.transition.timeout.enter'),
   componentPath('MuiTooltip', 'defaultProps.slotProps.transition.timeout.exit'),
   componentPath('MuiSelect', 'defaultProps.variant'),
-  componentPath('MuiSelect', 'styleOverrides.select.minHeight'),
-  componentKeyLeaf('MuiSelect', 'styleOverrides.select', '@media (any-pointer: coarse)', 'minHeight'),
+  componentPath('MuiSelect', 'styleOverrides.root.minHeight'),
+  componentKeyLeaf('MuiSelect', 'styleOverrides.root', '@media (any-pointer: coarse)', 'minHeight'),
   componentPath('MuiCheckbox', 'styleOverrides.root.color'),
   componentKeyLeaf('MuiCheckbox', 'styleOverrides.root', '@media (any-pointer: coarse)', 'minHeight'),
   componentKeyLeaf('MuiCheckbox', 'styleOverrides.root', '@media (any-pointer: coarse)', 'minWidth'),

package/src/theme/tokens.js

@@ -255,7 +255,7 @@ export const BASELINE_STATIC = {
     MuiSelect: {
       defaultProps: { variant: 'outlined' },
       styleOverrides: {
-        select: {
+        root: {
           minHeight: 40,
           boxSizing: 'border-box',
           '@media (any-pointer: coarse)': { minHeight: 44 },

package/tests/themeCompleteness.test.js

@@ -171,6 +171,21 @@ describe('theme completeness', () => {
       ]),
     );
   });
+
+  it('anchors the select touch target on the input root, not the inner select slot', () => {
+    // THEME-8: a min-height on styleOverrides.select lands on a display:block
+    // element with variant-dependent, top-anchored padding -- the surplus
+    // height collects entirely below the text instead of centring it. The
+    // root is already flex/align-items:center, so anchoring there is what
+    // actually centres the text. A test only checking "44px somewhere" would
+    // pass on the broken version too.
+    const theme = createAppTheme({ palette: { primary: { main: '#0F62FE' } } });
+    const selectOverrides = theme.components.MuiSelect.styleOverrides;
+
+    expect(selectOverrides.select?.minHeight).toBeUndefined();
+    expect(selectOverrides.root.minHeight).toBe(40);
+    expect(selectOverrides.root['@media (any-pointer: coarse)'].minHeight).toBe(44);
+  });
 });
 
 describe('kit sx disjointness', () => {

package/work-orders/THEME-7.md

@@ -0,0 +1,82 @@
+# THEME-7 — Guidance: a series slot that collides with an app's own accent
+
+## Part A — Envelope
+
+**Goal.** Give consuming apps a documented answer for the case where a baseline
+`dataSeries.categorical` slot sits too close to something the app itself owns — the app's
+accent, or one of its domain identity colours. Today the baseline offers six series colours
+and no guidance for that collision, so each app rediscovers the problem on its own.
+
+**Why — a measured case, not a hypothesis.** During hram's Imara design-language work
+(hram `IMARA-2`, frozen 2026-08-13) two collisions were measured against the app's own
+values, using Lab ΔE with the operator's own rejected candidate pair as the calibration
+floor (that pair sat at ΔE 16.6 and was judged "not tellable apart"):
+
+- baseline series 1 `#3D5A99` versus hram's chosen primary `#2F4F96` → **ΔE 7.2**, the
+  tightest pair in that app's whole system; a series line beside a primary button reads as
+  the same colour.
+- baseline series 3 `#2E8F8A` versus hram's DALYs identity `#1F7A72` → **ΔE 8.3**; same
+  hue (a −28.7 vs −27.8), one lightness step apart (L 54 vs 46).
+
+hram resolved both app-side: slot 1 dropped entirely (both replacement candidates measured
+worse elsewhere — a neutral slate landed ΔE 5.0 from the shared `stale` fill, a muted green
+ΔE 15.5 from the app's own olive slot), and slot 3 replaced by a navy, which simultaneously
+restored the dark blue the first removal had taken away. The nine remaining slots plus an
+overflow grey covered the app's needs.
+
+**This is not a defect report against the baseline.** For an app whose primary is not a
+muted indigo and which has no teal domain identity, series 1 and 3 are correct and useful.
+What is missing is the *guidance*, and the observation that the baseline's own muted,
+cool-leaning character makes a collision with a tastefully chosen accent more likely rather
+than less — apps that like this palette tend to pick accents from the same region.
+
+**Scope.**
+
+1. `DESIGN.md` — a short subsection under the data-colour principle: how to check a chosen
+   accent against the series palette (measure, do not eyeball; a usable threshold with the
+   calibration above named as its provenance), and what to do when it collides — drop the
+   slot rather than nudge it, because a nudged slot stays confusable while a dropped one is
+   simply absent.
+2. The same note in the theme package's own documentation where `dataSeries.categorical` is
+   described, so it is found by someone reading the token rather than the design doc.
+3. **Decide and record**: whether the baseline should additionally *ship* anything —
+   candidates being an exported ΔE helper apps can assert with, a documented extension
+   sequence for apps needing more than six slots, or nothing at all beyond the guidance.
+   Doing nothing is a legitimate outcome and should be recorded as a decision if chosen.
+
+**Non-goals / do-not-touch.** Do **not** change the six shipped series values — hram's
+divergence is app-specific and other consumers depend on the current set. No change to the
+status palette, the completeness assertion, or any component. This is documentation plus,
+at most, one small additive export.
+
+**Tier 3** — shared-core surface, per the estate tiering table, even though the change is
+documentation-led. Independent review mandatory.
+
+**Tests to write.** None for the documentation. If item 3 lands a helper, that helper gets
+its own unit test with the two measured pairs above as fixtures — they are real values with
+known answers.
+
+**Risks.** The guidance is derived from a single app's experience; state that plainly rather
+than presenting it as a general law. The threshold in particular is calibrated on one
+operator's judgement — useful as a starting point, not as a standard, and it should say so.
+
+## Part B — Implementation map (implementer)
+
+PLACEHOLDER — Orchestrator fills this on `git pull`: context package with `path:line`
+anchors into `DESIGN.md` and the token documentation, the absolute working directory, the
+progress contract, the preamble. Not dispatchable while this stands.
+
+## Part C — Orchestrator only
+
+**STOP — addressee guard.** If you are the implementer reading this file as your own spec:
+this part is not addressed to you. It tells the Orchestrator how to invoke you; you ARE that
+invocation — do not shell out to `codex exec`. Stop reading at this line.
+
+- **Execution.** Codex first per the Tier-2/3 rule unless the status record says otherwise.
+- **Review routing.** `reviewer` mandatory (Tier 3). No `ui_reviewer` unless item 3 turns
+  into code with a visual surface, which it should not.
+- **Verification.** Scoped: the theme package's existing tests must stay green; any new
+  helper carries its own.
+- **Cross-repo.** Reference hram `IMARA-2` and its frozen sheet as the evidence source; do
+  not restate the measurements from memory when the artifact holds them.
+

package/work-orders/THEME-8.md

@@ -0,0 +1,211 @@
+# THEME-8 — The select touch target sits on the wrong element and pushes its text off-centre
+
+## Part A — Envelope
+
+**Goal.** Move the baseline's touch-target minimum height for `MuiSelect` from the inner
+`select` slot to the input root, so the existing flex centring can do its job. Every
+consuming app's select text is currently top-anchored instead of vertically centred.
+
+**Why — measured, not inferred.** `src/theme/tokens.js` sets
+
+```js
+MuiSelect: { styleOverrides: { select: {
+  minHeight: 40,
+  '@media (any-pointer: coarse)': { minHeight: 44 },
+} } }
+```
+
+`.MuiSelect-select` is the element that carries MUI's variant-dependent padding, and for
+the `standard` variant that padding is deliberately top-anchored (`1px 24px 5px 0`). Forcing
+a 40/44 px height onto a `display: block` element whose content needs ~26 px puts the whole
+surplus below the text, so the text rides high in its box.
+
+Measured live in a consuming app (hram, Administration → Users, a select inside a table
+cell), then verified by moving the rule to the root at runtime:
+
+| | space above the text | space below |
+|---|---|---|
+| today | 0 px | 0 px — inner stretched to 44 px, top-anchored |
+| min-height on the root instead | **9 px** | **9 px** |
+
+The root (`MuiInputBase-root`) is already `display: flex; align-items: center`, so it centres
+the natural-height inner element for free.
+
+**This is an inconsistency inside the baseline, not a design choice.** Of the six components
+that carry a touch target — `MuiButton`, `MuiIconButton`, `MuiSelect`, `MuiCheckbox`,
+`MuiFormControlLabel`, `MuiTextField` — **`MuiSelect` is the only one that targets a
+non-root slot.** The other five all use `root`.
+
+**Amplified on touch-capable machines.** The `@media (any-pointer: coarse)` branch raises it
+to 44 px, and a laptop with a touchscreen matches that query. The operator's machine reports
+`any-pointer: coarse`, which is why it looks worse there than on a non-touch machine — the
+same defect, 4 px larger.
+
+**Scope.**
+
+1. Move the minimum height off `styleOverrides.select` and onto the root, keeping both the
+   base value and the coarse-pointer branch. **Verify which root actually receives it** —
+   `MuiSelect`'s `root` slot composes with the underlying input, and the outlined and
+   standard variants compose differently; if `MuiSelect.root` does not carry it cleanly for
+   both, `MuiInputBase.root` is the alternative. Decide by measuring in a running app, not
+   by reading the MUI source.
+2. Check the outlined variant does not grow taller than a neighbouring `MuiTextField` after
+   the move — `MuiTextField` already carries its own root min-height, so the two must still
+   line up in a form row.
+3. A test that pins the intent: assert the minimum height is not applied to the `select`
+   slot (or, better, assert the rendered inner element's natural height is preserved). A
+   test that only checks "44 px somewhere" would pass on the broken version too.
+
+**Non-goals / do-not-touch.** Do not change the touch-target *value* (40 / 44) — the size is
+correct, only its anchor is wrong. Do not touch the other five components; they are already
+correct. No colour, typography or density changes. Do not "fix" this per-app with an sx
+override in a consumer — that is what this baseline exists to prevent.
+
+**Tier 3** — shared-core surface. `reviewer` mandatory. Every consuming app's selects change
+appearance (for the better), which is exactly why it belongs here rather than in one app.
+
+**Tests to write.** The intent test above, plus whatever existing theme/completeness suite
+covers component overrides. Keep it small; the real proof is the rendered measurement.
+
+**Risks.**
+- **Estate-wide visual change.** Every app using the baseline gets subtly taller-looking
+  select rows or re-centred text. That is the fix, but it will be visible in apps nobody is
+  currently working on — name it in the release notes rather than letting it surprise someone.
+- Moving a min-height between slots can change how a select aligns next to a text field in
+  the same row. Scope item 2 exists for that; check it in a real form, not in isolation.
+- The coarse-pointer branch means a reviewer on a non-touch machine sees 40 px and a milder
+  version of the defect. Say which machine the verification ran on.
+
+**Delivery is not done at publish.** A version bump alone does not fix any app. The
+consuming apps still need their pin bumped and a look at their own forms — hram in
+particular, where this was found. Track the consumer bumps rather than closing this WO at
+the npm publish.
+
+## Part B — Implementation map — ADDRESSED TO THE IMPLEMENTER
+
+### Context package
+
+**Named file to change:** `src/theme/tokens.js`, the `MuiSelect` block, currently:
+
+```js
+MuiSelect: {
+  defaultProps: { variant: 'outlined' },
+  styleOverrides: {
+    select: {
+      minHeight: 40,
+      boxSizing: 'border-box',
+      '@media (any-pointer: coarse)': { minHeight: 44 },
+    },
+  },
+},
+```
+
+(around `src/theme/tokens.js:255-264`). The shared coarse-pointer helper used by every other
+component sits just above it:
+
+```js
+const coarseHitArea = {
+  '@media (any-pointer: coarse)': {
+    minHeight: 44,
+    minWidth: 44,
+  },
+};
+```
+
+(`src/theme/tokens.js:135-140`). The five correct comparators, for the target shape (all use
+`styleOverrides.root` and the shared `coarseHitArea` spread):
+
+- `MuiButton` — `src/theme/tokens.js:233-245` (`root: { minHeight: 40, ..., ...coarseHitArea }`)
+- `MuiIconButton` — `:249-251`
+- `MuiCheckbox` — `:265-267`
+- `MuiFormControlLabel` — `:268-273`
+- `MuiTextField` — `:334-337`
+
+Also relevant: `MuiOutlinedInput` already sets `root: { minHeight: 40, ...coarseHitArea }`
+(`:338-346`) — since `MuiSelect` with `variant: 'outlined'` (the default here) composes with
+`MuiOutlinedInput`'s root, moving `MuiSelect`'s own min-height onto `MuiSelect.styleOverrides.root`
+must not double up with that existing rule for the outlined variant. Measure both variants
+(`outlined` default, and `standard` where used) in a running app before deciding whether the
+target is `MuiSelect.styleOverrides.root` or `MuiInputBase.styleOverrides.root` — the Envelope
+already flags this as a measure-don't-read decision.
+
+**Second file:** `src/theme/themeCompleteness.js` references the old path and must move with it:
+
+```
+75:  componentPath('MuiSelect', 'defaultProps.variant'),
+76:  componentPath('MuiSelect', 'styleOverrides.select.minHeight'),
+77:  componentKeyLeaf('MuiSelect', 'styleOverrides.select', '@media (any-pointer: coarse)', 'minHeight'),
+```
+
+Update lines 76-77 to point at wherever the min-height actually lands (`styleOverrides.root...`
+or `styleOverrides.select` removed entirely if the property is dropped from that slot) — keep
+line 75 (`defaultProps.variant`) as is, it is unrelated. This file drives the baseline's own
+completeness assertion; a stale path here makes the completeness suite pass against dead code.
+
+**Existing test suite for reference:** `tests/themeCompleteness.test.js` — no existing test
+references `MuiSelect` by name today, so the new intent test (Envelope scope item 3) is net new,
+not a modification of an existing case.
+
+**Invariants / do-not-touch:** the touch-target *value* stays 40 / 44 — only the slot changes.
+Do not touch `MuiButton`, `MuiIconButton`, `MuiCheckbox`, `MuiFormControlLabel`, `MuiTextField`,
+or `MuiOutlinedInput` beyond what's needed to avoid the double-application noted above. No
+colour/typography/density changes anywhere in this diff.
+
+Directive: 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\biglmi\Documents\webapps\ui-core-micha`
+
+### Preamble — REQUIRED, addressed to the implementer
+
+> 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 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" 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 + 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`. Fallback to direct Claude implementation only on
+Codex quota/rate-limit/non-zero exit — the fallback flips authorship, so an independent
+`reviewer` becomes mandatory (already required at Tier 3, so no incremental change there).
+
+## Review routing
+
+`reviewer` mandatory (Tier 3); `ui_reviewer` too, since the visible result is a layout change
+across every consumer. Both spawned in the same background batch, Sonnet-pinned (Tier 3), diff
+inline, pointed at this WO's Envelope only.
+
+## Verification
+
+The package's own suite (`tests/themeCompleteness.test.js` plus the new intent test), plus a
+**rendered check in a consuming app**: a select in a table row and a select beside a text field,
+both re-measured for equal space above and below the text. State which machine (coarse or fine
+pointer) the measurement ran on.
+
+## Register + commit
+
+Advance the THEME-8 row with the named reviewer verdicts and the measured before/after numbers.
+Then track the consumer pin bumps (hram first) — this WO is not done at npm publish.