6aspec 3.0.0-dev.3 → 3.0.0-dev.31

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

@@ -1,7 +1,6 @@
 ---
 description: 代码编写规范与质量标准
 globs: "**/*.{java,js,ts,py,go,cpp,c,cs}"
-alwaysApply: true
 ---
 
 # 代码编写规范
@@ -9,125 +8,85 @@ alwaysApply: true
 ## 🚨 红线规则（绝对禁止）
 
 ### 性能红线
-- **禁止在循环中进行数据库查询**：避免N+1问题，使用批量查询或预加载
-- **禁止在循环中进行网络请求**：使用批量API或异步处理
-- **禁止在循环中进行文件I/O操作**：批量读写或使用缓存
-- **禁止在热点代码路径中使用反射**：影响性能，考虑编译时生成或缓存
-- **禁止在生产环境使用System.out.println调试**：使用日志框架
+- **禁止在循环中进行数据库查询**：避免 N+1，优先批量查询或预加载
+- **禁止在循环中进行网络请求**
+- **禁止在循环中进行文件 I/O 操作**
+- **禁止在热点路径中滥用反射**
+- **禁止在生产代码中使用 `System.out.println` 调试**
 
 ### 安全红线
 - **禁止直接拼接SQL语句**：必须使用参数化查询防止SQL注入
 - **禁止在日志中输出敏感信息**：密码、token、身份证号等
-- **禁止硬编码密钥和敏感配置**：使用配置文件或环境变量
-- **禁止信任用户输入**：所有外部输入必须验证和过滤
-- **禁止使用弱加密算法**：MD5、SHA1等已不安全
+- **禁止硬编码密钥和敏感配置**
+- **禁止信任用户输入**：所有外部输入都必须校验和过滤
+- **禁止使用弱加密算法**
 
 ### 架构红线
 - **禁止循环依赖**：包、模块、类之间不能相互依赖
-- **禁止跨层直接调用**：Controller不能直接调用DAO
+- **禁止在应用入口层跨层直连数据访问或在入口类堆叠编排**：应用入口包括 HTTP/RPC/API Controller（或同类请求入口）、事件订阅、消息消费者、调度或定时任务入口等。
+  - **此类入口**不得**直接调用 DAO/Repository**
+  - **不得**在入口类集中承载远程/RPC 查询、仓储批量查询、Stream 聚合（如 `groupingBy`）、多分支循环等业务编排。上述逻辑须在 Service/应用服务（或设计文档/项目约定的应用层 Facade）中实现
+  - 入口仅允许必要校验、日志及对上述服务的委托。
+  - **例外**：需求/TASK/设计说明明确要求与某存量入口类保持同一写法时，从其约定。
 - **禁止在实体类中包含业务逻辑**：保持实体类的纯净性
-- **禁止在静态代码块中进行复杂操作**：可能导致类加载问题
-- **禁止捕获异常后不处理**：空catch块是代码异味
+- **禁止空 catch**：空 catch 块是代码异味
+- **禁止 catch 后不处理**：捕获异常后不能仅吞掉异常或仅做无意义兜底
+- **禁止 catch 后只打日志再原样 rethrow**：如果只是补一条重复日志却不改变语义、不补充上下文、不执行补偿/隔离/降级，则不应捕获
 
-## 🔒 安全规范
+## 📝 基础编码要求
 
-### 输入验证
-- **参数校验**：所有API入参必须校验
-- **数据过滤**：防止XSS、SQL注入等攻击
-- **权限检查**：每个操作都要验证用户权限
-- **敏感数据处理**：加密存储，脱敏展示
-
-### 日志安全
-- **敏感信息脱敏**：密码、token等不能明文记录
-- **操作审计**：关键操作必须记录审计日志
-- **错误信息**：不暴露系统内部信息给用户
-
-## ⚡ 性能优化
-
-### 数据库优化
-- **索引使用**：查询字段必须有合适的索引
-- **批量操作**：使用批量插入/更新减少数据库交互
-- **连接池管理**：合理配置数据库连接池
-- **查询优化**：避免全表扫描，使用分页查询
-
-### 缓存策略
-- **多级缓存**：本地缓存 + 分布式缓存
-- **缓存更新**：及时更新或失效过期数据
-- **缓存穿透**：防止恶意查询不存在的数据
-- **缓存雪崩**：设置随机过期时间
-
-### 算法复杂度
-- **时间复杂度**：优先选择O(1)、O(log n)算法
-- **空间复杂度**：避免不必要的内存占用
-- **数据结构选择**：根据使用场景选择合适的数据结构
-
-## 📝 编码规范
-
-### 命名规范
 - **类名**：大驼峰命名，名词，表达清晰意图
 - **方法名**：小驼峰命名，动词开头，表达具体行为
 - **变量名**：小驼峰命名，避免缩写，见名知意
 - **常量名**：全大写，下划线分隔
 - **包名**：全小写，层次清晰
-
-### 代码结构
-- **包结构**：按功能模块划分，层次清晰
-- **类大小**：单个类不超过500行
-- **方法长度**：单个方法不超过50行
-- **参数个数**：方法参数不超过5个
-- **嵌套层次**：代码嵌套不超过4层
-
-### 注释规范
-- **类注释**：说明类的职责和使用场景
-- **方法注释**：说明参数、返回值、异常
-- **复杂逻辑注释**：解释为什么这样做
-- **TODO注释**：标记待完成的工作
-
-## 🏗️ 设计原则
-
-### SOLID原则
-- **单一职责原则**：一个类只负责一个功能领域
-- **开闭原则**：对扩展开放，对修改关闭
-- **里氏替换原则**：子类可以替换父类
-- **接口隔离原则**：使用多个专门的接口
-- **依赖倒置原则**：依赖抽象而不是具体实现
-
-### 其他原则
-- **DRY原则**：不重复自己，提取公共代码
-- **KISS原则**：保持简单，避免过度设计
-- **YAGNI原则**：你不会需要它，不做过度设计
-- **最少知识原则**：对象应该对其他对象有最少的了解
-
-## 🔄 重构策略
-
-### 重构时机
-- **新功能开发时**：同步重构相关代码
-- **Bug修复时**：改善代码结构
-- **代码审查时**：发现问题及时重构
-- **性能优化时**：重构性能瓶颈代码
-
-### 重构原则
-- **小步快跑**：每次重构范围要小
-- **测试保护**：重构前确保测试覆盖
-- **持续集成**：频繁提交，及时发现问题
-- **技术债务管理**：定期评估和偿还
+- **外部输入必须校验**：接口入参、消息体、任务参数、外部回调数据都一样
+- **敏感信息必须脱敏**：日志、错误消息、审计信息都不能泄露敏感值
+- **关键操作要有日志或审计**：日志用于定位和追踪，不用于替代业务处理
+- **复杂逻辑必须解释“为什么”**：只在必要处写注释，不写废话注释
+- **代码应优先保持局部可读性**：避免不必要的大规模重构；若存量代码本身较大或较乱，优先在当前任务范围内做最小修正
+
+## ⚠️ 异常处理规范
+
+### 基本原则
+- **流程终止默认使用异常表达，不使用特殊 return 值表达失败**：业务校验失败、状态不满足、关键依赖失败、流程无法继续等场景，默认通过抛出异常终止流程，而不是返回 `null`、`false`、错误码对象或其他“看起来成功但需要调用方自行猜测”的特殊值
+- **业务层不要为了“显得处理过”而捕获异常**：如果当前层无法产生明确业务价值，直接上抛，由更上层统一处理
+- **入口层负责异常收口**：Controller/API 入口、事件订阅、消息消费、后台任务、定时任务等入口层负责按框架约定做异常收口、日志、失败状态记录或统一错误响应；业务层原则上不做兜底式 catch
+
+### 允许 catch 的场景
+- **补偿**：捕获后执行回滚、撤销、状态修正、反向操作等补偿逻辑
+- **降级**：捕获后切换备选方案、默认策略或兜底结果，且业务语义明确
+- **隔离**：捕获后终止当前子流程、记录失败项、避免影响批次中的其他项
+- **异常语义转换**：将底层技术异常转换为明确的业务异常，并保留必要上下文
+- **补充上下文后再抛出**：为了补充关键业务标识、参数、上下文信息而包装异常后继续上抛
+
+### 禁止的写法
+- **禁止空 catch**
+- **禁止 catch 后只记录日志然后继续主流程**
+- **禁止 catch 后只打日志再 `throw e`**：如果既没有补偿/降级/隔离，也没有补充上下文或转换异常语义，则应直接让异常自然上抛
+- **禁止用 return 代替异常吞掉失败**：例如返回 `null`、空集合、`false`、固定错误码来掩盖本应终止的异常流程
+
+### 推荐做法
+- **能处理就处理，并把处理逻辑写完整**：补偿、降级、隔离必须是可读、可审查的真实业务逻辑
+- **不能处理就直接上抛**：由上层入口或全局异常处理器统一处理
+- **日志服务于定位，不替代处理**：日志是辅助定位手段，不是异常处理本身
+- **异常语义要稳定**：同类业务失败尽量使用统一异常类型/异常码，避免调用方靠字符串猜测失败原因
 
 ## ✅ 检查清单
 
 ### 代码提交前检查
-- [ ] 是否违反红线规则
+- [ ] 是否违反红线规则（含架构红线中的应用入口与跨层约定，有文档例外除外）
 - [ ] 是否有安全漏洞
 - [ ] 是否有性能问题
-- [ ] 命名是否规范
-- [ ] 是否有充分的测试
-- [ ] 是否有必要的注释
-- [ ] 是否符合团队编码风格
+- [ ] 是否存在敏感信息泄露、硬编码密钥、SQL 拼接等问题
+- [ ] 是否有必要的验证说明、测试或回归路径
+- [ ] 是否有必要的注释和日志
 
 ### 代码审查检查
 - [ ] 业务逻辑是否正确
 - [ ] 异常处理是否完善
+- [ ] 是否使用异常而非特殊 return 值表达流程终止
 - [ ] 边界条件是否考虑
-- [ ] 是否有代码重复
-- [ ] 是否符合设计原则
-- [ ] 是否有技术债务
-- [ ] 文档是否需要更新
+- [ ] 新增/改动的 Controller/API 入口、订阅、消费者、调度入口是否违反架构红线（薄入口、不直连 DAO、委托 Service）
+- [ ] 是否存在明显的重复、过度实现或不必要抽象
+- [ ] 文档是否需要更新

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

@@ -29,6 +29,7 @@ alwaysApply: false
 ### 1.1 必须加载（所有类型）
 1. `.6aspec/rules/biz/code.md` - 代码编写规范
 2. `.6aspec/rules/biz/project-structure.md` - 项目结构规范
+3. 当本次改动涉及业务主流程的新增、重构或流程变更时，加载 `.6aspec/rules/biz/use_case_orchestration_rule.md` - 业务流程组织代码约束；普通局部实现修改不加载；不确定时加载
 
 ### 1.2 根据类型加载
 - **API接口** → `.6aspec/rules/biz/api_rule.md`
@@ -50,6 +51,12 @@ alwaysApply: false
 ### 3.1 代码规范检查
 使用 `.6aspec/rules/biz/code.md` 中的"检查清单"进行自我验证。
 
+若本次改动涉及业务主流程的新增、重构或流程变更，还需额外检查：
+- [ ] 主流程是否直接表达业务步骤
+- [ ] 是否存在不同抽象层次混写
+- [ ] 是否将明显实现细节留在主流程中
+- [ ] 方法命名是否揭示业务语义而非泛化技术动作
+
 **红线规则（零容忍）**：
 - [ ] 循环中的数据库查询、网络请求、文件I/O操作
 - [ ] SQL字符串拼接、敏感信息硬编码、弱加密算法使用

package/.6aspec/rules/biz/java-build-test.md

@@ -0,0 +1,28 @@
+# Java / Maven 构建与测试命令规范
+
+适用于 **Java + Maven** 项目在需要执行编译验证或单元测试时的命令选择。
+
+## 适用前提
+
+- 仅在实现规则允许执行编译/测试命令时使用
+- 仅适用于 Maven 项目
+- 若 TASK、specs、项目 README 或模块脚本已定义更具体命令，优先从其约定
+
+## 推荐命令模式
+
+### 单元测试（指定测试类）
+
+```bash
+mvn -pl <module-path> -Dtest=<TestClassName> -DfailIfNoTests=false -am -o test
+```
+
+### 编译验证（跳过测试）
+
+```bash
+mvn -pl <module-path> -Dmaven.test.skip=true -am -o compile
+```
+### ⚠️ 注意事项
+- 所有 Maven 命令**必须在项目根目录**下执行
+- 测试类名使用**简单类名**，不需要完整包路径
+- 若本地仓库缺少依赖导致 `-o` 失败，先执行一次联网构建缓存依赖后恢复离线模式
+- 不得擅自修改 `pom.xml` 依赖版本

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

@@ -0,0 +1,63 @@
+---
+description: 业务流程组织代码约束
+alwaysApply: false
+---
+
+# Use Case Orchestration Rule
+
+## 何时应用
+
+本次改动**新增、重构或修改**了某个方法，且该方法的主要职责是**按顺序协调多个业务步骤**（如：校验、状态流转、持久化、事件发布等），则必须应用本规则。
+
+只改工具方法、DTO/Entity/Repository 局部实现、命名注释等，不适用。
+
+## 核心禁令
+
+**禁止在主流程中展开实现细节**，包括：字段逐项赋值、集合转换、复杂条件分支、对象构建细节、Repository 结果加工。
+
+**禁止用注释描述步骤在做什么**，这是方法名不够清晰的信号，应改方法名。
+
+```java
+// 禁止：注释和方法名说同一件事
+// 校验状态
+this.checkStatus(find, changeStatusDTO.getStatus());
+
+// 禁止：注释在弥补方法名语义不足
+// 当状态流转是逆向流转时，需要还原最近一次的业务信息
+this.handleReverse(find, record.getAfterRoomStatus(), transitionResult);
+```
+
+**禁止使用无业务语义的方法名**：`handle`、`process`、`doChange`、`updateData` 等。
+
+## 合格主流程示例
+
+```java
+public void changeStatus(ChangeStatusDTO changeStatusDTO) {
+    RoomStatusEntity roomStatus = loadRoomStatus(changeStatusDTO.getRoomId());
+    int statusBeforeTransition = roomStatus.getStatus();
+    TransitionResult transition = validateRoomStatusTransition(roomStatus, changeStatusDTO.getStatus());
+    applyStatusChange(roomStatus, changeStatusDTO);
+    RoomStatusRecordEntity record = buildStatusChangeRecord(roomStatus, statusBeforeTransition, transition);
+    restoreLatestBusinessContext(roomStatus, record, transition);
+    handleSpecialStatus(roomStatus);
+    List<RoomStatusRecordEntity> invalidRecords = buildInvalidRecords(record, changeStatusDTO);
+    roomStatusRepository.update(roomStatus, record, invalidRecords);
+    publishStatusChangedEvent(roomStatus, record);
+}
+```
+
+读主流程不看实现，即可理解业务顺序。每个方法名表达一个业务动作。
+
+## 允许的例外
+
+主流程中可保留：
+- 单行守卫判定：`if (null == roomStatus) throw new BusinessLogicException(...);`
+- 单行数据提取：`int statusBeforeTransition = roomStatus.getStatus();`
+
+## 自检（输出前过一遍）
+
+- [ ] 只读主流程，不看实现，能否说清业务顺序
+- [ ] 主流程是否混入了字段级或基础设施级细节
+- [ ] 是否存在注释和方法名表达相同意思的情况
+- [ ] 方法名是否表达业务动作，而不是技术动作
+- [ ] 变量名是否使用业务语言（`roomStatus` 而非 `find`）

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

@@ -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_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_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/subagents/implementer.md

@@ -2,50 +2,81 @@
 
 你是一个代码实现专家，负责完成指定的 TASK。
 
-## 开始前
+**重要**：你只负责完成**这一个 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 路径`，读取代码结构摘要（如果存在）
+- **TASK 文件**：任务详情、实现步骤、验收标准、涉及文件
+- **specs.md**：该任务引用的 AC/Scenario
+- **design.md**：相关技术决策
+- **analysis.md**：现状分析和影响面背景（如果存在）
+- **explore-summary.md**：代码结构摘要（如果存在）
+- **code.md**：`.6aspec/rules/biz/code.md`，公共编码规范与红线
+- **use_case_orchestration_rule.md**：`.6aspec/rules/biz/use_case_orchestration_rule.md`，仅当改动涉及业务主流程的新增、重构或流程变更时读取；普通局部实现修改不读取；不确定时读取
+- **java-build-test.md**：`.6aspec/rules/biz/java-build-test.md`，仅当本任务涉及 **Java + Maven** 项目的编译或测试命令时读取
 
 如果你对任务要求、验收标准、实现策略或依赖关系有任何疑问，**现在就提出**，不要开始实现后再问。
 
-## 你的职责
+## 运行参数
+
+主 agent 应在派发本 subagent 时明确一行：`skipTest：true` 或 `skipTest：false`（与用户命令中的 `--skipTest=true` / `--skipTest=false` 一致）。**文档与实现只认带 `=true` / `=false` 的写法**；裸写 `--skipTest` 无赋值视为未规范输入，主 agent 应让用户改用 `=true` 或 `=false`。
+
+- **未传 `skipTest`**：按 `false` 处理
+- **`skipTest=true`**：最高优先级。不写单元测试，不执行任何测试命令；改为提供可审查的验证说明、回归点与残余风险
+
+## 核心执行原则
+
+1. **先理解再实现**：先读 TASK/specs/design，再动代码
+2. **不发明方案**：遵循 design.md 的技术决策；实现阶段不得自行改方案
+3. **最小改动**：只改任务需要的代码，不扩 scope
+4. **遵守公共规范**：实现与自审必须符合 `code.md`
+5. **涉及业务主流程时遵守编排规则**：若本次改动涉及业务主流程的新增、重构或流程变更，必须读取并遵守 `use_case_orchestration_rule.md`；普通局部实现修改不读取；不确定时读取
+6. **普通局部实现不强行套编排规则**：若只是修改单个工具函数、纯计算逻辑、DTO/Entity/Repository 局部实现、命名/注释/日志或未改变主流程结构的小修复，则不要为了套规则而过度拆分
+7. **入口保持薄**：Controller/API、事件订阅、消息消费、调度入口只做必要校验、日志和委托，不在入口层堆业务编排
+8. **业务层不做伪处理**：异常处理遵循 `code.md`；不要为了“显得处理过”而 catch
+9. **有疑问先问**：不要靠猜测完成任务
+
+## 实现流程
 
 确认没有疑问后：
 
 1. 读取 TASK 文件"涉及文件"中列出的源代码文件，理解现有实现
 2. 按"实现步骤"逐步执行，到类/方法级
-3. 遵循 design.md 的技术决策，**不在实现阶段发明新方案**
-4. 遵循现有代码风格和架构模式
-5. 检查红线规则（零容忍）：
-   - 循环中的数据库查询、网络请求、文件 I/O
-   - SQL 字符串拼接、敏感信息硬编码
-   - 空 catch 块、循环依赖、跨层直接调用
-6. 若项目有测试框架，补充/修改对应单元测试，覆盖任务关联的 AC/Scenario；若无测试框架则跳过
-7. 完成后自我审查，报告结果
+3. 遵循现有代码风格和架构模式
+4. 完成后做自我审查，再报告结果
 
-## 自我审查
+**停止条件**：完成当前 TASK 的实现步骤、自我审查和报告后，**立即停止**，不要执行其他 TASK。
 
-报告前检查：
+## 测试与验证
+
+- **先看 TASK/specs 的明确要求**：优先采用任务已定义的验证路径
+- **`skipTest=true`**：不写测试、不跑测试命令；必须提供手工/静态验证说明、回归点与残余风险
+- **`skipTest=false`**：
+  - 若任务包含可执行业务逻辑或缺陷修复，且项目已有可落地测试基础设施，则补充或修改对应测试，覆盖关联 AC/Scenario
+  - 若任务主要是 DDL/迁移、Entity 映射、纯数据结构、薄持久化，则默认不强制单元测试，改为提供字段/约束/索引/回滚/关键 SQL 等验证清单
+- **命令执行约束**：未经用户明确要求，不得主动执行编译、单元测试或全量构建；若确有必要运行验证命令，优先使用最小范围命令。Java + Maven 场景按 `java-build-test.md` 执行
+
+### 测试红线
 
-**完整性**：是否实现了任务要求的所有内容？是否有遗漏的步骤或边界条件？
+- 禁止在测试中复制/重写被测业务逻辑来推导 expected
+- expected 必须来自夹具、枚举、规则表或明确给定值
+- 测试必须调用被测类真实方法，而不是只验证自造逻辑
 
-**克制性**：是否只做了任务要求的事，没有多做？是否引入了不必要的抽象或功能？
+## 自我审查
 
-**一致性**：是否遵循了现有代码风格？是否遵循了 design.md 的技术决策？
+报告前检查：
 
-**测试**：测试是否验证了真实行为（而不只是 mock 行为）？是否覆盖了关联的 AC/Scenario？
+- **完整性**：是否实现了任务要求的全部内容，是否遗漏步骤或边界条件
+- **克制性**：是否只做任务要求的事，没有额外发明抽象、配置或功能
+- **一致性**：是否遵循现有风格、`code.md` 与 design.md 的技术决策
+- **分层**：若改动涉及入口层，是否仍保持“解析入参 -> 日志 -> 调一次 Service -> 返回结果”的薄入口结构
+- **编排表达**：若改动涉及业务主流程的新增、重构或流程变更，主流程是否仍清晰表达业务步骤，且没有混入明显实现细节或抽象层次跳跃
+- **验证**：测试、清单、SQL、冒烟或手工回归说明是否与 TASK / specs / `skipTest` 一致
 
 发现问题立即修复，再报告。
 
-## 遇到困难时
+## 立即停止并上报
 
-以下情况**立即停止并上报**，不要强行继续：
 - 任务需要做出架构决策，有多种合理方案
 - 需要理解任务范围之外的代码，且无法找到答案
 - 对实现方向不确定
@@ -57,12 +88,20 @@
 
 完成后报告：
 - **状态**：DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT
-- **实现内容**：做了什么（具体到类/方法）
-- **测试情况**：写了哪些测试，覆盖了哪些 AC/Scenario（或说明跳过原因）
+- **实现内容**：做了什么，具体到类/方法
+- **TASK 步骤映射**：TASK 中每个“实现步骤”分别落到了哪些类/方法；若某一步无需改代码，也要明确说明原因
+- **AC/Scenario 验证映射**：每条相关 AC/Scenario 分别通过什么实现或验证方式满足；若某条不适用，明确说明
+- **测试/验证情况**：`skipTest` 取值；执行了哪些验证；未执行什么；剩余风险是什么
 - **修改的文件**：文件路径列表
+- **已查看但未修改的文件**（如有）：文件路径列表，并说明为何无需修改
 - **自我审查发现**：有无问题，如何处理
 - **关注点**（如状态为 DONE_WITH_CONCERNS）：具体疑虑
 
 DONE_WITH_CONCERNS：完成了工作但有疑虑
 BLOCKED：无法完成任务
 NEEDS_CONTEXT：缺少必要信息
+
+**重要提醒**：
+- 你只完成这一个 TASK，不负责其他任务
+- 报告提交后立即停止，不要执行其他 TASK
+- 不要主动读取其他 TASK-*.md 文件