bvandeusenandClaude Opus 5
37616682f0
CI & Build / Python lint (push) Successful in 4s
CI & Build / Plugin hooks (push) Successful in 10s
CI & Build / integration (push) Successful in 31s
CI & Build / TypeScript typecheck (push) Successful in 34s
CI & Build / Python tests (push) Successful in 1m4s
CI & Build / Build & push image (push) Successful in 45s
Measured before deciding: across the ~100 bespoke button rules, vertical padding does not spread — it clusters. ~27 at 0.4–0.45rem, ~28 at 0.25–0.3rem, ~23 at 0.1–0.15rem. Those are three different components that happen to share a name prefix: a page action, a row action, and an affordance that lives inside a card. Collapsing them to the single size the shared sheet had would have visibly broken every card layout, which is why the one-off migration stopped here for a decision rather than proceeding on the assumption that a button is a button. default 8px 16px page action — what the house style specifies .btn-compact 4px 12px toolbar, table row, list item controls .btn-inline 2px 4px dismiss ×, confirm tick, add-chip .btn-small and .btn-sm already sat at the compact step, so they are kept as aliases for it — no template churn, and the two spellings stop being a third thing that might drift. .btn-inline is deliberately below the spacing scale's first step on the vertical axis: 4px of padding on an 11px label already exceeds the line box these sit in. Stated in the file so it reads as a measured exception rather than someone ignoring the scale. DesignView renders all three as real specimens. A size scale described in prose is one nobody can check; rendered from the actual classes, it cannot claim something the app does not do. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs