@stackbone/cli 0.2.5 → 0.2.7

package/migrations/0024_browser_auth_profiles.sql

@@ -0,0 +1,59 @@
+-- 0024_browser_auth_profiles.sql — persistent, encrypted browser auth profiles
+-- for deep-agent browser tools (STA-99).
+--
+-- A browsing agent gets a fresh browser context per chat session, so it starts
+-- logged out of every site every conversation. This table lets a successful
+-- login be captured once and reused: the browser's serialized Playwright
+-- `storageState` (cookies + per-origin localStorage) is encrypted and stored
+-- keyed by (site origin, identity); every new browser context for that origin
+-- starts with the state injected — already authenticated, no fresh login.
+--
+-- Rides the SAME secrets machinery as `stackbone_platform.secrets`, not a new
+-- crypto path: it lives in the agent's OWN platform database (so scoping is
+-- physical — a different install is a different DB + a different per-agent
+-- `STACKBONE_SECRET_KEY`, and a row is unreachable/undecryptable from any other
+-- install or org) and uses the identical `@stackbone/crypto` libsodium envelope
+-- (`version` / `nonce` / `ciphertext`). Storage state is credential-equivalent
+-- (a leaked cookie is a leaked password), which is exactly why it never sits in
+-- plaintext and never leaves the install's database.
+--
+-- Identity model v1 is agent-owned: one identity per site per install (the
+-- agent's own account). The `identity` column defaults to 'agent' and the
+-- UNIQUE (origin, identity) key future-proofs per-identity profiles without a
+-- rewrite when per-end-user identities arrive.
+
+CREATE TABLE IF NOT EXISTS stackbone_platform.browser_auth_profiles (
+    id          uuid        PRIMARY KEY DEFAULT gen_random_uuid(),
+    -- The site origin the profile authenticates, canonicalized to
+    -- `<scheme>://<host>[:<port>]` (e.g. `https://tutorbird.com`). The primary
+    -- half of the identity key.
+    origin      text        NOT NULL,
+    -- Which identity on that site this profile is for. v1 is always 'agent'
+    -- (the agent's own account); the column exists so per-end-user identities
+    -- are a non-breaking addition, never a rewrite.
+    identity    text        NOT NULL DEFAULT 'agent',
+    -- Crypto envelope, identical to `stackbone_platform.secrets`. The plaintext
+    -- is the JSON-serialized Playwright storageState; the cipher is the shared
+    -- libsodium `crypto_secretbox` keyed by the per-agent `STACKBONE_SECRET_KEY`.
+    version     text        NOT NULL DEFAULT 'v1' CHECK (version IN ('v1')),
+    nonce       bytea       NOT NULL,
+    ciphertext  bytea       NOT NULL,
+    -- Set when the agent landed unauthenticated despite an injected profile, so
+    -- exactly one re-login runs under the per-identity mutex and refreshes it.
+    stale       boolean     NOT NULL DEFAULT false,
+    created_at  timestamptz NOT NULL DEFAULT now(),
+    updated_at  timestamptz NOT NULL DEFAULT now()
+);
+
+-- One profile per (origin, identity): the login flow upserts on this key so a
+-- re-login rotates the state in place rather than accumulating rows.
+CREATE UNIQUE INDEX IF NOT EXISTS browser_auth_profiles_origin_identity_idx
+    ON stackbone_platform.browser_auth_profiles (origin, identity);
+
+-- The operator list surface orders newest-first.
+CREATE INDEX IF NOT EXISTS browser_auth_profiles_updated_at_idx
+    ON stackbone_platform.browser_auth_profiles (updated_at DESC);
+
+-- Storage state is credential material — keep it out of reach of the read-only
+-- SQL Explorer role exactly like `secrets` (0011).
+REVOKE ALL ON stackbone_platform.browser_auth_profiles FROM stackbone_viewer;

package/migrations/0025_trigger_subscriptions_mapping_graph.sql

@@ -0,0 +1,9 @@
+-- 0025_trigger_subscriptions_mapping_graph.sql — add mapping_graph column to trigger_subscriptions
+-- The visual node editor authors an event→input mapping as a graph and COMPILES it to the
+-- existing JSONata `mapping` string on the client. `mapping_graph` persists that graph opaquely
+-- so the editor can re-open and keep editing; the runtime NEVER reads it (the forwarder still
+-- evaluates only `mapping`). Nullable for backward compatibility and for code-mode detach, where
+-- editing the raw JSONata clears the graph back to null.
+
+ALTER TABLE stackbone_platform.trigger_subscriptions
+ADD COLUMN IF NOT EXISTS mapping_graph jsonb;

package/migrations/0026_trigger_subscriptions_correlation_key.sql

@@ -0,0 +1,9 @@
+-- 0026_trigger_subscriptions_correlation_key.sql — add correlation_key column to trigger_subscriptions
+-- A JSONata expression over the inbound event that produces a stable correlation key (typically the
+-- email `threadId` / `conversationId`). When set, the forwarder derives the key from each event and
+-- resumes the hook parked on that token instead of always starting a new run (resume-else-start).
+-- This slice only STORES and PREVIEWS it — the runtime still ignores it — so it is inert and fully
+-- backward compatible. Nullable: `null`/empty preserves today's start-only behavior.
+
+ALTER TABLE stackbone_platform.trigger_subscriptions
+ADD COLUMN IF NOT EXISTS correlation_key text;

package/migrations/0027_trigger_deliveries_resumed_status.sql

@@ -0,0 +1,19 @@
+-- 0027_trigger_deliveries_resumed_status.sql — widen the delivery-journal status
+-- CHECK for resume-else-start (STA-278 / STA-280).
+--
+-- The inbound forwarder used to be start-only: a delivery ended as `claimed`,
+-- `started` or `rejected` (the inline CHECK from 0021). Resume-else-start adds a
+-- fourth terminal outcome — `resumed` — when an inbound reply wakes a hook parked
+-- on the link's correlation key instead of starting a brand-new run. Writing
+-- `resumed` against the old CHECK throws a constraint violation (and the
+-- forwarder's best-effort journal write would swallow it, leaving the row
+-- mislabelled `claimed`). Widen the constraint to admit it.
+--
+-- The 0021 CHECK was declared INLINE (unnamed), so Postgres system-named it
+-- `trigger_deliveries_status_check`. Drop that and re-add it including `resumed`.
+-- Self-host and cloud both run these migrations, so the behavior is identical.
+ALTER TABLE stackbone_platform.trigger_deliveries
+    DROP CONSTRAINT IF EXISTS trigger_deliveries_status_check;
+ALTER TABLE stackbone_platform.trigger_deliveries
+    ADD CONSTRAINT trigger_deliveries_status_check
+    CHECK (status IN ('claimed', 'started', 'resumed', 'rejected'));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stackbone/cli",
-  "version": "0.2.5",
+  "version": "0.2.7",
   "license": "UNLICENSED",
   "type": "module",
   "bin": {
@@ -25,7 +25,6 @@
     "cron-parser": "^4.9.0",
     "drizzle-kit": "^0.31.10",
     "drizzle-orm": "^0.45.2",
-    "esbuild": "^0.27.0",
     "hono": "^4.12.15",
     "libsodium-wrappers": "^0.8.4",
     "open": "^11.0.0",
@@ -36,7 +35,8 @@
     "pino-pretty": "^13.1.3",
     "postgres": "^3.4.9",
     "semver": "^7.7.4",
-    "tar": "^7.5.13",
+    "unpdf": "^0.12.1",
+    "uuid": "^14.0.0",
     "yaml": "^2.8.3",
     "zod": "^4.3.6"
   }