[建议] 提交等待接纳期间允许继续写下一条草稿（附可运行参考实现）

[takomitkm]

希望普通消息 A 等待 Host 接纳时，能在同一会话继续准备独立的下一条草稿 B，同时保住 A 的正文、附件和引用。图片准备、上传或接纳较慢时，这样不必停下来等输入框解锁。

这里说的是本次提交尚未被接纳的窗口。模型运行中已有的排队／插话能力不在本请求范围，也不要求移除命令确认、审批等流程的门禁。

当前行为与希望改进的地方

核对官方 master fcc0ad4：

• InputBar 在普通消息的 sending 阶段会让编辑器只读，也会限制继续添加附件。
• 接纳处理 已经做到 Host 明确接纳后立即交接、清空和解锁，不必等整个发送 Promise 结束，更不是等模型回答完。

这个锁定策略是在保护原稿，并不是说它设计错了。想讨论的是：能否在本地已有可靠副本并完成归属交接后，就把编辑器交给 B，让 A 的网络等待与下一条内容的编辑分开。

期望的行为

1. 先可靠保存，后交出编辑框。 A 的正文、富文本结构、附件和引用一起进入待发记录；保存失败时不清空、不发送。不能只把正文暂放一个内存变量就删除原草稿。
2. A 与 B 分开。 用户可以继续写 B、添加附件；A 的接纳、拒绝、超时或迟到结果，都不能清空或覆盖 B。B 何时可以提交，仍遵循现有投递策略。
3. 失败有归属，未知不盲发。 明确失败的 A 保留为可恢复条目；无法确认是否送达时，由投递协议按原消息身份核对，不自动把 A 填回编辑器诱导再次发送。本提案不假定 DSH 缺少现有的去重或回执机制。
4. 刷新、切会话与附件都要一起考虑。 待确认的 A、新草稿 B 和它们各自持有的附件不能串位、丢失或复活成错误的草稿；空 Enter／重复按键也不能额外提交 A。

可运行的参考实现

我整理了一份独立实现：takomitkm/betterharness — chat-composer。

固定版本：bad9c015。其中运行的组件是 TypeScript／React，包含真实 Lexical 编辑器；不是 DSH 的替换补丁。

里面还做了个CORE-rs 是rust版本，用rust的语言检查代替了ts中一些要靠额外测试才能做到的，那个叫什么，边界？困了

• 提交核心与事务存储：完整消息和后继空草稿在同一事务里交接；草稿有独立版本，回执只结算原消息。
• README：有运行方式、宿主协议和编辑器适配边界。npm ci 后可用 npm run demo 启动实际组件与回环 HTTP 示例宿主。
• 验证记录：25 个核心／恢复测试、21 个真实 Edge 浏览器测试通过；14 种故意引入的行为错误都被测试抓住。浏览器层包含 React StrictMode、Lexical、IndexedDB、丢回执和实际渲染器崩溃后的恢复。

这些数字只属于这份参考实现，不代表 DSH 已通过相同测试。 它与 DSH 的 Host、队列、附件和插件接口仍需适配；不建议为了此功能整体替换 DSH 的现有架构。希望先确认项目倾向的交接边界与扩展入口，再缩小成合适的改动。

与已有讨论的区别

• #3501：带图片消息挂起后输入框只读是较早版本的故障报告；本帖不声称该旧故障仍在，而是提出普通提交期间的独立新草稿能力。
• #10699：队列编辑确认丢弃后续输入处理的是排队消息行内保存的版本竞争，不是本帖的普通提交与下一条草稿交接。
• #11236：取回尚未执行的排队消息完整编辑是队列撤回方向，也不同于本帖。

发帖前检索了 successor draft、下一条草稿、等待接纳 以及 Host draft sending，未找到完全同范围的提案；如有已有讨论或更合适的插件入口，欢迎指向。

[takomitkm]

以下仅比较文本框本身的输入、编辑和草稿交互，由 GPT 根据固定版本源码整理。 对比 DSH fcc0ad4 与 betterharness 文本框 bad9c01。本轮没有新增实机对照，尚未核实的交互不直接判胜负。

只看文本框的设计

文本框交互	betterharness	DSH	设计判断
提交后继续写下一条	A 的本地可靠交接完成后，框内进入独立的新草稿 B；网络等待时仍能编辑 B	普通消息等待 Host 接纳时，原稿留在框内并只读；接纳后清空解锁	betterharness 更适合连续起草；DSH 的选择是暂时锁住原稿
框内旧文字何时消失	完成可靠交接后清空，不等待发送结果	Host 明确接纳后清空，不等待模型回答结束	关键是交接边界不同；不能误说 DSH 要等回答完才清空
连按两次 Enter	第二次空 Enter／提交等待中的 Enter 不发消息、不插换行	有提交相位保护，等待中的重复 Enter 无操作	目标相当，都不应把“暂不可发送”变成换行
正常发送与明确换行	Enter 发送，Shift+Enter 换行	同样支持发送与明确换行	基础交互相当
中文候选确认	有 isComposing／原生事件等守门；尚无原生候选窗口实测	另有 composition 生命周期、Safari compositionend 后保护	DSH 的跨浏览器处理更细；不能把合成事件测试当作原生输入法验证
发送边界与 Undo	换到后继草稿时清理历史，避免撤销把已发 A 带回 B	接纳清理时也会清 history	两边目标一致，已发内容不应通过 Undo 复活到新草稿
提交被明确拒绝后，框里显示什么	失败 A 单独保留，框里 B 不变；用户主动取回时才回填	原稿一直留在框内，拒绝后可直接修正	betterharness 更少打断新输入；DSH 改原稿更直接，属于交互取舍
恢复内容是否覆盖正在写的字	主动取回也不能覆盖非空草稿，纯空白同样算输入	已有草稿保护；接纳前通过只读限制原稿变化	独立草稿方案应严格按草稿身份处理回填，不能只比较文字是否相同
框内引用／mention 的选择	token 能显示并恢复，但当前演示按钮插入固定引用	有实际引用触发、候选与插入交互	DSH 的选择交互更实用；参考实现应接真实候选
输入 / 时的补全与确认	当前没有 slash 补全菜单	有命令菜单、选择和确认交互	DSH 这项更好；这里仅比较框内编辑交互，不讨论命令执行能力
普通文本粘贴	原生 textarea／Lexical 支持	有对应文本粘贴处理	不能把参考实现未做图片粘贴说成“不能粘贴文字”
图片／文件放进输入框组件	通过文件选择器加入	还有拖放及剪贴板接纳路径	DSH 更顺手；参考实现应补拖放和图片粘贴
附件在输入区的呈现	当前主要是文件名、大小与移除按钮	有附件展示、图片预览等接点	DSH 的视觉反馈更丰富；这不等于已经支持任意图文混排
图片／文件与文字的框内顺序调整	当前没有任意图文混排与拖动调位	已核对的默认输入框也未见完整的自由调位流程	两边都可改进，需求见 #12506
光标、选区、长文滚动与焦点	有基础编辑器行为；没有做与 DSH 同条件的完整交互对照	已读代码有选区可见性和移动焦点等处理	暂不判谁更好；应验证输入不跳光标、回填不抢焦点、长文不乱滚动

文本框本身值得保留或改进的设计

我更倾向的连续输入设计是：只在本地可靠交接的一小段时间保护旧草稿；交接后立即开放独立的新草稿，后续结果不再改动正在编辑的内容。 失败内容由用户主动取回，不能自动覆盖新输入。这个选择不等于要求 DSH 简单删除只读判断。

参考实现应吸收 DSH 在输入法边界、候选菜单、附件拖放／粘贴和预览方面的细节；DSH 可讨论本帖的独立后继草稿。双方都应把“光标与选区不跳、焦点不被异步变化抢走、Undo 不跨草稿、附件和引用不因回填丢失”作为文本框交互约束。

建议的文本框验收场景：

• 输入 A 并提交，接着输入 B；A 的结果晚到时，B、光标和选区保持不变。
• 连按 Enter 与按住 Enter 都不多发、不制造多余换行；明确换行正常。
• 输入法组合、候选菜单确认和发送键按优先级处理，不能互相误触。
• 新草稿的 Undo 只作用于新草稿，不能把已发 A 带回来。
• 带附件／引用的内容恢复时保持结构；已有文字或纯空白时不能被覆盖。
• 长文本、粘贴、多行编辑和异步回填不导致跳光标、抢焦点或意外滚动。

源码依据：DSH InputBar、DSH 输入与接纳清理、DSH keymap、参考文本框与编辑器。