@junoput01/junoui 0.6.0 → 0.8.0

package/docs/components/dock.md

@@ -187,6 +187,40 @@ over scroll-event discretization — anything longer visibly lags the finger.
   plus the pill's padding and border), `--juno-dock-edge-gap` (what the
   floating margins take from `100%` — default `2 × space.12`).
 
+## How many items fit
+
+`.juno-dock__item` is `flex: 1 1 0`, so the bar divides its inner width by
+however many items are present. A consumer deciding **how many to render** — and
+whether they still hold a tap target — reads that budget from junoui rather than
+re-deriving it from the numbers in `dock.css`:
+
+| Custom property             | What it is                                                                                                            |
+| --------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| `--juno-dock-items`         | The item budget. **You set it** to what you render; junoui does not enforce it, it derives from it.                   |
+| `--juno-dock-item-inline`   | The width one item gets. A prediction of what the flex layout produces — asserted against the measured box in CI.     |
+| `--juno-dock-fit-inline`    | The narrowest viewport at which every item still holds `--juno-size-tap-comfortable`. Below it, drop an item.         |
+| `--juno-dock-chrome-inline` | The bar's total inline chrome (margin + padding + border, both sides). `0` on the full-bleed bar, `34px` on the pill. |
+| `--juno-dock-avail`         | The width the budget divides. Defaults to `100vw`; override it when the bar is not viewport-wide.                     |
+
+```css
+/* five destinations need 254px; below that, render four */
+@media (max-width: 253px) {
+  .my-dock__item--secondary {
+    display: none;
+  }
+}
+```
+
+The margin, padding and border terms are declared **once** and consumed by both
+the variant's own box and the sum above, so the budget cannot disagree with the
+bar it describes — the same construction as `--juno-dock-edge-offset`.
+
+**There is deliberately no scale floor.** "What scale keeps a 44px target?" is
+`44px / --juno-dock-item-inline`, a ratio of two lengths, and CSS cannot divide
+by a length. A consumer that must scale rather than drop compares those two
+values itself. Prefer dropping an item: scaling a bar scales its hit areas with
+it, which is the problem the floor was being computed to avoid.
+
 ## Anatomy (any platform)
 
 - Full-width bar on `s1`, hairline seam on the block-start edge; items split the

package/docs/components/fold-slot.md

@@ -10,7 +10,7 @@ coming in, end-of-fade going out). Keep the element mounted; flip
 
 ```html
 <div class="juno-pillbar">
-  <button class="juno-fold" data-juno-in aria-label="Scroll to top">
+  <button class="juno-fold juno-pillbar__item" data-juno-in aria-label="Scroll to top">
     <svg class="juno-icon" aria-hidden="true"><use href="…#juno-i-arrow-up" /></svg>
   </button>
   …other members…
@@ -24,6 +24,31 @@ coming in, end-of-fade going out). Keep the element mounted; flip
 | `--juno-fold-size` | The slot's open width (default `size.tap.comfortable`) — must be definite, transitions cannot run to an intrinsic size.         |
 | `--juno-fold-gap`  | The row's flex/grid gap (default `0px`) — the folded slot swallows one gap with a negative margin so the row closes completely. |
 
+## Composing it with a component class
+
+The canonical use puts `.juno-fold` on an element that already carries a
+component class — `.juno-pillbar__item`, `.juno-btn`, `.juno-chip` — because that
+is where the capsule chrome (tap target, padding, hover, focus ring,
+`aria-pressed`) lives. The fold is built for that, and two things about it are
+worth knowing rather than rediscovering:
+
+**Which floors it releases.** A border-box inline size has exactly three inputs
+that can hold it above zero, and the folded state releases all three:
+`min-inline-size` (a component's tap floor), `padding-inline`, and
+`border-inline-width`. Each is in the fold's transition list too, so the content
+neither snaps sideways as the fold starts nor jumps to full width when the slot
+opens. Composed with `.juno-pillbar__item` and none of them released, the folded
+slot lays out at 44px — the tap target — and the row never closes.
+
+**It takes over the element's `transition`.** `transition` is a shorthand: two
+rules setting it do not merge, the winner replaces the loser's whole list. The
+fold's declarations are stated at attribute specificity so it wins that, and its
+list therefore also carries the chrome properties (`color`, `background-color`)
+the components animate — composing costs the capsule nothing. A component of your
+own that composes with `.juno-fold` and needs a third property transitioned
+should state it at higher specificity than `.juno-fold[data-juno-in]` (0,2,0),
+repeating the fold's own entries, or the fold's list wins and yours is dropped.
+
 - The row's own width follows the slot, so the whole row slides open/closed.
 - `prefers-reduced-motion`: handled by the base layer (states still apply,
   transition durations collapse).

package/docs/components/gizmo.md

@@ -0,0 +1,114 @@
+# Viewport orientation gizmo
+
+The orientation widget any 3D or map viewport ships: a compass ring 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.
+
+CAD and BIM viewers, product configurators, virtual tours, model previews, floor
+plans, any map with a tilt.
+
+## A ring, not a cube
+
+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 that case and
+generalises to free orbit; a cube does not go the other way.
+
+## Web
+
+```html
+<div
+  class="juno-gizmo"
+  role="group"
+  aria-label="View orientation"
+  style="--juno-gizmo-heading:45deg; --juno-gizmo-pitch:35deg;"
+>
+  <p class="juno-gizmo__readout" aria-live="polite">
+    Facing north-east, 45 degrees. Tilted 35 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">N</button>
+    <!-- …seven more, every 45° -->
+    <button class="juno-gizmo__center" aria-label="Reset view to north, level">⌖</button>
+  </div>
+  <div class="juno-gizmo__arc"><span class="juno-gizmo__arc-hand" aria-hidden="true"></span></div>
+</div>
+```
+
+| Class / prop                      | Effect                                       |
+| --------------------------------- | -------------------------------------------- |
+| `.juno-gizmo`                     | Root. Holds the angles and the derived size. |
+| `.juno-gizmo__readout`            | The spoken state. `aria-live="polite"`.      |
+| `.juno-gizmo__ring`               | The compass ring.                            |
+| `.juno-gizmo__needle`             | Points at `--juno-gizmo-heading`.            |
+| `.juno-gizmo__mark`               | A snap target. A real `<button>`.            |
+| `.juno-gizmo__center`             | Reset target.                                |
+| `.juno-gizmo__arc` / `__arc-hand` | The second angle, clamped.                   |
+| `--juno-gizmo-heading` / `-pitch` | **The app writes these.**                    |
+| `--juno-gizmo-at`                 | One mark's own bearing.                      |
+| `--juno-gizmo-pitch-min` / `-max` | The clamp (default `0deg`–`85deg`).          |
+| `--juno-gizmo-size`               | Ring diameter. Derived — see below.          |
+
+**The app owns the camera.** junoui rotates the needle and the hand; it never
+stores or changes an angle.
+
+## The accessibility contract
+
+This is why the component is upstream rather than in each app.
+
+- **`role="group"`** with an accessible name on the root.
+- **Snap targets are real `<button>`s.** 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 in a screen reader's forms mode.
+- **Every mark carries an accessible name**, because `"N"` is a letter, not a
+  name. `aria-label="Face north"`.
+- **One focus stop.** Tab reaches the gizmo once; arrow keys move between marks
+  and **wrap**, Enter activates. Eight tab stops for eight compass points is what
+  apps ship and what makes the widget unusable by keyboard.
+- **The bearing is announced in words.** A rotating needle announces nothing, and
+  `"37deg"` is a number the listener has to convert. The readout is a live region
+  saying _"Facing north-east, 37 degrees. Tilted 45 degrees."_
+- **`aria-current="true"`** on the mark the camera is nearest — not a class, since
+  the app must say it for the screen reader anyway.
+
+```js
+import { enhanceGizmo, orientationLabel, bearingLabel } from 'junoui/gizmo';
+
+enhanceGizmo(el); // one focus stop, wrapping arrows
+readout.textContent = orientationLabel(yaw, pitch);
+bearingLabel(37); // → "north-east"
+```
+
+Stateless, like `junoui/tree`: it moves focus and lets the marks' own click
+handlers fire. It never writes an angle.
+
+## The diameter is derived, not chosen
+
+`N` marks sit evenly around the rim, and each is inset from it by half a target,
+so their centres lie on a circle of radius `d/2 − tap/2`. The straight-line
+distance between two adjacent centres — the **chord**, not the arc — must be at
+least one tap target:
+
+```
+d ≥ tap · (1 / sin(π / N) + 1)
+```
+
+which is what `--juno-gizmo-size` computes: `158.98px` at `N = 8` and a 44px
+target.
+
+**This derivation was wrong twice, and both errors were invisible in the
+source.** Sizing off the _arc_ between centres (`N · tap / π`) gives 112.05px,
+whose chord is 42.9px — every neighbouring pair overlapping by 1.1px. Correcting
+to the chord but forgetting the inset gives 114.98px and measures 27.16px between
+centres. Both were caught by measuring a laid-out ring, which is why
+`test/visual/gizmo.spec.mjs` asserts the distance between every pair of marks
+rather than trusting the formula. The tap floor **moves** — 24px on a
+fine pointer, 44px on a coarse one — so a ring with a hard-coded diameter has
+eight overlapping targets on a phone. Setting `--juno-gizmo-size` larger is fine;
+`max()` stops it going below what the marks need.
+
+## Motion
+
+Snap transitions run on `--juno-motion-scale`, so `prefers-reduced-motion`
+collapses them through the base layer without a component-local media query.

package/docs/components/swatch.md

@@ -0,0 +1,95 @@
+# 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.
+
+So the border is a **pair** of hairlines, one dark (inset) and one light
+(outset). Whatever the swatch, one of them contrasts; the other is the one you
+do not notice. `test/swatch.test.mjs` sweeps the swatch colour and asserts one
+ring always clears 3:1, rather than asserting a border value.
+
+**Focus rings sit outside the swatch, with an offset**, so their contrast is
+against the panel — a known surface — rather than against a hue junoui cannot
+predict. A ring drawn _on_ the swatch has the same unsolvable problem, and a
+thicker ring does not fix a hue collision.
+
+## Web
+
+```html
+<span
+  class="juno-swatch"
+  style="--juno-swatch-color:#C41E3A"
+  role="img"
+  aria-label="Crimson"
+></span>
+
+<button
+  class="juno-swatch juno-swatch--button"
+  style="--juno-swatch-color:#1F6FEB"
+  aria-label="Annotation colour: Azure"
+  popovertarget="palette"
+></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:#1F6FEB"
+      aria-label="Azure"
+    >
+      <svg class="juno-icon juno-palette__check" aria-hidden="true">
+        <use href="…#juno-i-check" />
+      </svg>
+    </button>
+  </div>
+</div>
+```
+
+| Class / prop                  | Effect                                                  |
+| ----------------------------- | ------------------------------------------------------- |
+| `.juno-swatch`                | The square. Two-tone ring, sized off the control scale. |
+| `.juno-swatch--circle`        | Round rather than square.                               |
+| `.juno-swatch--sm`            | `space.16` — inline with body text.                     |
+| `.juno-swatch--lg`            | `size.tap.comfortable` — a primary trigger.             |
+| `.juno-swatch--button`        | Swatch used as a trigger.                               |
+| `.juno-swatch--none`          | "No colour" — a slash, not a grey.                      |
+| `.juno-palette__option--none` | The same, as a choice in the grid.                      |
+| `.juno-palette`               | The grid inside a `.juno-popover`.                      |
+| `.juno-palette__option`       | One choice. Selected shows a glyph **and** a ring.      |
+| `--juno-swatch-color`         | **The app writes this.**                                |
+| `--juno-swatch-size`          | Defaults to `size.tap.min`.                             |
+| `--juno-palette-columns`      | Grid width (default `6`).                               |
+
+The app owns the colour list and which one is chosen.
+
+## Colour is never the only signal
+
+junoui's standing rule, and a bare swatch is exactly what violates it.
+
+- **Every swatch carries an accessible name.** `aria-label="Crimson"`, not a bare
+  square. A decorative swatch beside its own visible label can be `aria-hidden`,
+  but a swatch that _is_ the information needs the name.
+- **The checked state is a glyph**, not a hue. "The chosen one looks slightly
+  different" is invisible to anyone who cannot separate the two hues — and to
+  anyone reading a screenshot. The selected option also grows a ring in the
+  active role, so there are two non-colour cues.
+- **The check itself sits on an arbitrary colour**, so it gets a light glyph with
+  a dark halo — the canvas-ink pair at glyph scale.
+- **"No colour" is a slash, not a grey.** A consumer without this paints unset as
+  a mid grey and the user cannot tell _grey_ from _none_, which is a different
+  thing to know.
+
+`role="listbox"` + `role="option"` + `aria-selected` is the contract for a
+single-choice palette. The popover, its trigger and the open/close behaviour are
+`.juno-popover`'s — this is the grid that goes inside it.

package/docs/components/tree.md

@@ -0,0 +1,112 @@
+# Tree / outliner
+
+Nested rows at arbitrary depth with disclosure, selection and a reorder handle.
+Layer stacks, file browsers, settings trees, org charts, comment threads, nested
+navigation. `.juno-list` is flat and `.juno-accordion` is single-level; this
+nests.
+
+## Web
+
+```html
+<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"><use href="…#juno-i-stack" /></svg>
+      <span class="juno-tree__label">Basemap</span>
+      <span class="juno-tree__count">3</span>
+      <span class="juno-tree__trail"><span class="juno-badge juno--nominal">ON</span></span>
+      <button class="juno-tree__handle" aria-label="Reorder Basemap"></button>
+    </div>
+    <ul class="juno-tree__group" role="group">
+      <li class="juno-tree__item" role="treeitem" aria-level="2" aria-selected="true">…</li>
+    </ul>
+  </li>
+</ul>
+```
+
+| Class / prop         | Effect                                                                   |
+| -------------------- | ------------------------------------------------------------------------ |
+| `.juno-tree`         | The `role="tree"` root. Sets `--juno-tree-indent`.                       |
+| `.juno-tree__item`   | One `role="treeitem"`. Carries `aria-expanded` / `-level` / `-selected`. |
+| `.juno-tree__group`  | A nested `role="group"`. One indent step; depth is structural.           |
+| `.juno-tree__row`    | The focusable line. Holds the tap floor.                                 |
+| `.juno-tree__caret`  | Disclosure triangle; rotates on `aria-expanded="true"`.                  |
+| `.juno-tree__count`  | Count badge slot on a group row.                                         |
+| `.juno-tree__trail`  | Trailing-control slot, as on `.juno-list__row`.                          |
+| `.juno-tree__handle` | Reorder affordance and its hit area.                                     |
+| `--juno-tree-indent` | One indent step (default `space.16`).                                    |
+
+Expansion and collapse are `aria-expanded` on the item — the app owns it, as with
+`aria-pressed` elsewhere in junoui. No JS is needed for the visuals.
+
+## The ARIA contract
+
+This is the half apps get wrong, so it is stated rather than implied.
+
+- **`role="tree"`** on the root, with an accessible name (`aria-label` or
+  `aria-labelledby`). **`role="group"`** on every nested list, **`role="treeitem"`**
+  on every item.
+- **`aria-level`** on every item, 1-based. Required: the nesting is visual, and
+  a screen reader does not infer depth from indentation.
+- **`aria-expanded`** on branches only. **Its absence is what makes an item a
+  leaf** — do not put `aria-expanded="false"` on a childless row, or it is
+  announced as a collapsed branch that never opens.
+- **`aria-selected`** for what the next action applies to. Distinct from
+  `aria-current` (which node you are _on_) and from `:hover`. A layer stack has
+  all three at once, which is why they paint differently.
+- **Roving tabindex**: exactly one row has `tabindex="0"`, the rest `-1`. One Tab
+  stop for the whole tree, not one per node.
+- **Multi-select** is `aria-multiselectable="true"` on the root plus
+  `aria-selected` on each item.
+
+### Keyboard
+
+| Key          | Action                                                          |
+| ------------ | --------------------------------------------------------------- |
+| ↓ / ↑        | Next / previous **visible** item, across levels                 |
+| →            | Closed branch: expand. Open branch: first child. Leaf: nothing. |
+| ←            | Open branch: collapse. Otherwise: parent.                       |
+| Home / End   | First / last visible item                                       |
+| Enter, Space | Select                                                          |
+| `*`          | Expand every sibling at this level                              |
+
+A tree without this is a list of buttons wearing tree roles. Because it is
+behaviour, no stylesheet can ship it — so junoui ships a stateless enhancer:
+
+```js
+import { enhanceTree } from 'junoui/tree';
+const stop = enhanceTree(document.querySelector('.juno-tree'));
+```
+
+It stores nothing: expansion and selection live on the DOM and belong to you. It
+moves focus and dispatches `juno-tree-toggle` / `juno-tree-select` (bubbling,
+cancelable, `detail.item`) — it does **not** expand, collapse, select or reorder,
+because in a real outliner expanding a node may need to load it.
+
+## Touch
+
+The row holds `--juno-size-tap-min`, which becomes the 44px comfortable target on
+a coarse pointer. The caret and the handle **paint** small so a dense tree stays
+dense, and grow only their **hit area** with a transparent overlay — a 44px
+painted caret would swallow the row it sits in.
+
+**The reorder handle is explicit, and that is not a style choice.** Long-press-drag
+is the obvious gesture and the wrong one: a tree sitting on or beside a pan/zoom
+surface has to let the pan win, and a gesture that means "reorder" here and "pan"
+one pixel to the left is a coin flip. The handle carries `touch-action: none` on
+itself alone, so dragging it never scrolls while the rest of the row still pans.
+
+## What junoui does not do
+
+Reorder **logic** — the drop calculation, the model mutation, autoscroll. junoui
+ships the affordance, its hit area, and the drop-target styling
+(`data-juno-drop="before|after|into"`, plus `data-juno-dragging`). A drop lands
+_between_ rows by default: the edge line says "between", a filled highlight says
+"into this one", and those are different operations in a tree.

package/docs/conformance-kit.md

@@ -0,0 +1,255 @@
+# The conformance kit — design
+
+> **Status:** design, for review. Nothing here is implemented except where a
+> section says "already shipped".
+> **Ticket:** 20260826-036. **Owner:** iosdev.
+
+## The problem, stated from evidence
+
+junoui is consumed by an app that then has to re-derive junoui's own facts to
+use it safely. One week of auditing a single consumer (nexora) produced this
+list, and every item is a thing the consumer had to build because the library
+did not ship it:
+
+| What the consumer built                             | Because junoui did not ship                         |
+| --------------------------------------------------- | --------------------------------------------------- |
+| `junoClasses.ts` + a class-name test                | any statement of which class names exist            |
+| a cascade resolver (`cssCascade.ts`)                | a way to ask what a property resolves to            |
+| `toppill_fit_verify.py`, `measure_mobile_chrome.py` | a way to measure a layout claim on a device profile |
+| a three-bucket `env()` discipline, in prose         | a rule for who adds the safe-area inset             |
+| `--nx-dock-clear` and the 320px arithmetic          | a published item budget                             |
+| local tap floors on four controls                   | floors on the primitives those controls imitate     |
+
+Two things make this worse than duplication.
+
+**The consumer's copy drifts, silently and in the safe direction.** The dock
+arithmetic subtracted 12px of inline padding where the pill spends 8, so every
+per-item width was ~0.8px low for months. Nothing was visibly wrong. The number
+was simply not the library's number any more.
+
+**The library's own defects survive because nobody can see them from inside.**
+`.juno-seg__option` sat in a `touch-action` list for as long as it existed; the
+shipped class is `.juno-seg__opt`. `:where()` matched nothing, the rule parsed,
+every other member kept working. One character, invisible to lint, to the
+build, and to a screenshot. `.juno-list__item` was the same defect in the same
+two lists. Both were found this week by a test written for the first one.
+
+The kit's thesis: **mobile correctness is a library concern, and the library
+should be able to prove its own claims.**
+
+## Design principles
+
+1. **A fact is published once and derived everywhere else.** If a consumer can
+   compute a number from junoui's geometry, junoui computes it and exports it.
+   `--juno-dock-edge-offset` is the shape: one declaration feeding both the
+   margin that paints and the clearance that reserves.
+2. **A name is generated, never typed twice.** Every list of junoui class names
+   inside junoui — `:where()` sets, docs tables, the manifest — comes from one
+   source. The `__option`/`__opt` class of defect stops being expressible.
+3. **A guard measures the artifact it is about.** Against the built bundle,
+   through a layout engine where used values matter, with a control proving the
+   measurement can register the defect. Stated as a rule because this kit's own
+   first test failed it: see [Anti-goals](#anti-goals).
+4. **The library ships the instrument, not just the answer.** A consumer that
+   can only read junoui's numbers still cannot check its own composition. The
+   doctor (F) exists so the answer is reproducible outside this repo.
+
+## A. Class contract shipped
+
+**Ship** `dist/classes.json`, generated by `scripts/bundle-css.mjs` from the
+selectors it already parses:
+
+```json
+{
+  "version": "0.7.0",
+  "components": {
+    "seg": { "block": "juno-seg", "elements": ["juno-seg__opt"], "modifiers": ["juno-seg--sm"] }
+  },
+  "all": ["juno-seg", "juno-seg__opt", "..."]
+}
+```
+
+**Ship** `junoui/testing`, a framework-agnostic helper:
+
+```js
+import { assertJunoClasses } from 'junoui/testing';
+assertJunoClasses(['src/**/*.tsx']); // throws listing every juno-* class no rule defines
+```
+
+Generalizes nexora's `junoClasses.ts`, which caught 11 misspelled BEM names
+that compiled silently and broke actions on phones.
+
+**Shipped**, with two revisions the implementation forced. Both came from
+running the helper against a real consumer rather than from taste.
+
+**The helper checks `all` by default, not `public`.** Measured on the 0.7.0
+build: 310 classes have rules, 277 are named anywhere in `docs/`. The 33-name
+difference is not an internals list — it is `juno-sr-only`, `juno-bg-s0`,
+`juno-hide-below-lg`, `juno-eyebrow` and friends: public utilities nobody wrote
+up. Defaulting to `public` would have failed consumers for using shipped API.
+`public` stays available as a stricter surface, and the docs gap is junoui's to
+close, tracked separately.
+
+**The claim is "junoui ships nothing by this name", not "this is not a class".**
+A consumer writes `junoPx('juno-pillbar-gap')` and `` `#juno-i-${n}` ``, and no
+regex over source text distinguishes those from a class. First run against
+nexora reported 24 names; 8 were tokens, an icon-id template and a keyframe —
+all names junoui does ship. So the manifest carries `tokens`, `keyframes` and
+`icons` alongside the classes, and component-local custom properties are read
+from the **bundle**, not only `juno-tokens.css` (that alone accounted for three
+of the eight).
+
+Final state on nexora's 133 source files: the only reports are 13 in the fixture
+file that deliberately names wrong classes, and 3 consumer-owned names.
+
+## B. Tap floors owned by the library
+
+**Already shipped**, this week, and the evidence for the rest of the section:
+`.juno-seg__opt` had no floor at all and computed 25.39px (20260826-025);
+`.juno-btn--sm` shipped a 24px target that 40 consumer call sites used to mean
+"secondary" (20260826-026).
+
+**Remaining work:**
+
+1. **Audit every interactive primitive** for a coarse-pointer floor and record
+   the result in one table, in the repo, generated by the doctor rather than
+   written by hand. Anything that cannot hold 44 states why in that table.
+2. **Generate the `touch-action` and tap-highlight `:where()` lists from the
+   class manifest.** Today they are two hand-maintained lists that had drifted
+   from the classes _and from each other_ — the tap-highlight set is a strict
+   subset of the touch-action set, and nothing says whether that is deliberate.
+   Generated, the typo class of defect cannot exist and the divergence becomes
+   a visible decision.
+
+**Shipped**, and the question is answered: **one set**, decided on the rules'
+own rationales rather than merged for tidiness. The tap-highlight rule exists so
+a UA square "never flashes past a rounded control on tap", and every name the
+shorter list omitted is a rounded tappable — `.juno-chip` and
+`.juno-pillbar__overflow` are 999px pills, `.juno-seg__opt` and
+`.juno-toggle-btn` carry `radius-3`. The omission had no stated reason and the
+rationale covers them, so it was an omission, not a decision.
+
+`src/css/touch-surfaces.mjs` declares the set; `bundle-css.mjs` emits both
+rules. `touch-action` stays out of the coarse block (a hybrid device reports a
+fine primary pointer while still taking touch input); the highlight stays in it.
+
+The guard checks the declared set against the **component sources**, not the
+manifest — the manifest is built from the bundle, and the bundle now contains
+these lists, so a misspelled member would vouch for itself there.
+
+## C. Pointer-first responsiveness
+
+**The defect:** a landscape iPhone is 844×390. It is wider than `md`, so a
+width-keyed rail serves it the desktop rail on every screen, on a device held
+in two hands. Width has never been the question.
+
+**Ship one blessed mechanism**, and use it in junoui's own CSS so it cannot be
+advisory:
+
+```css
+/* the coarse-pointer condition, stated once */
+@media (pointer: coarse) { ... }
+```
+
+CSS has no portable way to name a media query (`@custom-media` is a draft and
+junoui runs no PostCSS), so the honest form is: **junoui's CSS writes the
+literal, and the string is exported for JS**, with a test asserting the two
+agree.
+
+```js
+import { COARSE_POINTER, useCoarsePointer } from 'junoui/testing'; // name TBD
+```
+
+Key `rail--responsive`, the modal→sheet swap, and `density: auto` on it.
+
+**Open question for review:** whether the condition is `(pointer: coarse)` or
+`(pointer: coarse) and (max-height: …)`. A coarse-pointer 27" kiosk is a real
+device and wants the rail. Nexora already ships a JS-side coarse branch in
+Settings; that call site is the place to look before deciding.
+
+## D. Safe-area discipline in the library
+
+Adopt nexora's three-bucket `env()` doc verbatim — it is the clearest statement
+of this that exists in either repo, and junoui's own triage is missing its
+third bucket:
+
+| Bucket              | Rule               | Because                                                            |
+| ------------------- | ------------------ | ------------------------------------------------------------------ |
+| **edge padding**    | `max(base, env())` | content already inside the box; the inset replaces the gap         |
+| **clearance**       | `base + env()`     | the chrome's offset already contains the inset; reserve must match |
+| **floating chrome** | `base + env()`     | a floating element sits off the edge; gap and inset stack          |
+
+Then: **every floating-chrome primitive applies its own bucket** — `.juno-toast`,
+`.juno-pillbar`, `.juno-dock` — through a token the consumer can restate, which
+`--juno-dock-edge-offset` already demonstrates. Extends the xreqs filed as
+20260803-037 and 20260815-053.
+
+## E. Published budgets
+
+**Already shipped** for the dock (20260826-027): `--juno-dock-items`,
+`--juno-dock-item-inline`, `--juno-dock-fit-inline`, `--juno-dock-chrome-inline`,
+`--juno-dock-avail`, with the terms declared once and consumed by both the box
+and the sum.
+
+**Remaining:** the same treatment for `.juno-pillbar`, which publishes
+`--juno-pillbar-item/-gap/-pad` but no derived budget, so a consumer's capacity
+planner still does the division itself.
+
+**Recorded limit, so nobody re-opens it:** junoui cannot publish a _scale_
+floor. "What scale keeps a 44px target?" is `44px / item-width`, a ratio of two
+lengths, and CSS cannot divide by a length. The library publishes the two
+lengths; a consumer that must scale rather than drop compares them.
+
+## F. junoui doctor
+
+A runnable conformance probe a consumer executes against **its own** build:
+
+```sh
+npx junoui doctor --url http://localhost:5173 --profiles phone,phone-landscape
+```
+
+Checks, generalized from nexora's `toppill_fit_verify.py` and
+`measure_mobile_chrome.py`:
+
+- every element matching a `public` manifest class holds its tap floor
+- both orientations, because landscape is where the width assumption fails
+- no horizontal overflow at 320px
+- floating chrome clears the safe area, per bucket
+- a consumer class does not out-resolve a junoui declaration it did not mean to
+
+Reports as a table, exits non-zero, and prints what it did **not** cover.
+
+## Anti-goals
+
+**No advisory rules.** Anything in G that the doctor cannot check is a
+checklist item a reader will skip. Prefer fewer checks that run.
+
+**No guard that has not been shown to fail.** This kit's own first tap-target
+test passed with the fix deleted: it asserted against a showcase page, and
+something in that page already held the height, so it could not fail. Measured:
+24px off the bundle, 44px off `/showcase/buttons.html`, same markup, same
+emulation (20260826-030, cause still unidentified). Every check the doctor
+ships must be mutation-tested against a reintroduced defect before it counts.
+
+**No release gate that proves less than it claims.** `gate:consumer` reported
+GREEN twice against a consumer checkout 260 commits behind its own develop —
+the guard that would have failed did not exist on that branch (20260826-039).
+
+## Sequencing
+
+| Slice | Contents                                             | Depends on |
+| ----- | ---------------------------------------------------- | ---------- |
+| ~~1~~ | ~~A (manifest + helper)~~ — **shipped**              | —          |
+| ~~2~~ | ~~B2 (generate the `:where()` lists)~~ — **shipped** | 1          |
+| 3     | C (one pointer-first mechanism)                      | —          |
+| 4     | D (buckets + floating chrome owns its inset)         | 3          |
+| 5     | E (pillbar budget)                                   | —          |
+| 6     | F (doctor)                                           | 1, 3       |
+| 7     | G (checklist, reduced to what F checks)              | 6          |
+
+Slices 1 and 2, B1 and E-for-dock are done. 024–027 are absorbed and closed.
+
+**Review asks:** the three open questions above (A's public subset, B's two
+lists, C's condition), and whether slice 6 is worth its cost before slice 1
+lands — the doctor is the piece a consumer feels, and slices 1–5 are the pieces
+that stop the defects existing.