# EnterPlanMode

將工作階段切換至計畫模式，這是一個唯讀的探索階段，助理在此階段調查程式碼庫並草擬具體的實作計畫，供使用者在任何檔案被修改之前先行核准。

## 使用時機

- 使用者要求進行跨越多個檔案或子系統的非簡易變更。
- 需求含糊，助理需要先讀程式碼再決定做法。
- 提議進行重構、遷移或相依性升級，影響範圍尚不明確。
- 使用者明確表示「先規劃一下」、「先做個計畫」，或要求設計評審。
- 風險高到直接動手編輯可能浪費成果或損壞狀態。

## 參數

無。`EnterPlanMode` 不接受任何參數——以空的參數物件呼叫即可。

## 範例

### 範例 1：大型功能需求

使用者要求：「在管理後台加入 Okta SSO。」助理呼叫 `EnterPlanMode`，接著花數輪讀取認證中介層、session 儲存、路由守衛與既有登入 UI。它撰寫計畫描述所需變更、遷移步驟與測試覆蓋範圍，然後透過 `ExitPlanMode` 送出核准。

### 範例 2：風險較高的重構

使用者說：「把 REST controller 轉成 tRPC。」助理進入計畫模式，審視每個 controller，列出公開契約，列舉部署階段（shim、雙讀、切換），並在動任何檔案之前提出排序計畫。

## 注意事項

- 計畫模式依約定為唯讀。在其中，助理不得執行 `Edit`、`Write`、`NotebookEdit` 或任何有變更效應的 shell 指令。只能使用 `Read`、`Grep`、`Glob` 與非破壞性的 `Bash` 指令。
- 不要為了瑣碎的單行編輯、純研究問題，或使用者已完整指定變更細節的任務進入計畫模式。額外成本反而弊大於利。
- 在 Auto 模式下，除非使用者明確要求，否則不建議進入計畫模式——Auto 模式偏好行動勝於前期規劃。
- 使用計畫模式來減少高成本工作的轉向。五分鐘的計畫常能省下一小時誤入歧途的編輯。
- 一旦進入計畫模式，把調查重心放在實際會變動的系統部位。避免對與任務無關的 repo 做全面巡禮。
- 計畫本身應寫入 harness 預期的路徑，這樣 `ExitPlanMode` 才能送交。計畫應包含具體的檔案路徑、函式名稱與驗證步驟，而非空泛意圖。
- 使用者可能拒絕計畫並要求修訂。請在計畫模式內反覆迭代，直到計畫獲得接受；接受後再退出。
