executing-plans-preflight

执行计划前置检查

半自动 Git 状态门禁。检测问题、提出修复方案，并在确认后执行。在开始任何实现工作前运行此检查——确保 Git 状态已就绪，让你从干净、正确的基线开始。

不在 Git 仓库中？请说 Not a git repository — skipping preflight.，然后继续。

检查项

按顺序运行。如果没有问题，静默通过——只有需要修复时才提示。

1. 分支上下文

通过 origin/HEAD 检测默认分支。如果检测失败，则将 main/master 视为默认分支。

• 分离头指针 → 询问要切换到哪个分支（无法推断）。
• 位于默认分支 → 根据对话中的计划推断分支名称（标题 → kebab-case，添加常规提交类型前缀：feat/、fix/、docs/、refactor/、perf/、test/、chore/、ci/、build/；默认为 feat/）。提出建议，让用户确认或重命名，然后运行 git switch -c。对话中没有计划？直接询问——不要根据文件系统猜测。
• 其他情况 → 静默通过。

2. 工作树干净

运行 git status --porcelain。所有改动都算作不干净（已暂存、未暂存、未跟踪）。

• 干净 → 静默通过。
• 不干净 → 列出路径，并询问用户解决问题或说“continue”以覆盖。记录此覆盖——检查项 3 需要知道。不要协助提交或暂存；这由用户决定，因为提交范围和消息是需要审慎决定的事项，不应被埋在前置检查中。

3. 远程同步

运行 git fetch。如果获取失败，发出警告并使用本地信息继续——远程状态并非最新时，不要声称它是最新的。

• 没有上游 / 领先 / 已同步 → 静默通过。
• 上游已不存在 → 询问：清除跟踪设置还是重新创建？
• 落后/分叉 → 提议运行 git pull --rebase。如果在检查项 2 中覆盖了不干净的文件，警告用户拉取可能发生冲突，并提供跳过同步的选项。

检查项 1 中创建的新分支没有上游——这是预期情况，不要推送。

报告

所有检查完成后，用一行给出结论。每项修复前各占一行。

Switched to `feat/add-auth` (was on main)
Preflight passed. Ready to go.

如果覆盖了不干净的文件，结尾使用 Proceeding with uncommitted changes.，而不是 Ready to go.。

为什么需要这些防护措施

• 执行前先确认——Git 操作很难撤销；在错误分支上误运行一次 switch -c 或 pull --rebase，就可能造成实际损失。
• 允许覆盖不干净状态——无条件阻止操作是 v2 最令人困扰的问题。用户比前置检查更了解自己的工作状态。
• 绝不推送——前置检查只管理本地状态。发布是单独且需要审慎决定的步骤。