Menu
验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
指导稳定的 RPC、存储协议和接口设计。在设计节点间 RPC、存储协议语义、模块边界或任何公共接口时使用。在定义 gRPC service、对象存储或文件系统语义、节点间的类型契约，或确立组件边界时使用。
自动化 CI/CD 流水线设置。在设置或修改构建和部署流水线时使用。当需要自动化质量门禁、在 CI 中配置测试运行器，或建立部署策略时使用。当需要处理 CI 上不稳定（flaky）的测试时使用。
进行多维度代码审查。在合并任何变更之前使用。在审查由你自己、另一个智能体或人类编写的代码时使用。当需要在代码进入主分支之前评估其跨多个维度的质量时使用。当需要评估变更的正确性、可读性、架构与性能，或审查 PR/diff 时使用。
为清晰性而简化代码。在重构代码以提高可读性而不改变行为时使用。当代码可以正常工作但比应有的更难阅读、维护或扩展时使用。在审查已积累不必要复杂性的代码时使用。当组件过度设计、过于炫技而难以维护时使用。当需要清理越来越难读懂的代码时使用。
优化智能体上下文设置。在开始新会话、智能体输出质量下降、在不同任务之间切换，或需要为项目配置规则文件和上下文时使用。
指导系统化的根因调试。当测试失败、构建中断、行为不符合预期，或遇到任何意外错误时使用。当需要系统化地找到并修复根本原因而非猜测时使用。当服务崩溃（panic）、空指针异常、或之前通过的测试突然挂掉时使用。当生产环境间歇性报错、需要定位根因时使用。当测试或构建昨天还通过、今天就挂了时使用。
| name | consistency-and-durability-verification |
| description | 验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。 |
存储和分布式系统的核心承诺只有两条：已确认的数据不丢（持久性），所有副本讲同一个故事（一致性）。这两条承诺无法靠代码审查保证——它们必须被系统地验证，因为违反它们的 bug 平时不可见，只在崩溃、分区和并发交错下显形。
核心纪律：先把承诺写成精确的可证伪陈述，再用故障注入 + 模型检查 + 不变量校验三层手段去证伪它。
不适用于：一般功能测试（用 test-driven-development）、性能验证（用 performance-optimization）。
模糊的承诺无法验证。逐条写清楚：
- 持久性：客户端收到 ack 的写，在任意 ≤ f 个节点同时崩溃后仍可读回
- 一致性：任意时刻、任意副本上的读，满足 [强一致 / 读己之写 / 有界陈旧 / 最终一致]
- 原子性：多对象写入要么全部可见，要么全部不可见（含崩溃中点）
- 恢复：任意时刻 kill，重启后系统能到达一致状态且不报旧值
每条陈述必须指明：承诺在什么故障模型下成立（崩溃还是拜占庭？几个节点？分区多久？）。超出故障模型的场景不属于违约。
逐个回答，答案必须来自代码而非口头：
把写路径切成关键阶段，在每两个阶段之间注入崩溃，恢复后校验五层契约：
配合 failure-injection-testing 的注入编排执行；每个 kill point 的失败用例固化为回归测试。
协议级变更（选主、成员变更、日志匹配规则）在实现前用 TLA+ 或等价工具做形式化规约和模型检查。实现后，用确定性模拟（seed 驱动的模拟网络/磁盘/时钟）大规模探索交错序列，失败 seed 固化为回归用例。
| 借口 | 现实 |
|---|---|
| "我们用了 Raft，一致性是现成的" | 论文的正确性不等于你实现的正确性。成员变更、快照、预投票都是常见的实现级 bug 来源 |
| "fsync 都调了，数据不会丢" | fsync 只保证它覆盖的那一段。应用缓冲、组提交窗口、盘内缓存每个都是丢失点 |
| "重启一下就恢复了" | 恢复过程本身可能是数据丢失点（误回滚已 ack 的写）。恢复路径必须被测试，不是被假设 |
| "副本天天跑，不一致早发现了" | 没有对账就没有发现机制。副本发散是静默的，直到某次故障切换读到了旧数据 |
| "崩溃中点的概率太低不用测" | 概率低 × 调用次数多 = 必然发生。kill point 测试就是要把低概率变成必然复现 |
| "性能要紧，校验和可以省" | 省掉端到端校验和等于放弃发现静默损坏的唯一手段。先量化开销再谈取舍 |
failure-injection-testing 的爆炸半径纪律