lua-cli 3.33.0 โ 3.35.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/dist/api-exports.d.ts +29 -4
- package/dist/api-exports.js +331 -16
- package/dist/api-exports.js.map +1 -1
- package/dist/index.js +360 -27
- package/dist/index.js.map +1 -1
- package/dist/workflow-builder.js +324 -12
- package/dist/workflow-builder.js.map +1 -1
- package/docs/README.md +2 -2
- package/docs/api/LuaWorkflow.md +1 -1
- package/docs/workflows/migrating-runs.md +1 -1
- package/docs/workflows/recovery.md +4 -4
- package/docs/workflows/testing-offline.md +1 -1
- package/package.json +3 -3
- package/template/package.json +1 -1
package/docs/README.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
|
-
# lua-cli v3.
|
|
1
|
+
# lua-cli v3.35.0
|
|
2
2
|
|
|
3
|
-
Welcome to the comprehensive API documentation for lua-cli v3.
|
|
3
|
+
Welcome to the comprehensive API documentation for lua-cli v3.35.0. This guide covers every API, class, and function exported by the package.
|
|
4
4
|
|
|
5
5
|
## ๐ Documentation Index
|
|
6
6
|
|
package/docs/api/LuaWorkflow.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
The workflow primitive: a **durable, multi-step program** you author in TypeScript, compile with `lua compile`, and push with `lua push workflow`. The engine executes the compiled graph server-side โ steps survive restarts, waits hold no compute, and approvals/signals park the run until a person or a webhook answers.
|
|
4
4
|
|
|
5
|
-
> **Execution model โ read this first.** _`execute` re-runs from the top after resume; execution is at-least-once โ dedupe on `occurrenceId`._ `occurrenceId` is `${lineageId}:${stepId}` โ the same key on retry, resume
|
|
5
|
+
> **Execution model โ read this first.** _`execute` re-runs from the top after resume; execution is at-least-once โ dedupe on `occurrenceId`._ `occurrenceId` is `${lineageId}:${stepId}` โ the same key on retry, resume and `retry-step` (no repair run exists โ a terminal run is never re-run from its ledger); an effect that must be unique across independent runs needs your own business key (`refund:${ticketId}`). Wrap external effects in `ctx.once(key, fn)`.
|
|
6
6
|
|
|
7
7
|
## Import
|
|
8
8
|
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
_Source of truth: workflows-spec (Cluster D R46/R47, D7-r2). This page is the developer summary; the spec is normative._
|
|
4
4
|
|
|
5
|
-
`lua workflows migrate-runs <workflowId> --from <ver> --to <ver>` re-pins runs to a new version where compatible (`isResumeCompatible` โ same seeding math as
|
|
5
|
+
`lua workflows migrate-runs <workflowId> --from <ver> --to <ver>` re-pins runs to a new version where compatible (`isResumeCompatible` โ the same seeding math as `lua test workflow --from-run`); `cancel-by-version` recalls a bad version's fleet.
|
|
6
6
|
|
|
7
7
|
## Edited inputs
|
|
8
8
|
|
|
@@ -19,13 +19,13 @@ A parked step waits for exactly one of:
|
|
|
19
19
|
|
|
20
20
|
`onError:'continue'` never parks: the step is `failed` on the ledger, the run goes on, and every successor sees the step's **continued-failure value** `{ __lua_workflow:'continued_failure', failed:true, error:{code,message}, text:'' }` under `stepResults.<id>` (the default input, `${stepResults.<id>.text}` โ `''`, `getStepResult(id)`, a `conditional` on `stepResults.<id>.failed`, and the parallel / foreach join entry). A `retry-step` on such a row while the run is still running re-arms it, but a successor that already consumed the value is not re-run.
|
|
21
21
|
|
|
22
|
-
`fail` (or cancelling the run) applies the step's failure as-is. From the CLI: `lua workflows status <runId>` shows the park and names the verbs; `lua workflows retry-step <runId> --step <id>` re-runs, `lua workflows resolve-step <runId> --step <id> --outcome skip|complete|fail [--output <json|@file>] [--note โฆ]` decides (R37 โ `complete` needs `--output`, validated against the step's `outputSchema`; a second decision on the same park is a 200 no-op that names who decided). The desktop
|
|
22
|
+
`fail` (or cancelling the run) applies the step's failure as-is. From the CLI: `lua workflows status <runId>` shows the park and names the verbs; `lua workflows retry-step <runId> --step <id>` re-runs, `lua workflows resolve-step <runId> --step <id> --outcome skip|complete|fail [--output <json|@file>] [--note โฆ]` decides (R37 โ `complete` needs `--output`, validated against the step's `outputSchema`; a second decision on the same park is a 200 no-op that names who decided). The desktop run page carries the same decisions.
|
|
23
23
|
|
|
24
|
-
##
|
|
24
|
+
## No repair run
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
Nothing re-runs a run from its ledger today (LUA-709 retired the verb; BAC-601): there is no "repair run" in the CLI, the API, the chat tools or the desktop, and a **terminal run cannot be re-run**. `retry-step` and `resolve-step` are the ways past a park; a new run (`lua workflows start`) is the way past a terminal one โ offline, `lua test workflow <name> --from-run <runId>` can seed every `completed` step from the old ledger for a rehearsal. Because `occurrenceId` is stable across retry, resume and `retry-step`, an external effect executes at most once per occurrence within a run.
|
|
27
27
|
|
|
28
|
-
> **The rule to remember:** _execution is at-least-once โ dedupe on `occurrenceId`_; an effect that must be unique across **independent** runs needs your own business key (`refund:${ticketId}`).
|
|
28
|
+
> **The rule to remember:** _execution is at-least-once โ dedupe on `occurrenceId`_; an effect that must be unique across **independent** runs (a new run, seeded or not, is one) needs your own business key (`refund:${ticketId}`).
|
|
29
29
|
|
|
30
30
|
## Rehearsing offline
|
|
31
31
|
|
|
@@ -15,7 +15,7 @@ _Source of truth: workflows-spec 03 ยง3.9 (WF-204/WF-225/WF-332). This page is t
|
|
|
15
15
|
| `--approve <id>[=@payload]` ยท `--deny <id>[=@reason]` | Pre-answer approvals โ the node completes with the engine's own envelope, `WorkflowApprovalOutput` (`{ approved, decision, text, note?, editedPayload?, editRevision?, decidedBy? }`, see [Approvals](./approvals.md)); an edited payload is the FULL payload, judged like the server's inline edit (`changedPointers` against the payload the approval showed + `matchesEditablePath`, then `editedPayloadSchema`); `onDeny` defaults to `'continue'` as on the engine (LUA-751). `editable: true` with no `editablePaths` is whole-root rights (any member may change), as on the server. Because the change set is judged against the payload the approval actually showed, a change outside `editablePaths` fails exit 2 `edit-path-not-allowed` **when the approval's turn comes โ after the steps before it have run** โ not before the run starts; `editedPayloadSchema` is still checked up-front |
|
|
16
16
|
| `--signal <name>=@file\|<json>` (rep.) | Pre-supply `waitForSignal` payloads in order of arrival |
|
|
17
17
|
| `--fixtures <dir>` / `--record <dir>` | Replay / record agent+tool outputs (`<stepId>.<attempt>.json`); a missing fixture is exit **5** `FIXTURE_MISSING`, never a silent fake; `--step-output` wins over a fixture. An agent fixture's `output` is either the `{ text, object? }` reply envelope `--record` writes (the `object` wins, else the text is parsed under the `outputSchema`) or the structured value itself, taken as-is (LUA-751) โ a value that is exactly `{ text }` reads as a text reply; record it as `{ object: { text } }` |
|
|
18
|
-
| `--from-run <runId>` | Seed every `completed` step from a real run (
|
|
18
|
+
| `--from-run <runId>` | Seed every `completed` step from a real run (the ledger seeding `migrate-runs` also uses); graph drift asks for `--force` |
|
|
19
19
|
| `--park <id>` (rep.) | Simulate a platform-fault park of a `sideEffects:'external'` step โ then `retry / skip / complete / fail`, the production verbs (see [When a step parks](./recovery.md)) |
|
|
20
20
|
| `--fast-retries` | Collapse retry backoff waits to 0 |
|
|
21
21
|
| `--real-time` | Actually wait on `sleep`/backoff instead of fast-forwarding the virtual clock |
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lua-cli",
|
|
3
|
-
"version": "3.
|
|
3
|
+
"version": "3.35.0",
|
|
4
4
|
"description": "Build, test, and deploy AI agents with custom tools, webhooks, and scheduled jobs. Features LuaAgent unified configuration, streaming chat, and batch deployment.",
|
|
5
5
|
"readmeFilename": "README.md",
|
|
6
6
|
"main": "dist/api-exports.js",
|
|
@@ -116,8 +116,8 @@
|
|
|
116
116
|
"@lua/sandbox-runtime": "0.0.1",
|
|
117
117
|
"@lua/shared-sandbox": "0.0.1",
|
|
118
118
|
"@lua/shared-source-sync": "0.0.1",
|
|
119
|
-
"@lua/
|
|
120
|
-
"@lua/
|
|
119
|
+
"@lua/shared-types": "0.0.1",
|
|
120
|
+
"@lua/workflow-graph": "0.0.1"
|
|
121
121
|
},
|
|
122
122
|
"scripts": {
|
|
123
123
|
"clean": "rm -rf dist temp",
|