[LinuxDevil]

What

Three durable-execution correctness gaps, fixed together because they share one mechanism: on start, AgentExecutor now finds tool calls of the transcript's last model turn that have no result (splitPendingTurn(), new src/execution/transcript.ts) and runs exactly those through the normal LOU-V3 batch path before calling the model.

• LOU-U7 - approval mid-batch. ExecutionSnapshot.remainingToolCalls records the calls after the paused one. resumeAfterApproval() records the paused call's result (approved) or a structured { error, note } rejection, then the executor runs the remaining calls. They can run, fail validation, or pause again with a new approval, so the chain keeps going. The resumed run now uses the same approvalStore by default. Snapshots saved before this change (no field) resume the way they did: later calls do not run. Each of them gets a "not run" error result so the transcript is valid.
• LOU-U8 - resume with new input. Checkpoint.status: 'in-progress' | 'awaiting-approval' | 'finished' (plus approvalId):
  • (a) unfinished: resumes. New input is queued behind the pending tool results (never between a tool-call turn and its results). It survives another approval pause or crash because it rides at the end of the checkpoint/snapshot. Input that re-sends the run's starting message (the natural crash retry) is not appended again; input: [] just resumes.
  • (b) finished: the checkpoint is kept (it used to be deleted) and the session continues as a conversation. A caller that re-sends the full history is not duplicated. steps, usage and toolCalls restart at zero.
  • (c) awaiting approval: throws the new exported SessionAwaitingApprovalError (sessionId, approvalId). It names resumeAfterApproval.
• LOU-U9 - checkpoint after each model turn. The assistant tool-call turn is checkpointed before any tool runs. A crash then resumes by running the missing calls without re-calling the model. Tools now get toolCallId in their execute options (non-sandbox path; the sandbox path and messages stay with LOU-U15) to use as an idempotency key.

Why queue instead of reject for (a)

Rejecting would break the most valuable case: interrupt-and-redirect, where the user aborts and sends a correction. Queueing is always provider-valid because the message is placed after the pending results. Treating the starting message as a retry keeps "call execute() again with the same request after a crash" working without duplicating the question.

Behaviour changes (tests updated, called out)

• A finished run's checkpoint is kept as 'finished' instead of deleted. Tests that asserted deletion or "fresh input on a reused session" were changed: AgentExecutor.test.ts, resume.test.ts, kvCheckpointStore.test.ts, cloudflare.checkpoint.test.ts, cancellation.test.ts, and agent-forge runRegistry.test.ts. The known-failing agent-forge test stop() then run() resumes from the last checkpoint now passes.
• Checkpoint save counts went up (one extra save per model turn, plus the finished save).
• The test that asserted later batch calls are not run after resume (parallelToolCalls.test.ts) now asserts they run once, in call order.
• Tools' execute options now include toolCallId. Three toHaveBeenCalledWith(args, {}) assertions were updated, one of them in agent-forge compileHooks.test.ts.

How verified

On the merged result (origin/main d2cdf24 merged at 5407ed2):

• npx tsc --noEmit: exit 0
• npm run lint: ✖ 433 problems (0 errors, 433 warnings) (same count as main; none in touched files)
• npm run build && npm run build --workspace=packages/create-loushy-agent: exit 0
• npm run test:coverage: Test Files 130 passed (130), Tests 1921 passed | 4 skipped (1925). Earlier runs hit load-related timing flakes in http.test.ts, guardrails.test.ts and sandbox.test.ts; they pass in isolation and on rerun.
• npm run fallow: exit 0, ✓ No issues found, ✓ 0 above threshold
• npm run test:types: 19 passed, no type errors
• npm run docs:llms:check: exit 0
• npm run docs:verify-snippets: all 80 snippet(s) type-check against src/; 6 also run cleanly
• agent-forge: typecheck and typecheck:server exit 0; npx vitest run 108 passed; npm run test:server 105 passed

New tests are in src/execution/durableExecution.test.ts (mockModel + KVCheckpointStore + a JSON round-tripping approval store, with simulated crashes via PropagatingToolError and a failing store write). They cover:

• one result per call, in call order;
• no call executed twice (except the documented at-least-once re-run of a call that was running at the crash);
• model.calls.length proving the model is not re-called;
• approve, reject, chained approvals, validation failure and legacy snapshots;
• U8 (a) queued, (a) abort-redirect, (b) continue, (b) full-history dedupe and (c) error then continue;
• queued input surviving a second approval pause.

Store round-trips: checkpoint.test.ts, kvCheckpointStore.test.ts, ApprovalGate.test.ts. The SQLite store keeps opaque JSON and is already covered by its contract tests.

Notes for reviewer

• AgentExecutor.ts changes stay focused: pending-call resume, runBatch split out of runToolCalls, checkpoint after the model turn, status-aware pause/finish. When merging LOU-V2 (agent.stream()), runStepOrAbort became generic over a step thunk, so resumed pending calls get the same step events.
• main's README carried literal conflict markers from the LOU-V2 merge. They were removed in my merge commit (Streaming, Sessions and Project-instructions bullets all kept).
• Docs: new docs/durable-execution.md, covering what is checkpointed when, resume semantics, the at-least-once caveat with a toolCallId idempotency example, compatibility and limits. Also short updates to docs/api-overview.md, docs/sessions.md and README.
• Files touched outside src/execution: agent-forge runRegistry.ts/abortableProvider.ts (doc comments only) and two agent-forge tests.
• Possible follow-up: resumeAfterApproval() without checkpointStore leaves the session marked awaiting-approval. This is documented, but could be detected.

🤖 Generated with Claude Code