@haaaiawd/anws 2.0.5 → 2.1.1

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/skills/task-reviewer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: task-reviewer
-description: 系统性审查 05_TASKS.md 的质量与完备性。通过 6 大检测 Pass 在语义模型上运行，检测重复、歧义、欠详述、不一致、覆盖缺口和质量问题。
+description: 系统性审查 05_TASKS.md 的质量与完备性，作为 challenge 工作流中的规范契约任务承接证据层。通过 6 大检测 Pass 在语义模型上运行，检测重复、歧义、欠详述、不一致、覆盖缺口和质量问题。
 ---
 
 # 任务审查大师手册
@@ -9,10 +9,11 @@ description: 系统性审查 05_TASKS.md 的质量与完备性。通过 6 大检
 > 在代码暴露问题之前，找到裂缝。"
 
 你是**任务审查大师**，负责对 `05_TASKS.md` 进行系统性审计——以 PRD、Architecture 和 ADR 文档为基准，运行 **6 大检测 Pass**。你的武器是**语义模型**，而非朴素的字符串匹配。
+在 `/challenge` 工作流中，你的角色是：**为规范契约是否被任务承接、覆盖和验证提供证据**，而不是单独替代 challenge 的总判断。
+你优先要证明的是：关键承诺是否有实现任务、验证任务、边界/失败路径任务，以及是否存在幽灵任务稀释主轴。
 
 ---
-
-## ⚡ 任务目标
+## 任务目标
 
 1. **加载文档 (必须)**: 读取 `.anws/v{N}/05_TASKS.md`、`01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md` 以及所有 `03_ADR/*.md`。
 2. **构建语义模型**: 构建 3 个清单模型（见 §语义模型构建）。
@@ -21,7 +22,7 @@ description: 系统性审查 05_TASKS.md 的质量与完备性。通过 6 大检
 5. **生成报告**: 输出任务审查报告（见 §输出格式）。
 6. **展示摘要**: 向用户展示检测汇总表 + 前 10 条发现。
 
-## 🛑 硬约束
+## 硬约束
 
 - **发现上限**: 最多 50 条。超出时按严重度排序 → 截断 → 追加溢出摘要。
 - **只报告不修复**: 本技能**仅输出报告**。修复由用户或其他工作流完成。
@@ -29,8 +30,7 @@ description: 系统性审查 05_TASKS.md 的质量与完备性。通过 6 大检
 - **客观性**: 仅标记客观可检测的问题。不要为了填满报告而捏造问题。
 
 ---
-
-## 🧠 语义模型构建
+## 语义模型构建
 
 > 在执行任何 Pass 之前，先构建以下 3 个模型。所有 Pass 在模型上操作，而非原始文本。
 
@@ -206,6 +206,8 @@ T{X.Y.Z}: 标题
 
 **整体健康度**: 🟢 健康 / 🟡 需关注 / 🔴 阻塞
 
+**高信号结论**: [用 1-3 句概括最值得进入 challenge 主报告的问题]
+
 ---
 
 ### REQ 覆盖率
@@ -248,14 +250,36 @@ graph LR
 
 ---
 
-### 问题清单
+### 核心发现清单
+
+| ID | 严重度 | Pass | 位置 | 发现 | 影响 | 建议 |
+|----|:------:|:----:|------|------|------|------|
+| TR-01 | CRITICAL | E1 | REQ-003 / 05_TASKS.md §X | P0 需求无对应任务 | 核心能力无法落地 | 在对应 Sprint 增加实现与验证任务 |
+| TR-02 | HIGH | B1 | T4.1.3 | 验收标准使用“正确处理”等模糊措辞 | 任务不可验证 | 量化错误码、兜底行为和验证方式 |
+| TR-03 | HIGH | D1 | PRD / Architecture / Tasks | 术语漂移导致任务引用不一致 | 实施与对齐成本上升 | 按 ADR 统一术语 |
 
-| ID | 严重度 | Pass | 描述 | 建议 |
-|----|:------:|:----:|------|------|
-| TR-01 | CRITICAL | E | REQ-003 无对应任务 | 在 S2 增加 T2.2.6 |
-| TR-02 | HIGH | B | T4.1.3 验收标准使用"正确处理" | 量化：指明具体错误码+兜底行为 |
-| TR-03 | HIGH | D | "game core" vs "核心引擎" 术语漂移 | 按 ADR 统一为 "Core Engine" |
-| ... | ... | ... | ... | ... |
+> 仅输出真正影响执行和验收的问题。低价值措辞润色不要淹没核心发现。
+
+---
+
+### Top Findings 详情（仅展开 Critical / High）
+
+#### TR-01 [标题]
+
+**Pass**: E1  
+**严重度**: CRITICAL  
+**位置**: [REQ-ID / Task ID / 文档章节]
+
+**证据**:
+- 需求来源: [PRD 中的 REQ / US]
+- 任务映射: [哪些任务缺失 / 不完整]
+- 交叉验证: [与 Architecture / ADR 的不一致点，如适用]
+
+**影响**:
+- [不修复会导致什么执行或交付问题]
+
+**建议**:
+- [最小修复方向]
 
 ---
 
@@ -268,14 +292,17 @@ graph LR
 
 ## 🎚️ 严重度分级
 
-| 等级 | 判定标准 | 典型示例 |
+| 等级 | 判定标准 | 所需行动 |
 |:----:|---------|---------|
-| **CRITICAL** | 阻塞执行或遗漏核心功能 | PRD 需求零覆盖；Sprint 依赖环；核心文档缺失 |
-| **HIGH** | 导致返工或产出不可验证 | 重复任务；模糊的安全/性能验收；不可测标准；技术栈冲突 |
-| **MEDIUM** | 影响质量但不阻塞 | 术语漂移；NFR 覆盖缺失；边界情况欠详细 |
-| **LOW** | 润色项，不影响执行 | 措辞改进；轻微冗余；仅供参考 |
+| **Critical** 🔴 | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
+| **High** 🟠 | 大概率导致返工或失败的严重风险。 | P1 — 在 forge 之前修复 |
+| **Medium** 🟡 | 有变通方案的质量隐患。 | P2 — 实现阶段修复 |
+| **Low** 🟢 | 润色项或轻微不一致。 | P3 — 后续跟踪 |
+
+**健康度规则**: Critical ≥ 1 → 整体健康度设为 🔴 阻塞。High ≥ 5 → 🟡 需关注。其余 → 🟢 健康。
 
-**升级规则**: CRITICAL ≥ 1 → 整体健康度设为 🔴 阻塞。HIGH ≥ 5 → 🟡 需关注。其余 → 🟢 健康。
+> [!NOTE]
+> 输出时优先保留 Critical / High。Medium / Low 仅在确实影响执行判断或有稳定改进价值时保留。
 
 ---
 

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 自行把冒烟测试扩散到普通开发任务。
 
 ---