Gateway 消息响应

Gateway 优先使用渠道支持的结构化消息回复原始线程；不支持结构化消息的渠道退化为等价文本。响应不是终端日志转储，而是 Workbench 审查后的阶段性结论。公开文档不展示真实公司聊天环境、联系人、群组或水印截图。

三阶段反馈

请求进入工作台

“⏳ 小塔 · 请求已进入工作台”只表示请求已经持久化并交给 Workbench：

展示项目与当前编排阶段；
明确任务尚未创建；
附带请求 ID，便于诊断。

任务已创建

“🚀 小塔 · 任务已创建”使用紧凑的两列字段网格：

状态、优先级；
项目、工作区；
执行方式、分支；
任务目标单独成节；
底部展示真实 Tower task ID。

原始枚举会转为可读文本，例如 IN_PROGRESS 显示为“执行中”，LOW 显示为“🔵 低”，没有独立分支时显示“默认工作树”。

任务已完成

“✅ 小塔 · 任务已完成”把内容分成：

Workbench 审查后的验收结果；
代码提交和分支元数据；
与创建卡片一致的 Tower task ID。

没有提交时显示“无提交”，不会展示 none No commit recorded 等内部占位符。

投递契约

必须以原平台消息为 parent，不发送无引用的新消息。
结构化 payload 在发送前写入 Outbox。
每种语义使用稳定去重键，重试不会重复发送。
只有平台回执确认预期消息类型和正确 parent，才记为成功。
平台不支持结构化消息时才降级为等价文本。

设计原则

首屏只展示用户做判断需要的信息。
状态和风险优先于内部实现字段。
长目标与长结果独立成节，避免与元数据混排。
终端输出属于证据，不直接充当最终回复。
请求 ID、任务 ID 保留在弱化的底部上下文中，便于排查但不抢占视觉焦点。
真实渠道只用于私下验收；公开资产使用脱敏示意或自动化契约结果。