@lotics/ui 43.5.0 → 43.7.0

package/AGENTS.md

@@ -17,7 +17,7 @@ CURRENT major only — upgrading an app across majors is `MIGRATION.md`.
 | [docs/catalog.md](./docs/catalog.md) | **The complete inventory** — Reach-by-role (each data role → the ONE canonical component) + every `@lotics/ui/<module>` entry point (incl. `@lotics/ui/vite`'s `loticsOptimizeDeps` + `loticsResolve()` — the pre-bundle list and the whole `resolve` block a custom-code app's `vite.config.ts` imports rather than hand-carries, dev-link included). Read before building any screen; reuse first. |
 | [docs/data_entry.md](./docs/data_entry.md) | **a picker over a select field keeps the field's colours** (`optionPicker` — the hand-rolled `map` to `{value,label}` drops `color`, so a value reads coloured in a register and grey in the editor); Which editing pattern for which job — inline edit, fieldset forms, browser-autofill suppression (search controls only), find-or-create (`Combobox`), line items, handoffs, phased records, billing, tags, dispositions, attachments (`InlineFiles` for a record ROW — list + one CTA, `multiple` decides add-vs-replace; the `FilesEditor` COMPOUND for a whole section — root owns selection/gallery/confirm, you compose the bar, a HOST verb reads `useFilesEditorSelection` — plus the three-way file INTAKE: CTA + `FileDropTarget` + `usePasteFiles`), stage gates, whether a multiline value keeps its fixed reserve or `autoGrow`s (who decides the length — the field, or whoever is typing), the commit-on-blur vs action-press ordering law (the kit gates the press — `pending_commits`). |
 | [docs/ai_patterns.md](./docs/ai_patterns.md) | AI acts, the human stays in charge — composer, live run feed (`AgentRun`), the one law's split — it turns on WHO supplied the values (machine → a gate: a diff when something is being replaced, a full editable preview when records are being created from a document; human-typed → save-direct + the `ResultHeader` receipt), findings, provenance, confidence; **after the run** — a stored record that fills up from several writers (a person, a chat agent, an extraction, an automation) and remembers none of them: an unwritten value must not render like a written one, a machine's prose and a person's must not share a treatment, model markdown goes in `variant="embedded"`, and the read path must project every field the write paths set; the UI half of the SDK's [ai doc](../app-sdk/docs/ai.md), the whole run in a dialog (`AgentRunScope`/`AgentRunPane`/`AgentRunActions` — a parked question REPLACES the feed, actions in the footer, **Stop** while streaming), **stopping** (`cancel` stops the run, `abort` only stops listening — so closing a dialog must `cancel` or it keeps billing); **review surfaces compose from atoms** — `DiffValue` (a changed value, droppable in any cell/row/total), `DiffMark` (what happened to the row — ONE circular disc, every surface), `useChangeSet` (accept/reject/undo bookkeeping, no layout) — see [MIGRATION.md](./MIGRATION.md) for the `ChangeReview` family they replace |
-| [docs/composition.md](./docs/composition.md) | The design-language contract — canvas + content column, heading altitude (incl. eyebrow vs group lead — a label is one or the other), banded cards, register vs inset rows (incl. the register laws a row centres its cells by: every cell a FIXED height, a pressable cell on the shared hover token, a column sized by what it carries), the button ladder and **what underlined text may mean** (it GOES somewhere or REVEALS something — never mutates; blue leaves the surface, muted stays on it, and the one in-prose disclosure exception is scoped there), master-detail `Drawer` on a LIST screen vs a child collection's row EXPANDING inside a record, view controls, RECORD EXTENT (one page, sections scrolled to and never routed to), **the register's rhythm** (no hairline between rows — their own height and the hover wash separate them; the register's one line is the band capping the columns, because that is the break whitespace cannot state. Density is `TableRow`'s `minHeight`, never a mode), **a register that TRIAGES** (`TableGroup` — titled bands ordered by what needs the reader now, grouped by what implies a different ACTION rather than by a category already in a column), **the register's own craft** (a column header treated as CHROME a step lighter than row metadata, sentence case in the table header too, and a supporting line one RUNG BELOW the line it supports rather than a fixed size), **identity marks** (a mark that looks the same on every row carries nothing — `Avatar` derives its hue from the name and takes circle/square for person vs organization; the palette is ordered by contrast, not spectrum, and never paints a person red or amber), **where the accent goes** ("which of these" — a selected row, an active filter; never DATA and never the focus ring, while a page-scale position marker like an active TAB takes `primary`, the ink the kit already spends on "this is on"; and selection must not share a wash with hover), **theming is an app-level ESCAPE HATCH, not a product surface** (`applyLoticsTheme({ … })` once at boot, before `mount`, writing the `--lotics-*` roles on the document root; nothing in the platform writes a theme, and `apps.theme.color` is the launcher icon only — the five `var()` roles plus the three font rungs ARE the whole mechanism, and wrapping a component cannot replace them because RN-Web writes `fontFamily` per element and background/border do not inherit), color discipline, **typography** (the ramp is DATA in `type_ramp`, one table both platforms derive from; leading and tracking are baked per rung and a hand-set `letterSpacing` is always a second copy of the curve), whitespace, and how to TEST an overlay component (a `Popover`-backed surface never mounts under jsdom). |
+| [docs/composition.md](./docs/composition.md) | The design-language contract — canvas + content column, heading altitude (incl. eyebrow vs group lead — a label is one or the other), banded cards, register vs inset rows (incl. the register laws a row centres its cells by: every cell a FIXED height, a pressable cell on the shared hover token, a column sized by what it carries), the button ladder and **what underlined text may mean** (it GOES somewhere or REVEALS something — never mutates; blue leaves the surface, muted stays on it, and the one in-prose disclosure exception is scoped there), master-detail `Drawer` on a LIST screen vs a child collection's row EXPANDING inside a record, view controls, RECORD EXTENT (one page, sections scrolled to and never routed to), **the register's rhythm** (no hairline between rows — their own height and the hover wash separate them; the register's one line is the band capping the columns, because that is the break whitespace cannot state. Density is `TableRow`'s `minHeight`, never a mode), **a register that TRIAGES** (`TableGroup` — titled bands ordered by what needs the reader now, grouped by what implies a different ACTION rather than by a category already in a column), **the register's own craft** (a column header treated as CHROME a step lighter than row metadata, sentence case in the table header too, and a supporting line one RUNG BELOW the line it supports rather than a fixed size — plus the half that rule was missing: every SUBJECT on one row starts at the same rung, the subject leads by WEIGHT and its identity mark rather than by size, and whether the supporting line drops a rung is decided by what else separates the pair), **identity marks** (a mark that looks the same on every row carries nothing — `Avatar` derives its hue from the name and takes circle/square for person vs organization; the palette is ordered by contrast, not spectrum, and never paints a person red or amber), **where the accent goes** ("which of these" — a selected row, an active filter; never DATA and never the focus ring, while a page-scale position marker like an active TAB takes `primary`, the ink the kit already spends on "this is on"; and selection must not share a wash with hover), **theming is an app-level ESCAPE HATCH, not a product surface** (`applyLoticsTheme({ … })` once at boot, before `mount`, writing the `--lotics-*` roles on the document root; nothing in the platform writes a theme, and `apps.theme.color` is the launcher icon only — the five `var()` roles plus the three font rungs ARE the whole mechanism, and wrapping a component cannot replace them because RN-Web writes `fontFamily` per element and background/border do not inherit), color discipline, **typography** (the ramp is DATA in `type_ramp`, one table both platforms derive from; leading and tracking are baked per rung and a hand-set `letterSpacing` is always a second copy of the curve), whitespace, and how to TEST an overlay component (a `Popover`-backed surface never mounts under jsdom). |
 | [docs/reviewing.md](./docs/reviewing.md) | **Reviewing a screen you built** — the other docs say what good looks like; this one says how to find out whether you achieved it, because "it looks fine" is the same claim as "it should work" made with the same evidence. Measure, never eyeball: render it, extract computed values, let the table show the defect. Two GATES that outrank every treatment question (**SUBTRACT** — what question does this element answer, and count FACTS not elements; **RIGHT CONTROL** — name the species before treating it), then 10 probes each naming what to COLLECT and the SIGNATURE in the numbers: type inventory (range, singletons, the label/value shrink war), ground+border+radius across siblings, what each RULE separates, gap RATIOS, the state diff (paint may change, geometry may not), alignment drift (incl. a centred child that moves while its container measures identical), the surface walk (open it, press it, read the settled string), the DATA probe (what is really in the table — incl. grepping rendered text for internal ids), the ABSENCE pass that catches "bland", and microcopy. Plus the extraction snippets, what measurement cannot see, and how to act on a finding (fix the CLASS, and never resolve one with "the docs say X"). |
 | [docs/testing.md](./docs/testing.md) | Driving the kit in a browser — the three anatomies where the a11y tree says one thing and a driver must do another: a `PressDoor` row whose named button always intercepts pointer events (by design), portalled overlays that render at the top of the DOM, and custom pointer drag that `dragTo` cannot move. |
 | [docs/templates.md](./docs/templates.md) | The map of `examples/tpl_*.tsx` — what shape each template solves and which to start from (copy + adapt, never import) — plus the record-surface composition rules (pipeline order, static shape, decision budget) and the ACTIVITY shape — a communications feed where the row's label is the GIST and the body varies by medium, one anatomy rather than a row type per kind. |

package/docs/catalog.md

@@ -400,7 +400,9 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
 
 - **`text`** — the `Text` primitive (never raw `div`/`span`/`fontSize`): `size` `xs`–`xxxl`
   (the heading ramp: `xl` = `##` section title, `xxl` = `#` page/record title, `xxxl` = hero
-  numbers), `weight`, `color`, alignment, tabular numerals.
+  numbers), `weight`, `color`, alignment, tabular numerals. **`leading="tight"`** sets the line
+  box for a STACKED PAIR rather than for prose — a subject over its supporting line, a value over
+  its annotation; see composition.md, which also covers the `gap` that goes with it.
 - **`markdown`** — `Markdown`: the single canonical markdown renderer for chat, apps, and
   `AgentRun`; rich GFM markdown on web with copyable tables, plain-text on
   native; takes a markdown `children` string. **`variant`** decides whose type

package/docs/composition.md

@@ -1165,6 +1165,51 @@ wider pair then reads as though its second line shrank rather than stepped. Pick
 relative to the primary and the pair scales together. The probe: collect every primary/supporting
 pair on the screen and divide. A spread in the RATIOS is the finding, not a spread in the sizes.
 
+**Every SUBJECT on one row starts at the same rung — a register's is `sm`, and a value in any
+other column is `sm` too.** "One rung below" is only half a rule: it constrains the STEP and says
+nothing about where the pair starts, so a subject placed a rung high stays compliant while dragging
+its whole column above the rest. Measured on a register that read as disproportionate: the identity
+column ran 16/14 while the column beside it ran 14/12 — both correctly "one rung apart", one whole
+rung out of step with each other, and the first column shouted while everything else receded.
+
+**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.
+
+**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
+the size step is a second, and a second is only worth its cost where nothing else is doing the job:
+
+- The subject carries `medium`, or the row opens with an identity mark — the supporting line stays
+  at **`sm` muted**. Weight and the mark separate the pair; colour finishes it, and the line keeps
+  body size. This matters most where that line is the DISAMBIGUATOR (which person, at which
+  company): `xs` demotes content the reader needs, and 12px is where stacked diacritics crowd.
+- Both lines are regular weight and colour is the only thing between them — the supporting line
+  drops to **`xs`**. Measured: a date over its touch count, promoted to one rung, stopped reading
+  as a value and its annotation and started reading as two peers. The step is what makes them a
+  pair.
+
+Deciding from the CONTENT instead — prose gets `sm`, reference data gets `xs` — fails on a line
+that holds both. An account name beside a contract number is one line, and it takes ONE rung: the
+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.
+
+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
+line box already contributes 3px above and below, giving 6px between the two, and a `gap` on top
+is a third source of space between lines that are meant to read as one. Measured after: the
+identity stack sits at exactly the mark's 40, and every pair on the screen carries the same 6px.
+
+Running text keeps prose leading. The default is for paragraphs, and `.ui-markdown` renders at it.
+
 **A CONTROL riding a text line must not resize that line.** A control is taller than the text it
 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

package/examples/tpl_attendance.tsx

@@ -166,8 +166,11 @@ function TuanRow({ nv }: { nv: NhanVien }) {
     <Accordion>
       <AccordionHeader accessibilityLabel={`Week detail for ${nv.ten}`}>
         <View style={{ flex: 1, gap: 2 }}>
-          <Text size="sm" weight="medium" numberOfLines={1}>{nv.ten}</Text>
-          <Text size="xs" color="muted" numberOfLines={1}>{nv.chucVu}</Text>
+          <Text size="sm" weight="medium" leading="tight" numberOfLines={1}>{nv.ten}</Text>
+          {/* Body size: `medium` above already separates the pair, so the rung
+              down would be a second demotion on the line that says WHICH
+              person this is. */}
+          <Text size="sm" color="muted" leading="tight" numberOfLines={1}>{nv.chucVu}</Text>
         </View>
         <View style={{ flexDirection: "row", gap: 10 }}>
           {nv.tuan.map((ngay, i) => <DayCell key={NGAY_TUAN[i]} ngay={ngay} />)}

package/examples/tpl_dashboard.tsx

@@ -503,9 +503,11 @@ export function TplDashboard() {
                 <Avatar name={kh.ten} size="md" />
                 <View style={{ flex: 1, gap: 0, alignItems: "flex-start" }}>
                   <Peek accessibilityLabel={`Customer profile for ${kh.ten}`} content={<KhachPeek kh={kh} />}>
-                    <Text size="sm" weight="medium" numberOfLines={1}>{kh.ten}</Text>
+                    <Text size="sm" weight="medium" leading="tight" numberOfLines={1}>{kh.ten}</Text>
                   </Peek>
-                  <Text size="xs" color="muted" numberOfLines={1}>{kh.nganh}</Text>
+                  {/* Body size — the mark and the name's weight separate this
+                      pair; see composition.md on what decides the rung. */}
+                  <Text size="sm" color="muted" leading="tight" numberOfLines={1}>{kh.nganh}</Text>
                 </View>
                 <Sparkline data={kh.trend} width={84} height={24} color={kh.trend[5] >= kh.trend[0] ? solid("emerald") : solid("red")} />
                 <Text size="sm" weight="medium" tabular>{formatMoney(kh.doanhThu)}</Text>

package/examples/tpl_item_list.tsx

@@ -223,90 +223,36 @@ function HoSoRow({ hs, ordinal, daThu, selected, marked, selectable, onToggle, o
       trailing={<ActionMenu items={menuFor(hs, daThu)} accessibilityLabel={`Actions for ${hs.ma}`} />}
     >
       <TableCell>
-        {/* THE IDENTITY MARK leads the cell that names the row. A register of
-            entities without one is N rows of grey text a reader scans linearly;
-            with one, the eye lands on the row it wants by colour and letter
-            before it reads a word. `Avatar` derives its hue from the name, so
-            the marks differ across rows without anyone configuring anything —
-            the failure mode to avoid is N identical marks, which is the largest
-            and brightest thing on the row carrying no information at all.
-
-            It sits in the SUBJECT'S CELL, not the `leading` slot: `leading`
-            already holds the selection checkbox, and those two are different
-            jobs — one is what the row IS, the other is something you are doing
-            to it. Stacking them in one slot reads as a single compound control.
-
-            `lg` because the customer is what this row is ABOUT. A person who is
-            one FIELD among columns (the owner, below) takes `md`; see
-            `avatar_size.ts`, which owns that rule.
-
-            ONE SHAPE for the whole register. `Avatar` takes `square` for an
-            organization, but that distinction earns its place only where a
-            surface mixes entity TYPES and the reader acts on which is which.
-            Here every row is a record, and whether the customer is a company is
-            not something the reader does anything with — so a column of mixed
-            circles and squares reads as an inconsistency rather than as
-            information, which is exactly how it gets reported. */}
+        {/* The mark goes in the SUBJECT'S cell, not the `leading` slot —
+            `leading` holds the selection checkbox, and "what this row is" and
+            "something you are doing to it" in one slot read as a single
+            compound control. Rung and shape per composition.md § Identity. */}
         <View style={{ flexDirection: "row", alignItems: "center", gap: 10, alignSelf: "stretch" }}>
           <Avatar name={hs.khach} size="lg" />
-          <View style={{ gap: 2, flex: 1, minWidth: 0 }}>
+          <View style={{ gap: 0, flex: 1, minWidth: 0 }}>
             {/* The name takes the row, the thread pins right. A comment count is
                 the one thing on this row that is about PEOPLE talking rather than
                 the record's own state, so it sits apart from the values below it
                 instead of joining them on the supporting line. */}
             <View style={{ flexDirection: "row", alignItems: "center", gap: 8 }}>
-              <Text size="sm" weight="medium" numberOfLines={1} style={{ flexShrink: 1 }}>{hs.khach}</Text>
+              <Text size="sm" weight="medium" leading="tight" numberOfLines={1} style={{ flexShrink: 1 }}>{hs.khach}</Text>
               {/* Rendered only where a thread EXISTS — a zero on every quiet row is a
                   column of noise that trains the eye to skip where the signal appears. */}
               {hs.binhLuan > 0 ? <CommentsButton count={hs.binhLuan} subject={hs.khach} onPress={onOpenComments} /> : null}
             </View>
-            {/* Every value on this row is selectable — that is what a register owes
-                its reader, and it costs no chrome. The phone gets a CONTROL on top
-                because it is the one value copied often enough to earn one (a desk
-                pastes it into a message, a rep dials it). The verb rides the value
-                inside its own cell: the trailing gutter belongs to the ⋯, and with
-                two values in this cell it would have nothing to name.
-
-                UNCONDITIONAL, and that is the load-bearing part of this shape. A
-                row centres its cells, so a supporting line that appears only when
-                its field is set makes this cell two heights, and the NAME above it
-                then sits at two different offsets down the column while every row
-                still measures the same. That is why the values here are ones every
-                record carries — a key, a contact — rather than whichever field is
-                most interesting: the line has to be honest on every row to be
-                reservable at all. */}
-            {/* HEIGHT PINNED TO THE xs LINE BOX (18), because this line carries a
-                CONTROL. `CopyButton` at `sm` is 24 — sized to sit beside `sm`
-                text, per its own doc — so on an `xs` line it made the row 24 and
-                `alignItems: "center"` spent 3 of those px above the text. The
-                supporting line then started 5px under the name while the Fee
-                column's identical primary-over-supporting pair, which carries no
-                control, started 2px under its own. Same shape, two treatments,
-                and the reason (one of them has a button) is invisible to a
-                reader — which is the whole test.
-
-                Pinning the row to the text's line box lets the 24px hit area
-                overflow it without moving the text. Any verb riding a supporting
-                line needs this; a control must not resize the line it sits on. */}
-            <View style={{ flexDirection: "row", alignItems: "center", gap: 2, height: 18 }}>
-              {/* The KEY, muted, on the supporting line — at most this, never a
-                  column and never the row's name.
-
-                  It does NOT shrink. A key is quoted whole or it is not a key: a
-                  phone number clipped to "(555) 384-7…" is still recognisably a
-                  number the reader can widen the column to finish, while
-                  "RC-2026-0…" is unusable — it is the exact string a desk reads
-                  out. So the fixed-length identifier holds its width and the phone
-                  gives way, which is also the right order of loss: the phone has a
-                  Copy control beside it that hands over the full value regardless. */}
-              <Text size="xs" color="muted" tabular numberOfLines={1} style={{ flexShrink: 0 }}>{hs.ma}</Text>
-              {/* A GAP, not a middot. Two facts of different kinds sat either side
-                  of a ` · ` here, which is the separator this kit bans outright —
-                  punctuation claiming a relation it refuses to name, and dropped
-                  entirely by a screen reader. Spacing separates them without
-                  asserting anything, and the two are already told apart by shape:
-                  one is a key, one is a number with a Copy control on it. */}
-              <Text size="xs" color="muted" tabular numberOfLines={1} style={{ flexShrink: 1, marginLeft: 8 }}>{hs.dienThoai}</Text>
+            {/* UNCONDITIONAL — the load-bearing part of this shape. A row centres
+                its cells, so a supporting line that renders only when its field is
+                set makes this cell two heights, and the name above it then sits at
+                two different offsets down the column while every row still measures
+                the same. So the values here are ones every record carries. */}
+            <View style={{ flexDirection: "row", alignItems: "center", gap: 2 }}>
+              {/* The key does NOT shrink. Quoted whole or it is not a key: a phone
+                  clipped to "(555) 384-7…" is still a number you can widen the
+                  column to finish, while "RC-2026-0…" is unusable. So the
+                  fixed-length identifier holds its width and the phone gives way —
+                  and the phone has a Copy control that hands over the full value. */}
+              <Text size="sm" color="muted" tabular leading="tight" numberOfLines={1} style={{ flexShrink: 0 }}>{hs.ma}</Text>
+              <Text size="sm" color="muted" tabular leading="tight" numberOfLines={1} style={{ flexShrink: 1, marginLeft: 8 }}>{hs.dienThoai}</Text>
               <CopyButton value={hs.dienThoai} label="Copy phone number" />
             </View>
           </View>
@@ -378,12 +324,10 @@ function RecordDrawer({ hs, daThu: _daThu, onPaid: _onPaid, onClose, onPrev, onN
       position={canGoBack ? undefined : position}
     >
       <Screen route="">
-        {/* THE RECORD SURFACE, not a copy of it. tpl_record renders in `drawer`
-            chrome: same sections, same order, same rules — the rail and the docked
-            discussion collapse (a Drawer has no gutters), and the thread joins the
-            reading order as its last section. Rendering the component is what keeps
-            the two identical; the hand-built workspace that used to live here is
-            how they drifted — a checklist on this side, a pipeline on that one. */}
+        {/* THE RECORD SURFACE, not a copy of it — `tpl_record` in `drawer`
+            chrome: same sections, same order, same rules. The rail and the docked
+            discussion collapse (a Drawer has no gutters) and the thread joins the
+            reading order as its last section. */}
         <TplRecord chrome="drawer" code={hs.ma} openSection={openSection} />
       </Screen>
       <Screen route="/record/:ma">{(p) => <LinkedRecordScreen ma={p.ma} />}</Screen>
@@ -423,15 +367,9 @@ function LinkedRecordScreen({ ma }: { ma: string }) {
             <DetailRow label="Fee">
               <InlineNumberInput value={fee} onSave={persist(setFee)} min={0} format={(v) => (v == null ? "" : formatMoney(v))} accessibilityLabel="Fee" />
             </DetailRow>
-            {/* FILES AS A FIELD — the `Inline*` member that used to be missing,
-                so a record's documents got hand-rolled per app as `FileRows` +
-                `pickFiles` + a `Button`, each copy re-deriving the same
-                decisions and usually missing `InlineSlot` (which is what keeps
-                this value column a column rather than two left edges).
-
-                The MANY case: `multiple` defaults true, the CTA becomes
-                "Add document" once something is attached, and the host APPENDS.
-                `tpl_record` shows the single-file case, where the verb is
+            {/* FILES AS A FIELD, the MANY case: `multiple` defaults true, the CTA
+                becomes "Add document" once something is attached, and the host
+                APPENDS. `tpl_record` shows the single-file case, where the verb is
                 replace — see the table in data_entry.md §InlineFiles. */}
             <DetailRow label="Documents">
               <InlineFiles
@@ -1049,19 +987,14 @@ function EnterDataDialog({ open, onOpenChange, seedDocs, onCreate, onCreateMany
           </DialogFooter>
         ) : phase === "analyze" || phase === "clarify" || phase === "running" ? (
           <DialogFooter>
-            {/* EVERY run-driven phase, not just `clarify`. This branch used to
-                name that one phase, because `AgentRunActions` only ever held the
-                wizard and there was nothing to show while the feed streamed —
-                so the two streaming phases had an empty footer and no way to
-                stop. The component's contract is that the HOST mounts it
-                wherever the run drives the surface and the RUN decides what it
-                holds; gating it by phase out here duplicates that decision and
-                gets it wrong the moment the run learns a new one.
-
-                `onStop` is the SAME handler the pane's `onCancel` gets: stopping
-                a streaming run and abandoning a parked question both put the
-                operator back at the intake they started from, with their files
-                and their answers still there to retry from. */}
+            {/* EVERY run-driven phase, not just `clarify`. The contract is that the
+                HOST mounts this wherever the run drives the surface and the RUN
+                decides what it holds; gating it by phase out here duplicates that
+                decision and gets it wrong the moment the run learns a new phase.
+
+                `onStop` is the SAME handler the pane's `onCancel` gets: stopping a
+                stream and abandoning a parked question both put the operator back
+                at the intake, files and answers intact. */}
             <AgentRunActions run={run} onStop={() => setPhase("intake")} />
           </DialogFooter>
         ) : phase === "preview" ? (

package/examples/tpl_record.tsx

@@ -4178,8 +4178,10 @@ export function TplRecord({ chrome = "page", code = "RC-2026-0418", openSection
                         it on line 2, in one cell rather than two columns. */}
                     <TableCell>
                       <View style={{ gap: 2 }}>
-                        <Text size="sm" weight="medium" numberOfLines={1}>{f.name || "—"}</Text>
-                        <Text size="xs" color="muted" numberOfLines={1}>
+                        <Text size="sm" weight="medium" leading="tight" numberOfLines={1}>{f.name || "—"}</Text>
+                        {/* Body size: the subject carries `medium`, which is what
+                            makes this a pair rather than two peers. */}
+                        <Text size="sm" color="muted" leading="tight" numberOfLines={1}>
                           {f.party || (f.direction === "charge" ? "Charge" : "Cost")}
                         </Text>
                       </View>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lotics/ui",
-  "version": "43.5.0",
+  "version": "43.7.0",
   "type": "module",
   "exports": {
     "./vite": {

package/src/markdown.css

@@ -8,7 +8,7 @@
      carried before, written as an em so it scales with the rung instead of being
      a flat pixel value that drifts at every other size — and now ONE number
      shared with `Text` and the inputs rather than markdown's private one. */
-  letter-spacing: -0.028em;
+  letter-spacing: -0.006em;
   color: rgba(24, 24, 27, 1);
 }
 

package/src/metric.tsx

@@ -1,6 +1,7 @@
 import { View, StyleSheet, type TextStyle } from "react-native";
 import { Text } from "./text";
 import { colors } from "./colors";
+import { getTextColor } from "./text_utils";
 import { formatCompactNumber, formatMoney } from "./format_money";
 import { useMemo } from "react";
 
@@ -46,11 +47,6 @@ const TREND_UP = "↑";
 const TREND_DOWN = "↓";
 const TREND_FLAT = "→";
 
-const TONE_COLOR: Record<Exclude<MetricTone, "default">, string> = {
-  warning: colors.amber[600],
-  danger: colors.red[600],
-};
-
 export function Metric(props: MetricProps) {
   const {
     value,
@@ -107,7 +103,17 @@ export function Metric(props: MetricProps) {
           // none. (Tabular figures do not need it reset either — letter-spacing
           // adds a constant to every advance, so a tabular column stays aligned.)
           { fontVariantNumeric: "tabular-nums" } as TextStyle,
-          tone === "default" ? undefined : { color: TONE_COLOR[tone] },
+          // THE VALENCE INK COMES FROM `Text`, not a second map here. This kept
+          // its own — amber-600 and red-600 — while `getTextColor` answers
+          // amber-700 and red-900 for the same two words, so one `tone="warning"`
+          // rendered two different ambers depending on whether the number was a
+          // `Metric` or the sentence beside it.
+          //
+          // And the divergence was not cosmetic: amber-600 measures 3.19:1 on
+          // white, under the 4.5:1 AA floor for normal text, which is exactly
+          // what `getTextColor`'s own comment says the 700 rung exists to clear.
+          // A summary figure is the smallest, most glanced-at text on a register.
+          tone === "default" ? undefined : { color: getTextColor(tone) },
         ]}
       >
         {displayValue}

package/src/table.tsx

@@ -379,9 +379,19 @@ export type TableRowProps = {
    *  before `trailing`; stacked mode: the content's bottom line, right-aligned — an action
    *  reads at content scale, not as row chrome. Reserve Table `trailing` for it. */
   action?: ReactNode;
-  /** Min row height (register mode; stacked rows size to their content).
-   *  Defaults to the Table's rhythm — 52 `ruled`, 72 `airy` — so one prop on the
-   *  Table changes the whole register and no caller has to restate the beat. */
+  /**
+   * Min row height — a FLOOR, not a fixed height: a taller cell grows the row,
+   * so a two-line identity cell or a figure with a bar under it needs no
+   * override to fit. (Stacked rows size to their content and ignore this.)
+   *
+   * Defaults to `ROW_HEIGHT` (72), the register's rhythm. **Reach for this only
+   * when a surface genuinely needs more DENSITY than the beat** — and know that
+   * a number written against an older default silently becomes a shrink: an app
+   * carrying `minHeight={64}` from when the default was 52 now pulls that one
+   * register below every other on the screen, and it reads as cramped rather
+   * than as dense. If the reason you overrode it was "the content did not fit",
+   * delete the override.
+   */
   minHeight?: number;
   /**
    * The row's detail, revealed BENEATH it when `expanded` — the alternative to

package/src/text.css

@@ -15,25 +15,21 @@
  * single line, so every label, value and control gained ~4px of line box.
  * Density is what was traded for the rhythm.
  *
- * TRACKING: NEGATIVE throughout, steepening as the type grows.
+ * `[data-text-leading="tight"]` buys that density back where the text is a
+ * STACKED PAIR rather than prose — the box becomes `size + 6`, which is what
+ * `xs` has always been. See `TYPE_LEADING_TIGHT_*`; a rung already at or below
+ * that keeps its own number, so only the rungs that left it for a prose ratio
+ * have a rule here.
  *
- * The body rung is ANCHORED on -0.028em — the -0.4px this product already set on
- * `.ui-markdown` and on six inputs, expressed as an em so it scales. That value
- * is the product's own, arrived at by reading it in Vietnamese every day, and it
- * is what the rest of the ramp is derived FROM rather than something imported
- * from another design system. Inter is drawn generously at default tracking, so
- * untracked body reads loose beside it.
+ * TRACKING: Inter's own dynamic-metrics curve, evaluated per rung — the
+ * derivation and the function live in `type_ramp.ts`. Never nudged by eye: the
+ * typeface's designer has already answered this for this typeface, and a screen
+ * that reads too tight or too loose wants a size or a leading change instead.
+ * Zero at 12px, steepening as the type grows.
  *
- * Larger type takes proportionally more negative tracking, which is why the curve
- * steepens: what looks right at 14px looks slack at 32px.
- *
- * `xs` is the one rung held back (-0.02em, not the full body value). 12px is
- * where Vietnamese stacked diacritics (ự, ộ, ế, ệ) and Inter's `1`/`l`/`i` come
- * closest to colliding, and tightening is the direction that makes both worse.
- *
- * `.ui-markdown` and the inputs (`INPUT_LETTER_SPACING`) mirror the body rung
- * exactly. All three are ONE contract on both axes — leading above, tracking here
- * — and a value moved on one surface alone is the seam re-opening.
+ * `.ui-markdown` and the inputs (`INPUT_LETTER_SPACING`) sit on the body rung
+ * exactly. All three are ONE contract on both axes — leading above, tracking
+ * here — and a value moved on one surface alone is the seam re-opening.
  *
  * Inter stylistic alternates: `cv11` (single-storey `a`), `ss01` (alternate
  * `1`), `ss03` (alternate `g`) — disambiguates similar glyphs without
@@ -46,42 +42,56 @@
 [data-text-size="xs"] {
   font-size: 12px;
   line-height: 18px;
-  letter-spacing: -0.02em;
+  letter-spacing: 0em;
 }
 [data-text-size="sm"] {
   font-size: 14px;
   line-height: 24px;
-  letter-spacing: -0.028em;
+  letter-spacing: -0.006em;
 }
 [data-text-size="md"] {
   font-size: 16px;
   line-height: 26px;
-  letter-spacing: -0.03em;
+  letter-spacing: -0.011em;
 }
 [data-text-size="lg"] {
   font-size: 18px;
   line-height: 28px;
-  letter-spacing: -0.032em;
+  letter-spacing: -0.014em;
 }
 /* Display ramp — the heading ladder: xl = `##` (section), xxl = `#`
    (page/record title), xxxl = hero numbers. */
 [data-text-size="xl"] {
   font-size: 22px;
   line-height: 28px;
-  letter-spacing: -0.035em;
+  letter-spacing: -0.018em;
 }
 [data-text-size="xxl"] {
   font-size: 28px;
   line-height: 34px;
-  letter-spacing: -0.038em;
+  letter-spacing: -0.021em;
 }
 [data-text-size="xxxl"] {
   font-size: 32px;
   line-height: 38px;
-  letter-spacing: -0.04em;
+  letter-spacing: -0.022em;
 }
 
 /* Refer to `use_screen_size` for breakpoints */
+/*
+ * TIGHT — a stacked pair, not prose. Only the rungs whose prose leading exceeds
+ * `size + 6` need a rule; the rest already sit at or below it and inherit.
+ */
+[data-text-size="sm"][data-text-leading="tight"] {
+  line-height: 20px;
+}
+[data-text-size="md"][data-text-leading="tight"] {
+  line-height: 22px;
+}
+[data-text-size="lg"][data-text-leading="tight"] {
+  line-height: 24px;
+}
+
 @media screen and (min-width: 768px) {
   [data-text-size="xs"] {
     font-size: 12px;
@@ -111,4 +121,19 @@
     font-size: 48px;
     line-height: 52px;
   }
+  [data-text-size="sm"][data-text-leading="tight"] {
+    line-height: 20px;
+  }
+  [data-text-size="md"][data-text-leading="tight"] {
+    line-height: 22px;
+  }
+  [data-text-size="lg"][data-text-leading="tight"] {
+    line-height: 26px;
+  }
+  [data-text-size="xl"][data-text-leading="tight"] {
+    line-height: 30px;
+  }
+  [data-text-size="xxl"][data-text-leading="tight"] {
+    line-height: 38px;
+  }
 }

package/src/text.tsx

@@ -2,7 +2,7 @@ import "./text.css";
 import React from "react";
 import { Platform, Text as RNText, TextProps as RNTextProps, StyleSheet, type TextStyle } from "react-native";
 import { fontFamilyDisplay } from "./display_font";
-import { TYPE_RAMP_MOBILE, trackingPx, type TypeRungName } from "./type_ramp";
+import { TYPE_LEADING_TIGHT_MOBILE, TYPE_RAMP_MOBILE, trackingPx, type TypeRungName } from "./type_ramp";
 import {
   fontFamilyMedium,
   fontFamilyRegular,
@@ -26,6 +26,19 @@ export interface TextProps {
    * how one screen ends up in a different face from the next.
    */
   family?: "display";
+  /**
+   * `tight` sets the rung's line box for a STACKED PAIR instead of for prose —
+   * a subject over its supporting line, a value over its annotation. The two are
+   * one object, and prose leading puts enough empty box between them to read as
+   * two; beside a mark the pair also grows taller than the mark.
+   *
+   * Set it on BOTH lines of the pair, not just the second: the box belongs to
+   * each line, so tightening one leaves the stack lopsided.
+   *
+   * Not for running text. A paragraph keeps prose leading, which is what the
+   * default is for and what `.ui-markdown` renders at.
+   */
+  leading?: "tight";
   align?: TextAlign;
   weight?: TextWeight;
   numberOfLines?: number;
@@ -86,6 +99,7 @@ export function Text(props: TextProps) {
     size = "sm",
     weight = "regular",
     family,
+    leading,
     numberOfLines,
     decoration,
     tabular,
@@ -105,7 +119,12 @@ export function Text(props: TextProps) {
 
   // On web, responsive font sizes are applied via CSS using data-text-size attribute.
   // On native, sizes are applied via StyleSheet.
-  const webProps = Platform.OS === "web" ? { dataSet: { textSize: size } } : undefined;
+  // `textLeading` is only emitted when tight — an absent attribute is the prose
+  // default, so no rule has to restate the ramp to say "unchanged".
+  const webProps =
+    Platform.OS === "web"
+      ? { dataSet: leading != null ? { textSize: size, textLeading: leading } : { textSize: size } }
+      : undefined;
 
   return (
     <RNText
@@ -127,6 +146,9 @@ export function Text(props: TextProps) {
         // to, which on web was dead weight the cascade overrode and on native
         // was the reason the curve never reached the mobile app.
         Platform.OS !== "web" && sizeStyles[size],
+        // AFTER the rung, which set the prose leading — this replaces that one
+        // number and leaves size and tracking alone.
+        Platform.OS !== "web" && leading === "tight" && tightStyles[size],
         styles[weight],
         // AFTER the weight, because the weight ladder sets a family too — each
         // rung is a distinct Inter family, not a `font-weight` — so the display
@@ -186,6 +208,16 @@ const sizeStyles = StyleSheet.create(
   ) as Record<TypeRungName, TextStyle>,
 );
 
+/** The tight line box, same source, same reason there is no second table. */
+const tightStyles = StyleSheet.create(
+  Object.fromEntries(
+    (Object.keys(TYPE_LEADING_TIGHT_MOBILE) as TypeRungName[]).map((rung) => [
+      rung,
+      { lineHeight: TYPE_LEADING_TIGHT_MOBILE[rung] },
+    ]),
+  ) as Record<TypeRungName, TextStyle>,
+);
+
 const styles = StyleSheet.create({
   // Text alignment styles
   left: {

package/src/text_utils.ts

@@ -53,24 +53,22 @@ export function getTextColor(color?: TextColor): string {
 export { fontFamilyRegular, fontFamilyMedium, fontFamilySemiBold } from "./font_family";
 
 /**
- * Tracking for input text — the BODY rung of the curve in `text.css` (-0.028em),
- * in px because React Native's `letterSpacing` has no em unit. -0.4 IS that rung
- * at 14px; the ramp was anchored on this value rather than the other way round.
+ * Tracking for input text — the `sm` rung of Inter's curve (`TYPE_TRACKING.sm`,
+ * -0.006em) as px, because React Native's `letterSpacing` has no em unit.
  *
- * Six inputs each hard-coded it separately before this. The number did not
- * change; what changed is that there is now one of it, next to the line height,
- * because they are the same contract — an input is running text and sits at the
- * body rhythm on both axes.
+ * Six inputs each hard-coded their own value before this; there is one of it now,
+ * next to the line height, because they are the same contract — an input is
+ * running text and sits at the body rhythm on both axes.
  *
  * NOT derived, deliberately, unlike the line heights beside it. An input is 14px
  * on desktop and 16px on mobile, so no single px value is the em at both sizes —
  * computing one from a rung would pick a size and call the result exact. Written
- * out, it stays honestly an approximation: right at 14px, a hair light at 16px
- * (-0.4 against -0.45). `type_ramp.test.ts` pins it to within a hundredth of the
- * `sm` rung so it cannot drift away from the curve it belongs to; the exact form
- * (an `em` string through RN's style types) is not portable.
+ * out, it stays honestly an approximation: right at 14px, a hair light at 16px.
+ * `type_ramp.test.ts` pins it to within a hundredth of the `sm` rung so it cannot
+ * drift away from the curve it belongs to; the exact form (an `em` string through
+ * RN's style types) is not portable.
  */
-export const INPUT_LETTER_SPACING = -0.4;
+export const INPUT_LETTER_SPACING = -0.08;
 
 /**
  * Line height for mobile web — the input is 16px there (to defeat iOS-Safari

package/src/type_ramp.ts

@@ -24,18 +24,9 @@
  * every label, value and control gained about 4px of line box. Density was
  * traded for rhythm.
  *
- * TRACKING: negative throughout, steepening as the type grows. The body rung is
- * ANCHORED on -0.028em — the -0.4px this product already set on `.ui-markdown`
- * and on its inputs, expressed as an em so it scales. That value is the
- * product's own, arrived at by reading it in Vietnamese every day, and the rest
- * of the ramp is derived FROM it rather than imported from another design
- * system. Inter is drawn generously at default tracking, so untracked body reads
- * loose beside it, and what looks right at 14px looks slack at 32px.
- *
- * `xs` is the one rung held back (-0.02em rather than the full body value). 12px
- * is where Vietnamese stacked diacritics (ự, ộ, ế, ệ) and Inter's `1`/`l`/`i`
- * come closest to colliding, and tightening is the direction that makes both
- * worse.
+ * TRACKING: Inter's own dynamic-metrics curve, evaluated per rung — see
+ * `TYPE_TRACKING`. Near zero at 12px and steepening as the type grows, which is
+ * the shape the face is drawn for. It is derived, not chosen.
  *
  * Tracking is stated ONCE, in em, and is not repeated per breakpoint: an em
  * scales with the font size, so the same value is correct at both. Only the
@@ -75,15 +66,71 @@ export const TYPE_RAMP_DESKTOP = {
   xxxl: { size: 48, leading: 52 },
 } as const satisfies Record<keyof typeof TYPE_RAMP_MOBILE, TypeRung>;
 
-/** Tracking per rung, in em. Negative at every rung — see the header. */
+/**
+ * TIGHT LEADING — the same rungs, set for a STACKED PAIR rather than for prose.
+ *
+ * `Text` defaults to the prose leading above, and a stacked pair is not prose: a
+ * subject over its supporting line is ONE object, and prose leading puts ~10px of
+ * empty box between the two so it reads as two. Beside a 40px mark the pair also
+ * measures 50 and overhangs it, which is the visible form of the same fault.
+ *
+ * DERIVED, not chosen: it is `size + 6`, capped at the rung's own prose leading
+ * so a rung already tighter than that keeps what it has. That constant is not
+ * invented here — `xs` is 12/18, and has always BEEN `size + 6`. The body rungs
+ * are the ones that leave it for a prose ratio, so this is the smallest rung's
+ * existing rule extended up the ladder rather than a second opinion about
+ * leading. The display rungs mostly already sit at or below it and so are
+ * unchanged; the cap is what keeps `xxxl` from being LOOSENED by a rule meant to
+ * tighten.
+ */
+const TIGHT_LEAD = 6;
+
+function tighten(ramp: Record<TypeRungName, TypeRung>): Record<TypeRungName, number> {
+  return Object.fromEntries(
+    (Object.keys(ramp) as TypeRungName[]).map((rung) => [
+      rung,
+      Math.min(ramp[rung].leading, ramp[rung].size + TIGHT_LEAD),
+    ]),
+  ) as Record<TypeRungName, number>;
+}
+
+/** Tight leading below 768px, and on native. */
+export const TYPE_LEADING_TIGHT_MOBILE = tighten(TYPE_RAMP_MOBILE);
+
+/** Tight leading at 768px and above. */
+export const TYPE_LEADING_TIGHT_DESKTOP = tighten(TYPE_RAMP_DESKTOP);
+
+/**
+ * Tracking per rung, in em — INTER'S OWN dynamic metrics, not a house curve.
+ *
+ * Inter publishes the tracking it is drawn for as a function of size:
+ *
+ *     tracking(z) = a + b · e^(c · z)      a = -0.0223, b = 0.185, c = -0.1745
+ *
+ * evaluated at each rung's base size and rounded to a thousandth. The values
+ * below ARE that function; they are not tuned by eye and should not be. If a
+ * screen reads too tight or too loose, the answer is a size or a leading change,
+ * not a nudge here — the typeface's designer has already answered this question
+ * for this typeface, and second-guessing it per-rung is how a ramp ends up with
+ * seven independent opinions.
+ *
+ * The shape: near zero at 12px, steepening as the type grows, asymptotic to the
+ * -0.0223 the face is drawn to at display sizes. `xs` lands at 0.000, which is
+ * also the right answer for Vietnamese stacked diacritics (ự, ộ, ế, ệ) and for
+ * Inter's `1`/`l`/`i` at 12px — the sizes where tightening does the most damage
+ * are exactly the ones the curve leaves alone.
+ *
+ * One value per rung, not per breakpoint: an em already scales with the font
+ * size, and the curve's difference across a rung's two sizes is under 0.002em.
+ */
 export const TYPE_TRACKING = {
-  xs: -0.02,
-  sm: -0.028,
-  md: -0.03,
-  lg: -0.032,
-  xl: -0.035,
-  xxl: -0.038,
-  xxxl: -0.04,
+  xs: 0.000,
+  sm: -0.006,
+  md: -0.011,
+  lg: -0.014,
+  xl: -0.018,
+  xxl: -0.021,
+  xxxl: -0.022,
 } as const satisfies Record<keyof typeof TYPE_RAMP_MOBILE, number>;
 
 /** The rungs, in ladder order. `TextSize` in `text.tsx` is this set. */