- AGENTS.md.tmpl: v1.2.0,新增 rule#5 acceptance 可执行化([载体] 调用→断言) - 炼境 AGENTS.md: ONBOARDING_MANAGED 同步至 v1.2.0 - /architect: 新增 Step 3.5 声明验证路径载体(Tauri/HTTP/CLI/Playwright 优先级表) - /splitter: acceptance 格式升级为可执行验证路径,含三类示例
80 lines
2.5 KiB
Markdown
80 lines
2.5 KiB
Markdown
---
|
||
name: architect
|
||
description: 针对复杂新功能做架构分析,输出设计决策文档,为 splitter 提供输入。Use for L-complexity tasks before writing any code.
|
||
allowed-tools: Read, Glob, Grep, Bash(git log *), Bash(git diff *)
|
||
---
|
||
|
||
# 架构分析
|
||
|
||
在写任何代码之前,先理解现有结构,再做设计决策。
|
||
|
||
## 步骤
|
||
|
||
### 1. 读取项目上下文
|
||
- 读取 `CLAUDE.md` 了解技术栈和目录结构
|
||
- 若存在 `.blueprint/manifest.yaml`,读取它了解模块全景和依赖关系
|
||
|
||
### 2. 分析现有实现模式
|
||
根据需求涉及的层次读取核心文件:
|
||
- 数据层入口(数据库 schema、model 定义)
|
||
- 后端服务层(API / command 注册列表)
|
||
- 前端调用层(API 封装、状态管理)
|
||
- 相关功能模块的现有实现(同类功能参考)
|
||
|
||
### 3. 识别系统边界
|
||
确认本次需求涉及的层次变更:
|
||
- 是否需要新增数据表或字段
|
||
- 是否需要新增后端接口 / command
|
||
- 前后端数据流如何变化
|
||
|
||
### 3.5 声明验证路径载体
|
||
|
||
读取项目 AGENTS.md 的「agent 按钮与验证路径」章节(若存在),按载体就近原则确认本功能的验证载体:
|
||
|
||
| 项目类型 | 优先验证载体 |
|
||
|---------|------------|
|
||
| 桌面应用(Tauri) | 直接调用 command 函数(vitest / cargo test) |
|
||
| Web 服务 | HTTP API 端点(curl / supertest) |
|
||
| CLI / 脚本 | 命令行 / npm scripts |
|
||
| UI 呈现层 | Playwright 驱动真界面(最后手段,仅关键路径) |
|
||
|
||
写一条示例验证步骤:`[载体类型] 调用/请求什么(参数) → 断言什么`。
|
||
|
||
### 4. 输出设计文档
|
||
|
||
```
|
||
## 设计决策:<功能名>
|
||
|
||
### 背景
|
||
<关联的现有模块>
|
||
|
||
### 方案选择
|
||
<2-3 个方案及取舍,标注选定方案>
|
||
|
||
### 受影响文件
|
||
- 新增:<路径> — <用途>
|
||
- 修改:<路径> — <改动说明>
|
||
|
||
### 系统边界变更
|
||
<新增接口 / 数据表 / 字段定义>
|
||
|
||
### 验证路径
|
||
- 载体:<选定的验证载体(Tauri command / HTTP API / CLI / Playwright)>
|
||
- 示例:[载体] <具体调用>(<参数示例>) → <断言预期结果>
|
||
|
||
### 风险点
|
||
- <风险>:<规避方式>
|
||
|
||
### 拆解建议
|
||
建议拆为 N 张任务卡,依赖顺序:卡A → 卡B → 卡C
|
||
```
|
||
|
||
### 5. 更新蓝图(若项目有 .blueprint/)
|
||
- 若需要新模块,在 `manifest.yaml` 新增(status: concept)
|
||
- 创建对应 `modules/<id>.md` 骨架
|
||
|
||
## 原则
|
||
- **不写任何代码**,只输出设计文档
|
||
- 设计文档要足够具体,让 splitter 能直接产出可派发任务卡
|
||
- 需求不清晰时先向用户确认,再开始分析
|