アプリケーションのユーザー操作ルートを網羅的に洗い出し、不足しているE2Eテストケースをリスト化してください。

**注意:** Previous Responseがある場合は差し戻しのため、
その内容を踏まえてリストを見直してください。

**やること:**

1. **E2Eテストインフラの把握**
   - 既存E2Eテストのディレクトリ構成、テストランナー、ヘルパー、フィクスチャ、モック方針を確認する
   - テストの実行コマンドと実行方法を把握する

2. **ユーザー操作の起点を特定する**（ドキュメントではなくコードを読む）
   - CLIの場合: コマンド定義・サブコマンド・オプション一覧をコードから抽出する
   - Webの場合: ルーティング定義・ページ遷移・APIエンドポイントをコードから抽出する
   - 各起点のハンドラ・処理フローを追跡し、分岐・状態遷移を把握する

3. **UXバリエーションを深掘りする**
   - 各起点について、ユーザーが辿りうる全ルートを列挙する
   - オプション・フラグの組み合わせによる分岐（例: `--pipeline` あり/なし、`--auto-pr` あり/なし）
   - 状態による分岐（初回実行 vs 既存データあり、設定ファイルあり vs なし）
   - 正常フローだけでなく、途中で失敗した場合のエラーハンドリング・リカバリールート
   - 権限・ロール別のルート
   - 外部依存の状態による分岐（接続成功 vs 失敗、レスポンス正常 vs 異常）

4. **既存E2Eテストとの突き合わせ**
   - 既存テストが何をカバーしているかをファイル単位で分析する
   - 洗い出したルートのうち、既存テストでカバー済みのものを特定する
   - 未カバーのルートを「不足テストケース」としてリスト化する

5. **テストケースリストの作成**
   - 全テストケースに一意の番号を付ける（supervisor が突き合わせに使う台帳）
   - 各ケースに優先度を付ける（ユーザー影響度 × 未テストのリスク）
   - **省略しない。** 1-2件で終わらせず、洗い出した全ルートを網羅すること

**絶対禁止:**
- ドキュメントやREADMEだけ読んでテストケースを推測する → 禁止。コードを読む
- 「他にもあるかもしれない」で列挙を打ち切る → 禁止。全件洗い出す
- 既存テストと重複するケースをリストに含める → 禁止。突き合わせ済みのもののみ
