---
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 能直接产出可派发任务卡
- 需求不清晰时先向用户确认，再开始分析
