@flytedan/flytebot-design-system 0.12.10 → 0.12.12

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flytedan/flytebot-design-system",
-  "version": "0.12.10",
+  "version": "0.12.12",
   "description": "flytedesk Design System — shared component library, tokens, and business-logic kits for flytedesk apps.",
   "type": "module",
   "license": "UNLICENSED",

package/styles/components.css

@@ -176,13 +176,23 @@
   background: var(--surface);
   box-shadow: var(--e-1);
 }
-/* Tone on a quiet (ghost/outline) icon button: the glyph carries it, on hover too. */
-.fd-btn-icon.is-ok:not(.fd-btn-icon-solid),
-.fd-btn-icon.is-ok:not(.fd-btn-icon-solid):hover {
+/* Tone on a quiet (ghost/outline) icon button: the glyph carries it, on hover too.
+   MP-114 follow-up: also excludes .fd-btn-icon-soft, which was never meant to match
+   here (it isn't ghost or outline — it has its own real fill, see .fd-btn-icon-soft
+   below) but did, at (0,3,0) beating the soft rule's own un-toned (0,1,0)/toned
+   (0,2,0) color rules at rest. That stomped --btn-soft-ok-ink/--btn-soft-danger-ink
+   (chosen to clear 4.5:1 against the soft fill) with --ok-text/--danger-text (chosen
+   to clear 4.5:1 against a plain card instead) — a real fill behind the wrong ink,
+   e2e-measured at 2.04:1. The soft rule's own `:hover`/`:active` restatements already
+   won their own specificity fight against this same rule's `:hover` (both (0,3,0),
+   soft declared later so it wins the tie) — only the REST state, where soft never
+   restated color at all, actually lost. */
+.fd-btn-icon.is-ok:not(.fd-btn-icon-solid):not(.fd-btn-icon-soft),
+.fd-btn-icon.is-ok:not(.fd-btn-icon-solid):not(.fd-btn-icon-soft):hover {
   color: var(--ok-text);
 }
-.fd-btn-icon.is-danger:not(.fd-btn-icon-solid),
-.fd-btn-icon.is-danger:not(.fd-btn-icon-solid):hover {
+.fd-btn-icon.is-danger:not(.fd-btn-icon-solid):not(.fd-btn-icon-soft),
+.fd-btn-icon.is-danger:not(.fd-btn-icon-solid):not(.fd-btn-icon-soft):hover {
   color: var(--danger-text);
 }
 /* Solid: a real fill in the tone's colour. The fills and inks are the --btn-solid-*
@@ -234,7 +244,22 @@
 /* Soft: a lighter fill than solid, with a visibly darker border drawn around it (MP-52's
    "lighter fill, darker border" row action). Same --btn-soft-* tokens (tokens.css), same
    per-theme measurement discipline as solid, and the same pressed-selector-specificity
-   fix baked in from the start (see the comment on .fd-btn-icon-solid:active above). */
+   fix baked in from the start (see the comment on .fd-btn-icon-solid:active above).
+
+   MP-114 hover/active: the base `.fd-btn-icon:hover`/`:active` rules above (plain
+   `.fd-btn-icon`, no variant) set `background` too, at the same (0,2,0) specificity as
+   `.fd-btn-icon-soft:hover`/`:active` — a tie the cascade breaks by source order, so
+   whichever rule sets `background` LAST wins. The old hover/active rules here only set
+   `filter` and `color`, never `background`, so they never entered that tie for the
+   `background` property at all: the base rule's `background: var(--surface-3)` /
+   `var(--border)` was the only declaration left standing, and the soft fill vanished
+   under a plain neutral surface colour while the ink stayed tuned for the soft fill —
+   e2e-measured at 1.11:1. `filter: brightness()` made it worse in a way no contrast
+   check (this file's or a screen reader user's own eye) could catch: a filter changes
+   the pixels without ever touching `background-color`, so it cannot be reasoned about
+   from the declared colours at all. Fixed on both counts: every state below restates a
+   real `background` from a real token, so it wins its own tie the same way solid's
+   already does, and there is no filter left to hide behind. */
 .fd-btn-icon-soft {
   background: var(--btn-soft-bg);
   color: var(--btn-soft-ink);
@@ -243,26 +268,36 @@
 }
 .fd-btn-icon-soft.is-ok {
   --btn-soft-bg: var(--btn-soft-ok-bg);
+  --btn-soft-bg-hover: var(--btn-soft-ok-bg-hover);
+  --btn-soft-bg-active: var(--btn-soft-ok-bg-active);
   --btn-soft-border: var(--btn-soft-ok-border);
   --btn-soft-ink: var(--btn-soft-ok-ink);
 }
 .fd-btn-icon-soft.is-danger {
   --btn-soft-bg: var(--btn-soft-danger-bg);
+  --btn-soft-bg-hover: var(--btn-soft-danger-bg-hover);
+  --btn-soft-bg-active: var(--btn-soft-danger-bg-active);
   --btn-soft-border: var(--btn-soft-danger-border);
   --btn-soft-ink: var(--btn-soft-danger-ink);
 }
 .fd-btn-icon-soft:hover,
 .fd-btn-icon-soft.is-ok:hover,
 .fd-btn-icon-soft.is-danger:hover {
-  filter: brightness(1.08);
+  background: var(--btn-soft-bg-hover);
   color: var(--btn-soft-ink);
 }
+/* Pressed restates every selector hover uses, same reasoning as
+   .fd-btn-icon-solid:active above. */
 .fd-btn-icon-soft:active,
 .fd-btn-icon-soft.is-ok:active,
 .fd-btn-icon-soft.is-danger:active {
-  filter: brightness(0.92);
+  background: var(--btn-soft-bg-active);
+  color: var(--btn-soft-ink);
   box-shadow: none;
 }
+/* Restated after :active, same reasoning as .fd-btn-icon-solid:focus-visible above: a
+   pressed-while-focused button must keep the ring, not the pressed rule's `box-shadow:
+   none`. */
 .fd-btn-icon-soft:focus-visible {
   box-shadow: var(--focus-ring);
 }
@@ -4089,15 +4124,20 @@
    itself uses (--r-md here rather than Card's --r-lg — a compact list row reads
    better with the tighter radius; --e-1/--e-2 are the same elevation tokens). */
 .fd-erow {
-  /* display/align-items/gap live here, not on the component's inline style (where
-     they used to be, MP-114 follow-up) — an inline style always wins over a
+  /* display/align-items/gap/padding live here, not on the component's inline style
+     (where they used to be, MP-114 follow-ups) — an inline style always wins over a
      stylesheet rule, which would make it impossible for the narrow-container rule
-     below to ever switch this row from a flex row to a grid. */
+     below to ever switch this row from a flex row to a grid. gap/padding/border-width
+     read the shared --erow-* custom properties (declared once on .fd-tlist above)
+     rather than carrying their own literals, which is also what lets
+     .fd-tlist-footer's indent stay correct by construction instead of by two
+     numbers happening to agree. */
   display: flex;
   align-items: center;
-  gap: 10px;
+  gap: var(--erow-gap);
+  padding: 0 var(--erow-pad-x);
   background: var(--surface-2);
-  border: 1px solid var(--erow-border);
+  border: var(--erow-border-w) solid var(--erow-border);
   border-radius: var(--r-md);
   box-shadow: var(--e-1);
   transition:
@@ -4306,6 +4346,12 @@ button.fd-erow-metric:focus-visible {
   display: inline-flex;
   align-items: center;
 }
+/* Size lives here, not on the component's inline style (MP-114 third follow-up,
+   same reasoning as .fd-erow's own padding above): .fd-tlist-footer's indent reads
+   it back as --erow-grip-size. */
+.fd-erow-grip {
+  font-size: var(--erow-grip-size);
+}
 .fd-erow[draggable="true"]:active {
   cursor: grabbing;
 }
@@ -4335,12 +4381,68 @@ button.fd-erow-metric:focus-visible {
    screen's. */
 .fd-tlist {
   container-type: inline-size;
+  /* A row's own geometry, declared ONCE here rather than as literals wherever
+     something needs to line up with it (MP-114, third follow-up: the totals
+     footer's indent restated these as bare numbers in two places while the real
+     values lived as inline styles on EntityRow.tsx's row and its drag grip — a
+     change to either drifted the footer's indent silently, which is exactly what
+     the second follow-up's 24px misalignment was). `.fd-erow` and `.fd-erow-grip`
+     read these instead of carrying their own inline padding/font-size, and
+     `.fd-tlist-footer`'s two indents (below) are `calc()` of the same four
+     properties — a row and the totals line can only drift apart now if one of
+     THESE four values changes, and both readers change with it. Declared on
+     `.fd-tlist` (the one ancestor common to both a row and the footer, which are
+     otherwise unrelated siblings under `.fd-tlist-side`) rather than on `.fd-erow`
+     itself, so the footer — which is never a descendant of any `.fd-erow` — can
+     still read them by ordinary custom-property inheritance. */
+  --erow-border-w: 1px;
+  --erow-pad-x: 12px;
+  --erow-grip-size: 14px;
+  --erow-gap: 10px;
 }
 .fd-tlist-panes {
   display: flex;
   gap: 16px;
   align-items: flex-start;
 }
+/* TransferList's per-side slots. The footer is where a running totals line goes;
+   it sits on the panel, not on a card, and is separated by a rule rather than a
+   gap so it reads as a summary OF the list rather than another row IN it.
+   Declared here, BEFORE the narrow @container block below, deliberately: CSS
+   cascade order for two rules of equal specificity is source order regardless of
+   which one sits inside an at-rule, so a base rule declared AFTER a narrow
+   override for the same property would silently win at every width, override
+   included — this is what actually happened to this rule's own `padding-left`
+   for two follow-ups running (the override was textually correct and had a
+   passing stylesheet-contract test, but the base rule used to be declared further
+   down the file, after the @container block, and always won the tie). */
+.fd-tlist-header {
+  display: flex;
+  align-items: center;
+  gap: 8px;
+  min-width: 0;
+}
+.fd-tlist-footer {
+  display: flex;
+  align-items: center;
+  gap: 10px;
+  min-width: 0;
+  padding-top: 8px;
+  /* Indented to the x a row's own body starts at, so a totals strip in here lands
+     under the columns it totals rather than a card's width to the left of them: the
+     card's border, the row's own padding, the drag grip and its gap — every row in
+     a TransferList is a drag source, so it is the same on all of them. Written as
+     calc() of the shared --erow-* custom properties (.fd-tlist's own comment)
+     rather than as separate literals that merely happened to equal the same
+     numbers EntityRow.tsx's row/grip carried inline — a change to any one of those
+     four properties now moves this indent with it instead of silently drifting out
+     of alignment, which is exactly how this went wrong at the narrow breakpoint
+     (see that rule's own comment). */
+  padding-left: calc(var(--erow-border-w) + var(--erow-pad-x) + var(--erow-grip-size) + var(--erow-gap));
+  border-top: 1px solid var(--border);
+  font-size: var(--overline-size);
+  color: var(--text-2);
+}
 @container (max-width: 600px) {
   .fd-tlist-panes {
     flex-direction: column;
@@ -4392,7 +4494,10 @@ button.fd-erow-metric:focus-visible {
     grid-template-areas:
       "grip title accessory action"
       "strip strip strip strip";
-    gap: 4px 10px;
+    /* Row-gap is a new number (there was no vertical gap to preserve — the old
+       layout never had two grid rows), but the column-gap is the same --erow-gap
+       the wide flex row uses, not a second literal 10px that could drift from it. */
+    gap: 4px var(--erow-gap);
   }
   .fd-erow-body,
   .fd-erow-strip {
@@ -4436,6 +4541,21 @@ button.fd-erow-metric:focus-visible {
   }
   .fd-tlist-footer {
     flex-wrap: wrap;
+    /* The wide-width padding-left (see the base rule's own comment) indents the
+       totals strip to where a row's metric strip used to start: AFTER the card border,
+       the row's own padding, the drag grip and its gap. Down here the row's strip no
+       longer starts there — it's `.fd-erow`'s own full-width second grid row (see
+       `.fd-erow`'s own comment above), which starts at the row's own left padding
+       edge, before the grip rather than after it. audience-builder.spec.ts caught the
+       mismatch this left behind: a row's strip and the totals strip 24px apart at the
+       SAME breakpoint that made the grid switch active in the first place (any
+       TransferList pane under 600px, which an ordinary 1280px desktop window reaches
+       easily — see that rule's own comment). The totals strip needs the SAME new
+       origin: just the card's border and the row's own padding, with the grip/gap
+       terms dropped since they no longer apply to either strip — both terms of the
+       SAME --erow-* properties (.fd-tlist's own comment) the base rule below uses,
+       not separately-guessed numbers, so the two can't drift apart again. */
+    padding-left: calc(var(--erow-border-w) + var(--erow-pad-x));
   }
 }
 .fd-tlist-side {
@@ -4484,32 +4604,6 @@ button.fd-erow-metric:focus-visible {
   box-shadow: var(--e-2);
   color: var(--brand);
 }
-/* TransferList's per-side slots. The footer is where a running totals line goes;
-   it sits on the panel, not on a card, and is separated by a rule rather than a
-   gap so it reads as a summary OF the list rather than another row IN it. */
-.fd-tlist-header {
-  display: flex;
-  align-items: center;
-  gap: 8px;
-  min-width: 0;
-}
-.fd-tlist-footer {
-  display: flex;
-  align-items: center;
-  gap: 10px;
-  min-width: 0;
-  padding-top: 8px;
-  /* Indented to the x a row's own body starts at, so a totals strip in here lands
-     under the columns it totals rather than a card's width to the left of them.
-     The sum is the card's border and padding-left plus the drag grip and its gap
-     — every row in a TransferList is a drag source, so it is the same on all of
-     them. Spelled out rather than collapsed to 37px so it stays checkable against
-     .fd-erow if that padding ever moves. */
-  padding-left: calc(1px + 12px + 14px + 10px);
-  border-top: 1px solid var(--border);
-  font-size: var(--overline-size);
-  color: var(--text-2);
-}
 
 /* --- ScoreMeter — a small categorical 0-100 bar, optionally a trigger ------ */
 .fd-scoremeter {
@@ -6560,3 +6654,191 @@ button.fd-erow-metric:focus-visible {
   .fd-spinner{animation-duration:1.6s}
   .fd-arrived{animation:none}
 }
+
+/* FileViewer (MP-130): a preview pane plus an optional host-supplied side panel — the
+   companion notes/metadata surface the app composes in, generic here as `sidePanel`.
+   Two regions, one scroll region each (R-8): `.fd-fv-body` never scrolls, each pane owns
+   its own overflow. Side by side while there's room; below a narrow width of the
+   component's OWN box (a container query, not a media query — the same reasoning as
+   `.fd-tlist`'s above, since a FileViewer opened full-page and one opened in a Drawer see
+   completely different widths at the same viewport) the side panel becomes a tab next to
+   Preview and exactly one pane is visible at a time. */
+.fd-fv {
+  container-type: inline-size;
+  display: flex;
+  flex-direction: column;
+  height: 100%;
+  min-height: 0;
+  background: var(--surface);
+  color: var(--text);
+}
+.fd-fv-head {
+  display: flex;
+  align-items: center;
+  gap: 10px;
+  padding: 12px 16px;
+  border-bottom: 1px solid var(--border);
+  flex: none;
+}
+.fd-fv-head-icon {
+  display: grid;
+  place-items: center;
+  width: 32px;
+  height: 32px;
+  border-radius: var(--r-md);
+  background: var(--surface-2);
+  color: var(--text-2);
+  font-size: 17px;
+  flex: none;
+}
+.fd-fv-head-titles {
+  display: flex;
+  flex-direction: column;
+  min-width: 0;
+  flex: 1 1 auto;
+}
+.fd-fv-head-title {
+  font-weight: 600;
+  overflow: hidden;
+  text-overflow: ellipsis;
+  white-space: nowrap;
+}
+.fd-fv-head-meta {
+  font-size: var(--body-sm-size);
+  color: var(--text-2);
+}
+.fd-fv-head-actions {
+  display: flex;
+  align-items: center;
+  gap: 8px;
+  flex: none;
+}
+.fd-fv-download-error {
+  margin: 10px 16px 0;
+  padding: 8px 12px;
+  border-radius: var(--r-md);
+  background: var(--danger-fill);
+  border: 1px solid var(--danger-border);
+  color: var(--danger-text);
+  font-size: var(--body-sm-size);
+}
+/* Only ever shown below the narrow container-query breakpoint (see the block at the
+   bottom of this section) — at full width both panes are already visible, so a tab
+   bar choosing between them would be a control with nothing to do. */
+.fd-fv-tabs {
+  display: none;
+  flex: none;
+  padding: 0 16px;
+  border-bottom: 1px solid var(--border);
+}
+.fd-fv-body {
+  display: flex;
+  flex: 1 1 auto;
+  min-height: 0;
+  overflow: hidden;
+}
+.fd-fv-preview {
+  flex: 1 1 auto;
+  min-width: 0;
+  min-height: 0;
+  overflow: auto;
+  padding: 16px;
+}
+.fd-fv-side {
+  flex: 0 0 320px;
+  min-width: 0;
+  min-height: 0;
+  overflow: auto;
+  padding: 16px;
+  border-left: 1px solid var(--border);
+  background: var(--surface-2);
+}
+.fd-fv-image {
+  display: block;
+  max-width: 100%;
+  height: auto;
+  margin: 0 auto;
+  border-radius: var(--r-md);
+}
+.fd-fv-pdf {
+  display: block;
+  width: 100%;
+  height: 100%;
+  min-height: 480px;
+  border: 0;
+  border-radius: var(--r-md);
+  background: var(--surface-2);
+}
+.fd-fv-fallback {
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+  gap: 8px;
+  height: 100%;
+  min-height: 220px;
+  text-align: center;
+  color: var(--text-2);
+}
+.fd-fv-fallback-icon {
+  display: grid;
+  place-items: center;
+  width: 56px;
+  height: 56px;
+  border-radius: var(--r-full);
+  background: var(--surface-2);
+  font-size: 26px;
+}
+.fd-fv-fallback-title {
+  font-weight: 600;
+  color: var(--text);
+}
+.fd-fv-fallback-meta {
+  font-size: var(--body-sm-size);
+}
+.fd-fv-csv-table {
+  width: 100%;
+  border-collapse: collapse;
+  font-size: var(--body-sm-size);
+}
+.fd-fv-csv-table th,
+.fd-fv-csv-table td {
+  padding: 6px 10px;
+  border-bottom: 1px solid var(--border);
+  text-align: left;
+  white-space: nowrap;
+}
+.fd-fv-csv-table th {
+  color: var(--text-2);
+  font-weight: 600;
+  background: var(--surface-2);
+  position: sticky;
+  top: 0;
+}
+.fd-fv-csv-note {
+  margin-top: 10px;
+}
+/* Below 640px of `.fd-fv`'s OWN width (not the viewport's — see the block comment
+   above) there is no room for a preview beside a side panel: the tab bar takes over
+   choosing which one is visible, and the two panes stack full-width instead of sitting
+   side by side. Each pane keeps its own `overflow: auto` from the base rules above, so
+   R-8 (one scroll region per pane) holds at this width too — there is just one pane on
+   screen at a time instead of two. */
+@container (max-width: 640px) {
+  .fd-fv-tabs {
+    display: flex;
+  }
+  .fd-fv-body {
+    flex-direction: column;
+  }
+  .fd-fv-side {
+    border-left: 0;
+    border-top: 1px solid var(--border);
+  }
+  .fd-fv.is-tab-preview .fd-fv-side {
+    display: none;
+  }
+  .fd-fv.is-tab-side .fd-fv-preview {
+    display: none;
+  }
+}

package/styles/tokens.css

@@ -110,9 +110,18 @@
      usual badge sense (e.g. --ok-fill/--danger-fill) is only ~1.05:1 from --erow-danger-fill
      and fails outright; this is the lightest fill that still clears the bar next to a red
      row. The border reuses the darker --btn-solid-*-bg-active token, 1.8-2:1 off the new
-     fill and 7:1+ off both grounds, so it reads even where hue alone would not. */
-  --btn-soft-ok-bg:#557F6A;--btn-soft-ok-border:#145A38;--btn-soft-ok-ink:#FFFFFF;
-  --btn-soft-danger-bg:#C84E43;--btn-soft-danger-border:#862720;--btn-soft-danger-ink:#FFFFFF;
+     fill and 7:1+ off both grounds, so it reads even where hue alone would not.
+
+     MP-114 hover/active: darkened the same way --btn-solid-* darkens for its own
+     hover/active (light theme gets darker as you press deeper). -bg-hover is 8% darker
+     than -bg, -bg-active 16% darker; white ink stays 5.19:1+ / 5.97:1+ and the fill stays
+     4.45:1+ against --erow-danger-fill (the tighter of the two grounds) at every step.
+     These are real fills, not a `filter: brightness()` restatement — a filter changes
+     what the eye sees without changing `background-color`, so a contrast check (and a
+     person's actual reading of the button) that goes by the declared colour never sees
+     it move. */
+  --btn-soft-ok-bg:#557F6A;--btn-soft-ok-bg-hover:#4E7562;--btn-soft-ok-bg-active:#476B59;--btn-soft-ok-border:#145A38;--btn-soft-ok-ink:#FFFFFF;
+  --btn-soft-danger-bg:#C84E43;--btn-soft-danger-bg-hover:#B8483E;--btn-soft-danger-bg-active:#A84238;--btn-soft-danger-border:#862720;--btn-soft-danger-ink:#FFFFFF;
 
   --ok-fill:#DFF3E8;--ok-border:#A8DDC2;--ok-text:#0E5233;--ok-solid:#34A26B;--ok-emph:#57C68C;
   --warn-fill:#FDF1DA;--warn-border:#F0D49A;--warn-text:#6B4A05;--warn-solid:#C8890B;
@@ -279,9 +288,16 @@
      --surface-2 (#1B1F27) and --erow-danger-fill (#331813): white ink is 5.4:1 or better,
      the fill is 3.0:1 or better against either ground, and the border (the theme's own
      --btn-solid-*-bg, already proven legible here) is 1.9:1+ off the fill and 5.7:1+ off
-     both grounds. */
-  --btn-soft-ok-bg:#007A3D;--btn-soft-ok-border:#3FB37A;--btn-soft-ok-ink:#FFFFFF;
-  --btn-soft-danger-bg:#D41200;--btn-soft-danger-border:#E8776D;--btn-soft-danger-ink:#FFFFFF;
+     both grounds.
+
+     MP-114 hover/active: rest is already only ~3.0:1 off --surface-2, the floor, so
+     darkening further (the light-theme direction) would drop the fill below 3:1 — both
+     states have to LIGHTEN here instead, same direction as --btn-solid-* on this ground.
+     -bg-hover is +6% toward white, -bg-active +9%/+12% (ok/danger): white ink stays
+     4.61:1+ and the fill stays 3.30:1+ against both --surface-2 and --erow-danger-fill at
+     every step. Real fills, not `filter: brightness()` — see the :root comment above. */
+  --btn-soft-ok-bg:#007A3D;--btn-soft-ok-bg-hover:#0F8249;--btn-soft-ok-bg-active:#17864E;--btn-soft-ok-border:#3FB37A;--btn-soft-ok-ink:#FFFFFF;
+  --btn-soft-danger-bg:#D41200;--btn-soft-danger-bg-hover:#D7200F;--btn-soft-danger-bg-active:#D92E1F;--btn-soft-danger-border:#E8776D;--btn-soft-danger-ink:#FFFFFF;
 
   /* chat kit — see the :root block above */
   --chat-code-bg:#12151B;