[QAyong]

背景与关联 / Context and related issue

• 为什么要做：现有“任务引用 / 任务 ID / 标题”只能复制定位信息，无法将对话和工具日志交给其他 Agent 继续排查。新增一次复制当前分支为 Markdown 的入口，减少逐条复制消息和截图的操作。
• 关联 Issue：N/A。

主要改动 / Changes

• 做了什么：在侧栏和会话顶部共用的“复制”子菜单中增加“复制为 Markdown”，将分隔线放在“任务引用”下方；保留原有三个复制动作的载荷。
• 固定目标会话与活动分支，分页读取完整可读取历史，不依赖界面已经加载的消息；同一运行保留首次取得的公开事件快照，去重消息与工具输出。
• 复用已有消息和工具过程投影，导出双方消息、过程说明、命令、输出、错误、模型和状态，恢复终端增量与尚未持久化的公开回复。
• 附件、本地文件引用和结果文件只列元数据；选区引用只取已保存文字。不递归读取被引用会话，不读取附件内容，不调用模型，不上传。
• 排除隐藏思考、内部工具消息、上下文压缩总结正文、预览 URL 和内部事件包。保留来源截断、中断和失败标记，动态选择代码围栏长度，避免日志中的反引号破坏排版。
• 共享导出忙状态；提供整理中、成功、失败和超限反馈。设置 16 MiB 最终文本与 64 MiB 累计读取预算，异常或超限不复制半份内容。
• 新增中英文文案及 25 项定向测试；无新依赖、无迁移。本 PR 只包含此功能代码和测试，不包含下游品牌定制或私有文档。

验证 / Verification

• 自动检查：下游实现阶段桌面端类型检查、改动范围 ESLint 通过；6 个相关测试文件共 48 项通过，其中新增格式化 10 项、分页与状态 10 项、菜单 5 项，相关回归 23 项。分隔线位置调整后，菜单 5 项测试和相关 ESLint 再次通过。
• 手动验证：Windows 开发版预览由用户确认通过，包含将菜单分隔线调整到“任务引用”下方后的验收反馈。未将此确认扩写为所有大数据场景均已实测。
• 未执行：本上游分支未重新安装依赖或运行本地类型检查 / 测试，以上自动化证据来自下游实现阶段；上游适配后的验证以本 PR 的 CI 为准。未执行全量测试、Playwright E2E、打包，未测真实超长会话的耗时和内存峰值。

兼容与风险 / Compatibility and risks

• 不改变既有消息、草稿和分支数据，不新增权限或底层日志读取，也不改变会话引用协议。
• 当前分页接口不提供原子事务快照；导出固定分支并保留每轮首次读取的公开快照，运行中的内容可能在导出后继续变化，文档头部会说明该限制。
• 工具展示输出可能在来源处已经截断或脱敏，不能视为完整原始日志导出。
• 剪贴板可能包含正文中的敏感业务内容和路径，不保证自动脱敏；导出头部提示分享前检查。
• 建议重点审阅分页去重、运行中消息恢复与终端增量、隐藏数据排除，以及大会话保护边界。

界面变更 / UI changes

菜单结构如下，暂未附截图：

复制
  任务引用
  ────────────
  任务 ID
  标题
  复制为 Markdown

[shanyuhai123]

这个我仔细思考了下，这部分不适合放入主线，维护成本高，需要考虑的边界高，我自己经常都有 2亿+ tokens消耗的对话。还很多不是 deepseek 那种雷霆思考。复制太容易爆剪切板内存之类的了。不如考虑作为“导出markdown”插件，图片等其他资源也不用混入md文件，也可以作为纯后台任务...

如果这部分只是简化为正文的复制支持 markdown 倒是很好的选择。

[shanyuhai123]

感觉直接在另一对话直接 @ 对应对话，让其整理保存为 md 感觉都更理想一点

[QAyong]

这个我仔细思考了下，这部分不适合放入主线，维护成本高，需要考虑的边界高，我自己经常都有 2亿+ tokens消耗的对话。还很多不是 deepseek 那种雷霆思考。复制太容易爆剪切板内存之类的了。不如考虑作为“导出markdown”插件，图片等其他资源也不用混入md文件，也可以作为纯后台任务...

如果这部分只是简化为正文的复制支持 markdown 倒是很好的选择。

干脆为改造成导出压缩包

[QAyong]

感觉直接在另一对话直接 @ 对应对话，让其整理保存为 md 感觉都更理想一点

加一个判断，少的是md文件，大的就是导出的压缩包