fable-wise

Fable Wise

AI スロップ、複雑性の肥大化、成果物の乖離に対処する、低レベルの認知的反射とアーキテクチャパターンです。推測に基づくコードや定型コードを追加するのではなく、単純化、削減、統合を行い、観察可能な現実に基づいて判断するパターンを徹底します。

目的

Depth、Breadth、Coil、Mesh 全体で認知的反射を活用し、シニアレベルのアーキテクチャ上の知恵を徹底します。肥大化した抽象化を直接的な仕組みに置き換え、単一の信頼できる情報源に統合し、度重なるパッチが当てられた成果物をクリーンな v0 から書き直し、反対意見による批評で計画をストレステストします。

使用するタイミング

• 乖離し、度重なるパッチが当てられた成果物をクリーンな v0 に書き直すとき（/re0）。
• 実行前に、微妙な依頼に対するモデルの解釈を確認するとき（/readchk）。
• 安全でない範囲を最初に切り分け、安全な残りの部分を最大限に活用するとき（/autobahn）。
• 散在する事実を監査し、単一の信頼できる情報源に統合するとき（/ssotize）。
• 付随的なフレームワークやスタックに関する用語を、言語の基本的な仕組みに置き換えるとき（/detool）。
• 新たに下した技術的判断を突き詰め、単純化するか、弱点を明らかにするとき（/feynman）。
• エンジニアリング計画をストレステストし、計画を破綻させかねない反対意見を一つ見つけるとき（/hate）。
• 成果物を独立した評価の観点に分割し、隠れた衝突を明らかにするとき（/prism）。
• リポジトリのクリーンかつ正確なチェックで、提案された変更を試すとき（/sip）。

使用しないタイミング

• 構造的な複雑さがまったくない、定型的な小規模バグ修正（fable-execute を使用）。
• 自動化された依存関係の更新や標準的な CI の修復（リポジトリで承認された保守ワークフローを使用）。
• 高レベルのマルチホストライフサイクルのルーティング（get-fable を使用）。

入力

• engineering_artifact：コードファイル、アーキテクチャ文書、設定、または計画。
• pattern_directive：選択した Paperthin の認知的反射またはコマンド（例：re0、detool、ssotize、hate）。

期待される出力

• debloated_artifact：ネイティブ言語のプリミティブに基づいた、簡素化され、乖離のない成果物。
• consolidated_truth：重複したパラメーターを排除した、単一の信頼できる設定情報源。

手順

1. ステージ 1 — 数量と時間軸による分類：
   • Depth（成果物 1 つ、現在）：この単一の成果物はクリーンで、最小限で、正確ですか？re0、readchk、detool、debloat、feynman を適用します。
   • Breadth（成果物が複数、現在）：すべての場所で一つの事実が一貫していますか？ssotize、reorder を適用します。
   • Coil（プロジェクト 1 つ、複数の反復にわたる）：各サイクルの学びが次に活かされていますか？re0-loop、re0-memo、re0-work、catchup、nba を適用します。
   • Mesh（視点が複数、複数のラウンドにわたる）：グループは一つの事実に収束していますか？prism を適用します。
2. ステージ 2 — 肥大化の除去と仕組みの置き換え：
   • マーケティング用語、宣伝的な形容詞、AI の定型表現を削除します。
   • 付随的なサードパーティライブラリの用語を、標準的な言語の仕組みに置き換えます。
   • 成果物の内容を、要点を支える最小限の密度まで圧縮します。ルールは削らず、言葉を削ります。
3. ステージ 3 — 反対意見による検証とコールドリード：
   • Feynman チェックを適用します。専門用語を使わず、判断を平易な言葉で説明します。
   • Hate チェックを適用します。致命的な欠陥を一つ見つけ、それを否定するための最も低コストなテストを考案します。
   • 第三者の視点で成果物を先入観なく読みます。過去の会話の文脈がなくても、それ単独で意味が通じますか？
4. ステージ 4 — 単一の信頼できる情報源への統合（SSOT）：
   • 複数の文書やモジュールでパラメーターの定義が食い違っている場合、一つを正規の情報源として指定します。
   • すべての派生参照を単一の情報源に向けて更新し、重複による乖離をなくします。

判断ルール

誘惑的な合理化	厳守すべき現実／不変条件	理由
「説明を増やせば、文書がより分かりやすくなる」	違反です。 説明を増やすと、核心となるルールが薄まります。	文書が肥大化すると、エージェントが重要な指示を見落とします。
「このレガシーファイルをもう一度パッチすればよい」	違反です。 パッチが積み重なったら、クリーンな v0（re0）に書き直してください。	パッチを繰り返すと、根底にある設計の劣化が隠れてしまいます。
「誰もがこの計画を素晴らしいと思っている。異議を唱える必要はない」	禁止です。 必ず逆張りテスト（hate）を実施してください。	致命的な欠陥を早期に見つけるのにかかるのは数分ですが、本番環境で見つけると数週間かかります。
「この設定を2か所に複製しても問題ない」	禁止です。 直ちに1つのSSOTに統合してください（ssotize）。	重複した設定は、必ず同期がずれていきます。

• 追加より削除を優先してください。肥大化、乖離、根拠のない前提を取り除きます。
• 成果物の完成とは、これ以上追加できない状態ではなく、必要な動作を損なわずに削除できるものがなくなった状態です。

ツールポリシー

• 標準のファイル閲覧・編集ツールを使用して、重複したコードと設定を統合してください。
• 不要な部分を削減した後、プロジェクトのリンターとテストを実行し、動作が維持されていることを確認してください。
• 標準ライブラリの機能で十分な場合は、サードパーティーのヘルパー依存関係を導入しないでください。

エビデンス要件

• コード行数またはドキュメントの複雑さが全体として削減されたことを示す差分。
• 簡素化の前後で完全な同等性が保たれ、テストスイートがパスすること。

失敗時の対応

• 不要な部分を削減するリファクタリングによって既存のテストが失敗した場合は、隠れた不変条件を特定して明示的に文書化し、テストに合格する動作に戻してください。
• 逆張りの hate チェックで計画に修正不能な欠陥が見つかった場合は、計画を中止し、その欠陥を報告してください。

完了条件

• 冗長な定型文、不要なレイヤー、重複した設定をすべて取り除いている。
• 唯一の信頼できる情報源を確立し、参照するすべてのファイルで確認している。
• テストを実行してパスし、動作の正しさを確認している。