القائمة
验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 的爆炸半径纪律