@haaaiawd/anws 1.1.0 → 1.2.1

package/templates/.agent/skills/system-designer/references/system-design-template.md

@@ -1,4 +1,4 @@
-# {System Name} 系统设计文档
+# {System Name} 系统设计文档 (L0 — 导航层)
 
 **System ID**: {system-id} (如: frontend-system, backend-api-system)
 **Project**: [Project Name]
@@ -7,6 +7,11 @@
 **Author**: [Author Name or Agent]
 **Date**: [YYYY-MM-DD]
 
+> **📖 文档层级说明**
+> - **本文件 (L0)**: 导航层。包含架构图、操作契约表、设计决策。面向快速理解与任务规划。
+> - **[{system}-detail.md](./{system-id}.detail.md) (L1)**: 实现层。包含完整伪代码、配置常量、边缘情况。仅在 `/forge` 任务明确引用时加载。
+> - **L1 文件按需创建**：触发拆分规则 R1-R5 任意一条时，才需要创建对应的 `.detail.md`。
+
 ---
 
 ## 1. 概览 (Overview)
@@ -88,10 +93,10 @@ graph TD
 ### 4.2 Core Components (核心组件)
 <!-- 每个组件的职责和技术栈 -->
 
-| Component Name | Responsibility | Tech Stack | Notes |
-|---------------|----------------|------------|-------|
-| [Component 1] | [职责描述] | [技术] | [备注] |
-| [Component 2] | [职责描述] | [技术] | [备注] |
+| Component Name | Responsibility | Tech Stack | Notes  |
+| -------------- | -------------- | ---------- | ------ |
+| [Component 1]  | [职责描述]     | [技术]     | [备注] |
+| [Component 2]  | [职责描述]     | [技术]     | [备注] |
 
 ### 4.3 Data Flow (数据流)
 <!-- 描述数据如何在组件间流动 -->
@@ -119,135 +124,95 @@ sequenceDiagram
 
 ## 5. 接口设计 (Interface Design)
 
-<!-- ⚠️ CRITICAL: 根据系统类型选择合适的小节 -->
+<!-- ⚠️ L0 写法原则:
+  - 后端 API: 只放 endpoint 路径 + 请求/响应结构摘要（无需完整 JSON 示例）
+  - Agent/游戏系统: 使用「操作契约表格」代替函数伪代码
+  - 完整参数细节、错误码列表 → {system}.detail.md §3
+-->
 
-### 5.1 API Design (如果是后端系统)
+### 5.1 操作契约表 (Operation Contracts)
 
-#### 5.1.1 POST /auth/login [REQ-001]
-**Purpose**: 用户登录认证
+<!-- ⭐ 核心格式：用表格代替函数伪代码。每行覆盖一个原子操作。 -->
+<!-- 「detail 链接」填写 {system}.detail.md 的对应 §章节号 -->
 
-**Request**:
-```json
-{
-  "email": "user@example.com",
-  "password": "password123"
-}
-```
+| 操作                 | [REQ-XXX] | 前置条件     | 消耗/输入 | 产出/副作用  |      实现细节       |
+| -------------------- | :-------: | ------------ | --------- | ------------ | :-----------------: |
+| `operation_a(param)` | [REQ-001] | 条件1; 条件2 | cost★     | 状态变化描述 | [§3.1](./detail.md) |
+| `operation_b(param)` | [REQ-002] | 条件1        | cost★     | 状态变化描述 | [§3.2](./detail.md) |
 
-**Response (Success - 200)**:
-```json
-{
-  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
-  "user": {
-    "id": "550e8400-e29b-41d4-a716-446655440000",
-    "email": "user@example.com",
-    "name": "John Doe"
-  }
-}
-```
+> **填写说明**:
+> - **操作**: 使用函数签名风格 `func_name(key_params)`，参数只写关键入参类型，不写类型注解
+> - **前置条件**: 简洁列举，以「;」分隔，不超过 3 个
+> - **产出/副作用**: 描述状态变化，如「生成 Boat，承载 unit；原 unit 消失」
+> - **实现细节**: 链接到 `.detail.md` 对应章节（如尚未创建，填「待补充」）
 
-**Response (Error - 401)**:
-```json
-{
-  "error": {
-    "code": "INVALID_CREDENTIALS",
-    "message": "Invalid email or password"
-  }
-}
-```
+### 5.2 跨系统接口协议 (Cross-System Interface)
 
-**Rate Limit**: 5 requests/minute/IP
-**Authentication**: None (public endpoint)
+<!-- 与其他系统的边界协议：Protocol / ABC 接口签名，不含方法体 -->
 
----
-
-### 5.2 Component Interface (如果是前端系统)
-
-#### 5.2.1 LoginForm Component [REQ-001]
-
-**Props**:
-```typescript
-interface LoginFormProps {
-  onSuccess: (token: string) => void;
-  onError: (error: Error) => void;
-  isLoading?: boolean;
-}
+```python
+# 示例：本系统暴露给其他系统调用的接口协议（Protocol/ABC）
+class ISystemName(Protocol):
+    def method_a(self, param: Type) -> ReturnType: ...
+    def method_b(self, param: Type) -> ReturnType: ...
 ```
 
-**Events**:
-- `onSuccess(token: string)`: 登录成功时触发
-- `onError(error: Error)`: 登录失败时触发
+### 5.3 HTTP API 端点摘要 (如适用)
 
-**Usage**:
-```jsx
-<LoginForm
-  onSuccess={(token) => saveToken(token)}
-  onError={(error) => showError(error.message)}
-/>
-```
+<!-- 仅后端服务系统才需要此节，Agent/游戏核心系统跳过 -->
+<!-- 只列 endpoint 清单，不写完整 JSON 示例（JSON 示例 → detail.md） -->
 
----
-
-### 5.3 Message Format (如果是Agent/消息系统)
-
-#### 5.3.1 Tool Call Message [REQ-XXX]
-
-**Format**:
-```json
-{
-  "tool": "search_code",
-  "parameters": {
-    "query": "function authenticate",
-    "scope": "src/"
-  }
-}
-```
-
-**Response**:
-```json
-{
-  "status": "success",
-  "results": [...]
-}
-```
+| Method | Path          | Auth  | 用途               | [REQ-XXX] |
+| ------ | ------------- | :---: | ------------------ | :-------: |
+| POST   | `/auth/login` |  否   | 用户登录，返回 JWT | [REQ-001] |
+| GET    | `/users/me`   |  JWT  | 获取当前用户信息   | [REQ-002] |
 
 ---
 
 ## 6. 数据模型 (Data Model)
 
-### 6.1 Data Structures (数据结构)
-
-#### User Entity
-```typescript
-interface User {
-  id: string;           // UUID v4
-  email: string;        // Unique, RFC 5322 compliant
-  passwordHash: string; // bcrypt hash (rounds=10)
-  name: string;
-  createdAt: Date;
-  updatedAt: Date;
-}
+<!-- ⚠️ L0 写法原则 — 请严格遵守:
+  ✅ 允许: @dataclass 属性字段声明
+  ✅ 允许: Protocol 风格的方法签名 (def foo(self, x: T) -> R: ...)
+  ❌ 禁止: 任何方法体 (哪怕只有 2 行)
+  ❌ 禁止: 注释风格的方法列表 (# def foo... 这种)
+  ❌ 禁止: 配置常量字典 (UNIT_CONFIG = {...})
+  → 以上内容全部放入 {system}.detail.md §1 和 §2
+-->
+
+### 6.1 核心实体 (Core Entities)
+
+```python
+# ── 示例: 只放属性字段 + 签名 ──
+@dataclass
+class EntityName:
+    # 属性字段
+    id: str
+    field_a: TypeA
+    field_b: TypeB = default_value
+
+    # 方法签名 (不写方法体, 只写到 ...)
+    def some_method(self, param: Type) -> ReturnType: ...
+    def another_method(self) -> bool: ...
+    # 完整方法实现见 {system}.detail.md §2.1
 ```
 
-### 6.2 Database Schema (如适用)
-
-#### Users Table
-```sql
-CREATE TABLE users (
-  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-  email VARCHAR(255) UNIQUE NOT NULL,
-  password_hash VARCHAR(255) NOT NULL,
-  name VARCHAR(255),
-  created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
-  updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
-);
-
--- Indexes
-CREATE INDEX idx_users_email ON users(email);
-CREATE INDEX idx_users_created_at ON users(created_at DESC);
+### 6.2 实体关系图 (Entity Relationship)
+
+```mermaid
+classDiagram
+    class EntityA {
+        +id: str
+        +field_a: TypeA
+    }
+    class EntityB {
+        +id: str
+        +entity_a_id: str
+    }
+    EntityA "1" --> "0..*" EntityB : has
 ```
 
-### 6.3 Data Flow Direction (数据流向)
+### 6.3 数据流向 (Data Flow Direction)
 [数据如何在系统间流动？存储在哪里？]
 
 ---
@@ -257,12 +222,12 @@ CREATE INDEX idx_users_created_at ON users(created_at DESC);
 ### 7.1 Core Technologies (核心技术)
 <!-- 从ADR继承，或新增系统级技术决策 -->
 
-| Domain | Choice | Rationale |
-|--------|--------|-----------|
-| Framework | FastAPI | 高性能、异步、类型安全、OpenAPI自动生成 |
-| Database | PostgreSQL | ACID、JSON支持、成熟生态、团队熟悉 |
-| Cache | Redis | 高性能、丰富数据结构、持久化选项 |
-| ORM | SQLAlchemy | 类型安全、灵活、异步支持 |
+| Domain    | Choice     | Rationale                               |
+| --------- | ---------- | --------------------------------------- |
+| Framework | FastAPI    | 高性能、异步、类型安全、OpenAPI自动生成 |
+| Database  | PostgreSQL | ACID、JSON支持、成熟生态、团队熟悉      |
+| Cache     | Redis      | 高性能、丰富数据结构、持久化选项        |
+| ORM       | SQLAlchemy | 类型安全、灵活、异步支持                |
 
 ### 7.2 Key Libraries/Dependencies (关键依赖)
 - `pydantic ^2.0`: 数据验证、序列化
@@ -327,13 +292,13 @@ CREATE INDEX idx_users_created_at ON users(created_at DESC);
 
 ### 9.3 Security Risks & Mitigations (安全风险与缓解)
 
-| Risk | Severity | Mitigation |
-|------|:--------:|-----------|
-| SQL注入 | 高 | 使用ORM参数化查询，禁止拼接SQL |
-| XSS | 中 | 输入验证、输出转义、CSP头 |
-| CSRF | 中 | CSRF Token（如适用） |
-| 密码暴力破解 | 高 | Rate limiting (5次/分钟/IP) |
-| JWT伪造 | 高 | 使用强密钥（HS256, 256-bit），定期轮换 |
+| Risk         | Severity | Mitigation                             |
+| ------------ | :------: | -------------------------------------- |
+| SQL注入      |    高    | 使用ORM参数化查询，禁止拼接SQL         |
+| XSS          |    中    | 输入验证、输出转义、CSP头              |
+| CSRF         |    中    | CSRF Token（如适用）                   |
+| 密码暴力破解 |    高    | Rate limiting (5次/分钟/IP)            |
+| JWT伪造      |    高    | 使用强密钥（HS256, 256-bit），定期轮换 |
 
 ---
 
@@ -503,31 +468,39 @@ CREATE INDEX idx_users_created_at ON users(created_at DESC);
 
 ### 14.3 Change Log (变更日志)
 
-| Version | Date | Changes | Author |
-|---------|------|---------|--------|
-| 1.0 | 2026-01-08 | 初始版本 | XXX |
+| Version | Date       | Changes  | Author |
+| ------- | ---------- | -------- | ------ |
+| 1.0     | 2026-01-08 | 初始版本 | XXX    |
 
 ---
 
 <!-- ⚠️ CRITICAL 使用指南 -->
 <!--
-**系统设计文档撰写原则**:
-1. **自包含**: 文档应自包含，减少对外部上下文的依赖
-2. **追溯链**: 通过[REQ-XXX]引用PRD需求，而不是复制内容
-3. **约束继承**: 从PRD和ADR继承约束和决策
-4. **Trade-offs说明**: 每个重要技术选型都要说明"为什么选A不选B"
-5. **可视化**: 使用Mermaid图表，一图胜千言
+**L0 文档撰写原则 (本文件)**:
+1. **导航层定位**: 面向快速理解和任务规划，不展示实现细节
+2. **操作契约表格**: §5.1 用表格代替函数伪代码，每行对应一个原子操作
+3. **属性声明优先**: §6 只放字段声明，不放方法体
+4. **追溯链**: 通过 [REQ-XXX] 引用PRD需求，不复制内容
+5. **约束继承**: 从PRD和ADR继承约束和决策，不能放松
+6. **Trade-offs说明**: 每个重要技术选型都说明「为什么选A不选B」
+7. **Mermaid优先**: 架构图、数据流、决策树 → 用图
+
+**L1 文件拆分规则 (触发任意一条即创建 .detail.md)**:
+- R1: 单个代码块 > 30 行
+- R2: 文档代码块总行数 > 200 行
+- R3: 配置常量字典条目 > 5 个
+- R4: 版本内联注释 (# vX.X 变更) 出现 > 5 处
+- R5: 文档总行数 > 500 行
 
 **章节使用指南**:
 - **必需章节**: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
 - **可选章节**: 12 (部署，小项目可简化), 13 (未来，可简化), 14 (附录)
-- **根据系统类型选择Interface Design小节**:
-  - 后端系统 → 5.1 API Design
-  - 前端系统 → 5.2 Component Interface
-  - Agent系统 → 5.3 Message Format
-
-**小项目简化策略**:
-- 可省略: 13 (未来考虑), 14 (附录)
-- 可简化: 8 (Trade-offs, 只保留关键决策), 12 (部署, 简化为部署命令)
-- 但必须保留: 4 (架构), 5 (接口), 6 (数据模型), 11 (测试)
+
+**L1 文件 ({system}.detail.md) 内容**:
+- §1 配置常量 (UNIT_CONFIG 等)
+- §2 完整类定义 (含方法体)
+- §3 算法伪代码 (完整函数体)
+- §4 决策树展开
+- §5 边缘情况
+- §6 测试辅助
 -->

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

@@ -481,6 +481,11 @@ Phase 3: 回归测试 (Regression)
 - [ ] 所有Task关联PRD需求或标注为[基础]
 - [ ] 跨系统集成任务已识别
 
+### User Story 覆盖
+- [ ] 每个 US-XXX 有足够的 tasks 覆盖其所有涉及系统
+- [ ] 每个 US 的 task 链能形成可独立验证的闭环
+- [ ] 高优先级 US (P0) 的 task 分布在靠前的 Sprint
+
 ---
 
 ## 🚀 快速上手示例

package/templates/.agent/skills/task-reviewer/SKILL.md

@@ -0,0 +1,287 @@
+---
+name: task-reviewer
+description: 系统性审查 05_TASKS.md 的质量与完备性。通过 6 大检测 Pass 在语义模型上运行，检测重复、歧义、欠详述、不一致、覆盖缺口和质量问题。
+---
+
+# 任务审查大师手册
+
+> "计划的质量取决于最薄弱的那个任务。  
+> 在代码暴露问题之前，找到裂缝。"
+
+你是**任务审查大师**，负责对 `05_TASKS.md` 进行系统性审计——以 PRD、Architecture 和 ADR 文档为基准，运行 **6 大检测 Pass**。你的武器是**语义模型**，而非朴素的字符串匹配。
+
+---
+
+## ⚡ 任务目标
+
+1. **加载文档 (必须)**: 读取 `genesis/v{N}/05_TASKS.md`、`01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md` 以及所有 `03_ADR/*.md`。
+2. **构建语义模型**: 构建 3 个清单模型（见 §语义模型构建）。
+3. **执行 6 大 Pass (A→F)**: 顺序执行每个检测 Pass——每个 Pass 在语义模型上操作。
+4. **严重度分级**: 为每条发现分配严重度（CRITICAL / HIGH / MEDIUM / LOW）。
+5. **生成报告**: 输出任务审查报告（见 §输出格式）。
+6. **展示摘要**: 向用户展示检测汇总表 + 前 10 条发现。
+
+## 🛑 硬约束
+
+- **发现上限**: 最多 50 条。超出时按严重度排序 → 截断 → 追加溢出摘要。
+- **只报告不修复**: 本技能**仅输出报告**。修复由用户或其他工作流完成。
+- **跨文档依赖**: Pass D 和 E **依赖** PRD + Architecture。若缺失，跳过相应 Pass 并注明。
+- **客观性**: 仅标记客观可检测的问题。不要为了填满报告而捏造问题。
+
+---
+
+## 🧠 语义模型构建
+
+> 在执行任何 Pass 之前，先构建以下 3 个模型。所有 Pass 在模型上操作，而非原始文本。
+
+### 模型 1: 需求清单 (Requirements Inventory)
+
+从 `01_PRD.md` 提取**每一条**需求：
+
+```
+REQ-001: slug-key-from-title
+  ├── 来源章节: §4 User Stories / §3 功能需求
+  ├── 优先级: P0 | P1 | P2
+  ├── 验收标准: [列表]
+  └── 关键词: [提取的名词短语，用于模糊匹配]
+```
+
+### 模型 2: 用户故事清单 (User Story Inventory)
+
+从 `01_PRD.md` 提取**每一个** User Story：
+
+```
+US-001: 标题 (Priority)
+  ├── 用户价值: [一句话]
+  ├── 涉及系统: [系统 ID 列表]
+  ├── 独立可测: [如何独立验证]
+  ├── 验收场景: [Given-When-Then 列表]
+  └── 边界情况: [边界条件]
+```
+
+### 模型 3: 任务覆盖映射 (Task Coverage Mapping)
+
+为 `05_TASKS.md` 中的每个任务提取：
+
+```
+T{X.Y.Z}: 标题
+  ├── 显式 REQ: 任务头部标注的 [REQ-XXX]
+  ├── 推断 REQ: 通过关键词与 REQ 清单匹配
+  ├── 关联 US: 通过 REQ 或系统重叠连接的 [US-XXX]
+  ├── 所属系统: Level 1 WBS 系统名称
+  ├── 依赖: [T{A.B.C}, ...]
+  ├── 验收标准: [列表]
+  ├── 预估工时: N
+  └── Sprint: S{N}
+```
+
+---
+
+## 🔍 6 大检测 Pass
+
+### Pass A: 重复检测 (Duplication Detection)
+
+**目标**: 发现浪费精力或导致混乱的冗余任务。
+
+| # | 检查项 | 如何检查 |
+|---|--------|---------|
+| A1 | **近重复任务** | 比较任务标题+描述的语义相似度。标记意图重叠 >70% 的任务对。 |
+| A2 | **共享验收标准** | 相同的 Given-When-Then 在多个任务中逐字或换述出现。 |
+| A3 | **输出重叠** | 两个任务产出同一个文件/组件/接口。 |
+
+**建议**: 合并重复项，或标注为"共享验收"（如确实都需要）。
+
+---
+
+### Pass B: 歧义检测 (Ambiguity Detection)
+
+**目标**: 消除使任务不可验证的模糊语言。
+
+| # | 检查项 | 如何检查 |
+|---|--------|---------|
+| B1 | **模糊形容词扫描** | 标记验收标准中的这些词：正确/正常/合理/快速/稳定/安全/直观/健壮/appropriate/proper/correct/fast/stable/secure/intuitive/robust |
+| B2 | **未解决占位符扫描** | 标记：`TODO`、`TBD`、`???`、`<placeholder>`、`[TBD]`、`FIXME` |
+| B3 | **未量化的非功能需求** | 没有具体数字的性能/安全需求（如"快速响应"但无延迟目标） |
+| B4 | **含糊代词** | 任务描述中 "它"、"这个"、"系统" 指代不明 |
+
+**严重度规则**: B1/B3 在 P0 任务中 → HIGH；在 P2 任务中 → MEDIUM。B2 一律 → HIGH。
+
+---
+
+### Pass C: 欠详述检测 (Underspecification)
+
+**目标**: 发现信息不足以执行的任务。
+
+| # | 检查项 | 如何检查 |
+|---|--------|---------|
+| C1 | **有动词无宾语** | 验收标准有动作动词但无具体目标（如"处理错误" → 什么错误？哪个处理器？） |
+| C2 | **缺失验收标准** | 任务的验收标准为零或只有 1 条模糊标准 |
+| C3 | **幽灵引用** | 任务引用了 Architecture 文档中不存在的组件/接口/API |
+| C4 | **缺失输入/输出** | 任务没有明确的输入或输出字段 |
+| C5 | **缺失验证说明** | 任务没有说明如何验证完成 |
+
+**严重度规则**: C2 在 P0 任务上 → CRITICAL。C3 一律 → HIGH。
+
+---
+
+### Pass D: 不一致性检测 (Inconsistency) — 跨文档交叉验证
+
+> ⚠️ 依赖 PRD + Architecture。若不可用，跳过并注明。
+
+**目标**: 捕捉 PRD、Architecture、ADR 和 Tasks 之间的矛盾。
+
+| # | 检查项 | 如何检查 |
+|---|--------|---------|
+| D1 | **术语漂移** | 同一概念在不同文档中使用不同名称（如 PRD: "game core", Architecture: "Core Engine", Tasks: "核心引擎"） |
+| D2 | **孤儿架构组件** | Architecture 中定义的系统/组件在 Tasks 中没有对应任务覆盖 |
+| D3 | **依赖与排期冲突** | 任务 A 依赖任务 B，但 A 被安排在比 B 更早的 Sprint |
+| D4 | **技术栈冲突** | ADR 选定技术 X，但任务中使用技术 Y |
+| D5 | **接口不匹配** | 任务 A 的输出格式 ≠ 任务 B 的预期输入格式（当 B 依赖 A 时） |
+
+**严重度规则**: D3 一律 → CRITICAL（执行必然失败）。D2 → HIGH。D1 → MEDIUM。
+
+---
+
+### Pass E: 覆盖率检测 (Coverage Gaps)
+
+**目标**: 确保没有遗漏。
+
+| # | 检查项 | 如何检查 |
+|---|--------|---------|
+| E1 | **正向覆盖** | PRD 中每个 REQ-XXX → 至少 1 个 task？构建 REQ 覆盖矩阵。 |
+| E2 | **反向覆盖（幽灵任务）** | 每个 task → 追溯到某个 REQ？无 REQ 追溯的任务是"幽灵任务"——可能是过度工程。 |
+| E3 | **User Story 完整性** | 每个 US-XXX → 任务链覆盖其所有涉及系统？能形成独立可验证的闭环？ |
+| E4 | **NFR 覆盖** | 非功能需求（性能、安全、无障碍）→ 有专门任务或已融入现有任务？ |
+| E5 | **边界/错误覆盖** | PRD 边界情况 → 有对应的测试/处理任务？ |
+
+**输出**: REQ 覆盖矩阵 + US 完整性表（见 §输出格式）。
+
+**严重度规则**: E1 在 P0 REQ 上缺失 → CRITICAL。E2 幽灵任务 → LOW（仅信息）。E3 不完整 US → HIGH。
+
+---
+
+### Pass F: 质量与粒度检查 (Quality & Granularity)
+
+**目标**: 确保任务大小合理、结构正确。
+
+| # | 检查项 | 如何检查 |
+|---|--------|---------|
+| F1 | **过大任务** | 预估工时 > 8h → 建议拆分 |
+| F2 | **过小任务** | 预估工时 < 1h → 建议与相关任务合并 |
+| F3 | **深度依赖链** | 链长 > 5 → 警告瓶颈风险 |
+| F4 | **孤立任务** | 无依赖方且不被依赖（孤岛）→ 确认是否有意为之 |
+| F5 | **关键路径分析** | 识别最长依赖链 → 标出瓶颈任务 |
+| F6 | **验收标准质量** | Given-When-Then 完整性 + 可执行验证方法 |
+| F7 | **Sprint 均衡度** | Sprint 工作量方差 > 均值 50% → 不均衡警告 |
+
+**严重度规则**: F1 > 16h → HIGH。F3 链 > 7 → HIGH。F5 仅信息 → LOW。
+
+---
+
+## 📊 输出格式：任务审查报告
+
+按以下结构生成报告：
+
+```markdown
+## 📊 任务审查报告
+
+> **审查文件**: genesis/v{N}/05_TASKS.md  
+> **对照文档**: 01_PRD.md, 02_ARCHITECTURE_OVERVIEW.md, 03_ADR/*  
+> **日期**: {YYYY-MM-DD}
+
+---
+
+### 检测摘要
+
+| Pass | 检测项数 | CRITICAL | HIGH | MEDIUM | LOW |
+|------|:-------:|:--------:|:----:|:------:|:---:|
+| A 重复检测 | — | — | — | — | — |
+| B 歧义检测 | — | — | — | — | — |
+| C 欠详述检测 | — | — | — | — | — |
+| D 不一致性检测 | — | — | — | — | — |
+| E 覆盖率检测 | — | — | — | — | — |
+| F 质量粒度 | — | — | — | — | — |
+| **合计** | **—** | **—** | **—** | **—** | **—** |
+
+**整体健康度**: 🟢 健康 / 🟡 需关注 / 🔴 阻塞
+
+---
+
+### REQ 覆盖率
+
+| REQ-ID | 标题 | 优先级 | 关联任务 | 状态 |
+|--------|------|:------:|---------|:----:|
+| REQ-001 | ... | P0 | T2.1.1, T2.1.2 | ✅ |
+| REQ-003 | ... | P0 | — | ❌ GAP |
+
+**覆盖率**: {已覆盖}/{总数} ({百分比}%)
+
+---
+
+### User Story 完整性
+
+| US-ID | 标题 | 涉及系统 | 关联任务 | 独立可测 | 状态 |
+|-------|------|---------|---------|:--------:|:----:|
+| US-001 | ... | core, client | T2.1.1→T7.2.1 | ✅ | ✅ |
+| US-003 | ... | core, executor | T3.2.1 (不完整) | ❌ | ⚠️ |
+
+---
+
+### 术语一致性
+
+| 术语 | PRD 中 | Architecture 中 | Tasks 中 | 状态 |
+|------|--------|----------------|---------|:----:|
+| ... | "..." | "..." | "..." | ⚠️ 漂移 |
+
+---
+
+### 关键路径
+
+> 最长依赖链，高亮瓶颈任务。
+
+```mermaid
+graph LR
+  T1.1.1 --> T2.1.1 --> T2.1.2 --> T4.1.1:::bottleneck --> T6.1.1
+  classDef bottleneck fill:#f96,stroke:#333
+```
+
+---
+
+### 问题清单
+
+| 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" |
+| ... | ... | ... | ... | ... |
+
+---
+
+### 溢出摘要（发现 > 50 条时）
+
+{N} 条额外发现被省略。主要类别: ...
+```
+
+---
+
+## 🎚️ 严重度分级
+
+| 等级 | 判定标准 | 典型示例 |
+|:----:|---------|---------|
+| **CRITICAL** | 阻塞执行或遗漏核心功能 | PRD 需求零覆盖；Sprint 依赖环；核心文档缺失 |
+| **HIGH** | 导致返工或产出不可验证 | 重复任务；模糊的安全/性能验收；不可测标准；技术栈冲突 |
+| **MEDIUM** | 影响质量但不阻塞 | 术语漂移；NFR 覆盖缺失；边界情况欠详细 |
+| **LOW** | 润色项，不影响执行 | 措辞改进；轻微冗余；仅供参考 |
+
+**升级规则**: CRITICAL ≥ 1 → 整体健康度设为 🔴 阻塞。HIGH ≥ 5 → 🟡 需关注。其余 → 🟢 健康。
+
+---
+
+## 💡 审查要诀
+
+1. **不要过度标记**: 如果任务虽措辞不完美但意思明确，最多标 LOW。
+2. **上下文很重要**: 游戏 Tick 循环里的"快速"和批处理任务里的"快速"含义截然不同。
+3. **架构感知**: 用 `02_ARCHITECTURE_OVERVIEW.md` 的系统边界验证任务范围。
+4. **尊重 ADR**: 如果 ADR 明确选择了某个权衡并有文档记录，不要重新翻旧账。
+5. **增量价值**: 哪怕只找到 3 条 CRITICAL，审查就物有所值。完美不是目标。