Self Improvement

繰り返す運用上の問題や古いルールを、確認できる根拠に基づいて改善する。通常タスクの完了・PR・.quality-check-passed 発行の条件にはしない。候補がないときは実行も「候補なし」の手書き記録も不要。

適用条件

• 同じ種類の手戻り、誤検出、環境依存の失敗が繰り返された。
• ユーザーが運用改善を依頼した、または配布物と実態の不一致が判明した。
• 定期的な棚卸しで、不要な規則の削除・重複統合を評価する。

一度限りのミスや未検証の推測を恒久ルールにしない。製品の不変条件、独立したテスト期待値、必要な実動作確認を効率化と一緒に削除しない。

原因と置き場所を選ぶ

1. 再現条件と原因、既存の対策を確認する。配布元の不具合と導入先固有の条件を分ける。
2. 機械的に処理できる問題は設定・ラッパー・hook・検証コードで直す。入力の BOM 処理不備を、全モデル向けの長い Shell 規則で恒久的に代替しない。
3. 判断が必要な原則だけをスキルやルールに残す。追加だけでなく既存規則の削除・統合、回避策の撤去条件を検討する。
4. 必要な製品・環境固有の独自差分を維持する。配布元を直しても導入先が上書きしていれば、実際の読み込み経路と更新対象を伝える。

記録と適用

現在の依頼に含まれない改善は、既存の Issue や改善候補の記録先に短く残し、通常タスクを完了する。記録は根拠、対象、期待効果、既存ルールを削除できる条件で十分。同じ提案を毎回作り直さない。

適用はユーザーが認めた範囲で行う。会話で既に承認されている変更は再確認せず進める。別スコープの恒久変更は別 Issue / ブランチで扱い、採否待ちで現在の作業完了を止めない。採否を待つ候補は、最後の報告の「判断が必要なこと」に 1 行で書く（documents/development/development-policy.md §1.0「承認後の進め方」）。見送られた候補は適用しない。

必要な検証を行い、代替修正が確認できてから回避ルールを整理する。ゲート制御面の変更には通常の quality-check が必要。フラグの有効範囲は quality-check の契約に従い、自己改善を理由に免除を広げない。

既存レポートの self_improvement は互換性のため読める形で残す。今回実施した場合のみ任意で結果を記録し、未実施を not_required と偽って記録しない。