@haaaiawd/anws 1.0.1 → 1.2.0

package/templates/.agent/workflows/challenge.md

@@ -133,108 +133,65 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 
 ---
 
-## Step 3: 三维度审查 (Three-Dimensional Review)
+## Step 2.5: 审查模式判定 (Review Mode Detection)
 
-**目标**: 从系统设计、运行模拟、工程实现三个维度逐一审查，**每个质疑都要有据可依**。
+**目标**: 在开始任何审查之前，先确定**本次应该审查什么**——避免无脑双跑。
 
-> [!IMPORTANT]
-> 你**必须**按照以下三个维度进行审查：
->
-> **维度1: 系统设计** - 架构完整性、边界清晰度、一致性
-> **维度2: 运行模拟** - 时序正确性、状态同步、边界条件  
-> **维度3: 工程实现** - 可测试性、可维护性、性能、安全
+根据上下文信号推断模式：
 
-### 3.1 系统设计维度审查
+| 信号 | 推断模式 |
+|------|---------|
+| `05_TASKS.md` 不存在 | `DESIGN` — 只能审查设计 |
+| 用户明确提到任务/任务清单有问题 | `TASKS` |
+| 用户明确说「全面审查」或「都看看」 | `FULL` |
+| `05_TASKS.md` 存在，但用户无明确指向 | `DESIGN`，任务审查**按需自适应升级** |
+| 本轮是修复后的复查，上轮有任务类问题 | `FULL` |
 
-**目标**: 检查架构的完整性和一致性
+**如果模式仍不明确，直接询问用户**：
 
-**审查重点**:
-1. **架构一致性**: 不同文档中的系统描述是否一致？
-2. **边界清晰度**: 每个系统的职责边界是否清晰？有无重叠或遗漏？
-3. **依赖合理性**: 系统间依赖关系是否合理？有无循环依赖？
-4. **接口完整性**: 跨系统接口是否完整定义？
-5. **状态管理**: 系统状态变化是否有明确定义？
+> 本次审查侧重什么？
+> 1. **设计/架构**（design-reviewer）— 架构完整性、接口、运行时行为
+> 2. **任务清单**（task-reviewer）— 任务质量、REQ 覆盖、US 完整性
+> 3. **全面审查**（两者都跑）
 
-**思考引导**:
-1. "这个架构设计背后的核心假设是什么？"
-2. "如果假设不成立会怎样？"
-3. "系统边界定义中有没有歧义或矛盾？"
-4. "接口设计是否考虑了所有边界情况？"
-5. "状态转换是否有清晰的规则？"
+**设置** `REVIEW_MODE` = `DESIGN` / `TASKS` / `FULL`，后续步骤依据此值触发。
 
-### 3.2 运行模拟维度审查
+---
 
-**目标**: 在脑中"运行"系统，发现时序和状态问题
+## Step 3: 设计审查 (Design Review)
 
-> [!IMPORTANT]
-> 你**必须**使用 `sequentialthinking` 进行 **3-5 步**思考。
-> 
-> **为什么？** 运行时问题往往隐藏很深，需要快速模拟推演。复杂情况可循环。
+**触发条件**: `REVIEW_MODE` = `DESIGN` 或 `FULL`
 
-**审查重点**:
-1. **时序一致性**: 时序模型是否自洽？有无"先后顺序"矛盾？
-2. **状态同步**: 分布式状态如何同步？会不会出现不一致？
-3. **并发处理**: 并发操作如何处理？有无竞态条件？
-4. **边界条件**: "空状态"、"满状态"、"异常状态"如何处理？
-5. **故障传播**: 一个组件失败会如何影响其他组件？
+> 如果 `REVIEW_MODE` = `TASKS`，**跳过本步骤**，直接进入 Step 3.5。
 
-**思考引导**:
-1. "如果我跟踪一个典型操作的完整流程，会经过哪些步骤？"
-2. "在每个步骤，系统状态如何变化？"
-3. "如果某个步骤失败，系统会处于什么状态？"
-4. "两个并发操作会如何相互影响？"
-5. "边界条件下系统行为是否定义清楚？"
+调用 `design-reviewer` skill：
+- 输入: `{TARGET_DIR}` 下的 `01_PRD.md`, `02_ARCHITECTURE_OVERVIEW.md`, `03_ADR/`, `04_SYSTEM_DESIGN/`
+- 输出: 设计审查发现清单（含严重度分级 + 文档关联）
 
-### 3.3 工程实现维度审查
+**收集发现**，暂存待 Step 5 合并。
 
-**目标**: 检查设计的可实现性和工程质量
+---
 
-> [!IMPORTANT]
-> 你**必须**使用 `sequentialthinking` 进行 **3-5 步**思考。
-> 
-> **为什么？** 好的设计必须是可实现、可测试、可维护的。
-
-**审查重点**:
-1. **可测试性**: 设计是否便于编写测试？关键逻辑能否单元测试？
-2. **可维护性**: 代码结构是否清晰？修改是否容易？
-3. **性能**: 有无明显的性能瓶颈？
-4. **安全性**: 有无安全漏洞？敏感数据如何保护？
-5. **可观测性**: 如何监控和调试？日志是否充分？
-
-**思考引导**:
-1. "这个设计如何编写单元测试？"
-2. "如果需要修改某个功能，影响范围有多大？"
-3. "有哪些潜在的性能瓶颈？"
-4. "敏感数据（密钥、用户信息）如何保护？"
-5. "系统出问题时如何快速定位？"
-
-**问题分级标准**:
-- **Critical**: 根本性矛盾，不解决无法实现
-- **High**: 严重问题，会导致功能失效或重大返工
-- **Medium**: 中等问题，影响质量但有变通方案
-- **Low**: 轻微问题，优化空间
-
-**输出格式**：
-```markdown
-### [维度] - [问题编号]: [问题标题]
+## Step 3.5: 任务审查 (Task Review)
 
-**严重度**: Critical / High / Medium / Low  
-**文档**: [具体文档位置]
+**触发条件**（满足任一即执行，`05_TASKS.md` 必须存在）：
 
-**问题描述**:
-[详细描述问题，引用具体代码或设计]
+1. `REVIEW_MODE` = `TASKS` 或 `FULL`
+2. **自适应升级**：`REVIEW_MODE` = `DESIGN`，且 design-reviewer 的发现满足以下任一条件：
+   - 存在「架构组件在任务中无覆盖」类问题（对应 task-reviewer Pass D2）
+   - Critical/High 级设计问题超过 3 条，需确认是否已有任务跟进
 
-**证据来源**: 
-- 文档分析: [PRD/Architecture/ADR 中的具体内容]
-- 推理过程: [基于 sequentialthinking 的分析]
-- 类比参考: [类似系统的已知问题]
+**自适应升级时，询问用户**：
 
-**影响**:
-- [如果问题成真的具体后果]
+> 设计审查发现 {N} 个问题可能涉及任务覆盖不足，是否追加任务审查？
+> 1. 是，追加 task-reviewer
+> 2. 否，继续
 
-**建议**:
-[如何验证或解决，可提供多个方案]
-```
+如触发，调用 `task-reviewer` skill：
+- 输入: `{TARGET_DIR}` 下的 `05_TASKS.md`, `01_PRD.md`, `02_ARCHITECTURE_OVERVIEW.md`, `03_ADR/`
+- 输出: 任务审查报告（6-Pass + REQ 覆盖率 + US 完整性 + 问题清单）
+
+**收集发现**，暂存待 Step 5 合并。如跳过，记录 `Task review skipped`（附原因）。
 
 ---
 
@@ -320,28 +277,38 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 
 > **审查日期**: {YYYY-MM-DD}  
 > **审查范围**: {TARGET_DIR} 全部设计文档  
-> **审查者**: AI Challenger  
-> **总计发现**: X 项问题
+> **累计轮次**: {N}
 
 ---
 
-## 🎯 审查方法论
+## 📋 问题总览
 
-本次审查采用三维度分析框架:
+> 此目录随每轮审查同步维护。已解决的轮次仅保留此摘要行，详细内容在确认修复后删除。
 
-1. **系统设计维度** - 架构完整性、边界清晰度、一致性
-2. **运行模拟维度** - 时序正确性、状态同步、边界条件
-3. **工程实现维度** - 可测试性、可维护性、性能、安全
+### 第一轮（{日期}，{X}/{Y} 已修复）
+
+| ID | 严重度 | 摘要 | 状态 |
+|----|--------|------|------|
+| C1-CX | 🔴 | [同级别问题的精简一行摘要] | ✅ 全部修复 / ⏳ 待修复 |
+| H1-HX | 🟠 | [同级别问题的精简一行摘要] | ✅ 全部修复 / ⏳ 待修复 |
+| M1-MX | 🟡 | [同级别问题的精简一行摘要] | ✅ 全部修复 / ⏳ 实现时处理 |
+
+---
+
+## 🎯 审查方法论
 
-每个问题按以下结构描述:
-- **严重度**: Critical / High / Medium / Low
-- **问题描述**: 具体不足
-- **影响**: 对系统的影响
-- **建议**: 解决方案
+本次审查模式: **{REVIEW_MODE}**（DESIGN / TASKS / FULL）
+
+1. **设计审查** (design-reviewer skill) — {执行 / 跳过} — 系统设计 / 运行模拟 / 工程实现 三维度
+2. **任务审查** (task-reviewer skill) — {执行 / 跳过 / 自适应升级} — 重复 / 歧义 / 欠详述 / 不一致 / 覆盖率 / 质量粒度 六大 Pass
+3. **Pre-Mortem** — 预演失败 + 假设验证
+4. **合并评定** — 统一严重度分级 + 综合判断
 
 ---
 
-## 📊 问题统计
+## 🔥 第{N}轮详细审查（当前活跃）
+
+### 📊 本轮问题统计
 
 | 严重度 | 数量 | 占比 |
 |--------|------|------|
@@ -353,15 +320,13 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 
 | 维度 | 问题数 |
 |------|--------|
-| 系统设计 | X |
-| 运行模拟 | X |
-| 工程实现 | X |
+| 设计审查 (design-reviewer) | X |
+| 任务审查 (task-reviewer) | X |
+| Pre-Mortem + 假设验证 | X |
 
 ---
 
-# 第一部分: 系统设计问题
-
-## 🔴 Critical 级别
+# 🔴 Critical 级别
 
 ### C1. [问题标题]
 
@@ -387,45 +352,22 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 
 ---
 
-# 第二部分: 运行模拟问题
-
-## 🔴 Critical 级别
-
-...
-
----
-
-# 第三部分: 工程实现问题
+## 🟡 Medium / 🟢 Low 级别
 
 ...
 
 ---
 
-# 总结与建议
-
-## 🎯 核心发现
-
-**Critical 问题**: [总结最严重的问题]
-
-**High 问题**: [总结高风险问题]
-
-**系统性风险**: [是否存在系统性的设计缺陷]
-
----
-
 ## 📋 建议行动清单
 
 ### P0 - 立即处理 (阻塞)
 1. [C级问题] - [建议方案]
-2. ...
 
 ### P1 - 近期处理 (重要)
 1. [H级问题] - [建议方案]
-2. ...
 
 ### P2 - 持续改进 (优化)
 1. [M/L级问题] - [建议方案]
-2. ...
 
 ---
 
@@ -456,12 +398,56 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 
 ---
 
+## Step 6: 轮次归档协议 (Round Archive Protocol)
+
+**目标**: 保持报告精简，已解决的轮次只保留摘要。
+
+> [!IMPORTANT]
+> **此步骤在每轮新审查开始时自动执行，不需要单独触发。**
+
+### 归档规则
+
+1.  **新轮审查开始时**，检查上一轮的所有问题是否已解决（由用户确认修复）
+2.  **如已解决** →
+    - 在 `📋 问题总览` 中将该轮的状态全部标为 ✅
+    - **删除该轮的详细审查章节**（`## 🔥 第{N-1}轮详细审查`）
+    - 问题总览中的摘要行即为该轮的永久存档
+3.  **如部分解决** →
+    - 已解决的问题在总览中标 ✅
+    - 未解决的问题保留 ⏳ 并在新轮中继续跟踪
+    - 上一轮详情中仅保留未解决问题的描述
+4.  **报告中同一时刻只有一轮详细内容**（当前活跃轮）
+
+### 总览行合并规则
+
+同严重度的已解决问题合并为一行，格式：
+```markdown
+| C1-C4 | 🔴 | 条约矛盾/毁约逻辑/升级公式/领地缺失 | ✅ 全部修复 |
+```
+
+未解决问题保持独立行，格式：
+```markdown
+| R2-C1 | 🔴 | executor v2 动作缺失 | ⏳ 待修复 |
+```
+
+---
+
 <completion_criteria>
 - ✅ 深度阅读了项目设计文档
 - ✅ Pre-Mortem 分析有逻辑依据
 - ✅ 每个质疑点都有证据支撑
 - ✅ 技术健壮性审计已完成
 - ✅ Top 3 假设已尝试验证
-- ✅ 质疑报告格式完整
+- ✅ 质疑报告格式完整（含问题总览目录）
+- ✅ 上一轮已解决问题的详情已归档（仅保留总览行）
 - ✅ 用户已阅读并决定下一步
 </completion_criteria>
+
+---
+
+## 🔀 Handoffs
+
+完成本工作流后，根据情况选择：
+
+- **修复发现的问题** → `/change` — 根据 challenge 报告修复问题 *(存在需要修复的问题时)*
+- **开始编码执行** → `/forge` — 无阻塞问题，开始波次执行 *(无 CRITICAL 问题时)*

package/templates/.agent/workflows/change.md

@@ -292,3 +292,11 @@ description: 处理微调级变更请求，通过 7 问题法严格评估，仅
 - ✅ 未创建任何新任务
 - ✅ 未添加任何 AI 自认为好的功能
 </completion_criteria>
+
+---
+
+## 🔀 Handoffs
+
+完成本工作流后，根据情况选择：
+
+- **继续编码执行** → `/forge` — 变更完成，继续波次执行

package/templates/.agent/workflows/craft.md

@@ -623,4 +623,12 @@ description: [一句话描述]
 
 ---
 
+## 🔀 Handoffs
+
+完成本工作流后，根据情况选择：
+
+- **测试新创建的工作流** → `/quickstart` — 用 quickstart 流程测试新工作流 *(创建完成后需要验证时)*
+
+---
+
 // turbo-all

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

@@ -353,47 +353,93 @@ description: 为单个系统设计详细的技术文档，通过调研最佳实
 **目标**: 使用模板产出完整的系统设计文档
 
 > [!IMPORTANT]
-> 你**必须**使用 `.agent/skills/system-designer/references/system-design-template.md` 模板。
->
-> **为什么？** 统一结构，保证文档质量和完整性。
+> 本步骤最多产出**两个文件**：
+> - **必须**: `{system-id}.md`（L0 导航层）
+> - **按需**: `{system-id}.detail.md`（L1 实现层，当触发 R1-R5 任意一条时）
 
 **步骤**:
 
+### 5.0 拆分检测（Split Detection）
+
+> [!IMPORTANT]
+> **在加载模板之前，先评估是否需要创建 L1 文件。**
+
+检查本次设计草稿是否触发了以下任意一条规则：
+
+| 规则   | 检测项                              | 触发？ |
+| ------ | ----------------------------------- | :----: |
+| **R1** | 任何单个函数/算法伪代码 > 30 行     |  ✅/❌   |
+| **R2** | 所有代码块合计行数 > 200 行         |  ✅/❌   |
+| **R3** | 含配置常量字典且条目 > 5 个         |  ✅/❌   |
+| **R4** | 版本历史注释（`# vX.X 变更`）> 5 处 |  ✅/❌   |
+| **R5** | 预计文档总行数 > 500 行             |  ✅/❌   |
+
+**决策**:
+- 任意触发 → **是**: 创建两个文件（L0 + L1）
+- 全部未触发 → **否**: 只创建一个文件（L0）
+
+*Self-Correction*: "我这个系统触发了 {规则列表}，需要/不需要 detail 文件。"
+
+---
+
 ### 5.1 加载模板
+
+**加载 L0 模板**（必须）:
 读取 `.agent/skills/system-designer/references/system-design-template.md`
 
+**加载 L1 模板**（如果 5.0 决策为「需要」）:
+读取 `.agent/skills/system-designer/references/system-design-detail-template.md`
+
+---
+
 ### 5.2 填充内容
 
-**必需章节**（必须填写）:
+**L0 必需章节**（填入 `{system-id}.md`，必须填写）:
 1. 概览 (Overview)
 2. 目标与非目标 (Goals & Non-Goals)
 3. 背景与上下文 (Background & Context)
-4. 系统架构 (Architecture) - 包含架构图
-5. 接口设计 (Interface Design)
-6. 数据模型 (Data Model)
+4. 系统架构 (Architecture) - 包含 Mermaid 架构图
+5. **接口设计 (Interface Design)** — 用**操作契约表格**代替函数伪代码（见 SKILL.md 守则7）
+6. **数据模型 (Data Model)** — 只放**属性字段声明**，不写方法体（见 SKILL.md 守则8）
 7. 技术选型 (Technology Stack)
 8. **Trade-offs & Alternatives** ⭐ 核心
 9. 安全性考虑 (Security Considerations)
 10. 性能考虑 (Performance Considerations)
 11. 测试策略 (Testing Strategy)
 
-**可选章节**（小项目可简化）:
-12. 部署与运维 (Deployment & Operations) - 可简化
-13. 未来考虑 (Future Considerations) - 可省略
-14. 附录 (Appendix) - 可省略
+**L0 可选章节**（小项目可简化）:
+12. 部署与运维 (Deployment & Operations)
+13. 未来考虑 (Future Considerations)
+14. 附录 (Appendix)
+
+**L1 章节**（填入 `{system-id}.detail.md`，仅当 5.0 决策为「需要」）:
+- §1 配置常量（UNIT_CONFIG 等字典/表格）
+- §2 完整数据结构（含方法体的 @dataclass）
+- §3 核心算法伪代码（完整函数体，按操作契约表格对应）
+- §4 决策树详细逻辑（对应 L0 Mermaid 图的展开）
+- §5 边缘情况与注意事项（从旧文档 `# ⚠️ 注意` 类注释提取）
+- 版本历史表格（集中放在 L1 末尾）
 
 **关键要求**:
-- **架构图**: 必须使用Mermaid绘制
-- **Trade-offs**: 每个重要技术选型都要说明"为什么选A不选B"
-- **追溯链**: 在相关章节引用PRD需求 [REQ-XXX]
-- **约束继承**: 从PRD和ADR继承约束
+- **L0 架构图**: 必须使用 Mermaid 绘制
+- **L0 决策树**: 用 Mermaid `flowchart TD`，不用伪代码
+- **Trade-offs**: 每个重要技术选型都要说明"为什么选 A 不选 B"
+- **追溯链**: 在相关章节引用 PRD 需求 [REQ-XXX]
+- **约束继承**: 从 PRD 和 ADR 继承约束
+
+---
 
 ### 5.3 保存文档
+
+**保存 L0 文件**（必须）:
 将内容保存到 `genesis/v{N}/04_SYSTEM_DESIGN/{system-id}.md`
 
+**保存 L1 文件**（如果 5.0 决策为「需要」）:
+将内容保存到 `genesis/v{N}/04_SYSTEM_DESIGN/{system-id}.detail.md`
+
 **示例路径**:
-- `genesis/v{N}/04_SYSTEM_DESIGN/frontend-system.md`
-- `genesis/v{N}/04_SYSTEM_DESIGN/backend-api-system.md`
+- L0: `genesis/v{N}/04_SYSTEM_DESIGN/core.md`
+- L1: `genesis/v{N}/04_SYSTEM_DESIGN/core.detail.md`
 
 ---
 
@@ -453,6 +499,21 @@ description: 为单个系统设计详细的技术文档，通过调研最佳实
 
 ---
 
+### Agent Context 自更新
+
+**更新 `.agent/rules/agents.md` 的 `AUTO:BEGIN` ~ `AUTO:END` 区块**:
+
+在 `### 系统边界` 下追加或更新当前设计系统的信息：
+
+```markdown
+### 系统边界
+- {system-id}: {一句话职责} — 详细设计见 `genesis/v{N}/04_SYSTEM_DESIGN/{system-id}.md`
+```
+
+> 仅追加，不覆盖已有系统的条目（除非同一 system-id 有更新值）。
+
+---
+
 <completion_criteria>
 - ✅ 系统ID已确认
 - ✅ 上下文已加载（PRD + Architecture Overview + 相关ADR）
@@ -460,6 +521,7 @@ description: 为单个系统设计详细的技术文档，通过调研最佳实
 - ✅ 调研已完成 (/explore)
 - ✅ 设计已完成 (sequentialthinking 5-7步)
 - ✅ 文档已生成 (使用模板)
+- ✅ 更新了 agents.md AUTO:BEGIN 区块 (系统边界)
 - ✅ 用户已确认
 </completion_criteria>
 
@@ -494,4 +556,13 @@ A: 结构保持一致，但可以简化内容。可省略章节: 13 (未来考
 
 ---
 
+## 🔀 Handoffs
+
+完成本工作流后，根据情况选择：
+
+- **生成任务清单** → `/blueprint` — 将架构拆解为可执行任务
+- **质疑设计决策** → `/challenge` — 对当前系统设计进行系统性挑战
+
+---
+
 // turbo-all

package/templates/.agent/workflows/explore.md

@@ -1,5 +1,6 @@
 ---
 description: 深度探索复杂问题，通过"向外搜索 + 向内发散"双向螺旋产出结构化洞察，适用于技术调研、方案选型和头脑风暴。
+
 ---
 
 # /explore
@@ -304,4 +305,12 @@ description: 深度探索复杂问题，通过"向外搜索 + 向内发散"双
 
 ---
 
+## 🔀 Handoffs
+
+完成本工作流后，根据情况选择：
+
+- **将调研结果应用到项目** → `/genesis` — 基于调研结论启动或更新项目架构 *(调研结论需要落地时)*
+
+---
+
 // turbo-all