Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds a frontend global settings composable (theme + language) with localStorage persistence and t(...) translations, tokenized light/dark CSS variables, a consolidated Header User Profile Menu, plot-driven create flow (canvas dblclick → request-create → TaskDrawer createSeed), and corresponding component/template/style updates and docs. Changes
Sequence Diagram(s)sequenceDiagram
participant User as User
participant Scatter as ScatterPlot
participant Main as MainView
participant Drawer as TaskDrawer
participant Settings as useSettings
User->>Scatter: Double-click canvas
Scatter->>Scatter: compute due (ISO) & motivation
Scatter->>Main: emit request-create(payload)
Main->>Main: set createSeed, set drawer mode 'create', open drawer
Main->>Drawer: pass :create-seed prop
Drawer->>Drawer: applyCreateSeed() → populate form fields
Drawer->>Settings: call t(key) for labels
Settings-->>Drawer: localized strings
Drawer->>User: show create form with pre-filled values
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (7)
apps/frontend/src/components/TaskList.vue (1)
172-175: Consider dark mode compatibility for status pill colors.The status pill backgrounds use hardcoded light-theme colors (
#f1f5f9,#f8fafc). In dark mode, these light backgrounds may clash with the overall theme. Consider using CSS variables or adjusting these styles within a.darkscope if dark mode support is intended.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/components/TaskList.vue` around lines 172 - 175, Replace the hardcoded light-theme colors for the status pill classes (.todo, .inprogress, .done, .backlog) with CSS custom properties (e.g., --status-bg-todo, --status-color-todo, etc.) and provide dark-mode overrides either under a .dark scope or via `@media` (prefers-color-scheme: dark) so the pills pick appropriate background and text colors in dark mode; update the .todo, .inprogress, .done, .backlog rules to reference these variables and add a .dark .todo/.inprogress/.done/.backlog (or prefers-color-scheme) block that sets the dark values.apps/frontend/src/components/Header.vue (2)
168-181:!importantforces white background regardless of theme.The
.version-badgebackground is forced to#ffffff !important, which prevents dark mode from applying an appropriate background. If the white background is needed for gradient text contrast, consider using a theme-aware variable with sufficient contrast in both modes, or scoping this override.♻️ Suggested approach
.version-badge { border-radius: 9999px; - border: 1px solid `#e2e8f0`; - background-color: `#ffffff` !important; + border: 1px solid var(--tg-border-default); + background-color: var(--bg-primary); padding: 0.25rem 0.75rem;If white is essential for gradient text legibility, consider keeping the white background explicitly for both themes as a design decision, but remove
!importantand use a more specific selector if needed.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/components/Header.vue` around lines 168 - 181, The .version-badge rule currently forces background-color: `#ffffff` !important which breaks dark mode; remove the !important and replace the hard-coded color with a theme-aware CSS variable (e.g., --badge-bg) or a more specific selector so dark-mode styles can override it, or scope the white background to only the light-theme class while keeping the selector specificity for the gradient text requirement; update both .version-badge and .version-badge:hover to use the variable/specific selector so contrast is preserved across themes.
342-344: Hardcoded hover color for logout item.The hover background
#fef2f2is a light red that may not provide adequate contrast in dark mode. Consider using a theme variable or a CSS variable scoped for destructive action hover states.♻️ Suggested fix
.logout-item:hover { - background-color: `#fef2f2`; + background-color: var(--tg-surface-danger, `#fef2f2`); }This allows defining a dark-mode-appropriate danger surface color while falling back to the current value.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/components/Header.vue` around lines 342 - 344, Replace the hardcoded hover color in the .logout-item:hover rule with a theme/CSS variable so dark mode can override it; e.g. use a variable like var(--color-danger-surface-hover, `#fef2f2`) in the .logout-item:hover declaration and ensure the variable is defined in your global/theme styles (and overridden for dark mode) so .logout-item:hover uses the fallback when the variable is not present.apps/frontend/src/components/SpecialThanks.vue (1)
245-253: Minor: Hardcoded border color on.name-chip.The border uses
#dbe3eewhile other borders in this file usevar(--tg-border-default). For consistent dark mode support, consider updating this to use the theme variable as well.♻️ Suggested fix
.name-chip { - border: 1px solid `#dbe3ee`; + border: 1px solid var(--tg-border-default); background: var(--bg-primary);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/components/SpecialThanks.vue` around lines 245 - 253, The .name-chip CSS rule hardcodes the border color (`#dbe3ee`); update the border property in the .name-chip selector to use the theme variable (var(--tg-border-default)) instead so it matches other rules and supports dark mode consistently (locate the .name-chip rule in SpecialThanks.vue and replace the hardcoded color in the border declaration).apps/frontend/src/composables/useSettings.ts (2)
183-201: Consider respecting system color scheme preference for first-time users.When no saved theme exists, the composable defaults to
'light'. Consider detectingprefers-color-scheme: darkfor a better initial experience on dark-mode systems.Detect system preference
function initializeSettings(): void { if (isInitialized.value) return; if (typeof window !== 'undefined') { const savedTheme = window.localStorage.getItem(STORAGE_THEME_KEY); const savedLanguage = window.localStorage.getItem(STORAGE_LANGUAGE_KEY); if (isThemeMode(savedTheme)) { theme.value = savedTheme; + } else if (window.matchMedia?.('(prefers-color-scheme: dark)').matches) { + theme.value = 'dark'; } if (isLanguageCode(savedLanguage)) { language.value = savedLanguage; } } applyThemeClass(theme.value); persistSettings(); isInitialized.value = true; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/composables/useSettings.ts` around lines 183 - 201, The initializeSettings function currently defaults theme to 'light' when no saved theme exists; modify it so that when window is available and window.localStorage returns no valid savedTheme (isThemeMode(savedTheme) false), call window.matchMedia('(prefers-color-scheme: dark)') and if it matches set theme.value = 'dark' (otherwise leave as default), then continue to call applyThemeClass(theme.value) and persistSettings(); keep the existing SSR guard and validation via isThemeMode and refer to STORAGE_THEME_KEY, isThemeMode, theme, applyThemeClass, and persistSettings when making the change.
203-212: Consider applying theme class after updating ref for consistency.In
setTheme, the DOM class is toggled before updatingtheme.value. While this works, it creates a brief inconsistency where the DOM state differs from the reactive state. Updating the ref first would be slightly more predictable, though the practical impact is negligible.Optional: Update ref before DOM
function setTheme(nextTheme: ThemeMode): void { - applyThemeClass(nextTheme); theme.value = nextTheme; + applyThemeClass(nextTheme); persistSettings(); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/composables/useSettings.ts` around lines 203 - 212, In setTheme, update the reactive ref before touching the DOM: assign theme.value = nextTheme first, then call applyThemeClass(nextTheme) and persistSettings(); this ensures the reactive state (theme) reflects the upcoming DOM class change immediately—modify the setTheme function (referencing setTheme, theme.value, applyThemeClass, and persistSettings) to set the ref before applying the class.apps/frontend/src/components/ScatterPlot.vue (1)
165-177: Consider supporting 3-character hex shorthand for robustness.The
brightenHexColorfunction only matches 6-character hex codes (#rrggbb). If any color in the palette uses shorthand (#rgb), it would be returned unchanged.Optional: Support shorthand hex
function brightenHexColor(color: string, amount: number): string { const normalized = color.trim(); - const hexMatch = /^#([0-9a-f]{6})$/i.exec(normalized); - if (!hexMatch) return color; + const hex6Match = /^#([0-9a-f]{6})$/i.exec(normalized); + const hex3Match = /^#([0-9a-f]{3})$/i.exec(normalized); + + let hex: string; + if (hex6Match) { + hex = hex6Match[1] ?? '000000'; + } else if (hex3Match) { + const short = hex3Match[1] ?? '000'; + hex = short[0] + short[0] + short[1] + short[1] + short[2] + short[2]; + } else { + return color; + } - const hex = hexMatch[1] ?? '000000'; const r = Number.parseInt(hex.slice(0, 2), 16);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/components/ScatterPlot.vue` around lines 165 - 177, The brightenHexColor function only handles 6-digit hex and should be extended to accept 3-digit shorthand; update the regex in brightenHexColor to match both /^#([0-9a-f]{6})$/i and /^#([0-9a-f]{3})$/i (or a combined pattern), detect when a 3-char capture is returned, expand it to a 6-char hex by duplicating each nibble (e.g. "abc" -> "aabbcc"), then proceed with the existing parse and brightness adjustment logic so shorthand inputs like "#abc" are correctly brightened.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/frontend/src/components/TaskDrawer.vue`:
- Around line 530-532: The CSS custom properties --bg-primary and --bg-secondary
are missing from the .dark selector causing color-mix() and var() usages in
TaskDrawer.vue to produce invalid/transparent results; add definitions for
--bg-primary and --bg-secondary inside the .dark selector (use the dark-mode
equivalents or copy the :root values adjusted for dark theme) so references like
color-mix(in srgb, var(--bg-primary) ...) and background: var(--bg-secondary)
resolve to valid colors across dark mode.
---
Nitpick comments:
In `@apps/frontend/src/components/Header.vue`:
- Around line 168-181: The .version-badge rule currently forces
background-color: `#ffffff` !important which breaks dark mode; remove the
!important and replace the hard-coded color with a theme-aware CSS variable
(e.g., --badge-bg) or a more specific selector so dark-mode styles can override
it, or scope the white background to only the light-theme class while keeping
the selector specificity for the gradient text requirement; update both
.version-badge and .version-badge:hover to use the variable/specific selector so
contrast is preserved across themes.
- Around line 342-344: Replace the hardcoded hover color in the
.logout-item:hover rule with a theme/CSS variable so dark mode can override it;
e.g. use a variable like var(--color-danger-surface-hover, `#fef2f2`) in the
.logout-item:hover declaration and ensure the variable is defined in your
global/theme styles (and overridden for dark mode) so .logout-item:hover uses
the fallback when the variable is not present.
In `@apps/frontend/src/components/ScatterPlot.vue`:
- Around line 165-177: The brightenHexColor function only handles 6-digit hex
and should be extended to accept 3-digit shorthand; update the regex in
brightenHexColor to match both /^#([0-9a-f]{6})$/i and /^#([0-9a-f]{3})$/i (or a
combined pattern), detect when a 3-char capture is returned, expand it to a
6-char hex by duplicating each nibble (e.g. "abc" -> "aabbcc"), then proceed
with the existing parse and brightness adjustment logic so shorthand inputs like
"#abc" are correctly brightened.
In `@apps/frontend/src/components/SpecialThanks.vue`:
- Around line 245-253: The .name-chip CSS rule hardcodes the border color
(`#dbe3ee`); update the border property in the .name-chip selector to use the
theme variable (var(--tg-border-default)) instead so it matches other rules and
supports dark mode consistently (locate the .name-chip rule in SpecialThanks.vue
and replace the hardcoded color in the border declaration).
In `@apps/frontend/src/components/TaskList.vue`:
- Around line 172-175: Replace the hardcoded light-theme colors for the status
pill classes (.todo, .inprogress, .done, .backlog) with CSS custom properties
(e.g., --status-bg-todo, --status-color-todo, etc.) and provide dark-mode
overrides either under a .dark scope or via `@media` (prefers-color-scheme: dark)
so the pills pick appropriate background and text colors in dark mode; update
the .todo, .inprogress, .done, .backlog rules to reference these variables and
add a .dark .todo/.inprogress/.done/.backlog (or prefers-color-scheme) block
that sets the dark values.
In `@apps/frontend/src/composables/useSettings.ts`:
- Around line 183-201: The initializeSettings function currently defaults theme
to 'light' when no saved theme exists; modify it so that when window is
available and window.localStorage returns no valid savedTheme
(isThemeMode(savedTheme) false), call window.matchMedia('(prefers-color-scheme:
dark)') and if it matches set theme.value = 'dark' (otherwise leave as default),
then continue to call applyThemeClass(theme.value) and persistSettings(); keep
the existing SSR guard and validation via isThemeMode and refer to
STORAGE_THEME_KEY, isThemeMode, theme, applyThemeClass, and persistSettings when
making the change.
- Around line 203-212: In setTheme, update the reactive ref before touching the
DOM: assign theme.value = nextTheme first, then call applyThemeClass(nextTheme)
and persistSettings(); this ensures the reactive state (theme) reflects the
upcoming DOM class change immediately—modify the setTheme function (referencing
setTheme, theme.value, applyThemeClass, and persistSettings) to set the ref
before applying the class.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8cbaf984-9978-45c4-a0f6-8a60ea1ca999
📒 Files selected for processing (13)
apps/backend/API_DOCUMENT.mdapps/desktop/API_DOCUMENT.mdapps/frontend/ARCHITECTURE.mdapps/frontend/src/components/GraphControl.vueapps/frontend/src/components/Header.vueapps/frontend/src/components/ScatterPlot.vueapps/frontend/src/components/SpecialThanks.vueapps/frontend/src/components/TaskDrawer.vueapps/frontend/src/components/TaskList.vueapps/frontend/src/composables/useSettings.tsapps/frontend/src/main.tsapps/frontend/src/style.cssapps/frontend/src/views/MainView.vue
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/frontend/src/components/SpecialThanks.vue (1)
14-19:⚠️ Potential issue | 🟡 MinorExpose the modal as a dialog.
This block opens a visual modal without
role="dialog",aria-modal="true", or a dialog name, so assistive tech won’t announce the modal context when it appears.♿ Proposed fix
- <div class="modal-card"> + <div + class="modal-card" + role="dialog" + aria-modal="true" + :aria-label="t('specialThanks')" + >🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/components/SpecialThanks.vue` around lines 14 - 19, The modal markup in SpecialThanks.vue doesn't expose itself to assistive tech; update the modal container (the div with class "modal-card" inside the v-if="show" block) to include role="dialog" and aria-modal="true", give the heading element (h2 with class "modal-title") an id (e.g. "specialThanksTitle") and add aria-labelledby="specialThanksTitle" on the dialog container (or alternatively add an aria-label on the dialog if you prefer a string). Ensure these attributes are applied to the "modal-card" element so screen readers announce the dialog when show becomes true.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/frontend/src/components/Header.vue`:
- Around line 137-143: The header's high z-index (z-index: 11000) in Header.vue
causes the header/profile menu to sit above TaskDrawer.vue's overlay (z-index:
50); lower or remove the z-index in the header CSS so it is below the drawer
overlay (use a value <50 or inherit/default), and make the same change for the
other header-related CSS blocks referenced (the blocks around lines 220-223 and
281-292) so the header no longer intercepts clicks when the drawer/backdrop is
shown.
- Around line 83-86: The help button (class "help-circle" in Header.vue, click
emits 'show-help') uses title which is unreliable for accessible names; update
the button to provide a real accessible name by adding an aria-label or
aria-labelledby with the translated string (e.g., t('helpTitle')) or include a
visually-hidden span with that text so assistive tech announces it; ensure the
same identifier is used where you reference the translation so the accessible
name remains localized and consistent with the existing
`@click`="emit('show-help')" behavior.
In `@apps/frontend/src/components/SpecialThanks.vue`:
- Around line 31-35: The intro currently concatenates thanksIntroLead + a
hard-coded <strong> chunk + thanksIntroTail which forces English ordering;
change this to a single localized message with interpolation (e.g. replace
thanksIntroLead/thanksIntroTail with one key like thanksIntro that includes a
placeholder such as {programTag}), update the locale JSON entries to place the
{programTag} where each language needs it, and update SpecialThanks.vue to call
t('thanksIntro', { programTag: '<strong>100 program 9th (Spring 2026)</strong>'
}) (rendering safely via v-html or vue-i18n component interpolation) instead of
stitching strings; if useSettings.ts’s t() helper (the lookup-only t()
referenced) doesn’t accept values, modify it to forward interpolation params to
the underlying i18n t() so translations with placeholders work.
In `@apps/frontend/src/components/TaskDrawer.vue`:
- Around line 108-118: The create form is only initialized when mode changes, so
reopening the drawer (open toggling true while mode is already 'create') can
reuse stale seed values; call the existing applyCreateSeed() (and the analogous
initializer used at lines 309-328) whenever the drawer is opened for create
mode: add a watcher or effect on the `open` prop that checks `mode === 'create'`
and invokes applyCreateSeed() to reset createDue and createMotivation (and
mirror the same call for the edit/update initializer referenced at 309-328) so
the form is reinitialized on every open.
- Line 50: The due timestamp is being formatted with toLocaleString() which
falls back to the browser locale; update TaskDrawer.vue to pass the app-selected
locale from useSettings() into toLocaleString() so it uses the in-app language.
Locate the useSettings() call (const { t } = useSettings()) and the places where
dates are formatted with toLocaleString(), and change them to supply the
selected locale (from the settings object returned by useSettings(), e.g.,
settings.locale or t.locale) as the first argument along with the existing
options; apply the same change for the other occurrence around the later
formatting call (~line 435).
---
Outside diff comments:
In `@apps/frontend/src/components/SpecialThanks.vue`:
- Around line 14-19: The modal markup in SpecialThanks.vue doesn't expose itself
to assistive tech; update the modal container (the div with class "modal-card"
inside the v-if="show" block) to include role="dialog" and aria-modal="true",
give the heading element (h2 with class "modal-title") an id (e.g.
"specialThanksTitle") and add aria-labelledby="specialThanksTitle" on the dialog
container (or alternatively add an aria-label on the dialog if you prefer a
string). Ensure these attributes are applied to the "modal-card" element so
screen readers announce the dialog when show becomes true.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1695ed24-341d-48de-aac1-1f2aa1e97b09
📒 Files selected for processing (8)
apps/frontend/README.mdapps/frontend/src/components/Header.vueapps/frontend/src/components/ScatterPlot.vueapps/frontend/src/components/SpecialThanks.vueapps/frontend/src/components/TaskDrawer.vueapps/frontend/src/components/TaskList.vueapps/frontend/src/composables/useSettings.tsapps/frontend/src/style.css
✅ Files skipped from review due to trivial changes (1)
- apps/frontend/README.md
🚧 Files skipped from review as they are similar to previous changes (3)
- apps/frontend/src/composables/useSettings.ts
- apps/frontend/src/style.css
- apps/frontend/src/components/ScatterPlot.vue
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
apps/frontend/src/components/SpecialThanks.vue (1)
68-79: Consider documenting or consolidating the z-index scale.
z-index: 30000is quite high. While this ensures the modal overlays other content, an explicit z-index scale (e.g., via CSS custom properties like--z-modal) helps prevent future stacking conflicts as the app grows.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/components/SpecialThanks.vue` around lines 68 - 79, The modal overlay currently uses a hardcoded z-index (z-index: 30000) in the .modal-overlay rule; replace this with a named CSS custom property (e.g., --z-modal) and use that variable in .modal-overlay, and add a central place (root or a shared variables file/component) where the z-index scale is documented and values like --z-modal, --z-dropdown, etc., are declared so stacking order is explicit and easy to adjust across the app; update any other high z-index usages to reference the same variables for consistency.apps/frontend/src/components/Header.vue (1)
338-345: Tokenize the logout hover state too.
#fef2f2will render the same in dark mode, so this item stops matching the tokenized theme palette used by the rest of the menu.Please switch this hover state to a semantic CSS variable from
apps/frontend/src/style.cssso it adapts with the selected theme.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/frontend/src/components/Header.vue` around lines 338 - 345, The hover background for .logout-item uses a hardcoded color (`#fef2f2`) which breaks theme tokenization; update .logout-item:hover to use the theme semantic CSS variable defined in your global styles (e.g. replace background-color: `#fef2f2` with background-color: var(--bg-danger-hover, `#fef2f2`)) so it follows the tokenized palette from apps/frontend/src/style.css and keeps a fallback to the current color.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/frontend/src/components/Header.vue`:
- Around line 221-236: Long usernames can overflow because the profile flex item
doesn't allow its text to shrink; update the CSS so the flex container and text
can truncate: add min-width: 0 to .profile-menu or .profile-trigger to allow
children to shrink, and add a .username rule (the element that renders
displayUsername) with overflow: hidden; text-overflow: ellipsis; white-space:
nowrap; and a flex rule (e.g., flex: 1 1 auto or flex-shrink: 1) or a sensible
max-width so long names are truncated instead of expanding the header.
- Around line 96-128: The menu currently uses role="menu" but its child buttons
lack role="menuitem" and keyboard handling; update the menu buttons (theme,
language, logout) to include role="menuitem" and tabindex="-1" and change the
sync status element (menu-status) to a non-interactive element that also has
role="menuitem" and tabindex="-1" if it must be in the menu or remove it from
the menu role if it’s purely status text. Add a ref (e.g., ref="menuPanel") to
the container div and implement an onMenuKeydown handler (bound with
`@keydown.stop.prevent`="onMenuKeydown") and logic in the component methods to:
close menu on Escape (calling toggleMenu/closeMenu), move focus to next/previous
menuitem on ArrowDown/ArrowUp (querySelectorAll('[role=\"menuitem\"]')), and
when isMenuOpen becomes true call a focusFirstMenuItem routine to focus the
first menuitem; keep existing handlers toggleTheme, toggleLanguage, handleLogout
unchanged but ensure they can be invoked via Enter/Space as native buttons do.
- Around line 72-77: Replace the non-interactive <div> with a native <button> in
Header.vue for the element with class "version-badge" that currently uses
role="button" and `@click`="emit('show-thanks')"; keep the class and
:title="t('specialThanks')" and the `@click` handler but remove the role and add
type="button" so it doesn't submit forms, ensuring the native button provides
keyboard focus and activation semantics (no tabindex/JS key handling needed).
---
Nitpick comments:
In `@apps/frontend/src/components/Header.vue`:
- Around line 338-345: The hover background for .logout-item uses a hardcoded
color (`#fef2f2`) which breaks theme tokenization; update .logout-item:hover to
use the theme semantic CSS variable defined in your global styles (e.g. replace
background-color: `#fef2f2` with background-color: var(--bg-danger-hover,
`#fef2f2`)) so it follows the tokenized palette from apps/frontend/src/style.css
and keeps a fallback to the current color.
In `@apps/frontend/src/components/SpecialThanks.vue`:
- Around line 68-79: The modal overlay currently uses a hardcoded z-index
(z-index: 30000) in the .modal-overlay rule; replace this with a named CSS
custom property (e.g., --z-modal) and use that variable in .modal-overlay, and
add a central place (root or a shared variables file/component) where the
z-index scale is documented and values like --z-modal, --z-dropdown, etc., are
declared so stacking order is explicit and easy to adjust across the app; update
any other high z-index usages to reference the same variables for consistency.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 44fd9bf1-4363-4851-8db0-986daefe93b1
📒 Files selected for processing (4)
apps/frontend/src/components/Header.vueapps/frontend/src/components/SpecialThanks.vueapps/frontend/src/components/TaskDrawer.vueapps/frontend/src/composables/useSettings.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/frontend/src/composables/useSettings.ts
- apps/frontend/src/components/TaskDrawer.vue
|
close #76 |
close #74
close #75
Summary by CodeRabbit
New Features
Documentation
Style