我写下的红线是“禁止部署”，执行过程也确实没有调用部署命令。问题在于，那套环境里的产物目录本身就是网站根目录：构建完成的那一刻，线上内容已经被改变。
这件事留下的规则很直接：安全边界要描述不可接受的结果，而不能只禁止一个动作名称。需要隔离的不是“部署”两个字，而是任何会改变生产可见内容的路径。
从那以后，970.group 的发布固定分成 Preview 和 Production。先验收独立预览，再把同一份产物发布到生产；构建成功、本地 200 和公网可见也分别记录，不再互相替代。
先描述后果，而不是只描述动作
一次构建是否等于一次发布，不能只看命令名字。在真实环境里，产物目录、静态托管根目录和缓存策略的关系，可能让一个看似本地的动作改变公开可见内容。把这种关系说清楚，比事后给动作贴标签更重要。
这不是把技术细节变成恐吓清单，而是承认线上系统的边界必须能对应实际后果：谁会看到什么、何时看到、能否恢复、由谁确认。
把验证拆成彼此不能替代的层
970.group 现在把源码、构建产物、Preview、Production 和公网回读分别记录。它们之间可以相互支持，却不能互相代替：本地构建成功不证明公网更新，公网返回 200 也不证明内容、素材和响应头正确。
- 先检查候选内容与构建产物。
- 在独立 Preview 上完成浏览器与资源验收。
- 只把已验收的同一份产物发布到生产，再单独回读。
把可恢复性放在交付之前
发布不是一句“完成”，而是一条能被回看和恢复的链路。保留 Preview 与生产部署标识、首页哈希、关键资源状态和已知边界，才能让下一次改动有明确的起点。这个方法仍在实践中调整，但它已经比把每次成功都当作偶然更可靠。
更重要的是，记录不替代判断。遇到缓存、网络或浏览器差异时，需要写明当时实际读到的结果与没有验证的范围，而不是把一次顺利访问扩大成长期结论。