Decide whether the 7 remaining baselined Button overrides want semantic colour tokens (--warning) or stay one-offs
Follow-up to PLUTO-720, which burned 28 of 36 baselined Button className overrides and stopped where the remaining work stops being a SIZE question. The 7 keys / 8 occurrences still in scripts/ui-standard-lint.py BASELINE are colour, not geometry, and pm-pluto-cc ruled 2026-08-22 they stay there rather than being forced into size variants. The set: - access-requests-list.tsx "text-red-600 border-red-200 hover:bg-red-50" (1). Deliberately NOT folded into variant="destructive-outline" during 720: red-600 is not the destructive token, so folding it would have been a silent colour change disguised as a refactor. - login-client.tsx "w-full border-amber-300 bg-white text-amber-800 hover:bg-amber-100" (2) - the login warning action. - impersonation-banner.tsx "h-7 border-amber-700 bg-amber-300 text-amber-950 hover:bg-amber-200" (1) and "h-7 border-red-200 bg-red-500 text-white hover:bg-red-400" (1) - the impersonation exit/warning pair. - app-sidebar.tsx "w-full justify-center border border-[#eeeeee] bg-[#e3e3e3] text-[#54595f] hover:bg-[#d9d9d9]" (1) - hardcoded greys. - lazy-audit-log.tsx "gap-1 px-1" (1) - single-site padding on a ghost disclosure toggle, no second occurrence to justify a variant. - teacher-report.tsx "h-auto sm:h-auto items-start justify-start whitespace-normal py-2 text-left" (1) - a wrapping table cell, genuinely one-of-a-kind. The real question is whether warning/impersonation deserve SEMANTIC TOKENS the way destructive and primary already have them. 720 established the precedent that matters here: the brand buttons hardcoded bg-[#8d1d01], which turned out to BE --primary (globals.css) - the same colour re-spelled by hand. The amber and grey sites above may be the same story, or they may be genuine one-offs. Deciding that needs a look at whether amber recurs anywhere outside these three files, and a call on whether a --warning token is wanted at all. Do NOT mint a per-site variant for any of these: a variant with one call site is worse than the baseline entry it replaces, which is why 720 left them. Precondition: this is a design/token decision, not a mechanical burn-down. Needs an Elazar or pm call on whether --warning enters the token set before any code moves.
Activity
-
Precondition measurement done 2026-08-24 (coder-pluto-cc, code read only, no code moved). Amber recurs FAR outside the three button files: 122 utility hits across 30+ tsx files in 11 distinct shades (600 x34, 400 x14, 50 x13, 800 x12, 200 x11, 700 x8, 950 x7, 500 x7, 300 x7, 900 x5, 100 x4). Neighbours for scale: red 75, green 39, blue 18, orange 12. 22 of the amber hits already carry a hand-written dark: counterpart, so ~18% of sites pay the dark-mode cost by hand today. globals.css has a real .dark block and NO --warning token - the set is stock shadcn (primary/secondary/destructive/muted/accent/chart-1..5/sidebar-*). VERDICT on the WI question: the "same story as the brand buttons" half resolves YES - warning is a real semantic concept spelled by hand in 30 files, not a one-off. But it does NOT resolve into one token: 11 shades means the honest shape is a family (warning/warning-foreground/warning-muted/warning-border), mirroring destructive, with a dark-mode leg. Recommendation sent to pm-pluto-cc for the sequencing call: (A) mint the family and convert the recurring PAIRS first (bg-amber-50 + text-amber-800 + border-amber-200 is the banner shape; amber-600 alone is mostly an icon/text accent) - that also kills the 22 hand-rolled dark: pairs, the part most likely to be visually wrong today; (B) leave the 7 baselined BUTTON overrides where they are regardless, since they are 8 occurrences and the value is in the other 114 hits. Flagged that this collides with PLUTO-40 (mobile-first, p1), which will rewrite some of these surfaces - token work before 40 is cheaper than after, same pass is cheapest and riskiest. Held for pm sequencing; no code change proposed as p4 work.