refactor(ui): centralize destructive ghost button colors in EMCN

[BillLeoutsakosvl346]

Current stacked scope

This PR now targets #7998 and carries its original destructive-button migration plus child PRs already merged into this branch: #8071 (knowledge tag rows), #8136 (tag icons), #8138 (product corner radii), and #8017 (collapsible workflow field cards). Review the aggregate diff against the current #7998 base.

#8138 intentionally aligns product corners with the shared radius scale: 3→4px, 5→4px, and 10→8px at a 16px root size; fixed-pixel corners intentionally follow the scale at 20px. Its product screenshots, isolated treatment screenshots, and computed-radius matrix document that design decision. The unchanged-rendering statements below apply to the eleven destructive-button migrations only.

Original destructive-button change

Eleven product delete/remove buttons override EMCN Button colors locally. Add ghost-destructive (red at rest and on hover) and ghost-destructive-muted (muted at rest, red on hover) to the existing Button, and migrate all nine always-red and two muted consumers. Both use existing global color tokens.

For those eleven button migrations, the rendered class sets are identical. Geometry, icons, labels, handlers, disabled conditions, native button behavior and the input-format button's hover opacity remain unchanged. Existing Button variants and defaults are unchanged.

The original change is product only: 12 source files, with landing excluded. All audit tooling and browser fixtures stay outside the branch; no dependencies or new tests.

Original change validation

• 343 existing EMCN tests passed; EMCN/app type checks, repository lint, API validation and git diff --check passed.
• Consumer AST comparison confirms only the variant and color classes changed at all 11 locations.
• Real before/after Button and Trash renders have identical markup after class-order normalization. 110 Chromium comparisons match in light/dark idle, hover, focus, active and disabled states using compiled app CSS. All 210 existing variant/size/padding combinations render identical markup. These are isolated component checks, not end-to-end product navigation.
• Final external category audit: 22 color overrides across 11 buttons → 0. Broader findings 1003 → 981, with unrelated findings unchanged. Full inventory still has unrelated findings and analysis gaps. Landing diff is empty.
• Committed-diff audit: zero usage violations; four expected central-definition notices for the two new color variants.

[vercel]

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

Project	Deployment	Actions	Updated
docs	Ready	Preview	Sep 24, 2026 10:54pm UTC

[cubic-dev-ai]

No issues found across 12 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

The current head appears safe to merge, with no outstanding findings or newly introduced issues since the previous review.

Summary

This PR centralizes product styling through shared EMCN and design-system primitives while preserving existing rendered behavior.

• Adds reusable destructive ghost variants to the EMCN Button component and migrates destructive action consumers away from local color overrides.
• Replaces hard-coded border-radius values with equivalent Tailwind utilities or shared radius tokens across application and renderer surfaces.
• Refactors repeated tag and editor-row presentation into shared components and adds coverage for the updated collapsible-card behavior.
• The sole previous finding concerning the intentional global radius tokens was withdrawn, and its thread is resolved with no code change required.

_{Reviews (6) · Last reviewed commit: "Merge EMCN consolidation into destructiv..."}

[BillLeoutsakosvl346]

@greptileai @cubic-dev-ai Please review the current head. The previous scored reviews predate the base update.

[cubic-dev-ai]

@greptileai @cubic-dev-ai Please review the current head. The previous scored reviews predate the base update.

@BillLeoutsakosvl346 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 12 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[BillLeoutsakosvl346]

Before / after visual comparison

Destructive icon actions: shared Button treatments preserve the muted/red icon colors and geometry.

Within each numbered tile: first icon = before; second icon = after.

Rendered component fixtures with application CSS and local data, rather than authenticated product-page screenshots. These are representative visual examples, not end-to-end behavior coverage.

Current PR head checked at posting: 5653710ea0.

Additional theme/state comparisons

[BillLeoutsakosvl346]

@greptile

[BillLeoutsakosvl346]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@BillLeoutsakosvl346 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 13 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[BillLeoutsakosvl346]

@greptile Please review the current head 8241621 after the conflict resolution against the live modal-fields branch.

[BillLeoutsakosvl346]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@BillLeoutsakosvl346 I have started the AI code review. It will take a few minutes to complete.

[BillLeoutsakosvl346]

@greptile Please review the current head bb1ece7 against the new #7998 base. The prior #8009 base was already merged.

[BillLeoutsakosvl346]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@BillLeoutsakosvl346 I have started the AI code review. It will take a few minutes to complete.

[BillLeoutsakosvl346]

@greptile Thank you for withdrawing the radius-token finding. Please update the current-head summary and confidence score for bb1ece7; the thread is resolved and no code change is needed.

[cubic-dev-ai]

25 issues found across 79 files

Confidence score: 4/5

• The radius-token swaps in files such as apps/sim/app/(auth)/sso/loading.tsx and apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/resource-mention.tsx change rendered corner sizes, so skeletons and message chips may not match the geometry the PR intends to preserve — use values equivalent to the original radii.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/sim/app/(auth)/sso/loading.tsx">

<violation number="1" location="apps/sim/app/(auth)/sso/loading.tsx:10">
P3: `rounded-lg` here resolves to 8px, not the 10px it replaces: the app's theme sets `--radius: 0.5rem` and `--radius-lg: var(--radius)` (apps/sim/app/_styles/globals.css:1374, 193), so the two `h-[44px]` skeletons lose 2px of corner radius. This contradicts the PR claim that the rendered class sets are identical. Keep `rounded-[10px]` unless an 8px radius is the intended change.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/home/components/mothership-view/components/resource-content/components/browser-session/browser-session.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/components/mothership-view/components/resource-content/components/browser-session/browser-session.tsx:120">
P3: This class swap is not rendering-equivalent: `rounded-sm` resolves to `--radius-sm` = `calc(var(--radius) - 4px)` = 4px (with `--radius: 0.5rem` in `app/_styles/globals.css`), whereas the removed `rounded-[3px]` is exactly 3px. So the omnibox raster favicon's corner radius changes from 3px to 4px. That contradicts the PR's stated guarantee that rendered class sets are identical and only variant/color classes changed at the migrated call sites, and it is outside this PR's destructive-button scope. If the 1px change is intended (the repo's other favicon renders, e.g. `browser-tab-icon.tsx`, do use `rounded-sm`), call it out in the PR description; otherwise keep the original value.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/messages-input/messages-input.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/messages-input/messages-input.tsx:617">
P3: This swap of `rounded` for `rounded-sm` is not render-neutral in this app. `globals.css` (`@theme inline`) overrides `--radius-sm: calc(var(--radius) - 4px)`, so `rounded-sm` resolves 4px smaller than the previous bare `rounded` (which maps to `var(--radius)` in Tailwind v4). The role-select trigger's corner radius therefore shrinks by 4px, contradicting the PR's claim that geometry is unchanged — and this radius rename is unrelated to the destructive-button color work described. Revert to `rounded` unless the radius reduction is deliberate, in which case call it out in the PR description.</violation>
</file>

<file name="apps/sim/app/(interfaces)/chat/components/loading-state/loading-state.tsx">

<violation number="1" location="apps/sim/app/(interfaces)/chat/components/loading-state/loading-state.tsx:21">
P3: This change alters the chat loading skeleton's corner radius from 10px to 8px: `rounded-lg` resolves to 0.5rem, while `rounded-[10px]` was a literal 10px. That is an out-of-scope rendering change bundled into the button-color refactor, which otherwise claims identical geometry. The sibling `[identifier]/loading.tsx` already uses `rounded-lg` for the same skeleton, so the alignment may be intentional - confirm it belongs in this PR; otherwise revert to `rounded-[10px]`.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/agent-group/browser-agent-icon.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/agent-group/browser-agent-icon.tsx:130">
P3: `rounded-sm` is not pixel-equivalent to the `rounded-[3px]` it replaces. In this app's theme `--radius-sm` is `calc(var(--radius) - 4px)` (apps/sim/app/_styles/globals.css:191) with `--radius: 0.5rem` (8px, line 1374), so `rounded-sm` resolves to 4px while the old value was 3px — the favicon corner radius changes by 1px. Keep `rounded-[3px]` if the previous geometry must be preserved, or confirm the 1px change is intentional.</violation>
</file>

<file name="apps/sim/app/(auth)/login/loading.tsx">

<violation number="1" location="apps/sim/app/(auth)/login/loading.tsx:9">
P3: `rounded-[10px]` was replaced with `rounded-lg`, which resolves to 8px here (`--radius: 0.5rem` and `--radius-lg: var(--radius)` in apps/sim/app/_styles/globals.css), so all five 44px login skeletons shrink from a 10px to an 8px corner radius. Unlike `rounded-[4px]` → `rounded-sm` (exact 4px match), this does not preserve the original rendering. Revert these five to `rounded-[10px]`, or confirm the 2px reduction is intentional.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/resource-mention.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/resource-mention.tsx:12">
P3: `rounded-sm` resolves to 4px (`--radius-sm: calc(.5rem - 4px)`), so this changes the pill's corner radius from 5px to 4px. The PR description states geometry stays identical and only button color classes change; this mention pill (rendered as `<span>`/`<button>` text, not a Button variant) is outside that scope. Keep `rounded-[5px]` unless the 1px radius change is intentional.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/text/text.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/text/text.tsx:36">
P3: This swap of `[&_code]:rounded` to `[&_code]:rounded-sm` is unrelated to the PR's stated scope (centralizing destructive ghost-button colors in Button; the description says only variant/color classes changed). It restyles the radius of inline `<code>` chips inside HTML-rendered Text blocks with no rationale in the PR. If this was not intentional, drop it; otherwise document why the radius class is being changed in a button-color refactor.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/logs/components/dashboard/components/status-bar/status-bar.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/logs/components/dashboard/components/status-bar/status-bar.tsx:88">
P3: This change alters the rendered status-bar segment corner radius from 3px to 4px: `rounded-sm` resolves via `--radius-sm: calc(var(--radius) - 4px)` (globals.css:191) with `--radius: 0.5rem` (globals.css:1374), i.e. 4px, while `rounded-[3px]` was exactly 3px. The PR is scoped to EMCN ghost-destructive button colors and this file is not one of the 11 consumers, so the radius change is unrelated and contradicts the "geometry unchanged" claim; the visual comparisons described in the PR did not exercise this component. Either revert to `rounded-[3px]` if the radius must stay 3px, or document this as an intended change.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/selector-input/selector-input.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/selector-input/selector-input.tsx:80">
P3: This swap of `rounded` for `rounded-sm` changes the rendered corner radius, so it does not belong to the destructive-button color refactor and contradicts the PR's identical-rendering claim. Under this app's Tailwind v4 tokens, bare `rounded` resolves to `var(--radius)` = 0.5rem (globals.css line 1374) while `rounded-sm` resolves to `--radius-sm` = calc(0.5rem - 4px) = 4px (globals.css line 191), so the 'Selector not supported' box shrinks from 8px to 4px corners. This file is not one of the 11 EMCN button consumers, so the change looks accidentally included; revert it (or split it into its own PR if the radius change is intentional).</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/chat-content/external-link.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/chat-content/external-link.tsx:74">
P3: `rounded-sm` renders 4px (Tailwind v4 default 0.25rem), not the 3px this class previously produced. `apps/sim/devDependencies.tailwindcss` is ^4.3.3, and no `--radius-sm` override exists in `apps/sim/app/_styles/globals.css` (`@theme inline`/`@theme static`) or `tailwind.css`, so this silently changes the favicon's corner radius (3px → 4px); in v3 it would have been 2px, never 3px. This radius edit is unrelated to the PR's destructive-button purpose and is absent from the PR description, which otherwise claims rendering stays identical. Unless a radius change was intended, keep `rounded-[3px]` (or note the change explicitly).</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/home/components/queued-messages/queued-messages.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/components/queued-messages/queued-messages.tsx:100">
P3: `rounded-sm` does not preserve the old radius. The app theme defines `--radius-sm: calc(var(--radius) - 4px)` with `--radius: 0.5rem` (apps/sim/app/_styles/globals.css:191, 1374), so `rounded-sm` resolves to 4px while the removed `rounded-[5px]` was 5px. The attachment chip's radius changes by 1px, contrary to the PR's stated identical-geometry guarantee. Keep `rounded-[5px]` if identical rendering is intended.</violation>
</file>

<file name="apps/sim/app/(interfaces)/chat/[identifier]/loading.tsx">

<violation number="1" location="apps/sim/app/(interfaces)/chat/[identifier]/loading.tsx:27">
P3: `rounded-lg` is not size-equivalent to the removed `rounded-[10px]`. The `@theme inline` token `--radius-lg` resolves to `var(--radius)` = 0.5rem = 8px (globals.css lines 193, 1374), so these two `h-10 w-full` skeleton placeholders render with an 8px instead of 10px corner radius. The other three substitutions are pixel-identical (rounded-sm=4px, rounded-md=6px, rounded-xl=12px). This is the only non-identical arbitrary→token conversion in the diff; keep the radius unchanged.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/files/components/file-viewer/rich-markdown-editor/menus/suggestion-menu-chrome.ts">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/files/components/file-viewer/rich-markdown-editor/menus/suggestion-menu-chrome.ts:20">
P3: This changes geometry: the suggestion-menu row radius drops from 5px to 4px. The app's `@theme` defines `--radius-sm: calc(var(--radius) - 4px)` with `--radius: 0.5rem`, so Tailwind v4's `rounded-sm` resolves to 4px, not the `rounded-[5px]` it replaces. That contradicts the PR's claim that geometry and rendered class sets are unchanged, and it is unrelated to the destructive-button scope. Revert to `rounded-[5px]` unless the token alignment is intentional.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/files/components/file-viewer/rich-markdown-editor/image.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/files/components/file-viewer/rich-markdown-editor/image.tsx:289">
P3: This swaps a 3px radius (`rounded-[3px]`) for `rounded-sm`, which resolves to 4px here (`--radius-sm: calc(var(--radius) - 4px)`, `--radius: 0.5rem`), so the resize-handle indicator renders 1px more rounded than before. That contradicts the PR's "rendered class sets are identical" claim and is unrelated to the ghost-destructive color work. Keep `rounded-[3px]` here (or call out the radius change separately if intended).</violation>
</file>

<file name="apps/sim/app/unsubscribe/loading.tsx">

<violation number="1" location="apps/sim/app/unsubscribe/loading.tsx:10">
P3: `rounded-lg` resolves to `var(--radius)` = 0.5rem (8px) in this app's theme, so this skeleton's corner radius changes from 10px to 8px. Each other substitution matches (rounded-xl = 0.75rem = 12px, rounded-sm = calc(0.5rem - 4px) = 4px), but the button-shaped skeleton at the bottom stays at 10px (its actual `rounded-[10px]`) only if you keep the arbitrary value. If the intent was a pixel-identical radius sweep, restore `rounded-[10px]`.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/chat-content/chat-content.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/chat-content/chat-content.tsx:337">
P3: `rounded-[5px]` (5px) and `rounded-sm` are not equivalent in this repo: globals.css sets `--radius-sm: calc(var(--radius) - 4px)` with `--radius: 0.5rem`, so `rounded-sm` is 4px. This shrinks the wsres link chip radius by 1px, contradicting the PR's unchanged-geometry/identical-rendering claim. Keep `rounded-[5px]` unless the 4px radius is intended.</violation>
</file>

<file name="apps/sim/app/(auth)/signup/loading.tsx">

<violation number="1" location="apps/sim/app/(auth)/signup/loading.tsx:9">
P3: This swap is not value-preserving: `--radius-lg` resolves to `var(--radius)` = 0.5rem = 8px, so the 44px-high skeletons change from a 10px to an 8px corner radius. The theme in `apps/sim/app/_styles/globals.css` sets `--radius: 0.5rem` (both `:root` and `.dark`), `--radius-lg: var(--radius)`, `--radius-sm: calc(var(--radius) - 4px)` = 4px (so the `rounded-sm` swaps are exact). Keep the 10px corners via `rounded-[10px]`, or switch `--radius-lg` if 8px is actually intended for these strips.</violation>
</file>

<file name="apps/sim/app/(auth)/verify/loading.tsx">

<violation number="1" location="apps/sim/app/(auth)/verify/loading.tsx:9">
P3: `rounded-lg` does not reproduce the original 10px radius here. The app theme (`apps/sim/app/_styles/globals.css`) sets `--radius: 0.5rem` and maps `--radius-lg: var(--radius)` and `--radius-sm: calc(var(--radius) - 4px)` inside `@theme inline`, so `rounded-sm` resolves to 4px (the three `rounded-[4px]` replacements are exact) but `rounded-lg` resolves to 8px — 2px less than the `rounded-[10px]` it replaces. This changes the corner radius of the button-shaped skeleton, contradicting the PR's visual-equivalence claim. No token maps to 10px, so keep `rounded-[10px]`.</violation>
</file>

<file name="apps/sim/app/invite/[id]/loading.tsx">

<violation number="1" location="apps/sim/app/invite/[id]/loading.tsx:10">
P3: This replacement changes the rendered radius: `rounded-lg` resolves to `var(--radius)` (`--radius: 0.5rem` in `apps/sim/app/_styles/globals.css`), i.e. 8px, not the original 10px of `rounded-[10px]`. The other four replacements are value-identical (`rounded-xl` = 12px, `rounded-sm` = `calc(var(--radius) - 4px)` = 4px), so this fifth line silently shrinks the button-shaped skeleton's corner radius by 2px in a refactor whose other changes preserve rendering. Keep `rounded-[10px]` (or confirm 8px is intended).</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/source-chip/source-chip.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/source-chip/source-chip.tsx:78">
P3: `rounded-sm` resolves to 4px here, not 3px: `--radius-sm: calc(var(--radius) - 4px)` with `--radius: 0.5rem` in globals.css. So this swaps the 12px favicon's corner radius from 3px to 4px. That is a real rendered change, and it sits outside the PR's declared scope (only button variant/color classes, identical rendered markup). Either keep `rounded-[3px]` to preserve the current rendering, or document the rounding change as intended.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/logs/logs.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/logs/logs.tsx:199">
P3: `rounded-sm` resolves to `var(--radius-sm)` = `calc(var(--radius) - 4px)` = 4px (`--radius: 0.5rem` in apps/sim/app/_styles/globals.css), so this substitutes the previous `rounded-[3px]` (3px) with a 4px corner radius on the color swatch. The rendered output is no longer identical, and this radius change is outside the ghost-destructive button migration the PR describes. Keep `rounded-[3px]`, or use `rounded-sm` for both swatches only if the 1px visual change is intended and documented. Same applies to the status-dot line (`className='shrink-0 rounded-sm'`).</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/home/components/mothership-view/components/resource-registry/browser-tab-icon.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/components/mothership-view/components/resource-registry/browser-tab-icon.tsx:67">
P3: `rounded-sm` computes to 4px here (--radius-sm: calc(0.5rem - 4px) in globals.css), not the 3px the arbitrary class produced, so this favicon's corner radius changes by 1px and the rendered geometry is no longer identical to before. No token maps to 3px (xs is 2px, sm is 4px), so revert to `rounded-[3px]` if pixel-identical output is required, or keep `rounded-sm` and update the PR's identical-geometry claim accordingly.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/source-card/source-card.tsx">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/home/components/message-content/components/source-card/source-card.tsx:148">
P3: `rounded-sm` renders 4px, not 3px: the theme token is `--radius-sm: calc(var(--radius) - 4px)` with `--radius: 0.5rem` (8px) in apps/sim/app/_styles/globals.css, so the favicon corner radius changes from `rounded-[3px]` (3px) to 4px. That is an actual rendered change, and it is outside this PR's destructive-button scope, which claims geometry and all non-color classes remain unchanged. Either keep `rounded-[3px]` or state the intended 1px change explicitly.</violation>
</file>

<file name="apps/sim/app/workspace/[workspaceId]/files/components/file-viewer/rich-markdown-editor/rich-markdown-editor.css">

<violation number="1" location="apps/sim/app/workspace/[workspaceId]/files/components/file-viewer/rich-markdown-editor/rich-markdown-editor.css:40">
P3: This substitution is the only line in the file where the pixel value actually changes: the task-list checkbox previously rendered `border-radius: 3px` and now renders `var(--radius-sm)`, which is `calc(var(--radius) - 4px)` = 4px (globals.css: `--radius: 0.5rem`). Every other hardcoded radius in this diff maps pixel-identically (2px→`--radius-xs`, 4px→`--radius-sm`, 8px→`--radius-lg`), so this is a real 1px change to the rendered checkbox in all themes, contradicting the PR's 'geometry unchanged' claim. If the swap was meant to be value-preserving, keep 3px; if matching the emcn Checkbox (its `rounded-sm` resolves to the same `--radius-sm` = 4px) is intended instead, note the deviation explicitly.</violation>
</file>

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>

[BillLeoutsakosvl346]

@cubic-dev-ai review this PR. The description now lists the merged child PRs. I answered and resolved all 31 radius threads using the explicit #8138 design decision and its 16px/20px computed-radius evidence. Please review the current bb1ece7 head against #7998.

[cubic-dev-ai]

@cubic-dev-ai review this PR. The description now lists the merged child PRs. I answered and resolved all 31 radius threads using the explicit #8138 design decision and its 16px/20px computed-radius evidence. Please review the current bb1ece7 head against #7998.

@BillLeoutsakosvl346 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 79 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>You've manually re-run cubic several times on this PR. Each manual re-review checks the full PR again and counts toward your usage quota. To preserve your usage limits, we recommend letting cubic automatically review new commits.

Re-trigger cubic</sub>