@modus-ai/modus 0.1.0 → 0.1.2

package/templates/rules/modus-design-brief/RULE.mdc

@@ -0,0 +1,127 @@
+---
+description: 进入代码开发前，必须生成或存在 design-brief（设计方案）内容。本规则定义 design-brief 的 9 节必填结构与质量断言，适用于所有代码生成场景（plan/spec/harness 落盘，vibe 内联上下文）。
+globs:
+  - "modus/plans/**/*.md"
+  - "modus/changes/**/*.md"
+  - "modus/plans/active/**/*.md"
+alwaysApply: false
+---
+
+# modus-design-brief 质量规范
+
+## 适用范围
+
+每次进行代码开发之前，必须先产出或内联生成一份 **design-brief**（设计方案）。
+- `plan` / `spec` / `harness` 模式：落盘为 `design-brief.md`，与其他产出物同目录
+- `vibe` 模式：以内联结构化文本块注入当前 LLM 上下文，不写文件
+
+---
+
+## design-brief 必填 9 节结构
+
+### 节 1：基本信息（`## 1. 基本信息`）
+
+必填字段：
+- 功能名称
+- 关联文档路径（proposal.md / 01-analysis.md / Story URL）
+- 生成时间（ISO 8601）
+- 模式（plan / spec / harness / vibe）
+
+### 节 2：业务意图摘要（`## 2. 业务意图摘要`）
+
+- 一句话描述核心业务价值，必须与需求分析中的「业务意图」字段一致
+- 不允许描述技术实现（此节只说 WHAT，不说 HOW）
+
+### 节 3：实体与数据模型（`## 3. 实体与数据模型`）
+
+**质量断言：**
+- 每个字段必须标注 Java/Go 类型（如 `BigDecimal`、`Long`、`String`），禁止只写字段名
+- 若有数据库变更，必须附 DDL 片段（`ALTER TABLE` / `CREATE TABLE`）
+- 枚举值必须列出所有成员，不允许只写「参考现有枚举」
+
+### 节 4：API / 接口合同（`## 4. API / 接口合同`）
+
+**质量断言：**
+- 方法签名必须包含完整包路径（如 `com.company.order.service.OrderService#batchApprove`）
+- 请求/响应对象必须列出每个字段及其类型，不允许只写「参考现有 VO」
+- 若为 HTTP 接口，必须标注 HTTP Method 和 URL 路径
+
+### 节 5：实现蓝图（`## 5. 实现蓝图`）
+
+**质量断言：**
+- 必须按层次展开：Data 层 → Service/Manager 层 → API/Facade 层
+- 每层至少指定 1 个具体类名和方法名，不允许只写「在 Service 层实现」
+- 引用的类名必须来自已有代码或业务 Skill 的 `key_files`（禁止凭空生造类名）
+- 事务边界必须明确标注（哪个方法上加 `@Transactional`）
+
+### 节 6：边界条件与异常处理（`## 6. 边界条件与异常处理`）
+
+**质量断言：**
+- 必须覆盖需求中所有 GIVEN/WHEN/THEN Scenario 的失败路径
+- 每个异常场景必须指定：触发条件 + 错误码 + 错误消息文本
+- 并发场景（同一资源被并发修改）必须说明锁策略
+
+### 节 7：代码生成提示（`## 7. 代码生成提示`）
+
+**质量断言：**
+- 可复用的现有工具类/基类/常量必须带完整类路径
+- 命名规范必须给出示例（如「Mapper 接口命名：`{Domain}Mapper`，示例 `OrderMapper`」）
+- 若项目有特殊框架约束（来自 constitution `key_patterns`），必须在此节复述
+
+### 节 8：禁止事项与已知坑（`## 8. 禁止事项与已知坑`）
+
+**质量断言：**
+- 必须列出 `modus/config.yaml` 的 `constitution.hard_rules` 中所有与本次相关的规则（逐条对应）
+- 必须列出涉及业务域 Skill 中所有 `[pitfall]` 条目
+- 每条禁止事项必须说明「若违反会导致什么问题」
+
+### 节 9：需求-任务追踪矩阵（`## 9. 需求-任务追踪矩阵`）
+
+必须以表格形式呈现：
+
+```markdown
+| 需求点 / Requirement | 对应 Sprint | 对应任务行 | 对应 Scenario |
+|---|---|---|---|
+| {需求描述} | Sprint N | tasks.md #N.M | Scenario: {名称} |
+```
+
+**质量断言：**
+- 每个需求点必须有且仅有一个对应任务行，不允许「N/A」
+- 每个 Scenario 必须出现在至少一行中
+- harness 模式下，此矩阵同时作为 SubAgent 02 的验收检查列表
+
+---
+
+## 整体质量门禁（所有模式适用）
+
+在生成 design-brief 内容后，执行以下自检：
+
+```
+□ 节 3 中所有字段带类型标注
+□ 节 4 中所有方法签名带包路径
+□ 节 5 中每层至少一个具体类名/方法名，且可在 Skill key_files 或现有代码中找到依据
+□ 节 6 中覆盖了所有 Scenario 的失败路径
+□ 节 8 中逐条对应了 constitution hard_rules
+□ 节 9 中每个需求点都有对应 Sprint 和 Scenario
+```
+
+若任一项未通过，在该节标注 `⚠️ 待补充: {原因}`，提醒开发者补全后再开始编码。
+
+---
+
+## vibe 模式内联格式
+
+vibe 模式下，design-brief 以如下标记包裹，注入到编码步骤之前：
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+[Design Brief — 内联设计方案，仅用于本次编码，不写文件]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+## 1. 基本信息
+...（9节完整内容）...
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+[End of Design Brief — 开始编码]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```

package/templates/rules/modus-workflow/RULE.mdc

@@ -0,0 +1,64 @@
+---
+description: Modus workflow conventions. Load this rule when the user runs any /modus:* command or asks about Modus commands, Skills, Harness, plan/spec/vibe workflow, knowledge-catalog, or business Skills.
+alwaysApply: false
+enabled: true
+---
+
+# Modus 工作流规范
+
+## 核心目录结构
+
+```
+.codebuddy/
+├── skills/
+│   ├── modus-init/SKILL.md          # /modus:init 执行规范
+│   ├── modus-vibe/SKILL.md          # /modus:vibe 执行规范
+│   ├── modus-plan/SKILL.md          # /modus:plan 执行规范
+│   ├── modus-spec/SKILL.md          # /modus:spec 执行规范
+│   ├── modus-harness/SKILL.md       # Harness 调度规范
+│   ├── modus-harness-0*-*/SKILL.md  # Harness SubAgent 规范
+│   ├── modus-team-conventions/      # 团队约定（Layer 0-T）
+│   ├── modus-tech-wiki/             # 技术知识（Layer 1）
+│   └── modus-biz-{domain}/         # 业务知识（Layer 2）
+└── agents/
+    └── modus-harness-0*.md          # Harness SubAgent 定义
+
+modus/
+├── config.yaml                      # 项目配置和 constitution
+├── knowledge-catalog.md             # 知识全景目录（Level 1 索引）
+├── specs/                           # 主规格库
+├── plans/
+│   ├── active/{story-id}/           # 进行中的 Harness 任务
+│   └── archive/                     # 已归档的计划
+├── changes/                         # /modus:spec 变更目录
+└── sessions/vibe-log.md             # /modus:vibe 会话日志
+```
+
+## 三级渐进加载原则
+
+每次 Modus 命令启动时：
+1. **Level 1（必须，~200 tokens）**：读 `modus/knowledge-catalog.md`
+2. **Level 2（按需，~3000 tokens/个）**：基于任务匹配，读对应 `modus-biz-*/SKILL.md`
+3. **Level 3（按需，无限制）**：执行任务时读 Skill 引用的实际代码文件
+
+不相关的 Skill 不加载，大幅降低 token 消耗。
+
+## 命令速查
+
+| 命令 | 场景 | 产出物 |
+|------|------|--------|
+| `/modus:init` | 首次初始化或重建知识库 | `.codebuddy/skills/modus-biz-*/SKILL.md` |
+| `/modus:vibe` | 日常编码（含业务上下文） | 代码 + `modus/sessions/vibe-log.md` |
+| `/modus:plan` | 功能规划 | `modus/plans/{name}/proposal+design+tasks.md` |
+| `/modus:spec` | 规范驱动开发 | `modus/changes/{name}/specs/{domain}/spec.md` |
+| `/modus:harness` | 全自动 Harness 流程 | `modus/plans/active/{story-id}/0*.md` |
+
+## Skill 知识状态
+
+| maturity | 含义 | 衰减规则 |
+|----------|------|---------|
+| `draft` | 新建，未经验证 | — |
+| `verified` | 已在 1 个工作流中验证 | 6 个月未引用 → draft |
+| `proven` | 已在 ≥2 个工作流中验证 | 12 个月未引用 → verified |
+
+`⚠️` 标注表示可能过时，以最新代码为准。

package/templates/skills/modus-design-brief/SKILL.md

@@ -0,0 +1,324 @@
+---
+name: modus-design-brief
+description: 在代码开发前生成结构化的设计方案（design-brief），将需求分析信息转化为 LLM 可直接消费的实现指南。由 modus-plan、modus-spec 内部调用（落盘为 design-brief.md），或由 modus-vibe 内联调用（注入上下文，不落盘）。触发条件：plan/spec/vibe Skill 内部 Step 5.5 调用，或用户直接运行 @modus-design-brief。
+allowed-tools: Read, Write, Glob, Bash
+disable: false
+---
+
+# modus-design-brief（设计方案生成）
+
+**调用方：** modus-plan / modus-spec（落盘）| modus-vibe（内联）  
+**输入：** 需求分析产出物（proposal.md 或 01-analysis.md）+ 业务 Skill + constitution  
+**产出物：** `design-brief.md`（落盘模式）或内联上下文块（vibe 模式）
+
+## 职责
+
+将需求分析阶段的「业务语言」翻译成代码开发阶段的「实现语言」，产出一份 LLM 可直接消费的设计方案。设计方案覆盖实体模型、接口合同、实现蓝图、边界处理、代码提示、禁止事项和需求追踪，确保代码生成时不需要再反复「猜测」项目规范。
+
+---
+
+## 执行流程
+
+### Step 1：加载上下文
+
+按优先级读取以下输入（调用方已传入的直接使用，未传入的自行读取）：
+
+**需求分析文档（必读，二选一）：**
+- harness 模式：读取 `modus/plans/active/{story-id}/01-analysis.md`
+- plan/spec/vibe 模式：读取调用方目录下的 `proposal.md`，若存在同级 `specs/*/spec.md` 也一并读取
+
+**项目宪法（必读）：**
+- 读取 `modus/config.yaml`，提取 `constitution` 字段（`tech_stack`、`hard_rules`、`key_patterns`）
+
+**业务 Skill（调用方已加载则复用，否则自行读取）：**
+- 读取与本次需求相关的 `.codebuddy/skills/modus-biz-{domain}/SKILL.md`
+- 重点提取：`[model]`、`[process]`、`[guideline]`、`[pitfall]`、`key_files`
+
+### Step 2：澄清架构决策（AskUserQuestion）
+
+基于需求内容和已加载的业务 Skill，识别 2-3 个关键的架构决策点，向用户确认：
+
+**提问原则：**
+- 只问会显著影响设计方案的决策（影响实体结构、接口签名、事务边界）
+- 若 Skill 中已有 `[decision]` 明确记录相关决策，跳过此类问题
+- 若需求文档中已明确指定技术方案，跳过此步
+
+**典型问题类型：**
+```
+为了生成准确的设计方案，需要确认几个架构决策：
+
+1. [数据模型] {新状态/字段} 是新增到 {现有表}，还是独立建表？
+   （影响 DDL 设计和关联查询方式）
+
+2. [接口方式] {功能} 是同步接口还是异步 MQ？
+   （影响 API 合同和事务边界设计）
+
+3. [并发处理] 同一 {资源} 可能被并发操作，使用分布式锁还是乐观锁？
+   （影响服务层实现模式）
+
+4. [兼容性] 现有接口 {接口名} 是否可以修改入参，还是必须新增接口？
+   （影响 API 合同设计）
+```
+
+等待用户回答后，输出决策摘要：
+```
+架构决策已确认：
+- 数据模型: {决策结果}
+- 接口方式: {决策结果}
+- 并发处理: {决策结果}
+
+开始生成设计方案...
+```
+
+### Step 3：生成 design-brief
+
+基于以上所有上下文，生成完整的 design-brief，严格遵循 9 节结构（见下方产出物格式）。
+
+**生成原则：**
+- 每个类名/方法名必须有依据（来自 Skill `key_files` 或项目现有代码），不凭空造
+- 字段类型必须明确（优先使用 constitution `tech_stack` 指定的语言类型）
+- 禁止事项节必须覆盖 constitution `hard_rules` 中与本次相关的每一条
+- 追踪矩阵行数 = 需求分析中 Requirement/Scenario 总数，一一对应
+
+**生成后执行质量自检（依据 modus-design-brief RULE）：**
+```
+□ 节 3 中所有字段带类型标注
+□ 节 4 中所有方法签名带包路径
+□ 节 5 中每层至少一个具体类名/方法名
+□ 节 6 中覆盖了所有 Scenario 的失败路径
+□ 节 8 中逐条对应了 constitution hard_rules
+□ 节 9 中每个需求点都有对应 Sprint 和 Scenario
+```
+
+若有未通过项，在对应节标注 `⚠️ 待补充: {原因}`。
+
+### Step 4：写入或内联输出
+
+**落盘模式（plan / spec / harness）：**
+
+将生成内容写入调用方指定路径：
+- plan 模式：`modus/plans/{name}/design-brief.md`
+- spec 模式：`modus/changes/{name}/design-brief.md`
+- harness 模式：`modus/plans/active/{story-id}/01.5-design-brief.md`
+
+写入后输出确认：
+```
+✓ design-brief.md 已生成（{N}节 | 追踪矩阵 {N}行 | 质量自检: {通过N/6}）
+  路径: {文件路径}
+```
+
+**内联模式（vibe）：**
+
+以分隔线包裹，直接追加到当前对话上下文中，不写入任何文件：
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+[Design Brief — 内联设计方案，仅用于本次编码，不写文件]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+{9节内容}
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+[End of Design Brief — 开始编码]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+---
+
+## 产出物格式（design-brief.md）
+
+```markdown
+# Design Brief: {功能名称}
+
+<!--HANDOFF
+agent: "01.5-design"
+story_id: "{story-id}"
+domains: ["{domain1}", "{domain2}"]
+design_decisions:
+  - "{决策1}"
+  - "{决策2}"
+key_entities: ["{Entity1}", "{Entity2}"]
+api_contracts: ["{方法签名1}", "{方法签名2}"]
+gate_status: "passed"
+-->
+
+## 1. 基本信息
+
+| 字段 | 值 |
+|---|---|
+| 功能名称 | {名称} |
+| 关联文档 | {proposal.md / 01-analysis.md 路径 / Story URL} |
+| 生成时间 | {YYYY-MM-DD HH:mm} |
+| 模式 | {plan / spec / harness} |
+| 涉及业务域 | {domain1}, {domain2} |
+
+## 2. 业务意图摘要
+
+{一句话核心业务价值，直接摘录自需求分析文档}
+
+## 3. 实体与数据模型
+
+### 新增实体 / 字段
+
+```java
+// {EntityName}
+public class {EntityName} {
+    private Long id;                    // 主键
+    private Long tenantId;              // 租户 ID（必须从 UserContext 获取）
+    private {Type} {fieldName};         // {业务含义}
+    // ...
+}
+```
+
+### 数据库变更（DDL）
+
+```sql
+-- 若有新建表
+CREATE TABLE `{table_name}` (
+  `id` bigint NOT NULL AUTO_INCREMENT,
+  `tenant_id` bigint NOT NULL COMMENT '租户ID',
+  `{column}` {type} NOT NULL COMMENT '{说明}',
+  PRIMARY KEY (`id`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='{表说明}';
+
+-- 若有字段变更
+ALTER TABLE `{table_name}` ADD COLUMN `{column}` {type} COMMENT '{说明}';
+```
+
+### 枚举定义（若有）
+
+```java
+public enum {EnumName} {
+    {MEMBER_1}("{描述}"),
+    {MEMBER_2}("{描述}");
+}
+```
+
+## 4. API / 接口合同
+
+### {接口名称}
+
+**HTTP（若有）：** `{METHOD} /api/v1/{path}`  
+**方法签名：** `{com.company.package.ClassName#methodName}(RequestVO req) : ResponseVO`
+
+**请求对象 {RequestVO}：**
+| 字段 | 类型 | 必填 | 说明 |
+|---|---|---|---|
+| {field} | {Type} | 是/否 | {说明} |
+
+**响应对象 {ResponseVO}：**
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| {field} | {Type} | {说明} |
+
+## 5. 实现蓝图
+
+### Data 层
+
+- **Mapper：** `{com.company.dao.XxxMapper}` — 新增方法 `{methodName}(param) : ReturnType`
+- **XML：** `{resources/mapper/XxxMapper.xml}` — 对应 SQL
+
+### Service / Manager 层
+
+- **Manager：** `{com.company.manager.XxxManager}` — 核心逻辑入口
+  - `@Transactional` 标注在此方法：`{methodName}`
+  - 分布式锁（若需）：`{lockKey}` 格式 `{key-pattern}`
+- **Service：** `{com.company.service.XxxService}` — 业务编排
+
+### API / Facade 层
+
+- **Controller/Facade：** `{com.company.facade.XxxFacade}`
+  - 参数校验：`@Valid` + `{ValidationAnnotation}`
+  - 权限校验：`@UserAuthorization(permission = "{perm}")`（若适用）
+
+### 调用链
+
+```
+{FacadeClass}#{method}
+  └─ {ServiceClass}#{method}（参数校验、业务规则）
+       └─ {ManagerClass}#{method}（@Transactional，核心逻辑）
+            ├─ {MapperClass}#{queryMethod}（查询）
+            └─ {MapperClass}#{saveMethod}（写入）
+```
+
+## 6. 边界条件与异常处理
+
+| 场景 | 触发条件 | 错误码 | 错误消息 | 处理方式 |
+|---|---|---|---|---|
+| {Scenario 名称} | {触发条件} | {ERROR_CODE} | "{消息文本}" | {抛异常/返回/回滚} |
+| 并发冲突（若有） | 同一 {资源} 被并发操作 | {LOCK_ERROR} | "操作频繁，请稍后重试" | 分布式锁/乐观锁拒绝 |
+| 参数校验失败 | {必填字段} 为空 | PARAM_INVALID | "{字段}不能为空" | 接口层拦截 |
+
+## 7. 代码生成提示
+
+### 可复用的现有类
+
+| 类 | 路径 | 用途 |
+|---|---|---|
+| {ClassName} | {完整包路径} | {用途说明} |
+
+### 命名规范（来自业务 Skill）
+
+- **Mapper：** `{Domain}Mapper`，示例 `OrderMapper`
+- **Service：** `{Domain}Service`，示例 `OrderService`
+- **VO：** `{功能}RequestVO` / `{功能}ResponseVO`
+- **常量：** 放在 `{com.company.constants.{Domain}Constants}`
+
+### 关键代码模式（来自 constitution key_patterns）
+
+```java
+// 示例：正确的事务写法（避免同类内部调用失效）
+// 错误：this.method() 在同一类中不走代理
+// 正确：通过 AopContext.currentProxy() 或注入自身
+{具体示例代码片段}
+```
+
+## 8. 禁止事项与已知坑
+
+### constitution hard_rules（逐条对应）
+
+| 规则 | 违反后果 |
+|---|---|
+| {hard_rule_1} | {若违反会导致什么} |
+| {hard_rule_2} | {若违反会导致什么} |
+
+### 业务 Skill [pitfall] 条目
+
+| 坑 | 来源 Skill | 违反后果 |
+|---|---|---|
+| {pitfall_1} | modus-biz-{domain} | {后果} |
+
+### 本次需求特有 Anti-patterns
+
+- **禁止：** {具体禁止行为} — 原因：{原因}
+
+## 9. 需求-任务追踪矩阵
+
+| 需求点 / Requirement | 对应 Sprint | 对应任务行 | 对应 Scenario |
+|---|---|---|---|
+| {需求描述} | Sprint {N} | tasks.md #{N}.{M} | Scenario: {名称} |
+```
+
+---
+
+## 调用方集成说明
+
+### plan / spec 模式调用方式
+
+在 Step 5.5 中，直接调用本 Skill，传入以下参数：
+```
+output_path: modus/plans/{name}/design-brief.md   # plan 模式
+output_path: modus/changes/{name}/design-brief.md  # spec 模式
+mode: plan | spec
+analysis_doc: {proposal.md 路径}
+business_skills: [{已加载的 Skill 内容}]
+constitution: {constitution 字段内容}
+```
+
+### vibe 模式调用方式
+
+传入 `mode: vibe`，Skill 不执行 Step 4 的写文件操作，仅在对话输出中内联展示设计方案块。
+
+### harness 模式调用方式
+
+由 SubAgent 01.5 独立执行（见 `modus-harness-agents/01-5-design/SKILL.md`），输入为 `01-analysis.md`，输出为 `01.5-design-brief.md` 含 HANDOFF 块。

package/templates/skills/modus-harness/SKILL.md

@@ -1,3 +1,10 @@
+---
+name: modus-harness
+description: Use this skill when executing /modus:harness command to run the full dual-loop multi-agent Harness from requirements analysis to deployment. Acts as the orchestrator coordinating SubAgents 00-07. Trigger on /modus:harness command or when user provides a TAPD Story URL and wants automated end-to-end delivery.
+allowed-tools: Read, Write, Glob, Bash, Task
+disable: false
+---
+
 # modus-harness（双 Loop 多智能体 Harness Orchestrator）
 
 **触发条件：** 用户运行 `/modus:harness [TAPD Story URL]` 时使用此 Skill。
@@ -16,6 +23,7 @@
 |----|-----------|------|--------|------------|
 | 00 | `modus-harness-00-skills-builder` | Skills 更新/知识提取 | Skill 文件 + catalog | 无限制 |
 | 01 | `modus-harness-01-analysis` | 需求分析 | `01-analysis.md` | ≤ 3 个 Skill 文件 |
+| 01.5 | `modus-harness-01-5-design` | 设计方案生成 | `01.5-design-brief.md` | ≤ 3 个 Skill 文件 |
 | 02 | `modus-harness-02-dev` | 代码开发 | `02-sprint-contract.md` | ≤ 5 个 Skill 文件 + ≤ 10 个代码文件 |
 | 03 | `modus-harness-03-test` | 代码测试 | `03-test-report.md` | ≤ 2 个 Skill 文件 |
 | 04 | `modus-harness-04-perf` | 性能审计 | `04-perf-report.md` | ≤ 2 个 Skill 文件 |
@@ -132,6 +140,9 @@ Constitution: {N} 条硬性规则已加载
 ```
 SubAgent 01（需求分析）
   ↓ 产出 01-analysis.md（含 HANDOFF 块）
+  ↓ Gate A0: 01.5-design-brief.md HANDOFF.gate_status ∈ {passed, warning}
+SubAgent 01.5（设计方案生成）⏸️ 含人工架构决策确认
+  ↓ 产出 01.5-design-brief.md（含 HANDOFF 块）
 SubAgent 02（代码开发）
   ↓ 产出 02-sprint-contract.md（含 HANDOFF 块）
   ↓ Gate A: 编译验证（项目构建工具编译，exit code = 0）
@@ -152,6 +163,7 @@ SubAgent 07（部署发布）
 
 | Gate | 检查方式 | 失败处理 |
 |------|---------|---------|
+| Gate A0 | 读 `01.5-design-brief.md` HANDOFF 块，检查 `gate_status` ∈ {passed, warning} | `failed` 时重入 SubAgent 01.5，最多 2 次 |
 | Gate A | 执行 `constitution.build_command`，exit code = 0 | 重入 SubAgent 02，最多 3 次 |
 | Gate B | 扫描目录，检查 03/04/05 三个 HANDOFF 文件均存在 | 继续等待，超时上报 |
 | Gate C | 读 cr-report.md 的 HANDOFF 块，检查 `issues` 是否为空 | 触发 Loop 2 精准重入 |
@@ -191,6 +203,8 @@ SubAgent 07 完成后（进入 Human Final Review 等待阶段），调用 SubAg
 
 ```
 ✅ SubAgent 01 完成 → 01-analysis.md（影响范围: N 处 | 风险点: N 个 | domains: order,payment）
+⏸️ SubAgent 01.5 执行中...（等待架构决策确认）
+✅ SubAgent 01.5 完成 → 01.5-design-brief.md（设计决策: N 个 | 追踪矩阵: N 行 | Gate A0: passed）
 🔄 SubAgent 02 执行中...（Sprint 2/3 | token: 3/5 Skill 预算已用）
 ⏳ 并行等待 03/04/05（2/3 完成）
 ❌ Gate A 失败 → 重入 SubAgent 02（第 N 次）
@@ -228,6 +242,7 @@ feat: {业务摘要}
 |----------------|----------------|
 | 修改任何业务代码 | SubAgent 02 |
 | 分析 TAPD 需求内容 | SubAgent 01 |
+| 生成设计方案或询问架构决策 | SubAgent 01.5 |
 | 对代码质量发表意见 | SubAgent 06 |
 | 执行测试或验证逻辑 | SubAgent 03/04/05 |
 | 操作部署流程 | SubAgent 07 |
@@ -240,7 +255,9 @@ feat: {业务摘要}
 1. 扫描 `modus/plans/active/{story-id}/` 目录，列出已有 HANDOFF 块
 2. 只需读各文件的 HANDOFF 块（≤ 20 行），对照串行顺序确定当前阶段
 3. 检查当前阶段的 Gate 条件是否满足（优先读 HANDOFF，必要时读全文）
+   - Gate A0：检查 `01.5-design-brief.md` HANDOFF 的 `gate_status` 字段
 4. Gate 通过 → 调用下一个 SubAgent 的 Skill（传递 constitution + 相关 Skill 内容）
+   - 调用 SubAgent 02 时，必须同时传入 `01.5-design-brief.md` 内容
 5. Gate 失败 → 按规则处理（重入/上报）
 6. 输出本轮进度卡片
 7. 若 SubAgent 07 完成 → 触发 ARCHIVE 知识提取（SubAgent 00 模式 D）