feat(onboarding): git-workflow 模板分支策略升级为复杂度感知 v1.3.0

简单改动直推 main/master，功能性改动开 feat/<name> 分支 + PR，
废弃强制 dev→main 双分支模型。PR 示例 head 字段同步更新。

Rules-Applied: R13

.blueprint/modules/onboarding-pack.md

@@ -116,9 +116,9 @@
 - acceptance: [Tauri command] apply_onboarding_pack(project_id) 分发 lefthook.yml 后检测并激活 hook——找到 lefthook 可执行（node_modules/.bin/ 或 PATH）→ 执行 lefthook install，OnboardingReport 新增 hook_activated 三态（activated / missing_binary / failed），missing_binary 时附安装提示；[MCP tool] verify_onboarding(project_id) → 返回检查链 JSON（模板管理块版本到位 / .git/hooks/pre-commit 含 lefthook / origin 指向 Gitea / CI workflow 文件存在 / commit_metrics 近 30 天有该项目数据），每项 pass|fail + detail，无 error 字段；[cargo test] 检查链判定逻辑纯函数化，覆盖 hook 已挂/未挂、origin 匹配/不匹配（R06/R07）
 - notes: 背景（2026-07-04 侦察确认）——接入包写 lefthook.yml 后从不激活，文件在 hook 死 → conventional 不强制 → 飞轮数据脏；炼境自身未踩纯因手动装过。本卡补两件事：① 分发即激活；② "消费者角色"机器化验证（分发成功 ≠ 功能生效，对应 agent-button-system.md 消费者驱动验证）。产出直接供 B4 健康诊断遵守度消费。同日发现的姊妹雷：cicd.rs PR CI 模板 pnpm lint --if-present 必挂语法已修（dc501f7，回归断言驻军）
 
-### 📋 T2. git-workflow 模板：分支策略升级为复杂度感知
+### 🔵 T2. git-workflow 模板：分支策略升级为复杂度感知
 - complexity: M
-- status: todo
+- status: in_progress
 - files: src-tauri/resources/onboarding/git-workflow.md.tmpl
 - acceptance: [Tauri command] 对已接入项目重跑接入包 → git-workflow.md ONBOARDING_MANAGED 块升至 v1.3.0，内容含「简单改动直推 main/master，功能性改动开 feat/<name> 分支 + PR」策略；PR 创建 MCP 示例 head 字段从 "dev" 改为 "feat/<name>"；docs/templates/agents-meta-rules.md 不含分支策略无需同步
 - notes: 当前模板强制 dev→main 双分支，假设了任意项目都维护常设 dev 分支，实为过度约束。复杂度感知策略（小改直推 main/master，功能性改动开 feat/* + PR）与炼境自身策略一致、与飞轮目标对齐（PR body 是意图层数据），且对单人小项目更友好——不必维护无意义的常设 dev 分支。「简单/功能性」由 agent 根据改动文件数/性质自判，无需外部蓝图标签

src-tauri/resources/onboarding/git-workflow.md.tmpl

@@ -3,19 +3,20 @@
 > 把此文件粘贴给任何 AI Agent，让它了解本项目的 git 工作方式。由炼境接入包分发。
 > `ONBOARDING_MANAGED` 标记块由炼境版本化管理（重跑接入包可原位升级），块外可自由补充项目特有约定。
 
-<!-- ONBOARDING_MANAGED_START version="1.2.0" -->
+<!-- ONBOARDING_MANAGED_START version="1.3.0" -->
 
 ## 分支策略
 
 ```
-dev   ← 日常开发在这里 commit/push
- ↓
-main  ← 稳定分支，通过 PR 合入（合入时触发 CI code review）
+简单改动  → 直接 push main/master
+功能改动  → feat/<name> 分支 → PR → main/master
 ```
 
-- 小改动可直接 push `dev`
-- 功能完整后开 PR（dev → main）
-- 不要直接 push `main`，除非紧急热修复
+- **简单改动**（单文件 bug 修复、配置调整、文档更新）：直接 push `main`/`master`
+- **功能性改动**（多文件修改、新功能、重构、接口变更）：开 `feat/<功能简述>` 分支，完成后 PR 合入
+- 不维护常设 `dev` 分支——每个改动按复杂度选路径，功能分支用完即关
+
+> **为什么**：PR body 是意图层数据（炼境从中采集 Why + 验收结论），PR CI review 是 agent 自验链的最后一环；简单改动不值得开分支的额外成本——按实际复杂度决策，不一刀切。
 
 ## Commit 规范（lefthook 强制）
 
@@ -81,7 +82,7 @@ PR 别攒太大（建议每 3~5 个 commit 或几百行内就开一次），否
 ```
 1. Read .claude/liangjing.json  →  取出 project_id
 2. 调用 MCP 工具 create_pull_request：
-   { "project_id": "<id>", "head": "dev", "base": "main",
+   { "project_id": "<id>", "head": "feat/<name>", "base": "main",
      "title": "<Conventional Commits 格式>", "body": "<变更摘要>" }
 3. 炼境内部用存储的 Gitea 凭证调 API，返回 pr_url
 ```