fable-prove-it

Fable Prove It

主張には、このセッションで得た証拠が必要です。段階は3つあります。記述済み（コードが存在する）、実行済み（エラーなく実行した）、検証済み（正しく動作することを確認した）。自分がどの段階にいるかを伝えてください。「動くはず」は、スーツを着た段階ゼロです。

目的

完了したという誤った主張、楽観的な切り上げ、根拠のない確信、プラセボのようなバグ修正を防ぎます。fable-prove-it は、記述した内容、実行した内容、観察した内容の間の厳密な確度調整を徹底します。

使用する場面

• 何かが動作する、修正された、完了した、または合格したと主張する前。
• まだ実行していない変更について進捗を報告する前。
• 自分の作業に関する他者の推測に同意する前。
• 状態を変更するコマンド（再起動、削除、マイグレーション、設定変更）を実行する前。

使用しない場面

• 定型的な自動単体テストの実行（fable-verify を使用）。
• 敵対的な独立レッドチームテストや侵入テスト（fable-redteam を使用）。
• 複数エージェントによるピアレビュー評議会（fable-council を使用）。

入力

• candidate_claim：修正、機能の完了、または診断結果を主張する文。
• runtime_environment：利用可能な CLI ツール、テストランナー、またはステージングエンドポイント。

期待される出力

• calibrated_verdict：証拠の段階（written、runs、verified）を明示した宣言。
• machine_receipt：主張を証明する具体的なコマンド出力または観察可能なアサーション。

手順

1. 自分の段階の範囲内で主張する：「修正済み」とは、観察によって検証されたことを意味します。実行していないなら、正直な主張は「記述済み、未実行」です。必ずこの表現をそのまま使ってください。
2. 検証は推測ではなく行動：テストを実行し、エンドポイントにアクセスし、ページをレンダリングしてください。自分のコードを読み返すだけでは検証になりません。競合状態は、経路を頭の中でたどるときに隠れています。
3. 技術的に正しくても嘘になる：「修正は入っています」と言いながら「マージ済みだが、一度も実行していない」という意味なら、正しい文で誤った認識を植え付けることになります。実際の段階を明示してください。
4. 忠実に報告する：失敗したテストは、出力とともに失敗として報告してください。省略した手順は明示してください。一部のみ完了した場合は、そのように述べてください。
5. 楽観的に切り上げない：「これで動くはず」「おそらく直った」「テストは通るはず」は禁止です。実行するか、実行していない内容を明確に述べてください。
6. 確度調整は両方向に働く：検証済みなら、曖昧な言い回しを添えず、明確に断言してください。未検証なら、具体的に何を確認していないかを明示してください。
7. 実行前に証拠を確認する：状態を変更するコマンドの前に、原因を特定できるシグナルを確認してください。証拠は今回の原因を裏付けていますか。それとも、症状が単に既知のパターンに似ているだけですか。
8. 症状が変わった ≠ 修正された：エラーメッセージが変わったり消えたりしても、変更が原因だった証拠にはなりません。根本の仕組みを確認してください。

判断ルール

考えたこと	実際
「変更は簡単だから、明らかに動く」	簡単な変更でも毎日のようにビルドを壊します。間違いを思い込むより、実行して確かめるほうが手間はかかりません。
「変更前はテストに合格していた」	それで検証できたのは古いコードです。
「『動くはず』は正直な控えめ表現だ」	それは曖昧さをまとった未検証の主張です。代わりに段階を明示してください。
「リードに確認だけしてと言われた。判断するのは相手だ」	判断するのは相手ですが、報告の真偽に責任を持つのはあなたです。段階を伝え、正確な表現を提示してください。
「未検証と報告すると、未完成に見える」	後でユーザーに発覚すれば、今「未検証」と伝えるよりも、信頼を10倍失います。
「このインシデントは覚えている。前回と同じ修正でよい」	思い当たることは仮説にすぎません。状態を変更する前に、違いを見分けるシグナルを1つ確認してください。

• テストを実行していないなら、「テストに合格しました」と言ってはいけません。
• テストを実行して合格したなら、「これで大丈夫なはず」と言わず、「検証済み：テストに合格しました」と述べてください。

ツールポリシー

• テストランナーまたは検証コマンドを、シェルから直接実行してください。
• 進捗を報告する前に、終了コードと標準エラーを確認してください。
• 実際のエンドツーエンドチェックを実行できる場合、合成モックを決して使用しないでください。

エビデンス要件

• 正確なターミナルコマンドの実行内容とその出力（終了コード、テストランナーのサマリー）を添付してください。
• すべての成果物について、正確なエビデンス段階を明記してください。
  • written：コードをディスク上に作成した状態。未実行です。
  • runs：実行時の構文エラーやクラッシュなしでコードを実行した状態です。
  • verified：アサーションの成功または観測された副作用によって、コードの動作を確認した状態です。

失敗時の対応

次の危険信号に該当した場合は、停止して再実行するか、エビデンス段階を付け直してください。

• 「これで動くはずです」／「おそらく修正できています」／「テストは通るはずです」
• コード差分を読むだけで検証済みと主張すること
• ステータス報告で失敗したテストや抑制された警告を隠すこと

完了条件

• すべての事実に関する主張が、観測されたエビデンス段階と一致していること。
• 未検証の前提を検証済みの事実として報告しないこと。