ADR-0013：包/清单两条流水线；自动化门槛替代人工双人审批¶

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

修订关系：取代 ADR-0003 中"产品+技术双人审批节点"的表述；在 ADR-0008 的包构建流水线之上新增独立的清单流水线；细化 ADR-0004 中"percent 调整 = 人工改清单 + Jenkins 流水线发布"的落地形态；给决策引擎新增"幂等收敛"规则。审批流的变更与 PRD 表述有出入，待产品侧确认（开放问题 Q2）。

这份记录在讲什么¶

原方案把热修发布做成一条 Jenkins 流水线，内置产品+技术双人审批节点。本轮评审发现两个问题：一条流水线揉了两件节奏完全不同的事，会把"分钟级止血"的承诺搞塌；而双人审批在小团队里容易变成走过场，防 bug 不如机器，防滥用可以用透明化替代。

决定一：拆成两条流水线——厨房与菜单牌¶

一家餐厅，厨房做菜（慢，应该慢），门口菜单牌决定卖什么卖给谁（改一笔，瞬间生效）。"这道菜停售"不需要重启厨房——如果停售也要走全套厨房流程，客人吃出问题时你想停都停不下来。

	包流水线（厨房）	清单流水线（菜单牌）
管什么	内容是什么	发给谁、发多少
什么时候跑	有新热修内容才跑	每次放量决策变化：开 canary、扩 10%、全量、归零、强制回滚、改 exclude、标 urgent
干什么	构建 → 加壳平台签名 → Ed25519 文件签名 → 契约测试 → TEST_MODE 验证 → 上传 CDN	生成新清单（版本号 +1 保持单调）→ Ed25519 清单签名 → 发布到下发服务 → 自动广播
耗时	几十分钟到几小时，慢没关系	几分钟——不碰构建

四个典型场景里三个只动菜单牌：放量（percent 10→100）、半夜止血（percent 归零）、强制回滚（版本号 +1、内容指向 CDN 上已有的旧好包）——都不需要造任何新东西。ADR-0004 承诺的"percent 归零分钟级截断"，只有把清单操作从构建流水线里拆出来才能兑现。

包流水线不是新建：就是现有增量流水线按 ADR-0008 加料。清单流水线是新增的一个小 Jenkins job（输入几个参数、签名、发布、广播）；它的"分钟级生效"还依赖下发服务无小时级缓存（Q1 跟踪中）。

决定二：不设人工审批，换成"机器卡死 + 全员看见"¶

"测试没问题就发"——不需要人点同意。 但砍掉人工审批不等于裸奔，三样东西顶上：

原来	换成	防什么
人工点"同意"	自动化硬门槛：契约测试 + TEST_MODE 验证不通过，流水线直接不放行——不是人看着办，是机器卡死	防 bug（比人靠谱）
第二双眼睛	发布即广播：任何发布/放量/回滚动作自动飞书通知全员（谁、何时、发了什么、灰度多少），不可关闭	防滥用——想拿紧急通道偷偷塞功能，藏不住
审批记录	Jenkins 权限收紧到极少数人 + 操作全留痕	防账号盗用、留审计

canary 照旧不可跳过（北极星护栏"跳过 canary 次数 = 0"）——内部机器真跑半天，才是真正的质量闸门，比任何人工点头都实在。

与 PRD 的出入：双人审批是 PRD 明文要求（ADR-0003 曾把它"固化为工具流程"）。本决定由技术 DRI 提出，需与产品侧对齐后生效，挂开放问题 Q2 跟踪。

决定三：清单是导航不是命令——决策引擎的幂等规则¶

强制回滚清单必须广播给所有人（服务端不知道谁中招了）。如果清单是"命令"，没中招的 90% 也会白下载一遍好包、把自己换成一模一样的东西——每次替换都有非零风险。

所以清单的语义定为导航："目的地是这里"。已经在目的地的人，显示"您已到达"，熄火不动：

客户端应用清单前，先比对"当前运行文件的哈希"与"清单目标文件的哈希"。一致 → 记录清单版本号为已见，什么都不做；不一致 → 才下载替换。

清单本来就带每个文件的 SHA-256（验签要用），比对零成本。这条规则同时白送三个好处：防重复应用（percent 10→100 时已装用户不再装一遍）、网络重试安全（幂等）、与"分桶粘住"同一世界观——清单描述目标状态，客户端负责收敛。

这么定之后会怎样¶

ADR-0004 的 percent 操作、服务端两层回滚，落地形态 = 清单流水线，分钟级。
ADR-0003/0008 的"双人审批节点"表述作废；签名动作的执行点从"审批之后"改为"自动化门槛通过之后"。
决策引擎的判定清单新增"哈希一致即跳过"（幂等）。
产品规格用户故事 18 改写；北极星 P0-B2 工作线、tech-spec 架构图/CI 表/风险表/时序同步。
开放问题 Q2 扩充：PRD 的审批流表述与"配置开关"内容类，均需产品侧同步修订。