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

package/.cursor/hooks/task-skill-nudge.sh

@@ -1,71 +0,0 @@
-#!/usr/bin/env bash
-# Block first message without / task skill; flag session for status-line warning. Zero tokens.
-set -euo pipefail
-
-STATE_FILE="${HOME}/.cursor/pixelize-skill-session-state.json"
-SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-# shellcheck disable=SC1091
-source "$SCRIPT_DIR/task-hint.env"
-
-INPUT=$(cat)
-PROMPT=$(echo "$INPUT" | jq -r '.prompt // empty')
-CONV_ID=$(echo "$INPUT" | jq -r '.conversation_id // empty')
-
-if [[ -z "$CONV_ID" ]]; then
-  echo '{"continue":true}'
-  exit 0
-fi
-
-has_skill() {
-  echo "$PROMPT" | grep -qiE '^\s*/(task|crm-task|social-task|tickets-task|crm-mobile-task|design-task|hrms-task)\b'
-}
-
-ensure_state_file() {
-  mkdir -p "$(dirname "$STATE_FILE")"
-  [[ -f "$STATE_FILE" ]] || echo '{}' >"$STATE_FILE"
-}
-
-update_state() {
-  local first_nudge="$1"
-  local chatting="$2"
-  ensure_state_file
-  local tmp
-  tmp=$(mktemp)
-  jq --arg id "$CONV_ID" \
-    --argjson first "$first_nudge" \
-    --argjson chatting "$chatting" \
-    '.[$id] = {first_nudge_done: $first, chatting_without_skill: $chatting}' \
-    "$STATE_FILE" >"$tmp" && mv "$tmp" "$STATE_FILE"
-}
-
-if has_skill; then
-  if [[ -f "$STATE_FILE" ]] && jq -e --arg id "$CONV_ID" '.[$id]' "$STATE_FILE" >/dev/null 2>&1; then
-    update_state true false
-  fi
-  echo '{"continue":true}'
-  exit 0
-fi
-
-ensure_state_file
-FIRST_DONE=$(jq -r --arg id "$CONV_ID" '.[$id].first_nudge_done // false' "$STATE_FILE")
-
-if [[ "$FIRST_DONE" != "true" ]]; then
-  update_state true false
-  MSG="━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  NO TASK SKILL LOADED
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-You are chatting WITHOUT a pipeline skill.
-
-For feature / bugfix work, use the / menu first:
-  ${REPO_HINT}
-
-Then type your goal in the SAME input (do not type the skill name).
-
-Send this message AGAIN to continue without a skill."
-  jq -n --arg msg "$MSG" '{continue: false, user_message: $msg}'
-  exit 0
-fi
-
-update_state true true
-echo '{"continue":true}'

package/.cursor/hooks/task-slash-guard.sh

@@ -1,31 +0,0 @@
-#!/usr/bin/env bash
-# Blocks plain-text task skill names (not / menu picks). Zero API tokens.
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-# shellcheck disable=SC1091
-source "$SCRIPT_DIR/task-hint.env"
-
-INPUT=$(cat)
-PROMPT=$(echo "$INPUT" | jq -r '.prompt // empty')
-
-# Menu picker embeds "/tickets-task ..." in prompt; attachments stay empty.
-# Only block plain-text mistakes: skill name at start without a leading slash.
-if echo "$PROMPT" | grep -qiE '^\s*@?(task|crm-task|social-task|tickets-task|crm-mobile-task|design-task|hrms-task)\b'; then
-  MSG="⚠️  TASK PIPELINE NOT ACTIVE
-
-You typed a task command as plain text. The skill was NOT loaded.
-
-To run the pipeline:
-  1. Click the chat input
-  2. Type / and pick the skill from the menu
-  3. Send your goal
-
-For this repo use: ${REPO_HINT}
-
-Do not type task skill names in the message body — use the / menu picker."
-  jq -n --arg msg "$MSG" '{continue: false, user_message: $msg}'
-  exit 0
-fi
-
-echo '{"continue":true}'

package/.cursor/hooks.json

@@ -1,13 +0,0 @@
-{
-  "version": 1,
-  "hooks": {
-    "beforeSubmitPrompt": [
-      {
-        "command": ".cursor/hooks/task-slash-guard.sh"
-      },
-      {
-        "command": ".cursor/hooks/task-skill-nudge.sh"
-      }
-    ]
-  }
-}

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

@@ -1,41 +0,0 @@
-# Account Management
-
-## Purpose
-
-Account/admin-facing components: UserDetails, RolesPermission, CustomModulesTable, SignInActivityTable, OrganizationDetails, OrgSwitcher, UpgradeButton.
-
-## Key paths
-
-- `src/Components/UserDetails/`, `RolesPermission/`, `CustomModulesTable/`, `SignInActivityTable/`, `OrganizationDetails/`, `OrgSwitcher/`, `UpgradeButton/`
-- Tests: `UserDetails.test.tsx`, `RolesPermission.test.tsx`, `CustomModulesTable.test.tsx`, `SignInActivityTable.test.tsx`, `OrganizationDetails.test.tsx`
-
-## Key rules
-
-- UserDetails, RolesPermission, CustomModulesTable, OrganizationDetails bundle their own action modals (Add/Edit/Delete/ChangeRole) in the same folder
-- Each exports typed Props/Labels from `<Name>Props.tsx` via `src/index.ts` — keep props API-generic, no CRM/API logic in the library
-- Labels are injectable for i18n; consumers pass data and handlers (props in, events out)
-
-## Dark mode
-
-- Every component here reads colors via `useCustomTheme()`, so all follow the active light/dark palette
-- Tables/detail views alias tokens once at the top — `border`/`surface`/`muted`/`heading`/`headBg` from `boxborder[200]`/`background[50]`/`gray[500]`/`gray[800]`/`gray[50]`; reuse those names when adding UI
-- `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}`; 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`
-  with no explicit `bg=`, hitting the same Chakra-hardcoded-`colors.white`-behind-`_dark` bug as
-  `Modal`/`AlertDialog` (overlays module) and `Drawer` (layout-navigation module). Fixed with
-  `bg={colors?.background?.[50]}` (`colors` was already destructured from `useCustomTheme()` in
-  every one of these files, so no new hook import was needed).

package/.cursor/modules/buttons/MODULE.md

@@ -1,47 +0,0 @@
-# Buttons
-
-## Purpose
-
-Button, ButtonGroupIcon, Buttons variants.
-
-## Key paths
-
-- `src/Components/Button/`, `ButtonGroupIcon/`, `Buttons/`
-
-## Key rules
-
-- Match Chakra button theming via design tokens
-- `Button.styles.ts` variants are `({ theme })` functions reading `theme.colors` — no hex
-  literals, so they follow whichever palette the theme carries (light or dark)
-- Filled labels (`solid` bg, and `outline`/`ghost` hover/active fills) no longer hardcode
-  `theme.colors.white` — they pick ink via `onFilled(fill, white, black)`
-  (`Theme/tokens/builders/accentText.ts`), which provably clears AA 4.5 by preferring white and
-  falling back to black only when the fill itself can't carry white. Never use white for a button
-  *surface* either way
-
-## Dark mode
-
-- `outline` / `ghost` / `link` text sits on the canvas, so it goes through
-  `accentTextOnCanvas(scale, colors.backgroundColor.main)` instead of `[500]` directly.
-  `[500]` is pinned dark enough to carry a white label on `solid`, leaving it ~4.2 as text on
-  the dark canvas; the helper steps to a lighter rung there to clear AA 4.5. Light canvases
-  return `[500]` unchanged, so existing apps are pixel-identical.
-- **Ghost hover gotcha:** brand scales are *lifted* for dark, not reversed, so `primary[50]`
-  stays near-white — a white chip on a near-black canvas. On dark canvases the hover/active
-  tint uses the translucent `scale.opacity[16]` / `[24]` so it composites over the canvas.
-  Only brand scales carry `opacity`; utility scales (red, green…) fall back to `[50]`, which
-  is already dark because those scales *are* reversed for dark.
-- **Solid/outline label-ink fix:** `Button.styles.ts` derives each state's label from *that
-  state's* fill (`labelFor`, per hover/active/loading) instead of assuming white always works —
-  some brands' dark `primary[500]` fails AA against white (radiant/emerald/rosewood measure
-  4.37/3.38/3.46) and now fall back to black. `Button.styles.test.ts` verifies this with real
-  `contrastRatio` checks per brand rather than asserting a fixed white label.
-- **ButtonGroupIcon menu bug (new, generalizable):** Chakra's `MenuItem` baseStyle renders
-  `background: var(--menu-bg)` at rest, and `MenuList`'s baseStyle hardcodes that var to `#fff`
-  behind `_dark` — which this app's theme-swap dark mode (palette swapped, Chakra `colorMode`
-  stays `"light"`) never triggers. Setting `bg=` on `MenuList` alone recolors the list but not the
-  inherited var, so items rendered white at rest until hover/focus masked it. Fixed here via
-  `sx={{ "--menu-bg": theme.colors.backgroundColor.light }}` alongside `bg=`.
-  - **Known gap:** any other Chakra `Menu`/`Popover` usage is at risk of the same bug. A known
-    remaining instance — `Trail`/`EditableCell.tsx` (data-display module) — is **not fixed** in
-    this pass.

package/.cursor/modules/cards/MODULE.md

@@ -1,55 +0,0 @@
-# Cards
-
-## Purpose
-
-Card, PaymentCard, ProfileCard, ProductCard, ProductDetails.
-
-## Key paths
-
-- `src/Components/Card/`, `Card/PaymentCard/`, `ProfileCard/`, `ProductCard/`, `ProductDetails/`
-
-## Key rules
-
-- ProfileCard has Header/Body/Footer subcomponents
-
-## Dark mode
-
-PaymentCard, ProductCard, ProductPrice, ProductDtlPrice and ProductImageSlider read their colors
-from `useCustomTheme()` instead of hex literals, so they follow the active light/dark palette.
-
-- Surfaces use `colors.background[50]`, never `colors.white` — `white` is a foreground token and
-  stays white in dark. Covers the card body, the ProductPrice dropdown panel and its radio dot,
-  the unselected pack chip in ProductDtlPrice, and the play-button circle in ProductImageSlider.
-- PaymentCard's badge/button label no longer hardcodes `colors.white` — it's picked per
-  `buttonColor` via `onFilled()` (`Theme/tokens/builders/accentText`), which falls back to
-  `colors.black` when white would fail AA on that fill. Guarantees WCAG AA across the
-  active/upgrade/popular/default button colors instead of assuming white always works.
-- The product components keep Chakra literals for offer/pack chrome (`red.50`, `orange.50`,
-  `green.100`). Those are dark-aware already — the theme carries the palette as `colors`, and
-  `buildDarkPalette` reverses utility hue ramps so index roles survive (`red.50` = pale badge
-  background in light, deep in dark). They track the hue, not the brand accent.
-- ProductPrice's struck-through original price bumped `gray.400` → `gray.500` (still a raw
-  Chakra literal, not a theme token) for AA contrast against the card surface.
-- ProductTags' label swapped `colors.black` → `colors.text[900]` (mode-adaptive ink token) so it
-  stays legible in dark mode.
-- **Known gap:** ProductReview's rating chip (`bg="teal.50"` / `color="teal.900"`) and its star
-  fill (`RATING_STAR_FILL`, a pinned `#ECC94B` hex — see in-file comment) are still raw
-  Chakra/hex literals, not `useCustomTheme()` tokens. Pre-existing pattern, not worsened by this
-  pass, but won't track brand hue or dark mode — needs a mode-stable "rating gold" token added to
-  `pixelize-design-library` before this can move off literals.
-
-## WCAG contrast pass (Wave D, QA-driven)
-
-- **ProductPrice.tsx** — dropdown-arrow `red.400` (on `red.50` canvas) and discounted/final-price
-  `red.500` text (on `red.50`/`background[50]` depending on selection state) failed AA (2.6-3.7:1).
-  Fixed via `accentTextOnCanvas(theme.colors.red, <the actual local canvas>)` at each of the 3
-  call sites, matching the canvas each already renders on (including the existing `isSelected`
-  bg ternary). The dot-fill `bg="red.500"` (a filled swatch, not text) was left unchanged — it
-  clears the 3:1 non-text bar against `background[50]`.
-- **ProductDtlPrice.tsx** — price `Text` hardcoded `theme.colors.red[500]` (≈3.46:1 vs the page
-  canvas, fails) and the pack-swatch `color="orange.600"` (≈2.47-2.67:1 vs either bg state,
-  fails) both routed through `accentTextOnCanvas`. `borderColor`/`bg` on the swatch button are
-  decorative and were left alone.
-- **ProductImageSlider.tsx** — checked, not changed: all 6 `theme.colors.red[500]` Play-icon
-  usages sit on an opaque `background[50]` circular scrim (not the raw image), so the applicable
-  bar is 3:1 (graphical object, not text) — clears at ≈3.68:1 light / ≈6.48:1 dark.

package/.cursor/modules/charts/MODULE.md

@@ -1,40 +0,0 @@
-# Charts
-
-## Purpose
-
-Apexcharts wrappers: Bar, Line, Pie, Polar.
-
-## Key paths
-
-- `src/Components/Apexcharts/ApexBarChart/`, `ApexLineChart/`, `ApexPieChart/`, `ApexPolarCharts/`
-- `src/Theme/tokens/builders/chartColorsFromTheme.ts` — shared chart color helpers (+ test)
-
-## Key rules
-
-- react-apexcharts; every color is a theme token, never a literal. Shared helpers:
-  `getDefaultSeriesColors` (primary / error / success / orange `500`), `mergeChartTitleStyle`
-  (title → `primary[500]`), `chartAxisLabelColor` (`gray[700]`). The rest read `palette` directly:
-  legend `text[900]` (Pie/Polar), Bar data labels `primary[500]`, Polar stroke `white`.
-- All four read `useTheme().colors` (cast to `CustomThemeProps["colors"]`) rather than styling via
-  Chakra props, because ApexCharts `options` need resolved hex **strings**.
-- The helper sits in the pure token layer: type-only imports, never Chakra/React (see CLAUDE.md).
-
-## Dark mode
-
-- Dark-aware for free — the theme swaps in the dark palette and these tokens re-resolve. No hex
-  literals remain under `Apexcharts/`.
-- Caller color props (`barColor`, `lineColors`, `chartColor`/`donutColors`, `chartColors`,
-  `titleStyle`, `legendStyle`) override the token defaults and are **not** dark-aware: a consumer
-  passing a hardcoded hex keeps it in both modes.
-- ApexPolarCharts `basic`/`monochrome` stroke slice borders with `colors.white` — foreground on a
-  filled slice, so it correctly stays white; not a missed `background[50]` surface.
-- All four now also set ApexCharts' own `options.theme.mode` (`"dark"`/`"light"`) from
-  `isDarkCanvas(palette.backgroundColor.main)` (`Theme/tokens/builders/accentText.ts`), so
-  ApexCharts' internal chrome (gridlines, built-in tooltip, etc.) follows the active canvas too,
-  not just the token-driven series/title/legend colors. No change to any chart's data/options
-  prop contract.
-- Removed `chartTooltipBackground`/`chartTooltipForeground` from `chartColorsFromTheme.ts` (they
-  always resolved to a hardcoded dark-styled tooltip — `gray[700]`/`white` — regardless of mode,
-  now unused repo-wide). `ApexLineChart`'s title-truncation `ToolTip` no longer overrides
-  `bg`/`color`; it defers to `ToolTip`'s own theme-aware default instead.
-- Known gap: titles/legends use `primary[500]` / `text[900]`, not the AA-safe `accentText` token.

package/.cursor/modules/common/MODULE.md

@@ -1,36 +0,0 @@
-# Common Helpers
-
-## Purpose
-
-Internal shared helpers under `Components/Common/` — not all exported from index.
-
-## Key paths
-
-- `src/Components/Common/` — ErrorComponent, FormLabel, etc.
-
-## Key rules
-
-- Internal use by other components; export only if needed publicly
-
-## Dark mode
-
-- **FormLabel** (`TextLabel`): both tooltips (`showTooltip` / `isInformation`) swapped
-  Chakra's own `Tooltip` for the library's `ToolTip` (`../ToolTip/ToolTip`), dropping the
-  hardcoded `bg={gray[600]}` / `color={white}` — `ToolTip` owns its own theme-aware
-  contrast (see `overlays` MODULE.md). No `TextLabel` prop changes.
-- **fieldStyles.ts** (`getFieldStateStyles`): idle border bumped `boxborder[500]` →
-  `boxborder[800]` — `[500]` failed WCAG 1.4.11 (>=3:1 non-text contrast) against
-  surfaces up to `muted`; `[800]` clears with margin. Focus/error ring colors and the
-  function signature are unchanged.
-- **ErrorMessage.tsx**, **ErrorComponent.tsx**, **FormLabel.tsx** (required-asterisk), **Label.tsx**:
-  error text color switched from a hardcoded `theme.colors.red[500]` / `semantic.error[500]` to
-  `accentTextOnCanvas(scale, canvas)` (`../../Theme/tokens/builders/accentText`) — `red[500]` alone
-  fails AA (~3.4:1) against the page canvas in every brand; see `theme` MODULE.md "Wave D" for why
-  this couldn't be a token retune. No prop/API changes.
-- **ErrorComponent.tsx's SVG mark ink (code-review catch):** the circle/rect/dot marks drawn on
-  top of the `errorFill` circle were hardcoded `theme.colors.white`. `errorFill` is tuned for
-  text-on-page-canvas contrast, not for "carries a white mark on top of itself" — those are
-  different constraints, and nothing guaranteed white would keep clearing AA there if the token
-  ever changed (it happened to today). Replaced with
-  `onFilled(errorFill, theme.colors.white, theme.colors.black)`, the same provably-always-safe
-  ink-on-a-filled-swatch helper used by FilterSidebar's checkmark and PaymentCard.

package/.cursor/modules/contact-auth/MODULE.md

@@ -1,19 +0,0 @@
-# Contact & Email
-
-## Purpose
-
-ContactForm, VerifyEmailOtp (EmailCards).
-
-## Key paths
-
-- `src/Components/ContactForm/`, `EmailCards/VerifyEmailOtp/`
-
-## Key rules
-
-- OTP flow UI only — API wiring in consumer apps
-
-## Dark mode
-
-- **VerifyEmailOtp**: `PinInputField` idle border bumped `boxborder[300]` → `boxborder[800]` —
-  `[300]` failed WCAG 1.4.11 (>=3:1 non-text contrast) against surfaces up to `muted`; `[800]`
-  clears with margin. Already theme-token-driven before this change; no prop/signature changes.

package/.cursor/modules/data-display/MODULE.md

@@ -1,42 +0,0 @@
-# Data Display
-
-## Purpose
-
-Tag, Timeline, Reorder, Divider, Trail.
-
-## Key paths
-
-- `src/Components/Tag/` — `Tag.tsx`, `TagProps.ts`, `Tag.styles.tsx` (registered in `Theme/componentStyles.ts`)
-- `Timeline/`, `Reorder/`, `Divider/`, `Trail/`
-- Demo: `src/Pages/tag.tsx`
-
-## Key rules
-
-- Timeline: each event card renders its manual notes from `event.notes` (`TimelineNote[]` — `log_note_id`, `title`, `note`, `attachments[]`, `created_by`, `created_at`). Adding a note is event-scoped via the per-card "Add note" button → `onAddNote(note, title, files, event, index)`; the consumer persists it against `event.logs_id` and re-supplies it back in `event.notes`. Attachments show as links opening `attachment.url`.
-- Timeline notes support edit + delete: hovering a note shows edit/delete icons → `onEditNote(logNoteId, note, title, files, event, index)` (inline `NoteTextArea`) and `onDeleteNote(logNoteId, event, index)` (consumer owns any confirm dialog). Loading props: `addNoteLoading`/`editNoteLoading` keep the editor open with a Save spinner until the request resolves (then auto-close); `deletingNoteId` shows a spinner on the note being deleted. With no loading props wired, the add editor closes immediately on submit (back-compat).
-- Trail includes editable cell demos
-- Tag styling lives in `Tag.styles.tsx` (Chakra component theme), not hardcoded in `Tag.tsx`
-- Tag sizes: `xs | sm | md | lg`; variants: `solid | outline | subtle`
-- Tag colors are token-driven from the active theme via `colorScheme` (brand `primary/secondary/tertiary` + global scales); palette resolution falls back to `gray` so a missing scale never throws
-- Tag `solid` variant label color is now `onFilled(fill, white, black)` (per state: base/hover/active), not a hardcoded `white` — picks whichever of white/black clears WCAG AA against that swatch, so it stays readable on light brand fills too
-
-## WCAG / dark-mode pass (this session)
-
-- **Tag.styles.tsx** — `solid` variant's foreground swapped from hardcoded `theme.colors?.white` to
-  `onFilled(fill, white, black)`, computed per bg (base `500`, hover `600`, active `700`); verified
-  against WCAG AA.
-- **Trail/EditableCell.tsx** — `priority` menu's `MenuButton` had a real hover-contrast fix: `bg`
-  `teal.500`/`color white` → `bg="teal.50"` / `color="teal.900"` (+ hover/active states). **Known
-  gap:** this uses raw Chakra `teal.*` literals, not `useCustomTheme()` tokens, so it won't track
-  brand hue or dark mode — needs a follow-up token pass.
-  - **Known gap (not fixed this pass):** the same `MenuList`/`MenuItem` still has no `bg=`/
-    `sx={{ "--menu-bg": ... }}` override, so Chakra's `--menu-bg` CSS var still resolves to its
-    hardcoded light-mode white regardless of this app's active dark mode — same root-cause bug
-    already fixed this session in `ButtonGroupIcon` (buttons module) and `NavigationBar`
-    (layout-navigation module). Deliberately deferred, not overlooked.
-
-## Dark mode
-
-- Timeline takes every color from `useCustomTheme()`, so it follows whichever palette the theme carries. Dark works by swapping the palette — there is no `_dark`/`semanticTokens` layer, so a hardcoded value would stay light forever.
-- White surfaces use `colors.background[50]`, **not** `colors.white` — `white` is a *foreground* token (label on a filled button) and stays white in dark. Covers Timeline's event card, date chip, and the node ring that punches each node out of the spine. (Timeline's inline `NoteTextArea` is owned by `inputs-basic`.)
-- Timeline's remaining `?? "#fff"` fallbacks are defensive only — every brand palette defines `background[50]` (dark included, derived by `buildDarkPalette`).

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

@@ -1,38 +0,0 @@
-# Feedback
-
-## Purpose
-
-Loading, Skeletons, ProgressBar, Notification, FeedbackForm.
-
-## Key paths
-
-- `src/Components/Loading/`, `Skeletons/`, `ProgressBar/`, `Notification/`, `FeedbackForm/`
-- `src/services/feedback.ts`
-
-## Key rules
-
-- FeedbackForm may POST to account API in consumer apps — keep props generic
-
-## 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
-  forcing a white card in dark mode), not a plain refactor. Consumers passing `colors.bgColor`
-  explicitly are unaffected.
-- **`warningColor`/`errorColor`/`successColor` object-vs-string bug (QA-adjacent, real correctness
-  bug, not WCAG):** `NotificationProps` types these as hex strings, but the defaults were an
-  un-indexed whole `ColorScale` object (`theme.colors.semantic.warning` instead of
-  `theme.colors.semantic.warning[500]`) — Chakra silently can't render an object as a `bg=` color,
-  so the default (no-override) case was broken. Fixed by indexing `[500]` on all three defaults.
-- **Time-elapsed icon/label AA gap:** the "time ago" `Icon`/`Text` defaulted to `orange.400`/
-  `orange.500`, which fail AA (~1.9–2.2:1) against `bgColor` in every brand — same class of bug as
-  the `error`/`red[500]` gap (theme module). Fixed by routing both through
-  `accentTextOnCanvas(theme.colors.orange, bgColor)` (`Theme/tokens/builders/accentText`) instead
-  of a fixed rung.

package/.cursor/modules/form/MODULE.md

@@ -1,13 +0,0 @@
-# Form
-
-## Purpose
-
-FormWrapper — shared form layout wrapper for entity forms in CRM apps.
-
-## Key paths
-
-- `src/Components/Form/FormWrapper`
-
-## Key rules
-
-- Used with smart forms in crm-frontend; keep generic props

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

@@ -1,42 +0,0 @@
-# Basic Inputs
-
-## Purpose
-
-TextInput, PhoneNumberInput, InputTextArea, NoteTextArea, NumberInput, PinInput, PinInputs.
-
-## Key paths
-
-- `src/Components/Input/`, `InputTextArea/`, `NoteTextArea/`, `NumberInput/`, `PinInput/`, `PinInputs/`
-
-## Key rules
-
-- InputSwitch in `Input/Switch/`
-
-## Dark mode
-
-- No hex literals remain — every field follows the active palette, but by three paths, not one:
-  `useCustomTheme()` (TextInput, PhoneNumberInput, NoteTextArea, PinInput, InputSwitch), Chakra
-  `useTheme()` (Input/Input, PinInputs), and `componentStyles` `({ theme })` fns (InputTextArea,
-  NumberInput — no theme hook at all). The `?? "gray.300"` fallbacks in `*.styles.ts` are token
-  refs, not literals: `createBrandTheme` sets `colors: palette`, so they resolve against the
-  swapped palette.
-- `NoteTextArea` was the only migration here: its 4 white surfaces moved `colors.white` →
-  `colors.background[50]`. `colors.white` is a **foreground** token (a label on a filled button)
-  and stays white in dark; a white *surface* needs `background[50]` (identical `#ffffff` in light).
-- `InputSwitch` layers `useColorModeValue` over the palette swap — it picks a different *rung*
-  (`primary[500]`→`[300]`, `gray[300]`→`[600]`) of the already-dark palette, not a second palette.
-
-## Border contrast bump ([500]/[700] → [800])
-
-- Follow-up fix: `boxborder` at `[500]`/`[700]` only cleared canvas-level surfaces (main/base)
-  and failed WCAG 1.4.11 (control boundary, >=3.0) against `muted`, the lightest named surface
-  (2.41-2.72). All seven fields — `Input/Input.tsx`, `TextInput.styles.ts`,
-  `InputTextArea.style.tsx`, `NumberInput.styles.ts`, `PinInput.tsx`, `PinInputs.tsx`,
-  `NoteTextArea.tsx` — now use `boxborder?.[800]` for the resting/default border, clearing all
-  12 named surfaces (3.44-3.90) in both modes.
-- `Input/Input.tsx` also swapped its label/accent color from `colors.secondary?.[500]` to
-  `accentTextOnCanvas(colors.secondary, colors.backgroundColor?.main)` — relies on the shared
-  `accentText.ts` guard (Theme module) for safety when rendered without a full Pixelize theme;
-  no separate fix was needed in this file.
-- `Input/Input.tsx` is **not** exported from `src/index.ts` (internal, used only by
-  `src/Pages/TInput.tsx`) — low external impact.

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

@@ -1,67 +0,0 @@
-# Date & Files
-
-## Purpose
-
-ThemeDatePicker (Single/Range/Time variants), FileUpload, FileUploader, Editor (jodit-react).
-
-## Key paths
-
-- `src/Components/DatePicker/` — `ThemeDatePicker.tsx` (public entry), `SingleDatePicker.tsx`, `RangeDatePicker.tsx`, `TimePicker.tsx`, `TimeOnlyPicker.tsx`, `CalendarPanel.tsx`
-- `src/Components/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.
-- **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
-  orange gap). Fixed via `accentTextOnCanvas(colors.blue, colors.backgroundColor?.main ?? "#ffffff")`
-  (`Theme/tokens/builders/accentText`), reused for both spots. Rest of the component (drag/drop
-  chrome, file-row chips) is still Chakra scale literals (`gray.*`), not migrated to
-  `useCustomTheme()` — out of scope for this pass since those are already dark-aware Chakra
-  literals (see table/account-management MODULE.md for why plain `gray.*` literals already track
-  the swapped palette).
-- Editor is now theme-aware: it reads `theme.colors.backgroundColor?.main` (with a `"#ffffff"` fallback added after a code-review-caught crash risk) via `isDarkCanvas()` to switch Jodit's own internal `dark`/`default` editor theme — it does not restyle Jodit itself, just picks which built-in Jodit theme renders. FileUpload does use theme (`useCustomTheme()`: `gray`, `red`, `blue`, `background`, `secondary.opacity`) but was not migrated — **known gap**: `FileUpload.tsx:153` paints the uploaded-file row `bg={colors?.white}`, a *surface* on the foreground token, so it stays white in dark mode; should be `background[50]`.
-- **Editor dark-mode "not black" bug (user-reported, fixed):** toggling Jodit's `config.theme` between `"dark"`/`"default"` only switches which of Jodit's OWN CSS selectors apply (`.jodit_theme_dark`, 180+ occurrences in `jodit.css`) — those selectors are still driven by Jodit's own hardcoded CSS custom properties (`--jd-dark-background-color: #575757`, a mid-gray, not black; `--jd-color-border-selected: #1e88e5`, generic blue), never fed this library's palette. Fixed in `Editor.tsx` by wrapping `<JoditEditor>` in a `<Box sx={...}>` carrying `getJoditThemeVars(theme.colors, isDark)` (`joditThemeVars.ts`) — inline CSS custom properties, scoped to this instance only (no `:root` leak onto other Jodit instances). Mapping: canvas/toolbar → `backgroundColor.main`/`.secondary`, ink → `text[900]`, icons → `text[700]`, hover/select-bg → `backgroundColor.muted`, border → `boxborder[500]`, accent → `primary[500]` — reusing the SAME role-stable tokens in both modes (`background[50]`/`text[900]` etc. already flip lightness internally per `buildDarkPalette.ts`, so no per-mode branching on VALUES, only on the `--jd-color-*` vs `--jd-dark-*` variable NAMES Jodit's default vs dark theme actually reads). Verified via Playwright: before showed `rgb(87,87,87)` (`#575757`, Jodit's default) on the canvas/toolbar in dark mode; after shows the brand's real near-black surface. Regression tests: `joditThemeVars.test.ts` (contrast + non-default-value assertions, lavender + rosewood).
-- **Editor popup/dialog portal gap (user-reported follow-up on the fix above, fixed):** the "Known gap" this section used to note — Jodit appends dialogs and toolbar-dropdown popups (search & replace, image/link properties, font-size list, paragraph format, …) directly to `document.body` (`Dialog.destination` / `getPopupViewRoot` in jodit core), outside the CSS-variable wrapper's DOM subtree, so they kept rendering in Jodit's default (light, unthemed) styling even in dark mode — was reported again as "hovering [in the] editor is not following WCAG standards." Traced via `node_modules/jodit/es2021/jodit.css`: the main toolbar's own `:hover` rule (`.jodit_theme_dark .jodit-toolbar-button:hover`) already clears AA/AA-non-text comfortably once `--jd-dark-background-color`/`--jd-dark-icon-color` are mapped (verified numerically — computed contrast ~10:1+ across all 8 brands, not touched), so the actual gap was specifically the portalled popups never inheriting `themeVars` at all. Fixed by wiring Jodit's own `config.popupRoot` (a supported, documented option — `node_modules/jodit/esm/config.d.ts`: `popupRoot: Nullable<HTMLElement>`) to the wrapper `<Box>`'s own DOM node via a callback ref (`useState<HTMLElement | null>` + `ref={setPopupRoot}` on the `Box`), so `Dialog.destination` resolves to the themed wrapper instead of `document.body` and every popup/dialog now inherits the same CSS custom properties as the toolbar/canvas. Regression test: `Editor.test.tsx` (mocks `jodit-react` to assert `config.popupRoot` is a real DOM node, not `null`/`document.body`). One TS gotcha hit while wiring this: adding a literal `popupRoot` key alongside `...config` (typed `DeepPartial<Config>`, Jodit's huge recursive config type) triggered `TS2589: Type instantiation is excessively deep` — worked around by spreading `config` as `Record<string, unknown>` before the final `as EditorProps["config"]` assertion, since the plain literal-plus-spread pattern is otherwise unaffected (see comment in `Editor.tsx`).
-- **Editor dialog inputs/search-panel/button-hover still unthemed (QA follow-up round, fixed):** the
-  `popupRoot` fix above got popups into the themed DOM subtree, but 3 more Jodit CSS variables were
-  still unmapped: `--jd-color-panel` (search & replace box background — only set in the light
-  branch, so dark mode fell to Jodit's own `#f9f9f9`, a near-white panel), `--jd-color-white` /
-  `--jd-color-gray` (`.jodit-ui-input__input` / `.jodit-ui-select__input` background — Jodit's own
-  raw white default, unmapped in either mode; `-gray` is what the `_theme_dark`-suffixed variant
-  reads instead of `-white`, and dialogs don't reliably get that modifier class). Traced each via
-  `node_modules/jodit/es2021/jodit.css` line-by-line before touching anything. Also found (via a
-  throwaway jest contrast computation, not assumed): the toolbar/dialog-button hover fill and the
-  `.jodit-select`/`.jodit-input` background both already mapped to `--jd-dark-background-ligher:
-  colors.backgroundColor.muted` — computed at ~1.3:1 against the canvas, a near-miss that had
-  actually shipped (both values sit within ~11 lightness points of each other down near L7-18, where
-  WCAG contrast collapses non-linearly) — this was the QA-reported "Insert button illegible on
-  hover." Fixed in `joditThemeVars.ts`: `--jd-color-panel` moved into `shared` (role-stable, same
-  `backgroundColor.secondary` expression already correct for light); `--jd-color-white:
-  background[50]` added to `shared`; `--jd-color-gray: background[50]` added to the dark branch;
-  `--jd-dark-background-ligher` changed to `background[900]` (this palette's dark-mode "bright
-  highlight" rung, ~9.7-10.7:1 against the canvas across brands — verified before applying, not
-  guessed). Confirmed via `node_modules/jodit/es2021/jodit.css` that `.jodit_theme_dark` /
-  `.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
-
-- DatePicker public export moved: `DatePicker/DatePicker` → `DatePicker/ThemeDatePicker` (exported as `DatePicker` from `src/index.ts`)
-- Split into Single/Range/Time picker variants under the same folder
-- Picker tests build their Chakra theme from `Theme/tokens/brands/lavender/palette.light` (was `Theme/Default/palette`)