JianFeeeee
b5989a94a1
feat(deploy): 按 ⑬′ 给 ⑤b 与 §7 的绿补**负向清单**（判据须写出它不覆盖哪几类）
pi 2026-09-25 提的 ⑬′：写"要验 X"时必须写清**动作覆盖到哪**，而"覆盖到哪"要写成
**负向清单**（不覆盖哪些）—— 因为正向范围可以含糊，负向清单必须逐条列，否则等于没写。
他给的量化形式：假绿区 = |R| − |C|（R=宣称范围，C=实际能判红的集合）。
这两个判据原先只在**红**的时候说话，**绿**时读者会把"绿"读成"这份二进制没问题" ——
而它们其实只答了一个问题："内嵌 revision 是否等于 HEAD"。
⑤b note（绿时）: …；本判据**不覆盖**: ①从脏树构建（含未提交代码，只披露不判红）
②部署后被手工替换/修改（只看内嵌 revision）
§7 ok（绿时）: 已装二进制 = 当前 HEAD（xxxxxxxx）—— 不覆盖: 从脏树构建 / 部署后手工替换
★ 这条规矩**已被它自己验证过一次**：我 ⑤b 的 R\C 里那一格（`modified=true` 的脏树构建）
**不是我想到的，是 pi 找出来的** —— 我写 ⑤b 时以为 R = C。写出负向清单这件事
本身就会把那格逼出来。
自检新增一格 `★网关二进制：绿时 note 必须写负向清单（不覆盖哪几类）`，62 → **63 项**，
`判据自检失败` 不出现；`bash -n` 通过；`--dry-run` rc=0 且不落地。
2026-09-25 06:33:46 +08:00
..
2026-09-25 06:33:23 +08:00
2026-09-14 08:38:33 +08:00
2026-09-13 11:06:01 +08:00
2026-09-15 07:00:35 +08:00
2026-09-25 06:33:46 +08:00
2026-09-24 04:15:30 +08:00
2026-09-18 04:07:26 +08:00
2026-09-12 11:36:25 +08:00
2026-09-14 23:33:11 +08:00
2026-09-14 20:35:01 +08:00
2026-09-25 05:43:57 +08:00
2026-09-21 07:14:41 +08:00
2026-09-14 15:51:40 +08:00
2026-09-15 11:21:00 +08:00
2026-09-25 06:27:09 +08:00
2026-09-25 06:33:46 +08:00
2026-09-14 21:26:51 +08:00
2026-09-06 15:18:06 +08:00
2026-09-02 20:05:51 +08:00
2026-09-13 11:06:01 +08:00
2026-09-13 11:06:01 +08:00
2026-09-14 08:38:33 +08:00