@lotics/ui 43.6.0 → 43.7.1

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 — plus the half that rule was missing: every pair on ONE ROW starts at the SAME rung, a register's subject is `sm` over `xs` with values `sm`, and the subject leads by WEIGHT and its identity mark rather than by 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,20 +1165,50 @@ 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.
 
-**And every pair ON ONE ROW sits at the SAME rungs — a register's row subject is `sm`, its
-supporting line `xs`, 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.
+**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 — and it is what
-`tpl_item_list` does. 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.
+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

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

@@ -2931,20 +2931,19 @@ export function TplRecord({ chrome = "page", code = "RC-2026-0418", openSection
           divider above the section for every section before it. */}
       {/* The header band sits ABOVE the stack, on the canvas beat — it is the
           record's IDENTITY, not a section, so the 56px between-sections rhythm
-          (and, in scroll mode, the hairline that comes with it) does not apply.
-          Every condition it used to announce now lives on the field it concerns,
-          with a dot on the rail saying which section to look in. */}
+          (and, in scroll mode, its hairline) does not apply. A condition belongs
+          on the FIELD it concerns, with a dot on the rail naming the section to
+          look in — never announced up here away from what it is about. */}
       <View style={{ flex: 1, minWidth: 0, gap: 28 }}>
         {/* The record's own ACTS live here, beside its identity — not inside a
-            section. Dropping a file is something you do TO THE RECORD, but its
-            only affordance used to sit in the Files section, which scoped the
-            discoverability to that section: from anywhere else on the page
-            (or from 3,975px above it) nothing said the record took files at
-            all, and a whole-record drop target nobody can see is an
-            accelerator, never an entry point. The Files register keeps its own
-            Add — a register's Add belongs under its register — this is the
-            record-level way in. A template composition for now; it earns a kit
-            slot on RecordSummary at its second consumer. */}
+            section. Dropping a file is something you do TO THE RECORD, so an
+            affordance for it that lives only in the Files section is scoped to
+            that section: from anywhere else on a long page nothing says the
+            record takes files at all, and a whole-record drop target nobody can
+            see is an accelerator, never an entry point. The Files register keeps
+            its own Add — a register's Add belongs under its register — and this
+            is the record-level way in. A template composition for now; it earns a
+            kit slot on RecordSummary at its second consumer. */}
         <View style={{ flexDirection: "row", alignItems: "flex-start", gap: 16 }}>
           <View style={{ flex: 1, minWidth: 0 }}>
             {/* The SUBJECT leads, the key goes under it. A reader talks about
@@ -3165,31 +3164,17 @@ export function TplRecord({ chrome = "page", code = "RC-2026-0418", openSection
             />
           ) : (
             <>
-              {/* AN ENTRY, NOT A LOG LINE — and that distinction is the whole
-                  reason this stopped being a `Timeline`.
-
-                  `Timeline` puts its label INSIDE the row's press target. That
-                  is right for an event ("Stage changed to Won") whose text is
-                  derived and read-only. It is wrong here, because the gist is
-                  the one thing on an entry a person WROTE, and text inside a
-                  button can never be edited where it sits. Four repairs came out
-                  of working around that — the verbs moved off the row, the label
-                  learned to un-clamp, the body's copy of the gist came out, and
-                  the Edit verb ended up a scroll away from the sentence it
-                  edits. They were never independent: each one was the
-                  arrangement pushing back.
-
-                  So the gist is not a label. It is a RESIDENT field — always
-                  editable, in place, no mode and no Edit button, the same as
-                  every other authored value on this record. The old argument
-                  against a resident editor here ("the gist is already the row's
-                  label, so it renders the sentence twice") disappears the moment
-                  it stops being one.
-
-                  What is left is the shape every comment UI converged on: a
-                  metadata header, the prose under it, the row's own actions at
-                  the TOP RIGHT beside the text they act on, and the heavy
-                  artifacts behind their own disclosure. */}
+              {/* AN ENTRY, NOT A LOG LINE — which is why this is not a `Timeline`.
+                  `Timeline` puts its label INSIDE the row's press target, right
+                  for a derived read-only event ("Stage changed to Won") and wrong
+                  for a sentence a person WROTE: text inside a button cannot be
+                  edited where it sits.
+
+                  So the gist is a RESIDENT field — always editable in place, no
+                  mode, no Edit button, like every other authored value here. The
+                  shape every comment UI converges on: a metadata header, the prose
+                  under it, the row's actions at the TOP RIGHT beside the text they
+                  act on, and heavy artifacts behind their own disclosure. */}
               <View style={{ gap: 20 }}>
                 {(showAllActivity ? activity : activity.slice(0, ACTIVITY_FOLD)).map((a) => (
                   <ActivityEntryRow
@@ -3712,52 +3697,25 @@ export function TplRecord({ chrome = "page", code = "RC-2026-0418", openSection
         </Section>
         </View>
 
-        {/* PHOTOS — a second SET, and therefore the other SURFACE.
-
-            Files above is a row LIST because a shipping document is identified by
-            its NAME: a PDF thumbnail is a grey page identical to every other grey
-            page, so a grid of them is a wall of one tile. A photo is identified
-            by its CONTENT — `IMG_4471.jpg` tells nobody anything — so the tile IS
-            the identity and a grid puts twelve on screen at once.
-            (AGENTS.md: documents get a LIST, images get a GRID.)
-
-            BOTH SURFACES SHOW THE WHOLE COLLECTION — they are two LENSES over
-            one set, not two sets. Files answers "what is on this record" in a
-            scannable column; Photos answers "what did it LOOK like" at a glance.
-            A reader who guesses wrong still finds the artifact instead of
-            concluding it was never filed, and nobody has to know a file's FORMAT
-            before they know where to look for it.
-
-            The grid used to filter to `image/*`. That made the split a fact about
-            MIME rather than about reading, and it put the signed delivery note in
-            a different section from the photos of the same hand-over — while this
-            very comment promised that the odd `.docx` among forty phone photos
-            would stay in the grid. It could not: the filter forbade what the
-            sentence described. `FileThumbnail` already renders a non-image as a
-            doc tile (badge + filename), so nothing had to be built — only the
-            filter that hid it had to go.
-
-            THE COST IS REAL AND DELIBERATE: every file now appears twice. The
-            trade is that duplication is cheap to skim past, whereas an artifact
-            filed under the wrong lens looks like an artifact that was never
-            filed. A record whose attachments are overwhelmingly paperwork should
-            drop the grid entirely rather than carry a wall of identical tiles —
-            the choice is per-record-TYPE, made once, not per file.
-
-            Ordering follows the collection, so a record heavy in documents leads
-            this grid with grey tiles. If that reads badly for your record type,
-            sort images first rather than reinstating the filter.
-
-            The tiles are mixed by construction now, so the FIXTURE has to be
-            mixed too — a grid of eight JPGs never once renders the doc tile it
-            has always been able to render, which is how the gap survived.
-
-            The ADD rides the heading row, right edge, exactly as it does on Files
-            and Fees — a section's add sits in the same spot whether the section
-            holds nought or forty. Note it is a plain `Button` + `pickFiles`, not
-            `FilesEditorUpload`: that verb reads the `FilesEditor` context, and the
-            heading is OUTSIDE the editor by construction, so a compound's own
-            upload button can never reach the one place the law puts it. */}
+        {/* PHOTOS — two LENSES over ONE set, not two sets. Files answers "what is
+            on this record" in a scannable column; this answers "what did it LOOK
+            like" at a glance. (List for documents, grid for images: AGENTS.md.)
+
+            BOTH show the WHOLE collection, unfiltered. A reader who guesses wrong
+            still finds the artifact instead of concluding it was never filed, and
+            nobody has to know a file's FORMAT before knowing where to look. The
+            cost is real: every file appears twice. Duplication is cheap to skim
+            past; an artifact filed under the wrong lens reads as missing.
+
+            Ordering follows the collection, so a document-heavy record leads with
+            grey tiles — sort images first if that reads badly, and drop the grid
+            entirely for a record type that is overwhelmingly paperwork. That
+            choice is per record TYPE, made once, never per file.
+
+            The add is a plain `Button` + `pickFiles`, NOT `FilesEditorUpload`:
+            that verb reads the `FilesEditor` context and the heading row sits
+            outside the editor by construction, so the compound's own upload
+            button cannot reach the one place the law puts it. */}
         <View onLayout={nav.register("photos")}>
         <Section>
           <SectionHeading>
@@ -4147,26 +4105,16 @@ export function TplRecord({ chrome = "page", code = "RC-2026-0418", openSection
                             <InlineTextInput value={f.note} onSave={persist((v: string) => patchFee(f.id, { note: v }))} placeholder="Add a note…" accessibilityLabel="Fee note" />
                           </DetailRow>
                         </DetailTable>
-                        {/* The destructive verb, LEFT — the peek footer's
-                            convention, which is the kit's. It replaces the
-                            DrawerFooter that used to pin it.
-
-                            Solid `danger`, which is the destructive convention
-                            page-wide (composition rule 9) — not a text-weight act.
-                            A quiet destructive verb had been tried here and the
-                            surface-less rung is gone: an act now always carries a
-                            control, and only NAVIGATION is underlined text. The trash
-                            glyph stays off — "Remove fee" already names the object,
-                            which is the safeguard the icon was only decorating.
-
-                            NO Divider. Every hairline a `Table` draws is
-                            full-bleed (the row `Divider`s carry no padding, the
-                            header band's border spans its whole box), so one
-                            inset by ROW_GUTTER puts two hairline lengths in the
-                            same vertical run — and it would be saying twice what
-                            the expanded row's own wash already says. The row
-                            wrapper is required, not decoration: a `Button` alone
-                            in a column View stretches to full width. */}
+                        {/* The destructive verb, LEFT — the peek footer's convention.
+                            Solid `danger` per composition rule 9; no trash glyph,
+                            because "Remove fee" already names the object the icon
+                            was only decorating.
+
+                            NO Divider. Every hairline a `Table` draws is full-bleed,
+                            so one inset by ROW_GUTTER puts two hairline lengths in
+                            the same vertical run — and it repeats what the expanded
+                            row's wash already says. The row wrapper IS required: a
+                            `Button` alone in a column View stretches full width. */}
                         <View style={{ flexDirection: "row" }}>
                           <Button title="Remove fee" color="danger" onPress={() => deleteFee(f)} />
                         </View>
@@ -4178,8 +4126,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.6.0",
+  "version": "43.7.1",
   "type": "module",
   "exports": {
     "./vite": {

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
@@ -82,6 +78,20 @@
 }
 
 /* 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/type_ramp.ts

@@ -66,6 +66,40 @@ export const TYPE_RAMP_DESKTOP = {
   xxxl: { size: 48, leading: 52 },
 } as const satisfies Record<keyof typeof TYPE_RAMP_MOBILE, TypeRung>;
 
+/**
+ * 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.
  *