让 AI 先规划分支，再执行 Git 操作

“从开发分支拉一个修复分支”对人类团队可能有默认含义，对 Agent 却不够精确：哪个仓库、哪个远端、什么环境、面向哪个发布系列，都可能改变正确答案。分支规划因此应成为独立的只读步骤。

收集决定分支的最小参数

至少需要任务类型、仓库类型、目标环境、版本系列和工作项引用。客户端与服务端可能采用不同策略，生产修复与测试环境修复也可能维护不同基线。缺少关键参数时输出待确认项，不要根据分支名字的习惯猜测。

规划与执行分离

规划器只返回源分支、目标分支、建议新分支名、远端和理由，不执行切换、创建或推送。执行器收到人工确认后，再检查工作区是否干净、远端引用是否最新、源提交是否精确。这样即使规划错误，也不会改变仓库状态。

命名要承载可追溯信息

推荐把工作类型、版本系列和工作项引用放入分支名，但不要包含客户名称、手机号等敏感数据。例如需求分支可以携带需求号，缺陷分支携带 Bug 号。命名规则应由校验器检查前缀、字符集和长度。

“最新”不是选择规则

远端存在多个发布分支时，时间最新不代表受影响版本所属分支。应使用部署版本、构建号、发布记录或用户确认来唯一定位；证据不足就停止。

最终计划要能被另一个执行过程直接消费，并清楚说明为什么选这个源和目标。把 Git 的第一步变成可审查决策，远比事后修复错误提交更便宜。

第二轮实践复核

可复用交付物： 精确 remote/source/target/SHA 与规划理由。这些内容是从工程实践抽象出的通用方法，不包含内部仓库、真实工作项、业务数据、凭据、地址或实现源码。

最低验收： 规划阶段不创建分支；执行前重新获取远端并确认工作区状态。验收记录必须分开事实、推断、缺口和授权范围；只读检查不能自动扩展为提交、推送、评论或发布。

可执行契约与决策表

规划器输出机器可校验的对象，而不是一段“建议从 develop 拉分支”的自然语言：

{
  "repository": "service-api",
  "remote": "origin",
  "source_ref": "refs/remotes/origin/release/2.4",
  "source_sha": "<40-hex-sha>",
  "target_ref": "refs/heads/fix/2.4/BUG-241-timeout",
  "work_item": "BUG-241",
  "facts": ["affected_release=2.4.7", "deployed_sha=<sha>"],
  "assumptions": [],
  "requires_confirmation": false
}

source_ref 与 source_sha 同时存在：前者说明政策上的基线，后者冻结本次计划看到的对象。执行前重新 fetch；若 ref 已前进，计划变为 stale，必须重新生成或由人明确接受旧 SHA。

任务	已知发布线	源分支	目标命名	不足时行为
新需求	下一版本 2.5	`develop/2.5`	`feat/2.5/REQ-*`	询问版本
线上缺陷	当前 2.4	`release/2.4`	`fix/2.4/BUG-*`	读取部署证据
紧急修复	精确生产 SHA	组织定义的 hotfix 基线	`hotfix/2.4/BUG-*`	必须人工批准
文档维护	与代码版本无关	默认主线	`docs/DOC-*`	按仓库规则

执行前的竞态检查

执行器依次确认仓库根目录、远端 URL、ref 可达、工作区与 index 状态、目标分支不存在、分支名通过 check-ref-format。任何未知修改都停止，不能 stash、reset 或换目录绕过。创建本地分支后先核对 HEAD 等于计划 SHA，推送仍属于单独授权。

用 fixture 仓库覆盖 ref 前进、同名分支、detached HEAD、多个 remote、浅克隆缺对象和工作区脏六个用例。验收指标除“错误基线数”外，还要统计 stale 计划拦截率和人工修改原因；规则频繁被改写通常说明输入契约不足，而不是模型不够聪明。

公开规范

Git 引用命名规则

规范复核日期：2026-08-22。

小规模演练

收集任务类型、仓库类型、环境、版本和引用，输出 source/target/remote/SHA；人工确认后才交给执行器。

失败注入： 故意提供一个缺字段、过期版本或无权限目标，确认流程停在预定门禁。
观测指标： 待确认字段数、规划修改次数、错误基线分支数。
回滚方法： 远端前进或证据不唯一时废弃计划并重新生成；规划器本身不改 Git 状态。