@lotics/ui 27.17.0 → 28.0.0

package/docs/data_entry.md

@@ -381,88 +381,59 @@ When work crosses departments (sales → operations → accounting), the HANDOFF
 changing desks — never an inbox, a notification, or a copied task. Two types:
 
 **(A) Same entity** → a STAGE field on the shared record: sections carry OWNER dot tags, and the
-handoff is MANAGED AS TASKS — each desk's checklist on the record. The **`Task`** compound owns
-the list geometry (the control column, the indent, and `density` — 44px targets by default) —
-compose it, never hand-roll the row. A **`TaskItem`** carries a `TaskStatus` (a `CheckCircle` — a
-read-only ring when it has no `onChange`), a `TaskTitle` (an `InlineTextInput`,
-or the title TEXT as a string child — `<TaskTitle struck={done}>{label}</TaskTitle>` is the
-read-only form, and the compound owns its inset and band, so never hand-roll a `Text` title) and
-a `TaskActions` ⋯ menu — never a decorative progress strip. The fields the desk SETS (the
-assignee `InlineMemberSelect`, the due date) hang UNDER the row as `TaskSubRow`s, which reflow on
-their own, so the drawer and the record page run the SAME composition. `CaptureRow` closes the
-list as its add-affordance.
-
-**A row's first line is a BAND** (44px comfortable, 32 dense): both gutter controls centre in it,
-`TaskTitle` claims it, and everything else — caption, detail, nested list, a title's wrapped
-second line — hangs below it. That is what keeps a column of controls straight down a list of
-mixed-height rows, so a control never drifts into the gap under the title it belongs to.
-
-A task's own free text is its TITLE, a **`TaskCaption`** or a **`TaskDetail`** — there is no
-fourth place to write about the TASK, because a fourth place gets written in twice. `TaskCaption`
-is the row's state IN WORDS ("3 of 5 papers received", "waiting on the yard") on its own line
-under the title; it is not a field, because a field is a NAMED VALUE the reader sets and a caption
-is a SENTENCE about one row — labelling prose makes it read as a field nobody can edit. A sentence
-about one FIELD is not a caption either: it is that sub-row's own `description` / `warning` /
-`error`, which is why the sub-row carries all three.
-
-**THE ROW CARRIES THE TITLE; THE FIELDS THE USER CAN SET ARE SUB-ROWS BENEATH IT.** A field
-belonging to ONE task — its due date, its assignee, a portal login, a reference number — hangs
-under it as a **`TaskSubRow`** (`label`, the control, `description` / `warning` / `error`),
-indented ONE step, with the NAME beside its VALUE so the eye pairs them. Belonging is expressed by
-that indentation, which is the same step a nested `TaskList` takes — one device, at every depth.
-
-**The label column belongs to the LIST, not to the row** — `TaskList labelWidth`, defaulting to
-`DETAIL_LABEL_WIDTH` (130), inherited to every depth, exactly as `DetailTable labelWidth` is the
-record's. Every sub-row on the surface therefore starts its value on ONE x, and a name longer than
-the column WRAPS inside it instead of pushing its own value right. A column each row sized to its
-own words is not a column: it lined up the labels of a task whose names happened to be short and
-staggered every other one, and a vocabulary with longer field names than English staggered nearly
-all of them. Raise it once, on the list, for a vocabulary that genuinely needs more. The value
-takes the slack from a readable minimum, dropping onto its own line under the label on a surface
-too narrow to seat both. Use the `Inline*` editor —
-belongs to a grid.
-
-**A TASK'S FIELD ANNOTATES EXACTLY LIKE A RECORD'S FIELD.** `TaskSubRow` carries the same
-`description` / `warning` / `error` as `DetailRow`, from one shared implementation — same tones,
-same severity order (error nearest the control, then warning, then the guidance), same alert
-semantics. A fault in ONE field says so on that field. Demoting it into a `TaskCaption` — a
-sentence about the whole ROW — says something different, and that asymmetry is what forced apps
-to do it.
-
-**Anything that needs SCANNABLE COLUMNS is a `Table`, not a `TaskList`.** The compound once
-carried a declared VALUE column so cells lined up down the list; it aligned, and it read worse —
-each name ended up a quarter of the surface from its control, sized for the widest value on the
-page. Comparing the same four values across twenty rows is a table's job. A `DetailTable` inside a
-`TaskDetail` is the same mistake in miniature: the list already HAS a label column, so a second
-one lands a label and a control at two more x positions matching nothing above them — a form
-pasted into a list, and with sub-row annotations there is nothing left for it to say.
-`TaskDetail` keeps the FREE-FORM block (a chart, a table, a form with its own submit) — it has no
-name to hang on the indent, so a rule down its left edge is what ties it to the row.
-
-**The ⋯ is a COLUMN — the mirror of the control gutter.** Both pinned controls sit outside the
-row's flow and the ROW reserves each edge (`controlWidth` on the left, `actionWidth` on the
-right, each plus the row gap), leaving ONE content box between them that every line spans exactly:
-the title, a caption, a sub-row, a detail block, a nested list. That is what keeps a list where
-only SOME rows carry a menu straight — a menu-less row's content ends on the same x as a
-menu-carrying one's, and so does everything hanging beneath either. A nested list hands the
-parent's reservation back before its own rows re-take it, so the column does not step inward per
-level. Declare `actionWidth={0}` when NO row in the list carries actions, so it pays nothing for a
-column it never uses.
-
-**Subtasks are TASKS** — nest a `TaskList` inside the `TaskItem`, and the child carries fields,
-a menu and children of its own. There is no separate subtask shape to outgrow, and no built-in
-chevron: collapsing is the app's call (hold a boolean, render the nested list or don't).
-
-**State flows from the LEAVES.** Where a row's position is computable from what it owns, DERIVE
-it — a stored status is a second copy of what the fields already say, and two copies drift. Give
-the parent's ring the bulk gesture where its children ARE the fact (tick it, every child ticks);
-where the ring answers a DIFFERENT field the children do not determine — a date, say — coupling
-them asserts something the operator never said.
-
-**A sub-row holds a CONTROL.** Where exactly one field determines a row's status, the sub-row IS
-that field's editor: a read-only copy of it elsewhere on the row puts one value on screen twice,
-under two names. Everything else derived is prose in `TaskCaption` — a read-only pill given a
-field's label reads as pressable when it is not. A `Badge` INSIDE the editor (an
+handoff is MANAGED AS A CHECKLIST — each desk's work on the record. **`checklist`** owns the row
+geometry (the ring column, the connecting line, the rhythm) — compose it, never hand-roll the row.
+A **`ChecklistItem`** carries its title, its own stamp (`trailing`), a short `meta` and an
+optional ⋯ (`menu`); **`ChecklistGroup`** names a phase above the rows it heads. `CaptureRow`
+closes the list as its add-affordance.
+
+**`connected` decides which shape you are building.** ON for one record walking positions — the
+line asserts sequence, which is what a desk handoff IS. OFF for N items ticked in any order, where
+a line claims an order the work does not have. It is the same compound either way; they were two
+families until the anatomy turned out to be identical.
+
+**A GROUP is a name and nothing else.** No control: a phase owns no completion of its own, so a
+ring there reports without responding — and one identical to the pressable rings beneath it
+invites the press it refuses, which is worse than showing nothing. No BODY: a condition or an act
+hung off a heading leaves the reader working out which of the rows below it they were about. The
+row that OWES the work carries all of it — its wait (`meta`), its condition (`ChecklistNote`) and
+the act that leaves it (`ChecklistActions`).
+
+**ROWS TICK ONE AT A TIME.** A parent that ticked its children wrote what the reader never said:
+on a dated ladder, today's date onto milestones that happened on days nobody recorded. Where the
+run is a SEQUENCE, derive position from the highest stamp instead — one click then marks
+everything below it, and a rung the record passed without a recorded day shows a BLANK date, which
+is the honest answer to "when" and stays one click from being filled. That is the whole of the
+bulk gesture, and it invents nothing.
+
+**A CHECKLIST REPORTS; IT DOES NOT COLLECT, AND IT DOES NOT PREVIEW.** A field some section owns —
+an assignee, an address, a tax ID — is NAMED as a gap by a **`ChecklistNote`** whose `action` jumps
+to that section. Never an editor in the row: two edit surfaces for one fact, and every row becomes
+two things at once (a status and a form) with nothing to say which one the reader is in. Never a
+rendered value either — an avatar or a badge is a COPY that has to be kept in step with the
+field's real home, and readers start treating the list as the place the value lives. Two
+exceptions, both narrow: **`ChecklistItem.trailing`** for the row's OWN stamp (a tick writes today,
+so a run filled in after the fact needs the correction in reach), and **`ChecklistField`** for a
+value with NO other home — a portal login created at that step, unreachable otherwise.
+
+**Prose that grows owns its own line.** `ChecklistItem.meta` is two words riding the title (who it
+waits on, how long); anything that lengthens with the data — "Needs: Tax ID, Delivery address" —
+is a `ChecklistNote`, because a sentence on the title's line wraps into the title and the row stops
+scanning. Neither takes a LABEL: a field is a named value the reader sets, and labelling prose
+makes it read as a field nobody can edit.
+
+**Anything that needs SCANNABLE COLUMNS is a `Table`.** The compound once carried a declared VALUE
+column so cells lined up down the list; it aligned, and it read worse — each name ended a quarter
+of the surface from its control, sized for the widest value on the page. Comparing the same four
+values across twenty rows is a table's job.
+
+**State flows from the LEAVES.** Where a row's position is computable from what it owns, DERIVE it
+— a stored status is a second copy of what the fields already say, and two copies drift.
+
+**One value, one place on the row.** Where a row carries a field at all (`ChecklistField`, the
+no-other-home case), that editor IS the value: a read-only copy of it elsewhere on the row puts
+one value on screen twice, under two names. Everything else derived is prose in a
+`ChecklistNote` — a read-only pill given a field's label reads as pressable when it is not. A `Badge` INSIDE the editor (an
 `InlineSelect renderSelected`) is fine: it inherits the control's own inset.
 
 **A status reports what is OUTSTANDING, never what is settled.** A finished row already says so
@@ -485,7 +456,7 @@ record type) — no human types them; common-but-OPTIONAL tasks appear as `Sugge
 the list — a PILL, never a row, so a suggestion can't be mistaken for a task (tap = materialize,
 ✕ = dismiss for this record; already-present labels filter out; suggestions never count in
 done/total and pause while a filter narrows the view) — the same suggestion grammar as the billing
-Standard pill. `TaskActions` holds an `ActionMenu` (Delete lives BEHIND it, danger-styled and last
+Standard pill. `ChecklistItem.menu` holds an `ActionMenu` (Delete lives BEHIND it, danger-styled and last
 — never a bare ✕ a stray tap can hit), which completes the list's CRUD.
 
 Open tasks INFORM the handoff, they NEVER block it: the CTA stays enabled, the count warns, and
@@ -494,10 +465,9 @@ open tasks carry over. The handoff CTA opens a DIALOG for the receiving desk (as
 the record left this register.
 
 Tasks PEEK from the register: the done/total column is a pressable compact-`ProgressBar` trigger
-whose popover holds the same `Task` list — every `TaskItem`'s ring `TaskStatus`, struck
-`InlineTextInput` `TaskTitle` (flex), a quick-reassign `InlineMemberSelect` in a `TaskSubRow`
-under it — no expandable rows (tags/files depth is
-the Task list template's lesson, not the peek's); the popover body is `PopoverContent`'s own
+whose popover holds the same `Checklist` — every `ChecklistItem`'s ring and title, and nothing a
+section already owns (a reassign belongs to the record, not to a peek over fifty rows) — no
+expandable rows (tags/files depth is the task board's lesson, not the peek's); the popover body is `PopoverContent`'s own
 ScrollView (`disableBodyScroll` is ONLY for children that manage their own scroll, like
 `OptionList`). The DRAWER carries a real Tasks SECTION in the Record template's shape (heading +
 the compact meter + the same checklist) — one shared task state per record feeds the column, the

package/docs/templates.md

@@ -198,8 +198,15 @@ screens — register, per-row action, gated selection, and act-on-many in one. T
 
 - **One toolbar row** — search + a status `Select` + facet `FilterChip`s LEFT, the New CTA
   RIGHT; a light `SummaryLine` of the filtered view below.
-- **A sortable, `Divider`-separated `Table`** where the record's KEY/identifier is the FIRST
-  column and every row carries a leading checkbox; a row that can't take the bulk action gets a
+- **A sortable, `Divider`-separated `Table`** where the record's SUBJECT is the first column —
+  who or what the record is FOR, because that is what a reader scans for and what they say out
+  loud ("the Harbor Freight one", never "RC-2026-0041"). The KEY is how the SYSTEM refers to the
+  record, so it rides the identity cell's supporting line, muted, where the other supporting
+  values live; it does NOT take a column of its own, and it is never the row's name. It also does
+  not SHRINK there — a key is quoted whole or it is not a key, so a long phone number gives way
+  first (it has a `CopyButton` handing over the full value regardless). The record surface names
+  itself the same way, or the two disagree about what a record is called. Every row carries a
+  leading checkbox; a row that can't take the bulk action gets a
   **disabled** checkbox (the same gating as any blocked line). A row's status is
   `Badge variant="dot"` — never the tonal `Badge` (that's the drawer/header twin; → [composition
   grammar §"Status indicators have a WEIGHT"](./composition.md)) — and the SAME dot vocabulary
@@ -219,15 +226,18 @@ screens — register, per-row action, gated selection, and act-on-many in one. T
   [`tpl_record`](../examples/tpl_record.tsx) in `chrome="drawer"`, not a copy of it. Same
   sections, same order, same rules, because it is the same component: `<TplRecord
   chrome="drawer" code={row.id} />`. A hand-built second record surface is exactly how the two
-  drifted apart — a checklist on one side and a `Pipeline` on the other, a reference as a
+  drifted apart — the progress ladder grouped one way here and flat there, a reference as a
   section here and a field there — so the register owns the REGISTER and nothing else.
-  - What the chrome flag changes is only what a nested surface must not do: comments become the
-    LAST SECTION of the drawer's own scroller (a `Drawer` has no second gutter to dock them
-    into), and the back button is left to the Drawer's header. Everything else follows from
+  - What the chrome flag changes is only what a nested surface must not do: the back button is
+    left to the Drawer's header, since two exits is two exits. Everything else follows from
     width — the layout measures its CONTAINER via `onLayout`, never the window, so the outline
-    rail, the docked discussion and the mirrored gutters collapse on their own, and the section
-    picker is a popover ANCHORED to its bar button rather than a full-page `Modal` that would
-    escape the drawer.
+    rail and the mirrored gutters collapse on their own, and the section picker is a popover
+    ANCHORED to its bar button rather than a full-page `Modal` that would escape the drawer.
+    **The discussion follows the same measure**: docked beside the record where there is room for
+    its column, and a SECTION under General where there is not — which a drawer always is. It is
+    never behind a control. It was briefly a toggle in the top-right of a narrow page and a
+    body-SWAP inside a drawer; both made the reader know a control existed, press it, and give up
+    the record to read a note, which is where an unread note goes to be missed.
   - **Linked records** still push an editable screen for that record inside the drawer via the
     hosted `ScreenRouter` — while `canGoBack` the drawer header swaps to a back button + the
     pushed id and the ◀ ▶ sequencer hides; back pops with scroll preserved.
@@ -314,12 +324,19 @@ billing, and quick-capture templates. Top → bottom:
   (author-only edit/delete; attachments as a pressable `FileGrid` → gallery preview; a
   file-capable edit form injected via `renderEditForm`) + THE kit `Composer` (attach via
   `actionsButton`, staged files in its `files` slot) — never a bespoke comment box.
-- **Progress** — the desk handoff as the ordered positions it is: a bare `Pipeline` over
-  Sales → Operations → Accounting. Each REACHED stage owns the facts it stamps as
-  `PipelineField`s (taken-on `InlineDatePicker`, owner `InlineMemberSelect`) and keeps them
-  editable once the record has moved on; the LIVE one adds its condition (`PipelineNote`, e.g.
-  past the due date) and the single act that leaves it (`PipelineActions` → the handoff dialog).
-  An unreached stage is its title alone. `meta` carries how long the desk has held it — prose
+- **Progress** — directly UNDER General, because where the record SITS is the second question a
+  reader has after what it IS, ahead of its files, its route and its money, which are all
+  reference. The desk handoff as the ordered positions it is: a `Checklist connected` where the
+  desks are `ChecklistGroup`s (Sales → Operations → Accounting) and the milestones they produce
+  are the rows. A GROUP carries no COMPLETION control (a phase owns none, and
+  a ring that never responds invites the press it refuses) and no body (a condition hung off a
+  heading leaves the reader working out which row it was about). The row that OWES the work
+  carries all three: how long it has been owed (`meta`), its condition (`ChecklistNote`, e.g.
+  past the due date — with an `action` jumping to the section that owns a missing field rather
+  than editing it here) and the single act that leaves the desk (`ChecklistActions` → the handoff
+  dialog). Rows tick ONE at a time and position is the HIGHEST stamp, so one click marks
+  everything below it without writing dates nobody recorded; a rung it passes shows a BLANK date,
+  which is the honest answer to "when" and stays one click from being filled. `meta` is prose
   the reader can't set, never the date that the stage's own field already shows. See § The
   handoff shape for the rules; for a record that genuinely needs a CHECKLIST, the task-list
   grammar is worked in `tpl_item_list`.
@@ -405,22 +422,21 @@ billing, and quick-capture templates. Top → bottom:
   REPLACES the set — derived paperwork, never intake; the desk register above keeps what
   arrived. **READINESS**: a form declares the RECORD FIELDS it reads (`needs`); the fields'
   HOME stays their DATA section (the colocation law) with descriptions naming their
-  consumers ("printed on the delivery note"). The picker rows ride `TaskList`/`TaskItem`
-  (`controlWidth={24}` for the `CheckboxInput` in `TaskStatus`, and `actionWidth={0}` because no
-  row here carries a ⋯, so the list pays nothing for the action gutter) — the compound owns the
-  row geometry and both gutters; hand-rolling the anatomy is how alignment drifts. Warning and fix are CO-LOCATED on the row. The mark NAMES what's missing — a
-  **`TaskCaption`**, not a field: 13px `circle-alert` + "Needs: …" the actual field labels,
-  muted at rest so gaps show WITHOUT checking, warning once checked because it now blocks. It is
-  a SENTENCE about the row, and a `TaskSubRow` is a NAMED value the reader sets, so prose given a
-  label reads as a field nobody can edit. The FIX sits
-  right under it in the row's `TaskDetail` — an `Inset` (a FORM surface, NEVER a `Callout`:
-  a warning Callout is an ARIA `alert`, wrong around a form) with a `FormTextInput` per gap
-  (label + the consumer hint as `description`) and a "Save fields" (secondary — the section
-  keeps ONE primary, disabled while every draft is empty). Save writes the record fields
-  (their home rows show the values); the need resolves, the mark clears, the fill drops
-  away. Drafts are keyed BY FIELD, so a field two checked forms share is entered ONCE and
-  one Save resolves both. A ready form stays SILENT. Missing fields are the gating law's
-  DEGRADED-BUT-VALID case (they print blank, filled by hand later): Create stays ENABLED, a
+  consumers ("printed on the delivery note"). The picker rows ride a
+  `Checklist connected={false} mark="select"` — the SAME compound as Progress, TWO axes apart.
+  Unconnected because these forms are a SET the user picks from rather than a sequence, and a
+  line between them would claim an order the work does not have; `select` because picking a form
+  is a CHOICE, and a filled ring there would read as work already carried out to a reader who
+  learned what a ring means one section above. The row NAMES what is missing in a `ChecklistNote` — "Needs: …"
+  the actual field labels, muted at rest so gaps show WITHOUT checking, warning once checked
+  because it now blocks — and points at the section that owns those fields.
+
+  **It does not collect them.** The row briefly opened a form of its own here, which made every
+  row two things at once (a status and a form) with nothing to say which one the reader was in,
+  and put an editor beside a field's real home where its description and its neighbours live. A
+  checklist REPORTS; the section that owns a value COLLECTS it. A ready form stays SILENT.
+
+  Missing fields are the gating law's DEGRADED-BUT-VALID case (they print blank, filled by hand later): Create stays ENABLED, a
   co-located warning `Callout` states the consequence, and the press CONFIRMS via `Alert`.
   Only an empty pick disables, and silently. A form can also be DATA-conditional (the hazardous-goods note renders only
   while the record's Hazardous goods boolean is set — record data may reshape the list,
@@ -471,40 +487,62 @@ billing, and quick-capture templates. Top → bottom:
   below that it collapses to the pinned bar. Sizing the column is the SHELL's job — inner
   blocks are plain `width: "100%"`, never a second `maxWidth` + `alignSelf: "center"`.
 
-### The handoff shape — `Pipeline`, and where it lives
+### The handoff shape — a CONNECTED checklist, and where it lives
 
-One record walking N ordered stages, where **the stage decides what you can see and do**: work
-passed between desks — an application through intake → review → production → filing, a claim
+One record walking N ordered positions, where **the position decides what you can see and do**:
+work passed between desks — an application through intake → review → production → filing, a claim
 through submitted → assessed → paid.
 
-It is NOT its own template. A handoff is something a RECORD does, so it renders as one section
-OF that record — see `tpl_record` § Progress, where the desks (Sales → Operations → Accounting)
-become the stages, each owning the facts it stamps (taken-on, owner) and the live one carrying
-the act that leaves it.
-
-**It replaced a per-desk CHECKLIST, and that swap is the lesson.** Ticking boxes described the
-WORK; it never said where the record SAT, so the reader had to infer position from which group
-still had unticked rows — and the handoff CTA sat in a different section entirely, the act
-divorced from the state that gated it. A stage says the position outright, and the act rides the
-stage it belongs to. Reach for a checklist only when the rows are genuinely N independent
-tickable items (`TaskList`); a record's own progress is a pipeline.
-
-Built on the `Pipeline` compound (`Pipeline`, `PipelineStage`, `PipelineField`,
-`PipelineNote`, `PipelineActions`), which composes over `Stepper` — `Stepper` renders POSITION,
+It is NOT its own template. A handoff is something a RECORD does, so it renders as one section OF
+that record — see `tpl_record` § Progress, where the desks (Sales → Operations → Accounting) are
+`ChecklistGroup`s and the milestones they produce are the rows.
+
+**Two levels, because a desk and a milestone are not peers.** The ladder was briefly one flat run
+of eight — "Operations" beside "Collected" — which asked the reader to know which name was a PLACE
+and which was an EVENT. Grouping the milestones under the desk that produces them says it in the
+shape instead.
+
+**A group is a name and nothing else.** No control: a phase owns no completion of its own, so any
+ring it wore would report without responding — and one identical to the pressable rings beneath it
+invites the press it refuses, which is worse than showing nothing, because the reader clicks and
+the product says nothing back. No BODY either: a condition or an act hung off a heading leaves the
+reader working out which of the rows below it they were about.
+
+**Rows tick ONE at a time, and position is the highest stamp.** That is what lets one click say
+"everything up to here": ticking `Delivered` puts the record there and the rungs below it read
+done immediately. The alternative — a parent tick that fills its children — marks the same rows
+but INVENTS their dates, writing today onto milestones that happened on days nobody recorded. A
+rung the record passed without a recorded day shows a BLANK date, which is the honest answer to
+"when" and stays one click from being filled.
+
+**A checklist REPORTS.** It does not collect and it does not preview: a field some section owns is
+NAMED as a gap by a `ChecklistNote` whose `action` jumps there, never edited in the row and never
+rendered as a value. The row's OWN stamp (`trailing`) and a value with no other home
+(`ChecklistField`) are the two exceptions.
+
+**It replaced a per-desk CHECKLIST without the line, and that swap is the lesson.** Ticking boxes
+described the WORK; it never said where the record SAT, so the reader inferred position from which
+group still had unticked rows — and the handoff CTA sat in a different section entirely, the act
+divorced from the state that gated it. A connected run says the position outright, and the act
+rides the row that owes it. `connected={false}` is for rows that are genuinely N independent
+items; a record's own progress asserts sequence.
+
+Built on `checklist` (`Checklist`, `ChecklistGroup`, `ChecklistItem`, `ChecklistNote`,
+`ChecklistActions`, `ChecklistField`), which composes over `Stepper` — `Stepper` renders POSITION,
 this adds the anatomy that turns a position into a workspace.
 
 Three rules the anatomy holds, each learned from getting it wrong:
 
-- **Only the CURRENT stage carries an act.** A control on an unreached stage invites acting out
-  of order — and where the stage is derived from the highest stamp, one stray press jumps the
-  record past the desk that owns it. On a passed stage it re-offers something already done.
-- **A condition belongs to its stage.** "Sent back", "rejected", "waiting on the customer" are
-  facts about ONE stage, so they render inside it (`PipelineNote`) rather than as a `Callout`
+- **Only the OWED row carries an act.** A control on an unreached row invites acting out of
+  order — and where position is derived from the highest stamp, one stray press jumps the record
+  past the desk that owns it. On a passed row it re-offers something already done.
+- **A condition belongs to its row.** "Sent back", "rejected", "waiting on the customer" are
+  facts about ONE position, so they render inside it (`ChecklistNote`) rather than as a `Callout`
   above the run, which reads as "something is wrong with this record" and sits nowhere near the
-  control that answers it.
-- **A passed stage stays correctable** — its date (clearable, which is how you walk a record
-  BACK) and any field it owns. Otherwise a value typed wrong becomes unreachable the moment the
-  record moves on, and the only fix is direct table access.
+  control that answers it — and nowhere near enough to say WHICH row it is about.
+- **A passed row stays correctable** — its stamp is editable, which is how a date recorded wrong
+  gets fixed and how a record walks BACK. Otherwise a value typed wrong becomes unreachable the
+  moment the record moves on, and the only fix is direct table access.
 - **The stage that OPENS gets stamped by the act that opened it**, and the TERMINAL act is not
   a handoff. Handing off asks whom (a dialog) and writes that answer into the receiving stage's
   own fields — coming up blank re-asks a question just answered. Finishing has no receiving