@godxjp/ui 33.22.1 → 33.24.0

package/dist/tokens/components/badge.css

@@ -13,6 +13,9 @@
   --badge-min-height: initial;
   --badge-outline-foreground: initial;
 
+  --badge-agent-border: initial;
+  --badge-agent-foreground: initial;
+
   --badge-icon-size: var(--icon-size-xs);
 
   --badge-space-x-removable: var(--space-1);

package/dist/tokens/components/data-display.css

@@ -144,6 +144,15 @@
   --avatar-presence-busy-color: initial;
   --avatar-presence-offline-color: initial;
 
+  --avatar-agent-font-size: initial;
+  --avatar-agent-font-weight: initial;
+  --avatar-agent-padding-inline: initial;
+  --avatar-agent-inset: initial;
+  --avatar-agent-ring-width: initial;
+  --avatar-agent-background: initial;
+  --avatar-agent-foreground: initial;
+  --avatar-agent-ring-color: initial;
+
   --progress-track-background: initial;
   --progress-track-background-alpha: initial;
   --progress-fill-background: initial;

package/dist/tokens/components/shell.css

@@ -100,6 +100,8 @@
   --app-shell-bar-inset-compact: var(--space-page-compact-x);
   --app-shell-bar-gap: var(--space-3);
 
+  --app-shell-rail-gap: var(--space-3);
+
   --app-shell-brand-max-inline-size: none;
   --app-shell-brand-compact-max-inline-size: var(--app-shell-bar-height);
 

package/dist/tokens/foundation.css

@@ -41,6 +41,10 @@
   --attention: 25 99% 46%;
   --attention-foreground: 48 8% 13%;
 
+  --agent: 262 83% 58%;
+  --agent-foreground: 0 0% 100%;
+  --text-agent: 263 70% 50%;
+
   --brand: 240 6% 10%;
   --brand-foreground: 60 33% 99%;
 
@@ -383,6 +387,10 @@
     --attention: 25 95% 56%;
     --attention-foreground: 48 9% 9%;
 
+    --agent: 262 83% 58%;
+    --agent-foreground: 0 0% 100%;
+    --text-agent: 252 95% 85%;
+
     --brand: 0 0% 98%;
     --brand-foreground: 48 9% 9%;
 

package/docs/CONSUMER-RULES.md

@@ -7,7 +7,7 @@ should look like) is in the package's `DESIGN.md`. Everything else in `docs/` is
 2. **Mount `<AppProvider defaultLocale="…">` once, at the root.** Without it the kit's OWN strings (dialog close/cancel/delete, counters, picker labels) fall to the resting locale (`<html lang>` when it names a registered locale, else `en`) and pickers to UTC (gh#1005). A development build now warns once when a kit component renders outside it; `syncI18nLocale(locale, fallback)` is the escape for an app that truly cannot mount the provider. Every page is `<PageContainer title extra footer>` (a `subtitle` only when it adds a fact the title does not); its sections are spaced by the page. Group items inside a section with `<Flex direction="col" gap>` or `<ResponsiveGrid>`.
 3. No Tailwind layout on your own elements: no `flex`, `grid`, `gap-*`, `p-*`, `m-*`, `space-*`. Rows are `<Flex>` (default row), stacks are `<Flex direction="col">`, grids are `<ResponsiveGrid>`. A list's filters are ONE `<FilterBar>` that wraps at every width — never a sideways-scrolling strip of filters or filter chips; past 2–4 filters the rest go behind one "More filters" `Sheet` (cardinal rule #51, pattern `list-filters`, audit rules `filter-bar-no-overflow`, `filter-strip-no-scroll` and `hand-rolled-filter-bar`). Filters are packed at the start: never a hand-built `<Flex justify="between">` of FormFields above a table. Many conditions or an explicit 検索 button → `SearchForm` (pattern `search-form`); field × operator rows saved as views → pattern `condition-builder`.
 4. No hand-rolled surfaces: no `rounded-* border bg-*` divs. A box is `Card`, a pill is `Badge`, a person is `Avatar`, a row is `ListRow`, a label/value pair is `Descriptions`, an empty area is `EmptyState`, a read-only sample of a colour the USER chose is `Swatch`. A LIST of those rows is `<Flex as="ul" marker="none" direction="col" gap="none">` with `<ListRow as="li">` children — `marker="none"` keeps the `<ul>`, the `<li>` semantics and the gap token while dropping the bullet and the indent. Never a raw `<ul>`/`<ol>` (it carries no gap token), never `<div role="list">` + `<div role="listitem">`, and never a wrapper around each row: the divider is `:not(:last-child)` among siblings, so a row alone in its own wrapper is always the last one and EVERY divider disappears silently. A bulleted prose list is the same `<Flex as="ul">` without `marker`.
-5. Real controls only: `Button`, `Input`, `Select`, `Textarea`, `Checkbox`… never raw `<button>`/`<input>`; a labelled control lives in `<FormField label>`. A Select outside a form takes `width="auto"`. **A disabled control's reason is visible text, never a tooltip** — see below. **Fields live in a `<Form layout="horizontal" labelWidth controlWidth>`** — never a group of `FormField`s without one, never a hand-rolled `<Flex>` row of fields (a row that belongs together is `<Flex attached>` or `<Form columns>`); size each control for its content with `controlWidth` (GOV.UK text-input width: a port ~7rem, a short enum ~10rem); three or more fields is a page, not a Dialog. The audit rules are `formfield-needs-form`, `dialog-form-too-big` and `select-width-hint`. **A case the kit cannot express is an issue, not a hand-roll:** open it on godx-jp/godxjp-ui, use the nearest valid composition, and mark it `// TODO(godxjp-ui#<n>)` (gh#998). **One action row, one Button size:** every `Button` under one parent takes the same `size` — a missing size is `default`, and `icon-sm` pairs with `sm`, `icon-xs` with `xs`, `icon` with default. Never `size="sm"` beside a default Button. The audit rules are `mixed-button-size` (static) and `mixed-button-height` (visual-audit, within 0.5px) (gh#1084).
+5. Real controls only: `Button`, `Input`, `Select`, `Textarea`, `Checkbox`… never raw `<button>`/`<input>`; a labelled control lives in `<FormField label>`. A Select outside a form takes `width="auto"`. **A disabled control's reason is visible text, never a tooltip** — see below. **Fields live in a `<Form>`** — never a group of `FormField`s without one, never a hand-rolled `<Flex>` row of fields (a row that belongs together is `<Flex attached>` or `<Form columns>`). `layout="horizontal"` with `labelWidth`/`controlWidth` is the desktop default; `layout="vertical"` (labels above the inputs, as GOV.UK and the W3C WAI forms tutorial show) is equally valid when labels are long, the container is narrow, or the page asks one short question per row (gh#1496). Size each control for its content with `controlWidth` (GOV.UK text-input width: a port ~7rem, a short enum ~10rem). **GoDX house rule:** a form with three or more fields is its own page, not a Dialog (audit `dialog-form-too-big`) — a product decision for task focus and recovery, not a WCAG requirement. The audit rules are `formfield-needs-form`, `dialog-form-too-big` and `select-width-hint`. **A case the kit cannot express is an issue, not a hand-roll:** open it on godx-jp/godxjp-ui, use the nearest valid composition, and mark it `// TODO(godxjp-ui#<n>)` (gh#998). **One action row, one Button size:** every `Button` under one parent takes the same `size` — a missing size is `default`, and `icon-sm` pairs with `sm`, `icon-xs` with `xs`, `icon` with default. Never `size="sm"` beside a default Button. The audit rules are `mixed-button-size` (static) and `mixed-button-height` (visual-audit, within 0.5px) (gh#1084).
 6. Text is `<Text>` / `<Heading>` with `tone`, `size`, `weight`, `truncate`, `mono` — not `className="text-muted-foreground font-semibold"`. A STANDALONE glyph is `<Icon as={Lock} size="sm" tone="muted" />` from `@godxjp/ui/general`: a bare lucide icon carries its own `width="24" height="24"` and only four places re-size it for you (`Button`, a `DropdownMenuItem`, a `TopbarItem`, a `ListRow` leading slot), so everywhere else — in a `Text`, a table cell, an `<a>` — it draws at 24px beside 14px type. `size-4` and `w-[16px]` are closed to you by rules 3 and 8, and `size={16}` hard-codes a number the theme owns; `Icon` puts the glyph on the `--icon-size-*` scale (`2xs…4xl`) instead, and is `aria-hidden` unless you give it a `label` (then it is `role="img"` with that name). The audit rule is `lucide-icon-needs-size`.
 7. Colours are semantic tokens (`tone="destructive"`, `bg-primary`), never palette names, hex, or `bg-black` / `text-white`.
 8. Sizes come from props (`size`, `width`, `columns`), never `w-[240px]` / `max-h-[420px]`.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@godxjp/ui",
-  "version": "33.22.1",
-  "godxUiMcp": "33.22.1",
+  "version": "33.24.0",
+  "godxUiMcp": "33.24.0",
   "license": "Apache-2.0",
   "repository": {
     "type": "git",
@@ -406,6 +406,7 @@
     "check:no-tailwind-class-assertions": "node scripts/check-no-tailwind-class-assertions.mjs",
     "check:number-input-step-target": "node scripts/check-number-input-step-target.mjs",
     "check:packed-public-contract": "node scripts/check-packed-public-contract.mjs",
+    "check:packed-export-types": "node scripts/check-packed-export-types.mjs",
     "check:pr-closes-keyword": "node scripts/check-pr-closes-keyword.mjs",
     "check:prop-vocabulary": "node scripts/check-prop-vocabulary.mjs",
     "check:radix-surface": "node scripts/check-radix-surface.mjs",

package/scripts/consumer-rule.md

@@ -109,7 +109,7 @@ godx-mailer dính bốn lỗi form trong một ngày, cả bốn đều là kit
 
 | Sai                                                         | Đúng                                                                                            | rule                   |
 | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ---------------------- |
-| ≥2 `FormField` không có `Form`, hoặc xếp hàng bằng `<Flex>` | `<Form layout="horizontal" labelWidth controlWidth>`; hàng = `<Flex attached>` / `Form columns` | `formfield-needs-form` |
+| ≥2 `FormField` không có `Form`, hoặc xếp hàng bằng `<Flex>` | `<Form>` (`layout="horizontal" labelWidth controlWidth` là mặc định desktop; `layout="vertical"` hợp lệ khi nhãn dài/khung hẹp); hàng = `<Flex attached>` / `Form columns` | `formfield-needs-form` |
 | ≥3 `FormField` trong `DialogBody`                           | page riêng (route riêng)                                                                        | `dialog-form-too-big`  |
 | `Select` hai lựa chọn kéo full width                        | `controlWidth` trên field hoặc một lần trên `Form`                                              | `select-width-hint`    |
 

package/skills/godxjp-ui-navigation/SKILL.md

@@ -42,12 +42,16 @@ comparisons, domain vocabulary) in its own repository; they do not belong in thi
 ## 2. Hard rules
 
 **Count and form**
-- Phone: **bottom bar with 3–5 items** (the middle one may be a ＋ quick-log button); everything else
-  goes under "More". Never put setup on the bottom bar. Desktop: **an always-visible sidebar**, not
+- Phone: **bottom bar with 3–5 destinations**; every slot navigates, never an action slot (see
+  principles §1.6 and rule 11). The #1 create action sits above the bar (a FAB) or in the top bar.
+  Everything else goes under "More". Never put setup on the bottom bar. Desktop: **an always-visible sidebar**, not
   only a ☰ button. Choose by window width, not by device. (@godxjp/ui's `MobileShell` has a bottom
   bar — use it; don't rely on a drawer alone.)
-- Sidebar at most **2 levels**, groups with short headings; each role sees **≤ ~7 primary items**.
-  Anything deeper → list → detail inside the page.
+- Keep the sidebar shallow (aim for **2 levels**, groups with short headings) and each role's primary
+  list short (**~7 items**). These numbers are **review signals, not pass/fail limits**: when a role
+  exceeds them, validate the tree with the role's real tasks (tree test or walkthrough) and split by
+  work area rather than hiding items in a catch-all group. Record data deeper than the menu →
+  list → detail inside the page.
 
 **Grouping and labels**
 - Group by **task / work area**. Never group by data table, org chart or developer vocabulary
@@ -59,8 +63,8 @@ comparisons, domain vocabulary) in its own repository; they do not belong in thi
 - **Each destination appears once** in the menu. Two items leading to the same kind of record = a
   defect.
 - Action buttons (Log/Create) are **not menu items**: one prominent primary button (top of the menu,
-  or the ＋ in the middle of the bottom bar) for the #1 task; child objects are created right inside
-  their parent's page.
+  or a create button above the bottom bar — never inside a bar slot) for the #1 task; child objects
+  are created right inside their parent's page.
 
 **Per role**
 - Each role has its **own fixed landing page**: frontline staff → "Today" (due, overdue, my tasks);
@@ -99,14 +103,15 @@ An example only, for apps that run recurring checks across many sites:
   stay **permanently linked** to their source record.
 - Staff land on "Today" plus a separate place for "Overdue/Missed"; managers land on a rate table plus
   exceptions.
-- Phone bottom bar: 4–5 task items (e.g. Today · Inspections · ＋Log · Nonconformities · More).
+- Phone bottom bar: 4–5 destinations (e.g. Today · Inspections · Nonconformities · More), with
+  ＋ Log as a button above the bar.
 - Vocabulary: avoid "Reports"/"レポート" as the label for *records* (in English "Reports" means
   analytics; in Japanese "レポート" often means an individual record).
 
 ## 4. Self-check gate (before asking for approval / before merging)
 
-- [ ] A task table per role and a text menu tree per role exist; each role ≤ ~7 primary items; phone
-      3–5 items.
+- [ ] A task table per role and a text menu tree per role exist; a role past ~7 primary items or 2
+      levels has a tree test or walkthrough behind it; phone 3–5 destinations, no action slot.
 - [ ] Walkthrough of 8–10 tasks per role: no step answered "no"; no pair of competing labels.
 - [ ] No duplicate destinations; no grouping by data table; label = H1 = `<title>`, consistent across
       every locale.

package/skills/godxjp-ui-navigation/references/principles.md

@@ -215,7 +215,7 @@ The Atlassian Design System's public navigation page and the Salesforce Lightnin
 | Breadcrumb as history, or a breadcrumb plus a back link | Breadcrumbs show hierarchy [P] NN/g; "Never use the back link… together with the Breadcrumbs" [P] GOV.UK |
 | Losing list position or filters on Back | "the page often resets to the top of the list" [P] NN/g saving scroll position |
 | Main navigation in the page header, or repeated in the page body | "Avoid placing the main navigation in the page header"; avoid "replicating the app nav content in the app body" [P] Shopify |
-| More than 2 levels of sidebar or cascading menus | [P] HIG sidebars; Carbon; Fluent; NN/g menu design |
+| More than 2 levels of sidebar or cascading menus, with no tree test or walkthrough behind them | [P] HIG sidebars; Carbon; Fluent; NN/g menu design |
 | Dead ends on object pages | Give paths onward from every object instance [Pr] OOUX (A List Apart) |
 
 ---
@@ -232,7 +232,7 @@ The Atlassian Design System's public navigation page and the Salesforce Lightnin
 | 6 | Labels are short nouns in the users' words, 1–2 words, never coined terms. | https://shopify.dev/docs/apps/design/navigation ; https://www.nngroup.com/articles/top-10-ia-mistakes/ |
 | 7 | Every navigation item has a visible text label. Icons only support the label. Never truncate. | https://m3.material.io/components/navigation-bar/guidelines |
 | 8 | Order by frequency of use measured from users (top-tasks vote or field study). Positions stay fixed. | https://www.nngroup.com/articles/progressive-disclosure/ ; https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html |
-| 9 | Sidebar: at most 2 levels, with short group headings. Deeper data goes into list → detail inside the page. | https://developer.apple.com/design/human-interface-guidelines/sidebars |
+| 9 | Sidebar: aim for 2 levels, with short group headings — a review signal, not a pass/fail limit. A third level is for a work area that needs it, validated by a tree test or walkthrough; record data goes into list → detail inside the page. | https://developer.apple.com/design/human-interface-guidelines/sidebars |
 | 10 | Settings, admin and configuration live apart from daily work (utility area or admin section), behind a second level at most. | https://www.nngroup.com/articles/utility-navigation/ ; https://www.nngroup.com/articles/progressive-disclosure/ |
 | 11 | Navigation slots navigate; they never perform actions. Put Create in a FAB or top bar for the main object, and in context for children. | https://developer.apple.com/design/human-interface-guidelines/tab-bars |
 | 12 | Each role gets its own fixed start page, named after the work area, with task-oriented sections. | https://www.sap.com/design-system/fiori-design-web/v1-148/foundations/integration-and-services/sap-fiori-launchpad/sap-fiori-launchpad-spaces |