@ai-matrx/records 0.24.0 → 0.26.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,74 @@
1
1
  # Changelog — @ai-matrx/records
2
2
 
3
+ ## 0.26.0
4
+
5
+ **"Text me on a new lead; email me a Monday summary" — the second half of that
6
+ sentence becomes something the store can be told.**
7
+
8
+ A cadence was two words, `immediate` and `digest`, and `schedule` was free text
9
+ nothing read. `SubscriptionCadence` is now `instant | hourly | daily | weekly` —
10
+ the words `custom.agg_subscription_cadences()` answers and the digest runner acts
11
+ on. The two old words still work everywhere: the store normalises them, so a Rule
12
+ written last week and one written by the picker today mean the same thing.
13
+
14
+ `MySubscription` gained the three answers a notifications list actually needs and
15
+ could not ask for: `quiet_hours`, `last_sent_at` and `next_digest_at`. The last is
16
+ computed by the SAME store functions the runner uses, so "next Monday 08:00" on the
17
+ screen and the moment it fires cannot drift; it is null for a muted subscription,
18
+ because saying "next Monday" beside a switch that is off is a screen that lies.
19
+
20
+ Two doors that did not exist:
21
+
22
+ * `subscriptionDeclare({ table_id, spec })` — WRITE one. The store refuses a cadence
23
+ no runner acts on, a channel this platform does not send on and quiet hours nobody
24
+ can parse, each by name, then declares the Rule through `rule_declare` (REC-72: a
25
+ Rule written as a record is invisible to every reader that goes looking for one).
26
+ * `subscriptionPreview({ rule_id })` — the summary it would send RIGHT NOW, with what
27
+ entered, left and changed NAMED rather than counted, plus the in-view total and a
28
+ click-through to the filtered grid. It assembles only: nothing is delivered,
29
+ nothing is recorded, and the watermark does not move.
30
+
31
+ `QuietHours`, `DigestPreview` and `SubscriptionSpec` are new exported types.
32
+ `store.generated.ts` regenerated from live — 520 doors, `check:store-registry` OK.
33
+ ## 0.26.0 — 2026-09-20
34
+
35
+ **The queue was filing every refusal as a hiccup, and a real browser found it.**
36
+
37
+ `isDecided` listed SQLSTATEs. `RecordsClient` hands back its own WORD —
38
+ `invalid_argument`, `door`, `refused_by_rule` — with the sqlstate beside it, so
39
+ no refusal ever matched: a capture the store had refused BY NAME went back in the
40
+ queue and would have been sent again forever, which is the exact silent hole the
41
+ queue's fourth decision exists to prevent. The unit suite passed throughout
42
+ because it fed the check SQLSTATEs — it was testing the assumption, not the
43
+ client. Measured in a headless Chromium at 390 px against the main database.
44
+
45
+ It is now the other way round, and from the package's own list rather than a
46
+ guess: `stale_read`, `timed_out` and `store_limit` are worth repeating (which is
47
+ what `results.ts` says in as many words), a failure with NO code at all is the
48
+ network and waits, and everything the door named is a decision that stays.
49
+ `isDecided` takes the error, not a code, so either spelling works.
50
+
51
+
52
+ ## 0.25.0 — 2026-09-20
53
+
54
+ **A crew out in the field, and a phone with no bars (PRODUCTS row 15, P13).**
55
+
56
+ * `captureSheetDeclare`, `capturePublish`, `captureSheets`, `captureOpen` and
57
+ `captureSubmit` — the five SIGNED-IN doors of a crew capture sheet. A capture
58
+ sheet is not a second form store: it is the ONE Form object saying
59
+ `audience = 'crew'`, opened by `capture_opened_at` rather than `published_at`,
60
+ and the database carries a CHECK that refuses a row which is both. `captureOpen`
61
+ answers `null` for a sheet below `viewer` AND for a sheet that is not there —
62
+ the same answer the Table gives — and carries an honest `may_capture` with a
63
+ sentence, so a phone never discovers a refusal after the walk to the bin.
64
+ * `openCaptureQueue` — the offline queue itself, headless, in IndexedDB, with the
65
+ network calls injected. The capture is on disk before the network is asked; the
66
+ idempotency key is minted when the capture is TAKEN, not when it is sent; items
67
+ go up oldest first, one at a time; a file's bytes are uploaded once and the
68
+ reference written back, so a failed submit never re-sends the photograph; and a
69
+ REFUSAL is not a retry — it stays in the queue carrying the door's own sentence
70
+ until a person fixes it or throws it away. `sync()` answers with per-item
71
+ outcomes, never a boolean.
3
72
 
4
73
 
5
74
  ## 0.24.0 — 2026-09-20