Tcuzzo Full Close——完整闭环
Effort: free — 对你本来就欠的修复排个顺序：磁盘真相探针和失败测试放在最前面，不是额外开销。消除：故障当中甩给人的选项菜单和每一步的确认请求。
当人报告东西坏了、或者说"修好它"，正确答案只有一个：一次理解先行的完整闭环。带证据的根因、先写失败测试、转绿、在人自己的路径上现场证明，然后提交。绝不把选项菜单递回去，也绝不每步都要确认——他已经说了修好它。
兄弟技能对毁灭性操作要求明确同意，本规则只赢下可逆的那一半：人的"修好它"就是对留有备份痕迹的可逆恢复写入的常设同意；任何不可逆的事——销毁数据、花钱、对外发送——仍要过 decision-bar，且门槛说了算。
只有当某样东西被证明在所有其他地方都找不到、只有人能提供时，才向人开口要。其余一切输入，自己去找。
方法
- 探一次正常表面——然后停止信任它。 调一次 API 或 CLI。回答正常，那这就不是 事故闭环的场景；移交出去。返回 401/403、连接被拒、该有数据的地方空空如也、或者 数据过期——就不再把这个表面当权威。
- 从磁盘建立地面真相，不从 API。 绝不让一个坏掉的服务描述它自己的状态。亲自读 数据文件、目录列表、修改时间，再和 API 的说法对照。分歧就是诊断信号。
- 扫影响范围。 搜索每个顶层数据目录里故障窗口内被碰过的文件（例如
find /data/volumes -newermt "<start>" ! -newermt "<end>"）。目标是一屏内答清 "什么被碰了、什么没有"。范围窄（一个卷、一张表）在这里可恢复。范围宽（多个卷、 整个数据目录）就是灾难恢复——上报，别即兴发挥。 - 清点幸存与损失。 给每个受影响资产分类：
- 磁盘上完好——原样恢复
- 可从仓库重建——已提交进 git 的配置和备份
- 可从 env 或凭证文件重建——token、密码
- 永久丢失——密钥缺失的加密数据、只存在于运行时的状态 只有最后一类才值得问人。其余全部自己重建。
- 带证据定根因，然后写红色测试。 说清为什么坏、拿出磁盘上的证明——不是猜。 缺陷在代码里的，先写抓住它的失败测试，再修到绿。见 red-first 和 root-cause-first。
- 逐层向下，绝不向上抛给人。 首选路径断了，就下一层再试： API / SDK → 容器内的 CLI → 直接写数据库 → 文件系统手术。 还有下行梯级没试完，就不去打扰人。每往下一级都比开口问便宜。
- 假设依赖也坏了。 恢复代码只用你语言的标准库来做 HTTP 和 JSON——第三方客户端 可能正是死掉的一部分。
- 幂等地写，留备份痕迹。 每次磁盘写入都在目标旁边留一个带时间戳的
.bak副本。 读、健全性检查、复制、写入、复查——绝不盲覆盖。要临时换用凭证去铸新钥匙，先备份 原件，返回前恢复：人自己的登录毫发无损。 - 在人自己的路径上用活调用验证。 重跑第 1 步的探测，确认数字对得上事故前的清点 或仓库备份。数据库状态变绿不是证明；人用的那个表面重新工作才是证明。
- 提交并报告。 只提交这次修复自己的文件。报告：探了什么、影响范围、按顺序做了 什么、恢复了多少、永久丢失了什么（没有就写空）、以及任何非致命失败的步骤。
危险信号——停下重探
- "我去问问人为什么坏了"——不行；先从磁盘查明。
- "API 说这里什么都没有"——坏掉的 API 对自己的看法不是真相。
- "干脆重装干净"——你在丢弃可恢复的状态。
- "密钥没了所以凭证废了"——明文值常常还躺在 env 或凭证文件里；重建凭证。
- "每步之前确认一下？"——人已经说了修好它；跑完层级，最后一并报告。
硬规则——踩中任何一条即失败
- 明明有清晰解法，却把选项递回给人。
- 一次没有
.bak痕迹的毁灭性写入。 - 层级和清点还没穷尽，就向人开口要东西。
- "好心"恢复了一个已退役的子系统——已下线的服务保持下线才是期望状态，重新启用是人 的刻意决定。
- 凭内部状态而不是人路径上的活探测宣称恢复完成。
- 修复没提交（除非人明确说了不提交）。
搭配使用
- repair-loop——缺陷在代码里时，这次闭环运行的代码修复循环。
- root-cause-first · red-first
- decision-bar——什么可以到人面前，以及怎么到。