@stackbone/cli 0.2.6 → 0.2.8

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.
@@ -0,0 +1,9 @@
1
+ -- 0026_trigger_subscriptions_correlation_key.sql — add correlation_key column to trigger_subscriptions
2
+ -- A JSONata expression over the inbound event that produces a stable correlation key (typically the
3
+ -- email `threadId` / `conversationId`). When set, the forwarder derives the key from each event and
4
+ -- resumes the hook parked on that token instead of always starting a new run (resume-else-start).
5
+ -- This slice only STORES and PREVIEWS it — the runtime still ignores it — so it is inert and fully
6
+ -- backward compatible. Nullable: `null`/empty preserves today's start-only behavior.
7
+
8
+ ALTER TABLE stackbone_platform.trigger_subscriptions
9
+ ADD COLUMN IF NOT EXISTS correlation_key text;
@@ -0,0 +1,19 @@
1
+ -- 0027_trigger_deliveries_resumed_status.sql — widen the delivery-journal status
2
+ -- CHECK for resume-else-start (STA-278 / STA-280).
3
+ --
4
+ -- The inbound forwarder used to be start-only: a delivery ended as `claimed`,
5
+ -- `started` or `rejected` (the inline CHECK from 0021). Resume-else-start adds a
6
+ -- fourth terminal outcome — `resumed` — when an inbound reply wakes a hook parked
7
+ -- on the link's correlation key instead of starting a brand-new run. Writing
8
+ -- `resumed` against the old CHECK throws a constraint violation (and the
9
+ -- forwarder's best-effort journal write would swallow it, leaving the row
10
+ -- mislabelled `claimed`). Widen the constraint to admit it.
11
+ --
12
+ -- The 0021 CHECK was declared INLINE (unnamed), so Postgres system-named it
13
+ -- `trigger_deliveries_status_check`. Drop that and re-add it including `resumed`.
14
+ -- Self-host and cloud both run these migrations, so the behavior is identical.
15
+ ALTER TABLE stackbone_platform.trigger_deliveries
16
+ DROP CONSTRAINT IF EXISTS trigger_deliveries_status_check;
17
+ ALTER TABLE stackbone_platform.trigger_deliveries
18
+ ADD CONSTRAINT trigger_deliveries_status_check
19
+ CHECK (status IN ('claimed', 'started', 'resumed', 'rejected'));
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@stackbone/cli",
3
- "version": "0.2.6",
3
+ "version": "0.2.8",
4
4
  "license": "UNLICENSED",
5
5
  "type": "module",
6
6
  "bin": {
@@ -25,8 +25,8 @@
25
25
  "cron-parser": "^4.9.0",
26
26
  "drizzle-kit": "^0.31.10",
27
27
  "drizzle-orm": "^0.45.2",
28
- "esbuild": "^0.27.0",
29
28
  "hono": "^4.12.15",
29
+ "jose": "^6.2.3",
30
30
  "libsodium-wrappers": "^0.8.4",
31
31
  "open": "^11.0.0",
32
32
  "openai": "^6.42.0",
@@ -36,8 +36,8 @@
36
36
  "pino-pretty": "^13.1.3",
37
37
  "postgres": "^3.4.9",
38
38
  "semver": "^7.7.4",
39
- "tar": "^7.5.13",
40
39
  "unpdf": "^0.12.1",
40
+ "uuid": "^14.0.0",
41
41
  "yaml": "^2.8.3",
42
42
  "zod": "^4.3.6"
43
43
  }
Binary file
Binary file