发布 checklist 如果只记录几条命令，很快就会变成仪式。真正有用的清单，应该记录命令、路由、环境、风险和失败处理。
这篇是发布门禁主文的窄文 companion，专门回答 checklist 该记录哪些证据，不重复整套发布哲学。
清单要记录证据，不只是动作
很多发布事故不是因为完全没跑检查，而是因为检查没有覆盖真实风险：本地 build 过了，目标平台没过；主页面能打开，动态回调坏了；文章能访问，但 sitemap/RSS 暴露了不该公开的草稿。
所以 checklist 的每一行都应该回答两个问题：它证明了什么风险被挡住？如果失败，发布应该暂停、回滚，还是补证据后继续？
证据要能被下一次复用
发布记录不是为了证明这次很努力，而是为了让下一次发布能复用同一组判断。命令、路由和失败条件都要写成别人能复查的证据。
命令层要写清楚证明对象
npm run lint 证明静态规则没有被破坏，npm test 证明回归集合仍然成立，npm run build 证明 Next.js build 能过，npm run build:cf 才证明 Cloudflare/OpenNext 目标链路没有被延后到最后才发现问题。
命令越多不等于越安全。真正有效的是把命令和失败类型一一对应起来。
路由和公开索引必须单独记录
内容站发布前不仅要确认文章页能 build，还要确认未来日期草稿不会进入 static params、RSS 和 sitemap。对 MakePlans 来说，PUBLIC_SITE_CURRENT_DATE=2026-04-29 就是这轮验证的基准日期。
这类检查不该藏在“build 通过”后面。它应该在 checklist 里有独立区域：关键公开页、资源页、RSS、sitemap、404 和未来日期过滤。
风险层写暂停条件，而不是写漂亮流程
发布前先列本次最怕失败的三件事，再为每件事放一个命令证据或人工检查证据。最后写清失败时暂停、回滚或继续的判断条件。
如果 checklist 只能告诉你“下一步跑什么”，却不能在失败时告诉你该不该停，它还只是流程单，不是发布证据。
质量门：每项检查挡住什么风险
质量门是：每个检查项后面是否能写出它挡住的风险。如果写不出来，这一项就是仪式；如果写得出来，它才是发布证据。
这篇如果写成命令清单堆叠，会让发布流程看起来完整，却不能解释每一步为什么存在。