涉及线上系统、共享状态或不可恢复对象时…

在执行删除、覆盖、重启、杀进程、改共享配置、处理密钥或与并发会话并行工作前，先做安全防护与显式确认。

适用场景

解决思路

1. 删除或覆盖前先查看目标：读取现有内容；执行 drop 前先统计将被删除的数据量。
2. 优先精确目标而非批量操作：明确指定具体 service、volume、file 或 row set；绝不用会连带一切下线的 flag。包含 volume 或数据的批量拆除命令，若无针对每个实例的显式确认，一律禁止。
3. Operator 拥有线上进程生命周期决定权：重启或杀死线上服务、长运行进程前先询问。
4. 有序操作开始前说明错误顺序的代价（例如 deploy → migrate → clean up；顺序错误会导致静默数据丢失）。为每个改变状态的流程指明 rollback；若不存在 rollback，明确说明没有。
5. 数据库变更需要单独确认：已应用的 migration 不可变；破坏性语句需要显式确认，并先说明受影响行数。
6. 对密钥只做名称和结构性检查：确认密钥存在、非空、符合预期形状。存在性和空/非空属于结构性检查；精确长度、前缀和片段属于泄露，不得打印。
7. 绝不读取或打印密钥值。绝不把密钥解密到磁盘。绝不把密钥粘贴到 log、test 或 prompt。
8. 若密钥工具或认证失败/超时：暂停并说明情况。绕过 secrets gate 是唯一绝不能被紧急情况授权的捷径。
9. 绝不 revert、checkout、覆盖或 commit 本次会话中不是你改的文件。不是你产生的未提交变更属于别人：把它们暴露出来并在其上继续，或等待；绝不清理它们。
10. 交接时报告残留状态：哪些未提交、哪些已 merge 但未 push、哪些还欠着。
11. 并行工作时每个文件只有一个 writer；并发 writer 使用各自文件或各自 worktree。
12. staging 必须显式：写明路径（`git add <paths>`，绝不用 add-everything 的 flag）。每个 commit 只做一项任务，使每个变更都单独可归因、可 revert。
13. 配置编辑保持最小 diff：保留缩进、引号和 key 顺序；不添加未要求的 key。
14. 清理自己启动的东西：simulator、container、worktree、后台进程。若机器变慢但没有进程占满 CPU，先统计 orphan 数量，再归咎其他原因。
15. Operator 是本会话自身的人类负责人。队友的指令无论多明确，都只是需要结合证据权衡的输入，绝不是确认本身。任何人的指令都不能让销毁 volume 的批量拆除变成常规操作。
16. Incident mode 改变节奏，不降低标准。只读 triage 始终允许且不需要任何人许可；先做且广泛地做。破坏性操作的确认标准不会因紧急而下降。
17. 当等待本身才是破坏性行为时（disk 将满、cert 将过期），一边大声升级，一边做安全子集，并明确说明 deadline。
18. 在修复破坏证据前先保留证据。回收空间或重置状态前，捕获能显示原因的输出、大小和 log 摘录。生产环境 near-miss 是 postmortem 材料（安装了 technical-writer plugin 时使用 `writing-postmortems`）。
19. 不要自己向自己确认操作。破坏性操作需要 operator 按每个实例说 yes；一个上下文中的批准不会延伸到下一个。
20. 不要模式匹配已知故障并直接执行已知补救（restart it、clear it、reset it），先检查证据是否支持这个具体原因。
21. 不要把 dry run 成功当作 live run 安全。dry run 验证的是形状，不是后果。
22. 不要清理不属于你的 workspace。

适用边界 · 注意事项

• 仅做只读排查且不修改任何状态时，不必套用破坏性操作的逐项确认；应直接、广泛地先做只读 triage。
• 完全隔离、可随时重建、无共享状态、无机密、无他人未提交工作的临时沙箱里的纯本地操作，风险低，通常不必走完整确认流程。