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

package/work-orders/NOTIF-13.md

@@ -1,142 +0,0 @@
-# WORK ORDER NOTIF-13 (ui-core-micha + django-core-micha) — Layer-1 transport extraction
-
-**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`, prompt passed as a positional argument from this
-file. Fall back to direct Claude implementation only on Codex quota / rate-limit / non-zero exit.
-
-Feature-level WO (Expertenchat envelope). The seams below are **verified against the landed code**
-(ucm 2.12.0, dcm 2.32.0) and are the required scope. The Orchestrator fills the exact line map.
-
-## TIER
-Tier 2 — restructures a provider that **cockpit consumes in production**, and changes a WebSocket
-message contract shared across apps. Independent `reviewer` mandatory. Per AGENTS.md Tier 2,
-`sec_reviewer` is NOT auto-included; request it only if the operator asks.
-
-## GOAL
-Turn ucm's notification-only socket into a generic **Layer-1 realtime primitive**: one socket,
-subscribe-by-message-type, so a second domain (messaging) can ride it without being misread as a
-notification. **Additive**: `NotificationsProvider` remains the sole mount point and its public
-context value is unchanged (operator decision 2026-07-29).
-
-## EXPECTED OUTCOME
-- ucm exports a `useRealtime()`-style subscribe primitive alongside the unchanged `useNotifications()`.
-- An unknown/unsubscribed message type is **ignored** instead of being appended to the notification feed.
-- No app has to change its provider tree. cockpit and jg keep working untouched.
-- NOTIF-15 (jg bell adoption, retiring jg's local context) becomes implementable; Phase B messaging
-  gets its substrate.
-
-## CONTEXT PACKAGE — verified current state
-
-**ucm `src/notifications/NotificationsProvider.jsx` (232 LOC)** owns *both* the socket and the
-notifications domain state:
-- socket ownership: `socketRef`, `connect()`, exponential backoff `INITIAL_BACKOFF_MS` 1s →
-  `MAX_BACKOFF_MS` 30s, auth-gated effect keyed on `[authenticated, refresh, replaceNotifications, wsUrlBase]` (`:87-179`).
-- `handleMessage` (`:103-133`) dispatches on exactly **one** envelope type, `notification.status` (`:111`).
-- **The blocker:** everything else falls through to `normalizeNotificationPush(data)` and is appended
-  to the feed with `unreadCount + 1` (`:130-132`). A messaging payload on this socket becomes a fake
-  notification today.
-- **Field overload — the reason a third stream cannot simply be added:** in the status branch
-  `data.type` is the *envelope* type; in the new-notification branch `normalizeNotificationPush`
-  reads `data.type` as the *domain* notification-type key (`:25`). One field, two meanings. The
-  envelope contract must resolve this without breaking either reading.
-- WS URL hardcoded to `/ws/notifications/` (`:36`, `:40`).
-- exports in `src/index.js:48` (`NotificationsProvider`, `useNotifications`).
-
-**dcm transport is ALREADY generic — correct the roadmap wording here.** The roadmap §4 calls for a
-"dcm multi-stream consumer"; that overstates the dcm work:
-- `notifications/delivery.py::push_to_users(users, payload)` (`:20-43`) fans an **arbitrary** payload
-  into the per-user group `notifications_user_{id}`.
-- `notifications/consumers.py::NotificationConsumer.message()` (`:21-22`) is `send_json(event["payload"])` —
-  fully stream-agnostic. jg's messaging **already** rides this same group via `push_to_users`.
-- The only dcm-side envelope producer is `notifications/views.py:235` (`"type": "notification.status"`);
-  the contract is documented at `views.py:3`.
-- **So the dcm work is the envelope contract + a thin authoring helper + doc — NOT a consumer rewrite.**
-
-**Reference implementation to promote:** jg's `frontend/src/context/NotificationsContext.jsx` (91 LOC,
-docstring "WebSocket owner only") already does exactly this multiplexing with
-`registerMessageCallback` / `registerChatCallback`. Read it for the shape. **Do not edit jg here.**
-
-## SCOPE
-
-**A. ucm — extract the socket into an internal realtime core.** Single owner; preserve the existing
-backoff, reconnect, auth-gating and cleanup semantics **verbatim**. Expose
-`subscribe(type, handler) -> unsubscribe`.
-
-**B. ucm — `NotificationsProvider` becomes the first subscriber.** It registers handlers for the
-notification envelope types. Its returned context value stays **exactly**
-`{ notifications, unreadCount, markSeen, markDismissed, markDone, refresh }`.
-
-**C. Envelope contract.** Introduce an explicit envelope discriminator that does not collide with the
-domain `type` field (see the field-overload note above). Unknown / unsubscribed envelope types are
-**ignored** — the catch-all at `:130-132` dies. This is a deliberate behaviour change and must be
-called out in the CHANGELOG.
-
-**D. Backward compatibility in BOTH directions** — apps pin dcm and ucm independently, so mismatched
-versions are normal:
-- *new ucm + old dcm* (payload has no envelope field): must still be recognised as a new notification,
-  exactly as today. Without this the feed silently goes dead against an un-bumped backend.
-- *old ucm + new dcm*: dcm must keep emitting the legacy fields so a ucm 2.12.0 client is unaffected
-  (**cockpit runs 2.12.0 in staging/prod**).
-
-**E. dcm — formalize the contract.** Document the envelope next to `views.py:3` and add a thin
-authoring helper so producers stop hand-rolling the dict. `push_to_users`'s signature stays unchanged.
-
-## DO NOT TOUCH
-- **jg-ferien** (`NotificationsContext.jsx`, `MessagingContext.jsx`) — that is NOTIF-15.
-- The messaging domain itself — Phase B (`MSG-*`).
-- `NotificationBell.jsx`, `NotificationSettings.jsx`, `feedApi.js`, the `feed/*` REST contract.
-- `BaseSecureConsumer` / S112 permission model, `IsAuthenticatedWs`, the group name `notifications_user_{id}`.
-- **No standalone `RealtimeProvider` export that apps must mount.** Operator decision 2026-07-29:
-  additive only. A standalone provider is a later, separate WO if a second consumer ever needs it.
-- Reconnect/backoff semantics and the single-socket-owner invariant — preserve, do not "improve".
-- Schema, migrations, dependencies, CI.
-- **No app pin bumps** in this WO (cockpit/jg stay where they are).
-
-## RISKS
-- **Silent feed death** if C lands without D: an envelope-less payload from an older dcm would be
-  ignored instead of shown. D is not optional.
-- **cockpit is a live consumer** at ucm 2.12.0 — any change to the returned context shape breaks it.
-- **Subscription leaks / double delivery:** `subscribe` must return a stable unsubscribe, and handlers
-  must **survive reconnects** without the caller re-registering them.
-- **Reconnect loop:** the socket effect currently depends on `refresh` / `replaceNotifications`;
-  moving the socket out must not make the socket re-create on every feed update.
-
-## REQUIRED TESTS / ACCEPTANCE
-ucm runs `vitest` (`pnpm test`) and has **no tests under `src/notifications/` today** — this WO adds
-the first ones:
-- an unknown envelope type is ignored: feed and `unreadCount` both untouched (the regression that
-  protects messaging from being misread as a notification);
-- two subscribers on distinct types each receive only their own messages, from **one** socket —
-  assert exactly one `WebSocket` was constructed;
-- `unsubscribe` stops delivery for that subscriber and does not affect the others;
-- handlers keep receiving after a close → backoff → reopen cycle, with no re-registration by the caller;
-- a legacy envelope-less payload still lands in the feed (backward-compat D);
-- `notification.status` handling and the `unreadCount` delta are unchanged — this guards the NOTIF-6
-  R1 fix (badge went stale after a cross-device mark);
-- `NotificationsProvider`'s public context value is unchanged.
-
-Plus `pnpm build` (tsc) green. If E lands in dcm, run the dcm notifications `pytest` package.
-
-## RELEASE
-ucm minor bump + publish (publish-from-main). dcm only if E lands there — then publish-from-main with
-a **registry live-check before any app pin bump**. No app pin bumps in this WO.
-
-## TARGET REPO / WORKING DIRECTORY
-- Primary: `C:\Users\biglmi\Documents\webapps\ui-core-micha`
-- Secondary (scope E only): `C:\Users\biglmi\Documents\webapps\django-core-micha`
-- Never the workspace root `…\webapps`.
-Both are platform repos: commit directly to the trunk, no feature branches.
-
-## PROGRESS CONTRACT
-Emit a `PLAN: <step1> | <step2> | …` line up front, then a single-line
-`PROGRESS: [<n>/<total>] <present-tense action>` **before every relevant action** (file opened, file
-edited, command/test run) and `PROGRESS: [<n>/<total>] done` on step completion, spaced so no gap
-exceeds ~2 min. stdout unbuffered. Exactly one final `RESULT: DONE|BLOCKED <reason>`.
-
-## MINI-HANDOVER (paste into a fresh Orchestrator session)
-```
-Orchestrator: implement work-orders/NOTIF-13.md in ui-core-micha (main; scope E also touches
-django-core-micha). git pull first, read the WO, then follow orchestrate-codex (Codex-first, own
-independent review, commit on green).
-```

package/work-orders/NOTIF-14.md

@@ -1,151 +0,0 @@
-# WORK ORDER NOTIF-14 (ui-core-micha) — push-preview toggle in NotificationSettings
-
-**EXECUTION DIRECTIVE.** If you are the implementer reading this as your own spec, 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`. Orchestrator: 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`, prompt passed as a
-positional argument from this file. Fall back to direct Claude implementation only on Codex quota /
-rate-limit / non-zero exit.
-
-Feature-level WO (Expertenchat envelope). Companion to `django-core-micha`'s `work-orders/MSG-13.md`
-(landed `39135e9` on dcm `main`), whose Scope E explicitly said: "The `Switch` in `ui-core-micha`'s
-`NotificationSettings.jsx` is a companion change and is NOT deliverable from this repo — flag it in
-the completion note so a `ui-core-micha` WO gets written." This is that WO.
-
-## TIER
-Tier 2 — this repo IS a shared-core surface (`ui-core-micha`), which per AGENTS.md forces Tier 2
-regardless of change size. Independent `reviewer` mandatory. No `sec_reviewer` needed: the security
-question (should message content go in a push at all) was already ruled by the operator in dcm's
-MSG-13; this WO only wires an existing, already-shipped backend preference into the existing
-settings UI — no new exposure, no new endpoint, no new data crossing a trust boundary.
-
-## GOAL
-dcm's MSG-13 added a per-user account-level preference, `NotificationPreference.push_preview_opt_in`
-(default `True`), already exposed read/write on the existing `notifications/preferences/` endpoint
-(`NotificationPreferenceSerializer` fields: `email_opt_in`, `push_opt_in`, `push_preview_opt_in`).
-When off, dcm's `PushDispatcher` sends a content-free push body (no sender name, no message text) —
-the notification still arrives, but its preview is hidden. Nothing in ucm reads or writes this field
-yet, so a user has no way to turn it off (or back on) — a per-user preference sitting dead on the
-backend with no UI path to reach it.
-
-## EXPECTED OUTCOME
-- `NotificationSettings.jsx` gains a third toggle, alongside the existing email/push `Switch`es,
-  bound to `push_preview_opt_in` via the same generic `patchNotificationPreferences()` call already
-  used for the other two (no new API function needed — see Context Package).
-- The toggle reflects the loaded preference correctly, **including the default-on case**: a fresh
-  account (or a preferences payload predating this field) has never set `push_preview_opt_in`
-  explicitly, and this MUST still render as checked/on. `Boolean(preferences?.push_preview_opt_in)`
-  — the pattern the existing two switches use — is **wrong** here, because `Boolean(undefined) ===
-  false`; that would silently show "preview off" for a user whose real, backend-defaulted state is
-  "preview on" (the exact class of default-mismatch bug MSG-13 itself was about, one level up).
-  The correct check is `preferences?.push_preview_opt_in !== false`.
-- Toggling calls `patchNotificationPreferences({ push_preview_opt_in: <bool> })` and updates local
-  state from the response, mirroring `handleEmailToggle`'s existing shape exactly (loading flag,
-  error handling, no confirmation dialog).
-- **UX placement decision (Expertenchat call, confirm or override at Approval Gate #1):** render the
-  preview toggle directly under the push toggle (same `Box`/`Divider` block, not a new section), and
-  **disable it when push notifications are not actually enabled for this account**
-  (`!preferences?.push_opt_in`) — a preview setting is meaningless when no push is being sent at all,
-  and leaving it enabled-but-inert invites a user to "fix" a push they never receive by toggling a
-  setting that does nothing. Gate on the account-level `push_opt_in` (matches dcm's own
-  `is_channel_enabled` gate for the `push` channel), not on this device's `pushSubscribed` — a user
-  with push enabled on another device but not this one should still be able to manage their preview
-  preference here.
-
-## CONTEXT PACKAGE — verified current state
-
-**`src/notifications/NotificationSettings.jsx`** (194 lines) already renders two independent
-preference switches against the same preferences object:
-- `handleEmailToggle` (`:81-93`) — the exact shape to mirror: `setSavingEmail(true)` →
-  `patchNotificationPreferences({ email_opt_in })` → `setPreferences(updated)` → catch sets
-  `error` → `finally` resets the saving flag.
-- The push switch (`:176-187`) is more involved (subscribe/unsubscribe device flow) — **do not
-  mirror that one**, the preview toggle is a plain preference flip like email, not a device
-  subscription.
-- `preferences` state (`:37`) is the raw object returned by `getNotificationPreferences()`
-  (`GET /api/notifications/preferences/`) and updated in place by
-  `patchNotificationPreferences()` (`PATCH`, same URL, generic passthrough — accepts any subset of
-  serializer fields, **no new API function needed**, see `src/notifications/api.js:6-13`).
-- Render block to extend is `:162-188` (the email `Box`, a `Divider`, the push `Box`). Add a third
-  `Box` with a `FormControlLabel`+`Switch`, same structural pattern as the email one (`:163-168`) —
-  `checked`, `onChange`, `disabled`, then a label with a primary `Typography` + a `caption`
-  `Typography` hint underneath.
-
-**`src/notifications/api.js`** — `patchNotificationPreferences(patch)` (`:11-14`) is a bare
-passthrough `PATCH`; no change needed here.
-
-**i18n**: `src/i18n/notificationsTranslations.ts` — existing `NotificationSettings.*` keys (`:5-19`)
-cover `EMAIL_LABEL`/`EMAIL_HINT`/`PUSH_LABEL`/`PUSH_HINT` etc. across four languages (`de`, `fr`,
-`en`, `sw`). Add two new keys, e.g. `NotificationSettings.PUSH_PREVIEW_LABEL` and
-`NotificationSettings.PUSH_PREVIEW_HINT`, in the same four-language shape. The hint text should say
-what changes when off (no sender name or message text in the push body — the message itself still
-arrives) without needing to explain the underlying push-encryption reasoning from dcm's MSG-13 (that
-belongs to dcm, not this UI copy).
-
-**Tests**: `tests/NotificationSettings.test.jsx` already mocks `../src/notifications/api` in full
-(`:6-13`) and stubs `react-i18next` to return raw keys (`:16`) — extend the existing
-`getNotificationPreferences`/`patchNotificationPreferences` mocks, do not add a new mock module.
-
-## NON-GOALS / DO NOT TOUCH
-- Do not touch the push subscribe/unsubscribe device flow (`handleEnablePush`/`handleDisablePush`,
-  `:95-144`) or anything in `getPushSupport`/`getIosInstallState`.
-- Do not touch `django-core-micha` — the backend half (field, migration, serializer, dispatch gating)
-  already shipped in dcm MSG-13 (`39135e9` on `main`). This WO is UI-only.
-- Do not add a confirmation dialog or any new component beyond the one additional `Switch` block —
-  match the existing two switches' bare, no-confirmation UX exactly.
-- Do not change what dcm's push body renders when the preference is off (already correct and
-  reviewed in dcm MSG-13) — this WO is only "can the user reach the setting", not the setting's effect.
-
-## RISKS
-- The `Boolean(...)` vs `!== false` default-mismatch trap above is the main risk in this WO — call it
-  out explicitly in the PR/commit and in the required test, since it is easy to copy-paste the
-  existing `Boolean(preferences?.push_opt_in)` pattern without noticing the two fields have opposite
-  defaults (`push_opt_in` defaults `False` on the backend, `push_preview_opt_in` defaults `True`).
-- Low blast radius otherwise: one existing, already-authenticated, already-scoped-to-`request.user`
-  endpoint; no new permission surface; additive UI only.
-
-## REQUIRED TESTS TO WRITE
-Narrow, mirroring `tests/NotificationSettings.test.jsx`'s existing style and mocks.
-
-1. The preview switch renders **checked** when `getNotificationPreferences()` resolves with
-   `push_preview_opt_in: true`, **and also** when it resolves with the field **absent entirely**
-   (the default-on, non-vacuity case — must fail if the implementation uses `Boolean(...)` instead
-   of the `!== false` check).
-2. The preview switch renders **unchecked** when `push_preview_opt_in: false`.
-3. Toggling the switch calls `patchNotificationPreferences({ push_preview_opt_in: <new value> })`
-   and re-renders from the mocked response.
-4. The preview switch is **disabled** when `preferences.push_opt_in` is `false`, and **enabled**
-   when it is `true` — regardless of this device's own `pushSubscribed` state (per the UX placement
-   decision above).
-
-**Non-vacuity:** test 1's absent-field case must fail against a naive `Boolean(preferences?.…)`
-implementation — prove it before considering this WO done.
-
-## TEST SCOPE FOR THE GATE (orchestrator)
-`tests/NotificationSettings.test.jsx` only — no other suite touches this component.
-
-## TARGET REPO
-`C:\Users\biglmi\Documents\webapps\ui-core-micha`. Branch `main` (no `develop` in this repo — verify
-with `git branch -a` before starting in case that has changed). Publish + version bump per the
-repo's release flow if this ships as its own npm release, or bundle with the next ucm release per
-operator direction.
-
-## MINI-HANDOVER (pastable)
-
-> Repo: `C:\Users\biglmi\Documents\webapps\ui-core-micha` (branch `main`). Work order:
-> `work-orders/NOTIF-14.md` — read it fully, then follow the `orchestrate-codex` skill.
->
-> Adds the third `Switch` to `NotificationSettings.jsx` for dcm MSG-13's `push_preview_opt_in`
-> preference (already live on the backend, `django-core-micha` `39135e9`). The one thing that will
-> silently ship wrong if rushed: this field defaults to `True`, opposite of `push_opt_in`'s `False`
-> default — the existing `Boolean(preferences?.field)` pattern used for the other two switches
-> reads a missing/undefined field as `false` and would show "preview off" for every account that
-> never explicitly touched the setting. Use `preferences?.push_preview_opt_in !== false` instead,
-> and make sure the required test proves it (assert checked=true when the field is absent from the
-> mocked API response, not just when it's explicitly `true`).
-
-## PROGRESS CONTRACT
-Emit `PLAN: <steps>` up front, then a single-line `PROGRESS: [<n>/<total>] <action>` before every
-relevant action and `PROGRESS: [<n>/<total>] done` on completion, spaced so no gap exceeds ~2 min,
-stdout unbuffered, and exactly one final `RESULT: DONE|BLOCKED <reason>`.

package/work-orders/PRIM-1.md

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