fable-scope-discipline

Fable Scope Discipline

依頼された内容を、適切な範囲で正確に実装します。原因を解消するのに十分な深さで取り組み、ほかには何も触れないよう範囲を絞ります。求められていない改善は親切ではありません。他人の差分に紛れ込んだ、レビューされていないリスクです。

目的

コード変更時の厳格なスコープ境界を徹底します。ついでのリファクタリング、見た目だけの書き換え、憶測に基づく最適化、依頼されていない検証チェック、差分の肥大化を防ぎます。

使用する場面

• 既存のコードベースで変更を実装するとき。
• 近くの関数を整理したり、空白を再フォーマットしたり、変数名を変更したりしたくなったとき。
• 二次的な不具合も「おそらく範囲内だ」と考えたとき。
• タスク上必要とされる以上に多くのファイルや行に及ぶ差分を確認するとき。

使用しない場面

• 広範なリファクタリングやアーキテクチャ移行が明示的に依頼されたとき（fable-simplify または fable-architecture を使用してください）。
• ワークスペース全体から不要なコードや非推奨のシステムを削除するとき（fable-simplify を使用してください）。
• 探索的なプロトタイプや技術検証を作成するとき（fable-discover を使用してください）。

入力

• task_specification：具体的で範囲が限定されたタスク、ユーザーの指示、受け入れ基準。
• current_diff：実装中に生成された作業中の Git 差分。

期待される出力

• bounded_diff：許可された問題だけに対処する、最小限かつ的を絞った差分。
• discovered_items_report：意図的に手を加えなかったほかの不具合をまとめた、要約内の構造化リスト。

手順

1. 依頼された内容を実装する：割り当てられたカードや依頼だけに厳密に集中します。憶測に基づく変更や「ついで」の変更は行いません。
2. 隣接しているだけでは範囲内にならない：「同じ関数」「同じファイル」「同じ種類の不具合」は、単に場所を示すものであり、許可を意味しません。タスクの範囲を定めるのはユーザーの言葉だけです。近接性は何も定めません。
3. 正当化テスト：追加の変更も「おそらく修正の一部だ」と説明しようとしているなら、それは範囲外です。本当に範囲内の変更に正当化は必要ありません。気づいた点は報告に記載し、判断はユーザーに委ねます。
4. 未解決の問いテスト：追加の修正に未解決の設計判断（例：例外を発生させるか、値を丸めるか。何に改名するか）が必要なら、それは独立したタスクである証拠です。他人のバグ修正の中で、仕様上の判断を下すことはできません。
5. 適切な深さで対応する：症状への応急処置にとどめません（あるケースだけを修正し、バグが残る）。かといって書き直しもしません（バグは直るが、無関係なことが50個変更される）。範囲を限定したまま、根本原因を修正します。
6. ついでの変更をしない：変更に必要のない改名、再フォーマット、リファクタリング、依存関係の更新は行いません。差分のノイズに、本質的な変更が埋もれてしまいます。
7. 変更量の予算を守る：差分が依頼内容から想定される規模を大幅に超えている場合は、作業を止め、変更の深さを見直します。
8. 削除する前に確認する：見つかった内容がタスクの説明と食い違う場合、または自分が作成したものではない場合は、無条件に上書きせず、その事実を報告します。
9. 発見事項は報告に記載する：作業中に見つけた実際のバグ、不要なコード、古いドキュメントは要約に記載します。黙って修正したり、黙って放置したりしません。

判断ルール

考え	現実
「依頼されたバグと同じ種類の不具合だ」	分類は分類体系の問題であり、変更の許可ではありません。ユーザーが指定した不具合は1つです。
「同じ関数の契約に関わる」	それも場所の問題です。契約はカーソルの近さではなく、判断によって変わります。
「片方だけ直すのは、一貫した正確性の問題を半分しか解決しない」	問題の境界を定めるのはユーザーです。報告に記載し、境界を引き直すかどうかはユーザーに任せましょう。
「それならスコープクリープではなく、正当な修正の一部だ」	スコープクリープかどうかを議論し始めた時点で、それはスコープクリープです。
「これらはどれも、誰もが異論なく改善だと認めるものだ」	異論がないことは基準ではありません。依頼されたことが基準です。改善はそれぞれ、独立してレビュー可能な差分で行います。
「ユーザーはコード品質を重視していると言った」	それは価値観の表明であり、作業指示ではありません。品質には、独立して適用・取り消しでき、レビュー可能な差分も含まれます。

• ユーザーのシナリオやテストを通すために必要でないコード変更は、元に戻してください。
• 隣接するバグを発見した場合は、フォローアップ項目として報告に記録してください。

ツールポリシー

• 変更した行やファイルを確認するため、git diffを頻繁に実行してください。
• ファイル全体を無差別に再フォーマットするツールは使用しないでください。
• 変更は必要最小限のファイルに限定してください。

証拠要件

• 変更したファイルと行数が想定される影響範囲に合っていることを確認するため、git diff --statを確認してください。
• 依頼されていない付随的な変更に頼らず、最小限の変更でテストが通ることを確認してください。

失敗への対処

次の危険信号に遭遇した場合は、直ちに作業を中断し、差分を縮小してください。

• これから加えようとしている変更の近くに「おそらく」という言葉がある。
• 変更したファイルがコンポーネントの論理的な領域から外れている。
• 同じファイル内の変更していない関数にもフォーマット変更が加えられている。

完了基準

• 差分が、割り当てられたタスクの根本原因に的確に対処している。
• 関係のないファイル、スタイル、依存関係、依頼されていないリファクタリングが追加されていない。
• 追加で見つかった問題が、今後のトリアージに向けてすべて記録されている。