docs: record native channel merge validation

docs/方案/渠道原生能力建设方案.md

@@ -4,9 +4,9 @@
 
 | 项目 | 内容 |
 | --- | --- |
-| 状态 | 执行版 v3；PR 链 1 已随 v1.1.0 发布，九渠道普通文件入站已随 v1.3.0 发布；PR 链 2、3 尚未实现，基线与测试清单已刷新 |
+| 状态 | 执行版 v4；PR 链 1 已随 v1.1.0 发布，九渠道普通文件入站已随 v1.3.0 发布，九渠道原生图片交付已随 v1.5.0 发布；PR 链 2、3 已分别通过独立分支验证并合入 `main`。合并后 Discord Thread、免 @ 续聊和原生图片真机通过；Telegram 12.9 的 Rich 结构化回答及 Rich + 原生文件混合交付真机通过。现有账号没有群聊/Topic 会话的部分仍明确保留为未验收 |
 | 更新日期 | 2026-08-24 |
-| 代码基线 | `@xmanrui/dsh-im@1.4.0`、`main@1d7f6a5`；本机 `npm run check` 1036/1036 通过，构建与发布包校验通过 |
+| 代码基线 | 发布父基线 `v1.5.0@3ff8c2a`；PR 链 2、3 合并代码为 `main@a5c516a`，2026-08-24 实跑 `npm run check` 1129/1129，构建与发布包校验通过 |
 | 适用范围 | 九个 IM 渠道；AI Office Connector 作为相邻消费者纳入回归边界，但不算第十个 IM 渠道 |
 | 需求入口 | [#16 发送文件](https://github.com/xmanrui/dsh-im/issues/16)、[#27 Discord 自动创建 Thread](https://github.com/xmanrui/dsh-im/issues/27)、[#28 Telegram Rich Message](https://github.com/xmanrui/dsh-im/issues/28) |
 | 领域语言 | [CONTEXT.md](../../CONTEXT.md) |
@@ -59,16 +59,17 @@ dsh-im 已经是一个具有九渠道多机器人管理、工作区与 Session
 
 ## 3. 当前基线与问题定义
 
-### 3.1 v1.4.0 当前发布产品能力
+### 3.1 v1.5.0 当前发布产品能力
 
 以下能力是当前发布产品的基线，不是未来路线图：
 
-| 基线类别 | v1.4.0 当前行为 |
+| 基线类别 | v1.5.0 当前行为 |
 | --- | --- |
 | 渠道与账号 | 一个设置入口管理九个 IM 渠道；每个渠道支持多个机器人，凭据、连接状态、工作区、Agent Preset 和会话映射彼此隔离 |
 | 安全接入 | 扫码、Manifest 或手工凭据接入；Secret/Token 只进入 Host 凭据存储，浏览器和状态 RPC 只获得脱敏投影 |
 | 消息输入 | 九渠道均支持文字、受控图片和普通文件输入；图片维持既有格式与大小规则，普通文件由渠道原生下载后原样写入当前 Session 工作区，由 Harness 决定是否读取和如何处理 |
 | 文件交付 | 九渠道均可接收用户普通文件并在同一 Turn 保持文件名与顺序；Harness 可通过全局 `dsh_im_return_file` 将现有或新建普通文件作为渠道原生附件回传 |
+| 图片交付 | `dsh_im_return_file` 返回 `image/*` 时，九渠道均优先使用现有平台原生图片路径；确定性失败才复用既有文件附件降级，不增加配置、白名单或双消息补发 |
 | Harness 会话 | 按机器人与聊天持久绑定 Session；支持工作区切换、Session 列表与绑定、模型查询与切换、停止、纠偏和上下文压缩 |
 | Agent Preset | 每机器人独立选择或跟随 Host 默认；只影响之后新建 Session，不改变已有会话和在途回复 |
 | 控制命令 | `/help`、`/new`、`/status`、`/models`、`/model`、`/presetlist`、`/preset`、`/stop`、`/steer`、`/compact`、`/workspace`、`/workspacelist`、`/sessionlist`、`/session` |
@@ -87,14 +88,15 @@ AI Office Connector 也已实现 `office-harness.v1`、Heartbeat/SSE、任务租
 
 因此，当前问题不是“没有公共层”，也不再是“没有文件能力”，而是 **Discord 会话路由仍没有原生 Thread 落点，Harness 输出仍没有保留可供 Telegram 富渲染的呈现意图**。后续必须复用成熟的会话、命令、交互、文件和安全实现，只在 #27、#28 需要的位置增加最小语义接缝。
 
-### 3.3 从 0.14 到 v1.4.0 的迭代已经改变迁移前提
+### 3.3 从 0.14 到 v1.5.0 的迭代已经改变迁移前提
 
-旧方案形成时使用的是 0.14 附近的代码认知；本方案初次盘点使用 `main@59ed364`，PR 链 1 开始前的父基线为 `main@2803bbc`。这些提交只作为历史起点保留，**当前实施基线已经更新为 `v1.4.0@1d7f6a5`**。此后至少完成了：
+旧方案形成时使用的是 0.14 附近的代码认知；本方案初次盘点使用 `main@59ed364`，PR 链 1 开始前的父基线为 `main@2803bbc`，PR 链 2、3 首轮实现使用 `main@dbc0a4b`。这些提交只作为历史起点保留。**当前发布与提交基线是 `v1.5.0@3ff8c2a`。** 此前至少完成了：
 
 - v1.1.0：全局结果文件工具、Session/Turn 快照完整性和九渠道原生结果文件发送。
 - v1.2.0：WhatsApp 访问模式等渠道能力继续演进。
 - v1.3.0：九渠道普通文件原生接收、当前 Session 工作区交接和真实客户端验收。
 - v1.4.0：QQ Markdown 与 Turn Feed 收敛，并继续强化交付消息去重。
+- v1.5.0：九渠道原生图片交付落地，复用现有 `OutboundArtifact`、渠道图片 API 和确定性文件降级；完整门禁增至 1089/1089。
 - 既有飞书专属能力、每机器人 Agent Preset、Telegram 命令菜单与访问模式、AI Office Connector，以及工作区/Session/命令/问题审批的竞态与失败恢复测试全部继续保留。
 
 这意味着 `TextHarnessBridge`、各渠道独立 Bridge、普通文件管线和产物交付管线都是生产资产。迁移不以“新增一套新目录后替换旧类”为目标，而以 **能力切片内的增量包裹、明确回退和等价接管** 为目标。
@@ -115,8 +117,8 @@ AI Office Connector 也已实现 `office-harness.v1`、Heartbeat/SSE、任务租
 | Issue | 用户任务 | 统一语义最小增量 | 渠道原生实现 | 优先级 |
 | --- | --- | --- | --- | --- |
 | [#16 发送文件](https://github.com/xmanrui/dsh-im/issues/16) | 在当前聊天直接收到 Harness 要交付的现有或新建文件；首个确认场景是 DSH → 飞书的 HTML/文件回传 | 全局 `dsh_im_return_file`、Session/Turn 路由、`OutboundArtifact` 快照完整性和逐产物回执 | 已从飞书闭环扩展到默认可用的九渠道原生文件发送；格式、大小、权限和配额由渠道 API 决定 | P0：已随 v1.1.0 发布并纳入当前回归基线 |
-| [#27 Discord 自动创建 Thread](https://github.com/xmanrui/dsh-im/issues/27) | 在服务器频道 @ 一次开启独立对话，避免多人上下文串线和主频道刷屏 | `ConversationRoute.threadId`、最终会话落点和幂等路由；原始父消息 ID 只留在 Discord 动作上下文 | 查询 Channel 类型，按父频道创建 Public/Announcement Thread 并在线程内回复；建路由前的确定性失败回到父频道现有路径 | P0：正确性与隔离 |
-| [#28 Telegram Rich Message](https://github.com/xmanrui/dsh-im/issues/28) | 在 Telegram 中正确阅读标题、列表、代码、表格、公式和流式 AI 回答 | `DeliveryBlock(text.format)` 与呈现意图；不引入 Telegram 专属 Block 到核心 | `sendRichMessageDraft`、`sendRichMessage`，再降级到普通格式消息和纯文本 | P1：结果可读性 |
+| [#27 Discord 自动创建 Thread](https://github.com/xmanrui/dsh-im/issues/27) | 在服务器频道 @ 一次开启独立对话，避免多人上下文串线和主频道刷屏 | 复用现有 `conversationId`、`replyTarget` 和 Session 键，只增加“最终 Thread 落点”与受管 Thread 寻址接缝；原始父消息 ID 只留在 Discord 动作上下文 | 查询 Channel 类型，按父频道创建 Public/Announcement Thread 并在线程内回复；建路由前的确定性失败回到父频道现有路径 | P0：正确性与隔离 |
+| [#28 Telegram Rich Message](https://github.com/xmanrui/dsh-im/issues/28) | 在 Telegram 中正确阅读标题、列表、代码、表格、公式和流式 AI 回答 | `DeliveryBlock(text.format)` 与呈现意图；不引入 Telegram 专属 Block 到核心 | `sendRichMessageDraft`、`sendRichMessage`，确定性失败时复用当前普通文字路径 | P1：结果可读性 |
 
 #16 正文只有 `todo`，但 2026-08-20 至 2026-08-21 的 Issue 讨论已明确确认 DSH → 飞书 HTML/文件回传是本 Issue 的目标场景。本方案因此将其限定为 **出站结果产物回传**；用户向 Harness 发送普通文件不属于 #16，但该独立能力也已经随 v1.3.0 在九渠道发布。#27 和 #28 只增加闭环所需的最小语义，不要求其他八个渠道复制 Discord Thread 或 Telegram Rich Message UI。
 
@@ -260,7 +262,7 @@ flowchart LR
 
 - 平台事件 → 语义消息、语义交互响应或生命周期事件。
 - 语义输出 → 卡片、按钮、附件、流式更新或文字降级。
-- 在渠道策略明确要求时执行渠道原生动作，例如从 Discord 父消息创建 Thread；动作完成后只把最终 `ConversationRoute` 交给语义核心。
+- 在渠道策略明确要求时执行渠道原生动作，例如从 Discord 父消息创建 Thread；第一阶段把最终 `conversationId`/`replyTarget` 交给现有语义核心，后续确有跨渠道复用需求时再提升为完整 `ConversationRoute`。
 
 适配器可以保留一个仅供本渠道后续发送使用的不可序列化路由句柄，但不能让平台原始 payload 进入 Harness 核心。
 
@@ -775,7 +777,7 @@ thinking → tool-running* → answer-updating* → completed | stopped | failed
 
 ## 14. 当前九渠道能力基线
 
-下表以 `v1.4.0@1d7f6a5` 为当前发布行为基线。九渠道均已具备普通文件输入和结果文件原生回传；具体发送路径及平台限制见 3.7，入站职责边界见 9.1 和 12.2。平台能力仍可能变化，表中“文字”表示 Harness 交互目前依赖现有安全文字状态机，不表示功能缺失。
+下表以 `v1.5.0@3ff8c2a` 为当前提交行为基线。九渠道均已具备普通文件输入、结果文件原生回传和结果图片原生呈现；具体发送路径及平台限制见 3.7，入站职责边界见 9.1 和 12.2。平台能力仍可能变化，表中“文字”表示 Harness 交互目前依赖现有安全文字状态机，不表示功能缺失。
 
 | 渠道 | 当前输入基线 | 会话与路由基线 | 当前原生/专属呈现 | Harness 交互 | 剩余重点 |
 | --- | --- | --- | --- | --- | --- |
@@ -807,8 +809,8 @@ AI Office Connector 另行维护设备、Job、租约和 SSE 路由，不进入
 
 | 优先级 | 用户价值 | 当前能力 |
 | --- | --- | --- |
-| P0：正确性与任务闭环 | 缺失会造成上下文串线，或用户无法取回任务结果 | #16 结果文件回传（已发布）；#27 Discord 独立 Thread 会话（待实现）；引用内容准确性 |
-| P1：结果可用与显著降本 | 任务勉强可完成，但阅读、选择或输入成本明显过高 | #28 Telegram Rich Message（待实现）；原生审批/选择；平台已有语音识别结果接入 |
+| P0：正确性与任务闭环 | 缺失会造成上下文串线，或用户无法取回任务结果 | #16 结果文件回传（已发布）；#27 Discord 独立 Thread 会话（已合入 main）；引用内容准确性 |
+| P1：结果可用与显著降本 | 任务勉强可完成，但阅读、选择或输入成本明显过高 | #28 Telegram Rich Message（已合入 main）；原生审批/选择；平台已有语音识别结果接入 |
 | P2：渠道体验完善 | 核心任务可完成，继续恢复或强化渠道专属体验 | 其他渠道 Markdown/代码块、输入状态、结构化进度、引用外观 |
 | P3：暂不建设 | 与 Harness 核心任务关系弱，收益尚未成立 | 贴纸、位置、联系人、通用投票等 |
 
@@ -848,14 +850,14 @@ AI Office Connector 另行维护设备、Job、租约和 SSE 路由，不进入
 
 ## 16. 分阶段实施路线
 
-### 切片 0：v1.4.0 基线门禁（2026-08-24 已刷新）
+### 切片 0：v1.5.0 / main 基线门禁（2026-08-24 已刷新）
 
 目标：以当前已发布产品为 PR 链 2、3 建立足够的回归证据，不把“建立完整新架构”变成长周期前置项目，也不重复实施已经发布的文件能力。
 
-- 固定 `@xmanrui/dsh-im@1.4.0`、`main@1d7f6a5` 为本轮代码基线；2026-08-24 实跑 `npm run check` 为 1036/1036，通过构建和发布包校验。
-- 当前渠道定向测试为 Discord 14/14、Telegram 30/30；这些数字只证明现有测试通过，不代表 Thread 或 Rich Message 已实现。
+- 固定 `@xmanrui/dsh-im@1.5.0`、`main@3ff8c2a` 为本轮最新提交基线。2026-08-24 实跑 `npm run check` 为 1089/1089，通过构建和发布包校验；当前 main 工作树的文档未提交改动不计入代码基线。
+- 当前渠道目录定向测试为 Discord 15/15、Telegram 34/34；这些数字只证明现有测试和 v1.5.0 原生图片交付通过，不代表 Thread 或 Rich Message 已进入 main。
 - 按 18.6 锁定 Discord DM/父频道 @/已有 Thread 和 Telegram 私聊/群聊/Topic/普通编辑流的已有证据，先补现有行为缺失的 Fixture，再写新能力。
-- 九渠道文字、图片、普通文件输入、结果文件回传、全部命令、问题审批和 AI Office 均作为不可降低的发布基线。
+- 九渠道文字、图片、普通文件输入、结果文件与结果图片原生回传、全部命令、问题审批和 AI Office 均作为不可降低的发布基线。
 - 新语义对象先包裹现有参数；不移动 Bridge，不改变当前凭据、配置或 Session 文件。
 - Discord Thread 和 Telegram Rich Message 分别建立真机记录，不能用一个渠道或一次桌面测试替代。
 
@@ -891,9 +893,10 @@ AI Office Connector 另行维护设备、Job、租约和 SSE 路由，不进入
 
 **最小横向建设**：
 
-- 实现 `ConversationRoute` 的稳定键生成，明确 `peerId` 为父聊天、`threadId` 为原生子会话。
-- 渠道原生动作必须在 Harness Session 绑定前完成；语义核心只接收最终路由。
+- 第一版不新建完整 `ConversationRoute` 类型；复用现有 `kind`、`conversationId`、`replyTarget` 和 `requiresMention`，只补 Discord Runtime 到共享 Bridge 的最小接缝。
+- 渠道原生动作必须在 Harness Session 绑定前完成；共享 Bridge 只接收最终 Thread 的 `conversationId` 和回复目标。
 - 新建 Thread 不自动继承父频道已有 Session，避免把原本混合的上下文复制到新会话。
+- 只有后续第二个渠道出现同一类子会话路由需求时，再把已验证的接缝提炼为通用 `ConversationRoute`，不把未来抽象作为 #27 的前置工程。
 
 **Discord 纵向实现**：
 
@@ -915,21 +918,21 @@ AI Office Connector 另行维护设备、Job、租约和 SSE 路由，不进入
 
 - 最终回答和增量更新保留 `plain | markdown` 呈现意图；不再把所有输出无条件解释为纯文本。
 - Harness `assistant/chunk` 和 `assistant/message` 明确标记为 `markdown`；工具状态、错误、控制命令和插件自生成提示为 `plain`。裸旧字符串兼容入口默认 `plain`，新 Harness 回答路径必须显式携带 `markdown`，不能靠内容猜测格式。
-- `DeliveryReceipt` 记录实际采用 `telegram-rich-draft`、`telegram-rich-final`、`telegram-regular` 或 `text-fallback`。
+- `DeliveryReceipt` 记录实际采用 `telegram-rich-draft`、`telegram-rich-final` 或 `text-fallback`。
 - 公共层不引入 Telegram `InputRichBlock*` 类型；Markdown 到 Rich Markdown/Block 的转换留在 Telegram 边界。
 
 **Telegram 纵向实现**：
 
 - `sendRichMessageDraft` 只用于私聊，同一非零 `draft_id` 更新 30 秒临时预览；Turn 完成时必须调用 `sendRichMessage` 持久化唯一最终消息。
 - `sendRichMessage` 支持私聊、超级群/频道及 `message_thread_id`；私聊 Draft 没有持久占位时用它发送最终结果。群聊和 Topic 不调用 Draft：已有持久占位时必须通过 `editMessageText.rich_message` 原位收敛，只有未创建持久占位时才调用 `sendRichMessage`。
-- 若 `editMessageText.rich_message` 被平台明确拒绝，同一占位消息按 Telegram HTML → 纯文本继续原位编辑，不另发第二份最终消息；所有路径保留原始 `reply_parameters`/Topic 归属，不留下永久“处理中”。
+- 若 Rich API 被平台明确拒绝，直接复用当前普通文字路径；群聊/Topic 优先原位替换同一占位消息，不另发第二份最终消息。所有路径保留原始引用/Topic 归属，不留下永久“处理中”。
 - 转换器覆盖代码围栏、列表、表格、链接、Unicode 和超长内容；不把未经处理的任意 HTML 直接交给 Telegram。
-- 确定性降级顺序固定为 Rich Message → Telegram HTML Message → 当前纯文本；转换失败、能力不支持或确定性 API 拒绝才能进入下一层。最终发送在调用后出现超时、断线、5xx 或取消时记录不确定回执，不再补发另一份最终消息。
+- 确定性降级顺序固定为 Rich Message → 当前普通文字；不为降级再维护一套只做转义、却不能保留 Markdown 结构的伪 HTML 路径。最终发送在调用后出现超时、断线、5xx 或取消时记录不确定回执，不再补发另一份最终消息。
 - 不增加机器人级、请求级或用户可见配置项；用小提交分离呈现语义、Telegram 转换与 API 适配，自动化和真实客户端验收通过后随版本生效，异常时回滚上一发布版本。
 
 **必须保留**：兼容/安全访问模式、私聊白名单、群聊提及/回复、Topic Session、命令菜单、图片和普通文件输入、结果文件回传、长消息拆分、编辑流失败恢复、问题审批和全部控制命令。
 
-完成标准：官方客户端完成私聊、群聊和 Topic 真机验证；Rich API 明确不可用、语法转换失败和超长回答能进入确定性降级，停止 Turn 与网络不确定结果能收敛为唯一终态且不重复发送；不新增配置项，上一发布版本可安全读取状态并恢复当前 `sendMessage/editMessageText` 路径。
+完成标准：官方客户端完成现有账号可构造的私聊、群聊和 Topic 真机验证；缺少真实群聊/Topic 时必须明确保留为未验收项。Rich API 明确不可用、语法转换失败和超长回答能回到当前普通文字路径，停止 Turn 与网络不确定结果能收敛为唯一终态且不重复发送；不新增配置项，上一发布版本可安全读取状态并恢复当前 `sendMessage/editMessageText` 路径。
 
 ### 后续切片 4：原生审批与选择
 
@@ -981,7 +984,7 @@ flowchart TD
 
 - Schema 校验、版本兼容和未知字段处理。
 - MessagePart 顺序和多媒体组合。
-- ConversationRoute 稳定性和 Session 键迁移。
+- 当前 `conversationId` 的稳定性和 Session 键兼容；只有实际提炼 `ConversationRoute` 时才增加对应迁移测试。
 - Discord 父频道、已存在线程、新建线程和创建失败回退产生唯一、可解释的路由键。
 - Interaction 状态机、所有权和幂等。
 - `dsh_im_return_file` 全局可用性，现有/新建文件等价语义，`OutboundArtifact` 的 Session/Turn 路由、快照完整性和逐项交付结果。
@@ -1049,78 +1052,86 @@ flowchart TD
 | --- | --- | --- | --- | --- | --- | --- | --- |
 | 例：DELIVERY-STREAM-FEISHU | 飞书 | CardKit 原生流式并有单一最终状态 | 保留 | 接入统一进度语义，流式体验不降低 | 测试文件与用例名 | 客户端清单编号 | 回滚上一发布版本，恢复已发布流式实现 |
 
-### 18.6 PR 链 2、3 当前测试基线与待补清单（2026-08-24）
+### 18.6 PR 链 2、3 基线与测试清单（2026-08-24 刷新）
 
-本节记录 `v1.4.0@1d7f6a5` 的实际证据，不把“平台 API 存在”或“共享测试大致覆盖”写成项目已经支持。2026-08-24 实跑结果：`npm run check` 1036/1036、Discord 渠道目录 14/14、Telegram 渠道目录 30/30，构建和发布包校验均通过。PR 链 2 的 `ConversationRoute`、Discord 查询/创建 Thread，以及 PR 链 3 的 `DeliveryBlock`、Telegram Rich API 和转换器均尚未实现。
+正式基线只取已提交代码，不把当前 main 工作树或实验分支的未提交内容算成已发布能力：
+
+| 证据 | 提交 | 实跑结果 | 结论 |
+| --- | --- | --- | --- |
+| 正式 main | `v1.5.0@3ff8c2a` | `npm run check` 1089/1089，构建和发布包校验通过 | PR 链 2、3 的最新正式比较基线，包含九渠道原生图片交付 |
+| Discord 主线定向 | `3ff8c2a` | 渠道目录 15/15 | 证明旧能力和 v1.5.0 图片交付通过，不代表已支持自动建 Thread |
+| Telegram 主线定向 | `3ff8c2a` | 渠道目录 34/34 | 证明旧能力和 v1.5.0 图片交付通过，不代表已支持 Rich Message |
+| Discord 旧行为锁定 | `54496f9` | 新增锁定用例通过；分支渠道目录最终 28/28 | PR 链 2 的第一个测试提交，已随 `37992b1` 合入 main |
+| Telegram 旧行为锁定 | `73f2627` | 新增 2 个锁定用例通过；分支渠道目录最终 57/57 | PR 链 3 的第一个测试提交，已随 `a5c516a` 合入 main |
+| 两链合并后的 main | `a5c516a` | Discord 28/28、Telegram 57/57、共享交付 56/56、全量 1129/1129；构建和发布包校验通过 | 两项能力与 v1.5.0 原生图片交付共同回归通过 |
+
+测试遵循三条最小原则：
+
+1. 共享 Bridge 已覆盖的全部命令、问题审批、文件和 Session 状态机继续由全量回归把关，不为每个渠道复制一套数据驱动测试。
+2. 渠道定向测试只覆盖本 PR 新增的决策边界、路由目标、失败收敛和平台 Payload；一个代表性命令或交付链路足以证明共用接缝时，不枚举所有同构入口。
+3. 自动化负责并发、重放和故障矩阵；真实客户端负责用户可见闭环。无法在现有测试账号构造的多人、群组或 Topic 场景必须明确记录为自动化证据，不能伪称真机已测。
 
 #### PR 链 2：Discord Thread
 
-当前可复用的基线证据：
+v1.5.0 父基线的真实行为是：DM 自动处理；Guild 消息必须明确 @；已有 Thread 使用独立 `group:<threadChannelId>`，但每条消息仍需 @；父频道中不同用户共享 `group:<parentChannelId>`。文字、图片、普通文件、结果文件、typing、编辑流、命令和问题审批均已存在，但当时尚无 Channel 查询、Thread 创建和受管 Thread 概念。
 
-| 基线 ID | 必须保留的 v1.4.0 行为 | 当前自动化证据 | 覆盖结论 |
-| --- | --- | --- | --- |
-| D2-BASE-01 | DM 自动寻址；Guild 消息只有明确 @ 才进入 Harness | `test/channels/discord/discord.test.mjs`：`Discord normalizes DMs and only addressed server messages` | 已覆盖 DM、父频道 @ 和未 @ 忽略；未区分 Thread 类型 |
-| D2-BASE-02 | 图片与普通文件分类、渠道文件下载 | `test/channels/discord/discord.test.mjs`：`Discord keeps image attachments in images and exposes ordinary attachments as files` | 已覆盖 |
-| D2-BASE-03 | Gateway v10 建连、事件派发错误隔离和停止 | `test/channels/discord/discord.test.mjs`：`Discord runtime identifies on Gateway v10 and becomes ready` | 基础覆盖；没有 Thread 重放/并发 |
-| D2-BASE-04 | 普通文字、长消息分片、编辑流和消息 ID 回执 | `test/channels/shared/delivery-message-ids.test.mjs` 的普通/流式 Discord 用例 | 共享路径已覆盖；未断言 Thread 目标 |
-| D2-BASE-05 | `/compact`、模型、Preset、`/stop`、问题审批、Actor/会话隔离与重放去重 | `test/channels/shared/text-harness-bridge.test.mjs` 的命令、停止和交互用例 | 共享状态机已覆盖；全部命令和 Thread 路由仍需显式 Fixture |
-| D2-BASE-06 | 结果文件作为原生 Attachment 发送并保留回复关系 | `test/channels/discord/discord.test.mjs`：`Discord API uploads a result file as a native attachment and preserves the reply` | 已覆盖父目标；未断言自动创建 Thread 后的目标 |
-| D2-BASE-07 | 普通文件入站没有机器人/项目/请求 Gate，也没有类型、大小、数量、TTL 或独立下载超时准入；结果文件无 Gate，配置/RPC 不暴露凭据 | `test/inbound-file.test.mjs`、`test/channels/discord/production.test.mjs`、Discord Controller/RPC 用例 | 公共无额外准入和出站装配已覆盖；Discord 入站装配仍需显式锁定 |
+源分支 `codex/pr-chain-2-discord-thread@19480a2` 已重放到 `v1.5.0@3ff8c2a`，并通过 `37992b1` 合入 main；功能实现结束于 `5b3db16`，随后只用 `19480a2` 补齐英文权限说明。分支实跑 `npm run check` 1103/1103、Discord 渠道目录 28/28，构建与发布包校验通过。它复用当前 `conversationId`、`replyTarget` 和共享 Bridge，只增加 Discord 路由接缝；本切片没有新建完整 `ConversationRoute` 框架。
 
-PR 链 2 第一个提交必须先补齐以下测试，之后才实现 Thread：
+已覆盖：
 
-- [ ] `D2-PRE-01`：分别锁定 DM、父文字频道 @、未 @、已有 Public/Private/Announcement Thread 的当前事件 Fixture；明确无关既有 Thread 保留 @ 门槛。
-- [ ] `D2-PRE-02`：用两个用户在同一父频道复现当前共享 `group:<channelId>` Session 键，作为 #27 修复前的失败特征。
-- [ ] `D2-PRE-03`：锁定文字、图片、普通文件、file-only、结果文件、typing、长消息余段和编辑流的当前发送目标。
-- [ ] `D2-PRE-04`：用数据驱动覆盖全部控制命令，以及问题、审批、`/stop`、`/steer`、多机器人、Workspace 和 Session 隔离，避免只以少数共享用例代替 Discord 证据。
-- [ ] `D2-PRE-05`：锁定 Discord 普通文件接收不依赖机器人、项目或请求配置，不以扩展名、MIME、声明/实际大小、数量、TTL 或插件独立下载超时拒绝。
+- [x] `D2-BASE-01`：`54496f9` 锁定 DM、父文字/公告频道、三类已有 Thread、父频道两用户当前共享键，以及无关 Thread 未 @ 不处理。
+- [x] `D2-API-01`：查询 Channel，并从父文字/公告消息创建对应原生 Thread；已有三类 Thread 直接沿用。
+- [x] `D2-ROUTE-01`：新 Thread 使用源消息 ID 形成独立 Session；同一父频道两名用户不会再共享新 Session。
+- [x] `D2-MANAGED-01`：机器人拥有的 Thread 后续文字、文件、代表性命令和 Harness 问题无需再次 @；无关 Thread 仍需 @。
+- [x] `D2-IDEMP-01`：并发相同事件只创建一次；创建结果不确定时按源消息 ID 查询，仍无法确认时不运行 Prompt、不回父频道补发任务结果。
+- [x] `D2-FALLBACK-01`：不支持类型或确定性创建失败只回父频道旧路径一次，提示与答案合并，避免噪音消息。
 
-PR 链 2 的新增能力测试：
+自动化合并门禁：
 
-- [ ] `D2-ROUTE-01`：`ConversationRoute` 对 DM、父频道、已有 Thread、新建 Thread 生成稳定且互不冲突的键；新 Thread 不继承父 Session。
-- [ ] `D2-ROUTE-02`：DM/父频道兼容旧聊天键；已有 Thread 兼容当前 `group:<threadChannelId>` 并原子迁移；并发迁移只保留一个 Session。
-- [ ] `D2-API-01`：锁定 Channel 类型矩阵：`GUILD_TEXT → PUBLIC_THREAD`、`GUILD_ANNOUNCEMENT → ANNOUNCEMENT_THREAD`、Public/Private/Announcement Thread 直接沿用、Forum/Media/其他不调用 Start Thread from Message；覆盖请求、返回、限流与错误映射。
-- [ ] `D2-IDEMP-01`：相同 Gateway 事件的并发、重放和重启恢复只创建一个 Thread、执行一个 Turn、产生一个最终回复；受管 Thread 的持久识别不只依赖进程内状态。
-- [ ] `D2-TARGET-01`：创建成功后 `sendText`、typing、编辑/余段、图片、普通文件、结果文件及问题审批全部落到 Thread。
-- [ ] `D2-MANAGED-01`：受管 Thread 内后续普通消息、命令、图片和文件无需再次 @，仍命中同一 Session；无关 Thread 不被放开。
-- [ ] `D2-FALLBACK-01`：最终 Route 建立前的 403、429 经平台退避仍失败、线程上限和不支持类型等确定性创建失败才回父频道旧路径；创建超时、断线、5xx 和调用后 Abort 先按源 Message ID 查询并收敛，调用前 Abort 不发送。
-- [ ] `D2-DELIVERY-01`：已有/新建 Thread Route 确定后的归档、锁定、发送权限、网络或消息发送失败留在该 Route 记录失败，不重跑 Prompt、不把完整回答发到父频道；所有路径只产生一个安全提示且不留半绑定。
-- [ ] `D2-COMPAT-01`：没有新增项目/机器人/请求配置项；v1.4.0 状态可升级读取，上一发布版本可安全忽略新增状态。
-- [ ] `D2-LIVE-01`：真实 Discord 客户端覆盖 DM、父频道、受管 Thread 后续消息、已有三类 Thread、两用户并发、重放/重启、缺权限以及完整文字/文件/命令/交互链路。
+- [x] `D2-OWNER-01`：恢复同源 Thread 时按 `owner_id === botId` 区分受管与无关 Thread；用户抢先创建的 Thread 不能因此获得免 @ 权限。
+- [x] `D2-ABORT-01`：创建请求发出后才收到取消时，仍执行一次有界查询收敛结果；调用前已取消则不请求、不运行 Prompt。
+- [x] `D2-RESTART-01`：新 Runtime 复用持久状态和 Gateway Thread 快照；受管 Thread 重启后仍无需 @，成功事件重放不再执行 Turn。
+- [x] `D2-TARGET-01`：集成测试证明流式文字、typing 和结果文件使用最终 Thread 目标；共享命令和文件状态机继续由现有全量测试覆盖，不逐项复制。
+- [x] `D2-REGRESSION-01`：Discord 定向、全量 `npm run check`、构建、发布包校验全部通过，且没有新增机器人、项目或请求配置项。
+
+真机清单：
+
+- [x] `D2-LIVE-01`：2026-08-24 在本机 Discord 的 `#常规` 首次 @；只创建一个 Thread，`THREAD_OK` 只出现在 Thread。
+- [x] `D2-LIVE-02`：同一受管 Thread 无 @ 得到 `FOLLOWUP_OK`，`/status` 正常；重启 Host 后无 @ 得到 `RESTART_OK`，仍命中同一 Thread。
+- [x] `D2-LIVE-03A`：Thread 中调用现有 `dsh_im_return_file`，`discord-pr2-live.txt` 作为原生附件回到同一 Thread，父频道没有任务结果或附件副本。
+- [ ] `D2-LIVE-03B`：DM 旧路径本轮仅有自动化回归，尚未补一条本机客户端记录。
+- [ ] `D2-LIVE-04`：当前机器人已有创建和在线程中发送权限，未故意修改服务器权限构造失败；权限失败路径只有自动化证据，真实修改权限需另行获得用户授权。
+- [x] `D2-LIVE-MERGED-01`：`main@a5c516a` 重启 Host 后，在 `#常规` 发送真实 @ 消息 `MERGED-DISCORD-20260824-0348`；只创建一个新 Thread，`THREAD_MERGE_OK` 只出现在 Thread。随后不 @ 得到 `FOLLOWUP_MERGE_OK`，并在同一 Thread 原生显示 `logo-plugin-phone.png`，父频道没有任务结果副本。
 
 #### PR 链 3：Telegram Rich Message
 
-当前可复用的基线证据：
+v1.5.0 父基线的真实行为是：私聊、群聊提及/回复和 Topic 已隔离；兼容/白名单模式、命令菜单、图片与普通文件输入、结果文件 `sendDocument`、问题快车道及普通 `sendMessage/editMessageText` 编辑流均已存在，但当时尚无 `DeliveryBlock(text.format)`、Rich Message/Draft API 或 Rich 交付回执。
 
-| 基线 ID | 必须保留的 v1.4.0 行为 | 当前自动化证据 | 覆盖结论 |
-| --- | --- | --- | --- |
-| T3-BASE-01 | 私聊、群聊提及和 Topic `message_thread_id` Session 隔离 | `test/channels/telegram/telegram.test.mjs`：`Telegram normalizes private messages and requires an explicit group address` | 已覆盖入站路由；未完整断言所有出站调用目标 |
-| T3-BASE-02 | 兼容模式、私聊白名单及运行时执行 | Telegram access policy、allowlist runtime 用例 | 已覆盖 |
-| T3-BASE-03 | 命令菜单注册，菜单失败不阻塞连接 | Telegram command menu、runtime startup 用例 | 已覆盖 |
-| T3-BASE-04 | 图片、图片文档和普通文件输入 | `Telegram keeps native photos and image documents as images and exposes ordinary documents as files` | 已覆盖 |
-| T3-BASE-05 | 当前 `sendMessage/editMessageText` 编辑流和普通文字恢复 | `Telegram bridge ignores unaddressed groups and streams direct replies`、共享消息 ID 用例 | 基础覆盖；失败恢复和完整 API Payload 不足 |
-| T3-BASE-06 | 轮询在 Harness 问题等待期间继续，答案走交互快车道 | `Telegram runtime keeps polling while a Harness question waits for its answer` | 已覆盖 |
-| T3-BASE-07 | 结果文件保持 Topic 和回复链，流完成后再发送文件 | Telegram `sendDocument` 用例、共享文字 Bridge 产物用例 | 已覆盖普通路径；Rich 混合回复待补 |
-| T3-BASE-08 | 普通文件入站没有机器人/项目/请求 Gate，也没有类型、大小、数量、TTL 或独立下载超时准入；结果文件无 Gate，旧配置和凭据投影兼容 | `test/inbound-file.test.mjs`、`test/channels/telegram/production.test.mjs`、Controller/RPC 用例 | 公共无额外准入和出站装配已覆盖；Telegram 入站装配仍需显式锁定 |
+源分支 `codex/pr-chain-3-telegram-rich@fde088e` 已重放到 `v1.5.0@3ff8c2a`，并通过 `a5c516a` 合入 main：`73f2627` 锁定旧 Payload 与 4000/4001 拆分，`dd66f5c` 增加最小 `plain | markdown` 语义和兼容回执，`d7f4cf0` 完成 Rich API、转换器和 Runtime，`fde088e` 让 Rich 与 plain 均确定性失败时进入既有安全失败收敛，同时保证 Prompt 和结果产物不重复。冲突整合保留了 v1.5.0 共享 Artifact Delivery、Telegram `sendPhoto`、Rich Draft/Final 和 `unknown` 不补发语义；没有增加 Gate、双消息或新配置。分支实跑 Telegram 渠道目录 57/57、Rich 聚焦 21/21、`npm run check` 1115/1115，构建与发布包校验通过。
 
-PR 链 3 第一个提交必须先补齐以下测试，之后才实现 Rich Message：
+已覆盖：
 
-- [ ] `T3-PRE-01`：直接锁定 `sendMessage/editMessageText` 在私聊、群聊、Topic 中的 `reply_parameters`、`message_thread_id`、禁用链接预览和当前无 `parse_mode` 的 Payload。
-- [ ] `T3-PRE-02`：锁定 4000/4001 边界、只有首段引用、所有余段留在同一 Topic，以及中文、Emoji、代码围栏和长链接不丢字符。
-- [ ] `T3-PRE-03`：补齐占位创建失败、中途编辑失败、最终编辑失败、余段失败、网络取消和 `/stop`；每条路径只运行一次 Prompt、只有一个权威终态且不永久残留“处理中”。
-- [ ] `T3-PRE-04`：锁定当前文字先完成、结果文件后发送及统一回执，并覆盖全部命令、问题审批、图片/普通文件和两种访问模式。
-- [ ] `T3-PRE-05`：锁定 Telegram 普通文件接收不依赖机器人、项目或请求配置，不以扩展名、MIME、声明/实际大小、数量、TTL 或插件独立下载超时拒绝。
+- [x] `T3-BASE-01`：`73f2627` 锁定旧 `sendMessage/editMessageText` Payload、禁用链接预览、无 `parse_mode`、引用、Topic 和 4000/4001 拆分。
+- [x] `T3-SEM-01`：`DeliveryBlock` 只表达 `plain | markdown`，旧字符串默认 `plain`；assistant 增量/最终为 Markdown，插件状态为 plain。
+- [x] `T3-API-01`：原型覆盖私聊同一非零 Draft ID 更新后持久化唯一最终消息，以及群聊/Topic 原位编辑占位消息。
+- [x] `T3-SAFE-01`：原型覆盖原始/编码 HTML 转义、Unicode 和围栏代码基本拆分，不把模型 HTML 直接当 Telegram 控件执行。
+- [x] `T3-UNKNOWN-01`：最终调用结果不确定时记录 `unknown`，不补发第二份最终消息；已登记结果文件仍可继续交付。
 
-PR 链 3 的新增能力测试：
+自动化合并门禁：
 
-- [ ] `T3-SEM-01`：`DeliveryBlock` 校验并冻结 `plain | markdown`；Harness assistant 增量/最终明确为 `markdown`，工具状态、错误、命令和插件提示为 `plain`，裸旧字符串默认 `plain`；其他八渠道零行为变化。
-- [ ] `T3-RECEIPT-01`：回执准确记录 `telegram-rich-draft`、`telegram-rich-final`、`telegram-regular` 或 `text-fallback`；用向后兼容的可选 `deliveryOutcome` 表达最终文字的 `sent | failed | unknown`，并保留全部消息 ID 和结果文件状态。
-- [ ] `T3-CONVERT-01`：转换器覆盖标题、列表、嵌套列表、围栏代码、表格、公式、链接、中文/Unicode/Emoji 和超长边界；不透传任意 HTML，转换失败仍保留可读原文。
-- [ ] `T3-API-01`：私聊用稳定非零 `draft_id` 更新同一 Draft 并最终持久化；群聊/Topic 不调用 Draft，有持久占位时通过 `editMessageText.rich_message` 原位完成，无占位时才 `sendRichMessage`；全程保留正确聊天、引用和 `message_thread_id`。
-- [ ] `T3-FALLBACK-01`：Rich → Telegram HTML → 纯文本三级降级覆盖转换异常及确定性 400/403/429；有持久占位时始终原位编辑，无占位才发送一次最终消息；超时、断线、5xx 和调用后 Abort 记录 `unknown` 且不补发，调用前 Abort 不发送；全程不重复 Prompt、不残留“处理中”、不双最终消息。
-- [ ] `T3-MIXED-01`：Rich 文字与结果文件混合、file-only、停止 Turn 和最终发送失败仍保持一份权威回执，失败的富文本不吞掉已登记文件。
-- [ ] `T3-COMPAT-01`：不新增项目/机器人/请求配置项；访问模式、Topic、命令菜单、图片、普通文件、问题审批和旧状态全量回归，上一发布版本可安全回滚。
-- [ ] `T3-LIVE-01`：真实 Telegram 客户端覆盖私聊 Draft→Final、超级群、Topic、长代码/表格/公式/链接、三级降级、弱网/停止以及入站/结果文件混合回复。
+- [x] `T3-LOSSLESS-01`：超长拆分对首尾、空格、换行、Emoji 和代码围栏零丢失；Rich 30k 与普通文字 4000 拆分均记录全部平台消息 ID。
+- [x] `T3-TERMINAL-01`：占位创建、中途更新、最终编辑、余段和 `/stop` 的成功/失败路径只运行一次 Prompt、只产生一个权威终态；失败会穷尽现有安全替换路径。
+- [x] `T3-FALLBACK-01`：Rich 确定性失败直接复用当前普通文字路径并保留占位、引用和 Topic；超时、断线、无效响应、5xx 和调用后取消按 `unknown` 处理，没有伪 HTML 中间层。
+- [x] `T3-MIXED-01`：Rich 成功+结果文件、file-only、停止、确定性失败+文件和不确定结果+文件保持一份回执，记录全部消息 ID。
+- [x] `T3-REGRESSION-01`：Telegram 入站文件仍无机器人、项目或请求 Gate；访问模式、Topic、命令菜单和其他八渠道全量回归通过，且没有新增配置项。
+
+真机清单：
+
+- [x] `T3-LIVE-API-01`：2026-08-24 直接调用真实 Bot API `sendRichMessage` 返回 HTTP 200、持久消息 ID 和 3 个 Rich Block；`/status` 普通消息路径同时正常，证明机器人连接与 Rich API 请求有效。
+- [x] `T3-LIVE-01`：本机 Telegram for macOS 12.4.2 对真实 Rich Draft/Final 显示空白；更新到 12.9 后，同一真实机器人私聊正确呈现标题、列表、代码、原生表格、公式和链接，并只留下一个持久 Rich Final。兼容探针也证明 `text + rich_message` 最终仍是 Rich-only，因此实现没有增加客户端版本 Gate、双消息补发或额外配置。
+- [x] `T3-LIVE-02`：约 1500 字回答中观察到同一 Rich Draft 从标题/首节持续更新到表格等后续内容，完成后只保留一个长 Rich Final；随后得到一个 `File Test` Rich Final 和一个原生 `telegram-pr3-live.txt` Document，文件大小 17 B、内容核对为 `TELEGRAM_FILE_OK`，没有重复最终消息。
+- [ ] `T3-LIVE-03`：群聊和 Topic 必须用真实账号验收；当前账号未提供对应真实会话，只记录自动化通过，不把私聊或 Bot API 回执冒充群聊/Topic 真机证据。
+- [x] `T3-LIVE-MERGED-01`：`main@a5c516a` 重启 Host 后，本机 Telegram 12.9 先用 `/new` 验证普通消息，再正确呈现 `Merge Rich Test` 的标题、列表、代码、原生表格、公式和链接；随后只留下一个 `Merge File Test` Rich Final 和一个原生 `telegram-main-merge-20260824-0348.txt` Document，文件为 22 B，内容核对为 `TELEGRAM_MERGE_FILE_OK`，没有重复最终消息。
 
 ## 19. 可观测性与产品指标
 
@@ -1230,23 +1241,26 @@ PR 链 3 的新增能力测试：
 1. **已发布——全局工具与路由**：Host 启动时默认注册 `dsh_im_return_file`，不设项目、机器人或请求开关；工具成功结果显式绑定调用时的 Session/Turn。
 2. **已发布——文件快照完整性**：现有/新建文件均可；只校验存在、可读和普通文件，建立不可变快照及摘要，不增加来源、工作区、内容、类型、大小、数量、TTL 或独立读取超时准入规则。
 3. **已发布——九渠道原生发送**：飞书首个闭环后，已按 3.7 扩展到其余八个渠道；格式、大小、权限、配额和限流交给平台 API 决定，适配器映射真实错误。
-4. **已发布——自动化与逐渠道验收**：每渠道一个机器人完成原生附件、内容一致性、平台权限/错误提示和既有能力回归；README 已同步真实覆盖范围，当前 v1.4.0 门禁继续执行回归。
+4. **已发布——自动化与逐渠道验收**：每渠道一个机器人完成原生附件、内容一致性、平台权限/错误提示和既有能力回归；README 已同步真实覆盖范围，当前 v1.5.0 门禁继续执行回归。
 
 ### PR 链 2：#27 Discord Thread
 
-1. **基线测试提交**：先完成 18.6 的 `D2-PRE-*`，锁定父频道 @、DM、三类已有 Thread、受管/非受管 Thread 寻址边界、两用户并发、全部命令、文件和编辑流。
-2. **最小语义提交**：`ConversationRoute` 生成与旧 Discord `conversationId` 兼容测试。
-3. **Discord 原生提交**：查询 Channel、按源 Message ID 幂等创建 Thread、切换回复目标和权限降级；不新增项目、机器人或请求配置项。
-4. **验收提交**：自动化、Discord 客户端证据、README 行为说明和上一发布版本回滚验证；在 Issue #27 记录最终行为与限制。
+1. **基线测试提交（已完成，`54496f9`）**：锁定 DM、父频道 @、三类已有 Thread、无关 Thread @ 门槛和父频道两用户当前共享键；共享命令、文件和交互继续使用既有全量回归，不复制整套渠道测试。
+2. **Discord 原生提交（已完成，`47cf028`、`2609ae2`、`5b3db16`）**：复用当前 `conversationId`/`replyTarget`，查询 Channel、按源 Message ID 幂等创建 Thread、切换回复目标并做确定性回退；不新增完整路由框架，也不新增项目、机器人或请求配置项。
+3. **自动化门禁（已完成）**：所有权、调用前后取消、重启恢复、事件重放、代表性交付目标和 v1.5.0 原生图片交付均已覆盖；全量 1103/1103，构建与发布包校验通过。
+4. **真机与说明（核心闭环已完成）**：本机 Discord 已通过父频道 → Thread、免 @ 续聊、代表性命令、Host 重启和结果文件回传；DM 真机记录和人为权限失败演练仍按 18.6 保留为未完成项，不影响已通过项的真实性。
+5. **英文部署说明（已完成，`19480a2`）**：同步 Thread 行为、Message Content Intent，以及创建、发送、历史读取和附件所需权限，避免英文用户按旧 mention-only 说明部署失败。
 
 ### PR 链 3：#28 Telegram Rich Message
 
-1. **基线测试提交**：先完成 18.6 的 `T3-PRE-*`，锁定当前 `sendMessage/editMessageText` Payload、Topic、访问模式、命令菜单、图片/普通文件、结果文件和流式失败恢复。
-2. **最小语义提交**：`DeliveryBlock(text.format)`、呈现回执和旧字符串兼容。
-3. **Telegram 原生提交**：Rich Message Draft、Rich Message、转换器、唯一最终消息和三级降级；不新增项目、机器人或请求配置项。
-4. **验收提交**：自动化、私聊/群聊/Topic 真机记录、README 限制和上一发布版本回滚验证；在 Issue #28 记录支持的 Rich 结构。
+1. **基线测试提交（已完成，`73f2627`）**：锁定当前 `sendMessage/editMessageText` Payload、引用/Topic 和 4000/4001 普通文字拆分；访问模式、命令、文件和问题审批继续使用既有全量回归。
+2. **最小语义提交（已完成，`dd66f5c`）**：`DeliveryBlock(text.format)`、可选交付结果和旧字符串兼容，不改变其他八渠道调用入口。
+3. **Telegram 原生提交（已完成，`d7f4cf0`）**：实现 Rich Message Draft、Rich Message、无损拆分、唯一最终消息，以及 Rich → 当前普通文字的单层确定性降级；保留 v1.5.0 `sendPhoto` 与共享 Artifact Delivery，没有伪 HTML 中间层，也没有新增配置项。
+4. **确定性全失败收敛（已完成，`fde088e`）**：Rich 与 plain 最终交付都被平台明确拒绝时，复用既有安全失败提示；有结果产物时先完成一次产物交付，无结果产物时不会把失败回执误算为用户可见成功，且 Prompt 不重跑。
+5. **自动化门禁（已完成）**：失败终态、混合文件/图片、长内容和其他渠道回归均已覆盖；全量 1115/1115，构建与发布包校验通过。
+6. **真实客户端验收（私聊已完成）**：Bot API 已真实返回 Rich Message 和 Rich Block；本机客户端由 12.4.2 更新到 12.9 后，私聊 Draft→Final、结构化短回答、长回答和 Rich + 原生 Document 混合交付均通过。群聊/Topic 没有真实会话，继续明确标为未验收，不把自动化或私聊结果冒充对应客户端通过。
 
-三个 PR 链共享同一发布门禁，但不共享发布节奏：#16 已随 v1.1.0 独立发布，九渠道普通文件入站也已作为另一能力随 v1.3.0 发布；#27 与 #28 仍须分别完成基线、语义、渠道实现和真机验收后独立发布。任何 PR 都不能先合并脱离公共语义的临时渠道补丁，也不能为了公共类型整齐而改动未纳入范围的渠道。
+三个 PR 链共享同一发布门禁，但不共享提交链：#16 已随 v1.1.0 独立发布，九渠道普通文件入站也已作为另一能力随 v1.3.0 发布；#27 与 #28 已分别完成基线、语义、渠道实现和真机验收，并以两个独立 merge commit 合入 main。后续仍不得合并脱离公共语义的临时渠道补丁，也不能为了公共类型整齐而改动未纳入范围的渠道。
 
 ## 24. 参考资料