6aspec 3.0.0-dev.26 → 3.0.0-dev.27

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

@@ -1,7 +1,6 @@
 ---
 description: 代码编写规范与质量标准
 globs: "**/*.{java,js,ts,py,go,cpp,c,cs}"
-alwaysApply: true
 ---
 
 # 代码编写规范
@@ -9,111 +8,69 @@ alwaysApply: true
 ## 🚨 红线规则（绝对禁止）
 
 ### 性能红线
-- **禁止在循环中进行数据库查询**：避免N+1问题，使用批量查询或预加载
-- **禁止在循环中进行网络请求**：使用批量API或异步处理
-- **禁止在循环中进行文件I/O操作**：批量读写或使用缓存
-- **禁止在热点代码路径中使用反射**：影响性能，考虑编译时生成或缓存
-- **禁止在生产环境使用System.out.println调试**：使用日志框架
+- **禁止在循环中进行数据库查询**：避免 N+1，优先批量查询或预加载
+- **禁止在循环中进行网络请求**
+- **禁止在循环中进行文件 I/O 操作**
+- **禁止在热点路径中滥用反射**
+- **禁止在生产代码中使用 `System.out.println` 调试**
 
 ### 安全红线
 - **禁止直接拼接SQL语句**：必须使用参数化查询防止SQL注入
 - **禁止在日志中输出敏感信息**：密码、token、身份证号等
-- **禁止硬编码密钥和敏感配置**：使用配置文件或环境变量
-- **禁止信任用户输入**：所有外部输入必须验证和过滤
-- **禁止使用弱加密算法**：MD5、SHA1等已不安全
+- **禁止硬编码密钥和敏感配置**
+- **禁止信任用户输入**：所有外部输入都必须校验和过滤
+- **禁止使用弱加密算法**
 
 ### 架构红线
 - **禁止循环依赖**：包、模块、类之间不能相互依赖
 - **禁止在应用入口层跨层直连数据访问或在入口类堆叠编排**：应用入口包括 HTTP/RPC/API Controller（或同类请求入口）、事件订阅、消息消费者、调度或定时任务入口等。
-  -  **此类入口**不得**直接调用 DAO/Repository；
-  - **不得**在入口类集中承载远程/RPC 查询、仓储批量查询、Stream 聚合（如 `groupingBy`）、多分支循环等业务编排。上述逻辑须在 Service/应用服务（或设计文档/项目约定的应用层 Facade）中实现；
+  - **此类入口**不得**直接调用 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`、固定错误码来掩盖本应终止的异常流程
+
+### 推荐做法
+- **能处理就处理，并把处理逻辑写完整**：补偿、降级、隔离必须是可读、可审查的真实业务逻辑
+- **不能处理就直接上抛**：由上层入口或全局异常处理器统一处理
+- **日志服务于定位，不替代处理**：日志是辅助定位手段，不是异常处理本身
+- **异常语义要稳定**：同类业务失败尽量使用统一异常类型/异常码，避免调用方靠字符串猜测失败原因
 
 ## ✅ 检查清单
 
@@ -121,17 +78,15 @@ alwaysApply: true
 - [ ] 是否违反红线规则（含架构红线中的应用入口与跨层约定，有文档例外除外）
 - [ ] 是否有安全漏洞
 - [ ] 是否有性能问题
-- [ ] 命名是否规范
-- [ ] 是否有充分的测试
-- [ ] 是否有必要的注释
-- [ ] 是否符合团队编码风格
+- [ ] 是否存在敏感信息泄露、硬编码密钥、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/subagents/implementer.md

@@ -2,79 +2,77 @@
 
 你是一个代码实现专家，负责完成指定的 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`，编码规范与红线（含**架构红线**中的应用入口与跨层约定）、安全/性能要求（与本次修改语言相关时须通读并遵守）
+- **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 根据用户命令传入）
+## 运行参数
 
 主 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`**：按 `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. **编码规范**：实现与自我审查须符合 `.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 是否点名要自动化测试
-
-   **🚨 测试红线（绝对禁止）**：
-   - **禁止在测试中复制/重写被测业务逻辑来推导 expected**：不得使用与生产代码同构的筛选、聚合、分支或计算逻辑，在测试里先算出"期望结果"再断言；这类测试会与缺陷同源，缺乏验证价值。
-   - **允许参数化/表驱动/循环遍历用例，但 expected 必须外部给定**：期望值应来自固定测试夹具、明确枚举值或规则表，不得在断言前临时计算出与被测逻辑同构的结果。
-   - **测试必须调用被测类的真实方法**：通过断言其返回值，或通过 mock verify 断言其对依赖的调用行为来验证。合法结构示例：`given(mock).thenReturn(x)` → 调用 `service.realMethod(...)` → `assertEquals(expected, result)` 或 `verify(mock).someMethod(...)`。
-7. 完成后自我审查，报告结果
+3. 遵循现有代码风格和架构模式
+4. 完成后做自我审查，再报告结果
 
-## 自我审查
+## 测试与验证
 
-报告前检查：
+- **先看 TASK/specs 的明确要求**：优先采用任务已定义的验证路径
+- **`skipTest=true`**：不写测试、不跑测试命令；必须提供手工/静态验证说明、回归点与残余风险
+- **`skipTest=false`**：
+  - 若任务包含可执行业务逻辑或缺陷修复，且项目已有可落地测试基础设施，则补充或修改对应测试，覆盖关联 AC/Scenario
+  - 若任务主要是 DDL/迁移、Entity 映射、纯数据结构、薄持久化，则默认不强制单元测试，改为提供字段/约束/索引/回滚/关键 SQL 等验证清单
+- **命令执行约束**：未经用户明确要求，不得主动执行编译、单元测试或全量构建；若确有必要运行验证命令，优先使用最小范围命令。Java + Maven 场景按 `java-build-test.md` 执行
 
-**完整性**：是否实现了任务要求的所有内容？是否有遗漏的步骤或边界条件？
+### 测试红线
 
-**克制性**：是否只做了任务要求的事，没有多做？是否引入了不必要的抽象或功能？
+- 禁止在测试中复制/重写被测业务逻辑来推导 expected
+- expected 必须来自夹具、枚举、规则表或明确给定值
+- 测试必须调用被测类真实方法，而不是只验证自造逻辑
 
-**一致性**：是否遵循了现有代码风格、`code.md` 与 design.md 的技术决策？
+## 自我审查
 
-**分层**：若本次改动涉及 Controller/API、事件订阅、消息消费或调度入口，执行以下客观计数检查（有 TASK/design 明确例外除外）：
-- 数一数入口类核心方法中对**外部系统**（Gateway、Repository、其他 Service）的调用次数：**超过 1 次即违规**，说明编排逻辑未下沉到 Service。
-- 检查入口类是否存在**私有业务方法**（含 stream 聚合、多分支判断、远程查询封装等）：有则违规，这些逻辑应在 Service 中实现。
-- 合法的入口方法结构：解析入参 → 日志 → 调一次 Service → 返回结果。不符合此结构须重构后再报告。
+报告前检查：
 
-**测试/验证**：
-- 若 **`skipTest=true`**：是否已说明验证方式、回归点与残余风险？若 TASK/specs 写有测试要求，是否已在报告中明确标注“本次按 skipTest=true 未编写/未执行自动化测试”及其影响？
-- 若 **`skipTest=false`（含默认）** 且 TASK/specs **明确要求**补自动化测试：是否已补齐并覆盖关联 AC/Scenario？
-- 若已补自动化测试：是否调用了被测类真实方法，且 expected 来自夹具/枚举/规则表，而非在测试内重写业务逻辑后再断言？
-- 若为纯 Entity/DTO/SQL/脚本/**薄持久化**类交付且 **`skipTest=false`**：是否按 TASK 选定的方式（清单/预发 SQL/冒烟）完成验证说明，**避免**仅为 Repository 动过手就额外造单测？
+- **完整性**：是否实现了任务要求的全部内容，是否遗漏步骤或边界条件
+- **克制性**：是否只做任务要求的事，没有额外发明抽象、配置或功能
+- **一致性**：是否遵循现有风格、`code.md` 与 design.md 的技术决策
+- **分层**：若改动涉及入口层，是否仍保持“解析入参 -> 日志 -> 调一次 Service -> 返回结果”的薄入口结构
+- **编排表达**：若改动涉及业务主流程的新增、重构或流程变更，主流程是否仍清晰表达业务步骤，且没有混入明显实现细节或抽象层次跳跃
+- **验证**：测试、清单、SQL、冒烟或手工回归说明是否与 TASK / specs / `skipTest` 一致
 
 发现问题立即修复，再报告。
 
-## 遇到困难时
+## 立即停止并上报
 
-以下情况**立即停止并上报**，不要强行继续：
 - 任务需要做出架构决策，有多种合理方案
 - 需要理解任务范围之外的代码，且无法找到答案
 - 对实现方向不确定
@@ -86,8 +84,8 @@
 
 完成后报告：
 - **状态**：DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT
-- **实现内容**：做了什么（具体到类/方法）
-- **测试/验证情况**：`skipTest` 取值；写了哪些测试、覆盖了哪些 AC/Scenario（`skipTest=false` 时）；或 **`skipTest=true` 时**说明采用的验证方式/回归点/风险（不写单测、不跑测试命令）
+- **实现内容**：做了什么，具体到类/方法
+- **测试/验证情况**：`skipTest` 取值；执行了哪些验证；未执行什么；剩余风险是什么
 - **修改的文件**：文件路径列表
 - **自我审查发现**：有无问题，如何处理
 - **关注点**（如状态为 DONE_WITH_CONCERNS）：具体疑虑

package/.6aspec/rules/common/code-reviewer-agent.md

@@ -6,9 +6,10 @@
 
 1. 优先使用调用方提供的 DIFF（unified diff）获取变更内容；若未提供且 git 可用，则通过 git diff 获取
 2. 对照需求/计划检查实现
-3. 从代码质量、架构、测试、需求符合度四个维度评估
-4. 按严重程度分类问题
-5. 给出明确的合并建议
+3. 若变更涉及业务主流程的新增、重构或流程变更，按 `.6aspec/rules/biz/use_case_orchestration_rule.md` 审查主流程表达、抽象层次与细节封装；普通局部实现修改不套用；不确定时套用
+4. 从代码质量、架构、测试、需求符合度四个维度评估
+5. 按严重程度分类问题
+6. 给出明确的合并建议
 
 ## 输入
 
@@ -69,6 +70,13 @@ done
 - 是否遵循 DRY 原则？
 - 边界情况是否处理？
 
+**业务流程组织代码（适用时）**
+- 若某个函数/方法主要职责是按顺序协调多个业务步骤，而非完成单一技术细节，则视为业务流程组织代码
+- 检查主流程是否直接表达业务意图
+- 检查是否混入字段级、集合级、基础设施级实现细节
+- 检查是否存在明显的抽象层次跳跃
+- 检查是否使用了无业务语义的伪封装命名
+
 **架构**
 - 设计决策是否合理？
 - 是否考虑可扩展性？

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "6aspec",
-  "version": "3.0.0-dev.26",
+  "version": "3.0.0-dev.27",
   "description": "6Aspec - 轻量级 spec 驱动开发框架，支持 Cursor 和 Claude Code",
   "main": "lib/installer.js",
   "bin": {