@ai-matrx/records 0.5.1 → 0.7.2

package/CHANGELOG.md

@@ -1,5 +1,138 @@
 # Changelog — @ai-matrx/records
 
+## 0.7.2
+
+**The door catalogue, regenerated while the store was still growing.** 0.7.1
+mirrored 300 doors and the gate, running twelve minutes later, counted 301 —
+another lane shipped one in the window. Regenerated: 301 doors. Nothing else
+changed.
+
+## 0.7.1
+
+**The live suite opens the switch the way the store resolves it.**
+
+0.7.0's release gate failed four clauses against the live store and none of them
+was about this package's code. `platform.knob_resolve` reads an organization's
+own override ABOVE the base knob row, and Test's Org gained one
+(`custom/system_enabled` = false, written through the ramp screen's own writer)
+— so the suite's in-transaction `update platform.feature_knob` stopped opening
+anything and three cases met the store's switched-off refusal. Both rungs are
+set inside the transaction now, for the member's organization and for the
+stranger organization the membership wall case names, and the `rollback` still
+puts both back.
+
+The fourth was the door catalogue: 293 mirrored names against 300 live doors,
+because other lanes added seven. `src/store.generated.ts` is regenerated from
+the live store — 300 doors, 35 knobs, 1020 entity tokens — which is the file's
+whole contract: nothing in it is typed by a person.
+
+## 0.7.0
+
+**A screen can ask what this person may do, before it offers it.**
+
+The 19–20 September verdict (sixth pass) watched a colleague who had been shared
+a table at Viewer double-click a cell, get a live editor, type a value and press
+Enter — and only then be told she may not write. "The permission is right; the
+screen told her she could." No screen could have done better: the store answers
+"what may this person do to this thing?" in exactly one place,
+`custom.effective_level`, which has no grant to `authenticated` and no decision
+of its own — it takes ANY principal and ANY subject, so granting it to clients
+would be handing out a visibility probe.
+
+- **`client.myLevels({ ids })`** — the new `custom.my_levels` door. What level
+  the CALLER holds on the subjects they name, with no principal argument: the
+  person is resolved from the session, so you can ask about your own access and
+  about nobody else's. It takes a LIST so a page of fifty rows is one call, and
+  **every id asked about gets a row** — `null` included, because a missing row
+  and "no access" would be the same thing to the screen that asked and one of
+  them is a silence. `null` for an id that does not exist is the same answer, so
+  it is not an existence oracle.
+- **`useMyLevel(id)` / `useMyLevels(ids)`** in `/react`.
+- **`level.ts`**: `PermissionLevel`, `PERMISSION_LEVELS`, `atLeast`,
+  `asPermissionLevel`, `highestLevel`. The ladder a screen compares with is the
+  ladder the door compares with; two orderings would be two answers to one
+  question and the second is always wrong.
+
+**What this release deliberately does NOT do.** A `Table.your_level` carried off
+the read door looked free and was wrong: `tableList` reads the Table KERNEL, so
+`read_records`'s `level` there is the caller's level on the kernel — viewer, for
+everybody — and not on the table that row describes. It was written, measured
+wrong within the hour (a table's own owner came back `viewer`), and removed; the
+reason is in `core/client.ts` where the next person will reach for it. A table
+is a record, and its level is asked for like any other record's.
+
+### Consumer action
+
+None required. `custom.my_levels` is live on the main database (lane UI-HONEST,
+`uihonest_a_screen_can_ask_what_it_may_offer.sql` +
+`uihonest_the_level_door_takes_a_json_list.sql`), so `myLevels` answers as soon
+as this version is installed.
+
+## 0.6.2
+
+The generated store contract, regenerated at 279 doors. 0.6.1's gate was red on
+nothing but the count: the door catalogue is asserted EQUAL to the live store's,
+and other lanes landed a door in the ten minutes between the regeneration and
+the publish. No source change and no consumer action.
+
+
+## 0.6.1
+
+0.6.0's release gate caught four things the live store had changed since the
+contract was generated, and this is all four.
+
+- **`54001` is a refusal class this package now knows.** `custom.record_delete`
+  stops a cascade that nests past sixty-four levels of containment — a loop
+  somebody built rather than a hierarchy — and it is a `store_limit`.
+- **The generated contract is regenerated at 278 doors.**
+- **The signed-out reach assertion excludes trigger functions**, for the reason
+  `platform.reopen_declared_doors` excludes them: they have no direct call
+  surface, so a grant on one says nothing about who can reach the store. Two
+  store triggers another lane landed turned it red while nothing about the
+  store's reach had changed.
+- **The read door decides the organization WALL before the switch.** It opens
+  with `custom.assert_may_know_table`, so a person outside an organization is
+  told they are not a member and is never told whether the store is on for it.
+  The adapter suite accepts both of the store's own sentences and no third one.
+
+### Consumer action
+
+None.
+
+
+## 0.6.0
+
+**A column can be added.** The store grew the three doors a Field always needed
+and this package carries them.
+
+- **`fieldDeclare`, `fieldUpdate`, `fieldRetire`** on the client, and
+  `useFieldMutation()` in `/react`. Until now a Field was written with
+  `recordWrite` into the field kernel, and that could never work: the one write
+  door writes `data_class = 'record'` and cannot ALSO add the key to the Table
+  record's `fields` array, which the store's field guard requires before it
+  accepts any definition at all. Every screen that tried ended on *"the table
+  does not declare a field called … — declare it there first"*.
+- **`NewFieldDeclaration`** — what a PERSON says when they add a column: a
+  parity type, a name, and for a choice list the choices themselves. The store
+  turns that into the behaviour, modifiers, format, unit, relation target,
+  relation maximum, compute_on and attached Rules its own guards demand, so a
+  client states an intention and never re-derives thirteen types of its own.
+- **`FieldPatch`** — a field's own settings. What a field HOLDS is a conversion
+  and the door refuses it here by name.
+- The generated store contract is refreshed to the live 260-door registry.
+
+### Consumer action
+
+Nothing breaks. A host that writes Fields with `recordWrite` should move to
+`useFieldMutation().declare` — the old path is the defect, not a deprecation.
+
+
+## 0.5.2
+
+Automatic changed-only republish (docs/metadata drift since the last tag — see
+`git diff npm/records/v0.5.1..npm/records/v0.5.2 -- apps/shared/records`).
+No source changes intended and no consumer action required.
+
 ## 0.5.1
 
 Refreshes the generated store contract to the live 240-door registry caught by