feat(onboarding): T2+B3 复杂度感知分支策略 + agent 按钮载体声明体系

T2 git-workflow 模板升 v1.3.0:
- 分支策略从强制 dev→main 改为复杂度感知
  （简单改动直推 main/master，功能性改动开 feat/<name> 分支+PR）
- PR 创建 MCP 示例 head 从 "dev" 改为 "feat/<name>"

B3 agent 按钮载体声明闭环:
- CONVENTIONS.md manifest.yaml 规范新增 agent_button_carrier 字段
  （tauri/http/cli/playwright，新建蓝图时必填）
- splitter SKILL.md 三级优先载体继承：manifest字段 > architect声明 > 就近推断
- 炼境自身 manifest.yaml 补 agent_button_carrier: tauri
- AGENTS.md.tmpl 项目概况 TODO 提示新增载体字段填写指引

Rules-Applied: R04,R13

.blueprint/CONVENTIONS.md

@@ -163,8 +163,20 @@ version: 1
 name: 项目名称
 iteration: 1                   # 当前迭代号（默认 1，重构已完成模块时手动递增）
 updated: YYYY-MM-DD
+agent_button_carrier: tauri    # 项目主验证载体（见下方说明），新建蓝图时必填
 ```
 
+**`agent_button_carrier` 取值**（就近原则，与 AGENTS.md 载体谱系对应）：
+
+| 值 | 适用场景 | 对应验证方式 |
+|----|---------|-------------|
+| `tauri` | Tauri 桌面应用 | `cargo test` / Tauri command 函数 |
+| `http` | Web 服务 / REST API | `curl` / HTTP 端点 |
+| `cli` | CLI 工具 / npm scripts | 命令行调用 |
+| `playwright` | 纯 UI 呈现层（最后手段） | Playwright 真界面驱动 |
+
+> 新建蓝图时 AI 必须根据技术栈自动推断并填入此字段。`splitter` 生成任务卡时直接从此字段继承载体，无需每次重新推断。
+
 ### 模块字段
 
 ```yaml

.blueprint/manifest.yaml

@@ -7,6 +7,7 @@ description: >
   形成可自我进化的开发智能闭环。
 iteration: 1
 updated: 2026-07-04
+agent_button_carrier: tauri
 
 
 
@@ -370,7 +371,7 @@ modules:
     area: backend
     status: in_progress
     progress: 99
-    note: "体系分发主线：T1/B1/B2/B3/V1 ✅（V1 2026-07-04：lefthook 分发即激活 + verify_onboarding 六项检查链）；剩 B4 健康诊断遵守度（后置）"
+    note: "体系分发主线：T1/T2/B1/B2/B3/V1 ✅（T2 2026-07-04：git-workflow 复杂度感知分支策略；B3 2026-07-04：manifest agent_button_carrier + splitter 三级载体继承）；剩 B4 健康诊断遵守度（后置）"
     position: [3500, 0]
 
   - id: gitea-integration

.blueprint/modules/onboarding-pack.md

@@ -117,16 +117,18 @@
 - 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: in_progress
+- status: done
+- done_note: 2026-07-04 完成。模板 ONBOARDING_MANAGED 升至 v1.3.0，分支策略改为复杂度感知（简单改动直推 main/master，功能性改动开 feat/<name> 分支+PR），PR MCP 示例 head 从 "dev" 改为 "feat/<name>"
 - 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 根据改动文件数/性质自判，无需外部蓝图标签
 
-### 🔵 agent 按钮体系分发（B1/B2 已完成，B3/B4 待做）
+### ✅ agent 按钮体系分发（B1/B2/B3 已完成，B4 后置）
-- status: in_progress
+- status: done
-- progress: 2026-07-03 B1 done——CONVENTIONS 1.10.0 加 R12（边界单点实现）+ R13（M/L 验收路径须真实走通，含载体就近选择表）；B2 done——AGENTS.md.tmpl v1.1.0 管理块含「agent 按钮与验证路径」章节（双投影/边界单点/载体表/完成的定义/侦察→驻军）。剩 B3（提示词升级，M，单独一轮）、B4（健康诊断遵守度，后置）
+- done_note: 2026-07-04 B3 完成——CONVENTIONS.md manifest.yaml 规范新增 agent_button_carrier 字段（tauri/http/cli/playwright 四值）+ 必填规则；splitter SKILL.md 优先从 manifest 读取载体（三级优先：manifest字段>architect声明>就近推断）；炼境自身 manifest.yaml 补上 `agent_button_carrier: tauri`；AGENTS.md.tmpl 项目概况 TODO 提示新增该字段填写指引。B4 健康诊断遵守度后置。
+- progress: 2026-07-03 B1 done——CONVENTIONS 1.10.0 加 R12（边界单点实现）+ R13（M/L 验收路径须真实走通，含载体就近选择表）；B2 done——AGENTS.md.tmpl v1.1.0 管理块含「agent 按钮与验证路径」章节（双投影/边界单点/载体表/完成的定义/侦察→驻军）。B3 done 2026-07-04（见 done_note）
 - 版本化闭环要求（2026-07-03 用户澄清，体系分发的灵魂）: 分发不是"发了就不管"——每类资产带版本分发 → 子项目按该版本实践产生经验（成功/失败）→ 经验自吸反哺炼境（trailer/failure_cases/复盘/返工率）→ 按版本分组对比效果 → 修订出新版 → 再分发。CONVENTIONS 是模范生（version+队列对比+梦核+同步，1.8→1.9 已跑通一整圈）；B 系列每类资产按此标准建闭环。**前置依赖提升**：「接入包模板演进分发（MANAGED 块化）」concept 卡——模板无版本机制是当前最大缺口，没有它体系 v2 到不了存量项目
 - notes: 2026-07-03 概念探讨收束后的分发需求（体系详见 memory concept_dual_projection 与 mcp-server 模块 concept 卡）。用户全 agent 开发形态下，"给开发者立规范"="给 agent 注入规范"，可完全机器化。四条现成管道分发四类资产：① B1(S) CONVENTIONS 1.10.0 加 R12 边界单点实现 + R13 验收须真实走通验证路径 + 载体选择原则；② B2(S) 接入包 AGENTS.md 模板加 agent 按钮章节（三要素/载体谱系/侦察驻军）；③ B3(M) init/sync 提示词升级——建蓝图时声明项目按钮载体、acceptance 生成为可执行验证路径格式；④ B4(S,后置) 健康诊断加体系遵守度检查。移植体验=零新增动作，接入流程不变。
 

.claude/skills/splitter/SKILL.md

@@ -32,7 +32,10 @@ allowed-tools: Read, Edit, Write, Glob
 **可派发标准（每张卡必须满足）**
 - `files`：明确列出涉及文件的相对路径
 - `acceptance`：**可执行验证路径**，格式：`[载体] 调用/运行什么(参数) → 断言什么`
-  - 载体从 architect 的「验证路径」声明继承，就近选择：Tauri command / HTTP API / CLI / Playwright
+  - **载体来源（优先级）**：
+    1. 先读 `.blueprint/manifest.yaml` 的 `agent_button_carrier` 字段
+    2. 无此字段时，从当前对话中 `/architect` 的「验证路径」声明继承
+    3. 两者都没有时，就近推断：Tauri 桌面应用 → `cargo test`，Web 服务 → HTTP API，CLI → 命令行
   - 断言要具体（检查字段值、返回码、文件存在、数量 > 0），不写模糊的"功能正常"
   - 示例：`[Tauri command] apply_onboarding_pack(project_id) → 返回 written≥1，磁盘上文件存在`
   - 示例：`[HTTP API] POST /api/projects → 201，body.id 非空`

src-tauri/resources/onboarding/AGENTS.md.tmpl

@@ -7,6 +7,8 @@
 ## 项目概况
 
 <!-- TODO: 一句话描述项目 + 技术栈。例：pnpm monorepo，React 19 + TypeScript 前端 + Hono API。 -->
+<!-- TODO: 在 .blueprint/manifest.yaml 顶层补 agent_button_carrier（tauri/http/cli/playwright），
+          splitter 生成任务卡时直接从此字段继承验证载体。参考 .blueprint/CONVENTIONS.md §manifest.yaml规范。 -->
 
 ## 架构与模块
 

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

@@ -3,19 +3,22 @@
 > 把此文件粘贴给任何 AI Agent，让它了解本项目的 git 工作方式。由炼境接入包分发。
 > `ONBOARDING_MANAGED` 标记块由炼境版本化管理（重跑接入包可原位升级），块外可自由补充项目特有约定。
 
-<!-- ONBOARDING_MANAGED_START version="1.2.0" -->
+<!-- ONBOARDING_MANAGED_START version="1.3.0" -->
 
-## 分支策略
+## 分支策略（复杂度感知）
 
 ```
-dev   ← 日常开发在这里 commit/push
+main/master  ← 主分支，保持稳定
- ↓
+    ↑
-main  ← 稳定分支，通过 PR 合入（合入时触发 CI code review）
+    ├── 简单改动 → 直接 push main/master
+    └── 功能性改动 → feat/<name> 分支 → PR → main/master
 ```
 
-- 小改动可直接 push `dev`
+**简单改动（直接推主分支）**：bug fix、chore、docs、style、单文件小改，行为对外无变化。
-- 功能完整后开 PR（dev → main）
+
-- 不要直接 push `main`，除非紧急热修复
+**功能性改动（开 feat/* 分支 + PR）**：新功能、重构、涉及多模块的 refactor。由 agent 根据改动文件数和性质自判，无需蓝图标签。
+
+分支命名：`feat/<功能简述>`，如 `feat/login-sms`、`feat/order-pagination`。
 
 ## Commit 规范（lefthook 强制）
 
@@ -81,7 +84,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
 ```