fix(eve): own HITL approval closure end-to-end in the harness

[ruiconti]

Stacked on #588 (red evals + problem analysis). Fixes #236, #460, #529, #533 — the four red evals from the base PR go green without touching them.

What

• harness/approved-tool-execution.ts — the harness executes approved parked tool calls itself on resume; results are durable before any model request exists.
• harness/transcript-obligations.ts — one pure guard before every model call: no local tool-call reaches a provider without a terminal tool-result. No exemptions.
• Deletes the post-resolution message deferral; extends the HITL docs; changeset.

Why execution moves out of the AI SDK

Post-approval tool execution has always happened before the next model call — the provider contract forbids a request containing a tool_use with no adjacent tool_result. On main, that execution lived inside the AI SDK: streamText/generateText begin by scanning the initial messages for approval responses (collectToolApprovals) and, if found, run the tools in a synthetic pre-stream step with no model call, before issuing the first real request.

That black-box shim had two failure modes:

• Detection is positional. The SDK only fires if the approval response is at the tail of the messages it's handed; anything appended after it silently disables execution — which is what the (now deleted) queueDeferredStepInput deferral existed to guard, and what the Linear channel's per-prompt context slipped past (Linear channel: approving a HITL tool call permanently kills the session — channel context is appended after the approval response, so collectToolApprovals never sees it (dangling tool_use → Anthropic 400) #529).
• Persistence rode the stream. Results executed inside the SDK reached the durable transcript only via stream capture — a process death mid-stream lost the closure, leaving a dangling tool_use and a guaranteed provider rejection on resume (Approved HITL tool's execution result missing from history — "tool_use ids were found without tool_result blocks" #460).

This PR keeps the timing identical but moves ownership: the harness executes approved parked calls itself on resume (closeApprovedActionBatch), appends and persists their tool-results before any model request is assembled, and parks on any authorization challenge raised mid-execute — exactly mirroring the in-stream path (shared parkOnAuthorization). The SDK path isn't just bypassed; it's structurally inert: collectToolApprovals skips any approval whose call already has a tool-result in the trailing tool message, and owned closure writes into exactly that message, so double execution is impossible.

Closure semantics

Execution goes through the same wrapToolExecute + toModelOutput normalization the SDK path uses (extracted as resolveExecutedToolModelOutput so both paths record identical results). Every approved call gets exactly one terminal closure: the real output, an error result when execute throws, and an error result when the tool is missing or has no local execute — an execute-less approved call previously produced no result from any owner and was a guaranteed provider rejection, so closing it honestly replaces a 400 with a model-visible error. action.result is emitted against the parked turn's coordinates.

Because closure no longer requires the approval message to be the request tail, the "AI SDK cannot process an approval response and a new user message in the same request" deferral is deleted: a message or channel context sent with the approving prompt rides the same model call, one fewer round-trip. The unanswered-approval deferral (unrelated follow-ups never auto-deny a pending approval) is unchanged.

The invariant guard

All synthesized transcript closure flows through one primitive, closeDanglingToolCalls(messages, resolveClosure): it finds every local tool-call without a terminal tool-result and records the supplied closure adjacent to the calling assistant message (calls resolving to undefined stay open). Two callers: handleStepResult closes invalid-input tool calls with their specific parse error — folding #576's sibling obligation out of the insertInlineToolResultMessages trailing append and the emission layer, which now only emits the event — and the tool loop's request-assembly guard, which runs once after all message assembly (pending resolution, context/message appends, compaction): any local tool-call without a later tool-result is closed with a synthetic error-text result placed adjacent to its assistant message, plus a warn log. Zero exemptions — resume closure above guarantees anything still dangling here is an orphan nothing else will close.

The repair is durable, which is the part park-time fixes can't deliver: sessions already poisoned by a missed closure (the permanently-dead sessions reported in #460/#529/#533) heal on their next turn instead of replaying the same 400 forever.

Scope

• Behavior change: approve-with-message resolves in one model call instead of two steps (test expectations updated accordingly).
• Not touched: provider-executed (MCP) approval flows, the runtime-action park/resume path, emitStreamContent's inline-result capture (still used for provider-executed and in-stream error results; its approval-resume capture branch is now dead for local tools and can be deleted in a follow-up once the e2e suite has soaked).
• Changeset: patch.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
eve-docs	Ready	Preview, Comment	Jul 9, 2026 7:56pm
eve-docs-1644	Ready	Preview, Comment, Open in v0	Jul 9, 2026 7:56pm
eve-docs-4759	Ready	Preview, Comment, Open in v0	Jul 9, 2026 7:56pm

[ruiconti]

Closing this stacked implementation PR after reverting its four commits in 166ef3f3. GitHub now reports 0 changed files against rui/hitl-approval-red-evals.

Ownership split:

• Linear channel: approving a HITL tool call permanently kills the session — channel context is appended after the approval response, so collectToolApprovals never sees it (dangling tool_use → Anthropic 400) #529 is the one issue proven to map to AI SDK's tail-only approval collector. The upstream fix is tracked in streamText silently skips local tool approvals when a later context message follows the approval response ai#17033.
• needsApproval on an authored (local) executable tool crashes on approve-resume with the OpenAI Responses provider: No tool output found for function call #236, Approved HITL tool's execution result missing from history — "tool_use ids were found without tool_result blocks" #460, and Anthropic provider: pending approval-parked tool calls break every subsequent model call (tool_use without adjacent tool_result → 400 → session.failed) #533 remain open. They do not contain the trailing-context shape proven for Linear channel: approving a HITL tool call permanently kills the session — channel context is appended after the approval response, so collectToolApprovals never sees it (dangling tool_use → Anthropic 400) #529; Approved HITL tool's execution result missing from history — "tool_use ids were found without tool_result blocks" #460 and Anthropic provider: pending approval-parked tool calls break every subsequent model call (tool_use without adjacent tool_result → 400 → session.failed) #533 still point to eve durable transcript/replay work, while needsApproval on an authored (local) executable tool crashes on approve-resume with the OpenAI Responses provider: No tool output found for function call #236 needs separate isolation.

Net: this PR closes 0 issues. The deferred upstream fix targets 1 of the original 4, leaving 3 unresolved.