证据合约
创建可测试且基于实际仓库（而非合理猜测）的计划。
激活
当任务需要非平凡的实施方案或方案审查时，自动应用此技能。不要等待用户显式调用。
对于目标、行为和验证已经显而易见的琐碎更改，跳过完整合约。改为陈述简单的检查。
此技能仅用于规划。除非用户还要求您执行该计划，否则不要编辑实现文件。
工作流程
1. 确定意图和成功标准
用一句话重述期望结果。从请求中提取具体的验收行为。如果措辞模糊，先调查仓库再询问用户。仅在调查后仍存在重大不同结果时才询问用户。
2. 收集最低限度的充分证据
在提出架构或命名受影响的文件之前：
- 当存在时，读取
PROJECT_CONTEXT.md。 - 通过定向搜索定位功能入口点。
- 读取最小的相关实现、配置和测试文件集。
- 追溯重要的调用者、依赖关系、持久化边界和公共接口。
- 记录文档与代码之间的矛盾。将代码和可执行行为视为更强证据。
当定向证据足够时，避免广泛的仓库扫描。
3. 分类每一个实质性主张
在内部使用这些标签，并在有用时暴露它们：
- 已观察：直接由文件、符号、命令结果、测试或运行时观察支持。
- 推断：由已观察证据强烈暗示但未直接证明。
- 未知：尚未确定的关键信息。
绝不要将推断或未知的主张当作事实呈现。对于重要的已观察主张，包括代码位置或工具观察。不要编造文件路径、API、依赖关系或现有行为。
4. 解决阻塞性未知因素
调查可能改变架构、范围、数据流、兼容性或验收行为的未知因素。如果未知因素无法在本地解决：
- 明确陈述它，
- 解释为什么重要，
- 提出最安全的有限假设，以及
- 仅当继续可能导致错误结果时才询问用户。
5. 生成受证据约束的计划
每个非平凡计划项必须包括：
- 变更：最小的连贯实现步骤。
- 证据：证明该步骤合理的已观察仓库事实，附上相关路径或符号。
- 影响范围：可能变更的文件、接口、数据、调用者、依赖关系或工作流。
- 成功检查：可执行的测试、构建、lint、运行时或验收观察。
- 风险或假设：仅当重要时，标记为推断或未知。
优先选择将一个需求映射到一个可观察检查的计划。对于缺陷修复和兼容性敏感变更，包含回归覆盖。
6. 运行计划门
在呈现计划之前，验证：
- 每个请求的结果至少映射到一个计划项。
- 每个计划项都有证据和具体的成功检查。
- 命名的文件和符号是观察到的，而非猜测的。
- 重要假设是可见且分类的。
- 依赖关系和集成边界已覆盖。
- 计划使用满足请求的最小变更。
- 没有添加推测性功能或无关的重构。
如果门检查失败，在返回计划之前进行调查或修改。
输出格式
除非任务复杂，否则保持结果简洁。
## 证据合约
- 已观察：`path/to/file` 确立 ...
- 推断：... 因为 ...
- 未知：...；有限假设或所需决策 ...
## 计划
1. **变更** ...
- 证据：...
- 影响范围：...
- 验证：...
- 风险/假设：...
## 完成门
- [ ] 需求到检查的映射完整
- [ ] 没有未标记的假设
- [ ] 验收检查可执行
省略空的推断或未知部分。对于小型计划，将每个项压缩为单行，同时保留证据和验证。
反模式
不要：
- 仅根据文件名生成计划，
- 使用“可能”、“大概”或“应该”而不标记推断，
- 声称测试通过而不运行它们，
- 用模拟检查替代可用的真实验收路径，
- 用可从仓库回答的问题困扰用户，
- 将合约变成琐碎更改的文书工作，
- 仅仅因为计划完成就开始实现。