fix(fork): flat white release send button

[NoahHendrickson]

Summary

• On release/prod builds, the composer send button is flat pure white with a black icon instead of upstream primary purple.
• Dev and Nightly keep the existing stage-channel fill via data-fork-composer-send-tone="channel".
• Guard + manifest intent updated so a sync cannot silently drop the release tone.

Test plan

• Open a release/Alpha build (or force stage label off Dev/Nightly) and confirm send is #ffffff with a black return arrow, no shadow/purple tint
• On a Dev build, confirm the send button still shows channel dither art
• Confirm stop is unchanged (#ea3150)
• vp test run apps/web/src/__fork_guards__/forkComposerShell.test.ts

Made with Cursor

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[cursor]

Thermo-nuclear code quality

Not approved — no structural spaghetti or 1k-crossing regression, but this misses an obvious simplification.

Release send is painted three ways (tone attribute + Tailwind white/black + theme.custom.css #ffffff/#000000) for one fill change. The composer-shell manifest already notes fork CSS is unlayered and beats Tailwind utilities, so CSS alone would override bg-primary/90. Keeping all three adds a tone concept and a second source of truth without buying resilience.

Required: pick one paint owner — (1) attribute + CSS, leave Tailwind fill alone, or (2) Tailwind-only and delete attribute/CSS/tone. Also drop the redundant :hover:enabled twin if CSS stays.

theme.custom.css was already >1k; don't grow it for colors Tailwind already sets.

  

_{Sent by Cursor Automation: Thermo-nuclear PR review}

[NoahHendrickson]

Review: aggressive pass

The visual intent is right and the Dev/Nightly path is provably untouched. But the styling is declared twice, only one copy is live, and the live copy is missing the .dark scope that every neighbouring rule in this file carries — which breaks the light theme outright.

Verdict: request changes. One blocker, plus a structural argument that most of the .tsx diff should be deleted rather than fixed.

---

🔴 Blocker — light mode renders an invisible send button

theme.custom.css:441-447 is scoped to :root[data-fork=…] with no .dark:

:root[data-fork="noahhendrickson-t3code"]
  [data-fork-composer-action="send"][data-fork-composer-send-tone="flat"] {
  background: #ffffff;
  color: #000000;
  box-shadow: none;
}

In light mode the composer surface is --fork-composer-bg: var(--card) (theme.custom.css:268), and upstream's light --card is var(--color-white) — pure #fff (index.css:867, inside the color-scheme: light root). So on a light-theme release build the button is #ffffff on #ffffff, and box-shadow: none deliberately removes the only remaining edge. What ships is a floating black arrow with no button under it. Disabled is worse: disabled:opacity-30 fades the glyph to ~#b3b3b3 on white, so the control reads as absent.

Before this PR that path was bg-primary/90 — visible. This is a regression, not a gap.

This also contradicts the file's own stated convention in three places:

• theme.custom.css:254 — "Everything below is dark-scoped: the designs are dark-only, and an unmarked or light build keeps upstream's shell untouched."
• theme.custom.css:231 — "Scoped to dark because the design is dark-only."
• The stop button, 13 lines below the new rule, is .dark-scoped: :root[…].dark [data-fork-composer-action="stop"] (theme.custom.css:454).

Fix is one token — add .dark to both new selectors, matching stop. Light mode then keeps upstream primary, which is what the file says light mode is supposed to do.

---

🟠 The entire className diff is dead code

main.tsx:34 calls applyForkMarker(document.documentElement) at module scope, before React renders. So data-fork is always present. And per this file's own comment at theme.custom.css:330, "this stylesheet is unlayered and Tailwind v4 utilities sit in @layer utilities, which loses to unlayered rules whatever their specificity."

Therefore, on the flat branch:

class	overridden by	live?
bg-white	background: #ffffff	❌
text-black	color: #000000	❌
shadow-none	box-shadow: none	❌
hover:bg-white	the :hover:enabled rule	❌

Every one of them is unreachable. They are a second, unguarded source of truth for the same four declarations — the new guard asserts the CSS and the attribute, and nothing asserts these. That is exactly the drift shape #13 was written to close, reintroduced.

.fork/AGENTS.md ranks this explicitly: theme/styling → theme.custom.css (rank 3); inline edit of an upstream file → "last resort… keep the hunk small" (rank 4). The only inline edit this change actually needs is the data-fork-composer-send-tone attribute, which is a legitimate CSS hook. Recommend dropping the className ternary edit entirely and letting the ternary keep returning upstream's bg-primary/90 … for the flat case.

🟠 The base-class refactor is pure churn on a watch: file

I diffed the union of base + branch classes on both sides — old and new are the same 27 utilities, so Dev/Nightly is byte-for-byte identical behaviour. Good. But that means hoisting text-primary-foreground shadow-xs enabled:inset-shadow-[…] active:inset-shadow-[…] active:shadow-none disabled:shadow-none out of the shared base bought nothing, while rewriting both arms of a ternary in a file listed under watch: (customizations.yaml:720) — i.e. maximum upstream merge-conflict surface for zero behaviour change.

It wasn't even necessary for the Tailwind-only path: cn() is tailwind-merge, so shadow-xs in base followed by shadow-none in the branch already resolves to shadow-none. Per CLAUDE.md — "Prefer fixing over rewriting", "smallest change that satisfies the request" — this hunk should revert.

🟡 The :hover:enabled rule is a no-op

theme.custom.css:448-452 re-declares the identical background / color as the base rule. Nothing else targets the send button's background on hover — the channel branch uses brightness-110 (a filter), and hover:bg-white loses to unlayered CSS anyway. Delete it, or if it's intended as anti-drift armour, say so in the comment, because as written it reads as a real hover state and isn't one.

🟡 "flat" means "not dev/nightly", not "release"

resolveSidebarStageBackdropVariant (SidebarStageBackdrop.tsx:17-24) returns non-null only for exactly "nightly" and "dev"; everything else falls to null. So stageBackdropVariant ? "channel" : "flat" gives flat white to any unrecognised stage label — a future Beta/Canary/Alpha channel silently inherits the release treatment with no one deciding that.

That also makes the new manifest prose subtly untrue: it now asserts "On a release build the send button is flat pure white" (customizations.yaml:618), but the invariant the code enforces is "on a build with no stage art". intent is supposed to state what must stay true — worth wording it as the latter.

🟡 The guard tests assert formatting, not behaviour

expect(primaryActions).toContain('data-fork-composer-send-tone={stageBackdropVariant ? "channel" : "flat"}');

Two problems. It pins an exact source line, so vp fmt wrapping the attribute (one more tone, or a longer expression crossing print width) fails the guard for a formatting reason; and a behaviour-preserving refactor — const sendTone = stageBackdropVariant ? … — fails it too. Compare the sibling guards in this file, which match structure via regex.

More importantly, the guards don't cover the thing that actually broke. Both CSS assertions match on [data-fork-composer-action="send"][data-fork-composer-send-tone="flat"] without anchoring to the :root[data-fork=…]…dark prefix, so they pass identically whether or not the rule is dark-scoped — which is precisely why the light-mode regression landed green. If you take the .dark fix, extend the regex to require it, the way forkSurfacePalette.test.ts anchors on MARKER.

🟡 The CSS comment's rationale doesn't describe what the rule does

"the attribute is set from ComposerPrimaryActions so a missing art wrapper cannot silently leave the release button on upstream's primary purple"

StageBackdropButtonArt only renders when stageBackdropVariant is truthy — i.e. exactly when tone is "channel". A missing art wrapper is not a failure mode the flat rule can be reached by. What the CSS genuinely protects against is an upstream sync reverting the className ternary while the fenced fork:begin/fork:end attribute survives. That's a good reason; it's just not the one written down. In a manifest-driven fork where the prose is load-bearing, an inaccurate rationale is a real defect.

🟡 No pressed affordance on the flat button

Channel keeps enabled:hover:brightness-110 plus both inset shadows. Flat pins the background on hover and zeroes the shadow, leaving hover:scale-105 as the only feedback and nothing at all on :active. Plausibly intended ("flat"), but it's an interaction change riding along with a colour change and isn't mentioned in the description — please confirm it's deliberate.

---

Verification

• All four boxes in the test plan are unchecked, including vp test run apps/web/src/__fork_guards__/forkComposerShell.test.ts — the test this PR adds. CLAUDE.md also requires an integrated web pass via the test-t3-app skill for user-visible frontend changes; nothing here indicates one ran. Given the blocker is only visible when you actually look at the button in light mode, that gap is the proximate cause.
• I could not run the suite in this environment (deps unresolved — vite-plus, @tailwindcss/vite). I executed the three new assertions' regexes directly against the working tree instead: all three pass. The guard is internally sound; it just doesn't assert the scope that matters.
• Manifest hygiene is correct — ComposerPrimaryActions.tsx is already under watch: and the guard under verify:. No change needed there.

Heads-up

#23 is open against the same base SHA and touches the same three files (theme.custom.css, forkComposerShell.test.ts, customizations.yaml) in different hunks. Should auto-merge, but whichever lands second is worth re-running the full guard file on rather than trusting the merge.

---

Suggested shape

1. Add .dark to both new selectors. (blocking)
2. Revert the whole className hunk; keep only the data-fork-composer-send-tone attribute.
3. Drop the redundant :hover:enabled rule.
4. Anchor both CSS guard regexes on the dark-scoped marker prefix, and match the attribute structurally instead of by exact source text.
5. Reword the manifest intent and the CSS comment to state the invariant that's actually enforced.
6. Run the guard, and look at the composer in both themes on a release build.

Items 1 and 2 together shrink this to roughly a four-line CSS block plus a one-line attribute — which is the change the fork's rules ask for.

---

Generated by Claude Code

[NoahHendrickson]

Re-review @ 5c1118c

Two commits landed after my pass. Checked the delta rather than repeating the whole review.

✅ Fixed

• The :hover:enabled twin rule is gone. Verified: no send-tone="flat"]:hover rule remains.
• The duplicated bg-white text-black hover:bg-white utilities are gone — CSS is now the single paint owner, and the comment says so explicitly ("Unlayered, so this beats any leftover Tailwind fill utilities without a hover twin"). That's the right mechanism, correctly explained.

🔴 Blocker unchanged — still not .dark-scoped

5c1118c did not touch the scope. Confirmed against the current head:

dark-scoped flat rule? → false

The rule is still :root[data-fork="noahhendrickson-t3code"] [data-fork-composer-action="send"][…="flat"]. Light-mode release still paints #ffffff on a #ffffff card with box-shadow: none. This is the one item that has to move before merge, and it's still a one-token change.

🔴 New — 5c1118c deleted the upstream fallback instead of keeping it

The flat branch is now:

: "shadow-none",

I asked to drop the fork's duplicated white/black classes and let the ternary keep returning upstream's bg-primary/90 enabled:shadow-primary/24 hover:bg-primary. What happened instead is that all nine remaining utilities came off the flat branch, including every background and text-colour utility. Counting the flat union: 27 utilities before this PR → 19 now.

So the send button now has no fill declared anywhere except the fork stylesheet. If that rule ever fails to match — a marker regression, a selector renamed by a sync, a harness that renders the component without main.tsx:34 — the release send button is fully transparent with an inherited text colour. Before this PR the same failure landed on upstream purple: visibly wrong, but visible. This directly inverts theme.custom.css:40-45, which is the file's own contract: "An unmarked build never sets these, so it falls through to upstream's fallbacks." There is no fallback left to fall through to.

Restoring bg-primary/90 enabled:shadow-primary/24 hover:bg-primary on that branch costs nothing — the unlayered CSS still wins on every real render, exactly as the new comment says.

While there: "shadow-none" is itself dead. The base string no longer carries any shadow utility (that moved to the channel branch in d44095a), and the CSS sets box-shadow: none regardless. It's overriding nothing.

🟡 Still open from the first pass

• Base-class churn. Unaddressed. I re-diffed at 5c1118c: base + channel is still exactly the same 27 utilities as before the PR, so Dev/Nightly remains byte-for-byte identical — which is precisely why rewriting both arms of a ternary in a watch: file still buys nothing but upstream conflict surface.
• Guard asserts source text, not behaviour. 2b32f0e is that fragility, demonstrated: vp fmt rewrapped the assertion and it needed its own commit to get green again. The literal toContain is unchanged, so the next formatting shift does it again.
• Guards don't anchor the dark scope. I ran all three new assertions against 5c1118c: attr: true, bg: true, color: true. All green, blocker present. That's the mechanism keeping this defect invisible to CI, and it's the reason the .dark fix needs a matching guard change rather than just a CSS edit.
• "flat" still means "not dev/nightly". Manifest prose at customizations.yaml:618 still asserts "On a release build".
• No pressed affordance. Now more so — the flat branch carries no state styling of any kind.

One correction to my own comment

The CSS rationale I flagged as inaccurate has gotten further from the code, not closer. It still reads "a missing art wrapper cannot silently leave the release button on upstream's primary purple" — but 5c1118c removed bg-primary/90, so there is no primary purple anywhere on this button any more. The sentence now describes a fallback that no longer exists in either direction.

Minimal path to merge

1. Add .dark to the flat selector. (blocking)
2. Put bg-primary/90 enabled:shadow-primary/24 hover:bg-primary back on the flat branch and drop shadow-none. (blocking — regression introduced in 5c1118c)
3. Anchor the two CSS guard regexes on the dark-scoped marker prefix, so 1 can't silently regress.
4. Revert the base-class hoist in d44095a.
5. Reword the CSS comment and manifest intent to match what the code enforces.
6. Look at the composer in both themes on a release build — none of the four test-plan boxes are checked yet.

---

Generated by Claude Code

[NoahHendrickson]

Re-review blockers addressed @ 9548cdb

All six items from the re-review's minimal path:

1. .dark added to the flat selector — light builds fall through to upstream's fill.
2. Upstream fallback restored — the className hoist from d44095a is reverted wholesale: base string and both ternary arms are byte-identical to pre-PR upstream, so the flat branch carries bg-primary/90 enabled:shadow-primary/24 hover:bg-primary again and dead shadow-none is gone. The only remaining TSX delta is the fenced tone attribute line.
3. Guard regexes anchor the dark-scoped marker prefix (:root[data-fork="…"].dark …), and the attribute assertion is now a whitespace-tolerant structural regex instead of a source-text toContain.
4. Base-class churn reverted (same change as 2).
5. CSS comment and manifest intent reworded to the enforced invariant: tone="flat" means no stage-channel art (any label that isn't Dev/Nightly), dark mode only; light keeps upstream.

Integrated verification (test-t3-app, isolated env on the combined tree of PRs 22–25)

• Dev build, dark: send renders tone="channel", transparent fill with stage art — byte-identical path, confirmed live.
• Flat tone, dark (attribute forced to flat to simulate release): computed background: rgb(255,255,255), color: rgb(0,0,0), box-shadow: none.
• Flat tone, light (emulated prefers-color-scheme: light): the flat rule no longer matches (el.matches(sel) === false) — light keeps upstream's fill via the restored classes.
• Guard suite: forkComposerShell 25/25; full fork-guard + custom suite on the combined tree: 166/166.

Stop button untouched (guard still pins #ea3150).