# EnterPlanMode

将会话切换到计划模式——一个只读探索阶段，助手在其中调研代码库并起草具体的实施方案，交由用户审批后再修改任何文件。

## 何时使用

- 用户请求的是跨多个文件或子系统的非平凡改动。
- 需求存在歧义，助手需要先阅读代码再决定方案。
- 提出重构、迁移或依赖升级，而影响范围尚不明确。
- 用户明确说「先做计划」「先规划一下」或请求设计评审。
- 风险较高，直接动手可能浪费工作或破坏状态。

## 参数

无。`EnterPlanMode` 不接受任何参数——调用时传入空参数对象即可。

## 示例

### 示例 1：大型功能请求

用户说：「给管理后台加上通过 Okta 的 SSO。」助手调用 `EnterPlanMode`，接着花费若干轮阅读认证中间件、会话存储、路由守卫和现有登录 UI。它写出一份计划，描述所需改动、迁移步骤和测试覆盖，然后通过 `ExitPlanMode` 提交审批。

### 示例 2：高风险重构

用户说：「把 REST 控制器换成 tRPC。」助手进入计划模式，审视每个控制器，盘点公开契约，列出发布阶段（shim、双读、切换），并在修改任何文件之前提出排序计划。

## 注意事项

- 计划模式在契约上是只读的。处于其中时，助手不得运行 `Edit`、`Write`、`NotebookEdit` 或任何会改变状态的 shell 命令。仅使用 `Read`、`Grep`、`Glob` 以及非破坏性的 `Bash` 命令。
- 不要对简单的单行编辑、纯粹的研究性问题，或用户已详细指定的任务进入计划模式。开销得不偿失。
- 在 Auto 模式下，除非用户明确要求，否则不建议进入计划模式——Auto 模式倾向于先行动而非事先规划。
- 通过计划模式降低高成本工作的反复修改。五分钟的计划往往能省下一小时的无用编辑。
- 进入计划模式后，将调研聚焦在真正会改动的部分。避免对与当前任务无关的仓库区域做详尽巡视。
- 计划本身应写入运行时约定的路径，以便 `ExitPlanMode` 提交。计划应包含具体的文件路径、函数名和验证步骤，而不是笼统的意图。
- 用户可能驳回计划并要求修改。请在计划模式内迭代，直到计划被接受；然后再退出。
