persistent-exploration

name	persistent-exploration
description	調査が行き詰まったとき、再現できないと判断しそうなとき、「不可能」と結論づける前に使用する。Sentry/ログ起因の調査、再現困難なバグの深掘りに適用する。サブエージェント調査委譲時のprompt注入テンプレート、突破口チェックリストを含む。

Persistent Exploration — 探索行動原則

いつ使うか

• Sentry/ログでイベントが発生しているが再現方法が不明なとき
• 「UIから操作不可能」「再現できない」と判断しそうなとき
• サブエージェントに調査タスクを委譲するとき

行動制約テンプレート

サブエージェントに調査タスクを委譲する際、以下をプロンプトに含める:

## 行動制約
- 「不可能」「再現できない」と結論づける前に、最低3つの代替アプローチを試すこと
- Sentry/ログでイベントが発生している場合、発生ルートは必ず存在する。「不可能」は許容しない
- 試したアプローチと結果を構造化して報告すること（探索木形式）
- 未探索のアプローチが残っている場合、それを明示すること

「不可能」判定の前提条件

「不可能」と結論づける前に、以下を全てチェックする:

• データ的証拠: Sentry/ログでイベントが発生しているか → 発生しているなら「不可能」ではない
• 代替アプローチ: 最低3つの別アプローチを試したか
• セカンドオピニオン: SO で「本当に不可能か？」を検証したか
• 前提の再検証: 「不可能」の根拠となっている前提自体が正しいか確認したか

突破口チェックリスト

「UIから操作不可能」「再現できない」と判定した場合に試すべきアプローチ:

1. API 直接呼び出し: page.request、curl、session_api.sh でフロントエンドをバイパス
2. フレームワークランタイムデータ操作: browser_evaluate でコンポーネントデータを直接変更
3. ネットワークリクエストのインターセプト・リプレイ: Playwright Route 傍受で条件を変更
4. 別のユーザー権限・別のアカウント: 権限差異による挙動の違いを確認
5. DB の状態確認: バックフィル漏れ、マイグレーション履歴（データの歴史的経緯）
6. バックエンドのバリデーション/ガード確認: フロントエンドガードのみでバックエンドはスルーのケース
7. 過去のマイグレーション履歴: データの歴史的経緯がバグの原因になっていないか

探索木フォーマット

試したアプローチと結果を構造化し、未探索のブランチが残っている限り続行する。報告時にこの形式を使う:

<調査対象>
├── アプローチA → 結果 ❌
│   ├── 派生A-1 → 結果 ❌
│   ├── 派生A-2 → 条件付き可能 ⚠️（要確認事項）
│   └── 派生A-3 → 結果 ❌
├── アプローチB
│   ├── 手段B-1 → 失敗 ❌
│   ├── 手段B-2 → 成功 ✅
│   └── 手段B-3 → 未試行
├── アプローチC → 失敗 ❌
└── アプローチD → 未試行

凡例: ✅ 成功 / ❌ 失敗 / ⚠️ 条件付き / 未試行

使用例

サブエージェントへの委譲時:

Sentry で mb_convert_encoding(null) のエラーが発生しています。
対象ファイル: app/Services/Csv/CsvExportService.php

以下を調査してください:
- getValueForCsv() の null が渡されるパスを特定
- 再現手順を確立（UIまたはAPI経由）

## 行動制約
[上記テンプレートを貼り付け]

調査にあたっては persistent-exploration スキルの突破口チェックリストを参照してください:
Read ~/.cursor/skills/persistent-exploration/SKILL.md