做非平凡工程改动前的证据优先纪律与安全检查点

在实现、调试、重构、配置、运维或排查系统异常等任何可能出错的工程改动前，用证据而非记忆来约束决策、保证安全。

适用场景

解决思路

1. 在写第一行代码前，在工作笔记中填写强制检查点：`Grounded: <你读了或运行了什么来了解当前行为> | Blast radius: <这次改动触及什么> | Invariants: <什么绝不能坏> | Verify: <能证明它生效的命令>`；每个字段都要来自代码和数据，而不是记忆或合理性推测；填不出的字段就是你要先做的工作。
2. 根据任务类型加载对应的兄弟技能：开始改动/调试/接触陌生代码时加载 `grounding-before-coding`；写或触碰任何错误路径、回退或默认值时加载 `handling-failures`；新增数据、配置、状态或任何第二份副本时加载 `keeping-one-source-of-truth`；声称“完成”“修复”“通过”时加载 `verifying-before-done`；删除、覆盖、重启或触碰密钥与线上系统时加载 `operating-safely`；决定修复规模或发现范围漂移时加载 `scoping-changes`；决定改动需要哪些测试或面对空测试 diff 时加载 `testing-changes`；写或修单元测试、治理不稳定或难读的测试时加载 `writing-unit-tests`；跨越模块边界或触碰既定原则时加载 `guarding-architecture`；新增、更新、审查或移除包、库、基础镜像时加载 `adding-dependencies`。
3. 遵守硬性规则：绝不静默吞掉错误——每个 catch 和失败路径都要记录并重新抛出、返回调用方必须处理的类型化失败，或进入显式文档化的降级模式；新增静默吞错是自动的评审 BLOCKER。
4. 已应用的迁移是不可变历史：schema 修正必须是新增的追加式迁移，绝不编辑已应用的迁移。
5. 绝不在未指明检查内容的情况下声称已验证：一个“完成”声明要写明命令及其结果、引用每个失败测试的输出，并列出所有跳过的步骤。
6. 绝不读取、打印或解密密钥值到磁盘：只处理名称和结构性检查；认证失败意味着暂停，绝不绕过。
7. 破坏性操作必须先看目标：删除或覆盖前先查看目标；重启或杀死线上服务前先询问；优先使用定向操作而非批量操作。
8. 证据胜过理论：先做 profile、查询和阅读再下结论；一个与已知故障模式匹配的信号可能有不同原因，所以要检查证据是否支持这个具体动作，而不是那个熟悉的动作。
9. 按风险层级设定严格程度：规则在每个层级都成立，层级决定需要多少证明；项目自行声明哪些属于最高层级（如资金路径、销售管道、存储的用户数据、医疗记录、安全门、不可逆迁移）；项目规则或 CLAUDE.md 未指明时，问系统绝不能弄错什么，并把答案当作声明。
10. 最高层级工作获得最大严格度：不变量测试、独立验证，并逐字执行完整检查点；普通路径获得标准严格度；工具和一次性工作仍遵守硬性规则（脚本里的静默吞错仍会隐藏失败），但不做镀金；层级不明显时明确说明。
11. 规则生命周期：同一件事咬你两次就写成带出处的书面规则（发生了什么、何时、如何避免）；只发生一次算学习。持续触发的规则要磨锐；根因已修复的规则要退役；每条规则背后记录的事件能防止它被盲目照搬或错误删除。
12. 避免常见错误：不要依据文档对系统的声称行事而不看系统本身（文档状态很快过时，代码和历史才是记录）；不要修复模式匹配到的症状而不修复证据显示的根因；不要把“测试是绿的”当作“改动有效”（代码不可能工作时测试仍绿，说明测试没跑或没测到）；不要在你正在改的代码里留下未处理的重复（你触碰的代码里的重复要在本次工作中吸收；仅在别处注意到的重复要上报并跟踪，既不静默修复也不静默留下）；不要因为改进相邻就把修复扩大到触发点之外。

适用边界 · 注意事项

• 不适用于风格指南类问题：格式、命名品味和框架选择属于仓库自身约定，仓库约定优先。
• 不替代项目指令：CLAUDE.md 和仓库规则高于本技能的一切。
• 不提供产品决策：构建什么来自负责人；本技能只约束已构建之物如何保持真实与安全。