Control scale: Button/IconButton primitives, two-height tokens, app-wide migration

.claude/skills/alignment/SKILL.md

@@ -55,6 +55,17 @@ Review all changes in scope. If changes span multiple patterns below, apply all
 5. **Styles and UI**: When altering CSS or layout, follow or generalize existing patterns
    (CSS Modules + design tokens in `styles/tokens.css`) rather than writing from scratch. Don't
    fix whitespace/formatting (trailing newlines etc.) — Prettier owns that.
+   - **Control primitives & the two-height scale** (arch 09 §4): action buttons are the
+     `Button` component, icon-only buttons are `IconButton` — never a freshly styled
+     `<button>`. Interactive controls are `var(--control-height)` (32px) or
+     `var(--control-height-lg)` (40px); a hardcoded control height (28px, 36px, …) in a
+     diff is a finding. A freshly written bordered-field recipe is the same finding —
+     fields share one look (1px `--border-strong`, `--bg` fill, `--control-height`); a
+     new input should copy an existing field class, not re-derive it. Call-site classes composed onto a primitive may only do layout
+     (flex, margins, reveal) or a documented state accent (outlined-danger, pressed) —
+     restyling the primitive's box from a call site is a finding. Borders mark function:
+     value-holding controls get `--border-strong` boxes; plain actions are ghost or
+     filled; list rows are flat with dividers, not stacked boxes.
 
 6. **Code Comments**: Comments should not duplicate what the code already says. Remove
    parroting comments. Ensure comments capture non-obvious _why_ — design decisions,