@haaaiawd/anws 2.0.4 → 2.0.5

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

@@ -14,6 +14,8 @@
 - **[验证]**: 检查点任务（人工 / E2E 验证）
 - **用户故事**: 映射到 PRD（US01, US02...）
 - **验收成立**: 验收成立条件
+- **📎 ADR**: 关联的架构决策记录
+- **📎 System**: 关联的系统设计文档
 
 ---
 
@@ -22,12 +24,17 @@
 #### T001 - 数据库 Schema 初始化
 - **用户故事**: US01
 - **描述**: 创建 `users` 表，包含 `id`、`email`、`password_hash`、`created_at` 字段。
+- **输入**: `04_SYSTEM_DESIGN/database.md` §用户表设计
+- **输出**: `migrations/001_create_users.sql`
 - **依赖**: 无
 - **验收成立**: `psql -c "\d users"` 显示正确的表结构。
+- **📎 ADR**: ADR-003 (密码存储方案)
   
 #### T002 - [P] 环境配置
 - **用户故事**: US01
 - **描述**: 添加包含 `DATABASE_URL`、`JWT_SECRET` 的 `.env` 文件。
+- **输入**: `02_ARCHITECTURE_OVERVIEW.md` §环境配置
+- **输出**: `.env.example`, `docker-compose.yml`
 - **依赖**: 无
 - **验收成立**: `docker-compose up` 可以无报错启动数据库。
 
@@ -39,14 +46,20 @@
 #### T003 - 用户注册接口
 - **用户故事**: US01
 - **描述**: 实现 `POST /api/register`，对密码做哈希并保存用户。
-- **依赖**: T001（数据库 Schema）
-- **验收成立**: `curl -X POST /api
+- **输入**: `04_SYSTEM_DESIGN/auth.md` §注册流程, T001 产出的 `users` 表
+- **输出**: `src/routes/auth.js`, `src/services/user.service.js`
+- **依赖**: T001
+- **验收成立**: `curl -X POST /api/register` 返回 201。
+- **📎 ADR**: ADR-003 (密码存储方案)
 
 #### T004 - [P] JWT Token 生成
 - **用户故事**: US01
 - **描述**: 创建 `generate_token(user_id)` 辅助函数。
-- **依赖**: T002（JWT_SECRET 已配置）
+- **输入**: `04_SYSTEM_DESIGN/auth.md` §JWT 签发, T002 产出的 `JWT_SECRET` 配置
+- **输出**: `src/utils/jwt.js`
+- **依赖**: T002
 - **验收成立**: 单元测试 `test_generate_token()` 通过。
+- **📎 ADR**: ADR-004 (JWT 认证方案)
 
 ---
 
@@ -64,18 +77,21 @@
 #### T005 - 登录接口
 - **用户故事**: US01
 - **描述**: 实现 `POST /api/login`，校验凭证并返回 JWT。
-- **依赖**: T003（用户表已有数据）、T004（JWT 生成器就绪）
-- **输入**: T003 产出的 `users` 表 + T004 产出的 `generate_token()` 函数
+- **输入**: `04_SYSTEM_DESIGN/auth.md` §登录流程, T003 产出的 `users` 表, T004 产出的 `generate_token()` 函数
 - **输出**: `/api/login` 端点 (`src/routes/auth.js`)
+- **依赖**: T003, T004
 - **验收成立**: 
   1. 合法登录返回 `{token: "..."}`。
   2. 非法登录返回 401。
+- **📎 ADR**: ADR-004 (JWT 认证方案)
 
 #### INT-S2 - [MILESTONE] S2 集成验证 — 核心逻辑
 - **用户故事**: US01
 - **类型**: 集成验证（迭代关卡）
 - **描述**: 验证 S2 退出标准：完整认证流程可运行
-- **依赖**: S2 的所有任务（T003-T005）
+- **输入**: `02_ARCHITECTURE_OVERVIEW.md` §认证流程, S2 所有任务的产出
+- **输出**: 集成验证报告
+- **依赖**: T003, T004, T005
 - **验收成立**:
   1. 运行 `npm run dev` 或等价命令
   2. 通过 `/api/register` 注册新用户
@@ -117,6 +133,7 @@ T002 (环境配置) [P]
 - [ ] 所有任务都有唯一 ID
 - [ ] 依赖关系明确（使用 `→` 表示）
 - [ ] 每个任务都有 `验收成立` 条件
+- [ ] **每个任务的「输入」都引用了设计文档**（ADR/System Design/PRD/Architecture）
 - [ ] 任务中不包含实际代码（仅保留 <10 行描述）
 - [ ] 总体估时合理
 - [ ] 用户已确认该任务清单
@@ -135,8 +152,10 @@ T001 - 构建认证系统
 ✅ **好任务示例**：
 ```
 T001 - 数据库 Schema 初始化
+- 输入: `04_SYSTEM_DESIGN/database.md` §用户表设计
 - 描述: 创建包含 `id`、`email`、`password_hash` 的 `users` 表。
 - 验收成立: `psql -c "\d users"` 显示正确表结构。
+- 📎 ADR: ADR-003 (密码存储方案)
 ```
 
 ---

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

@@ -75,8 +75,9 @@ description: "将架构设计拆解为可执行的 WBS 任务清单。适用于
 ```markdown
 - [ ] **T{X}.{Y}.{Z}** [REQ-XXX]: 任务标题
   - **描述**: 具体要做什么
-  - **输入**: 依赖的文件/接口（如依赖前置任务，必须引用其具体输出产物）
+  - **输入**: 设计文档引用 + 前置任务产出（必须包含至少一个文档引用）
   - **输出**: 产出的文件/组件/接口
+  - **📎 参考**: ADR_XXX_*.md 或 System Design 章节（如有）
   - **验收标准**: 
     - Given [前置条件]
     - When [执行动作]
@@ -87,6 +88,13 @@ description: "将架构设计拆解为可执行的 WBS 任务清单。适用于
   - **依赖**: 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]

package/templates/.agents/workflows/challenge.md

@@ -26,19 +26,20 @@ description: "对项目决策进行系统性挑战，用证据证明风险真实
 
 ---
 
-## ⚠️ CRITICAL 强制深度思考
+## ⚠️ CRITICAL 深度思考要求
 
 > [!IMPORTANT]
-> **为什么必须使用 `sequential-thinking`？**
+> **质疑需要深度思考，思考方式基于模型能力和任务复杂度。**
+> 
+> **核心判断规则**：
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单质疑**（问题明确、步骤 < 5）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂质疑**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
 > 
 > 质疑不是"扫一眼文档然后列问题"。质疑需要**深度思考**：
 > - 你需要理解设计者的意图，才能找到他们遗漏的部分
 > - 你需要推演因果链，才能证明问题真实存在
 > - 你需要模拟系统运行，才能发现隐藏的故障模式
-> 
-> **直觉式质疑 = 空想问题 = 无效质疑**
-> 
-> 只有经过 3-5 步的系统性思考，你的质疑才有价值。
 
 ---
 

package/templates/.agents/workflows/design-system.md

@@ -170,7 +170,10 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 ### 1.6 生成上下文摘要
 
 > [!IMPORTANT]
-> 你**必须**使用 `sequential-thinking` skill 组织 3-5 个 thought 生成上下文摘要。
+> **思考方式选择**（基于模型能力和任务复杂度）：
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单系统**（职责清晰）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂系统**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
 
 **思考引导**:
 1. "该系统关联哪些PRD需求？[REQ-XXX]"
@@ -245,9 +248,12 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 **目标**: 深度理解该系统的职责和边界
 
 > [!IMPORTANT]
-> 你**必须**使用 `sequential-thinking` skill 组织 3-5 个 thought 进行系统理解。
+> **思考方式选择**（基于模型能力和任务复杂度）：
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单系统**（职责清晰）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂系统**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
 >
-> **为什么？** 深度理解是良好设计的前提。
+> **为什么需要深度理解？** 深度理解是良好设计的前提。
 
 **思考引导**:
 1. "这个系统的核心职责是什么？（用一句话概括）"
@@ -320,9 +326,12 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 **目标**: 基于调研和上下文，深度设计系统架构
 
 > [!IMPORTANT]
-> 你**必须**使用 `sequential-thinking` skill 组织 5-7 个 thought 进行设计思考。
+> **思考方式选择**（基于模型能力和任务复杂度）：
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单设计**（模式明确、步骤 < 5）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂设计**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
 >
-> **为什么？** 好的设计需要深度思考，不是拍脑袋决定。
+> **为什么需要深度思考？** 好的设计需要深度思考，不是拍脑袋决定。
 
 **思考引导**:
 

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

@@ -21,10 +21,35 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 ---
 
+## ⚠️ CRITICAL 触发条件
+
+> [!IMPORTANT]
+> **明确何时触发 /explore，避免滥用或漏用。**
+>
+> **触发条件**（满足任一）：
+> - 用户明确说"调研"、"探索"、"技术选型"、"方案对比"、"头脑风暴"
+> - `design-system` Step 3 自动调用（调研业界最佳实践）
+> - `genesis` Step 3 技术选型时（可选）
+> - 用户需要深度了解某个技术领域
+>
+> **不触发**：
+> - 用户直接说"开始设计"、"写代码"、"实现功能"
+> - `quickstart` 流程中不主动推荐
+> - 简单问题（单步即可回答）
+>
+> **为什么需要明确触发条件？** explore 是重量级工作流，滥用会拖慢节奏，漏用会导致设计缺乏调研支撑。
+
+---
+
 ## ⚠️ CRITICAL 深度思考要求
 
 > [!IMPORTANT]
-> **为什么必须使用 `sequential-thinking`？**
+> **探索需要深度思考，思考方式基于模型能力和任务复杂度。**
+> 
+> **核心判断规则**：
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单探索**（子问题 < 3）→ 自然 CoT 即可
+> - **有 CoT 模型 + 复杂探索**（需要修正前提、多方案比较）→ 调用 `sequential-thinking` CLI
 > 
 > 探索不是"搜一下 + 想一下"。真正的探索需要：
 > - **分解问题**：找到正确的问题比找到答案更重要
@@ -32,7 +57,7 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 > - **交叉验证**：不同来源的信息需要整合
 > - **收敛提炼**：从混乱中提取结构化洞察
 > 
-> **浅层思考 = 浅层答案 = 无效探索**
+> **判断口诀**：要修正？要比较？要回放？→ 用 CLI；否则 → 自然 CoT
 
 ---
 
@@ -57,9 +82,12 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 **目标**: 真正理解问题，将其分解为可探索的子问题。
 
 > [!IMPORTANT]
-> 你**必须**使用 `sequential-thinking` skill 组织 **3-5 个 thought**。
+> **思考方式选择**（基于模型能力和任务复杂度）：
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单问题**（子问题 < 3）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂问题**（需要修正前提、多方案比较）→ 调用 `sequential-thinking` CLI
 >
-> **为什么？** 问题分解的质量决定了整个探索的方向。错误的分解会导致：
+> **为什么需要深度思考？** 问题分解的质量决定了整个探索的方向。错误的分解会导致：
 > - 搜索了不相关的信息
 > - 发散了错误的方向
 > - 浪费时间在无效探索上
@@ -124,9 +152,12 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 用于：产生创意、探索可能性、突破常规
 
 > [!IMPORTANT]
-> 你**必须**使用 `sequential-thinking` skill 组织 **5-8 个 thought**进行发散思考。
+> **思考方式选择**（基于模型能力和任务复杂度）：
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单发散**（技巧 < 3）→ 用发散技巧组织自然 CoT
+> - **有 CoT 模型 + 复杂发散**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
 >
-> **为什么？** 第一个想法通常是最普通的。突破需要：
+> **为什么需要深度发散？** 第一个想法通常是最普通的。突破需要：
 > - 强迫自己继续想
 > - 尝试不同角度
 > - 连接不相关的概念
@@ -185,9 +216,12 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 **目标**: 整合所有发现，验证一致性，收敛到核心洞察。
 
 > [!IMPORTANT]
-> 你**必须**使用 `sequential-thinking` skill 组织 **3-5 个 thought**进行收敛思考。
+> **思考方式选择**（基于模型能力和任务复杂度）：
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单综合**（子问题 < 3，无矛盾）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂综合**（需要解决矛盾、修正前提）→ 调用 `sequential-thinking` CLI
 >
-> **为什么？** 原始发现是碎片化的。你需要：
+> **为什么需要深度收敛？** 原始发现是碎片化的。你需要：
 > - 识别模式和主题
 > - 解决矛盾信息
 > - 提炼核心洞察

package/templates/.agents/workflows/forge.md

@@ -239,7 +239,12 @@ T{X.Y.Z}, T{X.Y.Z}, T{X.Y.Z}
 ### 3.2 Think Before Code (编码前思考)
 
 > [!IMPORTANT]
-> **编码前必须先思考，不要直接开始写代码。**
+> **编码前必须先思考，思考方式基于模型能力和任务复杂度。**
+>
+> **核心判断规则**：
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单任务**（步骤 < 5，无歧义）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂任务**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
 >
 > **为什么？** 错误的理解导致返工，提前发现问题比事后修复便宜 10 倍。
 

package/templates/.agents/workflows/probe.md

@@ -11,10 +11,9 @@ description: "探测系统风险、隐藏耦合和架构暗坑。适用于接手
 在架构更新 (`.anws/v{N}`) 之前或之后，探测系统风险、暗坑和耦合。
 探测结果将作为**输入**反馈给 Architectural Overview。
 
-**核心能力**：
-- 调用 `nexus-mapper` 执行完整 PROBE 五阶段协议
-- 调用 `runtime-inspector` 补充进程边界分析
-- 产出风险矩阵和 Gap Analysis
+**探测模式**（双级别）：
+- **轻量探测**：nexus-query + runtime-inspector → 快速精准查询
+- **深度探测**：nexus-mapper + runtime-inspector → 完整知识库
 
 **你的限制**：
 - 不修改架构，只**观测**和**报告**
@@ -28,13 +27,21 @@ description: "探测系统风险、隐藏耦合和架构暗坑。适用于接手
 
 ---
 
-## ⚠️ CRITICAL 流程约束
+## ⚠️ CRITICAL 强约束：双级别探测
 
 > [!IMPORTANT]
-> Probe 不修改架构，只**观测**和**报告**。
-> 你的报告应该被 Genesis 过程参考。
+> **Probe 采用双级别探测，强制调用 skill，不允许"空手探测"。**
 >
-> **为什么？** 探测的目的是发现问题，而非解决问题。混在一起会导致视角偏差。
+> | 级别 | 触发条件 | 调用 Skill | 产出 |
+> | :--: | -------- | :--------- | :--- |
+> | **轻量** | 默认 | `nexus-query` + `runtime-inspector` | 精准查询结果 + 进程边界 |
+> | **深度** | 用户要求 `/probe --deep` 或项目 > 100 文件 | `nexus-mapper` + `runtime-inspector` | 完整 `.nexus-map/` 知识库 |
+>
+> **强约束**：
+> - ❌ **禁止**跳过 skill 调用直接写报告
+> - ❌ **禁止**用"目录扫描"替代 nexus-query
+> - ✅ **必须**至少执行轻量探测
+> - ✅ runtime-inspector 在两种级别都调用（进程边界分析不可省略）
 
 > [!NOTE]
 > **Probe 双模式说明**:
@@ -46,23 +53,88 @@ description: "探测系统风险、隐藏耦合和架构暗坑。适用于接手
 
 ---
 
-## Step 1: 执行 nexus-mapper PROBE 协议
+## Step 0: 级别判定
+
+**目标**: 确定探测级别。
+
+**判定规则**:
+
+```markdown
+检查条件：
+1. 用户是否明确要求 `/probe deep`？
+2. 项目源码文件数是否 > 100？
+
+判定结果：
+├── 满足任一条件 → 深度探测 → 跳到 Step 2
+└── 均不满足 → 轻量探测 → 继续 Step 1
+```
+
+**输出**: 记录 `probe_level = "light" | "deep"`
+
+---
+
+## Step 1: 轻量探测
 
-**目标**: 完成项目深度探测，产出 `.nexus-map/` 知识库。
+**目标**: 使用 nexus-query 快速获取关键结构信息。
 
 > [!IMPORTANT]
-> 你**必须**调用 `nexus-mapper` 执行完整的 PROBE 五阶段协议。
->
-> **为什么？** nexus-mapper 已整合了构建拓扑、Git 热点、领域概念分析能力，一次调用即可获得完整的项目认知。
+> 此步骤**必须调用 nexus-query skill**，不允许跳过或替代。
+
+### 1.1 调用 nexus-query
+
+**调用技能**: `nexus-query`
+
+**必执行查询**（按顺序）:
+
+```bash
+# 1. 全局结构摘要
+python $SKILL_DIR/scripts/query_graph.py $AST_JSON --summary
+
+# 2. 核心节点分析（高耦合热点）
+python $SKILL_DIR/scripts/query_graph.py $AST_JSON --hub-analysis --top 10
+
+# 3. 如果有特定关注模块，执行影响分析
+python $SKILL_DIR/scripts/query_graph.py $AST_JSON --impact <关注模块路径>
+```
+
+**输出**: 
+- 模块分布摘要
+- 高耦合热点清单
+- 关键模块影响半径
+
+### 1.2 调用 runtime-inspector
+
+**调用技能**: `runtime-inspector`
+
+> [!IMPORTANT]
+> runtime-inspector **必须调用**，进程边界分析不可省略。
+
+**分析内容**:
+- 识别入口点（main 函数）
+- 追踪进程生成链（spawn, fork）
+- 检测 IPC 契约状态（Strong/Weak/None）
+
+**输出**: Process Roots + Contract Status
+
+---
+
+## Step 2: 深度探测
+
+**目标**: 使用 nexus-mapper 产出完整知识库。
+
+> [!IMPORTANT]
+> 此步骤**必须调用 nexus-mapper skill**，产出完整的 `.nexus-map/` 目录。
+
+### 2.1 调用 nexus-mapper
 
 **调用技能**: `nexus-mapper`
 
 **nexus-mapper 内置能力**:
 - **PROFILE**: AST 提取、文件树、语言覆盖
-- **REASON**: 构建拓扑、依赖分析（原 build-inspector 功能）
+- **REASON**: 构建拓扑、依赖分析
 - **OBJECT**: 质疑验证、三维度分析
-- **BENCHMARK**: Git 热点、耦合对分析（原 git-forensics 功能）
-- **EMIT**: 概念模型、知识库生成（原 concept-modeler 功能）
+- **BENCHMARK**: Git 热点、耦合对分析
+- **EMIT**: 概念模型、知识库生成
 
 **输出**: `.nexus-map/` 目录，包含：
 - `INDEX.md` — AI 冷启动入口
@@ -71,18 +143,14 @@ description: "探测系统风险、隐藏耦合和架构暗坑。适用于接手
 - `concepts/concept_model.json` — 机器可读概念模型
 - `hotspots/git_forensics.md` — Git 热点分析
 
----
-
-## Step 2: 补充运行时拓扑分析
-
-**目标**: 追踪进程间通信和契约状态（nexus-mapper 不覆盖此领域）。
+### 2.2 调用 runtime-inspector
 
 **调用技能**: `runtime-inspector`
 
-**思考引导**:
-1. "进程边界在哪里？通信协议是什么？"
-2. "有没有僵尸进程或协议漂移风险？"
-3. "契约是强类型还是隐式约定？"
+**分析内容**:
+- 识别入口点和进程边界
+- 追踪进程生成链
+- 检测 IPC 契约状态（Strong/Weak/None）
 
 **输出**: Process Roots + Contract Status
 
@@ -96,7 +164,7 @@ description: "探测系统风险、隐藏耦合和架构暗坑。适用于接手
 > 仅在 `.anws/v{N}/` 存在时执行此步骤。
 
 **Gap Analysis 内容**:
-- 将 `.nexus-map/concepts/concept_model.json` 与 `.anws/v{N}/` 中的架构定义对比
+- 对比代码结构与 Architecture Overview 定义的系统边界
 - 识别文档与实现的偏差
 - 标记概念漂移或隐式设计
 
@@ -135,21 +203,22 @@ description: "探测系统风险、隐藏耦合和架构暗坑。适用于接手
 
 **探测时间**: [时间戳]
 **探测模式**: [模式 A/B]
+**探测级别**: [轻量 / 深度]
 
 ## 1. System Fingerprint
-[项目结构概览]
+[模块分布摘要，来自 nexus-query --summary 或 nexus-mapper]
 
 ## 2. Build Topology
-[构建边界和依赖]
+[依赖关系，来自 nexus-query --hub-analysis 或 nexus-mapper]
 
 ## 3. Runtime Topology
-[进程边界和契约]
+[进程边界和契约，来自 runtime-inspector]
 
 ## 4. Temporal Topology
-[历史耦合和热点]
+[历史耦合和热点] (深度探测才有)
 
 ## 5. Gap Analysis
-[文档 vs 代码偏差]
+[文档 vs 代码偏差] (模式 B)
 
 ## 6. Risk Matrix
 
@@ -159,10 +228,11 @@ description: "探测系统风险、隐藏耦合和架构暗坑。适用于接手
 ```
 
 <completion_criteria>
-- ✅ 建立了系统指纹
-- ✅ 识别了构建和运行时拓扑
-- ✅ 发现了历史耦合热点
-- ✅ 完成了 Gap Analysis
+- ✅ 确定了探测级别（轻量/深度）
+- ✅ 调用了 nexus-query 或 nexus-mapper
+- ✅ 调用了 runtime-inspector
+- ✅ 完成了 Gap Analysis（模式 B）
 - ✅ 产出了风险矩阵
+- ✅ 生成了报告文件
 </completion_criteria>
 

package/templates/.agents/workflows/quickstart.md

@@ -8,6 +8,8 @@ description: "智能编排全流程。适用于不确定从哪个工作流开始
 你是 **NAVIGATOR (导航员)**。
 你的核心任务是：**智能诊断项目状态，编排最佳工作流路径。**
 原则：⏸️ 每步必等确认 | 🧭 自动对准起点 | 📋 交付物导向。
+
+**注意**：`/explore` 是独立工作流，不在 quickstart 主流程中。仅在用户明确要求"调研/探索"时才触发。
 </phase_context>
 
 ---