[Bug] reasoning-only stop is treated as completed and silently ends the turn

[RuichiXu]

Summary

A terminal stop response containing reasoning blocks but no non-whitespace text or tool call is treated as a successful completed turn. The user sees thinking stop with no final answer, and retry is never entered.

Reproduction

Using the real ReactLoopAgent from 0.1.1-rc.2, an isolated in-memory stream with this normalized shape reproduced the problem 25/25 times:

finish: stop
content: [reasoning]
no text
no tool call

Each run returned completed; the final assistant message contained reasoning only.

Root cause

dsh-llm-pi-ai rejects only content.length === 0, so reasoning makes the response successful. AgentLoop then sees no tool calls and returns completed.

Expected behavior

A stop with neither deliverable text nor a tool call should not silently complete. It should enter a bounded retry path such as EMPTY_RESPONSE, or return an explicit error. max-tokens behavior should remain unchanged.

The existing empty-response design note explicitly keeps reasoning-only responses successful; this reproduction shows that the choice can silently lose the user-visible answer.

[liyangbing]

这个现象的关键是不要把“有 reasoning”当成“有 deliverable”。在 runtime 层可以把完成条件明确写成：

• finishReason=stop 只表示 provider 停止生成；
• 只有出现非空用户可见 text，或存在等待处理/确认的 tool call，才允许把 turn 标为正常完成；
• 只有 reasoning、空白 text、无 tool call 时，进入有上限的 EMPTY_RESPONSE 重试或显式失败，并保留原始 stream 证据；
• retry 必须带 attempt id / budget，避免把同一个 reasoning-only 响应无限重放。

SandBase Harness 的事件模型将 reasoning 单独记录为 agent.thinking，用户消息记录为 agent.message，工具调用也有独立事件；因此 UI/审计可以区分“模型想过”与“用户收到可交付结果”。事件投影实现 和 v0.3.8 发布说明 可作为参考。这里同样不意味着该项目替 DSH 核心决定 EMPTY_RESPONSE 策略，最终仍应由上游的 loop contract 明确定义并测试。

[argszero]

Source-verified at cd5ef8148 (0.1.2-alpha.1). Your root-cause chain is correct, and the good news is the bounded retry path you ask for already exists — the bug is a misclassification, not a missing mechanism.

① Chain confirmed at source

• dsh-llm-pi-ai mapStopReason (llm-pi-ai/src/stream.ts:98): stop + message.content.length === 0 → EMPTY_RESPONSE error. content is the block array, so a reasoning block makes content.length ≥ 1 → falls through to { kind: 'stop' } (:105).
• ReactLoopAgent.step() (core/agent-loop/src/agent.ts:423-435): finish.kind === 'stop' → createAssistantMessage with assembler.blocks() → toolCalls.length === 0 → return { kind: 'completed' }. There is no text-significance check on the assembled content — reasoning-only is indistinguishable from a real answer at this layer.

② The bounded retry path already exists — EMPTY_RESPONSE is retryable by default
dsh-llm retry-policy (llm/src/retry-policy.ts:19-23): DEFAULT_RETRYABLE_CODES = [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT], maxRetries: 5, exponential backoff 500ms→10s. And agent-loop already routes finish errors through the retry waterfall: finish.kind === 'error' → dispatch.waterfall('agent/request-error', {…, retryPolicy: preparedCall?.retryPolicy}) → retry or throw (agent.ts:389-395). So the fix is to classify reasoning-only stop as an empty response; the bounded retry, budget, and backoff all come for free.

③ Two fix layers, one recommendation

• Adapter layer (pi-ai only): change the degenerate-stop check at stream.ts:98 from "no content blocks" to "no non-whitespace text block and no tool-use block". pi-ai already distinguishes block types here (text_start→text :154, thinking_start→reasoning :162-169), so it's a small predicate. But this only fixes pi-ai — every other adapter (e.g. llm-deepseek maps a missing body to EMPTY_RESPONSE but has no reasoning-only check at all) would need the same per-adapter change.
• Agent-loop layer (generic — recommended): in step(), after toolCalls.length === 0 (agent.ts:429), check whether the assembled message has any non-whitespace text block; if only reasoning (or whitespace), return an EMPTY_RESPONSE-coded error instead of completed. One change fixes every provider at once, and it sits at the layer that actually owns "deliverable" semantics. The assembler already has a content-significance precedent: interruptedBlocks() filters "text/reasoning blocks with non-whitespace content" (llm/src/assembler.ts:163-177) — the same predicate applies here.

④ Your other constraints hold naturally

• max-tokens behavior unchanged: finish.kind === 'max-tokens' returns { kind: 'max-tokens' } before the tool-call/completed check (agent.ts:423).
• The pi-ai comment at stream.ts:96 ("a terminal stop that produced no content blocks is a degenerate provider completion") is indeed the "design note" — it defines degenerate as zero blocks, which is exactly the gap: reasoning-only is content, but not a deliverable.
• One nuance for the agent-loop fix: distinguish "model genuinely stopped with reasoning only" from "text was truncated away by a max-tokens ceiling" — the latter already exits earlier (:423), so the new check can safely treat stop-without-text as empty.

Also related to the sticky turn-end family (#3685/#4048/#4431 in this repo): a false completed is the mirror image of a sticky error — both are turn-end reason misclassifications, and both deserve the same treatment: explicit classification + test at the loop boundary.