Open
Conversation
Co-authored-by: sethmcknight <7377802+sethmcknight@users.noreply.github.com>
Co-authored-by: sethmcknight <7377802+sethmcknight@users.noreply.github.com>
…ing the base theme (palette/typography), then applying component overrides. - Fixed a crash caused by accessing `typography.weight.regular` before it was defined in the theme.
There was a problem hiding this comment.
Pull request overview
This PR adds dark mode support to the MUI theme configuration, implementing dynamic color palette switching based on system preferences with manual toggle capability.
Changes:
- Added brand color constants and dark mode palette configuration to theme
- Created ColorModeContext and ThemeProviderWithDarkMode component for dynamic theme switching
- Updated CSS baseline overrides to apply theme colors to html/body/h1 elements
- Updated hardcoded colors in sidebar and dashboard to be theme-aware
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| src/theme/palette.ts | Added brandColors constants and dark mode palette configuration; changed Role type to string |
| src/theme/overrides.ts | Added CSS baseline overrides for html, body, and h1 elements with theme colors |
| src/scenes/Root/Sidebar/sidebar.theme.ts | Updated sidebar paper background color reference |
| src/scenes/Dashboard/DashboardLayout.tsx | Made dashboard header background color theme-aware using palette.mode check |
| src/App.tsx | Added ColorModeContext, ThemeProviderWithDarkMode component, and system dark mode detection |
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a system-aware dark-mode ThemeProvider with a public ColorModeContext toggle, a new brandColors palette and palette typings, makes CssBaseline overrides theme-aware, and updates layout/components to use the new theme values. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (3)
src/theme/palette.ts (1)
10-23: ExportbrandColorsto eliminate the hard-coded duplicate insidebar.theme.ts.
sidebar.theme.tsline 13 hard-codes'#636466'which is identical tobrandColors.darkGray. Exporting the object keeps the two files in sync if a brand color ever changes.♻️ Proposed change
-const brandColors = { +export const brandColors = {Then in
sidebar.theme.ts:+import { brandColors } from '../../../theme/palette'; ... - paper: '#636466', // Dark Gray from Seed Company brand colors + paper: brandColors.darkGray, // Dark Gray from Seed Company brand colors🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 10 - 23, Export the existing brandColors object (e.g., add an export for brandColors) so it can be reused, then update the consumer that currently hard-codes '#636466' to import brandColors and reference brandColors.darkGray instead; specifically, ensure the symbol brandColors is exported from palette.ts and replace the literal '#636466' in the sidebar theme with the imported brandColors.darkGray to keep colors in sync.src/scenes/Root/Sidebar/sidebar.theme.ts (1)
7-14: Thepaperoverride is redundant and duplicates the brand colour.
createTheme({ dark: true })already setspalette.background.papertobrandColors.darkGray(#636466) viacreatePalette. The explicit override here sets it to the same string, so it has no effect. Two options:
- Remove the override entirely (cleanest — relies on
basealready having the correct value).- Import
brandColorsonce it is exported (see palette.ts comment), which removes the hard-coded duplicate and makes future brand colour changes safe.♻️ Option 1 — remove the redundant override
palette: { ...base.palette, - background: { - ...base.palette.background, - paper: '#636466', // Dark Gray from Seed Company brand colors - }, },♻️ Option 2 — use exported brandColors
+import { brandColors } from '../../../theme/palette'; ... paper: brandColors.darkGray, // Dark Gray from Seed Company brand colors🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/scenes/Root/Sidebar/sidebar.theme.ts` around lines 7 - 14, The explicit paper override in sidebarTheme (inside createMuiTheme call) duplicates the brand color already set by base (via createPalette), so remove the redundant background.paper property from the palette in sidebarTheme; alternatively, if you prefer an explicit value, import the exported brandColors and set palette.background.paper to brandColors.darkGray instead of the hard-coded '#636466' (change references in sidebarTheme and ensure no duplicate hard-coded strings remain).src/scenes/Dashboard/DashboardLayout.tsx (1)
21-26:sxordering: appearance style precedes layout/control styles.Per project guidelines, control styles should appear before appearance styles.
backgroundColoris appearance;pandborderRadiusare layout/shape and should come first.♻️ Proposed reorder
sx={{ + p: 4, + borderRadius: 1, backgroundColor: (theme) => theme.palette.mode === 'dark' ? theme.palette.grey[800] : '#E3F0F4', - p: 4, - borderRadius: 1, }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/scenes/Dashboard/DashboardLayout.tsx` around lines 21 - 26, The sx object in DashboardLayout (the sx prop setting backgroundColor, p, borderRadius) has appearance styles before layout/control styles; reorder so control/layout styles (p and borderRadius) appear before appearance styles (backgroundColor). Update the sx property in DashboardLayout.tsx to place p and borderRadius first, then backgroundColor (keeping the theme-based function for backgroundColor intact).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/App.tsx`:
- Around line 60-62: The current useEffect that calls setMode(prefersDarkMode ?
'dark' : 'light') unconditionally overrides a user's manual toggle whenever the
OS preference changes; change this by tracking user intent (e.g., add a boolean
like userHasPreference or userSelectedMode) and only apply prefersDarkMode when
the user has not made a manual choice (or only initialize mode from
prefersDarkMode once on mount). Update the logic around setMode, prefersDarkMode
and the useEffect so that changes to prefersDarkMode do not call setMode if
userHasPreference is true (or remove the effect and set initial state from
prefersDarkMode), ensuring manual toggles persist and preventing the FOUC.
- Around line 54-62: The current useEffect causes a flash-of-unstyled-content
because useState('light') renders before the effect updates for dark users;
replace the useEffect with a synchronous layout-style effect by using a
useIsomorphicLayoutEffect helper (maps to useLayoutEffect on the client and
useEffect on the server) and call setMode(prefersDarkMode ? 'dark' : 'light')
inside it; create/import useIsomorphicLayoutEffect, swap the hook where you
currently reference useEffect, and add a short inline comment near
prefersDarkMode/useMediaQuery explaining the SSR trade-off and why noSsr: true
is used.
In `@src/scenes/Dashboard/DashboardLayout.tsx`:
- Around line 22-23: The backgroundColor in DashboardLayout uses a magic hex
'#E3F0F4' and an inconsistent dark-mode value theme.palette.grey[800]; replace
the magic hex with a commented constant (or add an inline comment) explaining
its purpose, and swap the dark branch to use the brand palette value
brandColors.darkGray (or theme.palette.background.paper which is already mapped
to brandColors.darkGray) so header styling stays consistent with the rest of the
brand; update the backgroundColor expression in DashboardLayout to reference the
branded color and add the explanatory comment for '#E3F0F4'.
In `@src/theme/palette.ts`:
- Around line 57-62: Fix the stray quote in the Marketing comment (correct `//
'#DCEDC8` to `// `#DCEDC8``) and either remove the light-mode hex annotations next
to each role in the roles object or replace them with dual annotations showing
both light and dark hex values computed from the HSL template (e.g., comment
both hex values for roleLuminance=84 and roleLuminance=32) so the comments
aren’t misleading; then review the dark-mode contrast for role chips by checking
where roleLuminance is set (the roleLuminance variable used by roles) and either
raise the dark-mode luminance to meet WCAG 3:1 contrast or document that role
chips are decorative/non-interactive in the accessible text/color usage notes.
---
Nitpick comments:
In `@src/scenes/Dashboard/DashboardLayout.tsx`:
- Around line 21-26: The sx object in DashboardLayout (the sx prop setting
backgroundColor, p, borderRadius) has appearance styles before layout/control
styles; reorder so control/layout styles (p and borderRadius) appear before
appearance styles (backgroundColor). Update the sx property in
DashboardLayout.tsx to place p and borderRadius first, then backgroundColor
(keeping the theme-based function for backgroundColor intact).
In `@src/scenes/Root/Sidebar/sidebar.theme.ts`:
- Around line 7-14: The explicit paper override in sidebarTheme (inside
createMuiTheme call) duplicates the brand color already set by base (via
createPalette), so remove the redundant background.paper property from the
palette in sidebarTheme; alternatively, if you prefer an explicit value, import
the exported brandColors and set palette.background.paper to
brandColors.darkGray instead of the hard-coded '#636466' (change references in
sidebarTheme and ensure no duplicate hard-coded strings remain).
In `@src/theme/palette.ts`:
- Around line 10-23: Export the existing brandColors object (e.g., add an export
for brandColors) so it can be reused, then update the consumer that currently
hard-codes '#636466' to import brandColors and reference brandColors.darkGray
instead; specifically, ensure the symbol brandColors is exported from palette.ts
and replace the literal '#636466' in the sidebar theme with the imported
brandColors.darkGray to keep colors in sync.
- Convert MainLayout from makeStyles to Box/sx for reactive theme binding - Add GlobalStyles fallback for body background reactivity
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
src/theme/palette.ts (1)
57-62: Dark-mode role chip WCAG contrast still unresolved (roleLuminance = 32)At lightness 32 % on a
#323232background the role chip colours produce a contrast ratio near 2.5 : 1, which is below the WCAG 1.4.11 non-text-contrast threshold of 3 : 1. The annotations now correctly read(light mode), but the underlying luminance value is unchanged.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 57 - 62, The role chip colors use a single roleLuminance (currently 32) which yields ~2.5:1 contrast on the dark background (`#323232`); update the palette so dark-mode role chips meet WCAG non-text-contrast 3:1 by either increasing roleLuminance for dark mode or adding a separate roleLuminanceDark and using it when building the roles object; adjust the values for the roles object (FieldPartner, Translator, ProjectManager, Marketing) or compute them programmatically so the HSL lightness produces ≥3:1 contrast against `#323232` and keep the light-mode annotations as-is.
🧹 Nitpick comments (1)
src/theme/palette.ts (1)
10-23: ExportbrandColorsto enable centralized color reference
src/scenes/Root/Sidebar/sidebar.theme.tshard-codes#636466(line 13), which duplicatesbrandColors.darkGrayfromsrc/theme/palette.ts. ExportingbrandColorsaligns with the guideline to referencesrc/themefor palette colors and eliminates drift risk if brand colors are updated.♻️ Suggested change
-const brandColors = { +export const brandColors = {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 10 - 23, Export the existing brandColors object so other modules can import centralized palette values, then replace the hard-coded '#636466' in the Sidebar theme with an import of brandColors.darkGray; specifically, add an export for brandColors in src/theme/palette.ts and update the Sidebar theme that currently hard-codes '#636466' to import { brandColors } and use brandColors.darkGray to avoid duplicated literals and keep colors centralized.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@src/theme/palette.ts`:
- Around line 57-62: The role chip colors use a single roleLuminance (currently
32) which yields ~2.5:1 contrast on the dark background (`#323232`); update the
palette so dark-mode role chips meet WCAG non-text-contrast 3:1 by either
increasing roleLuminance for dark mode or adding a separate roleLuminanceDark
and using it when building the roles object; adjust the values for the roles
object (FieldPartner, Translator, ProjectManager, Marketing) or compute them
programmatically so the HSL lightness produces ≥3:1 contrast against `#323232` and
keep the light-mode annotations as-is.
---
Nitpick comments:
In `@src/theme/palette.ts`:
- Around line 10-23: Export the existing brandColors object so other modules can
import centralized palette values, then replace the hard-coded '#636466' in the
Sidebar theme with an import of brandColors.darkGray; specifically, add an
export for brandColors in src/theme/palette.ts and update the Sidebar theme that
currently hard-codes '#636466' to import { brandColors } and use
brandColors.darkGray to avoid duplicated literals and keep colors centralized.
ℹ️ Review info
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/App.tsxsrc/scenes/Dashboard/DashboardLayout.tsxsrc/scenes/Root/MainLayout.tsxsrc/scenes/Root/Root.tsxsrc/theme/overrides.tssrc/theme/palette.ts
💤 Files with no reviewable changes (1)
- src/scenes/Root/Root.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- src/App.tsx
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
src/theme/palette.ts (1)
57-61: Role color hex annotations still don’t match current luminance values.These “light mode” hex comments don’t align with the current
roleLuminancelogic and remain misleading. Please update or remove them.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 57 - 61, The inline hex comments for role colors are stale and no longer match the computed values from roleLuminance; update or remove those misleading annotations by either recalculating the correct hex values for FieldPartner, Translator, ProjectManager, Marketing using the current roleLuminance formula and replacing the comments, or delete the “// `#...` (light mode)” comments entirely; locate the roles object in palette.ts (roles, FieldPartner, Translator, ProjectManager, Marketing and roleLuminance) and apply the change consistently for all role entries.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/theme/palette.ts`:
- Line 27: Add a tagged comment explaining why roleLuminance uses 50 for dark
mode and 32 for light mode (e.g., the target contrast ratio or design token
mapping), placing it immediately above the declaration of roleLuminance; use the
required tag format like "// ai tag: roleLuminance contrast target: <brief
reason>" and, if this is an intentional edge-case deviation, also include "// ai
edge-case" on the same or next line so the magic numbers are searchable and
justified.
- Around line 5-23: The inline JSDoc comments for brandColors (the exported
constant brandColors and its keys natural, stone, white, lightGray, darkGray,
black) should be converted to tagged comments using the format "// ai <tag>"
above each property or group and rewritten to state the design rationale (why
the token exists and when to use it) rather than just describing the color hex;
update each comment to explain intended usage context (e.g., "ai background:
default light-mode background to preserve warmth and contrast with primary
text") and keep the tags consistent across all entries so the comments are
searchable by the ai tag.
- Around line 1-3: Change the three imports to type-only imports and switch the
Role path to the path alias; replace the current lines importing PaletteColor,
PaletteColorOptions and PaletteOptions with "import type { PaletteColor,
PaletteColorOptions } from '@mui/material';" and "import type { PaletteOptions }
from '@mui/material/styles';" and replace "import type { Role } from
'../api/schema.graphql';" with "import type { Role } from
'~/api/schema.graphql';" so all three are type-only and the cross-domain import
uses the ~/ alias.
---
Duplicate comments:
In `@src/theme/palette.ts`:
- Around line 57-61: The inline hex comments for role colors are stale and no
longer match the computed values from roleLuminance; update or remove those
misleading annotations by either recalculating the correct hex values for
FieldPartner, Translator, ProjectManager, Marketing using the current
roleLuminance formula and replacing the comments, or delete the “// `#...`
(light mode)” comments entirely; locate the roles object in palette.ts (roles,
FieldPartner, Translator, ProjectManager, Marketing and roleLuminance) and apply
the change consistently for all role entries.
ℹ️ Review info
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/scenes/Root/Sidebar/sidebar.theme.tssrc/theme/palette.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/scenes/Root/Sidebar/sidebar.theme.ts
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (4)
src/theme/palette.ts (4)
1-3:⚠️ Potential issue | 🟡 MinorSwitch these to type-only imports and use the
~/alias forRole.All three are type-only usages, and the Role import is cross-domain.
♻️ Suggested fix
-import { PaletteColor, PaletteColorOptions } from '@mui/material'; -import { PaletteOptions } from '@mui/material/styles'; -import type { Role } from '../api/schema.graphql'; +import type { PaletteColor, PaletteColorOptions } from '@mui/material'; +import type { PaletteOptions } from '@mui/material/styles'; +import type { Role } from '~/api/schema.graphql';As per coding guidelines: “Use
typeimports for type-only references” and “Use path alias~/(maps tosrc/) for cross-domain imports instead of relative paths.”🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 1 - 3, The three imports are only used as types so change them to type-only imports (e.g., use "import type { PaletteColor, PaletteColorOptions } from '@mui/material';" and "import type { PaletteOptions } from '@mui/material/styles';") and replace the cross-domain Role import with the path-alias version (use "import type { Role } from '~/api/schema.graphql';") so all three are declared as type imports and Role uses the ~/ alias.
52-56:⚠️ Potential issue | 🟡 MinorReplace inline role hex comments with a tagged rationale (or remove).
Inline hex comments are untagged and describe what; a single rationale comment is clearer.
♻️ Suggested fix
- roles: { - FieldPartner: { main: `hsl(187deg, 71%, ${roleLuminance}%)` }, // `#B2EBF2` (light mode) - Translator: { main: `hsl(36deg, 100%, ${roleLuminance}%)` }, // `#FFE0B2` (light mode) - ProjectManager: { main: `hsl(291deg, 46%, ${roleLuminance}%)` }, // `#E1BEE7` (light mode) - Marketing: { main: `hsl(88deg, 51%, ${roleLuminance}%)` }, // `#DCEDC8` (light mode) - }, + roles: { + // ai design-alignment: Preserve role hue semantics; luminance controlled by roleLuminance per mode. + FieldPartner: { main: `hsl(187deg, 71%, ${roleLuminance}%)` }, + Translator: { main: `hsl(36deg, 100%, ${roleLuminance}%)` }, + ProjectManager: { main: `hsl(291deg, 46%, ${roleLuminance}%)` }, + Marketing: { main: `hsl(88deg, 51%, ${roleLuminance}%)` }, + },As per coding guidelines: “Use tagged comments
// ai tagfor code searchability” and “Comments should explain why, not what.”🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 52 - 56, Replace the untagged inline hex comments next to the role color entries in the roles object (FieldPartner, Translator, ProjectManager, Marketing) with a single tagged rationale comment or remove them; use a searchable tag like "// ai rationale:" placed above the roles block to explain why HSL with roleLuminance is used (e.g., consistency across themes or accessibility goal) rather than repeating hex values for each entry, and ensure the comment references roleLuminance to clarify the design intent.
5-17:⚠️ Potential issue | 🟡 MinorTag the brand color docs and state why these tokens exist.
Current comments are untagged and describe what, not the rationale/usage intent.
♻️ Example update (apply consistently)
-export const brandColors = { - // `#F7F1E7` - Light beige used for light mode default background - natural: '#F7F1E7', +export const brandColors = { + // ai design-alignment: Default light-mode background to preserve warmth/contrast. + natural: '#F7F1E7',As per coding guidelines: “Use tagged comments
// ai tagfor code searchability” and “Comments should explain why, not what.”🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 5 - 17, Update the comments for the exported brandColors object to use the required tagged comment format and explain the rationale/usage (why these tokens exist) rather than just what they are: add a leading tag like “// ai color-token” (or the project’s preferred tag) above each token or the object and replace descriptive-only text with concise intent statements (e.g., "used as default light-mode background to ensure warm brand feel", "used for secondary text in dark mode to maintain contrast", etc.) referencing the brandColors object and the specific keys natural, stone, white, lightGray, darkGray, black so search tools can find them and developers know the usage intent. Ensure tags are consistent and follow the project's comment/tagging guideline.
22-22:⚠️ Potential issue | 🟡 MinorDocument the
roleLuminancemagic numbers with a tagged rationale.50/32 are unexplained and should note the contrast/visual target.
♻️ Suggested fix
- const roleLuminance = dark ? 50 : 32; + // ai design-alignment: role chip luminance targets for contrast/legibility by mode. + // ai edge-case: keep 50/32 unless contrast testing indicates adjustments. + const roleLuminance = dark ? 50 : 32;As per coding guidelines: “Comment if using magic numbers/colors/fonts. Use
// ai edge-casefor justified deviations” and “Use tagged comments// ai tagfor code searchability.”🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` at line 22, Add a tagged rationale comment for the magic numbers used in the roleLuminance constant: document why roleLuminance = dark ? 50 : 32 (e.g., these luminance values were chosen to hit the target contrast ratio for role/background colors, such as ~4.5:1 for UI text) and prepend the comment with the required tags so it is searchable and justified (use something like “// ai tag: roleLuminance” and “// ai edge-case: chosen to meet [contrast target]” directly above the roleLuminance declaration).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@src/theme/palette.ts`:
- Around line 1-3: The three imports are only used as types so change them to
type-only imports (e.g., use "import type { PaletteColor, PaletteColorOptions }
from '@mui/material';" and "import type { PaletteOptions } from
'@mui/material/styles';") and replace the cross-domain Role import with the
path-alias version (use "import type { Role } from '~/api/schema.graphql';") so
all three are declared as type imports and Role uses the ~/ alias.
- Around line 52-56: Replace the untagged inline hex comments next to the role
color entries in the roles object (FieldPartner, Translator, ProjectManager,
Marketing) with a single tagged rationale comment or remove them; use a
searchable tag like "// ai rationale:" placed above the roles block to explain
why HSL with roleLuminance is used (e.g., consistency across themes or
accessibility goal) rather than repeating hex values for each entry, and ensure
the comment references roleLuminance to clarify the design intent.
- Around line 5-17: Update the comments for the exported brandColors object to
use the required tagged comment format and explain the rationale/usage (why
these tokens exist) rather than just what they are: add a leading tag like “//
ai color-token” (or the project’s preferred tag) above each token or the object
and replace descriptive-only text with concise intent statements (e.g., "used as
default light-mode background to ensure warm brand feel", "used for secondary
text in dark mode to maintain contrast", etc.) referencing the brandColors
object and the specific keys natural, stone, white, lightGray, darkGray, black
so search tools can find them and developers know the usage intent. Ensure tags
are consistent and follow the project's comment/tagging guideline.
- Line 22: Add a tagged rationale comment for the magic numbers used in the
roleLuminance constant: document why roleLuminance = dark ? 50 : 32 (e.g., these
luminance values were chosen to hit the target contrast ratio for
role/background colors, such as ~4.5:1 for UI text) and prepend the comment with
the required tags so it is searchable and justified (use something like “// ai
tag: roleLuminance” and “// ai edge-case: chosen to meet [contrast target]”
directly above the roleLuminance declaration).
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (3)
src/theme/palette.ts (3)
54-57:⚠️ Potential issue | 🟡 MinorInline role hex comments are misleading in dark mode.
roleLuminanceis dynamic, but these comments only reflect light-mode hex values. Please remove them or annotate both light/dark values with tagged rationale.♻️ Minimal fix (remove misleading comments)
- FieldPartner: { main: `hsl(187deg, 71%, ${roleLuminance}%)` }, // `#B2EBF2` (light mode) - Translator: { main: `hsl(36deg, 100%, ${roleLuminance}%)` }, // `#FFE0B2` (light mode) - ProjectManager: { main: `hsl(291deg, 46%, ${roleLuminance}%)` }, // `#E1BEE7` (light mode) - Marketing: { main: `hsl(88deg, 51%, ${roleLuminance}%)` }, // `#DCEDC8` (light mode) + FieldPartner: { main: `hsl(187deg, 71%, ${roleLuminance}%)` }, + Translator: { main: `hsl(36deg, 100%, ${roleLuminance}%)` }, + ProjectManager: { main: `hsl(291deg, 46%, ${roleLuminance}%)` }, + Marketing: { main: `hsl(88deg, 51%, ${roleLuminance}%)` },As per coding guidelines: Use tagged comments
// ai tagfor code searchability; Comments should explain why, not what.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 54 - 57, The inline hex comments next to the role color defs (FieldPartner, Translator, ProjectManager, Marketing) are misleading because roleLuminance is dynamic; remove those static light-mode hex comments or replace them with a single tagged explanatory comment (use "// ai" tag) near the roleLuminance usage describing that colors are computed dynamically for light/dark modes and, if desired, list both light and dark example hex values with rationale; update the lines referencing roleLuminance (FieldPartner, Translator, ProjectManager, Marketing) accordingly to either drop the inline hex or reference the new tagged comment.
5-17:⚠️ Potential issue | 🟡 MinorConvert brand color comments to tagged, rationale-focused notes.
These comments are untagged and describe what the colors are instead of why they exist. Please switch to
// ai <tag>and capture design intent/usage rationale.♻️ Example update (apply consistently)
- // `#F7F1E7` - Light beige used for light mode default background + // ai design-alignment: Default light-mode background to preserve warmth and readability. natural: '#F7F1E7',As per coding guidelines: Use tagged comments
// ai tagfor code searchability; Comments should explain why, not what.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 5 - 17, The inline color descriptions on the brandColors object are currently untagged and describe what the hex values are; replace each comment with a tagged, rationale-focused note using the pattern "// ai rationale" (or similar consistent tag) and for each key (natural, stone, white, lightGray, darkGray, black) capture the design intent and usage (e.g., "ai rationale: light background for bright/airy top-level surfaces in light mode to increase warmth", "ai rationale: secondary/low-contrast text in dark mode to preserve hierarchy", "ai rationale: paper/background contrast token for elevation", etc.), keeping comments short, focused on why the color exists and where it must be used rather than restating the hex or color name, and apply the same tag and tone consistently for all entries in brandColors.
22-23:⚠️ Potential issue | 🟡 MinorDocument the roleLuminance rationale and tag it.
Line 23 uses magic numbers (50/32) without a tagged rationale. Please add a
// ai <tag>comment that explains the contrast or design target behind these values.♻️ Example update
- // Using HSL allows us to easily adjust the lightness for dark and light modes while keeping the hue and saturation consistent. + // ai design-alignment: role luminance tuned for contrast balance across light/dark surfaces. + // ai edge-case: values chosen from design review to avoid low-contrast role chips. const roleLuminance = dark ? 50 : 32;As per coding guidelines: Comment if using magic numbers/colors/fonts; Use tagged comments
// ai tagfor code searchability.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/theme/palette.ts` around lines 22 - 23, The const roleLuminance = dark ? 50 : 32 uses unexplained "magic" luminance values; add a tagged inline comment (// ai <tag>) next to that line explaining the design/contrast target those numbers satisfy (e.g., target WCAG contrast ratio or visual role purpose and why dark mode uses 50 vs light mode 32), referencing the roleLuminance and dark variables so future readers can find the rationale.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@src/theme/palette.ts`:
- Around line 54-57: The inline hex comments next to the role color defs
(FieldPartner, Translator, ProjectManager, Marketing) are misleading because
roleLuminance is dynamic; remove those static light-mode hex comments or replace
them with a single tagged explanatory comment (use "// ai" tag) near the
roleLuminance usage describing that colors are computed dynamically for
light/dark modes and, if desired, list both light and dark example hex values
with rationale; update the lines referencing roleLuminance (FieldPartner,
Translator, ProjectManager, Marketing) accordingly to either drop the inline hex
or reference the new tagged comment.
- Around line 5-17: The inline color descriptions on the brandColors object are
currently untagged and describe what the hex values are; replace each comment
with a tagged, rationale-focused note using the pattern "// ai rationale" (or
similar consistent tag) and for each key (natural, stone, white, lightGray,
darkGray, black) capture the design intent and usage (e.g., "ai rationale: light
background for bright/airy top-level surfaces in light mode to increase warmth",
"ai rationale: secondary/low-contrast text in dark mode to preserve hierarchy",
"ai rationale: paper/background contrast token for elevation", etc.), keeping
comments short, focused on why the color exists and where it must be used rather
than restating the hex or color name, and apply the same tag and tone
consistently for all entries in brandColors.
- Around line 22-23: The const roleLuminance = dark ? 50 : 32 uses unexplained
"magic" luminance values; add a tagged inline comment (// ai <tag>) next to that
line explaining the design/contrast target those numbers satisfy (e.g., target
WCAG contrast ratio or visual role purpose and why dark mode uses 50 vs light
mode 32), referencing the roleLuminance and dark variables so future readers can
find the rationale.
…dark and light modes
…t was there originally
rdonigian
reviewed
Mar 4, 2026
- Fixed headings that weren't updating when dark mode was enabled
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Finally got Dark Mode wired into the MUI theme. It handles dynamic switching now.
What changed:
Testing:
[x]
yarn cipassed locally.