AI-SLOP Detector スキル

AI支援コードの構造的リスクスキャナー。slop-detector CLIコマンドを実行し、4D スコアリング出力（LDR + ICR + DDC + Purity）を解釈し、scan → diagnose → patch → re-scan → gate → calibrate 品質ループを駆動します。

前提条件

pip install ai-slop-detector          # core
pip install "ai-slop-detector[js]"    # optional: JS/TS
pip install "ai-slop-detector[go]"    # optional: Go

確認: slop-detector --version

---

哲学: 自己参照バイアスの破壊

問題はAIがコードを書くことではありません。問題はAIが確実に導入する特定クラスの欠陥です: 未実装のスタブ、切断されたパイプライン、ファントム インポート、バズワード満載のノイズです。コードは雄弁です。

AI生成コードをAIで修正することへの一般的な批判は自己参照バイアスです: AIは単に自身の好みを検証しているだけではないでしょうか？このループを破るために、AI-SLOP Detectorは厳密に診断ツールとして設計されており、自律型コードジェネレータではありません。開発者とAIが協力しますが、人間がオラクルのままです。

• 意見ではなく証拠。 すべての発見は数学的証拠によって裏付けられています: JSON出力には行番号、AST由来のメトリクス、および式の導出が含まれます。すべてのスコアは「なぜ?」に答えます — LDRが X% を占め、DDC が Y%、純度が Z%、パターンペナルティが W ポイントです。
• 開発者主導のループ。 scan → diagnose → patch → re-scan → gate → calibrate サイクルは人間が主導します。開発者は構造化された証拠をレビューし、何を修正するかを決定し、AIにパッチについて指示します。AIが測定し、人間が判断します。
• 客観的メトリクス。 LDRは実行可能行（AST）を数え、DDCはインポートを解決（importlib.util.find_spec）し、循環複雑度は radon で計算されます。これらは構造的事実であり、スタイルの好みではありません。
• 人間に根ざした キャリブレーション。 自己キャリブレーションはAI判定ではなく、人間の編集行動（git コミット）から ground truth を導出します。
• すべてのレイヤーで監査可能。 --json は完全な証拠チェーンを公開します。ブラックボックスはありません。

---

実行モデル: 3フェーズ パイプライン

すべての /slop コマンドは3つのフェーズで実行されます。フェーズ1と2を完了せずにフェーズ3にスキップしないでください。

Phase 1 — Triage      (すべてのファイルを分類; CRITICAL を即座に表示)
Phase 2 — Deep-Dive   (なぜかを説明; アクションが必要なファイルのみ)
Phase 3 — Action Plan (順序付き修正; 明示的な次のステップ)

信頼度ルーティング (フェーズ2の深さを決定):

ステータス	スコア	フェーズ2の アクション
CRITICAL_DEFICIT	≥ 70	即座 — すべての問題を説明、完全なパッチ ガイダンス
INFLATED_SIGNAL	50–70	完全な深掘り — マージ前にアクション必須
SUSPICIOUS	30–50	最初にトップ2ファイルで /slop-file を実行; エスカレーション前に確認
DEPENDENCY_NOISE	varies	DDCセクションのみ監査 — /slop-file に --json 付き
CLEAN	< 30	フェーズ2をスキップ — クリーンを報告、ゲート提案

フェーズ1トリアージテーブルをセッション コンテキストにベースラインとして保存し、後で /slop-delta 比較用に使用します。

---

コマンド

/slop — フル プロジェクト スキャン

slop-detector --project . --json

フェーズ1 — トリアージ (常に最初に表示):

JSON をパース → deficit_score 降順でソートしたトリアージテーブルを構築:

[TRIAGE]
File                    │ Score │ Status            │ Top Issue
────────────────────────┼───────┼───────────────────┼──────────────────
cli_commands.py         │  45.2 │ SUSPICIOUS        │ empty_except
ddc.py                  │  38.1 │ SUSPICIOUS        │ lint_escape
────────────────────────┴───────┴───────────────────┴──────────────────
Project: SUSPICIOUS  avg=12.4  14 files  2 flagged  Gate track: PASS

フェーズ2 — 深掘り (上記の信頼度ルーティングに従う):

アクションが必要な各ファイルについて、説明します:

1. スコアがその値になっているなぜ — メトリクス分解（LDR X%、DDC Y%、純度Z%）
2. 各パターン問題：行参照、重大度、パッチガイダンスからの具体的な修正
3. SUSPICIOUS ファイル: アクションリストに含める前に slop-detector <file> をインラインで実行

フェーズ3 — アクション プラン:

[ACTION PLAN]
1. cli_commands.py L215 — empty_except → 特定の例外 + デバッグログを追加
2. ddc.py L160 — lint_escape FP → (SUSPICIOUS確認; ブロック不可、監視のみ)
ゲート準備: プロジェクト平均 12.4 → CLEAN の場合のターゲット < 30

→ 次へ: トップ修正を適用、次に /slop-file <最高スコアファイル> で検証、その後 /slop-delta

---

/slop-file [path] — 単一ファイル分析

slop-detector <path> --json

フェーズ1 — トリアージ: 報告: ステータス、deficit_score、LDR / Inflation / DDC / Purity を1行で。

フェーズ2 — 深掘り: 各パターン問題について:

• 重大度、行参照、およびなぜトリガーされたか
• 具体的な修正（パッチガイダンスを参照）

メトリクス説明の閾値:

• ldr_score < 0.30 → 「行の30%未満が実行可能ロジック。重いパディングまたは空のスタブ。」
• inflation_score > 1.0 → 「専門用語密度が閾値を超えています。正当化されない品質クレームが検出されました。」
• ddc usage_ratio < 0.50 → 「CRITICAL: インポートされたモジュールの半分以上が未使用。ファントムインポートの可能性。」
• ddc usage_ratio < 0.70 → 「WARNING: 低いインポート使用率を検出。」
• purity < 0.60 → 「複数の重大なパターンを検出。AND-ゲート スコアが低下。」

フェーズ3 — アクション プラン: 修正を優先度順に列挙（CRITICAL → HIGH → MEDIUM）。問題ごとに1つの具体的なアクション。

→ 次へ: 修正を適用 → /slop-file <path> を再度実行 → スコアを比較 → クリーンの場合 /slop-gate に進む

---

/slop-gate — ゲート決定

2つの異なるゲート パス — コンテキストに基づいて選択:

パスA: SNP ゲート (sr9/di2/jsd/ove メトリクス)

slop-detector <file_or_dir> --gate

正式な SlopGateDecision を生成します。メトリクス: sr9 (LDR)、di2 (DDC比率)、jsd (1-inflation)、ove (1-penalty/50)。 決定: PASS または HALT。

HALT 閾値:

• ldr_score < 0.60
• ddc_ratio < 0.50
• inflation_score > 1.5
• pattern_penalty > 30.0

パスB: CI ハード ゲート (deficit_score / パターン数)

slop-detector --project . --ci-mode hard --ci-report

Exit 0 = PASS、非ゼロ = FAIL。

FAIL 閾値（ハード モード — 1つでもトリガー可能）:

• deficit_score >= 70
• critical_pattern_count >= 3
• inflation_score >= 1.5
• ddc usage_ratio < 0.50

ワークフロー:

1. コマンドを実行; 終了コード / 決定フィールドをキャプチャ
2. 報告: PASS/FAIL、ブロック ファイル、重大パターン数
3. FAIL/HALT の場合: キーメトリクスと最小限のアンロック修正を含むオフェンディング ファイルをリスト
4. PASS の場合: ゲートクリア確認、マージ準備完了

→ 次へ: PASS → マージ | FAIL → ブロック ファイルを修正 → /slop-file <ブロック> → ゲートを再実行

---

/slop-delta — Before/After 比較

パッチ適用後、セッション ベースライン（前に保存したフェーズ1トリアージ）に対する改善を測定するために実行します。

slop-detector --project . --json   # パッチ後に再スキャン

各ファイルの現在の deficit_score をベースライン トリアージと比較:

[DELTA]
File                    │ Before │ After  │ Change  │ Result
────────────────────────┼────────┼────────┼─────────┼────────────
cli_commands.py         │   45.2 │   22.1 │  -23.1  │ CLEAN ✓
ddc.py                  │   38.1 │   35.4 │   -2.7  │ SUSPICIOUS
────────────────────────┼────────┼────────┼─────────┼────────────
Project avg             │   12.4 │   10.8 │   -1.6  │ CLEAN ✓

各ファイルの結果を分類: 改善 / 低下 / 変更なし。 スコアが増加したファイル（回帰）がある場合、即座にフラグを立てて可能な原因を説明します。

→ 次へ: すべてのターゲットが CLEAN → /slop-gate | まだ SUSPICIOUS → /slop-file <ファイル> → 繰り返し

---

/slop-spar — 敵対的 バリデーション

外部依存: fhval は別の Flamehaven バリデーション ツール — ai-slop-detector に含まれていません。

fhval spar
fhval spar --layer a    # 既知パターン アンカー
fhval spar --layer b    # メトリクス境界 プローブ
fhval spar --layer c    # 存在 プローブ

ワークフロー:

1. fhval がインストール されていることを確認（fhval --version）
2. 完全な3層チェックを実行
3. 検出されたキャリブレーション ドリフトを報告
4. メトリクククレームが測定動作と相違する次元を フラグ
5. ドリフトが見つかった場合: slop-detector . --self-calibrate --apply-calibration を推奨

→ 次へ: ドリフト検出 → 自己キャリブレーション → 新しい重みで /slop を再実行

---

ステータス解釈

ファイルレベルの ステータス:

ステータス	スコア	アクション
CLEAN	< 30	アクション不要 — クリーンを報告
SUSPICIOUS	30–50	2回目の /slop-file; エスカレーション前に確認
INFLATED_SIGNAL	50–70	マージ前に修正; おそらく AI パディング
DEPENDENCY_NOISE	varies	DDC < 20% でクリーン パターン; インポートを監査
CRITICAL_DEFICIT	≥ 70	マージをブロック; 今すぐ修正

DDC 閾値ゾーン:

DDC usage_ratio	効果
< 0.20	DEPENDENCY_NOISE (重大パターン なし かつ inflation ≤ 1.0 の場合)
< 0.50	CRITICAL 警告; CIGate ハード モード FAIL
< 0.70	WARNING; ゲート アクション なし

プロジェクトレベル ステータス (weighted_deficit_score = 0.6 * min + 0.4 * mean):

ステータス	閾値
CLEAN	< 30
SUSPICIOUS	30–50
CRITICAL_DEFICIT	≥ 50

---

パッチガイダンス — パターン別

パターン	修正
not_implemented / pass_placeholder	関数本体を実装するか、スタブを削除
phantom_import	インポートを削除; 必要な場合、実際のパッケージをインストール
empty_except	特定の例外タイプと処理ロジックを追加
god_function	フォーカスされたユニットに分解（各々≤ 50行）
function_clone_cluster	共有ロジックを単一ヘルパーに抽出
dead_code	到達不可能なブランチを削除
todo_comment / fixme_comment	解決するか、追跡課題をファイル; インライン コメントを削除
star_import	明示的な名前付きインポートに置き換え
placeholder_variable_naming	単一文字パラメーターを説明的な名前に変更
return_constant_stub	計算値を返すか、NotImplementedError を発生
lint_escape	基礎となるリント エラーを修正; 抑止が必須の場合、# noqa: CODE を追加

---

Scan → Diagnose → Patch → Re-scan → Gate → Calibrate ループ

Step 1  /slop              scan:     3-フェーズ ベースライン; トリアージをセッション ベースラインとして保存
Step 2  Review Phase 2     diagnose: 各メトリクスを説明; CRITICAL_DEFICIT を優先順位付け
Step 3  Apply patches      patch:    パッチガイダンスを使用; 開発者が何を修正するかを決定
Step 4  /slop-file <path>  re-scan:  各修正ファイルを個別に検証
Step 5  /slop-delta        compare:  before/after テーブル; 改善を確認
Step 6  /slop              re-scan:  プロジェクト集計が改善したことを確認
Step 7  /slop-gate         gate:     マージ前の PASS/FAIL 決定
Step 8  (auto) calibrate   calibrate: LEDA が改善イベントを登録; 重みを自動調整

デルタ ルール: 再スキャン後（ステップ4–5）、常に deficit_score 変化を報告: before → after (Δ)。測定されたデルタなしに「修正」と言わないでください。

---

自己キャリブレーション (スコアがおかしい場合)

slop-detector . --self-calibrate                       # 推奨される重みをプレビュー
slop-detector . --self-calibrate --apply-calibration   # .slopconfig.yaml に書き込み

2ゲート自動トリガー: (1) 外側 — 10マルチランファイル マイルストーンごと; (2) 内側 フロア — クラスごと ≥ 5 改善イベント および ≥ 5 fp_candidate イベント必須（不十分なシグナルは insufficient_data を返す）。ドメイン アンカー付き（プロファイル ベースラインから ±0.15）。

---

ドメイン プロファイル

slop-detector --init                        # ドメインを自動検出
slop-detector --init --domain data_science  # 明示的な上書き

プロファイル: general、scientific/ml、scientific/numerical、web/api、library/sdk、cli/tool、bio、finance

---

追加 CLI オプション

slop-detector --project . --emit-leda-yaml                         # LEDA レビュー サーフェス
slop-detector --project . --emit-leda-yaml --leda-profile public   # パブリック レダクション
slop-detector src/ --cross-file                                    # 依存関係 + クローン グラフ
slop-detector src/ --governance                                    # CR-EP セッション アーティファクト
slop-detector --project . --json   # ≥10 履歴実行時に ml_score が存在

---

スコアリング モデル リファレンス

purity        = exp(-0.5 × n_critical_patterns)
GQG           = exp( Σ(w_i × ln(max(1e-4, dim_i))) / Σw_i )   -- 加重幾何平均
deficit_score = 100 × (1 - GQG) + pattern_penalty

デフォルト重み: ldr=0.40, inflation=0.30, ddc=0.20, purity=0.10 プロジェクト集計: 0.6 × min + 0.4 × mean (SR9 conservative)