[Bug] workflow tool clips its result to 50,000 chars BEFORE the spill policy runs; the spill file labelled "Full formatted result" is truncated and the rest is lost

[kevinchiha]

Versions: dsh 0.1.5-rc.1, @deepseek-ai/dsh-tool-workflow 0.1.5-rc.2, @deepseek-ai/dsh-spill-policy 0.1.5-rc.2. Same code in dsh-tool-workflow@0.1.6-alpha.1 (lib/index.js:130-134).

What happens

A workflow script that returns more than maxResultChars (default 50,000) loses the excess for good. The tool's own render() clips the JSON and appends … [truncated: N more characters]. The spill policy runs later, on tools/post-execute, and only ever sees that clipped text. It saves it to the spill file and labels the file "Full formatted result stored at: …". The file is not full, and nothing in the message says so.

Nothing else keeps a copy. The tool/result session event stores the same clipped text, and the inline workflow tool writes only tool-workflow/run-start and run-end events, neither of which carries the value. The workflow_manage run records belong to a different package (@dsh-external/workflow), not to this tool.

On 2026-09-16 a 39-agent workflow here returned ~226 KB. 78% of the findings were gone before anything reached disk; the run had to be repeated with hand-capped return values.

Repro

Any script with a return value over 50,000 characters, zero agents needed:

return { blob: "x".repeat(60000), tail: "END-OF-VALUE" };

Result: a spill file of 50,098 bytes that ends with … [truncated: 10042 more characters]. tail never reaches disk. The inline notice reads (Omitted 292 bytes. Full formatted result stored at: /tmp/dsh-spill-…/…-workflow.txt. …).

Where

• dsh-tool-workflow/lib/index.js:130-134 — renderResult() slices to maxChars and returns the clipped string.
• dsh-tool-workflow/lib/index.js:226-229 — output.render calls it with maxResultChars.
• dsh-tools/lib/index.js:3415-3445 — createSuccessResult() renders before post-execute; the full value is still on result.value.
• dsh-spill-policy/lib/index.js:155-172 — the post-execute arm reads decision.content ?? result.content, the already-clipped text, and calls formatSpillNotice() (:21-23), which always says "Full formatted result".

Two defects

1. Ordering. Spill exists to keep the full output out of context without losing it. Clipping in render() first defeats that: the spill file holds a copy of the truncation, not of the result.
2. A false claim. "Full formatted result stored at" is wrong whenever a producer clips before the policy runs. Either the policy needs to be told the text is partial, or the wording should not promise completeness.

Why the cap can't be raised from user config

tool-workflow registers no settings namespace, so a tool-workflow: section in settings.yaml is ignored (verified: same 50,000 cut after adding one). The live row is inside the standard agent preset (dsh-agent-presets/presets/standard/agent.cordis.yml:227), which no cordis.patch.yml layer reaches. The base-bundle row at dsh-base/cordis.patch.yml:374 is disabled by dsh-web-app/cordis.patch.yml:458. And a bigger cap only widens the window; it does not fix the ordering.

Suggested fix

In dsh-tool-workflow, let render() emit the full JSON and leave bounding to the spill policy, which already does head/tail preview plus a locator. If a cap must stay in the tool for deployments without a spill store, spill first and clip second, or hand the policy a "partial" flag so formatSpillNotice() can say so.

Work-around we run

A ~40-line local plugin on tools/post-execute that, for a successful workflow call, re-renders result.value whole and replaces the content, so the policy spills the real thing. It is pushed (not prepended), so it always runs inside the policy's next() whichever row loads first. With it, the 60 KB repro lands whole in the spill file with no truncation marker. Happy to share it if useful.