用途：当两个或多个实现共享同一契约（接口、适配器、后端、客户端，或真假实现并存）时，代码阅读得出的“它们一致”只是假设而非结论。不应在发现测试缺口后只报告“有缺口但无缺陷”就停下，而应编写可执行的对比、运行它并据结果判断。
触发条件：契约有至少两个实现；你正准备在未运行任何测试的情况下报告测试缺口。单一实现不在范围内——只有一个实现的承诺是定义，无法发生分歧。假实现加上其替代的真实实现是最典型的两个实现场景，因为其他测试往往默认信任这对实现。若契约已有共享测试电池，应扩展而非另建分支。
主要能力与做法：枚举承诺，从契约文档或规范文本中找出所有可测试保证，搜索 idempotent、no-op、never、always、guaranteed、exactly once、at most one、must never、fails closed 等承诺性措辞，优先处理有书面承诺但无测试之处；使用一个共享模块，每个承诺一项检查，参数化覆盖所有实现，而非按后端分文件；断言可区分细节而非仅结果；加入阳性对照，避免电池空跑通过；先运行，再判断是否存在缺陷并如实报告。
电池有效性三要素：断言可区分细节（例如两者都抛错不等于一致，需比较异常类型、消息暴露与可重试性）；触及可区分状态（空值、并发、第二次调用等）；保留阳性对照（共享代码损坏时应有断言失败）。
报告方式：说明电池覆盖什么、发现什么、改了什么。发现分歧时点名分歧轴、双方行为及用户可见后果（状态码、错误值、重复执行）；未发现分歧时报告“电池在 N 个实现上全绿，缺口是覆盖而非正确性”。
限制：不适用于单实现契约；明确反对为所有东西都写电池。参考文献包括 references/battery-template.md、references/battery-craft.md。相关技能有 fewer-tests-more-proof、self-audit、readable-code、rfc-writer。