# EnterPlanMode

セッションをプランモードに切り替えます。これは読み取り専用の探索フェーズで、アシスタントはコードベースを調査し、ファイルを変更する前にユーザーの承認を得るための具体的な実装プランを作成します。

## 使用タイミング

- ユーザーが複数のファイルやサブシステムにまたがる重要な変更を依頼した場合。
- 要件が曖昧で、アプローチを決める前にアシスタントがコードを読む必要がある場合。
- リファクタリング、マイグレーション、依存関係のアップグレードが提案され、影響範囲が不明な場合。
- ユーザーが明示的に「プランを立てて」、「まずプランを立てよう」と言ったり、設計レビューを要求した場合。
- リスクが十分に高く、直接編集に移ると作業が無駄になったり状態を損なう可能性がある場合。

## パラメータ

なし。`EnterPlanMode` は引数を取りません — 空のパラメータオブジェクトで呼び出してください。

## 例

### 例 1: 大きな機能リクエスト

ユーザーが「管理パネルに Okta 経由の SSO を追加して」と依頼します。アシスタントは `EnterPlanMode` を呼び出し、数ターンかけて認証ミドルウェア、セッションストレージ、ルートガード、既存のログイン UI を読み込みます。必要な変更、マイグレーションステップ、テストカバレッジを説明するプランを作成し、`ExitPlanMode` を介して承認のために提出します。

### 例 2: リスクの高いリファクタリング

ユーザーが「REST コントローラーを tRPC に変換して」と言います。アシスタントはプランモードに入り、各コントローラーを調査し、公開コントラクトを整理し、ロールアウトフェーズ (shim、dual-read、cutover) をリストアップし、ファイルに触れる前にシーケンスプランを提案します。

## 注意事項

- プランモードは契約上読み取り専用です。その中にいる間、アシスタントは `Edit`、`Write`、`NotebookEdit`、または変更を行うシェルコマンドを実行してはいけません。`Read`、`Grep`、`Glob`、および非破壊的な `Bash` コマンドのみを使用してください。
- 些細なワンライナーの編集、純粋な調査質問、ユーザーがすでに変更を詳細に指定したタスクにはプランモードに入らないでください。オーバーヘッドが役立つよりも害になります。
- 自動モードの下では、ユーザーが明示的に要求しない限りプランモードは推奨されません — 自動モードは事前プランニングよりも行動を優先します。
- 高コストな作業での方向修正を減らすためにプランモードを使用してください。5 分のプランがしばしば 1 時間の誤った方向の編集を節約します。
- プランモードに入ったら、実際に変更される部分に調査の焦点を合わせてください。当面のタスクと無関係なリポジトリの網羅的なツアーは避けてください。
- プラン自体は、`ExitPlanMode` が提出できるように、ハーネスが期待するパスにディスクへ書き込む必要があります。プランには、漠然とした意図ではなく、具体的なファイルパス、関数名、検証ステップを含めるべきです。
- ユーザーはプランを拒否して修正を求めるかもしれません。プランが承認されるまでプランモード内で繰り返し、その後にのみ終了してください。
