@stackbone/cli 0.1.0-alpha.9 → 0.2.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
@@ -7,7 +7,207 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
7
7
 
8
8
  ## [Unreleased]
9
9
 
10
- ## [0.1.0-alpha.9] - 2026-06-12
10
+ ## [0.2.0] - 2026-07-02
11
+
12
+ ### Added
13
+
14
+ - **`stackbone add deep-agent <name>` (alias `add agent`) scaffolds a deep
15
+ agent.** A single `deep-agents/<name>/index.ts` default-exporting
16
+ `defineDeepAgent(...)`, added offline into the already-linked workspace.
17
+
18
+ ### Changed
19
+
20
+ - **Scaffolding targets the deep-agents runtime.** `init` and `add` now generate
21
+ `deep-agents/<name>/index.ts` (deepagents/LangGraph on the standard
22
+ OpenAI/Anthropic chat wire) instead of the old `agent/` shell with eve channels
23
+ and hand-written HMAC auth. `stackbone dev` serves agents over the standard chat
24
+ endpoints with a playground, durable sessions (PostgresSaver checkpointer),
25
+ tool-level HITL and connector tools.
26
+
27
+ ### Removed
28
+
29
+ - **The subtreed-starters system is gone.** `starter-loader` / `starter-renderer`
30
+ and the `starters-pull` script were removed; scaffolding now renders from the
31
+ bundled templates only.
32
+
33
+ ### Fixed
34
+
35
+ - **`stackbone init` / `link` install skills on Windows.** `npx` is a `.cmd` shim
36
+ there, so spawning it without a shell failed with `spawn npx ENOENT`. The CLI now
37
+ spawns `npx` through the shell on win32 (the argv is fixed constants) and maps
38
+ cmd.exe's "is not recognized" to the same npx-not-found hint.
39
+
40
+ ## [0.1.0] - 2026-07-01
41
+
42
+ ### Added
43
+
44
+ - **First stable release.** Drops the `-alpha` prerelease line: `npm i -g @stackbone/cli` now resolves the stable build through the `latest` dist-tag (previously pinned to the very first alpha).
45
+
46
+ - **`stackbone` warns when a newer CLI is published, and validates the project's
47
+ SDK version.** On any command the CLI now runs a cached (24h TTL), non-blocking
48
+ npm registry check and prints a discreet stderr banner when a newer
49
+ `@stackbone/cli` exists on the channel matching the installed version (`alpha`
50
+ for prereleases, `latest` for stable) — silenced under `CI`, non-TTY, `--json`
51
+ and `STACKBONE_NO_UPDATE_CHECK`. It also reads the control plane's
52
+ `x-stackbone-min-cli-version` header to warn softly, and turns a `426 Upgrade
53
+ Required` response into a clear `cli_upgrade_required` error. Generated projects
54
+ now pin `@stackbone/sdk` EXACTLY (no caret); `stackbone dev` warns and
55
+ `stackbone publish` blocks when the project's installed SDK is incompatible with
56
+ the CLI's bundled SDK line.
57
+
58
+ ## [0.1.0-alpha.15] - 2026-07-01
59
+
60
+ ### Changed
61
+
62
+ - **`stackbone init` now links every workspace to the control plane, and `add`
63
+ no longer touches the network.** The workspace is the linked unit: `init`
64
+ registers the workspace's identity (an agent named after the workspace) and
65
+ writes the single `.stackbone/project.json` for EVERY `--with` kind — `empty`
66
+ and `workflow` included — that `dev`, `publish` and the management commands
67
+ read. Because of this, `init` now needs a signed-in session for every kind (the
68
+ fully-offline `init` path is gone — run `stackbone login` first). In exchange,
69
+ `stackbone add agent` and `add workflow-agent` are now 100% offline: the pieces
70
+ you add are members of the already-linked workspace, not separate control-plane
71
+ registrations, so they no longer register an agent or write `project.json`.
72
+ This fixes the confusing flow where `init` left a workspace unlinked and
73
+ `stackbone dev` then failed with "No project linked — run `stackbone init`".
74
+
75
+ ## [0.1.0-alpha.14] - 2026-06-25
76
+
77
+ ### Removed
78
+
79
+ - **`stackbone trigger` and `stackbone queues` are gone.** Both belonged to the
80
+ deprecated classic `/invoke` runtime. `stackbone trigger` posted to the dev
81
+ emulator's `/api/invoke`, which the eve runtime retired (replaced by the
82
+ `/api/agents/:name/chat` proxy), so the command hit a route that no longer
83
+ exists. `stackbone queues` drove the classic agent-jobs BullMQ dispatcher,
84
+ which `stackbone dev` no longer boots (it answers `503 queues_unavailable`);
85
+ in the new runtime async work is modelled as durable workflow runs. To
86
+ exercise a trigger-driven workflow locally, start it by name with
87
+ `stackbone workflows start <name>`. The `STACKBONE_EMULATOR_URL` env var
88
+ (only `stackbone trigger` read it) is removed too. The `client.queues` SDK
89
+ capability and Studio's Queues inspector are unaffected.
90
+
91
+ ### Fixed
92
+
93
+ - **`stackbone init` no longer scaffolds a workspace that fails `pnpm install`.**
94
+ The generated `package.json` pinned `@stackbone/workflow-world` — our durable
95
+ Workflow SDK World fork, a platform internal that is never published to npm —
96
+ so the post-init `pnpm install` 404'd ("could not resolve
97
+ @stackbone/workflow-world"). The CLI now ships its own esbuild-bundled copy of
98
+ the World and provisions it into the workspace's `node_modules` at `stackbone
99
+ dev` boot (the same mechanism already used for `@stackbone/agent-server`), and
100
+ the scaffold no longer declares the package. The public `@workflow/world` is
101
+ kept as the single shared base.
102
+
103
+ ## [0.1.0-alpha.13] - 2026-06-25
104
+
105
+ ### Changed
106
+
107
+ - **`stackbone dev`'s eve workspace boot now runs on the shared `@stackbone/workspace-runtime`
108
+ engine** (a pure refactor — no behaviour change). The supervisor that spawns the
109
+ N eve agents, the per-agent session Worlds, the main workspace World, and their
110
+ ordered teardown moved out of `apps/cli/src/dev/` into the new
111
+ `libs/runtime/workspace-runtime` lib, behind a single `bootWorkspaceRuntime`
112
+ entry point. The CLI is now just the dev SHELL around it (docker, tunnel,
113
+ watchers, local config, and the `eve build` / workflow compile it injects); the
114
+ same engine will boot cloud BYOC + self-host so the three environments run the
115
+ identical workspace. The engine assumes pre-compiled `.output/` and never
116
+ compiles — `stackbone dev` keeps its build-then-start behaviour by injecting
117
+ `runEveBuild`. `stackbone dev` over a v3 workspace boots identically (same
118
+ ports, health, workflows, chat).
119
+
120
+ ### Added
121
+
122
+ - **`stackbone publish` now blocks an incomplete eve trace.** A new per-agent build
123
+ guardrail (alongside the native-deps + SDK-inline gates) detects when `eve build`
124
+ shipped a PARTIAL externalized `eve` into an agent's `.output/` — the symptom of an
125
+ upstream bug where eve's bundler (nitro + `@vercel/nft`) drops a file reachable only
126
+ through eve's `#`-subpath imports (e.g. `connections/errors.js`), which crash-loops
127
+ the agent at boot with `ERR_MODULE_NOT_FOUND`. Publish aborts with the fix: add
128
+ `"eve*"` to the agent's `defineAgent({ build: { externalDependencies } })`, which
129
+ forces nitro's full-trace of eve (and sidesteps eve's own self-filter). Agents that
130
+ fully inline eve are unaffected, so they never carry the full-trace's extra weight.
131
+ - **`stackbone publish` now packages a v3 workspace.** When the current directory
132
+ has a `stackbone.config.ts` (`defineWorkspace`), publish compiles every eve
133
+ agent (`eve build` → its Nitro `.output/`) and the workflows on THIS host, then
134
+ packs `stackbone.config.ts` + each `.output/` + `.well-known/` + a derived
135
+ workspace manifest into a single tar with a verifiable SHA-256, written to
136
+ `dist/stackbone/`. Compiling at publish (not at boot) makes cold starts fast and
137
+ deterministic and turns a build error into a publish failure instead of a
138
+ production crash-loop. Each agent is scanned for native (`.node`) dependencies
139
+ and for an inlined `@stackbone/sdk` — either aborts with an actionable message
140
+ naming the offending package/agent before any tar is produced. (The
141
+ control-plane upload + build-pointer registration is the provisioning saga's
142
+ job; publish produces and records the artifact locally for now.)
143
+
144
+ ## [0.1.0-alpha.12] - 2026-06-17
145
+
146
+ ### Added
147
+
148
+ - **Full agent-runtime command surface.** The CLI can now drive a running
149
+ agent end to end against the Studio endpoints, with one command group per
150
+ capability: `runs` and `config`, `queues`
151
+ (`list`/`jobs`/`retry`/`discard`/`peek`/`purge`/`push`), `logs`, `storage`,
152
+ `rag`, `secrets`, `hitl`, `openrouter`, `db`, `prompts`, `playground`,
153
+ `agents`, and `contract` (`show`/`schema`/`capabilities`/`validate`).
154
+ - `stackbone organization use` switches the active organization for subsequent
155
+ commands.
156
+ - `stackbone db migrate up`/`status` now prompt to create a `drizzle-kit`
157
+ rename when run on an interactive terminal, instead of silently guessing.
158
+ - `stackbone playground` streams a run's steps live as they happen during an
159
+ invocation.
160
+
161
+ ### Changed
162
+
163
+ - Studio commands now route to the **local emulator** for `kind=local` agents
164
+ (resolved from the dev statefile) instead of hitting the control plane, which
165
+ has no boot bundle for local installs.
166
+ - Unified the cross-cutting conventions (flags, output, error handling)
167
+ across every agent-runtime surface so they behave consistently.
168
+ - The HTTP adapter gained `put`/`delete` plus a Studio-target resolver, and
169
+ transfer helpers for SSE, multipart uploads and presigned downloads.
170
+
171
+ ### Removed
172
+
173
+ - `stackbone db studio` — the embedded drizzle-kit studio command.
174
+
175
+ ### Fixed
176
+
177
+ - `stackbone db migrate up`/`status` discover the dev Postgres URL instead of
178
+ failing to connect.
179
+ - `queues peek`/`purge` are now scoped to a single handler (logical queue)
180
+ rather than the whole physical queue.
181
+
182
+ ## [0.1.0-alpha.11] - 2026-06-12
183
+
184
+ ### Fixed
185
+
186
+ - `stackbone dev` (and the self-host runtime) no longer crash on boot with
187
+ `BUNDLE_IMPORT_FAILED` when an agent splits its code across files and uses
188
+ idiomatic extensionless relative imports (e.g. `import { x } from './schema'`).
189
+ The dev/self-host runner imports the creator's raw TypeScript through Node's
190
+ native type-stripping, whose ESM resolver never adds a file extension — so a
191
+ multi-file agent that ran fine once published would crash locally. The
192
+ generated dev entry now registers a module-resolution hook that mirrors
193
+ esbuild's TypeScript resolution (the same `stackbone publish` relies on): it
194
+ adds the missing `.ts`/`.tsx`/`.mts`/`.cts` extension (and the directory
195
+ `index` form), and applies the NodeNext `./x.js` → `./x.ts` rewrite. Dev and
196
+ self-host now resolve modules exactly like a published agent.
197
+
198
+ ## [0.1.0-alpha.10] - 2026-06-12
199
+
200
+ ### Fixed
201
+
202
+ - `stackbone dev` no longer crashes on boot with
203
+ `ERR_MODULE_NOT_FOUND: @stackbone/agent-server` in a real creator project
204
+ outside this monorepo. The dev agent runs as a separate `node` process that
205
+ imports `@stackbone/agent-server` — a private package a creator never installs
206
+ — and the published CLI had no way to provide it (it could only bundle it from
207
+ workspace source, which isn't present in an installed CLI). The CLI build now
208
+ ships its own pre-bundled copy under `runtime-deps/`, and `stackbone dev`
209
+ copies it into the project's `node_modules` at boot whenever no workspace
210
+ source is found. In-monorepo development is unchanged.
11
211
 
12
212
  ### Added
13
213
 
package/README.md CHANGED
@@ -9,30 +9,33 @@ The CLI for [Stackbone](https://stackbone.ai) — the marketplace and runtime fo
9
9
  No install required — invoke the CLI through `npx`:
10
10
 
11
11
  ```bash
12
- npx @stackbone/cli@alpha init my-agent
13
- cd my-agent
14
- npx @stackbone/cli@alpha dev
12
+ npx @stackbone/cli login
13
+ npx @stackbone/cli init my-workspace
14
+ cd my-workspace && npm install
15
+ npx @stackbone/cli dev
15
16
  ```
16
17
 
17
- That's it. `init` scaffolds a new agent project (templates + Claude skill); `dev` runs a local control-plane emulator with Stackbone Studio at `http://localhost:4242` so you can iterate without publishing.
18
+ That's it. `init` scaffolds a new workspace shell (agents + workflows + coding-agent skills) and links it to your organization, so you sign in first; `dev` boots the whole workspace locally Postgres, Redis, MinIO and Stackbone Studio at `http://localhost:4242` so you can iterate without publishing.
18
19
 
19
20
  ## Commands
20
21
 
21
- | Command | What it does |
22
- | ---------------------------- | ---------------------------------------------------------------------- |
23
- | `stackbone init [name]` | Scaffold a new Stackbone project from a template. |
24
- | `stackbone dev` | Run the local control-plane emulator + Stackbone Studio. |
25
- | `stackbone publish` | Build, push, and publish the current agent to Stackbone runtime. |
26
- | `stackbone login` / `logout` | Authenticate the CLI via the device-code flow (RFC 8628). |
27
- | `stackbone whoami` | Show the active user and organization. |
28
- | `stackbone current` | Print the organization currently linked to this session. |
29
- | `stackbone link` | Link the current directory to an existing organization + agent. |
30
- | `stackbone list` | List organizations the current user owns. |
31
- | `stackbone metadata` | Agent-friendly snapshot of the workspace state. |
32
- | `stackbone db <subcmd>` | Manage the local emulator database (migrations, queries). |
33
- | `stackbone docs <topic>` | Print Stackbone documentation inline. Run with no args to list topics. |
34
-
35
- Run any command with `--help` for the full flag reference, or `npx @stackbone/cli@alpha docs cli` for the inline documentation.
22
+ | Command | What it does |
23
+ | ----------------------------- | ---------------------------------------------------------------------- |
24
+ | `stackbone init [name]` | Scaffold a new workspace shell and link it to your org (needs login). |
25
+ | `stackbone add <kind> <name>` | Add an agent / workflow / workflow-agent to the workspace (offline). |
26
+ | `stackbone dev` | Boot the whole workspace locally + Stackbone Studio. |
27
+ | `stackbone workflows <verb>` | List, inspect the schema of, or start the install's workflows. |
28
+ | `stackbone publish` | Compile every agent + workflow and pack the workspace bundle. |
29
+ | `stackbone login` / `logout` | Authenticate the CLI via the device-code flow (RFC 8628). |
30
+ | `stackbone whoami` | Show the active user and organization. |
31
+ | `stackbone current` | Print the organization currently linked to this session. |
32
+ | `stackbone link` | Link the current directory to an existing organization + agent. |
33
+ | `stackbone list` | List organizations the current user owns. |
34
+ | `stackbone metadata` | Agent-friendly snapshot of the workspace state. |
35
+ | `stackbone db <subcmd>` | Manage the local emulator database (migrations, queries). |
36
+ | `stackbone docs <topic>` | Print Stackbone documentation inline. Run with no args to list topics. |
37
+
38
+ Run any command with `--help` for the full flag reference, or `npx @stackbone/cli docs cli` for the inline documentation.
36
39
 
37
40
  ## Requirements
38
41