ADR-0011：砍掉站点维护开关，故障沟通走现有通知通道¶

日期：2026-07-24　状态：已接受

修订关系：本决定废止 ADR-0006；配置开关文件整体退出 v1，受管文件从三类缩为两类。

这份记录在讲什么¶

原方案里，热修通道管三类文件：主程序 exe、yt-dlp.exe、配置开关文件。配置开关第一版只有一个用途——站点维护开关（ADR-0006）：站点故障、热修还没就绪时，给客户端下发"该站点维护中"的状态，在站点入口挂一块"维护中"的牌子，安抚用户。

本轮评审从第一性原理重新问了一句：这块牌子到底有没有必要？结论是——没有，砍掉。

决定¶

配置开关文件整体退出 v1。受管文件缩为两类：主程序 exe、yt-dlp.exe。
"告诉用户我们知道了、正在修"这个任务，改走现有的应用内通知通道（ServiceNotifyManager，Stream/main.cpp:1661——客户端启动就会拉取服务端通知并展示，管道现成）。
通知话术建议写成"修复正在分批推送，重启软件可提前收到"——不只是安抚，还顺手催用户重启，让热修更快生效。
待确认：通知后台（运营侧）能否及时发"按站点、多语言"的公告（开放问题 Q10）。若确认做不到，再回头考虑最小开关。

为什么砍掉它¶

一、它干的是"广播"的活，却用了"改设置"的管道。

"我们知道了，正在修"本质上是喊一句话（通知），不是改一台机器的设定（配置）。为了喊这句话，在热修通道里专门养一类受管文件——签名、下发、清单语义、决策引擎处理、CI 打包、运营挂牌/摘牌流程——一整套管道，全压在 6 周的关键路径上。而店里本来就有广播系统：客户端的服务通知管道是现成的，一行热修代码都不用加。

二、它会把回滚决策的数据源掐死。

灰度是过夜跑的，第二天早上拍"能不能全量"，靠的是"命中人群的下载成功率恢复了没、未命中人群还在失败没"。可牌子挂着，两边的用户都被劝退了、都不去尝试下载——命中组交不出"修好了"的证据，对照组也交不出"还没修"的基线。指标回滚（ADR-0012）的对比设计，被这块牌子从两头掐断。

三、给用户的价值，公告一样给得了。

用户从"站点入口看到维护中"变成"公告里看到已知晓、修复中"，信息量相同；而公告不拦人、不劝退，大家照常尝试，数据两边都在。公告还能干牌子干不了的事：催重启、加速热修生效。

这么定之后会怎样¶

热修通道 v1 更小更专：两类受管文件，清单语义、CI、决策引擎都少一块。
ADR-0006 标记废止；CONTEXT 删"站点维护开关"词条、"受管文件"改两类；产品规格的范围与用户故事 14 同步改写；北极星边界从"维护开关之外的开关不做"改为"配置开关通道 v1 整体不做"。
曾经讨论过的"命中者自动摘牌"方案（热修清单标注修复站点、客户端自清提示）随之整个不需要了——没有牌子，就没有摘牌问题。
新增开放问题 Q10：确认通知后台的公告能力。