@lotics/ui 45.9.0 → 45.10.1

package/docs/composition.md

@@ -10,30 +10,55 @@ them produces off-system UI.
 
 ## The form comes before the treatment
 
+**If the domain already has a standard shape, that is the answer — build it.** A parcel's journey
+has looked the same in every carrier's app for twenty years: an ordered set of stages, where it is
+now, when each was stamped, and where it is stuck. A ledger, a calendar, a seating chart, a
+pipeline, a boarding pass — each is a form the reader has already learned somewhere else, and
+matching it means they arrive knowing how to read the screen.
+Go and look at how the industry does it before designing something new; a shape that is unfamiliar
+in a domain that has a familiar one is a cost paid by every user, forever, to no end.
+
+That is a licence, not a leash. **The rules in this document constrain treatment, not invention.**
+Where the job needs a component the kit does not have, build it — the catalog is where solved
+problems live, not a ceiling on what a screen may be. The bar for a new composition is that it is
+the RIGHT shape for the subject and that it obeys the language below: the kit's type ramp, colours,
+spacing and states.
+
+**Which rules bind, and which advise.** Read every rule here for what it ENCODES, because the two
+kinds are answered differently:
+
+- **A rule that prevents a known HARM binds.** A page that scrolls sideways on a phone, an act that
+  cannot be undone, a figure that is typed where it should be computed, a machine's guess rendered
+  like a person's decision, a control a keyboard cannot reach — these are settled.
+- **A rule that picks among valid FORMS advises.** Which shape fits this subject, how a set is cut,
+  what the reader sees first — the space of jobs is unbounded and the best answer is regularly one
+  no document here has named. Treat these as the accumulated experience they are, then decide.
+
+**Most of what reads as inventive is this document's FIRST rule being followed well, not escaped**:
+a set whose tabs are the stages its records pass through is not a departure from "name what the
+subject IS", it is that rule landing. Naming the subject honestly is what produces a shape nobody
+has seen; reaching for the nearest template is what produces the fiftieth register with a header.
+
 **Name what the subject IS, then reach for parts.** A set of records is a register; a thing moving
 through ordered places is a rail; work assigned to finite resources over time is a board; a
 sequence of events is a timeline; a population whose point is its deviant minority is a queue
 sorted by deviation. Getting this wrong cannot be recovered later — a register of objects that
-should have been a rail is well-typed, well-spaced, correctly aligned and still says nothing about
-order or progress, because a status column reports one word and leaves the reader to know which
-word comes after which.
+should have been a rail says nothing about order or progress, because a status column reports one
+word and leaves the reader to know which word comes after which.
 
 **A hierarchy in the DATA does not oblige a hierarchy in the UI.** A parent id, a materialized
 path, a folder column — each is a real structure, and none of them decides the screen's form. Ask
 what the reader DOES with the set: a population they walk (a chart of accounts, a bill of
-materials, a site → line → cell breakdown) is a tree or a drill; one they scan and search is a
-register, and the path becomes the row's supporting line rather than a place to travel to. The
+materials) is a tree or a drill; one they scan and search is a register, and the path becomes the
+row's supporting line rather than a place to travel to. The
 distinction is who maintains the structure. Where something else writes it — an importer, an
 integration, an agent — a drill-down makes the reader navigate a shape they did not choose and
 cannot see the whole of, while a flat register with the address on the row costs one line and
 loses nothing. Build the tree when walking it IS the task, not because the column exists.
 
-The pull toward a register is structural, not a lapse in taste: `Table`, `DetailRow`,
-`SummaryLine` and `Badge` are the most reachable things here, and they compose into something
-defensible for almost any data. That is exactly why the question has to be asked out loud. **Reuse
-first is about not duplicating primitives** — a one-off composition needs no new component, so the
-kit lacking a device is a reason to compose one from what it has, not a reason to flatten the
-subject into rows.
+**Reuse first is about not duplicating primitives** — a one-off composition needs no new component,
+so the kit lacking a device is a reason to compose one from what it has, not a reason to flatten
+the subject into rows.
 
 ## Canvas & content column
 
@@ -44,11 +69,22 @@ subject into rows.
   the same left edge as the title above it and the actions below it. Never hand-pad inside one,
   and never hand-roll one: the three surfaces disagree on the number (24 / responsive / 20) and
   only the surface knows which it is.
+  - **The responsive one is READ, never re-derived — `useDialogGutter()`, no argument.** Inside
+    a `Dialog` that is what the header, the scroll area, the footer and any pane a caller drops
+    in all call. The `Dialog` resolves `small ? 16 : 24` ONCE, off the SCREEN, and publishes it.
+    Centralising the VALUE was not enough and that mistake shipped: a `dialogGutter(small)` left
+    every band to answer `small` for itself, so the header, scroll area and footer asked
+    `useScreenSize()` while the pane inside asked `useContainerSize()` — two honest answers to
+    one question, and the run's rows sat out of line with the dialog's own title. A band that
+    measures its own box is measuring the wrong box. Outside a dialog the hook falls back to the
+    screen, the same signal a dialog uses, so the two paths cannot disagree about what "small"
+    means. The `Drawer`'s counterpart is a constant, `DRAWER_GUTTER`, because that surface's
+    number does not move.
 - **Never wrap a scroller in a padded box.** The box insets the scroller's VIEWPORT, so the list
   ends short of the surface with dead space beneath it and its last row clipped. A pinned
-  heading above a scrolling list therefore takes the
-  overlay's BARE slot and puts the gutter on the pinned part and on the scroller's
-  `contentContainerStyle`. Same for a full-bleed band, which wants no gutter at all.
+  heading above a scrolling list therefore takes the overlay's BARE slot and puts the gutter on
+  the pinned part and on the scroller's `contentContainerStyle`. Same for a full-bleed band,
+  which wants no gutter at all.
 - **Content column**: one centered column — `{ width: "100%", maxWidth, alignSelf: "center" }` —
   sized to the job, with `gap: 16` between top-level bands/cards:
 
@@ -68,17 +104,16 @@ constant rather than happening to match today.
 The offender is nearly always a row that PADDED for its own hover wash instead of bleeding it
 (`ROW_WASH_BLEED`), which pushes its content in by the bleed while everything above it stays put.
 Fix the row, then DELETE the compensators that were added around it — once the row is right they
-become double-corrections, and they are the reason the edge drifts back the next time someone
-touches it. Two exceptions are legitimate and neither needs a fix: a self-contained overlay (a
-menu, a popover) has nothing to align with, and an indent that something VISIBLE occupies — a
+become double-corrections. Two exceptions are legitimate and neither needs a fix: a
+self-contained overlay (a menu, a popover) has nothing to align with, and an indent that something VISIBLE occupies — a
 checkbox, an ordinal, an identity mark — is explained by the thing occupying it.
 
 **A row beat belongs to the PAGE, not to the row.** Collect every row primitive's height on one
 screen before calling any of them right — the kit's own defaults do not agree with each other,
-because each was picked for its own surface: `ListItem` is 64, a ruled `Table` row is 52, a
-`Button`-height control is 40. Stack three of those in one column and it reads as three rhythms,
-each defensible alone. The page picks one beat and the primitives take it (`minHeight` on the
-row, `spacing` on the table).
+each picked for its own surface: `ListItem` is 64, a ruled `Table` row is 52, a `Button`-height
+control is 40. Stack three of those in one column and it reads as three rhythms, each defensible
+alone. The page picks one beat and the primitives take it (`minHeight` on the row, `spacing` on
+the table).
 
 ## The heading ramp — one construct per altitude, no drift
 
@@ -98,25 +133,22 @@ restyle a heading level per-page.
 20px bar — a heading shouting over the pane that holds it. The CONTAINER publishes the altitude
 and one `SectionHeadingTitle` answers to it: `##` on a page, `####` inside `DrawerScrollArea` /
 `DialogScrollArea` / `ModalBody` / `PopoverContent`. Write the same heading either way; there is
-no per-surface variant to remember, which is the point — a caller who has to know what is holding
-their heading will sooner or later be wrong about it.
+no per-surface variant to remember.
 
 Three consequences worth knowing before you compose:
 
 - **A whole PAGE surface docked in an overlay keeps the page rung.** The master-detail register
   puts a full record screen in a drawer; that screen brings its own `#` identity band, carries
-  its own gutters, and therefore sits in the container's BARE slot rather than the scroll area —
-  which is exactly why the altitude is published by the scroll area. Its sections stay `##` and
-  its subsections stay `###`. Nothing to pass; put an ordinary pane body in the scroll area and
-  a page surface in the bare slot, as the gutter contract already asks.
+  its own gutters, and therefore sits in the container's BARE slot rather than the scroll area.
+  Its sections stay `##` and its subsections stay `###`. Nothing to pass; put an ordinary pane
+  body in the scroll area and a page surface in the bare slot, as the gutter contract already
+  asks.
 - **A pane you build YOURSELF declares its own altitude.** A docked side panel is not an overlay
   and uses none of those regions, but its headings must not shout across 400px either — wrap its
   content in `<HeadingAltitudeContext.Provider value="panel">` (`@lotics/ui/heading_altitude`).
-  A rule scoped to the containers the kit happens to render is an allowlist short by however many
-  panes the app builds.
 - **In a pane, `####` is the FLOOR.** `SubsectionHeadingTitle` has one altitude (`###` lg) and
   would out-rank the section holding it, so a named group inside a pane's section is
-  `Text size="sm" weight="semibold"` — a pane is one surface, not a document.
+  `Text size="sm" weight="semibold"`.
 
 Nesting never compounds: a popover opened inside a drawer is one rung down, not two.
 
@@ -126,13 +158,11 @@ Nesting never compounds: a popover opened inside a drawer is one rung down, not
   hierarchy device colour cannot substitute for. Restoring a `Text size="xxl" weight="semibold"`
   title takes the same screen to ~2.7x. It also gives the page somewhere to land: without it the
   first thing on the screen is a search input, which is chrome.
-  Yes, the title usually repeats the nav. Accept the repetition — a heading that names the screen
-  costs one line and buys the whole type range, and the alternative (inventing a title the nav
-  does not say) is worse.
-  **A second line carries LIVE STATE, never a gloss.** "Track each record's status and print the
-  right document for its stage" explains the WIDGET, and a band has no use for it. But a
-  register's counts are not that line either: they are the result of the TOOLBAR, so they belong
-  under it — see § Summaries.
+  Yes, the title usually repeats the nav. Accept the repetition — the alternative (inventing a
+  title the nav does not say) is worse.
+  **A second line carries LIVE STATE, never a gloss** explaining the WIDGET. A register's counts
+  are not that line either: they are the result of the TOOLBAR, so they belong under it — see
+  § Summaries.
   Right side: the screen's ONE primary action and/or a period filter — never a
   summary `Badge` (those belong to the KPI strip).
 - **Card header** — a card's own title band (or separate banded cards): `CardHeader` +
@@ -143,10 +173,9 @@ Nesting never compounds: a popover opened inside a drawer is one rung down, not
   lowest heading rank — and neither of the two constructs it sits between: `CardHeaderTitle`
   (`sm`) labels a CONTAINER of data, whereas here the name IS the content; `RecordSummary`'s `#`
   is a page/drawer rung, and a page rung inside a popover flattens the very altitude distinction
-  the ramp exists to keep. **The failure it prevents is measurable:** a body-size name leaves the
-  panel's subject separated from its own supporting line by WEIGHT alone, which is a separate
-  font file rather than a step, and the whole surface then measures ~1.17x — flatter than a
-  register with no page band. Its supporting line takes the rung that gives it SIBLINGS (the
+  the ramp exists to keep. A body-size name leaves the panel's subject separated from its own
+  supporting line by WEIGHT alone, which is a separate font file rather than a step, and the whole
+  surface then measures ~1.17x. Its supporting line takes the rung that gives it SIBLINGS (the
   other muted lines in the same block), which is what "one rung below" is serving; applied
   literally against that it produces a singleton treatment instead.
 - **Section title** — ONE construct: `Section` › `SectionHeading` › `SectionHeadingTitle`
@@ -156,14 +185,12 @@ Nesting never compounds: a popover opened inside a drawer is one rung down, not
   below. **The row is `flexDirection: "row"` and never wraps**, so a long control label doesn't
   drop to its own line at phone width — it holds its own width and the title's `flex: 1` gives
   up whatever is left, taking the `description` down with it. A label that repeats the heading
-  verbatim is the usual way this gets long enough to bite: duplicating the title onto the button
-  squeezes both title and description into a narrow ribbon wrapping
-  one or two words per line for eleven lines total. The button-label law already asks for
-  2–4 words; a heading-row control is the case where skipping it has a measurable width cost,
-  not just a wordier button. A COUNT earns that slot only when what it counts is not fully on screen — collapsed,
+  verbatim is the usual way this gets long enough to bite. The button-label law already asks for
+  2–4 words; a heading-row control is the case where skipping it has a measurable width cost.
+  A COUNT earns that slot only when what it counts is not fully on screen — collapsed,
   paged, or long enough that the reader would have to scan to know. Over a list or thread
-  rendered whole directly beneath its own heading it restates what is already in view, and the
-  heading reads busier for it. The page column is a **`SectionStack`** — it owns the
+  rendered whole directly beneath its own heading it restates what is already in view. The page
+  column is a **`SectionStack`** — it owns the
   between-section law (a fixed 56px beat + a bare hairline separating one section from the NEXT;
   null/false children are skipped so a conditional section never leaves a stray hairline). The
   `Divider` NEVER goes directly under a heading — that orphans the title from its own content.
@@ -173,10 +200,8 @@ Nesting never compounds: a popover opened inside a drawer is one rung down, not
   sm-semibold lead lines on a flat page, and NEVER use a bare eyebrow as a section title.
 - **Pane section title** — the FOURTH rung, taken automatically by `SectionHeadingTitle`
   inside a pane's content region. Same construct, same `icon`/`description`/`info` slots;
-  only the type size steps down, and nothing at the call site says so. It exists because
-  `DialogHeaderTitle` and a `Drawer`'s title are **lg** — the rung `SubsectionHeadingTitle`
-  occupies — so a panel holding a multi-section surface otherwise ties with, or is outranked by,
-  its own content. Compose it with the SUBSECTION layout (`Subsection` › `SubsectionHeading` ›
+  only the type size steps down, and nothing at the call site says so.
+  Compose it with the SUBSECTION layout (`Subsection` › `SubsectionHeading` ›
   this, in a `SubsectionStack`): the 12px body gap and 32px beat are already right for a panel.
   The ladder stays ABSOLUTE — this is one more fixed rung, never a `size`/`compact` knob.
 - **Subsection title** — the level BELOW a section on a long record surface: `Subsection` ›
@@ -197,11 +222,8 @@ Nesting never compounds: a popover opened inside a drawer is one rung down, not
   to its own section-level heading just to separate it.
 - **Eyebrow vs group lead — a label is one or the other, and the difference is what it
   LABELS.** Each is a COMPONENT — `@lotics/ui/eyebrow` and `@lotics/ui/group_lead` — so the call
-  site DECLARES which one it is rather than re-deriving a rung from feel, which is how a title
-  ends up whispering. They were hand-written `Text` and this section told you to keep it that
-  way; a shipped app then labelled three act-on-it blocks at the eyebrow's `xs` muted, which is
-  the failure the prose could not prevent. Neither takes a `size`, `weight` or `transform`: the
-  props a component omits are the rule it enforces.
+  site DECLARES which one it is rather than re-deriving a rung from feel. Neither takes a `size`,
+  `weight` or `transform`: the props a component omits are the rule it enforces.
 
   | | Eyebrow | Group lead |
   |---|---|---|
@@ -239,11 +261,9 @@ altitude (`SubsectionHeading`, `CardHeader`).
 
 The rule is about a position that does not MOVE. Put the add under the register it extends and
 where the reader looks for it depends on how many rows there already are — past a screenful the
-verb is off-screen, and on an empty list there is no last row to sit under, so it has to become
-a second button inside the `EmptyState`. That is one verb with two homes, neither findable
-without scanning. The heading row is the section's control line — it already carries the meta
-and the view controls — so the add belongs on it, in the same spot whether the section holds
-nought or forty.
+verb is off-screen, and on an empty list there is no last row to sit under. The heading row is the
+section's control line — it already carries the meta and the view controls — so the add belongs on
+it, in the same spot whether the section holds nought or forty.
 
 **When the row runs out of width, the VERB wraps — the title never gives way.** The title names
 the section; the verb is the thing that can move. Getting this backwards is easy to ship because
@@ -251,12 +271,10 @@ RN-Web resolves `flex: 1` to `flex-basis: 0%` with `min-width: 0`, so a title be
 holds its intrinsic width is the half that collapses, and at phone width the heading breaks one
 word per line beside an untouched button. `SectionHeading` and `SubsectionHeading` wrap and floor
 their title column for this; do not add a second `flex: 1` spacer beside a title that already has
-one, which halves its share again and is how a badge came to land on top of a section title.
+one, which halves its share again.
 
 **Where there IS no heading row, the add has nowhere else to be, so it rides the surface's own
-bar** — an attachment popover, a dialog body, any self-contained widget. That is not an exception
-to the law so much as the same reasoning: the rule exists so the verb sits in ONE place a reader
-can return to, and on a surface with no heading the bar IS that place. `FilesEditorUpload` is for
+bar** — an attachment popover, a dialog body, any self-contained widget. `FilesEditorUpload` is for
 exactly this case; inside a section the host puts its own `Button` on the heading instead, because
 `FilesEditor` provides the context and the heading is outside it — and a file widget rendering a
 `SectionHeading` would own something the section owns. Worked both ways in `tpl_record` (Files,
@@ -264,19 +282,15 @@ Photos) and `tpl_task_board` (the attachment popover).
 
 **A header CHECKBOX is legible only when it heads a COLUMN.** A table's select-all works because
 it sits at the same x as every row's box beneath it — the column is what turns a 24px tick into
-"all of these". A grid has no such column, so the same control in a section heading heads
-nothing: it is a transparent 24×24 at radius 6 standing between 40px grounded buttons at radius
-10, off their baseline, differing on every axis at once, and shape is read before meaning. **A
+"all of these". A grid has no such column, so the same control in a section heading heads nothing. **A
 grid's select-all is a BUTTON** ("Select all" / "Deselect all"), which is what
 `FilesEditorSelectAll` ships. Nothing is lost by giving up the tri-state: `indeterminate` says
-"some", and the `FloatingActionBar` beside it already says WHICH some as an exact count — the
-glyph was approximating a number that was on screen.
+"some", and the `FloatingActionBar` beside it already says WHICH some as an exact count.
 
 While a mode is ON, the heading row holds only that mode's controls; the section's own ADD stands
 down until it is off. Otherwise a `primary` add sits in a row that is entirely about the
 selection, competing with the promoted act in the action bar — two accents on one screen. At rest
-the add returns to the right edge where the law puts it, and drag/paste never stopped working, so
-no path actually closes.
+the add returns to the right edge where the law puts it, and drag/paste keep working throughout.
 
 - **Weight is the section's**, not a hedge: a section's add is the act that section offers, so
   `primary`. Don't drop to `secondary` because the list is full — an add that changes weight
@@ -295,9 +309,9 @@ screen already computes, and it is the copy that goes stale — the band re-coun
 and the string does not.
 
 It also decides where the count may live. A register whose bands already state their sizes must
-not carry a strip of chips above it repeating the same three numbers; that is one fact twice, and
-the reader learns to skip the strip. And a count is a reason to PRESS — a control that states how
-many rows are behind it and does not filter to them is stating a fact it refuses to act on.
+not carry a strip of chips above it repeating the same three numbers; that is one fact twice. And
+a count is a reason to PRESS — a control that states how many rows are behind it and does not
+filter to them is stating a fact it refuses to act on.
 
 ## Period filters for time-constrained data
 
@@ -351,17 +365,16 @@ by WHAT THE SURFACE IS; never a raw `Pressable`.**
 
 | Surface | Examples | Resting signature | Hover | Base |
 |---|---|---|---|---|
-| Fields (type into / pick from) | `TextInputField`, `Picker`, `Select`, `Combobox`'s input, `NumberInput`, the date/time fields, `DateRangeFilterField`, the inline editors (`InlineSelect`/`InlineDatePicker`) | a BORDER | darkens the border to `HOVER_BORDER` (zinc-400); a borderless in-cell field REVEALS one | `FocusRingPressable` |
+| Fields (type into / pick from) | `TextInputField`, `Picker`, `Select`, `Combobox`'s input, `NumberInput`, the date/time fields, `DateRangeFilterField`, the inline editors (`InlineSelect`/`InlineDatePicker`) | a BORDER | darkens the border to `HOVER_BORDER` (zinc-500); a borderless in-cell field REVEALS one | `FocusRingPressable` |
 | Actions | `Button`, `IconButton` | a FILL | darkens the fill (own color logic) — never a border, never a wash | built-in |
 | Pills / toggles | `Chip`/`ChipGroup`/`FilterChip` (via `chipSurfaceStyle`), `SegmentedControl`, `Tabs`, `Switcher`, `RadioPicker` | a pill SURFACE | washes it (white → zinc-100; pressed zinc-200); selected adds a ring/fill | `chipSurfaceStyle` |
 | Surfaces | `PressableRow`, `MenuButton`, list/menu items, `CardSelectItem`, `Accordion` headers | a row/card SURFACE | washes it — the grey wash IS the affordance | `PressableHighlight` |
 
 **ONE signal per species, and it has to be strong enough to carry alone.** `HOVER_BORDER` is
-zinc-500, not 400, because at 400 the shift was zinc-200 → zinc-400 on a 1px line — measurably a
-change and visually almost nothing, so the inline editors had grown a background TINT on top to
-compensate. That left two hover languages in one kit, and a reader crossing a record surface met
-both. Strengthen the shared signal rather than letting one control add a second; a control wearing
-two is the tell that the first one is too weak for everybody.
+zinc-500, not 400: at 400 the shift is zinc-200 → zinc-400 on a 1px line — measurably a change and
+visually almost nothing, so a control grows a background TINT on top to compensate and the kit ends
+up with two hover languages. Strengthen the shared signal rather than letting one control add a
+second.
 
 **A themeable control derives EVERY state from its token — rest, hover, press, disabled.** The
 failure is a control that resolves `colors.primary` correctly at rest and then paints a fixed
@@ -369,39 +382,35 @@ neighbouring zinc the moment it is touched, so a branded button turns grey under
 for an OPAQUE overlay especially: a `backgroundImage` gradient drawn over a themed
 `backgroundColor` hides it entirely while every token in the source reads correct. On web a token
 is a `var()`, so "the same colour, lighter" cannot be computed at the call site — use a translucent
-white/black overlay, which lifts any hue and cannot go stale against a palette it does not know.
+white/black overlay.
 
 **A control changes PAINT across its states and never GEOMETRY** — and every property it paints
 has exactly ONE owner. Text that shifts on focus, a border that thickens, a ring drawn twice, a
 tint applied on one path only: each is two pieces of code owning one property and happening to
-agree at rest. It survives review because a resting screen is what gets looked at, and the second
-owner only speaks when the control is touched. The fix is to give the property one owner — a
-shared surface helper, a single frame kept across the view→edit swap — never to nudge the second
-owner into agreeing with the first, which leaves both in place for the next person to re-break.
+agree at rest. The fix is to give the property one owner — a shared surface helper, a single frame
+kept across the view→edit swap — never to nudge the second owner into agreeing with the first.
 
 **A control riding a hoverable surface must be DARKER than that surface** — and you have to hover
 BOTH to see whether it is, because reaching the control means crossing its host. Equal washes
 vanish at exactly the moment they are pointed at; a control LIGHTER than its host reads as a hole
-punched in the row rather than as a target sitting on it. Neither failure is visible at rest, and
-neither is visible hovering the control alone, which is why a control that measures perfectly can
-still disappear in use. Take `ROW_CONTROL_HOVER` / `ROW_CONTROL_PRESS` (`control_surface`), which are a step past the
-row's own wash for exactly this reason; a hand-picked grey chosen against the resting row is the
-finding however plausible the value looks.
+punched in the row rather than as a target sitting on it. Neither failure is visible at rest, nor
+hovering the control alone. Take `ROW_CONTROL_HOVER` / `ROW_CONTROL_PRESS` (`control_surface`),
+which are a step past the row's own wash for exactly this reason; a hand-picked grey chosen against
+the resting row is the finding.
 
-**A SELECTED control needs a GROUND, not a heavier outline.** Among white pills a 1px border change
-is noise — it is the same signal hover already spends, one step stronger, so selection and hover
-compete instead of reading as different things. Selection changes what the box IS (a fill, a wash);
-hover changes how intensely it says it.
+**A SELECTED control needs a DOUBLED dark EDGE, not a one-pixel border change.** Among white pills
+a 1px change is the same signal hover already spends, one step stronger, so selection and hover
+compete; `chipSurfaceStyle` doubles `zinc-900` with a `boxShadow` instead, which survives the hover
+wash rather than being replaced by it. A ROW is the other altitude and takes a GROUND — see
+§ Where the accent goes.
 
 For fields: layer the hover-border AFTER `style` so it wins over the caller's resting edge, put the
 open ring (`FOCUS_RING`) on the open state, and **a field NEVER greys its content**. That ordering
-is load-bearing rather than tidy: a caller's resting `borderColor` is exactly how a frameless
-variant gets expressed, and layered the other way it erases the hover edge that is such a field's
-ONLY affordance — a control that then draws nothing in either state and is simply never pressed.
+is load-bearing: a caller's resting `borderColor` is exactly how a frameless variant gets expressed,
+and layered the other way it erases the hover edge that is such a field's ONLY affordance.
 Give the field a variant PROP for its resting frame instead of taking one through `style`. The bug this
 grammar prevents: a FIELD built on `PressableHighlight` inherits the wash AND its own border — it
-greys *and* animates its edge while its siblings only border-hover. Reach for `PressableHighlight`
-on a bordered/input control and you've made it.
+greys *and* animates its edge while its siblings only border-hover.
 
 ## Cards — banded and composable
 
@@ -444,12 +453,11 @@ objects — hairlines between them blur into one run-on list.
 
 **A summary goes BELOW the controls that produce it.** Its figures are the result of the toolbar —
 they move every time the reader touches a filter — so the layout has to state that order: set the
-query, then read what it returned. Above the toolbar the screen answers before it has been asked,
-and the numbers change behind the reader's eye while they are still choosing.
+query, then read what it returned.
 
-It is not the page band's subtitle either, for the same reason. A subtitle describes the SCREEN,
-which does not change; these describe the QUERY, which the toolbar just rewrote. The band carries
-the title, and the summary sits under the controls, immediately above the rows it counts.
+It is not the page band's subtitle either. A subtitle describes the SCREEN, which does not change;
+these describe the QUERY, which the toolbar just rewrote. The band carries the title, and the
+summary sits under the controls, immediately above the rows it counts.
 
 `SummaryLine` is `Summary`'s `Facts` row on its own — reach for the compound when the set has a
 distribution worth drawing, and for the bare line when it is only a few aggregates. A
@@ -523,45 +531,42 @@ SECTION** is this same family with the heading rung composed inside it — `Sect
 collapsible section composes identically on both surfaces. There is no separate collapsible-section
 component: one heading family and one disclosure across static + collapsible. The disclosure
 header IS the section heading — name it for what it hides, never a generic bucket ("Advanced",
-"More", "Options") wrapped around one named section: that stacks two titles of the same rank and
-leaves the reader no reason to open the chevron.
+"More", "Options") wrapped around one named section.
 
 ### A control's resting treatment promises what pressing it does
 
-Both halves of that fail in practice, and they fail in opposite directions.
-
 **A control that looks like text.** A press target whose resting state is a muted caption is
-announced to a screen reader, revealed on hover, and invisible to everyone else — including the
-reader who navigates by eye, which is most of them. Hover is not an affordance; it is a
-confirmation of one. If pressing it navigates, it wears navigation ink at rest: default colour,
-`medium`, underlined.
-
-**Text that looks like a control.** The mirror mistake, and the more annoying one, because the
-reader presses and nothing happens — or something happens that was not what the ink promised. A
-figure that opens a PEEK is not navigating and must not wear the ink of something that leaves;
-identity marks and captions that go nowhere stay `muted`, regular, unruled.
-
-So the two states of one element are treated DIFFERENTLY on purpose, and the difference is the
-whole point. Rendering them the same is not neutrality — it is the promise being made to nobody, or
-to everybody, and both are wrong. When a component takes an optional handler, its resting
-appearance changes with the handler, never only its `accessibilityRole`.
-
-The failure is invisible to a test that asserts the role, which is why it survives: the role is
+announced to a screen reader, revealed on hover, and invisible to everyone else. Hover is not an
+affordance; it is a confirmation of one. If pressing it navigates, it wears navigation ink at rest:
+default colour, `medium`, underlined.
+
+**Text that looks like a control.** The mirror mistake: the reader presses and nothing happens — or
+something happens that was not what the ink promised. A figure that opens a PEEK is not navigating
+and must not wear the ink of something that leaves; identity marks and captions that go nowhere
+stay `muted`, regular, unruled.
+
+When a component takes an optional handler, its resting appearance changes with the handler, never
+only its `accessibilityRole`. The failure is invisible to a test that asserts the role: the role is
 what the element IS, and this rule is about what it LOOKS LIKE.
 
 ## No dead rows — registers & tables
 
 **The identifier leads.** A register's FIRST column is the thing the reader came to find the row
 by — its key, code, or id — because that is what they are scanning against a document, an email,
-or someone on the phone. Pushing it right of a name or a status makes every lookup a hunt across
-the row, and no other column can take its place: a name repeats, a status is shared by dozens.
+or someone on the phone. No other column can take its place: a name repeats, a status is shared by
+dozens.
 
 Every listed record is actionable. PRIMARY entity rows press-open the workspace `Drawer`
 (sequenced — see [master-detail](#master-detail--list--workspace-drawer-with-sequencing));
 read-only drill-downs expand via `Accordion` or glance via `Peek`; every other row gets an
 `ActionMenu` (⋯ → `MenuButton` items: destructive last + **confirmed** via `Alert`). The whole
 surface is the door: register rows are `PressableRow` (full-bleed wash including nested controls),
-Divider-separated.
+separated by a 4px gap and nothing else.
+
+**How MUCH the row reveals decides expand-vs-drawer.** An expanding row is for a few facts the
+reader takes in without losing their place — the rows around it stay visible. Once the reveal is a
+screenful, it pushes the rest of the register off the fold. That is a `Drawer`. The threshold is
+not a row count, it is whether the neighbouring rows survive the expansion.
 
 | `PressableRow` variant | Shape | Use |
 |---|---|---|
@@ -582,36 +587,33 @@ STATE (the count and Clear — what is picked, and how to un-pick it) from the A
 (`children`) with the section boundary getting the most air (20) and each group sitting on the
 action gap (8). Spaced uniformly, four controls read as four equal things, and the emphasis
 ladder between them — muted for a dismiss, `danger` for a destructive act, `primary` for the
-promoted one — stops reading as a ladder and starts reading as arbitrary variety. The colours
-are not the defect when this happens; the spacing is. Group first, and the ladder is then read
-WITHIN the acts, where it means something.
+promoted one — stops reading as a ladder. The colours are not the defect when this happens; the
+spacing is. Group first, and the ladder is then read WITHIN the acts, where it means something.
 
-The grouping pays a second time at PHONE width, which is why it is structure and not styling. A
-count plus an escape plus three verbs is ~520px of content — wider than a 375 screen — so the
-bar wraps; because `state` and `acts` are each a nowrap row, the ONLY break available is the
-boundary between them. The line splits exactly where the meaning does (what is picked / what to
-do with it) instead of orphaning one verb from the ladder it belongs to. A row of five peers has
-no such seam and breaks wherever it runs out of room.
+The grouping pays a second time at PHONE width. A count plus an escape plus three verbs is ~520px
+of content — wider than a 375 screen — so the bar wraps; because `state` and `acts` are each a
+nowrap row, the ONLY break available is the boundary between them, so the line splits exactly
+where the meaning does instead of orphaning one verb from the ladder it belongs to.
 
 **Two exceptions, both real.** A self-contained OVERLAY — a menu, a selector's popover
 (`MenuListItem`, `OptionList`) — has nothing outside itself to align with, so its rows keep
 plain padding; bleeding there would push them past the popover's own edge. And a slot that
-holds another component's PART takes that component's constant, never a hand-picked number:
-`AgentRun`'s dot column was 18 while the `Marker` it holds is `NODE` (24), so a 24px dot
-centred in an 18px column put the whole run rail 3px outside the surface's edge — every row
-wrong by the same amount, so it read as internally consistent and nothing flagged it.
+holds another component's PART takes that component's constant, never a hand-picked number.
 
 **An indent is legible only when something VISIBLE occupies it**
 — a checkbox, an ordinal, a diff mark. An empty one is a defect, and the
 compensation it forces spreads to every new surface that sits beside it.
 
-The `Divider` BETWEEN rows is the resting separation; the wash is the hover state. `selected`
-shows a zinc-100 highlight; `marked` (a bulk-ticked row) a resting blue-50 tint.
+NOTHING is drawn between rows — a `Table` spaces them by 4px, and the wash is the only mark a
+row makes. `selected` shows a zinc-100 highlight; `marked` (a bulk-ticked row) shows the SAME
+ground, because what tells a ticked row from an open one is the ticked checkbox.
 
 **The COLUMNAR register is `Table`/`TableRow`/`TableCell`**: define `columns` once — the header
-band + every row's cell widths derive from it and can't drift. ONE hairline under the header; the
-rows below it Divider-separated. A sortable column shows its `SortHeader` glyph ALWAYS (a neutral
-up/down glyph when unsorted) so it reads as sortable; pressing cycles none → asc → desc → none.
+band + every row's cell widths derive from it and can't drift. ONE hairline, under the header —
+it divides CHROME from CONTENT, which whitespace cannot say; a rule between two ROWS would divide
+like from like, so the rows below carry none. A sortable column shows its `SortHeader` glyph
+ALWAYS (a neutral up/down glyph when unsorted) so it reads as sortable; pressing cycles none →
+asc → desc → none.
 A `TableRow` with no `onPress` renders a STATIC read-only row (no hover wash) —
 so `Table` also serves read-only tabular data (a fee breakdown, a spec sheet), not just interactive
 registers. A pressable `TableRow` REQUIRES `accessibilityLabel` ("Open …") — its keyboard door is
@@ -624,12 +626,11 @@ Uniform ROW heights hide it completely — the rows measure identical, the conte
 not — and the drift is against the row's own centred chrome (ordinal, checkbox) as much as
 against the neighbouring columns.
 
-**It takes a height FLOOR to bite**, which is the part worth understanding rather than
-memorising. A `TableRow` with `minHeight` above its tallest cell holds slack that centring then
-distributes; without the floor the tallest cell sets the row, every cell starts at the top of its
-own row, and nothing drifts. So the cell that IS tallest may vary freely — it just makes the rows
-ragged instead, which is a different and far more visible problem. It is the cells living inside
-another cell's slack that have to hold still.
+**It takes a height FLOOR to bite.** A `TableRow` with `minHeight` above its tallest cell holds
+slack that centring then distributes; without the floor the tallest cell sets the row, every cell
+starts at the top of its own row, and nothing drifts. So the cell that IS tallest may vary freely —
+it just makes the rows ragged instead. It is the cells living inside another cell's slack that have
+to hold still.
 
 **"Fixed" means the same every row, NOT one line.** A two-line cell is fine if it is two lines on
 every row. And the cost is real: bounding a cell usually means `numberOfLines={1}` and
@@ -641,27 +642,24 @@ content off the register entirely.
 ornament sits beside a text block and centres on it — a `Timeline`'s disc, a marker, an avatar,
 a rail glyph — the ornament's position is a function of the text's height, so an unbounded text
 block moves it. A feed is where this actually bites, because a feed is the one row primitive
-whose text is written by the USER. Bound the text; the row keeps
-its beat and the ornament keeps its line. Where the full value still has to be readable, the row
-EXPANDS to it — a truncation and its source, not a second copy.
+whose text is written by the USER. Bound the text. Where the full value still has to be readable,
+the row EXPANDS to it — a truncation and its source, not a second copy.
 
 **Bounding the text is half the fix; the other half is aligning to the LINE, not the block.** A
 clamp turns an 80px drift into a 10px one — it does not remove it, because a two-line label
 still centres its ornaments half a line low while the one-line rows beside it do not. So pin
 every ornament in the band to the first line's centre, from ONE constant the row derives (see
 `FIRST_LINE_CENTRE` in `timeline.tsx`, the reference): the mark, the affordance, and whatever a
-caller passes as trailing content all read it, and a wrapped row lines up with an unwrapped one.
-Two consequences worth stating, because both look like unrelated tidying: a height FLOOR above
-the content is what created the slack being distributed, so deriving the touch target from
-`padding + line` instead removes the drift and the second source of truth in one move; and an
-ornament OUTSIDE the row's padding needs its own box, since it does not inherit that offset.
+caller passes as trailing content all read it. Two consequences: a height FLOOR above the content
+is what created the slack being distributed, so deriving the touch target from `padding + line`
+instead removes the drift and the second source of truth in one move; and an ornament OUTSIDE the
+row's padding needs its own box, since it does not inherit that offset.
 
 The way it gets in is a SLOT. A component that takes a caller's string or node cannot assume
-anything about it, and every fixture the component was built against is tidy, so the defect is
-invisible until it ships. Bound the slot in the component — not in a prop the next caller can
-re-open.
+anything about it, and every fixture it was built against is tidy, so the defect is invisible until
+it ships. Bound the slot in the component — not in a prop the next caller can re-open.
 
-Two corollaries, both counter-intuitive enough to state:
+Two corollaries:
 
 - **Shrinking a NEIGHBOURING cell does not fix it.** The spread is a function of the varying
   cell's own range, not of the row's height: a 20/42 cell spreads 11px in a 52px row and 11px in
@@ -679,13 +677,16 @@ freely when something FIXED occupies its top — a meter, a thumbnail — becaus
 then still lands near the row's centre, where the chrome already is. `tpl_item_list`'s identity
 cell is the worked example: name on top, the supporting values UNCONDITIONALLY beneath.
 
-**A pressable CELL wears `ROW_CONTROL_HOVER` / `ROW_CONTROL_PRESS`, never a hand-picked grey.**
-Reaching a cell means crossing its row, so both wash at once — a cell painting the row's own
-`zinc-100` vanishes under the pointer, and anything LIGHTER reads as a hole punched in the row.
-The tokens are one step darker for exactly that reason, and they are what `IconButton`,
-`CopyButton` and `CommentsButton` already paint, so a register whose cells use them speaks one
-hover language. Bleed the wash outward (`marginHorizontal: -8` against its own padding) so the
-cell's content stays on the column's edge — see `ROW_WASH_BLEED`.
+**A pressable CELL wears `ROW_CONTROL_HOVER` / `ROW_CONTROL_PRESS`, never a hand-picked grey** —
+they are what `IconButton`, `CopyButton` and `CommentsButton` already paint, so a register whose
+cells use them speaks one hover language. Bleed the wash outward (`marginHorizontal: -8` against
+its own padding) so the cell's content stays on the column's edge — see `ROW_WASH_BLEED`.
+
+**A pressable cell's target is the whole CELL, not the text inside it.** Bind the press and the
+hover to the cell box, so the reader aims at a column rather than at a word. Wrapping only the name
+leaves a target whose shape changes with the length of the value, and whose wash stops short of the
+cell's edges. If a cell holds an image and a name and pressing it opens the same thing, the image is
+part of the target too.
 
 **Size a flexible column by what it CARRIES, measured.** A `flex` share is a claim about content;
 when the content shrinks — a value moves to the record, a stacked pair becomes a count — the
@@ -696,20 +697,17 @@ instrument once its track is long enough to be a rule across the row.
 
 **The FIXED columns' widths are the flexible one's budget — so audit them by what they CARRY,
 not by what they are called.** With one `flex` column among N fixed, every pixel a fixed column
-takes comes out of the flexible one, silently and with no measurement pointing at the culprit:
-the symptom appears somewhere else entirely, as truncated content in the column that was
-supposed to have room. The usual offender is a column sized by its HEADER over single-character
-data — a long label above a column of one-digit counts reserves width for a word nobody reads
-twice, and the register's identity column pays for it. Measure the header row's cells and the
-widest CELL content per column; where a column's width is set by its label rather than its
-values, that difference is the identity column's, not its own.
+takes comes out of the flexible one, silently: the symptom appears somewhere else entirely, as
+truncated content in the column that was supposed to have room. The usual offender is a column
+sized by its HEADER over single-character data. Measure the header row's cells and the widest CELL
+content per column; where a column's width is set by its label rather than its values, that
+difference is the identity column's, not its own.
 
 **Space by the RATIO of within-group to between-group, never by absolutes.** Collect the gap
 inside a composed band and the gap between that band and its neighbours, and divide. Near 1 is
-the defect however sensible each number is alone — at 14 inside against 16 between, a headline,
-a chart and a register read as one undifferentiated stack, because nothing on the screen is
-grouped. Aim for roughly 2 or more, and change the BETWEEN gap first: tightening the inside
-crowds the group to buy separation the page should have provided.
+the defect however sensible each number is alone. Aim for roughly 2 or more, and change the
+BETWEEN gap first: tightening the inside crowds the group to buy separation the page should have
+provided.
 
 Make a register SELECTABLE with the `Table` `leading` gutter + `selectAll` slot — a
 `CheckboxInput` per `TableRow` (its `leading` slot) + a select-all in the header band, the ticked
@@ -721,29 +719,25 @@ only the selectable ids to `setAll`/`allSelected`/`indeterminate` (a non-selecta
 disabled checkbox, keeping the gutter aligned). Selection persists across pages, so `count` is the
 running total. `tpl_item_list` is the reference. Paginate OUTSIDE (slice + `Pagination`).
 
-**A paginated register owes the reader a scroll reset, and it is not the pager's to give.** Putting
-the pager under the rows is inherited from full page loads, where the browser reset the scroll for
-free; an SPA swaps the rows under a viewport that does not move, so paging from the bottom lands on
-the LAST rows of the next page with its first ones already scrolled past. Every control that changes
-WHICH rows are on screen owes the same reset — page, tab, search, sort, each filter — so route them
-all through ONE function that moves the window and scrolls (`goToPage` / `resetPaging` in
-`tpl_item_list`), never a `setPage(0)` at each call site that also has to remember to scroll.
+**A paginated register owes the reader a scroll reset, and it is not the pager's to give.** An SPA
+swaps the rows under a viewport that does not move, so paging from the bottom lands on the LAST rows
+of the next page with its first ones already scrolled past. Every control that changes WHICH rows
+are on screen owes the same reset — page, tab, search, sort, each filter — so route them all through
+ONE function that moves the window and scrolls (`goToPage` / `resetPaging` in `tpl_item_list`),
+never a `setPage(0)` at each call site that also has to remember to scroll.
 
 **ONE pager, ABOVE the rows.** Once the reset returns the viewport to the top on every press, the
 top is where the reader's cursor already is. A second copy under the rows is the same state said
-twice, and two identical clusters of arrows read as two controls.
+twice.
 
 **Put it on the `SummaryLine` row, not a row of its own** — summary at `flex: 1`, pager sized to its
 content, the row aligned `flex-start` so the arrows stay on the summary's FIRST line when it wraps.
 Both describe the window the toolbar just set (what matched, and which slice is on screen), so they
-are one line. A pager given its own row is a small cluster against a mostly empty band — measure it
-before believing the row is needed; a four-item summary and a full pager leave a quarter of a
-1000px band spare.
+are one line. A pager given its own row is a small cluster against a mostly empty band.
 
 Never hand `Pagination` the full width with an empty left slot. It gives its range `flex: 1` so a
 band whose left slot HOLDS something pushes the arrows to the far edge; with nothing there, that
-same rule strands the range hundreds of pixels from the arrows it belongs to — two halves of one
-control reading as two unrelated things on a line.
+same rule strands the range hundreds of pixels from the arrows it belongs to.
 
 **The pager's range IS the register's count** (`16–30 of 45`), so pair it with `Table` `counted`,
 never `count` — the latter prints the matched total again a few rows below, and one number in two
@@ -752,8 +746,7 @@ places is two numbers that can disagree. Row totals beside the pager go the same
 
 There is deliberately no page index. `Page 2 of 3` beside `16–30 of 45` answers the same question a
 second way and enables no decision the range does not — how much is left is in the total, whether
-this is the end is in the disabled arrow. A control that is reached for rarely (a register built
-around search and filters is meant to be NARROWED, not paged) earns one label, not two.
+this is the end is in the disabled arrow.
 
 Right-hand columns align only if every trailing element is FIXED-width — give each trailing action
 a fixed `width`, so amount/status columns don't jitter.
@@ -781,9 +774,7 @@ non-interactive by construction. `TableRow` already composes `PressDoor`.
 chevron belongs to the row's button; the slot beside it does not, and if the two are spaced like
 siblings the eye reads one cluster. Put clearly
 more space BETWEEN the groups than inside one (2:1 is enough) and the pair separates without a
-divider, a weight change or any new element. It is the ordinary grouping rule — one uniform gap
-makes every child a peer — applied to a row's right edge, where it is easy to miss because both
-items are small grey glyphs sitting on the same line.
+divider, a weight change or any new element.
 
 **"Non-interactive by construction" excludes any SLOT.** A trailing `right` / `actions` / `meta`
 prop takes whatever the caller passes, so a row that wraps one in its own press surface is a
@@ -800,13 +791,11 @@ so it's still keyboard-reachable. Do that locally — there is deliberately no s
 primitive.
 
 **A row is a button wrapped around DATA, so its text stays SELECTABLE and a drag is not a press.**
-The surface carries no blanket `userSelect: "none"` — that made a customer's own name and number
-undraggable, which is the one way anybody gets a value out of a table, and it bought nothing the
-furniture wasn't already buying for itself (`Badge`, `Avatar`, `Button` each opt out). Both press
+The surface carries no blanket `userSelect: "none"` — text a reader drags out of a table is the one
+way anybody gets a value out of it (`Badge`, `Avatar`, `Button` each opt out). Both press
 surfaces consult `pressSelectedText()` instead, so a release that ENDED a selection doesn't also
 open the record and throw that selection away. Only a real, non-empty selection suppresses: a
-swallowed ordinary click would leave the row impossible to open, which is a worse bug than the one
-this fixes.
+swallowed ordinary click would leave the row impossible to open.
 
 Selection covers every value at once, so reach for **`CopyButton`** only where one value is copied
 often enough to earn a control (a phone number a rep dials, a reference quoted into a message) —
@@ -833,34 +822,29 @@ Identity is the handful of facts someone would say aloud to name this record (it
 counterparty, usually two); everything else is an ATTRIBUTE and belongs below the answer the
 reader opened the record for. Get the size wrong and the position becomes unwinnable: eight
 labelled header fields push the ledger under the fold, and moving the block to the bottom to fix
-that leaves a reader who cannot tell whose record they are in. Both orders measure perfectly, so
-neither is caught by any check that reads the rendered screen. **When a leading block buries the
+that leaves a reader who cannot tell whose record they are in. **When a leading block buries the
 answer, shrink it — do not move it**; frequency of EDIT is not the axis, because a rarely-edited
 fact can still be the one that names the thing.
 
 "The chrome already carries identity, so the body need not lead with it" is a real argument and a
 falsifiable one — verify it FACT BY FACT before relying on it. A summary strip showing the record
-number and its totals carries half an identity; the counterparty is missing, and half is what
-makes the claim feel true while the reader still cannot name what they are looking at.
+number and its totals carries half an identity; the counterparty is missing.
 
 **All of the above is the LIST SCREEN.** A CHILD COLLECTION inside a record page — fees, lines,
 stops, containers — does the opposite: the row **EXPANDS** (`TableRow` `detail` + `expanded`),
 never docks a drawer. A drawer's whole job is to supply a context the reader is missing, and on a
-record page they are already in it: docking one charges a navigation to see nine fields, takes the
-sibling rows away while they read, and charges again to come back. `expanded` is CONTROLLED, so
-pick the rule — for a ledger it is ONE at a time, because two open details push the next row off
-screen and a register that cannot be scanned has stopped being one. The boundary is the detail's
+record page they are already in it. `expanded` is CONTROLLED, so pick the rule — for a ledger it is
+ONE at a time, because two open details push the next row off screen. The boundary is the detail's
 weight, not its field count: read or light-edit (independent inline commits) expands, a real form
 with a submit and cross-field validation still earns its own surface.
 
 The expansion carries **EVERY** field, including the ones already in columns. Column cells are
 read-only, and `table_fit` tier 2 drops droppable columns on the explicit promise that a door
-reaches the dropped values — the expansion IS that door, so anything it omits is unreachable
-rather than merely inconvenient. `Table` does not expose its fit result, so this cannot be
-conditional. This is also the answer to "just add more columns": the fit budget is the MEASURED
-container, so past it the register drops columns silently instead of overflowing — widening does
-not reveal the extra fields, it hides them without saying so. And free text (a note) has no column
-width at any measure.
+reaches the dropped values — the expansion IS that door, so anything it omits is unreachable.
+`Table` does not expose its fit result, so this cannot be conditional. This is also the answer to
+"just add more columns": the fit budget is the MEASURED container, so past it the register drops
+columns silently instead of overflowing. And free text (a note) has no column width at any
+measure.
 
 ## Two work shapes, no side panels
 
@@ -902,12 +886,11 @@ All view controls are 40px tall (`CONTROL_HEIGHT`), `sm` labels, in ONE wrapping
 content is TEXT: a line is ~20, so `minHeight` governs and the padding never binds — which is
 why a surface can pick any inset it likes and nothing on a resting screen ever contradicts it.
 The moment something with a FIXED height goes in — an avatar, a swatch, a thumbnail — that
-inset decides the control's whole height, and three surfaces that had each chosen their own
-(4, 6, 8) rendered one member chip at 46, 50 and 54. So: a fixed-height child is sized against
+inset decides the control's whole height. So: a fixed-height child is sized against
 the band's budget, never against how it looks alone, and a surface that needs more room than
 the budget is not a control. The budget is 28 because that is what `InlineButton` and a `md`
-`IconButton` were already using inside a field — a control's children must not differ in height
-by what KIND of thing they are, so an avatar takes the same number rather than a fourth one.
+`IconButton` use inside a field — a control's children must not differ in height
+by what KIND of thing they are.
 
 - **`SearchInput`** is THE search box — a white `TextInputField` preset (the shared
   `CONTROL_RADIUS` like every other input, a thin border, the leading search glyph + a clear ✕).
@@ -945,8 +928,8 @@ by what KIND of thing they are, so an avatar takes the same number rather than a
 - **A form's COMMIT sits with its fields, never in the footer.** The button submitting a set of
   inputs goes directly beneath the last one it commits, `alignSelf="flex-start"` — the same left
   edge the user just filled (data_entry.md's form-action alignment law, which holds inside an
-  overlay too). A footer commit is separated from what it commits by the width of the surface and
-  reads as belonging to the dialog rather than the fields. A **`Reset` travels with the `Save` it
+  overlay too). A footer commit reads as belonging to the dialog rather than the fields.
+  A **`Reset` travels with the `Save` it
   undoes** — same draft, same row, secondary to the commit's left; splitting the pair across two
   surfaces breaks one decision in half. A dialog whose only actions are a commit and its reset has
   **no footer at all**.
@@ -956,11 +939,10 @@ by what KIND of thing they are, so an avatar takes the same number rather than a
   at the right edge, secondary to its left. A confirm dialog (no fields) is all surface: its
   buttons ARE the dialog, and they belong in the footer.
 - **A full-page editor is not a dialog.** Where the body SCROLLS and one commit governs the whole
-  page, that commit stays pinned at the page's foot: there is no dialog for it to read as
-  belonging to, and inlining it makes a reader scroll a long document to the end to save an edit
-  made at the top. What the page's title row carries instead is the actions on the OBJECT — hand
-  it to the assistant, the overflow — so the pinned bar holds the commit alone and the two
-  clusters never compete for the same press.
+  page, that commit stays pinned at the page's foot: inlining it makes a reader scroll a long
+  document to the end to save an edit made at the top. What the page's title row carries instead
+  is the actions on the OBJECT — hand it to the assistant, the overflow — so the pinned bar holds
+  the commit alone.
 - **Empty result**: `<EmptyState message hint? icon? action?>` — never a bare muted Text.
 - **Inline status**: `<Callout tone="info|success|warning|error|neutral">` — compound (like
   Card): compose `CalloutTitle`/`CalloutText`/`CalloutActions` inside. `Callout` is INLINE;
@@ -981,8 +963,7 @@ by what KIND of thing they are, so an avatar takes the same number rather than a
   carries a ground (red-100) exactly where `secondary` carries zinc-100, so every act in the row
   keeps ONE shape and only the ink moves; the ladder is then legible as a ladder. Drop a
   groundless `danger-secondary` in there and the destructive verb is the one control with no box
-  — a shape difference, which a reader parses before colour and reads as an accident, and the
-  row stops looking designed (this is what "four buttons with different shapes" is, every time).
+  — a shape difference, which a reader parses before colour.
   Among TEXT — a row's trailing verb, a `Callout`'s action, a dialog's tertiary — use
   `danger-secondary`, because there a filled box is the thing that looks pasted on. A
   fill-less `Button` (`danger-secondary`, `muted`, un-colored) shows no box, so its optical edge is
@@ -994,21 +975,16 @@ by what KIND of thing they are, so an avatar takes the same number rather than a
   `InlineButton` (28px, filled, on a field's own surface).
 
   **AN ACT CARRIES A CONTROL; UNDERLINED TEXT REVEALS.** `Link`/`TextLink` are the underlined
-  pair; everything that MUTATES is a `Button` or an `InlineButton`. A surface-less act was tried
-  as a general third rung and removed: it made underline mean anything at all, so the affordance
-  stopped answering the one question a reader has — does this take me away, or does it do
-  something here. It also competed with the `Button` colour ladder, since `muted` already IS the
-  quiet rung.
+  pair; everything that MUTATES is a `Button` or an `InlineButton`. There is no surface-less
+  third rung — `muted` already IS the quiet rung of the `Button` colour ladder.
 
   **The ONE exception, and it is narrow: an IN-PROSE DISCLOSURE.** A show/hide for adjacent
   content — a transcript under its player, a long value under its summary — has nowhere else to
-  go. It cannot move to chrome, because it belongs to the thing above it; and the two controls
-  that look right in chrome are both wrong against a text column. `Button color="muted"` measures
-  transparent, borderless and undecorated AT REST, with its wash arriving only on hover: that is
-  a hover-only affordance, banned above, and it reads as a stray label between two content
-  blocks. `Accordion` fixes the affordance and overcorrects — it is a LIST-ROW primitive, a
-  full-width header with its own chevron, and nesting one inside a row that already has a chevron
-  is list furniture borrowed for a one-off verb.
+  go. It cannot move to chrome, because it belongs to the thing above it. `Button color="muted"`
+  measures transparent, borderless and undecorated AT REST, with its wash arriving only on hover:
+  that is a hover-only affordance, banned above. `Accordion` overcorrects — it is a LIST-ROW
+  primitive, a full-width header with its own chevron, and nesting one inside a row that already
+  has a chevron is list furniture borrowed for a one-off verb.
 
   So underline is permitted here, and the INK keeps it unambiguous:
 
@@ -1017,13 +993,11 @@ by what KIND of thing they are, so an avatar takes the same number rather than a
   | blue + `role="link"` (`Link`) | leaves this surface |
   | muted underline in a caller's `Pressable` (`TextLink`, no `href`) | reveals more of it, in place |
 
-  Both say "show me more"; only one takes you away, which is the question the affordance existed
-  to answer. It stays scoped to REVEAL: a press that saves, sends, deletes or opens an overlay
-  carries a control surface, always. Pick by what the press DOES,
-  and let the surface say which kind it is. Never a `muted` text action that MUTATES: it mutes
-  the one thing carrying the act. No
-  "success"/green button. Decision UIs put positive/negative color on the STATUS (dot) and verdict
-  (colored `Text`), not the buttons.
+  Both say "show me more"; only one takes you away. It stays scoped to REVEAL: a press that
+  saves, sends, deletes or opens an overlay carries a control surface, always. Never a `muted`
+  text action that MUTATES: it mutes the one thing carrying the act. No "success"/green button.
+  Decision UIs put positive/negative color on the STATUS (dot) and verdict (colored `Text`), not
+  the buttons.
 - **Create buttons carry NO `+` icon** — "Add fee", not "+ Add fee". A create is `primary` and
   rides its section's HEADING row at the right edge — see § The add-placement law for why, and
   for the one-verb-one-weight rule that keeps it `primary` wherever it renders. (The
@@ -1074,10 +1048,8 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
   should be is decided per table — see data_entry.md §The editability affordance.
 - **A verb about a VALUE goes ON the value — an `InlineButton` in the field's `actions`.** Copy
   this reference, call this number, open this record: the act names the value, so it travels
-  with what it acts on, and a reader never has to pair a control sitting at the page's right
-  edge with the field it belongs to. `DetailRow` has NO trailing slot, because a reserved
-  column is paid by every row for the benefit of one — it was declared on the TABLE, so a
-  single `Copy` made every value cell stop short of an edge nothing occupied. EVERY `Inline*`
+  with what it acts on. `DetailRow` has NO trailing slot, because a reserved
+  column is paid by every row for the benefit of one. EVERY `Inline*`
   editor takes `actions`, popover-backed ones included — a field exposes its outer box
   separately from the control inside it, so a select's list and a date's calendar still open at
   the field's own width. Anything that is not a verb — a status `Badge`, a unit — composes into
@@ -1088,22 +1060,15 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
   editor promises never to do.
 - **What is about the WHOLE record is a PANEL, not a section.** A section takes a position in a
   top-to-bottom reading order, which is a claim that it belongs at that point in the read. A
-  record's DISCUSSION does not: a note is written about anything on the page and is wanted while
-  you work anywhere on it, so parked at one position it is unreachable from every other — exactly
-  when it matters. Dock it in the page's right gutter (the one the outline rail's balance already
-  reserved), pinned, scrolling inside itself so a long thread never lengthens the record. Give it
-  no rail entry — it is not a place you navigate to. Narrow, it collapses onto the same bar the
-  sections use, on the RIGHT: sections are where you ARE, the discussion is what is being SAID,
-  and the two poles keep the sides they hold on a wide screen.
-- **A record is ONE PAGE. A section is a place you SCROLL to, never a route you swap to.** The
-  rule above already assumes it — a section earns a POSITION in a top-to-bottom read, and the
-  discussion is docked precisely because a thing "parked at one position is unreachable from
-  every other". Routing the sections makes that true of every one of them. It is tempting on a
-  long record and it does not survive contact: each fix it needs rebuilds the whole-record view
-  in miniature — a dot to say which hidden section just changed, a page-band action to
-  re-surface an affordance some section had swallowed, an "everything" route that IS this page.
-  It also HIDES what it does not carry: a whole-record drop target advertised only inside the
-  files section does not exist from the eight destinations that are not it. And it charges
+  record's DISCUSSION does not: a note is written about anything on the page, so parked at one
+  position it is unreachable from every other. Dock it in the page's right gutter (the one the
+  outline rail's balance already reserved), pinned, scrolling inside itself so a long thread never
+  lengthens the record. Give it no rail entry — it is not a place you navigate to. Narrow, it
+  collapses onto the same bar the sections use, on the RIGHT.
+- **A record is ONE PAGE. A section is a place you SCROLL to, never a route you swap to.**
+  Routing the sections makes every one of them "parked at one position and unreachable from every
+  other". It also HIDES what it does not carry: a whole-record drop target advertised only inside
+  the files section does not exist from the eight destinations that are not it. And it charges
   permanently — browser find reaches only the open section, two sections can never be read
   together, and every cross-section check costs a click each way. A long record is a DENSITY
   problem, and density is cuttable (a choice that took four rows, a group that restated the
@@ -1118,8 +1083,7 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
   `Transfer point` / `Destination` looks like three fields and is actually one route — it cannot
   hold a second transfer, and three identical rows say nothing about which comes first. The same
   goes for an approval chain, a set of legs, a list of signatories. Rendered as a `Sequence` it
-  gains the one thing the grid could never give it — visible ORDER — and stops competing with the
-  fields around it, because it is no longer pretending to be one.
+  gains the one thing the grid could never give it — visible ORDER.
   Nothing about spacing or disclosure fixes a section holding the wrong SHAPE, and a section that
   looks "unattended" is usually this rather than a density problem.
 - **A VERB GOES WHERE ITS EFFECT LANDS.** One law places every action on a record surface, and
@@ -1134,19 +1098,16 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
   | the record's EXISTENCE | the `DangerZone`, last on the page |
 
   The ADD is the one verb this law does NOT place next to its effect, and the add-placement law
-  says why: a position that never moves beats a position that is adjacent, because "below the
-  last row" is a different place on every list and no place at all on an empty one. The heading
-  row therefore carries identity + meta + view controls + the section's ADD, and no other content
-  verb. **An add is `primary` wherever it renders** — on that heading row, or inside an
-  `EmptyState` in the one case § Empty states allows, where there is no heading to carry it. It
+  says why. The heading row therefore carries identity + meta + view controls + the section's ADD,
+  and no other content verb. **An add is `primary` wherever it renders** — on that heading row,
+  or inside an `EmptyState` in the one case § Empty states allows, where there is no heading to carry it. It
   is the act its section offers, so it carries that section's weight; a lone `secondary` button
   reads as though the real action were somewhere else. The rule that matters is that ONE VERB
   KEEPS ONE WEIGHT — the same add must not be primary on an empty list and secondary on a full one.
   A record surface therefore carries several primaries, one per section, and that is correct:
   "one primary per SCREEN" governs the page BAND, not a stack of independent sections each with
-  its own single act. The cost is real and worth knowing — the more sections offer an act, the
-  less any one of them stands out — so the answer to a loud page is FEWER SECTIONS WITH ACTS,
-  never a quieter button.
+  its own single act. The more sections offer an act, the less any one of them stands out — so the
+  answer to a loud page is FEWER SECTIONS WITH ACTS, never a quieter button.
 - **A DENSE section is compacted by a SUMMARY above it, by ROW HEIGHT, and by grouping fields
   that are ONE ENTITY — never by a two-column layout.** The evidence is unusually clear here, so
   do not re-derive it: Baymard finds an overall two-column form layout "generally problematic and
@@ -1161,14 +1122,13 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
   name its parts by adding a sub-label line no other row has — which drops its controls off the
   baseline every other row shares — and naming them with placeholders loses the names the moment
   the row is filled. In a label-left grid, ONE FIELD PER ROW is not a failure to compact; it is
-  the only shape that keeps the column a reader scans. Both attempts are recorded here so nobody
-  re-runs them.
+  the only shape that keeps the column a reader scans.
   **A spread `DetailRow` gives its VALUE the squeeze, never its label.** The two share one flex
   row, so whichever of them cannot shrink forces the other to. A flex child defaults to
   `min-width: auto`, which floors the value at its longest word — and the label, having no floor
-  of its own, absorbs everything left: on a narrow register a two-word label collapsed to a 4px
-  column 200px tall, one character per line. The `minWidth: 0` on the value is what stops it, and
-  it is load-bearing rather than housekeeping. **The probe generalises past this component**:
+  of its own, absorbs everything left, collapsing to a one-character-wide column many times taller
+  than the row. The `minWidth: 0` on the value is what stops it. **The probe generalises past this
+  component**:
   wherever a fixed-ish label shares a row with a `flex: 1` value, measure the LABEL's width and
   height across rows whose values differ in length — a label whose box changes shape from row to
   row is the signature, and it is invisible at any width where every value happens to fit.
@@ -1176,9 +1136,8 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
   required field, while a record page is read-mostly.
   A SUMMARY belongs to the RECORD, not to a section. The highlights-panel precedent (a strip of
   key facts above the detail) is a PAGE-level device, where what it summarises is a scroll or a
-  tab away; repeated per section it sits inches above the very rows it repeats, so it reads as
-  duplication and adds a third block of chrome — section title, description, strip — before any
-  data. Put the few facts someone would ask for by phone in the record's own header, once.
+  tab away; repeated per section it sits inches above the very rows it repeats. Put the few facts
+  someone would ask for by phone in the record's own header, once.
   A read-only view behind an Edit button is the last resort: it compacts by DROPPING empty
   fields — and an empty row is information, the difference between "this record has no vehicle"
   and "this section has no vehicle field" — and it costs a MODE, against the law that the surface
@@ -1186,9 +1145,8 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
 - **A REFERENCE to another record is a FIELD, not a section and not a card.** The kit already
   draws every other reference as a token — a person is a `MemberChip`, a file a `FileBadge`, a
   select option an `OptionBadge` — and a record is no different. It renders as a VALUE wearing
-  the **inline editor's own resting surface** (the 40px band, the white bordered chip, the radius), so
-  a pointer at another record sits in the value column exactly like the editors above and below
-  it. Put BOTH the name and its code INSIDE it — one entity reads as one object, and a muted
+  the **inline editor's own resting surface** (the 40px band, the white bordered chip, the radius).
+  Put BOTH the name and its code INSIDE it — one entity reads as one object, and a muted
   code beside a link reads as an orphan.
   **ONE act on the surface, the rest one layer in.** Pressing the field PEEKS the facts — free,
   so it takes the whole box as its target — and every verb lives INSIDE the peek, placed by
@@ -1199,21 +1157,18 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
   Change is `secondary` and NOT `danger` — a correction, not a destruction — Edit takes the one
   filled-dark rung and hands it to Save, Open stays `secondary` and never prioritized. None of
   them sits on the field. After Change, hand the picker focus; after Clear, never — the two
-  verbs land in the same place meaning opposite things. An interior verb was tried and removed: it put two destinations behind one object
-  (press the box → a summary; press 8px right → navigate), it demanded the whole
-  container-with-controls anatomy (a role-less surface, a `PressDoor` for the tab stop, the verb
-  lifted on `zIndex`, hover tracked on the container), and it was neither common nor an act
-  ABOUT the value — leaving is the rare move on a record page. Without it the field has its plain
-  anatomy back: the press target is the box, the focus ring rings the field.
+  verbs land in the same place meaning opposite things. An interior verb puts two destinations
+  behind one object (press the box → a summary; press 8px right → navigate), and is neither common
+  nor an act ABOUT the value — leaving is the rare move on a record page. The field has its plain
+  anatomy: the press target is the box, the focus ring rings the field.
   Detach earns its depth twice — destructive and rare, and it ANSWERS the question the peek asks
   ("is this the right one?"), so the check and the correction are one gesture. A detach link
   repeated down a column of references is noise for an act most readers never perform.
   **Open is OPTIONAL, and Edit is why.** A reference whose facts can be corrected in the peek has
-  no errand to send the reader on, and a verb wired to nothing is worse than an absent one. Edit
-  opens a DRAFT in the same grid — nothing commits until Save, which sends only what CHANGED —
-  and the open draft PINS the popover so outside-press and Escape cannot bin the typing. That
-  pinning is the whole licence: a peek may hold a draft, and may never hold a self-persisting
-  inline editor, because there blur and dismiss are one gesture.
+  no errand to send the reader on. Edit opens a DRAFT in the same grid — nothing commits until
+  Save, which sends only what CHANGED — and the open draft PINS the popover so outside-press and
+  Escape cannot bin the typing. That pinning is the whole licence: a peek may hold a draft, and may
+  never hold a self-persisting inline editor, because there blur and dismiss are one gesture.
   **Never promote it to a Section.** A section claims a distinct AREA of the record and buys an
   outline-rail entry; one pointer at one other row never earns that. What tempts the promotion is
   the machinery around it — and each piece is just part of the field: the search is its EMPTY
@@ -1248,9 +1203,8 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
 - **A PERSON token peeks the same way a record reference does — but only where nothing else
   on the line presses.** `MemberPeek` makes a `MemberChip` a door onto `MemberProfileCard`
   (a `xl` avatar, the sign-in identity, role, teams), and it is the same drill-down grammar:
-  identity on the surface, the facts one layer in. The constraint is where it may live, and
-  it is the interior-verb lesson above generalised past the reference field: **a token inside
-  something already pressable puts two destinations behind one object.** Two surfaces fail it
+  identity on the surface, the facts one layer in. The constraint is where it may live: **a token
+  inside something already pressable puts two destinations behind one object.** Two surfaces fail it
   and both keep the plain chip — a PICKER OPTION (a card over the open menu, fired at the one
   moment the reader is choosing rather than browsing) and a ROW THAT NAVIGATES (press the row,
   open the record; press four pixels left, open a card). What is left is where a peek is
@@ -1260,10 +1214,9 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
   the drill-down.
   **Judge the CONTAINER, not how inert it looks.** A grouped register's band header names a
   person, carries no visible control, and is a button — it collapses the group — so a token
-  inside it nests a button in a button and splits one gesture in two. The corollary is worth
-  stating because it reads as a failure and is not: a screen built entirely of editors,
-  pickers and navigating rows has NOWHERE a peek belongs, and the right move there is no peek
-  at all rather than the least-bad host.
+  inside it nests a button in a button and splits one gesture in two. A screen built entirely of
+  editors, pickers and navigating rows has NOWHERE a peek belongs, and the right move there is no
+  peek at all rather than the least-bad host.
   **A profile's rows are conditional, and absent is not empty**: a field nobody supplied has
   no row, while a field supplied as EMPTY keeps its row and says so. Collapsing the two turns
   "we were not told" into a confident claim about a colleague — the same distinction a
@@ -1277,8 +1230,7 @@ checkbox, a switch, a chip. The line is not "is it pressable" (nearly everything
 "does pressing it DO something, or does it set a value / open the thing you are already
 looking at".
 
-Drawn tightly because a signal on half the screen is not a signal. A pointer everywhere says
-only "this is a web page"; reserved, it marks the few things that act. What carries "you can
+Drawn tightly because a signal on half the screen is not a signal. What carries "you can
 press this" elsewhere is the hover treatment the surface already owns — a row's wash, a
 field's border, a chip's fill — which is what a native list or menu uses too, where the
 cursor stays an arrow throughout.
@@ -1304,31 +1256,45 @@ ask for one.
 **WHAT a line separates is the whole test — not how big the break feels.** A rule between two rows
 divides LIKE FROM LIKE, and the space between them already says that. The band's rule divides
 CHROME from CONTENT — a row of labels from the records they name — and no amount of whitespace
-states that, because whitespace is what already separates the rows from each other. Removing it was
-tried on a real register and the column band floated: with nothing beneath them the labels read as
-a first row rather than as the header of the rest.
+states that. Without a rule beneath them the labels read as a first row rather than as the header
+of the rest.
 
 Drawing both makes them compete, and a grid of equal lines is most of what "it looks like a
 spreadsheet" means.
 
 **The hover wash does the work the rule did**, and it already has the shape: `PressableRow` bleeds
 its ground past the content and rounds it, so a register reads as a stack of cards with no card
-component involved. That is why dropping the rules does not make rows ambiguous — the separator
-moved from a permanent line to a pointer-following one. The row has to be tall enough for that wash
-to read as a surface rather than a stripe, which is what the 72 buys.
+component involved. The row has to be tall enough for that wash to read as a surface rather than a
+stripe, which is what the 72 buys.
 
 **Density is a number, never a mode.** A surface that genuinely needs more rows on screen sets
-`minHeight` on the row. What no caller can ask for is the rules back — and that is deliberate,
-because a table of VALUES rather than of objects is a different component: `Matrix` for a numeric
-grid (a statement, a pivot, a rollup), `DataGrid` for a compact one. The distinction the two
-rhythms used to express already lived at the component boundary; offering it again as a prop was a
-third way to say the same thing, and the way that let a register contradict this rule.
+`minHeight` on the row. What no caller can ask for is the rules back — a table of VALUES rather
+than of objects is a different component: `Matrix` for a numeric grid (a statement, a pivot, a
+rollup), `DataGrid` for a compact one.
 
 ## A register that TRIAGES — `TableGroup`
 
 A flat register sorted by a column hands the reader every row at equal weight and leaves the
-deciding to them: "which of these needs me today" is answered by reading all of them. `TableGroup`
-moves that decision into the screen — a titled band of rows with a count.
+deciding to them. `TableGroup` moves that decision into the screen — a titled band of rows with a
+count.
+
+**Flat is the default; grouping is something the reader turns ON.** A register opens as one
+continuous list, and the control that splits it into bands lives in the filter band beside the
+other view controls — an explicit "group by" the reader operates, defaulting to none. Authored
+bands fail three ways at once: the value they group on is unsortable, it is unfilterable, and it
+vanishes the moment the reader wants a different cut — so the screen holds an opinion the reader
+cannot inspect, disagree with, or put down.
+
+**The status COLUMN is the floor.** Whatever the register can group on also exists as a column the
+reader can see, sort and filter — the column is the fact, the grouping is one way of looking at it.
+Ship the column first, offer grouping as a control, and let `TableGroup` render whatever the reader
+picked. Everything below governs how the bands look and behave once they are on.
+
+**A value's filter renders the value the same way its cell does.** If the status cell is a
+`Badge variant="dot"`, the status filter's options are dot badges too — same vocabulary, same
+colours, same shapes. Re-rendering it as plain text makes the reader translate between two
+presentations of one field, and the two drift the first time either side gains a value. This holds
+for every custom-rendered value, not just status.
 
 **Group by what implies a different ACTION, never by a category the reader can already see.**
 Bands like *Waiting on you* / *Gone quiet* / *Open* / *Closed* each name a different response, so
@@ -1356,64 +1322,55 @@ column is a sort wearing chrome: it spends a band per value to repeat the cell b
   the archived ones — and the tempting shortcut is to let the band list double as the vocabulary,
   treating "matches no band" as "unrecognised". It breaks in both directions at once. The values
   you deliberately left out now match nothing, so they resurface under whatever heading catches
-  the remainder — *Unclassified*, *Other* — which is louder than the bands they were removed from
-  and states something false about them. Fix that by treating "known" as "shown" instead, and a
+  the remainder — *Unclassified*, *Other*. Fix that by treating "known" as "shown" instead, and a
   value added to the field later silently disappears from the one screen that would have shown it.
   Keep a set of values the screen can classify and a list of bands it renders: a value in the
   first but not the second is omitted on purpose, and a value in neither gets a visible band,
   because a register that quietly files what it does not understand is how a stale row stays
   invisible. Both lists are ALLOWLISTS — `else` is where the second one goes wrong.
 
-Banding also changes what the COLUMNS have to carry, and the check is worth running afterwards: a
-column that exists to signal presence ("is there a next step?") is now stated by the band, so it
-is left carrying only its text — and it will be empty in every band but one. That is not
-necessarily wrong (which pile against what specifically), but it is a new duplication to look at.
+Banding also changes what the COLUMNS have to carry: a column that exists to signal presence ("is
+there a next step?") is now stated by the band, so it is left carrying only its text — and it will
+be empty in every band but one. That is not necessarily wrong, but it is a new duplication to look
+at.
 
 ## The register's own craft — what "it looks like a spreadsheet" actually is
 
 Three defects produce that report, none of them about colour, and all three survive a design
-audit. (The fourth was drawing a line between every row;
-that one is settled above — a register has one line, and it is the band.)
+audit.
 
 **A column header is a LABEL at the body size** — `sm` / `muted` / `medium`, matching the values
 it heads in size and separating from them by weight and ink. It is not an eyebrow: an eyebrow is
 `xs`, calibrated to sit quietly beside a value it captions, and a column header names a whole
 column of them. Dropped to `xs` and lightened past `muted` it stops being legible and starts
-reading as a caption that lost its value — small type is not the same as quiet type. The active
-SORTED column steps up in ink, never in weight; semibold belongs to the heading ladder.
+reading as a caption that lost its value. The active SORTED column steps up in ink, never in
+weight; semibold belongs to the heading ladder.
 
 **A fixed column `width` is sized for the LONGEST locale, not the one you typed it in.** Every
 header is a translated string, and the same label runs half again as long in Vietnamese as in
 English — so a width measured against the source truncates the header in the language the app
-actually ships in, on a column the reader was told to check. It fails silently in review because
-the reviewer reads the source locale. Size against the longest translation, or give the column
-`flex` and let it take what it needs.
+actually ships in. It fails silently in review because the reviewer reads the source locale. Size
+against the longest translation, or give the column `flex` and let it take what it needs.
 
 **Sentence case, in the table header too.** The heading ramp already bans all-caps and names it
-the #1 templated tell; `Table` and `SortHeader` were uppercasing every column label in every app,
-which is the loudest possible version of the thing the rule exists to stop. Removing the case
-without replacing the separation is what left the header looking adrift — the ink step above is
-the replacement, and the two changes only work together.
+the #1 templated tell. Removing the case without replacing the separation leaves the header
+looking adrift — the ink step above is the replacement, and the two changes only work together.
 
 **A LOOKUP KEY IS NOT A COLUMN — and this is where "cramped" usually comes from.** Ask of each
 column whether its value is COMPARED down the page or MATCHED one at a time. A reference,
 identifier or code that a reader arrives already holding — quoted on the phone, printed on a
 document, pasted from an email — is matched, and the question it answers is "which record is this
 one", which the search field answers exactly and without scanning. A column answers it by spending
-its width on every row forever, and takes that width from the columns that ARE compared. Measured
-on a register whose reference columns held 350px and truncated nothing while the two columns
-carrying the facts a reader scans lost 224px and 84px of real values: cutting the references
-halved the truncation and returned the width to where the eye actually goes. Put them in the
-search haystack, on the record, and in the row's expanded detail if they must be visible — never
+its width on every row forever, and takes that width from the columns that ARE compared. Put them
+in the search haystack, on the record, and in the row's expanded detail if they must be visible — never
 in a column, unless the value is genuinely compared (a sequence a reader reads for gaps, a code
 whose PREFIX groups the rows).
 
 **`Table` does not scroll horizontally, and that is the feature.** When the columns do not fit, it
 sheds by `priority` and then stacks — it never offers a pan. A horizontal scroller is a WIDTH fix
 for a COUNT problem: it makes room for one more column without ever asking whether the column
-earns a row's width, and the columns it hides off-screen are hidden from the author too, so the
-register quietly grows past what anyone reads. The narrowing IS the question "which of these does
-the reader compare", asked at the only time it gets answered. A dataset that genuinely wants pan —
+earns a row's width, and the columns it hides off-screen are hidden from the author too. The
+narrowing IS the question "which of these does the reader compare". A dataset that genuinely wants pan —
 every column compared against its neighbours — is a different shape: a quantity across two
 dimensions is `Matrix`, a managed grid is `DataGrid`.
 
@@ -1430,11 +1387,11 @@ outwards.
 no row carries yet — that is data-driven shape, and it is allowed. What breaks is that the
 `columns` entry and the row's `TableCell` are two edits in two files, so it is natural to make
 only the first: the header band loses a heading, the row still renders the cell, and from there
-every column right of the gap sits under its neighbour's title. Nothing is null, nothing throws,
-and both files read as correct on their own — the defect exists only in the pair. Derive both from
-one value (`const showX = …`, used for the `columns` filter AND passed to the row) so they cannot
-be edited apart. The signature when reviewing a render: the header has one fewer cell than the
-body, and the columns after the hidden one are shifted by exactly one slot.
+every column right of the gap sits under its neighbour's title. Nothing is null, nothing throws —
+the defect exists only in the pair. Derive both from one value (`const showX = …`, used for the
+`columns` filter AND passed to the row) so they cannot be edited apart. The signature when
+reviewing a render: the header has one fewer cell than the body, and the columns after the hidden
+one are shifted by exactly one slot.
 
 **A row's SUBJECT is `medium`, never semibold.** Semibold is the heading ladder's weight — `#`,
 `##`, `###` are all semibold — so a register whose row subjects are semibold renders its content
@@ -1458,8 +1415,7 @@ recedes.
 **The subject leads by WEIGHT and by its identity mark, not by size.** `medium` against `regular`,
 plus the avatar or tile that answers "which row is this", is enough. Money is the case that most
 often argues for a size step and should not get one: tabular figures and right alignment already
-mark it, and a lone larger value on a row reads as a mistake rather than as emphasis. One larger
-thing among peers is not emphasis; it is the thing that looks broken.
+mark it, and a lone larger value on a row reads as a mistake rather than as emphasis.
 
 **Whether the SUPPORTING line drops a rung is decided by what else separates the pair — not by
 where it sits and not by what it carries.** `color="muted"` is already one channel of demotion, so
@@ -1480,9 +1436,8 @@ pair's, not each half's.
 **A STACKED PAIR takes `leading="tight"` — it is not prose.** The ramp's body rungs carry prose
 leading (14/24, ratio 1.71), which is right for a paragraph and wrong for two lines that are one
 object: it leaves ~10px of empty box between them, so the pair reads as two separate lines. Beside
-a 40px mark the same fault is measurable rather than a matter of taste — the stack comes to 50 and
-overhangs the mark it belongs to. Tight is `size + 6`, which is what `xs` has always been, so this
-is the smallest rung's own rule extended up the ladder rather than a second opinion about leading.
+a 40px mark the stack then comes to 50 and overhangs the mark it belongs to. Tight is `size + 6`,
+which is what `xs` already is — the smallest rung's own rule extended up the ladder.
 
 Set it on BOTH lines where both are body rungs; where the supporting line is `xs` it is already
 tight, so only the subject carries the prop. Then the stack's own `gap` goes to **0** — each tight
@@ -1495,12 +1450,8 @@ Running text keeps prose leading. The default is for paragraphs, and `.ui-markdo
 sits beside — a 24px `CopyButton` on an 18px `xs` line — so a flex row containing both is sized by
 the CONTROL, and `alignItems: "center"` then spends the difference above the text. The line's text
 starts lower, and the pair reads with a wider gap than the identical pair one column over that
-happens to carry no control — one shared `gap` reading as two different ones.
-
-It is invisible in review because every number is defensible — the gap is right, the rungs are
-right, the control is the documented size — and the defect is the interaction between them. It is
-also the harder half of *same shape, same treatment*: the reason for the difference is real, and a
-reader cannot see it.
+happens to carry no control — one shared `gap` reading as two different ones. It is invisible in
+review because every number is defensible and the defect is the interaction between them.
 
 Pin the row to the TEXT's line box (`height` = the rung's leading) and let the control overflow it.
 The hit area is unchanged — it paints outside the box rather than growing it — and the text sits
@@ -1515,17 +1466,14 @@ where it would if the control were not there. The same applies to any verb ridin
 **The shape varies only where the surface MIXES entity types** and the reader acts on which is
 which: a search result holding both people and companies, a "related records" list, a picker over
 two directories. On a surface whose rows are all one kind of thing — a register of records, a
-roster, a list of accounts — pick ONE shape and hold it. The distinction is real, but a reader
-does not act on it there, and a column of mixed circles and squares reads as an inconsistency
-rather than as information. That is the general form: a structural device asserts a difference,
+roster, a list of accounts — pick ONE shape and hold it. A column of mixed circles and squares
+reads as an inconsistency rather than as information: a structural device asserts a difference,
 and asserting one the reader cannot use costs more than it gives.
 
-Both exist for the same reason: the mark's entire job is making a row identifiable at a glance,
-so it is the one element in the row that must not look the same on every row. A register of
-twenty people in one accent colour is twenty identical circles, with the largest and most
-colourful thing in the row carrying no information; and a register of companies drawn with a
-person's disc asserts they are the same kind of entity, which the column header alone has to
-correct.
+The mark's entire job is making a row identifiable at a glance, so it is the one element in the
+row that must not look the same on every row. A register of twenty people in one accent colour is
+twenty identical circles, with the largest and most colourful thing in the row carrying no
+information.
 
 - **The hue is derived, never passed.** A per-app or per-screen map is a second copy of something
   the name already determines, and it drifts. `avatar_tone` is pure, so one person is one colour
@@ -1540,16 +1488,16 @@ correct.
 - **Every register row should carry a LEADING MARK, best effort from the data.** An avatar, a
   logo, a thumbnail, a file badge, a coloured initial — something the eye can aim at without
   reading. A register whose rows open with text starts flat, and the symptom is reported as
-  anything but the cause ("that avatar looks too small", "it looks plain"), because a missing
-  element is invisible by definition. A person gets initials; an account gets the squared mark; a
-  record with no likeness of its own borrows the identity a reader actually scans for — a deal
-  takes its account's mark, since "whose deal is this" is the question being asked of the list.
-  Only rows with genuinely no identity are exempt: a list of amounts, a log of events.
+  anything but the cause ("that avatar looks too small", "it looks plain"). A person gets
+  initials; an account gets the squared mark; a record with no likeness of its own borrows the
+  identity a reader actually scans for — a deal takes its account's mark, since "whose deal is
+  this" is the question being asked of the list. Only rows with genuinely no identity are exempt:
+  a list of amounts, a log of events.
 - **The rung follows what the row is ABOUT**: `lg` where the entity is the row's subject, `md`
   where it is one field among columns (see `avatar_size`).
 - **A column of faces must not draw an UNBOUNDED audience as faces.** Where a cell answers "who
   can reach this", the commonest state is often *everyone* — and three sampled avatars assert
-  something false about the one fact the column exists to be scanned for exceptions in. Draw the
+  something false about it. Draw the
   unbounded grant as a mark that SAYS so, and people only where the set is genuinely enumerable;
   cap the faces at a few and let the remainder be a `+N` — as the last mark IN the stack, since a
   number trailing after the discs reads as a separate fact about the row. Drop anyone the row
@@ -1558,23 +1506,19 @@ correct.
   reader may not be entitled to. And the faces stay INERT inside a pressable row, per
   member_peek.tsx.
 - **An overlapping stack separates with translucent INK, never with the surface colour.** The
-  conventional facepile rings each mark in the page background so the discs read as distinct —
-  which binds the ring to a colour the row does not keep. A register row washes on hover, again
-  when it is the open record, and again while pressed, so a ring painted white is a halo in three
-  of the four states, and they are the states a reader is in when they are actually looking. A
+  conventional facepile rings each mark in the page background — which binds the ring to a colour
+  the row does not keep. A register row washes on hover, again when it is the open record, and
+  again while pressed, so a ring painted white is a halo in three of the four states. A
   translucent dark edge darkens whatever is behind it instead of matching it, so it holds on every
   ground; `FileBadge` separates itself from its own surface the same way. Use a `boxShadow`, not a
   border — a border grows the box, and the stacked mark then measures wider than the identical
   mark in the next column.
 
-The brand did not lose a home when the disc stopped carrying it — it moved to chrome, below.
-
 ## Character comes from the DATA — the answer when a screen reads "bland"
 
 Every rule above removes a defect. None of them ADDS anything, so a screen can pass all of them
 and still be reported as plain, boring, or unfinished — which is a different complaint with a
-different fix. Removing defects converges on *inoffensive*; these three questions converge on
-*distinctive*.
+different fix.
 
 - **What is inherently visual in THIS data?** Work software has no photography, so the data itself
   is the imagery: identity marks (above), status colour, file-type badges, sparklines, proportion
@@ -1589,12 +1533,38 @@ different fix. Removing defects converges on *inoffensive*; these three question
   keep not landing.
 - **What makes this belong to THIS product?** Default typeface, default greys, default accent,
   default control shapes is a *well-built generic screen*, and no further polish changes that. The
-  fix at that point is a theme (`applyLoticsTheme`), not another treatment pass — and knowing
-  which of the two you are looking at saves a great deal of pointless nudging.
+  fix at that point is a theme (`applyLoticsTheme`), not another treatment pass.
 
 Type SCALE is the fourth, and it belongs with the others: range = largest ÷ smallest across the
-screen, and under about 2× reads flat *at any amount of colour*. Scale is the one hierarchy device
-colour cannot substitute for. A register with no page band tops out near 1.33×.
+screen, and under about 2× reads flat *at any amount of colour*.
+
+**The test every visual has to pass: does it make the screen CLEARER *and* better-looking?** Both,
+not either. A visual that only decorates is clutter and goes; a visual that only informs but fights
+the composition is a chart nobody reads. The ones that pay are the ones where the two are the same
+act — a status colour that is also the scan path, a product thumbnail that is also the identifier, a
+trend line that is also the answer.
+
+**And the same test cuts the other way.** Nearly every rule here removes something — follow only
+that gradient and you converge on a screen that is clean, defensible, and *does not tell the reader
+enough to act*. **Minimal is not the same as clear.** A number with no comparison, a status with no
+age, a total with no composition, a row that forces a click to answer the question it exists to
+answer — each is a screen that passed every subtraction and failed the reader. Withholding is a
+defect exactly as much as clutter is; it is simply the one that survives review, because nothing on
+the screen looks wrong. Ask what the reader must DECIDE, then check that the screen holds every
+fact that decision needs.
+
+**Where the data has a history, show the trajectory, not just the latest value.** A figure states
+where things stand; a line, a bar series or a `Sparkline` states where they are GOING, and the
+direction is usually the decision — a balance that is falling, a return rate that is climbing, a
+week that broke the pattern. This is the most common honest source of visual interest in work
+software, because the shape *is* information.
+
+**A register whose entity has ordered stages should render the stage, not just name it.** A word in
+a cell makes the reader know the vocabulary and its order; a small coloured progress indicator makes
+position legible at a glance and lets rows be compared down the column — which is the question a
+register is asked. Colour it by what the stage MEANS (moving / stalled / done / failed), so the
+column reads as a state of play rather than a palette. Do not spend this on a two-state field: a
+progress rendering of "open / closed" is a badge wearing a costume.
 
 ## Where the accent goes — "where you are", and nothing else
 
@@ -1608,8 +1578,8 @@ case. `primary` is already the ink the kit spends on "this is on": a checkbox's
 track, a picked option's tick, the one primary button. An active tab is the same claim at page
 scale, so it belongs to the same ink, and the rail then sits at the same weight as the CTA it
 shares a screen with. Painted in `accent`, an unthemed screen gets exactly one blue thing on it —
-a single-member hue from a family used nowhere else, which is the definition of a library default
-nobody chose (see § Color discipline), three pixels from a near-black button.
+a single-member hue from a family used nowhere else, which is a library default nobody chose (see
+§ Color discipline).
 
 The line between the two: `accent` marks WHICH OF THESE (a row among rows, a filter among
 filters), `primary` marks THIS IS ON (a control's state, the section you are in).
@@ -1620,51 +1590,41 @@ keeping the ground every other chip and card has. The two altitudes deliberately
 is the row's own language, so a control that borrows it says the same thing twice, and a control
 has a border to say it with while a row does not.
 
-The reason to hold that line is that it was crossed twice, in both directions, and each crossing
-looked reasonable. Painting selections through `accent_wash` shipped a blue nobody had chosen onto
-the busiest surface in the product; making the token neutral to fix that turned a themed app's drop
-target grey and left a token named for the brand that resolved to zinc. Selections carry their own
-LITERALS now, so "is this selected" never depends on whether a tenant set an accent, and
-`accent_wash` goes back to meaning what it says: the brand's tint, spent on ATTENTION — a region
+Selections carry their own LITERALS, so "is this selected" never depends on whether a tenant set
+an accent, and `accent_wash` means what it says: the brand's tint, spent on ATTENTION — a region
 lighting up under a dragged file — never on which record is open.
 
-**Selection and hover must not share a ground.** They did, and the register's one piece of
-persistent state was erased by a transient one: the row whose record is open looked exactly like
-the row under the pointer. One neutral step separates them — **hover zinc-50, selected zinc-100,
-pressed zinc-200**, three rungs of the ramp every other pressable already uses to say the same
-three things. A control marked by an EDGE sidesteps the collision entirely, which is the other
-reason chips are marked that way: the edge survives the hover wash instead of being replaced by
-it.
+**Selection and hover must not share a ground** — the register's one piece of persistent state is
+then erased by a transient one: the row whose record is open looks exactly like the row under the
+pointer. One neutral step separates them — **hover zinc-50, selected zinc-100, pressed zinc-200**,
+three rungs of the ramp every other pressable already uses to say the same three things. A control
+marked by an EDGE sidesteps the collision entirely, which is the other reason chips are marked that
+way: the edge survives the hover wash instead of being replaced by it.
 
 ### Theming is an app-level ESCAPE HATCH, not a product surface
 
 An app sets its own identity in its own code — `applyLoticsTheme({ … })` once at boot, before
 `mount`. **Nothing in the platform writes a theme**,
 there is no settings screen for it, and `apps.theme.color` is the LAUNCHER ICON's colour and
-nothing else. Read that as the boundary rather than as a gap waiting to be filled: the mechanism
-exists because a customer occasionally needs their own typeface, not because theming is a feature
-we sell.
+nothing else. That is the boundary, not a gap waiting to be filled.
 
 **What makes it possible is small and load-bearing.** `colors.web.ts` reads five roles through a
 CSS variable with the kit's own value as the inline fallback, and `font_family.web.ts` does the
 same for the three weight rungs. That indirection is the ENTIRE mechanism — and it cannot be
-replaced by wrapping a component and passing styles down, which is the intuition to check before
-reaching for it. React Native Web writes `fontFamily` onto every `Text` element itself, so a
-wrapper's font has nothing to inherit into; and `background-color` and `border-color` do not
-inherit in CSS at all, so no ancestor can reach a `Button`'s fill or a `Table`'s hairlines. The
-only alternative to the variables is passing `style` at every call site, which is a fork rather
-than a theme.
+replaced by wrapping a component and passing styles down. React Native Web writes `fontFamily`
+onto every `Text` element itself, so a wrapper's font has nothing to inherit into; and
+`background-color` and `border-color` do not inherit in CSS at all, so no ancestor can reach a
+`Button`'s fill or a `Table`'s hairlines. The only alternative to the variables is passing `style`
+at every call site, which is a fork rather than a theme.
 
 **Prefer `applyLoticsTheme` over declaring the variables by hand**, because two of the values are
 DERIVED and getting either wrong fails quietly: `accent_wash` is the accent at 7%, and one
 `bodyFont` has to reach all three weight rungs or the medium and semibold runs stay in the kit's
 own face and the screen reads as a font that half-loaded.
 
-**It is a function, not a provider**, and the shape follows from what theming IS: an app declares
-one identity at boot and never changes it. A React component bought a memo, a wrapper element, a
-layout effect, a restore-on-unmount and a context nobody read — all of it lifecycle for a value
-with no lifecycle. Calling it before `mount` is also strictly better than a provider could be: the
-variables are in place for the FIRST paint, where a provider's effect ran after one.
+**It is a function, not a provider**: an app declares one identity at boot and never changes it,
+so there is no lifecycle to buy. Calling it before `mount` puts the variables in place for the
+FIRST paint, where a provider's effect would run after one.
 
 ## Color discipline — solid / tint / ramp + ONE accent
 
@@ -1701,9 +1661,8 @@ the sizes are.
 `color="muted"` is the token that means "this supports something else"; a hand-written
 `color="zinc-500"` is a *different, lighter* neutral that typechecks, renders plausibly, and is
 already spoken for — components mute a DEPARTED or disabled subject to it. Reach for the raw shade
-and a supporting line ends up wearing the ink that means "this person has left", so on a departed
-row the mute and the metadata come out identical and the state stops signalling anything. Grep a
-component for a raw neutral on `Text` before trusting that it reads muted.
+and on a departed row the mute and the metadata come out identical, so the state stops signalling
+anything. Grep a component for a raw neutral on `Text` before trusting that it reads muted.
 
 **TEXT never wears `solid()`** — the 500 is a FILL shade (dots, series). A status word/number uses
 `Text`'s valence tokens: `color="danger"` (red-900) / `"warning"` (amber-700) / `"success"`
@@ -1730,8 +1689,7 @@ cue. That is the ONLY thing it is for; keep the vocabulary scarce so a colored c
 status. **A type / category / attribute / count is NOT a status — render it as inline `Text` (a
 muted metadata line, free to wrap the row taller), NEVER a Badge.** A party's type, a document
 kind, a city, "3 files" → text. If you're reaching for a Badge in a row or an option list "to
-show more info," STOP — that's text. (The bug that set this rule: tonal type-pills sprinkled
-through combobox option rows.)
+show more info," STOP — that's text.
 
 When it IS a status, match weight to prominence — lightest → heaviest:
 
@@ -1751,9 +1709,9 @@ Prefer `dot` when the column is secondary or the row already carries a coloured
 `tonal` when the status column is what the register is SCANNED by — the tints are the palette's
 50-step against its 900-step ink, comfortably clear of the AA floor, and
 a column of them is the difference between a register that reads as organised and one that reads
-as a grey spreadsheet. That difference is the commonest "it looks bland" report, and it has a
-real answer that costs no meaning: make the colour the screen ALREADY earns more present, rather
-than adding colour somewhere that has to invent a meaning to justify it.
+as a grey spreadsheet. That is the commonest "it looks bland" report: make the colour the screen
+ALREADY earns more present, rather than adding colour somewhere that has to invent a meaning to
+justify it.
 
 **A `Badge` in a table cell needs `alignSelf`.** A cell stretches its child on the cross axis, and
 a `dot` has no ground so nothing shows — swap the variant to `tonal` and the pill becomes a filled
@@ -1771,9 +1729,8 @@ not a form they fill down. Stacked one per row at the page's own rhythm, a handf
 values can spend a quarter of the first screen while the viewport's right half sits empty. Pair
 them into columns above the width where a label and its value still fit.
 
-The tell is a screen reported as **plain** whose treatment is fine. Then the treatment was never
-the problem, and another pass at it will not help: the page is spending its height on facts and
-its width on nothing.
+The tell is a screen reported as **plain** whose treatment is fine: the page is spending its height
+on facts and its width on nothing.
 
 **A record page also owes the reader the SIZE of its subject.** Where the data is quantities — how
 many lines, how heavy, worth what — a page that holds them only inside sections makes a reader open
@@ -1802,11 +1759,9 @@ cluttered rather than as small. Recede with INK, at the same rung. `xs` is for g
 timestamp, a count), not for a label that a person actually has to read.
 
 **A LABEL sharing a row with a flexible VALUE must be told which one gives way.** Two items in one
-flex row, and whichever cannot shrink forces the other to. A value floored at its longest
-unbreakable word leaves the label absorbing every remaining pixel — collapsing to a
-one-character-wide column many times taller than the row it names. It is invisible wherever the
-values happen to fit, which is usually the width it was built at, and it appears the first time a
-real record carries a long one. Decide deliberately: `flexShrink: 0` on the one that must stay
+flex row, and whichever cannot shrink forces the other to. It is invisible wherever the values
+happen to fit, which is usually the width it was built at, and it appears the first time a real
+record carries a long one. Decide deliberately: `flexShrink: 0` on the one that must stay
 whole (a fixed-length key, a label), `flexShrink: 1` + `numberOfLines` on the one that may clip,
 and pick by which is still USEFUL truncated — `RC-2026-0…` is unusable, `(555) 384-7…` is still
 recognisably a phone number.
@@ -1837,13 +1792,9 @@ steepens as the type grows — nothing in the kit tracks positive except `transf
 which compensates for the caps itself.
 
 A hand-set `letterSpacing` is a finding wherever it appears, and it fails in a specific way: it
-looks like a local decision and is actually a second copy of the curve. Three of them shipped
-before this was written — a private size→tracking table on `Metric` that put the product's
-summary figures at ZERO while the sentence beside them tracked -0.48px, a flat value on `Text`
-itself that was the whole of native's tracking, and `+0.3` left on a column header after its size
-and weight had been corrected. Each was defensible in its own file and wrong on the screen. If
-something cannot be wrapped in `Text` (a raw `TextInput`, a chart axis), take the rung from
-`type_ramp` rather than picking a number.
+looks like a local decision and is actually a second copy of the curve — defensible in its own
+file and wrong on the screen. If something cannot be wrapped in `Text` (a raw `TextInput`, a chart
+axis), take the rung from `type_ramp` rather than picking a number.
 
 Weights: `regular` / `medium` /
 `semibold`. Colors: `default` (zinc-900), `muted` (zinc-600), `inverted`, the valence set
@@ -1856,6 +1807,16 @@ Anything pressable is ≥ 40px tall (8px minimum gap between pressables). 16px b
 canvas padding, 16–20 inside bands, 10–12 between content lines. Density comes from alignment +
 hierarchy, not cramming.
 
+**Space states what belongs together, so the gap INSIDE a unit is always smaller than the gap
+BETWEEN units.** A line item's name, its code and its quantity are one thing and sit tight; the
+next line item starts after a clearly larger gap. Get the ratio backwards — or make both gaps
+equal — and the reader has to reconstruct the grouping from the content, because the layout is
+telling them the parts are peers of the wholes. The tell is a stack that reads as an undifferentiated
+list when you unfocus your eyes, or a supporting line drifting so far from the value it supports
+that it looks like the next unit's first line. This is the same law the gap-ratio probe in
+[reviewing.md](./reviewing.md) measures (~2:1 between over inside) — no amount of type or colour
+work fixes a stack whose spacing groups the wrong things.
+
 **A control's height comes from `CONTROL_HEIGHT`, never from padding tuned against a leading.**
 Padding that happens to sum to the band height is a second owner of that number, and it drifts the
 moment the type ramp moves — which the ramp is allowed to do. The signature is one control
@@ -1884,10 +1845,9 @@ React Native Web maps a subset of RN's accessibility props and **silently drops
 <Pressable accessibilityRole="tab" aria-selected={isActive} />
 ```
 
-The trap is the failure's shape rather than its cause. There is no type error —
-the prop is declared — no runtime warning, and the control looks and behaves
-correctly; only a screen reader and the DOM inspector disagree with the source.
-Nothing in a normal loop surfaces it, so it survives review, tests and QA.
+There is no type error — the prop is declared — no runtime warning, and the control looks and
+behaves correctly; only a screen reader and the DOM inspector disagree with the source. Nothing in
+a normal loop surfaces it, so it survives review, tests and QA.
 
 Write the raw `aria-*` attribute for any STATE (`aria-selected`, `aria-checked`,
 `aria-expanded`, `aria-disabled`, `aria-current`). `accessibilityRole` and
@@ -1903,8 +1863,7 @@ no matter how long you `waitFor`. That covers everything built on it: the `Combo
 this reason — there is no render test for any of them.
 
 The trap is that the CONTROL works fine, so the failure looks like a wiring bug: the input takes
-its value, `aria-expanded` flips to `true`, and `role="option"` is nowhere. Time goes into
-debugging the component instead of the harness.
+its value, `aria-expanded` flips to `true`, and `role="option"` is nowhere.
 
 So split the assertion:
 
@@ -1918,6 +1877,42 @@ A component test can still assert everything BEFORE the overlay opens: the empty
 placeholder, the disabled state, and — often the point — what the screen refuses to claim while
 nothing is selected.
 
+## Localization — a rendered string is WIRED, never a literal
+
+Microcopy below says what the words should SAY. This says how they reach the screen, and it is
+the same family of defect as `accessibilityState` above: it typechecks, it renders, and it is
+wrong in a language nobody on the change speaks.
+
+**No user-facing string is a literal in `src/` when a locale slice already names it.** Every
+string a component renders resolves **prop → `useLoticsLocale()` slice → the English pack**: a
+per-instance `labels` override wins, the pack from `LoticsLocaleProvider` answers next, and `en`
+is the context's default value rather than a per-key fallback — each slice reuses the
+component's own `*Labels` type, so both packs are compile-forced complete and a missing
+translation is a build error, never a silent English leak at a call site. The module itself —
+the provider, the shipped `en`/`vi` packs, the `bcp47` tag, and the few surfaces that still take
+`labels` directly — is [catalog.md §"Theming, locale & tokens"](./catalog.md).
+
+**Write it as an ALLOWLIST, not a hunt.** The question is never "does this string look
+English?" — it is "which slice names this string?", asked of every run of language the component
+emits, visible text and accessible names alike. A hunt is a denylist against a language you can
+recognise, and it goes blind twice over:
+
+- **A literal typechecks, renders, and passes a render test in whatever language it happens to
+  be written in.** The kit shipped a hardcoded Vietnamese ⓘ label — the exact value of the very
+  slot it should have read — to every tenant, and a whole suite of `vi`-pack assertions was
+  blind to it, because on that bug the literal and the translation are the same string.
+- **A string BUILT by concatenation hides inside caller data.** `Open ${name}`, `About ${label}`,
+  `${label} min` each carry one English word welded onto a value, so a Vietnamese app announced
+  "Open hop_dong.pdf" to the one reader who has only the announcement. The fix is a pack-owned
+  FUNCTION, not a connector string: word order forks by language, and a pack that only supplies
+  the word cannot move it.
+
+**So assert a wired string under the OTHER language.** English is what the bug produces, so an
+`en` assertion passes on the defect; render under `vi` and match the accessible name EXACTLY —
+a substring match contains the caller's data either way and is blind to precisely this. The one
+inversion: a string hardcoded to the Vietnamese value can only be caught under `en`. Whichever
+language the literal is in, the proof is the other one.
+
 ## Microcopy — content, not mechanics
 
 UI copy states WHAT something is — domain content or one real rule — never how the widget
@@ -1947,8 +1942,8 @@ that praises it is marketing.
 - **NEVER join text with a middot — ` · ` is banned.** It is punctuation doing a word's job: it
   asserts that two things are related while refusing to say how, leaving the reader to guess
   between "and", "of", "for", "then", and "here is another fact". It is also the single loudest
-  templated-metadata tell (`5 min read · Jan 3 · Design`), and screen readers drop it, so the
-  only thing carrying the relationship vanishes. Use the mark that MEANS what you intend:
+  templated-metadata tell (`5 min read · Jan 3 · Design`), and screen readers drop it. Use the
+  mark that MEANS what you intend:
   **`:`** for a run-in label naming its value (`Hàng hoá: <goods>`), **`( )`** for a
   supplementary count or qualifier (`Đã đọc biểu thuế (2 bước)`), **`;`** between two related
   clauses, **`,`** in a genuine list of like items, a real preposition when the relation is
@@ -1995,8 +1990,7 @@ one exists).
 
 An empty region has three jobs (NN/g): confirm this is EMPTY — not loading, not broken — and
 say what belongs here. The `EmptyState` props are that anatomy and nothing more (`message` =
-what's empty, `hint` = what to do about it). "Not broken" is why the failed read has its own
-component: an alert glyph inside an empty state says both at once and means neither.
+what's empty, `hint` = what to do about it).
 
 **`EmptyState` carries NO verb.** The add is on the heading row (§ The add-placement law) and
 duplicating it here would put two buttons for one act in view and make the add jump the moment
@@ -2016,10 +2010,8 @@ default holds a screenful because nothing else is in view: collapsing to two gre
 read as a rendering bug rather than a state, which is the first of the three jobs. Inside a
 record that premise is false. The band's heading above it, the sections below it and the add
 verb beside it have already proved the surface rendered; the only open question is what this one
-band holds, and a screenful is a long way to say "nothing yet". Measured on a four-section
-record where three bands can be empty at once, the default spent **178px per band** and pushed
-the section the reader opened the record FOR under the fold on a 768px screen — every probe
-passes on that page, because nothing is wrong with any element on it.
+band holds, and a screenful is a long way to say "nothing yet" — on a four-section record where
+three bands can be empty at once, the default spends **178px per band**.
 
 So: `compact` on a band, the default on a region. It is a DENSITY axis, not a second component —
 same three jobs, same two strings, same no-verb rule. Compact also sets its text to the LEFT,
@@ -2032,11 +2024,9 @@ at a fixed stroke on a 24 viewBox, so the artwork fills 20/24 of whatever box yo
 `sm` text the CAP HEIGHT is 11px, so a mark has to be ~13px to sit ON the line instead of
 straddling it — and at 13–16px a glyph with interior detail (`package`, `receipt`, `file-text`)
 closes up into a smudge. At 20px it reads, and its 16.7px of artwork then stands half again as
-tall as the capitals beside it, rising above them and dropping past the baseline. Three sizes,
-three different complaints, no size that answers both. Reach for a mark beside text only where
-the glyph is SIMPLE (`check`, a chevron, a dot) or the text is `md` or larger; a detailed glyph
-wants the block form, where it gets 28px and a line of its own. Here the anchoring is already
-done by the band's heading, which is the premise the whole variant rests on.
+tall as the capitals beside it, rising above them and dropping past the baseline. Reach for a mark
+beside text only where the glyph is SIMPLE (`check`, a chevron, a dot) or the text is `md` or
+larger; a detailed glyph wants the block form, where it gets 28px and a line of its own.
 
 ### Buttons & action labels — the outcome, verb-first