@ai-matrx/records 0.11.0 → 0.17.0

package/CHANGELOG.md

@@ -1,5 +1,159 @@
 # Changelog — @ai-matrx/records
 
+## 0.17.0
+
+**A list is a door, never a grant on the thing behind it.**
+
+`docTemplates`, `docRenders` and `docSignatures` read `custom.doc_template` (a
+view), `custom.doc_render` and `custom.doc_signature` (tables) with a direct
+PostgREST `.from()`. **None of those three holds a client SELECT**, and none ever
+should — so every plural act of document generation returned 403, and the
+try-everything page photographed *"permission denied for view doc_template"* on
+2026-09-20. A person could save a template they could never list and render a
+document they could never find again.
+
+All three now call doors that narrow inside the definer, after the ladder has
+spoken: `custom.doc_templates` and `custom.doc_renders` / `custom.doc_signatures`
+(viewer on the Table, viewer on the record). Two acts that had no door at all
+arrive with them:
+
+- **`docTemplateDelete({ template_id })`** — retire one template. Editor on the
+  Table it renders, because a template is that Table's wording. Soft only:
+  documents already rendered keep their frozen bytes and their seals, so
+  retiring a template can never invalidate a signature (VAL-10).
+- **`subscriptionCadences()`** — the cadences a subscription may be written
+  with, through the door a PERSON may call. `aggSubscriptionCadences` is the
+  notifier's own and holds no client grant, so every screen that asked for it
+  was refused and fell back to a word typed into the screen; this one delegates
+  to the same array, so a picker can never offer a cadence the digest runner
+  does not honour.
+
+`DocTemplateRow` drops `organization_id`, which the door does not answer and no
+caller read — the client already holds the organization. The door names its key
+`template_id` / `render_id` / `signature_id`; the package keeps `id`, mapped once
+here rather than renamed in four screens.
+
+`store.generated.ts` regenerated from the live store: **387 → 401 doors**.
+
+**Consumer action:** none for `docTemplates` / `docRenders` / `docSignatures` —
+same names, same row shapes, they simply stop being refused. The five doors they
+need are live on the main database (`doorstwo_the_document_and_cadence_doors.sql`
++ its grant file, applied 2026-09-20 13:43Z), so this version requires no
+migration of its own.
+
+## 0.16.0
+
+**A column is declared, and a client type can finally say so.**
+
+`NewFieldDeclaration` now names what `custom.field_declare` has actually taken
+since 2026-09-20: `type` (the one word every agent, script and import reaches
+for — the store resolves the thirteen parity types, the five behaviours and the
+plain synonyms, and refuses a word that means nothing by name), `config` (a long
+text's `multiline`, a list's existing options table — the door always read it and
+no client could send it), `relation_target` and `on_target_delete` (a column that
+points at another of this organization's own tables, which no client type could
+express at all), and `format` (the one shape `custom.doc_sign` accepts).
+
+`FieldPatch` gains the door's BEHAVIOUR arm — `parity_type`, `plain`, `type`,
+`multi` — plus `relation_target`, `on_target_delete`, `promoted`, `unique` and
+`depends_on`. It named only the settings, so the one caller that needed to move a
+column back onto the behaviour it is written against had no door and reached for
+`custom.record_update` instead, writing the document *under* the guards rather
+than through them. **`multi` is read only inside that arm: send the behaviour
+word with it or nothing happens.**
+
+**The columns come back in the order they were declared.** `custom.applicable_fields`
+answers a SET — its order is the plan's and it moves between calls — so every
+consumer of `client.fields()` was drawing columns in an arbitrary order. A table
+declared Title, Day rate, Due came back Day rate, Title, Due. The Field's own
+`sort` is applied once, here, so every screen, export, form and agent inherits it.
+
+**22007 is mapped.** The live-door census caught `custom.dashboard_window_sql`
+raising it; it reads as `invalid_argument`, like 42703 before it.
+
+**The live-door suite declared its own fixture the way the store no longer
+allows** — `custom.record_write` into the field kernel — so eighteen of its
+thirty-three clauses were red on `main` against the live store. It uses
+`custom.field_declare`. 33/33.
+## 0.15.0
+
+**A client portal has an owner's side, and this package can reach it.**
+`custom.portals`, `custom.portal_card`, `custom.portal_declare`,
+`custom.portal_invite`, `custom.portal_revoke` and `custom.portal_preview` have
+been live on the database and no client could call them, so the six doors that
+decide who signs in from outside an organization — and what they see — existed
+with nothing able to ask them. `store.generated.ts` was regenerated from the
+live store (372 → 387 doors) and the six are now on `client`:
+
+- `client.portals()` — every portal over this organization, with its client
+  Table, how many Tables it exposes, how many people are invited and how many
+  have actually signed in. The store filters the list on whether you may open
+  the client Table, so it never reveals a Table.
+- `client.portalCard({ portal_id })` — one portal in full: each exposed Table
+  with the relation Field that says whose a record is and the fields a client
+  sees and may change, every person with `signed_in` and `is_active` kept
+  APART, and `external_lane_open`.
+- `client.portalDeclare(...)` — create or RE-STATE one. Re-stating replaces
+  what the portal exposes and leaves the people alone.
+- `client.portalInvite({ portal_id, client_record_id, email })` — and it takes
+  no `user_id` on purpose. From a screen that value is always null: an
+  invitation confers NOTHING until the person follows their own sign-in link,
+  which is what the door's own `say` sentence states. A client that passed an
+  id would be granting access on somebody else's behalf.
+- `client.portalRevoke({ portal_id, principal_id })` — the answer's `say` names
+  the consequence in the past tense.
+- `client.portalPreview({ portal_id, principal_id, table_id })` — "view as this
+  client". The door asks `custom.visible_set` for HER user id, the same call
+  `custom.read_records` makes when she opens the page, so it cannot disagree
+  with what she sees. It REFUSES (`02000`, mapped to `not_found`) when she has
+  not signed in, rather than answering an empty list.
+
+New module `portal`, exported from the root: `PortalSummary`,
+`PortalTableExposure`, `PortalPrincipal`, `PortalCard`, `PortalInvitation`,
+`PortalRevocation`, `PortalPreviewRow`, and `portalPath(slug)` — the one place
+`/portal/c/<slug>` is written down.
+
+**Consumer action:** none required; every addition is new surface. A host that
+already builds a portal address by hand should use `portalPath` so there is one
+spelling of it.
+
+## 0.13.0
+
+**A choice value is the choice's own word, and this package says what that means.**
+A list Field's cell used to hold the option RECORD'S ID, so every read, filter,
+group-by, export and agent got back a uuid — the seventh independent pass failed
+acceptance test T8 on exactly that. The store now holds the option's own stable
+key, the read doors hand back the LABEL and name the key beside it in
+`_choices`, and a caller may write the label, the key or (so nothing that worked
+yesterday breaks) the option's id.
+
+New module `choice`, exported from the root: `optionKey`, `optionLabel`,
+`isTheChosen`, `choiceValuesOf`, `choicesOf`, `holdsARetiredChoice`,
+`choiceSlug`, `looksLikeAnId`, and the `ChoiceOption` type. `isTheChosen` is the
+one a control wants: it recognises a choice by its key, its label or its option
+id, which is what lets one picker read a document from any of the three eras.
+
+**Consumer action:** a control that compared a cell to `option.id` must use
+`isTheChosen` and write `optionKey(option)` — comparing against the id alone now
+shows nothing selected, because the read door hands back the label.
+
+## 0.12.0
+
+**A person can see what they are being told about, and switch one off.**
+`custom.subscriptions` and `custom.subscription_mute` have been live on the
+database since 20 September and no client could call them, so a form's "tell me
+when somebody answers" could be turned ON by an agent and never turned off by
+the person it was telling. `client.subscriptions({ table_id })` answers mine
+plus anyone's over a Table I hold admin on — narrowed to Tables I can already
+open, so the list never reveals one — and `client.subscriptionMute({ rule_id,
+muted })` is the switch. `MySubscription` carries the two things a screen needs
+and the notifier does not: `muted`, and `i_may_mute`.
+
+`aggSubscriptions` is unchanged and is still the NOTIFIER's reader, which no
+client can call. Muting is honoured inside that one reader, so a screen can
+never say a subscription is off while it keeps firing.
+
+
 ## 0.11.0
 
 **The publish gate stops red-lighting on other lanes' migrations.** `the