@junoput01/junoui 0.6.0 → 0.8.0

package/dist/css/juno.css

@@ -21,6 +21,16 @@
   --juno-shadow-1: 0 1px 2px rgb(0 0 0 / 0.30);
   --juno-shadow-2: 0 4px 14px rgb(0 0 0 / 0.35);
   --juno-shadow-3: 0 12px 32px rgb(0 0 0 / 0.50);
+  --juno-ink-canvas-ink: #FFFFFF;
+  --juno-ink-canvas-halo: #000000;
+  --juno-ink-canvas-halo-width: 2px;
+  --juno-ink-canvas-halo-width-lg: 3px;
+  --juno-ink-canvas-scrim: 0.28;
+  --juno-ink-vivid-nominal: oklch(76% 0.28 148);
+  --juno-ink-vivid-active: oklch(76% 0.24 205);
+  --juno-ink-vivid-target: oklch(70% 0.30 328);
+  --juno-ink-vivid-caution: oklch(82% 0.20 82);
+  --juno-ink-vivid-warning: oklch(68% 0.28 25);
   --juno-motion-duration-instant: 80ms;
   --juno-motion-duration-quick: 140ms;
   --juno-motion-duration-base: 200ms;
@@ -398,9 +408,30 @@
     var(--juno-size-tap-comfortable) + 4 * var(--juno-space-4) + 2 * var(--juno-border-width-1)
   );
   --juno-dock-clearance-scale: 1;
+
+  /* The bar's own offset from the bottom edge — declared ONCE and consumed by
+     both the bar's margin (dock.css) and the clearance below, so the two cannot
+     disagree about where the bar sits.
+
+     That is the whole reason this is a token rather than a literal in each
+     place. junoui's default is additive, per docs/ios-conformance.md: a
+     FLOATING element sits off the edge, so its gap and the inset stack. A
+     consumer whose design wants the bar flush above the home indicator instead
+     writes `max(8px, env(safe-area-inset-bottom, 0px))` here and BOTH the
+     margin and the reservation follow it. Before this token the form was baked
+     into each site separately, so a consumer that changed one silently
+     disagreed with the other — measured at 16px of dead band at inset 0 and
+     24px at inset 34 (20260815-055), and no single --juno-dock-h could
+     reconcile them because one side added the inset and the other maxed it. */
+  --juno-dock-edge-offset: calc(var(--juno-space-16) + env(safe-area-inset-bottom, 0px));
+
+  /* Gap between the bar's top edge and the last row of content. Zero is a
+     legitimate setting: a translucent bar that content is MEANT to scroll under
+     wants overlap, not breathing room. */
+  --juno-dock-clearance-breathing: var(--juno-space-8);
   --juno-dock-clearance: calc(
-    var(--juno-dock-h) * var(--juno-dock-clearance-scale) + var(--juno-space-16) +
-      var(--juno-space-8) + env(safe-area-inset-bottom, 0px)
+    var(--juno-dock-h) * var(--juno-dock-clearance-scale) + var(--juno-dock-edge-offset) +
+      var(--juno-dock-clearance-breathing)
   );
 
   /* The pillbar is the same shape one size down: no bubble, so its height is
@@ -409,8 +440,8 @@
     var(--juno-size-tap-comfortable) + 2 * var(--juno-space-4) + 2 * var(--juno-border-width-1)
   );
   --juno-pillbar-clearance: calc(
-    var(--juno-pillbar-h) * var(--juno-dock-clearance-scale) + var(--juno-space-16) +
-      var(--juno-space-8) + env(safe-area-inset-bottom, 0px)
+    var(--juno-pillbar-h) * var(--juno-dock-clearance-scale) + var(--juno-dock-edge-offset) +
+      var(--juno-dock-clearance-breathing)
   );
 
   /* JS-readable motion contract. CSS-only `prefers-reduced-motion` never reaches
@@ -519,47 +550,18 @@ code, kbd, samp, pre { font-family: var(--juno-font-family-mono); }
      `.juno-input` font-size later in the bundle. It did, silently, until
      20260815-006's coarse-pointer project measured it. */
 
-  /* Kill the UA tap-highlight square on the interactive surfaces so it never
-     flashes past a rounded control on tap. Consumers were adding this by hand
-     per component; make it a first-class touch default. See 20260802-020. */
-  :where(
-    .juno-btn,
-    .juno-dock__item,
-    .juno-pillbar__item,
-    .juno-tabs__tab,
-    .juno-list__item,
-    .juno-menu__item
-  ) {
-    -webkit-tap-highlight-color: transparent;
-  }
+  /* The tap-highlight default that used to live here is GENERATED now, from
+     src/css/touch-surfaces.mjs, together with the touch-action default that
+     shares its member list. Two hand-maintained lists had drifted from the
+     classes and from each other; see that file. */
 }
 
-/* Tappable primitives opt out of double-tap-to-zoom. A browser that still
-   recognises that gesture has to WAIT after the first tap to see whether a
-   second one is coming, which reads as a late, mushy tap on exactly the
-   surfaces a phone UI is built from. `manipulation` keeps panning and
-   pinch-zoom (so the page stays zoomable — never `none` here, that would be an
-   a11y regression) and drops only the double-tap.
-   NOT inside the pointer:coarse block above: a hybrid device (touch laptop,
-   iPad with a trackpad) reports a fine primary pointer while still taking
-   touch input, and the property is inert on a mouse anyway.
-   Community convention — no primary Apple/WebKit source names it; see
-   docs/ios-conformance.md. Named components only, so a consumer's own elements
-   are untouched. See 20260803-038. */
-:where(
-  .juno-btn,
-  .juno-dock__item,
-  .juno-pillbar__item,
-  .juno-pillbar__overflow,
-  .juno-tabs__tab,
-  .juno-list__item,
-  .juno-menu__item,
-  .juno-seg__option,
-  .juno-chip,
-  .juno-toggle-btn
-) {
-  touch-action: manipulation;
-}
+/* The touch defaults that used to be two hand-maintained `:where()` lists here
+   are GENERATED from src/css/touch-surfaces.mjs and emitted straight after this
+   file. Both lists had drifted — from the classes (`.juno-seg__option`,
+   `.juno-list__item`: neither exists, so `:where()` matched nothing and the
+   rule parsed anyway) and from each other. One declared set now feeds both.
+   See 20260826-024 and docs/conformance-kit.md. */
 
 /* Gesture-owned surfaces — for an element whose pointer events are fully
    driven by app JS (drag-pan, pinch-zoom, swipe classification: a state
@@ -699,6 +701,62 @@ code, kbd, samp, pre { font-family: var(--juno-font-family-mono); }
   .juno-tooltip__bubble[popover] { display: none; }
 }
 
+/* GENERATED from src/css/touch-surfaces.mjs — do not edit here.
+ *
+ * Tappable primitives opt out of double-tap-to-zoom. A browser that still
+ * recognises that gesture has to WAIT after the first tap to see whether a
+ * second one is coming, which reads as a late, mushy tap on exactly the
+ * surfaces a phone UI is built from. `manipulation` keeps panning and
+ * pinch-zoom (so the page stays zoomable — never `none` here, that would be an
+ * a11y regression) and drops only the double-tap.
+ * Community convention — no primary Apple/WebKit source names it; see
+ * docs/ios-conformance.md. Named components only, so a consumer's own elements
+ * are untouched. See 20260803-038. */
+:where(
+  .juno-btn,
+  .juno-chip,
+  .juno-dock__item,
+  .juno-list__row,
+  .juno-menu__item,
+  .juno-pillbar__item,
+  .juno-pillbar__overflow,
+  .juno-seg__opt,
+  .juno-tabs__tab,
+  .juno-toggle-btn,
+  .juno-tree__row,
+  .juno-gizmo__mark,
+  .juno-gizmo__center,
+  .juno-swatch--button,
+  .juno-palette__option
+) {
+  touch-action: manipulation;
+}
+
+/* And on touch, kill the UA tap-highlight square so it never flashes past a
+ * rounded control. Consumers were adding this by hand per component; it is a
+ * first-class touch default. See 20260802-020. */
+@media (pointer: coarse) {
+:where(
+    .juno-btn,
+    .juno-chip,
+    .juno-dock__item,
+    .juno-list__row,
+    .juno-menu__item,
+    .juno-pillbar__item,
+    .juno-pillbar__overflow,
+    .juno-seg__opt,
+    .juno-tabs__tab,
+    .juno-toggle-btn,
+    .juno-tree__row,
+    .juno-gizmo__mark,
+    .juno-gizmo__center,
+    .juno-swatch--button,
+    .juno-palette__option
+  ) {
+    -webkit-tap-highlight-color: transparent;
+  }
+}
+
 /* ════════════════════════════════════════════════════════════════════
  *  junoui — layout layer (intrinsic & responsive)
  *
@@ -1401,8 +1459,10 @@ details.juno-accordion__item:only-child {
 .juno-btn--ghost:hover { background: var(--juno-s2); filter: none; }
 
 /* Small — for dense desktop toolbars (40–46px bars) where the default
-   control would not fit. Deliberately under the WCAG tap-min target:
-   keep the default size for touch surfaces. Combines with --ghost + roles. */
+   control would not fit. Combines with --ghost + roles.
+   On a FINE pointer this is 24px: the WCAG 2.2 AA floor (2.5.8) exactly, and
+   no more. On a coarse pointer it promotes to the comfortable target — see
+   below. */
 .juno-btn--sm {
   min-height: var(--juno-space-24);
   font-size: var(--juno-font-size-11);
@@ -1411,6 +1471,44 @@ details.juno-accordion__item:only-child {
   border-radius: var(--juno-radius-3);
 }
 
+/* --sm names a DENSITY, and consumers reach for it as a SEMANTIC. Audited
+   across one app: 40 call sites, nearly all of them `--sm --ghost` meaning
+   "secondary", shipping a 24px target on a phone — and junoui's own showcase
+   does it twice in a navbar action slot. A size modifier should not quietly
+   become a tap-target decision, so on touch it holds the same floor every
+   other control does. Type and padding still shrink: --sm stays a density
+   modifier, it just stops being a touch-target one (20260826-026).
+
+   THE RULE LIVES HERE, not in base.css's (pointer: coarse) block: a media
+   query adds no specificity, so a `.juno-btn--sm` there would lose to this
+   file's own `.juno-btn--sm` later in the bundle. That is not a guess — it is
+   what silently happened to the .juno-input font floor until 20260815-006
+   measured it.
+
+   --dense is the opt-out, and it is deliberately only meaningful ON --sm:
+   a dense touch toolbar is a real thing (a media scrubber, an editor rail),
+   but it is a decision someone has to make by name rather than inherit from a
+   size.
+
+   The two rules below are REDUNDANT ON PURPOSE, and mutation testing is how
+   that became a decision rather than an accident: deleting either one leaves
+   --dense at 24px. The `:not()` excludes a dense button from the promotion, so
+   the pairing below it is dead weight — until the `:not()` names the wrong
+   class, at which point the pairing (also (0,2,0), and later in the file) is
+   the only thing holding the opt-out. Each covers the other's failure, so a
+   single edit to either cannot silently promote a --dense button. Both
+   selectors are (0,2,0) and mutually exclusive in the correct state, so they
+   never race. */
+@media (pointer: coarse) {
+  .juno-btn--sm:not(.juno-btn--dense) {
+    min-height: var(--juno-size-tap-min);
+  }
+
+  .juno-btn--sm.juno-btn--dense {
+    min-height: var(--juno-space-24);
+  }
+}
+
 .juno-btn:disabled {
   background: var(--juno-muted);
   color: var(--juno-label);
@@ -1419,6 +1517,104 @@ details.juno-accordion__item:only-child {
   filter: none;
 }
 
+/* ════════════════════════════════════════════════════════════════════
+ *  Component — Canvas ink (marks drawn over arbitrary imagery)
+ *  For text and vector ink sitting on a photo, a map, a video frame or a
+ *  camera feed: anywhere the background is CONTENT rather than one of
+ *  junoui's surfaces.
+ *
+ *  WHY IT IS NOT JUST A COLOUR. junoui's whole contrast story assumes a
+ *  controlled surface, s0 through s3 — every role colour's ratio is
+ *  computed against a known background. Over imagery there is no known
+ *  background. In one orthophoto a black shadow and a snowfield are
+ *  adjacent pixels, so no single ink colour is legible and no contrast
+ *  ratio can be asserted about one. The answer is a PAIR that spans the
+ *  luminance range: over a light backing the halo carries the contrast,
+ *  over a dark one the ink does. Neither half works alone, which is why
+ *  they are applied together by one class.
+ *
+ *  NOT THEMED, on purpose. A satellite image does not get lighter because
+ *  the user chose light mode. Theming this pair would make it track the
+ *  app's surface, which is precisely the background it is NOT over.
+ *  Usage:
+ *    <figcaption class="juno-canvas-ink">Sector 7 · 1.2 km</figcaption>
+ *    <svg class="juno-canvas-ink"><path class="juno-canvas-ink__stroke" …/></svg>
+ *    <div class="juno-canvas-scrim">…chrome floating over the content…</div>
+ * ════════════════════════════════════════════════════════════════════ */
+
+/* Text. Four offset shadows rather than one blur: a blurred shadow fades at
+   the glyph's corners, which is exactly where a thin stroke needs the most
+   help, and it costs the same. `paint-order` is for SVG text, where a real
+   stroke is available and better. */
+.juno-canvas-ink {
+  color: var(--juno-ink-canvas-ink);
+  paint-order: stroke fill;
+  stroke: var(--juno-ink-canvas-halo);
+  stroke-width: var(--juno-ink-canvas-halo-width);
+  text-shadow:
+    var(--juno-ink-canvas-halo-width) 0 0 var(--juno-ink-canvas-halo),
+    calc(-1 * var(--juno-ink-canvas-halo-width)) 0 0 var(--juno-ink-canvas-halo),
+    0 var(--juno-ink-canvas-halo-width) 0 var(--juno-ink-canvas-halo),
+    0 calc(-1 * var(--juno-ink-canvas-halo-width)) 0 var(--juno-ink-canvas-halo);
+}
+
+/* Display sizes: a 2px halo reads as a hairline against a heavier stroke. */
+.juno-canvas-ink--lg {
+  stroke-width: var(--juno-ink-canvas-halo-width-lg);
+  text-shadow:
+    var(--juno-ink-canvas-halo-width-lg) 0 0 var(--juno-ink-canvas-halo),
+    calc(-1 * var(--juno-ink-canvas-halo-width-lg)) 0 0 var(--juno-ink-canvas-halo),
+    0 var(--juno-ink-canvas-halo-width-lg) 0 var(--juno-ink-canvas-halo),
+    0 calc(-1 * var(--juno-ink-canvas-halo-width-lg)) 0 var(--juno-ink-canvas-halo);
+}
+
+/* Vector ink — measurement lines, selection outlines. Two passes: the halo
+   is the same path drawn wider underneath. In SVG give the halo element
+   this class and the mark element __stroke; in canvas, stroke twice. */
+.juno-canvas-ink__halo {
+  fill: none;
+  stroke: var(--juno-ink-canvas-halo);
+  stroke-width: calc(var(--juno-ink-canvas-halo-width) * 2);
+  stroke-linecap: round;
+  stroke-linejoin: round;
+}
+
+.juno-canvas-ink__stroke {
+  fill: none;
+  stroke: var(--juno-ink-canvas-ink);
+  stroke-linecap: round;
+  stroke-linejoin: round;
+}
+
+/* Status over canvas. The themed role hues are chosen against s0–s3 and wash
+   out over a saturated backdrop, so these are the same hues at raised chroma.
+   Louder than the panel roles by design — they will look wrong on a panel. */
+.juno-canvas-ink--nominal { color: var(--juno-ink-vivid-nominal); }
+.juno-canvas-ink--active { color: var(--juno-ink-vivid-active); }
+.juno-canvas-ink--target { color: var(--juno-ink-vivid-target); }
+.juno-canvas-ink--caution { color: var(--juno-ink-vivid-caution); }
+.juno-canvas-ink--warning { color: var(--juno-ink-vivid-warning); }
+
+/* Chrome floating over live content. Deliberately NOT --juno-opacity-scrim
+   (0.62): that value suppresses a modal's background, and here the background
+   is the thing the chrome is annotating — greying it out defeats the purpose. */
+.juno-canvas-scrim {
+  background: color-mix(in srgb, var(--juno-s0) calc(var(--juno-ink-canvas-scrim) * 100%), transparent);
+  -webkit-backdrop-filter: blur(8px);
+  backdrop-filter: blur(8px);
+}
+
+/* A translucent bar over moving content is the case where reduced
+   transparency matters most — the motion behind the text is the problem, not
+   the blur. Fall back to the opaque surface. */
+@media (prefers-reduced-transparency: reduce) {
+  .juno-canvas-scrim {
+    background: var(--juno-s0);
+    -webkit-backdrop-filter: none;
+    backdrop-filter: none;
+  }
+}
+
 /* ════════════════════════════════════════════════════════════════════
  *  Component — Card / panel
  *  Usage:
@@ -1750,6 +1946,55 @@ button.juno-chip {
      media query. */
   --juno-dock-scale: 1;
 
+  /* ── Horizontal budget contract ──────────────────────────────────────
+     Published so a consumer's capacity planner ("how many items fit, and
+     do they still hold a tap target?") reads junoui's real geometry
+     instead of re-deriving it from the numbers in this file. Two
+     consumers had derived it by hand, twice, in prose — and both had
+     drifted: they subtracted 12px of inline padding where the pill
+     actually spends 8, so their per-item width came out ~0.8px low at
+     every viewport (20260826-027).
+
+     --juno-dock-items      the item budget. junoui does not enforce it —
+                            __item is `flex: 1 1 0`, so the layout divides
+                            by however many items are present — it is the
+                            number the DERIVATIONS below are about, and the
+                            consumer sets it to what it renders.
+     --juno-dock-item-inline  the width one item gets. A prediction of what
+                            the flex layout produces, not an input to it;
+                            asserted against the measured box in the test
+                            suite so it cannot drift from the layout.
+     --juno-dock-fit-inline  the narrowest viewport at which every item
+                            still holds --juno-size-tap-comfortable. Use it
+                            in a media query and DROP an item; that is the
+                            answer junoui can give exactly.
+
+     A SCALE floor (44px / the item's width) is deliberately not published:
+     it is a ratio of two lengths, and CSS cannot divide by a length. A
+     consumer that must scale rather than drop compares
+     --juno-dock-item-inline against --juno-size-tap-comfortable itself.
+
+     The three inline terms are declared ONCE here and consumed by both the
+     variants' own margin/padding/border and the sums below, so the budget
+     cannot disagree with the bar it describes — the same reason
+     --juno-dock-edge-offset exists (20260815-055). The base bar is
+     full-bleed with a top-edge border only, so all three are zero; --pill
+     and --float set them. */
+  --juno-dock-items: 5;
+  --juno-dock-margin-inline: 0px;
+  --juno-dock-pad-inline: 0px;
+  --juno-dock-border-inline: 0px;
+  --juno-dock-chrome-inline: calc(
+    2 * (var(--juno-dock-margin-inline) + var(--juno-dock-pad-inline) + var(--juno-dock-border-inline))
+  );
+  --juno-dock-avail: 100vw;
+  --juno-dock-item-inline: calc(
+    (var(--juno-dock-avail) - var(--juno-dock-chrome-inline)) / var(--juno-dock-items)
+  );
+  --juno-dock-fit-inline: calc(
+    var(--juno-dock-items) * var(--juno-size-tap-comfortable) + var(--juno-dock-chrome-inline)
+  );
+
   position: sticky;
   inset-block-end: 0;
   z-index: var(--juno-z-raised);
@@ -1844,16 +2089,21 @@ button.juno-chip {
 .juno-dock--pill {
   --juno-role: var(--juno-active);
 
+  /* the three inline terms the budget contract sums — see .juno-dock */
+  --juno-dock-margin-inline: var(--juno-space-12);
+  --juno-dock-pad-inline: var(--juno-space-4);
+  --juno-dock-border-inline: var(--juno-border-width-1);
+
   position: fixed;
   inset-inline: 0;
   inset-block-end: 0;
   z-index: var(--juno-z-raised);
-  margin: 0 var(--juno-space-12) calc(var(--juno-space-16) + env(safe-area-inset-bottom, 0px));
-  padding: var(--juno-space-4);
+  margin: 0 var(--juno-dock-margin-inline) var(--juno-dock-edge-offset);
+  padding: var(--juno-dock-pad-inline);
   background: color-mix(in srgb, var(--juno-s1) 88%, transparent);
   -webkit-backdrop-filter: blur(12px);
   backdrop-filter: blur(12px);
-  border: var(--juno-border-width-1) solid var(--juno-border);
+  border: var(--juno-dock-border-inline) solid var(--juno-border);
   border-radius: 999px;
   box-shadow: var(--juno-shadow-2);
 }
@@ -1947,17 +2197,22 @@ button.juno-chip {
    Out of flow (fixed) so the page scrolls UNDER it — reserve room on the
    scroller with padding-block-end: var(--juno-dock-clearance). */
 .juno-dock--float {
+  /* the three inline terms the budget contract sums — see .juno-dock */
+  --juno-dock-margin-inline: var(--juno-space-12);
+  --juno-dock-pad-inline: var(--juno-space-4);
+  --juno-dock-border-inline: var(--juno-border-width-1);
+
   position: fixed;
   inset-inline: 0;
   inset-block-end: 0;
   z-index: var(--juno-z-raised);
-  margin: 0 var(--juno-space-12) calc(var(--juno-space-16) + env(safe-area-inset-bottom, 0px));
-  padding: var(--juno-space-4);
+  margin: 0 var(--juno-dock-margin-inline) var(--juno-dock-edge-offset);
+  padding: var(--juno-dock-pad-inline);
   overflow: hidden;
   background: color-mix(in srgb, var(--juno-s1) 88%, transparent);
   -webkit-backdrop-filter: blur(12px);
   backdrop-filter: blur(12px);
-  border: var(--juno-border-width-1) solid var(--juno-border);
+  border: var(--juno-dock-border-inline) solid var(--juno-border);
   border-radius: 999px;
   box-shadow: var(--juno-shadow-2);
 }
@@ -2335,17 +2590,44 @@ button.juno-chip {
  *  gap, the folded slot still occupies one gap — name it in
  *  --juno-fold-gap and the fold swallows it with a negative margin.
  *
+ *  COMPOSITION. The canonical use puts .juno-fold on an element that is
+ *  already a component — a .juno-pillbar__item, a .juno-btn, a .juno-chip
+ *  — because that is where the capsule chrome (tap floor, padding, hover,
+ *  focus ring, aria-pressed) lives. Two things follow, and both are
+ *  load-bearing rather than defensive:
+ *
+ *  1. The fold's own declarations are stated at ATTRIBUTE specificity
+ *     (0,2,0), on both branches of data-juno-in, i.e. always. A component
+ *     class is (0,1,0), and `transition` is a SHORTHAND: a later rule does
+ *     not add to the list, it replaces it. Measured in Chromium against the
+ *     built bundle, before this was raised: on a
+ *     .juno-fold.juno-pillbar__item, transition-property resolved to
+ *     `color, background-color` — pillbar.css sorts after this file, so the
+ *     fold had no transition at all and jumped shut instead of folding.
+ *     inline-size and overflow would lose the same way to a component that
+ *     sets either.
+ *
+ *  2. Owning `transition` means owning ALL of it, so the capsule chrome
+ *     properties are in the fold's list too, at the quick duration the
+ *     components themselves use. Dropping them would trade a broken fold
+ *     for a broken hover.
+ *
+ *  Which floors the fold RELEASES when folded — see the folded rule below:
+ *  min-inline-size, padding-inline, border-inline-width. Those are exactly
+ *  the three inputs that can hold a border-box inline size above zero.
+ *
  *  Canonical use: a transient action in a toolbar/pill row (a
  *  scroll-to-top arrow, a contextual button) whose arrival should slide
  *  the row open rather than jump it.
  *  Usage:
  *    <div style="display:flex; gap:4px">                  (any row)
- *      <button class="juno-fold" data-juno-in aria-label="Scroll to top">…</button>
+ *      <button class="juno-fold juno-pillbar__item" data-juno-in aria-label="Scroll to top">…</button>
  *      …other members…
  *    </div>
  *  prefers-reduced-motion needs nothing component-local — the base
  *  layer zeroes every transition duration. */
-.juno-fold {
+.juno-fold[data-juno-in],
+.juno-fold:not([data-juno-in]) {
   --juno-fold-size: var(--juno-size-tap-comfortable);
   --juno-fold-gap: 0px;
 
@@ -2354,13 +2636,32 @@ button.juno-chip {
   overflow: hidden;
   transition:
     inline-size var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
+    min-inline-size var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
+    padding var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
+    border-width var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
     margin var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
     opacity var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
-    visibility var(--juno-motion-duration-base) var(--juno-motion-ease-standard);
+    visibility var(--juno-motion-duration-base) var(--juno-motion-ease-standard),
+    color var(--juno-motion-duration-quick) var(--juno-motion-ease-standard),
+    background-color var(--juno-motion-duration-quick) var(--juno-motion-ease-standard);
 }
 
+/* Folded away. A min-* floor clamps the USED value whichever rule won the
+   cascade, and a border-box inline size can never resolve below its own
+   padding plus border — so a composed capsule holds the slot open however
+   hard the fold pushes. Measured against the built bundle, composed with
+   .juno-pillbar__item at a 390px viewport: 44px with both floors in place
+   (the tap target), 20px with min-inline-size released (the padding alone),
+   0px with all of them released.
+   min-inline-size is in the transition list above for the OPENING half:
+   released to 0 it would otherwise snap back to the capsule's tap floor the
+   instant data-juno-in returns, and the used width — max(inline-size,
+   min-inline-size) — would jump to full width with nothing to animate. */
 .juno-fold:not([data-juno-in]) {
   inline-size: 0;
+  min-inline-size: 0;
+  padding-inline: 0;
+  border-inline-width: 0;
   margin-inline-end: calc(-1 * var(--juno-fold-gap));
   opacity: 0;
   visibility: hidden;
@@ -2445,6 +2746,245 @@ button.juno-chip {
 }
 .juno-gauge--lg .juno-gauge__value { font-size: var(--juno-font-size-20); }
 
+/* ════════════════════════════════════════════════════════════════════
+ *  Component — Viewport orientation gizmo (compass ring + pitch arc)
+ *  The orientation widget any 3D or map viewport ships: a ring showing a
+ *  heading with clickable snap targets, a secondary arc for a second
+ *  angle (pitch / tilt / elevation) inside a clamped range, and a centre
+ *  target that resets the view.
+ *
+ *  A RING, NOT A CUBE, and that is a design decision rather than a style
+ *  one. An Autodesk-style ViewCube is the wrong shape for anything with a
+ *  privileged up-vector — a map, a terrain, a site plan — because there is
+ *  no meaningful front, right or bottom face to click. A ring degrades to
+ *  the up-vector case and generalises to the free-orbit one; a cube does
+ *  not go the other way.
+ *
+ *  THE APP OWNS THE CAMERA. It writes two angles in as custom properties
+ *  and junoui rotates the marks; nothing here stores or changes state.
+ *    element.style.setProperty('--juno-gizmo-heading', `${yaw}deg`);
+ *    element.style.setProperty('--juno-gizmo-pitch', `${pitch}deg`);
+ *
+ *  Usage — see docs/components/gizmo.md for the full a11y contract, which
+ *  is the half apps get wrong and the reason this is upstream:
+ *    <div class="juno-gizmo" role="group" aria-label="View orientation">
+ *      <p class="juno-gizmo__readout" aria-live="polite">Facing north, 0 degrees.</p>
+ *      <div class="juno-gizmo__ring">
+ *        <span class="juno-gizmo__needle" aria-hidden="true"></span>
+ *        <button class="juno-gizmo__mark" style="--juno-gizmo-at:0deg"
+ *                aria-label="Face north" aria-current="true">N</button>
+ *        …seven more…
+ *        <button class="juno-gizmo__center" aria-label="Reset view">⌖</button>
+ *      </div>
+ *      <div class="juno-gizmo__arc">
+ *        <span class="juno-gizmo__arc-hand" aria-hidden="true"></span>
+ *      </div>
+ *    </div>
+ * ════════════════════════════════════════════════════════════════════ */
+
+.juno-gizmo {
+  --juno-role: var(--juno-active);
+
+  /* The angles the app writes. Defaults are a level view facing north, so a
+     gizmo that is mounted before the camera reports is not a blank circle. */
+  --juno-gizmo-heading: 0deg;
+  --juno-gizmo-pitch: 0deg;
+
+  /* MINIMUM DIAMETER, DERIVED — and derived from the CHORD, which is the
+     correction that matters. N marks sit evenly around the rim, so the
+     straight-line distance between two adjacent centres is d * sin(pi / N).
+     For their targets not to overlap THAT must be at least one tap target:
+
+         d >= tap / sin(pi / N)
+
+     ...and the marks sit INSIDE the rim, so their centres are on a circle of
+     radius d/2 - tap/2, not d/2. Substituting that and solving:
+
+         d >= tap * (1 / sin(pi / N) + 1)
+
+     THIS DERIVATION WAS WRONG TWICE, and the browser guard caught both. First
+     it sized off the ARC between centres (N * tap / pi) — an arc is longer
+     than its chord, so at N=8 and a 44px target that gave 112.05px whose chord
+     is 42.9px, a 1.1px overlap on every neighbouring pair. Corrected to the
+     chord, it still measured 27.16px between centres, because the inset had
+     been left out of the radius. Neither error is visible in the source; both
+     are one measurement away.
+
+     The tap floor MOVES, 24px to 44px on a coarse pointer, which is precisely
+     when the ring has to grow; a hard-coded diameter ships eight overlapping
+     targets to a phone. The 96px is an aesthetic floor, not a derived one —
+     a 63px ring is legible-but-cramped on desktop — and max() keeps whichever
+     is larger. */
+  --juno-gizmo-marks: 8;
+  --juno-gizmo-size: max(
+    96px,
+    calc(var(--juno-size-tap-min) * (1 / sin(180deg / var(--juno-gizmo-marks)) + 1))
+  );
+
+  display: inline-flex;
+  flex-direction: column;
+  align-items: center;
+  gap: var(--juno-space-8);
+  font-family: var(--juno-font-family-sans);
+  color: var(--juno-data);
+}
+
+/* The spoken state. Visible by default — a bearing is useful to everyone —
+   but it is the live region either way, because a rotating needle announces
+   nothing. Consumers that want it invisible use .juno-sr-only rather than
+   display:none, which would take it out of the accessibility tree too. */
+.juno-gizmo__readout {
+  margin: 0;
+  font-size: var(--juno-font-size-11);
+  font-variant-numeric: tabular-nums;
+  letter-spacing: var(--juno-font-tracking-label);
+  color: var(--juno-label);
+}
+
+.juno-gizmo__ring {
+  position: relative;
+  inline-size: var(--juno-gizmo-size);
+  block-size: var(--juno-gizmo-size);
+  border-radius: 50%;
+  border: var(--juno-border-width-1) solid var(--juno-border);
+  background: color-mix(in srgb, var(--juno-s1) 88%, transparent);
+}
+
+/* The needle points where the camera looks. Rotated by the app's angle, and
+   the transition runs on the motion scale so prefers-reduced-motion collapses
+   it without this file needing its own media query (base.css owns that). */
+.juno-gizmo__needle {
+  position: absolute;
+  inset: 0;
+  display: grid;
+  place-items: start center;
+  pointer-events: none;
+  rotate: var(--juno-gizmo-heading);
+  transition: rotate calc(var(--juno-motion-duration-base) * var(--juno-motion-scale))
+    var(--juno-motion-ease-standard);
+}
+
+.juno-gizmo__needle::before {
+  content: '';
+  inline-size: var(--juno-border-width-2);
+  block-size: 38%;
+  margin-block-start: var(--juno-space-4);
+  background: linear-gradient(var(--juno-role), transparent);
+  border-radius: var(--juno-border-width-2);
+}
+
+/* ── snap targets ──────────────────────────────────────────────────────
+   REAL BUTTONS. Not a canvas hit test, not a div with a click handler: a
+   button is focusable, activates on Enter and Space, is announced as a
+   control, and works with a screen reader's forms mode. That is most of
+   this component's value and the reason it is upstream.
+
+   Positioned by rotating the mark out to the rim and counter-rotating the
+   glyph, so the letter stays upright at every angle. --juno-gizmo-at is the
+   mark's own bearing, set per element. */
+.juno-gizmo__mark {
+  position: absolute;
+  inset-block-start: 50%;
+  inset-inline-start: 50%;
+  inline-size: var(--juno-size-tap-min);
+  block-size: var(--juno-size-tap-min);
+  margin: calc(var(--juno-size-tap-min) / -2);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: none;
+  border-radius: 50%;
+  background: transparent;
+  color: var(--juno-label);
+  font: inherit;
+  font-size: var(--juno-font-size-11);
+  font-weight: var(--juno-font-weight-bold);
+  cursor: pointer;
+  transform: rotate(var(--juno-gizmo-at, 0deg))
+    translate(0, calc(var(--juno-gizmo-size) / -2 + var(--juno-size-tap-min) / 2))
+    rotate(calc(-1 * var(--juno-gizmo-at, 0deg)));
+}
+
+.juno-gizmo__mark:hover {
+  color: var(--juno-data);
+  background: var(--juno-s2);
+}
+
+/* The mark the camera is currently nearest. aria-current, not a class: the
+   app already has to say it for the screen reader, and a class would be a
+   second copy of the same fact. */
+.juno-gizmo__mark[aria-current='true'] {
+  color: var(--juno-role);
+  background: var(--juno-s3);
+}
+
+.juno-gizmo__mark:focus-visible,
+.juno-gizmo__center:focus-visible {
+  outline: var(--juno-border-width-2) solid var(--juno-active);
+  outline-offset: var(--juno-space-2);
+}
+
+/* Centre target — reset to the default view. */
+.juno-gizmo__center {
+  position: absolute;
+  inset-block-start: 50%;
+  inset-inline-start: 50%;
+  inline-size: var(--juno-size-tap-min);
+  block-size: var(--juno-size-tap-min);
+  margin: calc(var(--juno-size-tap-min) / -2);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: var(--juno-border-width-1) solid var(--juno-border);
+  border-radius: 50%;
+  background: var(--juno-s1);
+  color: var(--juno-label);
+  font: inherit;
+  cursor: pointer;
+}
+
+.juno-gizmo__center:hover {
+  color: var(--juno-role);
+  border-color: var(--juno-role);
+}
+
+/* ── pitch arc ─────────────────────────────────────────────────────────
+   The second angle, inside a CLAMPED range — a camera that can tilt 0..85°
+   should not show a hand that can point anywhere, or the widget lies about
+   what the app will accept. The clamp lives here so every consumer gets it
+   without re-deriving it from its own camera limits. */
+.juno-gizmo__arc {
+  --juno-gizmo-pitch-min: 0deg;
+  --juno-gizmo-pitch-max: 85deg;
+
+  position: relative;
+  inline-size: var(--juno-gizmo-size);
+  block-size: calc(var(--juno-gizmo-size) / 2);
+  overflow: hidden;
+  border-block-end: var(--juno-border-width-1) solid var(--juno-border);
+}
+
+.juno-gizmo__arc-hand {
+  position: absolute;
+  inset-block-end: 0;
+  inset-inline-start: 50%;
+  inline-size: var(--juno-border-width-2);
+  block-size: 80%;
+  background: var(--juno-role);
+  transform-origin: bottom center;
+  rotate: clamp(var(--juno-gizmo-pitch-min), var(--juno-gizmo-pitch), var(--juno-gizmo-pitch-max));
+  transition: rotate calc(var(--juno-motion-duration-base) * var(--juno-motion-scale))
+    var(--juno-motion-ease-standard);
+}
+
+/* ── touch ─────────────────────────────────────────────────────────────
+   Nothing to grow here, and that is the point: the marks are sized in
+   --juno-size-tap-min, which base.css promotes to the comfortable target on a
+   coarse pointer, and --juno-gizmo-size is derived from it — so the whole ring
+   grows and the marks stay non-overlapping by construction. A gizmo that keeps
+   its desktop diameter on a phone has eight overlapping targets, which is the
+   defect this derivation exists to make impossible. */
+
 /* ════════════════════════════════════════════════════════════════════
  *  Component — Icon loader (the ring-a-control primitive)
  *  A control ringed by the spinning arc while its section loads — the
@@ -4187,11 +4727,20 @@ button.juno-list__row:disabled {
   opacity: 0;
 }
 
-/* the pill — a span after the radio, or the aria-pressed button itself */
+/* the pill — a span after the radio, or the aria-pressed button itself.
+   The tap floor is on the PAINTED box, not on the label that wraps it: the
+   label is a bare inline-flex and takes its height from this. Segmented is a
+   phone-first control and is routinely the only control on a whole settings
+   section, so it holds --juno-size-tap-min like .juno-btn does — 24px (WCAG
+   2.2 AA, 2.5.8) on a fine pointer, promoted to the 44px comfortable target
+   under (pointer: coarse) by base.css. Without it the pill computed ~25px
+   from its padding alone, which is the AA floor by accident and nothing on
+   touch. See 20260826-025. */
 .juno-seg__opt input + span,
 button.juno-seg__opt {
   display: inline-flex;
   align-items: center;
+  min-block-size: var(--juno-size-tap-min);
   gap: var(--juno-gap-control);
   font-family: var(--juno-font-family-sans);
   font-size: var(--juno-font-size-11);
@@ -4239,7 +4788,11 @@ button.juno-seg__opt:disabled {
   cursor: not-allowed;
 }
 
-/* Small — matches .juno-btn--sm; for dense toolbars */
+/* Small — dense toolbars: less type, tighter padding. UNLIKE .juno-btn--sm it
+   does NOT drop below the tap floor, which the base rule above holds: --sm is a
+   density modifier here, not an opt-out of the touch target. A segmented row is
+   often the only control on a settings section, so a sub-tap variant of it has
+   no safe use on a phone. */
 .juno-seg--sm .juno-seg__opt input + span,
 .juno-seg--sm > button.juno-seg__opt {
   font-size: var(--juno-font-size-10);
@@ -4644,6 +5197,194 @@ button.juno-seg__opt:disabled {
   block-size: 100%;
 }
 
+/* ════════════════════════════════════════════════════════════════════
+ *  Component — Colour swatch + palette
+ *  Showing a user-chosen colour, and letting someone pick one. Diagrams,
+ *  calendars, tag and label systems, chart series colours, annotation
+ *  tools, theming UIs, kanban boards.
+ *
+ *  THE HARD PART IS NOT THE SQUARE. A swatch shows an ARBITRARY colour, so
+ *  every piece of chrome on it — its border, its focus ring, its checked
+ *  indicator — has to stay visible against a colour junoui has never seen.
+ *  A single hairline fails at one end of the range: a dark border vanishes
+ *  on near-black, a light one vanishes on near-white, and the swatch that
+ *  loses its border is the one that has merged with the panel behind it.
+ *
+ *  The answer is a PAIR of hairlines drawn as an inset and an outset ring.
+ *  They do NOT do the same job, which is the part worth reading twice: the
+ *  inset one composites over the SWATCH and edges it against its own fill,
+ *  the outset one composites over the PANEL and separates it from the
+ *  surface. With the swatch's own contrast against that panel, the boundary
+ *  has three ways to be visible and needs only one of them.
+ *
+ *  Guarded by sweeping the swatch colour against both panels rather than by
+ *  asserting a border value (test/swatch.test.mjs).
+ *
+ *  COLOUR IS NEVER THE ONLY SIGNAL. junoui's own standing rule, and a bare
+ *  swatch is exactly what violates it: every swatch carries an accessible
+ *  NAME, and the checked state carries a GLYPH, not just a hue.
+ *
+ *  The app owns the colour list and which one is chosen.
+ *  Usage:
+ *    <button class="juno-swatch juno-swatch--button" style="--juno-swatch-color:#C41E3A"
+ *            aria-label="Crimson"></button>
+ *
+ *    <div class="juno-popover" popover id="palette">
+ *      <div class="juno-palette" role="listbox" aria-label="Annotation colour">
+ *        <button class="juno-palette__option" role="option" aria-selected="true"
+ *                style="--juno-swatch-color:#C41E3A" aria-label="Crimson">
+ *          <svg class="juno-icon juno-palette__check" aria-hidden="true">
+ *            <use href="…#juno-i-check" /></svg>
+ *        </button>
+ *      </div>
+ *    </div>
+ * ════════════════════════════════════════════════════════════════════ */
+
+.juno-swatch {
+  /* The colour the app is showing. Named rather than an inline `background`
+     so the rings below can sit on top of it without the caller reassembling
+     the whole box-shadow stack. */
+  --juno-swatch-color: var(--juno-muted);
+
+  /* Sized off the control scale, so a swatch in a form row matches the
+     controls beside it and grows with them on a coarse pointer. */
+  --juno-swatch-size: var(--juno-size-tap-min);
+
+  display: inline-block;
+  inline-size: var(--juno-swatch-size);
+  block-size: var(--juno-swatch-size);
+  flex-shrink: 0;
+  border: none;
+  border-radius: var(--juno-radius-3);
+  background: var(--juno-swatch-color);
+
+  /* THE TWO-TONE RING, and the alphas are measured rather than chosen.
+     The inset ring composites over the SWATCH and gives it an edge against
+     its own fill; the outset ring composites over the PANEL — an outset
+     box-shadow is outside the element — and separates the swatch from the
+     surface behind it. Between them, plus the swatch's own contrast with the
+     panel, the boundary is discernible whatever colour the app supplies.
+
+     At 0.45 / 0.35 that property FAILS: on a light panel a mid-grey swatch
+     (around #919191) leaves the best of the three at 2.57:1, under the 3:1
+     non-text floor. 0.65 on both takes the worst case to 3.39:1. The sweep in
+     test/swatch.test.mjs is what measured it — the first version of that test
+     asked the wrong question (both rings against the swatch) and reported 145
+     failures; the right question is whether the BOUNDARY is visible, and it
+     has three ways to be.
+
+     Deliberately not `border`, which would eat into the colour area and change
+     the swatch's size with its style. */
+  box-shadow:
+    inset 0 0 0 var(--juno-border-width-1) rgb(0 0 0 / 0.65),
+    0 0 0 var(--juno-border-width-1) rgb(255 255 255 / 0.65);
+}
+
+.juno-swatch--circle {
+  border-radius: 50%;
+}
+
+.juno-swatch--sm {
+  --juno-swatch-size: var(--juno-space-16);
+}
+
+.juno-swatch--lg {
+  --juno-swatch-size: var(--juno-size-tap-comfortable);
+}
+
+/* A swatch used as a trigger — the thing you click to open the palette. */
+.juno-swatch--button {
+  padding: 0;
+  cursor: pointer;
+}
+
+/* FOCUS RINGS ON AN ARBITRARY HUE. The ring is drawn OUTSIDE the swatch,
+   with an offset, so its contrast is against the panel — a known surface —
+   rather than against a colour junoui cannot predict. A ring drawn on the
+   swatch itself has the same unsolvable problem as the border, and "use a
+   thicker ring" does not fix a hue collision. */
+.juno-swatch--button:focus-visible,
+.juno-palette__option:focus-visible {
+  outline: var(--juno-border-width-2) solid var(--juno-active);
+  outline-offset: var(--juno-space-4);
+}
+
+/* ── palette ───────────────────────────────────────────────────────────
+   A grid of swatches inside a .juno-popover. junoui ships the grid and the
+   states; the app owns the list and which one is chosen. */
+.juno-palette {
+  display: grid;
+  grid-template-columns: repeat(var(--juno-palette-columns, 6), auto);
+  gap: var(--juno-space-8);
+  padding: var(--juno-space-4);
+}
+
+.juno-palette__option {
+  --juno-swatch-color: var(--juno-muted);
+  --juno-swatch-size: var(--juno-size-tap-min);
+
+  position: relative;
+  inline-size: var(--juno-swatch-size);
+  block-size: var(--juno-swatch-size);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: none;
+  border-radius: var(--juno-radius-3);
+  background: var(--juno-swatch-color);
+  cursor: pointer;
+  box-shadow:
+    inset 0 0 0 var(--juno-border-width-1) rgb(0 0 0 / 0.65),
+    0 0 0 var(--juno-border-width-1) rgb(255 255 255 / 0.65);
+}
+
+/* THE CHECKED STATE IS A GLYPH, NOT A HUE. Colour is never the only signal,
+   and "the chosen one is the one that looks slightly different" is exactly
+   the failure that rule exists to prevent — it is invisible to anyone who
+   cannot separate the two hues, and to anyone looking at a screenshot.
+
+   The check itself sits on the arbitrary colour, so it gets the same
+   treatment as the swatch's own ring: a light glyph with a dark halo, which
+   is the canvas-ink pair at glyph scale. */
+.juno-palette__check {
+  display: none;
+  color: #fff;
+  filter: drop-shadow(0 0 var(--juno-border-width-1) rgb(0 0 0 / 0.9))
+    drop-shadow(0 0 var(--juno-border-width-2) rgb(0 0 0 / 0.7));
+}
+
+.juno-palette__option[aria-selected='true'] .juno-palette__check,
+.juno-palette__option[aria-checked='true'] .juno-palette__check {
+  display: block;
+}
+
+/* ...and a second, non-glyph cue for the same state, because a check inside a
+   28px square is small: the selected option also grows a ring in the active
+   role, drawn OUTSIDE the swatch where its contrast is against the panel. */
+.juno-palette__option[aria-selected='true'],
+.juno-palette__option[aria-checked='true'] {
+  box-shadow:
+    inset 0 0 0 var(--juno-border-width-1) rgb(0 0 0 / 0.65),
+    0 0 0 var(--juno-border-width-1) rgb(255 255 255 / 0.65),
+    0 0 0 calc(var(--juno-border-width-1) + var(--juno-border-width-2)) var(--juno-active);
+}
+
+/* A swatch showing "no colour" — transparent, unset, inherit. Without this a
+   consumer paints it in a mid grey and the user cannot tell "grey" from
+   "none", which is a different thing to know. */
+.juno-swatch--none,
+.juno-palette__option--none {
+  background:
+    linear-gradient(
+        to bottom right,
+        transparent calc(50% - var(--juno-border-width-1)),
+        var(--juno-warning) calc(50% - var(--juno-border-width-1)),
+        var(--juno-warning) calc(50% + var(--juno-border-width-1)),
+        transparent calc(50% + var(--juno-border-width-1))
+      )
+      var(--juno-s1);
+}
+
 /* ════════════════════════════════════════════════════════════════════
  *  Component — Switch (toggle)  ·  labeled rocker
  *  A wide squared slide-switch with the state printed inside the track
@@ -5786,6 +6527,266 @@ button.juno-seg__opt:disabled {
   inset-inline-start: calc(100% - var(--juno-space-4));
 }
 
+/* ════════════════════════════════════════════════════════════════════
+ *  Component — Tree / outliner (nested rows, disclosure, selection)
+ *  Layer stacks, file browsers, settings trees, org charts, comment
+ *  threads, nested navigation. Where .juno-list is flat and
+ *  .juno-accordion is single-level, this nests to arbitrary depth and
+ *  carries a selection.
+ *
+ *  ZERO JS FOR THE VISUALS. Indentation comes from the nested `role=group`
+ *  lists the ARIA pattern already requires, so depth costs no custom
+ *  property and no inline style; collapse is `[aria-expanded='false']`
+ *  hiding the child group. The app owns the attribute, exactly like
+ *  __item's aria-pressed elsewhere in junoui.
+ *
+ *  KEYBOARD IS NOT OPTIONAL and is not CSS. A tree without arrow-key
+ *  traversal and a roving tabindex is a list of buttons wearing tree
+ *  roles. junoui ships the contract in docs/components/tree.md and a
+ *  stateless enhancer at `junoui/tree` — use one or the other, but a tree
+ *  that has neither is not accessible and no stylesheet can fix it.
+ *
+ *  Usage (the markup the roles require — see the doc for the full ARIA
+ *  contract, which is the half apps get wrong):
+ *    <ul class="juno-tree" role="tree" aria-label="Scene">
+ *      <li class="juno-tree__item" role="treeitem" aria-level="1"
+ *          aria-expanded="true" aria-selected="false">
+ *        <div class="juno-tree__row">
+ *          <button class="juno-tree__caret" tabindex="-1" aria-hidden="true"></button>
+ *          <svg class="juno-icon juno-tree__icon" aria-hidden="true">…</svg>
+ *          <span class="juno-tree__label">Terrain</span>
+ *          <span class="juno-tree__count">12</span>
+ *          <span class="juno-tree__trail">…</span>
+ *          <button class="juno-tree__handle" aria-label="Reorder Terrain"></button>
+ *        </div>
+ *        <ul class="juno-tree__group" role="group">…</ul>
+ *      </li>
+ *    </ul>
+ * ════════════════════════════════════════════════════════════════════ */
+
+.juno-tree {
+  --juno-role: var(--juno-active);
+
+  /* One indent step. Applied per nested group, so depth is structural and
+     arbitrary rather than a level number someone has to keep in sync. */
+  --juno-tree-indent: var(--juno-space-16);
+
+  margin: 0;
+  padding: 0;
+  list-style: none;
+  font-family: var(--juno-font-family-sans);
+  font-size: var(--juno-font-size-13);
+  color: var(--juno-data);
+}
+
+.juno-tree__group {
+  margin: 0;
+  padding: 0;
+  padding-inline-start: var(--juno-tree-indent);
+  list-style: none;
+}
+
+/* Collapsed: the child group goes. `display: none` and not a height
+   animation — a tree collapses an unknown number of rows at an unknown
+   depth, so there is no end value to transition to, and interpolate-size
+   is not available everywhere junoui targets. */
+.juno-tree__item[aria-expanded='false'] > .juno-tree__group {
+  display: none;
+}
+
+.juno-tree__row {
+  display: flex;
+  align-items: center;
+  gap: var(--juno-space-8);
+  inline-size: 100%;
+  min-block-size: var(--juno-size-tap-min);
+  padding-inline: var(--juno-space-8);
+  padding-block: var(--juno-space-4);
+  border: none;
+  border-radius: var(--juno-radius-3);
+  background: transparent;
+  color: inherit;
+  font: inherit;
+  text-align: start;
+  text-decoration: none;
+  cursor: pointer;
+}
+
+.juno-tree__row:hover {
+  background: var(--juno-s2);
+}
+
+/* SELECTION is a different fact from hover and from aria-current, and the
+   ticket is right that conflating them is the common bug: hover is where the
+   pointer is, aria-current is which page you are on, aria-selected is what
+   the next action will apply to. A layer stack has all three at once. */
+.juno-tree__item[aria-selected='true'] > .juno-tree__row {
+  background: var(--juno-s3);
+  color: var(--juno-role);
+}
+
+.juno-tree__item[aria-current] > .juno-tree__row {
+  box-shadow: inset var(--juno-border-width-2) 0 0 var(--juno-role);
+}
+
+.juno-tree__row:focus-visible {
+  outline: var(--juno-border-width-2) solid var(--juno-active);
+  outline-offset: calc(-1 * var(--juno-border-width-2));
+}
+
+/* ── disclosure caret ──────────────────────────────────────────────────
+   aria-hidden and tabindex=-1 on purpose: the row itself is the treeitem
+   and Left/Right already collapse and expand, so a separately focusable
+   caret puts a second stop in the tab order for an action the row has. It
+   stays a real button for the pointer. */
+.juno-tree__caret {
+  flex-shrink: 0;
+  inline-size: var(--juno-space-16);
+  block-size: var(--juno-space-16);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: none;
+  background: transparent;
+  color: var(--juno-label);
+  cursor: pointer;
+  transition: transform var(--juno-motion-duration-quick) var(--juno-motion-ease-standard);
+}
+
+.juno-tree__caret::before {
+  content: '';
+  inline-size: 0;
+  block-size: 0;
+  border-block: calc(var(--juno-space-4) + 1px) solid transparent;
+  border-inline-start: calc(var(--juno-space-4) + 2px) solid currentcolor;
+}
+
+.juno-tree__item[aria-expanded='true'] > .juno-tree__row > .juno-tree__caret {
+  transform: rotate(90deg);
+}
+
+/* A leaf keeps the caret's box so labels line up down the column, but paints
+   nothing — an empty gap would let sibling labels wander. */
+.juno-tree__item:not([aria-expanded]) > .juno-tree__row > .juno-tree__caret {
+  visibility: hidden;
+  cursor: default;
+}
+
+.juno-tree__icon {
+  flex-shrink: 0;
+  color: var(--juno-label);
+}
+
+.juno-tree__label {
+  min-inline-size: 0;
+  overflow: hidden;
+  text-overflow: ellipsis;
+  white-space: nowrap;
+}
+
+/* Count badge on a group row. Pushed to the trailing edge with the rest of
+   the trailing furniture. */
+.juno-tree__count {
+  margin-inline-start: auto;
+  flex-shrink: 0;
+  font-size: var(--juno-font-size-11);
+  font-variant-numeric: tabular-nums;
+  color: var(--juno-muted);
+}
+
+/* The same trailing-control slot .juno-list__row has: a switch, a menu
+   trigger, a value. Follows the count when both are present. */
+.juno-tree__trail {
+  margin-inline-start: auto;
+  flex-shrink: 0;
+  display: inline-flex;
+  align-items: center;
+  gap: var(--juno-space-8);
+}
+
+.juno-tree__count + .juno-tree__trail {
+  margin-inline-start: 0;
+}
+
+/* ── reorder handle ────────────────────────────────────────────────────
+   The AFFORDANCE and its hit area; the reorder logic is the app's, which is
+   junoui's usual line. It is a real button and always visible on touch: a
+   long-press-drag is the obvious gesture and the wrong one, because a tree
+   sitting on or beside a pan/zoom surface has to let the pan win. An
+   explicit handle is the only unambiguous target — see the doc.
+   `touch-action: none` on the handle ALONE, so dragging it never scrolls
+   while the rest of the row still pans normally. */
+.juno-tree__handle {
+  flex-shrink: 0;
+  inline-size: var(--juno-space-16);
+  block-size: var(--juno-space-16);
+  display: grid;
+  place-items: center;
+  padding: 0;
+  border: none;
+  background: transparent;
+  color: var(--juno-muted);
+  cursor: grab;
+  touch-action: none;
+}
+
+.juno-tree__handle:active {
+  cursor: grabbing;
+}
+
+.juno-tree__handle::before {
+  content: '';
+  inline-size: var(--juno-space-10);
+  block-size: var(--juno-border-width-1);
+  box-shadow:
+    0 calc(-1 * var(--juno-space-4)) 0 currentcolor,
+    0 var(--juno-space-4) 0 currentcolor;
+  background: currentcolor;
+}
+
+/* The row being dragged, while the app moves it. */
+.juno-tree__item[data-juno-dragging] > .juno-tree__row {
+  opacity: var(--juno-opacity-muted);
+}
+
+/* Drop target edge. A line rather than a filled row: the drop lands BETWEEN
+   rows, and a filled highlight says "into this one", which is a different
+   operation in a tree and the one users complain about. */
+.juno-tree__item[data-juno-drop='before'] > .juno-tree__row {
+  box-shadow: inset 0 var(--juno-border-width-2) 0 var(--juno-active);
+}
+
+.juno-tree__item[data-juno-drop='after'] > .juno-tree__row {
+  box-shadow: inset 0 calc(-1 * var(--juno-border-width-2)) 0 var(--juno-active);
+}
+
+.juno-tree__item[data-juno-drop='into'] > .juno-tree__row {
+  outline: var(--juno-border-width-2) solid var(--juno-active);
+  outline-offset: calc(-1 * var(--juno-border-width-2));
+}
+
+/* ── touch ─────────────────────────────────────────────────────────────
+   The caret and the handle paint small so a dense tree stays dense, but a
+   16px target is not tappable. Grow the HIT AREA only, with a transparent
+   overlay, exactly as .nx-check does downstream: a 44px painted caret would
+   swallow the row it sits in. The row's own floor comes from
+   --juno-size-tap-min, which base.css promotes on a coarse pointer. */
+@media (pointer: coarse) {
+  .juno-tree__caret,
+  .juno-tree__handle {
+    position: relative;
+  }
+
+  .juno-tree__caret::after,
+  .juno-tree__handle::after {
+    content: '';
+    position: absolute;
+
+    /* (44 - 16) / 2 = 14 */
+    inset: calc(-1 * (var(--juno-size-tap-comfortable) - var(--juno-space-16)) / 2);
+  }
+}
+
 /* ════════════════════════════════════════════════════════════════════
  *  junoui — utilities layer
  *