@ai-matrx/records-ui 0.38.0 → 0.41.0

package/CHANGELOG.md

@@ -1,5 +1,136 @@
 # Changelog — @ai-matrx/records-ui
 
+## 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
+enrichment panel was added.**
+
+Lane LAND-SCREENS pressed it in a production build of the app, signed in as the
+admin who owns the table, and the route went to the application's global error
+boundary with React #310 — *"Rendered more hooks than during the previous render."*
+Everything on that panel went with it: rename the table, add a column, take one
+off, reorder, delete the table, and the enrichment panel itself, which lives behind
+a column's own row and was therefore unreachable in the shipped build.
+
+**The cause, and why no suite saw it.** `TableSettings` declared `useState` for the
+enrichment panel BELOW three early returns, one of which fires on the FIRST render
+of every real mount: a host that lets the store decide rights binds no `rights`
+port, so `useTableRights(table.data)` answers `NO_RIGHTS` until `useTable` and
+`custom.my_level` come back. Render one ran eight hooks and returned the "you may
+not change the structure" line; render two, a moment later, ran nine. Every test in
+this package binds `rights: () => tableRightsAt("admin")`, which never takes that
+return — so the panel was only ever rendered with nine hooks and the order never
+changed.
+
+`src/TableSettings.hooks.test.tsx` mounts the panel with NO rights port, which is
+the seat the product actually uses, and fails with that exact error on the previous
+hook order.
+
+Also: `src/form-publish.test.tsx` had two TS7006 implicit-`any` parameters that had
+`tsc --noEmit` red on this package on `main`. Typed; the package typechecks clean.
+
+## 0.39.0
+
+**The kanban view becomes the board, with the store judging every drag.**
+
+`PipelineBoard` renders THROUGH the view that already exists — `ViewSwitcher`'s
+kanban layout — rather than beside it. It draws the very same rows the view holds;
+what it adds is the store's judgement.
+
+* **Drag between columns.** A drop asks `custom.pipeline_transition_refusal` first
+  and either writes the move or leaves the card exactly where it was, carrying the
+  store's own sentence, verbatim. Nothing is written on a refusal, so there is no
+  snap-back to animate — the card never moved.
+* **A stage's demands, prompted on the way in.** When the refusal names the columns
+  a stage needs, they appear on the card with a field each and one button, so the
+  person finishes the move instead of being sent away from it. Until every demand is
+  answered there is no button to press, rather than one that looks live.
+* **Column headings carry the store's numbers** — the count, the chosen measure's
+  total, and the column's limit — over every record this person may see, not over
+  the page the screen happened to load. Which column is totalled is a fact about the
+  VIEW, saved on it like its colours.
+* **A work-in-progress limit shows on the column it belongs to**, and a column over
+  its limit says so in a sentence rather than only turning red.
+* **A viewer's card has no drag handle at all.** Absent rather than dead.
+
+A table that is not a pipeline draws the plain kanban exactly as before; the
+decision is the Table's own `stage_field`, asked once, never guessed from the shape
+of a Choice column.
+
+
 
 
 ## 0.38.0 — 2026-09-20