@haaaiawd/anws 2.0.5 → 2.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haaaiawd/anws",
-  "version": "2.0.5",
+  "version": "2.1.0",
   "description": "Anws — A spec-driven workflow framework for AI-assisted development. Empowers prompt engineers to build production-ready software through structured PRD → Architecture → Task decomposition. Works with Claude Code, GitHub Copilot, Cursor, Windsurf, and any tool that reads AGENTS.md.",
   "keywords": [
     "anws",

package/templates/.agents/skills/task-planner/SKILL.md

@@ -18,8 +18,10 @@ description: 使用WBS方法将系统设计文档分解为层次化任务。支
 2. **加载必需文档**：读取 Architecture Overview + PRD
 3. **加载可选文档**：扫描 ADR 目录 + System Design 目录
 4. **缺失检查**：必需文档缺失则报错退出
-5. **执行拆解**：按 WBS 方法拆解任务
-6. **输出**：保存到 `.anws/v{N}/05_TASKS.md`
+5. **加载测试约束**：如果 Workflow 或 ADR 提供测试策略、质量门禁、Sprint 边界，必须一并纳入任务生成输入
+6. **执行拆解**：按 WBS 方法拆解任务
+7. **应用验证类型选择逻辑**：为每个任务分配“最轻但足够”的验证类型，避免默认升级为 E2E
+8. **输出**：保存到 `.anws/v{N}/05_TASKS.md`
 
 ---
 
@@ -33,6 +35,13 @@ description: 使用WBS方法将系统设计文档分解为层次化任务。支
 > 3. **可验证** - 每个Task有明确的Done When标准
 > 4. **可追溯** - 每个Task关联PRD需求 [REQ-XXX]
 
+> [!IMPORTANT]
+> **测试规划附加原则**：
+> - 优先选择**最轻但足够**的验证类型
+> - 如 Workflow / ADR 已声明测试策略，必须优先遵循，不得自行改重
+> - **冒烟测试默认仅用于 `INT-S{N}` 或极少数里程碑任务**
+> - **回归测试仅在已有关键能力可能被破坏时生成**，不是所有任务的默认要求
+
 ❌ **错误做法**：
 - 平铺任务列表（无层次）
 - 任务过大（如"实现整个后端"）
@@ -114,6 +123,7 @@ description: 使用WBS方法将系统设计文档分解为层次化任务。支
   - **验收标准**: 
     - [ ] Done When 1
     - [ ] Done When 2
+  - **验证类型**: 单元测试 | 集成测试 | E2E测试 | 冒烟测试 | 回归测试 | 手动验证 | 编译检查 | Lint检查
   - **验证说明**: 如何确认任务完成 (检查什么，如何确认)
   - **估时**: 预估工时（如: 2h, 1d, 1w）
   - **依赖**: T{X}.{Y}.{Z} (依赖的Task ID)
@@ -130,11 +140,39 @@ description: 使用WBS方法将系统设计文档分解为层次化任务。支
     - [ ] `npm run dev` 正常启动
     - [ ] 页面显示"Hello World"
     - [ ] TypeScript类型检查通过
+  - **验证类型**: 编译检查
   - **估时**: 2h
   - **依赖**: 无
   - **优先级**: P0
 ```
 
+### 验证类型选择逻辑
+
+> [!IMPORTANT]
+> **如果 Workflow 未给出更具体约束，按以下默认顺序决策：**
+
+1. **局部逻辑 / 纯算法 / 数据变换** → 单元测试
+2. **跨模块 / 接口 / 数据库 / 多服务协作** → 集成测试
+3. **直接面向终端用户的关键路径** → E2E测试 或 手动验证
+4. **Sprint 退出标准 / 里程碑 gate** → 冒烟测试
+5. **修改可能影响已完成关键能力** → 回归测试
+6. **配置、脚手架、基础设施** → 编译检查 / Lint检查 / 手动验证
+
+**选择细则**:
+- 不要因为任务“看起来重要”就默认选择 E2E测试
+- 如果集成测试足以证明任务完成，就不要升级为 E2E测试
+- 如果只是里程碑 readiness 检查，优先使用少量冒烟测试，而不是新建大量 E2E任务
+- 如果只是验证旧能力未被破坏，优先复用已有测试集合作为回归测试
+
+### Sprint 与冒烟测试绑定规则
+
+> [!IMPORTANT]
+> **只有在 Workflow 已提供 Sprint 路线图 / INT 任务语义时，才应生成里程碑级冒烟测试。**
+
+- 如果上游 Workflow 已定义 `INT-S{N}`，则将冒烟测试优先绑定到这些 INT 任务
+- 不要为每个普通 Level 3 开发任务单独生成冒烟测试
+- 若没有明确 Sprint / 里程碑边界，则优先退回单元测试、集成测试、手动验证，而不是滥造冒烟任务
+
 ### 接口追溯规则
 
 > [!IMPORTANT]

package/templates/.agents/skills/task-planner/references/TASK_TEMPLATE.md

@@ -9,11 +9,13 @@
 ## 📋 任务清单
 
 ### 图例说明
-- **ID**: 唯一任务标识符（T001, T002...）
+- **ID**: 唯一任务标识符（T{System}.{Phase}.{Seq}）
 - **[P]**: 可并行（可独立执行）
-- **[验证]**: 检查点任务（人工 / E2E 验证）
+- **[MILESTONE]**: 里程碑 / Sprint 关卡任务（如 `INT-S{N}`）
 - **用户故事**: 映射到 PRD（US01, US02...）
-- **验收成立**: 验收成立条件
+- **验收标准**: Given / When / Then 或 Done When 形式的完成条件
+- **验证类型**: 单元测试 / 集成测试 / E2E测试 / 冒烟测试 / 回归测试 / 手动验证 / 编译检查 / Lint检查
+- **验证说明**: 如何验证任务完成、需要什么证据
 - **📎 ADR**: 关联的架构决策记录
 - **📎 System**: 关联的系统设计文档
 
@@ -21,44 +23,63 @@
 
 ### 阶段 1：基础阶段
 
-#### T001 - 数据库 Schema 初始化
+#### T3.1.1 - 数据库 Schema 初始化
 - **用户故事**: US01
 - **描述**: 创建 `users` 表，包含 `id`、`email`、`password_hash`、`created_at` 字段。
 - **输入**: `04_SYSTEM_DESIGN/database.md` §用户表设计
 - **输出**: `migrations/001_create_users.sql`
 - **依赖**: 无
-- **验收成立**: `psql -c "\d users"` 显示正确的表结构。
+- **验收标准**:
+  - Given 数据库已启动
+  - When 执行迁移并查看 `users` 表结构
+  - Then 表字段与系统设计一致
+- **验证类型**: 集成测试
+- **验证说明**: 运行迁移并执行 `psql -c "\d users"`，保留终端输出作为证据
 - **📎 ADR**: ADR-003 (密码存储方案)
-  
-#### T002 - [P] 环境配置
+
+#### T1.1.1 - [P] 环境配置
 - **用户故事**: US01
 - **描述**: 添加包含 `DATABASE_URL`、`JWT_SECRET` 的 `.env` 文件。
 - **输入**: `02_ARCHITECTURE_OVERVIEW.md` §环境配置
 - **输出**: `.env.example`, `docker-compose.yml`
 - **依赖**: 无
-- **验收成立**: `docker-compose up` 可以无报错启动数据库。
-
+- **验收标准**:
+  - Given 环境变量模板与容器配置已写入
+  - When 执行 `docker-compose up`
+  - Then 数据库可无报错启动
+- **验证类型**: 编译检查
+- **验证说明**: 启动依赖服务并确认终端输出无报错
 
 ---
 
 ### 阶段 2：核心逻辑
 
-#### T003 - 用户注册接口
+#### T2.1.1 - 用户注册接口
 - **用户故事**: US01
 - **描述**: 实现 `POST /api/register`，对密码做哈希并保存用户。
-- **输入**: `04_SYSTEM_DESIGN/auth.md` §注册流程, T001 产出的 `users` 表
+- **输入**: `04_SYSTEM_DESIGN/auth.md` §注册流程, T3.1.1 产出的 `users` 表
 - **输出**: `src/routes/auth.js`, `src/services/user.service.js`
-- **依赖**: T001
-- **验收成立**: `curl -X POST /api/register` 返回 201。
+- **依赖**: T3.1.1
+- **验收标准**:
+  - Given 注册接口已实现
+  - When 发送合法注册请求
+  - Then 返回 201 且用户被写入数据库
+- **验证类型**: 集成测试
+- **验证说明**: 调用 `POST /api/register` 并检查响应与数据库写入结果
 - **📎 ADR**: ADR-003 (密码存储方案)
 
-#### T004 - [P] JWT Token 生成
+#### T2.1.2 - [P] JWT Token 生成
 - **用户故事**: US01
 - **描述**: 创建 `generate_token(user_id)` 辅助函数。
-- **输入**: `04_SYSTEM_DESIGN/auth.md` §JWT 签发, T002 产出的 `JWT_SECRET` 配置
+- **输入**: `04_SYSTEM_DESIGN/auth.md` §JWT 签发, T1.1.1 产出的 `JWT_SECRET` 配置
 - **输出**: `src/utils/jwt.js`
-- **依赖**: T002
-- **验收成立**: 单元测试 `test_generate_token()` 通过。
+- **依赖**: T1.1.1
+- **验收标准**:
+  - Given JWT 辅助函数已实现
+  - When 运行 `test_generate_token()`
+  - Then 所有断言通过
+- **验证类型**: 单元测试
+- **验证说明**: 执行 JWT 相关测试并确认测试通过
 - **📎 ADR**: ADR-004 (JWT 认证方案)
 
 ---
@@ -67,51 +88,58 @@
 
 | 迭代 | 代号 | 核心任务 | 退出标准 | 预估 |
 |------|------|---------|---------|------|
-| S1 | 基础阶段 | T001-T002 | DB 可连接 + 环境变量生效 | 1d |
-| S2 | 核心逻辑 | T003-T005 | 完整认证流程可运行 | 2d |
+| S1 | 基础阶段 | T1.1.1, T3.1.1 | DB 可连接 + 环境变量生效 | 1d |
+| S2 | 核心逻辑 | T2.1.1-T2.2.1 | 完整认证流程可运行 | 2d |
 
 ---
 
 ### 阶段 3：集成阶段
 
-#### T005 - 登录接口
+#### T2.2.1 - 登录接口
 - **用户故事**: US01
 - **描述**: 实现 `POST /api/login`，校验凭证并返回 JWT。
-- **输入**: `04_SYSTEM_DESIGN/auth.md` §登录流程, T003 产出的 `users` 表, T004 产出的 `generate_token()` 函数
+- **输入**: `04_SYSTEM_DESIGN/auth.md` §登录流程, T2.1.1 产出的 `users` 表, T2.1.2 产出的 `generate_token()` 函数
 - **输出**: `/api/login` 端点 (`src/routes/auth.js`)
-- **依赖**: T003, T004
-- **验收成立**: 
-  1. 合法登录返回 `{token: "..."}`。
-  2. 非法登录返回 401。
+- **依赖**: T2.1.1, T2.1.2
+- **验收标准**:
+  - Given 登录接口已实现
+  - When 使用合法凭证请求登录
+  - Then 返回 JWT
+  - Given 非法凭证
+  - When 请求登录
+  - Then 返回 401
+- **验证类型**: 集成测试
+- **验证说明**: 调用 `/api/login` 并分别检查成功与失败路径
 - **📎 ADR**: ADR-004 (JWT 认证方案)
 
 #### INT-S2 - [MILESTONE] S2 集成验证 — 核心逻辑
 - **用户故事**: US01
-- **类型**: 集成验证（迭代关卡）
 - **描述**: 验证 S2 退出标准：完整认证流程可运行
 - **输入**: `02_ARCHITECTURE_OVERVIEW.md` §认证流程, S2 所有任务的产出
 - **输出**: 集成验证报告
-- **依赖**: T003, T004, T005
-- **验收成立**:
+- **依赖**: T2.1.1, T2.1.2, T2.2.1
+- **验收标准**:
   1. 运行 `npm run dev` 或等价命令
   2. 通过 `/api/register` 注册新用户
   3. 使用合法凭证登录 → 收到 JWT 令牌
   4. 使用非法凭证登录 → 收到 401 错误
   5. 所有单元测试通过（`npm test`）
   6. 无 Linter 错误（`npm run lint`）
+- **验证类型**: 集成测试 / 冒烟测试
+- **验证说明**: 按退出标准逐条执行；使用真实注册与登录链路作为最小冒烟检查，并保留日志或截图
 
 ---
 
 ## 🔗 依赖图
 
 ```
-T001 (数据库 Schema)
-  → T003 (注册)
-      → T005 (登录)
+T3.1.1 (数据库 Schema)
+  → T2.1.1 (注册)
+      → T2.2.1 (登录)
 
-T002 (环境配置) [P]
-  → T004 (JWT 辅助函数) [P]
-      → T005 (登录)
+T1.1.1 (环境配置) [P]
+  → T2.1.2 (JWT 辅助函数) [P]
+      → T2.2.1 (登录)
 ```
 
 ---
@@ -132,7 +160,8 @@ T002 (环境配置) [P]
 在将蓝图标记为完成前：
 - [ ] 所有任务都有唯一 ID
 - [ ] 依赖关系明确（使用 `→` 表示）
-- [ ] 每个任务都有 `验收成立` 条件
+- [ ] 每个任务都有 `验收标准`
+- [ ] 每个任务都有 `验证类型` 与 `验证说明`
 - [ ] **每个任务的「输入」都引用了设计文档**（ADR/System Design/PRD/Architecture）
 - [ ] 任务中不包含实际代码（仅保留 <10 行描述）
 - [ ] 总体估时合理
@@ -151,13 +180,14 @@ T001 - 构建认证系统
 
 ✅ **好任务示例**：
 ```
-T001 - 数据库 Schema 初始化
+T3.1.1 - 数据库 Schema 初始化
 - 输入: `04_SYSTEM_DESIGN/database.md` §用户表设计
 - 描述: 创建包含 `id`、`email`、`password_hash` 的 `users` 表。
-- 验收成立: `psql -c "\d users"` 显示正确表结构。
+- 验收标准: Given 迁移完成, When 查看表结构, Then 字段与设计一致。
+- 验证类型: 集成测试
 - 📎 ADR: ADR-003 (密码存储方案)
 ```
 
 ---
 
-**下一步**：进入 `/build` workflow，按顺序实现这些任务。
+**下一步**：进入 `/forge` workflow，按顺序实现这些任务。

package/templates/.agents/workflows/blueprint.md

@@ -58,7 +58,10 @@ description: "将架构设计拆解为可执行的 WBS 任务清单。适用于
 1.  **读取 Architecture**: 读取 `{TARGET_DIR}/02_ARCHITECTURE_OVERVIEW.md`
 2.  **读取 PRD**: 读取 `{TARGET_DIR}/01_PRD.md`
 3.  **读取 ADRs**: 扫描 `{TARGET_DIR}/03_ADR/` 目录
-4.  **调用技能**: `task-planner`
+4.  **加载测试策略约束**:
+    - 如 `{TARGET_DIR}/03_ADR/` 中存在测试策略、质量门禁、验证分层相关 ADR，必须一并读取
+    - 将其中关于单元/集成/E2E/冒烟/回归测试的约束视为 Task 生成输入，而不是事后参考
+5.  **调用技能**: `task-planner`
 
 ---
 
@@ -70,6 +73,14 @@ description: "将架构设计拆解为可执行的 WBS 任务清单。适用于
 > **任务格式要求** (CRITICAL):
 > 每个 Level 3 任务必须包含以下字段。
 
+> [!IMPORTANT]
+> **调用 `task-planner` 时必须显式传递以下约束**:
+> - 当前版本的 PRD、Architecture、ADRs、System Design 是唯一事实来源
+> - 如 ADR 中存在测试策略与质量门禁，`task-planner` 必须优先遵循
+> - 默认按“最轻但足够”的原则选择验证类型
+> - **冒烟测试默认仅放在 `INT-S{N}` 或极少数里程碑任务**
+> - 不得因为“更保险”就把大量任务默认升级成 E2E测试
+
 ### 任务格式模板
 
 ```markdown
@@ -78,71 +89,47 @@ description: "将架构设计拆解为可执行的 WBS 任务清单。适用于
   - **输入**: 设计文档引用 + 前置任务产出（必须包含至少一个文档引用）
   - **输出**: 产出的文件/组件/接口
   - **📎 参考**: ADR_XXX_*.md 或 System Design 章节（如有）
-  - **验收标准**: 
+  - **验收标准**:
     - Given [前置条件]
     - When [执行动作]
     - Then [预期结果]
-  - **验证类型**: [单元测试 | 集成测试 | E2E测试 | 手动验证 | 编译检查 | Lint检查]
+  - **验证类型**: [单元测试 | 集成测试 | E2E测试 | 冒烟测试 | 回归测试 | 手动验证 | 编译检查 | Lint检查]
   - **验证说明**: [如何检查完成，检查什么，具体命令或步骤]
   - **估时**: Xh
   - **依赖**: T{A}.{B}.{C} (如有)
 ```
 
-> [!IMPORTANT]
-> **输入字段强制要求**：
-> - 每个任务的「输入」必须引用至少一个设计文档
-> - 可引用：`02_ARCHITECTURE_OVERVIEW.md`、`01_PRD.md`、`03_ADR/ADR_XXX_*.md`、`04_SYSTEM_DESIGN/*.md`
-> - 禁止模糊描述如"相关设计"、"需求文档"——必须具体到文件和章节
-> - ADR 引用格式统一为 `ADR_XXX_*.md`（与 genesis 保持一致）
-
-### 验证类型说明
+### 测试分层标准
 
 > [!IMPORTANT]
-> **验证类型决定验证方式和证据要求**：
+> **Blueprint 必须按测试分层生成任务，而不是把所有验证都塞成 E2E。**
 >
-> | 验证类型 | 验证方式 | 证据要求 |
-> |---------|---------|---------|
-> | **单元测试** | 运行测试套件 | 终端输出：`X passed, 0 failed` |
-> | **集成测试** | 运行集成测试或 API 调用 | 终端输出或日志截图 |
-> | **E2E测试** | 运行端到端测试脚本 | 测试报告或录屏 |
-> | **手动验证** | 人工检查 | 用户确认 ✅ |
-> | **编译检查** | 构建命令 | 终端输出：`Build succeeded` |
-> | **Lint检查** | Lint 命令 | 终端输出：`0 problems` |
-
-**验证类型选择指南**：
-- 纯逻辑/算法任务 → 单元测试
-- 跨模块/跨系统任务 → 集成测试
-- 用户交互/前端任务 → E2E测试 或 手动验证
-- 配置/基础设施任务 → 编译检查 或 手动验证
-- 代码质量任务 → Lint检查
+> 默认采用以下层次：
+> - **单元测试**: 验证局部逻辑
+> - **集成测试**: 验证模块/系统协作
+> - **冒烟测试**: 验证里程碑关口的少量关键路径是否可运行
+> - **E2E测试**: 验证关键用户故事或主业务链路
+> - **回归测试**: 验证新变更未破坏已完成的关键能力
 
-### 接口追溯规则
+### 冒烟测试使用原则
 
 > [!IMPORTANT]
-> **任务间的输入/输出必须对齐。**
+> **冒烟测试应当少而真实，主要用于里程碑门控，不应泛滥到每个任务。**
 >
-> 如果任务 B 依赖任务 A，则 B 的「输入」必须明确引用 A 的「输出」的具体产物（文件路径、接口名、数据格式）。
->
-> - ✅ 好: B 输入 = “T2.1.2 产出的 `MapGenerator` 类（`src/core/map_gen.py`）的 `generate()` 方法返回的 `World` 对象”
-> - ❌ 差: B 输入 = “地图数据”
+> Blueprint 生成任务时，应优先把冒烟测试放在**大进展、大功能完成、准备进入下一阶段**的关口。
+> 它的目标是验证“系统是否基本可用 / 可演示 / 可继续推进”，而不是替代全量回归测试。
 
-### 验证说明格式指南
+### 回归测试使用原则
 
 > [!IMPORTANT]
-> **验证说明**描述"如何确认任务完成"，而非具体命令。
-> AI 执行任务时根据说明自行确定检查方式。
+> **回归测试不是每次小改都跑全量，而是对“已有能力是否被破坏”的有针对性复验。**
 
-**示例**:
-| 任务类型 | 验证说明示例 |
-|---------|-------------|
-| 前端组件 | 检查组件是否正确渲染；确认交互逻辑符合预期 |
-| API 端点 | 调用接口确认返回正确格式；检查错误处理 |
-| 数据库 Schema | 确认 Migration 成功执行；验证数据类型正确 |
-| 配置文件 | 启动服务确认配置生效；检查环境变量读取 |
-| 单元测试 | 运行测试套件确认全部通过 |
-| 文档 | 阅读确认内容完整准确 |
+### 接口追溯规则
 
-**输出路径**: `{TARGET_DIR}/05_TASKS.md`
+> [!IMPORTANT]
+> **任务间的输入/输出必须对齐。**
+>
+> 如果任务 B 依赖任务 A，则 B 的「输入」必须明确引用 A 的「输出」的具体产物（文件路径、接口名、数据格式）。
 
 ---
 
@@ -151,7 +138,7 @@ description: "将架构设计拆解为可执行的 WBS 任务清单。适用于
 **目标**: 将任务分组为 Sprint/里程碑，每个 Sprint 必须有明确的退出标准和集成验证任务。
 
 > [!IMPORTANT]
-> **每个 Sprint 必须有退出标准和集成验证任务。**
+> **每个 Sprint 必须有退出标准和 INT 集成验证任务。**
 >
 > Sprint 不只是“一堆任务”，而是一个有明确入口和出口的工作单元。
 > 退出标准定义“什么算做完”，集成验证任务负责“证明做完”。
@@ -180,12 +167,15 @@ description: "将架构设计拆解为可执行的 WBS 任务清单。适用于
     - Given S{N} 所有任务已完成
     - When 执行退出标准中的每一项检查
     - Then 全部通过 → Sprint 完成; 有失败 → 记录 Bug 并触发修复波次
-  - **验证说明**: 按土出标准逐条执行，截图/录屏/日志确认
+  - **验证类型**: 集成测试 / 冒烟测试 / E2E测试（按退出标准选择其一或组合）
+  - **验证说明**: 按退出标准逐条执行；如适用，增加少量真实冒烟检查验证关键路径是否可运行；若本 Sprint 改动触及已完成关键能力，可追加最小回归检查，使用截图/录屏/日志确认
   - **估时**: 2-4h
   - **依赖**: S{N} 所有任务
 ```
 
 > INT 任务是该 Sprint 的“关门任务”。未通过 INT 任务的 Sprint 不得标记为完成。
+> 默认优先将“真实冒烟测试”收敛在 INT 任务中，而不是扩散到所有开发任务。
+> 调用 `task-planner` 时，应把 **Sprint 边界 + INT 任务 + 冒烟测试绑定规则** 一并传入，禁止 skill 自行把冒烟测试扩散到普通开发任务。
 
 ---
 

package/templates/.agents/workflows/change.md

@@ -1,5 +1,5 @@
 ---
-description: "处理微调级变更请求，仅允许修改已有任务的细节。适用于任务执行过程中发现描述不准确、验收标准需调整等场景。禁止创建新任务或添加新功能，超出范围时引导用户运行 /genesis。"
+description: "处理当前版本内的局部修订请求，允许修改已有任务的细节和补充必要的承接项。适用于任务执行过程中发现描述不准确、验收标准需调整等场景。禁止创建新功能或添加无关新任务，超出范围时引导用户运行 /genesis。"
 ---
 
 # /change
@@ -8,19 +8,20 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 你是 **CHANGE MANAGER (变更管理师)**。
 
 **核心使命**：
-对已有任务清单进行**微调**。你的权限被严格限定——你是"计划的微调器"，而非"新需求的注入器"。
+- 处理当前版本内的**局部修订与 task 调整**。只要变更不偏离 ADR 与架构基线，就应优先在 `/change` 内完成，而不是动辄升级到新版本。
 
 **核心原则**：
-- **只改不增** - 只能修改已有任务，**禁止创建新任务**
+- **局部修订优先** - 普通文件、设计、任务定义修订默认优先走 `/change`
+- **不偏离 ADR 的 task 调整优先** - 验收标准、估时、优先级、任务编排、少量承接任务补充默认由 `/change` 处理
+- **只改不乱增** - 允许在当前版本内补足必要承接项，但禁止无明确请求的功能蔓延
 - **忠于 Blueprint** - 所有修改必须在 `01_PRD.md` 已定义的需求范围内
 - **人类审批** - 所有写操作必须先展示计划，经人类确认后才能执行
 - **可追溯** - 所有变更都记录在 CHANGELOG
 - **不维护完成状态** - `/change` 只修改任务定义，不负责回填 `05_TASKS.md` checkbox
 
 **Output Goal**: 
-- 更新 `.anws/v{N}/05_TASKS.md` (仅修改已有任务)
+- 更新 `.anws/v{N}/05_TASKS.md`
 - 更新 `.anws/v{N}/06_CHANGELOG.md`
-- (可选) 微调 `.anws/v{N}/04_SYSTEM_DESIGN/` 中已有文件的细节
 
 ---
 
@@ -36,15 +37,18 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 > | 调整已有任务的估时 | ✅ | |
 > | 标记任务阻塞/重分优先级 | ✅ | |
 > | 微调 `04_SYSTEM_DESIGN/` 中已有文件的细节 | ✅ | |
+> | 修改当前版本中的普通文档/设计文件细节 | ✅ | |
+> | 为承接已明确请求的局部修订而补充少量必要任务 | ✅ | |
 > | 更新任务说明字段，但不改变完成状态 | ✅ | |
+> | 调整任务编排、Sprint/Wave 内排序（不改变 ADR 前提） | ✅ | |
 > | **回填 `05_TASKS.md` checkbox** | | ❌ |
-> | **创建新任务 (T{X}.{Y}.{Z})** | | ❌ |
 > | **创建新文件** | | ❌ |
 > | **添加 AI 自认为好的功能** | | ❌ |
 > | **修改 [REQ-XXX] 需求引用** | | ❌ |
 > | **修改 `01_PRD.md`** | | ❌ |
 > | **修改 `02_ARCHITECTURE_OVERVIEW.md`** | | ❌ |
 > | **修改 `03_ADR/` 中的任何文件** | | ❌ |
+> | **修改系统边界或跨系统架构基线** | | ❌ |
 >
 > **违反以上任何一条 → 变更无效，引导用户运行 `/genesis`。**
 
@@ -63,6 +67,7 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 >
 > **你的职责是忠实执行用户要求的微调，而非自作主张改善系统。**
 > **如果你发现了值得改进的地方，请在报告中以"建议"形式告知用户，由用户决定是否通过 `/genesis` 处理。**
+
 </phase_context>
 
 ---
@@ -71,8 +76,13 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 
 > [!IMPORTANT]
 > **变更分类决定处理方式**:
-> - **微调 (Tweak)** → 本工作流处理（仅修改已有任务）
-> - **其他所有变更** → 引导用户运行 `/genesis`
+> - **局部修订 (Local Refinement)** → 本工作流处理
+> - **受控扩展 (Controlled Expansion)** → 本工作流处理，但必须显式展示影响范围
+> - **架构演进 (Architectural Evolution)** → 引导用户运行 `/genesis`
+
+> [!NOTE]
+> **默认判断原则**:
+> 只要变更仍然遵守现有 ADR、系统边界与版本基线，即使需要调整多个 task，也应优先留在 `/change`。
 
 ---
 
@@ -93,33 +103,34 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 
 ---
 
-## Step 1: 变更影响评估 (7 问题法)
+## Step 1: 变更影响评估 (分级判定)
 
-**目标**: 严格判断变更是"微调"还是"超出范围"。
+**目标**: 判断变更属于局部修订、受控扩展，还是必须升级到 `/genesis` 的架构演进。
 
 > [!IMPORTANT]
-> **你必须逐一回答以下 7 个问题**:
-> **全部为"否"才是微调，任意一个"是"就必须走 `/genesis`。**
+> **你必须逐一回答以下 7 个问题**，并据此给出分级。
 
-| # | 评估问题 | 微调条件 |
+| # | 评估问题 | Local / Controlled 条件 |
 |---|---------|---------|
 | 1 | 是否改变系统边界或新增系统? | 否 |
-| 2 | 是否新增外部依赖 (npm包/API/服务)? | 否 |
-| 3 | 是否影响多个系统的接口? | 否 |
-| 4 | 预估工时是否超过 2 天? | 否 |
+| 2 | 是否修改 ADR、Architecture Overview 或版本基线? | 否 |
+| 3 | 是否影响多个系统的接口? | 否或影响可控且不改基线 |
+| 4 | 是否需要新增外部依赖 (npm包/API/服务)? | 否或仅限当前版本内小范围可控引入 |
 | 5 | 用户是否明确要求新版本? | 否 |
-| 6 | **是否需要创建 `05_TASKS.md` 中不存在的新任务?** | **否** |
+| 6 | **是否需要在 `05_TASKS.md` 中新增承接当前变更的少量任务?** | **允许，但必须与用户原话直接对应** |
 | 7 | **变更是否超出 `01_PRD.md` 中已定义的需求范围?** | **否** |
 
 > [!IMPORTANT]
 > **Q6 和 Q7 是核心防线**:
-> - Q6 阻止了通过 `/change` 注入新任务的路径
+> - Q6 允许必要的最小承接，但不允许借机注入无关新功能
 > - Q7 阻止了超出 PRD 范围的"功能蔓延"
 > - 当你不确定 Q7 时，**必须读取 `01_PRD.md` 进行验证**，不允许凭印象判断
+> - **如果变更只是为了更好地兑现现有 ADR 与 PRD，应优先判为 `/change` 可处理**
 
 **判定逻辑**:
-- 7 个问题**全部为"否"** → **微调** (继续 Step 2)
-- **任意**问题为"是" → **超出范围** (跳转 Step 4)
+- 不改变系统边界 / ADR / 版本基线，且影响半径局部 → **局部修订 (Local Refinement)**
+- 不改变系统边界 / ADR / 版本基线，但需要少量任务、任务重排或设计同步调整以兑现当前版本目标 → **受控扩展 (Controlled Expansion)**
+- 只要触及系统边界、ADR、版本基线，或已经无法在当前 ADR 前提下继续收敛 → **架构演进 (Architectural Evolution)**，跳转 Step 4
 
 **输出示例**:
 ```markdown
@@ -131,25 +142,25 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 | 问题 | 答案 | 理由 |
 |------|:----:|------|
 | 改变系统边界? | 否 | 仅修改文案 |
-| 新增外部依赖? | 否 | 无 |
+| 修改 ADR/架构基线? | 否 | 无 |
 | 影响多系统接口? | 否 | 纯前端文案修改 |
-| 工时 > 2天? | 否 | 预估 30 分钟 |
+| 新增外部依赖? | 否 | 无 |
 | 用户要求新版本? | 否 | 未提及 |
-| 需要新任务? | 否 | 对应 T2.1.3 的验收标准修改 |
+| 需要新增承接任务? | 否 | 对应 T2.1.3 的验收标准修改 |
 | 超出 PRD 范围? | 否 | [REQ-005] 已定义登录功能 |
 
-**结论**: ✅ 微调 — 修改 T2.1.3 的验收标准
+**结论**: ✅ 局部修订 — 修改 T2.1.3 的验收标准
 ```
 
 ---
 
 ## Step 2: 定位受影响的已有任务
 
-**目标**: 找到需要修改的已有任务，**不创建新任务**。
+**目标**: 找到受影响的现有任务与文档，并判断是否需要补充最小承接项。
 
 > [!IMPORTANT]
-> **你只能修改已经存在的任务，禁止创建新的 `T{X}.{Y}.{Z}` 条目。**
-> 如果找不到对应的已有任务 → 说明这需要新任务 → 跳转 Step 4 引导 `/genesis`。
+> **优先复用已有任务。**
+> 只有当用户请求的局部修订无法被现有任务承接时，才允许补充少量直接相关的新任务；只要仍不偏离 ADR 与当前版本目标，就不应轻易跳转 `/genesis`。
 
 1.  **读取当前任务清单**:
     读取 `{TARGET_DIR}/05_TASKS.md`
@@ -160,7 +171,9 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 3.  **定位任务**:
     - 找到与变更相关的已有任务 (如 `T2.1.3`)
     - 记录所有实际受影响的已有任务
-    - 如果需要创建新任务才能承接变更 → 跳转 Step 4
+    - 如现有任务无法承接，但变更仍属当前版本内局部修订，可补充少量新任务并在 Step 3 明确展示
+    - 如仅需在当前 ADR 前提下重排任务、调整 Sprint/Wave 归属或补充少量承接项，仍由 `/change` 处理
+    - 如需要重做任务结构的根因是 ADR 已不成立或系统边界已变化 → 跳转 Step 4
 
 4.  **定位相关设计文件** (如需要):
     - 检查 `{TARGET_DIR}/04_SYSTEM_DESIGN/` 中是否有对应的系统设计文件
@@ -203,7 +216,7 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 ```markdown
 ⚠️ 人类检查点 — 变更确认
 
-**变更级别**: 微调 (Tweak)
+**变更级别**: 局部修订 / 受控扩展
 **用户原始请求**: "{用户原话}"
 **受影响任务**: {N} 个
 
@@ -233,12 +246,13 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 1.  **修改任务清单**:
     使用 `replace_file_content` 修改 `{TARGET_DIR}/05_TASKS.md` 中的对应任务定义
     - 仅允许修改任务描述、验收标准、估时、优先级、阻塞说明等定义字段
+    - 如 Step 1 判定为受控扩展，可补充少量与用户原话直接对应的新任务
     - **禁止**在 `/change` 中将 `- [ ]` 改为 `- [x]` 或反向修改 checkbox
 
 2.  **记录变更日志**:
     读取并追加到 `{TARGET_DIR}/06_CHANGELOG.md`:
     ```markdown
-    ## {YYYY-MM-DD} - 微调变更
+    ## {YYYY-MM-DD} - 局部修订变更
     - [CHANGE] T{X}.{Y}.{Z}: {修改描述}
       - 用户原话: "{用户的原始请求}"
       - 修改内容: {具体修改了什么}
@@ -248,7 +262,7 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 
 3.  **更新 AGENTS.md**:
     - 更新 `最近一次更新` 日期。
-    - (注意: 微调不改变待办任务数)
+    - (注意: 局部修订不改变待办任务数)
 
 4.  **报告**: 告知用户变更已完成。
 
@@ -259,8 +273,8 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 **目标**: 告知用户需要运行 `/genesis` 创建新版本。
 
 > [!IMPORTANT]
-> **任何需要"新任务"的变更都不是微调。**
-> 不要试图将变更伪装成微调来处理。
+> **只有触及系统边界、ADR、版本基线或明确的新版本诉求时，才升级到 `/genesis`。**
+> 不要把普通局部修订过度升级为架构演进，也不要把架构演进伪装成 `/change`。
 
 ```markdown
 🚫 此变更**超出 /change 的权限范围**。
@@ -269,8 +283,8 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 - [问题 X]: 是 — {理由}
 
 **为什么 /change 不能处理？**
-/change 的职责是微调已有任务（修改描述、调整验收标准），
-而非创建新功能或添加新任务。
+/change 的职责是处理当前版本内的局部修订与受控扩展，
+但不能改写架构基线、系统边界或版本级决策。
 
 **这能防止什么？**
 - ❌ AI 自行添加"觉得好"的功能
@@ -304,11 +318,10 @@ description: "处理微调级变更请求，仅允许修改已有任务的细节
 ---
 
 <completion_criteria>
-- ✅ 完成 7 问题评估 (含 Q6 新任务检查 + Q7 PRD 范围检查)
-- ✅ 微调变更: 定位已有任务 + 展示计划 + 人类确认 + 执行修改 + 记录 CHANGELOG
+- ✅ 完成 7 问题评估 (含 Q6 承接任务检查 + Q7 PRD 范围检查)
+- ✅ 局部修订 / 受控扩展: 定位受影响内容 + 展示计划 + 人类确认 + 执行修改 + 记录 CHANGELOG
 - ✅ 超出范围: 明确告知用户 /change 无权处理，引导 /genesis
 - ✅ 所有写操作前通过了人类检查点
-- ✅ 未创建任何新任务
+- ✅ 如有新增任务，必须与用户原话直接对应且影响范围已显式展示
 - ✅ 未添加任何 AI 自认为好的功能
 </completion_criteria>
-

package/templates/.agents/workflows/explore.md

@@ -137,6 +137,13 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 使用搜索工具搜索相关关键词
 
+> [!IMPORTANT]
+> **可选 Skill 可用性检测**:
+> - `find-skills` 是**可选增强**，不是默认依赖
+> - 如果当前环境支持 `find-skills`，可将其作为方法论与能力发现的额外来源
+> - 如果当前环境**不支持** `find-skills`，直接继续使用 `search_web`、`read_url_content` 等标准搜索路径
+> - **不得因 `find-skills` 不可用而中断 workflow**
+
 **搜索技巧**:
 | 目标 | 技巧 | 示例 |
 |------|------|------|
@@ -146,6 +153,27 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 | 对比分析 | `vs`, `comparison`, `benchmark` | "Rust vs Go benchmark" |
 | 实战经验 | `best practices`, `production` | "K8s production best practices" |
 | 问题解决 | `how to`, `fix`, `solution` | "Python asyncio memory leak fix" |
+| **find-skills** | `find-skills` | "find-skills Rust async" |
+
+> [!IMPORTANT]
+> **`find-skills` 是可选探索源，不是默认必用步骤。**
+>
+> 当问题需要吸收成熟方法论、检查框架、设计启发或测试策略时，可以额外调用 `find-skills`。
+> 适用场景包括：
+> - 想了解某类专业能力是否已有现成 skill 可复用
+> - 希望借鉴 UI/UX、架构评审、测试、性能优化等领域的成熟框架
+> - 需要把外部 skill 中的结构化经验转译进 ADR、SYSTEM_DESIGN、TASKS 或 Workflow
+
+**Skill Harvesting 原则**:
+1.  **先发现**: 用 `find-skills` 查找相关能力或方法源
+2.  **再提炼**: 提取有价值的检查维度、输出结构、启发式原则、验收方式
+3.  **后转译**: 将这些内容写入当前探索报告与后续文档，而不是整段搬运 skill 本体
+4.  **保持可选**: 如果普通搜索和内部推理已足够，不必强行调用 `find-skills`
+
+**备用搜索路径**（当 `find-skills` 不可用时）:
+1.  使用 `search_web` 搜索方法论关键词、最佳实践、对标对象和测试策略关键词
+2.  使用 `read_url_content` 读取高质量文档、官方文档或代表性深度文章
+3.  在最终报告中标注：本次结论来自 Web / 文档搜索，**未使用 skill harvesting 增强**
 
 ### 2.2 向内发散 (Inward Divergence) 🧠
 
@@ -248,6 +276,12 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 将内容保存到报告文件。
 
+> [!NOTE]
+> 如果本次探索使用了 `find-skills`，请在报告中明确区分：
+> - 哪些结论来自 Web / 文档搜索
+> - 哪些结论来自 skill harvesting
+> - 哪些内容被建议沉淀到 ADR、SYSTEM_DESIGN、TASKS 或 Workflow
+
 **报告模板**:
 
 ```markdown

package/templates/.agents/workflows/genesis.md

@@ -146,6 +146,38 @@ description: "从 0 到代码的项目启动全流程。适用于新项目立项
 
 ---
 
+## Step 2.5: 研究闸门 (Explore Gate)
+
+**目标**: 在高不确定性决策进入技术评估与 ADR 前，按需补充外部调研。
+
+> [!IMPORTANT]
+> **此步骤是条件触发，不是默认必跑。**
+>
+> **满足任一条件时，应插入 `/explore`**:
+> - 技术方案存在明显不确定性，需要先调研再比较
+> - 决策涉及 UI 风格、交互模式、工作台信息架构等高专业度问题
+> - 用户明确要求对标某个产品、行业实践或最佳实践
+> - 该 ADR 需要外部证据支撑，而非仅靠内部推导
+> - 需要检索可复用的方法论、检查框架或技能资产
+> - 需要先明确测试策略、质量门禁或验证分层，再决定架构和任务模板
+
+ **执行方式**:
+ 1.  **判断是否触发**: 基于 PRD、用户原话和预期 ADR 类型判断是否需要研究前置
+ 2.  **如需触发**: 调用 `/explore`，产出结构化研究结论
+     *   如问题涉及方法论、专业框架、测试策略或设计启发，可在 `/explore` 中按需使用 `find-skills`
+     *   如果运行环境中没有可用的 `find-skills`，则直接退化为普通搜索与结构化调研，不得阻塞 workflow
+ 3.  **使用研究结果**:
+     *   为 Step 3 的技术评估补充候选方案、对比维度和外部证据
+     *   为 Step 5 的 ADR 提供决策理由、Trade-off 和影响分析输入
+     *   如研究结果涉及测试金字塔、冒烟/回归策略、质量门禁，应在 Step 5 或后续设计文档中明确沉淀
+ 4.  **如不触发**: 直接进入 Step 3
+
+> [!NOTE]
+> `/explore` 提供的是**研究证据和方法论增量**，不是 ADR 的替代品。
+> 正式决策仍在 Step 5 写入 ADR 文件。
+
+---
+
 ## Step 3: 技术选型 (Tech Stack Selection)
 
 > [!TIP]
@@ -156,18 +188,29 @@ description: "从 0 到代码的项目启动全流程。适用于新项目立项
 > 
 > 每个 Skill 的追问都是必要的交互，应当执行而非绕过。
 
-**目标**: 评估技术栈候选方案,为 Step 5 的 ADR 决策提供依据。
+ **目标**: 评估技术栈候选方案,为 Step 5 的 ADR 决策提供依据。
 
-> [!IMPORTANT]
-> 你**必须**只输出评估结果,**不要提前写入 ADR 文件**。
+ > [!IMPORTANT]
+ > **技术选型不仅包括运行时和框架，还应审视验证策略。**
+ >
+ > 至少需要明确以下问题是否要进入 ADR 或后续设计文档：
+ > - 本项目主要依赖单元测试、集成测试、E2E测试中的哪些层
+ > - 是否需要里程碑级冒烟测试
+ > - 是否需要发布前或高风险改动后的回归测试
+ > - 测试运行的主要门禁放在 PR、INT、预发布还是发布前
+
+ > [!IMPORTANT]
+ > 你**必须**只输出评估结果,**不要提前写入 ADR 文件**。
 >
 > **为什么**: ADR 是正式决策记录,需要在 Step 5 经过完整审视后才能写入。Step 3 只负责技术评估,不做最终决策。
 
 1.  **调用技能**: `tech-evaluator`
-2.  **执行评估**:
-    *   基于 PRD 约束
-    *   12 维度评估
-3.  **输出**: 候选方案对比表 (Markdown 格式,暂存在内存中,不写入文件)
+ 2.  **执行评估**:
+     *   基于 PRD 约束
+     *   如 Step 2.5 已触发，则吸收研究结论中的候选方案、评估维度和约束
+     *   评估与该项目类型匹配的测试策略与质量门禁
+     *   12 维度评估
+ 3.  **输出**: 候选方案对比表 (Markdown 格式,暂存在内存中,不写入文件)
 
 ---
 
@@ -194,16 +237,18 @@ description: "从 0 到代码的项目启动全流程。适用于新项目立项
 
 **目标**: 基于 Step 3 的技术评估,正式记录架构决策 (ADR)。
 
-> [!IMPORTANT]
-> 你**必须**基于 Step 3 的候选方案对比表,正式写入 ADR 文件。
+ > [!IMPORTANT]
+ > 你**必须**基于 Step 3 的候选方案对比表,正式写入 ADR 文件。
 >
 > **为什么**: ADR 是跨系统决策的唯一记录源,后续 SYSTEM_DESIGN 会引用它。
 
-1.  **基于 Step 3 评估**: 将 Step 3 的候选方案对比表转化为正式 ADR
-2.  **使用 ADR 模板**: 参考 `tech-evaluator` skill 的 ADR_TEMPLATE.md
-3.  **输出**: 保存到 `.anws/v{N}/03_ADR/ADR_001_TECH_STACK.md`
-4.  **识别其他决策**: 认证方式、通讯协议等跨系统决策
-5.  **输出其他 ADR**: 保存到 `.anws/v{N}/03_ADR/ADR_00X_*.md`
+ 1.  **基于 Step 3 评估**: 将 Step 3 的候选方案对比表转化为正式 ADR
+ 2.  **吸收 Step 2.5 研究结论** (如有): 将外部调研、对标发现和方法论证据纳入决策理由与 Trade-off
+ 3.  **使用 ADR 模板**: 参考 `tech-evaluator` skill 的 ADR_TEMPLATE.md
+ 4.  **如测试策略属于跨系统约束**: 记录测试分层、冒烟/回归门禁、关键验证时机等决策
+ 5.  **输出**: 保存到 `.anws/v{N}/03_ADR/ADR_001_TECH_STACK.md`
+ 6.  **识别其他决策**: 认证方式、通讯协议、测试门禁等跨系统决策
+ 7.  **输出其他 ADR**: 保存到 `.anws/v{N}/03_ADR/ADR_00X_*.md`
 
 **检查清单**:
 - [ ] ADR 包含"影响范围"章节