@ai-matrx/records 0.8.0 → 0.16.0

package/CHANGELOG.md

@@ -1,5 +1,168 @@
 # Changelog — @ai-matrx/records
 
+## 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
+generated door catalogue is the store's` asserted `STORE_DOORS.length === live`,
+so every publish failed in which anybody anywhere had shipped a new `custom`
+routine — 337 mirrored against 342 live on 2026-09-20, and not one of the five
+was this package's. A release that red-lights on somebody else's work teaches
+everyone to ignore red.
+
+What the package must be right about is asserted and still gates: **every door
+this mirror names exists in the live store**. A name here the store does not
+have is this package claiming a door it cannot open, which is the whole reason
+`store.generated.ts` is generated rather than typed. Doors the store has and the
+mirror has not seen are REPORTED by name, loudly, and gate nothing.
+
+### Consumer action
+
+None. No API changed.
+
+## 0.10.0
+
+**The work layer has client doors, and this package can reach them.** Until lane
+WORK-DOORS (2026-09-20) all nineteen `custom.work_*` functions were SECURITY
+INVOKER, held no EXECUTE for `authenticated` and carried zero rows in
+`platform.client_callable_door`: REC-69 (assignment and action state), REC-70
+(template instantiation) and REC-71 (the slot hold) were live in the store and
+unreachable from a browser. Thirteen new client methods, all against doors that
+ask the one ladder first:
+
+* `workInbox` — **THE ONE QUEUE.** Assignments, approvals and the agent's
+  proposals in one ordered list with one row shape (PRODUCTS.md row 6).
+* `workList` — "my work", "work I assigned", "waiting on somebody being chosen",
+  across every Table in the organization, every row decided by the one ladder.
+* `workAssign` — the Assignee value AND editor access, in one transaction. An
+  assignment that did not give access put a row in somebody's inbox that they
+  were refused when they opened it.
+* `workRecordStates` / `workSetState` — the moves the workflow model allows, with
+  the sentence for each one it does not, so a screen offers real moves.
+* `workApprovalRequest` / `workApprovalMayDecide` / `workApprovalDecide` /
+  `workApprovalRead` / `workApprovalApprovers` — asking for a change instead of
+  making it, and a decision that **applies** the change in the same transaction.
+* `workPerson`, `workTemplates`.
+
+New types in `work.ts`: `WorkInboxItem`, `WorkListItem`, `WorkRecordState`,
+`WorkApprover`, `WorkApprovalFiled`, `WorkApprovalDecision`, `WorkAssignment`,
+`WorkChange`, `WorkInboxKind`, `WorkOrigin`, `WorkDueState`, `WorkListFlavour`.
+
+**Consumer action:** none required — every addition is new surface. A host that
+wants the inbox takes `@ai-matrx/records-ui` 0.15.0 with it.
+
 ## 0.7.2
 
 **The door catalogue, regenerated while the store was still growing.** 0.7.1