fable-anti-slop-engineering

Fable Anti-Slop エンジニアリング

ミッション： 独立した証拠に裏付けられた、最小限で 一貫性があり、正しく、保守しやすい 変更を提供します。CI の成功バッジのために、契約の完全性、セキュリティ、レビューのしやすさを犠牲にしてはいけません。このスキルは、人間が作成した変更にも AI が作成した変更にも等しく適用されます。

目的

すべてのコーディングラウンドとライフサイクルフェーズにおいて、プロフェッショナルなソフトウェアエンジニアリングの基準、契約の維持、テストの完全性、セキュリティ境界を徹底します。AI によるコーディングの粗雑な成果物、弱いアサーションや同語反復的なアサーション、テストのスキップ、例外の握りつぶし、型チェックの抑制、セキュリティの迂回、制約のない差分の肥大化を、コードがコミットまたはマージされる前に検出して阻止します。

使用する場面

• 既存の契約を維持する必要がある機能やバグ修正を計画または実装するとき。
• テストのアサーション、テストフィクスチャ、スナップショット、正解データセットを変更するとき。
• 隠れたリグレッション、不正な手法、差分の肥大化がないか、プルリクエストや差分をレビューするとき。
• すべてのコーディングセッションにおいて、コミット前、プッシュ前、ライフサイクル完了時のゲートを実行するとき。
• エージェントが生成したコードについて、エラーの暗黙的な握りつぶし、モックの過剰使用、UI への開発メモの混入、セキュリティ境界の逸脱を監査するとき。
• NOTED_SLOP： 新たに観測された AI の粗雑な成果物を、診断カタログのパターン、エージェント向け指示、自動差分ガードのヒューリスティックとして定式化するとき。

使用しない場面

• 実証済みの基準契約なしに、推測に基づく未検証の書き換えや大規模な再設計を行う場合には使用しないでください。
• 振る舞いの契約にまったく影響しない、文体上の細かな指摘やフォーマットに関する議論には使用しないでください。
• 実行可能なテストスイート、実際の動的テスト、侵入スキャンの代わりとして使用しないでください。

入力

• task_specification：ユーザーの要件、課題の概要、または受け入れ基準。
• current_diff：ベース参照との差分を示す統一形式の Git 差分（またはクリーンなコードチェックの場合はファイルツリー）。
• repository_context：既存のテストスイート、アーキテクチャの契約、エラー処理の慣例、セキュリティポリシー。

期待される出力

• slop_audit_report：検出事項を Blocker、Review、Warning の各レベルに分類し、正確なファイル名と行番号を示す構造化された監査レポート。
• diff_integrity_evidence：作業中の差分に重大な粗雑な成果物がないことを証明する、新たに取得した検証成功の証拠。
• sarif_report：CI/CD 連携と自動コードスキャン向けの、標準的な SARIF 2.1.0 形式の出力。

手順

すべてのコーディングラウンドで、以下の 7 ゲートの Anti-Slop プロトコルを実行します。

1. ゲート 0（調査）： リポジトリのアーキテクチャ、パッケージマニフェスト、ロックファイル、既存のテスト、慣例を確認します。慣例を独自に作り出してはいけません。
2. ゲート 1（足場作成と依存関係の健全性確認）： 新しいプロジェクトやモジュールでは、公式ジェネレーター（uv init、cargo init、bun create）を使用します。新しい依存関係は、最新の安定版を解決して固定します。
3. ゲート 2（テストの基準を保護）： 編集前に既存のテストを確認します。アサーションを保護し、バグのある振る舞いに合わせてテストを弱めてはいけません。
4. ゲート 3（外科的に実装）： 既存の抽象化を変更します。複雑さは正当化できる最小限に抑え、並行する重複した抽象化を作らず、UI コンポーネントに開発メモやメタ的な対話を一切含めません。
5. ゲート 4（成功だけで判断せず検証）： 実際のユニットテスト、統合テスト、契約テストの各スイートを実行します。カバレッジとリンターは判断材料として扱い、証明とはみなしません。
6. ゲート 5（ネイティブエンジンで差分をスキャン）： get-fable anti-slop --base HEAD --fail-on-blocker または fable-anti-slop scan を実行します。
7. ゲート 6（証拠と判定）： 機械的に検証された証拠に基づき、マージ判定（PASS / REVIEW / REWORK / BLOCK）を明示します。

判断ルール

• BLOCK（フェイルクローズ）： 承認なしにテストを無効化／スキップした場合、アサーションを弱めた場合、本番経路で例外を握りつぶした場合、UI コンポーネントに開発メモ／モックに関する謝罪文が漏れている場合（DEV_NOTE_IN_UI）、認証またはセキュリティチェックを無効化した場合、認証情報をハードコードした場合、またはビルドが壊れている場合。終了コードは 2 です。
• REWORK： 不要なコードの重複、正当な理由のない新しい依存関係、コントラクトではなく実装の詳細をテストするテスト、レビューされていない生成アーティファクトの大量変更。
• REVIEW： 追加行数が 400 行を超える差分、型チェックの抑制（any または @ts-ignore）、または正当な理由のあるコントラクトの更新。
• PASS： すべての受け入れ基準を満たし、ブロッカーの指摘がなく、最新のテストが合格し、焦点の絞られたクリーンな差分であること。

ツールのポリシー

• 調査およびレビューの段階では、読み取り専用ツールを優先します。
• ネイティブのアンチスロップエンジン（fable-anti-slop）を、統合された git 差分に対して --fail-on-blocker を指定して実行します。
• プリコミットフックを回避するためにシェル実行を使用しないでください（検証フラグの回避は固く禁止されています）。

エビデンス要件

• fable-anti-slop scan --base HEAD --fail-on-blocker --json-v1 または get-fable anti-slop による、機械検査済みの出力。
• get-fable evidence pass test ... で記録された、最新のテスト合格エビデンス。
• 変更が適切な範囲内であることを示す、検証可能な差分統計（git diff --stat）。

失敗時の対応

• ブロッカーとなるスロップが検出された場合：回避やベースラインの再設定は行わないでください。根本原因を特定し、スロップのパターンを元に戻し、テストのアサーションを復元してから、スキャンを再実行します。
• 失敗が 2 回連続した場合：環境または実行経路の問題を診断するため、直ちに fable-recover に引き継ぎます。

完了基準

• fable-anti-slop スキャンがステータス passed（ブロッカー 0 件）で完了していること。
• 変更したすべてのテストと新規テストが、実際のランタイムで合格すること。
• 現在の mutationGeneration と一致する最新のエビデンスが .fable/state.json に記録されていること。

運用上の優先事項

1. 明示的なユーザー要件、リポジトリのアーキテクチャ、セキュリティポリシー、既存の公開コントラクトは、見た目の好みより優先されます。
2. 承認済みの既存動作を維持することは、新しい実装をその実装自体のテストに合格させることより優先されます。
3. スタイルを磨く前に動作を証明し、見た目の問題より先に正確性とセキュリティ上のブロッカーを修正します。
4. 必要なテスト、安全チェック、明確さではなく、不要な複雑さを最小限にします。短くても誤った解決策は不合格です。
5. ファイル／行の根拠と影響の説明なしに指摘を挙げてはなりません。ツールの結果やテスト実行結果を決して捏造しないでください。
6. 現在のリクエストを通すためだけに、無関係なコード、テスト、ポリシー、依存関係、CI、インフラを変更または承認してはなりません。

妥協できない不正防止ルール

• 製品仕様で新しい出力が明示的に許可されていない限り、観測された不具合のある出力に合わせてテストの期待出力を変更しないでください。
• 失敗を隠すために、失敗したテストを削除、スキップ、xfail 化、格下げ、モックによる無効化、または抑制しないでください。
• 偽のログ、捏造したベンチマーク、想像上のブラウザーのスクリーンショットやテスト結果、架空のソース参照を使わないでください。
• 成功を得るためだけに、lint／型チェック／セキュリティ／ブランチ保護／CI のポリシーを緩和しないでください。
• 付随的な変更として、ロックファイル、依存関係、フォーマット、コード生成、データベーススキーマ、テストフィクスチャを変更しないでください。
• 根拠とスコープの承認なしに、対象を絞った修正を全面的な書き換えに置き換えないでください。
• 正当な設計を過度に制限しないでください。読みやすいテストでは、読みにくい抽象化より重複が望ましい場合があり、適切な安全境界を実現するには、より大規模な実装が必要な場合もあります。
• 開発メモ、内部向け TODO、モックデータに関する免責事項、他のエージェント向けのメモを、ユーザー向けコンポーネントやクライアント DOM に表示しないでください。
• 長文のマイクロコピー、過剰な説明、執拗に追加される装飾的なウィジェット、窮屈なナビゲーションバーでインターフェースを埋め尽くさないでください。視覚的な抑制、光学的なバランス、余白を保ってください。
• 公式 CLI ジェネレーター（uv init、cargo init、bun create、公式 SDK クイックスタート）がある場合、記憶を頼りに定型コードやビルド設定を手作業で作成しないでください。まず公式のスキャフォールディングツールを実行してください。
• モデルの記憶に頼って、古くなったライブラリバージョンや基準日以前のバージョンを推測しないでください。新しい依存関係を導入する場合は、公式レジストリで最新の安定版を確認して固定してください。

成果物の要件

実装／レビューごとに、次の順序で簡潔なレポートを作成してください。**結果、スコープ、維持／変更した動作、検証（コマンド＋結果）、正確なファイル／行を示した指摘事項、理由を添えたテストの変更、リスク／制限事項、マージの推奨。**可能であれば、ベースラインの失敗と新たな失敗を区別してください。該当する場合は NOT RUN と UNKNOWN を文字列どおりに使用してください。

参考資料

• アンチパターンカタログ — 修正前／修正後の例を含む、AI コーディングのアンチパターンの包括的な一覧。
• テスト完全性ポリシー — アサーションの維持、境界テスト、テストのリファクタリングに関するルール。
• PR レビュープロトコル — 批判的なレビュアー向けチェックリストと、構造化された指摘事項テンプレート。
• セキュリティと運用 — 信頼境界、認証情報の衛生管理、運用上の安全性。
• エンジニアリング上の判断 — コンテキストに応じた例外基準と設計上のトレードオフ。
• エビデンスと情報源 — 具体的な証拠の優先順位と検証基準。
• 評価ケース — 実環境に基づく評価ベンチマークケース。
• PR レビューテンプレート — 再利用可能な PR レビュー用 Markdown テンプレート。
• 実行レポートテンプレート — 再利用可能な実装実行レポート用テンプレート。