Merge PR #94: [moz] docs(§17): issue_assigned steps git 操作具体化

docs/design/17-toolchain-handler-enforcement.md

@@ -436,7 +436,7 @@ Agent 可能写了 action_report 但没真做。缓解机制：
 | Review 有新提交 → reviewer | review_updated | toolchain | 4 步 | 读 diff + 检查修改 + 提交 Review + report |
 | Review 评论 → PR 作者 | review_comment | toolchain | 3 步 | 查看评论 + 响应（修改/回复）+ report |
 | CI 失败 → PR 作者 | ci_failure | toolchain | 3 步 | 查 CI 日志 + 分支判断（代码问题自己修 / 基础设施问题提 Issue 给姜维）+ report |
-| Issue 指派 → 开发者 | issue_assigned / infrastructure_failure | toolchain | 6 步（编码）或 4 步（运维） | 按 label 分流：type/infrastructure → 运维排查；其他 → 创建分支 + 编码 + push + CI + PR + report |
+| Issue 指派 → 开发者 | issue_assigned / infrastructure_failure | toolchain | 6 步（编码，含具体 git 命令）或 4 步（运维） | 按 label 分流：type/infrastructure → 运维排查；其他 → git checkout main/pull → 创建分支 → 编码 → push → CI → PR + report |
 | 部署失败 → 运维 | deploy_failure | toolchain | 3 步 | 查日志 + 分支判断（代码/配置问题自己修 / 基础设施问题提 Issue 给姜维）+ report |
 | @mention → 被@者 | mention | toolchain | 按 guidance | 按 mention 模板的 response_guidance + report |
 | PR 合并 → PR 作者 | review_merged | toolchain | 0 步 | 纯通知，走 _send_toolchain_task（steps 为空，verify 始终通过） |
@@ -524,10 +524,12 @@ action_type: issue_assigned 或 infrastructure_failure
 steps（按 label 分流）:
 
   # 默认路径（编码任务）:
-  1. 创建分支 fix/{issue_number}-{brief}
+  1. 在开发目录执行 git 操作：
+     a. git checkout main && git pull origin main  （确保从最新代码分叉）
+     b. git checkout -b fix/{issue_number}-{brief}  （创建功能分支）
   2. 编码 + 写 UT
-  3. push → 等 CI
-  4. CI 通过后创建 PR（Gitea API: POST /repos/{repo}/pulls）
+  3. git add -A && git commit -m "[moz] fix: {简述}" && git push origin fix/{issue_number}-{brief}
+  4. CI 通过后创建 PR（Gitea API: POST /repos/{repo}/pulls，head: fix/{issue_number}-{brief}, base: main）
   5. 等 Review
   6. 提交 action report
 
@@ -542,6 +544,8 @@ context:
 
 **label 分流说明**：issue_assigned handler 检查 label 中是否包含 `type/infrastructure`。如果是，走运维排查 steps（event_type 设为 infrastructure_failure，verify 始终 auto-pass 防递归）；否则走编码 steps。
 
+**编码路径 git 操作具体化说明**（§17 v3 补充）：原 steps 只写「创建分支」「push」等抽象指令，agent 需要自己推导具体 git 命令。现在 steps 中写清楚完整 git 操作序列（checkout main → pull → checkout -b → commit → push），降低 agent 出错概率。系统不做分支管理（不通过 Gitea API 预创建分支），分支管理完全由 agent 自己执行。ToolchainApiSection 中新增 Git 操作说明段落作为通用参考。
+
 #### 部署失败 → 运维
 
 ```
@@ -650,6 +654,26 @@ context:
 
 Issue 创建的 API 调用方式（curl 示例）统一在 ToolchainApiSection 中，与 action_report / comment 指引并列。steps 指令中不重复 API 调用方式，只描述"做什么"。
 
+#### Git 操作说明段落
+
+ToolchainApiSection 中新增通用 Git 操作说明段落，作为 agent 执行 git 命令的参考：
+
+```
+### Git 操作说明
+
+你的工作目录是开发目录。
+标准分支操作流程：
+  git checkout main && git pull origin main    # 从最新主干开始
+  git checkout -b fix/{branch_name}           # 创建功能分支
+  # ... 写代码 ...
+  git add -A && git commit -m 'message'        # 提交改动
+  git push origin {branch_name}               # 推送到远程
+
+⚠️ 不要在 main 分支上直接 commit。
+```
+
+**设计原则**：系统不做分支管理（不预创建分支、不做 checkout），分支管理完全由 agent 自己执行。ToolchainApiSection 提供通用 git 操作参考，steps 中写清楚具体操作序列。
+
 #### Red Flags 补充
 
 硬约束 Red Flags 表新增一条：