White fill, 1px --gray-5, 5px radius, a 48px header at 0 16px, and 16px of content padding. The source writes this recipe three times with no shared class — in Module, ModuleCta and FormFieldArray/FormField — so components.css carries it once as .rt-card with modifiers. Two genuine differences are preserved rather than normalised away: the header's bottom rule is --gray-6 in Module but --gray-5 in FormField, and the header title is h5 in Module and ModuleCta but h4 in FormField. ModuleCta is the shell with no header or content at all — the 48px height and side padding sit on the box itself. Note the radius: 5px, the button radius, not the 7px input radius, and not dealer-controlled.

A 24×24 single-cell grid stacking two SVGs, last child on top. Five statuses render four ways: Done and Protected are identical — the ring in --green-1 with a check circle; Incomplete keeps the default --gray-6 ring and pins a green sweep top-right (align-items: flex-start; justify-items: flex-end); Default and Started show the orange start tick, with Default nudged left: 1px. The three glyphs are the repo's own SVG components (ProgressIcon, ProgressIncompleteIcon, ProgressStartIcon), copied verbatim into assets/icons — not redrawn. The widget inlines them as React components; this twin loads them as files, which is why ModuleStatus takes a base path.

InfoBox is an outline, not a fill: 8px padding, a --blue-1 border, var(--border-radius) corners — note the non-dealer-facing token — and exactly two strings, h5 then body3, both --blue-1. Divider is 1px of --gray-6, the same weight as a card's header rule. Disclaimer is body4 in --gray-3 with --blue-1 links, and its flex-grow: 1 plus align-content: flex-end is load-bearing: inside a flex-column step it absorbs the leftover height and pins the text to the bottom of the tray. Chip lives at components/app/Chip, not common: 8px radius (the only 8px corner in the system, off the --r-* scale), 8px 12px padding, an 8px gap, background: none and color: inherit. Removable chips are a button with a leading xmark and a gray-5 → gray-3 border on hover; read-only chips are a span with no hover at all.

The one off-palette component. 236px max-width, 10px radius (the only 10px in the system), 64px min-height, 16px 0 padding, a --blue-2 border and z-index: 1. Its fill is radial-gradient(100% 685.61% at 100% 52.63%, #007aff 0%, #3f9bff 45.83%, #005abd 100%) over linear-gradient(0deg, #e5f2ff, #e5f2ff), with a 0 0 32px #007affcc glow. Every one of those hexes is a literal in the source and in no token file, and the same blue family recurs on the date day buttons, the payment-options surfaces and the range and credit-score sliders. Recorded here as a tokenisation candidate for upstream — not a twin deviation: copied verbatim because the code is the source of truth. Text is h3 over h6 in white, or a single h4 for the pending state, which is what shows if either amount or description is missing.

ValueBox paints its text Color.White, which resolves to var(--white) — and in dark mode that token is #1e1e1e. Its fill is a hard-coded gradient that does not change with the theme, so in dark mode the amount renders near-black on a bright blue gradient. Mirrored as written: this is an upstream bug, not a twin choice. The same pattern affects every component that paints var(--white) text on a fill that holds across themes — Pill type="primary" (white on --blue-1), the Radio Recommended badge (white on --blue-1), and RadioLargeButton's label (white on --blue-1 / --green-1). All four invert. Primary Button is safe because its text falls back to a literal #ffffff, not the token; secondary Button is safe by accident, since its fill (--gray-0) and its text (--white) flip together.