@ai-matrx/records 0.24.0 → 0.27.0

package/CHANGELOG.md

@@ -1,5 +1,102 @@
 # Changelog — @ai-matrx/records
 
+## 0.27.0
+
+**"Give me a board of deals by stage" — the rules that judge every move become
+something a screen can ask about before the finger lets go.**
+
+A pipeline is not a new kind of thing and this release adds none. It is a Choice
+Field a Table names as its stage field, plus transition Rules of the ONE Rule
+object — so a move is an ordinary record write the store judges, History records
+because it IS a write, and every surface already knows how to read.
+
+`src/pipeline.ts`: `Pipeline`, `PipelineStage`, `PipelineRule`, `PipelineColumn`,
+`PipelineVerdict`, `PipelineMissingField`, `PipelineDeclared`, `PipelineSpec`.
+
+Six client methods, each one door: `pipelineRead`, `pipelineBoard`,
+`pipelineTransitionRefusal`, `pipelineMove`, `pipelineDeclare`, `tableStageField`.
+
+THIS PACKAGE ENFORCES NOTHING, and that is the point. `pipelineTransitionRefusal`
+asks the store the same question the write will ask — the same Rules, through the
+same evaluator, on the document the move WOULD produce — and hands back the store's
+own sentence plus, when a stage demands columns that are empty, exactly which ones.
+A board that decided in the browser would be a second opinion with nothing keeping
+it equal to the first, and it would be the comfortable one, because it is the one
+nobody can be refused by.
+
+`mayDrag(level)` is the one thing this package DOES decide, and it is about the
+person, not the rules: a viewer's card carries no drag handle at all rather than
+one that looks live and snaps back every time.
+
+## 0.26.0
+
+**"Text me on a new lead; email me a Monday summary" — the second half of that
+sentence becomes something the store can be told.**
+
+A cadence was two words, `immediate` and `digest`, and `schedule` was free text
+nothing read. `SubscriptionCadence` is now `instant | hourly | daily | weekly` —
+the words `custom.agg_subscription_cadences()` answers and the digest runner acts
+on. The two old words still work everywhere: the store normalises them, so a Rule
+written last week and one written by the picker today mean the same thing.
+
+`MySubscription` gained the three answers a notifications list actually needs and
+could not ask for: `quiet_hours`, `last_sent_at` and `next_digest_at`. The last is
+computed by the SAME store functions the runner uses, so "next Monday 08:00" on the
+screen and the moment it fires cannot drift; it is null for a muted subscription,
+because saying "next Monday" beside a switch that is off is a screen that lies.
+
+Two doors that did not exist:
+
+* `subscriptionDeclare({ table_id, spec })` — WRITE one. The store refuses a cadence
+  no runner acts on, a channel this platform does not send on and quiet hours nobody
+  can parse, each by name, then declares the Rule through `rule_declare` (REC-72: a
+  Rule written as a record is invisible to every reader that goes looking for one).
+* `subscriptionPreview({ rule_id })` — the summary it would send RIGHT NOW, with what
+  entered, left and changed NAMED rather than counted, plus the in-view total and a
+  click-through to the filtered grid. It assembles only: nothing is delivered,
+  nothing is recorded, and the watermark does not move.
+
+`QuietHours`, `DigestPreview` and `SubscriptionSpec` are new exported types.
+`store.generated.ts` regenerated from live — 520 doors, `check:store-registry` OK.
+## 0.26.0 — 2026-09-20
+
+**The queue was filing every refusal as a hiccup, and a real browser found it.**
+
+`isDecided` listed SQLSTATEs. `RecordsClient` hands back its own WORD —
+`invalid_argument`, `door`, `refused_by_rule` — with the sqlstate beside it, so
+no refusal ever matched: a capture the store had refused BY NAME went back in the
+queue and would have been sent again forever, which is the exact silent hole the
+queue's fourth decision exists to prevent. The unit suite passed throughout
+because it fed the check SQLSTATEs — it was testing the assumption, not the
+client. Measured in a headless Chromium at 390 px against the main database.
+
+It is now the other way round, and from the package's own list rather than a
+guess: `stale_read`, `timed_out` and `store_limit` are worth repeating (which is
+what `results.ts` says in as many words), a failure with NO code at all is the
+network and waits, and everything the door named is a decision that stays.
+`isDecided` takes the error, not a code, so either spelling works.
+
+
+## 0.25.0 — 2026-09-20
+
+**A crew out in the field, and a phone with no bars (PRODUCTS row 15, P13).**
+
+* `captureSheetDeclare`, `capturePublish`, `captureSheets`, `captureOpen` and
+  `captureSubmit` — the five SIGNED-IN doors of a crew capture sheet. A capture
+  sheet is not a second form store: it is the ONE Form object saying
+  `audience = 'crew'`, opened by `capture_opened_at` rather than `published_at`,
+  and the database carries a CHECK that refuses a row which is both. `captureOpen`
+  answers `null` for a sheet below `viewer` AND for a sheet that is not there —
+  the same answer the Table gives — and carries an honest `may_capture` with a
+  sentence, so a phone never discovers a refusal after the walk to the bin.
+* `openCaptureQueue` — the offline queue itself, headless, in IndexedDB, with the
+  network calls injected. The capture is on disk before the network is asked; the
+  idempotency key is minted when the capture is TAKEN, not when it is sent; items
+  go up oldest first, one at a time; a file's bytes are uploaded once and the
+  reference written back, so a failed submit never re-sends the photograph; and a
+  REFUSAL is not a retry — it stays in the queue carrying the door's own sentence
+  until a person fixes it or throws it away. `sync()` answers with per-item
+  outcomes, never a boolean.
 
 
 ## 0.24.0 — 2026-09-20