hazo_ui 4.9.0 → 5.1.1

package/CHANGE_LOG.md

@@ -5,6 +5,144 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## v5.1.0 (2026-07-10)
+
+### New
+- **`HazoUiKanban` card editor: `richtext` field type** — `editorFields` now
+  accepts `type: 'richtext'`, which renders the package's existing
+  `HazoUiRte` (`hazo_ui_rte`) in place of a plain text input. No new
+  dependency — TipTap was already required by this package. Binds to a
+  string HTML key on the item; `on_change` writes `RteOutput.html` back
+  into the draft. As with `select`/`checkbox`, `required` gating is not
+  honored for `richtext` (an "empty" RTE still emits `<p></p>`, not `""`).
+  Auto-detected fields are unaffected — `richtext` is opt-in via
+  `editorFields` only.
+- **`HazoUiKanban`: double-click to open the card editor** — double-clicking
+  a card now opens the same editor as the pencil icon, gated by the same
+  `showEdit`/`onEditRequest` props (no new prop). PointerSensor's 5px drag
+  activation distance means this doesn't interfere with drag-and-drop.
+
+## v5.0.0 (2026-07-09)
+
+### BREAKING — theming rehomed onto hazo_theme
+hazo_ui no longer owns theme tokens, a Tailwind preset, or its own theme
+provider — `hazo_theme` is now the single source, and is a **required** peer
+dependency (was optional).
+
+- **Removed exports:** `./styles.css` and `./tailwind-preset` package exports
+  are gone (`dist/styles.css`, `tailwind.preset.js` no longer ship). Import
+  `hazo_theme/theme.css` (+ optionally a `hazo_theme/themes/<name>.css` brand
+  palette) in your app's globals instead of `hazo_ui/styles.css`.
+- **`useTheme()` return shape changed:** `{ theme, setTheme, resolvedTheme,
+  toggleTheme }` → `{ mode, setMode, resolvedMode, toggleMode, themeSet,
+  setThemeSet }`. `HazoThemeProvider`'s `defaultTheme` prop is now
+  `defaultMode`; add `defaultThemeSet` to opt into a shipped brand palette.
+  `Theme`/`ThemeProviderProps`/`ThemeContextValue` types are removed — use
+  `ThemeMode`/`HazoThemeProviderProps`/`HazoThemeContextValue` from
+  `hazo_theme/client` (re-exported from the `hazo_ui` root).
+- **New export:** `ThemeSetPicker`, re-exported from `hazo_theme/client`,
+  lets consumers switch between shipped theme-sets (`indigo-sunset`,
+  `ops-dark`, `soft-studio`, ...) at runtime.
+- **Persisted-preference reset (one-time):** the localStorage key changed
+  from `"theme"` to `"hazo-theme"` (with `-mode`/`-set` suffixes), so a
+  user's saved theme choice resets to `"system"` once after upgrading.
+- **hazo_ui's own kanban tokens deleted** (`--hazo-kanban-*` in
+  `src/styles/globals.css`) — now sourced from `hazo_theme`'s Tier-1 tokens
+  (`hazo_theme@^0.2.0`), same values, zero visual change, but consumers
+  MUST import `hazo_theme/theme.css` for kanban components to render with
+  the intended colors (previously baked into `hazo_ui`'s own CSS).
+- **Migration:** bump to `hazo_theme@^0.2.0` (now required, not optional),
+  swap `hazo_ui/styles.css` → `hazo_theme/theme.css` in your globals, and
+  update any `useTheme()`/`HazoThemeProvider` call sites for the
+  `theme`→`mode` rename.
+
+## Unreleased
+
+### New
+- **`Logo`, `AppHeader`, `AppFooter` chrome components** (framework-neutral,
+  `"use client"`) — consume hazo_theme's `BrandIdentity` contract (type-only
+  import) plus the new `footer-public-*`/`footer-app-*` chrome tokens:
+  - `Logo({ logoUrl?, logoUrlDark?, appTitle?, href?, height?, className?,
+    imgClassName? })` — renders the light/dark logo image (swapped via
+    `dark:hidden`/`dark:block`), falling back to `appTitle` as text when no
+    `logoUrl` is set. Prop names intentionally mirror `BrandIdentity`'s fields
+    so a caller can spread an identity object directly: `<Logo {...identity}
+    />`.
+  - `AppHeader({ identity?, homeHref?, navItems?, actions?, className? })` — a
+    `bg-navbar`/`text-navbar-fg` header bar wrapping `Logo` plus nav/actions
+    slots.
+  - `AppFooter({ variant: 'public' | 'app', footer?, identity?, className? })`
+    — `'app'` renders the thin `bg-footer-app` strip (copyright + one link
+    row); `'public'` renders the taller multi-column `bg-footer-public` block
+    (brand row, link columns, social links), reading from `footer` or falling
+    back to `identity.footer[variant]`.
+  - All three are new exports from the package root; `hazo_theme` stays an
+    optional peer — the components don't import runtime code from it, only
+    the `BrandIdentity`/`FooterConfig` types.
+- **`safeHref(url?: string): string | undefined`** exported from the package
+  root — scheme-allowlist for admin-configurable hrefs (`http://`, `https://`,
+  `mailto:`, or a same-origin `/path` that isn't protocol-relative `//host`;
+  anything else, including `javascript:`/`data:`, returns `undefined`). Every
+  `<a href>` sink inside the new chrome components (footer links, social
+  links) runs through it — XSS hardening for hrefs sourced from
+  admin-editable branding data.
+- **`HazoUiDialog` header bar is now token-driven** — the header bar
+  background/foreground (previously hardcoded `#1e293b` background / white
+  text) now default to hazo_theme's `--dialog-header-bar-bg` /
+  `--dialog-header-bar-fg` tokens, and respect the existing per-variant
+  tinting (`headerColor`/`kind`) the same way the rest of the dialog does.
+- **`HazoUiDialog` `kind` prop** (PRD hazo_theme §5.7) — orthogonal rendering/behavior
+  profile: `'form' | 'confirm' | 'status' | 'content'`. `kind` is a discriminated
+  union on `HazoUiDialogProps`: `title` is a required `string` for `'form'`/`'confirm'`,
+  and stays optional (defaulting to `"Action required"`) for `'status'`/`'content'`/
+  omitted — omitting `kind` entirely is byte-for-byte the pre-existing default
+  behavior (regression guard, verified via `npm run build` + `type-check`).
+  - `'form'` — comfortable body/label typography via the hazo_theme
+    `--dialog-body-size` / `--dialog-label-size` tokens.
+  - `'confirm'` — the compact centered-card layout previously hardcoded into
+    `HazoUiConfirmDialog` (see below).
+  - `'status'` — tinted header (via `--dialog-<variant>-bg/-fg`) with a single
+    acknowledge button (`showCancelButton=false`, `actionButtonText="OK"` by
+    default); `closeOnConfirm` defaults to `true` (self-closing) for this kind.
+  - `'content'` — unchanged sticky header/footer + scrollable body (this was
+    already the default structure).
+- Added optional peer dependency `hazo_theme@^0.1.0` (`peerDependenciesMeta.hazo_theme.optional = true`).
+  hazo_ui does not import from hazo_theme; the `--dialog-*` CSS custom
+  properties referenced below only resolve when the CONSUMING app imports
+  `hazo_theme/tokens.css`.
+
+### Changed
+- **`HazoUiConfirmDialog` is now a thin wrapper** over `<HazoUiDialog kind="confirm">`.
+  Its exported `HazoUiConfirmDialogProps` interface and `ConfirmDialogVariant` type
+  are UNCHANGED — zero prop-level breaking changes for existing consumers
+  (verified: `hazo_pay`'s `billing_admin_panel.tsx` and `hazo_config`'s
+  `app_config_list_editor.tsx` both still build with no changes on their end).
+  One documented behavior simplification: the old component allowed
+  independently-colored `accentColor` (border) vs. `confirmButtonColor` (button);
+  the new wrapper folds both into a single accent (`confirmButtonColor` wins if
+  both are set), since no known consumer relied on divergent values.
+- **`VARIANT_PRESETS` (dialog) / `CONFIRM_VARIANT_PRESETS` (confirm dialog,
+  now deleted) hardcoded RGB → hazo_theme `--dialog-*` tokens.** This is a
+  **visual-only change** — flag it as a **major version bump** on the next
+  publish, since dialog/confirm-dialog appearance shifts for any consumer.
+  - Consumers that already import `hazo_theme/tokens.css` get the intended,
+    theme-consistent look automatically (dark/light + brand theme-sets).
+  - Consumers that do NOT import `hazo_theme/tokens.css` degrade gracefully:
+    an undefined CSS custom property used inside `hsl(var(--undefined-var))`
+    (or referenced directly, for the pre-wrapped `--dialog-<variant>-bg/-fg`
+    tokens) produces an invalid color value, which browsers simply ignore —
+    falling back to the previous/inherited value (e.g. transparent background,
+    inherited text color) rather than crashing or rendering `red`/broken
+    styles. Net effect: variant tinting silently disappears, dialogs still
+    render and function correctly. **Action for consumers wanting the
+    intended look: import `hazo_theme/tokens.css`.**
+  - hazo_theme exposes exactly one bg + one fg token per status (no separate
+    "header" vs. "description" shade), so the old two-tone split-header effect
+    is flattened to a single shade per variant.
+  - `kind="status"`/`kind="confirm"` at `variant="default"` (no per-status
+    token pair exists for "default") fall back to a neutral tint derived from
+    `--dialog-border` / `--dialog-fg` instead of leaving the header untinted.
+
 ## v4.9.0 (2026-07-06)
 
 ### New

package/README.md

@@ -3707,12 +3707,19 @@ on hover/focus). Clicking it opens a `HazoUiDialog` editor:
 
 Field types: `text`, `textarea`, `select`, `number`, `checkbox`,
 `priority` (a select pre-populated with `editorPriorities` —
-defaults to `["P0","P1","P2","P3"]`).
+defaults to `["P0","P1","P2","P3"]`), `status` (a select pre-populated
+from `columns`, bound to `columnKey`), and `richtext` (renders the
+package's `HazoUiRte` rich text editor — binds to a string HTML key;
+`required` gating is not honored for this type, same as `select`/
+`checkbox`).
 
 If you don't pass `editorFields`, the library auto-detects all
 string-valued fields on the item (except `id`, `columnKey`, `priority`)
 and renders each as a text input with a humanized label.
 
+Besides the pencil icon, **double-clicking a card** also opens the
+editor — same `onCardSave`/`editorFields` config, no extra prop needed.
+
 #### Custom form via renderCardEditor
 
 When the declarative config isn't enough, replace the dialog body