srcdev-nuxt-components 9.4.11 → 9.5.0

package/.claude/skills/component-aria-landmark.md

@@ -88,7 +88,7 @@ Self-bound (the component renders its own heading and binds `headingId` internal
 action needed):
 
 - `ServiceSummary` (03.organisms) — binds it to its own title `HeroText`
-- `LayoutGridByCols` / `LayoutGridByWidth` (01.atoms) — render their own visually-hidden `<p>` from the `label` prop
+- `LayoutGridByCols` (01.atoms) — renders its own visually-hidden `<p>` from the `label` prop (only when `label` is set; a `section` without one gets no `aria-labelledby`, and the composable warns)
 
 Not using this pattern:
 

package/.claude/skills/component-dynamic-slots.md

@@ -77,7 +77,6 @@ Slots are rendered in document order.
 
 - `app/components/01.atoms/card/CardCore.vue`
 - `app/components/01.atoms/content-wrappers/layout-grid/layout-grid-by-cols/LayoutGridByCols.vue`
-- `app/components/01.atoms/content-wrappers/layout-grid/layout-grid-by-width/LayoutGridByWidth.vue`
 - `app/components/container-glow/ContainerGlowCore.vue`
 
 ---

package/.claude/skills/component-export-types.md

@@ -11,7 +11,7 @@ Types defined inline in a `.vue` component file are not easily importable by con
 Create `app/types/components/<component-name>.d.ts` with the exported interfaces:
 
 ```ts
-// app/types/components/navigation-horizontal.d.ts
+// app/types/components/nav-item.d.ts
 export interface NavItem {
   text: string;
   href?: string;
@@ -30,7 +30,7 @@ export interface NavItemData {
 In `app/types/components/index.ts`, add an export line:
 
 ```ts
-export * from "./navigation-horizontal.d"
+export * from "./nav-item.d"
 ```
 
 ### 3. Update the component
@@ -43,7 +43,7 @@ export interface NavItem { ... }
 export interface NavItemData { ... }
 
 // After
-import type { NavItem, NavItemData } from "~/types/components/navigation-horizontal.d";
+import type { NavItem, NavItemData } from "~/types/components/nav-item.d";
 ```
 
 ## Consuming app usage

package/.claude/skills/component-inline-action-button.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-When a component needs an action button visually attached to an input-like wrapper (e.g. copy-to-clipboard, search-submit), use `InputButtonCore variant="inline"` rather than a raw `<button>`. The `inline` variant applies no built-in styles intentionally — the parent component's CSS provides all context. This keeps the button consistent with the rest of the input system (focus rings, hover tokens, transition timing) without duplicating the button style system.
+When a component needs an action button visually attached to an input-like wrapper (e.g. copy-to-clipboard, search-submit), use `InputButton variant="inline"` rather than a raw `<button>`. The `inline` variant applies no built-in styles intentionally — the parent component's CSS provides all context. This keeps the button consistent with the rest of the input system (focus rings, hover tokens, transition timing) without duplicating the button style system.
 
 ## Pattern
 
@@ -10,7 +10,7 @@ When a component needs an action button visually attached to an input-like wrapp
 <template>
   <div class="my-wrapper" :class="{ 'some-state': isActive }">
     <input class="my-field" ... />
-    <InputButtonCore
+    <InputButton
       type="button"
       variant="inline"
       class="my-action-button"
@@ -21,16 +21,16 @@ When a component needs an action button visually attached to an input-like wrapp
       <template v-if="slots.icon" #left>
         <slot name="icon"></slot>
       </template>
-    </InputButtonCore>
+    </InputButton>
   </div>
 </template>
 ```
 
-`aria-label` is not a declared prop on InputButtonCore — it falls through to the root element via Vue's default `inheritAttrs: true`.
+`aria-label` is not a declared prop on InputButton — it falls through to the root element via Vue's default `inheritAttrs: true`.
 
 ## CSS
 
-Target `.my-action-button.input-button-core` inside the wrapper to override InputButtonCore's defaults. Use theme tokens — not private `--_` tokens — for colours that already have theme equivalents:
+Target `.my-action-button.input-button` inside the wrapper to override InputButton's defaults. Use theme tokens — not private `--_` tokens — for colours that already have theme equivalents:
 
 ```css
 @layer components {
@@ -41,7 +41,7 @@ Target `.my-action-button.input-button-core` inside the wrapper to override Inpu
     border-radius: var(--form-input-border-radius);
     background-color: var(--theme-input-surface);
 
-    .my-action-button.input-button-core {
+    .my-action-button.input-button {
       border-radius: 0;
       border-inline-start: var(--form-element-border-width) solid var(--theme-input-border);
       padding-inline: var(--input-padding-inline);
@@ -65,7 +65,7 @@ Target `.my-action-button.input-button-core` inside the wrapper to override Inpu
       --_state-surface: light-dark(var(--green-01), var(--green-09));
       --_state-text: light-dark(var(--green-08), var(--green-01));
 
-      .my-action-button.input-button-core {
+      .my-action-button.input-button {
         background-color: var(--_state-surface);
         color: var(--_state-text);
       }

package/.claude/skills/component-local-style-override.md

@@ -8,6 +8,16 @@ on context.
 
 No changes to the layer component are required for either pattern.
 
+The main mechanism is the component's **public tokens** (`--component-name-*`, listed in its
+`CONSUMER-STYLING.md`). They're only ever read with a fallback, never declared on the component's
+own elements, so setting them on any ancestor you own reaches the component by normal custom
+property inheritance. Every compliant `CONSUMER-STYLING.md` has a **Local overrides** section
+applying this guide to that component.
+
+> **This library's own component styles are never `scoped`.** Everything below about
+> `<style scoped>` concerns the **consumer's** file (a page or component in the app that extends
+> this layer), not the library.
+
 > **⚠️ Never wrap consumer-app override `<style>` blocks in a named `@layer`** (e.g.
 > `@layer consumer`), even though library components wrap their own styles in `@layer components`
 > and it's tempting to mirror that. Cascade layer priority is fixed by whichever layer name is
@@ -23,6 +33,50 @@ No changes to the layer component are required for either pattern.
 
 ---
 
+## Site-wide component defaults (the baseline local overrides build on)
+
+Before any page or instance override, a consuming app usually sets its own **site-wide** values for
+a component's public tokens: one file per component under `app/assets/styles/setup/03.theming/`,
+each imported from that folder's `index.css` alongside `_default.css` (see
+`consumer-styles-structure.md` for the whole `setup/` tree):
+
+```css
+/* app/assets/styles/setup/03.theming/_card-core.css */
+/* CardCore — site-wide card look. */
+:where(html) {
+  --card-core-background-color: var(--rose-01);
+  --card-core-border: 0.1rem solid var(--rose-03);
+  --card-core-border-radius: 1.2rem;
+}
+```
+
+```css
+/* app/assets/styles/setup/03.theming/index.css */
+@import "./_default.css";
+@import "./_card-core.css";
+```
+
+Why `:where(html)` rather than `:root` or `html`:
+
+- `:where()` has **zero specificity**, so this is the weakest possible declaration on `<html>`. Any
+  other rule setting the same token on `<html>` wins without a fight: a colour-scheme selector
+  (`html[data-color-scheme="dark"] { ... }`), or a page-level `html.checkout-page { ... }`.
+  `:root` (0,1,0) would outrank or tie those and force specificity games.
+- Page and instance overrides (the patterns below) set the token on a descendant element, so they
+  win through inheritance regardless of specificity: the nearest declaration is what the component
+  reads.
+- Keep these files unlayered, same as everything else here (see the warning above).
+
+Only set tokens the component's current `CONSUMER-STYLING.md` lists. Components that haven't been
+through `/migrate-component` yet may still rename tokens when they are, so check a site-defaults
+file against the doc after upgrading the layer.
+
+Use this for "every instance on the site should look like this"; use the patterns below for
+"this page/section/instance differs from the site default". A component's `CONSUMER-STYLING.md`
+**Global theming** section, when it has one, is a starting point for this file.
+
+---
+
 ## Pattern 1 — Page-level scoping (preferred for single-use or section-scoped instances)
 
 The consuming page has a unique wrapper or body class. The `<style>` block is **unscoped** — no
@@ -34,7 +88,7 @@ scope. No `:deep()` is needed.
 <template>
   <div class="contact-page">
     <div class="hero-section">
-      <SocialIconsList :items="socialItems" />
+      <CardCore>...</CardCore>
     </div>
   </div>
 </template>
@@ -43,19 +97,13 @@ scope. No `:deep()` is needed.
 <style lang="css">
 .contact-page {
   .hero-section {
-    .social-icons-list {
-      /* Theming */
-      --theme-social-icon-size: 3.2rem;
-      --theme-social-icon-gap: 2rem;
-      color: var(--colour-brand-primary); /* drives currentColor on icons */
+    /* Public tokens: set on your own element, inherited by the component */
+    --card-core-background-color: var(--colour-brand-surface);
+    --card-core-border-radius: 1.6rem;
 
-      /* Geometry */
+    /* Direct property on the component root, only where no token covers it */
+    .card-core {
       margin-block-start: 1.6rem;
-
-      .social-icon-link {
-        border-radius: 0.4rem;
-        padding: 0.4rem;
-      }
     }
   }
 }
@@ -66,29 +114,29 @@ scope. No `:deep()` is needed.
 use that as the root scope for all page-specific overrides:
 
 ```ts
-useHead({ bodyAttrs: { class: "contact-page" } })
+useHead({ bodyAttrs: { class: "contact-page" } });
 ```
 
 ```css
 /* All overrides for the page nested under the body class */
 .contact-page {
-  .social-icons-list { ... }
+  --card-core-border-radius: 1.6rem;
   .hero-text { ... }
 }
 ```
 
-> **⚠️ Do not use `bodyAttrs.class` as the scope for a page's *own* local `<style>` overrides if the
+> \**⚠️ Do not use `bodyAttrs.class` as the scope for a page's *own* local `<style>` overrides if the
 > app uses `pageTransition`/`layoutTransition` (see `page-transitions.md`) — it races and breaks
 > mid-transition. `unhead` swaps `<body>`'s class the instant the *incoming* route's component sets
 > up, which happens as soon as navigation starts — not when the *outgoing* page's leave-transition
 > finishes animating. For a real transition duration (not an instant swap), the outgoing page is
-> still visible and mid-fade while `<body>` already carries the *new* page's class. Any selector
+> still visible and mid-fade while `<body>` already carries the *new\* page's class. Any selector
 > that depends on the old body class as an ancestor (`.contact-page .hero-bg-image { position:
-> absolute; ... }`) stops matching mid-fade, and the affected element snaps to unstyled/intrinsic
+absolute; ... }`) stops matching mid-fade, and the affected element snaps to unstyled/intrinsic
 > sizing for the rest of the transition — confirmed via direct DOM/computed-style polling against a
 > real `npm run build` + preview, not dev-server guesswork.
 >
-> Keep `bodyAttrs.class` for its legitimate use — a hook for *persistent* components (header, nav)
+> Keep `bodyAttrs.class` for its legitimate use — a hook for _persistent_ components (header, nav)
 > that live outside the transitioning page to react to "which page is active." For a page's own
 > local overrides, put a matching class directly on the page's own template root instead, so the
 > scope lives on the exact element that's fading and can never desync from what's rendered:
@@ -114,8 +162,13 @@ useHead({ bodyAttrs: { class: "contact-page" } })
 ## Pattern 2 — Per-instance modifier via styleClassPassthrough
 
 Use when the same component appears multiple times on a page and you need to target a specific
-instance, or when the consuming file uses `<style scoped>` and needs an anchor class that survives
-scoping.
+instance.
+
+If the component you're rendering is a **wrapper** that doesn't forward `styleClassPassthrough` to
+the inner component you want to style (e.g. `InputDescription` inside `InputTextWithLabel`), put a
+plain `class` on the wrapper instead. Vue falls it through to the wrapper's root element, which is
+an ancestor of the inner component, so tokens set there inherit down. This needs the wrapper to
+have a single root element and not set `inheritAttrs: false`.
 
 ```vue
 <CardCore :style-class-passthrough="['featured-card']">
@@ -133,11 +186,11 @@ scoping.
 .card-core {
   &.featured-card {
     /* Colours */
-    /* --_background-color: var(--brand-primary); */
-    /* --_border-color: var(--brand-secondary); */
+    /* --card-core-background-color: var(--brand-primary); */
+    /* --card-core-border: 0.1rem solid var(--brand-secondary); */
 
     /* Geometry */
-    /* border-radius: 1.6rem; */
+    /* --card-core-border-radius: 1.6rem; */
   }
 }
 </style>
@@ -148,10 +201,40 @@ path: `.card-core.featured-card .card-row-header { ... }`.
 
 ---
 
+## Consumer files using `<style scoped>`
+
+Vue adds the consuming file's scope attribute (`[data-v-xxxx]`) to the last compound selector of
+every rule in a scoped block. Your own template elements carry that attribute; the library
+component's elements don't. So:
+
+| Override                                                                                                                                | In a consumer's scoped block                                                     |
+| --------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
+| Public token set on **your own** element (`.contact-page { --card-core-border-radius: 1.6rem; }`)                                       | Works unchanged: your element matches, and the token inherits into the component |
+| Class/attribute on the component's **root** passed from your template (`:style-class-passthrough`, or `class` fallthrough)              | Works: Vue also puts your scope attribute on a child component's root element    |
+| Anything **inside** the component (`.card-core-header`, `.input-description[data-invalid]` when the description is nested in a wrapper) | Doesn't match. Wrap it in `:deep()`, or move it to an unscoped `<style>` block   |
+
+```vue
+<style scoped>
+.contact-page {
+  --input-description-font-size: 1.4rem; /* works as-is */
+
+  :deep(.input-description[data-invalid]) {
+    --input-description-color: var(--theme-error-border);
+  }
+}
+</style>
+```
+
+Prefer tokens on your own element wherever one exists: it works the same in scoped and unscoped
+files and doesn't depend on the component's internal class names.
+
+---
+
 ## When to offer a scaffold
 
 After placing a component in a consuming page or component, offer a CSS override scaffold. Use the
-component's own class name and any `--theme-*` tokens it exposes as commented stubs. Cover theming
+component's own class name and the public `--component-name-*` tokens listed in its
+`CONSUMER-STYLING.md` as commented stubs. Cover theming
 (colours, tokens) and geometry (sizes, spacing, borders) — not behaviour (`display`, `pointer-events`,
 `z-index`, animations).
 
@@ -159,11 +242,11 @@ component's own class name and any `--theme-*` tokens it exposes as commented st
 
 ## What to override
 
-| Category | Examples | Approach |
-|---|---|---|
-| Theming | icon colour, background, border colour | `--theme-*` tokens where exposed; otherwise direct values |
-| Geometry | border-radius, padding, gap, size | Direct property or `--_` private variable |
-| Border / outline | width, style, colour | Direct property or `--_` private variable |
+| Category         | Examples                               | Approach                                                   |
+| ---------------- | -------------------------------------- | ---------------------------------------------------------- |
+| Theming          | icon colour, background, border colour | The component's public tokens; otherwise a direct property |
+| Geometry         | border-radius, padding, gap, size      | The component's public tokens; otherwise a direct property |
+| Border / outline | width, style, colour                   | The component's public tokens; otherwise a direct property |
 
 **Do not override behaviour** — `display`, `visibility`, `pointer-events`, `z-index`, animations.
 Those belong in the component or a structural parent.
@@ -172,36 +255,34 @@ Those belong in the component or a structural parent.
 
 ## CSS custom property targeting
 
-Components expose `--theme-*` public tokens and use `--_` private tokens internally:
+Components expose **public** tokens named after the component (`--card-core-border-radius`,
+`--input-description-color`) and may use **private** `--_` tokens internally:
 
 ```css
-/* Component internally: --_icon-size: var(--theme-social-icon-size, 2.4rem) */
-
-/* Override via --theme-* (stable, recommended): */
-.social-icons-list {
-  --theme-social-icon-size: 3.2rem;
-}
-
-/* Override via --_ private token (fragile — may break on component update): */
-.social-icons-list {
-  &.my-modifier {
-    --_icon-size: 3.2rem;
-  }
+/* Public token (stable API, recommended): set on any ancestor you own */
+.contact-page {
+  --card-core-border-radius: 1.6rem;
 }
 ```
 
-Prefer `--theme-*` tokens. Only target `--_` private variables when no `--theme-*` equivalent exists.
+Private `--_` tokens are internal implementation detail and can change or disappear in any
+release. Don't override them. If a value you need has no public token, that's a gap in the
+component: raise it (or fix it in the library) rather than depending on the private name.
+
+Some older, not-yet-migrated components still read global `--theme-*` tokens directly instead of
+their own component tokens (see CLAUDE.md pitfall #14). Those work as ancestor overrides too, but
+they're shared by every component reading them, so scope the override tightly.
 
 ---
 
 ## When to use this vs other approaches
 
-| Situation | Approach |
-|---|---|
-| One-off visual tweak for a specific page/context | Local style override (this skill) |
+| Situation                                            | Approach                                      |
+| ---------------------------------------------------- | --------------------------------------------- |
+| One-off visual tweak for a specific page/context     | Local style override (this skill)             |
 | Consistent appearance across all instances site-wide | Default theme (`theming-override-default.md`) |
-| Variant that belongs in the component itself | Add a `variant` prop value to the component |
-| Structural layout change | Wrapper element or parent component |
+| Variant that belongs in the component itself         | Add a `variant` prop value to the component   |
+| Structural layout change                             | Wrapper element or parent component           |
 
 ### Component type guide
 
@@ -211,10 +292,13 @@ Prefer `--theme-*` tokens. Only target `--_` private variables when no `--theme-
 - Layout wrappers used in a specific visual context (e.g. a grid section with a tinted background)
 - Any component whose appearance legitimately varies per page or usage context
 
-**Keep styling global (theme/config) for:**
+**Usually better themed globally:**
 
 - Form elements and interactive controls — inputs, buttons, toggles, checkboxes
 - Typography components used for consistency across the site
 - Anything where visual inconsistency between instances would be a bug
 
-The test: *should all instances of this component look the same?* If yes → theme. If instances are expected to look different → local override.
+These all expose the same public tokens, so a local override is still available when a context
+genuinely calls for it (e.g. a form on a dark hero section). The point is the default, not a ban.
+
+The test: _should all instances of this component look the same?_ If yes → theme. If instances are expected to look different → local override.

package/.claude/skills/component-naming.md

@@ -0,0 +1,107 @@
+# Component naming: Control / Field convention
+
+Adopted 2026-09-25. `input-number` is the first component converted; everything else is backlog
+(see the table below). Apply this convention to every component migrated from now on, and convert
+previously migrated components retrospectively, one family at a time.
+
+## The rule
+
+| Role | Name | Root DOM class | Example |
+|------|------|----------------|---------|
+| Bare control (native element + its slots, no label/description/error) | `<Name>` | `.<kebab-name>` | `InputNumber` → `.input-number` |
+| Labelled field (label + description + control + error) | `<Name>Field` | `.<kebab-name>-field` | `InputNumberField` → `.input-number-field` |
+
+- **No `Core` suffix.** It only ever existed to tell the bare control apart from its wrapper; once
+  the wrapper is named `Field`, the control doesn't need a suffix. Components with no wrapper
+  sibling at all (`CardCore`, `TabsCore`, ...) never needed it.
+- **No `Default` / `WithLabel` suffix on wrappers.** `Default` says nothing about what the wrapper
+  adds; `WithLabel` undersells it (it also renders description and error). "Field" is the
+  established term (Material, Radix, Ark UI, Chakra) for "control plus its label and messages".
+- **Layout variations of a Field** are a prop on the Field (e.g. `layout="inline"`), not a new
+  suffix, unless the markup genuinely diverges; then `<Name>Field<Variant>`.
+- **Files, stories, tests, skill doc follow the name**: `InputNumber.vue`, `stories/InputNumber.stories.ts`,
+  `tests/InputNumber.spec.ts`, `.claude/skills/components/input-number.md` (the Field is documented
+  in its control's skill doc under "Variants"). Snippet file stays `srcdev-component-<family>.code-snippets`
+  and covers both.
+- **CSS custom properties don't change** on rename; they're already `--<family>-*` (e.g.
+  `--input-number-border`). Only the component name and its root/base DOM class change.
+
+## Never a single word that is (or could become) a native HTML element
+
+Stripping a suffix must never leave a single-word name that matches a native element: `Dialog`,
+`Button`, `Select`, `Input`, `Details`, `Summary`, `Menu`, `Header`, `Footer`, `Nav`, `Form`,
+`Label`, `Table`, `Option`, `Search`, `Slot`, `Template`, and so on. Vue refuses built-in/reserved tag
+names as component names, and templates match tags case-insensitively, so `<Dialog>` can resolve to the
+native `<dialog>` instead of the component. Also watch for names that *could become* an element (the
+HTML spec keeps adding them: `<search>` and `<selectedcontent>` are recent), so don't rely on "it isn't one
+today".
+
+This is where the `Core` suffix originally crept in. The fix is a meaningful prefix, not a suffix:
+`DisplayDialog` (not `DialogCore`), and the `Input*` prefix on form controls already covers
+`InputButton`/`InputSelect`/`InputText`. Multi-word names are enforced: `eslint.config.mjs` turns on
+`vue/multi-word-component-names` as an error for `app/components/**/*.vue` (added 2026-09-25; Nuxt's
+base config leaves it off). `Breadcrumb` is the one existing single-word component and sits in that
+rule's `ignores` list; it's not an element, so it's grandfathered, but don't add to that list; pick a
+multi-word name instead. `vue/no-reserved-component-names` (already on via the Nuxt base config)
+separately rejects exact native element names.
+
+## Collision caveat (Nuxt layer)
+
+This library is a Nuxt layer with `pathPrefix: false`. A consuming app's own component with the same
+name **silently replaces the layer's**, including every place the layer uses it internally. Dropping
+a prefix/suffix makes a name shorter and more generic, so more collision-prone. `InputNumber`,
+`InputSelect` etc. are distinctive enough. A bare common word (`Card`, `Tabs`, `Accordion`) is the
+risky case: marked **decide** in the backlog; consider a more specific name rather than just
+stripping `Core`.
+
+## How to rename a family
+
+1. `git mv` the `.vue` files, their stories and tests (and the skill doc if it's named after the old
+   control name).
+2. `sed` the old names across `app/`, `.claude/`, `.vscode/`, `MIGRATION.md` and `Claude.md`:
+   component names, `import` paths, story titles/`*StoryArgs` interfaces, `describe()` names, and the
+   root/base DOM class (update `CONSUMER-STYLING.md` and test selectors that use it).
+3. Add a "Renamed YYYY-MM-DD" note at the top of the skill doc listing old → new names and classes.
+4. Grep consumer repos (`/check-component-usage`) and **list** the files/lines that use the old
+   names (in the private consumer notes, never in this repo). Don't edit the consumers yet: they pin
+   an exact layer version, so a rename applied now breaks them until they bump. Apply the list when
+   each consumer upgrades to the release that ships the rename. No deprecated aliases are needed
+   (all consumers are the user's own apps); note the rename as breaking in the release notes.
+   (Decided 2026-09-28 during the InputButton rename.)
+5. Tick the row off below.
+
+## Backlog
+
+Consumers column = whether a consuming app used the name as of 2026-09-25 (`yes`), or `-` for no
+external consumer, free to rename. Run `/check-component-usage` for the current list before renaming.
+
+| Current | Proposed | Consumers |
+|---------|----------|-----------|
+| ~~InputNumberCore~~ | ✅ `InputNumber` (2026-09-25) | - |
+| ~~InputNumberDefault~~ | ✅ `InputNumberField` (2026-09-25) | - |
+| InputTextCore | `InputText` | yes |
+| InputTextWithLabel | `InputTextField` | yes |
+| InputPasswordWithLabel | `InputPasswordField` | yes |
+| InputTextAsNumberWithLabel | `InputTextAsNumberField` | - |
+| InputRangeCore | `InputRange` | - |
+| InputRangeDefault | `InputRangeField` | - |
+| InputTextareaCore | `InputTextarea` | - |
+| InputTextareaWithLabel | `InputTextareaField` | yes |
+| InputSelectCore | `InputSelect` | yes |
+| InputSelectWithLabel | `InputSelectField` | yes |
+| ToggleSwitchCore | `ToggleSwitch` | yes |
+| ToggleSwitchWithLabel | `ToggleSwitchField` | yes |
+| ToggleSwitchWithLabelInline | `layout` prop on `ToggleSwitchField`, or `ToggleSwitchFieldInline` | - |
+| ~~TripleToggleSwitchCore~~ | ✅ `TripleToggleSwitch` (2026-09-27) | - |
+| ~~InputButtonCore~~ | ✅ `InputButton` (2026-09-28) | yes |
+| ~~InputCheckboxRadioCore~~ | ✅ `InputCheckboxRadio` (2026-09-27) | - |
+| InputCheckboxRadioButton | ✅ kept: button-style option, not a Field (2026-09-27) | - |
+| ~~InputCheckboxRadioWithLabel~~ | ✅ `InputCheckboxRadioField` (2026-09-27) | - |
+| ~~ActionMenuItemCore~~ | ✅ `ActionMenuItem` (2026-09-27) | - |
+| AlertMaskCore | `AlertMask` | - |
+| CardCore | **decide**: `Card` is single-word and collision-prone; prefer a prefixed name (`Display*`, `Content*`) | yes |
+| AccordianCore | **decide**: also fixes the "Accordian" misspelling; bare `Accordion` is single-word and collision-prone, and it is built on `<details>`/`<summary>` | yes |
+| TabsCore | **decide**: `Tabs` is single-word and collision-prone | - |
+
+The `input-checkbox` family also has `MultipleCheckboxes`/`SingleCheckbox` on top of the Core; look
+at how the four relate before choosing names there.

package/.claude/skills/components/action-menu.md

@@ -1,10 +1,12 @@
 # ActionMenu
 
+> **Renamed 2026-09-27:** `ActionMenuItemCore` → `ActionMenuItem`; root class `.action-menu-item-core` → `.action-menu-item`.
+
 ## Overview
 
 `ActionMenu` is a trigger-and-popover component that shows a compact ellipsis button (`lucide:ellipsis`).
 Clicking it opens an anchored menu list populated via indexed dynamic slots (`item-{n}`). Each slot
-should contain a single `ActionMenuItemCore` — either a `<button>` (for actions) or a link (for
+should contain a single `ActionMenuItem` — either a `<button>` (for actions) or a link (for
 navigation). The popover API and CSS anchor positioning handle positioning and dismiss behaviour
 natively; no JavaScript click-outside logic is needed.
 
@@ -18,24 +20,25 @@ natively; no JavaScript click-outside logic is needed.
 
 | Prop | Type | Default | Notes |
 |---|---|---|---|
-| `itemCount` | `number` | `0` | Number of `item-{n}` slots to render. |
 | `label` | `string` | `"Open actions menu"` | Used as `aria-label` on the trigger and `aria-label` on the menu list. |
+| `triggerIcon` | `string` | `"lucide:ellipsis"` | Icon on the trigger button. |
 | `styleClassPassthrough` | `string \| string[]` | `[]` | Extra classes on the root `<div>`. |
 
 **Slots**
 
 | Slot | When used |
 |---|---|
-| `item-{n}` | One per item, where `n` is 0-indexed up to `itemCount - 1`. Should contain one `ActionMenuItemCore`. |
+| `item-{n}` | One per item, `n` 0-indexed. The row count is derived from which `item-{n}` slots are present (re-evaluated every render, so items added after mount appear). Should contain one `ActionMenuItem`. |
 
 ---
 
-### ActionMenuItemCore
+### ActionMenuItem
 
 | Prop | Type | Default | Notes |
 |---|---|---|---|
 | `label` | `string` | — | **Required.** Visible text for the row. |
 | `href` | `string` | `undefined` | If set, renders as `<a>` (external) or `NuxtLink` (internal `/…` path). Omit for a `<button>`. |
+| `arrowIcon` | `string` | `"lucide:arrow-right"` | Decorative trailing arrow icon. |
 | `styleClassPassthrough` | `string \| string[]` | `[]` | Extra classes on the root element. |
 
 **Slots**
@@ -62,19 +65,19 @@ natively; no JavaScript click-outside logic is needed.
 ```vue
 <ActionMenu :item-count="3" label="Row actions">
   <template #item-0>
-    <ActionMenuItemCore label="Edit" @click="handleEdit">
+    <ActionMenuItem label="Edit" @click="handleEdit">
       <template #icon><Icon name="lucide:pencil" /></template>
-    </ActionMenuItemCore>
+    </ActionMenuItem>
   </template>
   <template #item-1>
-    <ActionMenuItemCore label="View detail" href="/records/123">
+    <ActionMenuItem label="View detail" href="/records/123">
       <template #icon><Icon name="lucide:eye" /></template>
-    </ActionMenuItemCore>
+    </ActionMenuItem>
   </template>
   <template #item-2>
-    <ActionMenuItemCore label="Delete" @click="handleDelete">
+    <ActionMenuItem label="Delete" @click="handleDelete">
       <template #icon><Icon name="lucide:trash-2" /></template>
-    </ActionMenuItemCore>
+    </ActionMenuItem>
   </template>
 </ActionMenu>
 ```
@@ -119,9 +122,10 @@ Quick reference:
 
 ## Notes
 
-- **Popover API + CSS anchor positioning** — the menu uses `popover` attribute and `position-anchor`.
-  Both are broadly supported (Chrome 114+, Firefox 125+, Safari 17+). No polyfill is included.
-- **Auto-close** — clicking any `<li>` row fires `hidePopover()` on the menu. The `ActionMenuItemCore`
+- **Popover API + CSS anchor positioning** — the menu uses the `popover` attribute (broadly supported)
+  and `position-anchor` (newer: Chromium 125+, Safari 26+). Without anchor positioning the popover
+  still opens, just not anchored to the trigger. No polyfill is included.
+- **Auto-close** — clicking any `<li>` row fires `hidePopover()` on the menu. The `ActionMenuItem`
   emitting `click` triggers normally before the menu closes.
 - **Focus management** — on open the `toggle` event fires `handleToggle`, which moves focus to the
   first `[role="menuitem"]` inside the popover.
@@ -136,6 +140,6 @@ Quick reference:
 - **`anchorName` format** — internally generated as `--action-menu-anchor-{id}` (a valid CSS
   `<dashed-ident>`). Set via a CSS custom property on the root element so both the trigger's
   `anchor-name` and the popover's `position-anchor` can reference the same value.
-- **Dynamic slots stability** — `item-{n}` slots enforce that only `ActionMenuItemCore` content
+- **Dynamic slots stability** — `item-{n}` slots enforce that only `ActionMenuItem` content
   enters the list; arbitrary HTML inside the popover is not supported and will break the ARIA
   `menu` / `menuitem` pattern.