Best minds · Gregor Hohpe
观点一：长跑任务不能绑在消息通道生命线上
如果一个 deploy worker 会随着 channel restart 一起死掉，那它本质上还是“消息处理副作用”，不是独立任务。真正可运维的系统，必须把任务生命周期和接入层生命周期拆开。
消息通道负责接单，长跑 worker 负责完成交付。
Deploy Group · Hot Reload Isolation
/topic 长跑与群配置热重载隔离回归
这次回归的目标不是单纯“能不能再发一页”，而是确认 deploy 群里的真实 `/topic` 长跑 在执行过程中，即使中途修改了 deploy 群配置，也不会被 Feishu channel restart 打断。要验证的是隔离边界，而不是单次部署运气好不好。
Topic: deploy-group-hot-reload-isolation-20260317b
Ingress: 2026-03-17 23:40 Asia/Shanghai
Focus: pending → hot reload → no restart
1真实 Feishu /topic 入群作为入口证据
2必须隔离的平面：channel 生命周期与 deploy worker
4回归验收要点：入口、pending、热重载、可访问链接
10异构 SVG 模块，保留 deploy preflight 通过条件
Best minds · Charity Majors
观点二：pending 不是客套，是可观测性接口
在 deploy 场景里，用户最怕的是“看起来没回复，不知道死没死”。提前写入 pending reply-meta，可以让后续 `/status`、`/links` 和排障都围绕同一份事实源进行。
先留下可查询状态，再慢慢跑长任务，体验才不会漂。
Best minds · John Allspaw
观点三：热重载要减故障面，不该制造新故障
把 deploy 群下的 `channels.feishu.groups.*` 变更收敛成 dynamic-read，才符合热重载的初衷。否则“只是改一句群 prompt”，却让整个 Feishu channel 断一下，这等于把配置管理变成了隐性故障注入器。
配置变更越细粒度，重启边界就越要收窄。
综合判断
这条回归真正要证明的是三件事同时成立：真实 `/topic` 消息已经进 deploy 群、发布链路进入 long-running 状态时会先写 pending 元数据、中途修改 deploy 群配置只触发 dynamic-read，不触发 Feishu channel restart。只要这三个条件缺一，后面的 snapshot / latest / history 再完整，也不算“以后不会再漂”。
因此这次验收必须把“运行中改 `channels.feishu.groups` 不打断长跑”上升为上线门槛，而不是把它当成事后优化项。
四条验收要点
P1
要点 1 · 入口真实
回归必须从真实 Feishu deploy 群 `/topic` 入手，而不是只在本地假跑脚本。
P2
要点 2 · pending 先行
长跑 deploy 一启动就应留下可查询的 pending reply-meta，避免“跑着跑着没人知道还活着”。
P3
要点 3 · group config 仅热读
deploy 群下 `channels.feishu.groups.*` 的中途变更，只允许记录为 dynamic-read，不允许顺手重启 Feishu channel。
P4
要点 4 · worker 独立交付
就算 gateway 或父进程受影响，detach 出去的 ship worker 也应继续跑完并写出最终链接。
图 1 · 回归主流程
关键不是“能不能 deploy”，而是“长跑途中改群配置后还能不能继续 deploy”。
图 2 · 生命周期泳道
channel 负责收消息与热读配置，真正的 ship 由独立 worker 跑完。
图 3 · 重启边界矩阵
deploy 群组级配置要热读；只有真正的 transport/auth/topology 变化才值得 restart。
图 4 · 时间线
真正危险的点在中段：worker 还没完，deploy 群配置却发生了变更。
图 5 · 通过条件
“无重启”与“链接可访问”必须同时成立，否则这条回归仍不闭环。
图 6 · 状态反馈回路
只要 pending 先落地，后续状态查询与最终回执就能围绕同一 topic 收敛。
图 7 · 隔离能力雷达
真正稳定的 deploy 群，需要的是系统性隔离能力，而不是某次偶然成功。
图 8 · 事件流向
回归的价值在于把“改群配置”这类高频动作从“误重启”分支挪回“热读成功”分支。
图 9 · 判定树
这次回归要把 deploy 群的中途配置修改，稳定地导向“reload then ship”，而不是“restart then drift”。
图 10 · 风险热力图
最热的格子不是“部署失败”，而是“只是改群配置，却悄悄把长跑任务打断”。
验收矩阵
| 场景 | 输入 / 动作 | 预期行为 | 验收信号 | 失败解释 |
|---|---|---|---|---|
| 真实入口 | /topic deploy-group-hot-reload-isolation-20260317b ... | gateway 收到 deploy 群真实消息 | 日志中出现该 topic 与 token | 若没有，说明不是 E2E |
| 长跑开始 | 启动 detached ship worker | 先写 pending，再进入 publish / verify | reply-meta 或 last pending 指针可读 | 若只有最终态，没有中间态，则排障能力不足 |
| 中途改群配置 | 直接修改 deploy 群 systemPrompt | 仅记录 dynamic-read，不重启 Feishu channel | log 有 config change applied；无 restart / abort | 若触发 restart，说明热重载边界仍漂 |
| 最终交付 | 等待 worker 跑完 | snapshot / latest / history 可访问 | reply-meta=success 且链接验收通过 | 若只打印 URL 未验证，不算闭环 |
回归测试步骤
Step 01
确认真实 Feishu 消息已入 deploy 群
先看到真实 ingress，再谈后面的 deploy 隔离；否则只是本地脚本演示。
Step 02
拉起 detached ship worker
发布任务必须与 channel 生命周期拆开，避免父进程或 gateway 变化把长跑一起带死。
Step 03
运行中直改 deploy 群配置
只改 deploy 群组级字段，专门验证 channels.feishu.groups.* 的动态热读，不走会先重启的 CLI 写配置链路。
Step 04
看 log 与最终链接
log 里要看到 dynamic-read 且没有 restart；worker 最终还要产出可访问链接，才算这条回归通过。