Design language: status tones, StatusChip, CopyId, palette fixes, and four new primitives

[timurbazhirov]

Summary

Phases 1.5 and 2.3 of the Job Designer UX update (SOF-8023, plan) — but everything here is generic, and the parallel Materials Designer work needs the same pieces. It lands first because the other phases consume it.

Palette defects fixed

paletteDark was skeletal. It spread only the status colors and primary/secondary, never otherOptions — so in dark mode palette.text, action, background, border, icon and unitTypes were all undefined. Anything theming itself from those tokens silently kept light-mode styling, which is the root cause of light panes inside a dark shell. Now completed with dark counterparts of every slot (unit-type hues lightened so they keep their identity on a dark surface).

Status contrastText was unreadable. success.main is a neon green (#72E128) that declared white text — 1.7:1. error.contrastText and info.contrastText were rgba(0, 0, 0, 0.23), i.e. 23%-alpha black, invisible on anything. Each is now whichever ink actually clears 4.5:1 on its own main. No main/light/dark value changed, so this is not a recolor.

No soft surfaces existed. Chips, badges, meters and flag rows need a tinted background plus an ink that survives on it — you cannot get that from success.main alone (as text on white it is 1.7:1). Added palette.statusTones: validated { color, background, border } triples per tone (neutral | primary | info | success | warning | error), per theme.

Colors are computed and asserted, not eyeballed — src/theme/palette/contrast.ts implements WCAG relative luminance with alpha compositing, and tests/palette.tests.ts (73 assertions) holds every ink to 4.5:1 against the surface it is actually painted on, in both themes. My first pass at the chip outlines failed the check and had to be re-derived.

New components

Component	What it is
StatusChip	State pill on the new tones. Icon and label are always present, so status is never color-alone.
JobStatusChip	Same chip with tone/icon/wording resolved from a job status string.
CopyId	An identifier folded behind a copy affordance — short label, full value on hover, copies on click (with a fallback for non-secure contexts where navigator.clipboard is absent).
SelectableCard	One option in a set as a card rather than a row in a dropdown.
MetricTile	A number with what it measures and what it means.
SegmentedMeter	A bar split into named parts of a known whole.
NumericStepperInput	Bounded number entry whose steppers stop at the bounds.

jobStatusPresentation.ts holds the single job-status → tone/icon/label mapping. Worth noting why: @mat3ra/jode currently ships two mappings — JOB_STATUS_CLS() and the Job.statusCls getter — and they disagree about pre-submission (info vs default). Neither covers terminate-queued, timeout or deleted with anything but a default, and neither carries an icon or a human label. This resolves that in favour of a neutral draft and covers all ten statuses.

The four new primitives, and the judgement in each

They exist for the compute redesign (mat3ra/ive#6) but none of them is compute-specific.

• SelectableCard — a dropdown shows one option at a time and hides everything a reader would actually choose between. It renders as a radiogroup of radios, not buttons, so it is heard as a single choice too, and selection carries aria-checked rather than living in the border colour. The selected state thickens the edge with an inset shadow rather than a second border pixel, so choosing does not shift the layout.
• MetricTile — an absent value renders as an em dash, never 0. In an estimate the difference between "we do not know what this costs" and "this costs nothing" is the whole point.
• SegmentedMeter — overflow rescales instead of clipping. Clamping at 100% would draw an over-quota job identically to one that exactly fits, which is the one comparison the meter exists to make. The projected slice is hatched: it has not happened yet.
• NumericStepperInput — the steppers stop at min/max, so nudging cannot produce an invalid value; the helper text can then state the range instead of complaining about it afterwards. Typing past the bounds is still allowed and reported through error — clamping mid-keystroke would turn a typed "64" into "6".

The bound arithmetic and meter geometry are extracted as pure modules (numeric-stepper/bounds.ts, metric/meterGeometry.ts) and unit-tested, because those two rules are exactly what regresses silently.

Other fixes

• ButtonMultiSelect never resynced. It snapshotted buttonConfigs[0] into state on mount, so it kept calling the first onClick closure it ever received — a parent re-rendering with fresh handlers was ignored for the component's lifetime. (job-designer carries a long comment and a workaround for exactly this; that can now come out.) It now tracks the selected id and resolves against the live prop each render. Also: it read from localStorageKey but wrote to a hard-coded "selectedSaveOption", so any instance with a different key forgot the choice on reload. Empty buttonConfigs now renders nothing instead of dereferencing undefined.
• tests/ never ran in CI. npm test was lint && transpile; the directory existed but was dead weight. Added test:unit and wired it in — this revives the existing schemaUtils tests too.

Verification

npm test green: 0 eslint errors on src, tsc clean, 89/89 unit tests. Every new component has a gallery entry and was checked in the running gallery under Light (default) and Dark (MD). Driven in a browser rather than assumed:

• CopyId writes the full id to the clipboard;
• the card group reports one radiogroup with three radios, aria-checked moves on click, and the disabled card is disabled;
• the Nodes stepper clamps at 4 and 1, disables at each bound, and still accepts a typed 99.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DK8KomMescJvMQNSEfeRR8