rubocop-todo-fix

rubocop-todo-fix

rubocop --auto-gen-config で生成された .rubocop_todo.yml には、既存コードの違反が「いったん許容」 として列挙されている。これを潰していくための運用支援スキル。safe autocorrect（-a）だけで完結する Cop はまとめてバッチ処理し、unsafe autocorrect や手動修正が必要な Cop も、挙動変更のリスクに応じた （safe バッチより狭い）単位でバッチにまとめて潰す。 sgcop-setup が .rubocop_todo.yml を生成するところで終わるのに対し、 本スキルはその続き——生成済みの todo を実際に消化する工程——を担う。

導入先の Rails/Ruby プロジェクトで実行する（sgcop gem 本体の開発スキルではない）。

このスキルがやること / やらないこと

• やる:
  1. .rubocop_todo.yml から 潰す対象を選ぶ。Tier（safe autocorrect / unsafe autocorrect / 手動修正）ごとに、そのリスクに見合ったしきい値・基準で複数 Cop をバッチにまとめる。
  2. 対象 Cop のエントリを todo から削除して 違反を再び検出される状態に戻す。
  3. 修正する: Tier 順（rubocop -a → rubocop -A〈unsafe・要テスト〉→ 手動修正）でバッチを 処理する。同じ Tier のバッチはまとめて一度に適用・確認する。
  4. アプリ仕様上やむを得ない違反だけ、理由コメント付きで最小範囲の Exclude / 無効化に倒す。
  5. 再 rubocop で 違反ゼロを確認（挙動を変えたら関連テストだけ実行）し、必要なら .rubocop_todo.yml を作り直して 停止する。
• やらない:
  • .rubocop_todo.yml の生成そのものはしない（sgcop-setup の担当。本スキルは「生成済みを潰す」）。
  • コミット / push / PR 作成はしない。 1 サイクル潰したら停止し、差分確認とコミットはユーザーに委ねる。
  • Tier をまたいでバッチにしない。 safe / unsafe / 手動修正はリスクの質が異なるので、 1 回のバッチは同じ Tier の Cop だけで構成する。

なぜこの形か: 既存違反を一度に全部直すと差分が巨大化してレビュー不能になる。「潰す → ユーザーが差分を確認してコミット → 次へ」というレビュー単位の運用にすると、変更の責任範囲が 把握しやすく、挙動が変わっても切り分けやすい。一方で 1 Cop ずつ処理すると、サイクル数 （起動〜レビュー〜コミットの往復）だけが無駄に増えてしまう。そこで Tier ごとに「レビューが 破綻しない範囲」を見極めてバッチ化する：safe autocorrect は挙動を変えないので件数ベースで 最も広く（目安100件）まとめられる。unsafe autocorrect は挙動が変わりうるので、それより 狭い件数（目安30件）に抑える。手動修正はさらに読み解きコストが件数に比例しないため、 件数ではなく「性質が近い少数の Cop（目安2〜3個）」という基準でまとめる。

引数

• --auto: 起動時にこの引数が渡されたら、1 サイクルをユーザー確認なしで回しきるモードに入る。 スキップするのは「進めてよいか」の確認ゲートだけで、それ以外の原則は一切変わらない:
  • **1 サイクル ＝ 選んだバッチ（Tier をまたがない）**の原則、コミット・push・PR をしない原則、 サイクル完了で停止する原則は --auto でも不変。複数サイクルの自動連続実行はしない。
  • 人間の判断が要る曖昧な分岐は --auto でも勝手に決めない（手順 5 参照）。触らず残して報告する。
  • 手順 6 の関連テスト検証は --auto でも省かない。 unsafe autocorrect を無確認で当てる分、 関連テストが挙動変更を検知する唯一の安全網になるため、むしろ飛ばしてはいけない。
  • WHY: 確認ゲートは「差分が想定外に大きくならないか」「挙動変更を許容するか」を人に確かめる ためのもの。--auto は呼び出し側がその判断を事前に委譲した状態、と位置づける。委譲できるのは 「自動で潰してよい」判断までで、曖昧な Exclude 判断や壊れたテストの承認までは委譲されない。
• 引数が無ければ（従来どおり）各確認ゲートでユーザーに確認する。