带图片消息发送挂起后，输入框永久只读（readOnly），只能刷新页面恢复

[imtone]

现象

• 在某个含图片的会话中发送消息后，输入框区域出现异常：输入框还在、能点击、光标可见，但敲键盘完全没反应（textarea 处于只读状态）。
• 草稿里的图片附件和已发送/待发送的对话内容一直显示在输入框区域，发送按钮也失效。
• 没有任何提示文字，也没有任何逃生出口；只有按 F5 刷新页面才能恢复。

环境

• 本地源码构建：DSH Local Build（commit 141eb6f / dsh-0.1.0-rc.8）
• Windows + 浏览器 Web GUI（http://127.0.0.1:3080）

根因分析（代码层面）

输入框的只读锁定来自输入机器（input machine）卡在 submitting / adjudicating 阶段：

1. packages/client/ui-conversation/src/client/skeleton/InputBar.tsx L667：
   readOnly={machineBusy || workspaceTrigger}，其中 machineBusy 即 phase 为 submitting/adjudicating。
2. packages/client/ui-conversation/src/client/input/machine.ts onEnter()：提交时把 phase 置为 submitting（或 adjudicating），此后只有 submit-settled / adjudication-failed（或 release）事件才能回到 plain。
3. 带图片的消息走 default-sink(draft, imageIds, ...)：如果这次 host round-trip / 图片上传永远不返回（RPC 挂起、响应丢失等），flight 永不 settle，机器就永久锁死。beginAttempt() 创建的 AbortController 没有任何超时触发。
4. 该机器状态是纯前端内存态、不落盘，刷新后重建，所以 F5 能恢复。

复现（推断路径）

发送一条带图片的消息，且该次发送的 RPC 未在合理时间内返回（例如 agent 忙碌、上传卡住、连接异常）→ 输入机器停在 submitting → 输入框永久只读，且无提示、无解锁入口。

建议

1. 为提交 flight 加超时：超时后 abort 并以失败 settle，弹 toast 提示用户重试。
2. 提供一个逃生动作：卡住时允许用户取消/放弃本次提交，将机器重置回 plain。
3. 在非运行中但机器卡在 submitting 且无在途活动时，显示恢复提示而非静默只读。

---

English summary: In a conversation with image attachments, after a send whose host round-trip never settles, the input machine stays in submitting phase forever, leaving the composer textarea permanently readOnly (InputBar.tsx L667, machine.ts onEnter). No timeout or escape hatch exists; only a page reload recovers. Suggest adding a submit-flight timeout with abort+settle, and/or a user-facing "cancel pending send" affordance.

[denial123789]

I verified this path against rc.8 (141eb6f). The important details are:

• Enter creates one attempt and changes the input machine to submitting; the textarea projects that busy phase as readOnly.
• The phase returns to plain only through the sequence-owned submit-settled path or shell release.
• The facade settles only when the sink Promise resolves or rejects.
• The attempt has an AbortController, but beginAttempt() creates no deadline. Image arrayBuffer() and base64 serialization also happen before session.prompt(..., signal) and do not receive that signal.

So an AbortController exists, but the complete image-send flight is not bounded. Reload recovers because it releases/recreates the in-memory input shell; it does not prove Host admission failed.

For operators, the safe sequence is: stop repeated Send attempts, capture data-phase and Network/RPC evidence, check whether the durable user message or queued turn already exists, copy recoverable draft text, reload once, then retry only if Session truth proves the original prompt was not accepted. A lost acknowledgement after acceptance can otherwise become a duplicate prompt.

For the runtime, the deadline should cover serialization plus Host admission, settle the exact attempt through the existing sequence guard, retain draft/images on uncommitted failure, expose Cancel pending send, and reconcile unknown admission outcomes before enabling Retry. Late completions must remain unable to clear a newer draft.

I wrote the full runbook, deterministic test matrix, and fifteen acceptance gates here:
https://sandbaseai.github.io/deepseek-harness-handbook/image-send-readonly.html

[imtone]

补充：官方版（dsh web / official profile）同样复现 ✅

今天在官方版上再次测试「文字 + 图片」消息发送，表现与本地构建完全一致：

• 发送后，输入框里那条消息（文字 + 图片附件）一直作为草稿保留在输入区，不消失（截图证据：发送完成后输入框仍显示该条文字草稿，图片仍在附件栏）。
• 会话看起来卡在"已发送图片"的状态：agent 回复不出现、状态不推进，发送按钮失效。
• 按 F5 刷新后才恢复：草稿消失、回复正常出现、可以继续输入。

初步推断与之前一致：客户端提交事务（submit flight）没有 settle，草稿未被 commit 清除，输入机器卡在 submitting 阶段（InputBar.tsx L667 readOnly={machineBusy || workspaceTrigger}；machine.ts onEnter 后仅 submit-settled/adjudication-failed 可回 plain），且无超时、无逃生出口。刷新重建前端内存态后恢复。

结论：该问题与构建类型无关，是 Web 客户端的通用缺陷，带图发送场景必现或高概率触发。建议尽快：1) 提交 flight 加超时（abort + 失败 settle + toast）；2) 提供"取消待发送"逃生动作；3) 卡住时显示恢复提示而非静默只读。