@ai-matrx/records-ui 0.51.0 → 0.53.0

package/CHANGELOG.md

@@ -1,5 +1,84 @@
 # Changelog — @ai-matrx/records-ui
 
+## 0.53.0
+
+**Every card on every board said "Loading…", forever.**
+
+Birchwood Avenue Renovation is a whole-house remodel run out of a spare bedroom.
+Her quotes board, grouped by Quote stage, had the counts exactly right — Accepted
+6, Expired 1, Pending 6, Rejected 1, No value 1, off her real quotes — and all
+fifteen cards under those headings read "Loading…" and never resolved. No error,
+no refusal, no spinner that ever stopped. She could count her quotes and could
+not open one.
+
+The cause was one missing argument. `scalarText` draws "Loading…" for an id it
+has no resolver for, and `Card` called it with no resolver at all, so a title
+Field of type `list` or `relation` could never resolve on any card, ever — and
+Birchwood's title field is `room`, a relation to her rooms table. `Kanban` asks
+the resolver for the GROUPING field, which is precisely why the headings read
+"Accepted" while the cards beneath them read "Loading…": two halves of one board,
+one asking and one not.
+
+`Card` is the card of the **kanban, the calendar and the gallery**, so one
+argument broke three layouts and one fix closes all three. The component that
+draws the value now declares the Field it is about to draw, which is also what
+makes a future surface unable to reintroduce this by forgetting; `want` is keyed
+by Field id, so two hundred cards still ask once.
+
+**And a card that cannot load now says why.** Declaring the Field is what lets
+the resolver SETTLE it. Once settled, an id it did not return is chased one at a
+time and comes back either as the record's own name or as the store's own
+sentence for a record this reader may not open
+(`platform.relation_withheld_label()`). "Loading…" is now only ever true.
+
+`src/card-names-what-it-draws.test.tsx` — three clauses, two shown RED on
+0.52.0's bytes ("Loading…") and green on these.
+
+## 0.52.0
+
+**Four things this package could make and no screen could reach: a form, a
+booking page, a client portal and a scheduled summary.**
+
+The product walk of 2026-09-21 opened a real table filled with a real business's
+records. The Forms, Bookings and Portals rails each said the same thing — *none
+yet, ask an agent for one in a sentence* — and offered nothing else to press;
+dashboards worked and nothing could schedule one. A person who did not know what
+to say to an agent was finished. The agent path is the faster one; it was never
+meant to be the only one.
+
+* **`BuildOrAsk`** — the shared empty state every builder now uses. Two buttons,
+  one row, every rail identical, the agent named first because it is faster and
+  the builder beside it because it always works. "Ask an agent" is the host's new
+  `onAskForOne` port and is **absent, never greyed**, when a host has not bound
+  it — only a server can honestly speak as an agent.
+* **Forms** — `FormBuilder` opens in place in the Forms rail. It has written the
+  same `custom.anon_form` row through the same `custom.form_declare` door since
+  0.33.0 and was reachable from nowhere.
+* **`BookingBuilder`** — Calendly's four decisions: how long an appointment is,
+  which hours of the week you are free, the gap kept between them, and what the
+  person sees after booking. It declares through `custom.booking_declare` and
+  shows the availability the STORE normalised, so the builder and the visitor's
+  picker cannot hold two ideas of what is free. `slot`, `status` and
+  `booked_with` are never offered — the door refuses a question naming any of
+  the three, and an always-refused control is a dead control.
+* **`PortalBuilder`** — four questions, and the second is the product: which
+  Table holds the clients, which Field on each exposed Table NAMES one of them,
+  what they may read, and separately what they may change. A Table with no
+  relation pointing at the client Table gets no field picker at all and the
+  remedy is named, because "only theirs" has to be answerable before anything is
+  published. Re-stating replaces what a portal shows and the screen says so
+  above Save; the invitation is a separate act and the door's own sentence is
+  shown verbatim, so "invited" is never read as "signed in".
+* **`DigestScheduler`** — "send this every Monday at 8 to these people", mounted
+  on the dashboard and in the notifications rail. It saves the thing in front of
+  the person as a view (`custom.view_declare`) and writes the subscription over
+  it (`custom.subscription_declare`). No new cron and no second notifier: the one
+  pg_cron tick and `communication.notification` do the work. "These people" is
+  one subscription each, deliberately — admission is tested as the SUBSCRIBER, so
+  three recipients is three tests and three summaries, each holding only what
+  that person may see — and the per-person outcome is shown, so a partial success
+  is never reported as a whole one.
+
 ## 0.51.0
 
 **Paste fifty rows out of a spreadsheet, see what they will become, and only