/* ParentProof Secure — parent settings, served from platform.framebright.ai. * * DESIGN-SYSTEM FOUNDATION · 2026-09-18 * The binding visual source is the 2026-09-16 handoff named in * docs/OWNER-DECISIONS.md §0.4. This layer owns only fonts and tokens; the seven * screen-area epics apply them to individual components. Dark remains the bare * :root palette and every pre-existing dark value below is intentionally exact. */ /* Self-hosted Google Fonts latin subsets. The static server already sends WOFF2 * as font/woff2 and the CSP already permits font-src 'self'; no remote stylesheet, * font origin, inline style, or CSP relaxation is needed. */ @font-face { font-family: 'Nunito'; font-style: normal; font-weight: 400; font-display: swap; src: url('/fonts/nunito-400-latin.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: 'Nunito'; font-style: normal; font-weight: 600; font-display: swap; src: url('/fonts/nunito-600-latin.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: 'Nunito'; font-style: normal; font-weight: 700; font-display: swap; src: url('/fonts/nunito-700-latin.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: 'Nunito'; font-style: normal; font-weight: 800; font-display: swap; src: url('/fonts/nunito-800-latin.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: 'Quicksand'; font-style: normal; font-weight: 500; font-display: swap; src: url('/fonts/quicksand-500-latin.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: 'Quicksand'; font-style: normal; font-weight: 600; font-display: swap; src: url('/fonts/quicksand-600-latin.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } @font-face { font-family: 'Quicksand'; font-style: normal; font-weight: 700; font-display: swap; src: url('/fonts/quicksand-700-latin.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } /* LIGHT IS THE DEFAULT SINCE 2026-09-20, AND IT IS THE DESIGN — NOT A * PREFERENCE. This block is therefore the DARK palette, which is now reached * only by an explicit opt-in; the light palette lives in the * `:root[data-theme="light"]` block further down and is what a parent sees on * a cold load. * * It said the opposite until 2026-09-20, and the second half of that sentence * is the part that has NOT changed and is worth keeping: the default is a * DESIGN decision, not a reading of the parent's machine. There is no * `prefers-color-scheme` fallback here or in app.js's boot, on purpose, and * nav-reference-parity.test.js points a DARK-mode browser at the dashboard and * requires light specifically so that cannot quietly come back. * * Owner ruling: "absolutely light needs to be default". The 2026-09-16 * prototype handoff is drawn light on all 49 artboards and was ruled binding * on 2026-09-18. See plans/DECISIONS-2026-09-20-design-fidelity-over-contrast.md. * * NOTE, because this comment is load-bearing: tablet-setup-branding-ui.test.js * greps this file for the "LIGHT IS THE DEFAULT" sentence. The tablet hand-off * page has no theme toggle and follows whatever the portal defaults to, so * that test reads the decision HERE rather than restating it. * * Legacy dark tokens are kept because the live UI already consumes these names. * The role-named aliases below let the re-skin stop spreading hue names while * resolving to those same, already-reviewed dark values. */ :root { color-scheme: dark; --ink:#0A1020; --dusk:#101B2D; --dusk2:#152238; --glow:#69D8FF; --coral:#FF6B5E; --mint:#4EE0A5; --sky:#9C8CFF; --cloud:#EDF5FF; --haze:#91A2BB; --line:#25344B; --bg:#09101D; --statustop:#11263A; --statusbot:#102033; --arowline:#25344B; --track:#334764; /* GOODQA #32 — `--track` (#334764) is the shared muted-fill token: switch tracks (`.toggle.off`/`.sw.off`), progress-bar troughs (`.ovbar`, `.loginstep`), image placeholders and secondary button fills all paint it. A SWITCH'S TRACK IS ITS ENTIRE VISIBLE SHAPE — no separate border — so it alone has to clear WCAG 1.4.11's 3:1 non-text-contrast floor against the card it sits on; the other consumers do not carry that same obligation the same way (a progress trough is not a "boundary of a UI component" in the same sense). MEASURED: #334764 is only 1.83:1 against `--dusk` (#101B2D), 1.69:1 against `--dusk2`, 2.02:1 against `--bg`. `--track-switch` SPECIALIZES the token for switches alone, same hue and saturation as `--track`, lightened until the floor clears against every card background a switch renders on: 3.38:1 / 3.66:1 / 4.04:1 respectively (WCAG 2.x relative luminance, computed). `--track` itself is UNCHANGED — its other consumers keep their exact existing pixels. */ --track-switch:#5475A4; /* The five semantic roles are exposed below. These legacy hue tokens retain their exact dark values so existing dark screens do not move. */ --amber:#FFC44B; /* GOODQA #465/#466/#468/#470, OWNER-DECISIONS.md §0.4 (2026-09-18), decisions #508/#509/#510 (locked, see plans/DECISIONS-2026-09-18-prototype-conflicts.md). The 2026-09-16 handoff is binding for LIGHT only; dark keeps every value above unchanged — this pass adds two tokens neither theme had before, and retints one existing one (--glow, below, light block only). --danger and --indigo are NEW — the handoff's own light literals (#C0342C, #6D5BD0) are adopted for light AS GIVEN (both clear 4.5:1 on white: 5.57:1 and 5.18:1 — computed, WCAG 2.x relative luminance). Dark has no prior value to keep, so these are DERIVED, same hue, lightened for a dark ground, following the --coral/--mint/--sky/--amber dark derivations already in this file: --danger dark #EE5864 (5.63:1 on --bg, 4.72:1 on --dusk2); --indigo dark #A792FC (7.4:1 on --bg, 6.19:1 on --dusk2). Both verified against the two backgrounds anything painted with them actually sits on, not just #FFFFFF/--bg in isolation. See `.pill.danger`/ `.pill.attn` below for the further-darkened/lightened literals their own translucent fills need (same discipline as `.pill.off`'s own #FFB4AC). */ --danger:#EE5864; --indigo:#A792FC; /* GOODQA #467 — "no dedicated sidebar-chrome token pair" (evidence: the rail paints `.nav { background: var(--dusk) }`, the SAME token a card uses, so rail and page read as one surface). Dark KEEPS today's actual look: these two new tokens just point at --dusk/--haze's existing dark values rather than inventing a new one — "dark keeps today's token values" (§0.4) is honoured at the pixel, not just the number. Light gets the handoff's own two-tone chrome below, since light had no rail-vs-card distinction to keep. */ --railbg: var(--sidebar-bg); --railtext: var(--sidebar-inactive); --radius: 20px; /* GOODQA #470 — the handoff's dominant button/chip radius (259 of its own `border-radius:999px`, against `.card`'s 20-32px, which is already on-spec and untouched here). New token, not a rename: `.card` keeps reading --radius. */ --radius-pill: 999px; --shadow: 0 24px 70px #0007; /* THE DARK FIELD FILL. Her measured light value (#F5F7F9) lives in the `:root[data-theme="light"]` block below, NOT here — exactly like --surface-raised above it. MEASURED REGRESSION, 2026-09-20: #F5F7F9 was declared a second time INSIDE THIS SAME :root BLOCK, after this line, so it won at every theme and dark painted the LIGHT fill. axe-core caught it on #deviceTaskSelect at 320x568 and 440x956 in dark: contrast 1.02:1, #EDF5FF text on #F5F7F9. It shipped live in 949c1ed3 as part of a change whose whole purpose was contrast. A light value in the dark base block is not an override, it is a takeover. */ --field-fill: var(--dusk2); /* Typography is not a per-theme choice (UI-DIRECTION §3) — --font-heading and --font-body below are unscoped globals, so headings/body already render in Quicksand/Nunito in dark today. --ui itself leads with Nunito too, so the ~13 form controls that set font-family: var(--ui) directly (button, input, textarea labels, etc.) match rather than silently staying on the old system stack while their surrounding headings moved. */ --ui: 'Nunito', system-ui, -apple-system, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif; /* No dark colour was invented: roles alias existing dark tokens, while #8FE7FF is the live CTA gradient's existing second endpoint. Measured worst case on --dusk2: primary 14.50, secondary/control 6.14, brand 9.76, done 9.51, waiting 10.05, attention 5.77, danger 5.70. */ --font-body: 'Nunito', var(--ui); --font-heading: 'Quicksand', var(--ui); --text-primary: var(--cloud); --text-secondary: var(--haze); --text-tertiary: var(--haze); --text-tertiary-ui: var(--haze); --brand: var(--glow); --brand-deep: var(--glow); --brand-tint: var(--dusk2); --brand-bright: #8FE7FF; --primary-cta-gradient: linear-gradient(135deg, var(--glow), #8FE7FF); --primary-cta-text: var(--ink); --info: var(--glow); --info-text: var(--glow); --info-tint: var(--dusk2); --done: var(--mint); --done-text: var(--mint); --done-accent: var(--mint); --done-tint: var(--dusk2); --waiting: var(--amber); --waiting-text: var(--amber); --waiting-accent: var(--amber); --waiting-tint: var(--dusk2); --attention: var(--sky); --attention-text: var(--sky); --attention-accent: var(--sky); --attention-tint: var(--dusk2); --danger: var(--coral); --danger-text: var(--coral); --danger-accent: var(--coral); --danger-tint: var(--dusk2); /* A RAISED SURFACE THAT IS ACTUALLY RAISED IN BOTH THEMES. --dusk2 was doing this job and still does elsewhere, but in the LIGHT palette --dusk and --dusk2 are BOTH #FFFFFF, so every "raised band on a card" collapsed to one flat white and the distinction silently stopped existing. It went unnoticed because dark was the default and dark's --dusk/--dusk2 (#101B2D/#152238) really do differ. Dark points at --dusk2 so nothing dark moves; light gets the handoff's own neutral #F1F3F6 (the ground she puts her muted "No device yet" pill on). Deliberately NOT a global --dusk2 change: 83 rules consume that token and re-tinting all of them to fix one band is a far larger visual change than the defect warrants. */ --surface-raised: var(--dusk2); --sidebar-bg: var(--dusk); --sidebar-inactive: var(--haze); --sidebar-active: var(--glow); --sidebar-active-indicator: var(--ink); --border-subtle: var(--line); --border-control: var(--haze); /* HER TWO-LAYER CARD SHADOW, measured off the Home artboard: rgba(22,35,63,.03) 0 1px 2px, rgba(22,35,63,.04) 0 6px 18px. It replaces `0 24px 70px #0007` — a DARK-theme shadow (near-black at 44%) that light was inheriting, which is why light cards had no usable depth and the whole surface read flat. */ --shadow-card: 0 1px 2px rgba(22,35,63,.03), 0 6px 18px rgba(22,35,63,.04); --radius-pill: 999px; --radius-button: 999px; --radius-input: 999px; --radius-card: 20px; --radius-card-large: 32px; --radius-control: 14px; --radius-icon: 14px; } /* Light is opt-in through the persisted theme toggle. This is the single light * palette definition: later screen epics consume the role names and do not * introduce per-screen colour systems. */ :root[data-theme="light"] { color-scheme: light; /* Existing screens still consume the legacy hue names. They map onto the new foundation here, while the role aliases below are the public token layer. */ --ink:#16233F; --dusk:#FFFFFF; --dusk2:#FFFFFF; --cloud:#16233F; --bg:#FFFFFF; --statustop:#FFFFFF; --statusbot:#FFFFFF; /* Text measured on white, THE DESIGNER'S OWN VALUES. OWNER DECISION 2026-09-20 — same decision file as the borders below. --text-tertiary was #6D778A, the minimum same-family adjustment that clears WCAG 1.4.3's 4.5:1 (it measures 4.51:1); the handoff's own #8A93A3 is 3.10:1 and fails. The owner chose the handoff value knowingly. Secondary #5B6472 (5.98:1) and primary #16233F (15.60:1) were already hers and already pass, so they are unchanged. */ --haze:#5B6472; --text-primary:#16233F; --text-secondary:#5B6472; /* BOTH OF THESE HAVE ZERO CONSUMERS -- measured, `var(--text-tertiary)` and `var(--text-tertiary-ui)` appear 0 times in app.css and 0 times in css/*. ab3cb09c's comment here claimed --text-tertiary paints `.small`, `.legal` and `.footbrand`. IT PAINTS NOTHING. That claim was inferred from the selectors an axe failure happened to name and was never checked against the stylesheet -- the precise trap this very file warns about elsewhere ("a token existing is NOT a token being consumed"), written by the person who wrote the warning. They are kept, at the role-split values, because the role layer is meant to be the public token surface and a future consumer should find the right pair already here. But nothing renders from them today, so neither value can move a single pixel or a single contrast test. Said plainly so the next reader does not spend time here believing otherwise. */ --text-tertiary:#6D778A; --text-tertiary-ui:#8A93A3; /* Cool navy boundaries, THE DESIGNER'S OWN ALPHA. OWNER DECISION 2026-09-20 — plans/DECISIONS-2026-09-20-design-fidelity-over-contrast.md These were .482, and that was a deliberate, correct accessibility choice: the handoff's rgba(22,35,63,.16) measures 1.37:1 on white and WCAG 1.4.11 wants 3:1 for a UI component boundary, which .482 clears at 3.01:1. It was also the single largest reason the designer said the live product "doesn't look or feel anything like" her designs — roughly 3x her weight, which reads as hard and boxy next to her work. Asked directly, with the regression spelled out, the owner chose her exact values and accepted the regression. A middle option (soft decorative card edges + fill-identified controls, which would have PASSED 1.4.11) was offered and declined. This is therefore KNOWN AND ACCEPTED, not an oversight — do not "fix" it back without going to the owner, and read that decision file first. Revisit if a formal conformance claim is ever needed. */ --line:rgba(22,35,63,.16); --arowline:rgba(22,35,63,.16); --track:rgba(22,35,63,.16); --border-control:rgba(22,35,63,.16); --border-subtle:rgba(22,35,63,.08); /* GOODQA #32 is DARK-THEME ONLY (ticket title names `--dusk`). --track's own 1.37:1-on-white value immediately above is the OWNER-ACCEPTED regression this file's own comment already documents — do not fix it here. This is the same numeric value under the new specialized name so `.toggle.off`/`.sw.off` keep painting EXACTLY what they always have in light; nothing about the light switch changes in this pass. */ --track-switch:rgba(22,35,63,.16); /* Brand blue is 5.42:1 on white and 4.75:1 on its tint; deep is 9.24:1. The literal bright endpoint #4FA8E0 is 2.62:1 with white, so both its role token and the CTA endpoint are minimally darkened to #207CB7, which gives white text 4.54:1 across the full gradient. */ --glow:#2B6CB0; --brand:#2B6CB0; --brand-deep:#1B4A73; --brand-tint:#E8F1FA; --brand-bright:#207CB7; --primary-cta-gradient:linear-gradient(135deg, #1B4A73, #207CB7); --primary-cta-text:#FFFFFF; --info:#2B6CB0; --info-text:#2B6CB0; --info-tint:#E8F1FA; /* HER EXACT ACCENTS ON FILLS, ICONS, BADGES AND BORDERS; MINIMALLY DARKENED WHERE THE SAME HUE IS READ AS TEXT. OWNER DECISION 2026-09-20, second pass — plans/DECISIONS-2026-09-20-design-fidelity-over-contrast.md The first pass took her literals for text as well, on the owner's ruling. Measured cost, which he did not have when he ruled: EIGHT failing accessibility tests across Devices, Apps, Categories, search, pricing and Activity, every one of them `color-contrast`. Shown that number he chose the narrower rule below. The split is by ROLE, not by token name: -accent = a FILL, ICON, BADGE GROUND or BORDER. Her literal, always. This is what the eye actually reads as "her palette". -text = GLYPHS. The smallest same-hue darkening that clears WCAG 1.4.3's 4.5:1 on the tint it lands on. At 11px bold the two are near-indistinguishable; the contrast difference between them is the entire defect. Measured on the tint each one actually lands on: amber #C2760A -> #9D5E08 3.10:1 -> 4.53:1 on the rendered #F7EEE3 pill green #3FA66C -> #2F7B50 2.69:1 -> 4.55:1 on #E3F5EA indigo #6D5BD0 -> #6A57CF 4.31:1 -> 4.51:1 on #ECE8FB red #C0342C is 4.61:1 already and is hers unchanged --text-tertiary is a GLYPH token (it paints .small, .legal, .footbrand) and takes the same treatment; --text-tertiary-ui keeps her #8A93A3 for the non-text uses, where 1.4.3 does not apply. NOT CHANGED, and still an owner-accepted regression: the .16 control borders. They are a BORDER, so they fall under the -accent half of this rule. WCAG 1.4.11 still measures them at 1.38:1 and the test that says so is left failing and marked, not suppressed. */ /* THE BASE HUE TOKENS ARE HERS, BECAUSE THEY ARE THE FILL TOKENS. Corrected after a blind review of ab3cb09c, whose commit message stated this exact rule and then broke it: it darkened --mint/--amber/--sky themselves. Measured, those three are consumed as `background` 27 times and as `border*` 9 times in app.css alone -- every toggle ON state, every status dot, the overview progress bar, two avatar tones. Darkening them shipped her fills darker than her artboard, which is the OPPOSITE of what the owner ruled and of what the commit claimed to do. The glyph sites now read the -text twins instead: 81 `color:` declarations across app.css and css/* were repointed from --mint/--amber/--sky to --done-text/--waiting-text/--attention-text. That is a NO-OP in dark, where the dark :root defines each -text twin AS an alias of its hue token (--done-text: var(--mint)), so only the light palette moves. */ --mint:#3FA66C; --done:#3FA66C; --done-text:#2F7B50; --done-accent:#3FA66C; --done-tint:#E3F5EA; --amber:#C2760A; --waiting:#C2760A; --waiting-text:#9D5E08; --waiting-accent:#C2760A; --waiting-tint:#FDF1DF; --sky:#6D5BD0; --attention:#6D5BD0; --attention-text:#6A57CF; --attention-accent:#6D5BD0; --attention-tint:#ECE8FB; --coral:#C0342C; --danger:#C0342C; --danger-text:#C0342C; --danger-accent:#C0342C; --danger-tint:#FCE4E4; /* Sidebar copy/indicator are 11.54/15.60:1 on navy. The specified 10% active fill is 1.35:1 as a fill alone, so the white 15.60:1 indicator carries the selected-state boundary. */ /* See --surface-raised in the dark :root above for why this exists. #F1F3F6 is the handoff's own neutral surface, measured off her artboards. */ --surface-raised:#F1F3F6; /* Her in-app field fill, measured off her CheckinModal. LIGHT ONLY — see the --field-fill note in the dark :root above for what happened when this lived there instead. */ --field-fill:#F5F7F9; --sidebar-bg:#16233F; --sidebar-inactive:#D7DEEB; --sidebar-active:rgba(255,255,255,.1); --sidebar-active-indicator:#FFFFFF; /* The rail's MUTED tone — group labels ("CHILDREN"/"HOUSEHOLD") and the identity footer's role line. Measured #8695B3 off the handoff. It had no token, so both were falling back to --haze, which is the LIGHT PAGE's secondary ink (#5B6472) and is nearly invisible on the navy rail; the group labels were instead rendering in --sidebar-inactive (#D7DEEB), the same tone as the nav entries themselves, so a static divider competed with the links it was supposed to separate. */ --sidebar-muted:#8695B3; --radius:22px; --radius-pill:999px; --radius-button:999px; --radius-input:999px; --radius-card:22px; --radius-card-large:32px; --radius-control:14px; --radius-icon:14px; --shadow:0 1px 2px rgba(22,35,63,.03), 0 6px 18px rgba(22,35,63,.04); --shadow-card:var(--shadow); --ui:'Nunito', system-ui, -apple-system, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif; --font-body:'Nunito', system-ui, -apple-system, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif; --font-heading:'Quicksand', 'Nunito', system-ui, sans-serif; } :root:not([data-theme]) .wm b { color: #087EA4; } :root:not([data-theme]) .pill.on { color: #0A6242; } :root:not([data-theme]) .pill.off { color: #B23127; } :root:not([data-theme]) .devlockbtn.lock { color: #8E2922; } :root:not([data-theme]) .devlockbtn.unlock { color: #0A6242; } :root:not([data-theme]) .devlockstate.failed { color: #B23127; } :root:not([data-theme]) .banner.err { background: rgba(204,59,49,.10); border-color: rgba(204,59,49,.5); color: #B23127; } :root:not([data-theme]) .banner.warn { background: rgba(242,169,59,.15); border-color: rgba(242,169,59,.55); color: #7A4F00; } :root:not([data-theme]) .banner.ask { background: rgba(44,107,209,.10); border-color: rgba(44,107,209,.45); color: #1F4F9C; } :root:not([data-theme]) .banner.info { background: rgba(44,107,209,.10); border-color: rgba(44,107,209,.45); color: #1F4F9C; } /* .card's own box-shadow rule now reads var(--shadow) directly (see the .card elevation comment below), so this no longer needs its own box-shadow override — the token already carries the lighter, blue-tinted ambient shadow the reference mockup uses on white. */ /* Bare var(--coral) as TEXT (not the pill.off/devlockbtn.lock spots above, which already carry their own darker literal overrides): the mockup's canonical light coral (#D4483D) measures 4.38:1 on white, just under the 4.5 an 11-14px label needs. #B23127 is not a new colour — .pill.off and .banner.err two lines up already use it for the identical "coral text on a light page" problem — and it measures 6.25:1 on white. Reused rather than re-derived. */ :root:not([data-theme]) .ghost.danger { color: #B23127; } :root:not([data-theme]) .iconbtn.danger { color: #B23127; } :root:not([data-theme]) .ss.off { color: #B23127; } * { box-sizing: border-box; margin: 0; padding: 0; } body { background: radial-gradient(circle at 8% -10%, rgba(101,216,255,.12), transparent 34rem), radial-gradient(circle at 100% 24%, rgba(136,167,255,.10), transparent 30rem), var(--bg); color: var(--cloud); font-family: var(--font-body); /* 15px/1.45 BELOW 900px, her 16px/1.5 AT AND ABOVE IT — see the media query right after this rule. Her body copy computes to Nunito 16px on a 24px line box on every artboard, and the old 15px/1.45 (rendering 21.75px) is where the "everything is slightly small and slightly tight" reading came from; it compounds, because most of this file's type is sized in em/rem off this base. But every one of her artboards is 1512px wide, so 16px is her DESKTOP value and she never drew a phone. Pushing it to every width crushed two real layouts — child names on a profile row at 390px, and the Kids screen at iPhone SE sizes — both caught by existing tests. OWNER DECISION 2026-09-20: hold her scale where she drew it and keep today's tighter scale narrow. Same rule already applied to her 34px buttons and 41px nav rows. */ font-size: 15px; line-height: 1.45; min-height: 100vh; display: flex; justify-content: center; padding: max(18px, env(safe-area-inset-top)) max(14px, env(safe-area-inset-right)) max(48px, env(safe-area-inset-bottom)) max(14px, env(safe-area-inset-left)); -webkit-text-size-adjust: 100%; } /* THE LIGHT PAGE IS FLAT WHITE, NOT WHITE-WITH-THE-DARK-GLOW. body's two radial-gradients are the dark theme's backdrop — a cyan and a periwinkle bloom sized in rem, painted at 12% and 10% alpha. They were never turned off for light, so the light dashboard was rendering a cyan wash over the top-left of every screen and a blue-violet one over the right. Measured on the live build via getComputedStyle: backgroundImage was still `radial-gradient(circle at 8% -10%, rgba(101,216,255,.12), ...)` with data-theme="light" active. The handoff is explicit that the page behind the cards is plain #FFFFFF and "not a tinted panel" (PAGE_SPEC, Visual Direction), so this is both the designer's intent and the removal of a straightforward bug. */ @media (min-width: 900px) { /* HER SCALE, AT THE WIDTH SHE DREW IT. See body's own comment above. */ body { font-size: 16px; line-height: 1.5; } } :root[data-theme="light"] body { background: var(--bg); } h1, h2, h3, h4, h5, h6 { font-family: var(--font-heading); } .wrap { width: 100%; max-width: 480px; } /* Tablets keep the phone navigation shell until the 900px rail breakpoint, but they should not inherit the phone's 480px reading column. This bounded canvas uses the available portrait width without turning the header/menu into the desktop sidebar early. */ @media (min-width: 700px) and (max-width: 899.98px) { .wrap { max-width: 820px; } } /* THE PHONE COLUMN IS UNCHANGED. Everything above is written for 440px and e2e/mobile.spec.cjs measures it at 390x844 and 360x800; none of that moves. What this adds is the case the design never had an answer for: a parent on a laptop, where the same column left roughly 840px of empty page on either side and pushed "Add a tablet" — the thing they came to do — about 1500px down. Two columns of cards, flowed by the browser, so a tall card and a short one pack instead of leaving a hole. `break-inside: avoid` is what stops a card being split across the gap; without it a card's header lands at the bottom of the left column and its buttons at the top of the right. KEYED ON `.screen`, NOT ON #devices/#policy/#inv, AND THAT IS THE POINT. Wave 0 turns three screens into twelve, and every later track adds content to one of the nine it did not build. Written as an id list this rule would have to be edited by a track that owns no CSS file, so the six new sections would silently render as one narrow column on a laptop while the three old ones stayed two. A class the section already wears cannot be forgotten. */ @media (min-width: 900px) { .screen > .card { break-inside: avoid; } /* REDESIGN 2026-08-29 — GRID, NOT `columns: 2`. CSS multi-column is a NEWSPAPER flow: it pours one continuous stream top-to-bottom down column one and then continues in column two, so card order reads down-then-over and card heights are decided by the flow rather than by the content. That is why this dashboard read as a jumbled pile next to the reference design, and it is also the root cause the `#overviewMount` comment below describes (a card's buttons orphaning into the next column). A real two-track grid places each card as a unit, in source order, left-to-right. */ .screen { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); gap: 18px; align-content: start; } /* The heading row, the sign-out note, the first-run card and a screen's own message line span both columns: they are about the page, not about one card in it. `#startCard` is still named because it is a card and would otherwise be caught by the rule above it. `.subnav` (GoodQA 13d59ad9's Apps/Websites/ Categories row on those three screens) joins them for the same reason: it is not a card and has no break-inside protection of its own, so without this it could column-split into two half-rows of chips. */ .screen > .toprow, .screen > .fineprint, .screen > #startCard, .screen > .muted, .screen > .subnav { grid-column: 1 / -1; } /* Grid `gap` owns the spacing now; a per-card margin would double it. */ .screen > .card { margin-top: 0; margin-bottom: 0; } /* GOODQA 13d59ad9 — Home's per-child cards are `.screen > #overviewMount > .card`, one level deeper than every rule above reaches (`.screen > .card` is a DIRECT-CHILD selector and #overviewMount is a wave-0 mount div, not the section itself). MEASURED with a real Playwright screenshot: without this, a card's name+chip+limit line landed at the bottom of column one and its own Pause now/Bedtime buttons re-appeared, orphaned, at the top of column two — the exact class of bug `#profList .arow`'s own comment three sections up in this file describes ("nothing failed; the page just became unreadable... which is why the screenshot is part of the check"). Scoped to #overviewMount specifically, same reasoning as that comment's own id-scoping: only this screen's cards are one level deeper. */ /* #overviewMount is itself the grid now (it is a wave-0 mount div one level below `.screen`, so `.screen`'s own grid cannot place its children). The orphaned-buttons bug the paragraph above describes was a multi-column artefact and cannot occur in a grid, but the two-track layout it wanted is kept — that part was right. */ /* SPANS THE PARENT GRID. #overviewMount is a child of `.screen`, which is itself a two-track grid — without this it would occupy ONE track and then split that half again for its own two columns, rendering quarter-width cards. Measured in a real screenshot before this line existed. */ /* HER THREE BANDS (W4.1). A full-width head, a two-track middle with the parent's DECISIONS on the left and "Today at a glance" on the right, then full-width detail below. THE DEFECT THIS FIXES, measured on the live page: "Waiting for you" (.ovalerts) rendered LAST, with its top edge at y=1309 on a 1772px page -- so the banner at y=239 told a parent three requests were waiting and the card holding them was ~1300px further down. Her Home puts pending requests in the upper-left, beside the children. 1.3fr / 1fr, not 1fr / 1fr: her decision column is the wider one. `order` rather than explicit grid-row placement, because these children are CONDITIONAL -- .ovstrip only exists with pending requests, .ovnudge only when a child has no device -- so any row arithmetic would be wrong for most households. `dense` is what lets .ovchildren backfill the right-hand track beside the shorter left-hand items instead of starting a new row. Scoped to >=900px on purpose: below it the single column stacks in DOM order and none of this applies (V0.1 -- the narrow collapse is unverified, so it is deliberately left exactly as it was). */ #overviewMount { grid-column: 1 / -1; display: grid; grid-template-columns: minmax(0, 1.3fr) minmax(0, 1fr); /* `dense` IS required, and the earlier chaos was not its fault. Sparse flow cannot place a column-1 item beside a column-2 item that was placed before it: once the cursor has passed column 2 on that row it only moves forward, so .ovquick fell BELOW .ovchildren (measured, y=1071 against y=421) instead of beside it. Dense placed the bands wrongly on the first attempt only because .ai-filter-prompt-host had no `order` and tied with .ovhead at 0. With every child explicitly ordered below, dense is deterministic. */ grid-auto-flow: row dense; /* min-content rows, so the 45px quick-action row is 45px tall rather than half of .ovchildren's height. Without it the spanned right-hand column distributed its 633px across the two rows it spans and left a ~130px dead gap under the action row. */ grid-auto-rows: min-content; gap: 18px; align-content: start; } #overviewMount > .card { margin-top: 0; margin-bottom: 0; } /* EVERY child gets an explicit order, and anything unlisted defaults to the BACK of the middle band rather than the front. An empty mount div (.ai-filter-prompt-host) has no order of its own, so with the default 0 it tied with .ovhead, was placed first, and grid's default `stretch` blew it up to the 633px height of the row beside it -- adding 300px to the page. Measured, not theorised: it went 0px tall to 633px tall. `align-self: start` on it as well, so an empty mount can never take height from a neighbour again. */ #overviewMount > * { order: 50; } #overviewMount > .ai-filter-prompt-host { order: 10; grid-column: 1 / -1; align-self: start; } /* Band 1: full width. */ #overviewMount > .ovhead { order: 1; grid-column: 1 / -1; } #overviewMount > .ovstrip { order: 2; grid-column: 1 / -1; } #overviewMount > .ovnudge { order: 3; grid-column: 1 / -1; } /* Band 2: the two-track middle. NO `dense`. Dense backfills, and with conditional children it shuffled the bands out of order (measured: .ovstrip landed at y=871, below the quick row). Plain sparse flow is deterministic here PROVIDED the right-hand item is placed FIRST: .ovchildren takes column 2 at the band's first row, the cursor stays on that row, and .ovquick then fits beside it in column 1 with .ovalerts falling to the row below. That is exactly her layout -- decisions stacked on the left, "Today at a glance" on the right. */ /* .ovchildren SPANS BOTH ROWS of the band so the two left-hand items stack beside it, which is her layout: quick actions above pending requests on the left, "Today at a glance" running the full height on the right. Without the span, .ovalerts was pushed to a THIRD row below the band (measured y=1071 against the band's y=421). `align-self: start` on .ovquick because grid's default `stretch` blew the 45px action row up to the band's 633px height. */ #overviewMount > .ovchildren { order: 20; grid-column: 2; grid-row: span 3; } #overviewMount > .ovquick { order: 21; grid-column: 1; align-self: start; } /* THE STAT TILES RIDE IN THE LEFT TRACK, ABOVE the pending list. They are OUR functionality -- she draws no tiles -- and CLAUDE.md pins what they are for: "the Overview answers five questions in five seconds: protected? online? time left? anything waiting? next scheduled change?" reading-load-ui.test.js enforces that as a FOLD rule at 1440x900. Left in the full-width detail band below, the three-band restructure pushed them from y=798 to y=1071 -- below the fold -- and the test caught it: "2 of 2 headline numbers are below the fold". A real regression against a pinned product rule, not a layout preference. In the 667px left track the three tiles are ~210px each, comfortably above their own minmax(180px, 1fr) floor. .ovchildren spans three rows now rather than two, to cover quick-actions + tiles + pending. */ #overviewMount > .ovtiles { order: 22; grid-column: 1; align-self: start; } #overviewMount > .ovalerts { order: 23; grid-column: 1; align-self: start; } /* Band 3: full-width detail. */ #overviewMount > .adv { order: 31; grid-column: 1 / -1; } #overviewMount > .ovweekly { order: 32; grid-column: 1 / -1; } #overviewMount > .help, #overviewMount > .muted { order: 33; grid-column: 1 / -1; } /* THE SIDEBAR ITSELF — GoodQA 13d59ad9's "not pills across the top". Same breakpoint the two-column card rule above already uses, and the same story: below 900px there is no room for a persistent rail without eating the one column of content there is, so the nav below that width stays exactly the wrapping row #navRow's own comment describes, unmeasured by anything here. GRID, WITH grid-template-AREAS, RATHER THAN REORDERED MARKUP. `.pagehead`, `.nav` and `#main` are siblings in that document order — the nav's own skip link has to precede `#main` — and named areas place them into a header row plus a nav/main row below it without moving a single element. The alternative, flexbox `order`, changes paint order but not DOM order, so Tab and a screen reader would still reach the sidebar after the whole of `#main` instead of before it. */ /* REDESIGN 2026-08-29 — a REAL application sidebar, not a 232px strip of pills floating inside a 1040px reading column. The reference build (docs/design + the Hands-On demo) puts a full-height panel flush against the viewport edge with the content beside it, which is what makes this read as an app rather than as a document. Three things change together and all three are load-bearing: 1. `.wrap`'s max-width is released at this breakpoint (the 1040px cap below 900px is untouched — a phone still gets the reading column). 2. The nav column becomes a panel: its own background, its own full -height scroll, flush left (negative margin cancels .wrap's padding). 3. `columns: 2` goes away — see the `.screen` rule further down. */ .wrap { display: grid; grid-template-columns: 230px 1fr; grid-template-areas: "head head" "nav main"; column-gap: 0; /* `start` for the grid, and `stretch` on the RAIL ALONE (below). I shipped `align-items: stretch` here to give the rail full height, and it stretched the HEAD ROW with it: measured pre-hydration, `.pagehead` became 433px tall while its only two children are 48px and 44px. That is the giant empty white card in the owner's screenshot of the boot flash — my own regression, live in 590ab374. The rail gets its full height from `align-self` on itself, which is what should have been used in the first place. */ align-items: start; max-width: none; width: 100%; padding-left: 0; padding-right: 0; } /* The rail carries the brand AND both chrome controls at this width, so the page header has nothing left to show and is hidden outright (see below). Below 900px there is no rail and this header remains the only place the brand, the theme toggle and the language select appear. */ .pagehead { grid-area: head; margin-inline: 22px; } /* THE PAGE-LEVEL BAR IS GONE WHEREVER A RAIL CAN CARRY ITS CONTENTS. --------------------------------------------------------------------- It already dropped the wordmark at this width (the rail carries the brand), which left a full-width 48px+18px bar whose entire remaining job was to hold a theme toggle and a language select — two controls a parent touches once, charged against the top of every screen on every visit. renderNavChrome() now moves the language select into the rail's footer beside the Appearance control that was already there, so at this width there is nothing left in here to show. ONLY when a rail is actually on screen to carry them instead. The auth screens (sign-in, forgot, reset) hold `.nav.hide` — they have no rail and no footer, so this must not reach them: hiding the header there would leave the FIRST page a parent ever sees with no branding, no theme control and no language control at all. That regression was caught once already, in a real screenshot of the deployed sign-in page rather than by a test, which is why the predicate is kept rather than simplified. Below 900px there is no rail either (app.css hides `.navbrand`/`.navfoot` outright), so a phone keeps this header exactly as it was — brand, theme and language — and app.js's placeChromeControls() puts the select back. */ .wrap:not(:has(.nav.hide)) .pagehead { display: none; } /* The greeting block states the screen; the generic "Overview" title above it would be the same word twice. Other screens keep their .toprow. */ #overview > .toprow { display: none; } .nav { /* ONE SCROLL CONTEXT, AND THE RAIL IS PART OF THE PAGE. OWNER, using the deployed build: "i can awkwardly scroll the whole screen and the sidebar and the content .. it feels super wack". He is describing exactly this rule. `position: sticky` + `height: 100vh` + `overflow-y: auto` made the rail its OWN scroll container while the document scrolled behind it -- two scrollbars, two scroll positions, and a rail that detached from the content beside it. Measured against her Home artboard: her aside is `position: static`, x=0, 230x1030, and 1030 is EXACTLY her document height. The rail is a column of the page, stretched by the grid row, scrolling with everything else. `align-items` on `.wrap` is changed from `start` to `stretch` for the same reason -- `start` is what capped ours at the 982px viewport against a taller page and left it visibly floating. */ grid-area: nav; margin: 0; position: static; /* THE RAIL stretches, not the grid. See `.wrap`'s align-items note. */ align-self: stretch; min-height: 100vh; /* GOODQA #467 — was var(--dusk), the same token `.card` paints itself with, so rail and page read as one surface (evidence: dark #101B2D rail on #09101D page, light #FFFFFF rail on #F2F6FB page, 1px --line the only edge). --railbg is a new, dedicated token: dark points at --dusk (today's value, unchanged pixel-for-pixel); light is the handoff's own navy, so only light actually repaints. */ background: var(--railbg); border-right: 0; /* The rail no longer scrolls independently (see above), so these two are inert at this width. Kept because the SAME rule serves the narrow mobile-open drawer, which does still scroll. */ scrollbar-width: thin; scrollbar-color: color-mix(in srgb, var(--railtext) 42%, transparent) transparent; /* portal-revamp: trimmed from 18px 14px / gap 4px to recover vertical rhythm for the two new household destinations (Apps, Websites) added to this rail — nav-reference-parity.test.js's own footer-on-screen assertion measured Sign out pushed below the fold once those two rows landed. This and the .navlabel/.navbrand/.navfoot trims below are chrome spacing only; no row's own min-height (the 44px touch target) is touched. TRIMMED AGAIN, 10px 14px -> 6px 14px (redesign area "checkins", docs/OWNER-DECISIONS.md 2026-09-17): shipping the `engage` row to the nav adds a twelfth destination and the same assertion measured Sign out at 994 against a 950px viewport before this and the three trims below it. Same rule: chrome spacing only, no row's min-height. OWNER'S OWN LIVE FEEDBACK, 2026-09-18, on a screenshot side-by-side against docs/design/ui-prototype-01: "the feel of nav bar needs to be clean like the mockup." MEASURED the actual cause before touching anything: every row rendered with ZERO visual gap to the next (getBoundingClientRect() showed each .navbtn exactly 44px below the last, back-to-back) — `gap: 0` really did mean zero, not "the 10px padding still reads as separation" the older comment below assumed. TRIED a real gap and measured the actual remaining budget rather than guessing: even 2px pushed Sign out to bottom 951 against a 950px viewport in nav-reference-parity.test.js's own default (single-child) fixture — this rail's footer-reachability budget is spent down to the literal pixel, three trims deep already (see above), and adding vertical space anywhere in it is not safely available. Fixed the "cramped, back-to-back" feel with a ZERO-HEIGHT-COST hairline between rows instead (`#navRow .navbtn`'s own `box-shadow`, formerly below — see its own comment for what replaced it and why) — real visual separation that costs no pixels, so the reachability budget this comment protects stays exactly as spent as it was. REVERSED, 2026-09-19 — OWNER'S OWN LIVE FEEDBACK AGAIN, this time on the real signed-in portal rather than a static screenshot: "the mockup doesn't have the lines wrapping around each menu item and its menu sidebar is much cleaner." The hairline above was the "line wrapping around each item" he was pointing at: at `gap: 0` it sits flush against the padding of the row below it, so every boundary between two rows reads as a rule drawn across the rail, not as breathing room. `design_handoff_parentproof/pages/Home.dc.html` (still the binding handoff) draws no border or box-shadow on any top-level row at all — gone, not lightened; see `#navRow .navbtn`'s own comment. PADDING WIDENED IN THE SAME PASS (6px 14px -> 24px 16px), independently reached via the same handoff file during the follow-up comprehensive design pass: with the hairline gone, `gap: 0` needed the rail's own outer padding to carry more of the "not cramped" job the hairline used to. Re-measured against nav-reference-parity.test.js's footer- reachability budget with the new padding in place — still passes. */ padding: 24px 16px; display: flex; flex-direction: column; gap: 0; } .nav::-webkit-scrollbar { width: 8px; } .nav::-webkit-scrollbar-track { background: transparent; } .nav::-webkit-scrollbar-thumb { border: 2px solid transparent; border-radius: 999px; background: color-mix(in srgb, var(--railtext) 42%, transparent); background-clip: content-box; } /* THE RAIL REACHES THE VIEWPORT EDGE, so body's inset moves onto #main. body carries `padding: 18px 14px 48px` for the phone layout, and at this width that padding was insetting the RAIL too -- measured live at x=14 with an 18px gap above it, which is most of why the owner read it as "weirdly disconnected". Hers sits at x=0,y=0. The same inset is added back to #main here so the CONTENT keeps its breathing room. `padding-bottom` JOINS THE ZEROED SIDES HERE, 2026-09-20 — OWNER, on the live build: "you can still scroll too far to a white broken chunk". MEASURED (elementFromPoint at the bottom of the scroll, 1440x950): the rail's own navy (`--railbg`) stops and `body`'s plain white shows through, edge to edge, for the last ~66px of a page taller than one viewport. Two contributors, both now fixed: 1. `.nav`'s own `margin: 0 0 18px` (below, the wrapping-chips phone nav's rule, unscoped) was winning the cascade over THIS block's `margin: 0` on the exact same `.nav` selector, at EVERY width — same specificity, later in the file always wins regardless of which media query reads as "more specific". See that rule's own comment for the fix. 2. THIS: `body`'s base `padding-bottom: max(48px, safe-area-inset-bottom)` is a PHONE value (gesture-bar / home-indicator clearance) and was never zeroed for the rail layout the way left/top already are above. It sits OUTSIDE the `.wrap` grid entirely, so no amount of stretching `.nav` inside that grid can ever paint over it — the 48px was structurally unreachable by the rail, on every desktop screen, all the time, not just when content happens to be short. Kept as `env(safe-area-inset-bottom, 0px)` rather than a flat 0: a rail layout can still run on a tablet with a physical home-indicator gesture area (an iPad Pro in standalone/PWA mode), and that protection costs nothing when the inset is 0, which it is in an ordinary desktop browser. */ body.signed-in { padding-left: 0; padding-top: 0; padding-bottom: env(safe-area-inset-bottom, 0px); } #main { grid-area: main; min-width: 0; padding: 18px 28px 60px; max-width: 1320px; } /* The row becomes the rail: the same five-plus-per-child chips, stacked instead of wrapped, each filling the sidebar's width so the current- screen fill (`.navbtn[aria-current="page"]`, above) reads edge to edge instead of as a pill floating in a wide empty row. */ /* Stays gap: 0 — see .nav's own comment above for why a real gap is not affordable here. No line-based substitute either, as of 2026-09-19 — same comment, same reasoning. */ /* gap 4px, NOT 0. OWNER, using the deployed build: the rail "feels a bit crowded compared to hers - its not just number of items, but spacing". Measured: `gap: 0` put our 44-47px rows flush against each other, while her 8-item household group is 369px tall for 41px rows -- roughly 5px of air between each. Fixing the ITEM COUNT (DF-5) would not have touched this, which is exactly the distinction he drew. */ #navRow { flex-direction: column; align-items: stretch; gap: 4px; } /* In the rail a nav entry is a full-width ROW, not a pill: no border, square -ish corners, left-aligned, so the current-screen fill reads edge to edge. Below 900px none of this applies and the wrapping row of chips is unchanged — e2e/mobile.spec.cjs measures that at 390x844 and 360x800. */ #navRow .navbtn { /* EXPLICITLY FLEX. `justify-content` was already here and did nothing: a