fable-context-thrift

Fable Context Thrift

コンテキストは、ほかのすべての作業がそこから予算を割り当てられる基盤です。次のアクションを変える情報にだけ使い、それ以外には使わないでください。

目的

コンテキストの肥大化、トークンの枯渇、不要なファイル全体の読み込み、冗長な検証、逐次実行による遅延を防ぎます。fable-context-thrift は、コンテキストトークンとツール呼び出しを希少で価値あるエンジニアリング予算として扱います。

使用する場面

• 複数ステップのタスクの開始時、およびコードベースを調査する際。
• ファイルの読み込み、シンボルの検索、リポジトリ構造の確認を行う前。
• 対象を絞った範囲、シンボル、関数ではなく、ファイル全体を読みたくなったとき。
• 独立した複数の検索や確認を並列にまとめて実行できるとき。

使用しない場面

• 未知のサブシステムの構造を把握するために、コードベースを網羅的に調査する必要がある場合（fable-discover を使用）。
• 外部 API のドキュメントや一次資料を調査する場合（fable-research を使用）。
• 分散した信頼境界をまたいで脆弱性を詳しく追跡する場合（fable-security を使用）。

入力

• exploration_intent：解決すべき、具体的で重要な疑問や不確実性。
• workspace_state：すでに確認済みの事実、開いているファイル、以前のツール出力。

期待される出力

• targeted_evidence：最小限で有用性の高いコード抜粋、行番号への参照、正確な事実。
• decision_readiness：余分なトークンを一切使わず、「行動に移るのに十分」な基準に達したことの確認。

手順

1. 対象を絞った読み取り戦略：ファイルではなく、必要なシンボルやセクションだけを読みます。具体的な疑問に応じてのみ範囲を広げます。
2. 並列ブロックでのまとめ処理：複数の grep、読み込み、状態確認は、1つの並列ブロックで実行します。独立した読み込みを逐次実行しても、慎重さは増さず、遅延が増えるだけです。
3. 広範な調査は委任し、単独の検索は自分で行う：「X はどこで処理されているか」や、把握していない領域での全使用箇所の検索といった広範な質問は、利用可能であれば検索サブエージェントに任せます。ファイルの内容ではなく、結論を手元に残します。場所がわかっている単独の検索は直接行います。サブエージェントを使うのは、対象の場所がわからない場合です。
4. ツール確認の原則：編集が反映されたかを確認するためにファイルを再読してはいけません。編集ツールは失敗を明確に報告します。結果は、ファイルごとの再読み込みではなく、古いトークンを grep で検索するなど、安価な終了時確認を1回行って検証します。
5. 確立済みの事実を維持する：会話ですでに確認したことを再導出しないでください。ユーザーがすでに決めたことを蒸し返さないでください。
6. 説明の無駄を省く：採用しない選択肢について説明しないでください。熟考は、実際に選ぶ可能性のある選択肢に限ります。
7. 行動に移るのに十分かの確認：さらに調査しても次のアクションが変わらないなら、調査は終了です。行動に移してください。

判断ルール

考え	実際のところ
「コンテキストを把握するためにファイル全体を読もう」	変更が及ぶ箇所を読みます。答えるべき疑問によって、必要な行が決まります。
「編集が反映されたか、念のためもう一度確認しよう」	ツールが成功を報告したなら、何も言わないことが成功です。何度も読み直すより、終了時に grep を1回実行するほうが確実です。
「念のため、もう1回検索しよう」	結果によって行動が変わらないなら、それは安全策ではありません。証拠集めをしながら先延ばししているだけです。
「まずリポジトリの構成を再確認しよう」	その構成はコンテキストにあり、1時間前にも正しいことを確認済みです。ディレクトリツリーはセッション中に劣化しません。
「慎重に進めるなら、呼び出しは1つずつ」	慎重さとは、適切な呼び出しを行うことです。独立した検索を逐次実行するのは、同じ作業を遅く行うだけです。
「念を入れるためにサブエージェントを呼ぼう」	40ファイルのリポジトリなら、grep はサブエージェントの説明より速く、行単位で正確な情報を返します。対象に合ったツールを選びましょう。

• 追加の検索結果によって次のコマンドや編集が変わらないなら、検索しないでください。
• 編集が問題なく成功したら、変更後のファイルを再表示せず、そのまま検証に進んでください。

ツールポリシー

• 独立した読み取りツールと grep ツールの呼び出しは、すべて1つのメッセージ／ターンにまとめてください。
• ファイルを確認する際は、行オフセットと対象を絞った範囲（StartLine、EndLine）を使用してください。
• ripgrep で正確な行番号がすでに得られている場合は、ファイル全体の読み取りを拒否してください。
• シンボルを探す際は、ファイルツリーの探索よりも、対象を絞った ripgrep クエリを優先してください。

証拠要件

• 関数本体全体を会話に貼り付けるのではなく、行単位の引用（path/to/file#L10-L25）を報告してください。
• 編集が適用された証拠として、編集後の状態を1回だけ確認してください（例：削除したトークンを grep で検索する、または終了コードを確認する）。
• 同じセッション内で再実行による証拠を求めず、確立済みの事実を維持してください。

失敗時の対応

次のレッドフラグに遭遇したら、ただちに作業を止めてください。

• このターンで編集したファイルに対する Read 呼び出し。
• 同じセッションで同じ事実を2回検証すること。
• データ依存関係のないツール呼び出しを順番に行うこと。
• 判断の目的を説明できない探索ステップ。
• grep ですでに行番号が得られている箇所を、ファイル全体から読み取ること。

完了条件

• トークン消費を最小限に抑えて、重要な問いに答えていること。
• 次のエンジニアリング作業にすぐ着手できること。
• 実装、検証、差分レビューのためにコンテキストの余地を確保すること。