@lotics/ui 27.17.1 → 28.0.0

package/AGENTS.md

@@ -44,16 +44,19 @@ CURRENT major only — upgrading an app across majors is `MIGRATION.md`.
   (`message`/`detail`/`onRetry`) on failure → `EmptyState` (succeeded, found nothing) →
   `CompletionState` on done. An alert glyph inside an empty state claims the read succeeded when
   nothing is known. → [catalog.md §Status / feedback](./docs/catalog.md).
-- **Progress: rows of WORK vs positions of ONE thing.** N items ticked in any order, every row
-  the same shape → `task` (`TaskList`). ONE record walking ordered stages where the stage decides
-  which fields, conditions and act are even offered → **`pipeline`** (`Pipeline` +
-  `PipelineStage`, over `stepper`) — worked in `examples/tpl_record.tsx` § Progress, which it took
-  over FROM a per-desk checklist. Rendering positions as a checklist forces every row to carry
-  every control and never says where the record sits; rendering work items as a pipeline implies
-  an order that is not there. A ladder is TICKED — `PipelineStage.onToggle` makes the marker the
-  completion control (never a checkbox beside it), and the stamped date rides the title row via
-  `trailing` as a `DateStamp`: muted text, no frame, click to correct. One ladder per record,
-  never a handoff run beside a milestone run — see `docs/catalog.md`.
+- **Progress: ONE compound, TWO axes — and both are about meaning.** A run of markable rows is
+  `checklist` (`Checklist` + `ChecklistGroup` + `ChecklistItem`, over `stepper`). **`connected`**
+  asks *is this a sequence* — on for one record walking positions, off for N items handled in any
+  order, where a line claims an order the work does not have. **`mark`** asks *does ticking mean
+  DONE or CHOSEN* — a ring for completion, the square box for picking (which forms to produce,
+  which records to export). Spend the ring on a choice and a reader who learned that a filled
+  ring means "done" reads a ticked pick-list as work already carried out. It replaced separate
+  task/pipeline families that had converged on one anatomy. A GROUP is a phase — a name, optionally a
+  Show/Hide disclosure, and no body: it owns no COMPLETION, and a ring that never responds invites
+  a press it refuses. Rows tick ONE at a time; derive position from the highest stamp and one click marks
+  everything below it without inventing dates. A checklist REPORTS — a field owned by a section is
+  named as a gap with a `ChecklistNote action` that jumps there, never edited or previewed in the
+  row. Worked in `examples/tpl_record.tsx` § Progress. See `docs/catalog.md`.
 - **`Badge` = STATUS only; supporting detail is the muted second line.** A type / category /
   attribute / count is not a status — it belongs under its identity as `size="xs" color="muted"`,
   never a second chip. A chip beside a name reads as its PEER (a colored one reads louder),

package/MIGRATION.md

@@ -4,6 +4,70 @@ Breaking changes, newest first — normally per major, plus the rare minor that
 anyway (recorded under its exact version). The current contract lives in `AGENTS.md` + `docs/`;
 this file exists only to move an app from one release to the next.
 
+## 28.0.0 — `task` and `pipeline` merge into `checklist`
+
+Two families had converged on one anatomy: a ring, a title, a value beside it, a muted note, a
+detail block, an optional grouping level. What differed was a LINE between the rings — a mode,
+not a family. The proof: a single session added `trailing`/`meta` to `TaskTitle` **and**,
+separately, the same two to `PipelineStep`, then `tone` to `TaskCaption` and `tone`+`action` to
+`PipelineNote`. One feature, implemented twice.
+
+`@lotics/ui/task` and `@lotics/ui/pipeline` are **gone**. `@lotics/ui/checklist` replaces both.
+
+**`Checklist` and the `checklist` locale slice are REUSED names, not restored components.** A
+different `Checklist` / `ChecklistRow` shipped before v17 and was deleted there in favour of
+`Task`; this one shares only the word and takes none of its props (`trailingWidth`,
+`controlWidth`, `expansion`, `subtasks`). The `checklist` locale slice v17 deleted is likewise
+back under the same key with different strings — `expand` / `collapse`, the group disclosure's
+wording, where the old slice was note and subtask chrome. An app arriving from 16.x follows the
+table below; nothing of its old `Checklist` carries over.
+
+| was | now |
+| --- | --- |
+| `<TaskList>` / `<Pipeline>` | `<Checklist connected={…}>` — the line is an AXIS |
+| `<TaskItem>` + `<TaskStatus>` + `<TaskTitle>` | `<ChecklistItem title done current onToggle trailing meta menu>` |
+| `<PipelineStage>` | `<ChecklistGroup title>` (a phase) — or just a `ChecklistItem` (an atomic rung) |
+| `<PipelineStep>` | `<ChecklistItem>` |
+| `<TaskCaption>` / `<PipelineNote>` | `<ChecklistNote tone action>` |
+| `<PipelineActions>` / `<TaskActions>` | `<ChecklistActions>` / `ChecklistItem.menu` |
+| `<PipelineField>` | `<ChecklistField>` |
+| `<TaskDetail>` | a `ChecklistItem`'s own children — free-form content needs no wrapper |
+| nested `<TaskList>` for subtasks | `<ChecklistGroup>` — groups and items are SIBLINGS in one run |
+
+**`connected` is the whole difference.** On for a record walking positions (the line asserts
+sequence); off for a set picked in any order, where a line claims an order the work does not
+have.
+
+**A group carries no control and no body.** A phase owns no completion of its own, so a ring
+there is a control that never responds — and one identical to the pressable rings beneath it
+invites the press it refuses. A condition hung off a heading also leaves the reader working out
+which row it was about, so a row's wait, warning and act now sit on the row that owes them.
+
+**Rows are ticked one at a time.** A parent that ticked its children wrote what the reader never
+said — on a date ladder, today's date onto milestones that happened on unrecorded days. Where a
+run is a sequence, derive position from the highest stamp: one click then marks everything below
+it, and the rungs it passes show a BLANK date, which is the honest answer to "when".
+
+### Also cut
+
+- **`TaskSubRow`** and `TaskList.labelWidth`. A checklist REPORTS: it does not collect, and it
+  does not preview. A field with a home elsewhere — an assignee, an address — is named as a gap
+  by a `ChecklistNote` that links to the section owning it. An editor in a task row gave every
+  row two modes with nothing to say which one the reader was in; a rendered value (an avatar, a
+  badge) is a copy that has to be kept in step with the field's real home. `ChecklistField`
+  survives for the narrow case of a value with NO other home (a portal login created at that
+  step), and `ChecklistItem.trailing` for the row's OWN stamp.
+- **`Marker`** — zero consumers.
+- **`Step.partial`** — its only caller was the stage ring, and stages no longer wear one.
+  `CheckCircle`'s three positions are unchanged for direct use.
+- `TaskList.density` — one surface used it; a run of rows has one rhythm.
+
+### Kept
+
+`Stepper` / `Step` remain the low-level position READOUT — a wizard's rail is not a checklist.
+`Stepper` gains `connected` and `gap`; `Step` gains `marker={false}` for a row that groups
+others.
+
 ## 27.15.0 — a register row's text is selectable, and a drag no longer opens the record
 
 No API change, but two behaviors changed on **every** `PressableRow` / `TableRow` / `PressDoor`

package/docs/catalog.md

@@ -111,24 +111,40 @@ input chrome, so it aligns pixel-for-pixel). A stack of labelled field rows live
 `DetailTable` + `DetailRow`; the record's identity band is `RecordSummary`; its money
 summary is `Ledger`.
 
-### Tasks / to-dos — pick by ALTITUDE
-
-A task-management PAGE (many tasks, grouping, filters, expandable rows) is COMPOSITION —
-the `Task` compound owns the row — `TaskStatus` (a `CheckCircle`), `TaskTitle` (a struck
-`InlineTextInput`), `TaskActions`. **The row carries the TITLE; the fields a user can SET hang
-under it as `TaskSubRow`s** (`InlineDatePicker`/`InlineMemberSelect`/`InlineSelect`, each with
-its NAME beside it), never a `DetailTable` in a `TaskDetail`, which declares a grid of its own.
-One composition serves a standalone task surface at any density — a flat list or a grouped desk
-board — because a sub-row reflows instead of being authored per surface; add `SuggestionChip`
-commons + `CaptureRow` for the capture case. **A list you scan DOWN columns — the same four values
-compared across twenty rows — is a `Table`, not a `TaskList`.**
-
-**A RECORD never carries a checklist.** Its work state is `Pipeline`
-([`tpl_record`](../examples/tpl_record.tsx) § Progress): a reached stage owns the facts it stamps,
-the LIVE stage alone carries its condition and the one act that leaves it. A per-desk checklist
-described the work but never said where the record SAT, and it put the CTA a section away from the
-state that gated it — so `tpl_record` replaced one with the pipeline, and a register's workspace
-drawer follows the same shape. `TaskList` is for a surface whose SUBJECT is tasks; see
+### Tasks, to-dos, phased work — ONE compound, two axes
+
+Anything a reader marks is `checklist` — `Checklist` + `ChecklistGroup` + `ChecklistItem`. Two
+axes carry every shape it takes, and BOTH are decisions about meaning, not looks:
+
+- **`connected`** — is this a SEQUENCE? On for one record walking positions (the line asserts
+  order), off for N items handled in any order, where a line claims an order the work does not
+  have.
+- **`mark`** — does ticking mean DONE or CHOSEN? `check` is a ring, `select` is the square box.
+  Reach for the square whenever the row is PICKED rather than finished — which forms to produce,
+  which records to export. Spending the ring on a choice is the failure this axis exists to
+  prevent: a reader who has learned that a filled ring means "done" reads a ticked pick-list as
+  work already carried out, and nothing on screen corrects them. (The shapes are 24px either way
+  and share one gutter, so a surface swaps between them without moving anything.)
+
+A record's Progress and a desk's to-do list are the same component two booleans apart; they were
+two families until the anatomy proved identical.
+
+**A row carries its TITLE and its own stamp, and nothing else.** A checklist REPORTS: it does not
+collect, and it does not PREVIEW. A field some section owns — an assignee, an address, a portal
+login — is NAMED as a gap by a `ChecklistNote` whose `action` jumps to that section, never edited
+in the row (two edit surfaces for one fact) and never rendered as a value (an avatar or badge is
+a copy that has to be kept in step). The exceptions are narrow and stated: `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 list you scan DOWN columns — the same four values compared across twenty rows — is a
+`Table`.** Grouping, filters and a per-row register belong there.
+
+**A record's work state is a connected checklist** ([`tpl_record`](../examples/tpl_record.tsx)
+§ Progress), where the desks are `ChecklistGroup`s and the milestones are rows. A per-desk
+checklist without the connecting line described the work but never said where the record SAT, and
+put the CTA a section away from the state that gated it. A register's workspace drawer renders the
+same record, so it follows automatically; for a surface whose SUBJECT is tasks see
 [`tpl_task_board`](../examples/tpl_task_board.tsx).
 
 ### Tabular data — pick by SCALE + intent
@@ -494,6 +510,21 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   heading row) where no text edge exists to betray, or give it the filled tier.
 - **`icon_button`** — `IconButton`: the icon-only circular action (see
   [Actions](#actions)).
+- **`comments_button`** — `CommentsButton`: THE discussion affordance for a listed record — the
+  count and a bubble as ONE control, opening the thread. Reach for it wherever a record is listed
+  and its conversation would otherwise be invisible until opened (a register row, a card, a
+  compact header); it is `CopyButton`'s peer — the other thing a dense row lets you press — and
+  shares its surface, scale and focus ring, so a row carrying both reads as one grammar. The count
+  is INSIDE the target, never loose text beside an `IconButton`: the number is what the reader
+  aims at, and splitting them leaves half the affordance dead under the pointer. FULL INK, unlike
+  the muted values around it — everything else on a row is a fact ABOUT the record, this is people
+  talking about it and the one thing there that can be UNREAD. `subject` reaches the accessible
+  NAME only ("3 comments · Northwind Packaging" is a destination; "3 comments" on the fortieth row
+  is not) — never the visible label, which would spend row width restating whose record it is.
+  **Render it only when `count > 0`** — a zero on every quiet row is a column of noise that trains
+  the eye to skip exactly where the signal will appear. Pair it with a jump that LANDS on the
+  thread (`tpl_item_list` opens the record's drawer on its comments section), because a count the
+  reader cannot act on states that a conversation exists and leaves them to find it.
 - **`copy_button`** — `CopyButton`: THE copy control — `value` onto the clipboard, glyph
   flips to a check and the tooltip to the pack's "Copied" for ~2s. The confirmation follows
   a REAL write: an unreachable clipboard throws and the button stays at rest rather than
@@ -834,8 +865,8 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   not a drag handle — dragging is invisible to the keyboard and fiddly on a phone, and a
   three-to-six position list does not need it. Indent anything that follows the list (an "Add"
   link) by `SEQUENCE_INSET` so it lands on the rail's column. Distinct from `Timeline` (an
-  activity FEED), `Stepper` (a wizard's fixed positions) and `Pipeline` (ONE record walking
-  stages that own their controls) — this is the list a user EDITS.
+  activity FEED), `Stepper` (a wizard's fixed positions) and `Checklist` (rows a reader MARKS —
+  a record walking positions, or a set picked) — this is the list a user EDITS.
 - **`inline_button`** — `InlineButton`: a verb that sits INSIDE an inline field's surface
   (the `Open` on a reference, a `Copy` on a value worth copying) rather than in the row's
   trailing column — put it inside when the act is ABOUT THE VALUE, so it travels with what it
@@ -864,12 +895,12 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   wire both); invalid/cross-field STATE = a co-located `Callout`; **`flat`**
   on a flat-text value row (`InlineStatic`, plain `Text`) tucks the annotation up by the
   control band's slack so its gap matches a chip row's.
-  The three annotations are ONE anatomy shared with a task's `TaskSubRow` — same names, same
+  The three annotations are ONE anatomy shared with a checklist row's `ChecklistNote` — same
   order, same alert semantics — because a record's field and a task's field are the same thing
   on two surfaces.
   `DetailTable`: the compound parent of
   a row STACK — `labelWidth` (default `DETAIL_LABEL_WIDTH`, 130 — THE kit's label column, and
-  a `TaskList`'s default too) / `minHeight` (default 40, the inline-control grid) declared
+  the record surface's) / `minHeight` (default 40, the inline-control grid) declared
   ONCE + the `SPACE.md` (16) row gap — 8 was right while a field was a tint, but a stack of
   BORDERED rows that close together fuses into one block. TWO columns, no third: the value
   FILLS what the label leaves, so nothing one row does can narrow its neighbours' editors. RESPONSIVE with no prop: it
@@ -1020,6 +1051,20 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   by the row's own toggle), the row shows the open wash while it is out, and the door announces
   `aria-expanded`. Prefer the columns first: a fact every row needs is a column, not a reason
   to expand.
+  **`Table.count` + `TableRow.ordinal` make it a COUNTED register** — a narrow gutter left of
+  `leading` carrying each row's position, headed by the total. Reach for it on any register
+  long enough to scroll: it answers "how many" without paging to the end and "where am I"
+  without counting rows, and it is what a reader coming from a spreadsheet (STT) expects to
+  find. `count` is the single switch — omit it and no gutter is reserved, so an uncounted
+  register keeps every pixel it had. It is CHROME, not a column: it never sorts, never drops,
+  and is excluded from the column band, but it IS reserved space the fit accounts for.
+  **Both numbers are the caller's**, and deliberately: `count` is what MATCHED (a paged
+  register renders fifty of it, a filtered one counts the matches), and `ordinal` continues
+  across pages (`offset + i + 1`) or restarts inside a group band, depending on which question
+  the reader is asking — "which of all" or "which of these". Omit `ordinal` on a row with no
+  position (a group band, a totals line) and the gutter stays blank so the cells beside it stay
+  in line. A position is NEVER an identity: sort or filter and row 12 is a different record —
+  a stable handle is a column, and it leads the cells. Worked screen: `tpl_item_list`.
 - **`sort_header`** — `SortHeader` + `SortState`/`SortDir` + `cycleSort` + `sortBy` +
   `SortHeaderLabels`: the sortable column header and the sort-state helpers `Table`/
   `DataGrid` consumers drive.
@@ -1038,7 +1083,7 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   summarizes — including a record's child list (a consol's houses, an order's lines). **Never on
   a record's identity band reporting that record's own state**: derived verdicts on one record
   ("documents incomplete", "2 fields need checking") are the checklist a record must not carry
-  (§`pipeline`) and restate at a distance what the sections below state in place.
+  (§`checklist`) and restate at a distance what the sections below state in place.
 - **`use_selection`** — `useSelection`: always-on multi-select state for a register/list —
   the `selected` Set + `toggle`/`setAll`/`allSelected`/`indeterminate`/`count`/`clear`;
   selectability gating stays with the caller. The checkbox-always-visible counterpart to
@@ -1068,89 +1113,6 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   (`onChange(done)`) so the ring means one thing everywhere; `partial` is reached through
   whatever NAMES it — a status cell, or children ticking off — never by cycling the ring. Keep
   it monochrome and let colour live in the status cell.
-- **`task`** — `TaskList` + `TaskItem` + `TaskStatus` / `TaskTitle` / `TaskCaption` /
-  `TaskActions` / `TaskSubRow` / `TaskDetail` — the task COMPOUND, for anything
-  from a 5-item drawer checklist to a grouped desk board. `TaskList` owns geometry only: the two
-  GUTTERS — `controlWidth` (the left one, that every title aligns on, and so the INDENT step) and
-  `actionWidth` (the right one, that every ⋯ pins into; `0` on a list whose rows carry no
-  actions) — plus `labelWidth` (the column every `TaskSubRow` renders its NAME in; default
-  `DETAIL_LABEL_WIDTH`, 130) and `density` (`comfortable` = a 44px minimum tap target, `dense` =
-  32 for a pointer-driven register). All four are inherited by nested lists. Everything else is
-  composed, and JSX order is screen order — nothing inspects child types.
-
-  `TaskStatus` takes the `CheckCircle` (omit `onChange` for a read-only ring; a PICKER list
-  puts a `CheckboxInput` here and sets `controlWidth={24}`). `TaskTitle` takes the
-  `InlineTextInput variant="bare"` — or the title TEXT itself as a string child
-  (`<TaskTitle struck={done}>{label}</TaskTitle>`), which is the READ-ONLY form: the compound
-  applies the cell inset and the row's band, so a plain `<Text>` + a hand-rolled
-  `TASK_TEXT_INSET` is never needed and a long title that wraps keeps its first line beside the
-  control. It spans the content box between the gutters, like every line hung beneath it.
-  `TaskCaption` is the row's state IN WORDS on its own line under the title — a
-  sentence about the ROW, never a field, and never a sentence about one FIELD (that is the
-  sub-row's own `description` / `warning` / `error`).
-  `TaskActions` carries the row's ⋯ `ActionMenu`, pinned into the RIGHT
-  gutter on the first line (Delete lives BEHIND it, danger-styled and last, never a bare ✕).
-  `TaskDetail` is a FREE-FORM block under the row on the title's text edge — a chart, a table, a
-  form with its own submit — rendered only while open. The module also exports
-  **`TASK_TEXT_INSET`** (9), the inset an inline control puts on its own text: every
-  slot above already applies it, so reach for it ONLY when a custom title NODE (not a cell
-  control) has to land on the same text edge.
-
-  **THE ⋯ IS A COLUMN, THE MIRROR OF THE CONTROL GUTTER.** Both pinned controls sit outside the
-  flow and the ROW reserves each edge (`actionWidth` + the row gap), so what is left between them
-  is ONE content box every line spans exactly — title, caption, sub-row, detail, 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 under 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.
-
-  **THE ROW CARRIES THE TITLE; THE FIELDS THE USER CAN SET ARE SUB-ROWS BENEATH IT.** One task's
-  own fields hang under it as **`TaskSubRow`** (`label`, the control, `description` /
-  `warning` / `error`), indented ONE step — the same step a nested `TaskList` takes, because
-  belonging is expressed by indentation and there is only one device for it. Label and value sit
-  ADJACENT so the eye pairs them. **The label column is the LIST's, not the row's** — one
-  `labelWidth` for every sub-row at every depth, exactly as `DetailTable labelWidth` is the
-  record's — so every value on the surface starts on ONE x. A name longer than the column WRAPS
-  inside it and its value does not move; a column each row sized to its own words is not a
-  column (it started a short label's value at one x and a long one's at another, and any
-  vocabulary with longer field names staggered nearly every row). The value takes the slack from
-  a readable minimum — on a phone or in a narrow drawer it drops onto its own line under the
-  label rather than ellipsizing beside it. Pass a form-variant `Inline*` editor (the default),
-  `variant="bare"`: a dense grid drops the resting frame.
-
-  **A TASK'S FIELD ANNOTATES EXACTLY LIKE A RECORD'S FIELD.** `description` (persistent
-  guidance), `warning` (a consequence to weigh — amber, announced) and `error` (field-level
-  failure — danger, alert semantics) are the same three props with the same order and a11y as
-  `DetailRow`'s, from ONE shared implementation. A fault in a single field belongs ON that
-  field; `TaskCaption` is a sentence about the whole ROW, so demoting a field fault into one
-  says something different.
-
-  **ANYTHING THAT NEEDS SCANNABLE COLUMNS IS A `Table`, NOT A `TaskList`.** The compound spent a
-  version carrying a declared value column so cells would line up down the list; it aligned and
-  it read worse — each field's name ended up a quarter of the surface from its control, sized for
-  the widest value on the page. If the job is comparing the same four values across twenty rows,
-  that is a table, and `Table`/`DataGrid` are built for it. A `DetailTable labelWidth={…}` inside
-  a `TaskDetail` is the other shape to avoid: the list ALREADY has a label column, so a second
-  one lands its label and its value at two more x positions matching nothing above them — a form
-  pasted into a list. Fields belonging to the task are `TaskSubRow`s, which annotate the same way
-  a `DetailRow` does, so there is nothing left that a nested `DetailTable` can say.
-
-  **A row's FIRST LINE is a BAND** — 44px `comfortable`, 32 `dense`. Both gutter controls centre
-  in it and `TaskTitle` claims it, which is what keeps both columns of
-  controls straight as rows grow: a caption, a sub-row, a detail block, a nested list or a
-  wrapped title all hang BELOW the band instead of dragging the control down into the gap under
-  the title. So every sub-line sits the band's slack (12px comfortable) beneath the title's
-  words, the same whether the title is text or an editor. A title node TALLER than the band
-  overrides it — an inline editor is 40px, so a `dense` list of editable titles renders 40px rows
-  and its ring reads a few px high; `dense` is for text/static rows. A sub-row takes the TALLER
-  of the band and the 40px inline-control height, so its label's first line still meets its
-  control's centre in a `dense` list.
-
-  **Subtasks are a nested `TaskList`**, so a step IS a task: give one a field, a menu or
-  children of its own and it works. Collapsing belongs to the app — hold a boolean and render
-  the nested list or don't. There is deliberately **no note slot**: a task's free text is its
-  title, a caption, or detail, and a fourth place to write invited writing it twice.
-
 - **`suggestion_chip`** — `SuggestionChip`: the dismissible SUGGESTION pill — an item the
   record could have but doesn't yet (a common task, an expected line) as a `Chip` whose
   press MATERIALIZES it (plus glyph + label, one tuned anatomy) and whose ✕ refuses it;
@@ -1307,39 +1269,34 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   provider-wired — pass `labels` (`DEFAULT_GANTT_LABELS` is English).
 - **`timeline`** — `Timeline`: a heterogeneous event LOG — per-row icon + expandable
   details; models the past, NOT progress.
-- **`pipeline`** — `Pipeline` + `PipelineStage` + `PipelineField` / `PipelineNote` /
-  `PipelineActions` — the handoff COMPOUND: one record walking ordered STAGES where each stage
-  owns its own fields, conditions and act. Composes over `stepper` (which renders position
-  only). Reach for it over `task` when the rows are POSITIONS rather than work items — one thing
-  moving, one stage live, different controls per stage; `task` is N identical rows ticked in any
-  order. `PipelineNote` is a condition ON a stage (never a `Callout` above the run);
-  `PipelineField` stays editable on a PASSED stage, which is what makes a mis-entry fixable.
-  A field stacks UNDER the title (two lines per stage); on a ladder long enough that this
-  pushes the run past a screenful, **`PipelineStage.trailing`** puts ONE value on the title's
-  own row instead. Never hand-roll that row: a control is twice a text line's height, so the
-  marker — which centres on the first row — reads half the difference too high against it.
-  `trailing` fixes the row at `INLINE_CONTROL_HEIGHT` and tells the `Step`, so the ladder keeps
-  one rhythm whatever the value is. An ACT still belongs in `PipelineActions`.
-  Worked screen: `examples/tpl_record.tsx` § Progress — the desks (Sales → Operations →
-  Accounting) ARE the stages, each owning the facts it stamps and, on the live one, the act
-  that leaves it. A `PipelineStage` body is deliberately NOT pressable: it holds the controls.
-  **`PipelineStage.onToggle`** is the one exception and lives on the MARKER — the node becomes a
-  pressable `CheckCircle` instead of a status dot, for a ladder the reader TICKS OFF rather than
-  only reads. Reach for it before putting a checkbox in `trailing`: that lands a second completion
-  affordance beside a ring that already looks like one, and the reader has to guess which is real.
-  **Which of the two shapes you want**: if finishing a step must capture anything beyond "it
-  happened" — who took it, a reason — it is a HANDOFF, and the act belongs in `PipelineActions`
-  with the marker only reporting. If it does not, it is a MILESTONE and the marker IS the act.
-  ONE ladder per record, never two. A rung that needs more than a tick (a dialog, an owner, a
-  reason) renders it in its BODY — the tick and the act coexist on the same stage, which is what
-  a real pipeline looks like. Splitting them into a handoff run and a milestone run puts "where
-  is this" in two places the reader has to watch together. Worked screen:
-  `examples/tpl_record.tsx` § Progress — tickable markers, the stamped date on the title row as a
-  `bare` `InlineDatePicker` (reads as text, border on hover, click to edit), and the live stage
-  still carrying its owner, its note and the act that leaves it. The date stays EDITABLE on
-  purpose: a tick always writes today, so inert text would make a ladder filled in after the
-  fact — every imported record — impossible to enter correctly. An unstamped rung shows no
-  placeholder; its empty ring already says "not yet".
+- **`checklist`** — `Checklist` + `ChecklistGroup` + `ChecklistItem` + `ChecklistNote` /
+  `ChecklistActions` / `ChecklistField`: THE run of tickable rows, at any
+  altitude. It replaced a `task` family and a `pipeline` family that had converged on one
+  anatomy — a ring, a title, a value beside it, a muted note, a detail block, an optional
+  grouping level — differing only in whether a LINE joined the rings. **`connected` is that
+  line, and it is the whole difference**: on for ONE record walking positions (it asserts
+  sequence), off for a SET picked in any order, where a line claims an order the work does not
+  have. Rows are ticked ONE AT A TIME; where the run is a sequence, derive position from the
+  highest stamp so one click marks everything below it — a parent that ticked its children wrote
+  what the reader never said (today's date onto milestones that happened on unrecorded days),
+  and a rung passed without a recorded day shows a BLANK date, which is the honest answer to
+  "when". **`ChecklistGroup` is a phase — a name, and at most a way to fold its rows away**: no
+  COMPLETION control, because a phase
+  owns no completion of its own and a ring there is a control that never responds (one identical
+  to the pressable rings beneath it invites the press it refuses); and no BODY, because a
+  condition hung off a heading leaves the reader working out which row it was about — a row's
+  wait (`meta`), warning (`ChecklistNote`) and act (`ChecklistActions`) sit on the row that owes
+  them. Groups and items are SIBLINGS in one run, so the ladder keeps one ring column, one text
+  edge and one line; a flat list renders no groups at all. **A checklist REPORTS — it does not
+  collect and it does not PREVIEW**: a field with a home elsewhere is named as a gap by a
+  `ChecklistNote` whose `action` jumps to the section owning it, never edited here (two edit
+  surfaces for one fact) and never rendered as a value (an avatar or badge is a copy to keep in
+  step). The exceptions are `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).
+  `ChecklistItem.meta` is two words on the title's row; prose that grows is a `ChecklistNote`,
+  which owns its line. Worked screens: `tpl_record` § Progress (connected, grouped) and its
+  document desk (unconnected set).
 - **`stepper`** — `Stepper` + `Step` — done/current/upcoming/warning/complete progress on a
   track (horizontal) or spine (vertical); compound `<Step status>children` OR data
   `steps[]`+`current`; **navigable** via `Step.onPress` (both orientations — the whole step
@@ -1350,7 +1307,7 @@ source (`src/<module>.tsx`/`.ts`) is the API reference.
   VERTICAL: the marker centres on the content's FIRST ROW, assumed to be one line of `sm` text.
   Put anything taller on that row — an inline editor beside the label — and pass
   **`Step.headHeight`** (`INLINE_CONTROL_HEIGHT` for an editor) or the marker stays pinned to
-  the text line while the label centres in the taller row. Prefer `PipelineStage.trailing`,
+  the text line while the label centres in the taller row. Prefer `ChecklistItem.trailing`,
   which does this for you.
 
 ### Files