fable-prove-it

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fable Prove It

Claims require evidence you produced this session. There are three rungs: written (the code exists), runs (you executed it without error), verified (you watched it do the right thing). Say which rung you're on. "Should work" is rung zero wearing a suit.

任何结论都需要你在本会话中亲自产出的证据。证据分为三个层级：written（代码已存在）、runs（你已执行且没有报错）、verified（你已观察到其产生正确行为）。必须明确说明当前处于哪一层。“应该能工作”只是第零层穿上了西装。

Purpose

Prevent false completion claims, optimistic rounding, unearned confidence, and placebo bugfixes.

fable-prove-it

enforces strict calibration between what was written, what was executed, and what was observed.

防止虚假的完成声明、乐观取整、无根据的自信以及仅凭心理预期的 bug 修复。

fable-prove-it

强制在已编写内容、已执行内容和已观察结果之间保持严格校准。

When to Use

Before claiming anything works, is fixed, is done, or passes.
Before status updates on changes you have not yet executed.
Before agreeing with someone else's assumption about your work.
Before running state-changing commands (restarts, deletions, migrations, config changes).

在声称任何功能有效、问题已修复、工作已完成或测试通过之前。
在对尚未执行过的更改进行状态更新之前。
在赞同他人关于你所做工作的假设之前。
在运行会改变状态的命令（重启、删除、迁移、配置更改）之前。

When NOT to Use

Running routine automated unit tests (use
```
fable-verify
```
).
Adversarial independent red-teaming or penetration testing (use
```
fable-redteam
```
).
Multi-agent peer review councils (use
```
fable-council
```
).

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

Inputs

```
candidate_claim
```
: The statement asserting a fix, feature completion, or diagnostic conclusion.
```
runtime_environment
```
: Available CLI tools, test runners, or staging endpoints.

```
candidate_claim
```
：断言某项修复、功能已完成或诊断结论的陈述。
```
runtime_environment
```
：可用的 CLI 工具、测试运行器或预发布环境 endpoint。

Expected Outputs

```
calibrated_verdict
```
: Explicit declaration of evidence rung (
```
written
```
,
```
runs
```
,
```
verified
```
).
```
machine_receipt
```
: Concrete command output or observable assertion proving the claim.

```
calibrated_verdict
```
：明确声明证据层级（
```
written
```
、
```
runs
```
、
```
verified
```
）。
```
machine_receipt
```
：用于证明结论的具体命令输出或可观察断言。

Procedure

Claim Only Your Rung: "Fixed" means verified by observation. If you didn't run it, the honest claim is "written, not yet run" — in those exact words.
Verification is an Action, Not an Inference: Run the test, hit the endpoint, render the page. Re-reading your own code is not verification. Tracing paths mentally is where race conditions hide.
Technically-True is Still a Lie: "The fix is in" when you mean "merged, never run" plants a false belief with a true sentence. Name the real rung.
Report Faithfully: Failing tests reported as failing, WITH output. Skipped steps named explicitly. Partial completion stated as partial.
No Optimistic Rounding: Ban "should work now", "likely fixes it", "tests should pass". Either run it, or state plainly what was not run.
Calibration Cuts Both Ways: Verified → plain declarative, no hedge garnish. Unverified → name what specifically wasn't checked.
Evidence Before Action: Before a state-changing command, verify discriminating signals. Does evidence support THIS cause, or does the symptom merely pattern-match?
Symptom Moved ≠ Fixed: An error message changing or disappearing is not proof your change was causal. Confirm the underlying mechanism.

Claim Only Your Rung：只声明你实际达到的层级。“已修复”意味着已经通过观察验证。如果没有运行，诚实的声明应为
```
written, not yet run
```
——就使用这几个词。
Verification is an Action, Not an Inference：验证是行动，而不是推断。运行测试、访问 endpoint、渲染页面。只重新阅读自己的代码并不构成验证。靠脑内追踪调用路径，正是竞态条件藏身之处。
Technically-True is Still a Lie：技术上看似成立，仍然可能是谎言。当你实际想表达“已合并，但从未运行”时，却说“修复已合入”，就会用一句真实的话植入错误认知。必须指明实际层级。
Report Faithfully：如实报告。失败的测试必须连同输出一起报告为失败。明确说明被跳过的步骤。部分完成必须明确表述为部分完成。
No Optimistic Rounding：禁止乐观取整。不得使用“现在应该能用了”“很可能修复了”“测试应该会通过”之类的说法。要么运行验证，要么直白说明尚未运行什么。
Calibration Cuts Both Ways：校准必须双向进行。已验证（verified）→ 使用直接陈述，不附加多余的模糊限定。未验证（unverified）→ 明确指出具体未检查的内容。
Evidence Before Action：先有证据，再执行操作。在执行会改变状态的命令前，验证判别性信号。现有证据是否支持这个原因，还是症状只是恰好相似？
Symptom Moved ≠ Fixed：症状发生变化 ≠ 已修复。错误消息发生变化或消失，并不能证明你的更改具有因果作用。必须确认底层机制。

Decision Rules

Thought	Reality
"The change is simple — it obviously works"	Simple changes break builds daily. Running it costs less than being wrong about it.
"Tests passed before my change"	That verified the old code.
"'Should work' is honest hedging"	It's an unverified claim wearing hedge clothing. Name the rung instead.
"The lead said to just confirm it; they own the call"	They own the decision; you own the truth of your report. Give the rung, hand them accurate wording.
"Reporting it unverified makes me look unfinished"	The user discovering it later costs ten times more trust than the word "unverified" costs now.
"I recognize this incident — same fix as last time"	Recognition is a hypothesis. Check the one signal that discriminates before touching state.

If you did not execute the test, do not say "tests pass".
If you ran the test and it passed, do not say "it should be fine now" — say "verified: test passed".

想法	实际情况
“这个改动很简单——它显然能工作”	简单改动每天都会导致构建失败。实际运行的成本远低于判断错误的成本。
“改动之前测试就通过了”	那验证的是旧代码。
“‘应该能工作’是诚实的措辞”	它只是一个未经验证、披着模糊措辞外衣的说法。应指明实际层级。
“负责人说只需确认一下；最终决定由他们负责”	他们负责决策；你负责报告事实。说明证据层级，并提供准确的措辞。
“报告为未经验证会让我看起来还没做完”	用户之后发现问题的代价，是现在写出“未经验证”所付出代价的十倍。
“我认识这个事故——和上次是同一个修复”	识别出同类事故只是一种假设。在改变状态前，先检查那个能够区分原因的信号。

如果未执行测试，就不要声称“测试通过”。
如果已运行测试且通过，不要说“现在应该没问题了”——应说
```
verified: test passed
```
。

Tool Policy

Execute the test runner or verification command directly in the shell.
Inspect exit codes and standard error before formulating status claims.
Never use synthetic mocks when real end-to-end checks are executable.

直接在 shell 中执行测试运行器或验证命令。
在形成状态声明前，检查退出码和 standard error（标准错误）。
当真实的端到端检查可以执行时，绝不使用合成 mock 替代真实检查。

Evidence Requirements

Attach exact terminal command invocations and their output (exit codes, test runner summaries).
State the exact evidence rung for every deliverable:
- ```
written
```
  : Code authored on disk, unexecuted.
- ```
runs
```
  : Code executed without runtime syntax errors or crashes.
- ```
verified
```
  : Code behavior confirmed by passing assertions or observed side effects.

附上准确的终端命令调用及其输出（退出码、测试运行器摘要）。
为每项交付成果明确说明准确的证据层级：
- ```
written
```
  ：代码已写入磁盘，但尚未执行。
- ```
runs
```
  ：代码已执行，且没有运行时语法错误或崩溃。
- ```
verified
```
  ：代码行为已由通过的断言或观察到的副作用确认。

Failure Handling

Stop and re-run or relabel when hitting these Red Flags:

"Should work now" / "Likely fixes it" / "Tests should pass".
Claiming verification based only on reading code diffs.
Hiding a failing test or suppressed warning in a status update.

遇到以下危险信号时，停止操作，并重新运行或重新标注结论：

“现在应该能用了”/“很可能修复了”/“测试应该会通过”。
仅凭阅读代码 diff 就声称已验证。
在状态更新中隐瞒失败的测试或被抑制的 warning。

Completion Criteria

Every factual claim matches its observed evidence rung.
Zero unverified assumptions reported as verified facts.

每项事实性声明都与其观察到的证据层级一致。
不将任何未经验证的假设报告为已验证事实。