@ai-matrx/records-ui 0.40.0 → 0.42.0

package/CHANGELOG.md

@@ -1,5 +1,110 @@
 # Changelog — @ai-matrx/records-ui
 
+## 0.42.0
+
+**A pipeline table opened as "pick a column", and the board it already had was
+unreachable.**
+
+Measured in the real app (lane SCREENS-2, 2026-09-20) against a real pipeline —
+five stages, a moves rule, a requires rule and a WIP limit of 2.
+`custom.pipeline_read` answered `is_pipeline: true` with `stage_field: "stage"`,
+every rule beside it, and the kanban drew
+
+> A kanban board needs a Field to make its columns from — pick one and the board
+> appears.
+
+Two things stacked. `Board`'s "no grouping field" gate sat ABOVE its pipeline
+branch, and `useIsPipeline` answered `stage.key === groupField` — so a table was
+only a pipeline once somebody had ALREADY guessed which column to group by. The
+store knew the answer the whole time and the screen asked the person for it. A
+board nobody can reach without knowing the answer in advance is not a board.
+
+The stage column is now the TABLE's own answer (`custom.table_stage_field`), used
+both to know the table is a pipeline and to know which column its columns come
+from. A view that names its own grouping column still wins — grouping a pipeline
+by its owner is a real thing to want, and it draws the plain board of that column
+and says so. While the table has not answered, NOTHING is claimed in either
+direction: the "pick one" sentence would be a question about to answer itself.
+
+`src/pipeline-reach.test.tsx` is at the one seam that decides it
+(`boardColumnChoice`, exported for exactly that reason) and all four clauses fail
+on 0.41.0's bytes.
+
+**Consumer action:** none. `ViewSwitcher`'s props are unchanged.
+
+## 0.41.0
+
+**The last two product screens that could not work at all, rewritten against the
+doors the store actually has. PRODUCTS rows 13 and 14 (lane SCREENS-2).**
+
+Both components shipped, were exported, and were mounted NOWHERE — and neither
+could have worked if it had been.
+
+**`ChecklistRunner` kept its own store.** It was written before the store had
+checklists, so it built one out of the generic work-template doors and kept the
+run in a package-owned Table (`records_ui_checklist_run`) whose columns were
+`step_ids` as a JSON string that `JSON.parse` decided the steps from. That is the
+same defect `ActionInbox` had — a second store beside the store — and it meant the
+screen could do none of the things a checklist is FOR: no roles, so no step
+belonged to anybody by their part in the process; no due dates, so "day one" and
+"by Friday" had nowhere to live; no dependencies, so a step could be ticked before
+the one it waits for and nothing had told the store to refuse it; no requirements,
+so "done" was a person clicking a word; no trigger, so a run started by hand every
+time.
+
+It is now three mounts of one component over the store's own nine checklist doors:
+the **record page** (the checklists running on this record, and the templates that
+could be started on it), the **table's own Checklists rail** (`ChecklistsPanel` —
+the templates, the runs, the progress, and a plain-rows editor that asks
+`custom.checklist_refusal` on every change so the store's sentence arrives before
+the save), and the **inbox** (`MyChecklistSteps` — a checklist step is a work item,
+so it reaches its owner where her approvals already are, asked through the door
+that also knows what the step asks for and whether it may be finished).
+
+Nothing is decided on the screen. `may_complete` and `refusal` are the store's
+answers per step and per seat, and `blocked_by` is what tells the door's two kinds
+of "no" apart: *waiting on another step*, which has no control at all, and *asks
+you to say what you did*, which is the box beside the button. A screen that read
+the sentence's wording would be a second opinion, and it would be the comfortable
+one — the one nobody can be refused by.
+
+**`BookingSlots` was a slot picker for a person who has no account.** It called
+`tableList`, `personKernelId`, `recordWrite`, `workSlotsDeclare`, `workSlotHolds`,
+`workSlotHold` and `workSlotRelease` — seven doors granted to `authenticated` —
+for a VISITOR, who can reach none of them. It also built its own grid of times in
+the browser from an `availability` prop, which is a second idea of what is on
+offer, and declared a THIRD slots Table under its own slug beside the one
+`custom.booking_declare` finds-or-makes, so a page opened through the component and
+a page opened through the link protected different indexes.
+
+It is now the owner's panel, the way `FormsPanel` is for forms: `custom.bookings`
+for the pages, their four counts and the next appointment in words in the
+ORGANIZATION's own zone, the visitor's link, and open/close through
+`custom.anon_publish` — offered only where `custom.my_levels` answered `admin`, and
+never while that door is still in flight. It mounts on the Records home (absent
+when the organization has none) and on the bookings table's own rail. The picker is
+the public `/b/<id>` route's, server-fed and server-lane; a suite clause fails if
+any of those nine doors is ever called from here again.
+
+**Consumer action:** `CHECKLIST_TABLE` is gone, and so is the run store it
+described — a run is `custom.checklist_runs`' and its steps are work items.
+`ChecklistSpec` / `ChecklistStepSpec` are no longer re-declared here; import them
+from `@ai-matrx/records`, which is where the store's own judge
+(`custom.checklist_refusal`) reads them from. `BookingSlots` no longer takes
+`form` or `availability`; it takes an optional `tableId` and nothing else.
+`ChecklistRunner`'s `seed` prop is gone — a checklist is declared through
+`checklistDeclare`, whole, and judged before a single step is written.
+
+**The proof.** `demo/checklists.test.tsx` and `demo/bookings.test.tsx` are in the
+blocking gate against RECORDED REAL answers taken from the one database by
+`demo/fixtures/*.record.sql`, from the `authenticated` seat, through the doors
+alone, rolled back. The checklist recording is a two-seat run — an admin describes
+onboarding once, a new hire record arrives, a run starts by itself, four steps land
+on two real people, and the same run answers differently from each of their seats.
+The booking recording is a whole lifecycle in five snapshots: open, held, booked,
+rescheduled, cancelled. `src/checklists.red.tsx` and `src/bookings.red.tsx` are the
+red twins; all six clauses fail on these bytes.
+
 ## 0.40.0
 
 **Pressing "Settings" on a table crashed the whole page, and had since the