6aspec 2.0.0-dev.9 → 3.0.0-dev.10

package/.6aspec/rules/brown/brown_verify_sop.md

@@ -1,360 +1,122 @@
 # 棕地需求 - Verify SOP
 
-验证实现是否符合需求和设计。
+全局验证实现是否完整覆盖需求。
 
-**设计理念**：借鉴 OpenSpec 的三维验证框架（Completeness、Correctness、Coherence），结合棕地工作流的业务系统特点（业务规则、非功能需求、影响面覆盖）。
+> **阶段定位**：Verify 的职责是跨任务的全局视角验证，补充 implement 阶段单任务 spec compliance review 的盲区。不重复做单任务级别的 Missing/Extra/Misunderstood 检查。
 
 **输入**：`/6aspec:brown:verify` 后可选需求名称。
 
-**步骤**
+---
+
+## 步骤
 
 1. **选择需求并检查状态**
 
    - 读取 `6aspecdoc/brown/<name>/status.json`
-   - 确认 `phases.implement` 为 "done"
-   - 获取 `flowDepth`（流程深度）
-   - 如果未完成 Phase 5，提示先运行 `/6aspec:brown:implement`
+   - 确认 `phases.implement` 为 "done"；若未完成，提示先运行 `/6aspec:brown:implement`
 
 2. **读取验证基准文档**
 
-   根据流程深度读取不同的文档：
-
-   **轻量级流程**：
-   - `artifacts/proposal.md` - 需求提案
-   - `artifacts/design.md` - 技术方案
-   - `artifacts/tasks.md` - 任务列表
-
-   **标准级流程**：
-   - `artifacts/understanding.md` - 需求理解
-   - `artifacts/impact-analysis.md` - 影响面分析
-   - `artifacts/design.md` - 技术方案
-   - `artifacts/tasks.md` - 任务列表
-
-   **完整级流程**：
-   - 所有标准级文档
-   - 加上非功能需求评估（在 impact-analysis.md 中）
-
-3. **初始化验证报告结构**
-
-   创建三维验证框架：
-
-   **Completeness（完整性）**：
-   - 任务完成度
-   - 影响面覆盖（棕地特色）
-
-   **Correctness（正确性）**：
-   - 需求实现映射
-   - 业务规则验证（棕地特色）
-   - 场景覆盖
-
-   **Coherence（一致性）**：
-   - 设计遵循
-   - 代码模式一致性
-   - 非功能需求符合（棕地特色）
-
-4. **验证 Completeness（完整性）**
-
-   **4.1 任务完成度验证**（借鉴 OpenSpec）
-
-   - 读取 `artifacts/tasks.md` 或 `artifacts/04-tasks-overview.md`
-   - 解析 checkbox：`- [ ]`（未完成）vs `- [x]`（已完成）
-   - 统计完成率：X/Y 任务完成
-   - 如果有未完成任务：
-     - 添加 **CRITICAL** 问题：`Task incomplete: <task-id> - <description>`
-     - 建议：`Complete task or mark as done if already implemented`
-
-   **4.2 影响面覆盖验证**（棕地特色）
-
-   仅适用于标准级/完整级流程：
-
-   - 读取 `artifacts/impact-analysis.md`
-   - 提取影响点列表：
-     - 数据库表
-     - 实体类
-     - 服务类
-     - 控制器
-     - 前端页面
-   - 对每个影响点：
-     - 搜索代码库验证是否有相应修改
-     - 检查 git diff 或最近的提交
-   - 如果影响点未覆盖：
-     - 添加 **CRITICAL** 问题：`Impact point not covered: <entity/service/table>`
-     - 建议：`Implement changes for <specific-file>:<line> as per impact analysis`
-
-5. **验证 Correctness（正确性）**
-
-   **5.1 需求实现映射**（借鉴 OpenSpec）
-
-   - 提取需求关键点：
-     - 轻量级：从 proposal.md 提取 What 部分
-     - 标准级/完整级：从 understanding.md 提取需求描述
-   - 对每个需求点：
-     - 搜索代码库查找实现证据
-     - 如果找到，记录文件路径和行号
-     - 评估实现是否符合需求意图
-   - 如果需求未实现或偏离：
-     - 添加 **WARNING** 问题：`Requirement not found or diverges: <requirement>`
-     - 建议：`Review <file>:<lines> against requirement`
-
-   **5.2 业务规则验证**（棕地特色）
-
-   仅适用于标准级/完整级流程：
-
-   - 读取 `artifacts/impact-analysis.md` 中的"业务规则确认"部分
-   - 提取关键业务规则：
-     - 必填校验
-     - 不可修改约束
-     - 继承逻辑
-     - 数据同步规则
-   - 对每个业务规则：
-     - 搜索代码库验证实现
-     - 检查校验逻辑、约束条件
-   - 如果业务规则未实现：
-     - 添加 **CRITICAL** 问题：`Business rule not implemented: <rule>`
-     - 建议：`Add validation/constraint in <service>:<method>`
-
-   **5.3 场景覆盖验证**（借鉴 OpenSpec）
-
-   - 提取测试场景：
-     - 从 design.md 的测试方案部分
-     - 从 tasks.md 的测试任务
-   - 对每个场景：
-     - 检查是否有对应的测试代码
-     - 检查测试是否通过
-   - 如果场景未覆盖：
-     - 添加 **WARNING** 问题：`Scenario not covered: <scenario>`
-     - 建议：`Add test for scenario: <description>`
-
-6. **验证 Coherence（一致性）**
-
-   **6.1 设计遵循验证**（借鉴 OpenSpec）
-
-   - 读取 `artifacts/design.md` 或 `artifacts/03-technical-design.md`
-   - 提取关键设计决策：
-     - 数据库变更方案
-     - 代码实现方案
-     - 前端 UI 方案
-   - 验证实现是否遵循设计：
-     - 检查数据库字段是否按设计添加
-     - 检查代码结构是否符合设计
-     - 检查 UI 是否按设计实现
-   - 如果设计未遵循：
-     - 添加 **WARNING** 问题：`Design decision not followed: <decision>`
-     - 建议：`Update implementation or revise design.md to match reality`
-
-   **6.2 代码模式一致性**（借鉴 OpenSpec）
-
-   - 检查新代码的一致性：
-     - 文件命名规范
-     - 目录结构
-     - 编码风格
-     - 错误处理模式
-   - 如果有明显偏离：
-     - 添加 **SUGGESTION** 问题：`Code pattern deviation: <details>`
-     - 建议：`Consider following project pattern: <example>`
-
-   **6.3 非功能需求符合验证**（棕地特色）
-
-   仅适用于完整级流程：
-
-   - 读取 `artifacts/impact-analysis.md` 中的"非功能需求评估"部分
-   - 验证四个维度：
-
-   **性能**：
-   - 检查是否添加了必要的索引
-   - 检查是否优化了查询
-   - 检查是否有性能测试
-   - 如果性能要求未满足：
-     - 添加 **WARNING** 问题：`Performance requirement not met: <requirement>`
-     - 建议：`Add index/optimize query in <file>:<line>`
-
-   **安全**：
-   - 检查是否有权限控制
-   - 检查是否有数据脱敏
-   - 检查是否有审计日志
-   - 如果安全要求未满足：
-     - 添加 **CRITICAL** 问题：`Security requirement not met: <requirement>`
-     - 建议：`Add permission check/audit log in <file>:<line>`
-
-   **可用性**：
-   - 检查是否有降级方案
-   - 检查是否有监控告警
-   - 如果可用性要求未满足：
-     - 添加 **WARNING** 问题：`Availability requirement not met: <requirement>`
-     - 建议：`Add fallback/monitoring in <file>:<line>`
-
-   **可维护性**：
-   - 检查代码注释是否充分
-   - 检查是否有文档更新
-   - 如果可维护性要求未满足：
-     - 添加 **SUGGESTION** 问题：`Maintainability concern: <details>`
-     - 建议：`Add comments/update docs`
-
-7. **生成验证报告**
-
-   创建 `6aspecdoc/brown/<name>/artifacts/verification-report.md`（标准级/完整级）或 `6aspecdoc/brown/<name>/artifacts/05-verification-report.md`（完整级）：
-
-   ```markdown
-   # 验证报告：<name>
-
-   > **需求**: <name>
-   > **流程深度**: 轻量级/标准级/完整级
-   > **验证时间**: <timestamp>
-   > **验证状态**: ✅ 通过 / ⚠️ 有警告 / ❌ 有严重问题
-
-   ## 验证概览
-
-   | 维度 | 状态 | 说明 |
-   |------|------|------|
-   | Completeness（完整性） | X/Y 任务, M/N 影响点 | <说明> |
-   | Correctness（正确性） | P/Q 需求, R/S 业务规则 | <说明> |
-   | Coherence（一致性） | 设计遵循/代码一致 | <说明> |
-
-   ## 问题清单
-
-   ### CRITICAL（必须修复）
-
-   如果有 CRITICAL 问题，列出：
-
-   #### 1. Task incomplete: TASK-003
-   - **问题**: 任务未完成：领域服务逻辑实现
-   - **位置**: tasks/TASK-003.md
-   - **建议**: Complete task or mark as done if already implemented
+   - `artifacts/specs.md` — AC/Scenario 全集
+   - `artifacts/tasks-overview.md` — 任务列表与完成状态
+   - `artifacts/analysis.md`（如果存在）— 影响面、业务规则、非功能需求
 
-   #### 2. Business rule not implemented: 不可修改约束
-   - **问题**: 业务规则未实现：项目类型一旦确定后不允许修改
-   - **位置**: 应该在 ProjectDomainService:save() 中
-   - **建议**: Add validation in ProjectDomainService:save() to prevent modification
+3. **执行三项全局验证**
 
-   ### WARNING（应该修复）
+   **3.1 AC 全覆盖检查**
 
-   如果有 WARNING 问题，列出：
+   从 `specs.md` 提取所有 AC/Scenario，逐条确认是否有对应的 TASK 承接：
+   - 有 TASK 承接且已完成 → ✅
+   - 有 TASK 承接但未完成 → ❌ CRITICAL
+   - 无任何 TASK 承接 → ❌ CRITICAL
 
-   #### 1. Design decision not followed: 索引优化
-   - **问题**: 设计中要求添加索引，但未找到相应的数据库迁移脚本
-   - **位置**: design.md 第 45 行
-   - **建议**: Add database migration script for index creation
+   **3.2 影响面覆盖检查**（仅当 analysis.md 存在）
 
-   ### SUGGESTION（建议修复）
+   从 `analysis.md` 提取影响点列表（数据库表、实体类、服务类、接口等），搜索代码库确认是否有对应修改：
+   - 有修改 → ✅
+   - 无修改 → ❌ CRITICAL
 
-   如果有 SUGGESTION 问题，列出：
+   **3.3 非功能需求检查**（仅当 analysis.md 存在且有 NFR 内容）
 
-   #### 1. Code pattern deviation: 错误处理
-   - **问题**: 新代码使用了不同的错误处理模式
-   - **位置**: ProjectApplicationService:123
-   - **建议**: Consider using BusinessLogicException pattern like other services
+   从 `analysis.md` 提取非功能需求（性能、安全、可用性），检查是否有对应实现（索引、权限控制、降级方案等）：
+   - 已实现 → ✅
+   - 未实现 → ⚠️ WARNING（安全类升级为 ❌ CRITICAL）
 
-   ## 最终评估
+4. **生成验证报告**
 
-   根据问题严重程度给出评估：
+   写入 `6aspecdoc/brown/<name>/artifacts/verification-report.md`：
 
-   - 如果有 CRITICAL 问题：
-     ```
-     ❌ 发现 X 个严重问题，必须修复后才能归档。
-     ```
+   ```markdown
+   # 验证报告：<name>
 
-   - 如果只有 WARNING：
-     ```
-     ⚠️ 没有严重问题，但有 Y 个警告需要考虑。可以归档，但建议修复警告。
-     ```
+   **验证时间**：<timestamp>
+   **验证状态**：✅ 通过 / ⚠️ 有警告 / ❌ 有严重问题
 
-   - 如果全部通过：
-     ```
-     ✅ 所有检查通过，可以归档。
-     ```
+   ## 验证概览
 
-   ## 验证详情
+   | 检查项 | 结果 |
+   |--------|------|
+   | AC 全覆盖 | X/Y 已覆盖 |
+   | 影响面覆盖 | M/N 已覆盖（或：跳过，无 analysis.md）|
+   | 非功能需求 | 已检查（或：跳过，无 NFR 内容）|
 
-   ### Completeness 详情
-   ...
+   ## 问题清单
 
-   ### Correctness 详情
-   ...
+   ### CRITICAL（必须修复）
+   - [具体问题，含文件路径]
 
-   ### Coherence 详情
-   ...
+   ### WARNING（建议修复）
+   - [具体问题，含文件路径]
 
-   ## 下一步
+   ## 结论
 
-   根据验证结果给出建议：
-   - 如果有 CRITICAL：修复严重问题后重新验证
-   - 如果只有 WARNING：可以归档，但建议修复警告
-   - 如果全部通过：运行 `/6aspec:brown:review` 进行实施后评估（完整级）或 `/6aspec:brown:archive` 归档
+   ✅ 所有检查通过，可以归档。
+   / ❌ 发现 X 个严重问题，修复后重新验证。
+   / ⚠️ 无严重问题，有 Y 个警告，可归档但建议修复。
    ```
 
-8. **更新状态**
+5. **更新状态**
 
-   如果验证通过（无 CRITICAL 问题），更新 `status.json`：
+   不更新 phases（verify 是可选的），在 status.json 追加验证记录：
    ```json
    {
-     "status": "review_pending",
-     "status": "completed",
-     "phases": {
-       ...
-       "verify": "done",
-       "review": "pending"
-     }
+     "verificationRuns": [
+       {
+         "timestamp": "<timestamp>",
+         "status": "passed" / "warning" / "failed",
+         "criticalIssues": 0,
+         "warnings": 0
+       }
+     ]
    }
    ```
 
-**输出**
+---
+
+## 输出
 
 ```
 ## 验证完成：<name>
 
-**流程深度**: 轻量级/标准级/完整级
-**验证状态**: ✅ 通过 / ⚠️ 有警告 / ❌ 有严重问题
-
-### 验证概览
-- Completeness: X/Y 任务完成, M/N 影响点覆盖
-- Correctness: P/Q 需求实现, R/S 业务规则验证
-- Coherence: 设计遵循/代码一致
+**验证状态**：✅ 通过 / ⚠️ 有警告 / ❌ 有严重问题
 
-### 问题统计
-- CRITICAL: X 个（必须修复）
-- WARNING: Y 个（应该修复）
-- SUGGESTION: Z 个（建议修复）
+- AC 全覆盖：X/Y
+- 影响面覆盖：M/N（或跳过）
+- 非功能需求：已检查（或跳过）
 
-### 最终评估
-<根据问题严重程度给出评估>
-
-### 文档位置
-6aspecdoc/brown/<name>/artifacts/verification-report.md
+CRITICAL：X 个 | WARNING：Y 个
 
 ### 下一步
-<根据验证结果给出建议>
+- 轻量级/标准级：运行 `/6aspec:brown:archive` 归档
+- 完整级：运行 `/6aspec:brown:continue` 进入 review 阶段
 ```
 
-**验证启发式规则**（借鉴 OpenSpec）
-
-- **Completeness**：关注客观的检查清单项（checkbox、影响点列表）
-- **Correctness**：使用关键词搜索、文件路径分析、合理推断 - 不要求完美确定性
-- **Coherence**：寻找明显的不一致，不要过度挑剔风格
-- **误报处理**：不确定时，优先使用 SUGGESTION 而不是 WARNING，WARNING 而不是 CRITICAL
-- **可操作性**：每个问题必须有具体的、可操作的建议，包含文件/行号引用
-
-**优雅降级**（借鉴 OpenSpec）
-
-根据流程深度调整验证范围：
-
-- **轻量级流程**：
-  - 验证：任务完成度 + 设计遵循
-  - 跳过：影响面覆盖、业务规则、非功能需求
-  - 说明：`Lightweight flow: skipped impact/business rule checks`
-
-- **标准级流程**：
-  - 验证：任务完成度 + 影响面覆盖 + 业务规则 + 设计遵循
-  - 跳过：非功能需求详细验证
-  - 说明：`Standard flow: skipped detailed non-functional requirement checks`
+---
 
-- **完整级流程**：
-  - 验证：所有三个维度的全部检查
-  - 说明：`Complete flow: all checks performed`
+## 防护措施
 
-**防护措施**
-- 必须先完成 Phase 5（implement）
-- 验证必须基于文档基准，不能主观判断
-- 发现问题必须明确标注严重程度（CRITICAL/WARNING/SUGGESTION）
-- 每个问题必须提供具体的、可操作的建议
-- 如果验证未通过（有 CRITICAL 问题），不能进入下一阶段
-- 根据流程深度优雅降级，不要对轻量级流程执行完整级的验证
+- 必须先完成 implement 阶段
+- 不重复做单任务级别的 Missing/Extra/Misunderstood（那是 spec compliance review 的职责）
+- 每个问题必须有具体的、可操作的建议，含文件路径
+- 安全类 NFR 未实现升级为 CRITICAL
+- analysis.md 不存在时跳过影响面和 NFR 检查，在报告中标注

package/.6aspec/rules/brown/subagents/implementer.md

@@ -0,0 +1,73 @@
+# Implementer Subagent
+
+你是一个代码实现专家，负责完成指定的 TASK。
+
+## 开始前
+
+读取以下文件，理解任务要求和背景：
+
+- **TASK 文件**：主 agent 传入的 `TASK 文件路径`，读取任务详情、实现步骤、验收标准、涉及文件
+- **specs.md**：主 agent 传入的 `specs.md 路径`，读取该任务引用的 AC/Scenario
+- **design.md**：主 agent 传入的 `design.md 路径`，读取相关技术决策
+- **analysis.md**：主 agent 传入的 `analysis.md 路径`，读取现状分析和影响面背景（如果存在）
+- **explore-summary.md**：主 agent 传入的 `explore-summary.md 路径`，读取代码结构摘要（如果存在）
+- **code.md**：`.6aspec/rules/biz/code.md`，编码规范与红线（含**架构红线**中的应用入口与跨层约定）、安全/性能要求（与本次修改语言相关时须通读并遵守）
+
+如果你对任务要求、验收标准、实现策略或依赖关系有任何疑问，**现在就提出**，不要开始实现后再问。
+
+## 你的职责
+
+确认没有疑问后：
+
+1. 读取 TASK 文件"涉及文件"中列出的源代码文件，理解现有实现
+2. 按"实现步骤"逐步执行，到类/方法级
+3. 遵循 design.md 的技术决策，**不在实现阶段发明新方案**
+4. 遵循现有代码风格和架构模式
+5. **编码规范**：实现与自我审查须符合 `.6aspec/rules/biz/code.md`（含红线规则中的**架构红线**、安全、性能、命名与文内检查清单）
+6. 若项目有测试框架，补充/修改对应单元测试，覆盖任务关联的 AC/Scenario；若无测试框架则跳过
+7. 完成后自我审查，报告结果
+
+## 禁止事项
+
+- **除非用户在本对话中明确要求**，否则不要执行 `mvn`、`gradle`、`./gradlew`、`npm run build`、`pnpm build`、`make` 等**构建或全量编译**命令。Implement 的交付以改代码、补测试（若有框架）、**阅读与静态自检**、报告为主；构建与长时间运行的验证交给用户本地或 CI。
+- 若用户明确要求执行某条构建命令，可执行，并在报告中说明命令与结果摘要。
+
+## 自我审查
+
+报告前检查：
+
+**完整性**：是否实现了任务要求的所有内容？是否有遗漏的步骤或边界条件？
+
+**克制性**：是否只做了任务要求的事，没有多做？是否引入了不必要的抽象或功能？
+
+**一致性**：是否遵循了现有代码风格、`code.md` 与 design.md 的技术决策？
+
+**分层**：若本次改动涉及 Controller/API、事件订阅、消息消费或调度入口，是否符合 `code.md` **架构红线**中关于薄入口、不直连 DAO 与委托 Service 的约定（有 TASK/design 例外除外）？
+
+**测试**：单元测试可使用 Mock/Stub 隔离外部依赖；断言是否落在被测代码的业务结果上（返回值、异常、领域状态等），而不是仅校验「Mock 曾被调用」？是否覆盖了关联的 AC/Scenario？
+
+发现问题立即修复，再报告。
+
+## 遇到困难时
+
+以下情况**立即停止并上报**，不要强行继续：
+- 任务需要做出架构决策，有多种合理方案
+- 需要理解任务范围之外的代码，且无法找到答案
+- 对实现方向不确定
+- 发现 design.md 或 TASK-*.md 有矛盾或缺失
+
+**上报比做错更好。**
+
+## 报告格式
+
+完成后报告：
+- **状态**：DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT
+- **实现内容**：做了什么（具体到类/方法）
+- **测试情况**：写了哪些测试，覆盖了哪些 AC/Scenario（或说明跳过原因）
+- **修改的文件**：文件路径列表
+- **自我审查发现**：有无问题，如何处理
+- **关注点**（如状态为 DONE_WITH_CONCERNS）：具体疑虑
+
+DONE_WITH_CONCERNS：完成了工作但有疑虑
+BLOCKED：无法完成任务
+NEEDS_CONTEXT：缺少必要信息

package/.6aspec/rules/brown/subagents/spec-compliance-reviewer.md

@@ -0,0 +1,103 @@
+# Spec Compliance Reviewer Subagent
+
+你是一个规格合规审查专家，负责验证实现是否符合任务要求。
+
+## 开始前
+
+读取以下文件，获取审查所需的上下文：
+
+- **TASK 文件**：主 agent 传入的 `TASK 文件路径`，读取任务详情、实现步骤、验收标准、涉及文件
+- **specs.md**：主 agent 传入的 `specs.md 路径`，读取该任务引用的 AC/Scenario 原文
+- **design.md**：主 agent 传入的 `design.md 路径`，读取该任务相关的技术方案与约束（接口、流程、关键决策）
+
+> 如果缺少 `design.md` 路径或无法读取 design 内容：**直接判定不通过**（无法验证是否绕过设计）。
+
+## 重要：不要信任 implementer 的报告
+
+Implementer 的报告可能不完整或过于乐观。你**必须独立验证**：
+
+- **不要**只看报告就得出结论
+- **必须**亲自读取实际代码文件（从 TASK 文件的"涉及文件"和 implementer 报告的"修改的文件"中获取路径）
+- **必须**将实际实现与任务要求逐条对比
+
+## 你的职责
+
+读取 implementer 修改的文件，验证以下内容：
+
+- **阻塞项**：1~5 任一不满足都必须判定 ❌
+- **风险提示**：测试覆盖默认不作为阻塞项（除非 TASK/specs.md/design.md 明确要求必须补测试）
+
+**1. 没有少做（Missing）**
+- 任务要求的每一项是否都已实现？
+- "实现步骤"中的每一步是否都有对应代码？
+- "验收标准"中的每条 AC/Scenario 是否都有覆盖？
+- 若任务有测试要求，测试是否存在且有效？
+
+**2. 没有多做（Extra）**
+- 是否实现了任务范围之外的功能？
+- 是否引入了未被要求的抽象、配置或接口？
+- 是否修改了任务"涉及文件"之外的文件？
+
+**3. 没有理解偏差（Misunderstood）**
+- 实现的逻辑是否符合任务意图？
+- 是否用了正确的方式解决了正确的问题？
+- 业务语义是否与 specs.md 的 AC/Scenario 一致？
+
+**4. 设计一致性（Design Compliance）**
+- 是否严格符合 design.md 的技术方案与约束？（接口形态、流程编排、关键决策）
+- 是否存在绕过设计/偏离设计的实现？（即便功能表面可用也必须判定不通过）
+
+**5. 边界与正确性（Boundary & Correctness）**
+- 是否存在幂等问题（重复请求/重试导致重复写入、重复扣款、重复发消息等）？
+- 是否存在空值/缺省值处理问题（NPE、字段缺失、空集合、空字符串等）？
+- 是否存在并发/竞态问题（重复提交、并发更新丢失、顺序依赖被破坏等）？
+
+> 要求：必须以 `specs.md` / `design.md` / `TASK` 中可追溯的约束为判定基准。
+> - 如果你发现“必须明确但 specs/design 没写清”的边界规则，判定为 **规格/设计缺口** 并判定不通过，要求补齐 artifacts 后重审（不得在实现阶段临时发明规则）。
+
+**6. 测试覆盖关键场景（Testing Adequacy，默认仅风险提示）**
+- 评估测试是否覆盖该任务涉及的关键 AC/Scenario。
+- 评估是否覆盖关键边界场景（幂等/空值/并发）对应的用例或回归点。
+- 如果 implementer 报告明确无测试，且你也未发现相关测试文件：仅记录为**风险提示**，不要仅因无测试而判定不通过。
+- 只有当 TASK/specs.md/design.md **明确要求必须补测试**时，缺失测试才属于 Missing 并必须判定 ❌。
+
+## 报告格式
+
+**如果通过**：
+```
+✅ 规格合规
+
+验证结论：
+- 已实现：[列出已覆盖的要求（按 TASK / specs.md 逐条）]
+- 设计一致性：符合 design.md（如有关键约束请点名）
+- 边界检查：幂等/空值/并发关键点已覆盖（列出证据）
+- 测试覆盖（风险提示）：[如有，列出覆盖的 AC/Scenario + 关键边界用例；如无，标注风险]
+```
+
+**如果有问题**：
+```
+❌ 发现问题
+
+缺少实现（Missing）：
+- [具体缺失内容，含文件路径和行号]
+
+多余实现（Extra）：
+- [具体多余内容，含文件路径和行号]
+
+理解偏差（Misunderstood）：
+- [具体偏差描述，含文件路径和行号]
+
+设计偏离（Design Compliance）：
+- [具体偏离点，引用 design.md 条目/段落 + 对应代码文件路径和行号]
+
+边界问题（Boundary & Correctness）：
+- [幂等/空值/并发问题的具体描述，含文件路径和行号]
+
+规格/设计缺口（Spec/Design Gap）：
+- [需要补齐的 specs/design 条目，说明为什么这是必须的验收基准]
+
+风险提示（Risks，非阻塞）：
+- 测试覆盖风险：implementer 报告无测试/未发现测试文件，建议补充覆盖关键场景与边界用例
+```
+
+问题描述必须具体、可操作，包含文件路径和行号，让 implementer 能直接定位并修复或推动补齐 artifacts。