@ai-matrx/records 0.52.0 → 0.53.0

package/CHANGELOG.md

@@ -1,5 +1,74 @@
 # Changelog — @ai-matrx/records
 
+## 0.53.0
+
+**Archiving a table is a job, not a statement.** (lane FIX-11A, VERIFIER-11 finding F3.)
+
+An admin of Greenline Landscaping Crew opened Settings on "Riverside Yard season tickets"
+— 1,430 records the product's own import had just written — pressed **Delete this table**
+and waited twelve seconds for `57014`, "canceling statement due to statement timeout …
+Nothing was changed. Try a smaller page." There is no page. `custom.record_delete` aimed at
+a Table recurses through everything the Table contains inside ONE transaction: a delete
+rule, an access check, a history capture and an outbox row per record. That is unbounded by
+construction — no timeout is long enough — and a store whose write path is batched and
+whose delete path is not has one honest shape available to it.
+
+* New client method `tableArchive({ table_id, chunk, includeTable })` over
+  `custom.table_archive`, typed as `TableArchiveProgress`: `archived`, `remaining`,
+  `total`, `archived_total`, `table_archived`, `done`, `chunk` and the store's own
+  `message`. `chunk: 0` reports and changes nothing, so a screen can say how many records
+  will be archived BEFORE a person commits to it.
+* New hook `useTableArchive(tableId, { chunk, includeTable })` — it owns the loop, the
+  numbers, the stop and the resume, so every screen that ever gets rid of a table inherits
+  one behaviour instead of each re-deriving it. Resumable because it is STATELESS: what
+  remains is read off the records themselves every pass, so a refused pass, a `stop()`, a
+  closed tab or a deploy mid-run leave `interrupted` true and a `carryOn()` that continues
+  from exactly where it stopped. It must never be reported as "nothing happened":
+  `archived_total` is what actually landed.
+* **The pass size is 50, measured, and it backs off.** One record costs about 35ms to
+  archive on the live store, so a pass of 200 is ~7s against an 8s statement timeout — it
+  died on `57014` on the first real table it was pointed at, which is the original defect
+  one level up. When the store does run out of time the loop HALVES the pass and carries
+  on (floor 10, `slowedDown` true so a screen can say so), because a pass that timed out
+  changed nothing and retrying it smaller repeats no work.
+* Nothing is hard-deleted: every row still goes through `custom.record_delete`, so every
+  guard, history capture and outbox row happens and `recordRestore` still brings it back.
+
+Proven on the main database on 2026-09-22 from the admin seat, through this package's own
+client: 1,430 records archived in 25 passes across a deliberate cut and a resume (450 at
+the cut, 1,430 at the end), then 312 more in 7 passes. Consumer action: a screen that
+deletes a whole Table must call `useTableArchive`, never `useRecordMutation().remove`;
+matrx-frontend's `pnpm check:table-archive-is-chunked` fails on the old shape.
+
+## 0.52.0
+
+**The portal archive doors are reachable.** (lane PUBLISH-SWEEP, closing ORG-CLEANUP's
+own "left behind, named".)
+
+* `custom.portal_archive`, `custom.portal_restore` and the archive-aware
+  `custom.list_portals(org, 'active'|'archived'|'all')` landed on the main database on
+  2026-09-22, and nine of Rincon Plumbing Co's ten identical portals were archived through
+  them FROM A SCRIPT. This package knew none of them, so from every client those nine simply
+  ceased to exist: `custom.portals` hides archived portals by design and there was no other
+  reader, no restore, and no archive.
+* New client methods: `listPortals({ archived })`, `portalArchive({ portal_id, confirm_title,
+  reason })`, `portalRestore({ portal_id, confirm_title })`, over the three new door names.
+* New vocabulary and words, so every screen says the same thing: `PORTAL_ARCHIVE_FILTERS` /
+  `PortalArchiveFilter` / `isPortalArchiveFilter` (three values, no fourth — the door refuses
+  a fourth `22023`), `PortalArchiveAnswer`, `portalArchiveConsequence`, `portalConfirmLine`,
+  `portalTitleTypedBack` and `emptyPortalArchiveLine`. The typed-title confirmation is the
+  DOOR's rule, not a screen's ceremony: ten portals can carry one title, so the title is not
+  what picks this one and `23514` is what says so.
+* `src/store.generated.ts` regenerated from the live store (570 doors), which also picks up
+  IMPORT-2's `custom.io_import_declare_columns`.
+
+**The import wizard adds the columns as its own step.** (lane IMPORT-2.)
+
+* `importDeclareColumns` over `custom.io_import_declare_columns`, and the batch size the store
+  itself sizes, so a wide file stops being one statement the store refuses.
+
+**Consumer action:** none — everything here is additive.
+
 ## 0.51.0
 
 **The seal is asked through its own door.** (lane FIX-10B, from VERIFIER-10 finding F6.)

package/dist/core/index.cjs

@@ -1469,6 +1469,7 @@ var STORE_DOORS = [
   { name: "stamp_value_envelopes", args: "p_data jsonb, p_actor text, p_on_behalf_of text, p_at timestamp with time zone", returns: "jsonb", security: "invoker" },
   { name: "storage_modes", args: "", returns: "text[]", security: "invoker" },
   { name: "store_is_open", args: "p_organization_id uuid DEFAULT NULL::uuid", returns: "boolean", security: "invoker" },
+  { name: "store_off_sentence", args: "p_organization_id uuid", returns: "text", security: "invoker" },
   { name: "subscription_cadences", args: "p_organization_id uuid", returns: "text[]", security: "definer" },
   { name: "subscription_declare", args: "p_organization_id uuid, p_table_id uuid, p_spec jsonb", returns: "uuid", security: "definer" },
   { name: "subscription_mute", args: "p_organization_id uuid, p_rule_id uuid, p_muted boolean DEFAULT true", returns: "boolean", security: "definer" },
@@ -2751,6 +2752,19 @@ var DOORS = {
   fieldOptions: "field_options",
   parityValues: "parity_values",
   tableDeclare: "table_declare",
+  // GETTING RID OF A TABLE — which is a JOB, NOT A STATEMENT (VERIFIER-11 F3).
+  // `record_delete` above is the store's one soft-delete door and it is right
+  // for a record; aimed at a TABLE it recurses through everything the Table
+  // contains inside one transaction, and that is unbounded by construction. A
+  // person pressing "Delete this table" on 1,430 records the product itself
+  // had just imported waited twelve seconds and was told `57014`, "canceling
+  // statement due to statement timeout … Nothing was changed. Try a smaller
+  // page" — advice that means nothing when what you are doing is getting rid
+  // of a table. `custom.table_archive` does the same work in passes and
+  // answers each one with numbers, so a screen shows a sentence and a count
+  // instead of a spinner and an SQLSTATE. It is STATELESS, so a run cut in
+  // half resumes exactly where it stopped: there is no job row to lose.
+  tableArchive: "table_archive",
   // ADDING A COLUMN — the first thing anybody does with a table, and until
   // 2026-09-19 there was no door for it. A Field is a record (REC-25), so a
   // screen wrote one with `record_write`; that door writes ONE row with
@@ -3414,6 +3428,18 @@ function createRecordsClient(config) {
         "recordRestore"
       );
     },
+    async tableArchive({ table_id, chunk, includeTable }) {
+      return callDoor(
+        DOORS.tableArchive,
+        {
+          p_organization_id: org,
+          p_table_id: table_id,
+          p_chunk: chunk ?? 50,
+          p_include_table: includeTable ?? true
+        },
+        "tableArchive"
+      );
+    },
     async recordRead({ record_id, withComputed = false }) {
       const door = await callDoor(
         DOORS.readRecord,