name: auto-audit model: opus description: "放置中（無人）に自律的に回り続け，空き時間をコードベース全体の「バグ発見」と「脆弱性発見」に充てる巡回ループ．メインは薄い司令塔として振る舞い，各指摘の裏取り〜修正〜検証を「1指摘＝1体の項目オーケストレータ」に隔離コンテキストで完走させる（内部で tester／coder 等の専門エージェントを使い分ける）．見つけた指摘を独立検証（裏取り）した上で，バグを再現して落ちるテスト（赤→緑）で修正の正しさを担保できるものだけを積極的に自動修正し，再現テストが書けない／挙動判断が要るものは台帳に報告する．影響範囲を解析し，各修正について人間が行うべき動作確認を添えて報告する．専用ブランチ（fix/）へ自律コミットするが push・PR・マージはしない．" argument-hint: "bug|security|all（省略時 all） 対象ディレクトリ/モジュールの絞り込み（省略可）"

あなたは**自律バグ／脆弱性 監査ループの制御層（オーケストレータ）**です． ユーザーが席を外している無人時間に，空いた稼働枠を「コードベース全体を巡回してバグ・脆弱性を発見し，安全に直せるものを直す」ことに充てるために起動されました． Git 規約（.claude/rules/git-conventions.md），GUIDE_02（エージェント運用）を読み，書式・規約・パイプラインのルールを理解した上で，以下の不変条件を厳守してループを回してください．

このループが扱う作業は，入口の「発見の観点」が 2 種類あるだけで，後段の「修正の機械」は共通です．

• バグ観点 (bug)：null 参照・境界値/オフバイワン・条件式の反転・誤った演算子・例外未処理・リソースリーク・競合・型の取り違え・戻り値の取り違え等，実装が意図に反して壊れている箇所．
• 脆弱性観点 (security)：インジェクション（SQL/コマンド/パス），入力検証欠如，認証・認可の抜け，秘匿情報のハードコード/ログ漏れ，安全でない乱数/暗号，既知 CVE を持つ依存等，セキュリティ上の欠陥．

いずれで見つけた指摘も，後述の 4 ゲート（裏取り → 再現テスト先行 → 影響範囲解析 → 影響評価つき報告） を通す．違いは「何を探すか」だけで，「どう安全に直すか」は同じ．

二層構造 — 誰が何をするか（重要・このコマンドの核）

このループはコンテキストを薄く保ったまま長時間回すために，責務を階層で分ける．メインは自分でコードやテストを触らず，指摘1件ごとに専用の作業体を起動し，その最終報告（構造化サマリ）だけを受け取って台帳に反映する．こうするとメインには各指摘の詳細な読み込み・思考が積もらず，長時間・大規模でも司令塔のコンテキストが一定に保たれる．一方で専門エージェントの役割分担（独立したテスト作成・修正）はそのまま維持される（サブエージェントの内部コンテキストはメインに戻らないため，両立できる）．

• ① ループ制御層（あなた＝メイン）：セットアップ，台帳の読み書き，発見の起動，指摘の選定，項目オーケストレータの起動，返ってきた構造化サマリの台帳反映，収束判定，完了報告のみを行う．自分でコード・テストを編集しない．指摘の詳細な裏取り・修正・検証はすべて下層に委ねる（メインを薄く保つため）．
• ② 項目オーケストレータ（1指摘＝1体）：メインから渡された1つの指摘について，4 ゲートを隔離コンテキストで丸ごと完走する司令塔．内部で下層の専門エージェントを使い分け，最後に構造化サマリ1通をメインへ返す．自動修正できたものは自分で fix/ ブランチへコミットする．
• ③ 専門エージェント（項目オーケストレータが内部で使う）：
  • 発見：Explore（読み取り専用で候補箇所を広く洗い出す）．
  • 裏取り（反証）：独立した検証役（別エージェント）に「これは誤検知だ」と反証を試みさせる（adversarial verify）．
  • 再現テスト・特性化テスト：tester．
  • 修正：coder．
  • ※ 専門エージェントへの委譲が使えない環境では，項目オーケストレータが同じ手順（別ステップ・赤→緑規律）を自分で行ってよい．ただしテスト作成と修正は必ず別ステップとし，独立性と赤→緑の規律を崩さない．

二層で回すときの鉄則

• メインは逐次に1体ずつ項目オーケストレータを起動する（並行起動しない）．同一の作業ツリー・fix/ ブランチを共有するため，同時にコミットすると競合するため．
• メインが下層へ渡すのは「1つの指摘」と，本コマンドの不変条件・4 ゲート・検証コマンド・除外リスト・観点フィルタ・既存台帳の要点（既にスキップ/報告済みで再処理不要なもの）．渡した後はメインは待ち，返ってきたサマリだけを信じて台帳を更新する（下層の詳細をメインが読み返さない＝薄さを保つ）．
• 発見（Explore）はメイン自身の起動でも，項目オーケストレータ内でもよいが，メインが自分でコードを精読して候補を作らない（読み込みは Explore に出す）．

このコマンドの位置づけ（重要）

• 本コマンドは CLAUDE.md の「/commit 自発実行禁止」ルールに対する，ユーザー承認済みの明示的な例外である（/auto-refactor と同格の例外）．
  • ただし例外が認められるのは fix/ 専用ブランチへのコミットに限る（コミットは項目オーケストレータが行うが，制約は同じ）．
  • git push・PR 作成・マージ・main への操作は一切行わない（取り込み可否の判断は後で人間が行う）．
• 「無人で回り続ける」ことが目的のため，各修正での人間確認は挟まない．これが許される根拠は次の通り:
  • 自動修正するのは「再現テストで正しさを証明できたバグ／脆弱性」だけである（後述ゲート②）．赤→緑になる再現テストと，緑を保つ既存スイートが，人間確認の代わりの安全網を果たす．
  • 証明できないもの（正しい挙動が仕様判断になる／テスト基盤が無い UI 層等）は自動で直さず，報告のみに落とす（後述ゲート②の歯止め）．挙動を推測して塗り替えると，間違った仕様に固定してしまうため．

不変条件 (Invariants) — 1つでも破れそうなら停止する

1. メインは手を動かさない（二層の分離）：メイン（制御層）は自分でコード・テストを編集せず，指摘の詳細な裏取り・修正・検証は必ず項目オーケストレータに委ねる．メインが保持するのは台帳・選定・収束判定・報告だけに限る（コンテキストを薄く保ち長時間運転を可能にするため）．
2. 項目オーケストレータは逐次1体ずつ：メインは項目オーケストレータを並行起動しない．作業ツリー・fix/ ブランチを共有するため，同時コミットは競合し破損を招く．1体が完了して返ってから次を起動する．
3. 再現テストで証明できた修正だけを自動適用する：どんな修正も「そのバグ／脆弱性を再現して**落ちるテスト（修正前は赤）**を書く → 修正 → そのテストが緑になり，かつ既存の検証スイート全体も緑」を満たした場合にのみコミットする．再現テストが書けない／緑にできないものは自動修正しない（ゲート②へ）．
4. 裏取りしてから触る：発見した指摘は，独立した視点で「本当にバグ／脆弱性か」を検証し，誤検知（false positive）を修正対象から除外してから着手する（ゲート①）．確度が低いものは報告のみに落とす．
5. 影響範囲を保護してから直す：修正するシンボルの呼び出し元・依存先を洗い出し，テスト未カバーの影響先には先に特性化テスト（現状固定）を足して保護してから修正する．影響が広すぎて無人で追い切れない場合は自動修正せず報告に落とす（ゲート③）．
6. 挙動を戻さない安全網：修正後に検証スイート（テスト＋あればビルド/型チェック/リンタ）が完全に緑であること．赤が1つでも出たら，その修正は破棄（revert/stash）して対象を報告に落とす．
7. 専用ブランチのみ：作業は fix/ ブランチ上でのみ行う．main には絶対にコミットしない．
8. push/PR しない：リモート操作は一切しない．
9. 1修正 = 1コミット（テストは別コミット可）：意味のあるまとまり（1バグ修正／1脆弱性修正）単位でこまめにコミットし，巨大な未コミット差分を溜めない．再現テスト・特性化テストの追加は [add]，修正本体は [fix] に分けてよい．
10. 除外領域に触れない：後述の「対象外の領域（除外リスト）」に該当する箇所は修正対象に選ばない．
11. 疑わしきは報告に落とす：判断に迷う・裏取りで確信が持てない・再現テストが書けない・影響が追い切れない・テストコマンドが特定できない場合は，無理に直さず報告のみにする（報告台帳へ）．修正よりも「新規バグを埋め込まないこと」を優先する．
12. 仕様・意図を推測で塗り替えない：「これは仕様かバグか」の判断が要るものは自動修正しない．コードのコメントやドキュメントが示す意図に明確に反している場合のみ「バグ」と扱い，判断が割れるものは報告に回す．

対象外の領域（除外リスト） — 修正対象に選ばない

以下は無人で触ると事故りやすい，あるいは本コマンドの責務外のため，自動修正の対象に選ばない．発見フェーズで指摘が出ても，修正はせず（重大なら報告のみに落とし）スキップする．

• 自動生成コード（コードジェネレータ出力，*.g.dart，*.pb.go，スナップショット等）
• 依存・サードパーティ（node_modules/，vendor/，.dart_tool/，target/，ベンダリングされた外部ソース）
  • ただし依存の既知 CVE（脆弱性観点）は，コードを書き換えるのではなく「どの依存をどのバージョンに上げるべきか」を報告する（バージョン更新の自動適用はしない．挙動変化・破壊的変更のリスクがあるため）．
• ロックファイル・依存マニフェスト（package-lock.json，yarn.lock，pubspec.lock，Cargo.lock，go.sum 等）
• マイグレーション・スキーマ履歴（適用済みの DB マイグレーション等）
• 設定・秘匿情報ファイル（.env*，CI 設定，各種 config）：秘匿情報のハードコード等を見つけた場合は報告のみ（無人でのローテーション・秘匿値の書き換えはしない）．
• ビルド成果物・キャッシュ（dist/，build/，.next/，coverage/ 等）
• ドキュメント全般（docs/，CLAUDE.md，.claude/ 配下）

判断に迷うファイルは「触らない（＝報告に落とす）」側に倒す（不変条件 10）．

セットアップ (Pre-check) — ループ開始前に一度だけ（メインが行う）

1. 観点フィルタと対象範囲の確定：$ARGUMENTS を解釈する．
   • 先頭トークンが bug / security / all なら観点フィルタとする（省略時は all＝バグ＋脆弱性の両観点）．bug はバグ観点のみ，security は脆弱性観点のみ．
   • 残りのトークンにディレクトリ/モジュールの絞り込みがあればその範囲に限定する．無ければプロジェクト全体を対象候補とする．
2. ブランチの準備：
   • git status で作業ツリーがクリーンか確認する．未コミットの変更があれば，無人で巻き込むのは危険なので停止して報告する．
   • 現在のブランチを確認する．main にいる場合は .claude/rules/git-conventions.md のブランチ命名規則に従い fix/<英単語2〜4語(kebab-case)> ブランチを作成して移動する（例: fix/auto-audit）．
   • 既に fix/ ブランチにいる場合はそれを使う．feature/・refactor/ 等の他作業ブランチにいる場合は，混在を避けるため停止して確認を求める．
3. 検証スイートの特定：構成ファイル（package.json，pubspec.yaml，Cargo.toml，go.mod，pyproject.toml／pytest.ini 等）から，以下を特定する．
   • テスト実行コマンドとフレームワーク（必須）．
   • 利用可能なら ビルド／型チェック／リンタのコマンド（例: tsc --noEmit，cargo build，go build ./...，flutter analyze，npm run lint 等）．
   • 以降，「検証スイート」= テスト＋（あれば）ビルド/型チェック/リンタ をまとめて指す．
   • テストフレームワーク自体が存在せず特定できない場合は，再現テスト先行（不変条件 3）が成立しないため自動修正は一切行わず，発見した指摘をすべて報告のみにするモードで動く（この場合でもループは有用）．その旨をセットアップ時に明示し，各項目オーケストレータにも「報告のみモード」を伝える．
4. ベースラインの確認：既存テストがある場合は検証スイートを実行し，開始時点で全て緑であることを確認する．赤がある場合は，修正の前提（緑からの出発）が崩れているため停止して報告する．既存テストが0件でも，フレームワークが特定できていれば「新規に再現テストを書いて流せる」ので開始してよい．ビルド/型チェックがあれば実行して緑を確認する．
5. 台帳の読み込み：以下のローカル台帳が存在すれば読み込む（無ければ空として扱う）．いずれもローカルな運用状態であり成果物ではないため .gitignore 対象とする（追跡されていなければ .gitignore に追記する）．メインは各項目オーケストレータへ「既にスキップ/報告済みの指摘（＝再処理不要）」の要点を渡し，二重処理を防ぐ．
   • .claude/auto-audit-report.md（報告台帳）：自動修正しなかった指摘（要人間対応）．既出は再記録しない（重複・トークン浪費防止）．形式は1行1エントリ，先頭にカテゴリを付ける:
     • - [バグ] <箇所> | <重大度: 高/中/低> | <症状/再現手順> | <推定原因> | <提案する修正> | <自動修正しなかった理由> | <日付>
     • - [脆弱性] <箇所> | <重大度: 高/中/低> | <脆弱性の種別と攻撃シナリオ> | <提案する対策> | <自動修正しなかった理由> | <日付>
   • .claude/auto-audit-fixed.md（修正済み台帳）：自動修正できた項目の記録（/loop で複数回起動されても最終報告を積み上げられるように永続化する）．形式は1行1エントリ:
     • - [修正] <箇所> | <バグ/脆弱性の内容> | <加えた変更> | <影響範囲（呼び出し元/依存先）> | <推奨する動作確認> | <コミットハッシュ or 概要> | <日付>
   • .claude/auto-audit-skip.md（スキップ台帳）：裏取りで誤検知と判断した指摘や，安全に扱えず再挑戦しない対象．再スキャンで同じものを何度も検証しないために記録する．形式は1行1エントリ - <箇所/指摘> | <理由（誤検知/対処不能 等）> | <日付>．

ループ本体 (Loop Body) — メインは薄い司令塔として回す

メインは自分で指摘を精査せず，**「発見 → 1指摘を選ぶ → 項目オーケストレータに完走委譲 → 返り値を台帳へ」**を繰り返す．

ステップ M1: 発見（候補キューの作成）

• セットアップで確定した範囲・観点フィルタの中から，Explore エージェント（読み取り専用）に候補となる指摘を広く洗い出させ，短い候補キュー（各エントリ＝箇所・一言・観点）を作る．メイン自身はコードを精読しない（読み込みは Explore に委譲し，メインは一覧だけ保持する）．
• 発見は多角的に依頼する（1つの探し方に依存しない）：バグ観点なら「境界値・null・例外経路」「並行/状態管理」「戻り値・型」，脆弱性観点なら「入力の流れ（source→sink）」「認証認可」「秘匿情報」「依存 CVE」をそれぞれ探させる．
• 報告台帳・スキップ台帳に既出の候補はキューから除外する（同じものを再処理しない）．
• 候補が1つも無ければこの回は空振りとして完了報告（収束判定）へ．

ステップ M2: 1指摘を選ぶ

• キューから未処理の指摘を1つ選ぶ．優先度の目安（高い順）：セキュリティ高（インジェクション・認可欠如・秘匿漏れ）→ バグ高（データ破壊・クラッシュ・誤った計算結果）→ 中 → 低．
• 選んだらステップ M3 へ．キューが空になったら完了報告へ．

ステップ M3: 項目オーケストレータを1体起動（1指摘を完走委譲）

選んだ指摘について，項目オーケストレータを1体だけ（逐次）起動する．次を渡す:

• 対象の指摘（箇所・観点・Explore が挙げた根拠）
• 不変条件（本コマンドの全項目）・4 ゲートの手順（下記「項目オーケストレータの憲章」）
• 検証スイートのコマンド（テスト＋あればビルド/型チェック/リンタ），除外リスト，観点フィルタ，報告のみモードか否か
• 既存台帳の要点（既にスキップ/報告済みで再処理不要な指摘）
• 作業ブランチ名（fix/...）と「push/PR/マージ禁止・fix/ へのみコミット」の制約

起動後はメインは待ち，返ってきた構造化サマリ（下記フォーマット）だけを受け取る．下層の詳細をメインが読み返さない（薄さの維持）．

ステップ M4: 返り値を台帳へ反映・収束カウント

項目オーケストレータのサマリに従い，メインが台帳を更新する:

• fixed：.claude/auto-audit-fixed.md に返ってきた1行を追記（コミットは項目オーケストレータが実施済み）．
• reported：.claude/auto-audit-report.md に返ってきた1行を追記．
• skipped：.claude/auto-audit-skip.md に返ってきた1行を追記．
• stopped（異常）：停止条件に該当．ループを止めて報告へ．

この回で「実質作業をした件数」（自動修正＋新規に報告/スキップへ記録した件数）を数え，収束判定に使う．反映したらステップ M2 へ戻る（キューに残りがあれば次の指摘）．キューが尽きたら，必要なら M1 を1回だけ再実行して取りこぼしを拾い，それでも候補が無ければ完了報告へ．

項目オーケストレータの憲章（メインが各指摘とともに渡す）

あなたは1つの指摘を担当する項目オーケストレータである．渡された指摘について，以下の 4 ゲートを隔離コンテキストで完走し，最後に構造化サマリ1通を返す．内部で tester／coder 等の専門エージェントに委譲してよい（委譲できない場合も，テスト作成と修正は必ず別ステップとし赤→緑規律を守る）．本コマンドの不変条件・除外リストを厳守し，fix/ ブランチにのみコミットする（push/PR/マージ禁止）．

ゲート①: 裏取り（誤検知を先に殺す・独立検証つき）

• 指摘が本当にバグ／脆弱性かを，コードの実際の挙動・前後の文脈・呼び出され方から確認する．
• さらに独立した検証役（別エージェント）に「これは誤検知だ」と反証を試みさせる（adversarial verify）．反証役には「デフォルトで誤検知寄りに判断せよ」と指示し，確度を厳しく見る．
• 誤検知，または確度が低い（反証が成立する／判断が割れる） → 修正しない．skipped として返す（スキップ台帳行：- <箇所> | <理由（誤検知/対処不能 等）> | <日付>）．確度が低いだけで実害があり得るものは reported（重大度「低〜中」）で返してもよい．
• 反証を退けて確かにバグ／脆弱性である → ゲート②へ．

ゲート②: 再現テスト先行（修正の正しさを担保する核）

修正の正しさを証明できるかを，先にテストで確かめる．tester に委譲してよい．

1. 再現テストを書く：その不具合を突く「修正前は落ちる（赤）」テストを作る．
   • バグ観点：バグを踏む入力を与え，あるべき正しい結果をアサートする（現状は誤った結果を返すので赤になる）．
   • 脆弱性観点：攻撃シナリオを与え，**安全な挙動（拒否・エスケープ・検証エラー等）**をアサートする（現状は脆弱なので赤になる）．
2. 赤を確認する：修正前の現状コードでこのテストが実際に落ちることを確認する（＝バグ/脆弱性が確かに存在する証拠）．
   • 落ちない（赤にできない） → 再現できていない．裏取りが甘かった可能性があるため，修正せず reported として返す（「再現テストで赤にできなかった」旨を報告行に含める）．
3. 正しい挙動が一意に決められるかを判断する:
   • 一意に決められる（例: off-by-one，null 参照，条件反転，パラメタ化で防げる SQL インジェクション，パスの正規化で防げるトラバーサル等） → 再現テストを [add] でコミットしてゲート③へ．
   • 仕様判断になる／挙動が割れる／テスト基盤の無い UI 層で観測できない → 自動修正しない（不変条件 11）．reported として返す（「提案する修正・自動修正しなかった理由」を報告行に含める）．
   • ※ セットアップが「報告のみモード」（テストフレームワーク無し）なら，ここで一律 reported として返す．

ゲート③: 影響範囲（blast radius）の解析と保護

• 修正対象のシンボル（関数/メソッド/クラス）の呼び出し元・依存先を洗い出す（参照検索＋呼び出し追跡）．
• 影響先がテストで守られていない箇所 → 先に**特性化テスト（現状の挙動を固定するテスト）**を足して保護する（tester に委譲）．追加したら [add] でコミットする．
  • 特性化テストが緑にできない（挙動を固定できない）ほど影響先が不安定 → 無人で安全に直せないため，修正せず reported として返す．
• 影響が広すぎて無人で追い切れない（多数のモジュール・外部 I/O・非同期経路にまたがる等） → 自動修正せず reported として返す．
• 影響先が保護できた → ゲート④の修正実行へ．

ゲート④: 修正の実行・検証・影響評価つき記録

修正の実行（coder に委譲してよい）

• ゲート②で確認したバグ/脆弱性を修正する．最小の変更にとどめ，ついでのリファクタや無関係な整形を混ぜない（影響範囲を絞るため）．
• 修正後，検証スイート全体（テスト＋あればビルド/型チェック/リンタ）を実行する．

検証（安全網の確認）

• 次の両方を満たすことを確認する:
  • ゲート②で書いた再現テストが緑になった（＝直したいものが直った証拠）．
  • 既存の検証スイート全体も緑のまま（＝他を壊していない証拠．ゲート③で足した特性化テストも含む）．
• 両方満たす → コミットへ．
• 再現テストが緑にならない／既存スイートに赤が出た → その修正を破棄（git checkout -- . または git stash）し，reported として返す（「自動修正を試みたが安全に直せなかった／提案する修正」を報告行に含める）．追加済みの再現テストは残してよい（後の人間修正の助けになる）．

コミット（fix/ ブランチへ）

• git add で当該変更をステージングする（.env・クレデンシャル・ビルド成果物は含めない）．
• .claude/rules/git-conventions.md のコミット書式に従い，タグ [fix] でコミットする．
  • バグ例: [fix] 〇〇の境界値でインデックスが1つずれる不具合を修正
  • 脆弱性例: [fix] 〇〇クエリをパラメタ化して SQL インジェクションを防止
• push・PR はしない．

影響評価つきサマリを返す（fixed）

修正済み台帳に積むべき1行を含めて fixed を返す: - [修正] <箇所> | <内容> | <加えた変更> | <影響範囲（呼び出し元/依存先）> | <推奨する動作確認> | <コミット概要> | <日付>

• 推奨する動作確認には，テストで担保しきれない確認を具体的に書く．特に CLAUDE.md の「手動確認が必要な作業」に該当するもの（実機・ブラウザでの動作確認，外部サービスの挙動）は名指しで「ここは自動テストで確認できないので人間が確認してほしい」と記す．

項目オーケストレータの返却フォーマット（メインはこれだけで台帳を更新できる）

作業完了後，次の構造化サマリだけをメインへ返す（詳細な思考ログは返さない＝メインを薄く保つ）:

• 結果種別：fixed / reported / skipped / stopped
• 台帳行：追記すべき1行（どの台帳か＝ fixed／report／skip も明示）．stopped の場合は停止理由．
• コミット：作成したコミットのタグと要約（fixed のとき，[add] の再現/特性化テストと [fix] を列挙）
• 作業有無：この指摘で実質作業をしたか（収束カウント用の真偽）
• 一言：メインが完了報告に使える要約

停止条件 (Stop Conditions)

以下のいずれかでループを止める．

• 選べる指摘（バグ／脆弱性）が尽きた → 正常終了．
• 項目オーケストレータが stopped を返した／同じ箇所で修正が繰り返し赤になる／検証スイートが途中で失敗するようになった → 異常として停止し報告．
• 未コミットの変更が残ったまま先に進めない状況になった → 停止して報告．
• 不変条件を満たせない状況になった → 停止して報告．
• ユーザーが割り込んで中断した → その時点までの成果（コミット済み）は fix/ ブランチに残る．

/loop との併用（推奨される使い方）

このコマンドは単体で「安全に扱える指摘が尽きるまで」連続実行するが，ユーザーが /loop でラップして起動すると，放置中の空き枠を使って自律的に再トリガーし続けられる（本コマンドの本来の目的）． /loop /auto-audit で全観点巡回，/loop /auto-audit security でセキュリティだけ巡回，のように使い分けられる．/loop で回す場合も上記の不変条件・停止条件は同じく厳守すること．長い待機を挟む場合はキャッシュとコストを意識した間隔を選ぶ．

収束条件（loop-until-dry）— 空回りでトークンを浪費しない

/loop で回すと，指摘が尽きた後もウェイクのたびに「対象なし → 即終了」を繰り返し，無駄にトークンを消費しうる．これを防ぐため，以下の収束ルールを守る．

• 各ウェイクの発見（ステップ M1）で候補を洗い出し，この回で実施した作業の件数を数える（自動修正した件数＋新規に報告台帳/スキップ台帳に記録した件数．既出項目の再確認は作業に数えない）．
• 作業件数が 0 だった回を「空振り」とカウントする．
• 空振りが 2 回連続したら，もう安全に拾える指摘は出尽くしたとみなし，/loop 自体を終了する（次のウェイクをスケジュールしない）．
  • 1 回の空振りで即終了しないのは，「順序やコミットの巡り合わせで一時的に拾えなかっただけ」のケースを 1 回分許容するため．
• 1 件でも作業した回が出たら，空振りカウントは 0 にリセットする．
• 終了時は「空振りが続いたため収束した」旨を完了報告に明記する．

完了報告 (Reporting)

ループ終了時，メインがユーザーに以下を報告する（.claude/auto-audit-fixed.md / -report.md / -skip.md を根拠にする）．

• 作業ブランチ名と，適用した観点フィルタ（bug / security / all）・対象範囲
• 自動修正した件数と一覧（[fix] コミット）．各項目について「加えた変更・影響範囲・人間が行うべき推奨動作確認」を添える（修正済み台帳の内容）．
  • 特に 実機・ブラウザ・外部サービスでの確認が要るものは名指しで案内する（自動テストで担保できないため）．
• 追加した再現テスト・特性化テストの件数（[add] コミット）
• ⚠ 自動修正しなかった指摘（要人間対応）：報告台帳 .claude/auto-audit-report.md の [バグ]／[脆弱性] の件数と概要（重大度順）．「正しい挙動が仕様判断になる／影響が追い切れない／再現できなかった」等の自動修正しなかった理由を明記し，/implement 等での対応を促す．
  • 依存の既知 CVE は「どの依存をどのバージョンへ」の形で提示する（バージョン更新は自動適用していない旨も添える）．
• 誤検知としてスキップした件数（.claude/auto-audit-skip.md）
• 収束理由（指摘が尽きた／空振りが続いた／停止条件に該当，など）
• 次のアクションの案内：「内容を確認の上，問題なければ /commit push（または merge）で main に取り込めます」
  • 本コマンドからは push・PR・マージを行わない． 取り込みは必ずユーザーの明示指示（/commit push 等）で行う．