Reconsider review

以下の手順で、PRレビューコメントを検証し対応方針ドキュメントを作成してください。

入力

PR番号: $ARGUMENTS

1. 情報収集

PR番号が指定されていない場合は、現在のブランチから自動検出してください。

gh pr view --json number,title,body
gh repo view --json nameWithOwner -q .nameWithOwner

以下を並行して取得してください：

# インラインレビューコメント（resolve 済みスレッドの判定を含む）
# REST API には isResolved がないため GraphQL を使う
gh api graphql -f query='
{
  repository(owner: "<owner>", name: "<repo>") {
    pullRequest(number: <PR番号>) {
      reviewThreads(first: 100) {
        nodes {
          isResolved
          comments(first: 1) {
            nodes {
              id
              path
              line
              author { login }
              body
            }
          }
        }
      }
    }
  }
}'

resolve 済みスレッド（isResolved: true）は検証・分類の対象外とする。 対応方針ドキュメントにも記載しない（既に対応完了としてクローズされているため）。未resolve のスレッドのみを以降のステップで扱う。

PR本文から関連 Issue 番号を特定（"Resolves #N" 等）し、Issue 本文も取得して本来の仕様を確認してください：

gh issue view <issue番号> --json body -q .body

このPRが実際に変更した範囲を把握してください。指摘がこのPRのスコープ内かを後で判断するために使います。main との差分ではなく、PRのベースブランチ（マージ先）との差分を見ること（main 差分にはマージで持ち込まれた他ブランチの変更が混ざり、スコープを誤判定するため）：

gh pr view <PR番号> --json baseRefName,headRefName
git diff --name-only origin/<baseRefName>...HEAD   # このPRが触ったファイル

2. 各コメントの妥当性検証

提案を機械的に受け入れるのではなく、以下の観点で検証してください。レビュアーの指摘は人間・自動レビュアー（CodeRabbit 等）を問わず「考えるきっかけ」であって「正解」ではない。どんなレビュアーもコードの全文脈や仕様意図を完全には把握しておらず、正しい指摘と的外れな指摘が混在しうる前提で、1件ずつ吟味すること。

検証の前に、まず指摘の表面的な文言ではなく、その背後にある懸念（レビュアーが何を心配しているか）を読み取ること。文言通りに直すと的外れになる場合があり、真の懸念に応える形（別の手段でその懸念を解消する、あるいは懸念が成立しない理由を示す）が最善のこともある。

スコープの確認（最初に行う）

• その指摘がこのPRで実際に追加・変更した行に対するものかを確認する。レビュアーは変更行の近傍をまとめて見るため、指摘が既存コード（他ブランチからのマージで持ち込まれた行など）に着弾していることがある（コミット範囲を機械的に走査する自動レビュアーでは特に起きやすい）。git diff origin/<base>...HEAD で当該行がこのPRの変更分かを照合する。
• スコープ外なら、たとえ指摘自体が正しくても「対応保留（別管理）」か「対応不要（このPRの責務外）」とする。指摘の正しさとこのPRで直すべきかは別問題。

元の仕様との整合性

• Issue の実装内容・タスクリストに明示された仕様と提案が食い違っていないか
• 食い違いがある場合、どちらが優先されるべきかを検討する

コードベースとの一貫性

• 提案の根拠として挙げられた「他の箇所」を実際にファイルを読んで確認する
• 変更対象以外に同種の箇所があれば、提案を適用した場合に全体が揃うかを確認する

提案内容の妥当性

• 提案された変更がその箇所の意図に合っているか
• 一般的な慣習（PEP 8、logging レベルの使い分け等）と整合しているか

「実害」か「予防・一貫性」かを見極める

指摘されたバグ・競合が、実際にどういう条件で・どの程度の確率で発現するかを具体的に辿ること。「○○という競合があり得る」という指摘を額面通り受け取らず、現実の挙動に落として評価する。

• 発現条件と確率: タイミング依存（レース・競合）の指摘なら、関係する処理の呼び出し間隔と所要時間のオーダーを比較する（例: 呼び出し間隔が数秒・処理が数ミリ秒なら、逐次フローでは交差しない）。理論上 racy でも現実の設計で発現しないなら、その旨を明記する。
• 被害の大きさと自己修復性: 万一発現した場合に何が壊れるかを評価する。「最悪ケースでも後続処理（dedup・リトライ・冪等な再実行等）で吸収される」なら優先度は大きく下がる。
• 動機の区別: その修正の動機が「実害の回避」なのか「コードベースの一貫性・予防」なのかを区別し、ドキュメントに正直に書く。後者だけが理由のときは、その旨を明示して優先度を下げるか、「対応不要」も選択肢として提示する。実害がないのに「修正対象」と断定しない。

データフロー上の「正となる場所」を特定する

• 挙動を実際に決めているのがどの状態か（例: in-memory の値か、永続ストレージか／どのレイヤーがスキップ判定を駆動しているか）を辿る。これが分かると、「どの失敗が本当に問題で、どの失敗は許容できるか」を根拠を持って判断できる。fire-and-forget・キャッシュ・冗長な保存などの指摘は、この特定なしには正しく評価できない。

添えられた提案コードを逐語的に信用しない

• レビュアーが示す修正コード（人間の suggestion ブロックや、自動レビュアーの committable suggestion）には、古いコメント文言・リネーム前の変数名・別箇所のロジック・現在の実装と合わない前提が紛れていることがある。提案の趣旨は採用しても、貼り付ける前に現在のコードと突き合わせ、細部（コメント・命名・周辺の整合）を直す。提案をそのまま適用して新たな齟齬を生まないこと。

指摘を起点に周辺の同種問題を探す

• 1件の指摘は氷山の一角のことがある。検証中に同じ種類の齟齬（設計変更の取り残し、同じパターンの抜け、コメントと実装の不一致など）が周辺にないかを確認し、見つかれば「追加検出」として併せて記載する。レビュアーが挙げていない問題でも、関連が強ければ拾う。

3. ステータス分類

検証結果をもとに、各コメントを以下の4区分に分類してください：

ステータス	基準
修正対象	このPRで修正する
対応不要	修正しない（理由を明記）
対応保留	スコープ外・別Issueで管理
要議論	判断が難しく、レビュアーとの確認が必要

• 対応保留にする場合は、既に対応する Issue が存在しないかを gh issue list で確認し、あれば Issue 番号を明記する（「別Issue候補」で止めず、実在の管理先を示す）。
• 対応不要にする場合は、検証で得た具体的根拠（発現しない／被害が自己修復する／このPRの責務外 等）を必ず添える。「不要」とだけ書かない。指摘に反論する形になるときも、相手を論破するためではなく、後から第三者（レビュアー本人を含む）が判断を追えるよう根拠を残すことを目的とする。
• 「実害がある修正」と「一貫性・予防のための修正」が両方とも修正対象になる場合でも、後者は優先度が低い旨が読み手に伝わるように書く。

4. 対応方針ドキュメントの作成

出力先: .claude/reports/task_docs/<issue番号>/pr-review-<PR番号>-<レビュアー名>.md

task_docs/<issue番号>/ ディレクトリが存在しない場合は作成してください。

ドキュメントの構成は examples/sample.md を参考にしてください。

検証で新たな不整合（「提案を受け入れると別の箇所と揃わなくなる」等）が見つかった場合は、追加対応が必要な箇所もあわせて記載してください。

5. 完了報告

• 生成したファイルのパス
• 各コメントの対応分類を一覧表で提示
• 修正対象・要議論となったコメントの概要