pixelize-design-library 2.4.1-beta.1 → 2.4.1-beta.2

package/.cursor/modules/account-management/MODULE.md

@@ -22,9 +22,16 @@ Account/admin-facing components: UserDetails, RolesPermission, CustomModulesTabl
 - `surface` reads `background[50]`, never `colors.white` — white is a foreground token and stays white in dark
 - Remaining hex literals are `??` fallbacks, not live values: a hand-built palette may omit rungs (tests `jest.mock` a partial one), so keep the fallback when adding a token read
 - Fixed by design, not palette-following: `avatarColor()`'s `AVATAR_COLORS` (OrgSwitcher — deterministic identity fill seeded by org name, white label on top) and `UpgradeButton`'s `iconColor` default (icon on a gradient fill). Colored fills/foregrounds, not canvas surfaces
-- **OrgSwitcher popover bg bug (same class as the ButtonGroupIcon menu bug in `buttons`):** `PopoverContent` had no `bg=`, so it fell through to Chakra's baseStyle `var(--popper-bg)` — hardcoded to `colors.white`, gated behind Chakra's own `_dark` which this app's palette-swap dark mode never triggers — rendering a white popover in dark mode regardless of theme. Fixed with an explicit `bg={theme.colors.backgroundColor.light}`
+- **OrgSwitcher popover bg bug (same class as the ButtonGroupIcon menu bug in `buttons`):** `PopoverContent` had no `bg=`, so it fell through to Chakra's baseStyle `var(--popper-bg)` — hardcoded to `colors.white`, gated behind Chakra's own `_dark` which this app's palette-swap dark mode never triggers — rendering a white popover in dark mode regardless of theme. Fixed with an explicit `bg={theme.colors.backgroundColor.light}`; now also covered app-wide by the theme-level `Popover` style override (`Theme/chakra/Popover.styles.ts`, overlays module / theme module Wave H)
 - OrgSwitcher trigger border: `borderColor` switched from `gray[200]` to `boxborder?.[800] ?? gray[200]` — it styles a real `<button>`, so its border is a control boundary needing WCAG 1.4.11 (>=3.0 non-text contrast) against any surface up to `muted`, which `gray[200]` failed in dark. Org name/role text switched from `gray[800]`/`gray[500]` to `text[900]`/`text[500]` — mode-adaptive text tokens, the correct choice over mode-invariant gray literals for body text
 - UserDetails avatar initials color: replaced the fixed `primary[600]` rung with `accentTextOnCanvas(colors.primary, avatarBg)` (guarded `colors?.primary ? accentTextOnCanvas(...) : "#4F46E5"` fallback) — picks contrast dynamically against the avatar bg instead of assuming one fixed rung clears AA 4.5 for every brand's dark palette
+- **Avatar badge/container ring bug (theme-level fix):** Chakra's own `Avatar` baseStyle
+  hardcodes the badge/container cutout border to `colors.white` (a ring meant to match the
+  surface the avatar sits on), behind `_dark`, same never-triggered gate as Modal/Menu — every
+  bare `<Avatar>`/`<AvatarBadge>` (used here in `UserDetails`, `OrgSwitcher`,
+  `OrganizationDetails`, plus `NavigationBar`/`Notification`/`SelectSearch` elsewhere) rendered a
+  white ring on the dark canvas. Fixed centrally in `Theme/chakra/Avatar.styles.ts` (registered
+  in `componentStyles.ts`), not per-component.
 - **Modal surface bug (QA-caught, blocking) — 6 action modals:** `AddUserModal`,
   `DeactivateConfirmModal`, `ChangeRoleModal` (UserDetails), `DeleteRoleModal` (RolesPermission),
   `CreateOrgModal`, `DeleteOrgModal` (OrganizationDetails) all rendered a raw Chakra `ModalContent`

package/.cursor/modules/feedback/MODULE.md

@@ -15,6 +15,12 @@ Loading, Skeletons, ProgressBar, Notification, FeedbackForm.
 
 ## Dark mode
 
+- **Skeleton** (`Components/Skeletons/`) — Chakra's own baseStyle hardcodes
+  `--skeleton-start-color`/`--skeleton-end-color` to `gray.100`/`gray.400` behind `_dark`, same
+  never-triggered gate as Modal/Menu (theme module). Fixed centrally in `componentStyles.ts`
+  (`Skeleton` entry, rungs `gray[100]`/`gray[300]`) rather than in `Skeletons.tsx` — a
+  caller-supplied `startColor`/`endColor` prop still wins exactly as before; this only supplies
+  the default the base style already owns.
 - **Notification**: default `bgColor` switched `theme.colors.white` → `theme.colors.background[50]`
   — `white` is a foreground token (label ink, stays white in dark) and was being used as the card
   surface; `background[50]` is the correct dark-mode-aware white-surface token. Real bug fix (was

package/.cursor/modules/inputs-date-file/MODULE.md

@@ -12,7 +12,8 @@ ThemeDatePicker (Single/Range/Time variants), FileUpload, FileUploader, Editor (
 ## Key rules
 
 - DatePicker themed for brand tokens — `CalendarPanel` reads every color from `useCustomTheme()` (no hex literals), so it follows the active light/dark palette automatically.
-- The month/year `<select>` uses `colors.background[50]`, not `colors.white`: it is a white *surface* and must darken in dark mode. The one remaining `colors.white` (day label on the filled `primary[500]` circle — selected / range start / range end) is a *foreground* and correctly stays white. Don't "fix" it.
+- The month/year `<select>` uses `colors.background[50]`, not `colors.white`: it is a white *surface* and must darken in dark mode.
+- **Selected-day circle WCAG contrast (user-reported, fixed) — supersedes prior guidance below.** The filled day circle (selected / range start / range end) hardcoded `colors.white` text on `primary[500]`/`[600]` regardless of brand — the same class of gap `Button.styles.ts`'s solid variant already accounts for (white doesn't reliably clear AA against every brand's `[500]`, e.g. emerald/rosewood in dark, ~3.38/3.46). A previous pass here called this hardcoded white "correctly a foreground token, don't fix it" — that was wrong for the fill-contrast case specifically; foreground-vs-surface only tells you whether a token *inverts with mode*, not whether it *clears contrast against the fill it sits on*. Fixed via `onFilled(fill, theme.colors.white, theme.colors.black)` (`Theme/tokens/builders/accentText`) for both resting (`primary[500]`) and hover (`primary[600]`) fills.
 - **Calendar/time popover surface bug (user-reported, blocking):** `SingleDatePicker.tsx`, `RangeDatePicker.tsx`, `TimeOnlyPicker.tsx`, and the legacy `DatePicker.tsx` (still reachable — consumed directly by `Table/filters/LeftFilterPane.tsx`, not just via the unused commented-out playground import) each rendered a `PopoverContent` with no explicit `bg=` — the same Chakra-hardcoded-`colors.white`-behind-`_dark` bug as `Modal`/`AlertDialog`/`Drawer` (overlays module). Because `CalendarPanel`'s day/weekday text (`text[700]`/`gray[400]`/`gray[500]`) is computed against the *intended* dark canvas, the panel rendered on Chakra's un-migrated white default while its text was tuned for a dark background — producing exactly the washed-out, near-invisible day numbers reported. Fixed with `bg={theme.colors.background[50]}` on all four `PopoverContent`s (`TimeOnlyPicker.tsx` didn't previously call `useCustomTheme()` at all — added the hook). Verified live via Playwright across all four variants (date-only, date+time, range, time-only).
 - **FileUploader (QA-caught)** — its file-count and "Click here" text hardcoded `color="blue.500"`/
   `"blue.400"`, which fail AA against the component's canvas (same class as the Notification
@@ -47,6 +48,16 @@ ThemeDatePicker (Single/Range/Time variants), FileUpload, FileUploader, Editor (
   `.jodit-dialog_theme_dark` already hardcode `--jd-color-border: #6b6b6b` themselves (a Jodit-owned
   override we can't/don't need to touch), so this fix only had to cover panel/input backgrounds and
   the hover fill. Regression tests added to `joditThemeVars.test.ts`.
+- **Date/time input control-boundary + surface pass (this session):** `SingleDatePicker`'s text
+  input, `TimePicker`'s hour/minute/AM-PM `<Select>`s, and `TimePickerInput`'s input all gained an
+  explicit `bg={theme.colors.gray?.[50]}` (was inheriting the ambient/transparent default) and
+  `borderColor={theme.colors.boxborder?.[800]}` (was `undefined`/unset outside the error state) —
+  same WCAG 1.4.11 control-boundary standard already applied to `MultiSelect`/`Select.styles`/
+  `SelectSearch` (see `inputs-select` MODULE.md). Hover now also resolves to
+  `theme.colors.primary[500]` (was `undefined`, i.e. no hover feedback at all) to match the
+  existing `_focus` treatment. `TimeOnlyPicker`'s footer divider `borderColor` switched from the
+  raw Chakra literal `gray.200` to the token `theme.colors.boxborder?.[300]`. `TimePicker` didn't
+  previously call `useCustomTheme()` — added the hook.
 - Masked-input blur must not discard a valid value. `isMaskComplete()` only recognises numeric/`a` tokens, so text month formats (e.g. `MMM d, yyyy`) never look "complete" — `handleInputBlur`/`handleInputFocus` therefore keep any value that `parseValidatedValue()` can parse to a valid date, and only `requestClose(null)` (clear) on empty/unparseable input. The Clear button and emptied-mask paths remain the explicit ways to clear. Regression: `SingleDatePicker.blur.test.tsx`.
 
 ## Migration notes

package/.cursor/modules/inputs-select/MODULE.md

@@ -2,11 +2,11 @@
 
 ## Purpose
 
-Select, SearchSelect, SelectSearch, MultiSelect, Dropdown, Search.
+Select, SelectV2, SearchSelect, SelectSearch, MultiSelect, Dropdown, Search.
 
 ## Key paths
 
-- `src/Components/Select/`, `SearchSelect/`, `SelectSearch/`, `MultiSelect/`, `Dropdown/`, `Search/`
+- `src/Components/Select/`, `SelectV2/`, `SearchSelect/`, `SelectSearch/`, `MultiSelect/`, `Dropdown/`, `Search/`
 
 ## Key rules
 
@@ -25,3 +25,65 @@ SearchSelect and SelectSearch source every color from `useCustomTheme()` or a pa
 - Control borders (`MultiSelect`, `Select.styles`, `SelectSearch`) bumped `boxborder` step [500]/[700] to **[800]**: WCAG 1.4.11 needs a 3:1 contrast ratio against any named surface up to `muted` (lightest) — [500]/[700] failed there, [800] clears all with margin (see inline comments at each call site)
 - Known behavior change: SearchSelect's inside-select placeholder text dropped the `theme.colors.placeholder?.[500] ?? theme.colors.gray[500]` fallback for a flat `theme.colors.gray[500]` — still a valid token, but only the lavender brand defines a distinct `placeholder` scale (other brands inherit it via spread), so lavender's placeholder text loses its tint and now renders plain gray
 - SearchSelect's "Remove All" tooltip dropped its explicit `bg`/`color` overrides, now rendering with ToolTip's own default styling instead of a forced `gray[600]`/`white`
+
+## SelectV2 — custom-popup dropdown (additive, new)
+
+**Why it exists:** the existing `Select` (`src/Components/Select/`) wraps Chakra's `<Select>`, which
+renders a **real native `<select>`/`<option>`** — the closed field is themeable, but the open dropdown
+popup is painted by the browser's own UA stylesheet, not React. That means it can never get custom
+option rendering, hover states beyond OS defaults, or type-ahead filtering — the popup is architecturally
+outside Chakra/React's control (same class of gap as the native `color-scheme` bug documented in the
+theme MODULE.md, Wave H). `SelectV2` is a MUI-style alternative: a fully React-rendered popup, so every
+visual state (hover, selected, focus, disabled) is themeable via `useCustomTheme()`.
+
+**This is purely additive.** `Select.tsx`/`SelectProps.ts`/`Select.styles.ts` were not touched — existing
+consumer apps see **zero behavior change** on upgrading `pixelize-design-library`, whether or not they
+ever adopt `SelectV2`. New work should prefer `SelectV2`; old call sites can keep using `Select`
+indefinitely, with no forced migration.
+
+- **Path:** `src/Components/SelectV2/` — `SelectV2.tsx`, `SelectV2Props.ts`, `SelectV2.test.tsx`.
+- **Built from existing primitives only** — Chakra `Popover`/`PopoverTrigger`/`PopoverContent` (already
+  globally dark-mode-patched via `Theme/chakra/Popover.styles.ts`, Wave H) plus plain React state. No new
+  dependency added (no react-select/downshift/MUI) — bundle size and dependency surface are unchanged for
+  every consumer.
+- **Prop shape mirrors `Select`** for easy future migration: `options: {id, label}[]`, `value`,
+  `onChange(option | undefined)`, `placeholder`, `label`, `error`, `errorMessage`, `helperText`,
+  `isDisabled`, `isRequired`, `size` (`sm`/`md`/`lg`, same px/height scale as `Select.styles.ts`). Not
+  identical — e.g. no `variant`/`colorScheme` passthrough — since it isn't a drop-in wrapper.
+- **`data-testid`** is forwarded to the trigger button (same element as `role="combobox"`), so a
+  `Select` call site's existing `getByTestId(...)` query keeps working after switching to `SelectV2`.
+- **Multi-select** via `isMulti` (discriminated union in `SelectV2Props`): `value` becomes
+  `(string|number)[]`, `onChange` receives the full `OptionProp[]` selection, each row renders a checkbox,
+  and the popup stays open across picks (`resetAndClose` skips closing on `isMulti`). Trigger shows the
+  joined labels, or `"N selected"` past `maxLabelsBeforeSummary` (default 2).
+- **Custom option/row/trigger content**: `option.icon` + `option.description` give a built-in
+  icon+label+description row layout with no extra work; `renderOption(option, {isSelected, isActive})`
+  takes full control of a row (badges, avatars, arbitrary JSX) when that's not enough; `renderValue(selected)`
+  does the same for the trigger's content. All optional — omit for the original plain-text behavior.
+- **`defaultOpen`**: opens the popover immediately on mount instead of waiting for a click — for
+  inline-edit patterns (a table cell that swaps to a select the instant it becomes editable, replacing a
+  native `<select autoFocus>`). Click-away still closes it via `Popover`'s own close-on-blur, firing `onBlur`.
+- **Type-ahead filtering** built in (`isSearchable`, defaults `true`): a text input at the top of the
+  popup filters `options` client-side by substring match on `label`. Set `isSearchable={false}` to hide
+  it (still fully keyboard-navigable without it).
+- **Keyboard/ARIA:** trigger is `role="combobox"` with `aria-haspopup="listbox"`/`aria-expanded`/
+  `aria-controls`; popup list is `role="listbox"` with `role="option"`/`aria-selected` items. ArrowDown/
+  ArrowUp move the active option (wraps at both ends), Enter selects, Escape closes without selecting,
+  Tab closes and lets focus move on. Reuses Chakra's `Popover` focus/outside-click handling rather than
+  reimplementing it.
+- **Styling:** trigger box uses `Components/Common/fieldStyles.ts`'s `getFieldStateStyles()` — the same
+  shared border/focus/error visual standard as `Select`, `SearchSelect`, `MultiSelect` — so a `SelectV2`
+  sits visually consistent next to any of them. Popup surface/list follow the same token conventions as
+  `Dropdown`'s portaled menu (`background[50]`, `boxborder[200]`, `primary.opacity[8]` hover).
+- **Known gap / fast-follow:** no virtualization — fine for typical option-list sizes (tens to low
+  hundreds); for very large lists prefer `SearchSelect`, which already has performance tests and
+  virtualizes.
+- **Popup clipped inside `overflow:hidden` ancestors (user-reported, fixed).** `PopoverContent` wasn't
+  wrapped in Chakra's `<Portal>`, so it rendered inline in the DOM — any ancestor with
+  `overflow: hidden` (e.g. the library's own `Card variant="elevated"`, used throughout consumer
+  apps' settings/detail pages) visually clipped the open popup to whatever space was left below the
+  trigger. Symptom looked like a filtering bug (a 3-option list showing only the first option by
+  default, but showing correctly once typed down to 1 match) when it was actually the same content
+  height fitting inside the clipped region either way — the filter never changed. `Dropdown` and
+  `SearchSelect` already portal their menus for exactly this reason (see "Key rules" above); `SelectV2`
+  now does too.

package/.cursor/modules/inputs-toggle/MODULE.md

@@ -16,3 +16,9 @@ Checkbox, RadioButton, Switch, Slider, Toggle/TableToggle.
 
 - `Checkbox`: label tooltip now uses the shared `ToolTip` component instead of raw Chakra `Tooltip` with hardcoded `gray[600]`/`white` — `ToolTip` resolves a dark-mode-aware surface itself.
 - `Toggle/TableToggle`: selected-tab label color changed from `theme.colors.black` (mode-invariant) to `theme.colors.text[900]` (mode-adaptive). Real bug fix: `black` was rendered on `background[50]`, which is near-black in dark mode — black-on-near-black was invisible; `text[900]` flips to near-white in dark mode.
+- **`Slider`/`Switch` thumb bug (theme-level fix):** Chakra's own thumb baseStyle for both
+  hardcodes `bg: "white"` with **no** `_dark` gate at all (unlike most other components in this
+  sweep), so every bare `<SliderThumb>`/`<Switch>` rendered a literal white circle/knob on the
+  dark canvas regardless of mode. Fixed centrally in `Theme/chakra/Slider.styles.ts` and
+  `Switch.styles.ts` (registered in `componentStyles.ts`), each overriding the thumb part's `bg`
+  to `theme.colors.backgroundColor?.light ?? theme.colors.background?.[50]`.

package/.cursor/modules/layout-navigation/MODULE.md

@@ -26,6 +26,32 @@ WorkspaceWindow shell, WorkspaceTrayPreview popover).
 `WorkspaceWindow` calls `useCustomTheme()` **before** its `state === "minimized"` early
 return — after it, hook order would change when the window reopens.
 
+**First real consumer: tickets (user-reported dark-mode gaps + first adoption).** `WorkspaceWindow`/
+`WorkspaceTray`/`WorkspaceTrayPreview` existed but had no consumer yet; tickets' own hand-rolled
+floating-ticket-window/tray/hover-preview (`core/workspace/`) was migrated onto these, and the
+migration surfaced real gaps the "dark-mode checked" note above didn't cover — the control-bar
+`bg="gray.50"`/`borderColor="gray.100"`/title `color="gray.700"` and the tray pill's
+`bg/color/borderColor="blue.100/700/200"` were still **hardcoded literals**, not
+`useCustomTheme()` tokens, so they didn't actually follow brand/dark-mode. Fixed to
+`theme.colors.background?.[100]`/`boxborder?.[200]`/`text?.[700]` (window chrome, same pattern as
+`AiLauncher`) and `theme.colors.primary?.[100/700/200]` (tray pill, matching tickets' own prior
+token usage). `WorkspaceTrayPreview`'s card wrapper had the same gap (`borderColor="gray.200"`,
+`color="gray.800"`) — same fix.
+- **`onOverlayClick?: () => void`** added to `WorkspaceWindowProps` — with `size="full"` the
+  transparent `ModalContent` covers the viewport so Chakra's own `closeOnOverlayClick` never fires;
+  the parent needs its own "clicked the blurred backdrop" signal (tickets uses it to minimize
+  rather than close, preserving unsaved edits). `WorkspaceWindow` detects this itself
+  (`onMouseDown` + `e.target === e.currentTarget` on `ModalContent`) and also exposes
+  `${testId}-backdrop`.
+- **`renderItem?: (item, {restore, close}) => ReactNode`** added to `WorkspaceTrayProps` — full
+  override for one tray item's pill markup, for a consumer that needs to wrap the pill in its own
+  logic (tickets wraps it in a ticket-fetching hover preview, `TrayTabPreview`) while still reusing
+  the tray's positioned/wrap-reverse container. Omit it for the plain built-in pill.
+- Tickets' `TrayTabPreview` now delegates the hover-bridge timer/positioning entirely to
+  `WorkspaceTrayPreview` (`onOpenChange` gates the ticket fetch) and only supplies the ticket-specific
+  `preview` content — the timer/placement logic that used to be duplicated in the app is gone from
+  there now.
+
 ### Header, NavigationBar, FilterSidebar — WCAG/dark pass
 
 - **Header.tsx** — default (no explicit `colors` prop) styling changed: `bg` now
@@ -44,7 +70,9 @@ return — after it, hook order would change when the window reopens.
   `secondary[500]`). Its profile/account `MenuList` also sets
   `sx={{ "--menu-bg": theme.colors.backgroundColor.light }}` — same Chakra CSS-var fix as
   `ButtonGroupIcon` (buttons module): Chakra's `MenuItem` baseStyle hardcodes `--menu-bg` to
-  white, gated behind `_dark`, which this app's theme-swap dark mode never triggers.
+  white, gated behind `_dark`, which this app's theme-swap dark mode never triggers. Now also
+  covered app-wide by the theme-level `Menu` style override (`Theme/chakra/Menu.styles.ts`, theme
+  module Wave G) — this per-call-site `sx` is redundant but harmless alongside it.
 - **FilterSidebar.tsx** — section-label tooltip swapped from raw Chakra `Tooltip` (hardcoded
   `bg={gray[600]}`/`color={white}`) to the library's `ToolTip` (token-driven); search-input
   `borderColor` now `theme.colors.boxborder?.[800] ?? gray[200]` — plain `gray[200]` fails
@@ -67,10 +95,12 @@ return — after it, hook order would change when the window reopens.
   The submenu row's label ink also switched from static `text[800]` (tuned for the `background[50]`
   canvas, not the `activeBg` fill the active row switches to) to `onFilled(activeBg, white, black)`,
   which is provably >=4.5 against any fill regardless of which rung `pickActiveAccent` picks.
-- **Drawer.tsx (QA-caught, blocking)** — same `ModalContent` surface bug as `Modal`/`AlertDialog`
-  (overlays module): `DrawerContent` had no explicit `bg=`, so it fell through to Chakra's
-  hardcoded `colors.white` baseStyle, gated behind a `_dark` this app's theme-swap dark mode
-  never triggers. Fixed with `bg={colors?.background?.[50]}`.
+- **Drawer.tsx surface bug — now fixed at the theme level.** Same bug class as `Modal`/
+  `AlertDialog` (overlays module): Chakra's own `Drawer` baseStyle hardcodes `--drawer-bg` to
+  `colors.white` on the `dialog` part, gated behind a `_dark` this app's theme-swap dark mode
+  never triggers. Fixed centrally in `Theme/chakra/Drawer.styles.ts` (registered as `Drawer` in
+  `componentStyles.ts`), mirroring `Modal.styles.ts` — covers every `DrawerContent` app-wide. An
+  earlier pass's per-call-site `bg={colors?.background?.[50]}` fix is now redundant but harmless.
 - **FilterSidebar.tsx WCAG pass (Wave D, QA-driven)** — two real AA/graphical-object failures
   found beyond the surface bug above: the min/max price selected-row checkmark icon (`red[600]`
   on its own `red[100]` fill, ≈2.89:1, fails the 3:1 non-text bar) now uses
@@ -163,6 +193,26 @@ Regression tests: `sidebarAccentColors.test.ts` (lavender + rosewood) — light
 dark mode pins the light-mode rung (not the dark-inverted one), contrast ≥3:1 (icon) / ≥4.5:1
 (label) against the sidebar canvas, graceful fallback when `brand` is unknown.
 
+### SideBar default logo — hardcoded black fill invisible on dark-`primary[500]` brands (user-reported, fixed)
+
+`SidebarHeader`'s fallback mark (no `logo` prop passed) wraps `Assets/defaultLogo.tsx` in a `Box`
+with `bg={theme.colors.primary[500]}` + `color={theme.colors.white}` — but the SVG paths inside
+`DefaultLogo` hardcoded `fill={theme.colors.black}` instead of inheriting that `color`. Most brands'
+`primary[500]` is a mid-tone hue, so a black mark still read against it by accident; **zinc**'s
+`primary[500]` is `#18181b` (near-black by design — see zinc's palette comment), so the black-on-
+near-black logo was effectively invisible. Fixed by switching all three paths to `fill="currentColor"`
+so the mark always matches whatever `color` its wrapper sets, regardless of brand — `DefaultLogo` no
+longer needs `useCustomTheme()` at all.
+
+That alone wasn't sufficient: the wrapper `Box` itself hardcoded `color={theme.colors.white}`
+regardless of mode. Zinc **inverts** its dark palette — `primary[500]` is `#18181b` in light but
+`#e4e4e7` (near-white) in dark — so a hardcoded-white icon on a hardcoded-white-in-dark-mode fill
+went invisible again, this time in dark mode. Fixed with the same `onFilled(fill, white, black)`
+WCAG-pick helper already used for the calendar's selected-day circle and `Button.styles.ts`'s solid
+variant: `color={onFilled(theme.colors.primary[500], theme.colors.white, theme.colors.black)}`. Any
+future "icon on a `primary[500]` fill" spot should use this same helper rather than assuming white
+always clears — zinc dark is the proof case that it doesn't.
+
 ### Known gap — Header "Login" demo button (raw Chakra, wrong-canvas ghost ink)
 
 `Layout.tsx`'s `/header` playground route renders its `rightSlot` demo content with a **raw**

package/.cursor/modules/overlays/MODULE.md

@@ -35,25 +35,30 @@ Toaster and ToolTip take all color from the theme (`useTheme()` / `useCustomThem
 so they follow the active light/dark palette; remaining hex literals are only `??`
 fallbacks for when no Pixelize palette is in context.
 
-- **Modal/AlertDialog surface bug (QA-caught, blocking):** `ModalContent`/`AlertDialogContent`
-  had no explicit `bg=`, so both fell through to Chakra's own `baseStyle`, which hardcodes
-  `[$bg.variable]: "colors.white"` gated behind `_dark` — this app's theme-swap dark mode
-  (palette swapped, Chakra `colorMode` stays `"light"`) never triggers that `_dark` block, so
-  every Modal/AlertDialog rendered a white panel with near-invisible text on the dark canvas.
-  Same bug class as the `ButtonGroupIcon` menu-bg bug (buttons) and the `OrgSwitcher` popover
-  bug (account-management) — Chakra part-styles that hardcode a literal instead of reading a
-  semantic token. `Card` was unaffected because it already used the patched
-  `chakra-body-bg`/`chakra-body-text` semantic tokens (see theme module); Modal/AlertDialog
-  bypass that layer entirely. Fixed with an explicit `bg={colors?.background?.[50]}` on both.
-  `AlertDialog` has no separate Chakra theme key (it reuses Chakra's `Modal` style config
-  internally), but still needed its own prop-level fix since this app's fix is component-level,
-  not a Chakra `components.Modal` theme-config override.
+- **Modal/AlertDialog surface bug — now fixed at the theme level, not per-component.**
+  Chakra's own `Modal` baseStyle hardcodes `[$bg.variable]: "colors.white"` on the `dialog`
+  part, gated behind `_dark` — this app's theme-swap dark mode (palette swapped, Chakra
+  `colorMode` stays `"light"`) never triggers that block, so every `ModalContent` rendered a
+  white panel with near-invisible text on the dark canvas. `AlertDialog` reuses Chakra's
+  `Modal` style config internally, so it inherits the same fix with no separate theme key.
+  Fixed centrally in `Theme/chakra/Modal.styles.ts` (`definePartsStyle` on the `dialog` part,
+  registered as `Modal` in `componentStyles.ts`) — mirrors `Menu.styles.ts`/`Drawer.styles.ts`.
+  A prior pass fixed this per-call-site with an explicit `bg=` prop; that approach is
+  superseded by this theme-level override, which covers every `ModalContent`/`AlertDialogContent`
+  app-wide with zero per-call-site changes (an explicit `bg=` still wins if a caller sets one).
+- **Popover surface bug** — same bug class, fixed in `Theme/chakra/Popover.styles.ts`
+  (`--popper-bg` + `--popper-arrow-shadow-color`, registered as `Popover` in
+  `componentStyles.ts`) — see theme module Wave H. Every bare `<PopoverContent>` in the
+  library (this module doesn't own a dedicated Popover component folder — Popover is used
+  directly from Chakra by many components, e.g. `OrgSwitcher`, `MoreItems`, `SideBar`,
+  `DatePicker`) now gets a dark-aware surface for free.
 
 ## Dark mode — Modal/AlertDialog consumers
 
-`Drawer` (layout-navigation module) has the identical fix. Every other file in the library that
-renders a raw Chakra `ModalContent` needed the same explicit `bg=` — see the account-management,
-table, and cards MODULE.md sections for the specific consumer components fixed in this pass.
+`Drawer` (layout-navigation module) has the identical theme-level fix (`Drawer.styles.ts`). Many
+consumer components (see account-management, table, cards MODULE.md) additionally carry an
+explicit per-call-site `bg=` from an earlier pass, predating the theme-level `Modal`/`Drawer`
+style overrides above — now redundant but harmless (an explicit prop still wins, same value).
 `WorkspaceWindow` (layout-navigation) was checked and is **not** affected: its `ModalContent` is
 deliberately `bg="transparent"` with an inner `Box bg={theme.colors.background[50]}` as the real
 surface.
@@ -67,3 +72,11 @@ surface.
   passes through un-inverted (`sidebar: light.sidebar`), so it stays near-black in
   dark and the label stays legible; any other surface ramp would flip light and
   render the white label invisible. Callers overriding `bg` own that contrast.
+- **Chakra's raw `Tooltip` baseStyle** hardcodes `--tooltip-bg`/`--tooltip-fg` to
+  `gray.700`/`whiteAlpha.900` behind `_dark`, same never-triggered gate — our reversed dark
+  gray ramp makes `gray.700` LIGHT, so a bare (non-`ToolTip`) Chakra `<Tooltip>` renders
+  near-white-on-near-white. Fixed with a `Tooltip` entry in `componentStyles.ts` pinning both
+  vars to `black`/`white` — the two tokens `buildDarkPalette` never remaps, so the chip stays a
+  stable dark-bg/white-text pair in both modes. This library's own `ToolTip` above already sets
+  its own `bg`/`color` explicitly and is unaffected; the fix targets consumer apps that render a
+  raw Chakra `Tooltip` directly instead of this component.

package/.cursor/modules/table/MODULE.md

@@ -69,6 +69,12 @@ active palette: `Table` (pagination popover), `TableBody` (expanded-row panel),
   (`table.hover[300]`, same as before). Regression tests: `tableRowHoverStyle.test.ts` (lavender +
   rosewood). Scoped to the per-cell hover mechanism already in place — not restructured to a
   `<Tr>`-level highlight, since that wasn't the reported defect.
+- **`TableSettings.tsx` enclosed-tab "cutout" bug (theme-level fix):** Chakra's own `Tabs`
+  baseStyle hardcodes the selected tab's cutout color to `colors.white` for the `enclosed`
+  (selected border) and `enclosed-colored` (selected background) variants, both behind `_dark`,
+  same never-triggered gate. `TableSettings.tsx` is this library's only consumer of Chakra's raw
+  `TabList`/`TabPanels`. Fixed centrally in `Theme/chakra/Tabs.styles.ts` (registered in
+  `componentStyles.ts`), overriding both variants' selected-tab cutout token.
 - **Known gap (found by code review, not fixed this pass):** `Table/filters/CompactSelect.tsx`,
   `Table/filters/TableFilters.tsx`, and `Table/components/TableActions.tsx` each render a raw
   Chakra `PopoverContent` with no `bg=` — the identical bug class just fixed in `Table.tsx`'s

package/.cursor/modules/theme/MODULE.md

@@ -296,6 +296,123 @@ shared-shape/shared-role values that would require restructuring the 10-step ram
 cross-brand `roles/bg.surface` mapping, not a zinc-only anchor swap — out of scope for a
 change scoped to "don't break anything."
 
+**2026-07-20 — `PixelizeThemeProvider` gained an optional `themeOverrides` prop.** Found while
+wiring dark mode into the **tickets** consumer app: it has its own font-stack/compact-control-size/
+component-defaultProps customizations layered onto the brand theme (the old `withTheme(app, theme)`
+pattern spread these onto `ThemesList[brand]` directly), and `PixelizeThemeProvider` had no
+equivalent injection point — its internal `ChakraProvider` is hardcoded to
+`brandThemes[brand][resolvedMode]`. Without this, every consumer app with its own theme
+customizations would have had to build the same workaround (mount its own second `ChakraProvider`
+inside the provider's tree, shadowing the internal one). `themeOverrides?: Record<string, unknown>`
+is deep-merged via `extendTheme(brandThemes[brand][resolvedMode], themeOverrides)`, re-computed
+whenever `brand`/`resolvedMode`/`themeOverrides` change so overrides always layer onto the *current*
+palette. Safe post-resolution: `createBrandTheme` already fixes `config.initialColorMode` to
+`"light"` on every palette, and `extendTheme` is a pure additive merge that doesn't re-derive
+`_dark:` blocks — so this cannot reintroduce the double-adaptation bug the forced light
+`colorModeManager` avoids. Optional, defaults to `undefined` — zero behavior change for existing
+consumers that don't pass it.
+
+**2026-07-20 — `PixelizeThemeProvider` re-syncs `brandState` when the `brand` prop changes post-mount.**
+`brandProp` previously only seeded initial state (`useState(brandProp)`), so a consumer that
+re-renders with a new `brand` after mount (e.g. persisting the pick through its own Redux store
+instead of calling this provider's own `setBrand`) never saw it applied — the same gap `mode`
+already had, worked around elsewhere by callers mirroring it in an effect. Fixed with a `useEffect`
+on `brandProp` (skipping the first run, so it doesn't fight the rehydrate-from-storage effect) that
+calls `setBrandState(brandProp)` only when the **prop itself** changes — not on every local
+`setBrand()` call, so it doesn't fight the user's own in-session `ThemeSwitcher` picking.
+
+**2026-07-20 — `ThemeSwitcher`'s brand menus gained a color swatch dot per brand.** `BrandMenu`
+(icon variant) and `MenuVariant`'s brand submenu both previously showed only the brand name text.
+Each option now renders a small (`0.625rem`) filled circle before the label, colored from that
+brand's own `colors.primary[500]` in **light** mode (`brandThemes[brand].light...primary[500]`) —
+always the light-mode anchor regardless of the switcher's current mode, so the dot is a stable
+brand identifier rather than something that itself flips with dark mode. `ThemeSwitcher.tsx` also
+stopped re-deriving `menuBg`/pushing it back via `sx` on every render (`useSwitcherColors()`) now
+that `Menu.styles.ts` (Wave G) supplies `--menu-bg` centrally — removes a redundant Emotion style
+recompute per render that showed up as flicker while hovering/scrolling the brand list.
+
+## Wave G — global `Menu` component style override (`--menu-bg`), found while auditing tickets
+
+Same bug class as Wave E's `ThemeSwitcher` fix, but at the root instead of per-call-site: Chakra's
+own `Menu` baseStyle hardcodes the `--menu-bg` CSS var to `"#fff"` (gated behind `_dark`, which this
+app's theme-swap never triggers — `PixelizeThemeProvider`'s forced-light `colorModeManager`, Wave D
+above). Every **bare** `<MenuList>` in every consuming app (tickets' board overflow menu,
+`TicketOptionMenu`, rows-per-page menu, etc.) rendered a white dropdown on a dark canvas, and a
+call-site `bg=` prop alone doesn't fix it — that only recolors the list's own box, not the CSS var
+`MenuItem`'s `_focus`/`_active`/`_expanded` states read.
+
+Added `src/Theme/chakra/Menu.styles.ts` (new file, registered in `componentStyles.ts`): a
+`definePartsStyle` override on the `list` anatomy part that sets `--menu-bg` (via `cssVar`) to
+`theme.colors.backgroundColor?.light ?? theme.colors.background?.[50] ?? "#fff"` and `color` to
+`theme.colors.text?.[900]`. This fixes every consumer's bare `MenuList` app-wide with zero
+per-call-site changes — `ThemeSwitcher`'s existing manual `bg=`/`sx={{"--menu-bg": ...}}` workaround
+(Wave E) still works alongside it (an explicit call-site override still wins), it's just no longer
+required for a plain `<MenuList>`. Verified: `tsc --noEmit` clean, lint clean, full `jest` suite
+905/905 (72 suites, up from 902/72 pre-fix — 3 new but this pass added no dedicated `Menu.styles`
+test, the count reflects unrelated in-flight suite growth).
+
+## Wave H — `Popover`/`Skeleton` component-style overrides + native UI `color-scheme`, same audit as Wave G
+
+Same bug class as Wave G's `Menu` fix, found while sweeping the rest of Chakra's own component
+themes for the identical `_dark`-gated hardcoded-white pattern — plus one new bug *class* (native
+browser chrome) the earlier waves never covered.
+
+- **`Popover`** — Chakra's own Popover baseStyle hardcodes `--popper-bg` to `"colors.white"` and
+  `--popper-arrow-shadow-color` to `"colors.gray.200"`, both gated behind `_dark` (confirmed by
+  reading `@chakra-ui/theme`'s `popover.mjs` source directly — `content` is the anatomy part that
+  owns both vars; `--popper-arrow-bg` is untouched because Chakra's own baseStyle already points it
+  at `$popperBg`, so fixing `$popperBg` fixes the arrow fill for free). Every bare
+  `<PopoverContent>` rendered a white card with a light arrow shadow on the dark canvas. Added
+  `src/Theme/chakra/Popover.styles.ts` (new file, registered in `componentStyles.ts`) mirroring
+  `Menu.styles.ts` exactly: `createMultiStyleConfigHelpers(popoverAnatomy.keys)` +
+  `definePartsStyle` on the `content` part, `[$popperBg.variable]` sourced from
+  `theme.colors.backgroundColor?.light ?? theme.colors.background?.[50] ?? "#fff"` (identical
+  fallback chain to Menu) and `[$arrowShadowColor.variable]` from `theme.colors.border?.[200]`.
+- **`Skeleton`** — Chakra's own Skeleton baseStyle hardcodes `--skeleton-start-color`/
+  `--skeleton-end-color` to `colors.gray.100`/`colors.gray.400`, same `_dark`-gated pattern.
+  Verified in `@chakra-ui/react`'s actual `skeleton.mjs` that Chakra's `Skeleton` is a
+  **single-part** style config (`defineStyleConfig`, not a multi-part anatomy like Menu/Popover),
+  and that its `startColor`/`endColor` are **props**, not style-config keys — but those props only
+  ever populate the same two CSS vars when a caller actually passes them (`useToken("colors", ["",
+  ""])` resolves to `undefined`, so `cssVarStyles` stays empty and the base style's vars pass
+  through untouched). That confirms Chakra's own prop-vs-style precedence already does the right
+  thing, so the fix was made at the `componentStyles.ts` level (a `Skeleton: ComponentStyleConfig`
+  entry, same file as `Badge`/`FormError`) rather than touching `Components/Skeletons/Skeletons.tsx`
+  — zero risk to the existing prop passthrough there; a caller-supplied `startColor`/`endColor`
+  still wins exactly as before. Rungs: `gray[100]`/`gray[300]` — `buildDarkPalette.ts`'s `gray`
+  ramp is already role-reversed for dark mode (low rungs go dark, high rungs go light there), so
+  the same two rung indices read as a light shimmer in light mode and a subtle dark-on-dark shimmer
+  in dark mode with no mode branching needed in the override itself.
+- **`color-scheme` CSS property (new bug class)** — native browser UI (the `<select>` popup
+  chrome, the `<input type="date">` calendar picker) is painted by the browser's own UA stylesheet
+  keyed off the CSS `color-scheme` property, entirely outside Chakra/React theming — no component
+  style or palette swap can reach it, which is why this wasn't caught by any earlier wave's
+  component-by-component audit. Neither repo set it anywhere, so that native chrome always rendered
+  light regardless of the app's resolved mode. Fixed in `PixelizeThemeProvider.tsx` with a
+  `useEffect` that sets `document.documentElement.style.colorScheme = resolvedMode` whenever
+  `resolvedMode` changes. Scoped to the provider (not a global stylesheet or index.css rule) so
+  `withTheme` consumers — deliberately light-only per this doc's "Key rules" — see no change;
+  only `PixelizeThemeProvider`/`useThemeMode` consumers get mode-aware native chrome.
+- Full gate green: `tsc --noEmit` clean, lint clean, `jest` 905/905 (72 suites, unchanged from
+  pre-Wave-H — no new dedicated test file added for these three, consistent with Wave G's Menu fix
+  which also shipped without one).
+
+## Wave I — remaining `_dark`-gated component overrides (Modal/Drawer/Avatar/Tabs/Slider/Switch/Tooltip)
+
+Completes the Wave G/H sweep: every other Chakra component whose own baseStyle hardcodes a
+literal behind the never-triggered `_dark` gate (or, for Slider/Switch, no gate at all), fixed
+the same way — a `definePartsStyle`/`ComponentStyleConfig` override registered in
+`componentStyles.ts`, sourcing color from `theme.colors.backgroundColor?.light ?? theme.colors
+.background?.[50]` (or the relevant token) instead of Chakra's literal. See each domain
+MODULE.md for the consumer-facing detail: `Modal`/`Drawer` (overlays, layout-navigation —
+supersedes those modules' earlier per-call-site `bg=` fixes), `Avatar` (account-management),
+`Tabs` (table), `Slider`/`Switch` (inputs-toggle), `Tooltip`/`Skeleton` (overlays, feedback —
+`Tooltip` pins `black`/`white`, the two tokens `buildDarkPalette` never remaps, since a tooltip
+must stay a stable dark chip in either mode rather than following the canvas).
+`componentStyles.ts` now registers 10 chakra-native theme keys total (`Drawer`, `Menu`, `Modal`,
+`Popover`, `Slider`, `Switch`, `Tabs`, `Avatar`, `Skeleton`, `Tooltip`) alongside the library's
+own `Checkbox`/`Input`/`Button`/`Badge`/`FormError`/etc.
+
 ## Known gaps
 
 - `KanbanBoard.tsx` uses `var(--chakra-colors-gray-300)`, but `cssVarPrefix` is `"ck"` — that

package/dist/Assets/defaultLogo.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"defaultLogo.d.ts","sourceRoot":"","sources":["../../src/Assets/defaultLogo.tsx"],"names":[],"mappings":"AAEA,QAAA,MAAM,WAAW,+CAyBhB,CAAC;AAEF,eAAe,WAAW,CAAC"}
+{"version":3,"file":"defaultLogo.d.ts","sourceRoot":"","sources":["../../src/Assets/defaultLogo.tsx"],"names":[],"mappings":"AAAA,QAAA,MAAM,WAAW,+CAuBhB,CAAC;AAEF,eAAe,WAAW,CAAC"}

package/dist/Assets/defaultLogo.js

@@ -1,9 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 const jsx_runtime_1 = require("react/jsx-runtime");
-const useCustomTheme_1 = require("../Theme/useCustomTheme");
 const DefaultLogo = () => {
-    const theme = (0, useCustomTheme_1.useCustomTheme)();
-    return ((0, jsx_runtime_1.jsxs)("svg", { width: "12.09", height: "15.95", viewBox: "0 0 31 29", fill: "none", xmlns: "http://www.w3.org/2000/svg", children: [(0, jsx_runtime_1.jsx)("path", { d: "M30.4999 6.26137V7.81058H15.9761H14.8787V22.8508V28.8862H12.5226C9.6824 28.8862 7.32632 26.4656 7.06812 23.3995C7.06812 23.2381 7.06812 23.0444 7.06812 22.8508V18.3323C7.06812 18.2677 7.06812 18.2032 7.06812 18.1063V15.5889V6.2291C7.06812 2.80793 9.84378 -5.72205e-06 13.2972 -5.72205e-06H24.8517C28.0147 0.355021 30.4676 3.00158 30.4676 6.2291L30.4999 6.26137Z", fill: theme.colors.black }), (0, jsx_runtime_1.jsx)("path", { d: "M7.10053 23.3672H7.03598C5.16402 23.2381 3.48571 22.4635 2.25926 21.3338C0.871428 20.0428 0 18.2677 0 16.3312V15.6211H7.06825V18.1386C7.06825 18.2032 7.06825 18.2677 7.06825 18.3645V22.883C7.06825 23.0767 7.06825 23.2381 7.06825 23.4317L7.10053 23.3672Z", fill: theme.colors.black }), (0, jsx_runtime_1.jsx)("path", { d: "M30.4678 12.0063V15.6211V17.1703C30.4678 20.6238 26.272 23.3994 21.0757 23.3994H14.8789V22.8508V15.6211H22.6572V7.81056C22.6895 7.81056 30.5001 7.81056 30.5001 7.81056V11.5868C30.5001 11.7159 30.5001 11.8772 30.5001 12.0063H30.4678Z", fill: theme.colors.black })] }));
+    return ((0, jsx_runtime_1.jsxs)("svg", { width: "12.09", height: "15.95", viewBox: "0 0 31 29", fill: "none", xmlns: "http://www.w3.org/2000/svg", children: [(0, jsx_runtime_1.jsx)("path", { d: "M30.4999 6.26137V7.81058H15.9761H14.8787V22.8508V28.8862H12.5226C9.6824 28.8862 7.32632 26.4656 7.06812 23.3995C7.06812 23.2381 7.06812 23.0444 7.06812 22.8508V18.3323C7.06812 18.2677 7.06812 18.2032 7.06812 18.1063V15.5889V6.2291C7.06812 2.80793 9.84378 -5.72205e-06 13.2972 -5.72205e-06H24.8517C28.0147 0.355021 30.4676 3.00158 30.4676 6.2291L30.4999 6.26137Z", fill: "currentColor" }), (0, jsx_runtime_1.jsx)("path", { d: "M7.10053 23.3672H7.03598C5.16402 23.2381 3.48571 22.4635 2.25926 21.3338C0.871428 20.0428 0 18.2677 0 16.3312V15.6211H7.06825V18.1386C7.06825 18.2032 7.06825 18.2677 7.06825 18.3645V22.883C7.06825 23.0767 7.06825 23.2381 7.06825 23.4317L7.10053 23.3672Z", fill: "currentColor" }), (0, jsx_runtime_1.jsx)("path", { d: "M30.4678 12.0063V15.6211V17.1703C30.4678 20.6238 26.272 23.3994 21.0757 23.3994H14.8789V22.8508V15.6211H22.6572V7.81056C22.6895 7.81056 30.5001 7.81056 30.5001 7.81056V11.5868C30.5001 11.7159 30.5001 11.8772 30.5001 12.0063H30.4678Z", fill: "currentColor" })] }));
 };
 exports.default = DefaultLogo;

package/dist/Assets/defaultLogo.tsx

@@ -1,7 +1,4 @@
-import { useCustomTheme } from "../Theme/useCustomTheme";
-
 const DefaultLogo = () => {
-  const theme = useCustomTheme();
   return (
     <svg
       width="12.09"
@@ -12,19 +9,18 @@ const DefaultLogo = () => {
     >
       <path
         d="M30.4999 6.26137V7.81058H15.9761H14.8787V22.8508V28.8862H12.5226C9.6824 28.8862 7.32632 26.4656 7.06812 23.3995C7.06812 23.2381 7.06812 23.0444 7.06812 22.8508V18.3323C7.06812 18.2677 7.06812 18.2032 7.06812 18.1063V15.5889V6.2291C7.06812 2.80793 9.84378 -5.72205e-06 13.2972 -5.72205e-06H24.8517C28.0147 0.355021 30.4676 3.00158 30.4676 6.2291L30.4999 6.26137Z"
-        fill={theme.colors.black}
+        fill="currentColor"
       />
       <path
         d="M7.10053 23.3672H7.03598C5.16402 23.2381 3.48571 22.4635 2.25926 21.3338C0.871428 20.0428 0 18.2677 0 16.3312V15.6211H7.06825V18.1386C7.06825 18.2032 7.06825 18.2677 7.06825 18.3645V22.883C7.06825 23.0767 7.06825 23.2381 7.06825 23.4317L7.10053 23.3672Z"
-        fill={theme.colors.black}
+        fill="currentColor"
       />
       <path
         d="M30.4678 12.0063V15.6211V17.1703C30.4678 20.6238 26.272 23.3994 21.0757 23.3994H14.8789V22.8508V15.6211H22.6572V7.81056C22.6895 7.81056 30.5001 7.81056 30.5001 7.81056V11.5868C30.5001 11.7159 30.5001 11.8772 30.5001 12.0063H30.4678Z"
-        fill={theme.colors.black}
+        fill="currentColor"
       />
     </svg>
-
-  )
+  );
 };
 
 export default DefaultLogo;

package/dist/Components/DatePicker/CalendarPanel.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"CalendarPanel.d.ts","sourceRoot":"","sources":["../../../src/Components/DatePicker/CalendarPanel.tsx"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,OAAO,CAAC;AAO1B,MAAM,MAAM,kBAAkB,GAAG;IAC/B,YAAY,EAAE,IAAI,CAAC;IACnB,eAAe,EAAE,CAAC,OAAO,EAAE,CAAC,IAAI,EAAE,IAAI,KAAK,IAAI,KAAK,IAAI,CAAC;IACzD,KAAK,EAAE,IAAI,CAAC;IACZ,OAAO,EAAE,OAAO,CAAC;IACjB,QAAQ,EAAE,IAAI,GAAG,IAAI,CAAC;IACtB,cAAc,EAAE,IAAI,GAAG,IAAI,CAAC;IAC5B,YAAY,EAAE,IAAI,GAAG,IAAI,CAAC;IAC1B,SAAS,EAAE,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,EAAE,IAAI,KAAK,OAAO,CAAC;IACzC,QAAQ,EAAE,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,EAAE,IAAI,KAAK,OAAO,CAAC;IACxC,OAAO,EAAE,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,EAAE,IAAI,KAAK,OAAO,CAAC;IACvC,OAAO,CAAC,EAAE,IAAI,CAAC;IACf,OAAO,CAAC,EAAE,IAAI,CAAC;IACf,gBAAgB,CAAC,EAAE,OAAO,CAAC;IAC3B,kBAAkB,CAAC,EAAE,OAAO,CAAC;IAC7B,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB,WAAW,EAAE,CAAC,CAAC,EAAE,IAAI,KAAK,IAAI,CAAC;IAE/B,WAAW,CAAC,EAAE,IAAI,GAAG,IAAI,CAAC;IAC1B,UAAU,CAAC,EAAE,CAAC,CAAC,EAAE,IAAI,GAAG,IAAI,KAAK,IAAI,CAAC;IACtC,cAAc,CAAC,EAAE,KAAK,CAAC,SAAS,CAAC;CAClC,CAAC;AAEF,eAAO,MAAM,aAAa,EAAE,KAAK,CAAC,EAAE,CAAC,kBAAkB,CA8QtD,CAAC;AAEF,eAAe,aAAa,CAAC"}
+{"version":3,"file":"CalendarPanel.d.ts","sourceRoot":"","sources":["../../../src/Components/DatePicker/CalendarPanel.tsx"],"names":[],"mappings":"AAAA,OAAO,KAAK,MAAM,OAAO,CAAC;AAQ1B,MAAM,MAAM,kBAAkB,GAAG;IAC/B,YAAY,EAAE,IAAI,CAAC;IACnB,eAAe,EAAE,CAAC,OAAO,EAAE,CAAC,IAAI,EAAE,IAAI,KAAK,IAAI,KAAK,IAAI,CAAC;IACzD,KAAK,EAAE,IAAI,CAAC;IACZ,OAAO,EAAE,OAAO,CAAC;IACjB,QAAQ,EAAE,IAAI,GAAG,IAAI,CAAC;IACtB,cAAc,EAAE,IAAI,GAAG,IAAI,CAAC;IAC5B,YAAY,EAAE,IAAI,GAAG,IAAI,CAAC;IAC1B,SAAS,EAAE,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,EAAE,IAAI,KAAK,OAAO,CAAC;IACzC,QAAQ,EAAE,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,EAAE,IAAI,KAAK,OAAO,CAAC;IACxC,OAAO,EAAE,CAAC,CAAC,EAAE,IAAI,EAAE,CAAC,EAAE,IAAI,KAAK,OAAO,CAAC;IACvC,OAAO,CAAC,EAAE,IAAI,CAAC;IACf,OAAO,CAAC,EAAE,IAAI,CAAC;IACf,gBAAgB,CAAC,EAAE,OAAO,CAAC;IAC3B,kBAAkB,CAAC,EAAE,OAAO,CAAC;IAC7B,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB,WAAW,EAAE,CAAC,CAAC,EAAE,IAAI,KAAK,IAAI,CAAC;IAE/B,WAAW,CAAC,EAAE,IAAI,GAAG,IAAI,CAAC;IAC1B,UAAU,CAAC,EAAE,CAAC,CAAC,EAAE,IAAI,GAAG,IAAI,KAAK,IAAI,CAAC;IACtC,cAAc,CAAC,EAAE,KAAK,CAAC,SAAS,CAAC;CAClC,CAAC;AAEF,eAAO,MAAM,aAAa,EAAE,KAAK,CAAC,EAAE,CAAC,kBAAkB,CAsRtD,CAAC;AAEF,eAAe,aAAa,CAAC"}

package/dist/Components/DatePicker/CalendarPanel.js

@@ -10,6 +10,7 @@ const date_fns_1 = require("date-fns");
 const lucide_react_1 = require("lucide-react");
 const Button_1 = __importDefault(require("../Button/Button"));
 const useCustomTheme_1 = require("../../Theme/useCustomTheme");
+const accentText_1 = require("../../Theme/tokens/builders/accentText");
 const CalendarPanel = ({ currentMonth, setCurrentMonth, today, isRange, tempDate, tempRangeStart, tempRangeEnd, isSameDay, isBefore, isAfter, minDate, maxDate, disablePastDates, disableFutureDates, disableToday, onDaySelect, hoveredDate, onDayHover, renderWeekdays, }) => {
     var _a;
     const theme = (0, useCustomTheme_1.useCustomTheme)();
@@ -86,11 +87,19 @@ const CalendarPanel = ({ currentMonth, setCurrentMonth, today, isRange, tempDate
                     else if (isEnd)
                         cellBg = `linear-gradient(to right, ${rangeBg} 50%, transparent 50%)`;
                 }
+                // Solid fill (selected/range-endpoint) needs the ink checked against that
+                // specific fill — `primary[500]` doesn't reliably clear AA for white text on
+                // every brand/mode (same gap the solid Button variant already accounts for).
+                const solidFill = theme.colors.primary[500];
+                const solidHoverFill = theme.colors.primary[600];
                 const circleColor = circleSolid
-                    ? theme.colors.white
+                    ? (0, accentText_1.onFilled)(solidFill, theme.colors.white, theme.colors.black)
                     : isInCurrentMonth
                         ? theme.colors.text[700]
                         : theme.colors.gray[400];
+                const circleHoverColor = circleSolid
+                    ? (0, accentText_1.onFilled)(solidHoverFill, theme.colors.white, theme.colors.black)
+                    : circleColor;
                 const circleBorder = circleSolid
                     ? "1px solid transparent"
                     : isTentativeEnd
@@ -98,10 +107,10 @@ const CalendarPanel = ({ currentMonth, setCurrentMonth, today, isRange, tempDate
                         : isToday
                             ? `1px solid ${theme.colors.primary[300]}`
                             : "1px solid transparent";
-                days.push((0, jsx_runtime_1.jsx)(react_1.Box, { h: "2rem", display: "flex", alignItems: "center", justifyContent: "center", style: cellBg ? { background: cellBg } : undefined, children: (0, jsx_runtime_1.jsx)(react_1.Box, { as: "button", type: "button", disabled: disabled, onClick: () => !disabled && onDaySelect(new Date(thisDay)), onMouseEnter: () => !disabled && (onDayHover === null || onDayHover === void 0 ? void 0 : onDayHover(new Date(thisDay))), w: "1.75rem", h: "1.75rem", borderRadius: "full", display: "flex", alignItems: "center", justifyContent: "center", fontSize: "0.8125rem", fontWeight: circleSolid ? 600 : 500, lineHeight: "1", cursor: disabled ? "not-allowed" : "pointer", bg: circleSolid ? theme.colors.primary[500] : "transparent", color: circleColor, border: circleBorder, transition: "background 0.12s, color 0.12s", _hover: disabled
+                days.push((0, jsx_runtime_1.jsx)(react_1.Box, { h: "2rem", display: "flex", alignItems: "center", justifyContent: "center", style: cellBg ? { background: cellBg } : undefined, children: (0, jsx_runtime_1.jsx)(react_1.Box, { as: "button", type: "button", disabled: disabled, onClick: () => !disabled && onDaySelect(new Date(thisDay)), onMouseEnter: () => !disabled && (onDayHover === null || onDayHover === void 0 ? void 0 : onDayHover(new Date(thisDay))), w: "1.75rem", h: "1.75rem", borderRadius: "full", display: "flex", alignItems: "center", justifyContent: "center", fontSize: "0.8125rem", fontWeight: circleSolid ? 600 : 500, lineHeight: "1", cursor: disabled ? "not-allowed" : "pointer", bg: circleSolid ? solidFill : "transparent", color: circleColor, border: circleBorder, transition: "background 0.12s, color 0.12s", _hover: disabled
                             ? {}
                             : circleSolid
-                                ? { bg: theme.colors.primary[600] }
+                                ? { bg: solidHoverFill, color: circleHoverColor }
                                 : { bg: rangeBg }, children: (0, date_fns_1.format)(thisDay, "d") }) }, thisDay.toString()));
                 day = (0, date_fns_1.addDays)(day, 1);
             }

package/dist/Components/DatePicker/SingleDatePicker.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"SingleDatePicker.d.ts","sourceRoot":"","sources":["../../../src/Components/DatePicker/SingleDatePicker.tsx"],"names":[],"mappings":"AAAA,OAAO,KAA6E,MAAM,OAAO,CAAC;AA6BlG,OAAO,EAAE,qBAAqB,EAAc,MAAM,mBAAmB,CAAC;AA2OtE,eAAO,MAAM,gBAAgB,EAAE,KAAK,CAAC,EAAE,CAAC,qBAAqB,CA29B5D,CAAC;AAEF,eAAe,gBAAgB,CAAC"}
+{"version":3,"file":"SingleDatePicker.d.ts","sourceRoot":"","sources":["../../../src/Components/DatePicker/SingleDatePicker.tsx"],"names":[],"mappings":"AAAA,OAAO,KAA6E,MAAM,OAAO,CAAC;AA6BlG,OAAO,EAAE,qBAAqB,EAAc,MAAM,mBAAmB,CAAC;AA2OtE,eAAO,MAAM,gBAAgB,EAAE,KAAK,CAAC,EAAE,CAAC,qBAAqB,CAg+B5D,CAAC;AAEF,eAAe,gBAAgB,CAAC"}