PRD → 技术设计文档（→ 代码骨架）

规范加载指引 【重要 · 适用时加载】

本技能依赖两类规范，均按需加载、禁止一次性全部加载：

① 通用设计规范（独立技能）——design-api、design-db、design-code 是与本技能并列注册的独立技能，可单独用于 API 评审、数据库评审、代码审查等场景。在 PRD2PLAN 流程中，进入对应阶段时调用 skill 工具加载（使用准确技能名）：

② 流程规则（本技能私有 rules/ 目录）——详细流程模板以普通 Markdown 存放在 <base>/rules/*.md（不是独立技能，不会出现在技能目录里），用 read 工具按需读取：

> 加载/读取某个规范后，其内容即成为当前阶段的硬约束；完成对应阶段后不必反复重读。rules/ 路径以本技能加载时渲染的 Base directory 为基准（rules/scenario-new.md 等相对路径）。

核心铁律

> 禁止猜测。 整个过程中，只要遇到 PRD 中未明确的信息——业务规则、数据约束、用户交互细节、边界条件、非功能需求——立刻停止，用结构化方式向用户提问。没有例外。
>
> 先识别，后扫描。 收到用户输入后，必须先分析问题类型、输入格式和场景关键词，然后才能启动项目扫描。禁止收到输入后不加分析直接扫描代码库。

总体流程

用户输入
       │
       ▼
Phase 1: 问题识别 ─────── 【新增】分析输入类型、场景预判、格式识别
       │                  （不扫描代码，纯文字分析）
       ▼
Phase 2: 解析需求 ─────── 提取需求全貌（含实体列表）
       │
       ▼
Phase 3: 代码库感知 ───── 基于 Phase 2 实体列表，定向扫描项目
       │                  （先知道要找什么，再扫描）
       ▼
Phase 4: 场景分类 ─────── 比对 Phase 2 实体列表 vs Phase 3 现有实体 → 判定场景
       │
       ▼
Phase 5: 澄清歧义 ─────── 【STOP】逐一确认 + 场景特定追问
       │
       ▼
Phase 6: 模块设计 ─────── 领域划分 + 模块职责 + 状态机
       │
       ▼
Phase 7: API 设计 ─────── 遵循 design-api（场景自适应）
       │
       ▼
Phase 8: 数据库设计 ───── 遵循 design-db（场景自适应）
       │
       ▼
Phase 9: 架构设计 ─────── 遵循 design-code
       │
       ▼
  ┌─────────────────────────────────────┐
  │ Phase 10: 打包设计资产              │
  │ 将 {感知卡片, 实体列表, API清单,     │
  │  DDL, 状态机, 时序图, 澄清记录}      │
  │ 作为上下文传递给场景规则文件       │
  └─────────────────────────────────────┘
       │
       ▼
  ┌─────────────────────────────────────┐
  │ 根据 Phase 4 场景，读取规则文件     │
  │ 🟢 → rules/scenario-new.md    │
  │ 🟡 → rules/scenario-modify.md │
  │ 🔵 → rules/scenario-crosscut.md│
  │ ⚪ → rules/scenario-refactor.md│
  └─────────────────────────────────────┘
       │
       ▼
规则文件接管后续阶段：
  输出设计文档（按场景模板，引用 Phase 10 传递的资产）
  交叉验证与审计
  生成 OpenAPI YAML（🟢🟡）
  拆分 DDL SQL 文件（🟢🟡🔵）
       │
       ▼
  ┌─────────────────────────────────────┐
  │ Phase 11: 设计→代码生成（可选）     │
  │ 子交付后，若用户需要代码骨架，      │
  │ 调用 skill 工具加载 design-code：   │
  │   CG-1~CG-8：以设计资产+设计文档为  │
  │   唯一依据，生成 Handler/Service/   │
  │   Repository/Entity/DTO/枚举骨架，  │
  │   并执行四方对齐审计签章            │
  └─────────────────────────────────────┘

Phase 1：问题识别 【强制 · 第一道工序】

目的：收到用户输入后，先分析、后行动。不要立刻扫描代码库，先理解用户给的是什么、想做什么。

执行约束：此阶段禁止调用任何文件搜索/读取工具，只对用户输入的文本做纯逻辑分析。

1.1 判断输入形态

1.2 场景关键词预判

在不扫描代码的前提下，从用户描述中提取关键词，给出初步场景判断（Phase 4 会结合代码库扫描结果最终确认）：

输出：一句简短摘要，例如：

【问题识别】
- 输入形态：PRD 文件（PDF）
- 预判场景：🟡 增量改造（关键词："给任务流程增加审批"）
- 下一步：Phase 2 解析 PRD

然后直接进入 Phase 2。不要在此阶段扫描项目。

Phase 2：解析需求

2.1 识别文件格式

• *.pdf → 用 pdf skill 提取文本
• *.docx → 用 docx skill 提取文本
• *.md / *.txt → 直接读取
• 口头描述 → 直接使用用户的文字描述作为输入
• 其他格式 → 提问用户能否提供以上格式之一

2.2 提取结构化信息

从输入中逐项提取，填入以下清单。提取不到就标 [未提及]，不编造：

【需求提取清单】

■ 项目背景：[一句话]
■ 核心目标：[解决什么问题，KPI 是什么]
■ 目标用户/角色：[谁在用，权限有什么不同]
■ 功能列表：
  1. [功能名] — [一句话描述] — 优先级 P0/P1/P2
  2. ...
■ 核心业务流程：[用文字描述主流程，标注分支]
■ 数据实体：[出现过的名词：用户、订单、项目...]  ← Phase 4 用此列表判定场景
■ 实体关系：[谁包含谁、谁引用谁]
■ 业务规则：[约束、校验条件、状态机]
■ 非功能需求：[并发量、数据量、响应时间、安全要求]
■ 外部依赖：[需要对接的系统/服务]

2.3 输出确认

将提取的清单展示给用户，等待确认后再进入 Phase 3。

> 注意：Phase 2 确认后，才开始 Phase 3 代码扫描。因为此时你已经知道"要找什么实体"，扫描可以更有针对性。

Phase 3：代码库感知 【强制】

目的：基于 Phase 2 提取的实体列表，定向扫描项目结构和现有实体，避免盲目全量扫描。

3.1 自动扫描项目结构

使用代码搜索工具扫描以下信息，填写《项目感知卡片》：

【项目感知卡片】

■ 技术栈
  - 语言/框架：[如 Spring Boot 2.x / Django / Express / Gin]
  - ORM：[如 MyBatis-Plus / JPA / GORM / Prisma / SQLAlchemy]
  - 数据库：[MySQL / PostgreSQL / SQL Server / SQLite]
  - 缓存：[Redis / Memcached / 无]
  - 其他中间件：[对象存储 / 消息队列 / ...]

■ 代码组织
  - 根包/根模块路径：[如 com.example.xxx / app / src/]
  - Controller/Handler 所在目录：[实际路径]
  - Service 所在目录：[实际路径]
  - Repository/Mapper 所在目录：[实际路径]
  - Entity/DTO/VO 所在目录：[实际路径]
  - 自动生成代码与手写代码的隔离方式：[如有]

■ 现有业务模块清单
  | 模块名 | 所在位置 | 功能简述 | 是否新模块的依赖 |
  |--------|----------|----------|-----------------|
  | ... | ... | ... | ... |

■ 现有 API 惯用模式
  - URL 前缀：[如 /api/v1/]
  - 分页参数名：[page/pageSize 或 offset/limit]
  - 统一响应格式：[提取实际响应结构：顶层字段命名、list 包裹方式等]
  - 认证方式：[Header Token / Cookie Session / OAuth2]

■ 数据库惯用模式
  - 表命名风格：[小写下划线 / 驼峰]
  - 主键策略：[AUTO_INCREMENT / UUID / 雪花ID]
  - 审计字段约定：[如 created_at+updated_at / create_time+modify_time]
  - 软删除标记：[is_deleted TINYINT / deleted_at DATETIME / 不使用]
  - 金额类型：[DECIMAL(18,2) / BIGINT 分]

■ 现有实体全景（优先扫描 Phase 2 中提到的实体名）
  | 实体/表名 | 所在位置 | 备注 |
  |-----------|---------|------|

■ 设计约束（从现有代码中提取）
  - 禁止使用的类型/模式：[如 ENUM / FLOAT]
  - 强制使用的父类/接口：[如有，列出类名和路径]
  - 代码风格要求：[方法行数限制 / 命名约定等]

3.2 扫描方法（两步走）

第一步：定向扫描（优先）。根据 Phase 2 提取的实体名称，在项目中搜索同名或相似的表/Service/Controller：
- 搜索实体/表名 → 确认是否已有
- 搜索对应的 Service → 确认是否已有业务逻辑
- 搜索对应的 Controller → 确认是否已有 API

第二步：全貌扫描（补全）。完成定向扫描后，再补全技术栈和惯用模式信息：

3.3 设计约束输出

扫描完成后，明确以下约束并在后续设计中遵守：

1. 包/模块路径约束：新模块放在哪里？命名如何约定？
2. 继承约束：Service 是否有基类需要继承？有哪些公共方法可用？
3. URL 约束：所有 API URL 必须以项目的统一前缀开头
4. 响应格式约束：统一用项目现有的响应包装结构
5. 审计字段约束：每张表必须包含项目的标准审计字段
6. 命名约束：表名、列名、索引名遵守项目现有约定

输出：将《项目感知卡片》作为设计文档第 0 章写入。

Phase 4：场景分类与自适应执行计划 【强制】

目的：不是所有 PRD 都是"从零建"。必须在设计前判断这是哪种类型的需求，并自动调整后续执行强度。

4.1 四类场景定义

4.2 自动判定流程

Phase 2 提取的实体列表 ─┐
                         ├─ 比对 Phase 3 扫描的现有实体全景
Phase 3 现有实体全景  ───┘
       │
       ▼
  ┌─ 全部不一致 ──────────────→ 🟢 全新功能
  ├─ 1~2 张表有变化 ─────────→ 🟡 增量改造
  ├─ 涉及 ≥3 张表且无新增表 ──→ 🔵 横切机制
  └─ 无表/API 变更需求 ──────→ ⚪ 重构优化

判定后必须输出结论给用户确认（同时对比 Phase 1 的预判）：

## 场景判定

| 项目 | 内容 |
|------|------|
| Phase 1 预判 | 🟡 增量改造 |
| 实际判定结果 | 🟡 增量改造 ✅ 一致 |
| 涉及已有实体 | `tasks`（增加 status, approver_id 字段） |
| 涉及新实体 | `approval_records`（1 张新表） |
| 受影响 API | POST /tasks/{id}/submit（新增）、GET /tasks/{id}/approvals（新增） |
| 不受影响 API | GET/PUT/DELETE /tasks 系列保持不变 |

→ 将采用【精简模式】执行后续 Phase。
→ 确认？(Y/N)

4.3 各场景执行清单

4.4 文件命名规则（场景规则文件执行）

Phase 5：澄清歧义 【强制 STOP】

5.1 何时必须提问

下表每项检查 PRD 是否明确，不明确则提问：

5.1.1 按场景追加额外问题

根据 Phase 4 的场景分类，在通用 11 项之上追加：

🟡 增量改造追加：

🔵 横切机制追加：

⚪ 重构优化追加：

5.2 提问格式

## 🔴 需要确认

### Q1: [类别] 问题描述

**上下文**：PRD 提到 xxx，我们已知 yyy。

**不明确点**：具体哪个环节不确定。

**可能的选项**（如有）：
- A. xxx
- B. yyy
- C. 其他（请说明）

一次提完所有问题，不要一个一个问。若问题超过 10 个，分 2 批提问（每批 ≤10 个）。用户回答完再进入 Phase 6。

Phase 6：模块设计

6.1 领域划分

按业务领域拆分模块，每个模块：
- 一句话定义职责
- 列出核心聚合
- 标注模块间依赖关系

【模块划分】

┌─────────────┐     ┌─────────────┐
│  用户与权限   │────>│   项目管理   │
└─────────────┘     └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ 报告管理  │ │ 流程审批  │ │ 数据看板  │
        └──────────┘ └──────────┘ └──────────┘

6.2 模块明细

为每个模块输出。包/模块路径基于 Phase 3 感知卡片中确定的项目根路径拼接：

场景自适应：
- 🟢 全量输出所有新模块
- 🟡 只输出本次变更涉及的模块，标注不变部分
- 🔵 输出切面/拦截器模块，而非业务模块
- ⚪ 画新旧架构对比图，标注变更点

6.3 状态机设计 【强制】

每发现一个含状态流转的实体，必须画状态机。 格式：

【订单状态机】
                    ┌──────────────┐
                    │   已取消(3)   │
                    └──────▲───────┘
                           │ 任意非终结态可取消
  ┌─────────┐    ┌────────┴───────┐    ┌─────────┐
  │ 草稿(0) │───>│  待付款(1)     │───>│ 已付款(2)│
  └─────────┘    └────────────────┘    └─────────┘
    提交订单          支付成功

变迁约束：
- 草稿→待付款: 订单项非空 && 库存充足
- 待付款→已付款: 支付回调成功
- 待付款→已取消: 超时 30min 自动取消 / 用户手动取消
- 已付款→已取消: ❌ 不允许（需走退款流程）
- 已付款→待付款: ❌ 不可逆

铁律：状态机中每个变迁必须有触发条件。不允许 "任意状态可到任意状态"。

Phase 7：API 设计

先调用 skill 工具加载 design-api 技能并严格遵守，然后遵循其规范执行：

7.1 资源建模

为每个聚合根定义 REST 资源。URL 中必须使用 Phase 3 感知卡片中提取的项目 URL 前缀：

场景自适应：
- 🟢 全量接口清单
- 🟡 只列新增/变更接口，明确标注不变接口
- 🔵⚪ 跳过（不暴露新 API）

7.2 接口清单

每个接口含：

#### POST /{prefix}/tasks/{id}/submit

| 项 | 内容 |
|----|------|
| 说明 | 提交任务进入审批流程 |
| 认证 | 需要 |
| 权限 | 任务负责人 或 项目管理员 |
| 前置校验 | 任务状态 = 草稿(0)，不能为空 |
| 幂等 | 是，同一任务重复提交返回 409 |
| 成功 | 200，任务变为 待审批(1) |
| 失败 | 400（参数）/ 403（无权限）/ 409（已提交）/ 404（不存在） |

7.3 请求/响应结构明细 【强制】

每个接口必须给出字段级定义，不写 "略" / "按需"。格式骨架：

POST /{prefix}/tasks/{id}/submit

Request: (Path 参数)
  - id: Long, 任务ID

Response 200:
{
  "code": 0,              // Int, 项目约定的成功状态码
  "data": {
    "id": 1,              // Long, 实体ID
    "status": 1,          // Int, 新状态值
    "updatedAt": "..."    // String, 操作时间
  }
}

Response 409:  // 冲突场景
{
  "code": 409,            // Int, 项目约定的冲突状态码
  "message": "用户可读的错误描述",
  "data": {
    "currentStatus": 1,     // 当前状态
    "allowedStatuses": [0]  // 允许操作的状态列表
  }
}

规则：
- 所有字段标注类型和含义，不能省略
- 错误响应的 data 层提供上下文信息，帮助前端展示或重试（如适用）
- 列表接口给出排序字段、分页参数的默认值和硬上限（≤100）
- 响应格式必须与 Phase 3 感知卡片中提取的项目统一响应格式一致

7.4 错误码清单 【强制】

按模块汇总所有接口的错误码，建立全局唯一编码体系：

| 错误码 | HTTP | 模块 | 接口 | 触发条件 | message 模板 |
|--------|------|------|------|----------|-------------|
| TASK-001 | 404 | 任务 | GET /tasks/{id} | ID 不存在 | 任务(id={})不存在 |
| TASK-002 | 409 | 任务 | POST /tasks/{id}/submit | 状态不允许 | 任务状态不允许提交，当前: {} |
| TASK-003 | 403 | 任务 | PUT /tasks/{id} | 非负责人 | 无权限编辑该任务 |
| AUTH-001 | 401 | 认证 | ALL | Token 过期 | 登录已过期，请重新登录 |

编码规则：{模块缩写}-{3位序号}，如 TASK-001、ORDER-001。每个错误码全局唯一。

Phase 8：数据库设计

先调用 skill 工具加载 design-db 技能并严格遵守，然后遵循其规范执行：

8.1 ER 实体关系

文字版 ER：
  users 1──N orders (user_id → users.id)
  orders 1──N order_items (order_id → orders.id)
  products 1──N order_items (product_id → products.id)
  orders 1──1 payments (order_id → orders.id)

8.2 表结构设计

每张表输出完整的 CREATE TABLE 语句（主键、字段、审计字段、索引、注释）。增量场景的 ALTER TABLE 语法在对应场景规则文件（scenario-modify.md）中规范，此处只做逻辑设计。

审计字段必须与 Phase 3 感知卡片中提取的项目约定一致。

-- ============================================
-- 表名: orders (订单表)
-- ============================================
CREATE TABLE orders (
    id          BIGINT          NOT NULL AUTO_INCREMENT  COMMENT '主键',
    -- 业务字段
    order_no    VARCHAR(32)     NOT NULL                 COMMENT '订单号，唯一',
    user_id     BIGINT          NOT NULL                 COMMENT '用户ID',
    total_amount DECIMAL(18,2)  NOT NULL DEFAULT 0.00    COMMENT '订单总额',
    status      TINYINT         NOT NULL DEFAULT 0       COMMENT '状态: 0草稿 1待付款 2已付款 3已取消',

    -- 审计字段（按项目约定）
    created_at  DATETIME        NOT NULL DEFAULT CURRENT_TIMESTAMP       COMMENT '创建时间',
    updated_at  DATETIME        NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    created_by  BIGINT          DEFAULT NULL                            COMMENT '创建人ID',
    updated_by  BIGINT          DEFAULT NULL                            COMMENT '修改人ID',

    PRIMARY KEY (id),
    UNIQUE KEY uk_orders_order_no (order_no),
    KEY idx_orders_user_id (user_id),
    KEY idx_orders_status_created (status, created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

8.3 索引设计说明

8.4 数据量预估 【强制】

每张表预估 3 个指标，影响索引策略和是否分表：

| 表名 | 初始行数 | 年增长率 | 单行估算 | 3 年总量 | 是否需要分表 |
|------|----------|----------|----------|----------|-------------|
| orders | 0 | ~50万/年 | ~200B | ~150万 | 否 |
| order_items | 0 | ~200万/年 | ~150B | ~600万 | 否 (<1000万) |
| operation_logs | 0 | ~500万/年 | ~100B | ~1500万 | 是 (按年分区) |

判断标准（基于 MySQL InnoDB + 常规 SSD 硬件 + 多列索引的正常查询场景）：

> 注意：以上阈值为 MySQL InnoDB 的通用经验值。具体阈值受硬件（内存/IOPS）、查询模式（索引覆盖率、JOIN 复杂度）等影响，实际应以性能测试结果为准。PostgreSQL、SQL Server 等其他数据库的阈值不同，需单独评估。

8.5 API ↔ DB 交叉校验

设计完 API 和 DB 后，必须做交叉校验：

不匹配的标注 ⚠️ 待对齐。

Phase 9：架构设计

先调用 skill 工具加载 design-code 技能并严格遵守，然后遵循其规范执行：

9.1 分层结构

handler/        ← 只做：参数校验 + 调 Service + 组装响应
service/        ← 只做：业务逻辑 + 事务
repository/     ← 只做：数据访问
entity/         ← DTO / VO / 领域实体
common/         ← 横切：异常、工具、切面
enums/          ← 业务枚举

9.2 核心 Service 职责

9.3 关键业务流程

用文字描述核心流程 + Service 调用链：

【提交任务审批流程】
1. TaskController.submit(taskId) → 参数校验
2. TaskServiceImpl.submit(taskId)
    ├─ validateStatus(task)                   // 卫语句：非草稿抛 409
    ├─ validateUserPermission(task, user)     // 无权限抛 403
    ├─ buildApprovalRecord(task)              // 构造审批对象
    ├─ approvalRecordMapper.insert(record)    // 创建审批记录
    ├─ taskMapper.updateStatus(taskId, 1)     // 更新任务状态
    └─ notificationService.notify(approver)   // 通知审批人
3. 组装统一响应并返回

9.4 时序图（关键交互） 【强制】

至少为核心业务流程中的 3 条决策路径 画时序图。格式使用文字时序图（Mermaid 风格，纯文本兼容）：

【提交任务审批 - 正常流程】
客户端          Controller       Service           Repository       外部服务
  │                │                │                 │               │
  │ POST /tasks/1/submit           │                 │               │
  │───────────────>│                │                 │               │
  │                │ submit(1)      │                 │               │
  │                │──────────────>│                 │               │
  │                │                │ findById(1)     │               │
  │                │                │────────────────>│               │
  │                │                │ <── Task(status=0)              │
  │                │                │                 │               │
  │                │                │ updateStatus(1, 1)              │
  │                │                │────────────────>│               │
  │                │                │                 │               │
  │                │                │── notify(approver)              │
  │                │                │                 │  ──推送──>    │
  │                │ <── OK ────────│                 │               │
  │ <── 200 ───────│                │                 │               │

【提交任务审批 - 状态非法】
客户端          Controller       Service
  │                │                │
  │ POST /tasks/1/submit           │
  │───────────────>│                │
  │                │ submit(1)      │
  │                │──────────────>│
  │                │                │ findById(1) → status=1(已提交)
  │                │                │ throw BusinessException("已提交, 不可重复")
  │                │ <── 异常 ──────│
  │ <── 409 ───────│                │

规则：时序图必须在正常流程外覆盖至少 1 条异常分支和 1 条边界条件。

9.5 技术决策

技术决策基于 Phase 3 感知卡片中提取的项目现有技术栈，保持一致。仅对新增技术选型做决策：

新增技术选型必须给出充分理由，优先复用项目现有技术栈。

Phase 10：打包设计资产，传递给场景规则 【强制】

Phase 9 完成后，在读取场景规则文件前，将以下设计资产以结构化摘要形式汇总，作为场景规则的上下文：

【设计资产传递清单】（在读取场景规则文件时一并附上）

□ 项目感知卡片（Phase 3 输出）
  - URL 前缀、响应格式、审计字段约定
  - 项目根路径、现有实体全景

□ 场景判定结论（Phase 4 输出）
  - 场景类型、涉及实体、受影响/不受影响 API

□ 功能模块设计（Phase 6 输出）
  - 模块划分图、模块明细表、状态机图

□ API 设计清单（Phase 7 输出）
  - 资源建模表、接口清单、DTO 字段定义、错误码清单

□ 数据库设计（Phase 8 输出）
  - ER 关系图、表结构 DDL、索引设计、数据量预估

□ 架构设计（Phase 9 输出）
  - 分层结构、Service 职责表、时序图、技术决策

□ 澄清记录（Phase 5 输出）
  - 问题及用户回复原文

场景规则在接收设计资产后，必须引用以上资产——而非重新推导或猜测。

Phase 10 完成后：读取场景规则文件

根据 Phase 4 判定的场景，读取对应的场景规则文件接管后续阶段：

执行：用 read 工具读取对应的场景规则文件，同时将《设计资产传递清单》作为上下文附上。按规则文件执行文档输出、审计、YAML 生成、SQL 产出直至交付。

Phase 11：代码实现（可选，需用户确认）

场景规则交付设计文档后，询问用户是否需要编写代码：

> 设计文档已交付。是否需要我基于该设计编写完整的后端代码（Handler / Service / Repository / Entity / DTO / 枚举等）？

• 用户确认 → 调用 skill 工具加载 design-code 技能，将《设计资产传递清单》+ 已交付的设计文档作为上下文。严格遵循 design-code 中的编码规范，编写高质量、可维护的生产级代码。
• 用户拒绝 → 交付结束。

代码实现要点：
- 遵循 design-code 中的分层职责、SOLID 原则
- 实现状态机校验、幂等性、事务管理
- 添加完善的异常处理和日志
- 编写清晰的注释和文档
- 执行 API↔DB↔Code 交叉校验

禁止事项（通用）

• ❌ 收到用户输入后不加分析直接扫描代码
• ❌ PRD 没提就当不存在
• ❌ 遇到不明确的自行脑补
• ❌ 跳过 Phase 1 问题识别（必须先分析，后扫描）
• ❌ 跳过 Phase 3 代码库感知直接设计
• ❌ 跳过 Phase 4 场景分类，直接按全新功能走全流程
• ❌ 跳过 Phase 5 直接开始设计
• ❌ API 全部用 POST / 不分页给默认上限
• ❌ 表设计无主键 / 漏索引 / 用 ENUM
• ❌ 技术选型不给理由
• ❌ Phase 10 不打包设计资产，场景规则基于不完整信息生成文档
• ❌ 不按场景读取对应的规则文件（如 🟡 场景去读 scenario-new.md）
• ❌ 设计与 Phase 3 感知卡片中提取的项目现有约定不一致（如 URL 前缀、审计字段、响应格式）
• ❌ 用户确认需要代码后跳过 Phase 11（不调用 design-code 技能直接结束交付）
• ❌ 一次性加载全部规范（通用规范按阶段用 skill 工具加载、流程规则按需用 read 读取，禁止全量）