feat(ItemAction): default to the current type instead of inheriting the row's

[tenphi]

ItemAction / ItemBadge now default to type="current" and no longer mirror the host row's type from context. current derives every color from the inherited currentcolor, so one type covers every host type × theme that the context mapping used to enumerate — and because currentcolor is inherited rather than resolved once, an action also follows its row through hover, selected and disabled instead of holding a fixed palette. The mapping in ItemActionProvider that folded item / outline / outline-2 / header / card onto clear is gone.

Started from the question "can we drop ItemActionContext entirely?" — the answer is no, but the type-inheritance half of it can go.

What stays, and why

ItemActionContext still carries disableActionsFocus, isDisabled, the theme, and type — the last only for its presence, which drives the context mod that collapses an action's side margins. The provider's signature is unchanged, so no call site moved.

theme is still consumed for exactly one reason: current needs to know when it sits on the special theme's dark surface, where the alpha ramp has to step harder to stay visible.

An explicit theme opts an action out of current and back to clear, since current is theme-agnostic by construction and the theme would otherwise have nothing to color. theme="default" is excluded from that fallback — passing a prop's own default value must not change what renders, which is the invariant no-redundant-default-prop lints for. The first cut got this wrong and probe.test.tsx case E caught it.

Supporting changes

• A scheme-aware alpha ramp. Unlike the brand tokens, #current alphas don't adapt to the color scheme — a 4% tint of a dark label on a light surface reads far stronger than 4% of a light label on a dark one. Each step now carries a light value, an @dark value, and a theme=special value (special is static across light/dark/HC by design, so one ramp). Each step lives in its own custom property rather than inline in fill: three ramps in one state-map would put ~18 alpha values where Tasty's mergeEntriesByValue pass coalesces equal value strings into one OR-entry at the group's max priority and breaks negation against lower-priority rules — the failure mode SPECIAL_OUTLINE_STYLES documents.
• ItemAction regains a focus ring. CURRENT_ITEM_STYLES follows the *_ITEM_STYLES convention of leaving focus to the collection that owns the row, which is wrong for a focusable action. The ring moves into ItemAction's base styles, where every variant's own outline still overrides it, so only current is affected.
• ItemButton paints its actions' color. It renders actions as a sibling of the button rather than inside it — deliberately, so they aren't nested in a <button> — so currentcolor reached them from the page: a danger row handed its actions neutral text, and a special row handed them the page's dark text to tint on a dark purple surface. ActionsWrapper now carries the row's resting color, derived from the variant map rather than restating the palette.
• One variants map. Item's inline theme.type → styles object is now the exported ITEM_VARIANTS, shared with the color projection above so the two can't drift.

Field components

Every clear and trigger button in the field components drops its explicit type / validation theme and relies on the new default, so each takes the color of the field it sits in and follows a custom theme instead of being pinned to default.clear. Where that changes rendering, it changes it toward matching the field's own text:

Button	Invalid-state color	Change
Picker, FilterPicker clear	rgb(157,88,85)	none — trigger text already carries validation
ComboBox, SearchComboBox, SearchInput clear	rgb(157,88,85) → rgb(130,72,69)	now matches the input text exactly
ComboBox trigger	rgb(68,69,77) → rgb(130,72,69)	was neutral beside red input text
PasswordInput toggle	neutral → tinted	now follows the field
Select clear	rgb(157,88,85) → rgb(68,69,77)	no longer reddens when invalid

That last row is the one deliberate regression, and it surfaces a real inconsistency rather than being caused by this change: Select's trigger keeps neutral label text when invalid, while Picker and FilterPicker — also Item-based — tint theirs. So at main an invalid Select showed a neutral label beside a red clear button. The button now matches its own field, and the red border still signals invalidity. Fixing Select's non-tinting invalid label belongs in Select, and is worth a follow-up — masking it with a themed clear button is what we just removed.

ColorInput's pipette and DatePicker's calendar button had no explicit type and were already picking up current.

Tooling fix

.claude/worktrees is now excluded from vitest collection and from git. Vitest globs with dot: true, so other branches' checkouts were collected alongside the real suite: every spec ran twice, a CLI path argument matched as a substring in both trees, and failures were reported from code not on this branch. Worse for anything that writes — the registry generator behind pnpm audit-defaults resolves its output against process.cwd(), so a worktree's copy silently overwrote this tree's defaults.generated.ts with its own branch's registry, wiping the whole aliases block. oxlint src, prettier "src/**" and tsconfig are all rooted at src and were never affected.

Notes for the reviewer

• ItemAction / ItemBadge type returns to a plain 'current' default in the lint registry. The skip: 'context' it was given in feat(eslint-plugin): lint ui-kit with its own no-redundant-default-prop rule #1319 existed because the prop resolved through ItemActionProvider; it no longer does. isDisabled is still context-resolved and still skipped.
• A selected action inside a special row now paints #current.28 rather than inverting to a white pill — the inversion is a SPECIAL_CLEAR_STYLES signature that a single inherited ramp can't express.
• The ramp alphas (light .04/.06/.09/.12/.15, dark .07/.1/.14/.18/.22, special .15/.22/.28/.34/.4) are the main design tunables here if any step reads too strong or too weak.
• CURRENT_BUTTON_STYLES (Button's current type) has the same dark-scheme weakness but was left alone as out of scope.

Verification

• pnpm vitest run — 1870 passed, 1 skipped, 91 files
• pnpm lint clean, pnpm build clean, no new tsc errors (18, matching the main baseline)
• Every inherited color above was measured with pnpm probe:browser --computed and diffed against main, not reasoned about; the ComboBox trigger was the only unintended line that moved, and it was kept on purpose.

🤖 Generated with Claude Code

---

Note

Medium Risk
Wide visual surface across list actions and many field affordances, with intentional invalid-state color shifts; core styling is centralized but regressions would show as contrast or theme mismatches on special/dark surfaces.

Overview
ItemAction / ItemBadge default to type="current" instead of mirroring the host row's type from ItemActionProvider. Colors come from inherited currentcolor, so actions track hover, selected, and disabled with the row; explicit non-default theme still falls back to clear. Provider no longer maps row types onto clear.

Theme/styling plumbing: CURRENT_ITEM_STYLES gains a light / @dark / theme=special alpha ramp via custom properties, stronger selected chips, focus ring on ItemAction, and inherit-disabled so host-disabled rows are not double-faded. ITEM_VARIANTS, resolveItemVariant, and ITEM_RESTING_COLOR_VARIANTS centralize variants; ItemButton's ActionsWrapper sets resting row color for sibling actions.

Field components drop pinned type / getValidationTheme on clears and related controls so icons inherit the field text (notably invalid ComboBox trigger/clear align with input text; Select clear is neutral when invalid because the trigger label stays neutral).

Tooling: ESLint defaults treat type as 'current'; Vitest and .gitignore exclude .claude/worktrees.

^{Reviewed by Cursor Bugbot for commit 2bc4a71. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cube-ui-kit	Ready	Preview	Aug 17, 2026 8:35pm

[changeset-bot]

🦋 Changeset detected

Latest commit: 2bc4a71

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@cube-dev/ui-kit	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

🧪 Storybook is successfully deployed!

• 👀 Review changes: https://www.chromatic.com/build?appId=626ee6db91d1c8004a912249&number=3861
• 👨‍🎨 Preview storybook: https://626ee6db91d1c8004a912249-evlqnsjykn.chromatic.com/

[github-actions]

📦 NPM canary release

Deployed canary version 0.0.0-canary-2ac9da8.

[github-actions]

🏋️ Size limit report

Name	Size	Passed?
All	487.75 KB (+0.07% 🔺)	Yes 🎉
Tree shaking (just a Button)	119.78 KB (+0.16% 🔺)	Yes 🎉

Compared against main at f3d9a1f — run 32052281350, 2026-08-17T17:52:39Z.

Click here if you want to find out what is changed in this build

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2bc4a71. Configure here.}

[cursor]

Disabled actions stay full opacity

Medium Severity

Skipping the #current.4 fade when disabled is inherited assumes the host has already faded currentcolor. That holds for Item, where actions sit inside the row, but not for ItemButton, whose ActionsWrapper only paints the resting color via ITEM_RESTING_COLOR_VARIANTS. Inherited-disabled actions there keep full-strength labels while non-interactive.

Additional Locations (1)

• src/components/actions/ItemAction/ItemAction.tsx#L202-L207

 

^{Reviewed by Cursor Bugbot for commit 2bc4a71. Configure here.}