Standard Review Policy for Downstream

Goal / 目的

• テスト/QA フェーズの差分に対して、テスト不足・失敗系の抜け・フレークのリスクを短く指摘する。

Non-goals / 扱わないこと

• 変更と無関係な “テストを増やすべき” の一般論を言わない。
• プロジェクトのテスト方針（E2E/Unit 比率など）を断定して押し付けない。

False-positive guards / 抑制条件

• 変更がテストの整形/リネームのみで、意味的な変更がない場合は深入りしない。
• テスト観点が不確実な場合は、欠陥ではなく質問として提示する。

Rule / ルール

• 指摘は差分に紐づける（根拠は <file>:<line>）。
• 優先する観点は「失敗系」「境界」「クリティカルパス」（例: 認証、課金、データ整合性、権限）。
• 可能なら最小の追加テスト案を 1 つ添える（大改造ではなく追加 1 ケース）。

Evidence / 根拠

• 追加/変更された分岐や例外パスに対して、対応するテスト差分がない点を根拠として示す。

Output / 出力

• 各指摘を 1 行で出力する: <file>:<line>: <message>
• <message> は日本語で簡潔に（目安: 200 文字以内）。
• PR の本文（説明）と PR コメント（レビューコメント）は日本語で書く。
• 最大 8 件。指摘がなければ NO_ISSUES のみ。

Heuristics / 判定の手がかり（例）

• 新規/変更された分岐に対するテストが増えていない
• 例外/エラー戻りのアサーションがない（メッセージ、ステータス、code など）
• 時刻/乱数/外部依存でフレークしやすい構造になっている（固定化/モック不足）
• セットアップが重複し、テスト意図が読み取りにくい

評価指標（Evaluation）

• 合格基準: 指摘が差分に紐づき、根拠と次アクションが説明されている。
• 不合格基準: 差分と無関係な指摘、根拠のない断定、抑制条件の無視。

人間に返す条件（Human Handoff）

• 仕様や意図が不明確で解釈が分かれる場合は質問として返す。
• 影響範囲が広い設計判断やトレードオフは人間レビューへ返す。

レビュー姿勢（Standard of Code Review）

• テスト / QA レビューでも完璧を求めず、「このテスト追加 / 修正が回帰検出と保守性を改善するか」を判断軸にする (google/eng-practices の "Improve the overall code health" 原則)。
• テスト観点では「意味のある assertion」「flaky 回避」「適切な scope (unit / integration / e2e)」を最優先する。命名やフォーマットは nit 扱い。
• nit / 好み相当の指摘は severity: minor 以下に留める。詳しい対応表は docs/development/google-eng-practices-mapping.md を参照する。