fable-verify

Fable Verify

尝试证明实现有误，然后只报告经最新证据验证仍成立的结论。

使命

验证不等于“运行测试套件”，而是针对已变更的风险提供相关且最新的证据。

绿色命令只能证明它实际检查的内容。构建成功不能证明运行时行为。安全检查通过不能证明功能正确。单元测试通过不能证明打包或集成路径正常。旧证据不能证明更新后的改动。

适用场景

• 实现或修复已就绪，需要独立验证；
• 完成声明需要最新证据；
• 评审或发布门禁要求提供测试、构建或运行时证据；
• 改动后需要刷新过时证据；
• 怀疑的回归范围超出针对性 TDD 测试。

不适用场景

• 编写实现（fable-execute/fable-tdd）；
• 决定架构（fable-plan）；
• 根据差异评审设计或可维护性（fable-review）；
• 诊断反复出现的困惑型失败（fable-recover）。

风险分类

将每个变更面对应到能够证伪它的证据。

变更面	典型证据
纯行为	针对性单元测试／属性测试 + 受影响的测试套件
跨模块契约	集成／契约测试
公共 CLI/API	调用／冒烟测试 + 契约测试
构建／导出／打包	构建 + 打包／干净安装冒烟测试
持久化／迁移	集成测试 + 迁移／兼容性测试固件
异步／并发	确定性顺序检查／压力测试补充
配置／功能标志	在相关配置分支下运行的测试
浏览器／UI	视情况采用组件／集成／E2E 测试
安全边界	专项安全检查 以及 功能证据
性能敏感路径	在有相关要求时进行针对性测量

验证流程

阶段 1 — 阅读差异和执行说明

不要只凭习惯选择命令。识别以下内容：

• 变更的行为；
• 涉及的文件／契约；
• 新增／变更的测试；
• 生成物／打包／配置相关面；
• 实现留下的残余风险；
• 当前改动代次。

阶段 2 — 建立验证矩阵

针对每项重要风险，写明：

• 声明；
• 失败模式；
• 能发现问题的证据／命令；
• 证据必须属于针对性、集成、运行时、构建、E2E、安全还是打包级别。

删除只能证明相同狭窄事实的重复检查；为尚未测试的变更面补充检查。

阶段 3 — 先运行范围窄、因果关系明确的检查

从针对已变更行为的检查和受影响的测试开始。快速的本地证据有助于区分实现问题与无关的测试套件噪声。

阶段 4 — 按影响范围扩大验证

只有在变更可能影响相关内容，或仓库发布策略要求时，才运行更广泛的类型检查／构建／测试／集成／E2E／打包门禁。

不要仅因针对性测试通过就跳过项目要求的全局门禁。

阶段 5 — 对抗式证伪

主动探查最可能的回归面：

• 边界／空／无效输入；
• 错误传播；
• 重试／幂等性；
• 新旧格式兼容性；
• 异步顺序／并发；
• 清理／资源生命周期；
• 打包／导出／运行时入口；
• 配置分支。

优先选择能产生有意义失败的测试／命令，而不是推测性描述。

阶段 6 — 检测非确定性和过时执行结果

如果相同命令的结果时好时坏，就不要继续累计通过次数。记录这种差异并转交恢复流程。

如果结果未反映已知的源代码变更，在接受输出前检查源码与构建产物、缓存、分支、环境、进程和产物路径。

阶段 7 — 记录类型明确且最新的证据

证据应包括：

• 类型（适用时为 test、build、runtime、review、security）；
• 精确命令／探测；
• 退出状态／结果及相关计数；
• 可用时记录改动代次／产物 SHA；
• 证据能够证明的范围／声明。

阶段 8 — 明确限定结论

使用：

• PASS：每项必需声明都有新鲜且相关的证据；
• FAIL：至少有一项必需声明被证伪；
• INCOMPLETE：无法获取必需证据，或证据未覆盖相关风险。

不要因为剩余检查不方便就把 INCOMPLETE 改为 PASS。

决策规则

• 证据生成时间早于当前相关变更 → 证据已过时，重新运行。
• 测试通过，但未执行变更路径 → 证据无关，不能判为 PASS。
• 只有安全性证据，却要验证功能性缺陷 → 需要功能性证明。
• 只有构建／类型检查证据，却要验证运行时行为 → 需要运行时／测试证明。
• 针对性测试通过，但集成契约已变更 → 运行集成／契约检查。
• 软件包／导出内容变更 → 检查／冒烟测试分发的产物，而不只检查源代码测试。
• 结果反复波动 → 转交给 fable-recover；不要挑选一次通过的结果。
• 新验证失败由范围明确、显而易见的实现缺陷导致 → 返回一张修复卡；重复／原因不明的失败 → 恢复处理。
• 当前环境中无法运行某条命令 → 将证据标记为不完整，并指出外部关卡；不要捏造结果。

不变量

• 验证不得改变产品行为；任何修复都会开启新的变更／证据周期。
• 每项完成声明都必须对应新鲜证据。
• 不同类型的证据不可互换。
• 最终结论必须针对当前变更代次／产物。
• 不得通过截断输出或反复运行直至通过来隐瞒必需的失败／警告。

失败分类

相关测试失败

变更后的行为已被证伪。根据问题是否明确／是否重复，返回范围明确的修复任务或进行恢复处理。

无关套件失败

排除前必须证明其无关；不能仅因为它早于本次变更就置之不理。

过时的证据／产物

输出对应的是更早的变更／构建。评估实现前，先刷新构建／路径／环境。

非确定性验证

相同状态产生不一致结果。下结论前，先诊断共享状态／时序／环境问题。

覆盖缺口

现有检查未覆盖实质性的变更风险。添加／找到合适的证据，或标记为不完整。

环境限制

所需的外部服务／浏览器／平台／发布环境不可用。报告具体缺少的证据；不要伪造通过结果。

反模式

• 仅以 tests passed 作为整份验证报告；
• 只运行实现者刚编写的测试；
• 反复运行不稳定的测试，直到通过；
• 代码变更后仍信任旧截图／日志；
• 将类型检查／构建／安全检查当作功能性证明；
• 忽略打包／导出路径；
• 未分析受影响风险就运行大范围完整套件；
• 必需的外部关卡从未运行，却声称通过。

验证包

Current mutation/artifact:
Changed risks:
Verification matrix:
- claim → evidence → result
Adversarial probes:
Stale/nondeterministic evidence detected:
Required external evidence not run:
Verdict: PASS | FAIL | INCOMPLETE
Repair/recovery recommendation:

完成标准

满足以下条件时，验证即告完成：

• 变更风险均有相关检查；
• 所需的项目关卡均已执行，或明确标记为不可用；
• 证据针对当前变更／产物，且为新鲜证据；
• 已主动探测可能的边缘／失败场景；
• 未隐瞒非确定性结果／过时输出；
• 结论范围不超出证据所支持的范围。

渐进式资源

• 深度矩阵指南：references/verification-matrix-and-evidence-strength.md
• 现有证伪启发式：references/falsification-heuristics.md
• 证据记录：references/evidence-recording.md
• 示例：examples/falsification-session.md