Burn down the 34 baselined Button className overrides (PLUTO-719 follow-up)

Sub-tickets

Activity

• wi-cli-venus created · 7w ago
• wi-cli-venus progress · 7w ago
  Batch 1 shipped 666906d, v2.23.38, PTD green (dpl_6VHJMhueU1RwCUYwZVH33Cjn9d2j). Baseline 29 keys/36 occ -> 20 keys/24 occ (12 burned). Done: size sm-compact (audit-log x2, roster-history-log x2, docente-membership-edit-form, docente-membership-actions) + variant destructive-outline (docente-membership-actions, alumno-remover-form) + existing icon-xs (practica-distribution-card, support-sop-ref x2). Both button.tsx additions are renames of tokens already inline, not new design. TWO THINGS THE NEXT BATCH NEEDS TO KNOW: 1. h-7 was NOT rendering flat. The inline class is unprefixed while size=sm carries sm:h-8, a later media-query rule, so those six sites rendered 28px mobile / 32px desktop. sm-compact pins exactly that. Reading an unprefixed height override as the final height is wrong on every one of these sites. 2. Moving an icon button to icon-xs silently SHRINKS its icon unless the child gets an explicit size- class: the cva base rule [and]_svg:not([class*=size-]) was already overriding h-4/h-3.5 children to 16px, and icon-xs would have taken them to 12px. Pinned size-4 at all three sites to preserve rendering. NEEDS A DESIGN CALL, NOT A BURN-DOWN (raised, not decided): the six sm-compact sites are 28px tall on mobile, below the PLUTO-40 Stage A 44px touch target. Raising them to h-11 sm:h-7 would change the height of every dense log/audit row on a phone. I did not make that call silently - it wants Elazar or pm. REMAINING 20 keys/24 occ, batched by what they need: (a) mobile-height family h-11 sm:h-6/7/8 - comision-filter, practica-detail x2, export-buttons, notifications-list, teacher-report x3 - needs one or more sm:h-N variants, and the three different desktop heights look like drift worth consolidating; (b) brand colour bg-[#8d1d01] + its outline form - export-buttons x2, teacher-report x2, error-card - wants a brand/brand-outline variant; (c) access-requests-list text-red-600/border-red-200 - deliberately NOT folded into destructive-outline this batch because red-600 is not the destructive token and the shift is unverified; (d) one-offs: app-sidebar, login-client x2 amber, impersonation-banner x2, lazy-audit-log gap-1 px-1, participant-change-panel + practicas-student-search h-auto justify-start x2, teacher-report h-auto multi-line, comentarios-list h-6 px-2 muted.
• wi-cli-venus progress · 7w ago
  Batch 2 shipped v2.23.39, PTD green (dpl_Heiip6Hysnkp4bYby3Ad8hMvuF2E). Baseline 20 keys/24 occ -> 15 keys/19 occ. Cumulative: 29/36 -> 15/19, 17 of 36 burned. Finding: the hardcoded brand hex WAS the token. globals.css sets --primary: #8d1d01, so bg-[#8d1d01] text-white re-spelled variant=default and border-[#8d1d01]/40 text-[#8d1d01] hover:bg-[#8d1d01]/10 re-spelled an outline in the same token at identical /40 and /10 opacities. Five sites were carrying a literal of a variable they already had. Solid sites (export-buttons, teacher-report, error-card Reintentar) -> variant=default, className gone. Outline sites (export-buttons, teacher-report) -> new outline-primary variant, pixel-identical. DELIBERATE VISUAL DELTA, stated not hidden: the three solid sites hardcoded a DARKER hover (#741800; error-card #6d1601) and variant=default hovers to primary/90 which is LIGHTER, so hover direction inverts on those three. I took the design-system answer over minting a brand variant that would hardcode a hex inside the system just to keep a hover shade. Reversible in one line if Elazar wants the darker hover back - it then belongs in --primary-hover, not in a className. REMAINING 15 keys/19 occ: (a) mobile-height family h-11 sm:h-6/7/8 - comision-filter, practica-detail x2, export-buttons, notifications-list, teacher-report x3 (8 occ) - needs sm:h-N variant(s); three different desktop heights look like drift worth consolidating, which is a design call; (b) access-requests-list text-red-600/border-red-200 - still held out of destructive-outline, red-600 is not the destructive token; (c) one-offs: app-sidebar, login-client x2 amber, impersonation-banner x2, lazy-audit-log gap-1 px-1, participant-change-panel + practicas-student-search h-auto justify-start x2, teacher-report h-auto multi-line, comentarios-list h-6 px-2 muted.
• wi-cli-venus progress · 7w ago
  Batch 3 shipped 27bca9f / v2.23.40 (PTD dpl_8xJ91GcRan9qsrW6m4PG661UsdPf). Baseline 15 keys/19 occ -> 12 keys/15 occ (cumulative 29/36 -> 12/15, 21 of 36 burned). Two retirements, different reasons: - typeahead option row: participant-change-panel and practicas-student-search carried the BYTE-IDENTICAL override (ghost + sm + "h-auto w-full justify-start px-2 py-1.5 font-normal") on a <Button> inside <li role="option">. Repeated pattern, so it earned size="option-row". The variant takes only the SIZE half; w-full/justify-start/font-normal stay at the call site as per-context layout (the lint regex does not flag them). has-[>svg]:px-2.5 carried verbatim from sm so nothing moves. - comentarios-list "h-6 px-2 text-xs text-muted-foreground": needed NO new variant. It was a hand-spelling of the existing size="xs" (h-6 gap-1 rounded-md px-2 text-xs). The only deltas are gap-1 vs gap-1.5 and the svg size-3 rule, both of which only bite with an icon child, and that site is the text-only "Eliminar". Now size="xs" + className="text-muted-foreground". REMAINING 12 keys/15 occ, and the cheap ones are gone - what is left needs decisions: (a) mobile-height family, 8 occ, BLOCKED on a design call: comision-filter (h-11 sm:h-6), practica-detail x2 (h-11 sm:h-6), export-buttons (h-11 sm:h-8), notifications-list (h-11 sm:h-8), teacher-report x3 (h-11 sm:h-7). All are load-bearing PLUTO-40 Stage A mobile fixes, so a bare className removal is a touch-target regression. THREE different desktop heights (sm:h-6/7/8) for the same class of dense filter chip reads as drift; minting three near-identical variants would freeze that drift into the design system, which is the opposite of the point. Consolidating to one desktop height is a visual decision, not a lint burn-down decision. Raising it rather than picking. (b) access-requests-list "text-red-600 border-red-200 hover:bg-red-50" (1) - deliberately held out of destructive-outline; red-600 is not the destructive token, so folding it in would be a silent colour change. (c) one-offs, each a single site with no second occurrence to justify a variant: login-client amber warning (2), app-sidebar grey (1), impersonation-banner amber + red (2), lazy-audit-log "gap-1 px-1" (1), teacher-report h-auto wrapping cell (1). Minting a variant per site is worse than the baseline entry; these are candidates for semantic tokens (a warning/impersonation colour pair) if that is ever wanted, not for size variants. Also noted for Stage A, not fixed here: the option-row renders ~32px (py-1.5 on text-sm), under the 44px touch target, and typeahead options are tapped on a phone. Preserved exactly rather than raised - same design call as (a).
• wi-cli-venus progress · 7w ago
  Batch 4 shipped 2ef3a86-class commit / v2.23.41 (PTD dpl_4fEmnHpcHTFAgjXjU4DiY5Qorc65). Baseline 12 keys/15 occ -> 7 keys/8 occ. Cumulative 29/36 -> 7/8: 28 of the original 36 occurrences burned. pm-pluto-cc ruling 2026-08-22 10:02 ART: h-8, one dense-chip variant, all 8 occurrences consolidate, h-6/h-7 were drift not intent. Option-row sub-44px explicitly out of scope (Stage B mobile-viewport, blocked on eq#48). Four one-offs + red-600 stay in baseline as proposed. size="chip" = h-11 sm:h-8 rounded-md gap-1.5 px-3 sm:px-2 text-xs has-[>svg]:px-2.5. Applied at comision-filter, practica-detail x2, export-buttons, notifications-list, teacher-report x3. Two independent corroborations that h-8 was the right target rather than a coin flip, found while making the edit and worth recording because they are the kind of evidence that settles a design question without a screenshot: - practica-detail: the historia-clinica <Input> at line 308 is h-11 sm:h-8, and the two edit buttons sitting beside it were sm:h-6. The chip was 8px SHORT of its own field on desktop. - export-buttons: the email-format <select> is h-11 sm:h-8 next to a button already at sm:h-8. That row was already correct, which is why sm:h-8 is the value the family converges on. Both are the same misalignment PLUTO-40 Stage B fixed on the mobile axis with sm-field (7a009bd); this is the desktop-axis twin. Deltas stated, not hidden: desktop height 24->32px (comision-filter, practica-detail x2), 28->32px (teacher-report x3), desktop padding 12->8px (export-buttons, notifications-list, which carried no px override and so inherited sm px-3). Mobile rendering unchanged at all eight - every one was already h-11 px-3, which is exactly why a bare className removal was never available and each needed the variant first. REMAINING 7 keys/8 occ, all pm-confirmed to stay in baseline, none of them size problems: - access-requests-list text-red-600 border-red-200 hover:bg-red-50 (1) - red-600 is not the destructive token; folding into destructive-outline would be a silent colour change. - login-client amber warning (2), app-sidebar grey (1), impersonation-banner amber + red (2) - semantic-colour one-offs. If these are ever wanted in the system it is as warning/impersonation TOKENS, not size variants. - lazy-audit-log gap-1 px-1 (1) - single-site padding on a ghost disclosure toggle. - teacher-report h-auto sm:h-auto items-start justify-start whitespace-normal py-2 text-left (1) - wrapping table cell, genuinely one-of-a-kind. The size half of this WI is done. What is left is a colour-token question, which is a different piece of work from a size-variant burn-down and should be filed separately if wanted.
• wi-cli-venus completed · 7w ago
  Size burn-down complete: 36 baselined occurrences -> 8, across four batches (666906d v2.23.38, v2.23.39, 27bca9f v2.23.40, v2.23.41), each PTD-verified live. 28 of 36 burned. Variants introduced, all with the call sites they earned: destructive-outline and outline-primary (variant), sm-compact, option-row and chip (size). Two sites needed NO new variant - error-card and export-buttons/teacher-report were re-spelling variant="default", and comentarios-list was re-spelling size="xs". The finding that generalises beyond this WI: the hardcoded brand hex WAS the token. bg-[#8d1d01] is exactly --primary in globals.css, so five sites had hand-spelled a variable they already had. Same shape at three more: h-6 px-2 text-xs was size="xs", and the dense chip was spelled at three different desktop heights (sm:h-6/h-7/h-8) for one visual role. A className override is usually not a deliberate exception - it is the design system being re-typed from memory, drifting a little each time. Two deltas stated rather than hidden, both accepted: - the three solid brand buttons hardcoded a DARKER hover (#741800 / #6d1601); variant="default" hovers LIGHTER (primary/90), so hover direction inverts there. If the darker hover is wanted back it belongs in a --primary-hover token, not a className. - the chip consolidation moves desktop height 24->32px at three sites and 28->32px at three, and desktop padding 12->8px at two. Mobile unchanged everywhere. Per pm ruling 2026-08-22 10:02 ART that h-6/h-7 were drift, not intent. Closed on the SIZE scope, not on an empty baseline. The remaining 7 keys / 8 occurrences are colour one-offs (amber warning pair, hardcoded greys, red-600, a wrapping cell, one padding tweak) that pm confirmed stay in the baseline - a variant with a single call site is worse than the baseline entry it would replace. Whether warning/impersonation deserve semantic tokens is filed as PLUTO-723. Coverage statement: verified via ui-standard-lint --check-tree (green after every batch), npx tsc --noEmit, the .gitpush-pre.sh gate, and PTD on all four deploys. NOT verified: rendered pixel output. No screenshot or visual diff was taken on any of the ~30 changed sites - the renderings are argued from the cva strings and tailwind-merge precedence, which is sound for the pure renames but is not the same as having looked at them. The chip/hover deltas above are known-intentional; an unintended one would not have been caught by anything run here. A visual pass on comision-filter, practica-detail, teacher-report, export-buttons and notifications-list is the honest next step if anyone wants certainty.