维护者确认：划词引用支持评论

[MagicLizi]

这次改动给划词引用增加 comment 能力，会改变用户看得见的引用 chip / 选择引用按钮和写入 composer 的内容。

请维护者确认「引用时附带评论」是否是要上的产品能力，以及桌面与移动是否应对齐。

确认方式：直接在 PR 上 Approve；需要修改就 Request Changes，作者改完后再 Approve 即放行。

---

关联 PR:#3701(作者 @MaxxxDong);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的产品 / UI 变更,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断：划词引用附带评论具备清晰的用户价值，建议继续推进；桌面与移动应对齐同一引用语义，但当前 PR 仍不满足直接合并条件。请先在 #3701 Request Changes，完成协议、会话边界和 UI 证据补齐；修复并重新验证后，由维护者确认产品意图，再 Approve。

已确认的现状

当前 main 快照 865ccfb25ddc62c87ea9785384214cd5512bd6cf 已有“选中文字 → 添加到对话”的引用能力，但没有评论字段：

• packages/maker-shared/src/chatQuotes.ts:25 的 ChatQuote 仅包含 text、可选 sourcePath、startLine、endLine。
• apps/desktop/src/renderer/components/chat/SelectionQuoteButton.tsx 在提交时只将选中文本及文件来源/行号写入草稿，没有评论输入流程。
• apps/desktop/src/renderer/components/chat/QuoteChip.tsx 的 chip 与 tooltip 展示引用原文和来源，不展示评论。
• Mobile 已具备引用选区菜单、引用暂存、发送序列化和引用 chip，但当前共享模型和 Mobile 文档比较/归一化逻辑同样没有 comment：apps/mobile/src/session/selectionQuote.ts 的提交接口只有文本，apps/mobile/src/session/composerDocument.ts 的 quote 比较只比较文本和来源字段，apps/mobile/src/session/chatQuoteStore.ts 的存储校验也未处理评论字段。

因此，这不是已有功能的重复报告，而是一次真实的产品能力扩展；PR #3701 的改动范围也确实覆盖共享引用协议、Desktop composer、Mobile composer、文案和测试。

对 #3701 的判断

PR 描述的产品路径是：用户选择文本后打开“评论”入口，输入注释，再把“评论 + 原文”作为一个引用 atom 插入 composer；发送时通过引用协议编码，恢复历史消息时再解析，chip 侧显示评论和原文。这个方向可以支持更精确的提问、代码审查和文件修改上下文，值得继续推进。

但 PR 仍是 open、未合并状态，且公开讨论中有三类需要处理的具体问题：

1. 多行评论的编码边界：PR 的自动 review 指出，若评论允许 Shift+Enter，现有编码方式可能只给首行加引用前缀，导致后续行脱离评论并混入正文。该问题直接影响用户可见内容和发送语义，应补充多行、空行、尾随换行的往返测试，不能只验证单行评论。
2. 协议前缀歧义：PR 使用 — comment: 作为元数据行。需要证明引用原文自身包含该前缀（包括空值、末行、多行组合）时不会被错误识别、吞掉或改写。当前共享协议已经为产品引用引入 <!-- cindy-composer-quote --> marker，建议沿用同样的“结构边界优先”思路，而不是增加无条件的文本前缀猜测。
3. 会话切换后的旧选区：评论框打开后，如果文件浏览器或聊天视图切换 session，再提交可能把旧选区组合到新 session 的草稿。应让评论状态绑定创建时的 session/来源上下文；上下文失效时取消提交或重新要求选择，不能静默写入另一会话。

此外，PR 讨论中仍有未 resolve 的 review conversation，且 UI review 已要求补充截图、录屏或改动后的 HTML 页面。由于本次变化会改动选择入口、引用 chip 和 composer 内容，补充可见效果证据是合并前必要的产品验收材料。

桌面与移动对齐建议

建议确认“能力对齐、交互可平台化”：

• 两端共享同一 ChatQuote.comment 可选字段、序列化/解析规则、历史恢复语义和评论展示含义。
• Desktop 可以使用选区上方的评论输入浮层；Mobile 沿用系统选择菜单入口，再进入适合触屏的评论输入界面。交互控件不必像素级一致，但用户最终看到的引用 chip、发送内容和历史恢复应一致。
• 不建议在没有产品确认的情况下限制评论只能单行，也不建议因为当前 Mobile 入口尚未具备就取消该能力；这些属于待确认的交互取舍。若产品决定暂不支持多行，应在 UI 中明确限制并配套测试，而不是让协议静默截断。

建议行动与验收

1. 维护者现在对 feat(chat): add comment support for selection quotes #3701 Request Changes：原因不是否定能力，而是当前公开记录显示协议边界、会话绑定和 UI 证据尚未闭环。
2. 作者修复并 resolve review：至少覆盖单行、多行、内部空行、空评论、评论含 — comment:、引用正文含同名文本、多个引用交错、历史恢复和发送失败恢复。
3. 补齐两端行为测试：Desktop 选择/评论/QuoteChip/composer 序列化；Mobile 选择菜单、草稿持久化、composerDocumentsEqual、发送和历史恢复；验证旧的无评论引用仍可读，旧客户端遇到新增字段时不会丢失正文或崩溃。
4. 补充 UI 验收证据：Desktop 与 Mobile 的入口、评论编辑态、带评论 chip、长评论、Light/Dark，以及五种语言文案；确认评论不会遮挡选区、不会因选区塌缩而误关闭，也不会跨 session 提交。
5. 合并前产品确认：维护者明确“引用时附带评论”是要发布的能力，并明确两端采用上述语义对齐方案。确认完成且定向测试和 UI 证据通过后，再在 feat(chat): add comment support for selection quotes #3701 Approve。

相关记录

• #3701：当前能力的实现 PR，直接包含本 Issue 所讨论的评论入口、引用协议和 Desktop/Mobile 传递改动；目前仍 open，且有未闭合的 review 事项。
• #3203 / #3200：此前为 QuoteChip 增加草稿引用删除入口的产品确认流程，说明引用 chip 的可见交互变化通常需要维护者明确确认；它不决定本次评论能力的产品意图，只提供流程上的直接先例。