lua-cli 3.32.1 → 3.32.3

package/template/examples/workflows/adversarial-verify.workflow.script.js

@@ -1,6 +1,10 @@
 // Example (i) — adversarial verify: spawn finders until two consecutive rounds add nothing
 // new, then have an independent verifier confirm each finding. Script form (04 §4.3);
 // push with `lua push workflow`, run offline with `lua test workflow adversarial-verify`.
+// LUA-751: `parallel()` takes THUNKS (04 §4.3.2 — `parallel(angles.map((angle) => () => agent(…)))`); an array of
+// promises resolved to `null`s. And a `step()` closure is journaled once and never re-runs on replay, so it must not
+// mutate module state: it RETURNS the fresh findings and the merge into `found` happens outside it — otherwise the
+// replay tick saw an empty `found`, issued nothing to verify and diverged (`JOURNAL_DIVERGENCE(entry_before_issue)`).
 export const meta = {
   name: 'adversarial-verify',
   description: 'Find candidate issues from several angles, verify each independently, report the confirmed set',
@@ -13,29 +17,29 @@ const found = new Map();
 let quietRounds = 0;
 for (let round = 1; round <= 5 && quietRounds < 2; round++) {
   const batch = await parallel(
-    args.angles.map((angle) =>
-      agent(`Round ${round}: list concrete issues in ${args.subject} from the ${angle} angle. One per line.`, {
-        phase: 'Find',
-        label: `find-${angle}-${round}`,
-      })
+    args.angles.map(
+      (angle) => () =>
+        agent(`Round ${round}: list concrete issues in ${args.subject} from the ${angle} angle. One per line.`, {
+          phase: 'Find',
+          label: `find-${angle}-${round}`,
+        })
     )
   );
-  // step(): a pure reduction journaled once — its closure may use anything, it never re-runs on replay.
-  const added = await step(`dedupe-${round}`, () => {
-    let fresh = 0;
+  // step(): a pure reduction journaled once — its closure may use anything, it never re-runs on replay, so it
+  // returns what it found and touches no state of its own; the merge below is plain script code that replays.
+  const fresh = await step(`dedupe-${round}`, () => {
+    const out = [];
     for (const text of batch) {
-      for (const line of String(text).split('\n')) {
+      for (const line of String(text ?? '').split('\n')) {
         const key = line.trim().toLowerCase();
-        if (key && !found.has(key)) {
-          found.set(key, line.trim());
-          fresh++;
-        }
+        if (key && !found.has(key) && !out.some((f) => f.key === key)) out.push({ key, line: line.trim() });
       }
     }
-    return fresh;
+    return out;
   });
-  quietRounds = added === 0 ? quietRounds + 1 : 0;
-  log(`round ${round}: ${added} new finding(s)`);
+  for (const f of fresh) found.set(f.key, f.line);
+  quietRounds = fresh.length === 0 ? quietRounds + 1 : 0;
+  log(`round ${round}: ${fresh.length} new finding(s)`);
 }
 
 const verdicts = await foreach(

package/template/examples/workflows/outreach.ts

@@ -1,5 +1,8 @@
 // foreach + approval + an exactly-once send (`ctx.once`).
-// Verbatim from workflows-spec 03 §3.2 (b) (WF-215 / WF-223 — the spec is normative).
+// From workflows-spec 03 §3.2 (b) (WF-215 / WF-223 — the spec is normative). LUA-751: `sendEmails` reads the approval node's
+// REAL output — `WorkflowApprovalOutput` (@lua/shared-types), the ONE shape the engine emits and `lua workflows run --approve`
+// emits offline: the approver's edited `{ drafts }` rides under `editedPayload`; otherwise the drafts are read back from the
+// `drafts` map the approval was shown (`getStepResult`) — the output never echoes the original payload.
 import { z } from 'zod';
 import { createStep, createWorkflow, fromInit, fromStep, template, AI, Channels } from 'lua-cli';
 
@@ -8,7 +11,7 @@ const draft = z.object({ to: z.string(), body: z.string() });
 
 const draftEmail = createStep({
   id: 'draftEmail',
-  inputSchema: lead,                                       // foreach passes the RAW item — `{ email, name }`, not `{ lead: {…} }` (§3.2.1 check 4)
+  inputSchema: lead, // foreach passes the RAW item — `{ email, name }`, not `{ lead: {…} }` (§3.2.1 check 4)
   outputSchema: draft,
   async execute({ inputData }) {
     // string overload → Promise<string> (`api-exports.ts:768`); the object overload returns `AiGenerateOutput{ text, … }` (`:786`, shared-types `ai-generate.types.ts:78-86`)
@@ -18,16 +21,22 @@ const draftEmail = createStep({
 });
 const sendEmails = createStep({
   id: 'sendEmails',
-  inputSchema: z.object({ drafts: z.array(draft) }),
+  // The approval node's output (`WorkflowApprovalOutput`): what this step reads, `.passthrough()` for the rest of the envelope
+  // (`decision`, `text`, `note`, `editRevision`, `decidedBy`, `timedOut`, `escalations`).
+  inputSchema: z
+    .object({ approved: z.boolean(), editedPayload: z.object({ drafts: z.array(draft) }).optional() })
+    .passthrough(),
   outputSchema: z.object({ sent: z.number() }),
-  sideEffects: 'external',                                  // never auto-retried on platform-fault reclaim
-  onError: 'park',                                          // an EFFECT_IN_DOUBT parks the step for R37 instead of failing the run
-  async execute({ inputData, once }) {
+  sideEffects: 'external', // never auto-retried on platform-fault reclaim
+  onError: 'park', // an EFFECT_IN_DOUBT parks the step for R37 instead of failing the run
+  async execute({ inputData, getStepResult, once }) {
+    if (!inputData.approved) return { sent: 0 }; // denied — data, not an exception (§06 §6.4.11); a timeout cancels the run before this step (`onTimeout:'cancel-run'`)
+    const { drafts } = inputData.editedPayload ?? getStepResult<{ drafts: z.infer<typeof draft>[] }>('drafts'); // the approver's edits, else the batch the approval showed
     let sent = 0;
-    for (const d of inputData.drafts) {
+    for (const d of drafts) {
       // exactly-once per {occurrenceId, key}: a retry, resume, repair run or migrated run that reaches this line again gets the stored
       // result back and never re-sends (I27 claim/settle). No hand-rolled Data check-then-act — that pattern was non-atomic.
-      const r = await once(d.to, () => Channels.email.send({ to: { email: d.to }, subject: 'Hello', body: d.body }));   // `EmailSendInput.to` is `{ userId?, email? }`
+      const r = await once(d.to, () => Channels.email.send({ to: { email: d.to }, subject: 'Hello', body: d.body })); // `EmailSendInput.to` is `{ userId?, email? }`
       // The whole `Channels` facade is callable in-step — incl. `Channels.whatsapp.send({ threadId: ctx.runtime.replyTo!.threadId, text })` on a customer-channel run (07 §7.0-L / §7.4.5): a step MAY answer the customer
       // itself (e.g. the refund outcome right after the Stripe step, before a QA step that must not delay it); `once()` covers it exactly like email, and the platform's terminal reply then lands as a
       // duplicate-safe fallback (same threadId; the customer sees two lines only if the step's text differs). Outside WhatsApp's session the in-step send needs a template too — `Channels.whatsapp.sendTemplate` (closing pass 2026-08-27).
@@ -45,11 +54,18 @@ export const outreach = createWorkflow({
   scheduleInput: { leads: [] },
   concurrencyPolicy: 'forbid',
 })
-  .map({ leads: fromInit('leads') }, { id: 'leads' })                        // entry 1 — three maps in this workflow ⇒ every id explicit (`map-id-required`)
-  .map({ '': fromStep('leads', 'leads') }, { id: 'items' })                  // entry 2 — '' key = "output IS this value" (Lua extension, §3.4): foreach needs a raw array upstream
-  .foreach(draftEmail, { concurrency: 8, maxItems: 500 })                   // entry 3 — items are `lead`s, output is `draft[]`
-  .map({ drafts: fromStep('draftEmail') }, { id: 'drafts' })                 // entry 4 — `{ drafts: draft[] }`, the approval's editable payload
-  .approval('reviewDrafts', { title: 'Approve outreach batch', details: template('${stepResults.drafts.drafts.length} drafts ready'),
-    approver: 'org-admins', timeoutHours: 48, onTimeout: 'cancel-run', editable: true, editablePaths: ['drafts', 'drafts[*].body'] })   // entry 5
-  .then(sendEmails)                                                          // entry 6 — reads `stepResults.drafts` (the approval passes its edited payload through)
+  .map({ leads: fromInit('leads') }, { id: 'leads' }) // entry 1 — three maps in this workflow ⇒ every id explicit (`map-id-required`)
+  .map({ '': fromStep('leads', 'leads') }, { id: 'items' }) // entry 2 — '' key = "output IS this value" (Lua extension, §3.4): foreach needs a raw array upstream
+  .foreach(draftEmail, { concurrency: 8, maxItems: 500 }) // entry 3 — items are `lead`s, output is `draft[]`
+  .map({ drafts: fromStep('draftEmail') }, { id: 'drafts' }) // entry 4 — `{ drafts: draft[] }`, the approval's editable payload
+  .approval('reviewDrafts', {
+    title: 'Approve outreach batch',
+    details: template('${stepResults.drafts.drafts.length} drafts ready'),
+    approver: 'org-admins',
+    timeoutHours: 48,
+    onTimeout: 'cancel-run',
+    editable: true,
+    editablePaths: ['drafts', 'drafts[*].body'],
+  }) // entry 5
+  .then(sendEmails) // entry 6 — its input IS the approval's output; the drafts come from `editedPayload` or `getStepResult('drafts')`
   .commit();

package/template/examples/workflows/pr-review-round.ts

@@ -13,9 +13,13 @@ const pushFix = createStep({
   tier: 'job',
   workspace: { mount: 'rw' },
   timeoutSeconds: 600,
-  async execute({ workspace }) {
-    // git runs through the credential proxy — no token in this container (05 §5.17.3)
-    const sha = (await $`git -C ${workspace!.path} rev-parse HEAD`).stdout.trim(); // `$` = the Job image's shell helper (`@lua/coding-harness/shell`); a plain child_process spawn works too — the Job site has no REQUIRE_BLOCKLIST for `child_process`
+  async execute({ $, workspace, log }) {
+    // `ctx.$` (LUA-682) runs an allow-listed binary in the checkout — argv only, no shell — with git's remote on the
+    // credential proxy: no token in this container (05 §5.17.3). `child_process` is NOT available to a code step
+    // (`lua compile` refuses it: node-capability-unavailable); a coding turn's `shell` tool is the other way to run
+    // commands. The harness pushes the branch at the checkpoint / terminal; this step reports what it pushed.
+    const sha = (await $!.strict`git rev-parse HEAD`).stdout.trim();
+    log(`pushed ${sha} on ${workspace!.branch ?? 'the run branch'}`);
     return { headSha: sha };
   },
 });

package/template/examples/workflows/refund-approval.ts

@@ -1,22 +1,35 @@
 // Maker-checker refund with escalation, business-hours deadlines and a recoverable external step.
-// Verbatim from workflows-spec 03 §3.2 (e) (WF-215 / WF-223 — the spec is normative).
+// From workflows-spec 03 §3.2 (e) (WF-215 / WF-223 — the spec is normative). LUA-751: the step after the approval reads the
+// approval node's REAL output — `WorkflowApprovalOutput` (@lua/shared-types): `{ approved, decision, text, note?, editedPayload?,
+// editRevision?, decidedBy?, timedOut?, escalations? }`, the ONE shape the engine emits and `lua workflows run --approve` emits
+// offline. The listing's `input: <preceding output>` pass-through (04 §4.2.3) was never implemented — the original payload is not
+// echoed back; the step reads the request back with `getStepResult('refundRequest')` (docs/workflows/approvals.md). The `refundRequest`
+// map ahead of the approval makes the payload the approver sees and edits exactly what `editedPayloadSchema` describes
+// (`{ ticketId, amount }`, not the whole run input): an edit is judged on the pointers that changed against that payload.
 import { z } from 'zod';
-import { createStep, createWorkflow, template, Integrations } from 'lua-cli';
+import { createStep, createWorkflow, fromInit, template, Integrations } from 'lua-cli';
+
+const refundRequest = z.object({ ticketId: z.string(), amount: z.number() });
 
 const postRefund = createStep({
   id: 'postRefund',
-  inputSchema: z.object({
-    approved: z.boolean(),
-    editedPayload: z.object({ ticketId: z.string(), amount: z.number() }).optional(),
-    input: z.object({ ticketId: z.string(), amount: z.number() }),
-  }), // the approval node's output shape (04 §4.2.3)
+  // The approval node's output (`WorkflowApprovalOutput`): the members this step reads; `.passthrough()` admits the rest of the
+  // envelope (`decision`, `text`, `note`, `editRevision`, `decidedBy`, `timedOut`, `escalations`) — the engine validates a step's
+  // input with `additionalProperties:false` otherwise.
+  inputSchema: z
+    .object({
+      approved: z.boolean(),
+      editedPayload: refundRequest.optional(), // only when the approver edited the amount (`editablePaths` below)
+    })
+    .passthrough(),
   outputSchema: z.object({ refundId: z.string().nullable() }),
   sideEffects: 'external', // a platform-fault reclaim PARKS this step (never auto-retried); the run gates `exception` (§06 §6.3.5)
   onError: 'park', // a final customer-fault failure parks too — the operator retries / skips / supplies the refundId / fails it
   requiredConnections: ['stripe'], // the declared key below — resolved on the owner agent at run time (LUA-623); no connection of that type ⇒ failed{credentials_unresolved}, unmountable ⇒ failed{credentials_revoked, reason:'required_connection_unmountable'} → parked via onError:'park' (§11 §11.5.5)
-  async execute({ inputData, occurrenceId }) {
-    if (!inputData.approved) return { refundId: null };
-    const r = inputData.editedPayload ?? inputData.input;
+  async execute({ inputData, getStepResult, occurrenceId }) {
+    if (!inputData.approved) return { refundId: null }; // denied, or timed out under the chain's terminal 'deny' — data, never an exception (§06 §6.4.11)
+    // The edited details when the approver lowered the amount, else the request the approver saw (the `refundRequest` map). The output never echoes it.
+    const r = inputData.editedPayload ?? getStepResult<z.infer<typeof refundRequest>>('refundRequest');
     // `occurrenceId` is `${lineageId}:${stepId}`: the same key on retry-step, on resume and on a REPAIR RUN — the refund collapses to one (§06 §6.3.3 (e)).
     // A key that must hold across INDEPENDENT runs (two runs for the same ticket) is the caller's: `refund:${r.ticketId}` (§06 §6.3.3 (f)).
     const res = await Integrations.passthrough('stripe', {
@@ -36,6 +49,7 @@ export const refund = createWorkflow({
   budget: { maxDurationSeconds: 14 * 24 * 3600 }, // long enough for two business-hours escalation hops (the compiler warns `deadline-clamped` otherwise)
   connections: [{ key: 'stripe', integrationType: 'stripe', required: true }], // the Stripe connection the refund step acts through, declared once by key — never a frozen connection id (LUA-623)
 })
+  .map({ ticketId: fromInit('ticketId'), amount: fromInit('amount') }, { id: 'refundRequest' }) // the payload the approver reviews — and may edit — is the refund request, not the whole run input
   .approval('approveRefund', {
     title: 'Refund request',
     details: template('Refund ${initData.amount} for ticket ${initData.ticketId}'),
@@ -48,10 +62,10 @@ export const refund = createWorkflow({
       { escalateTo: { role: 'finance-controller' }, timeoutHours: 16 }, // …hop 1: finance, 16 business hours, then…
       { escalateTo: 'org-admins', timeoutHours: 24 }, // …hop 2: org admins, then…
       'deny',
-    ], // …the node completes {approved:false, timedOut:true, escalations:2} — branchable data (§06 §6.4.11)
+    ], // …the node completes {approved:false, decision:'timed_out', text:'timed_out', timedOut:true, escalations:2} — branchable data (§06 §6.4.11)
     editable: true,
     editablePaths: ['amount'], // the approver may lower the amount; the approve call echoes the fingerprint of the revision it saw (§06 §6.4.9)
     editedPayloadSchema: z.object({ ticketId: z.string(), amount: z.number().positive().max(500) }),
   })
-  .then(postRefund)
+  .then(postRefund) // its input IS the approval's output (the default previous-output rule, §05 §5.5.1.1)
   .commit();

package/template/examples/workflows/ticket-to-pr.ts

@@ -1,4 +1,4 @@
-// Linear label -> clone -> parallel worktree arms -> merge -> tests -> PR -> review loop -> approval -> merge.
+// Linear label -> clone -> parallel worktree arms -> merge -> tests -> PR (coding turn) -> review loop -> approval -> the decision (the merge stays human).
 // From workflows-spec 03 §3.2 (f) (WF-215 / WF-223 — the spec is normative). LUA-635: `openPr` is placed by `.then(openPr)` on
 // both test outcomes — the listing's `otherwise: 'openPr'` named a `.then(createStep)` placement, which never declares an id
 // (03 §3.2.0); a string arm names an agentStep / specialistStep / toolStep / map / workflow declaration. `mergeGate.title` is a
@@ -16,49 +16,43 @@ const runTests = createStep({
   workspace: { mount: 'rw' },
   timeoutSeconds: 3600,
   jobResources: 'large', // a 15–40 min monorepo suite fits one 4 h segment (D19-r1); up to 86 400 s is legal since D19-r2 — see §3.2 (h) for a step that crosses the segment boundary
-  async execute({ workspace, log }) {
-    const r = await $`cd ${workspace!.path} && npm ci && npm test -- --maxWorkers=2`.nothrow(); // untracked node_modules were rebuilt on restore (05 §5.17.5, E12); `--maxWorkers=2` keeps a mongodb-memory-server-per-file suite inside `large`'s 8 GiB — over it the container is OOM-killed and the step fails `job_oom_killed` (customer fault, 05 §5.17.4; §3.12 note)
+  async execute({ $, log }) {
+    // `ctx.$` runs ONE allow-listed binary per call, argv only, in the checkout (LUA-682): no `cd`, no `&&` — the
+    // cwd is the workspace root and a second command is a second call. `.strict` throws on a non-zero exit; the
+    // plain form returns it, which is what a test run wants.
+    await $!.strict`npm ci`; // untracked node_modules were rebuilt on restore (05 §5.17.5, E12)
+    const r = await $!`npm test -- --maxWorkers=2`; // `--maxWorkers=2` keeps a mongodb-memory-server-per-file suite inside `large`'s 8 GiB — over it the container is OOM-killed and the step fails `job_oom_killed` (customer fault, 05 §5.17.4; §3.12 note)
     log(r.stdout.slice(-4000));
-    return { passed: r.exitCode === 0, summary: r.stdout.slice(-2000) };
+    return { passed: r.code === 0, summary: r.stdout.slice(-2000) };
   },
 });
 
-const openPr = createStep({
-  id: 'openPr',
-  inputSchema: z.object({ ticketId: z.string(), title: z.string() }),
-  outputSchema: z.object({ prNumber: z.number(), url: z.string() }),
-  tier: 'job',
-  workspace: { mount: 'ro' },
-  sideEffects: 'external',
-  onError: 'park', // a PR is an external effect: a platform fault PARKS (06 §6.3.5); `gh` is idempotent on the branch anyway
-  async execute({ workspace, inputData, runId }) {
-    const out =
-      await $`cd ${workspace!.path} && gh pr create --fill --title ${inputData.title} --body ${`Closes ${inputData.ticketId}\n\n<!-- lua-run:${runId} -->`}`; // the run id in the PR body is what the GitHub webhook uses to route review signals (§3.7)
-    const url = out.stdout.trim();
-    return { prNumber: Number(url.split('/').pop()), url };
-  },
-});
+// `openPr` is a CODING TURN (05 §5.17.6) — the pilot's real pattern: the harness's own `gh` tool talks to the sidecar's
+// gh proxy. A Job-tier code step can run `gh` too (`ctx.$`, with `jobTools:['gh']` on the step), but the proxy admits
+// `gh pr create` / `gh pr edit` / `gh pr comment` on the pinned repo only — no merge, no /graphql (T17-D-SE25) — and the
+// end-to-end path is the sidecar's to prove; the coding turn is what ships PRs today.
 
-const mergePr = createStep({
-  id: 'mergePr',
-  inputSchema: z.object({ approved: z.boolean(), input: z.object({ prNumber: z.number() }) }),
-  outputSchema: z.object({ merged: z.boolean() }),
-  tier: 'job',
-  workspace: { mount: 'ro' },
-  jobTools: ['gh'],
-  sideEffects: 'external',
-  onError: 'park', // `jobTools:['gh']` is what mints GH_TOKEN for a code step (11 §11.5.6: pull_requests:write + contents:write + issues:read, repo-scoped — merge is a contents write on GitHub)
-  async execute({ workspace, inputData }) {
-    if (!inputData.approved) return { merged: false };
-    await $`cd ${workspace!.path} && gh pr merge ${inputData.input.prNumber} --squash --delete-branch`; // succeeds only if the base branch's ruleset lets the App merge — human-only-merge orgs keep contents:write off the App (11 T21)
-    return { merged: true };
+const recordDecision = createStep({
+  id: 'recordDecision',
+  inputSchema: z.object({ approved: z.boolean(), prNumber: z.number() }), // projected by the `mergeInput` map below — an approval's output carries `approved` (and `decidedBy`, `editRevision`…), never the payload it was shown (docs/workflows/approvals.md), so the PR number is read back from `openPr`
+  outputSchema: z.object({ approved: z.boolean(), prNumber: z.number(), merged: z.boolean() }),
+  async execute({ inputData, log }) {
+    // The merge itself stays with a person: `gh pr merge` is refused by the sidecar BY DESIGN (a contents write; human-only-merge
+    // orgs keep contents:write off the App, 11 T21), so the workflow ends at the decision — `merged` is always false here and
+    // the approver merges when ready.
+    log(
+      inputData.approved
+        ? `PR #${inputData.prNumber} approved — merge when ready`
+        : `PR #${inputData.prNumber} not approved`
+    );
+    return { approved: inputData.approved, prNumber: inputData.prNumber, merged: false };
   },
 });
 
 export const ticketToPr = createWorkflow({
   name: 'ticket-to-pr',
   description:
-    'Linear label → implement/tests/docs in parallel worktrees → merge → test suite → PR → review rounds → approval → merge',
+    'Linear label → implement/tests/docs in parallel worktrees → merge → test suite → PR → review rounds → approval → decision (a human merges)',
   inputSchema: z.object({
     ticketId: z.string(),
     title: z.string(),
@@ -66,7 +60,7 @@ export const ticketToPr = createWorkflow({
     repo: z.string(),
     baseRef: z.string().default('main'),
   }),
-  outputSchema: z.object({ merged: z.boolean(), prUrl: z.string().optional(), rounds: z.number() }),
+  outputSchema: z.object({ approved: z.boolean(), prNumber: z.number(), merged: z.boolean() }), // the decision; the merge is a human act (see `recordDecision`)
   connections: [{ key: 'github', integrationType: 'github', required: true }], // the GitHub connection this workflow acts through, declared ONCE by key — resolved on the owner agent at run time (an agent-scoped GitHub connection first, then org-scoped; LUA-623), so the same definition runs on any agent: no frozen connection id in source, no per-agent build
   workspace: {
     kind: 'git',
@@ -117,7 +111,19 @@ export const ticketToPr = createWorkflow({
       'The test suite failed:\n${stepResults.runTests.summary}\nFix the code (not the tests unless they are wrong) and re-run `npm test` until green.'
     ),
   })
-  .then(openPr)
+  .agentStep('openPr', {
+    // a CODING TURN with `gh` (05 §5.17.6): opens the PR from the run branch and reports it as typed output
+    agentId: 'swe-implementer',
+    tier: 'job',
+    workspace: { mount: 'ro' },
+    timeoutSeconds: 600,
+    jobResources: 'small',
+    prompt: template(
+      'Open a pull request from the current branch against ${initData.baseRef} for ticket ${initData.ticketId}, titled "${initData.title}". Put the marker the harness gives you for this run in the PR body (the GitHub webhook routes review signals by it). Reply with the PR number and URL.'
+    ),
+    toolScope: { jobTools: ['gh', 'git', 'read', 'glob', 'grep'] }, // `gh` here is the harness's tool through the sidecar's gh proxy (create / edit / comment on this repo only)
+    outputSchema: z.object({ prNumber: z.number(), url: z.string() }),
+  })
   .dowhile('reviewRound', eq(step('reviewRound').path('state'), lit('changes_requested')), { maxIterations: 8 }) // ≤ 8 review rounds (the SWE_REVIEW_MAX_ROUNDS lesson)
   .workflow(
     'reviewRound',
@@ -133,5 +139,6 @@ export const ticketToPr = createWorkflow({
     timeoutHours: 72,
     onTimeout: 'deny',
   })
-  .then(mergePr)
+  .map({ approved: fromStep('mergeGate', 'approved'), prNumber: fromStep('openPr', 'prNumber') }, { id: 'mergeInput' }) // a `.then(step)` receives the PREVIOUS node's output — the approval's, which has `approved` but not the PR number — so the fields `recordDecision` declares are projected explicitly; without this map the row fails `input_schema_invalid` before dispatch (LUA-679, found by the LUA-669 builder)
+  .then(recordDecision)
   .commit();

package/template/package.json

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