fable-native-code

Fable Native Code

差分は、長年そのファイルを担当してきた人が書いたように見える必要があります。ファイルには、命名、エラー処理、コメントの密度、フォーマットといったスタイルがあります。それに合わせて書いてください。個人的な好みは改善ではなく、単なる癖です。

目的

コードベースの慣例を徹底し、よそから持ち込まれたような AI のパターンを抑えます。過剰な防御的コード、過度なコメント、不要な try/catch ブロック、依頼されていないログ出力、コーディングスタイルを会話調で正当化する説明をなくします。

使用する場面

• 既存のリポジトリでコードを書く、または編集するとき。
• docstring、コメント、型注釈、検証を、それらがないファイルに追加する前。
• 命名規則、エラー処理のパターン、インポート構成を選ぶとき。
• ターンを完了する前に、仕上げた差分をレビューするとき。

使用しない場面

• 確立された慣例のない新規プロジェクトを一から立ち上げるとき（fable-architecture または fable-execute を使用）。
• アーキテクチャ上の境界をリファクタリングしたり、モジュールを疎結合化したりするとき（fable-simplify を使用）。
• パフォーマンスのベンチマークやアルゴリズムの最適化を行うとき（fable-review を使用）。

入力

• source_diff：提案するコードの変更。
• target_file：既存のソースファイル、その周辺の慣例、隣接するモジュール。

期待される出力

• idiomatic_code：周囲のスタイルに自然に溶け込む、簡潔で慣例に沿ったコード変更。
• clean_diff：見た目だけの変更、余計なコメント、過剰な防御的コードのない差分。

手順

1. ファイルのスタイルに合わせる：命名、エラー処理の慣例、コメントの密度、フォーマット、インポートの整理方法に従います。200 行にコメントが 1 つしかないファイルなら、追加するコメントはほぼ確実にゼロです。
2. 不変条件だけをコメントにする：コメントには、コードだけでは示せない制約、注意点、直感に反する実装を選ぶ理由だけを書きます。次の行の説明も、変更についての語り（「X を正しく処理するようになりました」）も、レビュアーに向けた正当化も書きません。
3. 過剰な防御的コードを抑える：問題なく動作するコードを try/catch で囲まないでください。型や呼び出し元が保証する不変条件を検証しないでください。依頼されていないログ、設定、フラグを追加しないでください。
4. 控えたことを語らない：追加しなかったものについて説明したくなる衝動（「注：意図的に doc comment を省略しました。理由は…」）は、それを追加したくなる衝動と同じです。ただ返答に形を変えて表れているにすぎません。コードを届け、ユーザーから求められた場合に限り、スタイルに触れてください。
5. きれいに終える：デバッグ出力、コメントアウトしたコード、自分が作った TODO の残骸を残さないでください。
6. コードベースの語彙を使う：名前には、コードベースですでに使われている語彙を使います。既存の概念に別の名前を新たに付けないでください。

判断基準

対照例：簡潔な Go ファイル

タスク：並べ替えの不変条件を示すコメントだけが 200 行に 1 つある簡潔な Go ファイルに clampWindow を追加します。呼び出し元は max >= 0 を保証します。

よそから持ち込まれたコード（AI の癖であり、ファイルのスタイルではないもの）：

// clampWindow clamps start and end into the valid range [0, max] and
// normalizes inverted windows. Returns (start, start) when end < start.
func clampWindow(start, end, max int) (int, int) {
    if max < 0 {
        return 0, 0 // defensive: should never happen
    }
    ...
}

ファイルになじむコード（ファイルの担当者が書くもの）：

func clampWindow(start, end, max int) (int, int) {
    if start < 0 {
        start = 0
    }
    if end > max {
        end = max
    }
    if end < start {
        end = start
    }
    return start, end
}

• 周囲のコードが早期リターンを使っているなら、早期リターンを使います。
• 周囲のコードがエラーをそのまま呼び出し元に返しているなら、同様に返します。握りつぶしたり、依頼されていない独自エラーでラップしたりしないでください。
• 外側のインターフェースやファイルでエクスポートされたすべてのシンボルに docstring が厳格に求められていない限り、docstring を追加しないでください。

ツールの方針

• 編集する前に隣接する関数を読み、ファイルの慣例を把握してください。
• 空白やインデントのずれを防ぐため、正確な行置換ツール（replace_file_content）を使ってください。
• 同じファイル内の、変更しない行を再フォーマットしないでください。

エビデンス要件

• 変更がファイルに自然に溶け込んでいることを示す、正確な差分を提示してください。
• テストスイートとリンターが通り、スタイルまたは型に関する違反がゼロであることを確認してください。

失敗時の対応

• リンターがスタイルの不一致を指摘したら、プロジェクトのリンタールールに厳密に従ってください。
• 不要なコメントやデバッグ出力が差分に紛れ込んだら、ターンを完了する前にすぐ削除してください。

完了基準

• 差分が、リポジトリの主要メンテナーによって書かれたように読めます。
• 防御的な冗長さ、要求されていないログ出力、不自然なコメントが一切ありません。
• コードがコンパイルでき、既存のスタイルチェックとすべてのユニットテストに合格します。