🤖 fix: summarize invalid tool input errors and state the advisor question cap - #4227

Summary

Tool input validation failures now reach the model as one concise, actionable sentence instead of the AI SDK's raw AI_InvalidToolInputError string, the advisor tool description states its 2000-character question cap, and an advisor stream that produces no text is reported as an error instead of a success-shaped empty result.

Background

In an RLM-mode session the model called advisor with a 3421-character question. The zod schema rejected it before execution and StreamManager relayed the SDK's error verbatim as the tool result: a ~4 KB string that echoes the entire submitted input and only at the very end says Too big: expected string to have <=2000 characters, without the actual length. The model retried at 2071 characters (same blob), then its two in-limit calls returned { type: "advice", advice: "" } because the advisor model stream produced nothing, which the tool reported as success. Four calls, zero advice, and the tool description never mentioned the cap.

The RLM kernel path (toolBridge.ts) already rendered zod failures readably; only the top-level AI SDK path relayed the raw string.

Implementation

• formatToolInputIssues (new, src/common/utils/tools): renders zod v4 issues as <path>: <message>, appending (received N characters) for string size violations by resolving the path inside the parsed input. It never includes the input value. Shared by the kernel bridge and StreamManager so both paths produce the same shape.
• summarizeInvalidToolInputErrors (new, src/node/utils/messages): a streamText experimental_transform. An invalid dynamic tool-call part carries the structured error; its cause chain (InvalidToolInputError -> TypeValidationError -> ZodError) is walked to build Invalid input for tool advisor: question: Too big: expected string to have <=2000 characters (received 3421 characters), and the matching tool-error part's error is rewritten to it. Non-zod causes fall back to the clamped original message. It has to be a transform rather than fullStream-consumer logic: AI SDK 7 builds the next step's tool-result message from the transformed stream (and prepareStep does not rewrite it), so a consumer-side rewrite only reached the tool card and later turns while the model's same-turn retry still got the input-echoing text. StreamManager wires the transform in createStreamResult; its tool-error handling is unchanged and now simply persists the rewritten string.
• ADVISOR_QUESTION_MAX_CHARS is shared by AdvisorToolInputSchema and ADVISOR_TOOL_DESCRIPTION.
• advisor.ts: blank advice returns { type: "error", message: "Advisor returned no advice (finish reason: ...)" } after usage is still reported.

Validation

streamManager.invalidToolInput.test.ts drives a real startStream with a mock model that emits an over-cap advisor call and captures the second provider request: its tool-result is the one-line summary (with received 2100 characters, no echoed input), and the persisted tool part carries the same text. Without the transform the same test receives the ~2 KB AI_InvalidToolInputError blob.

Remote dogfood UAT on b5a71760 (Coder Agents, fresh workspace, real models): over-long (2500, 6057 chars), boundary (2000 passes, 2001 fails with received 2001), special-character and multibyte payloads all produce the one-line error with no echoed input; a retry within the limit and a short regression call return real advice; the tool description shows the cap; an organic empty advisor response rendered as a failed card with the finish reason. Round 2 (RLM Mode enabled) repeated the over-cap, 2000/2001 boundary, hostile-character, kernel (xum.timeline_event 400 chars -> received 400 characters) and short-regression cases, and found the same-turn gap fixed by the third commit. Round 3 on the final head is recorded in the ledger below.

Risks

Low. The StreamManager change only alters the error string of tool results the SDK already rejected before execution; successful tool calls and non-validation tool errors are untouched. The advisor change converts a previously silent empty success into a visible error result.

Found during UAT, out of scope

Instructing the agent to call advisor({ question: "" }) produced a provider-side stream error from the dev AI gateway (processing error: accumulate event: error converting content block to JSON ... invalid character '}') before any tool-call part reached StreamManager. The stream then auto-retried indefinitely (Stop did not end it) and the app hung on "Loading Xum..." for every browser session until the backend was restarted. Nothing in this diff is on that path (the error arrives as a provider error part, not as a tool call), and round 2 reproduced it byte-identically on the merge-base 023701d63, so it is pre-existing and tracked separately: see #4228.

Round 2 also noted that kernel code_execution results echo an oversized argument inside toolCalls[].args even though the error string is concise. That is the designed, size-capped args trace (KERNEL_COMPACT_ARGS_CAP_BYTES in src/constants/kernelOutput.ts), untouched here.

Deferred from review: capping the number of rendered zod issues in formatToolInputIssues (Codex P1, round 2). Not a regression of this PR; the change is ready and tested on branch mike/bound-tool-input-summary (d65a6739, stacked on this head) and can be opened as a stacked PR on request once this PR lands.

Generated with xum • Model: anthropic:claude-fable-5-1 • Thinking: xhigh