@lotics/ui 27.13.0 → 27.13.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -494,7 +494,7 @@ All view controls are 40px tall (`CONTROL_HEIGHT`), `sm` labels, in ONE wrapping
494
494
  (colored `Text`), not the buttons.
495
495
  - **Create buttons carry NO `+` icon** — "Add fee", not "+ Add fee". A create is `primary` and
496
496
  rides its section's HEADING row at the right edge — see § The add-placement law for why, and
497
- for the one-verb-one-weight rule that keeps it primary in the `EmptyState` too. (The
497
+ for the one-verb-one-weight rule that keeps it `primary` wherever it renders. (The
498
498
  icon-only `+` `IconButton` — a composer's attach — is a different thing and keeps its glyph.)
499
499
 
500
500
  ## The action-gating law — disabled + the reason as a co-located Callout
@@ -600,11 +600,13 @@ gate's SCOPE, once** — never prose beside the button, never revealed only on p
600
600
 
601
601
  The ADD is the one verb this law does NOT place next to its effect, and the add-placement law
602
602
  says why: a position that never moves beats a position that is adjacent, because "below the
603
- last row" is a different place on every list and no place at all on an empty one.
604
- **An add is `primary`, in the `EmptyState` too.** It is the act its section offers, so it
605
- carries that section's weight; a lone `secondary` button reads as though the real action were
606
- somewhere else. The rule that matters is that ONE VERB KEEPS ONE WEIGHT the same add must
607
- not be primary on an empty list and secondary on a full one.
603
+ last row" is a different place on every list and no place at all on an empty one. The heading
604
+ row therefore carries identity + meta + view controls + the section's ADD, and no other content
605
+ verb. **An add is `primary` wherever it renders** on that heading row, or inside an
606
+ `EmptyState` in the one case § Empty states allows, where there is no heading to carry it. It
607
+ is the act its section offers, so it carries that section's weight; a lone `secondary` button
608
+ reads as though the real action were somewhere else. The rule that matters is that ONE VERB
609
+ KEEPS ONE WEIGHT — the same add must not be primary on an empty list and secondary on a full one.
608
610
  A record surface therefore carries several primaries, one per section, and that is correct:
609
611
  "one primary per SCREEN" governs the page BAND, not a stack of independent sections each with
610
612
  its own single act. The cost is real and worth knowing — the more sections offer an act, the
package/docs/templates.md CHANGED
@@ -53,6 +53,22 @@ the package index is [../AGENTS.md](../AGENTS.md).
53
53
  | AI ranks answers — look-up-and-explain | `tpl_lookup` |
54
54
  | AI over a record's documents (extract / cross-check / generate) | `tpl_record` — its Documents + Document set sections |
55
55
 
56
+ ### Register + drawer, or a navigated page?
57
+
58
+ The register is the DEFAULT, and its row press opens the workspace `Drawer`. A record earns
59
+ its own navigated route only when one of these holds:
60
+
61
+ - **It is a destination.** Someone arrives cold from outside the register — a link in an
62
+ email, a notification, a handoff from another desk — and must land on the record without
63
+ the list to open it from.
64
+ - **The work needs the canvas.** A docked comments gutter, a document read beside the fields,
65
+ an outline rail worth navigating — width the drawer's single column cannot give.
66
+
67
+ The volume of DATA is not the test. A record with forty fields still closes in the drawer if
68
+ the operator opens it from the list, works it, and goes back to the list. What an app without
69
+ a destination skips is the ROUTE, never the template: the drawer renders `tpl_record` either
70
+ way, so "no record page" must never become a hand-built detail surface.
71
+
56
72
  ## Composition rules — how a record surface is assembled
57
73
 
58
74
  Laws for any screen where a record's data is edited and a primary action produces its output
@@ -268,7 +284,10 @@ billing, and quick-capture templates. Top → bottom:
268
284
  ATTENTION state as a co-located `Callout` (e.g. overdue — record-scoped state reads here;
269
285
  field-scoped state stays on its field), then a quiet `SummaryLine` (desk, documents
270
286
  , to collect).
271
- - **GENERAL — the MAIN details, FIRST in the rail**; every later section is supplementary.
287
+ - **GENERAL — the MAIN details, first in THIS record's rail** because its work starts at the
288
+ details; rule 1 orders sections by work flow, so a surface whose work starts at a DOCUMENT
289
+ (an invoice desk, a claims desk) leads with Documents and General follows. Every later
290
+ section is supplementary.
272
291
  A `SubsectionStack` (space-only beat) of a headingless LEAD group (the key facts) plus
273
292
  named groups (e.g. Order / Fulfilment / System — system identifiers get a HOME, not a
274
293
  per-row badge). Every group's `DetailTable` repeats the same `labelWidth` so the grid
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@lotics/ui",
3
- "version": "27.13.0",
3
+ "version": "27.13.1",
4
4
  "type": "module",
5
5
  "exports": {
6
6
  "./vite": {