feat: async prompt dispatch (kind:"prompt" leaf)

[pdettori]

Summary

Adds a kind:"prompt" leaf envelope that dispatches a free-form prompt through the existing async KEDA/Redis-Streams queue, so a /turn-style interaction can be backgrounded and polled for completion — mirroring the existing kind:"solve" precedent.

Governing principle: cleanest design over fewest changes. Exactly one new discriminant is threaded end-to-end — prompt kind → responded result status → text payload — reusing every existing seam (async enqueue, KEDA ScaledJob drain, /runs/status polling, terminal classification). /turn parity comes from a shared exported executeTurn() core (parameterized only by createIfAbsent), with runTurn reduced to a thin wrapper, plus a shared sumBranchUsage helper (no third copy).

Design docs: docs/specs/2026-08-25-async-prompt-dispatch-design.md and docs/adrs/0028-async-prompt-dispatch.md.

What's in it

• Envelope + result: LeafEnvelope gains kind:"prompt" + prompt; LeafResult gains { status:"responded"; text; usage? } (one status → one payload).
• Persistence: leaf-result-store persists text: string | null with a dedicated responded branch in toResultRecord.
• Turn core: executeTurn(input) extracted from runTurn; behavior-preserving — the /turn 404 "no session in backend" contract is preserved bit-for-bit (createIfAbsent:false).
• Dispatch: runPromptLeaf maps stopReason → responded (with aborted/error special-cased); wired into runLeaf with an injectable deps.executeTurn.
• Routing: isPromptEnvelope folds into isRunEnvelope; a bare {sessionId, kind:"prompt", prompt, async:true} enqueues → 202 {status:"accepted"}; handleLeafStatus emits the responded wire shape. Zero /runs route branching change.
• Boundary guard (review fix): a workloadId on a prompt envelope still gates existence (404 if absent) but its pool selector is intentionally not injected — the API boundary logs a warning rather than injecting a selector executeTurn would silently drop (ADR 0028; prompt leaves inherit /turn's sandbox model, no per-leaf pool isolation).

Testing

Full suite green (make test, EXIT:0): @sh/knative-server 179 passed, harness 201 passed / 3 skipped, all other packages passed. Skips are the pre-existing gated live-model / live-Redis suites — not regressions. Includes new unit coverage for the prompt envelope, the responded record, the max_tokens → responded mapping, and the workload-gated-but-selector-ignored boundary.

Follow-up (non-blocking)

• Hermetic variant of the executeTurn 404-contract test with an injected backend, so the contract is asserted unconditionally in a Redis-less CI leg (the contract is currently also pinned by server.ts:94).

Resolves #168.

🤖 Generated with Claude Code

[pdettori]

✅ Reviewed — would APPROVE (self-approval blocked by GitHub, so posting as a comment).

Clean, well-documented async prompt-dispatch feature. Exactly one discriminant (prompt kind → responded status → text payload) threaded end-to-end, reusing every existing seam. Verified "responded" is terminal end-to-end: classifyOutcome uses a default-ack model, so no new branching was needed there. Model-selection precedence, the import type cycle guard, and the selector-drop boundary guard all check out, with thorough unit coverage. All CI green; 9 commits, all signed-off.

One non-blocking suggestion inline (CodeQL log-injection cleanup). The executeTurn err.message.includes("no session in backend") string-match is brittle but you've already noted the hermetic 404-contract test as a follow-up — right call.

Assisted-By: Claude Code

[pdettori]

CodeQL flags this as log injection (alert #45). Not practically exploitable — findWorkload is an exact-key lookup and workload names are validated against WORKLOAD_NAME (RFC-1123, ≤50 chars) at creation, so reaching this line means the id is already validated. But logging the stored record.workloadId instead of raw body.workloadId makes that safety self-evident and clears the alert without a suppression.

[pdettori]

Done in 6733c12 — the boundary warning now logs the resolved record.workloadId (the exact key findWorkload matched, already validated against WORKLOAD_NAME at creation) instead of the raw body.workloadId. Clears alert #45 without a suppression; no behavior change. The existing I1 test asserts only that the warn fires, so it stayed green.