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

package/tests/StatTile.test.jsx

@@ -0,0 +1,57 @@
+// @vitest-environment jsdom
+import { afterEach, describe, expect, it } from 'vitest';
+import { cleanup, render, screen } from '@testing-library/react';
+import { ThemeProvider } from '@mui/material/styles';
+
+import { createAppTheme } from '../src/theme';
+import StatTile from '../src/components/StatTile';
+
+const theme = createAppTheme({ palette: { primary: { main: '#0F62FE' } } });
+
+function renderTile(props) {
+  return render(<ThemeProvider theme={theme}><StatTile {...props} /></ThemeProvider>);
+}
+
+afterEach(() => cleanup());
+
+describe('StatTile', () => {
+  it('renders label, value and caption', () => {
+    renderTile({ label: 'Coverage at budget', value: '71.4 %', caption: 'of maximum realizable' });
+
+    expect(screen.getByText('Coverage at budget')).toBeTruthy();
+    expect(screen.getByText('71.4 %')).toBeTruthy();
+    expect(screen.getByText('of maximum realizable')).toBeTruthy();
+  });
+
+  it('omits the value row when value is undefined', () => {
+    renderTile({ label: 'Recovered' });
+
+    expect(screen.getByText('Recovered')).toBeTruthy();
+    expect(screen.queryByText('undefined')).toBeNull();
+  });
+
+  it('renders children', () => {
+    renderTile({ label: 'Deaths averted', value: '63.8 %', children: <span>children slot</span> });
+
+    expect(screen.getByText('children slot')).toBeTruthy();
+  });
+
+  it('applies the accent border only when accent is set', () => {
+    const { container: plain } = renderTile({ label: 'Body fat', value: '18.4 %' });
+    const plainStyle = window.getComputedStyle(plain.firstChild);
+    expect(plainStyle.borderWidth).toBe('1px');
+
+    cleanup();
+
+    const { container: accented } = renderTile({ label: 'Lean mass', value: '62.1 kg', accent: true });
+    const accentedStyle = window.getComputedStyle(accented.firstChild);
+    expect(accentedStyle.borderWidth).toBe('2px');
+  });
+
+  it('renders the value with tabular-nums', () => {
+    renderTile({ label: 'theta*', value: '0.8421' });
+
+    const value = screen.getByText('0.8421');
+    expect(window.getComputedStyle(value).fontVariantNumeric).toBe('tabular-nums');
+  });
+});

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', () => {
@@ -245,6 +260,22 @@ describe('kit sx disjointness', () => {
           surface: 'UserListComponent.emptyCell.MuiTableCell.py',
           reason: 'The empty-state message intentionally uses more vertical breathing room than the baseline TableCell default.',
         },
+        {
+          surface: 'SoftChip.root.MuiChip.height',
+          reason: 'SoftChip is a small annotation chip, deliberately auto-height rather than the baseline interactive Chip\'s fixed 32px.',
+        },
+        {
+          surface: 'SoftChip.caveat.MuiChip.borderRadius',
+          reason: 'The caveat variant uses the shared square-ish radius token (shape.borderRadius), not the baseline Chip\'s pill radius.',
+        },
+        {
+          surface: 'SoftChip.caveat.MuiChip.fontSize',
+          reason: 'PRIM-1 token delta: caveat text is 12/500, one weight step above the nearest baseline variant (caption, 12/400). Adding a variant for this is an app-level baseline decision out of scope for this promotion; deliberately left unresolved.',
+        },
+        {
+          surface: 'SoftChip.status.MuiChip.borderRadius',
+          reason: 'The status variant is a pill, matching cockpit\'s existing lane-status pill shape, not the baseline Chip\'s default radius.',
+        },
       ],
     }).findings).toEqual([]);
   });

package/work-orders/PRIM-1.md

@@ -0,0 +1,177 @@
+# PRIM-1 — Promote `StatTile` and `SoftChip` into the shared kit
+
+**Target repo:** `ui-core-micha` (branch `main`)
+**Tier:** 3 — shared-core.
+
+New register prefix `PRIM-*`: shared dashboard/data primitives — small presentational components that
+are neither chart (`CHART-*`) nor app chrome (`SHELL-*`).
+
+---
+
+## A. Envelope
+
+### Goal
+
+Both components already exist **twice**, built independently, and the second build in each case is an
+**inline component inside a page** rather than a file — which is why a filename search misses it:
+
+| Component | First build | Second build |
+|---|---|---|
+| `StatTile` | `hram/frontend/src/components/ResearchComponents/StatTile.jsx` (36 lines) | `fitness-monitor/frontend/src/pages/BodyHistoryPage.jsx:554-568` |
+| `SoftChip` | `hram/frontend/src/components/ResearchComponents/SoftChip.jsx` (67 lines) | `cockpit/frontend/src/cockpit/BoardView.jsx:65-73` (the lane pill) |
+
+Promote both into the kit as the single implementation. The promotion trigger is met on evidence — two
+independent builds each, and a third app in view for each.
+
+### The visual spec, and the seven decisions in it
+
+**Prototype:** [`work-orders/assets/PRIM-1-dashboard-primitives.html`](work-orders/assets/PRIM-1-dashboard-primitives.html).
+It renders the promoted spec at 375 px and 1280 px, keeps both original builds side by side as the
+record of what changed, and computes its contrast ratios in-page against the *blended* fill.
+
+The two builds diverged in seven places. All seven were decided by the operator on 2026-08-12, and the
+prototype already reflects them:
+
+| | Decision | Which app changes |
+|---|---|---|
+| StatTile value size | **`h5` — 18/600** | hram, 16 → 18 |
+| StatTile digits | **`tabular-nums`, always** — it is what makes a KPI row read as a row | fitness-monitor |
+| StatTile row behaviour | **`flex: 1` with a `minWidth` floor** — one rule covering both existing behaviours, no prop | hram, tiles now share the row |
+| StatTile `accent` | **kept** — 2 px `primary.main`; without it fitness-monitor cannot adopt | neither |
+| StatTile padding | **responsive `{xs: 1, sm: 1.5}`** | hram, was fixed |
+| SoftChip `status` typography | **`overline` — 11/600, uppercase, .4 px tracking** | hram (`passed` → `PASSED`); cockpit drops 700 → 600 |
+| SoftChip leading element + border | **dot by default, any icon via prop; border optional** | neither — both adopt unchanged |
+
+**Why `overline` rather than a new variant:** cockpit's build independently arrived at 11-with-uppercase-
+and-.4 px-tracking, which is the baseline's `overline` in all but the weight step. So the shared choice
+is what the second consumer already made, and it satisfies `THEME-4` **without a baseline change**.
+
+### Token delta list
+
+**One entry** — the rest is drawn from the baseline's own tokens, so there is nothing else to reconcile.
+
+- **`caveat` variant text: 12/500.** The baseline's nearest variant is `caption` at 12/**400**; there is
+  no 12/500. **Resolved by the operator as: keep the prototype value, do not add a baseline variant in
+  this WO.** It will surface as a `THEME-4` finding on the promoted component and must be **exempted
+  with that reason stated** — not silently flattened to 400, and not fixed by extending the baseline
+  here. Adding a variant is an app-level decision that does not belong inside a component promotion.
+
+### Scope
+
+1. **`StatTile`** as a kit component, per the decisions above. Props: `label`, `value`, `caption`,
+   `accent`, `children`, and a `minWidth` floor with a sensible default.
+2. **`SoftChip`** as a kit component. Props: `label`, `tone` (`success`/`warning`/`error`/`info`),
+   `variant` (`caveat`/`status`), `icon` (defaulting to the 6 px dot), a border toggle, and `title` for
+   the tooltip.
+3. **Colour derivation stays as authored** — fill `alpha(main, .12)`, border `alpha(main, .30)`, text and
+   dot `darken(main, .3)`, read from `theme.palette[tone]`. **Do not restate any hex.** This is the
+   property that makes the component exemplary and the reason its four tones all pass AA (measured in the
+   prototype: 7.11 / 7.33 / 7.67 / 9.20).
+4. **Keep `enterTouchDelay={0}`** on the tooltip. It is why SoftChip's `title` is reachable on a touch
+   pointer — the exact failure `AUTH-4` is blocked on elsewhere. Do not drop it as boilerplate.
+5. Exports from the package root, and the README line.
+
+### Non-goals / do not touch
+
+- **The three app adoptions.** hram, fitness-monitor and cockpit each get their own small follow-up WO.
+  This WO ships the kit component and nothing in any app.
+- **No baseline/theme change.** No new typography variant, no palette edit. See the token delta list.
+- **The other primitives in hram's `ResearchComponents/`** — `CardTitle`, `InfoPopover`,
+  `ProvisionalChip`, `FieldInfo`. `ProvisionalChip` wraps `SoftChip` and is the obvious next candidate,
+  but it has one build and is out of scope here.
+- **`SoftChip`'s `caveat` weight.** Left at 12/500 deliberately.
+- Any chart wrapper, shell component, or existing kit surface.
+
+### Risks
+
+- **Two apps' visible appearance changes when they adopt** — hram's status chips become uppercase and its
+  KPI values grow 16 → 18; cockpit's pills lose a weight step. All three are decided, not accidental, and
+  all three land in the *adoption* WOs rather than here. Worth stating in each so nobody reports them as
+  regressions.
+- **Neither `StatTile` build has a test.** The promoted component's tests are written here from scratch,
+  not ported. `SoftChip` has `SoftChip.test.jsx` in hram — read it, but do not assume it covers the
+  promoted API.
+- **`THEME-4` will flag the `caveat` 12/500.** Expected. Exempt with the reason; an unexplained exemption
+  is itself a finding by that check's own design.
+- **Version:** this is a new capability area (two new components), so a **minor** — `2.38.0` → `2.39.0`.
+
+### Required tests to WRITE
+
+- **`StatTile`**: renders label/value/caption; omits the value row when `value` is undefined; renders
+  `children`; `accent` applies the 2 px border and the default does not; the value carries
+  `tabular-nums`.
+- **`SoftChip`**: each of the four tones derives fill/border/text from `theme.palette[tone]` rather than a
+  literal (assert against the theme object, not against a hex string); `status` vs `caveat` differ in
+  radius and typography; the default leading element is the dot and a passed `icon` replaces it; the
+  border toggle works; `title` renders a tooltip and `enterTouchDelay` is 0.
+- **Do not write a contrast assertion using `getContrastRatio`** — it ignores alpha, so on a 12 % tint it
+  answers a different question and would pass while meaning nothing. The prototype computes the real
+  ratios; if a contrast test is wanted it must blend the fill first.
+
+Scope the run to these two new specs plus anything the new exports touch. Not the full suite — no
+dependency change, no theme change.
+
+### Parity guardrail
+
+Visual and API only. The promoted components must be capable of rendering **both** existing builds'
+appearances where a decision preserved them, and exactly the decided appearance where it did not. No
+behaviour, permission or data-contract surface exists here.
+
+---
+
+## B. Implementation map
+
+*Filled by the Orchestrator on `git pull` — see `AGENTS.md` → "Work Order".*
+
+---
+
+## C. Orchestrator only
+
+> **STOP — if you are the implementer reading this work order as your own specification, this section is
+> NOT addressed to you. Skip it entirely.** It tells the Orchestrator how to invoke you, how the result
+> is reviewed, and how it is committed. **You ARE that invocation — do NOT shell out to `codex exec`, do
+> NOT spawn reviewers, do NOT run tests beyond your own new ones, do NOT edit `WORK_ORDERS.md`, and do
+> NOT `git add`/`commit`/`push`.** Leave the diff in the working tree.
+
+### Execution directive
+
+Check `.claude/codex-status.md` first. **No line for the current date means use Codex.** A line recording
+`unavailable` for the current date means skip the attempt, implement directly in Claude, and name the
+record and its date — that flips authorship. If the newest confirmation is older than today, make exactly
+one probe and write the outcome back either way.
+
+### Review routing
+
+Tier 3: **independent `reviewer`** and **`ui_reviewer`**, concurrent, in one background batch, before the
+commit. **No `sec_reviewer`** — no auth, permission, money or schema surface.
+
+Ask `ui_reviewer` specifically whether the `overline` decision reads correctly at both variants, and
+whether the `caveat` exemption is stated rather than assumed.
+
+### Verification
+
+**A prototype is in scope, so the rendered side-by-side at 375 px and 1280 px is a commit gate** — see
+`AGENTS.md` → Reviews. Note the known constraint: the Browser pane composites only while displayed and
+screenshots have not been legibly obtainable in this repo. If capture fails, **declare the substitution
+in the register Notiz** and say what was inspected instead (computed styles, DOM) — an undeclared
+substitution is a skipped gate, and that fallback cannot see whether a screen reads heavy or dense.
+
+The prototype's own contrast numbers are computed at render time; re-read them rather than restating
+these.
+
+### Register + commit
+
+One row, `PRIM-1`, with the `PRIM-*` prefix documented in the register header. `done` only with both
+reviewers and their verdicts named, plus the rendered-gate evidence or its declared substitution.
+
+Publishing is a separate step from committing: **a landed commit is not a publish.** If the three
+adoption WOs are to follow, `2.39.0` must actually be on the registry first — verify against npm, not
+against a commit.
+
+### Mini-handover
+
+Repo: `ui-core-micha` (`C:\Users\biglmi\Documents\webapps\ui-core-micha`), branch `main`.
+WO: `work-orders/PRIM-1.md`. Promotes two components whose second builds are inline in
+`fitness-monitor/BodyHistoryPage.jsx:554` and `cockpit/BoardView.jsx:65`. Seven divergences already
+decided — the table in Part A is the spec, the prototype renders it. Tier 3, both reviewers, rendered
+gate applies, minor version `2.39.0`. App adoptions are separate WOs. Follow `orchestrate-codex`.

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.