fable-prove-it

Fable Prove It

声明必须有你在本次会话中产出的证据支持。证据分为三个等级：已编写（代码已存在）、已运行（你已执行且未报错）、已验证（你已观察到它按预期工作）。说明你达到了哪个等级。“应该能用”只是穿上西装的零级证据。

目的

防止虚报完成、乐观淡化问题、信心不足为凭，以及安慰剂式修复。fable-prove-it 会严格校准已编写、已执行和已观察到的内容。

使用时机

• 在声称任何东西可用、已修复、已完成或已通过之前。
• 在汇报尚未执行的更改状态之前。
• 在赞同他人对你工作的假设之前。
• 在运行会改变状态的命令（重启、删除、迁移、配置更改）之前。

不使用时机

• 运行常规自动化单元测试时（使用 fable-verify）。
• 进行对抗性独立红队测试或渗透测试时（使用 fable-redteam）。
• 召开多 Agent 同行评审委员会时（使用 fable-council）。

输入

• candidate_claim：声明修复已完成、功能已实现或诊断结论成立的陈述。
• runtime_environment：可用的 CLI 工具、测试运行器或预发布端点。

预期输出

• calibrated_verdict：明确声明证据等级（written、runs、verified）。
• machine_receipt：能证明声明的具体命令输出或可观察断言。

流程

1. 只声明你达到的等级：“已修复”意味着经过观察验证。如果你没有运行它，诚实的说法是“已编写，尚未运行”——必须使用这几个字。
2. 验证是一项操作，不是推断：运行测试、访问端点、渲染页面。重新阅读自己的代码不算验证。凭空推演执行路径，正是竞态条件藏身之处。
3. 技术上属实，仍可能是谎言：你想表达的是“已合并，但从未运行”，却说“修复已提交”，会用真实的句子让人产生错误认知。请说明实际达到的等级。
4. 如实汇报：测试失败就报告失败，并附上输出。明确说明跳过的步骤。部分完成就说明是部分完成。
5. 禁止乐观淡化：禁用“现在应该能用了”“可能修好了”“测试应该能通过”之类的说法。要么运行它，要么明确说明哪些内容没有运行。
6. 校准有双向性：已验证 → 直接陈述，不要添加含糊措辞。未经验证 → 明确指出具体未检查的内容。
7. 先有证据，再采取行动：运行会改变状态的命令前，先核实有区分度的信号。证据支持的是这个原因吗，还是症状只是看起来相似？
8. 症状变化 ≠ 已修复：错误消息改变或消失，并不能证明你的更改是原因。请确认底层机制。

判断规则

想法	实际情况
“改动很简单，显然能用”	简单改动每天都会弄坏构建。运行一下，比误判的代价低。
“我的改动之前测试通过了”	那验证的是旧代码。
“‘应该能用’是诚实的保留说法”	这只是穿着保留措辞外衣的未经验证声明。请改为说明实际等级。
“负责人说只要确认一下；决定由他们来做”	决定由他们负责；你要对报告的真实性负责。说明实际等级，并给出准确措辞。
“报告未经验证会显得我没完成”	用户之后才发现问题，造成的信任损失，是现在说“未经验证”所付代价的十倍。
“我认得这次事故——和上次是同一个修复方案”	熟悉感只是一种假设。在改变状态之前，先检查能区分原因的那个信号。

• 如果你没有运行测试，就不要说“测试通过”。
• 如果你运行了测试且测试通过，就不要说“现在应该没问题了”——请说“已验证：测试通过”。

工具策略

• 直接在 shell 中执行测试运行器或验证命令。
• 在陈述状态之前检查退出代码和标准错误。
• 如果可以执行真实的端到端检查，绝不要使用合成模拟。

证据要求

• 附上精确的终端命令调用及其输出（退出代码、测试运行器摘要）。
• 为每项交付物注明确切的证据等级：
  • written：已在磁盘上编写代码，但尚未执行。
  • runs：已执行代码，未出现运行时语法错误或崩溃。
  • verified：已通过断言或观察到的副作用确认代码行为。

失败处理

遇到以下警示信号时，停止并重新运行，或调整标签：

• “现在应该能用了”／“可能修复了”／“测试应该能通过”。
• 仅凭阅读代码差异就声称已验证。
• 在状态更新中隐瞒失败的测试或被抑制的警告。

完成标准

• 每项事实陈述都与其观察到的证据等级相符。
• 不得将未经验证的假设报告为已验证的事实。