---
status: queued
classification: server-only-no-actually-just-frontend-styles-cleanup
parent_convoy: unify-glass-panel-surfaces
blocked_by: []
size: small
budget_hours: 2-3
---

# migrate-button-input-mobilenav-to-glass-primitive

## Why

The `unify-glass-panel-surfaces` convoy's Brief 7 added a CI gate that
forbids bespoke `var(--glass-surface-*)` inline-style usage outside a
documented allowlist. When the gate was being added, three files
turned out to still handroll their own glass surfaces and had to be
admitted to the allowlist to ship the gate now:

- `components/ui/Button.js` — the `secondary` variant carries
  `style={{ background: 'var(--glass-surface-high)', backdropFilter:
  '...' }}` and a Tailwind arbitrary class
  `hover:bg-[var(--glass-surface-mid)]`.
- `components/ui/Input.js` — the input fill is `style={{ background:
  'var(--glass-surface-high)', backdropFilter: '...' }}` on the
  outer wrapper of the input control.
- `components/MobileNavigation.js` — the bottom-nav background
  layer is `style={{ background: 'var(--glass-surface-mid)',
  backdropFilter: '...' }}`.

The pattern (inline `background: var(--glass-surface-X)` + inline
`backdropFilter`) is exactly what the convoy spent six briefs
eliminating elsewhere. These three are the residual.

## Goal (1 sentence)

Migrate `components/ui/Button.js`'s `secondary` variant,
`components/ui/Input.js`, and `components/MobileNavigation.js` to
compose `<GlassSurface>` (with the right `cornerLights` + `blur` +
`tint` props from Brief 1) or the appropriate `.glass-panel-*` /
`.page-header-glass` class, then **delete** the three entries from
the `forbidden-bespoke-glass-surface` allowlist in
`.github/workflows/ci.yml` so the gate covers them too.

## Files in scope

- `components/ui/Button.js` — the `secondary` variant block only;
  leave `primary`, `danger`, `ghost`, etc. as-is unless they
  legitimately need the same migration (they don't today).
- `components/ui/Input.js` — the outer wrapper style only.
- `components/MobileNavigation.js` — the bottom-nav backdrop layer
  only.
- `.github/workflows/ci.yml` — the `forbidden-bespoke-glass-surface`
  check (now Check 7/7 of the consolidated `forbidden-patterns`
  job). Delete the three pending entries from `GLASS_ALLOWLIST`,
  leaving only the 3 chrome blocks.

## Open questions for the architect

1. **`<Button variant="secondary">` — `<GlassSurface>` or class?**
   The button uses a complex `backdropFilter` + `boxShadow` stack
   matching `glass-panel-strong`'s look. Composing
   `<GlassSurface tint="high" blur="low" cornerLights="subtle">`
   keeps it tokenized and means `cornerLights` ripples in for free.
   The hover variant (`hover:bg-[var(--glass-surface-mid)]`) needs
   a different solution — either a `hover` prop on `<GlassSurface>`,
   or wrap the hover state in a separate utility class. Recommend
   pulling the hover into a CSS variable swap on the `:hover`
   pseudo-class of a new utility class (`.glass-surface-hover-shift`
   or similar), authored in `styles/globals.css`.

2. **`<Input>` — `<GlassSurface as="div">` wrapping the native
   `<input>`?** That's the most consistent shape, but the current
   `<Input>` API takes inline-style props the wrapper would have to
   forward. Easier alternative: add `.glass-input` utility class to
   `styles/globals.css` mirroring `.glass-panel-strong`'s shape but
   with `border-radius: 8px` and the input-specific focus ring.

3. **`<MobileNavigation>` — `.page-header-glass`?** That class was
   designed for the desktop top-of-page strip; the bottom-nav has
   the same "full-bleed translucent chrome" semantics inverted
   vertically. Either reuse the class (simplest), or introduce a
   `.glass-bottom-nav` mirror. Recommend reuse since the visual
   contract is identical aside from vertical anchoring (controlled
   by the consumer's `<div className="fixed bottom-0 ...">`).

## Acceptance criteria (draft — architect to ratify)

- [ ] `Button.js` secondary variant uses `<GlassSurface>` or a
  documented `.glass-*` class.
- [ ] `Input.js` outer wrapper uses `<GlassSurface>` or a
  documented `.glass-input` class.
- [ ] `MobileNavigation.js` bottom-nav backdrop uses
  `.page-header-glass` (or `.glass-bottom-nav` if the architect
  decides on a mirror).
- [ ] `grep -lE "var\(--glass-surface-(low|mid|high)\)" pages
  components -r --include='*.js'` returns **only the 3 chrome
  files** (Layout, TopSearchBar, GlassSurface).
- [ ] `.github/workflows/ci.yml`'s `GLASS_ALLOWLIST` is reduced
  from 6 entries to 3.
- [ ] Visual diff against `main` shows no regression in the
  `secondary` button, the `<Input>` control, or the bottom-nav
  surface in both themes.
- [ ] `npm run lint` + `npm run test:run` both green.

## Out of scope

- Other `Button` variants (primary, danger, ghost) — they don't
  use `var(--glass-surface-*)`.
- The `<GlassSurface>` primitive itself — Brief 1 already shipped
  the `cornerLights` prop; this convoy just adopts it in 3 places.
- Any other component the grep doesn't currently flag — if a new
  file appears in the grep result after this convoy lands, that's
  a separate convoy (per the `forbidden-bespoke-glass-surface`
  gate's own friction principle).

## Pre-work the conductor should verify

- Brief 1 (`<GlassSurface>` cornerLights prop) has merged. ✅ — PR #123.
- Brief 7 (this convoy's parent gate) has merged.
- The 3 target files still contain `var(--glass-surface-*)` inline
  styles (re-run the grep at kickoff).

## Notes for future agents

The 3 files are independent — there's no shared abstraction across
them. Recommend treating this as 3 small briefs (one per file) the
architect can dispatch in parallel after deciding the migration
shape per file in the open questions above. If the architect chooses
the "add `.glass-input` and `.glass-bottom-nav` mirror utility
classes" path, those style additions belong in a 4th brief that
ships first.