@ai-matrx/records-ui 0.51.0 → 0.52.0

package/CHANGELOG.md

@@ -1,5 +1,50 @@
 # Changelog — @ai-matrx/records-ui
 
+## 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