feat(flywheel): 阶段三执行质量预测层(trailer 死链修复 + 风险画像) #2
@ -161,10 +161,22 @@ concept 卡是想法 inbox,**不要求 files / acceptance / complexity**,随
|
||||
```yaml
|
||||
version: 1
|
||||
name: 项目名称
|
||||
iteration: 1 # 当前迭代号(默认 1,重构已完成模块时手动递增)
|
||||
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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 待做)
|
||||
- status: in_progress
|
||||
- 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(健康诊断遵守度,后置)
|
||||
### ✅ agent 按钮体系分发(B1/B2/B3 已完成,B4 后置)
|
||||
- status: done
|
||||
- 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,后置) 健康诊断加体系遵守度检查。移植体验=零新增动作,接入流程不变。
|
||||
|
||||
|
||||
@ -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 非空`
|
||||
|
||||
@ -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规范。 -->
|
||||
|
||||
## 架构与模块
|
||||
|
||||
|
||||
@ -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 ← 稳定分支,通过 PR 合入(合入时触发 CI code review)
|
||||
main/master ← 主分支,保持稳定
|
||||
↑
|
||||
├── 简单改动 → 直接 push main/master
|
||||
└── 功能性改动 → feat/<name> 分支 → PR → main/master
|
||||
```
|
||||
|
||||
- 小改动可直接 push `dev`
|
||||
- 功能完整后开 PR(dev → main)
|
||||
- 不要直接 push `main`,除非紧急热修复
|
||||
**简单改动(直接推主分支)**:bug fix、chore、docs、style、单文件小改,行为对外无变化。
|
||||
|
||||
**功能性改动(开 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
|
||||
```
|
||||
|
||||
Loading…
Reference in New Issue
Block a user