@ai-matrx/records 0.17.0 → 0.21.0

package/CHANGELOG.md

@@ -1,5 +1,154 @@
 # Changelog — @ai-matrx/records
 
+
+## 0.21.0 — 2026-09-20
+
+**The store moved and this package's census caught it — twice.** The release
+gate runs the live-door suite against the real record store, and it went red on
+main:
+
+- `src/store.generated.ts` regenerated from the live store. The value envelope
+  gained `pinned`, the door census gained `conversation_scope` and its bind /
+  unbind / context siblings (478 doors, up from 428), and the knob list grew to
+  43. Nothing in that file is typed by a person.
+- **SQLSTATE `22003` is mapped.** `custom.context_resolve` raises it — a number
+  the store could not hold at the size it was handed — and this package did not
+  know the class, so it would have read as `internal` in somebody's console. It
+  is `invalid_argument`, the same class `22P02`, `42703` and `22007` already
+  are: the call named a value the shape does not accept, and the store's own
+  sentence names the number and the range.
+
+> **About 0.20.0 on npm.** This lane tagged `0.20.0` from a commit that carried
+> the census fixes above but NOT the checklist doors below — the tag was pushed
+> while a merge of main was still open, and a tag is never moved. `0.21.0` is
+> the first version that carries both. Nobody should sit on 0.20.0.
+
+
+## 0.20.0
+
+**"Every new hire gets these twelve steps." — the checklist doors, PRODUCTS row 13.**
+
+A checklist template is a record of the store: ordered steps, each with the role
+that owns it, how many days in it is due, what it waits for and what it asks for
+before it counts as done, plus the thing that starts a run. Starting one makes
+ONE work item per step in the one work layer — assigned by role to real people,
+dated from the offsets, dependencies carried across — so a step appears in the
+person's ordinary inbox beside everything else and there is no
+checklist-shaped queue anywhere.
+
+Nine doors, all of them live on the main database:
+`checklistRefusal` (pure — a screen may ask it on every keystroke, and the
+refusal arrives before the save), `checklistDeclare`, `checklistTemplates`,
+`checklistTemplateShape`, `checklistStart`, `checklistRun`, `checklistRuns`,
+`checklistStepComplete`, `checklistStepRefusal`.
+
+`ChecklistRunStep` carries `blocked_by`, `refusal`, `may_complete` and
+`requires_key`, so a screen can say why a step cannot be finished yet — in the
+words a person would use — before anybody clicks, file the evidence under the
+key the checklist itself named, and show no control at all where a control would
+fail.
+
+THE DEPENDENCY RULE LIVES IN THE STORE, not in these methods: a BEFORE trigger
+on `custom.record` refuses a step reaching Done while a step it waits for is
+open, so `workSetState` meets the same sentence `checklistStepComplete` does.
+
+
+## 0.19.0
+
+**"Pull my spreadsheet in" — the import doors, and the address a Table can own.**
+
+`core/io.ts` has parsed CSV and XLSX bytes since W4-IO, and `ImportWizard` then
+wrote the rows one at a time through `recordWrite` — one HTTP round trip per
+row, no duplicate check, no provenance, and a refusal that carried a row NUMBER
+into a file the screen no longer had. Every one of those is a way to lose data
+quietly at 5,000 rows.
+
+Eleven client methods arrive. The BYTES are still parsed here, because Postgres
+cannot unzip a workbook; **everything after the parse is the store's**, so a file
+imported from a screen, from an agent and from a script land identically and
+there is no second importer in this package to drift.
+
+- **`importPlan({ table_id, columns })`** — what the store makes of a file's
+  columns before anything is written, reading the parity map AND this
+  organization: an address that belongs to a member is a `member` column, a few
+  repeating words are a `select` with its options, `$1,250.00` is `currency` with
+  its unit, a column of names that are all records of another Table is a
+  `relation` at it. Every answer carries one sentence saying why, and two columns
+  that would make the same key say so.
+- **`importBegin(...)`** — opens a run with the file's sha-256 as its IDENTITY.
+  The same bytes into the same table a second time answer the FIRST run with
+  `already: true` and write nothing, so **a re-import doubles nothing**. Carries
+  the duplicate key and the policy the whole run obeys.
+- **`importRows({ import_id, rows, mapping })`** — a BATCH. Every row goes
+  through the one write door inside its own subtransaction and comes back with
+  one of exactly three outcomes: `landed` with the record id, `duplicate` with
+  the id of the record already there, or `refused` with the store's own sentence
+  **and the source row**, so an outcome table is clickable. Every value that
+  lands carries `{"kind":"import", …}` as its source (VAL-1).
+- **`importFinish({ import_id, unmapped })`** — closes the run and sends every
+  column the file had and the table did not to the **ONE approvals inbox**
+  (`propose`, the default and the only choice a non-admin has), or adds them
+  outright (`create`, an admin's), or leaves them out. Never a junk bag.
+- **`importReport`**, **`imports`**, **`importForget`** — the refused and
+  already-here rows with their source, this organization's runs, and forgetting
+  a receipt so the same bytes can be imported again deliberately.
+- **`inboundDeclare` / `inboundAddresses` / `inboundSet`** (DOOR-19) — the
+  address a Table owns. `inboundDeclare` answers with **`mail_route`**: the one
+  sentence saying what has to exist in DNS before anything arrives. Show it
+  wherever the address is shown. The gateway's own landing door is deliberately
+  absent from this client — it is `service_role`'s alone.
+
+New types in `@ai-matrx/records`: `ImportPlan`, `ImportColumnPlan`,
+`ImportPolicy`, `ImportOpened`, `ImportOutcome`, `ImportProposal`,
+`ImportBatchResult`, `ImportFinished`, `ImportReport`, `ImportRun`,
+`InboundAddress`, `InboundDeclared`.
+
+`store.generated.ts` regenerated against the live store: **428 doors**.
+
+## 0.18.0
+
+**"Who changed this price, and can I put it back?" — the doors for PRODUCTS row 4.**
+
+The store has kept every version of every record since W3-HIST: one append-only
+chain covering Values AND structure, with the compound verb that wrote each
+version stamped on it since MERGE-HISTORY. None of it reached a screen. The only
+thing a client could ask for was `revisions()` (`custom.io_revisions`), which
+answers a version number, a moment, a RAW UUID for the author and a list of
+KEYS — so a timeline could say "something changed" and could not say who, what
+it was before, or which Rule produced a derived value.
+
+Seven client methods arrive:
+
+- **`recordHistory({ record_id })`** — one record's versions, newest first, each
+  naming the author as `user` / `agent` / `system` **and, for an agent, the
+  person it acted for**, the operation in the word somebody used, and every
+  field that moved with its `before`, its `after`, the Rule VERSION that
+  produced a derived value and its interned source pointer. Viewer.
+- **`fieldHistory({ table_id, field_key })`** — one column's history across a
+  whole Table ("who changed the price on ANY record"), narrowed to the records
+  this person may see by a predicate in the same statement. A column that names
+  no Field is refused BY NAME.
+- **`restorePreview({ record_id, version, field_key? })`** — what a restore
+  would change, BEFORE it does, computed by the body that computes the write.
+  Editor: the first half of an act is not shown to somebody who may not do it.
+- **`restoreVersion`** and **`valueRestore`** — put the whole record, or ONE
+  column (HIS-N-2), back to what it said at a version. Both write a NEW version
+  through the record's own write path; no stored version is ever altered.
+- **`commentThread`**, **`commentWrite`**, **`commentResolve`** — SCR-18, at the
+  store's own `commenter` rung, with everybody NAMED, a comment anchored to one
+  Field, and a mention that notifies the person named.
+
+**Consumer action:** none required. `revisions()` is unchanged and every
+existing caller keeps working. A screen showing a record's past should move to
+`recordHistory` — `revisions()` cannot answer who, and was never able to.
+
+**And two defects in the store this came with**, both fixed in the same session
+and both reaching every existing caller: `custom.io_restore` did not restore (it
+patched the old document through a merging write, so a key added after the
+target version survived its own restore in silence), and it returned NULL to
+every caller it has ever had (it read the version out of the read door, which
+answers a document, and `version` is a column).
+
 ## 0.17.0
 
 **A list is a door, never a grant on the thing behind it.**