💭 Looking at the diff, I see it's adding html.dark[data-theme-id] as a selector alongside html[data-theme-id]. This is a raw .dark usage, which according to the rules should only appear in the custom-variant definitions for dark and light, not in theme-only declarations that should use @variant dark instead. I need to check the context in index.css to understand if this is creating a duplicate selector branch or if there's a specific reason for this pattern. The PR is adding a duplicate selector with higher specificity to ensure theme tokens override dark-mode declarations elsewhere in the stylesheet. By including html.dark[data-theme-id] alongside the existing selector, each gets evaluated independently by the browser, but the higher specificity (0,3,1 vs 0,2,1) makes the theme block win when both match. However, the instructions say raw .dark should only appear in the custom-variant definitions, so this usage violates that rule—a dark-only branch should use @variant dark instead. But that approach wouldn't produce the same specificity boost, so I need to check how the custom variant is actually defined to understand if there's a better way to achieve this. Looking at the PR description to understand what's happening — it seems the dark mode variant is overriding the selected theme tokens due to CSS specificity or ordering. The @variant dark block generates selectors with specificity that's taking precedence over the theme values, so I need to trace through how the dark variant is being applied at the root level and why it's interfering with theme selection. I'm seeing the specificity issue now — in dark mode, the :root:is(.dark, .dark *) selector has specificity (0,2,0) because :root is (0,1,0) and :is() takes the highest of its arguments at (0,1,0), while html[data-theme-id] only has (0,1,1), so the dark variant wins out and overrides the theme attribute. The proposed fix adds html.dark[data-theme-id] with specificity (0,2,1) to outrank the dark variant, which does solve the specificity problem. But I'm noticing a few concerns: the change introduces a raw .dark selector outside of the variant definitions, which violates the project's convention that raw .dark should only appear in the dark and light custom-variant blocks. There's also a semantic question — does the app actually apply the .dark class to the html element itself, or is it applied elsewhere? And more fundamentally, this feels like a specificity hack rather than a proper solution; the cleaner approach would be to use @variant dark inside the block for dark overrides or handle specificity in a way that aligns with the project's variant conventions. Actually, I'm reconsidering — using html[data-theme-id]:root instead would give (0,2,1) specificity without any raw .dark, which beats the light mode declarations and stays consistent with the project's conventions. That's a smaller, cleaner fix. Now I'm checking whether there's a cascade layer issue — the :root block at line 1011 appears to be top-level, outside any @layer declarations, and same with the html[data-theme-id] block at 1172, so specificity alone determines which wins. That's fine. But I need to verify that the .dark class is actually being applied to the <html> element, and whether data-theme-id is set on the document root. I'm also wondering if there's a light variant that could create the opposite problem — in light mode, the theme block would drop to (0,1,1) specificity and lose to any root-level light variant declarations. The .dark class is applied to the <html> element, and the selector html.dark[data-theme-id] matches as expected. Now I'm checking whether this fix actually resolves the regression—in Tailwind 4, the @variant dark on :root expands to :root:is(.dark, .dark *), and since the & ampersand represents :root, the specificity comes down to :root at 0,1,0 plus the :is() pseudo-class which takes the maximum specificity of its arguments. The .dark * selector has specificity 0,1,0, so the total is 0,2,0. Meanwhile, html[data-theme-id] has specificity 0,1,1, which means the theme selector wins and breaks dark mode styling. The bug is confirmed. Looking at whether the PR's fix violates the project's rules: the guidelines explicitly state that raw .dark should only appear in the custom variant definitions, and the added html.dark[data-theme-id] is a raw .dark outside those definitions. While one could argue the rule about theme-only declarations doesn't strictly apply here since these declarations are mode-agnostic, the absolute statement about where raw .dark belongs is clearly violated. There's also a potential functional gap—the fix only addresses specificity but may not fully resolve the underlying issue. I'm checking whether the light-side is handled and whether the specificity bump is sufficient against other dark overrides. The [data-app-sidebar] variant dark selector has lower specificity than the html selector, so that's not a conflict. But I'm wondering if something changed recently that broke this, or if there's a pre-existing mechanism that made it work before—maybe the theme block was previously inside a layer or positioned differently in the cascade. Looking at how Tailwind v4 handles nested @variant dark inside plain CSS rules, it emits the :root block followed by the :root:is(.dark, .dark *) variant block, which is where the specificity issue arises. The real problem is that raw .dark selector violates the style guide's preference for source-level logic over clever selectors, though the emitted selector itself is valid. I'm also considering whether the fix is complete and whether there are edge cases where the dark class gets applied to subtrees—like a theme preview component in settings that uses a .dark wrapper div to preview dark mode styling. Since :root can't be a descendant, that wouldn't match, but something like [data-app-sidebar]:is(.dark *) could potentially be affected. The real question is whether to duplicate the selector as a maintenance concern. I could use html[data-theme-id]:root to get a specificity of 0,2,1, which would beat the raw .dark rule without relying on source order. But :root[data-theme-id] ties at 0,2,0 with the :root:is(.dark,...) variant, so it would depend on which comes later in the file—that feels fragile. The CSS selector list applies each selector's specificity independently, so the dark variant declarations land at (0,2,1) correctly. The theme block only overrides tokens it explicitly sets, leaving others like --info-foreground to inherit from the dark block—that's fine. I need to verify the fix doesn't break nested variants like when @variant dark is used inside a scoped selector, which would emit a compound selector with :is(). The raw .dark selector violates the project's theme-variant convention, so I should flag this as a concrete finding and suggest bumping specificity without using raw .dark while adding a comment explaining why. A reviewer might push back asking if @variant dark would work, but that requires duplicating declarations, so the most idiomatic fix within the project's patterns is a different approach. Let me check if there's precedent in the codebase for raising specificity — I'll search for :root usage and any existing raw .dark selectors in the web CSS outside of variant definitions to see how the project typically handles this. So the .dark class being added here is the only raw instance outside the custom-variant definitions in the web CSS, which directly violates the project's convention. I need to figure out if this is actually necessary or if there's a different root cause—maybe the dark tokens in :root were supposed to work differently, or perhaps the html[data-theme-id] selector had different behavior in dark mode previously. Let me trace through the git history to see how this was handled before. The real issue comes down to specificity: the :root @variant dark block needs higher specificity to override the theme tokens for descendants without resorting to a raw .dark selector. I'll post an inline comment suggesting we replace those lines with html[data-theme-id]:root instead, which raises the specificity appropriately while keeping the comment explaining why this approach works. This is a genuine convention violation—the project keeps .dark only in custom-variant definitions, so having it duplicated here as a specificity hack is undocumented and inconsistent. I'll fail the check with this finding and post the review.

1. modify_pr — One finding: the dark-mode fix introduces a raw .dark selector outside the dark/light custom-variant definitions. Suggested a variant-safe specificity bump that keeps the same behavior.