@stackbone/cli 0.1.0-alpha.10 → 0.1.0-alpha.12

package/migrations/0001_runs.sql

@@ -1,6 +1,6 @@
 -- 0001_runs.sql — schema and tables for the run-level surface of Studio.
 -- Spec: docs/arquitectura/specs/stackbone-agent-protocol-v1.md §6 (runs, run_steps).
--- ADR:  docs/arquitectura/decisiones/2026-05-03-stackbone-studio-datapath-y-scope-mvp.md §D2/D7/D9.
+-- ADR:  docs/arquitectura/decisiones/2026-05-30-stackbone-studio.md §D2/D7/D9.
 
 CREATE SCHEMA IF NOT EXISTS stackbone_platform;
 

package/migrations/0002_approvals.sql

@@ -1,7 +1,7 @@
 -- 0002_approvals.sql — HITL approvals queue and audit trail.
 -- Spec: docs/arquitectura/specs/stackbone-agent-protocol-v1.md §6.6/§6.7.
 -- Component: docs/arquitectura/componentes/08-hitl-inbox.md.
--- ADR:  docs/arquitectura/decisiones/2026-05-03-stackbone-studio-datapath-y-scope-mvp.md §D2.
+-- ADR:  docs/arquitectura/decisiones/2026-05-30-stackbone-studio.md §D2.
 
 CREATE TABLE IF NOT EXISTS stackbone_platform.approvals (
     id                      uuid        PRIMARY KEY DEFAULT gen_random_uuid(),

package/migrations/0003_runs_is_playground_index.sql

@@ -1,6 +1,6 @@
 -- 0003_runs_is_playground_index.sql — billing-friendly partial index over runs.
 -- Spec: docs/tasks/Studio V5 - Playground e Invoke.md (V5#01).
--- ADR:  docs/arquitectura/decisiones/2026-05-03-stackbone-studio-datapath-y-scope-mvp.md §D5/D9.
+-- ADR:  docs/arquitectura/decisiones/2026-05-30-stackbone-studio.md §D5/D9.
 --
 -- The `is_playground` column itself already lives in 0001_runs.sql (F2 baked it
 -- in defensively so playground writes had a place to land before V5 shipped).

package/migrations/0005_stackbone_viewer.sql

@@ -1,7 +1,7 @@
 -- 0005_stackbone_viewer.sql — read-only role for the Studio DB Explorer.
 -- Spec: docs/arquitectura/componentes/11-stackbone-studio.md §"DB Explorer".
 -- Task: docs/tasks/Studio V6 - DB Explorer read-only.md (V6#01).
--- ADR:  docs/arquitectura/decisiones/2026-05-03-stackbone-studio-datapath-y-scope-mvp.md §D6.
+-- ADR:  docs/arquitectura/decisiones/2026-05-30-stackbone-studio.md §D6.
 --
 -- The role is `NOLOGIN` because callers (apps/api, apps/cli emulator) reach it
 -- via `SET ROLE stackbone_viewer` on a session opened with the regular owner

package/migrations/0006_secrets.sql

@@ -2,7 +2,7 @@
 -- `stackbone dev` emulator (Studio V10).
 -- Spec: docs/arquitectura/componentes/11-stackbone-studio.md §"Secrets".
 -- Task: docs/tasks/Studio V10 - Secrets.md (V10#02).
--- ADR:  docs/arquitectura/decisiones/2026-05-03-stackbone-studio-datapath-y-scope-mvp.md
+-- ADR:  docs/arquitectura/decisiones/2026-05-30-stackbone-studio.md
 --       (decision V10#01 in the task itself: cloud secrets stay in
 --       `installation_secret` of the control plane; local emulator stores
 --       the same wire shape here so the Studio UI sees identical data.)

package/migrations/0007_agent_config_versions.sql

@@ -2,7 +2,7 @@
 -- payloads for Studio's Config dinámica screen (V11).
 -- Spec: docs/arquitectura/componentes/11-stackbone-studio.md §"Mapa de pantallas / C.Config dinámica".
 -- Task: docs/tasks/Studio V11 - Config dinámica.md (V11#01).
--- ADR:  docs/arquitectura/decisiones/2026-05-03-stackbone-studio-datapath-y-scope-mvp.md §D2/D7.
+-- ADR:  docs/arquitectura/decisiones/2026-05-30-stackbone-studio.md §D2/D7.
 --
 -- The current config is the row with the highest `version`. Older rows are
 -- kept for the rollback action and the lateral history list. Hot-reload is

package/migrations/0014_rag.sql

@@ -1,6 +1,6 @@
 -- 0014_rag.sql — the canonical RAG store (collections / documents / chunks /
 -- jobs), moved into the platform schema.
--- ADR: docs/adr/2026-06-05-rag-tables-in-platform-schema.md
+-- ADR: docs/adr/2026-06-05-rag.md
 --
 -- Previously these four tables lived in `public` and were installed by the
 -- creator's own migrator (`stackbone db migrate add-rag`). They are a

package/migrations/0015_queue_jobs_lease.sql

@@ -0,0 +1,60 @@
+-- 0015_queue_jobs_lease.sql — lease columns + a terminal NOTIFY on the agent's
+-- `_queue_jobs` journal (P1 "async jobs").
+--
+-- The wrapper around a dispatched handler now leases the in-flight row so the
+-- control-plane reaper can tell a still-running job from a crashed one:
+--
+--   heartbeat_at — touched by the harness roughly every 15s while a dispatched
+--                  handler is running. A stale heartbeat is what lets the
+--                  reaper DERIVE the `lost` state (never written as a column —
+--                  the status CHECK stays `done` / `failed`).
+--   deadline_at  — started_at + the effective handler timeout; the hard ceiling
+--                  past which the reaper treats the lease as expired.
+--   run_id       — correlation key with the `runs` timeline so Studio can join
+--                  a journal row to its run.
+--
+-- All three are nullable and added IF NOT EXISTS: the install saga may re-apply
+-- migrations on a redeploy, and a job journaled before this migration simply
+-- carries NULL leases.
+--
+-- A terminal NOTIFY fans out the NULL→terminal transition on
+-- `stackbone_platform_events` so the dispatcher's tracker can resolve a job the
+-- instant its journal row flips, instead of polling. It mirrors the trigger
+-- style of `0001_runs.sql`.
+
+ALTER TABLE stackbone_platform._queue_jobs
+    ADD COLUMN IF NOT EXISTS heartbeat_at timestamptz;
+ALTER TABLE stackbone_platform._queue_jobs
+    ADD COLUMN IF NOT EXISTS deadline_at  timestamptz;
+ALTER TABLE stackbone_platform._queue_jobs
+    ADD COLUMN IF NOT EXISTS run_id       text;
+
+-- AFTER UPDATE trigger fans out into pg_notify('stackbone_platform_events', ...)
+-- ONLY on the NULL→terminal status transition (the job just finished). The
+-- dispatcher's tracker LISTENs on this channel and resolves the in-flight job
+-- the moment its journal row flips to `done` / `failed`.
+CREATE OR REPLACE FUNCTION stackbone_platform.notify_queue_job_event() RETURNS trigger
+LANGUAGE plpgsql AS $fn$
+DECLARE
+    payload jsonb;
+BEGIN
+    IF (OLD.status IS NULL) AND (NEW.status IS NOT NULL) THEN
+        payload := jsonb_build_object(
+            'type', 'queue_job.finished',
+            'dispatch_id', NEW.dispatch_id,
+            'run_id', NEW.run_id,
+            'status', NEW.status
+        );
+    ELSE
+        RETURN NULL;
+    END IF;
+
+    PERFORM pg_notify('stackbone_platform_events', payload::text);
+    RETURN NULL;
+END;
+$fn$;
+
+DROP TRIGGER IF EXISTS queue_jobs_notify_au ON stackbone_platform._queue_jobs;
+CREATE TRIGGER queue_jobs_notify_au
+AFTER UPDATE ON stackbone_platform._queue_jobs
+FOR EACH ROW EXECUTE FUNCTION stackbone_platform.notify_queue_job_event();

package/migrations/0016_runs_job_trigger.sql

@@ -0,0 +1,15 @@
+-- 0016_runs_job_trigger.sql — allow `trigger = 'job'` on stackbone_platform.runs.
+--
+-- Dispatched queue jobs (ADR 2026-05-30) are first-class runs, but until now a
+-- queue dispatch only wrote the `_queue_jobs` journal — it never inserted a
+-- `runs` row. Two consequences: the dispatched run was INVISIBLE in the Studio
+-- runs timeline, and `ctx.progress` / `ctx.step` inside a job handler hit the
+-- `run_steps.run_id REFERENCES runs(id)` FK with no parent row, so the progress
+-- note was silently dropped. The wrapper now materialises a `trigger='job'` run
+-- row when it journals the job's started lifecycle, which fixes both — but the
+-- original `0001_runs.sql` CHECK predates the `job` trigger and would reject the
+-- insert. Widen it to match `runTriggerSchema` (which already carries `job`).
+ALTER TABLE stackbone_platform.runs DROP CONSTRAINT IF EXISTS runs_trigger_check;
+ALTER TABLE stackbone_platform.runs
+    ADD CONSTRAINT runs_trigger_check
+    CHECK (trigger IN ('manual', 'webhook', 'cron', 'event', 'job'));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stackbone/cli",
-  "version": "0.1.0-alpha.10",
+  "version": "0.1.0-alpha.12",
   "license": "UNLICENSED",
   "type": "module",
   "bin": {