桌面聊天交互图的“发送修改”将设计控件选择完整显示在确认窗口，但点击“发送”后，实际构建的选择文本仅保留序列化 JSON 的前 16,000 个字符。超过这个长度时，确认内容与发送内容不同，后面的选择会丢失，JSON 片段还可能在字段中途结束。没有提示哪些内容未发送。
证据层级：2026-09-30 在 react-test-renderer 中加载完整原 ChatVisualization 组件，保留原 React hooks、消息接收、控件入列、设计调整入口、确认内容和发送 callback；Button/Dialog、DOM/frame 和 API 仅使用语义 mock。使用同一个合成 frame 提供合法 select 控件，不执行任何 iframe 脚本或实际请求。原组件最多接受 144 个控件，额外第 145 个被拒绝，group/label 均在原 120 字符限制内。随后通过原“调整设计”→“发送修改”→“发送”callback 检查结果：确认窗口保留全部 144 项及最后一项；完整 JSON 为 42,918 字符，sendConversationCommand 接收到的选择片段只有 16,000 字符，最后一项缺失，该片段无法独立解析为 JSON。12 控件对照的 3,582 字符完整保留且可解析。原源码哈希前后一致，两份关键源码也与公开 ca65724 字节一致。
这不是实际 Electron/浏览器或真实聊天发送复现。未连接 Provider、后端或用户存储，未验证模型是否报错、如何解释片段或最终任务效果。外层 typed command 的 JSON body 未被证明损坏；被截短的是 text 内嵌的设计选择 JSON。完整输入、确认文本、精确传给 mock 的命令参数和输出只保存在本地忽略目录，公开材料不含私有聊天或截图。
widgetState 的 16 KiB 保护不能覆盖这个入口：setWidgetState 与 host state-write 都检查状态的 UTF-8 字节数，而“发送修改”直接从最多 144 个独立 Tweak 控件生成 modelContent，不经过 widgetState 存储。这次合法控件列表就是从该入口进入确认窗口。控件数量和标签限制仍然有效，问题是确认后又发生未声明的字符级裁切。
优先级与影响：P2 消息保真问题。用户批准了完整选择，模型输入却只包含一段前缀；设计调整可能遗漏后面的选项。JSON 片段不完整是合成结果已确认的文本事实，不等同于已证明后端拒绝、模型执行失败或不可恢复的数据损坏。
源码定位：
apps/web/ui/components/chat/markdown/ChatVisualization.tsx:94-100：标签限制及最多 144 个控件。ChatVisualization.tsx:149：“发送修改”直接将 controls 映射为 followup.modelContent。ChatVisualization.tsx:159：确认窗口展示完整 modelContent。ChatVisualization.tsx:135-136：发送前 .slice(0, 16000) 截短序列化内容。apps/web/ui/components/chat/markdown/visualizationBridge.ts:18-22 与 ChatVisualization.tsx:84-88：另一个 widgetState 通道的 16 KiB 保护。
桌面融合方案：由桌面图表 follow-up adapter 构建与确认窗口相同的完整结构化选择，禁止在用户确认后静默裁切。若传输或上下文容量无法承载，明确拒绝并显示可修正的原因，或将完整选择保存为稳定、可读取的 artifact 并在确认时说明其提交方式；被选中的对象要完整保留。维持现有控件/schema/状态预算和用户确认，避免只降低控件数量掩盖发送契约缺口。本轮不修改源码，登记桌面 renderer/adapter 的保真合同与验收；共享 Web 源码作为成因定位，不扩大到 Web 功能改造。
验收：小列表和原合法大列表的确认内容与提交内容语义一致，最后一项仍可达；以 JSON 传递时保持完整可解析。无法提交时在发送前给出 typed error，不能成功后只交付前缀。完整 artifact 方案必须验证稳定引用及完整原文可读。仅用合成控件与 mock/隔离 profile 验证，不使用真实聊天、凭据或 Provider 效果代替保真检查。
去重：#61 是迟到发送清理删除已修改的草稿引用；本条是图表确认内容与提交文本之间的裁切。#37 是通知样式与生命周期，#67 是审批跨视图重复受理，均不是该消息构建根因。文档隔离的 #66 也不替代此保真修复。关联 桌面聊天融合 Epic #31。
公开固定源码：ChatVisualization、状态预算对照。实际逻辑验证以本地原组件和 mock 产物为准，不声称公开发行包已运行。
桌面聊天交互图的“发送修改”将设计控件选择完整显示在确认窗口，但点击“发送”后，实际构建的选择文本仅保留序列化 JSON 的前 16,000 个字符。超过这个长度时，确认内容与发送内容不同，后面的选择会丢失，JSON 片段还可能在字段中途结束。没有提示哪些内容未发送。
证据层级：2026-09-30 在 react-test-renderer 中加载完整原 ChatVisualization 组件，保留原 React hooks、消息接收、控件入列、设计调整入口、确认内容和发送 callback；Button/Dialog、DOM/frame 和 API 仅使用语义 mock。使用同一个合成 frame 提供合法 select 控件，不执行任何 iframe 脚本或实际请求。原组件最多接受 144 个控件，额外第 145 个被拒绝，group/label 均在原 120 字符限制内。随后通过原“调整设计”→“发送修改”→“发送”callback 检查结果：确认窗口保留全部 144 项及最后一项；完整 JSON 为 42,918 字符，sendConversationCommand 接收到的选择片段只有 16,000 字符，最后一项缺失，该片段无法独立解析为 JSON。12 控件对照的 3,582 字符完整保留且可解析。原源码哈希前后一致，两份关键源码也与公开 ca65724 字节一致。
这不是实际 Electron/浏览器或真实聊天发送复现。未连接 Provider、后端或用户存储，未验证模型是否报错、如何解释片段或最终任务效果。外层 typed command 的 JSON body 未被证明损坏；被截短的是
text内嵌的设计选择 JSON。完整输入、确认文本、精确传给 mock 的命令参数和输出只保存在本地忽略目录，公开材料不含私有聊天或截图。widgetState 的 16 KiB 保护不能覆盖这个入口：
setWidgetState与 host state-write 都检查状态的 UTF-8 字节数，而“发送修改”直接从最多 144 个独立 Tweak 控件生成 modelContent，不经过 widgetState 存储。这次合法控件列表就是从该入口进入确认窗口。控件数量和标签限制仍然有效，问题是确认后又发生未声明的字符级裁切。优先级与影响：P2 消息保真问题。用户批准了完整选择，模型输入却只包含一段前缀；设计调整可能遗漏后面的选项。JSON 片段不完整是合成结果已确认的文本事实，不等同于已证明后端拒绝、模型执行失败或不可恢复的数据损坏。
源码定位：
apps/web/ui/components/chat/markdown/ChatVisualization.tsx:94-100：标签限制及最多 144 个控件。ChatVisualization.tsx:149：“发送修改”直接将 controls 映射为 followup.modelContent。ChatVisualization.tsx:159：确认窗口展示完整 modelContent。ChatVisualization.tsx:135-136：发送前.slice(0, 16000)截短序列化内容。apps/web/ui/components/chat/markdown/visualizationBridge.ts:18-22与ChatVisualization.tsx:84-88：另一个 widgetState 通道的 16 KiB 保护。桌面融合方案：由桌面图表 follow-up adapter 构建与确认窗口相同的完整结构化选择，禁止在用户确认后静默裁切。若传输或上下文容量无法承载，明确拒绝并显示可修正的原因，或将完整选择保存为稳定、可读取的 artifact 并在确认时说明其提交方式；被选中的对象要完整保留。维持现有控件/schema/状态预算和用户确认，避免只降低控件数量掩盖发送契约缺口。本轮不修改源码，登记桌面 renderer/adapter 的保真合同与验收；共享 Web 源码作为成因定位，不扩大到 Web 功能改造。
验收：小列表和原合法大列表的确认内容与提交内容语义一致，最后一项仍可达；以 JSON 传递时保持完整可解析。无法提交时在发送前给出 typed error，不能成功后只交付前缀。完整 artifact 方案必须验证稳定引用及完整原文可读。仅用合成控件与 mock/隔离 profile 验证，不使用真实聊天、凭据或 Provider 效果代替保真检查。
去重：#61 是迟到发送清理删除已修改的草稿引用；本条是图表确认内容与提交文本之间的裁切。#37 是通知样式与生命周期，#67 是审批跨视图重复受理，均不是该消息构建根因。文档隔离的 #66 也不替代此保真修复。关联 桌面聊天融合 Epic #31。
公开固定源码：ChatVisualization、状态预算对照。实际逻辑验证以本地原组件和 mock 产物为准，不声称公开发行包已运行。