feat(theme): white chat canvas with grey shell in kiro-light

[CrysisDeu]

Problem / Motivation

In kiro-light the chat transcript sits on a grey page (--bg: #fafafa) while the nav rail and sessions list float above it as white cards. The content — long markdown answers, code blocks, the composer — is the thing a user reads for hours, yet it is the recessive surface; the shell is the one that reads as "lifted". Every mainstream chat product does the opposite: a white canvas for the conversation and a quiet grey shell beside it.

Why it matters

Readability of long-form answers is the light theme's main job. A pure-white canvas gives markdown and code the highest-contrast surface available, and letting the shell step back makes the transcript unambiguously the primary surface instead of one more panel among the cards. This only touches kiro-light; every other theme, including kiro-dark, renders byte-identically.

What changed (motivation → approach → change)

Goal: invert the surface hierarchy in kiro-light — white canvas, grey shell.

Approach. Three token-level options were rendered against the real built SPA before choosing: (a) --bg → #ffffff alone, (b) the same plus a bordered user bubble, (c) the swap. (a) collapses every depth cue in the theme — the user bubble is a borderless bg-card fill and vanishes entirely (white on white), and the rail/sidebar/composer fall onto one flat plane. (b) fixes the bubble but adds an outline to every user turn. (c) is what shipped here: the canvas goes white and the two shell surfaces take the grey the page used to have.

Moving the rail and sidebar onto a shared token was considered and rejected: in ~30 of the 50 built-in theme blocks --panel is the page colour, not a shell colour, so a token-level bg-panel would have collapsed the rail and sidebar into the page background across most themes. Adding a new colour role instead would mean defining it in every built-in theme and both validator allowlists — the wrong scale for a one-theme change. The repo already scopes per-theme component rules with a [data-theme="kiro-light"] prefix (inline code, selected nav rows), so the change uses that mechanism.

Change.

• website/src/index.css, [data-theme="kiro-light"]: --bg #fafafa → #ffffff; --chrome follows to rgba(255,255,255,.95) so the translucent top bar does not band against the canvas. --panel stays #fafafa.
• website/src/index.css, kiro-light-scoped rules: .focus-chrome-rail (nav rail) and .sidebar-inner (sessions list) take background-color: var(--panel); .user-bubble takes var(--bg-hover) (#f0f0f0) so the bubble stays visible on the white canvas, in the same grey family as the shell. Specificity (0,2,0) outranks the Tailwind utilities (0,1,0); the existing embed-mode [&_.sidebar-inner]:!bg-bg override still wins.
• website/src/pages/chat/UserMessage.tsx: the non-steer user bubble carries a stable user-bubble hook class, and so does the in-place edit box that replaces it (its textarea is transparent), so editing does not flip the surface back to white under the caret. The steer variant (bg-accent-subtle) is untouched.
• website/src/pages/chat/PinnedPrompt.tsx: the pinned-prompt banner is documented as a pixel-for-pixel stand-in for the user bubble it replaces while that bubble is scrolled under the band; it carries the same user-bubble hook so the hand-off does not flip from #f0f0f0 to white in kiro-light.
• website/src/index.css + website/src/components/FeedbackPill.tsx: the two top-bar capsules (status readout .tb-capsule, Request a Feature .feedback-pill) share the bubble's failure mode — borderless bg-card on --chrome, which now follows the white canvas — so kiro-light gives them box-shadow: inset 0 0 0 1px var(--border), the edge the neighbouring search field draws with a real border, with no change to the box's size.
• website/docs/theming-contract.md: new paragraph "A card must carry its own edge" — since --card equals --bg in kiro-light, a bg-card box on the page draws a border, ring or shadow, a bg-bg well inside a card does the same, and hover states use --bg-hover; the deliberate borderless exceptions are the kiro-light hooks below, and a new one is a new hook, not an unmarked exception. Cross-referenced from the index.css comment.
• website/src/apps/workflows/WorkflowsRuns.tsx: the run rows' hover:bg-card becomes hover:bg-bg-hover — with --card equal to --bg, swapping one for the other was no hover at all in kiro-light; the hover token reads in every theme.
• website/src/test/kiroLightShellHooks.test.ts: a source-level guard pins every hook class the kiro-light rules select (focus-chrome-rail, sidebar-inner, user-bubble, tb-capsule, feedback-pill) to the component that must render it, and pins the three rules themselves.

Tests

kiroLightShellHooks.test.ts (12 cases) locks in: each hook class the kiro-light rules select is rendered by its component, the bubble tint stays on the non-steer branch only, and the three scoped rules exist as written — mutation-checked (dropping user-bubble from UserMessage.tsx turns two cases red). Existing coverage that pins the touched surfaces still passes — userBubbleMobileOverflow.test.tsx / UserMessage.bubbleHug.test.tsx (bubble width chain, tolerant of the added class), PhasedViewTheme.test.tsx (every referenced token exists), themeFillForeground.test.ts and dashboardTheme.test.ts (kiro-light resolution). Full frontend suite: 1854 files / 29168 tests green; tsc -b, eslint (--max-warnings 0), phantom-classes, i18n check + render, jscpd, focus-cue, bundle-size, brand, docs-lint and scrub-lint all green. The 434 backend cross-surface guard files were run; the 76 reds are host-environment failures (uid ownership of the checkout path, pytest tmp under the data home) and reproduce identically on the base commit.

Manual verification

Rendered the real built website/dist against stubbed fixtures with the repo's transcript harness, before and after, and read the computed colours: kiro-light body rgb(250,250,250) → rgb(255,255,255); rail and sessions list #ffffff → #fafafa; user bubble #ffffff → #f0f0f0. kiro-dark body/rail/sidebar/bubble are identical before and after. Settings and the chat page were checked visually. A computed-style sweep of nine non-chat routes in kiro-light (Settings ×4, Schedule, Artifacts, Knowledge, Apps library, Members) found zero card-coloured boxes without a border, ring, shadow or contrasting parent — the only hit is body itself — so no further borderless bg-card surface is affected by --card now equalling --bg.

Screenshots / video

Static change, no motion — stills are the right evidence.

Chat, kiro-light — before / after

Bubble + composer, after (crop)

Top-bar capsules — first head vs now (crop, 2x)

Settings page before / after, and kiro-dark parity

Related Issues

no linked issue: design decision taken directly with the maintainer from rendered variants; no tracked issue exists for it.

Checklist

• At most two commits (one is the norm), with a Conventional Commits title (feat|fix|docs|refactor|perf|test|chore|ci|build|revert: ...)
• Existing tests pass and new tests added for new functionality
• Self-review completed; code follows project style guidelines
• Documentation updated (if applicable) — N/A, no doc records per-theme token values
• No secrets, credentials, or internal references in the diff

[github-actions]

Opus 4.8 Review — ✅ no blocking findings

Reviewed 11903a4aa6bdc439d408ebbf07d0282bcd8df267 — this comment is updated in place on each push.

Review details

All candidate claims verified against source: the five test hook regexes match their real markup (focus-chrome-rail/tb-capsule in App.tsx, sidebar-inner in ChatSidebar.tsx, plus the in-diff hooks), the new CSS rules are all scoped to [data-theme="kiro-light"], and the borderless bg-card surfaces that the white-canvas change would erase each receive a compensating hook. Nothing survives falsification.

No findings.

[OPUS-REVIEWED] 11903a4

Verdict parsed from the review's SHA-scoped output markers for commit 11903a4aa6bdc439d408ebbf07d0282bcd8df267.

False positive or not applicable? A repository writer can comment:
/ai-review override fable 11903a4aa6bdc439d408ebbf07d0282bcd8df267: <one-sentence reason>

[github-actions]

Design Review (Fable 5) — 🟡 CONCERNS

Design-level review of 11903a4aa6bdc439d408ebbf07d0282bcd8df267 — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

Design-Verdict: CONCERNS

Collapsing --card to equal --bg creates a permanent, ungated invisible-surface class in kiro-light, guarded only by convention; plus temp screenshots committed into the repo.

Watch

• The doc itself states the new failure mode: a borderless bg-card box "ships invisible in that one, with no gate failing." The new test pins the five known hooks but cannot catch the next contributor's borderless bg-card, so the invariant every other theme upholds is now enforced in kiro-light by a doc paragraph and reviewer memory — a silent regression class that recurs on every new surface. The verification sweep the PR already ran ("computed-style sweep of nine routes... zero card-coloured boxes without a border") is exactly the automatable check that would close this; without it the mitigation is convention-only.
• Six binary PNGs (~660 KB) land under temp-screenshots/ solely to serve the PR description's image links. Once merged they sit in main and in git history permanently; GitHub PR image uploads do the same job with zero repo cost. Move the images out of the tree before merge.

Suggestions

• Promote the manual computed-style sweep (borderless bg-card on --bg in kiro-light) into a CI or vitest gate, replacing the source-regex pinning as the primary guard.

[DESIGN-REVIEWED] 11903a4

[github-actions]

GPT 5.6 Review — ✅ no blocking findings

GPT 5.6 completed its review of 11903a4aa6bdc439d408ebbf07d0282bcd8df267 and found no blocking issues.

This comment is updated in place on each push.

Review details

FINDING -- website/src/apps/workflows/WorkflowsRuns.tsx:325 -- "hover:bg-bg-hover" changes workflow-row hover colors in every theme despite the stated kiro-light-only scope -> Fix: keep hover:bg-card as the default and apply the new hover token through a kiro-light-scoped hook. (origin: validation)
[GPT-REVIEWED] 11903a4

False positive or not applicable? A repository writer can comment:
/ai-review override gpt 11903a4aa6bdc439d408ebbf07d0282bcd8df267: <one-sentence reason>

[github-actions]

First Principles Review (Fable 5) — 🟡 CONCERNS

Premise-level review of 11903a4aa6bdc439d408ebbf07d0282bcd8df267 — why this exists and whether the shipped surface is the smallest honest version. Updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

All claims verified: the per-theme scoped-rule mechanism pre-exists (index.css:1531,1543), temp-screenshots/ is the documented PR-template evidence convention, message-bubble is shared with AssistantMessage so it cannot serve as the bubble hook, and hover:bg-card has zero remaining instances after the WorkflowsRuns fix. The findings are below.

First-Principles-Verdict: CONCERNS

The whole change hangs on an inherited premise: "every mainstream chat product does the opposite" is analogy, and no user harm or recorded decision backs the inversion.

What this change ships

Intent: make the chat transcript, not the shell, the visually primary surface in kiro-light. ADDITION (a changed default, not a fix).

1. kiro-light canvas and every page turns pure white — inherited premise, see Watch
2. Nav rail and sessions list turn grey in kiro-light — justified
3. User bubble (plus edit box and pinned banner) turns grey in kiro-light — justified
4. Top bar follows the canvas to white — justified
5. Top-bar capsules gain a 1px inset edge in kiro-light — justified
6. Workflows run-row hover uses the hover token in every theme — justified; 0 remaining hover:bg-card
7. New theming-contract rule "a card must carry its own edge" — derived, spec-sync same commit
8. New test pinning the five hook classes to their components — justified guard
9. Six evidence PNGs under temp-screenshots/ — derived, documented PR-template convention

Watch

• The core item's only support is resemblance to other products plus an unrecorded maintainer sign-off ("no linked issue: design decision taken directly with the maintainer"). No reader was failing on #fafafa; both values pass AAA. A human should confirm that sign-off before merge.
• Everything in items 3, 5, 7, 8 (two hook classes, three scoped rules, a doc rule, a 95-line test) exists only because --card now equals --bg. The rejected-alternatives analysis covers --panel and bubble variants but never "nudge --card off --bg", which would delete that whole exception apparatus at the cost of repainting every card. Unconsidered, not necessarily better.

[FIRST-PRINCIPLES-REVIEWED] 11903a4

[github-actions]

UX Review (Fable 5) — ✅ PASS

UX-level review of 11903a4aa6bdc439d408ebbf07d0282bcd8df267 — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

UX-Verdict: PASS

The white-canvas swap ships with every vanishing-surface case hooked, screenshot-proven, and pinned by test plus contract doc; nothing a user hits regresses.

[UX-REVIEWED] 11903a4

[CrysisDeu]

• Unguarded user-bubble hook — disposition: fixed in 93dbb1991.

The new user-bubble hook is load-bearing but unguarded: no test pins it and the phantom-classes gate only covers Tailwind color utilities, so a future UserMessage.tsx refactor that drops the class silently returns the kiro-light bubble to white-on-white.

Added website/src/test/kiroLightShellHooks.test.ts: it parses every .hook the [data-theme="kiro-light"] rules select out of index.css and asserts each one is still rendered by its component (user-bubble → UserMessage.tsx, focus-chrome-rail/tb-capsule → App.tsx, sidebar-inner → ChatSidebar.tsx, feedback-pill → FeedbackPill.tsx), that the bubble tint stays on the non-steer branch, and that the three scoped rules exist as written. Mutation-checked: removing user-bubble from UserMessage.tsx turns two cases red.

[CrysisDeu]

• FeedbackPill loses its container on the white --chrome — disposition: fixed in 93dbb1991.

FeedbackPill.tsx:91 shares the exact failure mode this PR fixes: a borderless bg-card (#ffffff) fill on the now-white --chrome, so the "Request a Feature" pill loses its container and its nightly/insider divider floats between two bare labels.

Confirmed in the rendered build — and the status readout capsule next to it (.tb-capsule, also borderless bg-card) had the same failure, so both are covered: FeedbackPill now carries a feedback-pill hook and kiro-light gives .tb-capsule, .feedback-pill an inset 1px --border ring (the edge the neighbouring search field draws with a real border; no box-size change; other themes untouched). Before/after crop: temp-screenshots/kiro-light-canvas-swap/topbar-capsules-before-after.png on 93dbb1991.

[CrysisDeu]

• --card aliases --bg in kiro-light; the exception list is hand-enumerated — disposition: fixed in fab67ca88 (the sweep it asked for was run; the convention it asked for is now written).

With --bg: #ffffff and --card: #ffffff, bg-card no longer contrasts with the page anywhere in kiro-light … before merging, a human should sweep the non-chat pages in kiro-light and, going forward, the collision needs a stated convention.

Sweep: a computed-style pass over nine non-chat routes in kiro-light on the built bundle (Settings ×4, Schedule, Artifacts, Knowledge, Apps library, Members), counting every element painted --card with no border, ring, shadow or contrasting parent — zero hits apart from body itself, so every real bg-card on those pages already carries its own edge. Convention: website/docs/theming-contract.md gains "A card must carry its own edge" (a bg-card box on --bg draws a border-border, ring-1 ring-border or shadow-*; the borderless exceptions are the kiro-light hooks, and a new one is a fourth hook pinned by kiroLightShellHooks.test.ts, not an unmarked exception), cross-referenced from the index.css comment. The guard test cannot see the next borderless card by construction; the written rule plus the theming contract's place in review is what catches it, which is the shape the finding asked for.

[CrysisDeu]

• Edit-mode bubble stays white while the display bubble is grey — disposition: fixed in fab67ca88.

The edit-mode bubble (UserMessage.tsx:182, edit-grow … bg-card) stays white while the display bubble it replaces is now grey; tinting it via the same hook keeps the edit affordance visually anchored to the bubble being edited.

The edit box now carries the same user-bubble hook (className="edit-grow user-bubble …"); its textarea is bg-transparent, so the kiro-light tint shows through under the caret. kiroLightShellHooks.test.ts pins the edit-box hook alongside the display-bubble one.

[CrysisDeu]

• Six bg-card candidates in built-in app pages not covered by the sweep — disposition: rebutted (each checked; all six already carry an edge or are a functional opaque cover, so none ships invisible in kiro-light). No code change.

Grepping className="…bg-card…" without border|ring|shadow in the same attribute finds 6 candidates there: spec-builder/components/SpecStatePanel.tsx:169,176,232, spec-builder/components/DocView.tsx:185, aws-control/DrivePage.tsx:2088,2196. Any of these that renders directly on --bg ships invisible in kiro-light with no gate failing.

Per candidate:

• SpecStatePanel.tsx:169 — the decision card has style={{ border: '1px solid ' + (settled ? 'var(--border)' : 'color-mix(in srgb, var(--accent) 50%, transparent)') }} on the same element; the edge is an inline style, which the attribute-only grep cannot see.
• SpecStatePanel.tsx:176 — the sticky question header inside that bordered card; its bg-card exists to cover options scrolling under it, and it sits within the card's border.
• SpecStatePanel.tsx:232 — the blocking-note card has style={{ border: '1px solid color-mix(in srgb, var(--warn) 45%, transparent)' }}.
• DocView.tsx:185 — the comment strip has style={{ borderTop: '2px solid ' + ACCENT }} and is the shrink-0 last child of the view, so its top edge is a 2px accent rule and its bottom edge is the panel's own edge.
• DrivePage.tsx:2088 / :2196 — <td class="sticky right-0 bg-card"> action cells whose bg-card is a functional opaque cover over horizontally scrolled cells; the rows they sit in (border-b border-border, no fill) were already the page colour, so the cell's job (hide what scrolls beneath) is unchanged and the previous faint lighter stripe simply disappears.

The heuristic gap the finding exposes — inline style borders and functional covers are invisible to an attribute grep — is why the PR's sweep reads computed styles (getComputedStyle: border widths, box-shadow, outline, and the nearest painted ancestor) rather than class strings.

[CrysisDeu]

Rebased onto c791f0f1d (main now carries #8712, the fix for the TestGitPublishSubshellGluing / TestUnrecognisedOptionsReadProtectively failures this PR's backend shards had been inheriting). Same single commit, diff unchanged — now 8d9129070; those two test classes pass locally on the rebased tree (51/51). Screenshot URLs in the description re-pinned to the new SHA.

[CrysisDeu]

• SpecDetail.tsx:873 spec-builder well is borderless — disposition: rebutted (it carries a border). No code change.

… and the spec-builder well at SpecDetail.tsx:873.

That element is <div className="mt-2.5 rounded-lg bg-bg shrink-0 …" style={{ border: '1px solid ' + SEL_BORDER }}> — the edge is an inline style, which a class-attribute grep cannot see (the same blind spot as the six bg-card candidates checked earlier on this PR). Its header row additionally draws border-b border-border. Rendered in kiro-light it is a framed panel, not a melted one.

[CrysisDeu]

• Give the three KiroPrerequisiteGate pre blocks border border-border — disposition: accepted-and-deferred → fix(setup-gate): route the kiro-cli spec-refusal wells through ErrorNotice (framing lost in kiro-light) #8753 (labelled deferred-finding, assigned, due 2026-10-03); unchanged from the ruling on the previous head.

Give the three KiroPrerequisiteGate pre blocks border border-border, matching their sibling <code> at line 1072, instead of adding hooks.

Exactly that one-line change was applied locally on the head before this one and reverted: the wells render kiro-cli's spec-refusal output, and touching them pulled them under the blocking errors-use-error-notice rule (the local GPT lane blocked; the local Opus lane read them as informational — a lane split). The compliant fix is the ErrorNotice migration with an askAgent decision, which is a first-run-gate redesign, not a theme change. #8753 carries the framing and the migration together so the gate is changed once.

[CrysisDeu]

• One root cause, several surfaces: a borderless bg-bg well inside a bg-card container paints nothing in kiro-light — disposition: fixed in 47aaace51 for the surface this PR owns to name (the contract now states the inverse rule); the two concrete hits are ruled individually above (SpecDetail.tsx:873 rebutted — it has a border; the setup-gate wells deferred to fix(setup-gate): route the kiro-cli spec-refusal wells through ErrorNotice (framing lost in kiro-light) #8753).

One root cause, several surfaces: --bg now equals --card, so a borderless bg-bg well inside a bg-card container paints nothing in kiro-light … kiro-light is the default light resolution, so frequency is every light-mode user × friction × persistent.

The frequency argument is fair and is why #8751 (a rendered computed-style gate over the routes) exists as the durable answer for both directions; the contract paragraph is what a reviewer applies until that gate lands.

[CrysisDeu]

• PinnedPrompt breaks the hand-off illusion in kiro-light — fixed in 11903a4. The pinned card is documented as a pixel-for-pixel stand-in for the bubble it replaces while that bubble is scrolled under the band; it kept bg-card (white) while the bubble moved to --bg-hover. It now carries the same user-bubble hook, so the hand-off stays #f0f0f0 → #f0f0f0; the header comment in PinnedPrompt.tsx names the hook's purpose, and kiroLightShellHooks.test.ts pins the class on that card so a class-string refactor cannot silently drop it.

[CrysisDeu]

• Guard-test failures give no hint about the fix — fixed in 11903a4. Every assertion in kiroLightShellHooks.test.ts now carries a message that names the theme rule it protects, says to keep the hook class on the element rather than widening the regex, and points at the "A card must carry its own edge" section of website/docs/theming-contract.md. Mutation-checked: removing the pinned-card hook fails with exactly that message.

[CrysisDeu]

• ~341 bg-card sites are covered only by convention after this change — accepted-and-deferred → ci: gate kiro-light against borderless bg-card surfaces with a rendered computed-style sweep #8751. This PR handled the sites that are visible in kiro-light today (a swept render of the chat route plus nine non-chat routes found zero remaining borderless card-on-page surfaces; the three earlier candidates carried their edge via inline style, which is why a class grep over-reports). The contract paragraph is the convention; the mechanical check for the rest is the issue's scope, not this theming PR's.

[CrysisDeu]

• The kiro-light hook list is a growing maintenance tax — accepted-and-deferred → ci: gate kiro-light against borderless bg-card surfaces with a rendered computed-style sweep #8751. The list is three hooks (user-bubble, tb-capsule/feedback-pill, sidebar-inner/focus-chrome-rail), each pinned to its component by the guard test so a rename fails loudly instead of silently reverting the surface. Replacing the hooks with new theme tokens would require adding them to all 50 themes and the validator allowlists (the contract forbids partial tokens), which is a bigger change than the visual fix warrants; ci: gate kiro-light against borderless bg-card surfaces with a rendered computed-style sweep #8751 tracks whether a computed-style gate makes the hook list unnecessary.

[CrysisDeu]

• Add a mechanical className check as a follow-up — accepted-and-deferred → ci: gate kiro-light against borderless bg-card surfaces with a rendered computed-style sweep #8751, with one amendment recorded there: a className grep for bg-card without border/ring/shadow over-reports, because several sites carry their edge through an inline style or a parent's divider, and under-reports the inverse case (bg-bg wells inside a card). The issue is scoped to a computed-style check over rendered routes in kiro-light (background equal to the parent's and no visible edge), which is what the manual sweep for this PR did.

[CrysisDeu]

• Six PNGs under temp-screenshots/ should move out of the tree before merge — rebutted. temp-screenshots/<feature>/ is this repository's documented evidence convention: the PR template (.github/PULL_REQUEST_TEMPLATE.md §Screenshots) prescribes exactly this directory and the commit-SHA-pinned raw URL form, and temp-screenshots/README.md explains why GitHub's user-attachments cannot replace it — nothing in CI or the CLI can produce an attachment, and ux-review.yml / fork-ux-review.yml gate on files the diff adds, so an attachment would take the PR out of UX-review scope. The directory ships in neither the wheel nor the desktop bundle. Removing the files is a change to the repo convention, which belongs in its own PR.

[CrysisDeu]

• Collapsing --card to --bg leaves an ungated invisible-surface class guarded by convention — accepted-and-deferred → ci: gate kiro-light against borderless bg-card surfaces with a rendered computed-style sweep #8751 (unchanged from the disposition on the previous head). This PR pins every hook it introduces and swept the rendered routes; the mechanical gate for future surfaces is the issue's scope.

[CrysisDeu]

• Promote the computed-style sweep into a CI/vitest gate — accepted-and-deferred → ci: gate kiro-light against borderless bg-card surfaces with a rendered computed-style sweep #8751, which is scoped to exactly that (computed background vs parent + visible-edge check over rendered kiro-light routes, replacing the source-regex pinning as the primary guard once it exists).

[CrysisDeu]

• "Nudge --card off --bg" was not in the rejected-alternatives analysis — rebutted, with the reason recorded here. A --card value off --bg (#ffffff) also has to stay off --panel (#fafafa), because cards sit on the panel too (ChatSidebar.tsx alone has three bg-card surfaces on the sessions list). That forces a third grey (#f5f5f5 or darker) and repaints every card in the theme grey-on-white — the grey-surface direction the maintainer rejected when choosing this design against rendered variants. It also would not delete most of the apparatus: the bubble tint and the panel-coloured rail are the chosen design's content, not consequences of --card == --bg; only the capsule inset edge and the contract paragraph are. The sign-off item above stands as the human decision on this PR.

[CrysisDeu]

• hover:bg-bg-hover in WorkflowsRuns.tsx:325 changes hover colour in every theme despite the kiro-light scope (span=d9cded1b24ee) — rebutted. The cross-theme scope of this one line is deliberate and stated in the PR body: hover:bg-card was a mis-token — a hover state painted with the card colour is a no-op in any theme where --card equals the background under the row (kiro-light now, and every theme where a card sits on a card), while --bg-hover is the token every theme defines for exactly this state. Keeping the no-op as the default and patching kiro-light through a hook would preserve the bug for the other themes it already affects. The selected-row state still uses bg-card.