release(v2.2.0): TuxSearch de-AggieUX + Batch M control radius rule #55

Merged

A-Guevara merged 1 commit from feat/batch-m-control-radius into main 2026-09-08 16:40:08 +00:00

Conversation 1 Commits 1 Files changed 25 +932 -173

A-Guevara commented 2026-09-08 16:30:55 +00:00

Owner

Copy link

Rebuilds TuxSearch off its AggieUX port, and fixes a system-wide corner-radius bug that chasing its square corners surfaced.

TuxSearch — three shapes, field now the default

Through 2.1.0 this was a 1:1 port of the AggieUX search bar: its 60/51px heights, its 155/123px button widths, its 2px→3px border-thickening focus, its italic placeholder, its five raw hexes. Every tux move ratified since — two-ring focus, transportation-tempo easings, elevation tiers, rhythm ramp, wash ladder — had passed it by.

field (new default)	Leading glyph, hairline border, clear (×). 44 / 36px slim.
slab	Attached uppercase button, 2px rule, 60/51px, 44rem. Still the right editorial shape — no longer the default.
block	Heading + bar + lede on the rhythm ramp, role="search".

• Two-ring focus at a constant border width. The old 2px→3px thickening shifted the bar 1px on every focus.
• Corner-drop adapted from TuxCard, deliberately without the translate — the card moves because it's a navigation target; moving a text field out from under a live caret is hostile, so only the shadow lands.
• Solid brand fill moved --brand-primary → --brand-fill, so the slab keeps maroon on dark instead of flipping to gold the way the port did. Raw color literals 5 → 0; the file drops out of the tux-color literal budget.
• New: clear affordance, loading state, #suggestions scoped slot.

Breaking (visual): existing call sites render as field unless they pass variant="slab".

Batch M — the control radius rule

Three controls sitting side by side rendered at three radii: UButton 9px, .tux-pagination__btn 2px, TuxCommandPalette 6px. Batch K.2 exists specifically to prevent this and had caused half of it.

K.2 was solving for the wrong variable. Nuxt UI 4 never reads --radius-md. It re-declares the Tailwind radius scale inside an @theme default inline block as multiples of its own base:

--radius-sm: var(--ui-radius);
--radius-md: calc(var(--ui-radius) * 1.5);

inline substitutes those expressions straight into the utilities at build time, so rounded-md compiles to calc(var(--ui-radius) * 1.5) and never resolves tux's same-named token. The two scales share names but never meet in the cascade — which is why this was invisible.

Every U* control is rounded-md = 1.5× the base, so binding the base to --radius-md rendered them at 9px against tux chrome's 6px. Nuxt UI's untouched 0.25rem default had been landing on exactly 6px all along — K.2 moved them off the match it was written to create.

- --ui-radius: var(--radius-md);
+ --ui-radius: calc(var(--radius-md) / 1.5);

One rule, ratified (design/visual-language-evolution.md § Batch M): interactive controls use --radius-md; inline marks and chrome use --radius-sm. 15 declarations across 13 components moved. TuxKbd keycaps, TuxInlineCitation pills and display chips stay near-square deliberately — a <kbd> reads as a physical key at 2px and a pill at 6px — and now say so.

Breaking (visual): every U* control moves 9px → 6px.

Also

• Two install pages passed an invalid kind + title to TuxCallout — the repo's only two nuxt typecheck errors. Converted to TuxAlert. Typecheck is now clean.
• TuxPagination's docs claimed "square corners" as a system trait; that was describing the drift, not a decision.

Verification

• vitest 115/115
• eslint . clean
• nuxt typecheck clean (was 2 errors on main)
• ports-manifest --check census OK
• npm run build:kit produces no diff — token values unchanged
• Verified in-browser, light + dark: focus ring, corner-drop, clear, Escape, suggestions panel, and the 6px parity across UButton / TuxPagination / TuxDocsSidebar / TuxSearch

Rebuilds `TuxSearch` off its AggieUX port, and fixes a system-wide corner-radius bug that chasing its square corners surfaced. ## TuxSearch — three shapes, `field` now the default Through 2.1.0 this was a 1:1 port of the AggieUX search bar: its 60/51px heights, its 155/123px button widths, its 2px→3px border-thickening focus, its italic placeholder, its five raw hexes. Every tux move ratified since — two-ring focus, transportation-tempo easings, elevation tiers, rhythm ramp, wash ladder — had passed it by. | | | |---|---| | `field` **(new default)** | Leading glyph, hairline border, clear (×). 44 / 36px slim. | | `slab` | Attached uppercase button, 2px rule, 60/51px, 44rem. Still the right *editorial* shape — no longer the default. | | `block` | Heading + bar + lede on the rhythm ramp, `role="search"`. | - **Two-ring focus at a constant border width.** The old 2px→3px thickening shifted the bar 1px on every focus. - **Corner-drop** adapted from `TuxCard`, deliberately *without* the translate — the card moves because it's a navigation target; moving a text field out from under a live caret is hostile, so only the shadow lands. - Solid brand fill moved `--brand-primary` → `--brand-fill`, so the slab keeps maroon on dark instead of flipping to gold the way the port did. **Raw color literals 5 → 0**; the file drops out of the `tux-color` literal budget. - New: clear affordance, `loading` state, `#suggestions` scoped slot. **Breaking (visual):** existing call sites render as `field` unless they pass `variant="slab"`. ## Batch M — the control radius rule Three controls sitting side by side rendered at three radii: `UButton` **9px**, `.tux-pagination__btn` **2px**, `TuxCommandPalette` **6px**. Batch K.2 exists specifically to prevent this and had caused half of it. **K.2 was solving for the wrong variable.** Nuxt UI 4 never reads `--radius-md`. It re-declares the Tailwind radius scale inside an `@theme default inline` block as multiples of its own base: ```css --radius-sm: var(--ui-radius); --radius-md: calc(var(--ui-radius) * 1.5); ``` `inline` substitutes those expressions straight into the utilities at build time, so `rounded-md` compiles to `calc(var(--ui-radius) * 1.5)` and never resolves tux's same-named token. The two scales share names but never meet in the cascade — which is why this was invisible. Every U* control is `rounded-md` = **1.5× the base**, so binding the base to `--radius-md` rendered them at 9px against tux chrome's 6px. Nuxt UI's untouched 0.25rem default had been landing on exactly 6px all along — K.2 moved them *off* the match it was written to create. ```css - --ui-radius: var(--radius-md); + --ui-radius: calc(var(--radius-md) / 1.5); ``` **One rule, ratified** (`design/visual-language-evolution.md` § Batch M): interactive controls use `--radius-md`; inline marks and chrome use `--radius-sm`. 15 declarations across 13 components moved. `TuxKbd` keycaps, `TuxInlineCitation` pills and display chips stay near-square **deliberately** — a `<kbd>` reads as a physical key at 2px and a pill at 6px — and now say so. **Breaking (visual):** every U* control moves 9px → 6px. ## Also - Two install pages passed an invalid `kind` + `title` to `TuxCallout` — the repo's only two `nuxt typecheck` errors. Converted to `TuxAlert`. Typecheck is now clean. - `TuxPagination`'s docs claimed "square corners" as a system trait; that was describing the drift, not a decision. ## Verification - `vitest` 115/115 - `eslint .` clean - `nuxt typecheck` clean (was 2 errors on main) - `ports-manifest --check` census OK - `npm run build:kit` produces no diff — token values unchanged - Verified in-browser, light + dark: focus ring, corner-drop, clear, Escape, suggestions panel, and the 6px parity across `UButton` / `TuxPagination` / `TuxDocsSidebar` / `TuxSearch`

A-Guevara added 1 commit 2026-09-08 16:30:55 +00:00

release(v2.2.0): TuxSearch de-AggieUX + Batch M control radius rule ... 4d5b19015f

TuxSearch was a 1:1 port of the AggieUX search bar and stayed one — its
60/51px heights, its 2px→3px border-thickening focus, its square
corners, its five raw hexes. Every tux move ratified since (two-ring
focus, transportation-tempo easings, elevation tiers, rhythm ramp, wash
ladder) had passed it by. Chasing its corner radius surfaced a second,
system-wide bug in Batch K.2.

TuxSearch — three shapes, `field` now the default

* `field` (default): leading lucide:search glyph, hairline border,
  clear (×). 44/36px. What belongs in a toolbar — where the slab bar
  was being applied for want of an alternative (landscape-dashboard sat
  a 51px maroon SEARCH slab beside a 28px "Columns" button).
* `slab`: the attached-button editorial shape, 2px rule, 60/51px, 44rem.
  Right for hero strips; no longer the default.
* `block`: heading + bar + lede on the rhythm ramp, role="search".
* Two-ring focus at a CONSTANT border width — the old 2px→3px
  thickening shifted the bar 1px on every focus.
* Corner-drop adapted from TuxCard, deliberately without the translate:
  the card moves because it's a navigation target, but moving a text
  field out from under a live caret is hostile, so only the shadow
  lands.
* Solid brand fill moved --brand-primary → --brand-fill, so the slab
  keeps maroon on dark instead of flipping to gold. Raw color literals
  5 → 0; the file drops out of the tux-color literal budget.
* New: clear affordance, loading state, #suggestions scoped slot
  (combobox/aria-expanded/aria-controls + Escape + focus-out; consumers
  own the listbox semantics).

BREAKING (visual): existing call sites render as `field` unless they
pass variant="slab".

Batch M — the control radius rule

Three controls side by side rendered at three radii: UButton 9px,
.tux-pagination__btn 2px, TuxCommandPalette 6px. K.2 exists to prevent
exactly this and had caused half of it.

* K.2 was solving for the wrong variable. Nuxt UI 4 never reads
  --radius-md: it re-declares the Tailwind radius scale in an
  `@theme default inline` block as multiples of its own base
  (--radius-md: calc(var(--ui-radius) * 1.5)), and `inline` substitutes
  those expressions into the utilities at build time. Every U* control
  is rounded-md = 1.5x the base, so binding the base to --radius-md
  rendered them at 9px against tux chrome's 6px. Nuxt UI's untouched
  0.25rem default had been landing on 6px correctly all along. Now
  --ui-radius: calc(var(--radius-md) / 1.5).
* One rule, ratified: interactive controls use --radius-md; inline
  marks and chrome use --radius-sm. 15 declarations across 13
  components moved. TuxKbd keycaps, TuxInlineCitation pills and display
  chips stay near-square deliberately — and now say so.
* --radius-none retired from components; TuxSearch was its only user,
  carried over from AggieUX.

BREAKING (visual): every U* control moves 9px → 6px.

Also

* Two install pages passed an invalid `kind` + `title` to TuxCallout —
  the repo's only two typecheck errors. Converted to TuxAlert, which is
  the component that models severity. `nuxt typecheck` is now clean.
* TuxPagination's docs claimed "square corners" as a system trait; that
  was describing the drift, not a decision.

vitest 115/115, eslint clean, nuxt typecheck clean, ports manifest
census OK, npm run build:kit produces no diff.

ai-review-bot reviewed 2026-09-08 16:35:40 +00:00

ai-review-bot left a comment

Copy link

AI review · advisory

Verdict: looks good — all four reviewers found nothing that needs fixing.

_{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 1 distinct, 0 confirmed, 0 below threshold, 1 refuted · web: not used · context: 14 files under review · 90 codebase · 14 standards chunks (best-grounded: Laguna S 2.1; smaller windows saw less)}

Panel debate — how this review was reached

Grounding — context: 14 files under review · 90 codebase · 14 standards chunks (best-grounded: Laguna S 2.1; smaller windows saw less)

Round 1 — independent reviews

• GPT-OSS 120B (0 findings, confidence 0.97): No issues detected in the changed lines; the updates appear correct and consistent with the design specifications.
• Gemma 4 31B (0 findings, confidence 1.0): The changes are correct and consistent with the design goals outlined in the PR context and the wider codebase, specifically implementing the 'Batch M' control radius rules and the transition of TuxSe
• Devstral 2 123B (1 finding, confidence 0.9): The PR introduces a critical issue in the CSS calculation for --ui-radius, which will break Nuxt UI controls rendering.
• Laguna S 2.1 (0 findings):

Round 2 — cross-examination

• Devstral 2 123B#1 Incorrect calculation for --ui-radius · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1 · support 0

Raised but refuted (left out of the review above)

• Devstral 2 123B#1 Incorrect calculation for --ui-radius — The claim that calc(var(--radius-md) / 1.5) is invalid CSS is incorrect. CSS calc() allows division of a length variable by a unitless number, yie

Synthesis — Laguna S 2.1 wrote the final review from 0 confirmed findings · promotion: support ≥ 2, and no refutation at high severity.

_{Transcript rv-20260908163317-f30e84 — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.}

_{Advisory — never a merge gate. Findings are ordered by how well the panel's own evidence checks out, strongest first. React 👍/👎 on any inline comment to tell it whether it was worth flagging — that is the only feedback this system gets, and every threshold in it is tuned from those reactions. Transcript rv-20260908163317-f30e84.}

### AI review · advisory <!-- tti-rv:rv-20260908163317-f30e84: --> **Verdict: looks good** — all four reviewers found nothing that needs fixing. _{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 1 distinct, 0 confirmed, 0 below threshold, 1 refuted · web: not used · context: 14 files under review · 90 codebase · 14 standards chunks (best-grounded: Laguna S 2.1; smaller windows saw less)} <details> <summary>Panel debate — how this review was reached</summary> **Grounding** — context: 14 files under review · 90 codebase · 14 standards chunks (best-grounded: Laguna S 2.1; smaller windows saw less) **Round 1 — independent reviews** - **GPT-OSS 120B** (0 findings, confidence 0.97): No issues detected in the changed lines; the updates appear correct and consistent with the design specifications. - **Gemma 4 31B** (0 findings, confidence 1.0): The changes are correct and consistent with the design goals outlined in the PR context and the wider codebase, specifically implementing the 'Batch M' control radius rules and the transition of TuxSe - **Devstral 2 123B** (1 finding, confidence 0.9): The PR introduces a critical issue in the CSS calculation for --ui-radius, which will break Nuxt UI controls rendering. - **Laguna S 2.1** (0 findings): **Round 2 — cross-examination** - `Devstral 2 123B#1` Incorrect calculation for --ui-radius · confirmed: — · refuted: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1 · support 0 **Raised but refuted** (left out of the review above) - `Devstral 2 123B#1` Incorrect calculation for --ui-radius — The claim that `calc(var(--radius-md) / 1.5)` is invalid CSS is incorrect. CSS `calc()` allows division of a length variable by a unitless number, yie **Synthesis** — Laguna S 2.1 wrote the final review from 0 confirmed findings · promotion: support ≥ 2, and no refutation at high severity. _{Transcript `rv-20260908163317-f30e84` — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.} </details> _{Advisory — never a merge gate. Findings are ordered by how well the panel's own evidence checks out, strongest first. React 👍/👎 on any inline comment to tell it whether it was worth flagging — that is the only feedback this system gets, and every threshold in it is tuned from those reactions. Transcript `rv-20260908163317-f30e84`.}

A-Guevara merged commit 435d98c85b into main 2026-09-08 16:40:08 +00:00

A-Guevara referenced this pull request from a commit 2026-09-08 16:40:09 +00:00

Merge pull request 'release(v2.2.0): TuxSearch de-AggieUX + Batch M control radius rule' (#55) from feat/batch-m-control-radius into main

A-Guevara referenced this pull request from a commit 2026-09-08 17:09:19 +00:00

fix(a11y): valid ARIA role on TuxCodeMaroon + non-empty headings on /install

A-Guevara referenced this pull request 2026-09-08 17:09:51 +00:00

fix(a11y): valid ARIA role on TuxCodeMaroon + non-empty headings on /install #56

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

  

idea

Feature suggestion — shows on the repo's Ideas tab

  

points

1

Estimate: 1 point

  

points

13

Estimate: 13 points

  

points

2

Estimate: 2 points

  

points

3

Estimate: 3 points

  

points

5

Estimate: 5 points

  

points

8

Estimate: 8 points

  

priority

p0

Drop everything

  

priority

p1

High

  

priority

p2

Medium

  

priority

p3

Low

  

state

blocked

Blocked — see dependencies

  

state

done

Complete

  

state

in-progress

Being worked

  

state

ready

Ready to start

  

state

review

In review

  

state

triage

Needs triage

  

status

declined

Not planned — see the closing comment

  

status

in-progress

Actively being built

  

status

planned

Accepted — on the roadmap

  

status

proposed

New suggestion, not yet reviewed

  

status

shipped

Delivered

  

status

under-review

Being evaluated by maintainers

  

type

bug

Defect in existing behaviour

  

type

epic

Large body of work spanning multiple stories

  

type

feature

Shippable capability under an epic

  

type

spike

Time-boxed investigation / research

  

type

story

User-facing increment, points-estimated

  

type

task

Implementation unit under a story

No labels

idea

points

1

points

13

points

2

points

3

points

5

points

8

priority

p0

priority

p1

priority

p2

priority

p3

state

blocked

state

done

state

in-progress

state

ready

state

review

state

triage

status

declined

status

in-progress

status

planned

status

proposed

status

shipped

status

under-review

type

bug

type

epic

type

feature

type

spike

type

story

type

task

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

tti/tti-ux!55

No description provided.