comment-cleanuplisted

対象リポのコメントを、行数の機械的な強制ではなく内容の質で仕分けて整理する。 ## 1. 検出 対象ディレクトリで2行以上連続するコメントブロックを洗い出す。 ``` rg -n --no-heading -e '^\s*#' -e '^\s*//' <target-dirs> | awk -F: '{print $1":"$2}' | sort -t: -k1,1 -k2,2n | awk -F: ' { if ($1==pf && $2==pl+1) { grp[++c]=$0; if(c==1) grp[0]=prevline } else { if (c>=2) { print "---"; for(i=0;i<=c;i++) print grp[i] } c=0 } pf=$1; pl=$2; prevline=$0 } END { if (c>=2) { print "---"; for(i=0;i<=c;i++) print grp[i] } } ' ``` 除外する（対象外）: - コメントアウトされた旧コード（`# "foo" = {...}` のような設定の残骸） - セクション区切りバナー（`# ---` のような装飾線のみ）は圧縮対象だが、直後の1行タイトルは残す - `issues/`, `docs-agents/`, README等の説明文書（コードコメントではない） 単行コメントも、明らかにWHAT型（直後の1行を英語でそのまま言い換えているだけ等）なら対象に加えてよいが、優先度は2行以上のブロックより低い。単行を拾う場合も全文Readはせず、以下のように行内容だけを安く一覧してから判定する（ブロック検出で拾った行はここでは除外してよい）。 ``` rg -n --no-heading -e '^\s*#' -e '^\s*//' <target-dirs> ``` ## 2. 分類と処理 各ブロックを読んで判定する。ファイルが小さい（目安200行未満）、またはブロックが3箇所以上散在する場合は該当ファイルを全体Readしてよい。それ以外（大きいファイルにブロックが1〜2箇所だけ浮いている場合）は、該当ブロックの前後15行程度を offset/limit で読み、周辺コードとの整合だけ確認する。判定に文脈が要ると分かった時点でその都度全体Readに切り替えてよい（迷ったら広く読む方を��先し、無理に節約しない）。 - **WHAT型**（コードを読めば分かることの説明。関数名・変数名・次の1行の言い換え） → 削除する。圧縮ではなく削除が基本。 - **WHY型**（非自明な理由・過去の失敗の経緯・外部制約・ハマりどころの回避策） → 残す。冗長な言い回し・無駄な改行・箇条書きの飾りは削るが、**情報を落としてまで1行に圧縮しない**。要点が保たれるなら1行にまとめてよいが、2〜3行に整理する形で終えてもよい。 → 日付・タイムスタンプ入りの「日記」的な経緯コメント（「2026-01時点で〜に直した」等）は日付部分を削り、経緯そのものは保つか、非自明な制約として残すべきか判断する。 - **判断に迷う場合**は削除・圧縮せず、そのまま一覧に残して report する（後述）。 ## 3. 適用 - 対象リポのワークフロールールに従う（`docs-agents/issue-driven-workflow.md`）。Issueドリブンのリポでは Issue 化フローに従い、そ