@stackbone/cli 0.3.3 → 0.3.4

package/migrations/0050_run_steps_model_provider.sql

@@ -0,0 +1,30 @@
+-- 0050_run_steps_model_provider.sql — give the model its own home on a run step.
+--
+-- Until now the model id had nowhere to live, so it shared the `name` column with
+-- whatever else each writer put there: a direct `client.ai` call stores the model
+-- id, a deep-agent invocation stores the AGENT's name. Both read back as "name",
+-- and nothing on the row says which of the two it is — so the trace viewer could
+-- only print `name` and hope.
+--
+-- Two nullable text columns fix that. `name` keeps meaning whatever each writer
+-- already means by it; it simply stops being where a reader looks for the model.
+--
+-- `provider` is DERIVED from the model id's prefix, never guessed. The ids the box
+-- speaks are OpenRouter-style `vendor/model`, so `openai/gpt-4o-mini` yields
+-- `openai`, and an id with no prefix leaves the column NULL rather than inventing
+-- one. `openrouter` is never stored: it is the gateway that routed the call, not
+-- the provider that served it.
+--
+-- Both columns are nullable with no default and no CHECK, because every row
+-- written before this migration has neither and must stay readable: the trace
+-- viewer falls back to `name` when `model` is null.
+--
+-- Viewer posture is UNCHANGED. 0005 grants SELECT on the TABLE
+-- (`GRANT SELECT ON ALL TABLES IN SCHEMA stackbone_platform`), which covers every
+-- column the table ever grows, and no column-level revoke exists to undo it. So a
+-- new column needs no grant of its own — the DB Explorer sees these two the moment
+-- they exist.
+
+ALTER TABLE stackbone_platform.run_steps
+    ADD COLUMN IF NOT EXISTS model    text,
+    ADD COLUMN IF NOT EXISTS provider text;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stackbone/cli",
-  "version": "0.3.3",
+  "version": "0.3.4",
   "license": "UNLICENSED",
   "type": "module",
   "bin": {