Move the remaining radius derivations onto the shape roles #255

New issue

Open

opened 2026-08-25 14:04:48 +00:00 by nalum · 0 comments

nalum commented

2026-08-25 14:04:48 +00:00

Owner

The shape roles exist now: radius-panel and radius-btn are authored per theme in design/tokens.yaml, generated into every surface, and the generator refuses a theme without them. The jobs flow reads them (.job-panel, .btn-done, .job-more, the ask-dialog buttons; Compose jobPanel(), the App*Button family, JobMoreButton).

The rest of the app still derives its corners locally. web/src/app.css holds about twenty calc(var(--radius) - Npx) and calc(var(--radius) / 2) rules (pin keys, me-menu items, calendar chips, event rows, and more), plus a few hard-coded 13px (.cal-pick-day, .menu-row). Android mirrors the habit with RoundedCornerShape((tokens.radiusDp - N).coerceAtLeast(...)) and minOf(tokens.radiusDp, 12) in Errors.kt, TopBar.kt, More.kt, Home.kt, SwitchSheet.kt and others.

Each of these is a place where the two surfaces can disagree per theme — the same defect the jobs flow had on hearth (panel 2px on web, 12dp on Android) before the roles landed.

The sweep:

Classify every derivation: is it a panel corner, a button corner, or genuinely a third shape?
Panel-shaped and button-shaped rules read --radius-panel / --radius-btn (radiusPanelDp / radiusBtnDp).
Anything that is genuinely neither either gets its own role in tokens.yaml or a written verdict in the commit message for why it stays derived.
Check each rule's Compose twin in the same pass — the sweep of one surface is how the last divergence was missed.
Goldens re-record where corners move, in their own commit.

Context: the roles were minted in feat(tokens): the panel and button radii become generated roles (job-card-demo.dc.html §9 — read the role, never derive it).

The shape roles exist now: `radius-panel` and `radius-btn` are authored per theme in `design/tokens.yaml`, generated into every surface, and the generator refuses a theme without them. The jobs flow reads them (`.job-panel`, `.btn-done`, `.job-more`, the ask-dialog buttons; Compose `jobPanel()`, the `App*Button` family, `JobMoreButton`). The rest of the app still derives its corners locally. `web/src/app.css` holds about twenty `calc(var(--radius) - Npx)` and `calc(var(--radius) / 2)` rules (pin keys, me-menu items, calendar chips, event rows, and more), plus a few hard-coded `13px` (`.cal-pick-day`, `.menu-row`). Android mirrors the habit with `RoundedCornerShape((tokens.radiusDp - N).coerceAtLeast(...))` and `minOf(tokens.radiusDp, 12)` in `Errors.kt`, `TopBar.kt`, `More.kt`, `Home.kt`, `SwitchSheet.kt` and others. Each of these is a place where the two surfaces can disagree per theme — the same defect the jobs flow had on hearth (panel 2px on web, 12dp on Android) before the roles landed. The sweep: - Classify every derivation: is it a panel corner, a button corner, or genuinely a third shape? - Panel-shaped and button-shaped rules read `--radius-panel` / `--radius-btn` (`radiusPanelDp` / `radiusBtnDp`). - Anything that is genuinely neither either gets its own role in `tokens.yaml` or a written verdict in the commit message for why it stays derived. - Check each rule's Compose twin in the same pass — the sweep of one surface is how the last divergence was missed. - Goldens re-record where corners move, in their own commit. Context: the roles were minted in `feat(tokens): the panel and button radii become generated roles` (job-card-demo.dc.html §9 — read the role, never derive it).

nalum added the

area/design-system

enhancement

labels

2026-08-26 18:49:18 +00:00