Best minds · 运营可靠性
观点一：先保证“有回执”
对 deploy 群来说，最伤信任的不是偶发失败，而是用户发了状态查询却没有回音。裸 topic、`/links`、`/status` 都必须有可见回复，哪怕结果是失败解释，也要先把状态通道打通。
优先级顺序：先可见、再正确、再优雅。静默是最糟糕的失败形态。
Deploy Group · E2E Acceptance
Deploy 群端到端验收清单
这页不是泛泛 checklist，而是给 deploy 群日常回归直接使用的验收稿：围绕 slash-strip、status / links 回执、404 防线 与 回归测试步骤，把“消息进来 → topic 识别 → 返回可用链接 → 遇错可解释”整条链路跑通。
Topic: deploy-group-e2e-casepack-20260317
Scope: slash / bare-topic / links / status / 404
Output: 供上线与回归共用
12核心验收项
4关键失效模式
3高优先级回执入口
1上线前阻断门槛：链接可解释
Best minds · 命令路由
观点二：slash-strip 要被当成常态
Feishu/中间层剥掉 slash 后，消息可能只剩 `topic-slug token=...`。这不是异常边角，而是主路径之一。验收里必须把“剥 slash 之后仍能识别 topic 并走 status 查询”列为高优先级用例。
不要把 slash-strip 当兼容逻辑；它就是产品行为的一部分。
Best minds · 故障处置
观点三：404 不是页面问题，是证据链问题
当用户问“为什么 404 / 为什么失败”，不能只回一句“链接失效”。应先读取最近 ship log 或 reply-meta，定位是未部署、latest 指针丢失、history 可达但 canonical 不可达，还是 topic 提取错误。
好验收不是证明系统成功，而是证明系统失败时也能自证。
综合判断
推荐的验收口径：把 deploy 群链路拆成四段：消息解析、状态回执、链接可达、失败解释。每段都要有最小可操作证据。只测“成功部署”不够，因为真实生产里最频繁的是 status 查询、links 回执与 404 追问。
结论：本页建议把上线门槛定义为：用户任意用 `/links`、`/status` 或裸 topic/token 触发查询时，系统都能返回明确结果；若失败，也能从日志或 reply-meta 给出证据化解释。只有这样，deploy 群才算“可运维”。
四条验收原则
P1
要点 1 · 命令显式
`/topic` 才进入生成链路；`/links` 与 `/status` 只查状态，不重生成。
P2
要点 2 · 裸 token 兜底
正文只要出现合法 kebab-case topic，就应先提取首个 token 走 status 查询。
P3
要点 3 · 证据优先
成功要有 verified links，失败要有 log / reply-meta。没有证据，不算回执完成。
P4
要点 4 · 404 可追责
404 发生时必须能区分是 topic 错、deploy 断、latest 丢，还是 history 仍可恢复。
图 1 · 主链路流程图
主链路必须覆盖 slash 正常、slash-strip、裸 topic/token 三种入口形态。
图 2 · 泳道分工
自动化负责解析与回执；半自动负责验证；人工只接管 404 解释与重跑决策。
图 3 · 风险矩阵
静默失败与无证据 404 处于红区，必须作为阻断项。
图 4 · 响应时间线
用户感知的完成，不是脚本跑完，而是链接已回到对话里。
图 5 · 风险权重柱状图
404 与 status 回执是最该高频回归的两类场景。
图 6 · 稳定性爬坡曲线
每加上一层证据回读，定位效率都会显著改善。
图 7 · 闭环结构图
最外层是入口兼容，中层是链接返回，最内层是证据可追踪。
图 8 · 输入流向图
大部分真实消息最终都应收敛到“状态回执”这一统一出口。
图 9 · 404 处置树
先识别 topic，再读 logs / reply-meta，最后决定是直接回链还是重跑。
图 10 · 场景热力图
最深色的应是 slash-strip 与 404 组合场景，优先级最高。
验收矩阵
| 场景 | 输入示例 | 预期行为 | 验收信号 | 失败时动作 |
|---|---|---|---|---|
| /topic 生成 | `/topic deploy-group-e2e-casepack-20260317 ...` | 生成页面、预检通过、部署成功并回复结果 | reply-meta 标记 success + verification.ok=true | 继续修页，不提前宣称完成 |
| /status 查询 | `/status deploy-group-default-livefix` | 不重生成，只返回当前链接/状态 | ship-links 输出 latest/history | 若 topic 缺失，明确 FAILED 原因 |
| /links 查询 | `/links deploy-group-default-livefix token=...` | 按 topic 返回链接列表 | 可见回复中含最新 URL | 补充执行证据 |
| slash-strip 裸 topic | `deploy-group-default-livefix token=...` | 提取首个 kebab-case token 走 status 查询 | 仍有可见回执 | 检查 topic 解析规则 |
| 404 追问 | “为什么 404” | 先读 ship log / reply-meta，再解释 | 解释中含日志证据 | 区分 latest 丢失、未部署、topic 错误 |
| 无 topic 命令 | `/status` | 若提取不到 topic，明确失败原因 | 回复中有 FAILED 与原因 | 提示正确用法 |
四个失效模式与防线
1. slash 被剥掉后静默
症状：消息只剩 topic + token，系统不回应。
- 防线：总是提取第一个 kebab-case token
- 防线：将裸 topic/token 映射到 ship-links
- 验收：必须出现可见结果回复
2. status / links 被错误走成生成链路
症状：简单查状态却触发重生成、慢且不可控。
- 防线：命令路由前置
- 防线：/topic 与 status 语义硬隔离
- 验收：status 查询不改页面
3. 404 无证据解释
症状：只能说“打不开”，无法说明为什么。
- 防线：优先读 `.ship-logs/last_log.txt` 与 reply-meta
- 防线：按 latest/history/canonical 分类
- 验收：答复中能指出具体断点
4. 成功宣称早于验证
症状：脚本退出就说成功，但实际链接未就绪。
- 防线：必须以 verified live URLs 为准
- 防线：读取 reply-meta 的 verification 结果
- 验收：无 verification.ok 不宣称完成
回归测试步骤
Step 01
跑 slash 正常路径
用 `/links
Step 02
跑 slash-strip 路径
模拟消息只保留 `topic token=...`，确认仍按首个 kebab-case token 提取 topic 并返回状态链接。
Step 03
跑 404 解释路径
针对一个故意失效或历史 topic，追问“为什么 404”，确认系统先读日志再解释，而不是空泛安慰。
Step 04
跑 /topic 发布路径
生成一页真实报告，确保预检通过、部署后 latest/history 可访问，reply-meta 声明验证成功。
建议的最小发布门槛
Gate A
可见回执
所有 `/links`、`/status`、裸 topic/token 均必须回复，不允许沉默。
Gate B
topic 识别正确
首个 kebab-case token 提取稳定，不受尾随 token 干扰。
Gate C
链接可达或可解释
latest/history 至少其一可用；否则必须给出日志证据化说明。
Gate D
回归脚本可复跑
团队成员能用统一步骤复现验收，不依赖个人记忆。
行动建议
本周内：把 slash-strip、裸 topic/token、404 triage 三类用例加入固定 smoke 套件，并保留一份“失败但可解释”的样本 topic。
下一个迭代：在 status 回执旁统一附上“最新、历史、报告”三类链接，降低人工判断成本。
长期：将 reply-meta 与 ship log 的关键字段固化为值班排障面板，减少“靠翻对话猜状态”的隐性成本。