@ai-matrx/records-ui 0.75.0 → 0.77.0

package/CHANGELOG.md

@@ -1,5 +1,68 @@
 # Changelog — @ai-matrx/records-ui
 
+## 0.77.0
+
+**A publish button that would hand out a dead link is not drawn.** (lane STORE-OFF, from
+FIX-10A's own "left behind, named".)
+
+Of the seventeen published forms live on the main database on 2026-09-22, three belonged to
+ONE organization whose record store is switched off — and `custom.form_public` answered every
+one of them with nothing, which the public route turned into a 404. Their owner pressed
+Publish here, was handed a URL, and sent it to her customers.
+
+The STORE always said no: `custom.anon_publish` opens with `custom.assert_store_door`, which
+refuses 42501 while the switch is down. What was missing was the SCREEN. `usePublishGate`
+(new, exported) asks `custom.store_is_open` once per mount, and the forms rail, the form
+builder and the booking builder all read it — so one switch cannot be described three ways.
+The control is ABSENT, never greyed, and `PUBLISH_NEEDS_THE_STORE_ON` says where the switch
+is and that nothing already built is lost.
+
+An unreadable switch is deliberately NOT treated as a closed one here — the opposite of the
+store's own rule, for the opposite reason: on a screen the cost of guessing wrong is hiding a
+button from somebody who may press it, so only a definite `false` removes anything and the
+door still refuses.
+
+Guard: `src/a-publish-control-needs-the-store-on.test.tsx`, shown RED (1 of 2 clauses) on the
+bytes before this change and GREEN after.
+
+**Consumer action:** none — no API changed. `usePublishGate` and
+`PUBLISH_NEEDS_THE_STORE_ON` are available to a host that wants the same gate on its own
+publish surface.
+
+## 0.76.0
+
+**An archived portal was reachable from nowhere.** (lane PUBLISH-SWEEP, closing ORG-CLEANUP's
+own "left behind, named".)
+
+* The store grew `custom.portal_archive`, `custom.portal_restore` and the archive-aware
+  `custom.list_portals`, and nine of Rincon Plumbing Co's ten identical "Your jobs and
+  invoices" portals were archived through them from a script. No screen could do any of it:
+  the Portals rail reads `custom.portals`, which hides archived portals by design — so those
+  nine vanished from every client in the platform, with no way to see one, no way to bring one
+  back, and no way to archive the tenth when somebody made another mess. The same shape
+  `ArchivedView` closed for records, one surface later.
+* `ArchivedDisclosure` (new, exported) is the archived-items law's ONE CLICK, written once so
+  any rail that grows an archive reveals it with the same control and the same words:
+  the default hides, one press on the surface itself reveals, and an empty archive is a
+  sentence rather than a blank.
+* `ArchivedPortals` (new, exported) reads `list_portals(org, 'archived')` — the archive-aware
+  door, never a filter over a list that already hid them — and restores through the store's own
+  door with the portal's title typed back. It is organization-wide on purpose: a portal is
+  archived because nobody is standing on it, and narrowing the archive to the Table you happen
+  to be on is how an archived portal becomes unreachable from every page at once.
+* `PortalsPanel` grows both halves: Archive on a live portal, with the consequence said in the
+  words of what actually happens before the click and the store's own sentence after it, and
+  the archive below the list, re-read whenever the rail changed something or somebody reveals
+  it.
+
+Guard: `src/an-archived-portal-can-come-back.test.tsx` (Meridian Tax & Bookkeeping's three
+identical client portals), shown RED on the rail wiring removed and the archive lane wrong,
+then GREEN.
+
+**The import wizard adds the columns as its own step.** (lane IMPORT-2.)
+
+**Consumer action:** none — everything here is additive.
+
 ## 0.75.0
 
 **0.74.0 was tagged and never reached npm** — its release gate failed on