fix(git-history): improve ref label contrast in dark theme

[Defmon3]

Problem

Git History renders ref labels such as HEAD -> custom and origin/custom in a saturated red/magenta color that has poor contrast against the dark background. The labels are difficult to read even though they carry important branch and remote-ref state.

Current behavior

• Ref labels use a low-contrast red/magenta foreground on the dark commit-details surface.
• The affected labels include the checked-out branch marker and remote-tracking refs.
• Nearby neutral text is substantially easier to read.

Expected behavior

Ref labels remain visually distinguishable from ordinary metadata while being comfortably readable in the dark theme.

Screenshot

Acceptance criteria

• HEAD -> <branch> and remote-ref labels meet WCAG AA contrast for normal text against their actual dark-theme background.
• The labels remain visually distinct from the commit hash, author, and date.
• Hovered, selected, and unselected commit-detail states remain readable.
• The light theme is unchanged unless the same token is proven deficient there.
• A focused UI/style regression test covers the selected dark-theme state.

[Defmon3]

Plan gh4-1 — Git History ref labels get an AA-clearing, theme-independent color token

Subagent: bug-fix-agent · Stack: frontend · Model: opus · Effort: medium · Depends on: none · Lanes: 1

Goal: Recolor the commit-details ref labels from text-primary (2.16:1 on the t3-chat dark canvas, and also failing AA in t3-chat light and t3-code dark) to text-info-foreground, the one semantic foreground the theme system deliberately keeps out of per-palette override, clearing 4.5:1 in both modes of all six built-in canvases; ref-kind distinction is deliberately not introduced here (the pane cannot reach refKinds), and the commit list's low-contrast kind tints are deliberately left alone because kind there is already carried by distinct glyph shapes plus a title, and its label text already passes AA.

Locks

• apps/web/src/index.css › the comment above the html[data-theme-id], html.dark[data-theme-id] block, verbatim: "Success, info, provider, and channel identity colors remain independent; error, warning, and update roles are themeable below." That block sets --primary, --warning-foreground, --update-foreground, --error-foreground per palette but never --info-foreground or --success-foreground. So --info-foreground is exactly two values app-wide: var(--color-blue-700) in :root and var(--color-blue-400) under @variant dark — for every built-in theme, every user theme, and the unthemed default. This is the whole reason the fix is a token choice and not a per-theme audit.

• apps/web/src/index.css › line 3 @custom-variant dark (&:is(.dark, .dark *)); — dark mode is class-driven, and --info-foreground flips with it. No dark: utility variant is needed at the call site.

• apps/web/src/index.css › --primary — :root has oklch(0.488 0.217 264), @variant dark has oklch(0.571 0.21 264), and html[data-theme-id] rebinds it to var(--app-theme-message-action). It also feeds --ring, --update, --message-action, and every solid CTA (components/ui/button.tsx bg-primary, checkbox.tsx, the settings slider rules). It is the token under the bug and is frozen: retuning it repaints every CTA in all five palettes.

• apps/web/src/components/git-history/GitHistoryCommitDetails.tsx › CommitDetailsPane — refs render as <span key={ref} className="text-[0.625rem] text-primary">{ref}</span> inside the details.refs.length > 0 block. This is the only text-primary in the git-history tree.

• apps/web/src/components/git-history/GitHistoryCommitDetails.tsx › CommitDetailsPane props — the pane takes no refKinds. The map lives in GitHistoryPanel.tsx › commitRefKinds and is passed only to CommitRow. GitHistoryPanel.tsx is fenced (issues fix(git-history): refresh externally updated commits and refs #3/feat(git-history): show additions and deletions in changed-file lists #5 own it), so local-vs-remote kind data cannot reach this pane and a string heuristic cannot recover it (feat/x and origin/x are indistinguishable by shape). Ref-kind distinction is therefore out of reach here, which is why nothing in this plan needs a second color to audit.

• Measured contrast, #a3004c/#db2777/#346bf1/#1b4ed8 from apps/web/src/themePalette.ts (messageAction), canvases from the same file (canvas), --color-blue-400: oklch(70.7% 0.165 254.624) = #51a2ff and --color-blue-700: oklch(48.8% 0.243 264.376) = #1447e6 from tailwindcss@4.3.0/theme.css:

  Theme · mode	canvas	before (text-primary)	after (text-info-foreground)
  T3 Chat · dark	#1f1a24	#a3004c 2.16:1 FAIL	6.46:1
  T3 Chat · light	#fdf7fd	#db2777 4.36:1 FAIL	6.47:1
  T3 Code · dark	#0a0a0a	#346bf1 4.26:1 FAIL	7.50:1
  T3 Code · light	#fcfcfc	#1b4ed8 6.54:1	6.66:1
  Grove · dark	#1d2b24	generated, unaudited	5.59:1
  Grove · light	#f2f8f4	generated, unaudited	6.35:1
  Ocean · dark	#1b2938	generated, unaudited	5.60:1
  Ocean · light	#f2f7fb	generated, unaudited	6.34:1
  Ember · dark	#30231e	generated, unaudited	5.75:1
  Ember · light	#fff6ef	generated, unaudited	6.40:1
  Iris · dark	#29243b	generated, unaudited	5.65:1
  Iris · light	#f7f4fc	generated, unaudited	6.28:1

  Ratios are against the theme canvas. The pane's bg-muted/5 is a near-canvas tint at 5% alpha (--muted is --alpha(var(--color-white) / 4%) unthemed, --app-theme-muted themed), which moves luminance by well under 1% and cannot pull the worst case (5.59:1) below 4.5:1. Grove/Ocean/Ember/Iris messageAction comes from themeActionColors(...) and is never contrast-solved against the canvas — a second reason --primary is the wrong token for body text.

• apps/web/src/themePalette.ts › standardStatusColors — solveOklchLightness(..., 4.6, ...) with the comment "lightness is nudged until the pair clears 4.5". 4.5:1 is the repo's own stated bar for themed foregrounds; this plan meets it without adding a solver.

• apps/web/src/components/git-history/GitHistoryCommitList.tsx › CommitRefDecoration — kind is carried by four distinct glyphs (CircleDotIcon/GitBranchIcon/CloudIcon/TagIcon), a title naming the kind, and label text at text-muted-foreground which already clears AA in both modes. The tints (text-sky-400 ≈ 1.5:1 on #fff6ef, text-amber-400 similar) are redundant reinforcement, not the sole carrier of meaning, so they are out of this bug's scope and stay untouched. Reusing this component in the details pane would import those tints into the pane and is fenced below.

• apps/web/vite.config.ts › unitTestProject — the single unit project, include: ["src/**/*.test.{ts,tsx}"], no DOM environment. Tests call components as plain functions and walk the returned element tree; computed color, cascade, and theme class are all unreachable. Any assertion here is an assertion about a className string.

• apps/web/src/components/GitHistoryPanel.test.tsx › its vi.mock("react", ...) / vi.mock("react/compiler-runtime", ...) factories, reactHookHarness as hooks, and visitElements usage — this is the wiring idiom for the new test. apps/web/src/test/reactHookHarness.ts shims only useCallback/useMemo/useRef/useState/useMemoCache; useCopyToClipboard (called by CommitDetailsPane) also uses React.useEffect, so the mock factory must supply one, as GitHistoryPanel.test.tsx already does.

• Surface sweep, per AGENTS.md "Hit every surface": the Git History panel exists only in apps/web (desktop wraps the same bundle; apps/mobile has git state/actions but no ref-decoration UI; nothing crosses packages/contracts). One file is the whole surface.

Surface reach

Surface	Before	After	Truth-telling when it cannot show everything
Commit details pane, ref row (CommitDetailsPane, details.refs)	Every ref of the selected commit, rendered verbatim, at 2.16:1 on the shipped dark canvas	Same refs, same strings, same order, same wrapping — readable at ≥5.59:1 in every built-in theme and mode	Unchanged: the pane renders every ref it is given and never truncates, so no truncation state exists to lie about; the empty/loading/error branches above it are untouched

Do

1. Recolor apps/web/src/components/git-history/GitHistoryCommitDetails.tsx › CommitDetailsPane, the details.refs.map span — change className="text-[0.625rem] text-primary" to className="text-[0.625rem] text-info-foreground". Nothing else on that span, that div, or that block changes. text-info-foreground is an existing utility (--color-info-foreground is declared in the @theme block of index.css) already used in components/AgentsPanel.tsx, components/chat/MessagesTimeline.tsx, and the info variant of components/ui/badge.tsx.
2. Add apps/web/src/components/git-history/GitHistoryCommitDetails.test.tsx — a new colocated test file covering the ref-label region per Test intent, wired exactly like GitHistoryPanel.test.tsx but importing and invoking CommitDetailsPane directly.

Don't

• Do not edit apps/web/src/themePalette.ts, apps/web/src/index.css, --primary, --app-theme-message-action, or any palette entry. The fix is at the call site.
• Do not edit apps/web/src/components/GitHistoryPanel.tsx — it belongs to the plans for issues fix(git-history): refresh externally updated commits and refs #3 and feat(git-history): show additions and deletions in changed-file lists #5. That also means: do not add a refKinds (or any new) prop to CommitDetailsPane, since only that file could pass it.
• Do not touch anything else in GitHistoryCommitDetails.tsx: not CommitFilesTree, not FILE_STATUS_COLORS, not the {props.files.length} loaded changed header row. Issue feat(git-history): show additions and deletions in changed-file lists #5's plan edits those and declares Depends on: this one.
• Do not touch apps/web/src/components/git-history/GitHistoryCommitList.tsx, and do not import or reuse CommitRefDecoration — it carries text-sky-400/text-violet-400/text-cyan-400/text-amber-400, which fall near 1.5:1 on the light canvases.
• Do not turn the refs into badges, pills, bordered chips, or icon rows; do not add a background, border, padding, radius, font, or size change; do not strip the HEAD -> or tag: prefixes from the rendered string. This is a color-token bug with one concern.
• Do not use text-warning-foreground, text-update-foreground, text-destructive-foreground, or text-error-foreground — all four are rebound per palette in the html[data-theme-id] block, so their contrast is unaudited on generated canvases.
• Do not add jsdom, happy-dom, testing-library, or Playwright; do not add or modify a test project in apps/web/vite.config.ts; do not introduce a runtime contrast-computation helper.
• Do not run repo-wide checks (AGENTS.md: no vp check, no vp run -r test/typecheck) — targeted test, lint, and typecheck for the two touched files only.
• Do not start a dev server, open a browser, or do computer use (AGENTS.md requires explicit permission first). The live check below is the conductor's step.

End state on disk

• Modified: apps/web/src/components/git-history/GitHistoryCommitDetails.tsx (one className token in the refs span).
• Added: apps/web/src/components/git-history/GitHistoryCommitDetails.test.tsx.
• apps/web/dist/** and apps/server/dist/client/** contain a prebuilt GitHistoryPanel-*.js bundle carrying the old class string; they are build output regenerated by the app build, not edited here.

Test intent

Target test file: apps/web/src/components/git-history/GitHistoryCommitDetails.test.tsx.
File policy: write-in-one-pass.

Category	Case	Assertion shape
Regression (the bug)	CommitDetailsPane invoked with hasSelection: true, a details carrying refs: ["HEAD -> custom", "origin/custom", "tag: v1.2.0"], no error, not pending	The element whose children equals each ref string has props.className containing text-info-foreground and not containing text-primary
Contract	Same render	Exactly three ref elements are produced, one per entry of details.refs, each rendering its raw string unmodified (tag: v1.2.0 stays verbatim)
Distinctness	Same render	The ref elements' className differs from the author/date span (text-muted-foreground) and from the commit-hash button (font-mono text-foreground), and none of the three classNames is a substring of another
Empty state	details.refs: [] with the same otherwise-valid selection	No element carries the ref className; the author/date/hash row still renders
Unselected / pending	hasSelection: false, then isPending: true	No ref element is produced in either branch — the ref row exists only in the selected, loaded state

What this proves: the ref labels are emitted with the AA-clearing token and never with --primary, on the selected loaded state. What it does not prove: any computed color, any cascade, any theme class, any actual contrast ratio — the unit project has no DOM. The ratios in Locks are the arithmetic proof; the run below is the eyeball proof.

Visual acceptance

• Screen/state: Git History panel, a commit whose details pane shows HEAD -> and an origin/ ref — open the panel from the right-panel tabs, click the top commit in the graph list, read the ref row directly under the author/date/hash line in the right-hand aside.
• Capture in T3 Chat dark (the palette in the report, #1f1a24 canvas) and in T3 Chat light (#fdf7fd), same commit, same panel width.
• Reference to compare: the same two shots taken before the change, where the dark-mode labels read as saturated magenta.
• Pass condition: in dark mode the ref labels read as clear blue text at the same weight/size as before and are as easy to read as the author name beside them; in light mode they read as deep blue and are not washed out; in both, they are obviously a different color from the white/near-black commit hash and the gray author and date. Nothing else in the pane shifted position, size, or spacing.

Risks / STOP

Risk	STOP condition
The fix is pulled toward a chip/badge redesign of the ref row, colliding with issue #5's edits to the same file	Any proposed change to the refs block beyond the single className token — stop and report rather than widen
Pressure to prove real contrast leads to standing up a DOM test environment	Any edit to apps/web/vite.config.ts or any new test-env dependency becomes necessary — stop; that is a separate decision
A user theme with a mid-tone canvas could still fail against the fixed blue	Out of scope here, but if the executor finds a built-in palette whose canvas contradicts the Locks table, stop and report the measured pair rather than pick a different token