6aspec 3.0.0-dev.2 → 3.0.0-dev.21

package/.6aspec/rules/biz/code.md

@@ -24,9 +24,12 @@ alwaysApply: true
 
 ### 架构红线
 - **禁止循环依赖**：包、模块、类之间不能相互依赖
-- **禁止跨层直接调用**：Controller不能直接调用DAO
+- **禁止在应用入口层跨层直连数据访问或在入口类堆叠编排**：应用入口包括 HTTP/RPC/API Controller（或同类请求入口）、事件订阅、消息消费者、调度或定时任务入口等。
+  -  **此类入口**不得**直接调用 DAO/Repository；
+  - **不得**在入口类集中承载远程/RPC 查询、仓储批量查询、Stream 聚合（如 `groupingBy`）、多分支循环等业务编排。上述逻辑须在 Service/应用服务（或设计文档/项目约定的应用层 Facade）中实现；
+  - 入口仅允许必要校验、日志及对上述服务的委托。
+  - **例外**：需求/TASK/设计说明明确要求与某存量入口类保持同一写法时，从其约定。
 - **禁止在实体类中包含业务逻辑**：保持实体类的纯净性
-- **禁止在静态代码块中进行复杂操作**：可能导致类加载问题
 - **禁止捕获异常后不处理**：空catch块是代码异味
 
 ## 🔒 安全规范
@@ -115,7 +118,7 @@ alwaysApply: true
 ## ✅ 检查清单
 
 ### 代码提交前检查
-- [ ] 是否违反红线规则
+- [ ] 是否违反红线规则（含架构红线中的应用入口与跨层约定，有文档例外除外）
 - [ ] 是否有安全漏洞
 - [ ] 是否有性能问题
 - [ ] 命名是否规范
@@ -129,5 +132,6 @@ alwaysApply: true
 - [ ] 边界条件是否考虑
 - [ ] 是否有代码重复
 - [ ] 是否符合设计原则
+- [ ] 新增/改动的 Controller/API 入口、订阅、消费者、调度入口是否违反架构红线（薄入口、不直连 DAO、委托 Service）
 - [ ] 是否有技术债务
 - [ ] 文档是否需要更新

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

@@ -16,7 +16,7 @@
 
 如果提供了名称，使用它。否则：
 - 从对话上下文推断
-- 如果模糊，读取 `6aspecdoc/brown/` 目录，让用户选择
+- 如果模糊，读取 `6aspecdoc/brown/` 目录，使用 `AskUserQuestion` 工具列出需求让用户选择
 
 读取 `6aspecdoc/brown/<name>/status.json`：
 - 确认流程深度为 "standard" 或 "complete"
@@ -159,7 +159,11 @@ b. **判断是否需要追问或指出风险**：
    - 答案清晰完整且无风险 → 继续
    - **不涉及技术实现层面的问题**（事务、通知机制、回滚策略等），那是 design 阶段的职责
 
-c. **追问格式**（简洁，不重复已知信息）：
+c. **追问时先写文档，再提问**：
+   - 将追问内容追加到 analysis.md "待澄清问题"章节（标注为追问，例：`> 追问：[追问内容]`）
+   - 再向用户提问
+
+d. **追问格式**（简洁，不重复已知信息）：
    > "关于[具体问题]，你提到了[用户答案]，我想进一步确认：[追问内容]"
 
 d. **禁止**：不得在用户未回答完所有问题时自动进入影响面分析
@@ -283,6 +287,7 @@ e. **持续更新文档**：每次用户回复后，更新 analysis.md，确保
 - 代码范围确认前不得生成问题清单
 - 问题必须按维度分组，不得使用扁平编号列表
 - 每次用户回复后必须更新 analysis.md，保持文档与对话同步
+- 追问必须先写入 analysis.md "待澄清问题"章节，再向用户提问
 - 追问时一次最多提出 1-2 个问题，不得连续追问超过 3 轮同一问题
 - 必须用户明确确认澄清完成后才能进入影响面分析
 - 影响面分析只做粗粒度评估（模块范围、schema变更、间接影响有/无），不做函数级映射

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

@@ -18,9 +18,10 @@
 
 2. **确认归档**
 
-   询问用户确认：
+   使用 `AskUserQuestion` 工具确认：
    ```
-   确认归档需求 <name>？归档后需求将移至归档目录，操作不可逆。
+   问题："确认归档需求 <name>？归档后需求将移至归档目录，操作不可逆。"
+   选项：
    - 是，归档此需求
    - 否，取消归档
    ```

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

@@ -10,9 +10,7 @@
 
    如果提供了名称，使用它。否则：
    - 从对话上下文推断
-   - 如果模糊，读取 `6aspecdoc/brown/` 目录，让用户选择
-
-   显示最近修改的 3-4 个需求作为选项，标注最近修改的为 "(推荐)"。
+   - 如果模糊，读取 `6aspecdoc/brown/` 目录，使用 `AskUserQuestion` 工具列出最近修改的 3-4 个需求让用户选择，标注最近修改的为 "(推荐)"。
 
 2. **检查当前状态**
 

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

@@ -7,7 +7,9 @@
 > - 执行模型：主 agent 作为协调者，每个任务派发独立的 implementer subagent 执行；实现完成后派发 spec compliance reviewer subagent 验证；主 agent 只管理队列和状态，不直接写代码。
 > - 关键承接：Tasks 中定义的「契约/数据库变更/迁移兼容回滚」等交付物，必须在 Implement 阶段逐项落地并验收。
 
-**输入**：`/6aspec:brown:implement` 后可选需求名称。
+**输入**：`/6aspec:brown:implement` 后可选需求名称；可选 `--skipTest=true` 或 `--skipTest=false`（仅认带 `=` 的写法）。**未写 `skipTest` 时视为 `false`**（标准测试模式：编写适用单测并尽量执行范围受限的测试命令）。
+
+主 agent 须在**每一次**派发 `6aspec-brown-implementer` 时显式传入一行：`skipTest：true` 或 `skipTest：false`（与用户在命令中的取值一致）；修复循环中重新调用 implementer 时须**沿用同一取值**，除非用户明确要求修改。
 
 ---
 
@@ -15,6 +17,9 @@
 
 1. **选择需求并检查状态**
 
+   - 从用户本次命令中解析 `--skipTest=true` / `--skipTest=false`；若未出现则记为 `false`
+   - 如果用户在命令中指定了特定任务（如"只实现 TASK-001"、"实现 TASK-002 和 TASK-003"），记录为**指定任务模式**，只将这些任务加入执行队列；仍需在步骤 3 检查其前置依赖是否已完成，若未完成则提示用户并暂停。未指定则为**全量模式**，按原有里程碑优先 + 依赖优先全量执行。
+
    - 读取 `6aspecdoc/brown/<name>/status.json`
    - 确认 `phases.tasks` 为 “done”
    - 如果未完成 Phase 4，提示先运行 `/6aspec:brown:tasks`
@@ -35,18 +40,36 @@
    - 各里程碑完成度（M0~Mn：已完成/总数）
    - 下一个可执行任务
 
+   **建立任务列表（外部状态锚点）**：
+
+   为每个待执行的 TASK，依次调用 `TaskCreate` 建立两个子任务，顺序为：
+   ```
+   TASK-<序号>: 实现
+   TASK-<序号>: Compliance Review
+   ```
+   例如有 TASK-001、TASK-002 待执行，则建立：
+   - `TASK-001: 实现`
+   - `TASK-001: Compliance Review`
+   - `TASK-002: 实现`
+   - `TASK-002: Compliance Review`
+
+   > 目的：任务列表作为外部状态锚点，防止 implementer subagent 返回后因"完成感"跳过 compliance review 步骤。
+
 4. **执行任务（循环直到完成或阻塞）**
 
    对每个待完成的任务，按以下流程执行：
 
    **a. 派发 implementer agent**
 
-   调用 `implementer` agent，传入以下内容：
+   调用前：将对应的 `TASK-<序号>: 实现` 任务标记为 `in_progress`。
+
+   调用 `6aspec-brown-implementer` agent，传入以下内容：
 
    ```
-   请用 implementer agent 实现以下任务：
+   请用 6aspec-brown-implementer agent 实现以下任务：
 
    需求名称：[name]
+   skipTest：false（或 true，须与本流程步骤 1 解析的 --skipTest 取值一致）
    TASK 文件路径：6aspecdoc/brown/[name]/tasks/TASK-<序号>.md
    specs.md 路径：6aspecdoc/brown/[name]/artifacts/specs.md
    design.md 路径：6aspecdoc/brown/[name]/artifacts/design.md
@@ -55,20 +78,23 @@
    ```
 
    **处理 agent 状态**：
-   - `DONE`：进入 spec compliance review
-   - `DONE_WITH_CONCERNS`：读取关注点，判断是否影响正确性；若影响则先处理，否则进入 review
+   - `DONE`：将 `TASK-<序号>: 实现` 标记为 `completed`，进入 spec compliance review
+   - `DONE_WITH_CONCERNS`：读取关注点，判断是否影响正确性；若影响则先处理，否则将 `TASK-<序号>: 实现` 标记为 `completed`，进入 review
    - `NEEDS_CONTEXT`：补充缺失信息后重新调用
    - `BLOCKED`：暂停，向用户报告阻塞原因和选项
    - **agent 开始前提问**：若 agent 在实现前提出疑问，主 agent 回答后重新调用（携带原有上下文 + 补充答案）
 
    **b. 派发 spec compliance reviewer agent**
 
-   调用 `spec-compliance-reviewer` agent，传入以下内容：
+   调用前：将对应的 `TASK-<序号>: Compliance Review` 任务标记为 `in_progress`。
+
+   调用 `6aspec-brown-spec-compliance-reviewer` agent，传入以下内容：
 
    ```
-   请用 spec-compliance-reviewer agent 审查以下任务的实现：
+   请用 6aspec-brown-spec-compliance-reviewer agent 审查以下任务的实现：
 
    需求名称：[name]
+   skipTest：false（或 true，须与本次实现所用取值一致）
    TASK 文件路径：6aspecdoc/brown/[name]/tasks/TASK-<序号>.md
    specs.md 路径：6aspecdoc/brown/[name]/artifacts/specs.md
 
@@ -77,15 +103,15 @@
    ```
 
    **处理 review 结果**：
-   - `✅ 通过`：标记任务完成，继续下一个任务
-   - `❌ 有问题`：重新调用 implementer agent 修复，传入原有上下文 + reviewer 的完整反馈（具体缺失/多余/偏差及文件路径）；修复后再次调用 reviewer；**最多循环 3 次**
+   - `✅ 通过`：
+     1. 将 `TASK-<序号>: Compliance Review` 标记为 `completed`
+     2. 在任务文件中更新状态：`📋 待开始` → `✅ 已完成`
+     3. 在 `tasks-overview.md` 中更新：`- [ ]` → `- [x]`（只修改勾选，不破坏链接结构）
+     4. 更新 `status.json` 中的任务计数
+     5. 继续下一个任务
+   - `❌ 有问题`：重新调用 6aspec-brown-implementer agent 修复，传入**相同的 `skipTest：true|false` 行** + 原有上下文 + reviewer 的完整反馈（具体缺失/多余/偏差及文件路径）；修复后再次调用 reviewer；**最多循环 3 次**
    - **超过 3 次仍未通过**：暂停，向用户报告每轮的问题和修复情况，让用户决定如何处理
 
-   **c. 标记任务完成**
-   - 在任务文件中更新状态：`📋 待开始` → `✅ 已完成`
-   - 在 `tasks-overview.md` 中更新：`- [ ]` → `- [x]`（只修改勾选，不破坏链接结构）
-   - 更新 `status.json` 中的任务计数
-
    **暂停条件**：
    - `BLOCKED`：实现遇到阻塞，向用户报告
    - 发现设计问题：暂停，建议更新 artifacts（design/specs/tasks）
@@ -156,7 +182,7 @@
 ## 防护措施
 
 - 必须先完成 Phase 4（Tasks）
-- 主 agent 只做协调，不直接写代码；实现由 `implementer` agent 完成，验证由 `spec-compliance-reviewer` agent 完成
+- 主 agent 只做协调，不直接写代码；实现由 `6aspec-brown-implementer` agent 完成，验证由 `6aspec-brown-spec-compliance-reviewer` agent 完成
 - 串行执行，不并行调用多个 implementer agent
 - implementer agent 报告 BLOCKED 时必须暂停并向用户报告，不得强行重试
 - spec compliance review 必须通过才能标记任务完成，不得跳过

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

@@ -13,8 +13,12 @@
 
    根据用户输入判断类型：
 
-   **情况A：无输入** — 询问用户（开放式问题）：
-   > "你想分析什么需求？请描述要实现的功能或要解决的问题，也可以 @引用 一个需求文档。"
+   **情况A：无输入** — 使用 `AskUserQuestion` 工具询问：
+   ```
+   问题："你想分析什么需求？"
+   选项（Other 即可，无需固定选项）
+   ```
+   或直接用开放式文本输入（Other）让用户描述需求。
 
    **情况B：直接文字描述** — 记录原始描述文本，标记 `inputSource.type = "text"`。
 
@@ -26,13 +30,13 @@
 
 2. **选择流程深度**
 
-   让用户选择流程深度：
+   使用 `AskUserQuestion` 工具让用户选择流程深度：
    ```
    问题："请选择适合的流程深度："
    选项：
-   - 轻量级 - 无需分析现有系统（proposal → specs → design → tasks）（推荐用于与现有业务低耦合的需求）
-   - 标准级 - 深入分析（analyze → proposal → specs → design → tasks）（推荐用于需要分析现有业务影响面的需求）
-   - 快速通道 - 简单修复（直接实现，适用于Bug修复、单文件改动）
+   - 轻量级（推荐）- 无需分析现有系统（proposal → specs → design → tasks），适用于与现有业务低耦合的需求
+   - 标准级 - 深入分析（analyze → proposal → specs → design → tasks），适用于需要分析现有业务影响面的需求
+   - 快速通道 - 简单修复（直接实现），适用于 Bug 修复、单文件改动
    ```
 
    **流程深度说明**：

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

@@ -15,7 +15,7 @@
 
 1. **如果没有提供输入，询问需求内容**
 
-   询问用户：
+   使用 `AskUserQuestion` 工具询问（开放式，用 Other 输入）：
    > "你想快速处理什么需求？请描述要修复的问题或要做的改动。"
 
    从描述中提取 kebab-case 名称。

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

@@ -23,7 +23,7 @@
 
    如果提供了名称，使用它。否则：
    - 从对话上下文推断
-   - 如果模糊，读取 `6aspecdoc/brown/` 目录，让用户选择
+   - 如果模糊，读取 `6aspecdoc/brown/` 目录，使用 `AskUserQuestion` 工具列出需求让用户选择
 
 2. **检查当前状态**
 
@@ -56,13 +56,9 @@
 
 4. **确认回退操作**
 
-   询问用户确认：
+   使用 `AskUserQuestion` 工具确认：
    ```
-   确认回退操作？
-   - 当前阶段：<current-phase>
-   - 回退到：<previous-phase>
-   - 将删除的文件：<files-to-delete>
-
+   问题："确认回退操作？当前阶段：<current-phase>，将回退到：<previous-phase>，将删除：<files-to-delete>"
    选项：
    - 确认回退
    - 取消

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

@@ -59,7 +59,7 @@ Phase 4: 任务拆解与排期
    - 预估工作量在 0.5-3 人日（超过则继续拆分）
 
    **拆解维度**（可组合使用）：
-   - 按交付里程碑：契约与集成 → 数据变更 → 迁移/兼容/回滚 → 核心链路 → 集成联调与观测 → 发布准备
+   - 按交付里程碑：契约与集成 → 数据变更 → 迁移/兼容/回滚 → 核心链路
    - 按功能模块：模块A → 模块B → 模块C
    - 按依赖关系：前置任务 → 核心任务 → 后置任务
    - 按横切能力：Integration / Migration / Compatibility / Observability / Security
@@ -116,7 +116,13 @@ Phase 4: 任务拆解与排期
    1. <具体操作，到类/方法级>
    2. <具体操作>
    3. ...
-   4. **测试**：若项目有测试框架，补充/修改对应单元测试，覆盖 specs.md 中关联的 AC/Scenario；若无测试框架则跳过此步骤
+   4. **测试/验证（按任务类型写清楚，不要一刀切）**：
+      - 若本任务引入/修改可执行业务逻辑（如 Service/Domain/校验/计算/流程编排）或修复缺陷：
+        - 若项目有测试框架：补充/修改对应单元测试，覆盖 specs.md 中关联的 AC/Scenario
+        - 若无测试框架：写清验证方式与回归点（例如：手工验证步骤/日志观测点/接口回放用例）
+      - 若本任务主要为纯数据结构（Entity/DTO/VO/Enum/注解映射）或 SQL/DDL/迁移脚本：
+        - 默认不强制单元测试
+        - 必须写清可审查的验证清单（字段/约束/索引/影响面/回滚要点/关键校验 SQL）与回归点
 
    ## 验收标准
    - 与 Specs 对齐的 AC/Scenario 覆盖：<列出 ACx / Sx>
@@ -179,13 +185,6 @@ Phase 4: 任务拆解与排期
    - [ ] [TASK-030: 核心业务逻辑实现（对齐 AC/Scenario）](../tasks/TASK-030.md)
    - [ ] [TASK-031: 定时任务/事件消费/回调处理实现（如适用）](../tasks/TASK-031.md)
 
-   ### M4: 集成联调与可观测性（Integration & Observability）
-   - [ ] [TASK-040: 集成联调与异常路径验证（重试/乱序/重复）](../tasks/TASK-040.md)
-   - [ ] [TASK-041: 可观测性补齐（处理记录可查、日志/指标/追踪要点）](../tasks/TASK-041.md)
-
-   ### M5: 发布准备（Release）
-   - [ ] [TASK-050: 发布检查清单（灰度/回滚演练要点）](../tasks/TASK-050.md)
-
    ## 依赖关系图（示例）
 
    ```mermaid
@@ -193,8 +192,6 @@ Phase 4: 任务拆解与排期
        TASK001 --> TASK010
        TASK010 --> TASK020
        TASK020 --> TASK030
-       TASK030 --> TASK040
-       TASK040 --> TASK050
    ```
 
    ## 工作量统计
@@ -205,8 +202,6 @@ Phase 4: 任务拆解与排期
    | M1 | <n> | <x> 人日 |
    | M2 | <n> | <x> 人日 |
    | M3 | <n> | <x> 人日 |
-   | M4 | <n> | <x> 人日 |
-   | M5 | <n> | <x> 人日 |
    | **总计** | **<n>** | **<x> 人日** |
 
    ## 风险清单

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

@@ -41,7 +41,7 @@
 
    如果提供了名称，使用它。否则：
    - 从对话上下文推断
-   - 如果模糊，读取 `6aspecdoc/brown/` 目录，让用户选择
+   - 如果模糊，读取 `6aspecdoc/brown/` 目录，使用 `AskUserQuestion` 工具列出需求让用户选择
 
 2. **处理特殊选项**
 
@@ -70,15 +70,10 @@
 
 5. **获取用户修改需求**
 
-   询问用户要修改的内容：
+   使用 `AskUserQuestion` 工具询问（开放式，用 Other 输入）：
    ```
    问题："请描述您要对 <phase> 阶段文档进行的修改："
-
-   提示：
-   - 请具体描述要修改、补充或调整的内容
-   - 如果是补充信息，请说明要补充什么
-   - 如果是修正错误，请说明错误的地方和正确的内容
-   - 如果是调整描述，请说明要如何调整
+   提示：具体描述要修改、补充或调整的内容
    ```
 
 6. **执行更新（根据模式）**
@@ -123,7 +118,7 @@
    - 建议：<执行建议>
    ```
 
-   d. **等待用户确认**：
+   d. **使用 `AskUserQuestion` 工具等待用户确认**：
    ```
    问题："是否执行上述更新计划？"
    选项：

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

@@ -11,9 +11,17 @@
 - **design.md**：主 agent 传入的 `design.md 路径`，读取相关技术决策
 - **analysis.md**：主 agent 传入的 `analysis.md 路径`，读取现状分析和影响面背景（如果存在）
 - **explore-summary.md**：主 agent 传入的 `explore-summary.md 路径`，读取代码结构摘要（如果存在）
+- **code.md**：`.6aspec/rules/biz/code.md`，编码规范与红线（含**架构红线**中的应用入口与跨层约定）、安全/性能要求（与本次修改语言相关时须通读并遵守）
 
 如果你对任务要求、验收标准、实现策略或依赖关系有任何疑问，**现在就提出**，不要开始实现后再问。
 
+## 运行参数（由主 agent 根据用户命令传入）
+
+主 agent 应在派发本 subagent 时明确一行：`skipTest：true` 或 `skipTest：false`（与用户命令中的 `--skipTest=true` / `--skipTest=false` 一致）。**文档与实现只认带 `=true` / `=false` 的写法**；裸写 `--skipTest` 无赋值视为未规范输入，主 agent 应让用户改用 `=true` 或 `=false`。
+
+- **`skipTest：false` 或未传 `skipTest` 参数**：视为 **false**（标准测试模式），见下方职责第 6 条「`skipTest=false`」分支。
+- **`skipTest：true`**：**不编写**单元测试，**不执行**任何测试类命令（含 `test`、`mvn test`、`gradle test`、`pytest`、`go test` 等）；仍须在报告中写清**手动/静态验证方式、回归点与残余风险**。若 TASK/specs **明文要求**必须交付测试，而用户仍指定 `--skipTest=true`，实现前应先向主 agent **说明冲突并等待取舍**，不要擅自忽略 specs。
+
 ## 你的职责
 
 确认没有疑问后：
@@ -22,11 +30,22 @@
 2. 按"实现步骤"逐步执行，到类/方法级
 3. 遵循 design.md 的技术决策，**不在实现阶段发明新方案**
 4. 遵循现有代码风格和架构模式
-5. 检查红线规则（零容忍）：
-   - 循环中的数据库查询、网络请求、文件 I/O
-   - SQL 字符串拼接、敏感信息硬编码
-   - 空 catch 块、循环依赖、跨层直接调用
-6. 若项目有测试框架，补充/修改对应单元测试，覆盖任务关联的 AC/Scenario；若无测试框架则跳过
+5. **编码规范**：实现与自我审查须符合 `.6aspec/rules/biz/code.md`（含红线规则中的**架构红线**、安全、性能、命名与文内检查清单）
+6. **测试/验证（以 TASK / specs.md 的明确要求为准；并受 `skipTest` 约束）**：
+
+   **先读 TASK 再决定形式（避免「简单任务也写单测」）**  
+   - 若 TASK 的「输出 / 实现步骤 / 预发验证」已明确写：**手工 SQL、预发验证、冒烟、无内嵌 DB、或「有框架再测否则文档验证」**：**以 TASK 为准**，优先采用 TASK 已给出的验证路径；**不要**为「凑单测」再额外加 Repository/DAO 层单元测试，除非 TASK 或 specs **强制**要求必须交付自动化测试且项目里**已有**可落地的测试基础设施（如 Testcontainers/H2/既有集成测模式）。  
+   - **薄持久化**（仅 DDL/迁移、Entity 映射、`insert`/`update`/`delete`、无业务规则与无复杂查询编排的 Mapper/Repository）：与「纯数据结构」**同等对待**——默认**不**把「写单元测试」当作必选项；用可审查的验证清单（字段/约束/索引/回滚/关键 SQL）或 TASK 规定的预发步骤即可。
+
+   - **`skipTest=true` 时**：不写单元测试、不执行测试命令；改为提供可审查的验证说明（可含关键路径、数据与边界、建议人工/CI 回归点），并在报告中标注风险。
+   - **`skipTest=false`（含默认）时**：
+     - 若本任务引入/修改**可执行业务逻辑**（如 Service/Domain/校验/计算/流程编排）或修复缺陷：在项目有测试框架时补充/修改对应单元测试，覆盖任务关联的 AC/Scenario；若无测试框架则说明验证方式与回归点  
+     - 若本任务主要为纯数据结构、**SQL/DDL/迁移脚本**、或**薄持久化**（见上）：默认不强制单元测试；改为提供可审查的验证清单，并在报告中标注风险  
+     - **禁止**：把「本任务动到了 Repository/Mapper」**单独**当成必须写单测的理由；是否写单测取决于是否出现**非平凡逻辑**（分支、规则、补偿、复杂 SQL 行为），以及 TASK/specs 是否点名要自动化测试
+
+   **🚨 测试红线（绝对禁止）**：
+   - **禁止在测试代码中重新实现被测逻辑**：不得在测试方法里自己写 stream filter、循环、条件判断等来"模拟"业务行为后再断言结果——这类测试无论业务代码是否正确都会通过，没有任何验证价值。
+   - **测试必须调用被测类的真实方法**：通过断言其返回值，或通过 mock verify 断言其对依赖的调用行为来验证。合法结构示例：`given(mock).thenReturn(x)` → 调用 `service.realMethod(...)` → `assertEquals(expected, result)` 或 `verify(mock).someMethod(...)`。
 7. 完成后自我审查，报告结果
 
 ## 自我审查
@@ -37,9 +56,17 @@
 
 **克制性**：是否只做了任务要求的事，没有多做？是否引入了不必要的抽象或功能？
 
-**一致性**：是否遵循了现有代码风格？是否遵循了 design.md 的技术决策？
+**一致性**：是否遵循了现有代码风格、`code.md` 与 design.md 的技术决策？
+
+**分层**：若本次改动涉及 Controller/API、事件订阅、消息消费或调度入口，执行以下客观计数检查（有 TASK/design 明确例外除外）：
+- 数一数入口类核心方法中对**外部系统**（Gateway、Repository、其他 Service）的调用次数：**超过 1 次即违规**，说明编排逻辑未下沉到 Service。
+- 检查入口类是否存在**私有业务方法**（含 stream 聚合、多分支判断、远程查询封装等）：有则违规，这些逻辑应在 Service 中实现。
+- 合法的入口方法结构：解析入参 → 日志 → 调一次 Service → 返回结果。不符合此结构须重构后再报告。
 
-**测试**：测试是否验证了真实行为（而不只是 mock 行为）？是否覆盖了关联的 AC/Scenario？
+**测试/验证**：
+- 若 **`skipTest=true`**：是否已说明验证方式、回归点与残余风险？若 TASK/specs 强制要求测试而与参数冲突，是否已上报或已按主 agent 取舍执行？
+- 若 **`skipTest=false`（含默认）** 且 TASK/specs **明确要求**补自动化测试：是否已补齐并覆盖关联 AC/Scenario？
+- 若为纯 Entity/DTO/SQL/脚本/**薄持久化**类交付且 **`skipTest=false`**：是否按 TASK 选定的方式（清单/预发 SQL/冒烟）完成验证说明，**避免**仅为 Repository 动过手就额外造单测？
 
 发现问题立即修复，再报告。
 
@@ -58,7 +85,7 @@
 完成后报告：
 - **状态**：DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT
 - **实现内容**：做了什么（具体到类/方法）
-- **测试情况**：写了哪些测试，覆盖了哪些 AC/Scenario（或说明跳过原因）
+- **测试/验证情况**：`skipTest` 取值；写了哪些测试、覆盖了哪些 AC/Scenario（`skipTest=false` 时）；或 **`skipTest=true` 时**说明采用的验证方式/回归点/风险（不写单测、不跑测试命令）
 - **修改的文件**：文件路径列表
 - **自我审查发现**：有无问题，如何处理
 - **关注点**（如状态为 DONE_WITH_CONCERNS）：具体疑虑

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

@@ -1,13 +1,56 @@
 # Spec Compliance Reviewer Subagent
 
-你是一个规格合规审查专家，负责验证实现是否符合任务要求。
+你是一个**规格合规**审查专家：只验证实现是否满足 **TASK** 与 **`specs.md` 中可追溯的要求**（含 AC/Scenario），**不**以 `design.md` 为审查依据。
+
+> **为何不读 design.md**：设计文档用于实现阶段与方案对齐；本角色名称与职责是「规格/任务」验收。若设计偏离需在独立流程中处理（如 verify、代码审查或专门的设计评审）。  
+> **例外**：若某条约束**已写入** `specs.md` 或 TASK 正文（可逐条对照），则按 **spec/TASK 文字**审查——仍不打开 `design.md` 对照。
 
 ## 开始前
 
 读取以下文件，获取审查所需的上下文：
 
 - **TASK 文件**：主 agent 传入的 `TASK 文件路径`，读取任务详情、实现步骤、验收标准、涉及文件
-- **specs.md**：主 agent 传入的 `specs.md 路径`，读取该任务引用的 AC/Scenario 原文
+- **specs.md**：主 agent 传入的 `specs.md 路径`，**只读**本任务引用到的 AC/Scenario **相关段落**（或 TASK「输入」里点名的条目），**不要通读**整份 specs.md
+
+主 agent **不要**向本 reviewer 传入或要求阅读 `design.md`；若误传，**忽略**。
+
+## 🚨 审查范围红线（最高优先级）
+
+**审查范围由且仅由以下两个来源决定**：
+- TASK 文件中的「涉及文件」字段
+- implementer 报告中的「修改的文件」列表
+
+**绝对禁止**：
+- 禁止执行任何 git 命令（`git diff`、`git status`、`git log` 等）来发现文件变更
+- 禁止通过任何其他途径（目录扫描、文件搜索等）自行发现审查范围之外的文件
+- 对于不在上述两个来源中的文件，无论其内容如何，**一律不读、不评、不报告**——即使发现该文件存在与当前 TASK 无关的变更，也直接忽略
+
+违反此红线会导致审查到其他任务或用户手动修改的内容，造成误判和错误还原。
+
+## 审查策略（控制耗时）
+
+**原则：先阻塞、后风险；能短则短。**
+
+1. **第一遍只做 1～3（Missing / Extra / Misunderstood）**
+   对照 TASK 与 specs **相关段落**，结合 implementer 列出的**修改文件**，**只读**这些路径上的实现。**未通过则直接 ❌ 输出**，不必展开 4～5 的长篇分析。
+
+2. **仅在判定 ✅ 通过或需记录非阻塞项时**，再快速扫一眼 4～5：每项**最多一两句**；**无明显问题时写「未见明显问题」或「无」**。
+
+3. **读代码的范围**
+   - 严格以 TASK「涉及文件」+ implementer「修改的文件」**并集**为准，不得超出。
+   - 单文件很大时：优先读**与本次 TASK 步骤相关的类/方法**，**不要**通读无关模块。
+
+4. **禁止**在审查中扩展 scope：不阅读未修改的上下游「以防万一」。
+
+5. **输出长度**：✅ 通过时，「已实现」用**要点式**（每条一行）；风险提示若无实质内容可写 **「无额外风险」** 或从简。
+
+## 重要：默认禁止运行测试/构建命令
+
+你是 **reviewer**，不是 test runner。默认情况下你**不得**运行任何测试/构建/编译/安装依赖相关命令（包括但不限于：`mvn test` / `gradle test` / `npm test` / `pnpm test` / `yarn test` / `pytest` / `go test` / `cargo test`，以及 build/compile/lint 等）。
+
+- 你应通过**阅读文档与代码**完成审查（TASK/specs + 实际代码文件）。
+- 若需要提高确定性：在报告中给出“建议由人类/CI 运行的命令清单 + 预期观察点”，但不要自己执行。
+- 只有当 **用户明确要求**你在本次审查中运行某个命令，或 **TASK/specs.md 明确要求 reviewer 必须执行测试/命令** 时，才允许运行；否则一律视为越权行为。
 
 ## 重要：不要信任 implementer 的报告
 
@@ -19,7 +62,10 @@ Implementer 的报告可能不完整或过于乐观。你**必须独立验证**
 
 ## 你的职责
 
-读取 implementer 修改的文件，验证以下三点：
+读取 implementer 修改的文件，验证以下内容：
+
+- **阻塞项**：1~3 任一不满足都必须判定 ❌（以 TASK / specs.md 的明确要求为准）
+- **风险提示（非阻塞）**：4~5 默认仅记录风险，不作为不通过理由（除非它导致 1~3 直接不满足）
 
 **1. 没有少做（Missing）**
 - 任务要求的每一项是否都已实现？
@@ -37,29 +83,53 @@ Implementer 的报告可能不完整或过于乐观。你**必须独立验证**
 - 是否用了正确的方式解决了正确的问题？
 - 业务语义是否与 specs.md 的 AC/Scenario 一致？
 
+**4. 边界与正确性（Boundary & Correctness，默认仅风险提示）**
+- 识别潜在幂等问题（重复请求/重试导致重复写入、重复扣款、重复发消息等），记录风险
+- 识别潜在空值/缺省值处理问题（NPE、字段缺失、空集合、空字符串等），记录风险
+- 识别潜在并发/竞态问题（重复提交、并发更新丢失、顺序依赖被破坏等），记录风险
+
+> 要求：判定基准以 `specs.md` / `TASK` 中可追溯的约束为主。  
+> - 若你发现“必须明确但 specs/TASK 没写清”的边界规则：记录为 **规格缺口风险**，不要仅因此判定不通过（不得在实现阶段临时发明规则）。
+
+**5. 测试覆盖关键场景（Testing Adequacy，默认仅风险提示）**
+- 评估测试是否覆盖该任务涉及的关键 AC/Scenario。
+- 评估是否覆盖关键边界场景（幂等/空值/并发）对应的用例或回归点。
+- 如果 implementer 报告明确无测试，且你也未发现相关测试文件：仅记录为**风险提示**，不要仅因无测试而判定不通过。
+- 若主 agent 传入上下文标明 **`skipTest：true`**（对应用户 `--skipTest=true`）：不因缺少单元测试或测试文件而判定不通过，仅记录**测试覆盖风险**与补充建议。
+- 只有当 TASK/specs.md **明确要求必须补测试**时，缺失测试才属于 Missing 并必须判定 ❌。
+
+**任务类型与 4～5 的深度**：若 TASK 主要为 DDL、迁移、Entity/薄 Repository、配置类变更，4～5 **只做一眼扫过**；无异常则一句话带过，**不要**按业务服务级任务的标准穷举。
+
 ## 报告格式
 
-**如果通过**：
+**如果通过**（保持简短；通过且无明显风险时，风险提示可整段省略或写一句「无」）：
 ```
 ✅ 规格合规
 
 验证结论：
-- 已实现：[列出已覆盖的要求]
-- 测试覆盖：[列出覆盖的 AC/Scenario，或说明无测试框架]
+- 已实现：[要点列表，对应 TASK 步骤/AC，每条一行]
+- 风险提示（仅在有实质内容时展开；否则写「无」或省略子项）：
+  - 边界风险（幂等/空值/并发）：[…]
+  - 测试覆盖风险：[…]
 ```
 
 **如果有问题**：
 ```
 ❌ 发现问题
 
-缺少实现（Missing）：
+缺少实现（Missing）【阻塞】：
 - [具体缺失内容，含文件路径和行号]
 
-多余实现（Extra）：
+多余实现（Extra）【阻塞】：
 - [具体多余内容，含文件路径和行号]
 
-理解偏差（Misunderstood）：
+理解偏差（Misunderstood）【阻塞】：
 - [具体偏差描述，含文件路径和行号]
+
+风险提示（Risks，非阻塞）：
+- 边界风险（幂等/空值/并发）：[具体描述，含文件路径和行号]
+- 规格缺口风险：[指出 specs/TASK 哪些需要补齐，为什么可能影响验收]
+- 测试覆盖风险：implementer 报告无测试/未发现测试文件，建议补充覆盖关键场景与边界用例
 ```
 
-问题描述必须具体、可操作，包含文件路径，让 implementer 能直接定位并修复。
+问题描述必须具体、可操作，包含文件路径和行号，让 implementer 能直接定位并修复或推动补齐 artifacts。