/* == tokens/tokens.css == */ /* tokens.css — the SINGLE materialisation of design/TOKENS.json. * * Strategy: an ALIAS LAYER, not a rename (see design/PLAN.md §2). This file * does two jobs and nothing else: * * 1. Declares the Design 2.0 palette under its own `--ra-*` names, one * custom property per design/TOKENS.json `colors` entry. * 2. Re-points every LEGACY variable (--bg-0, --pos, --neg, --ch-ax, …) at * a 2.0 value, IN PLACE, under the exact name it has today. No consumer * file is renamed or edited to adopt the palette. * * Rule (design/PLAN.md §9.1): after this file exists, it is the ONLY file in * platform/frontend/ allowed to contain a colour literal. Every other file * reads a var(--…). A dev who needs a colour that does not exist asks the * architect — they do not invent a hex. * * Rule (§9.3): never rename a --ch-* custom property. features/chart/render.js and * features/chart/trade-markers.js read these by literal string name via chTC() * (render.js:94-109); a renamed --ch-* returns "" from getComputedStyle, * `strokeStyle=""` is silently ignored by canvas, and the chart keeps * painting the OLD colour with no build error and no lint error. Only the * VALUE changes here, never the NAME. * * Exempt from token_lint by the tokens.css glob in devstudio.json * (careful: literal "star-star-slash" text here would close THIS comment * early and silently truncate the whole :root block below — it did, once). */ :root { /* ============================================================ 1. Design 2.0 palette — one custom property per design/TOKENS.json `colors` entry (excluding the `legacy.*` group, materialised in section 3 below, right next to the --ch-* names that read them). ============================================================ */ --ra-surface-base: #060A10; --ra-surface-panel: #0D1319; --ra-surface-header: #0D1114; --ra-surface-tape: #15191C; --ra-surface-card: #23282C; --ra-surface-card-elevated: #2A2F33; --ra-surface-subtle: #50565A; --ra-surface-inset: #1C2024; --ra-surface-inset-deep: #080C10; --ra-surface-chip: #1A2332; --ra-surface-scrollbar-track: #262B33; --ra-surface-scrollbar-thumb: #737A85; --ra-surface-overlay: #1E252D; --ra-surface-stat-tile: #1C2635; --ra-surface-table-header: #151F28; --ra-surface-bubble-user: #24282E; --ra-surface-plot: #171D20; --ra-surface-price-chip: #1E2326; --ra-surface-rule-card: #0D1216; --ra-surface-btn-danger: #0B0E14; --ra-surface-black: #000000; --ra-surface-deepest: #010203; --ra-surface-panel-alt: #0D1117; /* S46 task #35 (design/TOKENS.json colors["surface.chip-count"]) — the news duplicate-count chip fill (`×3`/`×2`, NEWS_SPEC_S46.md §5.3), 723:2751 x3. Light value in the [data-theme="light"] block below: this one DOES need a real derivation (not a carried hex) — task #38 measured that carrying #182029 into light passes contrast (5.72:1) but paints a near-black chip on a near-white page, which a ratio can't catch because it isn't a contrast defect. Derived the same way --ra-surface-inset already derives its light value: one tier darker than the page (`var(--bg-2)`), not a from-scratch invention. */ --ra-surface-chip-count: #182029; /* S19 §2.1 (PLAN_S19.md): the frame's `Session Dropdown` component fill, read at EIGHT nodes that all agree -- 450:1087, 451:1165, 451:1168, 450:1080, 451:1209 (Sound Rules 448:1631) and 443:716, 443:724, 443:728 (Replay 443:707). A NEW name, not a reuse of --ra-text-neutral-900 (same hex, #1A1A1A): that token is bound as a TEXT role and consumed as one (widgets.css:1277). Binding a SURFACE role to a TEXT name is how --ra-text-axis was once misread as a chart token -- two tokens sharing one hex under two roles is the existing convention here (--ra-chart-axis / --ra-text-axis, same #606060). design/TOKENS.json colors["surface.field"]. */ --ra-surface-field: #1A1A1A; --ra-border-default: #1A222B; --ra-border-card: #23282C; --ra-border-strong: #1A2332; --ra-border-track: #333840; --ra-border-switch: #202A31; /* S46 task #35 (design/TOKENS.json colors["border.hairline"] / ["border.control"]) — the news row separator (NEWS_SPEC_S46.md §5.1, 723:2751 x19). It measured 1.1-1.2:1 in DARK against a 3:1 non-text floor (task #38, NEWS_CONTRAST_S46.md §6) — task #38 argues the hairline isn't the kind of boundary 1.4.11 covers (a row divider that could be deleted without losing information). NO light override below: the SAME hex measures 15.6:1 / 14.4:1 in light (task #38, carried unchanged) — a dark line reads fine on a light page without any derivation, unlike a dark FILL (see --ra-surface-chip-count above). */ --ra-border-hairline: #23282c; --ra-border-hairline-w: 1px; /* S51 WP6-A: the hairline WIDTH, so a ds/ file can draw a border with no literal */ --ra-border-control: #1B242E; --ra-text-primary: #EEF1F1; --ra-text-secondary: #9AA1A4; /* S32 #42 (owner ruling, S31 task #11 dialog, durable copy S31-R7.2): "the one kind of pixel movement he has approved" — the Figma value failed the readability standard in DARK theme (design-qa's canvas- normalized baseline, design/s32/qa/acceptance/run-20260827T-grey-dark/ grey_baseline_readings.json: worst measured ratio 3.04 against the panel's own lightest real ground, rgb(35,40,44) — 66 elements below 4.5:1 across the six sampled panels). LIGHT theme is untouched (it already passes; its own value lives at widgets.css:1085, a SEPARATE declaration under [data-theme=light]). Derivation, same method as S19-R7's rule-colour set: canvas-normalized (a fillStyle/getImageData round-trip, never a hand oklch-> sRGB formula or a regex — the S16-B1 class of bug design-qa's own first baseline attempt hit and self-caught) binary search on OKLCH lightness, hue 70 / chroma .012 held fixed (the same neutral hue this token's LIGHT-theme sibling already uses, oklch(0.52 0.012 70) — not a new hue invented for dark), walked UP from the old L until the WORST of this token's measured grounds cleared 4.5:1 with a real margin (4.59, not 4.50 exactly — a value sitting on the line re-fails the moment a future ground gets 1 shade darker). oklch(0.65 0.012 70) -> #948E87. Hierarchy re-verified after the raise, canvas-normalized relative luminance: text1 .874 > text2 .350 > text3(new) .274 > text4(new, below) .226 — still strictly decreasing, primary/secondary/tertiary/faint keep their order. */ --ra-text-tertiary: #948E87; --ra-text-muted: #6B7276; --ra-text-bright: #E6EDF3; --ra-text-dim: #6B7A88; /* S32 #42, same ruling and method as --ra-text-tertiary above — measured WORSE (dark floor 2.32 vs tertiary's 3.04, against its own worst ground rgb(20,25,35)). oklch(0.61 0.01 70) -> #87827D (chroma .01, matching this token's own light-theme sibling, widgets.css:1086 — oklch(0.64 0.01 70)). This token ALSO measures below 4.5:1 in LIGHT theme (design-qa's grey-light baseline: worst 2.82-3.37 depending on ground, screener's .scr-chart-tf). NOT fixed here — "light theme untouched" is this task's own explicit boundary, and the owner's ruling was about the dark grey specifically; light theme's failure on this token is a SEPARATE, not-yet-ruled-on defect. Filed, not absorbed: design/s32/dev_a/text4_light_theme_still_fails.md. */ --ra-text-faint: #87827D; --ra-text-subtle: #8B959E; --ra-text-on-accent: #010203; --ra-text-inverse: #FFFFFF; /* Text on a hovered control: pure white on the dark theme, --text-1 on the light one (light block below). --ra-text-inverse itself has no light value: it is also the white that must stay white on solid fills (ticks, tags, buy / sell), so hovers use this instead. */ --ra-text-hover: var(--ra-text-inverse); --ra-text-thumb: #E5EBED; --ra-text-slate: #C7D1DE; --ra-text-slate-dim: #93A6C5; --ra-text-switch-thumb: #62737E; --ra-text-axis: #606060; --ra-text-neutral-300: #A0A0A0; --ra-text-neutral-700: #404040; --ra-text-neutral-900: #1A1A1A; --ra-text-ellipse: #E2E8F0; --ra-text-scrollbar-alt: #667385; --ra-text-checkbox-grey: #596166; --ra-text-vol: #5A626A; /* S46 task #35 (design/TOKENS.json colors["text.inactive"]) — the news absolute-time line (`08:02:41`, 10.5px, NEWS_SPEC_S46.md §5.3) and the search placeholder. NOT a light-derivation case: task #38 measured this hex at 3.28:1 against --ra-surface-panel in DARK, against a 4.5:1 floor for text under 18px — a dark-theme breach that exists before any light value is considered, escalated to the owner as a frame defect (the frame specifies #5C6874 at 10.5px and the frame is dark-only). No override in [data-theme="light"]: the SAME hex measures 5.23:1 in light — carrying it unchanged already passes there, so light is not where the problem is and not where a fix would belong even if one were minted here. Do not correct the dark value on this task's authority. */ --ra-text-inactive: #5C6874; --ra-accent-primary: #0FD4BB; --ra-accent-primary-soft: #7EE0CD; --ra-accent-secondary: #5AA597; --ra-accent-dark: #35A08B; --ra-teal-950: #022F2E; /* design-sync 2026-10-03: Figma teal/950, the empty-state dot grid */ --ra-accent-deep: #1E826E; --ra-accent-tint: #E6FBF7; --ra-accent-blue: #6D9EE0; --ra-accent-blue-deep: #1E6B8A; --ra-accent-blue-ink: #0C4A6E; --ra-semantic-success: #00E676; --ra-semantic-success-alt: #4CAF50; --ra-semantic-warning: #F59E0B; --ra-semantic-error: #F87171; --ra-semantic-error-strong: #EF4444; --ra-semantic-error-deep: #9E3838; --ra-semantic-danger: #FF5252; --ra-semantic-info: #3B99FC; /* S17-R31 -- the ONE token S17 mints beyond --ra-link-ink. Frame 405:193 fills the five OVERLAY row icons #29ABE2 (the five MODE rows are #FFFFFF). It is a raw vector fill in the frame, NOT a design variable: absent from design/TOKENS.json's 135 colours and from this file under any name -- dev-b established that and refused to mint it itself, correctly, this file being frozen to the lead. TWO VALUES, NOT ONE, AND THE REASON IS MEASURED: #29ABE2 is 7.13:1 on the dark popover and 2.62:1 ON WHITE -- under the 3:1 non-text minimum. A single-value mint would have shipped a light-theme defect of precisely the class S17-R26 ruled on. The light value below is OURS, a DECLARED DIVERGENCE (S17-R28 O-1): no light-theme frame exists for any node, so it cannot be frame-derived and is not claimed to be. */ --ra-chart-overlay-icon: #29ABE2; --ra-market-up: #0FD4BB; --ra-market-down: #EF4444; --ra-market-up-bright: #38F2CE; --ra-market-up-bright-alt: #38F2CF; --ra-market-down-bright: #FF5555; --ra-market-up-flow: #00E5C9; --ra-market-down-flow: #FF5376; --ra-market-down-muted: #C96672; --ra-market-down-vivid: #FF5F57; --ra-market-sell: #FF4D6D; --ra-market-buy: #10B981; --ra-market-session-live: #76B900; /* S46 task #35 (design/TOKENS.json colors["signal.bull"/"bear"/"neutral"]) — a NEW category, distinct from --ra-market-* and --ra-semantic-* (existing tokens with different hexes: --ra-market-up #0FD4BB vs signal.bull #35D07F — not the same colour, not a rename target). Two known consumers today, neither built yet: the news impact-bar segments (NEWS_SPEC_S46.md §5.4, graphical, 3:1 floor) and the duplicate-count chip TEXT (§5.3, `×3`/`×2` on --ra-surface-chip-count, 4.5:1 floor — signal.neutral only). Light values below are DERIVED and MEASURED (task #38's numbers + design/s46/qa/rg_colors_s46.js), not carried: all three fail their floor in light if the dark hex is reused unchanged (task #38 §7.3 measured 1.71 / 2.75 / 2.42 against a plain carry). The bull/bear derivation models the impact bar's own tint the same way this file's shipped sentiment pill already tints a signal colour (news.css `.pill.pos`/`.pill.neg`: color-mix(in oklch, COLOR 14%, transparent)) rather than inventing a different assumption for an unbuilt component — when #24 builds the real impact bar, re-verify against its actual CSS, the same way every other section-1e-style modelled value in this file gets re-checked once a real consumer exists. */ --ra-signal-bull: #35D07F; --ra-signal-bear: #F2565F; --ra-signal-neutral: #8C9AA8; --ra-chart-bg: #0D1319; --ra-chart-grid: #1A2332; --ra-chart-grid-sub: #131C28; --ra-chart-axis: #606060; --ra-chart-candle-up: #0FD4BB; --ra-chart-candle-down: #EF4444; --ra-chart-volume-up: #0FD4BB; --ra-chart-volume-down: #EF4444; --ra-chart-ema-fast: #B39DDB; --ra-chart-ema-slow: #5AA597; /* S27-R9 (owner: give EMA-100 its own colour, no longer shared with EMA-21). MINTED, not a Figma verbatim value like its neighbours above — there is no frame for this, it's an ad-hoc owner ruling. A vivid magenta/pink: measured min sRGB distance to every other overlay/ sub-pane line is ~79 (closest is ema50/rsi's shared lavender-purple; every other line is ≥92) — design/s27b/dev-a/ indicator_legend_readings.json task_22 entry has the full table. */ --ra-chart-ema100: oklch(0.72 0.19 340); --ra-chart-vwap: #E5A663; --ra-chart-vwap-line: #F59E0B; --ra-chart-price-line: #7EE0CD; --ra-chart-crosshair: #FFFFFF; --ra-state-hot-bg: #380F0F; --ra-state-hot-border: #6B1F1F; --ra-state-hot-fg: #FF5959; --ra-state-warm-bg: #2E260D; --ra-state-warm-border: #61521A; --ra-state-warm-fg: #FFD940; --ra-state-chip-bg: #00323C; --ra-state-chip-border: #00505A; --ra-state-tag-bg: #112E24; --ra-state-danger-bg: #2D191E; --ra-state-checkbox-blue: #2659A6; /* seal/checkbox (Figma acDx3hoowFphwB8tGtqIPi 3057:26338, ds/atoms/checkbox.css): the Control/* styles plus the fills its Hover / Pressed / Focus / Disabled variants carry. The unchecked fill is --bg-2 (#15191C, Control/Selected). */ --ra-control-checked: #3B82F6; --ra-control-checked-hover: #4F8DF7; --ra-control-checked-pressed: #2F6FD6; --ra-control-checked-focus: #8CB5FA; --ra-control-checkmark: #FFFFFF; --ra-control-checkbox-border: #5F676E; --ra-control-checkbox-hover-bg: #1B2227; --ra-control-checkbox-hover-border: #828A91; --ra-control-checkbox-pressed-bg: #101519; --ra-control-checkbox-disabled-border: #595F6680; /* seal/button Neutral MD (Figma 3057:26180, the Replay Control panel's Play, 3057:26616): its stroke and label. */ --ra-control-button-border: #4B5258; --ra-control-button-ink: #D2D7DA; --ra-state-star: #598CD9; --ra-state-neutral: #D9D9D9; /* S36 OT-3 / OT-4 (design/PLAN_S36.md §11 D14, D15): the session recorder's RECORDING-LIVE chip. Sourced from `seal/chip-status` 233:94's HOT-Hover state in the design file, which the journal frames reuse deliberately rather than minting a new red in Figma. They are NOT the hot pair three lines above -- checked, not assumed: hot is #380F0F / #6B1F1F, these are #240D0D / #471414, and neither value appears anywhere else under tokens/. Minted because a colour cannot be approximated the way a radius can: one pixel of radius is invisible, a wrong red is not. */ --ra-state-rec-bg: #240D0D; --ra-state-rec-border: #471414; /* The record glyph's ink (ring + core) in the header's Record-session chip: `record` inside `seal/chip-tiny` 3020:32651, file acDx3hoowFphwB8tGtqIPi. Minted for the same reason as the pair above — the nearest reds here (market.down-flow #FF5376, semantic.danger #FF5252) are other colours. */ --ra-state-rec-ink: #FF5C7A; /* S36 OT-5 (design/PLAN_S36.md §11 D16): the journal entry-row hover fill -- the accent at 20%. Written as a color-mix over the accent token rather than as a flattened literal so it FOLLOWS the accent instead of drifting from it, and so it needs no second definition in the light-theme block. Literal-free by construction: token_lint's colour regexes match `oklch(`, and `in oklch,` is a colour SPACE argument, never a value. A dev reaching for rgba(53,160,139,.2) is blocked, correctly. */ --ra-state-row-hover: color-mix(in oklch, var(--ra-accent-dark) 20%, transparent); --ra-link-cyan: #0AC6E6; --ra-link-magenta: #F63BF3; /* S13-A6e / owner ruling S13-R44a: blue and purple are a DECLARED DIVERGENCE from 362:1608 (frame-exact there, like the other four). Measured against the panel surface rgb(35,40,44), the frame values scored 1.44 (blue) and 1.36 (purple) -- WORSE than an ungrouped tile's own 2.37, i.e. joining either group made the route marker HARDER to see than not being routed at all. Re-picked at the SAME hue (blue 224.4deg -> 224.0deg, purple 263.5deg -> 263.6deg -- both within 0.5deg, so "reads as blue"/"reads as purple" holds) and raised lightness only, until contrast >= 4.5 against the surface (target per R44a; landed at 4.80/4.79, the same margin the readable four already carry). Mutual distinguishability re-checked pairwise across all six after the move: full readings + the CIELAB deltaE + hue-angle tables in design/s13/dev_a/S13-A6e_evidence.md. Do NOT restore the frame values as a parity fix -- this is the owner's call, recorded here and in design/TOKENS.json (colorSources.link.blue/.purple), same filing as the removed `ribbon` row (design/s13/dev_b/CD755_ribbon_removed.md). */ --ra-link-blue: #6E8FEA; --ra-link-orange: #F97316; --ra-link-yellow: #FACC15; --ra-link-purple: #A87CEC; /* S13-A5 (design/PLAN.md §S13.3.2): the ONE token this session mints. 402:209's selection-ring stroke (strokeAlign OUTSIDE, 1.5px) -- numerically equal to --ra-text-inverse / --ra-chart-crosshair but semantically neither (a selection affordance, not text or a chart element). design/TOKENS.json colors.link.ring carries the same value + provenance. */ --ra-link-ring: #FFFFFF; /* S17-R1 (lead, Addendum S17-A item 1): the ink for a glyph sitting ON a group identity fill, once the group signal moves off the 3px top stripe and onto the link button itself. The ONE token S17 mints. WHY A VALUE AND NOT --ra-text-inverse: the operand underneath is a group IDENTITY colour, not a surface, so the ink must be chosen against six fixed fills rather than against a theme. --ra-text-inverse is #FFFFFF and is ALSO an open owner decision (HANDOFF_S17 §D, the F-13 class remainder) -- binding this to it would make a settled contrast result hostage to an unsettled one. WHY DARK, when the owner's own reference crop (design/owner-reports/ s17-fb-644.png) paints a LIGHT glyph #E6FBF7: measured, his glyph fails BOTH the 4.5:1 text floor and the 3:1 non-text floor on every one of the six group colours (worst yellow 1.42, cyan 1.91). The addendum that carries his order also requires "glyph contrast measured per theme, not assumed", so ratifying the crop's pixels would fail its own term. Dark clears 4.5:1 on all six: cyan 7.69 . magenta 5.14 . blue 5.10 . orange 5.63 . yellow 10.31 . purple 5.08 (worst) Recomputed by the lead off the six values above, not inherited. WHY #1A2332 and not #1A1A1A (which scores marginally better, worst 5.60): #1A2332 is the ink the frame itself uses on the y-axis price badges (6.59-10.10:1), and a small coloured chip carrying ink is the closest authored analogue to this button. Consistency with the nearest precedent over 0.5 of a contrast point. NO LIGHT-THEME OVERRIDE, DELIBERATELY -- and it is measured, not assumed: none of the six --ra-link-* colours carries one (widgets.css:1030 overrides exactly one family member, --ra-link-ring, and leaves the six alone), so the fill is theme-invariant and both operands of every ratio above are fixed. cf06961c's own acceptance term measured the consequence directly: cyan resolves to rgb(10,198,230) "in BOTH dark and light, identically". THE BOUND, so it can expire honestly: this collapses if any of the six ever gains a light override -- at which point this token needs one too, re-measured, not guessed. The FILLED state it serves is a DECLARED DIVERGENCE (S17-R2): the design system authors the colour PICKER (362:1608) and has never authored a RESULT for a grouped panel. Established twice, independently -- the S13 search recorded in components.css, and S17's pixel sample of 341:3788 returning #23282C x376px with ZERO cyan. */ --ra-link-ink: #1A2332; --ra-rule-orange: #FF9F00; --ra-rule-violet: #CB89FA; --ra-rule-sky: #59AAF8; --ra-rule-mint: #6FD087; --ra-rule-green: #4CD676; --ra-rule-tangerine: #FF823F; --ra-rule-peach: #FE9B60; --ra-rule-steel: #7392B3; /* Radii + display font (design/TOKENS.json `radii.conventions` / `fontFamilies.display`) — not colours, materialised here anyway so the Rail/header this session builds and the card system dev-b builds read the same names. Legacy --r-sm/--r/--r-lg (base.css) are untouched: they still serve un-migrated files and are a separate, smaller radius scale by design (§2 of PLAN.md scopes the alias layer to colour). */ --ra-radius-xs: 4px; --ra-radius-sm: 6px; --ra-radius-md: 8px; --ra-radius-card: 14px; --ra-radius-xl: 16px; --ra-radius-pill: 27px; --ra-radius-full: 999px; /* S51 WP4: the two small radii the panels draw on tags, chips and handles (3px at 40+ sites, 2px at 15) -- minted so the kit variants that reproduce those panels carry no literal. */ --ra-radius-2xs: 3px; --ra-radius-3xs: 2px; --font-display: "Space Grotesk", var(--font-sans); /* ============================================================ 1b. Type scale (design/PLAN_S19.md §2.3) -- the frame's SEVEN named text styles (design/TOKENS.json `typography.*`, all seven already registered there), materialised as CSS custom properties for the first time. `font:` SHORTHAND deliberately -- a consumer that reads the size cannot skip the weight, which is exactly the drift the S19 census measured (three pop-up roots at 10/11/12, six controls at 9.5/10/13). `-ls` is a separate property (letter-spacing isn't part of the `font` shorthand). `text-transform` is NOT in any of these -- only Heading/H3 carries textCase:UPPER, on one node; the shared class that consumes it (.pop-head-title) declares the case itself, not the token, or every other consumer of the scale would inherit an unwanted uppercase. Nodes, per style (design/PLAN_S19.md §2.3 table): h3-card 447:1059 · h4-subtitle 448:1649 · h6-table-header 13 nodes incl. 451:1094/448:1654/451:1160/1162/1233/1235 · body-small 9 nodes incl. 451:1182/1229/1211/1212 · body-medium 450:1089/451:1167/450:1082 (the three carets) · button-medium 448:1737/451:1250 · caption-helper 449:1063/451:1118/448:1743/448:1744. */ /* design-sync 2026-10-03: card-title, table-header, body-medium, button-medium, widget-title, nav-tab, label-form and label-stat realigned to Platform's local text styles (owner: Figma's text styles are the truth). */ --ts-h3-card-title: 500 15px/24px var(--font-display); --ts-h3-card-title-ls: 0; --ts-h4-card-subtitle: 600 15px/20px var(--font-sans); --ts-h4-card-subtitle-ls: 0; --ts-h6-table-header: 500 11px/16px var(--font-sans); --ts-h6-table-header-ls: 0.2px; --ts-body-small: 400 12px/16px var(--font-sans); --ts-body-small-ls: 0; --ts-body-medium: 400 14px/20px var(--font-sans); --ts-body-medium-ls: 0; --ts-button-medium: 500 14px/20px var(--font-sans); --ts-button-medium-ls: 0.3px; --ts-caption-helper: 400 12px/18px var(--font-sans); --ts-caption-helper-ls: 0.1px; /* FOUND WHILE MEASURING THE TOKEN BELOW, NOT THIS SESSION'S TO FIX: this rule reads 10px, but `design/TOKENS.json`'s own `typography.caption .helper` (its declared Figma source, `figmaVariable: "Caption/Helper"`) records size **9**, same 16px line-height. The materialised value here disagrees with its own source of truth by 1px. Flagged for whoever owns the token audit — not changed here, since every existing consumer of `--ts-caption-helper` would move under a same-name value fix, which is exactly what this file's single-writer rule (plan §1.3) exists to gate. S44 task #41 (CD-S44-090), MINTED WITH EXPLICIT AUTHORITY (team-lead, 2026-09-05): the gamma ladder's row pitch — `gex.css` `.gex-row` — has an owner-set BUILD target of 15px pitch / 14px tall (the frame's own measurement, live again after OR-S44-14 cancelled the chart-binding reading that had marked it "superseded"). No existing `--ts-*` token below `--ts-h6-table-header`'s 12px shares anything but a 16px line- height (measured: `--ts-body-small` 12/16, `--ts-caption-helper` 10/16 as shipped above) — even the frame's OWN 9px row-label spec pairs with a 16px line-height (`caption.helper` above), which cannot fit a 14px row at any padding >=0. Reaching the frame's row-GEOMETRY number needs a tighter line-height the frame's own type styles never pair with a caption-sized font — this is a derived value for a layout constraint, not a mirrored Figma text style, and does not carry a `figmaVariable` name in `design/TOKENS.json` for that reason. Derivation, shown so the next reader can check it rather than trust it: row content-box height 14px = 2px padding-top (`--ra-sp-3xs`, already the tightest existing spacing token) + line-height + 2px padding- bottom => line-height = 10px. Font-size 9px matches the frame's own CD-S44-094/096 measurement (and, once the drift noted above is fixed, `--ts-caption-helper`'s true source value) exactly. This is an ADDITION, not a same-name edit — no existing consumer moves. */ --ts-caption-tight: 400 9px/10px var(--font-sans); --ts-caption-tight-ls: 0; /* GEX panel frame 780:2557 (2026-09-09, design/s50/GEX_PARITY_AUDIT.md GP-04/05/07/10): the ladder's strike + value labels are Inter 400 11px (780:2657), the NET|SPLIT segment and the Live label Inter 500 11px ls 0.2 (799:17082, 780:2726). ADDITIONS — no existing consumer moves. */ --ts-caption-11: 400 11px/16px var(--font-sans); --ts-caption-11-ls: 0; --ts-caption-11m: 500 11px/16px var(--font-sans); --ts-caption-11m-ls: 0.2px; /* GP-20 (780:2564; the GEX cut, 2026-10-05): the GEX card's symbol subtitle is Inter 400 9px/16 in the frame -- Caption/Helper's source value in design/TOKENS.json (`typography.caption.helper`, 9/16), while `--ts-caption-helper` above now materialises at 12/18 (the design-sync 2026-10-03 realign). This step carries the frame value (TOKENS.json `typography.caption.9`); it replaces the panel's `--ts-caption-tight` + `line-height: 16px` pair. ADDITION — no existing consumer moves. */ --ts-caption-9: 400 9px/16px var(--font-sans); --ts-caption-9-ls: 0; /* S51 WP6-A (2026-09-14, design/PLAN_S51.md section 7): two APP-MINTED steps, not in design/TOKENS.json's typography (the frame never named them) -- the census of the panels' own sheets (design/s51/wp6/COMPONENT_MAP.md) found `font-size: 10px` written as a literal in ~150 rules and a 9px tracked uppercase label in ~40; a step the app uses that often is a step of the scale. Consumed through ds/atoms/text.css (`.t-caption-10`, `.t-eyebrow`); retiring either later is a one-token edit that moves every site at once. ADDITIONS -- no existing consumer moves. */ --ts-caption-10: 400 10px/14px var(--font-sans); --ts-caption-10-ls: 0; --ts-eyebrow: 500 9px/12px var(--font-sans); --ts-eyebrow-ls: 0.12em; /* The remaining NINE of the frame's sixteen named text styles (design/TOKENS.json `typography.*`, same source as the seven above). S19 materialised seven -- the ones pop-up 448:1631 consumes -- and stopped there, correctly, because that was its mandate. S20's mandate is the whole app, so the other nine land now, generated from the Figma REST dump by design/build_tokens.py; no number here was typed by hand, and the generator re-checks the original seven against the same source on every run (0 discrepancies -- S19 typed all seven correctly). ADOPTION HAZARD, read this before consuming one (owner ruling S20-R2): the `font:` shorthand sets family + weight + size + line-height in ONE declaration. A rule that today writes only `font-size: 12px` and INHERITS its weight will silently change weight the moment it adopts the shorthand. The ruling is that no pixel moves, so a site adopts a --ts-* only when the computed style is identical before and after -- measure it, do not reason about it (design/measure_dom.js). Where it is not identical the site is off-scale and takes a declared exception in section 1e instead. That is not a workaround, it IS the ruling. */ --ts-h2-section: 500 22px/28px var(--font-display); --ts-h2-section-ls: -0.2px; --ts-h5-widget-title: 500 13px/18px var(--font-sans); --ts-h5-widget-title-ls: 0.1px; --ts-body-large: 400 15px/22px var(--font-sans); --ts-body-large-ls: 0; --ts-label-form: 400 12px/20px var(--font-sans); --ts-label-form-ls: 0.3px; /* S51 WP4: the small TONE TAG the panels draw ~15 times (trade side, heat tier, urgency, flags): mono 600 9px, uppercase, ls .06em. App-derived, like the --ra-xfs-* entries below. */ --ts-tag: 600 9px var(--font-mono); --ts-tag-ls: 0.06em; --ts-label-nav-tab: 500 10px/12px var(--font-display); --ts-label-nav-tab-ls: 0.3px; --ts-label-badge: 500 12px/16px var(--font-sans); --ts-label-badge-ls: 0.5px; --ts-label-status-upper: 500 10px/14px var(--font-sans); --ts-label-status-upper-ls: 0.4px; /* Figma label/status: the toast title */ --ts-button-small: 500 12px/16px var(--font-sans); --ts-button-small-ls: 0.5px; --ts-dropdown-menu-item: 400 13px/13px var(--font-sans); --ts-dropdown-menu-item-ls: 0; --ts-dropdown-icon-label: 700 12px/12px var(--font-sans); --ts-dropdown-icon-label-ls: 0; /* A SEVENTEENTH text token, and deliberately not grouped with the sixteen above -- S20-R53, owner ruling 2026-08-21, escalated from the --ts-label-nav-tab misadoption at 80 sites (S20-R8's audit, task #25). THIS IS THE B1 CLASS, THE SAME SHAPE AS SECTION 1e'S B1 ROWS: drawn on 67:2, never named. Do not read this entry as a seventeenth named Figma style -- re-measured live, all five source nodes carry an EMPTY styles map (no style binding at all). The frame HAS an answer for 10px text that is not a nav tab; it just never gave that answer a name, the same gap the --ts-label-nav-tab misadoption exposed. SOURCE: five odd-numbered sibling nodes at 432:5635/5637/5639/5641/5643 (BP, DAY, NIGHT, UPNL, RPNL) -- the even ids in that range are null, the component is the five odd ones. Read at file version 2389946676565475445. Weight 600, size 10px, family Inter (var(--font- sans), never var(--font-display) -- that is the whole reason the nav-tab adoption was wrong at these sites). 12.1px line-height, not the fuller Figma-auto decimal: lineHeightUnit is INTRINSIC_%, the same auto-leading mechanism already measured for the 1.21x family (section 2c below) -- 10 * 1.21 = 12.1, rounded to the same precision the .t-u-* utility classes already use for exactly this class of value. textCase:UPPER is real on all five source nodes and is DELIBERATELY NOT baked into this token, on --ts-h3-card-title's own precedent: the shared class a site uses declares the case, not the token -- binding it here would force uppercase on every future consumer whether or not their markup wants it. */ --ts-label-stat: 500 12px/16px var(--font-sans); --ts-label-stat-ls: 0.3px; /* ============================================================ 1d. Spacing scale -- the first 2.0 spacing tokens this product has had (design/TOKENS.json `spacing`). Until now every one of the ~1354 padding/margin/gap declarations under platform/frontend/ was a bare literal, which is exactly why 38 distinct values are in use: nothing named them, so nothing stopped the 39th from being added. *** THE PREFIX IS --ra-sp-, NOT --sp-, AND THAT IS NOT A STYLE CHOICE. *** css/base.css:20-25 ALREADY declares --sp-1 .. --sp-6, a DIFFERENT scale (4/6/8/12/16/24, each multiplied by var(--density)), and base.css loads AFTER this file (index.html:24-25), so it WINS every collision. Written under the obvious prefix, two of these tokens would have been silently overridden and resolved to a value from the other scale: --sp-3 frame says 3px -> base.css resolves it to 8px --sp-5 frame says 5px -> base.css resolves it to 16px No error, no warning, no build failure -- the same silent-fallthrough class as the --ch-* rename hazard documented at the top of this file. Caught by measurement before shipping, not by review. Do not "tidy" this prefix back to --sp-. The two scales coexisting under distinguishable names is the point: var(--sp-3) is the legacy density scale, and var(--ra-sp-lg) is the 2.0 frame scale. TWO TIERS below, and the distinction is load-bearing -- do not collapse: T-SHIRT NAMES are design/TOKENS.json `spacing.named`, copied exactly. They are the design file's own words. Do not rename, do not extend. NUMERIC NAMES are values the frame USES HEAVILY that the named scale never named. This is not drift being legitimised after the fact; it is measured, and the measurement sits in the design file itself. `spacing.observedFrequency.padding` records 5px x434, 3px x320, 7px x204 and 14px x48 across the Figma nodes -- 5px is the SECOND most frequent padding in the entire frame, and 3px and 7px each beat 10px, 16px and 24px, all three of which ARE on the named scale. `spacing.scale` is therefore an editorial selection, not a census, and a file painting 5px agrees with the frame rather than defying it. A numeric name reads as "the frame measures this, the scale forgot to name it"; keeping the tiers visually distinct is how that stays readable a session from now. ============================================================ */ --ra-sp-3xs: 2px; --ra-sp-2xs: 4px; --ra-sp-xs: 6px; --ra-sp-sm: 8px; --ra-sp-md: 10px; --ra-sp-lg: 12px; --ra-sp-xl: 16px; --ra-sp-2xl: 24px; --ra-sp-3xl: 32px; --ra-sp-4xl: 48px; --ra-sp-5: 5px; /* Figma padding x434 */ --ra-sp-3: 3px; /* Figma padding x320 */ --ra-sp-7: 7px; /* Figma padding x204 */ --ra-sp-14: 14px; /* Figma padding x48 */ --ra-sp-40: 40px; /* Figma inset, Review sessions sub-row 723:6517 (S47, 2026-09-07): the frame insets it 40 and the scale jumps 32 -> 48, so rounding would move a pixel the designer placed (owner ruling S20-R2). REVIEW_SPEC_S47.md:534. Added by the lead: tokens.css is routed to no seat, and widening your own guard is not authorising it. */ /* Semantic spacing -- design/TOKENS.json `spacing.conventions`, measured off frame 321:90. ALIASES, never new values: a card's inset changes here, in one place, instead of in every panel that ever drew one. */ --ra-sp-card-x: var(--ra-sp-xl); /* 16 */ --ra-sp-card-y: var(--ra-sp-14); /* 14 */ --ra-sp-card-gap: var(--ra-sp-md); /* 10 */ --ra-sp-panel-head-gap: var(--ra-sp-sm); /* 8 */ --ra-sp-gutter: var(--ra-sp-sm); /* 8 -- columnGutter */ --ra-sp-workspace: var(--ra-sp-sm); /* 8 -- workspacePadding */ /* ============================================================ 1g. Size scale -- design-sync 2026-10-03, Figma Platform variables `size/...` (collection Spacing): controls 4 heights by role, menu rows 2, icons 6 plus one stroke weight, labels 5, the three app bars. ============================================================ */ --ra-size-control-xs: 18px; --ra-size-control-sm: 24px; --ra-size-control-md: 32px; --ra-size-control-lg: 44px; --ra-size-menu-item-sm: 30px; --ra-size-menu-item-md: 36px; --ra-size-icon-xs: 10px; --ra-size-icon-sm: 12px; --ra-size-icon-md: 14px; --ra-size-icon-lg: 16px; --ra-size-icon-xl: 20px; --ra-size-icon-2xl: 24px; --ra-size-icon-stroke: 1.33px; --ra-size-badge-xs: 16px; --ra-size-badge-sm: 22px; --ra-size-badge-md: 24px; --ra-size-badge-lg: 28px; --ra-size-badge-xl: 32px; --ra-size-bar-top: 60px; --ra-size-bar-ticker: 38px; --ra-size-bar-status: 48px; /* A chart's one-line head in a Picture-in-Picture window (design/TOKENS.json layout.panelHead, D6 shell-c; ds/organisms/pip.css): its 34px minimum and 40px cap. The shared panel head is 48 since the Fitts & Miller parity pass (8 + the 28 action row + 12, ds/organisms/panel-variants.css). */ --ra-size-panel-head: 34px; --ra-size-panel-head-max: 40px; /* Figma effect style shadow/popover (toast): two accent-primary drop shadows at 12% and 16%; the first one sits 5 px down since the Figma round of 2026-10-15 (was 8). */ --ra-shadow-popover: 0 5px 24px #0FD4BB1F, 0 6px 12px #0FD4BB29; /* ============================================================ 1h. Text metrics one property at a time -- E1, 2026-10-05 (design/behavior/PLAN_FULL_ATOMIC.md). A rule that sets ONLY a size, a line-height or a tracking cannot adopt a --ts-* shorthand without also taking its weight and family (the adoption hazard above), so these carry the one value and nothing else: computed style is identical by construction, which is the ruling (S20-R2, no pixel moves). --ra-fs-N design/TOKENS.json `fontSizes.scale` (9..15, 18, 22), the frame's own sizes, materialised for the first time. Not an exception, so not the --ra-xfs- prefix of section 1e. --ra-lh-N the line-heights of the frame's text styles (16 20 24, the 1.21x auto-leading of the 20px ticker, 24.2) plus the tight 8 and 14 two kit atoms set; value-named. --ra-ls-* tracking the kit sets on its own (uppercase labels, mono numerals): -em-NN = 0.NN em, -em-nNN its negative, -px-0-N = 0.N px. Value-named, section 1e's rule: the frame never named them, so the value IS the reason. */ --ra-fs-9: 9px; --ra-fs-10: 10px; --ra-fs-11: 11px; --ra-fs-12: 12px; --ra-fs-13: 13px; --ra-fs-14: 14px; --ra-fs-15: 15px; --ra-fs-18: 18px; --ra-fs-22: 22px; --ra-lh-8: 8px; --ra-lh-14: 14px; --ra-lh-16: 16px; --ra-lh-20: 20px; --ra-lh-24: 24px; --ra-lh-24-2: 24.2px; --ra-ls-em-01: 0.01em; --ra-ls-em-02: 0.02em; --ra-ls-em-03: 0.03em; --ra-ls-em-04: 0.04em; --ra-ls-em-05: 0.05em; --ra-ls-em-06: 0.06em; --ra-ls-em-07: 0.07em; --ra-ls-em-08: 0.08em; --ra-ls-em-10: 0.1em; --ra-ls-em-12: 0.12em; --ra-ls-em-14: 0.14em; --ra-ls-em-16: 0.16em; --ra-ls-em-20: 0.2em; --ra-ls-em-28: 0.28em; --ra-ls-em-30: 0.3em; --ra-ls-em-n01: -0.01em; --ra-ls-em-n02: -0.02em; --ra-ls-px-0-2: 0.2px; --ra-ls-px-0-3: 0.3px; /* D3, 2026-10-06 (the trading organisms): the 1.21x auto-leading of 10, 11, 12 and 14px text (Inter's intrinsic line height, the values the .t-u-* classes already carry), and the stat labels' 0.5px tracking. Value-named, as above. */ /* --ra-lh-12: the Customization swatches' clear chip (ds/organisms/account-settings.css .cu-sw-clear), f1b-account-settings 2026-10-06. */ --ra-lh-12: 12px; --ra-lh-12-1: 12.1px; --ra-lh-13-31: 13.31px; --ra-lh-14-52: 14.52px; --ra-lh-16-94: 16.94px; --ra-ls-px-0-5: 0.5px; /* --ra-ls-em-07: the velocity ignite badge's tracking (ds/organisms/screener-depth.css), added by D8 screener-b. */ /* ============================================================ 1k. Component variables -- Figma round 2026-10-09 (fig-tokens), Platform library variables added 6/10 and 8/10 with no code syntax, named by the "Como usar" rule: --ra- + the variable path, / as -, lower case (the collection is not part of the name, as size/control/md -> --ra-size-control-md). design/TOKENS.json `platform`. One value for both themes (Figma gives Dark = Light); an alias follows its target's light value. Figma opacities are percentages (100, 35), CSS takes 0..1. Drawn at /catalog, section Tokens (tokens/tokens.demo.js). ============================================================ */ /* radio (Platform 2820:1206): dot, inner gap of the small one, ring widths, face opacity */ --ra-radio-dot-big: 7px; --ra-radio-dot-small: 3.5px; --ra-radio-gap-small: 6px; --ra-radio-border-big-default: 2px; --ra-radio-border-big-selected: 2.5px; --ra-radio-border-small-selected: 1.25px; --ra-radio-opacity-default: 1; --ra-radio-opacity-disabled: 0.35; /* send-button (Platform 2921:1249), the chat send / pause button: accents, disabled face, focus ring width */ --ra-button-message-pause-accent: var(--ra-link-yellow); --ra-button-message-send-accent: var(--ra-accent-primary); --ra-button-message-disabled-opacity: 0.38; --ra-button-message-focus-border-width: 2px; /* Intelligence brief, Today's pulse cards (Organisms 13:35263): the same colours the dark theme paints today (--ra-intel-h165-80-15, --ra-intel-h70-82-13, --ra-intel-info-80-12), here fixed for both themes */ --ra-intell-drivers: #41DCA5; --ra-intell-divergences: #FAB45F; --ra-intell-catalysts: #80C3FF; /* trading (Figma round 2026-10-09, fig-trading; design/TOKENS.json `trading`): values the round's trading organisms need that Figma leaves unbound or gives one value in both themes. The Closed P&L card's height cap (Organisms trading-activity 13:12251, 261, no variable) and the activity cards' floor (head, table head and empty state; the app's own, Figma draws no short column). The ticket's side tones (ds/atoms/tx-side.css): dark = Figma's (accent/primary, the bright down red, the down red for the SELL on fill); light repoints at --pos / --neg in the light block at the end of this file, as Figma's single values read about 1.7:1 and 2.3:1 on the light card. The danger skin's ring and label (the ticket's Cancel), --ra-semantic-error in dark; it and --ra-state-danger-bg take the app's --neg / --neg-bg in light (the pair the sound rules' delete button switches to there). */ --ra-size-trading-closed-card: 261px; --ra-size-trading-act-card-min: 177px; --ra-tx-side-buy: var(--ra-accent-primary); --ra-tx-side-sell: var(--ra-market-down-bright); --ra-tx-side-sell-on: var(--ra-market-down); --ra-state-danger-ink: var(--ra-semantic-error); /* the Desk AI column (fig-followups; design/TOKENS.json `deskai`): Figma's greeting group and message/agent roots are 855 wide since 2026-10-15 (760 before), unbound (Organisms 428:21944, 13:37274); the welcome, the ask box and the thread's items. Beside a conversation, the evidence column (ai-desk/chat-evidence 626:21098, 432, unbound). */ --ra-size-chat-column: 855px; --ra-size-chat-evidence: 432px; /* ============================================================ 1e. Declared exceptions -- owner ruling S20-R2, 2026-08-21. A size or a spacing the frame does not carry SURVIVES HERE, with a token, a reason and a date. It is not snapped to the nearest scale step, because snapping moves pixels and the ruling is that no pixel moves. The owner's words: "conservar como excepcion declarada". ONE TOKEN PER VALUE, ONE REASON PER CLASS. A custom property holds one value, so 35 sites at 10.5px share one token; and the reason for 10.5px is the same sentence as the reason for 9.5px, so it is written once. An entry with no stated reason is a defect, not an exception -- an undeclared exception is just a literal that learned how to hide from the linter. HOW AN ABSENCE HERE WAS ESTABLISHED, once for the whole block: a single live GET /v1/files/kW1IFt1tCe7o5AnwJjJpV4 (22.2 MB) walked the ENTIRE Figma document -- all five pages, 21,624 nodes -- reading style.fontSize off every TEXT node together with its styles.text binding. Four pages carry sized TEXT (5,736 TEXT nodes with a fontSize); the fifth (0:1 Cover, 2 nodes) carries none. Script design/s20/_fullfile_census.py, output design/s20/fullfile_census.json, table design/s20/TYPE_SPACING_MAP.md. A search scoped to the five app frames could not have found a value living in a component elsewhere and would have proved nothing. THE PAGE IS PART OF THE EVIDENCE. The document has five pages and only ONE is the 2.0 design: 67:2 Rally Alpha Design - 2.0 <- THE design surface 41:2 KIT QA <- the old 1.0 kit, historical 49:2 Seal kit remix <- a variant exploration, no authority 7:2 Scan reproductions <- TRACED RASTER OF SCREENSHOTS, see A3 0:1 Cover <- 2 nodes A citation that does not name its page is not evidence. PREFIX: --ra-xfs- for a font size, --ra-xsp- for a spacing. x for exception, and the trailing dash is a decimal point (--ra-xfs-10-5 is 10.5px). Deliberately NOT the --ra-fs- prefix: section 1d's numeric tier (--ra-sp-5) asserts "the frame measures this heavily and the scale forgot to name it", and a section 1e token asserts the OPPOSITE. Two tiers that mean opposite things must not look alike. COMMENT HAZARD, BINDING (S20-R13). Never let an asterisk sit immediately before a slash inside a comment. CSS closes the comment there and every entry below it dies silently: no error, no warning, and nothing in this project parses CSS. A glob at the end of a clause is the trap -- write "panels//", never the star-slash form; write the spacing-scale prefix followed only by a space or a word, never directly by a slash. This is not hypothetical: a line in an earlier draft of this very block named two prefixes with a bare slash between them and survived only because a space happened to be there. Describe such a construction in words if you must refer to it -- never reproduce the two characters adjacent, even to explain the hazard, which is itself a trap this project has now fallen into more than once. Live fatal instance in the corpus at css/widgets.css:1198-1200 (killed --ra-text-axis outright, repaired in S20-R13/TH-1); a fragile near-miss at css/widgets.css:661 and here at :1200 post-repair, both a whitespace deletion from fatal. ONE FURTHER GUARD, LEARNED WHILE WRITING THIS VERY BLOCK (S20-R13, second instance): a comment EXPLAINING a colour value in prose is itself a colour literal to token_lint's colour scanner, which does NOT strip comments the way the type/spacing scanner does. Describe a colour's direction of change in words ("lighter", "unchanged") and cite the file with the real measurement; never quote a hex or oklch() value in a comment inside a file that is on the colour migrationDebt list. ============================================================ */ /* --- A1: ABSENT FROM THE ENTIRE DOCUMENT. ------------------------------- REASON (2026-08-21, S20-R2): these five sizes exist NOWHERE in the Figma file -- not on 67:2, not on the old kit, not in the traced scans, not on any page. Pure app-side drift, and the strongest absence this corpus can produce: five pages, 21,624 nodes walked, zero occurrences. There is no design intent to honour and nothing to adopt, so they are preserved exactly and named here. 88 of the 128 off-scale literals are in this class, and 86 of the app's 91 half-pixel font sizes are the four clean halves below -- which is the shape of drift, not of a design decision. REVISIT: never, unless the frame starts drawing one. Shrink by MIGRATING sites to a --ts-* style under S20-R8, not by re-pointing this token. */ /* design-sync 2026-10-03 (owner: half-pixel font sizes are rounded): every --ra-xfs-N-5 below is rounded UP to N+1 -- plain half-up, each result is a Platform text-style size (9..15) and no label drops under the 9px floor. Names kept; the literal sweep retires them. */ --ra-xfs-8-5: 9px; /* 5 sites */ --ra-xfs-9-5: 10px; /* 27 sites */ --ra-xfs-10-5: 11px; /* 35 sites ADDENDUM (2026-09-06, S46 task #33): this value is no longer absent from the whole document. The news frame's TIME cell absolute line (`723:2943`, unstyled, Inter 400 10.5px/13 ls0 -- design/s46/NEWS_SPEC_S46.md Sections 5.3/7.3) draws it. That falsifies this class's own premise for THIS size specifically (8.5/9.5/11.5/26 above are unaffected -- not re-checked here, do not assume they're clean by association) and devstudio.json's `_nota_typeSpacingDebt`, which asserts the same thing app-wide ("no existen en ningun estilo del frame"). RECORDED, NOT RECLASSIFIED: moving this size to a different section-1e class, or promoting it to a named --ts-* style the way caption.tight was, is a call for whoever owns that boundary (escalated to the team-lead), not something to do unilaterally while minting an unrelated exception. Until that's decided, this token is a valid font-size source for the news time-cell absolute line (its line-height/weight/letter-spacing are declared at the call site, same as every other consumer here) -- no news.css site draws from it yet; that's #23's job. */ --ra-xfs-26: 26px; /* 2 sites -- 67:2's nearest is 25.993px, ONE scaled glyph (296:11735), which is not 26 */ /* --- A2: NOT ON 67:2. Only on a page with no authority. ----------------- REASON (2026-08-21, S20-R2): each of these appears in the file, but never on the 2.0 design surface -- only on 41:2 (the old 1.0 kit) or 49:2 (a variant exploration). The 2.0 surface does not draw them. 24px AND 48px ARE NAMED THERE, and the name is why they still cannot be adopted: 24px is bound to `Headings/H4` on 41:2 (x25, 16 of them on the style) and 48px to `Headings/H1` (x8) -- both are REMOTE styles from the 1.0 library. A 1.0 name is not a 2.0 name. Adopting one would import the old kit's type ramp into the new design under cover of a token migration, which is precisely what a declared exception exists to prevent. REVISIT: if a 2.0 style is ever registered at one of these sizes. */ --ra-xfs-8: 8px; /* 8 sites -- 41:2 x4, 49:2 x3, unstyled both */ --ra-xfs-17: 17px; /* 1 site -- 41:2 x21, 49:2 x28, 7:2 x32, all unstyled even there */ --ra-xfs-24: 24px; /* 4 sites -- 41:2 x25, REMOTE `Headings/H4` */ --ra-xfs-30: 30px; /* 1 site -- 49:2 x3 only, remix exploration */ --ra-xfs-48: 48px; /* 1 site -- 41:2 x8, REMOTE `Headings/H1` */ /* --- A3: PRESENT ONLY ON 7:2, AND CITING 7:2 WOULD BE CIRCULAR. --------- *** READ THIS BEFORE "DISCOVERING" FRAME SUPPORT FOR ONE OF THESE. *** REASON (2026-08-21, S20-R2): each of these four sizes is absent from 67:2 and appears ONLY on page `7:2 Scan reproductions`, which is TRACED RASTER OF SCREENSHOTS OF THIS APP. So the frame did not specify these sizes -- SOMEONE TRACED OURS. Citing 7:2 as frame support for an app value is CIRCULAR: it is our own value coming back to us with a node id attached, and a node id is exactly what makes it look like evidence. A future session searching the document WILL find 13.5px on 7:2 and may conclude the design supports it. It does not. That session is reading a photograph of this codebase. 7:2 is `authority: none` in every table in design/s20/TYPE_SPACING_MAP.md section 1.2, and this comment is the mechanism that stops the rediscovery. REVISIT: only if one of these appears on 67:2. Never on 7:2 evidence. */ --ra-xfs-12-5: 13px; /* rounded up, design-sync 2026-10-03 (see A1). 3 sites -- 7:2 x4 traced, 67:2 none */ --ra-xfs-13-5: 14px; /* rounded up, design-sync 2026-10-03. 1 site -- 7:2 x5 traced, 67:2 none */ --ra-xfs-14-5: 15px; /* rounded up, design-sync 2026-10-03. 1 site -- 7:2 x17 traced, 67:2 none */ --ra-xfs-19: 19px; /* 1 site -- 7:2 x3 traced, 67:2 none */ /* --- B1: DRAWN ON 67:2 AND NEVER NAMED. --------------------------------- REASON (2026-08-21, S20-R2): the 2.0 design DOES draw these sizes, on the design surface itself -- and left every one of them unstyled. So the app agrees with the frame on the value and the frame declined to give it a name; there is no --ts-* to adopt because the design never minted one. This is the weakest-standing class in section 1e and the likeliest to be retired: a single new named style on 67:2 converts any of these from an exception into an adoption. REVISIT: whenever a 2.0 text style is registered. */ --ra-xfs-6: 6px; /* 1 site -- 67:2 x7 unstyled. Below EVERY registered style; caption-helper is the smallest at 9px. The design draws it and the scale stops above it */ --ra-xfs-18: 18px; /* 9 sites -- 67:2 x16 unstyled (296:11739 up- arrow, 461:3831 refresh, 296:11655 copy). Icon-glyph sizing, not text */ --ra-xfs-20: 20px; /* 4 sites -- 67:2 x1: 422:5261 "BLKB", Inter 700 20px/24.2. One ticker-symbol treatment, never promoted to a style */ --ra-xfs-28: 28px; /* 3 sites -- 67:2 x2: 296:9253 "1.0x" and 321:1799 "0.0x", INTER 800. Its weight is not in TOKENS.json fontWeights at all, so no token could express this even if one existed */ /* --- B2: DRAWN AND NAMED ON 67:2, BUT THE NAME HAS NO TOKEN. ------------ REASON (2026-08-21, S20-R2): 16px is the one size where the 2.0 design surface both draws it AND names it -- 6 nodes on 67:2, one bound to `Button/Large` (296:11728), five unstyled glyphs. It is still an exception because THE NAME RESOLVES TO NOTHING WE CAN CONSUME: `Button/Large` is the REMOTE style 82:768, and its LOCAL twin 93:1453 is one of the five unused styles recorded in TYPE_SPACING_MAP section 0.2. No --ts-* exists, so there is nothing to adopt. *** REVISIT THIS ONE FIRST. *** It is the single entry in section 1e that a design-side action retires outright: register `Button/Large` as a 2.0 style, regenerate TOKENS.json, add --ts-button-large, and this token is deleted rather than argued about. Task #11 was told to keep it revisitable and this comment is that hook. ALSO: 3 of the 4 rules at this size are SPLIT in design/s20/TS_ADOPTION.json -- their own matched elements already compute differently -- so no single token can serve them even once one exists (S20-R8 item 5). */ --ra-xfs-16: 16px; /* 2 sites -- 67:2 x6, 1 on `Button/Large` */ /* --- FLUID RAMPS: the token holds the whole clamp, not a bound. -------- REASON (2026-08-21, S20-R2 + lead ruling on this draft): the four font-size declarations in features/squeeze-overlay/squeeze_overlay.js are container-query FLUID RANGES, not fixed sizes -- clamp(min, Ncqi, max) inside a container-sized overlay, with the cqi figures derived in that file's own comment at :40-42. Neither bound is a text size on its own: the min is what the type collapses to in a narrow overlay and the max is its ceiling, so a token named for either would be a name for half a range. THE WHOLE EXPRESSION IS THE VALUE, so the whole expression is the token. A literal with a comment still counts against the ceiling, and --strict -- an empty dictionary -- is the declared end state, so leaving these as literals would make that end state permanently unreachable for this file. MEASURED, so nobody re-derives it: token_lint captures a clamp as ONE fragment, so these are 4 literals and not 8, and a var() reference here scores zero because tokens.css is excluded from the scan. Moving them here removes 4 from the ceiling. ROLE-NAMED, not value-named, per this block's own rule: the number is not a plain size. */ --ra-xfs-sqz-head: clamp(10px, 4.29cqi, 18px); /* squeeze_overlay.js:43 `.sqz-ov .sqz-head` */ --ra-xfs-sqz-pct: clamp(11px, 4.64cqi, 20px); /* squeeze_overlay.js:46 `.sqz-ov .sqz-pct` */ --ra-xfs-sqz-row: clamp(9px, 3.57cqi, 15px); /* 2 sites -- :51 `.sqz-ov .sqz-stat` and :54 `.sqz-flags` */ /* --- EM-RELATIVE: a size that is a ratio of the text around it. -------- REASON (2026-10-05, D14): inline code inside an answer is drawn a step smaller than the prose it sits in, whatever that prose's size is (the Desk tab, the Review chat and the screener card each set their own). A px token would freeze it at one surface's size, so the ratio itself is the value. ROLE-NAMED for the same reason as the fluid ramps above. */ --ra-xfs-code-inline: 0.92em; /* 1 site -- harness-chat-thread.css `.hc-code-inline` */ /* ============================================================ 1e (spacing half) -- owner ruling S20-R2, 2026-08-21. S20-R2 HOLDS IN FULL FOR SPACING. NOTHING MOVES. S20-R8 overturned it for TEXT ONLY -- "use the named styles anyway and accept things moving" was an answer about type, and stretching it to padding/margin/gap is the single most likely way this sweep breaks the layout. If a spacing value is not on the 14-token scale it is PRESERVED and declared here, never snapped. HOW AN ABSENCE HERE WAS ESTABLISHED, once for the whole block: the same whole-document walk as the type half -- one live GET of the Figma file, all five pages, 21,624 nodes, reading itemSpacing / counterAxisSpacing / padding on every node. Script design/s20/_fullfile_census.py, output design/s20/fullfile_census.json (spaceByPage), classification in design/s20/TOKENS_1E_SPACING_DRAFT.md. THREE pages carry spacing, not four: 67:2 (THE design surface), 41:2 (the old 1.0 kit) and 49:2 (a variant exploration). Page 7:2 "Scan reproductions" carries NO spacing data at all, because it is traced raster -- so the circular-evidence trap documented on the type side does NOT arise here. A citation still has to name its page. TWO NAMING FORMS AND THE RULE THAT PICKS ONE, because it matters: VALUE-NAMED (--ra-xsp-22) when the exception is about the VALUE -- a genuine inset the frame does not carry at that size. ROLE-NAMED (--ra-xsp-payer-dot-center) when the number is NOT A SPACING VALUE AT ALL -- half a height, a border width, an overlap. This is S20-R11 one level up: that ruling refused to calc-negate a centring offset because it would couple the offset to the spacing scale, and a name like `neg-6` invites the same coupling by a slower route -- the next dev with an unrelated -6px reuses it because the name says only "negative six". A role name makes reuse-by-coincidence impossible, which is the only protection available for a value nothing can check. COMMENT HAZARD, BINDING (S20-R13): see the guard already stated above the type half of this block -- it governs this half identically. There is no asterisk anywhere adjacent to a slash in what follows, deliberately. ============================================================ */ /* --- 1px: 52 LITERALS AND SIX DIFFERENT MEANINGS. ---------------------- REASON (2026-08-21, S20-R2): 1px IS drawn on the 2.0 design surface -- padding x6 at node 421:521 -- and the design never named it. So the value itself is honest; what is dishonest is one shared reason across 52 sites. They are not one thing, so they are not one token. Each name below says what its sites actually DO, and the split is the deliverable: chip-y a small inline label's vertical inset (padding: 1px Npx) stack-gap a tight column gap between stacked rows nudge a 1px optical correction, always margin-top hairline a gap that REVEALS THE PARENT BACKGROUND as a divider border-inset the mask-composite gradient-border ring width (bare 1) miscellaneous 1px insets with no shared role REVISIT: hairline and border-inset FIRST -- see their own note. */ --ra-xsp-chip-y: 1px; /* 29 sites -- vertical inset of a chip, badge or pill; the horizontal half is already on-scale (4/5/6px) */ --ra-xsp-stack-gap: 1px; /* 9 sites -- flex-direction: column gap */ --ra-xsp-nudge: 1px; /* 4 sites -- optical margin-top only */ --ra-xsp-1: 1px; /* 4 sites -- bare 1px insets, no shared role: shell.css:444, widgets.css:375, drawing-popover.js:102, screener.css:1044 */ /* --- 1px that is NOT SPACING. Flagged, declared, and due to move out. --- REASON (2026-08-21, S20-R2): these six sites spell a BORDER WIDTH using a spacing property, and the number means "one device pixel of rule", not "one pixel of space". They are declared here because they are literals today and the block must be pasteable today -- NOT because this is where they belong. *** RECOMMENDATION, needs an owner: migrate both to a border-width token and delete these two entries. *** Leaving them in the spacing tier couples a hairline to the spacing scale, which is exactly what S20-R11 refused to do for a centring offset. Same argument, same answer, and it is on the record here rather than discovered later. */ --ra-xsp-hairline: 1px; /* 3 sites -- `gap: 1px` over a `background: var(--line)` parent: the GAP draws the rule. intelligence.css 237, 1680, 4023 */ --ra-xsp-border-inset: 1px; /* 3 sites -- `position:absolute; inset:0; padding:1px` gradient-border ring. components.css:1404, composer.css:140, screener.css:2598 */ /* --- B1: DRAWN ON 67:2 AND NEVER NAMED. -------------------------------- REASON (2026-08-21, S20-R2): the 2.0 design surface draws each of these itself, at the node cited on each line, and the spacing scale never named it. The app agrees with the frame on the value; only the name is missing. Note WHAT the scale is: the Figma file binds exactly ONE spacing variable anywhere in the section (spacing/2xl = 48), so section 1d's 14-step scale is an EDITORIAL SELECTION from a measured frequency table, not a census. A file painting a value the frame paints is agreeing with the frame, not defying it -- which is why these are preserved rather than snapped. REVISIT: if a real spacing collection is ever published in the file. */ --ra-xsp-9: 9px; /* 20 sites -- 67:2 gap x11, 421:520(itemSpacing) */ --ra-xsp-22: 22px; /* 10 sites -- 67:2 padding x16, 85:5540(L/R) */ --ra-xsp-11: 11px; /* 5 sites -- 67:2 padding x32 + gap x1, 296:11703(itemSpacing), 391:4764(paddingTop) */ --ra-xsp-13: 13px; /* 5 sites -- 67:2 gap x1, 451:1208(itemSpacing) */ --ra-xsp-19: 19px; /* 3 sites -- 67:2 padding x6, 296:11548(T/B) */ --ra-xsp-17: 17px; /* 2 sites -- 67:2 gap x8, 85:5563(itemSpacing) */ --ra-xsp-26: 26px; /* 1 site -- 67:2 gap x1, 443:721(itemSpacing) */ --ra-xsp-27: 27px; /* 1 site -- 67:2 padding x16, 85:5563(L/R) */ /* --- A2: NOT ON 67:2. Only on a page with no authority. ----------------- REASON (2026-08-21, S20-R2): each appears in the file but NEVER on the 2.0 design surface -- only on 41:2 (the old 1.0 kit) or 49:2 (a variant exploration). The 2.0 surface does not draw them. Their frequency on the old kit is not an argument FOR them: 40px is 41:2's most-used gap (x26) and 67:2 does not use it once, which is the shape of a ramp that was deliberately left behind. REVISIT: if the value appears on 67:2. Never on old-kit frequency. */ --ra-xsp-18: 18px; /* 29 sites -- 41:2 gap x3, 49:2 gap x2, 67:2 none */ --ra-xsp-20: 20px; /* 14 sites -- 41:2 gap x12 + padding x33, 49:2 padding x36, 67:2 none */ --ra-xsp-40: 40px; /* 5 sites -- 41:2 gap x26 + padding x16, 67:2 none */ --ra-xsp-28: 28px; /* 3 sites -- 41:2 gap x4 + padding x12, 67:2 none */ /* --- A1: ABSENT FROM THE ENTIRE DOCUMENT. ------------------------------ REASON (2026-08-21, S20-R2): these eight exist NOWHERE in the Figma file -- not on 67:2, not on the old kit, not in the remix. Five pages, 21,624 nodes walked, zero occurrences. Pure app-side drift, preserved because S20-R2 says no pixel moves and there is nothing to adopt. THE FOUR FRACTIONALS ARE THE BEST-DOCUMENTED EXCEPTIONS IN THIS CODEBASE and three of them carry their own derivation in the comment directly above the declaration -- cited per line below. They are NOT computed at runtime; they are static literals someone worked out and wrote down. REVISIT: never, unless the frame starts drawing one. */ --ra-xsp-15: 15px; /* 6 sites */ --ra-xsp-30: 30px; /* 6 sites */ --ra-xsp-25: 25px; /* 1 site */ --ra-xsp-56: 56px; /* 1 site */ --ra-xsp-10-375: 10.375px; /* 1 site -- screener.css:1705, derivation in its own comment at :1697 (CD-752/CD-753, row pitch 8 -> 10.375 to reach a 40px row) */ --ra-xsp-21-258: 21.258px; /* 1 site -- screener.css:264 */ --ra-xsp-7-5: 7.5px; /* 1 site -- screener.css:1795, the compact variant of the 10.375 row pitch at :1765 */ --ra-xsp-5-5: 5.5px; /* 1 site -- screener.css:700. ALONE AMONG THE FRACTIONALS IT HAS NO STATED ORIGIN: no comment, no derivation, and no node in the file carries it. Recorded as unexplained rather than given a plausible reason -- inventing one would make it unfalsifiable */ /* --- .cind's padding, ruled individually (S20-R4). --------------------- REASON (2026-08-21, S20-R4): SUSPECTED PARITY DEFECT, PRESERVED ON PURPOSE. screener.css:808 paints padding 3.57px. The frame carries 3.5699381 at node 142:1564 -- but that node is a x1.19 SCALED INSTANCE, and the standing scaled-instance ruling (quoted in that rule's own comment) stores target / scale: 3.5699381 / 1.19 = 3.0000, i.e. --ra-sp-3. So the scaled-instance ruling says 3px and S20-R2 says no pixel moves. The lead ruled PRESERVE, DECLARE, FILE -- three acts -- because changing it here would move a pixel under cover of a token migration, which is the exact shape S20-R2 exists to stop. A migration session may not silently repair a defect it notices. REVISIT: via the register row, as a deliberate parity fix, never here. */ --ra-xsp-3-57: 3.57px; /* 1 site -- screener.css:808 `.btn.cind`. 67:2 padding x44 at 149:61, all scaled */ /* --- NEGATIVES: ruled by S20-R11, and FOUR OF SIX ARE INVISIBLE. ------- *** DO NOT DELETE THESE AS UNUSED. *** token_lint's UNIT_RE refuses a digit preceded by a minus sign, so `margin-top: -6px` is INVISIBLE to the gate -- the linter will never report a literal for it and never confirm this token is doing anything. Four of the six below are in that state, INCLUDING BOTH THAT S20-R11 EXPLICITLY RULED. They are declared anyway. A future session finding "a token with no matching literal" has found this comment, not dead code. (S20-R3 names this defect; its patch had not landed as of 2026-08-21.) S20-R11's TEST, which is why these are exceptions and not calc(): a negative MAY become calc(var(--ra-sp-X) * -1) when its magnitude is exactly a scale value AND READING THE SITE shows it is genuinely a spacing pull. An exact numeric match is PERMISSION TO LOOK, not permission to substitute. intelligence.css:477's -4px passed that test and is NOT here -- it leaves this population by being migrated. Every one below FAILED it, each for a stated reason. */ --ra-xsp-payer-dot-center: -6px; /* intelligence.css:1492. Half the 12px dot height for the absolute-centring idiom; not a spacing value, and coupling it to the spacing scale would decentre the pin if the scale moved. INVISIBLE to the gate. */ --ra-xsp-tab-border-overlap: -1px; /* automations.css:654. Pulls the tab up by one pixel so its own `border-bottom: 2px solid transparent` overlaps the container rule; a border-overlap offset, and there is no 1px spacing token to lean on. INVISIBLE to the gate. */ --ra-xsp-rail-hr-bleed: -1px; /* intelligence.css:3997, in `margin: 8px -1px 0`. Bleeds a 1px rule to the card edge, mirroring .panel-head::after's inset (components.css). Seen by the gate ONLY because the 8px in the same shorthand matched -- migrate the 8px and this literal vanishes from the count. */ --ra-xsp-cind-caret-nudge: -0.8px; /* screener.css:810. NO STATED ORIGIN. Sits beside .cind's 3.57px and is probably the same x1.19 scaled- instance family, but nothing in the file or the code says so, and 0.8 x 1.19 = 0.952 is not a round number either. Recorded as UNEXPLAINED, in the same suspected-parity register row as S20-R4. Seen by the gate only because a period precedes the digit 8. */ /* ============================================================ 1c. Select caret (design/PLAN_S19.md §2.2) -- moved OUT of components.css, which is how it loses its only `%23` colour-literal (a debt point banked). Four things happen in one move: the ink becomes #9AA1A4, the frame's OWN value for the "▾" glyph (450:1082, 450:1089, 451:1167 -- Inter 400 14/20 #9AA1A4; the app drew #88929C, a value from no node); the caret gets a LIGHT value for the first time (see the [data-theme="light"] block below); and there is exactly one place to change a caret from now on. The light ink is a REPOINT, not an invention (per the plan's explicit instruction, do not choose by eye): it is the resolved light value of --ra-text-secondary (var(--text-2) under [data-theme="light"], widgets.css:1064 -> oklch(0.38 0.012 70) -> #47413C), measured at 10.05:1 against oklch(1 0 0) -- clears the 3:1 non-text floor with room to spare, so the plan's fallback step to --ra-text-tertiary's light value is not needed. */ --ra-caret-select: url("data:image/svg+xml;utf8,"); /* ============================================================ 1f. Motion vocabulary (PLAN_S31.md §3) -- the first motion tokens this product has had. `grep -- '--mo-' platform/frontend/` returned ZERO hits before this block [probed, PLAN_S31 §3.1] -- the prefix is free, and it is deliberately NOT --anim- (near-miss to the existing --ai-anim-ms, renamed --mo-dur-ai-morph at F2) and NOT --m- or --motion- (§3.1 is explicit). PROVENANCE -- NOT design/TOKENS.json. TOKENS.json has no `motion` group; the Figma file carries no timing data. Every value below is measured off the owner's reference video, design/s31/MOTION_REF_SPEC.md (frame ranges cited per value there), reconciled against design/UX-REVIEW-motion.md's four-tier vocabulary where the two disagreed -- each row below names its source. A dev who needs a duration that does not exist here asks the architect -- they do not invent a millisecond. THE ONE RULE WITH TEETH (PLAN_S31 §3.6): only `opacity`, `transform` and `background-color` are animatable. Never `width`, `height`, `top`, `left`, `filter`, `box-shadow`, `grid-template-columns` or `all` on anything that shares a frame with a chart. The single authorised exception in the whole session is `backdrop-filter` on the modal scrim (S31-R4). Reduced motion is NOT a token here -- html.reduce-motion (css/app.css) already forces every animation/transition duration to 0.01ms !important across the whole app; a second mechanism would drift from the first (§3.5). ============================================== */ --mo-dur-hover-in: 90ms; /* UX-R1 --mo-fast; ref measures 300-380ms but UX's 90ms wins -- it measured OUR dense tables, the ref measured someone else's */ --mo-dur-hover-out: 0ms; /* UX-R8: a hover that lingers reads as lag */ --mo-dur-menu: 160ms; /* UX-R1 --mo-base */ --mo-dur-view: 220ms; /* MOTION_REF §7.1 measured 217ms, view out-fade; UX-R1 --mo-slow agrees */ --mo-dur-exit: 160ms; /* MOTION_REF §3: exit measured 183ms, snapped to --mo-dur-menu so exits and menus share one number */ --mo-dur-scrim: 200ms; /* MOTION_REF §2.1 -- measured 200ms, linear, both directions */ --mo-dur-switch: 150ms; /* S51 WP4: the thumb slide of the trading ticket / nav-bar and the Stats EMA switches, measured .15s at four sites; the kit switch variants (.switch.flat/.navbar/.lg) reproduce it through this token */ --mo-dur-blur: 120ms; /* MOTION_REF §7.1 -- measured 110-130ms */ --mo-dur-flash: 500ms; /* UX-R11a, down from today's literal 650ms */ --mo-dur-pulse: 1200ms; /* D14, 2026-10-05: one beat of a "working" dot (hc-pulse, an opacity loop) -- PROMOTED, not invented: the Desk AI status dot, its evidence rows and the card's activity line all shipped 1.2s */ --mo-dur-caret: 1000ms; /* D14: the streaming caret's blink (hc-pulse on .hc-streaming), shipped as 1s; kept apart from --mo-dur-pulse so neither changes speed */ --mo-delay-busy: 300ms; /* Feedback standard: a Loading face waits this long before it shows, so a fast answer never flashes it -- the chart's loading grace, features/chart/state.js:58-67. Not zeroed by reduce-motion (ds/molecules/empty-state.css) */ --ra-stale-opacity: 0.7; /* Level 1 stale: values stay readable, dimmed -- the News list's dim, ds/organisms/news-states.css:34 */ --ra-opacity-disabled: 0.4; /* btn-states, 2026-10-07: a disabled .btn (ds/atoms/button.variants.css), busy or not -- PROMOTED, not invented: the Settings Save, the ticket submit and the review icon buttons all shipped .4. Same value in both themes (design/TOKENS.json opacity.disabled) */ --mo-stagger: 60ms; /* MOTION_REF §7.1 measures ~100ms; shortened so a 12-block modal lands in ~600ms, not 1.5s */ /* E1, 2026-10-05: the kit's own durations, named where they already ship (each value unchanged, so no transition gets faster or slower). */ --mo-dur-control: 120ms; /* a kit control's hover/focus state change (border, fill, ink): .12s at ~20 kit sites -- button, input, segmented, switch, rail, the search pill, the news badges */ --mo-dur-nudge: 150ms; /* the login submit arrow's hover slide */ --mo-dur-toast: 200ms; /* the toast's rise and fade (ui-kit.css) */ --mo-dur-ring: 300ms; /* the link-target ring on a chart (drag.css) */ --mo-dur-mark: 1s; /* the outline on a moved, added or copied screener panel (frame 27, screener-panel-drag.css) */ --mo-dur-pulse: 1.2s; /* one beat of the AI badge's pending pulse */ --mo-dur-instant: 0s; /* a step with no duration: the trading drawers' visibility flip (D3, 2026-10-06) */ /* D8 screener-b, 2026-10-06: the screener organisms' own durations, named where they ship (each value unchanged). */ --mo-dur-needle: 180ms; /* the velocity gauge's needle swing (screener-depth.css #vel-needle-line) */ --mo-dur-ignite: 2.6s; /* the velocity panel's ignition flash; FLASH_MS 2600 in panels/screener/velocity.js */ --mo-dur-ignite-badge: 450ms; /* one beat of the ignite badge, four beats */ --mo-dur-fbd-flash: 300ms; /* a false-breakout fail flash on a panel */ --mo-dur-sl-flash: 600ms; /* the same flash when a stop-loss trips */ --mo-dur-loading-pulse: 1.4s; /* the chart loading veil's text pulse */ --mo-dur-tint: 200ms; /* the NBBO wide-spread background tint */ --mo-dur-progress: 300ms; /* the replay progress bar's growth */ --mo-dur-knob: 160ms; /* a sound rule's on/off knob slide */ --mo-dur-row-in: 300ms; /* a recent-fire row's entrance in the sound rules */ --mo-dur-row-glow: 900ms; /* a gainers row's sound-rule glow; soundGlowClear (950) outlasts it */ --mo-dur-marquee: 60s; /* one loop of the footer's trending tape (ticker-bar.css), the movers scrolling by */ --mo-dur-lift: 80ms; /* automations-b, 2026-10-06: a card's 1-2 px hover lift (the Automations canvas node and the trigger picker's cards: .08s, unchanged) */ --mo-dur-ai-morph: 280ms; /* F2, 2026-10-06: the Desk AI launcher morph and card grow-in, moved unchanged from ds/organisms/screener-ai-card.css (panels/screener/ai-agent.js reads it back for the timeout that sets [hidden]); 1ms under prefers-reduced-motion, after this block */ /* The brand splash, design/rally-alpha-ident.html: its own surface (absent from the 2.0 section, design/CHANGE_MAP.md), its own choreography: the mark sweeps in, the apex pings, the two words' letters rise one step apart, the hint fades in last. */ --mo-ident-sweep: 1.3s; --mo-ident-sweep-delay: 0.2s; --mo-ident-ping: 0.7s; --mo-ident-ping-delay: 1.05s; --mo-ident-letter: 0.7s; --mo-ident-word-1: 1.55s; /* the first word's first letter */ --mo-ident-word-2: 1.85s; /* the second word's first letter */ --mo-ident-letter-step: 0.05s; --mo-ident-hint: 0.6s; --mo-ident-hint-delay: 3.4s; --mo-ease-ident-reveal: cubic-bezier(0.22, 1, 0.36, 1); --mo-ease-ident-soft: cubic-bezier(0.16, 1, 0.3, 1); --mo-ease-settle: cubic-bezier(.2, .7, .2, 1); /* the house curve, PROMOTED, not invented -- already shipping at css/widgets.css:816 and :973 */ --mo-ease-exit: cubic-bezier(.4, 0, 1, 1); /* UX-R1 --mo-in */ --mo-ease-blur: ease; /* MOTION_REF §7.2 -- measured to match CSS `ease` */ --mo-ease-scrim: linear; /* MOTION_REF §7.2 -- measured flat, not a default */ /* Blur-to-focus pair -- S33-R3 (owner picked option B, task #60): design/s33/CHART_REVEAL_REF.md §3.4 measured the reference's incoming content (chart route mounts AND the boot-time "Most active" block) entering blurred and resolving to sharp, camera-static so the numbers are real: duration ~420-250ms per block depending on ROI, easing not independently fit (camera contaminates the candle event itself) but the boot-window fit and CHART_REVEAL_OPTIONS.md §2 Option B both state it as ease-out -- taken as given per the ruling, not re-measured here. --mo-dur-focus snaps to the ROUND figure both the ref file and the options doc quote (~500ms), distinct from --mo-dur-blur (120ms) above, which is the S31-R4 SCRIM's backdrop-filter resolve -- same ingredient (filter), different surface, different number, kept as separate named tokens on purpose (same precedent as --mo-dur-exit deliberately NOT collapsing into --mo-dur-menu despite sharing 160ms). --mo-blur-focus is an explicit ESTIMATE, not a measurement: CHART_ REVEAL_REF §0/§3.4 states every sharpness estimator saturates above sigma~=3-4px, so the reference's true peak (sigma 6-10px band) cannot be read off a frame directly. 8px sits mid-band. R3 p.3: "a peak radius that is an estimate must be TUNED AGAINST HIS EYE, not asserted" -- this value ships for the owner's look-and-tell, not as a settled figure; whoever changes it only edits this one line. */ --mo-dur-focus: 500ms; /* CHART_REVEAL_REF §3.3/§3.4, CHART_REVEAL_ OPTIONS.md §2 Option B -- ease-out, taken as measured per S33-R3 */ --mo-blur-focus: 8px; /* ESTIMATE inside the measured 6-10px band -- see comment above, tune against the owner's eye, do not re-derive as a measurement */ /* Scrim trio -- S31-R4 (LEAD_RULINGS.md): ships AS THE REFERENCE DRAWS IT, blur included, radius its own token so the fallback flip is one variable away. --ra-scrim-modal is achromatic and absent from TOKENS.json, same declared-decision precedent as the pre-existing literal it replaces at css/components.css:1852 (Amendment 2, df9f04b8) -- quoted here, not re-invented. Alpha measured 0.345 open / 0.354 close (MOTION_REF §2.1/§3); today's literal was 0.55, so the scrim gets deliberately LIGHTER and gains a blur -- QA should expect this as a designed change, not a regression. Blur: MOTION_REF measures sigma 3.8-4.0px. CSS `blur()` sets the Gaussian STANDARD DEVIATION, so 4px is correct -- 8px would be the diameter misreading the spec itself warns against. Verify against design/s31/ref_frames/ref-01-modal-backdrop.png before ever changing this number. PRE-AUTHORISED FALLBACK (S31-R4): if task #13's headful reading shows visible frame drops with charts streaming behind an open modal, --mo-scrim-blur -> 0px and --ra-scrim-modal's alpha -> 0.45 to compensate. A one-line, two-token edit with both readings attached -- not a redesign, does not reopen PLAN_S31. */ --ra-scrim-modal: oklch(0 0 0 / 0.35); --mo-scrim-bg: var(--ra-scrim-modal); --mo-scrim-blur: 4px; /* ============================================================ 2. Legacy DOM tokens, re-pointed at 2.0 values. Same names consuming CSS has always used (css/components.css, css/widgets.css, every panel/*.css) — zero edits needed in those files to adopt 2.0. P5 (design/PLAN.md §8.1 #15): "delete the alias layer OR DECLARE PER-ALIAS WHY IT SURVIVES" — not an unconditional delete. Measured, not assumed, before touching anything: grepped every var(--) call site across platform/frontend for each of the ~22 names below, PER NAME, not as a range — a range summary can conceal exactly the value being looked for (caught live: an early "--bg-0/1/2/3, --surf, --surf-hi by 2-14 files" summary hid that --surf itself was zero). Four names (--surf, --pos-dim, --neg-dim, --info-dim) had ZERO remaining consumers anywhere in the tree, in EITHER theme (each also had an orphaned [data-theme="light"] re-declaration in css/widgets.css — deleted there too, same commit) — deleted below, the literal act the phase is named for. Every other name is still called directly by 4-28 files each (exact counts on every group below) — full deletion would break rendering across most of the app, the OPPOSITE of the phase's acceptance test ("if a colour moves, a file was still riding the layer"). It would move on purpose, not by accident. THE FINDING UNDERNEATH THIS PHASE: migrationDebt (devstudio.json) only ever counted literal hex/oklch VALUES — it never counted var(--legacy-name) USAGE. A file can carry zero raw colour literals (and so sit off migrationDebt, reading as "migrated") while still depending on this exact alias layer for every var(--text-1)/ var(--pos)/etc. call it makes. The plan's "debt shrinks per phase as files migrate" framing silently assumed those two measures were the same thing — they are not, and the 4-28-file counts below are the actual, measured depth of the token migration, not the debt list's. Not a session failure; nobody had taken this measurement before now. Next session: migrating a file off migrationDebt does not migrate it off the alias layer — check var() usage separately. ============================================================ */ /* Accent hues (OKLCH hue channel) — read/written directly by shell/account/customization.js (S.applyCust() in shell/account/state.js, out of this session's scope). Values, names and consumers are all unchanged EXCEPT --hue-neg: see the Option C note below. */ --hue-pos: 180; --hue-neg: 25.5; /* was 12 — design/PLAN.md §4.5 "Option C", see --neg below */ --hue-neg-light: 10; --hue-info: 250; /* NOT a gap (verified against the live file, not assumed stale — a previous version of this comment claimed one and was wrong, caught during P5 review): applyCust() stamps --hue-neg onto document.documentElement.style on every boot, which would normally win over this :root default as an inline style regardless of load order. S.applyCust() (shell/account/state.js) already guards this — a stored hueNeg of 12 (the pre-2.0 legacy default) is treated as "unset" via r.removeProperty('--hue-neg') instead of being stamped, so tokens.css's 25.5 below reaches the DOM for a non-customised user. A hue the user actually chose is still stamped normally. */ /* Background tint */ --bg-hue: 250; --bg-chroma: 0.015; /* Surfaces — SURVIVES: --bg-0 10 files, --bg-1 13, --bg-2 14, --bg-3 7, --surf-hi 2. (--surf itself: 0 — deleted below, not here, so the deletion sits next to its own light-theme counterpart instead of splitting the two.) */ --bg-0: var(--ra-surface-base); --bg-1: var(--ra-surface-panel); --bg-2: var(--ra-surface-tape); --bg-3: var(--ra-surface-card); --surf-hi: var(--ra-surface-card-elevated); /* --surf DELETED (design/PLAN.md §8.1 #15) — 0 consumers found for var(--surf) anywhere in platform/frontend, in either theme. Its [data-theme="light"] counterpart (css/widgets.css) deleted in the same commit. --surf-hi above is NOT dead (2 consumers) — this is a single-name deletion inside a two-name group, not a whole-group call. */ /* SURVIVES: --line called by 21 files, --line-strong by 13. */ --line: var(--ra-border-default); --line-strong: var(--ra-border-card); /* Text ramp — SURVIVES: --text-1 28 files, --text-2 21, --text-3 24, --text-4 26 — the widest-used names in this section. */ --text-1: var(--ra-text-primary); --text-2: var(--ra-text-secondary); --text-3: var(--ra-text-tertiary); --text-4: var(--ra-text-faint); /* Semantic colors — SURVIVES: --pos 18 files, --neg 22, --info 18, --warn 9, --pos-bg 4, --neg-bg 4, --info-bg 10. */ --pos: oklch(0.78 0.14 var(--hue-pos)); /* -> #0FD4BB, exact match to market.up, unchanged */ --pos-light: oklch(0.84 0.097 var(--hue-pos)); --pos-bg: oklch(0.30 0.08 var(--hue-pos) / 0.18); /* design/PLAN.md §4.5 "Option C": free L, C AND H (not hue-only) is the only route that hits market.down #EF4444 exactly while keeping the hue-based Customization slider alive. L 0.72->0.638, C 0.18->0.208, hue 12->25.5 (declared above). Verified independently by both the architect and this dev via oklch->sRGB conversion: exact byte match. features/chart/render.js's own down-formula sites (6 of them) get the same L/C re-pin in S4 — see design/PLAN.md §4.5 / §5 S4. */ --neg: oklch(0.638 0.208 var(--hue-neg)); /* -> #EF4444 exact */ --neg-light: oklch(0.615 0.115 var(--hue-neg-light)); --neg-bg: oklch(0.30 0.12 var(--hue-neg) / 0.18); --info: oklch(0.74 0.15 var(--hue-info)); --info-bg: oklch(0.32 0.10 var(--hue-info) / 0.22); --warn: oklch(0.82 0.15 85); /* --pos-dim/--neg-dim/--info-dim DELETED (design/PLAN.md §8.1 #15, the literal act of the P5 phase): grepped every var(--pos-dim), var(--neg-dim), var(--info-dim) call site across platform/frontend — zero consumers found for any of the three, in either theme. Their [data-theme="light"] counterparts (css/widgets.css) deleted in the same commit. Genuinely orphaned, not just off migrationDebt; deleting them changes nothing on screen. */ /* --glow-pos/--glow-info/--glow-neg/--shadow-lg DIE here — design/PLAN.md §4.3: zero DROP_SHADOW effects anywhere in the 2.0 section, surfaces are separated by a 1px border instead. Not aliased, not carried over: any `box-shadow: var(--glow-pos)` etc. left in an unmigrated file (css/components.css, css/widgets.css, css/login.css, panels/screener/screener.css — none owned by this session) simply resolves to no shadow, which IS the 2.0 look. No crash, no console error: an undefined custom property with no fallback makes the `box-shadow` declaration invalid at compute time and the property falls back to its initial value (none). */ /* Hoisted UI-gradient formulas (design/PLAN.md §9.1: this file is the only file allowed a colour literal). Each VALUE is unchanged from its old inline site — only its home moved, so the consuming file can drop off migrationDebt. --scrollbar-thumb-hover shipped in S1 (base.css's :root block emptied out that commit); the rest are hoisted here in S2, when shell.css/app.css are next edited for the header/tape/workspace restyle — not preemptively in S1, per the team-lead's instruction not to mix steps in one commit. */ --scrollbar-thumb-hover: oklch(0.35 0.01 var(--bg-hue)); /* css/base.css */ /* --topbar-gradient-top / --topbar-underline-glow DELETED (design/PLAN.md §8.1 #6): their only consumers were .topbar's 1.0 gradient background and the .topbar::after underline glow, both deleted in this commit (css/shell.css). An orphan token is the seed of the next stacked UI. */ --avatar-ring-info: oklch(0.7 0.12 var(--hue-info)); /* css/shell.css .avatar */ --avatar-ring-pos: oklch(0.7 0.12 var(--hue-pos)); --mask-edge-opaque: #000; /* css/shell.css .ticker-bar mask-image; alpha-only, not a design colour */ --tape-flash-glow: oklch(0.5 0.14 var(--hue-info) / 0.45); /* css/app.css @keyframes tape-flash */ --search-focus-border: oklch(0.55 0.12 var(--hue-info) / 0.6); /* css/app.css .search-pill:focus-within */ --placeholder-glow: oklch(0.5 0.12 var(--hue-info) / 0.18); /* css/app.css .placeholder-card::before */ /* D16 (the shared features, 2026-10-05): the alerts drawer and card, the squeeze review card, the SEC form tag, hoisted the same way: each VALUE is unchanged from its inline site, only its home moved, so the files drop their colour literals (the post-login ident, shell/ident.js, reads the brand splash's --ra-ident-* tokens, below). Hue-relative values compute here on the root, where applyCust() and the light theme set the hues, as they did inline. */ --ra-sig-alert-up-line: oklch(0.55 0.12 var(--hue-pos) / 0.7); /* .sig-alert.up (features/alerts/alerts.js) */ --ra-sig-alert-down-line: oklch(0.55 0.14 var(--hue-neg) / 0.7); --ra-sig-accent-up: oklch(0.82 0.16 var(--hue-pos)); /* .sig-alert-accent, top of the gradient */ --ra-sig-accent-down: oklch(0.78 0.2 var(--hue-neg)); --ra-sqz-rule: rgba(255,255,255,0.08); /* features/squeeze-overlay/squeeze_overlay.js .sqz-flags */ --ra-sqz-flag-bear: oklch(0.7 0.18 25); --ra-sqz-flag-bull: oklch(0.78 0.16 145); --ra-sqz-bull-bg: oklch(0.20 0.07 145 / 0.92); /* .sqz-ov.bull */ --ra-sqz-bull-line: oklch(0.55 0.16 145); --ra-sqz-bull-ink: oklch(0.95 0.10 145); --ra-sqz-bear-bg: oklch(0.20 0.10 25 / 0.94); /* .sqz-ov.bear */ --ra-sqz-bear-line: oklch(0.58 0.20 25); --ra-sqz-bear-ink: oklch(0.95 0.10 25); --ra-sqz-neutral-bg: oklch(0.18 0.02 260 / 0.92); /* .sqz-ov.neutral */ --ra-sqz-neutral-line: oklch(0.45 0.05 260); --ra-form-tag-line: oklch(0.55 0.12 var(--hue-info) / 0.4); /* features/sec-forms/sec-forms.js .form-tag */ /* S11-R21 (OWNER, granted to dev-B): panels/news/news.css's one migrationDebt literal, hoisted here per the same "each VALUE unchanged, only its home moved" pattern as the rest of this block -- token_lint's exemption is per-FILENAME (tokens.css / tokens.*.css), not per-declaration-site (token_lint.py:67), so materialising the literal inside news.css itself would move it, not remove it. */ --news-item-hover-bg: oklch(0.22 var(--bg-chroma) var(--bg-hue) / 0.55); /* panels/news/news.css .news-item:hover */ /* The account chrome's colour literals (task D4 of design/behavior/PLAN_FULL_ATOMIC.md, 2026-10-05), hoisted from ds/organisms/account-{avatar,popover,settings,adjust}.css by the same "each VALUE unchanged, only its home moved" rule as the rest of this block, so those four files leave migrationDebt. Theme-agnostic, as the literals were: they read --hue-info / --bg-hue / --bg-chroma, which the Customization section stamps on this same element. */ --acct-mark-ink: oklch(0.98 0.01 250); /* account-avatar .am-mark letter */ --acct-mark-ring: oklch(1 0 0 / 0.12); /* account-avatar .am-mark inset ring */ --acct-head-tint: oklch(0.3 0.08 var(--hue-info) / 0.22); /* account-popover .acct-head */ --acct-item-hover-bg: oklch(0.3 0.05 var(--hue-info) / 0.18); /* account-popover .acct-item:hover */ --set-head-tint: oklch(0.2 var(--bg-chroma) var(--bg-hue) / 0.8); /* account-settings .set-head */ --set-foot-tint: oklch(0.18 var(--bg-chroma) var(--bg-hue) / 0.85); /* account-settings .set-foot */ --set-nav-on-top: oklch(0.28 0.06 var(--hue-info) / 0.35); /* account-settings .set-side .nav.on */ --set-nav-on-bottom: oklch(0.22 0.04 var(--hue-info) / 0.15); --set-nav-on-border: oklch(0.5 0.12 var(--hue-info) / 0.5); --set-tog-thumb: oklch(0.55 0.01 var(--bg-hue)); /* account-settings .tog::after */ --set-tog-on-bg: oklch(0.5 0.14 var(--hue-info) / 0.6); /* account-settings .tog.on */ --set-tog-on-border: oklch(0.55 0.14 var(--hue-info) / 0.6); --set-tog-on-ring: oklch(0.55 0.14 var(--hue-info) / 0.25); --set-card-on-border: oklch(0.55 0.12 var(--hue-info) / 0.7); /* .av-item.on, .th-card.on, .ac-card.on, .bg-card.on */ --set-th-on-tint: oklch(0.28 0.06 var(--hue-info) / 0.3); /* .th-card.on */ --set-ac-on-tint: oklch(0.28 0.06 var(--hue-info) / 0.25); /* .ac-card.on, .bg-card.on */ --set-swatch-border: oklch(0 0 0 / 0.25); /* .ac-card .sw, .bg-card .sw, .hue-row .chip */ --set-swatch-ring: oklch(1 0 0 / 0.1); /* .ac-card .sw, .bg-card .sw inset ring */ --set-del-hover-border: oklch(0.55 0.14 var(--hue-neg) / 0.5); /* .del-btn:hover */ --set-hue-track: linear-gradient(90deg, oklch(0.7 0.16 0), oklch(0.7 0.16 60), oklch(0.7 0.16 120), oklch(0.7 0.16 180), oklch(0.7 0.16 240), oklch(0.7 0.16 300), oklch(0.7 0.16 360)); /* .hue-row .track::before */ --set-card-light-bg: oklch(1 0 0); /* account-adjust, light theme: .fp, .av-preview and the cards */ /* The shell/account/ parts' own colour literals (task f1b-account-settings of design/behavior/PLAN_FULL_ATOMIC.md, 2026-10-06), hoisted from shell/account/state.js and customization.js by the same rule, so both leave migrationDebt. Where a preview's hue is the user's (an accent card, a background card, the hue chip, the accent preview), the token holds the lightness and chroma that preview always used ("L C", composed as oklch(var(--set-sw-lc) )). */ --acct-av-aurora-from: oklch(0.7 0.12 180); /* shell/account/state.js S.AV, the avatar presets */ --acct-av-aurora-to: oklch(0.7 0.14 250); --acct-av-ember-from: oklch(0.78 0.14 40); --acct-av-ember-to: oklch(0.6 0.18 20); --acct-av-violet-from: oklch(0.7 0.18 300); --acct-av-violet-to: oklch(0.55 0.18 270); --acct-av-moss-from: oklch(0.7 0.14 150); --acct-av-moss-to: oklch(0.45 0.12 160); --acct-av-dune-from: oklch(0.8 0.1 80); --acct-av-dune-to: oklch(0.55 0.08 60); --acct-av-glacier-from: oklch(0.82 0.08 220); --acct-av-glacier-to: oklch(0.5 0.12 240); --acct-av-monogram: conic-gradient(from 120deg, oklch(0.65 0.14 var(--hue-info)), oklch(0.7 0.12 var(--hue-pos)), oklch(0.65 0.14 var(--hue-info))); /* the Monogram preset */ --set-thp-dark-bg: oklch(0.14 0.015 250); /* customization.js theme cards: the Dark preview */ --set-thp-dark-line: oklch(0.3 0.01 250); --set-thp-dark-panel: oklch(0.2 0.015 250); --set-thp-dark-t1: oklch(0.96 0.005 250); --set-thp-dark-t3: oklch(0.58 0.01 250); --set-thp-dark-chart: oklch(0.17 0.01 250); --set-thp-light-bg: oklch(0.955 0.008 75); /* ... the Light preview */ --set-thp-light-line: oklch(0.45 0.01 75 / 0.2); --set-thp-light-panel: oklch(1 0 0); --set-thp-light-t1: oklch(0.22 0.01 70); --set-thp-light-t3: oklch(0.52 0.012 70); --set-thp-light-chart: oklch(0.12 0.01 250); --set-thp-spark: oklch(0.72 0.14 var(--hue-info)); /* ... both previews' sparkline */ --set-sw-lc: 0.72 0.15; /* .ac-card .sw, positive and info */ --set-sw-neg-lc: 0.72 0.17; /* .ac-card .sw, negative */ --set-chip-lc: 0.72 0.16; /* .hue-row .chip and its hex sample */ --set-bgsw-dark-l: 0.14; /* .bg-card .sw: lightness (the preset's chroma and hue) */ --set-bgsw-light-l: 0.955; --set-prev-up-lc: 0.78 0.14; /* #acPrevChart up candles (--pos's L C) */ --set-prev-down-lc: 0.638 0.208; /* ... down candles (--neg's L C) */ --set-bub-prev-fallback: rgb(170 170 170); /* #cBubPrev: a colour that is not a 6-digit hex */ /* The Automations canvas and run history's colour literals (task D5 second pass, automations-b, of design/behavior/PLAN_FULL_ATOMIC.md, 2026-10-06), hoisted from ds/organisms/automations-{canvas,bottom}.css by the same "each VALUE unchanged, only its home moved" rule, so both files leave migrationDebt. Theme-agnostic, as the literals were; the --hue-* they read are stamped on this same element (shell/account/state.js applyCust). */ --auto-canvas-glow-info: oklch(0.22 0.04 var(--hue-info) / 0.18); /* .auto-canvas-wrap, the top-left glow */ --auto-canvas-glow-pos: oklch(0.22 0.04 var(--hue-pos) / 0.10); /* .auto-canvas-wrap, the bottom-right glow */ --auto-edge-and: oklch(0.72 0.14 var(--hue-info) / 0.55); /* path.edge-real.edge-and (cond to cond) */ --auto-edge-then: oklch(0.78 0.14 70 / 0.6); /* path.edge-real.edge-then (into an action) */ --auto-edge-trigger: oklch(0.72 0.14 var(--hue-pos) / 0.6); /* path.edge-real.edge-trigger */ --auto-node-highlight: oklch(1 0 0 / 0.03); /* .auto-node inset top highlight */ --auto-node-shadow: oklch(0 0 0 / 0.30); /* .auto-node drop shadow */ --auto-node-shadow-lifted: oklch(0 0 0 / 0.4); /* .auto-node.selected, .auto-node.edge-target */ --auto-node-selected-glow: oklch(0.5 0.14 var(--hue-info) / 0.35); /* .auto-node.selected halo */ --auto-node-trigger-tint: oklch(0.22 0.04 var(--hue-pos) / 0.10); /* .auto-node.trigger fill */ --auto-node-cond-tint: oklch(0.22 0.04 var(--hue-info) / 0.10); /* .auto-node.cond fill */ --auto-node-act-tint: oklch(0.22 0.04 320 / 0.10); /* .auto-node.act fill */ --auto-act-accent: oklch(0.72 0.16 320); /* .auto-node.act stripe */ --auto-act-ink: oklch(0.78 0.16 320); /* .auto-node.act kind label, + Action hover */ --auto-socket-glow: oklch(0.6 0.14 var(--hue-info) / .6); /* .auto-socket:hover */ --auto-menu-shadow: oklch(0 0 0 / .45); /* .auto-socket-menu */ --auto-run-skip-ink: oklch(0.78 0.14 60); /* run history: skipped status, pill and filter dot */ --auto-run-skip-bg: oklch(0.65 0.12 60 / 0.16); /* .hist-action-pill.refused */ --auto-run-skip-border: oklch(0.7 0.14 60 / 0.5); /* Rail nav-item icons (design/DESIGN_SPEC.md §1.3): mask-source SVGs. S3-11 (design/PLAN.md §S3 D-S3-3 REVISED) inlines the 4 Figma-exported tabs + 3 rail-utils via foundation/icons.js's hydrateRail() — these `--icon-nav-*`/`--icon-rail-*` masks now serve only as the PER-BUTTON FALLBACK for a tab that never hydrates (JS blocked, a name the registry doesn't know), so the rail can never blank. Re-pointed from the 7 legacy PNGs (deleted, platform/frontend/icons/) to the real vectors under assets/icons/ — same files hydrateRail() embeds, so a fallen-back button and a hydrated one read identically at rest. 4 come from Figma (321:222/225/228/231 Screener/Intelligence/Stats/Trading + the bottom group 321:235/239/242 Keyboard Shortcuts/Settings/Log Out); the app has 9 tabs and the 2.0 frame draws icons for 4 (design/PLAN.md §4.8 — all 9 render, 5 have no Figma icon). Those 5 (Stream/News/ Composer/Automations/Watchlists) are new SVGs drawn in this session's house line-icon style (the existing topbar buttons' 1.4-2px stroke, currentColor, round caps) — derived from the system per design/PLAN.md §4.2's precedent for gaps the file doesn't answer, not invented from nothing. They stay mask-only (no registry entry, no frame vector). CD-607 (owner ruling: keep all 9 rail items — the 5 the frame doesn't model are real panels and keep their entry point): this comment already claimed all nine live "under assets/icons/", but five of the six url()s below still pointed at the pre-migration /static/icons/ path — the one second-vocabulary directory CD-607 asks to retire. Moved the files (git mv, same content, not re-drawn) and re-pointed the URLs so the comment finally matches what it always described. */ --icon-nav-stream: url(/static/assets/icons/nav-stream.svg); --icon-nav-screener: url(/static/assets/icons/nav-screener.svg); --icon-nav-news: url(/static/assets/icons/nav-news.svg); --icon-nav-composer: url(/static/assets/icons/nav-composer.svg); --icon-nav-automations: url(/static/assets/icons/nav-automations.svg); --icon-nav-watchlists: url(/static/assets/icons/nav-watchlists.svg); --icon-nav-intelligence: url(/static/assets/icons/nav-intelligence.svg); --icon-nav-stats: url(/static/assets/icons/nav-stats.svg); --icon-nav-trading: url(/static/assets/icons/nav-trading.svg); --icon-rail-kbd: url(/static/assets/icons/nav-hotkeys.svg); --icon-rail-settings: url(/static/assets/icons/nav-settings.svg); /* ============================================================ 2b. Gradient exceptions (design/PLAN.md §3 D1 / design/DESIGN_SPEC.md §8.7). TOKENS.json is frozen, so #067D6A and #99F0E2 (both gradient stops with no token) are minted HERE instead — the one file token_lint exempts and the one place a colour literal is legitimate. Four documented exceptions, not a system-wide gradient primitive (escalated to the team-lead per PLAN §3 D1 for a session-3 mint). Second stop of --ra-gradient-chart-area is written as an explicit rgb()-with-alpha-0, not the bare `transparent` keyword — `transparent` resolves to rgba(0,0,0,0), and CSS gradients interpolate the RGB channels even at shrinking alpha, so fading toward black-transparent instead of 067D6A-transparent would tint the fade grey partway down. ============================================================ */ --ra-gradient-chart-area: linear-gradient( /* 331:3727, 461:2584 */ 180deg, color-mix(in oklch, var(--ra-accent-primary) 30%, transparent), rgb(6 125 106 / 0) /* #067D6A @ alpha 0 */ ); --ra-gradient-ai-button: linear-gradient(90deg, #99F0E2, var(--ra-accent-primary)); /* 321:2108, button stroke */ --ra-gradient-ai-sparkle: linear-gradient(90deg, #99F0E2, var(--ra-accent-primary)); /* 321:3676, sparkle icon fill */ --ra-gradient-gauge-arc: linear-gradient(90deg, var(--ra-market-sell), var(--ra-accent-primary)); /* 321:1795, both stops tokenised */ /* ============================================================ 2c. Unbound type scale (design/PLAN.md §3 D3 / design/DESIGN_SPEC.md §8.6): 170 text nodes across the five frames carry no Figma text style, and TOKENS.typography is frozen so none can be minted. These five clusters cover 131 of the 170; measured, not designed — flagged for a session-3 mint. Every line-height is size × 1.2102 (Figma's auto). `m` suffix = Inter 500 (medium); no suffix = Inter 400 (regular). ============================================================ */ /* .t-u-13: Base 321:306 "08:39" */ /* .t-u-11m: Base 321:285 "TIME" */ /* .t-u-12: status bar 321:2117 "NY 14:07:21 EDT" */ /* .t-u-12m: status chips 321:2123/2125 "RTH"/"ETH" */ /* .t-u-11: the grip glyph 419:316 */ /* ============================================================ 3. Chart canvas tokens (--ch-*), read by name via chTC() in features/chart/render.js and features/chart/trade-markers.js (see file header). S1 moved these out of css/base.css verbatim; S4 (this section) now maps each one with a 2.0 equivalent to its value per design/CHANGE_MAP.md §3.2 — BY VALUE, names untouched. Colours with no 2.0 equivalent stay legacy verbatim (design/TOKENS.json's legacy.chart_* group; entries for the ones mapped below are removed from that group in this same commit — the ratchet CHANGE_MAP §5 describes). ============================================================ */ /* Chart canvas typeface (session 2 QA F2 follow-up, human ruling): the canvas's ~26 ctx.font call sites (features/chart/render.js, features/chart/trade-markers.js, panels/screener/tpswave.js) hardcoded "JetBrains Mono" literally — canvas can't read CSS custom properties, so the --font-mono token switch (base.css:33) never reached them. QA confirmed the 2.0 frame's own chart axis glyphs are drawn in Inter (no base serif on the "1"), so this isn't a deliberate terminal-mono convention being overridden, it was the one region still on the old family. Read once by chTC() into its cached palette (same mechanism already serving every --ch-* colour) and interpolated into each ctx.font string — not theme-scoped (no [data-theme="light"] entry below): font-family isn't a themed property, and duplicating it there would just be more dead-alias debt (see P5's --surf/--pos-dim finding for what that costs later). */ --ch-font: var(--font-sans); /* S30 item 4 (owner: "make the candle tails slightly thicker") — the high/low wick, in canvas device px. One step up from the previous 1px (measured: WebGL's gl.lineWidth is clamped to [1,1] on this bench's ANGLE/GL backend per ALIASED_LINE_WIDTH_RANGE, so features/chart/ gl.js draws the wick as a filled quad of this width rather than a GL_LINE). Not theme-scoped, same reasoning as --ch-font above: a width isn't a themed property, so no [data-theme="light"] entry. */ --ch-wick-width: 2px; --ch-ax: var(--ra-chart-axis); /* was #888 -> darkens */ --ch-text: var(--ra-text-primary); /* was #ddd -> lightens */ --ch-label-bg: var(--ra-surface-card); /* was #333 */ --ch-sep: var(--ra-chart-grid); /* was #1a1a1a -> shifts to blue */ --ch-draw: #fff; --ch-draw-label: #fff; --ch-draw-label-fg: #000; --ch-tip-bg: rgba(0,0,0,0.85); --ch-crosshair: var(--ra-chart-crosshair); /* was #555 -> strong change: white */ --ch-tip-border: rgba(255,255,255,0.20); /* new: shared tooltip border, features/chart/trade-markers.js */ --ch-sub-line: var(--ra-chart-grid-sub); /* was #2a2f38 -> darkens */ /* Fitts & Miller 20 (Organisms screener-chart, delta-pane 740:5617 and the mode captions 740:18977 / 740:18978): the words a pane or a mode writes on the plot (a title, a scale, a caption) in text/secondary, which flips with the theme. */ --ch-pane-text: var(--ra-text-secondary); /* Fitts & Miller 21 (Organisms screener-chart position-line 741:5609): the position line and its label's ring in accent/primary, the label on the tape surface (panels/trading/chart-lines.js); both flip with the theme. */ --ch-position: var(--ra-accent-primary); --ch-position-bg: var(--ra-surface-tape); /* The Buy/Sell TPS wave (panels/screener/tpswave.js), the literals that file drew (D8, 2026-10-05): its buy and sell lines are the candles' formulas (features/chart/render.js _CP / _CN, PLAN.md §4.5 Option C), its "Waiting for trades" text and scale maximum two white washes. Not theme-scoped: the light theme draws them the same. */ --ch-wave-buy: oklch(0.78 0.14 var(--hue-pos)); --ch-wave-sell: oklch(0.638 0.208 var(--hue-neg)); --ch-wave-empty: rgba(255,255,255,0.28); --ch-wave-max: rgba(255,255,255,0.3); --ch-guide: rgba(90,90,90,0.5); --ch-scrim: rgba(10,12,16,0.62); --ch-scrim-fg: #d8d8e0; --ch-on-chip: #000; --ch-on-mark: #fff; --ch-macd: var(--ra-accent-blue); /* was #4aa3ff */ --ch-macd-sig: var(--ra-chart-vwap); /* was #ff9f45 */ --ch-rsi: var(--ra-chart-ema-fast); /* was #c58af9 */ --ch-delta-up-rgb: 40,100,220; --ch-delta-dn-rgb: 200,40,40; --ch-vah: #5dc88a; --ch-poc: #ffb84d; --ch-val: #e36b6b; /* no 2.0 equivalent — 2.0 draws no volume profile */ --ch-marker-buy: var(--ra-semantic-success); /* was #3ddc84 */ --ch-marker-sell: var(--ra-market-down-bright); /* was #ff5a5a -> nearly the same */ --ch-order-buy: var(--ra-accent-blue); /* was #4aa3ff */ --ch-order-sell: var(--ra-market-up); /* was #0fd4bb -> already matched */ --ch-order-stop: var(--ra-market-down); /* was #ff5870 */ --ch-order-entry: var(--ra-semantic-warning); /* was #f0b000 */ --ch-order-trail: var(--ra-chart-ema-fast); /* was #c060ff */ /* EMA/VWAP palette (features/chart/render.js's chart-legend indicators, node 321:3709). EMA50/EMA100/VWAP have real 2.0 tokens (design/DESIGN_SPEC.md §1.7: legend EMA100->chart.ema-slow, EMA50->chart.ema-fast). EMA9/200 have no 2.0 legend entry at all — legacy carry-over, verbatim values, now tokenised instead of inline oklch() literals. SUPERSEDED 2026-08-25 (S27-R6, owner ruling on S27 addendum B item 1, "the indicators in the chart, the lines, are not consistent with the legends" -> "Lines adopt design colours"): this comment used to read "the DRAWN VWAP curve uses chart.vwap-line per design/CHANGE_MAP.md §3.1's documented legend/curve discrepancy — do not unify with chart.vwap on your own, it's an open design decision" and EMA21 was "no 2.0 legend entry" — both now RESOLVED, not still open: the design (the legend's own colour, panels/screener/screener.css's .chart-legend, CD-176/G29) is the source of truth the DRAWN line now matches, both here. --ch-vwap-line reads --ra-chart-vwap (was --ra-chart-vwap-line, now unconsumed by any --ch-* token — left defined at its own declaration as a palette value, not deleted). --ch-ema21 reads --ra-chart-ema-slow, same design teal EMA100 USED TO draw (CD-176 measured the FRAME itself paired them) — see S27-R9 below, which overturns this specific pairing as a declared PRODUCT divergence from the frame, not a mistake in either prior finding. SUPERSEDED AGAIN 2026-08-25 (S27-R9, owner dialog): the paragraph above called EMA21==EMA100 "deliberately the same colour, a design fact, not a bug" — the owner has since ruled the two lines must be tellable apart at a glance, overturning CD-176's pairing as a declared product divergence from the frame (cited here so a future parity pass does not silently "fix" this back to match Figma). --ch-ema100 now reads the newly-minted --ra-chart-ema100 (a vivid magenta, measured min sRGB distance ~79 from every other overlay/ sub-pane colour, both themes — closest is ema50/rsi's shared lavender-purple, every other line ≥92; design/s27b/dev-a/ indicator_legend_readings.json task_22 entry has the full table) instead of --ra-chart-ema-slow. EMA21 itself is untouched by R9 and still reads --ra-chart-ema-slow per S27-R6. */ --ch-ema9: oklch(0.78 0.18 70); --ch-ema21: var(--ra-chart-ema-slow); --ch-ema50: var(--ra-chart-ema-fast); --ch-ema100: var(--ra-chart-ema100); --ch-ema200: oklch(0.72 0.05 260); --ch-vwap-line: var(--ra-chart-vwap); --ch-bb-band: rgba(170,170,210,0.75); --ch-bb-mid: rgba(190,190,220,0.55); /* Psychological-level / bid-ask spread markers (features/chart/render.js "$"/"S$"/"BA" chart buttons) — a legacy feature with no 2.0 frame at all. LCH triple with no alpha, so call sites vary opacity per emphasis level same as before; values are verbatim, just named. */ --ch-psych-lch: 0.68 0.15 235; --ch-psych-label-bg: oklch(0.5 0.16 235 / 0.92); --ch-psych-label-border: oklch(0.68 0.15 235 / 0.8); --ch-psych-tag-big: oklch(0.85 0.18 235); --ch-psych-tag-whole: oklch(0.8 0.16 235); --ch-psych-tag-minor: oklch(0.72 0.14 235 / 0.7); /* Psych price-level gridlines (features/chart/render.js s.psych "$" toggle) — a distinct legacy feature from the psych-touches group above (gold, not blue). RGB triple, same pattern as --ch-delta-up/dn-rgb below, since call sites vary the alpha per emphasis (whole-dollar vs half-dollar). */ --ch-psych-gold-rgb: 255,200,0; /* Live NBBO bid/ask spread lines (features/chart/render.js s.spread "BA" toggle). Fixed alpha at every call site, so a flat rgba() is enough. */ --ch-spread-bid: rgba(60,200,140,0.85); --ch-spread-ask: rgba(230,80,110,0.85); /* Big-trade bubble neutral fallback (features/chart/render.js _bc()) — used when no buy/sell direction and no user hex override. RGB triple: the call site multiplies the user's opacity slider onto this. */ --ch-bubble-neutral-rgb: 170,170,170; /* Drawing-tool hover/preview overlays (features/chart/render.js, rvp/rect/line tools) — theme-dependent (light needs a dark wash, dark needs a light wash), so dark values live here and the [data-theme="light"] block below carries the light variants, same pattern as the rest of --ch-*. This replaces the old inline `_lt ? '...' : '...'` ternary in JS. */ --ch-hover-fill: rgba(255,255,255,0.06); --ch-hover-crosshair: rgba(255,255,255,0.6); --ch-hover-preview: rgba(255,255,255,0.5); /* Extended-hours shading band. Same theme-dependent-wash pattern. */ --ch-eth-shade: oklch(0.05 0.02 250 / 0.45); /* Chart patterns (features/chart/patterns.js, 2026-09-16). The bias colours alias the trade-marker pair and Entry/SL alias the trading overlay's order vocabulary, so one colour keeps one meaning on the canvas; TP reads the market-up role. Aliases re-resolve under [data-theme="light"] through their targets (the --ch-gex-wall-* precedent below), so no light entry. The picker swatches (chart/indicators-dd.js) read the same var()s. */ --ch-pat-bull: var(--ch-marker-buy); --ch-pat-bear: var(--ch-marker-sell); --ch-pat-entry: var(--ch-order-entry); --ch-pat-sl: var(--ch-order-stop); --ch-pat-tp: var(--ra-market-up); /* The candle roles on the user's accent hues (chart-b, 2026-10-06): the literals features/chart/render.js and its layers built from --hue-pos/neg/info, hoisted with the same L, C and alpha, so no pixel moves and the Customization sliders still move them (chTC() rereads them on _chThemeInvalidate()). Theme-independent, as the literals were, so no light entry. --ch-up/--ch-dn/--ch-info are the default candle colours (a hex override in Customization wins) and the bubbles' base, painted at the opacity setting via rgba(). */ --ch-up: oklch(0.78 0.14 var(--hue-pos)); --ch-dn: oklch(0.638 0.208 var(--hue-neg)); --ch-info: oklch(0.74 0.15 var(--hue-info)); --ch-last-up: oklch(0.78 0.14 var(--hue-pos) / 0.55); /* the dashed last-price line */ --ch-last-dn: oklch(0.638 0.208 var(--hue-neg) / 0.55); --ch-area-up-top: oklch(0.78 0.14 var(--hue-pos) / 0.05); /* the area gradient under the closes: top, 35 %, bottom */ --ch-area-up-mid: oklch(0.78 0.14 var(--hue-pos) / 0.22); --ch-area-up-end: oklch(0.78 0.14 var(--hue-pos) / 0); --ch-area-dn-top: oklch(0.78 0.18 var(--hue-neg) / 0.05); --ch-area-dn-mid: oklch(0.78 0.18 var(--hue-neg) / 0.22); --ch-area-dn-end: oklch(0.78 0.18 var(--hue-neg) / 0); --ch-blocks-buy: oklch(0.72 0.14 var(--hue-info)); /* the blocks mode's buy share */ --ch-line: oklch(0.78 0.14 var(--hue-info)); /* the line mode */ --ch-vol-up: oklch(0.7 0.13 var(--hue-pos) / 0.55); /* the volume histogram */ --ch-vol-dn: oklch(0.538 0.198 var(--hue-neg) / 0.55); --ch-hist-up: oklch(0.7 0.13 var(--hue-pos) / 0.65); /* the MACD histogram */ --ch-hist-dn: oklch(0.538 0.198 var(--hue-neg) / 0.65); /* ========================================================================== GEX — gamma exposure. S40 P0, owner ruling OR1 (2026-08-31). THIS WHOLE BLOCK IS THE SWAPPABLE GROUP. The owner ruled the ramp is DERIVED from existing tokens now, rather than authored in Figma, and accepted that it will not match his reference screens exactly. If a real ramp is authored in Figma later, replace THIS BLOCK — nothing in gex.js, gex.css, render.js or any panel changes. That is the whole reason the stops are color-mix() over two role tokens instead of eight literals: eight literals would be eight edits and eight allowlist entries. The two role tokens are HAND_SOURCED in design/build_tokens.py and design/TOKENS.json (gex.positive = Accent/Blue, gex.negative = Semantic/Error) — values unchanged from the frame, only the naming is new. Filing them as DIVERGENCES would ABORT the token build; see design/s40/token_table_dryrun.out for that run. COLOUR IS NEVER THE ONLY CHANNEL (design/PLAN_S40.md A-2). Bar LENGTH carries magnitude, an explicit +/- glyph carries sign, and chart levels are told apart by a reserved dash pattern. Text NEVER sits on a heat cell: a ramp runs from near-background to full saturation, so no single text colour passes at both ends. If removing all colour from these surfaces would lose information, the design is wrong. EVERY STOP IS MIXED TOWARD --ra-text-primary, AND THAT IS THE WHOLE TRICK. Two constructions were measured and rejected before this one: 1. Fading each stop toward the card background. Only ONE step per side clears WCAG 1.4.11's 3:1 non-text floor (20% -> 3.87, then 2.77 / 1.93 / 1.35). A ramp whose faint end has no findable edge is not a ramp. 2. Mixing toward a FIXED light colour. Clears dark theme easily and FAILS light theme outright: on the light card (--bg-3 #DBD7D0) the role tokens measure 1.92 and 1.93, and only the hottest stop recovers. "Upward in lightness" is not theme-invariant. --ra-text-primary already flips with the theme (#EEF1F1 dark, #111 light), so mixing toward it means "more prominent against THIS theme's background" in BOTH themes — lighter on dark, darker on light — and the ramp points the right way in each without a single [data-theme="light"] override. Measured, re-runnable via design/s40/ramp_contrast.py: dark (on #23282C) light (on #DBD7D0) pos lo 30% 7.21 3.54 pos mid 45% 8.24 4.90 pos hi 60% 9.43 6.86 neg lo 30% 7.20 3.56 neg mid 45% 8.26 4.92 neg hi 60% 9.42 6.87 All six clear 3.0 in both themes, and the two sides stay CIEDE2000 25-34 apart at every stop, so a positive can never be read as a negative. THE COST, STATED: the hot end is progressively DESATURATED. That is acceptable here and only here, because bar length already carries the magnitude — colour is the redundant channel (A-2). If colour were the carrier this construction would be wrong. Hue is untouched at every stop: the correction is entirely lightness, because the hue is the owner's ruling. */ /* OWNER-RULED RE-PICK — S44, OR-S44-24. Derived by the ux-designer in design/s44/GAMMA_COLOUR_S44.md; every figure below is a PAINTED PIXEL through design/s40/ramp_contrast.py, alpha preserved, not a token read. WHY BOTH SIDES MOVED: - the old positive was byte-identical to --ch-order-buy (dE00 0.00, both themes) — gamma bars drawn in the reader's own buy-order colour. The owner had chosen that hue himself in S40 OR1 precisely so gamma could not be confused with a CANDLE; it dodged that neighbour and landed on this one. - the old negative failed in BOTH themes, and the binding neighbour was --ch-marker-sell (9.26 light, 14.39 dark neg-lo), not the candle the first report named. A red negative could not be kept. WHAT THIS IS: not a new hue — the SAME olive/violet pair the walls, chips and gutter already draw (OR-S44-5). After it, Net, Split, the overlays and the gutter all speak one gamma colour. MEASURED, across all six neighbours (both candles, both order colours, both markers) in BOTH themes, and INDEPENDENTLY RE-VERIFIED by design-qa (task #68, QA_VERDICT_S44.md section 16) — every figure below is a painted pixel unless it says otherwise: - Worst NEIGHBOUR distance, token-level: 22.01, dark pos-mid vs marker-buy, against the 14.93 floor. Worst among stops a reader can ACTUALLY SEE: 22.24 — pos-mid is never painted by this chain, so the visible margin is wider than the token-level worst, not narrower. - Lowest contrast 4.90:1 is measured on --ra-surface-card, which tokens.css:1444 documents as this family's ground. THE LADDER PAINTS ITS ROWS ON --ra-surface-panel, where the same stop measures 6.15. Both clear the 3.0 floor; the 4.90 is the conservative reading. THIS FAMILY SERVES TWO GROUNDS — quote the one you measured on. - Painted vs token: 10 of 10 identical. No antialiasing erosion at these colours. Three stops (pos-mid, pos-hi, call-hi) are never rendered by a normal dataset — halfHtml() tiers at pct>=66/33, so a single dominant wall leaves nearly every row at `lo`. DO NOT confuse an INTERNAL distance with a NEIGHBOUR distance. The Split ramp's 20.23 is call-hi vs put-hi in LIGHT — the ramp's own positive-vs-negative separation at its tightest stop, NOT a distance to anything external. Split's worst against the six neighbours is 22.24 dark / 25.39 light. Conflating the two is exactly what produced the stale "worst 24.22" claim this re-pick had to correct. NOTE the neighbour list is effectively FIVE, not six: --ch-order-sell and the up-candle are the same value (dE00 0.00, both themes), so "far from the up-candle" and "far from order-sell" are one constraint. It does not bind this pick; it removes a degree of freedom a future one may need. */ --ch-gex-pos: var(--ch-gex-wall-call); --ch-gex-neg: var(--ch-gex-wall-put); --ch-gex-zero: var(--ra-surface-card); /* no exposure reads as background */ --ch-gex-pos-lo: color-mix(in oklab, var(--ch-gex-pos) 70%, var(--ra-text-primary)); --ch-gex-pos-mid: color-mix(in oklab, var(--ch-gex-pos) 55%, var(--ra-text-primary)); --ch-gex-pos-hi: color-mix(in oklab, var(--ch-gex-pos) 40%, var(--ra-text-primary)); --ch-gex-neg-lo: color-mix(in oklab, var(--ch-gex-neg) 70%, var(--ra-text-primary)); --ch-gex-neg-mid: color-mix(in oklab, var(--ch-gex-neg) 55%, var(--ra-text-primary)); --ch-gex-neg-hi: color-mix(in oklab, var(--ch-gex-neg) 40%, var(--ra-text-primary)); /* `in oklab`, NOT `in oklch` — S44, same derivation. `oklch` interpolates along a HUE PATH, and light theme's --ra-text-primary is a WARM near-black (hue ~70). At the `hi` stop the ink is 60% of the mix, so a violet rotates THROUGH RED to reach it: the light negative high stop came out brown instead of dark violet. `oklab` interpolates rectangularly and has no hue path to travel. Dark moves by dE00 ~0.3 — it costs nothing there. THE SPLIT RAMP BELOW IS DELIBERATELY LEFT ON `oklch`: it shares this construction and PASSES today (worst 20.23, call-vs-put at light `hi`, against the 14.93 floor). `oklab` would widen that to 35.56 — a SHOULD, not a must, and changing it would alter a mode the owner has already reviewed. Recorded rather than taken. */ /* CHART-SIDE gamma tokens — REVISED S41 (owner ruling HANDOFF_S41 §0b, 2026-08-31, implemented 2026-09-01 at his direct instruction): colour is now the PRIMARY channel for the gamma levels — SOLID, FULL-WIDTH, HVL-style — reversing A-2's dash-carries-identity for this group only. Identity still never rides hue alone (the greyscale test survives): every level draws a text chip (HVL / C1..C3 / P1..P3) plus its coloured axis tag (render.js _gexChip/_yTagQ). MEASURED, NEVER PICKED — same instrument as the S40 env pass; the pick search and every number below re-run via `./venv/bin/python design/s41/gexline_hue_pick.py` (.out committed). FLIP: the owner's reference cyan is "the direction" — but a BRIGHT cyan cannot clear the palette's own 14.93 CIEDE2000 floor on this canvas: candle-up #0FD4BB and price-line #7EE0CD own that region, the same measured wall the S40 hue search hit at 215-290. This is the brightest FLOOR-CLEAN cyan: dark #597C7C (min dE00 15.62, nearest --ch-ax/ema21; bg 4.09:1; black tag ink 4.60:1), light #086B6C (min dE00 20.21; bg 6.31:1). Emphasis rides line WIDTH (2px vs the walls' 1.2) — the recorded fallback channel. Wanting it hotter means accepting a sub-floor distance to the teals: an owner trade, one edit here. WALLS split per SIDE and alias the two S40-measured survivor hues VERBATIM via the env tokens kept below for exactly this revival (olive 110 = call, violet 320 = put; per-theme values + light overrides ride along for free): min dE00 22.22/18.89 dark, 24.31/24.42 light; bg 5.91/3.69 dark, 4.76/7.43 light. Mutual flip/call/put distances 24-69. Violet is not the reference's literal red because red is measurably banned here (gex.negative sits dE00 9.78 from candle-down — the recorded trap). */ --ch-gex-flip: oklch(0.56 0.04 195); --ch-gex-wall-call: var(--ch-gex-env-pos); --ch-gex-wall-put: var(--ch-gex-env-neg); /* S43 -- the CARD ramp for the diverging CALL/PUT ladder (design/PLAN_S43.md A-1). NO NEW HUE: these are the two S40-measured survivor hues above, --ch-gex-wall-call / --ch-gex-wall-put, put through the SAME three-stop lift the pos/neg ramp already uses at :1433-1438 -- color-mix(in oklch, {70,55,40}%, var(--ra-text-primary)). Minted HERE, once, because gex.css only ever references a ramp (its own header rule) and a Figma-authored ramp must be able to replace this block in one file. Both inputs are already theme-overridden, so the stops follow light/dark for free -- no [data-theme="light"] entry is needed or wanted. RE-RUN THE NUMBERS BELOW, DO NOT QUOTE THEM. ./venv/bin/python design/s43/token_stops_check.py Raw output design/s43/token_stops_check.out. The first version of THIS COMMENT quoted figures that disagreed with that output on every value (err:d9439589035b) -- a comment in tokens.css is what the next sessions read instead of re-running, which is exactly why it has to be re-run. HOW THE STOPS ARE MEASURED, because the obvious way is wrong twice over. They are NOT modelled in Python. design/s43/computed_stops_dump.js paints each var() into a 1x1 canvas and reads the device pixel back; only the JUDGEMENT (contrast, CIEDE2000) uses design/s40/ramp_contrast.py. Two independent defects sit in the modelled route, and BOTH inflate the readings, i.e. both make this ramp look safer than it is: 1. mix_oklab(h1, h2, pct) weights pct toward h2 -- its own docstring says color-mix(in oklch, h1, h2 %). Passing the CSS's own 70 as mix_oklab(hue, text, 70) therefore asks for 70% TEXT, the inverse of what the CSS declares. Dark call-lo: #D7D5B0 (9.94:1) modelled, #AFB165 (6.59:1) painted. 2. `in oklch` is POLAR and interpolates HUE; mix_oklab is rectangular. Small in dark, but in light it ROTATES the put ramp 320 -> 26, i.e. violet drifts toward red -- the one family this palette bans. WHY THE LIFT IS NOT OPTIONAL. RAW violet reads 2.94:1 on the dark card #23282C, UNDER the 3.0 non-text floor (WCAG 1.4.11). Lifted, every stop clears it -- card contrast, DARK: call 6.59/7.74/8.97 (lo/mid/hi), put 4.88/6.19/7.71; LIGHT: call 5.16/6.35/7.82, put 6.99/8.00/9.14. Contrast RISES as the stop lifts toward the text colour, in both themes; a table here that falls is a transcription error, no instrument needed to see it. Every stop also clears the 14.93 CIEDE2000 floor against BOTH candles, worst 24.22 (dark call-hi vs candle-up). Call-vs-put at the same stop: 54.34 lo / 46.56 mid / 38.28 hi dark, 43.04 / 30.97 / 20.23 light -- the distance that makes a diverging bar readable. THESE STOPS MUST NEVER MIGRATE ONTO THE CHART CANVAS. Measured, same run, section [C]: dark put-mid sits 6.40 from --ch-ema50, put-hi 8.98 and put-lo 9.54, all far under the canvas floor of 14.93. The canvas uses the RAW hues above (18.89 clear) for exactly that reason. Card device and chart device are different measurements of the same hue -- GEX_CONTRACT.md section 6 says the same thing about the existing red ramp. (In LIGHT theme the stops happen to clear the canvas; the ban stands on the dark reading, and a rule that bites in one theme is still a rule.) ONE CONSEQUENCE FOR THE CARD, not for this file: the ladder keeps the pos/neg ramp above for its net-only fallback row, so both ramps appear on one card, and in LIGHT theme three cross-ramp pairs fall under the floor (call-hi vs neg-hi 12.90, put-hi vs pos-hi 11.41, put-hi vs neg-hi 13.14). Accepted ONLY because colour is never the carrier there -- the fallback row is told apart by GEOMETRY (one bar from an edge vs two from the centre). PLAN_S43.md section 8d. Do not "fix" it with a fourth hue. */ --ch-gex-call-lo: color-mix(in oklch, var(--ch-gex-wall-call) 70%, var(--ra-text-primary)); --ch-gex-call-mid: color-mix(in oklch, var(--ch-gex-wall-call) 55%, var(--ra-text-primary)); --ch-gex-call-hi: color-mix(in oklch, var(--ch-gex-wall-call) 40%, var(--ra-text-primary)); --ch-gex-put-lo: color-mix(in oklch, var(--ch-gex-wall-put) 70%, var(--ra-text-primary)); --ch-gex-put-mid: color-mix(in oklch, var(--ch-gex-wall-put) 55%, var(--ra-text-primary)); --ch-gex-put-hi: color-mix(in oklch, var(--ch-gex-wall-put) 40%, var(--ra-text-primary)); --ch-gex-dash: 6 3; /* reserved for delayed-source overlays ONLY — no gex reader since S41 (levels went solid) */ /* GAMMA ENVIRONMENT BAND (S40 task #9). The band down the chart edge that says whether the day is positive- or negative-gamma. Measured, never picked: every reading below is re-runnable via `./venv/bin/python design/s40/ramp_contrast.py` section [5], and the hue search behind the choice is in design/s40/env_hue_search.out. WHY THESE TWO HUES, and the finding that decided it. The search measures every 5-degree hue at every lightness and chroma the sRGB gamut allows, in both themes, against the 38 tokens ALREADY DRAWN on this canvas (candles, volume, the EMA set, VWAP, psych levels, Bollinger, spread, extended-hours shade, liquidity heatmap, volume profile, markers, orders, grid, axis, crosshair). Three results: 1. BLUE IS UNAVAILABLE ON THIS CANVAS IN DARK THEME. Not one value between hue 215 and 290 clears the palette's 14.93 CIEDE2000 floor at ANY lightness or chroma -- the corridor is fully occupied by the psych-level family (235), --ch-ema200 (260), --ch-order-buy/--ch-macd and the heatmap's delta-up. So the CARD ramp's gex.positive (Accent/ Blue) cannot follow the band onto the chart. Same shape as the recorded gex.negative trap, at the other end of the wheel: the card's evidence does not transfer to the canvas. 2. RED and GREEN/TEAL are excluded on MEANING, not distance. They do produce values that clear the floor -- a dark, low-chroma dusty red is numerically far from --ch-candle-down. They are still wrong. Gamma is a REGIME, not a direction: negative gamma means dealers AMPLIFY moves, it does not mean bearish. A band in the down-candle family would tell the trader something false in the channel he reads before he reads the words. 3. What survives both is hue ~110 (olive) and hue ~320 (violet): the two families with no drawn token on this canvas and no direction attached to them, 210 degrees apart so they cannot be confused with each other either. Positive is the olive, negative the violet -- neither is a "good/bad" colour, which is the point. HOW THE RENDERER USES ONE TOKEN TWICE, and where each floor is met: RAIL -- the token at FULL opacity, the band's edge. This is where WCAG 1.4.11's 3:1 non-text floor is satisfied: a region with a discernible boundary is a discernible region. Measured against the real chart background in each theme: 5.91 / 3.69 dark, 4.37 / 6.82 light. Nearest drawn neighbour anywhere: 18.89 (negative vs --ch-ema100 in dark), floor 14.93. FIELD -- the same token at alpha 0.12 over the chart background, the band body behind the tape. Recommended, not mandated: the geometry is the renderer's call, the colour is not. THE TRADE-OFF, STATED RATHER THAN SPLIT. A band is a large field, not a line. A field flat at 3:1 would compete with live candles; a field quiet enough not to compete cannot itself carry 3:1. So the field is quiet by design -- at alpha 0.12 it reads 7.0 to 12.9 CIEDE2000 from the background, deliberately BELOW the 14.93 mark floor so the band body can never be mistaken for something drawn -- and the RAIL carries 1.4.11. Both halves are measured; neither is a compromise between them. GREYSCALE, STATED PLAINLY AND NOT ROUNDED UP: the two bands are only 1.6:1 apart in greyscale, and no lightness pair would reach 3:1 -- a value must clear 3:1 against a near-black background AND a near-white one at once, which pins it to roughly 18 L* of room. That is not a defect, because colour is not the carrier (A-2): the band ships with the WORDS beside it (R2) and the words are what survive greyscale. The ~13 L* split is a bonus, not the mechanism. If the words are ever dropped, these tokens stop being sufficient and the design is wrong, not the colour. NOT FILED IN design/TOKENS.json, deliberately, and this is the S20 rule being followed rather than skipped: TOKENS.json is the record of the FIGMA design system, and the frame authors no chart-canvas colour of any kind. Every app-minted chart colour already lives here and only here as an oklch literal -- --ch-ema9, --ch-ema200, --ra-chart-ema100, --ch-psych-*, --ch-eth-shade. Written in oklch (not hex) for that same reason: build_tokens.py's legacy scraper collects --ch-* HEX only, and that group is a ratchet that must shrink to zero. Nothing is hand-edited into TOKENS.json here, so there is nothing for a generator re-run to revert -- which is the failure S20 recorded. */ --ch-gex-env-pos: oklch(0.65 0.14 110); --ch-gex-env-neg: oklch(0.56 0.16 320); } /* The one motion token reduced motion changes: ai-agent.js times [hidden] off it, so it collapses with the transitions it times (moved unchanged from screener-ai-card.css, F2). */ @media (prefers-reduced-motion: reduce) { :root { --mo-dur-ai-morph: 1ms; } } /* ------------------------------------------------------------ UNBOUND type scale — measured, not tokenised (design/PLAN.md §3 D3, see the :root comment above for provenance/nodeIds). Utility classes, not custom properties, since they carry font-family/size/weight/line-height together — the same shape as every other 2.0 utility in this file. ------------------------------------------------------------ */ .t-u-13 { font-family: var(--font-sans); font-weight: 500; font-size: 13px; line-height: 15.73px; } .t-u-11m { font-family: var(--font-sans); font-weight: 500; font-size: 11px; line-height: 13.31px; } .t-u-12 { font-family: var(--font-sans); font-weight: 400; font-size: 12px; line-height: 14.52px; } .t-u-12m { font-family: var(--font-sans); font-weight: 500; font-size: 12px; line-height: 14.52px; } .t-u-11 { font-family: var(--font-sans); font-weight: 400; font-size: 11px; line-height: 13.31px; } /* ============================================================ 1i. The Intelligence panel's look, tokenised -- task D9 of design/behavior/PLAN_FULL_ATOMIC.md (second pass, 2026-10-06). Its 15 organism sheets (ds/organisms/intelligence-*.css) and its panel scripts (panels/intelligence/) held about 460 type and spacing literals, 6 motion literals and about 300 colour literals. EVERY VALUE IS UNCHANGED: only its home moved here, so the panel renders exactly as before (S20-R2, no pixel moves; checked against the base tree on the harness). ============================================================ */ :root { /* Text metrics one property at a time: the panel reads task E1's section 1h (--ra-fs-*, --ra-lh-24, --ra-ls-*; same names and values, the copy this section carried on its branch was dropped at the merge). Two tracking values are this panel's alone. */ --ra-ls-em-15: 0.15em; --ra-ls-em-18: 0.18em; /* The panel's own durations, named where they already ship (each value unchanged, so nothing moves faster or slower). */ --mo-dur-tip: 120ms; /* the kit tooltip's fade in and out (.ui-tip, ds/organisms/tooltip.js); the script hides it PV2.bt.timing.tooltipHide after the fade starts */ --mo-dur-bar: 200ms; /* the ticker percentile bar filling to its rank (.tk-pctile-fill) */ --mo-dur-chev-turn: 150ms; /* a collapsible briefing panel's chevron turning (.bio2-chev) */ --mo-dur-live-dot: 1.6s; /* one beat of the TODAY aside's RTH session dot (tdPulse) */ /* The parts of a colour the scripts compute per row: an industry's or a therapy area's hue (rail.js, today.js, bio.js) or a heat cell's chroma and alpha (rail.js) is data, so only the fixed lightness, chroma and alpha around it are tokens. */ --ra-intel-dot-l: 0.72; --ra-intel-dot-c: 0.14; /* today.js: the per-industry dot */ --ra-intel-ta-l: 0.72; /* bio.js: a therapy area's dot */ --ra-intel-ta-lo-l: 0.45; --ra-intel-ta-lo-a: 0.6; /* bio.js: a therapy area's bar, its start */ --ra-intel-ta-hi-l: 0.7; /* and its end */ --ra-intel-fda-bg-l: 0.3; --ra-intel-fda-bg-c: 0.07; --ra-intel-fda-bg-a: 0.5; /* bio.js: an FDA category chip */ --ra-intel-fda-ink-l: 0.84; --ra-intel-fda-ink-c: 0.12; --ra-intel-heat-l: 0.55; /* rail.js: a lit heat cell */ } /* The panel's colours, VALUE-NAMED (section 1e's rule: the frame never named them, so the value is the name): --ra-intel---[-a], with one of pos, neg, info, warn (the --hue-* variables), bg (--bg-hue), hNN (a fixed hue) or rgb-R-G-B; and in hundredths (thousandths when that is what the value carries), bgc for --bg-chroma. WHY THE SECOND SELECTOR: `.oil2` (ds/organisms/intelligence-oil.css) re-declares --hue-pos, --hue-neg, --hue-warn and --hue-info for its own subtree, and a custom property resolves the var() inside it where it is declared. Declared on :root alone, every hue-relative colour below would take the root's hues inside .oil2, where the literals it replaced took the subtree's. Declared on .oil2 too, it resolves there, so each one computes exactly what its literal computed. --hue-warn exists ONLY inside .oil2: on :root the warn colours are invalid, as their literals were outside it. */ :root, .oil2 { --ra-intel-bg-15-005-a80: oklch(0.15 0.005 var(--bg-hue) / 0.8); --ra-intel-bg-16-005: oklch(0.16 0.005 var(--bg-hue)); --ra-intel-bg-16-005-a50: oklch(0.16 0.005 var(--bg-hue) / 0.5); --ra-intel-bg-18-005: oklch(0.18 0.005 var(--bg-hue)); --ra-intel-bg-18-bgc-a95: oklch(0.18 var(--bg-chroma) var(--bg-hue) / 0.95); --ra-intel-bg-20-bgc-a35: oklch(0.20 var(--bg-chroma) var(--bg-hue) / 0.35); --ra-intel-bg-20-bgc-a50: oklch(0.20 var(--bg-chroma) var(--bg-hue) / 0.5); --ra-intel-bg-20-bgc-a95: oklch(0.20 var(--bg-chroma) var(--bg-hue) / 0.95); --ra-intel-bg-24-bgc: oklch(0.24 var(--bg-chroma) var(--bg-hue)); --ra-intel-bg-25-005-a30: oklch(0.25 0.005 var(--bg-hue) / 0.3); --ra-intel-bg-25-005-a40: oklch(0.25 0.005 var(--bg-hue) / 0.4); --ra-intel-bg-28-bgc: oklch(0.28 var(--bg-chroma) var(--bg-hue)); --ra-intel-bg-30-01: oklch(0.3 0.01 var(--bg-hue)); --ra-intel-bg-35-bgc-a50: oklch(0.35 var(--bg-chroma) var(--bg-hue) / 0.5); --ra-intel-bg-40-01-a50: oklch(0.4 0.01 var(--bg-hue) / 0.5); --ra-intel-bg-45-02: oklch(0.45 0.02 var(--bg-hue)); --ra-intel-bg-55-02: oklch(0.55 0.02 var(--bg-hue)); --ra-intel-bg-55-04: oklch(0.55 0.04 var(--bg-hue)); --ra-intel-bg-55-05: oklch(0.55 0.05 var(--bg-hue)); --ra-intel-bg-85-005-a70: oklch(0.85 0.005 var(--bg-hue) / 0.7); --ra-intel-bg-92-005: oklch(0.92 0.005 var(--bg-hue)); --ra-intel-bg-95-01: oklch(0.95 0.01 var(--bg-hue)); --ra-intel-bg-95-005: oklch(0.95 0.005 var(--bg-hue)); --ra-intel-bg-97-005: oklch(0.97 0.005 var(--bg-hue)); --ra-intel-bg-98-003: oklch(0.98 0.003 var(--bg-hue)); --ra-intel-bg-99-005: oklch(0.99 0.005 var(--bg-hue)); --ra-intel-h25-45-13-a32: oklch(0.45 0.13 25 / 0.32); --ra-intel-h25-45-16-a18: oklch(0.45 0.16 25 / 0.18); --ra-intel-h25-45-16-a20: oklch(0.45 0.16 25 / 0.2); --ra-intel-h25-45-16-a35: oklch(0.45 0.16 25 / 0.35); --ra-intel-h25-45-16-a55: oklch(0.45 0.16 25 / 0.55); --ra-intel-h25-68-18: oklch(0.68 0.18 25); --ra-intel-h30-32-10-a45: oklch(0.32 0.1 30 / 0.45); --ra-intel-h30-40-12-a30: oklch(0.4 0.12 30 / 0.3); --ra-intel-h30-45-10-a12: oklch(0.45 0.1 30 / 0.12); --ra-intel-h30-60-14-a40: oklch(0.6 0.14 30 / 0.4); --ra-intel-h30-68-18: oklch(0.68 0.18 30); --ra-intel-h30-70-18: oklch(0.7 0.18 30); --ra-intel-h30-72-15: oklch(0.72 0.15 30); --ra-intel-h30-78-16: oklch(0.78 0.16 30); --ra-intel-h30-82-16: oklch(0.82 0.16 30); --ra-intel-h30-84-15: oklch(0.84 0.15 30); --ra-intel-h30-85-16: oklch(0.85 0.16 30); --ra-intel-h40-45-14-a25: oklch(0.45 0.14 40 / 0.25); --ra-intel-h40-78-14: oklch(0.78 0.14 40); --ra-intel-h40-78-16: oklch(0.78 0.16 40); --ra-intel-h50-70-12: oklch(0.7 0.12 50); --ra-intel-h55-73-17: oklch(0.73 0.17 55); --ra-intel-h60-40-11-a32: oklch(0.4 0.11 60 / 0.32); --ra-intel-h60-70-16: oklch(0.7 0.16 60); --ra-intel-h60-72-14: oklch(0.72 0.14 60); --ra-intel-h60-78-16: oklch(0.78 0.16 60); --ra-intel-h60-82-16: oklch(0.82 0.16 60); --ra-intel-h60-85-13: oklch(0.85 0.13 60); --ra-intel-h70-28-08-a30: oklch(0.28 0.08 70 / 0.30); --ra-intel-h70-30-08-a40: oklch(0.30 0.08 70 / 0.40); --ra-intel-h70-30-08-a50: oklch(0.30 0.08 70 / 0.5); --ra-intel-h70-30-10-a40: oklch(0.30 0.10 70 / 0.40); --ra-intel-h70-45-10-a55: oklch(0.45 0.10 70 / 0.55); --ra-intel-h70-48-12-a55: oklch(0.48 0.12 70 / 0.55); --ra-intel-h70-55-10: oklch(0.55 0.10 70); --ra-intel-h70-55-14-a15: oklch(0.55 0.14 70 / 0.15); --ra-intel-h70-55-14-a40: oklch(0.55 0.14 70 / 0.4); --ra-intel-h70-55-14-a45: oklch(0.55 0.14 70 / 0.45); --ra-intel-h70-65-14: oklch(0.65 0.14 70); --ra-intel-h70-68-16: oklch(0.68 0.16 70); --ra-intel-h70-68-16-a55: oklch(0.68 0.16 70 / 0.55); --ra-intel-h70-78-13: oklch(0.78 0.13 70); --ra-intel-h70-78-14: oklch(0.78 0.14 70); --ra-intel-h70-78-16: oklch(0.78 0.16 70); --ra-intel-h70-80-14: oklch(0.80 0.14 70); --ra-intel-h70-82-13: oklch(0.82 0.13 70); --ra-intel-h70-82-16: oklch(0.82 0.16 70); --ra-intel-h70-86-14: oklch(0.86 0.14 70); --ra-intel-h75-18-012: oklch(0.18 0.012 75); --ra-intel-h75-84-14: oklch(0.84 0.14 75); --ra-intel-h75-97-012: oklch(0.97 0.012 75); --ra-intel-h80-45-12-a25: oklch(0.45 0.12 80 / 0.25); --ra-intel-h80-78-14: oklch(0.78 0.14 80); --ra-intel-h80-82-13: oklch(0.82 0.13 80); --ra-intel-h90-70-13: oklch(0.7 0.13 90); --ra-intel-h90-75-14: oklch(0.75 0.14 90); --ra-intel-h90-82-13: oklch(0.82 0.13 90); --ra-intel-h145-68-15: oklch(0.68 0.15 145); --ra-intel-h145-70-16: oklch(0.7 0.16 145); --ra-intel-h155-45-13-a18: oklch(0.45 0.13 155 / 0.18); --ra-intel-h155-45-13-a20: oklch(0.45 0.13 155 / 0.2); --ra-intel-h155-45-13-a35: oklch(0.45 0.13 155 / 0.35); --ra-intel-h155-45-13-a55: oklch(0.45 0.13 155 / 0.55); --ra-intel-h155-70-14: oklch(0.7 0.14 155); --ra-intel-h165-28-10-a30: oklch(0.28 0.10 165 / 0.30); --ra-intel-h165-48-13-a55: oklch(0.48 0.13 165 / 0.55); --ra-intel-h165-62-16: oklch(0.62 0.16 165); --ra-intel-h165-78-16: oklch(0.78 0.16 165); --ra-intel-h165-80-15: oklch(0.80 0.15 165); --ra-intel-h170-45-14-a25: oklch(0.45 0.14 170 / 0.25); --ra-intel-h170-78-12: oklch(0.78 0.12 170); --ra-intel-h195-80-13: oklch(0.80 0.13 195); --ra-intel-h200-40-10-a32: oklch(0.4 0.1 200 / 0.32); --ra-intel-h200-58-10: oklch(0.58 0.10 200); --ra-intel-h200-82-13: oklch(0.82 0.13 200); --ra-intel-h230-65-14: oklch(0.65 0.14 230); --ra-intel-h230-70-16: oklch(0.7 0.16 230); --ra-intel-h230-70-16-a18: oklch(0.7 0.16 230 / 0.18); --ra-intel-h230-78-14: oklch(0.78 0.14 230); --ra-intel-h235-68-18: oklch(0.68 0.18 235); --ra-intel-h240-32-04-a40: oklch(0.32 0.04 240 / 0.4); --ra-intel-h240-65-12: oklch(0.65 0.12 240); --ra-intel-h240-70-14: oklch(0.7 0.14 240); --ra-intel-h240-74-13: oklch(0.74 0.13 240); --ra-intel-h250-28-01-a50: oklch(0.28 0.01 250 / 0.5); --ra-intel-h250-30-01-a40: oklch(0.3 0.01 250 / 0.4); --ra-intel-h250-30-01-a50: oklch(0.3 0.01 250 / 0.5); --ra-intel-h250-32-01: oklch(0.32 0.01 250); --ra-intel-h250-32-01-a35: oklch(0.32 0.01 250 / 0.35); --ra-intel-h250-34-01: oklch(0.34 0.01 250); --ra-intel-h250-45-12-a18: oklch(0.45 0.12 250 / 0.18); --ra-intel-h250-45-12-a25: oklch(0.45 0.12 250 / 0.25); --ra-intel-h250-45-12-a30: oklch(0.45 0.12 250 / 0.3); --ra-intel-h250-45-12-a50: oklch(0.45 0.12 250 / 0.5); --ra-intel-h250-65-13: oklch(0.65 0.13 250); --ra-intel-h250-78-12: oklch(0.78 0.12 250); --ra-intel-h250-78-14: oklch(0.78 0.14 250); --ra-intel-h290-62-14: oklch(0.62 0.14 290); --ra-intel-h290-65-18: oklch(0.65 0.18 290); --ra-intel-h290-78-12: oklch(0.78 0.12 290); --ra-intel-info230-60-12: oklch(0.6 0.12 var(--hue-info, 230)); --ra-intel-info-20-025-a40: oklch(0.2 0.025 var(--hue-info) / 0.4); --ra-intel-info-24-04-a60: oklch(0.24 0.04 var(--hue-info) / 0.6); --ra-intel-info-30-05-a40: oklch(0.30 0.05 var(--hue-info) / 0.4); --ra-intel-info-30-07-a40: oklch(0.30 0.07 var(--hue-info) / 0.40); --ra-intel-info-30-08-a50: oklch(0.30 0.08 var(--hue-info) / 0.5); --ra-intel-info-32-06-a70: oklch(0.32 0.06 var(--hue-info) / 0.7); --ra-intel-info-32-08-a55: oklch(0.32 0.08 var(--hue-info) / 0.55); --ra-intel-info-40-04-a08: oklch(0.4 0.04 var(--hue-info) / 0.08); --ra-intel-info-45-10-a60: oklch(0.45 0.10 var(--hue-info) / 0.6); --ra-intel-info-55-12-a40: oklch(0.55 0.12 var(--hue-info) / 0.4); --ra-intel-info-55-12-a45: oklch(0.55 0.12 var(--hue-info) / 0.45); --ra-intel-info-55-12-a50: oklch(0.55 0.12 var(--hue-info) / 0.5); --ra-intel-info-55-14: oklch(0.55 0.14 var(--hue-info)); --ra-intel-info-55-14-a40: oklch(0.55 0.14 var(--hue-info) / 0.4); --ra-intel-info-55-14-a50: oklch(0.55 0.14 var(--hue-info) / 0.5); --ra-intel-info-55-14-a55: oklch(0.55 0.14 var(--hue-info) / 0.55); --ra-intel-info-55-14-a65: oklch(0.55 0.14 var(--hue-info) / 0.65); --ra-intel-info-60-14-a40: oklch(0.6 0.14 var(--hue-info) / 0.4); --ra-intel-info-60-14-a60: oklch(0.6 0.14 var(--hue-info) / 0.6); --ra-intel-info-62-14: oklch(0.62 0.14 var(--hue-info)); --ra-intel-info-62-16: oklch(0.62 0.16 var(--hue-info)); --ra-intel-info-62-16-a40: oklch(0.62 0.16 var(--hue-info) / 0.4); --ra-intel-info-65-13: oklch(0.65 0.13 var(--hue-info)); --ra-intel-info-65-13-a55: oklch(0.65 0.13 var(--hue-info) / 0.55); --ra-intel-info-65-14: oklch(0.65 0.14 var(--hue-info)); --ra-intel-info-70-13: oklch(0.70 0.13 var(--hue-info)); --ra-intel-info-70-14: oklch(0.7 0.14 var(--hue-info)); --ra-intel-info-72-12-a70: oklch(0.72 0.12 var(--hue-info) / 0.7); --ra-intel-info-74-13-a25: oklch(0.74 0.13 var(--hue-info) / 0.25); --ra-intel-info-74-13-a50: oklch(0.74 0.13 var(--hue-info) / 0.5); --ra-intel-info-74-15: oklch(0.74 0.15 var(--hue-info)); --ra-intel-info-78-13: oklch(0.78 0.13 var(--hue-info)); --ra-intel-info-78-14: oklch(0.78 0.14 var(--hue-info)); --ra-intel-info-80-12: oklch(0.80 0.12 var(--hue-info)); --ra-intel-info-82-11: oklch(0.82 0.11 var(--hue-info)); --ra-intel-info-86-10: oklch(0.86 0.10 var(--hue-info)); --ra-intel-neg-25-10-a45: oklch(0.25 0.10 var(--hue-neg) / 0.45); --ra-intel-neg-28-08-a50: oklch(0.28 0.08 var(--hue-neg) / 0.5); --ra-intel-neg-28-10-a30: oklch(0.28 0.10 var(--hue-neg) / 0.30); --ra-intel-neg-30-06-a40: oklch(0.3 0.06 var(--hue-neg) / 0.4); --ra-intel-neg-30-10-a40: oklch(0.30 0.10 var(--hue-neg) / 0.40); --ra-intel-neg-32-06-a40: oklch(0.32 0.06 var(--hue-neg) / 0.4); --ra-intel-neg-40-10-a55: oklch(0.40 0.10 var(--hue-neg) / 0.55); --ra-intel-neg-45-13-a70: oklch(0.45 0.13 var(--hue-neg) / 0.70); --ra-intel-neg-45-15-a40: oklch(0.45 0.15 var(--hue-neg) / 0.4); --ra-intel-neg-48-14-a55: oklch(0.48 0.14 var(--hue-neg) / 0.55); --ra-intel-neg-55-14-a50: oklch(0.55 0.14 var(--hue-neg) / 0.5); --ra-intel-neg-62-16: oklch(0.62 0.16 var(--hue-neg)); --ra-intel-neg-62-18: oklch(0.62 0.18 var(--hue-neg)); --ra-intel-neg-62-18-a55: oklch(0.62 0.18 var(--hue-neg) / 0.55); --ra-intel-neg-70-16: oklch(0.7 0.16 var(--hue-neg)); --ra-intel-neg-74-14: oklch(0.74 0.14 var(--hue-neg)); --ra-intel-neg-74-16: oklch(0.74 0.16 var(--hue-neg)); --ra-intel-neg-74-17: oklch(0.74 0.17 var(--hue-neg)); --ra-intel-neg-74-18: oklch(0.74 0.18 var(--hue-neg)); --ra-intel-neg-75-14: oklch(0.75 0.14 var(--hue-neg)); --ra-intel-neg-78-15: oklch(0.78 0.15 var(--hue-neg)); --ra-intel-neg-78-16: oklch(0.78 0.16 var(--hue-neg)); --ra-intel-neg-80-14: oklch(0.80 0.14 var(--hue-neg)); --ra-intel-pos-22-05-a30: oklch(0.22 0.05 var(--hue-pos) / 0.3); --ra-intel-pos-30-06-a40: oklch(0.3 0.06 var(--hue-pos) / 0.4); --ra-intel-pos-32-06-a40: oklch(0.32 0.06 var(--hue-pos) / 0.4); --ra-intel-pos-50-13: oklch(0.5 0.13 var(--hue-pos)); --ra-intel-pos-55-14-a50: oklch(0.55 0.14 var(--hue-pos) / 0.5); --ra-intel-pos-70-14: oklch(0.7 0.14 var(--hue-pos)); --ra-intel-pos-74-14: oklch(0.74 0.14 var(--hue-pos)); --ra-intel-pos-74-16: oklch(0.74 0.16 var(--hue-pos)); --ra-intel-pos-78-14: oklch(0.78 0.14 var(--hue-pos)); --ra-intel-pos-78-15: oklch(0.78 0.15 var(--hue-pos)); --ra-intel-pos-78-16: oklch(0.78 0.16 var(--hue-pos)); --ra-intel-pos-80-15: oklch(0.8 0.15 var(--hue-pos)); --ra-intel-rgb-0-0-0-a50: rgba(0, 0, 0, 0.5); --ra-intel-rgb-255-255-255-a02: rgba(255, 255, 255, 0.02); --ra-intel-rgb-255-255-255-a03: rgba(255, 255, 255, 0.03); --ra-intel-warn-70-14: oklch(0.7 0.14 var(--hue-warn)); --ra-intel-warn-74-13: oklch(0.74 0.13 var(--hue-warn)); --ra-intel-warn-74-14: oklch(0.74 0.14 var(--hue-warn)); --ra-intel-warn-78-14: oklch(0.78 0.14 var(--hue-warn)); --ra-intel-warn-82-13: oklch(0.82 0.13 var(--hue-warn)); --ra-intel-inset-deep-a20: oklch(from var(--ra-surface-inset-deep) l c h / 0.2); /* the peers table's even-row stripe */ } /* ============================================================ 1j. The Composer and Watchlists panels' colours, and the Stats, Composer and Watchlists text metrics -- task D15 of design/behavior/PLAN_FULL_ATOMIC.md (2026-10-06). Their organism sheets (ds/organisms/composer-*.css, watchlists-*.css, stats-*.css) held 43 colour, 54 type and spacing and 2 motion literals. EVERY VALUE IS UNCHANGED: a colour moved here under its value's name, a size or a spacing went onto the existing token of the same value (sections 1d, 1e, 1h), so the panels render exactly as before (S20-R2, no pixel moves). VALUE-NAMED (section 1e's rule: the frame never named them, so the value is the name): --ra----[-a], one of info, pos, neg (the --hue-* variables), bg (--bg-hue) or hNN (a fixed hue); and in hundredths (thousandths when the value carries them), bgc for --bg-chroma. Declared on :root, where --hue-* and --bg-* are declared and where the Customization section stamps them, so each resolves to what its literal resolved to. No subtree of either panel redeclares a hue. ============================================================ */ :root { /* a disclosure caret turning: a watchlist sublist's caret (.wl-sec-head .cv), shipped .12s */ --mo-dur-caret-turn: 120ms; /* Composer (ds/organisms/composer-*.css; composer-light.css's three are the light theme's chip and value grounds, used under [data-theme="light"] there) */ --ra-cmp-bg-12-bgc: oklch(0.12 var(--bg-chroma) var(--bg-hue)); --ra-cmp-bg-12-bgc-a70: oklch(0.12 var(--bg-chroma) var(--bg-hue) / 0.7); --ra-cmp-bg-14-bgc: oklch(0.14 var(--bg-chroma) var(--bg-hue)); --ra-cmp-bg-14-bgc-a50: oklch(0.14 var(--bg-chroma) var(--bg-hue) / 0.5); --ra-cmp-bg-14-bgc-a70: oklch(0.14 var(--bg-chroma) var(--bg-hue) / 0.7); --ra-cmp-bg-15-bgc-a50: oklch(0.15 var(--bg-chroma) var(--bg-hue) / 0.5); --ra-cmp-bg-16-bgc-a50: oklch(0.16 var(--bg-chroma) var(--bg-hue) / 0.5); --ra-cmp-bg-16-bgc-a60: oklch(0.16 var(--bg-chroma) var(--bg-hue) / 0.6); --ra-cmp-bg-17-bgc-a50: oklch(0.17 var(--bg-chroma) var(--bg-hue) / 0.5); --ra-cmp-bg-22-bgc-a30: oklch(0.22 var(--bg-chroma) var(--bg-hue) / 0.3); --ra-cmp-bg-23-bgc-a50: oklch(0.23 var(--bg-chroma) var(--bg-hue) / 0.5); --ra-cmp-h0-100-0: oklch(1 0 0); --ra-cmp-h70-50-04-a30: oklch(0.5 0.04 70 / 0.3); --ra-cmp-h70-97-006: oklch(0.97 0.006 70); --ra-cmp-h75-98-006: oklch(0.98 0.006 75); --ra-cmp-h85-60-12-a18: oklch(0.6 0.12 85 / 0.18); --ra-cmp-info-17-012-a40: oklch(0.17 0.012 var(--hue-info) / 0.40); --ra-cmp-info-18-018-a45: oklch(0.18 0.018 var(--hue-info) / 0.45); --ra-cmp-info-40-06-a35: oklch(0.40 0.06 var(--hue-info) / 0.35); --ra-cmp-info-50-08-a40: oklch(0.50 0.08 var(--hue-info) / 0.40); --ra-cmp-info-55-12-a18: oklch(0.55 0.12 var(--hue-info) / 0.18); --ra-cmp-info-55-12-a20: oklch(0.55 0.12 var(--hue-info) / 0.2); --ra-cmp-info-55-14-a18: oklch(0.55 0.14 var(--hue-info) / 0.18); --ra-cmp-info-55-14-a25: oklch(0.55 0.14 var(--hue-info) / 0.25); --ra-cmp-info-55-14-a40: oklch(0.55 0.14 var(--hue-info) / 0.4); --ra-cmp-info-55-14-a45: oklch(0.55 0.14 var(--hue-info) / 0.45); --ra-cmp-info-55-14-a55: oklch(0.55 0.14 var(--hue-info) / 0.55); --ra-cmp-neg-55-14-a20: oklch(0.55 0.14 var(--hue-neg) / 0.2); --ra-cmp-pos-55-12-a20: oklch(0.55 0.12 var(--hue-pos) / 0.2); /* Watchlists (ds/organisms/watchlists-*.css) */ --ra-wl-bg-13-bgc: oklch(0.13 var(--bg-chroma) var(--bg-hue)); --ra-wl-bg-17-bgc: oklch(0.17 var(--bg-chroma) var(--bg-hue)); --ra-wl-bg-18-bgc: oklch(0.18 var(--bg-chroma) var(--bg-hue)); --ra-wl-bg-20-bgc: oklch(0.20 var(--bg-chroma) var(--bg-hue)); --ra-wl-bg-21-bgc: oklch(0.21 var(--bg-chroma) var(--bg-hue)); --ra-wl-h0-0-0-a50: oklch(0 0 0 / .5); --ra-wl-info-55-10-a14: oklch(0.55 0.10 var(--hue-info,250) / .14); --ra-wl-info-60-12-a70: oklch(0.6 0.12 var(--hue-info,250) / .7); --ra-wl-info-72-14: oklch(0.72 0.14 var(--hue-info,250)); --ra-wl-info-78-14: oklch(0.78 0.14 var(--hue-info,250)); } /* Chart-token light theme. FROZEN verbatim per design/PLAN.md §4.6: the 2.0 section has not one light frame (dark-only), so this block is carried over unchanged rather than migrated or deleted — deleting it would remove shipped, user-selectable functionality (the theme toggle), and inventing a light 2.0 palette would be exactly the "fill the gap by eye" design/DESIGN_SPEC.md §5 forbids. Escalated to the team-lead for ratification per design/PLAN.md §10.8. Never remapped, in S4 or later. */ [data-theme="light"] { /* S19 §2.1: no light-theme frame exists for any composition node, so light cannot be frame-derived -- --bg-0 is exactly what these fields already render today in light, so light is byte-identical after this token lands and only dark moves to the frame's #1A1A1A. A repoint, never an invention -- the precedent S18 set twice for this same file. */ --ra-surface-field: var(--bg-0); --ra-text-hover: var(--text-1); /* Figma round 2026-10-09 (fig-automations review): --ra-accent-primary-soft had no light value, so its mint #7EE0CD read 1.43:1 on --surf-hi (the counter badge's digits, the topbar's on icon, the chart sidebar's on button, the stats values). Light repoints it at the accent's deep step, 5% darker for AA: 4.84:1 on --surf-hi, 5.28:1 on --bg-1. Fills that carry --ra-surface-tape (--bg-2) on it read 4.43:1 (were 1.31:1); the one fill with --ra-text-on-accent on it (the harness chat's allow-once) drops from 13.28:1 to 3.93:1. */ --ra-accent-primary-soft: color-mix(in oklch, var(--ra-accent-deep), black 5%); /* seal/checkbox has no light frame: the unchecked box's greys repoint at the light ramp (fill --bg-2 flips on its own); the blues and the white mark hold. */ --ra-control-checkbox-border: var(--text-2); --ra-control-checkbox-hover-bg: color-mix(in oklch, var(--bg-2), var(--bg-3)); --ra-control-checkbox-hover-border: var(--text-2); --ra-control-checkbox-pressed-bg: var(--bg-3); --ra-control-checkbox-disabled-border: var(--line-strong); /* seal/button Neutral has no light frame either: stroke and label repoint at the light ramp. */ --ra-control-button-border: var(--line-strong); --ra-control-button-ink: var(--text-1); /* S46 task #35 — the four news-screen light derivations, measured live (design/s46/qa/rg_colors_s46.js), not modelled (HANDOFF_S46.md §3.1 records two modelled OKLCH predictions failing, one of them the team-lead's own). border.hairline/border.control have NO entry here — their dark hex already passes 15.6:1/14.4:1 carried unchanged into light (:root comment above them explains why a dark line needs no light-specific derivation the way a dark FILL does), and text.inactive likewise carries unchanged (5.23:1, passes; its failure is dark-theme only, see its :root comment — not this block's problem to solve). --ra-surface-chip-count: one tier darker than the light page, same derivation --ra-surface-inset already uses (var(--bg-2)) — a light chip that's actually recessed, not the dark hex's near-black blob on white that measures a technical pass task #38 explicitly warned isn't a real one (NEWS_CONTRAST_S46.md §7.2). --ra-signal-bull/bear/neutral: dark hex carried unchanged fails in light (task #38 §7.3: 1.71 / 2.75 / 2.42 against floor) — each darkened by binary search (color-mix in oklab) until its measured floor clears with margin: bull/bear against a modelled 14%-tint impact-bar background (this file's own .pill.pos/.pill.neg tint convention, 3:1, landed at 3.20-3.22 — #24 has not built the real component yet, so re-verify once it exists); neutral against BOTH its floors at once — 4.5:1 as the duplicate-chip's text (the stricter of its two roles, satisfies the impact bar's 3:1 for free) — landed 4.53 on --ra-surface-chip-count's own new light value above and 4.35 on its own impact-bar tint. Raw numbers: design/s46/RED_GREEN_COLOR_S46.md. */ --ra-surface-chip-count: var(--bg-2); --ra-signal-bull: #218F56; --ra-signal-bear: #D94C54; --ra-signal-neutral: #616B75; /* S19 §2.2: the light ink, derived not chosen -- see the :root comment above (10.05:1 on white). */ --ra-caret-select: url("data:image/svg+xml;utf8,"); /* F9 (QA_VERDICT_S22.md): --ra-text-bright had NO light value anywhere, so index.html's footer message-rate digit (inline style, `color:var( --ra-text-bright)`) stayed #E6EDF3 (near-white) over the light topbar pill (measured live: oklch(0.97 0.006 75) background) -- contrast ~1.05:1, the digit effectively invisible (qa/parity_light_theme.png). No light-theme frame exists for this node either, so same "derived not chosen" move as the caret ink two lines up: reuse #47413C, the SAME resolved light value already measured at 10.05:1 on white for --ra-text-secondary (S19 §2.2's own derivation) -- "bright" is the highest-prominence text tier in both themes, and in light mode that means the darkest ink, not a second arbitrary colour. */ --ra-text-bright: #47413C; /* R10 (design/UX-REVIEW-recorder.md, owner ruling S24-R5 CORRECTION, task #21): --ra-surface-inset had NO light value anywhere, so every surface painted with it stayed the dark #1C2024 under the light theme while the ink around it went dark too. Measured through the renderer (a 1x1 canvas fill + getImageData — never by parsing the colour string, AGENTS.md S23-Q1a), light theme, BEFORE: recording-row title 1.06:1, row meta 2.98:1, the recorder's permission banner 1.63:1 — three consumers, all three unreadable, not the one the review found. A REPOINT, never an invention — the move S19 §2.1 and F9 above both made for the same shape of gap (no light frame exists to arbitrate): --bg-2 is already this theme's card surface (it is what `.snd-pop .snd-card` paints and what S19-R7's owner-approved rule colours were measured against). Chosen by measuring all four plausible candidates on the real elements, not by eye: --bg-1 (white) makes every ratio higher but the row vanishes into the white panel (1.0:1 against it — no card left); --bg-3 and --ra-surface-card resolve to the same oklch(0.88 0.01 75) and leave the row meta at 3.83:1, still failing. --bg-2 is the only candidate where all three consumers clear 4.5:1 (14.44 / 4.59 / 8.39) AND the row still reads as an inset against the panel (1.2:1). Readings: design/s24/arch/ r8r10_before.json and r8r10_after.json. CENSUS — CORRECTED. The first version of this comment claimed "exactly TWO rules, both in the Recorder tab, so nothing outside it can regress". That was WRONG: it came from a grep of *.css only, and the team-lead caught the third consumer. The token is also read from JS, in an inline style — panels/intelligence/rail.js:51, the intel peers heat-map's UNLIT cell (its own comment at :44 names the token). A CSS-only grep is not a census in this repo; S20 §F already recorded that ~400 colour literals live in JS. The command that produces the real list is `grep -rn -- "--ra-surface-inset\b" platform/frontend` across ALL file types. Three consumers: 1. panels/recorder/player.css:41 — recording row 2. panels/recorder/recorder.css:51 — permission/unsupported banner 3. panels/intelligence/rail.js:51 — heat-map unlit cell The third one was then measured on the live Intelligence tab (240 cells, 14 of them unlit), and it IMPROVED — in the direction its own CD-426 comment intends ("the UNLIT cell is an opaque NEUTRAL"). Light theme, unlit cell against the strip it sits in: 11.43:1 BEFORE (the no-data cell was the loudest mark in the strip, 3.3x louder than a lit one at 3.5:1) -> 1.20:1 AFTER, with lit cells unchanged at 3.5:1. Dark theme: identical before and after (1.04:1). Pictures: design/s24/arch/r10_intel_*_strip_*.png. SEPARATE, NOT FIXED HERE: --ra-surface-inset-DEEP (line 44) is a different token and it has NO light value either. Measured the same way on `.data-table thead th` (components.css:1192, used by Intelligence and Stats): 4.45:1 in dark, 3.57:1 in LIGHT — below the 4.5:1 minimum. It needs its own census over every .data-table consumer, so it is filed, not folded into this task. */ --ra-surface-inset: var(--bg-2); /* S19 §17 / OWNER RULING S19-R7 ("Yes, derive darker versions."): the 8 per-sound rule colours have no light value anywhere -- 4 of 8 sit below 1.9:1 on the light rule-card surface. No light-theme frame exists for any composition node, so the frame cannot arbitrate; the owner accepted deriving readable variants of HIS eight colours, same hues, shown to him before landing (design/s19/sbs/s19r7_rule_colors_dark_vs_light.png). Derivation (design/s19/dev_a/rule_colors_light.js, colour math reused verbatim from design/s13/qa/qa_s13_a6e_verify.js, self-tested 8/8 against Sharma et al. published CIEDE2000 reference pairs before this script runs anything else): each dark value walked toward L=0 at fixed hue until contrast >= 4.5:1 against the real paint surface (the background `[data-theme="light"] .snd-pop .snd-card` sets via var(--bg-2), screener.css:1903 -- oklch(0.94 0.008 75) = #EDEAE6). Independent per-colour darkening alone made TWO pairs (mint/green, tangerine/peach) converge well below the dark palette's own closest pair (4.36 dE2000, mint/green) -- both pairs' dark-palette separation is mostly CHROMA, and the higher-chroma member of each pair loses chroma to sRGB gamut clipping at the L needed for 4.5:1, drifting onto its partner. Fixed by a joint coordinate-ascent hue offset per colour (same +-10deg "recognisably preserved" budget the S13-A6e precedent used), maximising the GLOBAL minimum pairwise dE2000 across all 28 pairs rather than just the single worst pair (which only relocates the problem). Result: light palette's closest pair is 9.55 dE2000 (tangerine/peach) -- BETTER than dark's own 4.36 floor, not just "no worse". All 8 hue shifts <=10deg, all 8 contrasts 4.50-4.55:1 (measured against the real surface, not a rounder floor). Full measurements: design/s19/dev_a/ rule_colors_light_report.json. */ --ra-rule-orange: #975C01; --ra-rule-violet: #8B4EB9; --ra-rule-sky: #046EB0; --ra-rule-mint: #0B794E; --ra-rule-green: #067B11; --ra-rule-tangerine: #C03A1A; --ra-rule-peach: #A8521A; --ra-rule-steel: #546B8C; --ra-chart-overlay-icon: #1F8FBF; /* S17-R31: ours, measured 3.66:1 on white (frame is silent) */ --ch-ax: #666; --ch-text: #111; --ch-label-bg: #d8d8d8; --ch-sep: #e2e2e2; --ch-draw: #1a1a1a; --ch-draw-label: #1a1a1a; --ch-draw-label-fg: #fff; --ch-tip-bg: rgba(255,255,255,0.92); --ch-crosshair: #aaa; --ch-tip-border: rgba(0,0,0,0.15); --ch-sub-line: #d8dade; --ch-scrim: rgba(240,240,244,0.62); --ch-scrim-fg: #333; --ch-marker-buy: #1b9e5a; --ch-marker-sell: #d23b3b; /* Not part of the original frozen carry-over set above (§4.6) — these 3 are newly tokenised out of features/chart/render.js's old `_lt ? a : b` ternary (never a CSS var before), so both variants are declared fresh here rather than "frozen", following the same dark/light split every other --ch-* token already uses. */ --ch-hover-fill: rgba(0,0,0,0.05); --ch-hover-crosshair: rgba(0,0,0,0.55); --ch-hover-preview: rgba(0,0,0,0.45); --ch-eth-shade: oklch(0.85 0.01 60 / 0.35); /* Gamma environment band, light half (S40 task #9). Same hue per role as the dark block -- only lightness and chroma move, the discipline the --ra-rule-* light variants used in S19 -- so the band keeps its identity across the theme switch. THE LIGHT SURFACE IS NOT --ra-chart-bg, and measuring against that token would have measured a surface nobody sees: [data-theme="light"] never overrides --ra-chart-bg, it overrides --ra-surface-panel to --surf-hi (widgets.css) and the canvas is transparent over the panel. So these two are measured on oklch(0.97 0.006 75), the surface actually painted. Rail contrast 4.37 positive / 6.82 negative; nearest drawn neighbour 23.93 and 24.42 against a 14.93 floor. Full readings, both themes: design/s40/ramp_contrast.out section [5]. */ --ch-gex-env-pos: oklch(0.55 0.12 110); --ch-gex-env-neg: oklch(0.47 0.155 320); /* S41 gamma flip, light half — same hue as the dark value, only L/C move (the S19 discipline above). #086B6C: min dE00 20.21 to every drawn neighbour, 6.31:1 on the painted light surface — the pick search is design/s41/gexline_hue_pick.py, .out committed. The wall tokens need no light entry: they alias --ch-gex-env-* and follow these two overrides. */ --ch-gex-flip: oklch(0.48 0.08 195); /* F-13 / S16-R1 (OWNER RULING: "fix the whole piece") — R4, THE TOKEN LINE. --ra-surface-panel had NO light value anywhere, so [data-theme="light"] .panel set its background DIRECTLY to white while every surface built FROM the token stayed dark on it: 9 selectors across 4 of the 5 parity routes, including .rail — the 81px global left navigation, dark on a white page, app-wide. WHY THIS VALUE AND NOT A NEW ONE: --surf-hi is an EXISTING light-theme token (css/widgets.css:999, oklch(0.97 0.006 75)) — nothing is minted here. It is also the exact value dev-b's throwaway-override prototype was measured under, so this ships the value that was measured rather than one that merely computes the same today. ORDER IS THE INTENT: the dependent text/value/badge colours (R1-R3) landed FIRST, in 49cad708 / 47b4ad03 / ac733429, because flipping this line alone was measured to trade one visible defect for two new ones (.st-metric values and .intel-today headings, found BY SCREENSHOT). The gate for this commit was dev-b's falsifiable 9/9-clean sweep at design/s16/dev_b/f13_sweep.9of9.json — not a conversational handoff. NOT INCLUDED, deliberately: --ra-surface-panel-alt has the identical gap. R3 measured the Intelligence badges to be #intel-today .badge on --ra-surface-card, NOT -alt, so -alt's only consumer app-wide remains #intel-today .intel-empty — an EMPTY STATE a page-load sweep does not reach. Flipping it here would ship an unmeasured change under cover of a measured one. */ --ra-surface-panel: var(--surf-hi); } /* ============================================================ 4. The light theme's legacy palette and repoints -- moved VERBATIM from ds/themes/light.css by E1 (2026-10-05, design/behavior/PLAN_FULL_ATOMIC.md): that file was on migrationDebt for these literals, and this is the one file allowed to hold them. Same selector, and still the LAST [data-theme="light"] declaration of every name below (light.css loaded after tokens.css, and this block sits after the chart-token light block above), so every computed value is unchanged. Comments below that say "this file" or "below" were written in ds/themes/light.css and refer to it; its rules now consume the --ra-lt-* tokens declared at the end of this block. ============================================================ */ /* design/PLAN.md §8.1 #15 (P5): --surf/--pos-dim/--neg-dim/--info-dim deleted from this block — 0 consumers for each anywhere in platform/frontend (dark-theme counterparts deleted the same commit, tokens/tokens.css §2). A light-theme value for a variable nobody reads is dead code a future reader would otherwise assume is live. Not a remap — no surviving light-theme value changed, D10's "frozen verbatim" still holds for everything this block still renders. */ [data-theme="light"] { --hue-info: 235; --bg-0: oklch(0.955 0.008 75); --bg-1: oklch(1 0 0); --bg-2: oklch(0.94 0.008 75); --bg-3: oklch(0.88 0.01 75); --surf-hi: oklch(0.97 0.006 75); --line: oklch(0.45 0.01 75 / 0.18); --line-strong: oklch(0.35 0.012 75 / 0.3); --text-1: oklch(0.22 0.01 70); --text-2: oklch(0.38 0.012 70); /* S33 #53 (owner ruling, brief SESSION 33 item 2 -- "fix the light theme too", same rigour as S32 #42's dark pass): both raised BY DARKENING (light theme puts dark text on light grounds, so more contrast = lower L, the mirror of dark theme's "raise = lighten"). Canvas-normalized binary search (S16-B1 -- oklch() must be resolved via a canvas fillStyle/getImageData round-trip, never regex-matched) against the worst REAL composited ground found live across all 6 baseline panels (design/s33/dev_a/instrument/light_grey_probe.js + design-qa's own banked run-20260827T-grey-light), not a synthetic --bg-0/--bg-1 pair: --text-3 was 3.83:1 on rgb(219,215,208) (news "ACCESS Newswire" et al buttons); --text-4 was 2.82:1 on rgb(238,234,229) (screener's timeframe chip / currency code). Chose the DARKEST real ground either token actually sits on, same discipline as #42. --text-3: 0.52 -> 0.48 clears 4.60:1 on its worst ground (was 3.83). --text-4: 0.64 -> 0.52 clears 4.60:1 on its worst ground (was 2.82). --ra-text-dim aliases var(--text-2) two lines up (widgets.css light block, F-13-as-a-class repoint) so its own 4.24 near-miss (named in this same ruling) closes for free -- no second edit. HIERARCHY HELD: new order by L is text1 .22 < text2 .38 < text3 .48 < text4 .52 -- both still fainter than --text-2, still ordered the same as before (text3 darker/more-prominent than text4), gap to --text-2 compresses from .14/.26 to .10/.14 but does not invert or collide. Dark theme untouched -- these two names exist ONLY in this [data-theme="light"] block; tokens.css's :root values are a SEPARATE declaration this edit never touches, re-verified byte-identical after (design/s33/dev_a/T53_dark_after_readings.json). FILED, NOT FIXED (measured, this same pass): three sites style text with these two token names against a FIXED dark background that does NOT flip with theme (screener.css:424 `.scr-act table.data th`, watchlists.css:59 `.wl-sec-head`, widgets.css:936 `.sig-chip-count`, since removed) -- the identical "F-13 as a class" cascade defect this file's own history already names repeatedly, one tier removed: these three read the LIGHT-theme value of a token whose actual background never left dark theme. All three were ALREADY below 3:1 before this edit (3.57 / 3.48 / 3.25) and get WORSE by darkening further (3.01 / 2.93 / 1.99) as an unavoidable side effect of raising the shared token for its correct (theme-following) consumers. The real fix is a repoint, not a token value -- these three selectors want the DARK-theme reading of --ra-text-tertiary/--ra-text-faint regardless of the active theme, which is a code change to three files across two other devs' panels, out of this task's scope (raise the palette, not decouple a cascade). Numbers: design/s33/dev_a/T53_fixed_dark_surfaces.md. */ --text-3: oklch(0.48 0.012 70); --text-4: oklch(0.52 0.01 70); --pos: oklch(0.5 0.14 155); --pos-bg: oklch(0.88 0.08 155 / 0.45); --neg: oklch(0.5 0.19 25); --neg-bg: oklch(0.88 0.08 25 / 0.45); --info: oklch(0.46 0.17 235); --info-bg: oklch(0.9 0.05 235 / 0.55); --warn: oklch(0.58 0.15 70); /* --ra-link-ring (S15, W1/target-marker colour): pure white (its own :root value, tokens.css) against a white .panel background (:1015, below) is contrast 1.00 -- the ring does not render in light theme at its :root value at all, measured live rather than assumed from the token's own definition. Reused var(--ra-surface-black) (pure black, tokens.css) rather than mint a new token or write a literal here (widgets.css is on migrationDebt, the ratchet blocks new colour literals -- avoiding the hex spelling in this comment on purpose, same trap F4's own comment already names: token_lint's HEX_RE flags it even inside a comment describing an already-allowed value) -- pure black is also the MEASURED CEILING at the marker's fixed 40% opacity against this white background (~2.7-2.84, not the dark-theme reading's 3.80 -- no darker tone exists to close that gap at this opacity, it is a property of the alpha value, not the colour). components.css names the full comparison (--ra-text-primary doesn't flip; the legacy --text-1 above flips but renders lighter than this ceiling). */ --ra-link-ring: var(--ra-surface-black); /* F-13 AS A CLASS, DEPENDENCY CLOSURE (S16-R14, revised): the text-token cascade below (--ra-text-primary/-secondary/-tertiary) is UNSHIPPABLE standalone -- measured live (design/s16/dev_b/cascade_contrast.json), 10 selectors across 5 routes went to ~1.0-1.9 contrast (effectively invisible) because their text goes dark under the cascade while their OWN background sits on a DIFFERENT unflipped --ra-surface-* token. THE TIERING IS RECURSIVE: R1-R3-before-R4 was this same pattern at the text-on-panel tier (dependent text colours had to flip before the surface they sit on); this is the identical pattern one tier deeper, text-on-tape/-card/-bubble/-header. A "safe one-line cascade" earns that description only after its own dependents are checked -- it is not a property of using an existing alias, which was the reasoning that missed this the first time. Preserves the dark-theme RELATIVE ORDER onto the light aliases rather than picking values (same reasoning as --bg-3 on the Intelligence selected row, S16-R14): dark lightness order is base < panel < tape < card < card-elevated; --ra-surface-panel already flips to --surf-hi (R4), so tape/card land one and two steps further from it, respectively -- --bg-2 (a half-step off --surf-hi) for tape, --bg-3 (a full step) for card. --ra-surface-bubble-user (#24282E, a chat "user" bubble) sits within one hex step of --ra-surface-card itself (#23282C) -- takes --bg-3 to match, not a separate guess. --ra-surface-header (#0D1114, darker than panel's own #0D1319 in dark theme) takes --bg-2, the same half-step below --surf-hi tape got, since header sits between panel and tape in the dark ladder. No new token minted, all four already exist above in this same block. */ --ra-surface-tape: var(--bg-2); --ra-surface-card: var(--bg-3); --ra-surface-bubble-user: var(--bg-3); --ra-surface-header: var(--bg-2); /* --ra-surface-panel-alt -- DEFERRAL REVERSED (S16-R1 deferred this as a NEUTRAL change nobody had measured; the trio below measures it WORSE: its one consumer, #intel-today .intel-empty, was readable white-on-dark before the trio and goes invisible dark-on-dark after it -- the deferral's premise (leaving it alone changes nothing) no longer holds, so the deferral does not survive it, S16-R10's class applied to a ruling rather than a code path). --surf-hi, matching --ra-surface-panel's OWN light value exactly, not --bg-2/-3: panel and panel-alt sit within 2 hex units of each other in dark theme (#0D1319 vs #0D1117) -- closer to each other than either is to tape or card, so panel-alt tracks panel's own flip rather than getting a visually distinct one the dark values never had either. */ --ra-surface-panel-alt: var(--surf-hi); /* F-13 AS A CLASS (S16-R14, the cascade trio) -- this file's own comment above already named the mechanism in passing while picking the ring colour ("--ra-text-primary doesn't flip") and nobody closed it. --ra-text-primary/-secondary/-tertiary are read DIRECTLY (bypassing --text-1/-2/-3) by 25-28 sites each across the app (measured, design/s16/dev_b/f13_class_census.json) -- every default value colour, panel title, table header, placeholder etc that doesn't route through the legacy alias. A TOKEN-LEVEL repoint here, not a per-site fix: these three ALREADY have an existing, already-verified light value one line above (the --text-N family) -- pointing the --ra- name at its own alias closes every direct consumer in one line each, the same shape R4 used for --ra-surface-panel. Lands AFTER the five surface repoints above, in the SAME commit -- the dependency, not a coincidence of file position. LIGHT-SCOPED ONLY (this block, not tokens.css's :root) -- the dark-theme value is untouched, --ra- and --text-N stay two names for one value exactly as they are today. No new token minted. */ --ra-text-primary: var(--text-1); --ra-text-secondary: var(--text-2); --ra-text-tertiary: var(--text-2); /* F-13 AS A CLASS (S16-R14, cascade-shaped members of the top-8, ruled GO after triage by shape rather than site count). Four tokens, lower-risk than the text/surface tiers above: three are BORDER roles (thin lines, not fills -- a wrong pick reads as slightly-off, not invisible, the risk profile the lead named), the fourth is a surface one hex-step up from --ra-surface-card. --ra-border-default (#1A222B) / --ra-border-card (#23282C, identical to --ra-surface-card's own dark value): both take --line, the existing default light-theme border token every other border in this file already uses (.btn/.input/.segmented/.ch-sb button etc) -- --ra-border-card's own largest consumer, .panel, ALREADY carries its own direct light border-color override (widgets.css:1033, close to --line's own value, L .4 vs .45) so this repoint is a no-op there and a real fix everywhere else (search-pill, table borders, Intelligence rail dividers). --ra-border-strong (#1A2332, identical to --ra-surface-chip's own dark value -- the Intelligence selected-row token from this same session, already mapped to --bg-3): takes --line-strong, the existing STRONGER light border pair to --line's default, matching both the name and the emphasised/hover consumers it actually has (the cind/cols-chip menu borders). --ra-surface-card-elevated (#2A2F33, one hex-step lighter than --ra-surface-card's own #23282C in dark theme): takes --bg-3, the SAME value as --ra-surface-card. No fourth light surface tier exists beyond --bg-2/--bg-3/--surf-hi without minting one (against this session's own rule) -- card and card-elevated's subtle dark-theme distinction collapses to one shade in light theme, an accepted simplification, not a defect: nothing goes invisible, two adjacent surfaces (mostly hover/popout chip backgrounds) simply render identically instead of one shade apart. Recorded so a later session does not "fix" this by minting a --bg-4 nobody asked for. No new token minted anywhere in this rule -- four repoints, all pointing at values already in this light-theme block. */ --ra-border-default: var(--line); --ra-border-card: var(--line); --ra-border-strong: var(--line-strong); --ra-surface-card-elevated: var(--bg-3); /* F-13 AS A CLASS -- three more, triaged cascade-shaped: --ra-text-axis (#606060): CHECKED against the hypothesis that it rides the --ch-* alias layer for chart-canvas (--ch-ax already has a light value) -- it does NOT. --ch-ax aliases --ra-chart-axis, a DIFFERENT token that merely shares this hex by coincidence; --ra-text-axis's 14 sites are plain DOM colour (icon buttons, grip handles, modal-close, rail SVG fills) with no path through chTC(). Real gap, uniform role (muted UI-chrome text/icon colour, dimmer than --ra-text-tertiary in dark theme). --text-4, the dimmest rung of the --text-N ramp, preserving that it's the dimmest tier in dark theme too. --ra-surface-subtle (#50565A): background AND border-color on a handful of drag-handle/hover/chip sites -- same dual-role shape --ra-surface-card-elevated had. --bg-3, same reasoning: one surface value serving both roles reasonably, consistent with the tier already established for the adjacent surface tokens. --ra-text-dim (#6B7A88): rail icon fills + Intelligence secondary text/table headers -- sits within one hex step of --ra-text-tertiary (#6B7276) in dark theme, near-identical role. --text-3, matching its closest sibling's already-verified value. No new token minted -- three repoints, all existing values. */ /* S20-R13 / TH-1, 2026-08-21 -- --ra-text-axis's repoint above was NEVER LIVE: the comment this sits inside used to close itself early, three paragraphs up, on the glob naming the chart-canvas alias family (an asterisk immediately followed by a slash reads as a real comment close), so this whole block parsed as CSS prose and the malformed declaration recovered at the semicolon that would have set --ra-text-axis, discarding it. Comment now defused with a space inserted into that glob -- which would otherwise ACTIVATE this repoint and move light-theme --ra-text-axis off its current, accidental, dark-identical grey to the notably lighter grey --text-4 resolves to in that theme, moving 19 var(--ra-text-axis) sites across 7 files (ai-agent.css x10, components.css x4, app.css, shell.css, screener.css, stats.css, intelligence.css) from roughly 6:1 down to roughly 3:1 contrast on a light background (exact values: design/s20/TOKEN_HYGIENE.md sec.4 -- not repeated here verbatim, since a hex/oklch literal in THIS comment would itself count against the colour ratchet). That is a real, unreviewed appearance change, so S20-R2/R4 require it stay OUT until someone judges the contrast on purpose. PRESERVED by omission: the repoint is deleted here rather than reactivated, so --ra-text-axis keeps resolving to the dark value in light theme, exactly as it already, accidentally, does today. Filed for a future session to activate in one line once judged: design/s20/TOKEN_HYGIENE.md §4 has the full measurement (both themes, both before/after this fix). */ --ra-surface-subtle: var(--bg-3); --ra-text-dim: var(--text-2); /* S18 #12 (POPUPS_GRADE_S18.md §6.1/§6.2): three more tokens S17 pinned from the (dark-only) frame in d2f42dc6, alongside --ra-text-axis above -- same disease, same fix shape: a one-line repoint into THIS block, never a frame-derived guess (HANDOFF_S18 §A -- no light frame exists for these nodes at all, so an absent value stays absent, not invented). --ra-text-slate (#C7D1DE, .ctf-pop .cmode-opt .glyph -- the TF code column, 1s/5m/1h/1d): measured 1.54:1 in light, the row's only content going invisible. screener.css:1727's own comment records this rule's PRE-rename colour as "secondary" -- --text-2 is the exact rung --ra-text-secondary already sits on two lines up; same tier, restored. --ra-state-star (#598CD9, .cmode-opt .pin.on): measured 3.40:1. This rule read var(--info) before S17 pinned it -- --info already carries its OWN light redeclaration in this same block (see above) and is proven live one selector away (.cmode-opt.active also reads --info). Restoring it is not a new choice, it undoes S17 replacing a working theme-aware token with a dark-only one. --ra-surface-scrollbar-thumb (#737A85, .cmode-section -- the section label; also .cind-dd .hdr's identical 11/500 ls0.2 uppercase label, and the real scrollbar thumb): measured 4.33:1 at 11px. Nearest hex sibling in dark theme is --ra-text-tertiary (#6B7276), already mapped to --text-3 two lines up -- the same "closest sibling" reasoning this block already used for --ra-text-dim. */ --ra-text-slate: var(--text-2); --ra-state-star: var(--info); --ra-surface-scrollbar-thumb: var(--text-2); /* S18 #14 (WIDTH_SWEEP_S18.md §8): --ra-accent-tint (#E6FBF7, a pale dark-theme "active chip" mint) has never had a light repoint anywhere -- unlike --ra-text-axis/--ra-text-slate/etc above, this isn't a cascade collision, it's a plain token gap, so it fixes the same way task #12's did: a one-line repoint, not a frame-derived guess (no light frame exists, HANDOFF_S18 §A). --ra-accent-tint colours .cpsych/.cpsyl/.ctrades/.cgrad.on (chart-head-row2 toggles, screener.css) at 1.11-1.33:1 in light. THE PRECEDENT, already shipped and proven: this exact token, on this exact "accent text on an active chip" problem, is ALREADY overridden two lines below -- `.segmented button.on` (screener.css:1530/1531 set color:var(--ra-accent-tint) unconditionally; this block's own `[data-theme="light"] .segmented button.on` two lines down replaces it with --text-1) -- proof nobody had to invent a value here either. Repointing the token itself, not patching each consumer, closes .cpsych/.cpsyl/.ctrades/.cgrad.on together with the two already-fixed .segmented buttons and .cliq.on/.cind.on (same family, same token, untested by this readout but no longer latent). */ --ra-accent-tint: var(--text-1); /* The light theme RULES' colours (ds/themes/light.css and the light half of ds/organisms/login-adjust.css), hoisted VERBATIM by E1 (2026-10-05): each value is the literal that rule painted, only its home moved. VALUE-NAMED on purpose (section 1e's rule: the exception is about the value): --ra-lt-h--[-a], L and C in hundredths (L .985 = 985, C .005 = 005); -info = var(--hue-info); white = L 1, C 0. Declared only here, so they exist only in light, where their only consumers live. Consolidating them into roles is a design call, not a migration's. */ --ra-lt-h155-88-08-a25: oklch(0.88 0.08 155 / 0.25); --ra-lt-h235-35-16-a70: oklch(0.35 0.16 235 / 0.7); --ra-lt-h235-45-17: oklch(0.45 0.17 235); --ra-lt-h235-50-14-a30: oklch(0.5 0.14 235 / 0.3); --ra-lt-h235-50-14-a85: oklch(0.5 0.14 235 / 0.85); --ra-lt-h235-55-16: oklch(0.55 0.16 235); --ra-lt-h25-55-18-a85: oklch(0.55 0.18 25 / 0.85); --ra-lt-h25-88-08-a25: oklch(0.88 0.08 25 / 0.25); --ra-lt-h70-58-17-a85: oklch(0.58 0.17 70 / 0.85); --ra-lt-h70-90-006-a50: oklch(0.9 0.006 70 / 0.5); --ra-lt-h70-94-008: oklch(0.94 0.008 70); --ra-lt-h70-94-008-a70: oklch(0.94 0.008 70 / 0.7); --ra-lt-h70-96-006: oklch(0.96 0.006 70); --ra-lt-h70-96-008: oklch(0.96 0.008 70); --ra-lt-h70-97-006: oklch(0.97 0.006 70); --ra-lt-h70-98-004: oklch(0.98 0.004 70); --ra-lt-h70-98-005: oklch(0.98 0.005 70); --ra-lt-h75-20-02-a15: oklch(0.2 0.02 75 / 0.15); --ra-lt-h75-20-02-a6: oklch(0.2 0.02 75 / 0.06); --ra-lt-h75-20-02-a8: oklch(0.2 0.02 75 / 0.08); --ra-lt-h75-40-015-a10: oklch(0.4 0.015 75 / 0.1); --ra-lt-h75-40-015-a14: oklch(0.4 0.015 75 / 0.14); --ra-lt-h75-40-015-a15: oklch(0.4 0.015 75 / 0.15); --ra-lt-h75-82-01: oklch(0.82 0.01 75); --ra-lt-h75-97-006: oklch(0.97 0.006 75); --ra-lt-h75-985-005-a60: oklch(0.985 0.005 75 / 0.6); --ra-lt-white: oklch(1 0 0); --ra-lt-white-a90: oklch(1 0 0 / 0.9); } /* ============================================================ 5. Kit colours -- the atoms', molecules' and login organisms' colour literals, hoisted VERBATIM by E1 (2026-10-05, design/behavior/PLAN_FULL_ATOMIC.md): each value is the literal its rule painted, only its home moved, so no pixel moves (owner ruling S20-R2) and the files leave migrationDebt. VALUE-NAMED on purpose (section 1e's rule: the exception is about the value, and these are the values the 2.0 frame never named): --ra-k---[-a], L and C in hundredths (L .55 = 55, C .005 = 005); hue = info / pos / neg (var(--hue-*), so the Customization sliders and the light theme still move them), bg = var(--bg-hue), or h for a fixed hue; --ra-k-bg-[-a] is the tinted surface oklch(L var(--bg-chroma) var(--bg-hue)). Resolved on the root element AND on .oil2, the one subtree that sets its own --hue-pos/neg/info (ds/organisms/intelligence-oil.css): a literal used to read those hues where it was painted, so a kit atom inside an oil briefing keeps them. Folding them into role tokens is a design call for the token owner, not a migration's. ============================================================ */ :root, .oil2 { --ra-k-bg-12: oklch(0.12 var(--bg-chroma) var(--bg-hue)); --ra-k-bg-13: oklch(0.13 var(--bg-chroma) var(--bg-hue)); --ra-k-bg-14: oklch(0.14 var(--bg-chroma) var(--bg-hue)); --ra-k-bg-14-01: oklch(0.14 0.01 var(--bg-hue)); --ra-k-bg-14-a70: oklch(0.14 var(--bg-chroma) var(--bg-hue) / 0.7); --ra-k-bg-14-a85: oklch(0.14 var(--bg-chroma) var(--bg-hue) / 0.85); --ra-k-bg-16-a70: oklch(0.16 var(--bg-chroma) var(--bg-hue) / 0.7); --ra-k-bg-16-a90: oklch(0.16 var(--bg-chroma) var(--bg-hue) / 0.9); --ra-k-bg-18-a60: oklch(0.18 var(--bg-chroma) var(--bg-hue) / 0.6); --ra-k-bg-18-a80: oklch(0.18 var(--bg-chroma) var(--bg-hue) / 0.8); --ra-k-bg-20: oklch(0.2 var(--bg-chroma) var(--bg-hue)); --ra-k-bg-20-015: oklch(0.2 0.015 var(--bg-hue)); --ra-k-bg-20-a60: oklch(0.2 var(--bg-chroma) var(--bg-hue) / 0.6); --ra-k-bg-23-a50: oklch(0.23 var(--bg-chroma) var(--bg-hue) / 0.5); --ra-k-bg-24-02-a70: oklch(0.24 0.02 var(--bg-hue) / 0.7); --ra-k-bg-30-02-a18: oklch(0.3 0.02 var(--bg-hue) / 0.18); --ra-k-bg-55-05: oklch(0.55 0.05 var(--bg-hue)); --ra-k-black-a40: oklch(0 0 0 / 0.4); --ra-k-h165-62-16: oklch(0.62 0.16 165); --ra-k-h200-74-13: oklch(0.74 0.13 200); --ra-k-h240-30-01: oklch(0.3 0.01 240); --ra-k-h250-32-01-a60: oklch(0.32 0.01 250 / 0.6); --ra-k-h260-28-04-a50: oklch(0.28 0.04 260 / 0.5); --ra-k-h30-70-20: oklch(0.7 0.2 30); --ra-k-h30-78-16: oklch(0.78 0.16 30); --ra-k-h320-30-10-a18: oklch(0.3 0.1 320 / 0.18); --ra-k-h320-78-16: oklch(0.78 0.16 320); --ra-k-h60-78-14: oklch(0.78 0.14 60); --ra-k-h60-78-16: oklch(0.78 0.16 60); --ra-k-h70-30-10-a55: oklch(0.3 0.1 70 / 0.55); --ra-k-h70-55-04: oklch(0.55 0.04 70); --ra-k-h70-68-16: oklch(0.68 0.16 70); --ra-k-h70-80-15: oklch(0.8 0.15 70); --ra-k-h70-82-16: oklch(0.82 0.16 70); --ra-k-h70-82-16-a60: oklch(0.82 0.16 70 / 0.6); --ra-k-h85-55-12-a50: oklch(0.55 0.12 85 / 0.5); --ra-k-info-30-06-a18: oklch(0.3 0.06 var(--hue-info) / 0.18); --ra-k-info-30-10-a35: oklch(0.3 0.1 var(--hue-info) / 0.35); --ra-k-info-50-20: oklch(0.5 0.2 var(--hue-info)); --ra-k-info-55-12-a10: oklch(0.55 0.12 var(--hue-info) / 0.1); --ra-k-info-55-12-a15: oklch(0.55 0.12 var(--hue-info) / 0.15); --ra-k-info-55-12-a55: oklch(0.55 0.12 var(--hue-info) / 0.55); --ra-k-info-55-12-a60: oklch(0.55 0.12 var(--hue-info) / 0.6); --ra-k-info-55-12-a70: oklch(0.55 0.12 var(--hue-info) / 0.7); --ra-k-info-55-14-a50: oklch(0.55 0.14 var(--hue-info) / 0.5); --ra-k-info-55-14-a55: oklch(0.55 0.14 var(--hue-info) / 0.55); --ra-k-info-55-14-a60: oklch(0.55 0.14 var(--hue-info) / 0.6); --ra-k-info-65-13: oklch(0.65 0.13 var(--hue-info)); --ra-k-info-66-14: oklch(0.66 0.14 var(--hue-info)); --ra-k-info-72-14: oklch(0.72 0.14 var(--hue-info)); --ra-k-info-78-14-a60: oklch(0.78 0.14 var(--hue-info) / 0.6); --ra-k-info-85-14: oklch(0.85 0.14 var(--hue-info)); --ra-k-neg-40-12-a24: oklch(0.4 0.12 var(--hue-neg) / 0.24); --ra-k-neg-50-16-a6: oklch(0.5 0.16 var(--hue-neg) / 0.06); --ra-k-neg-50-22-a28: oklch(0.5 0.22 var(--hue-neg) / 0.28); --ra-k-neg-55-14-a12: oklch(0.55 0.14 var(--hue-neg) / 0.12); --ra-k-neg-55-14-a15: oklch(0.55 0.14 var(--hue-neg) / 0.15); --ra-k-neg-55-14-a50: oklch(0.55 0.14 var(--hue-neg) / 0.5); --ra-k-neg-55-14-a60: oklch(0.55 0.14 var(--hue-neg) / 0.6); --ra-k-neg-55-20-a50: oklch(0.55 0.2 var(--hue-neg) / 0.5); --ra-k-neg-70-18-a60: oklch(0.7 0.18 var(--hue-neg) / 0.6); --ra-k-pos-40-10-a28: oklch(0.4 0.1 var(--hue-pos) / 0.28); --ra-k-pos-50-14-a6: oklch(0.5 0.14 var(--hue-pos) / 0.06); --ra-k-pos-50-20-a28: oklch(0.5 0.2 var(--hue-pos) / 0.28); --ra-k-pos-55-12-a50: oklch(0.55 0.12 var(--hue-pos) / 0.5); --ra-k-pos-55-12-a60: oklch(0.55 0.12 var(--hue-pos) / 0.6); --ra-k-pos-55-18-a55: oklch(0.55 0.18 var(--hue-pos) / 0.55); --ra-k-pos-55-20: oklch(0.55 0.2 var(--hue-pos)); --ra-k-pos-60-15: oklch(0.6 0.15 var(--hue-pos)); --ra-k-pos-70-14-a60: oklch(0.7 0.14 var(--hue-pos) / 0.6); /* The screener organisms' colours (ds/organisms/screener-*.css), hoisted VERBATIM by D8 screener-b (2026-10-06) on the same value-named scheme; --ra-k-hex- is a literal written as a hex. */ --ra-k-bg-10-a70: oklch(0.10 var(--bg-chroma) var(--bg-hue) / 0.7); --ra-k-bg-20-a85: oklch(0.20 var(--bg-chroma) var(--bg-hue) / 0.85); --ra-k-bg-22-a50: oklch(0.22 var(--bg-chroma) var(--bg-hue) / 0.5); --ra-k-h200-30-12-a50: oklch(0.30 0.12 200 / .5); --ra-k-h260-14-01-a92: oklch(0.14 0.01 260 / 0.92); --ra-k-h260-18-02-a92: oklch(0.18 0.02 260 / 0.92); --ra-k-h260-45-05: oklch(0.45 0.05 260); --ra-k-hex-caa54b: #caa54b; --ra-k-info-65-20: oklch(0.65 0.20 var(--hue-info)); --ra-k-neg-22-12-a96: oklch(0.22 0.12 var(--hue-neg) / 0.96); --ra-k-neg-30-12-a22: oklch(0.3 0.12 var(--hue-neg) / 0.22); --ra-k-neg-55-20: oklch(0.55 0.20 var(--hue-neg)); --ra-k-neg-55-20-a55: oklch(0.55 0.20 var(--hue-neg) / 0.55); --ra-k-neg-55-22-a35: oklch(0.55 0.22 var(--hue-neg) / 0.35); --ra-k-neg-60-22: oklch(0.60 0.22 var(--hue-neg)); --ra-k-neg-72-15: oklch(0.72 0.15 var(--hue-neg)); --ra-k-neg-92-18: oklch(0.92 0.18 var(--hue-neg)); --ra-k-neg-97-16: oklch(0.97 0.16 var(--hue-neg)); --ra-k-pos-100-12: oklch(1 0.12 var(--hue-pos)); --ra-k-pos-34-15-a60: oklch(0.34 0.15 var(--hue-pos) / 0.6); --ra-k-pos-55-16-a24: oklch(0.55 0.16 var(--hue-pos) / 0.24); --ra-k-pos-62-20-a85: oklch(0.62 0.2 var(--hue-pos) / 0.85); --ra-k-pos-70-24-a55: oklch(0.70 0.24 var(--hue-pos) / 0.55); --ra-k-pos-75-22-a70: oklch(0.75 0.22 var(--hue-pos) / 0.7); --ra-k-pos-97-16: oklch(0.97 0.16 var(--hue-pos)); /* The muted caret two kit selects still draw (ds/atoms/input.variants.css) -- the pre-S19 ink that --ra-caret-select (section 1c) replaced elsewhere, hoisted verbatim with the same SVG. */ --ra-caret-select-muted: url("data:image/svg+xml;utf8,"); /* The brand splash, design/rally-alpha-ident.html: its own surface, absent from the 2.0 section (design/CHANGE_MAP.md row 4), hoisted with the same values. Written as rgb(), not hex, ON PURPOSE: token_lint allows every hex declared in this file, so a hex here would silently clear the same two literals shell/ident.js still writes (its overlay) and hide that debt from the ratchet. */ --ra-ident-bg: rgb(10 12 18); --ra-ident-bg-edge: rgb(6 7 11); --ra-ident-hint-ink: rgba(255, 255, 255, 0.28); --ra-xsp-ident-stage-x: 6vw; /* the stage's side inset, a share of the viewport */ } /* ============================================================ 6. Developer tools -- the colours of dev/ (the ?perf=1 HUD), owner decision 2026-10-06: a dev-only tool is not exempt from the colour rule, it gets its own tokens. App-only by nature (no frame draws a dev tool): each is a declared app-only entry in design/TOKENS.json (dev.hud-*, dev.hud-*-light; design/build_tokens.py DIVERGENCES, so a regeneration keeps them). Dark = the literals the HUD painted, unchanged (its bg was rgba(0,0,0,0.82); D1 = 0.82 of 255). Light = the same roles on a white ground, picked for contrast: WCAG ratios of every ink on its ground, composited over each theme's page grounds, are recorded in TOKENS.json's colorSources (lowest: dark dim 5.51, light ok 5.70). Borders are decoration, not text. Nothing outside dev/ reads them. ============================================================ */ :root { --ra-dev-hud-bg: #000000D1; --ra-dev-hud-border: #2A3340; --ra-dev-hud-ink: #CCDDEE; --ra-dev-hud-dim: #7B8794; --ra-dev-hud-head: #99FFCC; --ra-dev-hud-ok: #7DDC8A; --ra-dev-hud-warn: #FFCF5D; --ra-dev-hud-bad: #FF6B6B; } [data-theme="light"] { --ra-dev-hud-bg: #FFFFFFEB; --ra-dev-hud-border: #B4BEC9; --ra-dev-hud-ink: #1F2933; --ra-dev-hud-dim: #56616C; --ra-dev-hud-head: #0B6E44; --ra-dev-hud-ok: #1A7431; --ra-dev-hud-warn: #835400; --ra-dev-hud-bad: #B3232B; } /* Light values of section 1k's trading tokens (Figma round 2026-10-09, fig-trading). */ [data-theme="light"] { --ra-tx-side-buy: var(--pos); --ra-tx-side-sell: var(--neg); --ra-tx-side-sell-on: var(--neg); --ra-state-danger-bg: var(--neg-bg); --ra-state-danger-ink: var(--neg); } /* == ds/base/reset.css == */ /* base.css: design tokens + body reset — split out of rally.css. */ /* ============================================================ Rally Alpha — Design System Tokens + primitives. Port of Rally Alpha design tokens.css, adapted for vanilla DOM (no React). ============================================================ */ /* Design-token materialisation (colours, --ch-*, hues, bg-tint) lives in tokens/tokens.css (design/PLAN.md §2 "alias layer" — loaded before this file, see index.html). This file keeps only the non-colour primitives that tokens/tokens.css does not own: density/radii/spacing/type sizing. */ :root { /* Density + radii */ --density: 1; --r-sm: 4px; --r: 8px; --r-lg: 12px; /* Spacing scale */ --sp-1: calc(4px * var(--density)); --sp-2: calc(6px * var(--density)); --sp-3: calc(8px * var(--density)); --sp-4: calc(12px * var(--density)); --sp-5: calc(16px * var(--density)); --sp-6: calc(24px * var(--density)); --row: calc(22px * var(--density)); --ctrl: var(--ra-size-control-sm); /* design-sync 2026-10-03: Figma size/control/sm, was 26px */ --head: calc(48px * var(--density)); /* Type */ --font-sans: "Inter", ui-sans-serif, system-ui, -apple-system, sans-serif; /* --font-mono is Inter, not a monospace stack — human ruling, session 2 QA F2: the 2.0 design defines NO mono family at all (checked: neither TOKENS.json nor any of the five frames declares one), and monospace covered 34.8% of Trading's visible text and 21% of Stats' — the frame doesn't. NAME kept as --font-mono deliberately (design/PLAN.md's own --ch-* precedent: renaming a custom property 292 call sites read by name, for zero benefit, risks the exact silent-failure mode that convention exists to avoid — an unrecognised name just falls through to nothing, no error). Digit alignment in price/quantity columns is the load-bearing risk of this switch: font-variant-numeric:tabular-nums is declared at every site where digits stack in a column (the per-file audit this same commit adds it to) — that declaration is the NECESSARY condition. Whether Google Fonts' Inter static build (wght@400;500;600) actually HONOURS tabular-nums (ships a tnum OpenType table) was a measured question, not an assumed one, because a declared-and-computed tabular-nums can still be inert if the loaded font has no tnum table, and system fallback fonts on some machines default to tabular figures regardless, which can mask a real Inter-specific regression in a quick local check. RESOLVED, 2026-08-21: YES — measured live at every weight the app requests (400/500/600) and every size 9-28px, 264 elements, 0.0px spread between mismatched digit strings under tabular-nums (600px spread under font-variant-numeric:normal for the same strings); also holds at the synthesized 700/800/900 the app does not request but `screener.css`'s `.scr-velo-ratio` uses. Full measurement + method: design/s20/TABULAR_NUMS.md §1/§4. `JetBrains+Mono` has not been in index.html's font request since session 2 (see the comment there) — this file's own switch to Inter for --font-mono is what that question was blocking on, and it is no longer blocked. */ --font-mono: var(--font-sans); } /* ------------------------------------------------------------ Base reset ------------------------------------------------------------ */ * { box-sizing: border-box; margin: 0; padding: 0; } /* overscroll-behavior-x: without it a horizontal touchpad swipe anywhere on the page reaches Chrome's back/forward overscroll navigation — a full reload. */ html, body { height: 100%; overflow: hidden; overscroll-behavior-x: none; } body { font-family: var(--font-sans); font-size: var(--ra-fs-12); color: var(--text-2); background: var(--bg-0); letter-spacing: var(--ra-ls-em-01); -webkit-font-smoothing: antialiased; font-feature-settings: "cv11", "ss01", "ss03"; } button, input, select, textarea { font: inherit; color: inherit; } button { background: none; border: none; cursor: pointer; } a { color: var(--info); text-decoration: none; } a:hover { color: var(--text-1); } /* .num.num (class repeated, not a typo — specificity hack, no !important): .num's whole purpose is "this text is numeric, stay tabular no matter what else styles this element," but at plain (0,1,0) specificity it was silently losing ties to same-specificity, later-loaded rules that reset the font shorthand — `font: inherit` on form controls / status chips / etc. (11 such rules across owned files). Session 2 QA F11: span.num, input.input.num read tabular-nums fine, but span.status-chip.num, input.search-input.num, b.num all computed `normal` — same class, different luck on cascade order, no error anywhere. Doubling the class raises specificity to (0,2,0), which beats any plain single-class or class+element selector regardless of load order, without enumerating (and re-finding, every time a new file adds one) each colliding rule. ST1 (CD-618, design/PLAN.md §U1): the doubling protects font-family and font-variant-numeric — the two properties this comment names. Six of this session's letter-spacing rows (CD-368, 495, 497, 516, 535, 624) were shipped as correct-reading per-component overrides that this rule silently out-specificities regardless, because letter-spacing rode along on the same doubled selector without ever being the reason for it. Demoted to plain (0,1,0) below so a same-or-higher-specificity, later- loaded rule can win it, same as it always could for font-family/ font-variant-numeric's own callers. */ .num.num { font-family: var(--font-mono); font-variant-numeric: tabular-nums; } .num { letter-spacing: var(--ra-ls-em-n01); } /* Scrollbar */ *::-webkit-scrollbar { width: 8px; height: 8px; } *::-webkit-scrollbar-thumb { background: var(--bg-3); border-radius: 4px; } *::-webkit-scrollbar-thumb:hover { background: var(--scrollbar-thumb-hover); } *::-webkit-scrollbar-track { background: transparent; } *::-webkit-scrollbar-corner { background: transparent; } /* == ds/organisms/panel.css == */ /* components.css: panel, button, input, pill, segmented, kbd, tables — split out of rally.css. */ /* ------------------------------------------------------------ Panel — Design 2.0 card anatomy (DESIGN_SPEC §3): radius 14, 1px border, surface.panel background, a 34px panel-head @ 16,14 -> 1px hairline (in surface.card, not border.default) -> content. Restyle of the existing .panel/.panel-head/.panel-body primitives — reused everywhere, not recreated (PLAN.md §3.1). ------------------------------------------------------------ */ .panel { background: var(--ra-surface-panel); /* Border colour is NOT a card-family axis (design/DESIGN_SPEC.md §6.6: "Not invariant... Name it per screen") — it's the --card-border custom property, set by the owning column/screen and defaulting to border.card. design/PLAN.md §3 D2. */ border: 1px solid var(--card-border, var(--ra-border-card)); border-radius: var(--ra-radius-card); /* CD-37 (G12): horizontal padding relocates from .panel-head/.panel-body (each independently declaring their own 16px) onto the card itself — "16,14" is the card's OWN inset, not two children's. Top-only stays 14px (unaffected — CD-37's own row is scoped to horizontal padding; bottom stays 0, .panel-body keeps its own vertical padding so scrollable bodies don't lose their end-of-content inset, which a card-level bottom padding would sit OUTSIDE the scroll region and move behind, not scroll with). */ padding: var(--ra-sp-14) var(--ra-sp-xl) 0 var(--ra-sp-xl); position: relative; overflow: hidden; display: flex; flex-direction: column; min-height: 0; } /* border.strong (right column + chart) vs border.card (left column, the .panel default above) — DESIGN_SPEC §3's component table. Scoped here since components.css doesn't know column context; screener.css owns #scr-col-right/.trd-cp so it isn't duplicated. */ #scr-col-right .panel, .scr-panel.trd-cp.panel { --card-border: var(--ra-border-strong); } /* SUPERSESSION RECORD -- S17 item 1 (owner order, addendum S17-A, design/PLAN.md §S17.3e/§S17.14e). The group colour's CARRIER changes from the panel's top stripe (this comment's original subject, deleted below) to the link tile, [data-pchrome=link] (the rules immediately following this comment). Rewritten as a supersession record rather than deleted outright (H1: a change that moves a subject re-points every artefact naming it) -- read this in full before touching either half. === WHAT THE STRIPE WAS, KEPT FOR THE RECORD ============================= S13-A6f / owner ruling S13-R44b: "carry the group colour on something with AREA" -- before it, only a single 22x22 [data-pchrome=link] icon carried the colour, so a user had to hunt a specific glyph per panel to answer a question that is about GROUPING. DECLARED DIVERGENCE BY CONSTRUCTION even then, not a parity fix: the design system authors the colour PICKER (362:1608) and never a RESULT for a grouped panel -- searched, no such node existed. The remedy shipped was a thin inset `background` stripe along the panel's own top edge (not border/padding/ outline, so it added zero layout size), 3px, six --ra-link-* tokens, no new literal, on the generic `.panel[data-link-group]` primitive so any panel that can join a group gets it without a screener-specific touch. It was originally `box-shadow: inset ...` and was MOVED onto a `::before` overlay in `cf06961c` (F-11, S15, 2026-08-18): `widgets.css` [data-theme="light"] .panel` also sets `box-shadow` (the light-theme elevation shadow), tied specificity with this rule, decided by source order -- widgets.css loads after components.css and won, so the stripe SILENTLY STOPPED RENDERING in light theme until `cf06961c` moved it to a property light theme never touches. SUPERSEDED HERE, NOT WASTED: that fix was correct for the mechanism it targeted and stays a real repair in git history; only the carrier it repaired is being relocated now. `cf06961c`'s OWN acceptance term 3 is also why today's relocation is a CORRECTION, not merely a preference -- independent evidence, from the seat that had just repaired the mechanism: pixel-sampled with PIL, the stripe's magenta was found COMPLETELY INVISIBLE along the top edge on a panel that was both grouped AND the selection target, at the marker's then-4px width (`ddaf601c`) -- the target ring covered the whole 3px band. At today's shipped 2px ring (`ff116e79`) the occlusion is PARTIAL, not total (the weaker, honest claim, re-measured at ship rather than inherited from the 4px premise -- see `A1.6`). Either width: the stripe failed at its own job, at the exact moment the user was acting on the panel, measured by the person who had just fixed it. That is independent evidence the top edge was the wrong carrier for this signal, not only a different one the owner happened to prefer. THE STRIPE WAS NEVER FILED IN THE REGISTER: `design/COMPONENT_DIFF.md` (13,404 lines, checked) returns 0 hits for "link group" / "link-group" / "colour group" / "color group" / "F-11", in either direction. Deleting it below therefore orphans no register row. === WHERE THE BURDEN WENT ================================================= THE DIVERGENCE BURDEN DOES NOT DISAPPEAR -- IT MOVES TO THE BUTTON, and that is the half an auditor will actually need after this ships: THE FILLED LINK BUTTON, BELOW, IS ITSELF A DECLARED DIVERGENCE. The frame does not draw it. Node `341:3788` (`action-link-active`, the link tile on `seal/card/chart-10S` and, identically, on all nine link-carrying panels) renders `#23282C` ×376px and ZERO cyan pixels in the frame -- 22×22, radius 6, padding 8, icon `341:3789` glyph `#606060`. THAT is what `341:3788` will show anyone who opens it after this ships. What this app draws instead, unconditionally on a grouped panel: the panel's own group colour (one of the six --ra-link-* tokens below) as the fill, `--ra-link-ink` (`#1A2332`, `S17-R1`, ratified by the owner) as the glyph, no border. Established by TWO INDEPENDENT ROUTES, not assumed from one: this file's own S13 search (kept below, verbatim) and, a session later, `FRAME_S17A.md` §0.5's pixel sample of the SAME node, re-run independently with the same zero-cyan result, plus a targeted search of the node's only twin (`461:2161`), the colour picker's own header link button (`402:203`, itself a flattened `#23282C` neutral even INSIDE the picker), and the whole KIT QA page (158k chars, 0 relevant hits). Both routes agree on the same reading: the design system authors the colour PICKER (`362:1608`, selection modelled as a white ring on a swatch) and has NEVER modelled a RESULT for a grouped panel. There is no frame state this app's filled link button corresponds to; it is our own, owner-ordered (the owner was shown both the frame's neutral and the measured cyan-fill alternative, with contrast numbers for both glyph directions, before ordering the fill -- `S17-R1`/`S17-R2`). An auditor who walks `341:3788` after this ships and finds a group colour there, without this paragraph, will file it as an unauthorised addition -- correctly, by this corpus's own rules, unless the divergence is recorded exactly where they will look. This paragraph is that record. === THE ORIGINAL S13 SEARCH, VERBATIM (the first of the two routes above) ==================================================== - Lived HERE, on the generic `.panel[data-link-group]` primitive, not on `.scr-panel` in screener.css: a group colour is a property of ANY panel that can join one, not a screener-specific look, and every one of the nine link-roster panels already carries `.panel` (`class="panel scr-panel ..."`) -- confirmed by reach measurement, design/s13/dev_a/S13-A6f_evidence.md, all nine paint identically. - Six existing --ra-link-* tokens ONLY, one rule per colour, no new literal -- token_lint blocking count unaffected by this change. - Ungrouped panels (no data-link-group attribute at all) matched none of the six stripe selectors -- zero change, by construction, not by a default/fallback branch that could regress. The link-button cascade below inherits this same property. - Survived PiP: pip.js moves the ACTUAL panel DOM node (dataset attributes travel with it) into a document that copies this stylesheet (pip.js's _copyStyles) -- the rule just re-matched. Did NOT survive "Pop out" ([data-pchrome=pop]): that control opens a brand-new tab that re-mounts the panel from persisted layout state, and data-link-group/-sym are pure in-memory DOM state (cross-window.js's own header comment, §S13.14.2a) -- never serialized into popout()'s state payload. A grouped panel that pops out loses its WHOLE group membership today (routing included, not just this stripe) -- a pre-existing gap in S13-A4's own mechanism (S13-A8, cut). STILL TRUE OF THE BUTTON BELOW, unchanged by this session and NOT fixed here -- carried forward by name, `design/PLAN.md` §S17.14f, so it is not silently inherited. */ /* S17 item 1 (owner order, addendum S17-A, design/PLAN.md §S17.3b): the panel's group colour ALSO lands on the link tile, [data-pchrome=link] -- a pure descendant cascade off .panel[data-link-group], the SAME attribute the stripe above already keys on. The signal population is therefore IDENTICAL to the stripe's by construction -- no roster to maintain, nothing for the two to drift against. Landed WHILE the stripe above still stands (S17.6 steps 2/3: the new signal must exist before the old one is removed, not the reverse -- removing the stripe first would leave every grouped panel signal-less for however long the two commits are apart; both are deliberately live at once for one commit). REFUSED: stamping data-link-group (or anything matching [data-link-group]) on the button. shell/cross-window.js:65's _groupMembers is an UNSCOPED document.querySelectorAll('[data-link- group="X"]') -- a button carrying that attribute becomes a group member and PV2.link.applyGroup starts writing data-link-sym onto it, re- manufacturing the leak model this cascade exists to avoid. The selector below never puts the attribute on a new element, so it cannot reach that hazard by construction, not by care. Specificity, CHECKED not hoped -- and checked twice, because the first check (against .btn.on, (0,2,0)) is not the whole story: the six rules below also have to beat THIS FILE'S OWN `.phd-actions > .btn.ghost` background/color rules above ((0,3,0) -- an exact tie with the plan's bare `.panel[data-link-group] [data-pchrome=link]` shape) and their :hover sibling ((0,4,0)). Neither tie is visible from the addendum or the plan, only from reading this file -- measured live with a Playwright probe (design/s17/dev_b/probe_step2_cascade.js) before this landed, because this file has already lost exactly this kind of tie once (widgets.css's light-theme `.btn.ghost` override beating this block's own neutral fill on source order, an unrelated pre-existing gap filed separately, not fixed here). Rather than rely on order a second time, every selector below adds `.btn`: (0,4,0) resting / (0,5,0) hover+active, unconditionally above both phd-actions rules regardless of where in the cascade this block sits. Hover/active are not modelled by the frame (S17-R3, no variants anywhere in the cluster) -- the grouped fill MODULATES via filter rather than being replaced by a neutral: `.btn:hover` sets background:var(--bg-2) and `.phd-actions>.btn.ghost:hover` sets background:var(--ra-surface-card-elevated); either one replacing the group colour on hover would make a grouped panel look ungrouped at the exact moment the user reaches for its link control. `filter` introduces no colour value at all, so it is token-clean by construction and needs no per-colour duplication. `.btn.on`'s own `border-color:var(--ra-accent-primary)` is neutralised the same way -- left alone it would be a teal ring around a group-coloured fill, a third meaning inside one 22x22 control; neutralising it also matches the frame, which paints no border at all on 341:3788. */ .panel[data-link-group] [data-pchrome=link].btn{ color: var(--ra-link-ink); border-color: transparent; } .panel[data-link-group="cyan"] { --link-fill: var(--ra-link-cyan) } .panel[data-link-group="magenta"] { --link-fill: var(--ra-link-magenta) } .panel[data-link-group="blue"] { --link-fill: var(--ra-link-blue) } .panel[data-link-group="orange"] { --link-fill: var(--ra-link-orange) } .panel[data-link-group="yellow"] { --link-fill: var(--ra-link-yellow) } .panel[data-link-group="purple"] { --link-fill: var(--ra-link-purple) } /* The group fill holds on hover / press too -- those states only modulate it (filter, below). The tiles' own hover fill (.phd-actions > .btn.ghost:hover; light.css's .btn.ghost:hover) tied the resting rule at (0,4,0) and, later in the cascade, replaced the group colour: dark ink on a dark grey tile, 1.22:1. */ .panel[data-link-group] [data-pchrome=link].btn, .panel[data-link-group] [data-pchrome=link].btn:hover, .panel[data-link-group] [data-pchrome=link].btn:active { background: var(--link-fill) } .panel[data-link-group] [data-pchrome=link].btn:hover { filter: brightness(1.12); color: var(--ra-link-ink) } .panel[data-link-group] [data-pchrome=link].btn:active { filter: brightness(0.92) } /* ------------------------------------------------------------ S31-TICKER-MOTION (design/s31/TICKER_MOTION_SPEC.md §3/§4.1). A panel re-identifies its content when the symbol it displays changes (the former js/core/ui.js's symApplied() toggles .sym-swap on CHANGE only, never on a data tick — see that function for the full contract). Existing tokens only, opacity only (PLAN_S31 §3.6); fade IN only, no fade out -- the old value is never held on screen to be faded away, the content is already rewritten by the time this class lands. --mo-dur-view/--mo-ease-settle is UX-R13 class B (orientation), the same class a panel/tab swap uses, so a ticker change and a tab change move alike. The class is TRANSIENT (spec v2 §2.2, reversing an earlier draft on design-qa's flag): symApplied() removes it itself via an animationend listener PLUS a setTimeout net (a panel in a hidden tab or a closed PiP never fires animationend, so the class would otherwise rest exactly where nobody looks -- see that function for the full contract). NO animation-fill-mode is set here on purpose: the resting style is whatever the panel's own rules already say, so there is no faded state for anything to "release" even if both removal mechanisms failed. Precedent for a .scr-panel-scoped rule living here rather than in the frozen screener.css: the .panel[data-link-group] block immediately above. */ @keyframes sym-swap-in { from { opacity: 0 } to { opacity: 1 } } .scr-panel.sym-swap .panel-body { animation: sym-swap-in var(--mo-dur-view) var(--mo-ease-settle); } .scr-panel.sym-swap .phd-title .sub { animation: sym-swap-in var(--mo-dur-view) var(--mo-ease-settle); } /* Chart canvases never animate (UX §4.1/PLAN §3.6: no opacity/transform/ filter on .ch or any ancestor while it draws -- measured, a blur+scale on a live-canvas subtree cost 22 long frames in 3s). A chart panel's ticker transition is its symbol LABEL only (.phd-title .sub above still applies); the body -- canvas and every ancestor of the canvas -- gets nothing. Exact list, not :has() guesswork: pane.html carries exactly two elements, one in data-panel=chart, one in data-panel=tpswave. */ .scr-panel[data-panel=chart].sym-swap .panel-body, .scr-panel[data-panel=tpswave].sym-swap .panel-body { animation: none } /* == ds/organisms/chart-veil.css == */ /* ------------------------------------------------------------ S32 candle entrance (design/s32/CANDLE_ENTRANCE_SPEC.md §2.3/§3, owner ruling S31-R10). The veil is a SIBLING of the canvas, never the canvas or an ancestor of it -- features/chart/entrance.js creates/removes it, this file only styles it. Covering the panel's OWN background (--bg-1, the same ground pane.html's chart wrapper sits on) rather than transparent, so what's underneath reads as "not painted yet", not "see-through". z-index 6 -- above every other in-plot overlay this file's own screener.css: (verified) already stacks here: .chart-zoom/.chart-legend (z-index 2) and .chart-loading (z-index 4, screener.js's OWN separate "waiting for first trade" text, gated on the SAME bars-empty condition this veil covers) -- so nothing shows through or double-messages during a load; screener.js is frozen this session and untouched, this is a pure CSS-layering resolution. NO animation-fill-mode (spec §6 amendment boundary + the same TICKER_ MOTION_SPEC lesson this session already paid for once, the tzMenu): the node is REMOVED by JS (entrance.js) right after the fade, whichever of animationend/its own setTimeout net fires first, so there is no resting state for a fill-mode to hold open. */ .ch-veil { position: absolute; inset: 0; z-index: 6; background: var(--bg-1); pointer-events: none; display: flex; align-items: center; justify-content: center; } .ch-veil.lifting { animation: ch-veil-lift var(--mo-dur-view) var(--mo-ease-settle); } @keyframes ch-veil-lift { from { opacity: 1 } to { opacity: 0 } } /* The slow-load line (spec §4): static text only, no spinner/shimmer/pulse -- motion expresses arrival, never aliveness (UX-R6), and animating a "still loading" message makes a stalled feed look healthy (TENETS 3). */ .ch-veil-slow { font: var(--ts-label-form); letter-spacing: var(--ts-label-form-ls); color: var(--text-2); } /* S33-R3 (task #60, design/s33/CHART_REVEAL_REF.md) -- the blur-to-focus on the chart's WRAPPER (features/chart/entrance.js's c.parentNode, the bare position:relative div the veil above already lives in), added alongside the veil rather than replacing it: the veil still covers the WAIT for data (unchanged), this covers the RESOLVE once data has arrived, which is the one ingredient the reference has and the S32 veil didn't. `filter` lands on an ANCESTOR of `.ch`, never on `.ch` itself -- the one shape PLAN_S31 §3.6 reserved its single canvas-adjacent exception for (S31-R10), spent here exactly as S33-R3 authorised. No transform/scale (CHART_REVEAL_REF §3.2/§4.4 rules both out) and no width/height/opacity on this class -- opacity is still the veil's own job above, kept as two independent transitions on two different elements rather than one mechanism carrying both meanings. .ch-focus-done is added at the SAME moment .ch-veil gets .lifting (entrance.js's _lift()) and both classes are stripped together when the veil is torn down -- steady state carries no filter at all, matching the veil's own "no resting state" rule two comments up. ANIMATION, not transition -- same choice ch-veil-lift already made two comments up, and for the identical reason: a filter transition on .ch-focus-armed would itself animate the moment the class is FIRST added (blur(0) -> blur(N), sharp-to-blur, backwards), because the transition and the new value land in the same style recalculation -- caught live, measured with design/s33/dev_a/instrument/ blur_focus_verify.js sampling the resolved filter every 30ms (first attempt: `blur(1.28px) -> blur(8px)`, ramping UP, not down). A keyframe's `from{}` block fixes the START value explicitly regardless of the element's prior computed style, so .ch-focus-armed alone sets the resting blurred state with NO transition property to misfire, and the animation only exists on the SECOND class, added later once bars have actually arrived. */ .ch-focus-armed { filter: blur(var(--mo-blur-focus)); } .ch-focus-armed.ch-focus-done { animation: ch-focus-in var(--mo-dur-focus) ease-out; /* motion_lint:allow-filter */ } @keyframes ch-focus-in { from { filter: blur(var(--mo-blur-focus)); } to { filter: blur(0); } } /* == ds/organisms/chart-draw-pop.css == */ /* ds/organisms/chart-draw-pop.css — the edit popover of a chart drawing (features/chart/drawing-popover.js, the face of chartDraw 'selected'). Moved out of the script's inline