spike

spike — 解决方案验证

运行不变量

• 临时目录边界：仅在 .agents/scratch/ 中编写候选逻辑、测试框架、固件和验证产物；不要改动生产代码和永久测试。
• 工作树保护：保留现有更改和无关的临时产物。以只读方式检查集成边界；执行操作需要修改时，使用隔离副本。
• 问题保真度：依据原始问题和验收标准建立断言。在基线运行和候选方案运行中保持断言不变；区分隔离的能力验证与生产修复验证。
• 方向边界：在给定的解决方案方向和约束内，探索有限且有证据支撑的备选方案。需要改变方向时，报告并交由单独决策；不得默默扩大搜索范围，也不得强行得出 GREEN 结果。
• 敏感证据与环境：记录日志前先删去机密；绝不检查机密文件（.env*、*.key、*.pem）。依据 .agents/environment.md 配置测试框架运行器和临时数据存储；实验严格限制在 .agents/scratch/ 中。

领域评估标准

输入与验证目标

• 接受问题或 RED 信号、候选方案，以及由输入确定或经上下文确认的解决方案方向和约束。问题可能是推断得出或含糊不清；根据现有证据推导可测试的标准，并记录假设。如果候选方案的方向边界明确，它可以自行确定方向；未明确说明的架构选择应保持开放。
• 确定相关的集成边界、预期结果、已知的原始故障机制，以及需要验证的主要不确定性。如果输入或上下文无法确定测试标准或允许的方向，请先报告 UNRESOLVED 并说明所需输入，不要探索备选方案。
• 使用原始症状定义修复断言。对于新能力，使用其必需行为作为断言；只有在与需求相关时，才选择正确性、兼容性、并发、对等性或资源测量作为验证标准。

基线与候选方案实验

• 条件允许时，先建立基线 RED，然后对候选方案运行相同的断言以尝试达到 GREEN。如果无法复现原始故障，在任何缺陷修复声明中都应保留这一差距。
• 测试实际集成边界或忠实的隔离副本。说明模拟边界和省略的集成行为；仅模拟达到 GREEN，只能证明所建模的范围，无法确认未经验证的生产修复。
• 在保留关键输入、环境、状态转换和边界情况的前提下，尽可能精简测试框架。使用命令和经过脱敏的固件，确保设置和执行过程可复现。
• 对于间歇性或并发行为，尽可能控制随机种子、时钟和交错执行；记录失败情况和重复次数，不要仅凭一次通过就接受结果。
• 根据每次失败，在既定方向内选择有依据的备选方案。达到完整验证、相关的允许备选方案耗尽、运行时或访问受阻，或有证据表明必须改变方向时，停止探索。

结论状态

• CONFIRMED：实证符合所述测试范围内的原始标准。确认缺陷已修复，还要求基线在相同断言下失败，并且候选方案达到 GREEN。
• INFERRED：推理或部分执行支持候选方案，但原始标准尚未得到完整的实证验证；请明确说明具体差距。
• REJECTED：有限实验表明，在穷尽相关的允许备选方案后，候选方案或方向仍不符合标准。结论仅限于已测试的备选方案和条件；不得声称其普遍不可能。
• UNRESOLVED：缺少方向、标准、运行环境、访问权限或其他前置条件，无法给出可靠的验证或否定结论。

规范输出约定

生成一份简洁的报告，提供足够的证据以便重现验证并评估其适用性。必要时在临时目录中保留经过净化的脚本和日志；在报告中总结决定性观察结果。

# Solution-Proof Report: <problem / candidate>

State: <CONFIRMED | INFERRED | REJECTED | UNRESOLVED>
Conclusion: <what the candidate demonstrably solves, may solve, failed to solve, or leaves unknown>
Original criteria: <problem-grounded assertions>
Direction and constraints: <supplied boundary and assumptions>
Integration seam: <module/interface/runtime boundary>
Evidence: <scratch paths and commands; baseline and candidate results for the same assertion>
Conditions and proof limits: <tested environment, substitutions, missing proof, applicability limits>

## Alternatives *(omit if none were explored)*
<candidate -> decisive observation -> retained or eliminated within direction>

路由

• 已接受经过验证的解决方案，且需要规划文件影响 →（通过 /changeset）。
• 缺少的需求导致无法进行有意义的验证 →（通过 /clarify）。
• 成功需要改变给定方向 →（通过 /architect-decision）。
• 缺少工具链或测试数据存储尚未就绪，导致无法执行实验 →（通过 /env-doctor）。

执行协议

1. 明确问题、候选方案、方向、约束和切入点。定义原始断言以及证明该断言所需的证据。
2. 构建最小化的临时实验，并尽可能运行基线。根据相同标准和相关边界条件测试候选方案。
3. 检查失败情况，并在既定方向内探索有依据的替代方案，直至获得证明、有限探索穷尽、遇到阻碍或必须改变方向。记录足以说明停止理由的观察结果。
4. 提交解决方案验证报告，说明其状态、条件和限制；确认生产文件未被更改，并保留有用且经过净化的验证材料。