lua-cli 3.49.0 → 3.49.1

package/docs/README.md

@@ -1,6 +1,6 @@
-# lua-cli v3.49.0
+# lua-cli v3.49.1
 
-Welcome to the comprehensive API documentation for lua-cli v3.49.0. This guide covers every API, class, and function exported by the package.
+Welcome to the comprehensive API documentation for lua-cli v3.49.1. This guide covers every API, class, and function exported by the package.
 
 ## 📚 Documentation Index
 
@@ -263,7 +263,7 @@ Each API doc includes:
 
 ---
 
-**Version:** 3.49.0
+**Version:** 3.49.1
 **Last Updated:** October 2026
 
 ---

package/docs/api/LuaDecision.md

@@ -89,7 +89,7 @@ The compiler reads each decision from its source, so write it as `new LuaDecisio
 
 `lua push` stages a new version of every decision listed in `decisions`; it does not change what `Decisions.run` asks. `lua push decision --name triage` stages one decision. A staged version becomes current only through `lua version promote` or `lua decisions publish`. Until a decision has a current version, `Decisions.run` throws `decision_not_found` for it.
 
-A staged version goes live with the agent version that includes it: run `lua version create`, then `lua version promote <version>`. Promoting an older agent version brings back the decision versions it included, which is how you roll back a pushed decision.
+A staged version goes live with the agent version that includes it: run `lua version create`, then `lua version promote <version>`. Promoting an older agent version brings back the decision versions it included, which is how you roll back a pushed decision. A decision that the promoted agent version does not include stops answering (`decision_not_found`) and keeps its versions, and promoting an agent version that includes it makes it current again.
 
 A version saved from the dashboard goes live when you publish it, and publishing an older version there rolls back too.
 
@@ -103,7 +103,7 @@ Each lua-core pod caches the current version. A promote, a publish, a rename or
 
 The first push of a decision writes 1.0.1, as for every versioned primitive: a push bumps the version in `lua.skill.yaml` (1.0.0 for a new entry) before it writes.
 
-`lua decisions publish triage 1.0.1` makes 1.0.1 the current version straight away, which is the quickest rollback. Promoting a different agent version sets it back to what that version pins; promoting the agent version that is already active changes nothing.
+`lua decisions publish triage 1.0.1` makes 1.0.1 the current version straight away, which is the quickest rollback. The next `lua version create` keeps 1.0.1 unless you push a newer version of the decision after publishing. Promoting a different agent version sets it back to what that version pins; promoting the agent version that is already active changes nothing.
 
 `lua decisions delete triage` deactivates the decision after asking and keeps its versions. From then on `Decisions.run('triage', ...)` throws `decision_not_found`. `lua decisions versions triage` still lists its versions, and publishing one of them turns it back on.
 

package/docs/api/LuaWorkflow.md

@@ -48,7 +48,23 @@ A typed code step. `inputSchema` / `outputSchema` / `resumeSchema` are zod schem
 
 `createWorkflow(cfg)` opens a fluent builder; `.commit()` freezes it into the compiled graph. `defineWorkflow(cfg, (wf) => …)` is sugar for the same thing.
 
-Config: `name`, `description?`, `inputSchema`, `outputSchema?`, `budget?` (`maxCredits`, `maxDurationSeconds`, `maxJobSeconds?`), `schedule?` (`{ type:'cron', expression, timezone }`), `scheduleInput?`, `concurrencyPolicy?` (`'allow'|'forbid'`), `concurrencyKey?` (`'correlationKey'`, requires `concurrencyPolicy:'forbid'`), `workspace?`, `outputVisibility?` (see [Output visibility](../workflows/output-visibility.md)), `env.template()` overlays (see [Env overlays](../workflows/env-overlays.md)).
+Config: `name`, `description?`, `inputSchema`, `outputSchema?`, `budget?` (`maxCredits`, `maxDurationSeconds`, `maxJobSeconds?`), `schedule?` (`{ type:'cron', expression, timezone }`), `scheduleInput?`, `concurrencyPolicy?` (`'allow'|'forbid'`), `concurrencyKey?` (`'correlationKey'`, requires `concurrencyPolicy:'forbid'`, see [Concurrency](#concurrency)), `workspace?`, `outputVisibility?` (see [Output visibility](../workflows/output-visibility.md)), `env.template()` overlays (see [Env overlays](../workflows/env-overlays.md)).
+
+### Concurrency
+
+`concurrencyPolicy: 'forbid'` alone is workflow-wide: one in-flight run blocks every other start of that workflow. `concurrencyKey: 'correlationKey'` narrows the guard to runs that share a `correlationKey`:
+
+- A start is refused only while a **non-terminal** run of the same workflow carries the **same** `correlationKey`. Starts with different keys run in parallel.
+- Starts with **no** `correlationKey` share one null bucket: a second keyless start is refused while a keyless run is in flight. A keyless start and a keyed start never block each other.
+- `concurrencyKey` requires `concurrencyPolicy: 'forbid'`; otherwise the push is a 400 `VALIDATION_FAILED` (`concurrency-key-requires-forbid`).
+
+The refusal is a 409 `RUNS_IN_FLIGHT` whose body carries `blockingRunId`, `blockingStatus`, `concurrencyKey` and the colliding `correlationKey` (absent for the null bucket). `lua workflows start` prints it:
+
+```
+❌ "outreach" has concurrencyPolicy:'forbid' and run `wfr_0` is in flight for correlationKey "release-agent-42" — wait for it or cancel it: lua workflows cancel wfr_0
+```
+
+For the null bucket it says the in-flight run was started without a `correlationKey` and that `--correlation-key <key>` starts in parallel. A 409 with no key fields (workflow-wide `forbid`) prints the message without the key part. `--json` always carries the full error body. See [Workflows](./Workflows.md#concurrency-per-correlation-key).
 
 ### Builder verbs and the placement rule
 

package/docs/api/Workflows.md

@@ -14,7 +14,7 @@ Inside a sandbox (tools, jobs, webhooks, workflow code steps) `Workflows` is als
 
 - `start` **never awaits execution** — it returns `{ runId, status }` immediately. `waitSeconds` (≤ 55) asks the server to hold the response for early terminal state; it changes the response, never the execution model.
 - Runs are idempotent on `idempotencyKey` — re-sending the same key returns the existing run instead of a duplicate.
-- A workflow with `concurrencyPolicy: 'forbid'` refuses a second start while one is in flight with a thrown `WorkflowApiError { code: 'RUNS_IN_FLIGHT', blockingRunId }` — never a 429, never a gate.
+- A workflow with `concurrencyPolicy: 'forbid'` refuses a second start while one is in flight with a thrown `WorkflowApiError { code: 'RUNS_IN_FLIGHT', blockingRunId }` — never a 429, never a gate. A per-key refusal also carries `concurrencyKey` and the colliding `correlationKey`, and `lua workflows start` prints that key (see [Concurrency](./LuaWorkflow.md#concurrency)).
 - `status: 'gated'` means the run is parked (quota, billing or consent) and holds no slot. A **consent** gate is cleared by a person resolving its approval — from the desktop, or through the approvals API / inbox. `lua workflows approve` cannot clear one: it requires an `--approval wfa_…` id, which belongs to a workflow `approval` node, and a consent gate has no such id. `lua workflows status <runId>` reports a gated run, and exits 6 under `--strict`.
 - `nameOrId` resolves the workflow **name on the calling agent first**, then a workflow id.
 - `get` / `list` honour output visibility: a restricted run comes back with `restricted: true` and no `output` — never an error.
@@ -30,6 +30,7 @@ Inside a sandbox (tools, jobs, webhooks, workflow code steps) `Workflows` is als
 - Without `concurrencyKey` nothing changes: the guard stays workflow-wide.
 - `concurrencyKey` requires `concurrencyPolicy: 'forbid'`; otherwise `lua compile` / `lua push` fail with `concurrency-key-requires-forbid`, and a push that reaches the server is a 400 `VALIDATION_FAILED` (`concurrency-key-requires-forbid`). Any value other than `'correlationKey'` also fails the compile.
 - The refusal is a 409 `RUNS_IN_FLIGHT` whose body carries `blockingRunId`, `blockingStatus`, `concurrencyKey` and the colliding `correlationKey` (absent for the null bucket).
+- `lua workflows start` names the colliding `correlationKey` in its error line (and says so when the in-flight run is the keyless one); the body is unchanged under `--json`.
 - A scheduled fire that collides on its rendered `correlationKeyTemplate` key records `skipped_overlap`; a fire with a different key dispatches.
 
 ## Methods

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "lua-cli",
-  "version": "3.49.0",
+  "version": "3.49.1",
   "description": "Build, test, and deploy AI agents with custom tools, webhooks, and scheduled jobs. Features LuaAgent unified configuration, streaming chat, and batch deployment.",
   "readmeFilename": "README.md",
   "main": "dist/api-exports.js",
@@ -115,9 +115,9 @@
     "ts-node": "^10.9.2",
     "tsup": "^8.5.1",
     "@lua/sandbox-runtime": "0.0.1",
+    "@lua/shared-sandbox": "0.0.1",
     "@lua/shared-source-sync": "0.0.1",
     "@lua/shared-types": "0.0.1",
-    "@lua/shared-sandbox": "0.0.1",
     "@lua/workflow-graph": "0.0.1"
   },
   "scripts": {

package/template/package.json

@@ -20,7 +20,7 @@
     "inquirer": "^12.9.6",
     "stripe": "^17.5.0",
     "js-yaml": "^4.1.0",
-    "lua-cli": "^3.49.0",
+    "lua-cli": "^3.49.1",
     "openai": "^5.23.0",
     "uuid": "^13.0.0",
     "zod": "^3.24.1"