friction-reviselisted

# friction-revise: 摩擦ログの精査と dev-method 改訂バッチ ## 入力 - `~/dev-notes/dev-method/friction.md` の**未対応エントリ**（`（改訂済み …）` `（見送り …）` マークが無い行） - 補助: `node scripts/method-stats.mjs` の出力（新旧実測フッターの集計・並列 Ask のレビュー壁時計分／共同ラウンド数／pre・cross 別 R1／固有・重複、欠落やパース不能の警告・smoke実施率とFAIL件数・未整備率・評価不能率・対象外率・friction.mdの品質漏れエントリ件数）。並列 Ask は downstream R1 単独で評価せず、壁時計・共同ラウンド数・差し戻し・pre/cross ���有数・重複数の時系列を比較する。5件たまった時点で旧直列 Ask と比較し、両レビュアーが拾う固有指摘の比率と待ち時間短縮が共同ラウンド契約のコストに見合うか判定する。過去の直列フッターは書き換えず、旧 R1 指標は当時方式の基準として読む。**品質漏れ0件を実績と解釈する前に、smoke実施率・未整備率・評価不能率・対象外率を併記して判断する**（未整備が多い状態での0件は「検知していないだけ」＝手法の穴の可能性がある。対象外は正当にsmoke不要のケースで手法の穴ではないが、UI変更が続く期間に対象外が並ぶ場合は判定の甘さを疑う。評価不能率が高い場合はアプリの退行ではなく環境側の問題が繰り返されている可能性があり、smoke手法自体の穴ではない） - 補助: `node scripts/check-wait-usage.mjs`（引数なしで `~/.codex/sessions` を自動走査）の出力（Codex セッションの wait_agent 呼び出しが短周期反復（同一セッション10回以上かつ間隔中央値180秒未満）になっていないかの機械監視。待機運用条項の再発を人の記憶に頼らず検知する。閾値は60秒ではなく180秒未満: `timeout_ms=60000` で待ち続けた呼び出しは間隔が構造的に60秒をわずかに上回るため（実測: 07-16 中央値73.7秒・07-17 中央値64.4秒）、60秒未満の閾値では動機となった friction セッションを取りこぼす。07-17 改訂後の正しい運用（timeout最大で一度に待つ）は少数回・長間隔になるため、3分未満の反復を短周期とみなす設計にして多少の過検知を許容し、取りこぼしを避ける。過検知はあり得るため、警告は自動でスキル改訂の根拠にせず、対象��ッションの内容を人が読んで判断する前提で使う） ## 手順 1. 未対応エントリを**発生位置タグ**（`[node:*]` / `[edge:*]`。語彙の正本は `method-check` の friction 記録節）でまず束ね、同じタグの中で同型をグルーピングする。タグの無い過去エントリは、そのバッチで扱う分だけ本文から判定してタグを補う（全件の遡及付与はしない） 2. 過去に `（改訂済み）` マークが付いたエントリと同型の friction が未対応エントリに再発していないか確認する。照合は同じタグの範囲を先に見て、そこで見つからなければ隣接タグ（同じ工程を挟む node と edge）まで広げる。**無タグの過去エントリは本文内容で照合する**（タグ範囲の絞り込みは無タグ行にヒットしないため、タグ照合だけで