@micha.bigler/ui-core-micha 3.14.3 → 4.0.0

package/work-orders/THEME-6.md

@@ -1,247 +0,0 @@
-# THEME-6 — An app-side check for `sx` values the theme already gives
-
-**Target repo:** `ui-core-micha` (branch `main` — this repo has no `develop`)
-**Tier:** 3 (shared core)
-**Review:** independent `reviewer` — mandatory (new logic). **`ui_reviewer` does not apply**: this WO
-adds a check and fixes nothing, so no rendered output changes. If that turns out to be false, it
-applies after all.
-**Version target:** the next **minor** after the published version — a new exported check is additive
-API. Read the published version at implementation time.
-**Strand:** `DS-18`, the app-side half. Trigger fired when cockpit adopted `createAppTheme` (`UI-6`);
-deferred once because cockpit was mid-rebuild in `UI-3`, **which has since landed.**
-
----
-
-## A. Envelope
-
-### Goal
-
-`THEME-4` made it mechanical that no **kit** component defeats the baseline. Apps have no equivalent:
-cockpit alone carries **464 `sx` props across 37 files** (measured 2026-08-11), and nothing checks any
-of them against the theme they sit on.
-
-Give apps an exported check they call from their own suite, the way they already call
-`assertThemeComplete`.
-
-### This is NOT a port of `THEME-4`, and getting that wrong would flood the app
-
-In the **kit**, an `sx` value that duplicates a baseline default is a bug by definition: the default
-becomes inert for every consumer. So `THEME-4` compares **key sets** and demands disjointness.
-
-In an **app**, `sx` beating the theme is **the intended mechanism** — that is how a screen customises
-one instance. A key-collision check over 464 props would flag mostly legitimate customisation, get
-blanket-exempted, and become the no-op `THEME-4`'s own WO warned about.
-
-**So the app-side rule is different: flag an `sx` value that is *equal* to what the theme already
-resolves for that component and property.** Not "you overrode a default" — "you re-stated a value you
-already had". That is dead weight which **silently diverges the next time the token changes**, which is
-the real failure mode and the one worth a check.
-
-Grounded in cockpit, measured: `borderColor: 'divider'` (×2) and `bgcolor: 'background.paper'` (×3) on
-surfaces whose theme already sets exactly that, and `borderRadius: 1` (×3) which resolves to the
-baseline's own `shape.borderRadius`. Those are the findings this check exists for.
-
-### Scope
-
-**1. An exported check, source-level.** Same finding contract as its siblings
-(`{ findings: [{ surface, reason }] }`), same shape as `reportThemeAdoption` and
-`reportOffPaletteColours`: it takes the app's own sources plus its theme, and returns findings. The app
-globs its `src/**` in its own test and passes them.
-
-For each `sx` entry it can attribute to a MUI component the theme styles, resolve what the theme gives
-for that property and flag **equality**. The attribution comes from the JSX element name in the source
-text — `<Paper sx={{ borderRadius: 1 }}>` → `MuiPaper` → compare against
-`theme.components.MuiPaper.styleOverrides.root.borderRadius`.
-
-**2. Report-only, with a ratchet.** New findings must not turn a green app red on a pin bump. Ship it
-**report-only**, and let each app make it a hard assertion in its own cleanup WO — the same ratchet
-`DS-2` used for `assertThemeComplete`, and for the same reason.
-
-**3. Run it against cockpit and report the count. Fix nothing.** cockpit is the first real consumer and
-the reason the trigger fired. The cleanup is cockpit's own work order, not this one — bundling an
-unbounded app cleanup into a shared-core WO is what `AUTH-4` was split out of `DS-11` to avoid.
-
-### Reuse, do not rebuild — and one gap in the reuse
-
-**The hardcoded-colour half already exists and is already app-callable.**
-`reportOffPaletteColours(sources, { palette })` (`themeCompleteness.js:759`) takes sources and an
-optional palette, so an app can pass its own files and its own palette today. cockpit's
-`bgcolor: '#fff'` (×2) is exactly what it reports. **Do not duplicate it.**
-
-**But its skip pattern assumes ucm's layout.** It skips paths matching `src/theme/` — with a trailing
-slash (`:768`). ucm's tokens live in `src/theme/tokens.js`; an app's theme is usually
-`src/theme.js`, which **does not match** and therefore gets scanned, so every identity token in it
-(cockpit: `#3D5A99`, `#eff2f7`, `#e4e8f1`, …) would be reported as off-palette.
-
-Resolve it **app-side**, not by widening the pattern: the app excludes its own theme file from the
-sources it passes. That keeps ucm's behaviour unchanged and puts the knowledge where the layout is
-known. Say so in the check's doc comment so the next app does not rediscover it.
-
-### The bound, and it is open
-
-Attribution from source text is a **heuristic**. It will miss `sx` on a variable, spread props, an
-aliased import (`import { Paper as Surface }`), a `styled()` component, and a MUI component rendered
-through `component={...}`. **Write the bound as open — "unknown attribution gaps remain" — not as a
-list.** `THEME-4`'s WO enumerated its limits and the first real miss (shorthand alias spelling) was not
-on the list; `THEME-5` was told to phrase it openly and that phrasing then held when the fourth
-shadowing layer appeared. An enumeration reads as coverage.
-
-This check is a lower bound on redundancy, and green means "nothing found by this method".
-
-### Non-goals / do not touch
-
-- **No fixes anywhere.** Not in cockpit, not in the kit. This WO ships a check and a count.
-- **No change to `reportOffPaletteColours`**, `assertKitSxDisjoint`, `reportKitSxBypasses`,
-  `reportThemeAdoption` or `assertThemeComplete` — including no widening of the `src/theme/` skip.
-- **Not a hard assertion anywhere yet.** Report-only; the ratchet is each app's own.
-- `DS-18`'s remaining half — "which components *can violate* a rule", derived from a
-  `grep 'shadows\['` lower bound — stays out and stays without a driver.
-- No baseline token, component default or public prop change.
-
-### Risks
-
-- **False positives are the failure mode**, not false negatives. A check that flags legitimate
-  customisation gets switched off. That is why it compares values rather than keys, and why it ships
-  report-only.
-- **The count from cockpit may be large.** 464 props is the denominator. If it is large enough that no
-  app could plausibly act on it, that is a finding to report — the check may need a narrower first
-  scope (e.g. only the ~23 component keys the baseline actually styles) rather than shipping noise.
-- **No staging net.** A version bump on `main` publishes; the independent review is the only gate.
-- **Other sessions are frequently active in this repo.** Read `git status` and
-  `git log origin/main..HEAD` before reviewing; this strand has had concurrent work in the same files
-  throughout.
-
-### Required tests to WRITE
-
-1. **Non-vacuity:** a fixture source with `<Paper sx={{ borderColor: 'divider' }}>` against a theme
-   whose `MuiPaper` already sets `borderColor: divider` produces a finding naming the file, line,
-   component and property.
-2. **The legitimate case produces nothing:** the same fixture with a *different* value
-   (`borderColor: 'error.main'`) is **not** flagged. This is the test that keeps the check usable.
-3. A component the theme does not style is not flagged at all.
-4. The finding shape matches its siblings, so a consumer handles one contract.
-5. `reportOffPaletteColours` is unchanged — its existing tests stay green untouched.
-
-Plus `tsc -p tsconfig.build.json --noEmit` clean. **No full-suite run** — affected set is the theme
-module's specs.
-
-### Verification
-
-No rendered surface. The evidence is test 1 plus the cockpit count, reported in the register note with
-the exact number and a sample of what it found. A check nobody has run against real code is not
-verified, however green its fixtures.
-
-### Parity guardrail
-
-Nothing renders differently. No existing check changes behaviour.
-
----
-
-## 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.** Fallback to direct Claude implementation only on Codex quota/rate-limit/non-zero exit —
-> and that flips authorship, so the independent `reviewer` stays mandatory either way.
->
-> **Do NOT edit `WORK_ORDERS.md`.** Before your own review read `git log origin/main..HEAD` and
-> `git status`, and check the register row carries no review claim you did not make yourself.
-
-### Context package
-
-**Precondition confirmed:** `SHELL-6` landed and published (`f119b70`/`3b746d4`, `package.json` reads
-`2.37.1`). Clean starting tree.
-
-**Reusable primitives already in `src/theme/themeCompleteness.js` — do not rebuild these:**
-- `getPath(value, path)` (`:13-15`) and `sameValue(left, right)` (`:17-21`) — exactly what "resolve
-  what the theme gives for that property and flag equality" needs; both already handle the
-  string/JSON-stringify comparison this check requires.
-- `BASELINE_STYLED_MUI_COMPONENTS` (`:484-508`, 23-entry list), `jsxOpeningTag(source, start)`
-  (`:510-530`, returns the full `<Tag ...>` text starting at a match) and `topLevelSxValue(tag)`
-  (`:532-553`, extracts the raw `sx={...}` attribute text, top-level braces only) — the exact
-  tag-scanning machinery `reportKitSxBypasses` (`:560-`) already uses. Reuse the same
-  `<(${componentPattern})\\b` regex approach for finding tags; you will need a NEW small parser to
-  walk `topLevelSxValue`'s result and extract individual top-level `property: value` pairs from a
-  literal object (`{ borderColor: 'divider', p: 2 }` → `[['borderColor', "'divider'"], ['p', '2']]`) —
-  this doesn't exist yet, write it narrowly (top-level only, matching the existing lower-bound
-  philosophy; do not attempt to parse nested objects, media-query keys, or `theme =>` callbacks).
-- `reportOffPaletteColours`'s `normalizedSources`/path-skip pattern (`:747-753`, `:768-769`) — same
-  `{ path, source }` input shape, reuse `normalizedSources` directly, do NOT touch or widen its
-  `/(^|\/)src\/theme\//` skip (Non-goal, explicit).
-
-**A real discrepancy found while preparing this map, worth resolving deliberately rather than
-silently — the WO's own "grounded in cockpit" evidence does not match its own stated attribution
-method:** the cited `borderColor: 'divider'` (×2), `bgcolor: 'background.paper'` (×3, one is inside a
-`'&:hover'` nested selector), and `borderRadius: 1` (×3) all live in
-`cockpit/frontend/src/cockpit/ChatView.jsx:75,82,95`, on **`<Box component="button" sx={{...}}>`** —
-verified directly, not assumed. `Box` is not in `BASELINE_STYLED_MUI_COMPONENTS`, and the WO's own
-"Scope" section describes attribution purely by JSX tag name (`<Paper sx=...> → MuiPaper`), while its
-own "bound" section separately, explicitly lists a component rendered through `component={...}` as a
-KNOWN, ACCEPTED GAP. **These two things conflict**: the check as scoped will NOT catch the WO's own
-cited grounding examples. Meanwhile, cockpit's actual `<Paper>`/`<Card>`/etc. usages elsewhere
-(`HeaderStrip.jsx`, `KnowledgeView.jsx`, `SettingsView.jsx`, and others) mostly use **template-literal**
-sx values like `` border: `1px solid ${palette.divider}` `` — a JS expression referencing cockpit's own
-imported `palette` object, not a plain string literal — which a source-level literal-value parser also
-cannot resolve to "equals the theme's value" without evaluating arbitrary JS.
-
-**Resolve this by NOT expanding scope to chase the cited numbers** (that would be exactly the
-"enumeration reads as coverage" mistake the WO warns against, applied to attribution instead of the
-bound's phrasing) — implement the check exactly as scoped (tag-name attribution, literal `'string'`/
-`"string"`/numeric sx values only, skip anything that isn't a simple literal — a template literal,
-identifier reference, or expression is out of scope and simply produces no finding for that property,
-same lower-bound philosophy as every sibling check). **Then, when running it against cockpit for the
-required count and sample, report what it ACTUALLY finds — which may be zero, or may differ from the
-Envelope's cited 2+3+3 — and say so explicitly in the register note as a correction to the Envelope's
-own grounding claim**, the same way prior WOs in this strand corrected their own stale counts
-(`THEME-4`'s "51 files", `SHELL-4`'s "ten to six"). Do not silently match the cited numbers by quietly
-special-casing `component=` or template-literal parsing to make them fit — if the honest run finds
-different examples (or none) on properly-attributable tags, that is the real, reportable result.
-
-**Where to add the new export:** same file, `src/theme/themeCompleteness.js`, alongside its siblings.
-Suggested name (Codex's call, keep it short and consistent with `reportKitSxBypasses`/
-`reportOffPaletteColours`): `reportRedundantThemeValues` or `reportAppSxRedundancy`. Same
-`{ findings: [{ surface, reason }] }` contract; `surface` should follow the sibling convention
-(`${path}:${line}.${property}` or similar — check `reportOffPaletteColours`'s `${path}:${line}.colour`
-shape for the exact precedent). Export it from `src/theme/index.js` and `src/index.js` (follow the
-existing export-list pattern in both — this is additive public API, matching the "next minor" version
-target).
-
-**Signature, per Scope item 1 + 2:** `reportRedundantThemeValues(sources, { theme })` — takes the
-app's own sources (same `{path, source}`/string-array shape as siblings) and a **resolved theme
-object** (an app passes its own `createAppTheme(...)` result, or — for ucm's own required tests — a
-theme built the same way `assertKitSxDisjoint`'s tests do). For each JSX tag matching
-`BASELINE_STYLED_MUI_COMPONENTS`, for each top-level literal `property: value` pair in its `sx`,
-resolve `theme.components.Mui<Tag>.styleOverrides.root.<property>` via `getPath` and flag if
-`sameValue(parsedValue, themeValue)` — matching value AND matching property AND matching component,
-report-only (no exemption arm needed per the WO — this ships report-only with no hard-assertion path
-yet, so skip building an exemption contract this round, that's each app's own future ratchet WO).
-
-**Running it against cockpit (Scope item 3, required for the register note):** cockpit's frontend
-source lives at `C:\Users\biglmi\Documents\webapps\cockpit\frontend\src` (37 `.jsx` files, confirmed).
-Glob it (a small Node script or a throwaway test-like harness is fine — this does not need to be a
-committed cockpit-side test, just evidence for the register note) the same way `reportOffPaletteColours`'s
-own `'keeps current kit source free of hard off-palette findings'` test globs `src/` — exclude
-`cockpit/frontend/src/theme.js` explicitly from the sources passed (per Scope's "resolve it app-side"
-instruction — do NOT widen `reportOffPaletteColours`'s or this new check's own skip pattern to do it).
-Build the theme via cockpit's own `createAppTheme(...)` call if one exists (check `theme.js` for the
-palette it passes), or a reasonable equivalent. Report the exact count and 2-3 sample findings in the
-register note, per Verification's explicit requirement — a check nobody has run against real code is
-not verified.
-
-**Invariants:** no fix in cockpit or the kit; no change to `reportOffPaletteColours`,
-`assertKitSxDisjoint`, `reportKitSxBypasses`, `reportThemeAdoption`, or `assertThemeComplete`; no new
-baseline token; no hard assertion anywhere (report-only only).
-
-### Mini-handover
-
-Repo: `ui-core-micha` (`C:\Users\biglmi\Documents\webapps\ui-core-micha`), branch `main`.
-WO: `work-orders/THEME-6.md`. Follow `orchestrate-codex`.

package/work-orders/THEME-7.md

@@ -1,82 +0,0 @@
-# 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

@@ -1,211 +0,0 @@
-# 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.