adspecs 0.1.12

package/skills/adspecs-adversarial-review/SKILL.md

@@ -0,0 +1,486 @@
+---
+name: "adspecs-adversarial-review"
+description: "使用对抗策略对需求文件、系统设计文件和开发任务清单进行一致性与质量审查。支持单文档模式（仅 PRD）和三文档联合模式。引入多个红队角色从不同立场挑战文档中的假设、缺失、矛盾与歧义"
+argument-hint: "指定1~3个文档路径。单文档：PRD路径；三文档：PRD路径 系统设计路径 任务清单路径"
+compatibility: "需要 docs/ 目录体系：docs/20-prd（需求）+ docs/30-system-design（系统设计+tasks）+ CLAUDE.md。单文档模式仅需 PRD"
+metadata:
+  author: "qingwen"
+  source: "基于对抗策略三文档联合审查框架 + ECP 全链路追溯 ID 体系 + 单文档深度审查模式"
+user-invocable: true
+disable-model-invocation: false
+---
+
+## 用户输入
+
+```text
+$ARGUMENTS
+```
+
+在处理之前**必须**考虑用户输入（若不为空）。用户应提供文档路径，支持两种模式：
+
+| 模式           | 输入                 | 示例                                                                              |
+| -------------- | -------------------- | --------------------------------------------------------------------------------- |
+| **单文档模式** | 1 个 PRD 路径        | `docs/20-prd/002-product-catalog-master-data/M01-产品目录主数据需求规格说明书.md` |
+| **三文档模式** | 3 个路径（空格分隔） | `PRD.md _system-design.md _tasks.md`                                              |
+
+若为空则从上下文推导。
+
+## 目标
+
+模拟真实项目中的**利益冲突与认知偏差**，引入多个"红队"角色，对需求文档（PRD）进行对抗式审查。支持两种工作模式：
+
+- **单文档模式**：仅审查 PRD，红队角色聚焦需求质量、完整性、歧义、可测试性和隐含假设
+- **三文档联合模式**：对 PRD + 系统设计 + 任务清单进行三轮对抗式审查（单文档攻击 + 交叉一致性 + 综合裁决）
+
+核心目标不是单纯"找错"，而是以最低成本暴露文档中的结构性矛盾、歧义、缺失和过度设计，从而在编码前消除隐患。
+
+**与 `adspecs-analyze` 的区别**：
+
+- `adspecs-analyze`：**静态/一致性/兼容性分析**——侧重 ECP 编码规范合规检查和全链路 ID 追溯
+- `adspecs-adversarial-review`：**动态/对抗/破坏性分析**——侧重红队角色的主动挑战和"如果X会怎样"的场景推演
+
+## 操作约束
+
+**严格只读**：**不**修改任何文件。输出结构化的对抗审查报告。提供修复建议但需用户明确批准后才可应用。
+
+## 输入要求
+
+### 必选文档
+
+| #   | 文档类型            | 路径模式                         | 关键内容                                                   |
+| --- | ------------------- | -------------------------------- | ---------------------------------------------------------- |
+| 1   | **需求文档（PRD）** | `docs/20-prd/{crm\|mom}/{模块}/` | 用户故事（US-###）、业务规则（BR-###）、验收场景、权限矩阵 |
+
+### 可选文档（三文档联合模式时需要）
+
+| #   | 文档类型         | 路径模式                                                     | 关键内容                                                      |
+| --- | ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------- |
+| 2   | **系统设计文档** | `docs/30-system-design/{crm\|mom}/{功能名}_system-design.md` | OOA+OOD 13 章统一设计（实体、行为、接口、异常、依赖）         |
+| 3   | **开发任务清单** | `docs/30-system-design/{crm\|mom}/{功能名}_tasks.md`         | Phase 1~N 结构、Task ID、`[TDD]`/`[P]`/`[US#]` 标记、文件路径 |
+
+> **模式判定**: 若仅提供文档 1（PRD）→ 进入**单文档模式**；若提供全部 3 个文档 → 进入**三文档联合模式**。
+
+---
+
+## 对抗角色定义
+
+本 Skill 依次扮演**五个红队角色**（前四者为单文档攻击者，最后为一致性裁判）：
+
+| 角色             | 攻击视角                                 | 核心攻击问题                                                                      | 提问模板                                        |
+| ---------------- | ---------------------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------- |
+| **需求杀手**     | 需求可行性、完整性、无歧义、可测试性     | 这个需求能客观验证吗？有没有遗漏边界/异常？是否存在伪命题？是否依赖未声明的假设？ | "如果 [异常条件]，这个需求还成立吗？"           |
+| **架构破坏者**   | 设计冗余、过度复杂、技术债、高负载失效   | 如果流量翻10倍，哪里先崩？有没有循环依赖？安全控制是否缺失？技术选型是否过度？    | "假设 [极端场景]，设计中的哪个组件第一个失效？" |
+| **任务质疑者**   | 任务拆分粒度、依赖关系、可验证性、工作量 | 任务拆分够细吗？DoD 是什么？是否遗漏集成/测试/监控/回滚任务？依赖是否形成死锁？   | "如果只完成这个任务，能独立验证什么？"          |
+| **用户代理**     | 端到端体验、边界情况、异常流程           | 正常流程之外的操作路径是什么？用户犯错时会发生什么？界面反馈是否友好？            | "作为用户，如果我 [意外操作]，系统会怎样？"     |
+| **安全运维对抗** | 攻击面、可观测性、回滚能力               | 设计是否隐含安全漏洞？任务是否包含监控埋点？是否有回滚方案？数据一致性如何保证？  | "如果 [攻击场景]，防御措施在哪里？"             |
+
+---
+
+## 审查流程
+
+审查流程根据输入文档数量自动选择模式。
+
+---
+
+### 模式 A：单文档 PRD 深度审查（仅需求规格说明书）
+
+**适用场景**: 仅有 PRD，尚未产出系统设计和任务清单。在需求阶段尽早暴露问题。
+
+**参与角色**: 需求杀手（主攻）、用户代理（主攻）、安全运维对抗（辅攻）
+
+#### A.1 第1轮：多角色需求攻击
+
+所有适用角色从各自视角对 PRD 发起独立攻击，产出统一的"需求缺陷清单"。
+
+**需求杀手**（主攻维度）:
+
+| 维度             | 检查要点                                                                                     |
+| ---------------- | -------------------------------------------------------------------------------------------- |
+| **不可测试**     | 缺少量化指标；验收场景缺少 Given-When-Then 结构；成功标准无法客观度量                        |
+| **不完整**       | 遗漏边界条件、异常流程、非功能需求（性能/安全/合规）；用户故事的验收场景不足；角色权限未定义 |
+| **歧义**         | 同一概念前后术语不一致；占位符未解决（TODO/TKTK/???）；模糊形容词（"快速""稳定""友好"）      |
+| **不可实现**     | 依赖未说明的假设；依赖外部系统但未定义接口契约；需求超出项目技术能力                         |
+| **优先级不合理** | P1 故事是否有必要的前置故事？P2 故事是否实际是 P1 的硬依赖？                                 |
+| **范围漂移**     | 是否混入了本应属于其他模块的功能？范围边界是否清晰？                                         |
+
+**用户代理**（主攻维度）:
+
+| 维度                 | 检查要点                                                              |
+| -------------------- | --------------------------------------------------------------------- |
+| **端到端流程**       | 核心用户旅程是否完整可闭环？是否存在断头路（只有开始没有结束）？      |
+| **异常路径**         | 用户犯错时会发生什么？系统如何反馈？撤销/回退操作是否存在？           |
+| **空/加载/错误状态** | 列表无数据时如何展示？接口超时/失败时用户看到什么？权限不足时的反馈？ |
+| **角色切换**         | 不同角色看到的内容是否正确区分？只读角色是否被错误赋予了编辑能力？    |
+
+**安全运维对抗**（辅攻维度）:
+
+| 维度         | 检查要点                                                         |
+| ------------ | ---------------------------------------------------------------- |
+| **权限缺口** | 是否存在未定义权限的功能？敏感数据是否暴露给了低权限角色？       |
+| **数据保护** | 客户/物料等敏感信息是否被合理保护？导出/接口是否有数据范围控制？ |
+| **审计追溯** | 关键操作是否要求记录审计日志？变更历史是否可追溯？               |
+
+输出格式：
+
+```markdown
+### 需求缺陷清单（单文档模式 — 需求杀手 + 用户代理 + 安全运维对抗）
+
+| ID   | 攻击角色     | 缺陷类型 | 位置       | 缺陷描述                                                | 严重级别 | 修复建议                                                       |
+| ---- | ------------ | -------- | ---------- | ------------------------------------------------------- | -------- | -------------------------------------------------------------- |
+| R-01 | 需求杀手     | 不可测试 | PRD §2.1.3 | "评审时参考物料类型" — "参考"无具体行为定义             | HIGH     | 补充：评审页展示物料类型字段，不允许编辑                       |
+| R-02 | 用户代理     | 不完整   | PRD §3.1.2 | CTCT 新增时若客户模块不可用，选择客户的交互未定义空状态 | MEDIUM   | 补充验收场景：客户模块不可用时客户选择器展示错误提示和重试按钮 |
+| R-03 | 安全运维对抗 | 权限缺口 | PRD §5.1   | IN1-01 接口权限标识存在但未定义调用频率限制             | MEDIUM   | 补充：定义接口调用频率上限，防止滥用                           |
+```
+
+#### A.2 第2轮：模块边界与依赖审查
+
+**目标**: 检查 PRD 的外部依赖声明是否完整，模块边界是否清晰，防止隐性耦合。
+
+| 检查点             | 攻击问题                                                                       |
+| ------------------ | ------------------------------------------------------------------------------ |
+| **外部依赖完整性** | "§7.3 列出的外部依赖是否覆盖了所有跨模块引用？是否有遗漏的隐式依赖？"          |
+| **接口契约明确性** | "依赖的外部接口是否定义了输入/输出/错误码/超时/降级策略？"                     |
+| **模块边界清晰性** | "是否混入了本应由其他模块负责的功能？§1.3.2 排除列表是否足够？"                |
+| **数据所有权**     | "外部引用的数据（如客户编号）是否明确了数据所有者？是否假设了外部数据的格式？" |
+
+输出格式：
+
+```markdown
+### 模块边界与依赖审查（单文档模式）
+
+| ID   | 缺陷类型 | 位置         | 缺陷描述                                                            | 严重级别 | 修复建议                                            |
+| ---- | -------- | ------------ | ------------------------------------------------------------------- | -------- | --------------------------------------------------- |
+| D-01 | 隐式依赖 | PRD §4.3.3.1 | IN1-01 调用客户模块获取销售组织名称，但未声明对组织架构主数据的依赖 | HIGH     | 在 §7.3 补充：组织架构主数据 — 提供销售组织名称查询 |
+```
+
+#### A.3 第3轮：综合裁决
+
+汇总前两轮所有缺陷，输出最终裁决报告：
+
+```markdown
+### 综合裁决（单文档模式）
+
+| 缺陷总数 | CRITICAL | HIGH | MEDIUM | LOW |
+| -------- | -------- | ---- | ------ | --- |
+| X        | X        | X    | X      | X   |
+
+**验收关口**：所有 CRITICAL 缺陷必须关闭后，才允许进入 `/adspecs-plan` 阶段。
+
+**角色攻击力排名**:
+| 角色 | 发现缺陷数 | 最致命发现 |
+|------|-----------|-----------|
+| 需求杀手 | X | [最致命的需求缺陷] |
+| 用户代理 | X | [最致命 UX 缺陷] |
+| 安全运维对抗 | X | [最致命的安全缺陷] |
+
+**下一行动**：
+
+- CRITICAL ×N → 建议在 `/adspecs-plan` 前修复，修复后重新审查
+- HIGH ×N → 建议在实现前修复
+- MEDIUM ×N → 可在 `/adspecs-plan` 过程中逐步修复
+```
+
+---
+
+### 模式 B：三文档联合审查（PRD + 系统设计 + 任务清单）
+
+**适用场景**: PRD、系统设计、任务清单均已产出，需要进行全链路一致性和质量审查。
+
+### 第1轮：内部质量审查（单文档独立攻击）
+
+**目标**：每个文档独立接受 5 个角色的对抗挑战，产出"单文档缺陷报告"。这一轮不跨文档对比。
+
+#### 1.1 攻击需求文档 → 需求杀手 + 用户代理 主攻
+
+从以下维度输出缺陷清单：
+
+| 维度             | 检查要点                                                                          |
+| ---------------- | --------------------------------------------------------------------------------- |
+| **不可测试**     | 缺少量化指标（如"快速响应"→无具体时延）；验收场景缺少 Given-When-Then 结构        |
+| **不完整**       | 遗漏边界条件、异常流程、非功能需求（性能/安全/合规）；用户故事的验收场景不足      |
+| **歧义**         | 同一概念前后术语不一致（如"用户ID" vs "账户编号"）；占位符未解决（TODO/TKTK/???） |
+| **不可实现**     | 依赖未说明的假设（如"用户已登录"但未定义登录机制）；依赖外部系统但未定义接口契约  |
+| **优先级不合理** | P1 故事是否有必要的前置故事？P2 故事是否实际是 P1 的硬依赖？                      |
+
+输出格式：
+
+```markdown
+### 需求缺陷清单（攻击角色：需求杀手 + 用户代理）
+
+| ID   | 攻击角色 | 缺陷类型 | 位置             | 缺陷描述                              | 严重级别 | 修复建议                                  |
+| ---- | -------- | -------- | ---------------- | ------------------------------------- | -------- | ----------------------------------------- |
+| R-01 | 需求杀手 | 不可测试 | PRD §2.1.3 US-03 | "实时展示排产进度" — "实时"无量化指标 | HIGH     | 补充：排产进度查询响应时间 ≤ 2s，超时降级 |
+| R-02 | 用户代理 | 不完整   | PRD §2.1.6 US-06 | 概览视图无导出空数据时的空状态处理    | MEDIUM   | 补充验收场景：导出无数据时弹出提示        |
+```
+
+#### 1.2 攻击系统设计文档 → 架构破坏者 + 安全运维对抗 主攻
+
+从以下维度输出缺陷清单：
+
+| 维度           | 检查要点                                                          |
+| -------------- | ----------------------------------------------------------------- |
+| **耦合过度**   | 是否存在循环依赖？模块间是否过度耦合？Feign 调用链是否过长？      |
+| **非功能缺失** | 设计是否覆盖性能/安全/可用性/可扩展性？缓存策略是否充分？         |
+| **高负载失效** | 假设 QPS 翻10倍，索引/缓存/连接池/事务边界是否支撑？              |
+| **安全漏洞**   | 是否存在未鉴权端点？敏感数据是否加密？SQL 注入/XSS 防护是否到位？ |
+| **技术债**     | 是否引入了不必要的复杂性？是否存在未说明的设计决策？              |
+| **回滚能力**   | 数据库变更是否可回滚？部署失败后如何恢复？                        |
+
+输出格式：
+
+```markdown
+### 设计缺陷清单（攻击角色：架构破坏者 + 安全运维对抗）
+
+| ID   | 攻击角色   | 缺陷类型   | 位置      | 缺陷描述                                       | 严重级别 | 修复建议                           |
+| ---- | ---------- | ---------- | --------- | ---------------------------------------------- | -------- | ---------------------------------- |
+| D-01 | 架构破坏者 | 高负载失效 | 设计 §8.3 | 撤回与排产确认仅用乐观锁，高并发下可能大量重试 | HIGH     | 增加 `@Klock` 分布式锁作为补充保护 |
+```
+
+#### 1.3 攻击任务清单 → 任务质疑者 主攻
+
+从以下维度输出缺陷清单：
+
+| 维度           | 检查要点                                                 |
+| -------------- | -------------------------------------------------------- |
+| **可执行性**   | 任务描述是否足够具体可执行？是否缺少精确文件路径？       |
+| **DoD 缺失**   | 每个任务是否有明确的"完成定义"？测试通过标准是什么？     |
+| **依赖不完整** | 任务间依赖是否全部标注？是否有隐藏的隐式依赖？           |
+| **粒度不当**   | 是否有任务过大（应拆分）或过小（应合并）？               |
+| **遗漏任务**   | 是否缺少监控埋点/日志/回滚/数据迁移/文档更新等交叉任务？ |
+| **工作量失真** | 是否存在明显低估或高估的任务？                           |
+
+输出格式：
+
+```markdown
+### 任务缺陷清单（攻击角色：任务质疑者）
+
+| ID   | 缺陷类型 | 位置          | 缺陷描述                                          | 严重级别 | 修复建议                                   |
+| ---- | -------- | ------------- | ------------------------------------------------- | -------- | ------------------------------------------ |
+| T-01 | 遗漏任务 | tasks Phase 8 | 变更单审批通过后联动更新预测单，缺少回滚/补偿任务 | HIGH     | 新增回滚任务：审批通过后预测单数据恢复机制 |
+```
+
+---
+
+### 第2轮：交叉一致性审查（成对对比）
+
+**目标**：使用双向追溯矩阵，由一致性裁判角色指出三文档间的矛盾。
+
+#### 2.1 双向追溯矩阵构建
+
+提取三文档的 ID 体系：
+
+| 文档        | ID 体系                     | 提取方法                                                |
+| ----------- | --------------------------- | ------------------------------------------------------- |
+| 需求（PRD） | US-###、BR-###              | §2.1 用户故事、§3.2 业务规则                            |
+| 系统设计    | FUNC-###、PERM-###、§4 行为 | §1.1.3 功能条目映射、§1.1.4 权限映射、§4.1 业务行为清单 |
+| 任务清单    | T###、Phase #               | Task ID + `[US#]` 标签 + Phase 结构                     |
+
+#### 2.2 三组成对对比
+
+**对比 A：需求 → 设计**
+
+| 检查点                                    | 攻击问题                                                                                   |
+| ----------------------------------------- | ------------------------------------------------------------------------------------------ |
+| 每个 US/BR 是否在设计中有对应的实现方案？ | "US-03（查看排产反馈）在设计 §4.1 和 §5.1 中是否有完整的 Service 方法 + Controller 端点？" |
+| 是否存在设计元素无需求支撑（镀金）？      | "设计中是否有不被任何 US 引用的实体字段或 Service 方法？"                                  |
+| 需求优先级与设计覆盖顺序是否一致？        | "P1 故事 US-05（变更单）在设计中的实现复杂度是否被合理评估？"                              |
+
+**对比 B：设计 → 任务**
+
+| 检查点                                              | 攻击问题                                                            |
+| --------------------------------------------------- | ------------------------------------------------------------------- |
+| 每个设计模块是否至少对应一个开发任务？              | "设计 §5.1 的 23 个端点是否在 tasks 中都有对应的 Controller 任务？" |
+| 任务是否遗漏设计中的接口变更或数据迁移？            | "设计中的 Liquibase DDL 是否在 tasks Phase 2 中有对应任务？"        |
+| 设计的 Feign Client 依赖是否在 tasks 中有对应实现？ | "设计 §10 的 5 个外部依赖 ↔ tasks 中 5 个 Feign Client 任务？"      |
+
+**对比 C：需求 → 任务**
+
+| 检查点                                   | 攻击问题                                                                              |
+| ---------------------------------------- | ------------------------------------------------------------------------------------- |
+| 是否存在需求完全没有任务覆盖？           | "US-08（取消/删除预测单）在 tasks 中仅 Phase 5 有 2 个任务，是否覆盖了全部验收场景？" |
+| 是否存在任务实现了不在需求清单中的功能？ | "tasks 中是否有未在任何 US 中描述的功能实现任务？"                                    |
+| 需求的验收条件是否映射到具体的测试任务？ | "US-01-AC2（提报提前期拦截）是否在 tasks 中有 `[TDD]` 测试任务 T023 覆盖？"           |
+
+输出格式：
+
+```markdown
+### 交叉一致性矛盾清单（攻击角色：一致性裁判）
+
+| 矛盾ID | 对比维度  | 涉及文档                             | 矛盾描述                                                                                    | 严重级别 | 修复建议                                             |
+| ------ | --------- | ------------------------------------ | ------------------------------------------------------------------------------------------- | -------- | ---------------------------------------------------- |
+| C-01   | 需求→设计 | PRD §2.1.3 US-03 ↔ 设计 §4.1         | 需求要求"实时查询排产进度"，但设计中出站查询标注"超时降级不抛异常"—"实时"与"降级"语义矛盾   | HIGH     | 明确"实时"定义：≤2s 正常展示，超时降级展示"暂不可用" |
+| C-02   | 设计→任务 | 设计 §10 ↔ tasks                     | 设计依赖 5 个外部 Feign Client，tasks 仅有 5 个对应任务但 SoClient 的无超时降级处理         | MEDIUM   | 为 SoClient 任务增加超时降级说明                     |
+| C-03   | 需求→任务 | PRD §2.1.5 US-05-AC4 ↔ tasks Phase 8 | 需求验收场景"并发控制—存在未完成变更单时阻止新增"在 tasks T062 测试任务中未作为独立场景标注 | MEDIUM   | T062 测试任务明细中明确标注"并发控制场景"子项        |
+```
+
+---
+
+### 第3轮：综合对抗评审（三方合议）
+
+**目标**：汇总前两轮所有缺陷，每个对抗角色提出其 **Top 5 破坏性问题**，输出最终裁决报告。
+
+#### 3.1 各角色 Top 5 破坏性问题
+
+每个角色从前两轮发现中，提炼 5 个**如果不修复将导致项目失败或重大返工**的问题：
+
+```markdown
+### 需求杀手 Top 5
+
+| #   | 问题               | 如果不修复的后果 | 涉及文档 | 严重级别 |
+| --- | ------------------ | ---------------- | -------- | -------- |
+| 1   | [最致命的需求缺陷] | [后果]           | [位置]   | CRITICAL |
+| 2   | ...                | ...              | ...      | ...      |
+| 3   | ...                | ...              | ...      | ...      |
+| 4   | ...                | ...              | ...      | ...      |
+| 5   | ...                | ...              | ...      | ...      |
+
+### 架构破坏者 Top 5
+
+...
+
+### 任务质疑者 Top 5
+
+...
+
+### 用户代理 Top 5
+
+...
+
+### 安全运维对抗 Top 5
+
+...
+```
+
+#### 3.2 综合裁决
+
+```markdown
+### 综合裁决
+
+| 缺陷总数 | CRITICAL | HIGH | MEDIUM | LOW |
+| -------- | -------- | ---- | ------ | --- |
+| X        | X        | X    | X      | X   |
+
+**验收关口**：所有 CRITICAL 缺陷必须关闭后，才允许进入开发阶段。
+
+**下一行动**：
+
+- CRITICAL ×N → 建议立即修复后重新审查
+- HIGH ×N → 建议在实现前修复
+- MEDIUM ×N → 可在实现过程中逐步修复
+```
+
+---
+
+## 输出报告模板
+
+### 单文档模式报告结构
+
+```
+# 对抗审查报告（单文档模式）：[PRD 文件名]
+
+## 审查概要
+- 审查时间 / 审查模式：单文档 / 审查范围：[PRD路径] / 参与对抗角色
+
+## 第1轮：多角色需求攻击
+### 需求缺陷清单（需求杀手 + 用户代理 + 安全运维对抗）
+
+## 第2轮：模块边界与依赖审查
+### 边界与依赖缺陷清单
+
+## 第3轮：综合裁决
+### 缺陷汇总 / 角色攻击力排名 / 验收关口 / 下一行动
+
+## 修复优先级建议
+- P0 必须修复（CRITICAL）— `/adspecs-plan` 前修复
+- P1 强烈建议（HIGH）— 实现前修复
+- P2 建议（MEDIUM）— 计划过程中修复
+- P3 可选（LOW）— 后续迭代优化
+```
+
+### 三文档联合模式报告结构
+
+```
+# 对抗策略三文档联合审查报告
+
+## 审查概要
+- 审查时间 / 审查模式：三文档联合 / 三文档路径 / 参与对抗角色
+
+## 第1轮：单文档内部质量审查
+### 1.1 需求文档缺陷清单
+### 1.2 系统设计文档缺陷清单
+### 1.3 任务清单缺陷清单
+
+## 第2轮：交叉一致性审查
+### 2.1 需求 → 设计 矛盾清单
+### 2.2 设计 → 任务 矛盾清单
+### 2.3 需求 → 任务 矛盾清单
+
+## 第3轮：综合对抗评审
+### 3.1 各角色 Top 3 破坏性问题
+### 3.2 综合裁决与验收关口
+
+## 修复优先级建议
+- P0 必须修复（CRITICAL）
+- P1 强烈建议（HIGH）
+- P2 建议（MEDIUM）
+- P3 可选（LOW）
+```
+
+---
+
+## 严重级别定义
+
+| 级别               | 定义                           | 示例                                                                                     |
+| ------------------ | ------------------------------ | ---------------------------------------------------------------------------------------- |
+| **CRITICAL**（P0） | 阻止进入开发阶段，项目失败风险 | 需求核心功能完全无设计对应；设计存在循环依赖导致无法构建；system 级别的安全漏洞          |
+| **HIGH**（P1）     | 可能导致重大返工或功能缺失     | 需求/设计/任务间的矛盾导致验收场景无法通过；非功能需求（性能/安全）在设计/任务中完全缺失 |
+| **MEDIUM**（P2）   | 影响质量但不阻塞流程           | 术语不一致；单个边界情况遗漏；任务拆分粒度可优化                                         |
+| **LOW**（P3）      | 风格/措辞改进                  | 描述可更精确；注释缺失；非关键命名不一致                                                 |
+
+---
+
+## 执行前检查
+
+**检查扩展钩子（审查前）**：
+
+- 检查项目根目录下是否存在 `.adspecs/extensions.yml` 文件。
+- 如果存在，读取该文件并查找 `hooks.before_adversarial_review` 键下的条目。
+- 如果 YAML 无法解析或无效，则静默跳过钩子检查并继续正常流程。
+- 过滤掉 `enabled` 显式为 `false` 的钩子。
+- 对于每个可执行钩子，根据其 `optional` 标志处理（可选钩子提示用户、强制钩子自动执行）。
+- 如果没有注册任何钩子，或 `.adspecs/extensions.yml` 不存在，则静默跳过。
+
+## 强制性执行后钩子
+
+审查完成后，检查 `.adspecs/extensions.yml` 中 `hooks.after_adversarial_review` 键下的条目，同上规则处理。
+
+---
+
+## 完成标准
+
+### 单文档模式
+
+- [ ] PRD 已加载并接受 3 个角色（需求杀手+用户代理+安全运维对抗）的攻击
+- [ ] 模块边界与依赖审查已完成
+- [ ] 输出完整的单文档对抗审查报告
+- [ ] CRITICAL 缺陷清单明确标注验收关口
+- [ ] 扩展钩子已根据规则派发或跳过
+
+### 三文档联合模式
+
+- [ ] 三文档均已加载并接受 5 个角色的单文档攻击
+- [ ] 双向追溯矩阵已完成三组成对对比
+- [ ] 每个角色提出了 Top 3 破坏性问题
+- [ ] 输出完整的对抗审查报告
+- [ ] CRITICAL 缺陷清单明确标注验收关口
+- [ ] 扩展钩子已根据规则派发或跳过
+
+---
+
+## 操作原则
+
+- **绝不修改文件**（只读审查）
+- **角色立场坚定**：每个角色以其攻击视角为核心，不折中、不妥协
+- **聚焦高影响问题**：优先暴露结构性矛盾，而非拼写和格式
+- **具体而非泛泛**：每条发现必须引用具体的文档位置（章节号/行号/ID）
+- **对抗而非合作**：角色之间不互相妥协，各自的攻击发现独立呈现