diff --git a/.blueprint/modules/onboarding-pack.md b/.blueprint/modules/onboarding-pack.md index 08d1239..b9efdea 100644 --- a/.blueprint/modules/onboarding-pack.md +++ b/.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/ 分支 + PR」策略；PR 创建 MCP 示例 head 字段从 "dev" 改为 "feat/"；docs/templates/agents-meta-rules.md 不含分支策略无需同步 - notes: 当前模板强制 dev→main 双分支，假设了任意项目都维护常设 dev 分支，实为过度约束。复杂度感知策略（小改直推 main/master，功能性改动开 feat/* + PR）与炼境自身策略一致、与飞轮目标对齐（PR body 是意图层数据），且对单人小项目更友好——不必维护无意义的常设 dev 分支。「简单/功能性」由 agent 根据改动文件数/性质自判，无需外部蓝图标签 diff --git a/src-tauri/resources/onboarding/git-workflow.md.tmpl b/src-tauri/resources/onboarding/git-workflow.md.tmpl index 56b421c..cda70d2 100644 --- a/src-tauri/resources/onboarding/git-workflow.md.tmpl +++ b/src-tauri/resources/onboarding/git-workflow.md.tmpl @@ -3,19 +3,20 @@ > 把此文件粘贴给任何 AI Agent，让它了解本项目的 git 工作方式。由炼境接入包分发。 > `ONBOARDING_MANAGED` 标记块由炼境版本化管理（重跑接入包可原位升级），块外可自由补充项目特有约定。 - + ## 分支策略 ``` -dev ← 日常开发在这里 commit/push - ↓ -main ← 稳定分支，通过 PR 合入（合入时触发 CI code review） +简单改动 → 直接 push main/master +功能改动 → feat/ 分支 → 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": "", "head": "dev", "base": "main", + { "project_id": "", "head": "feat/", "base": "main", "title": "", "body": "<变更摘要>" } 3. 炼境内部用存储的 Gitea 凭证调 API，返回 pr_url ```