adspecs 0.1.35 → 0.1.37

package/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
     {
       "name": "adspecs",
       "description": "AI Coding研发协同开发插件",
-      "version": "0.1.35",
+      "version": "0.1.37",
       "source": "./",
       "author": {
         "name": "Qingwen Chen",

package/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "adspecs",
   "displayName": "adspecs AI Plugin",
   "description": "AI first工程规范驱动开发插件",
-  "version": "0.1.35",
+  "version": "0.1.37",
   "author": {
     "name": "Qingwen Chen",
     "email": "cqinwn@qq.com",

package/.codebuddy-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "adspecs",
   "displayName": "adspecs AI 工程规范驱动开发插件",
-  "version": "0.1.35",
+  "version": "0.1.37",
   "description": "AI-first specification-driven development plugin for ECP platform full-lifecycle development",
   "descriptionZh": "AI优先的工程规范驱动开发插件，覆盖需求分析、PRD、系统设计、任务拆解、TDD、代码评审、Wiki同步全流程",
   "author": {

package/.qoder-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "adspecs",
   "displayName": "adspecs AI 工程规范驱动开发插件",
-  "version": "0.1.35",
+  "version": "0.1.37",
   "description": "AI-first specification-driven development plugin for ECP platform full-lifecycle development",
   "descriptionZh": "AI优先的工程规范驱动开发插件，覆盖需求分析、PRD、系统设计、任务拆解、TDD、代码评审、Wiki同步全流程",
   "author": {

package/.workbuddy-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "adspecs",
   "displayName": "adspecs AI 工程规范驱动开发插件",
-  "version": "0.1.35",
+  "version": "0.1.37",
   "description": "AI-first specification-driven development plugin for ECP platform full-lifecycle development",
   "descriptionZh": "AI优先的工程规范驱动开发插件，覆盖需求分析、PRD、系统设计、任务拆解、TDD、代码评审、Wiki同步全流程",
   "author": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "adspecs",
-  "version": "0.1.35",
+  "version": "0.1.37",
   "description": "AI first 工程规范驱动开发插件 — 支持 npm 安装和 CLI 初始化",
   "bin": {
     "adspecs": "bin/adspecs.js"

package/skills/adspecs-biz-blueprint/SKILL.md

@@ -155,8 +155,9 @@ $ARGUMENTS
    | 用户角色分析   | 二           | → F6 业务角色与权限         |
    | 使用场景拆解   | 三           | → F2 流程架构 + F3 流程详述 |
    | 业务流程梳理   | 四           | → F1/F3/F3附录/F4/F5        |
-   | 异常和边界     | 五           | → F5 业务规则清单           |
-   | 最终输出与决策 | 六           | → §1 概览 + §8 风险与待确认 |
+   | 业务对象说明   | 五           | → F4 业务字段清单（对象分类与命名口径） |
+   | 异常和边界     | 六           | → F5 业务规则清单           |
+   | 最终输出与决策 | 七           | → §1 概览 + §8 风险与待确认 |
 
    **如果缺失必填章节**：列出缺失章节，使用 AskUserQuestion 询问用户是否继续（部分章节可生成占位内容，标注 `[待确认：需求分析缺失 {章节名}，待补充]`）。
 
@@ -480,15 +481,15 @@ OUTPUT_FILE = "{OUTPUT_DIR}/{short-name}_业务方案.md"
 
 | 章节                   | 状态      | 来源需求分析章节        |
 | ---------------------- | --------- | ----------------------- |
-| §1 概览                | ✅ 已生成 | 一·真实问题 + 六·决策   |
+| §1 概览                | ✅ 已生成 | 一·真实问题 + 七·决策   |
 | §2 业务核心逻辑 (F1)   | ✅ 已生成 | 一 + 四·4.1/4.2         |
 | §3 业务流程架构 (F2)   | ✅ 已生成 | 三·场景清单 + 四·主流程 |
-| §4 业务流程文件 (F3)   | ✅ 已生成 | 三 + 四·4.1/4.3 + 五    |
+| §4 业务流程文件 (F3)   | ✅ 已生成 | 三 + 四·4.1/4.3 + 六·异常 |
 | F3 附录 状态流转       | ✅ 已生成 | 四·4.2 状态机           |
-| §5 业务字段清单 (F4)   | ✅ 已生成 | 四·4.1 输入/输出        |
-| §6 业务规则清单 (F5)   | ✅ 已生成 | 四·4.1 判断 + 五·异常   |
+| §5 业务字段清单 (F4)   | ✅ 已生成 | 四·4.1 输入/输出 + 五·5.2 对象清单 |
+| §6 业务规则清单 (F5)   | ✅ 已生成 | 四·4.1 判断 + 六·异常   |
 | §7 业务角色与权限 (F6) | ✅ 已生成 | 二·角色 + 权限矩阵      |
-| §8 风险与待确认问题    | ✅ 已生成 | 六·风险与待补充         |
+| §8 风险与待确认问题    | ✅ 已生成 | 七·风险与待补充         |
 | §9 确认签              | ✅ 已生成 | 模板固定文本            |
 
 ## 质量验证

package/skills/adspecs-new-requirement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "adspecs-new-requirement"
-description: "基于业务需求描述，结合 01-业务需求分析模板（六步结构），完成深度需求分析并输出业务需求分析文档。Skill 内部执行模拟需求评审（多角色尖锐提问），评审结论融入最终决策。在写 PRD 之前，先搞清楚真正的问题是什么、为谁解决、怎么解决、有哪些风险。"
+description: "基于业务需求描述，结合 01-业务需求分析模板（七章结构），完成深度需求分析并输出业务需求分析文档。Skill 内部执行模拟需求评审（多角色尖锐提问），评审结论融入最终决策。在写 PRD 之前，先搞清楚真正的问题是什么、为谁解决、怎么解决、有哪些风险。"
 agent_created: true
 argument-hint: "描述你要分析的业务需求，或指定已有需求文档路径"
 compatibility: "需要 docs/ 目录体系，含 01-业务需求分析模板.md"
@@ -37,7 +37,7 @@ $ARGUMENTS
 
 ## 定位
 
-本 skill 专注于 **业务需求深度分析**，是产品交付流水线的第一步——在写 PRD（`02`-产品需求说明书）之前，先完成六步需求分析 + 模拟需求评审，确保方向正确。
+本 skill 专注于 **业务需求深度分析**，是产品交付流水线的第一步——在写 PRD（`02`-产品需求说明书）之前，先完成七步需求分析 + 模拟需求评审，确保方向正确。
 
 | 对比项   | adspecs-new-requirement（本 skill）                          | adspecs-prd                            | adspecs-front-spec           | adspecs-plan                  |
 | -------- | ------------------------------------------------------------ | -------------------------------------- | ---------------------------- | ----------------------------- |
@@ -45,7 +45,7 @@ $ARGUMENTS
 | 模板     | `01-业务需求分析模板.md`                                     | `02-产品需求说明书模板.md`             | `04-前端功能设计模板.md`     | `03-系统设计模板.md`          |
 | 目标读者 | 产品经理、业务方、技术负责人                                 | 产品经理、业务方                       | 产品经理、前端开发、UX       | 开发架构师、后端工程师        |
 | 核心问题 | **为什么要做 & 问题本质是什么**                              | **做什么 & 为什么**                    | **怎么用**                   | **怎么建**                    |
-| 关注点   | 真实问题、解法空间、角色权限、流程状态、异常边界、需求成熟度 | 业务场景、用户故事、功能描述、验收标准 | 页面路由、界面布局、交互行为 | DO/DTO/VO、数据模型、接口设计 |
+| 关注点   | 真实问题、解法空间、角色权限、流程状态、业务对象、异常边界、需求成熟度 | 业务场景、用户故事、功能描述、验收标准 | 页面路由、界面布局、交互行为 | DO/DTO/VO、数据模型、接口设计 |
 
 **典型工作流**：
 
@@ -65,7 +65,7 @@ $ARGUMENTS
 
 ## 任务
 
-读取用户提供的业务需求描述（或已有需求文档），按照七步分析法（六步写入文档 + 模拟评审内部执行）完成深度需求分析，输出业务需求分析文档。
+读取用户提供的业务需求描述（或已有需求文档），按照八步分析法（七步写入文档 + 模拟评审内部执行）完成深度需求分析，输出业务需求分析文档。
 
 ## 输入
 
@@ -73,7 +73,7 @@ $ARGUMENTS
   - 可以是自然语言描述（如"我们需要一个客户管理模块"）
   - 也可以是文件路径（如 `docs/00-customer-requirements/crm/客户需求.md`）
   - 如果输入为空，提示用户输入需求描述
-- **模板文件**: `.adspecs/templates/01-业务需求分析模板.md` — 业务需求分析输出模板（六步结构）
+- **模板文件**: `.adspecs/templates/01-业务需求分析模板.md` — 业务需求分析输出模板（七章结构）
 - **业务功能架构文档**: `{ARCH_DIR}/01-*_business_scenarios.md` 或 `{ARCH_DIR}/01-*_business_architecture.md` — 用于识别需求所属的二级模块（子模块）
 - **项目上下文**（可选）:
   - `CLAUDE.md` — 项目技术架构、模块结构
@@ -126,8 +126,8 @@ $ARGUMENTS
    - 如果 `$ARGUMENTS` 为空 → 使用 **AskUserQuestion** 工具提示用户输入需求描述
 
 2. **加载模板**：
-   - 读取 `.adspecs/templates/01-业务需求分析模板.md`，获取六步分析法的完整结构
-   - 如果模板不存在，使用内置的分析结构（见下方"七步分析法"，其中第六步为 skill 内部模拟评审，不写入模板）
+   - 读取 `.adspecs/templates/01-业务需求分析模板.md`，获取模板七章结构的完整骨架
+   - 如果模板不存在，使用内置的分析结构（见下方"八步分析法"，其中第七步为 skill 内部模拟评审，不写入模板）
 
 3. **加载项目上下文**（可选）：
    - 如果 `CLAUDE.md` 存在，读取以了解项目背景
@@ -191,9 +191,9 @@ $ARGUMENTS
 
      **注意**: 不要在功能目录下创建 `feature.json` 文件——所有功能追踪统一在 `.adspecs/feature.json` 中管理。
 
-## 七步分析法
+## 八步分析法
 
-> **注意**：模板 `01-业务需求分析模板.md` 包含六步结构（一~六）。本 skill 在六步基础上额外执行**第六步·模拟需求评审**（skill 内部分析），评审结论融入第七步最终决策。输出文档按模板的六步结构组织，评审发现体现在「最终输出与决策」的风险和成熟度评估中。
+> **注意**：模板 `01-业务需求分析模板.md` 包含七章结构（一~七），其中"五、业务对象说明"仅按单据类/主数据/枚举类分类列出对象名称与一句话简述，不展开属性（属性与 OBJ 编号在 `02` 第 5 部分定义）。本 skill 在七章基础上额外执行**第七步·模拟需求评审**（skill 内部分析），评审结论融入第八步最终决策。输出文档按模板的七章结构组织，评审发现体现在「最终输出与决策」的风险和成熟度评估中。
 
 ### 一、真实问题分析
 
@@ -291,7 +291,28 @@ $ARGUMENTS
 - 状态机至少包含 3 个状态
 - 如果流程涉及多角色协作（如提交→审批），必须明确交接点
 
-### 五、异常和边界场景
+### 五、业务对象说明
+
+**目标**：厘清本需求涉及的业务对象全景，为流程描述和后续 PRD 提供统一的对象口径；本步只做对象清单，不展开属性。
+
+**分析步骤**：
+
+1. **对象识别**：从需求描述、场景清单和业务流程中提取所有涉及的业务对象
+
+2. **对象分类**（与 `02`-产品需求说明书第 5 部分口径一致）：
+   - 单据类对象：伴随业务事件产生、有生命周期状态流转的业务单据
+   - 主数据对象：相对稳定、被多个单据/流程引用的基础资料
+   - 枚举类对象：取值范围固定的分类/状态标识（一个枚举类对象对应一类取值集合，如"单据状态"）
+
+3. **清单输出**：每个对象一行，按模板 5.2 清单格式输出对象名称、对象类型和一句话简述
+
+**输出要求**：
+
+- 覆盖需求涉及的全部核心业务对象（单据 + 其引用的主数据 + 状态/类型枚举）
+- **不列出**对象的具体属性、字段与关联关系（在 `02`-产品需求说明书第 5 部分定义）
+- 分类拿不准的对象标注 `[待确认：对象分类]`
+
+### 六、异常和边界场景
 
 **目标**：穷举可能遗漏的异常场景，防止上线后出问题。
 
@@ -318,7 +339,7 @@ $ARGUMENTS
 - 每个异常场景给出预期系统行为
 - 不确定的异常处理标注 `[待确认：异常处理策略]`
 
-### 六、需求评审
+### 七、需求评审
 
 **目标**：提前暴露需求盲点，减少后续返工。
 
@@ -349,7 +370,7 @@ $ARGUMENTS
 - 问题必须基于当前需求分析的具体内容，不能是泛泛的模板问题
 - 评审结论表汇总所有问题的解决状态
 
-### 七、最终输出与决策
+### 八、最终输出与决策
 
 **目标**：通过 10 项质量检查验证分析完整性，给出需求成熟度判断和下一步建议。
 
@@ -366,9 +387,9 @@ $ARGUMENTS
    | 5   | 用户在什么场景下使用？         | ✅/⚠️/❌ | 三·3.1     | 【高频+低频场景是否已拆解，触发条件是否明确】            |
    | 6   | 完整业务流程是什么？           | ✅/⚠️/❌ | 四·4.1     | 【主流程每一步的操作者、动作、输入输出是否清晰】         |
    | 7   | 每一步涉及哪些状态变化？       | ✅/⚠️/❌ | 四·4.2     | 【状态机是否已梳理，流转条件和约束是否明确】             |
-   | 8   | 有哪些异常和边界场景？         | ✅/⚠️/❌ | 五·5.1     | 【是否从操作/系统/数据/权限/网络/并发等多角度覆盖】      |
-   | 9   | 研发、测试可能会质疑什么？     | ✅/⚠️/❌ | 六（评审） | 【模拟评审是否提出了有针对性的尖锐问题】                 |
-   | 10  | 上线后用什么指标判断有效？     | ✅/⚠️/❌ | 六·6.2     | 【是否定义了可度量的成功标准（业务指标/性能指标）】      |
+   | 8   | 有哪些异常和边界场景？         | ✅/⚠️/❌ | 六·6.1     | 【是否从操作/系统/数据/权限/网络/并发等多角度覆盖】      |
+   | 9   | 研发、测试可能会质疑什么？     | ✅/⚠️/❌ | 七（评审） | 【模拟评审是否提出了有针对性的尖锐问题】                 |
+   | 10  | 上线后用什么指标判断有效？     | ✅/⚠️/❌ | 七·7.2     | 【是否定义了可度量的成功标准（业务指标/性能指标）】      |
 
 2. **通过规则**：
    - **✅ 全部通过**：10 项均为 ✅ → 建议进入 PRD 阶段
@@ -400,9 +421,9 @@ $ARGUMENTS
    - 如果找到，读取并按"执行前检查 · 步骤 4"的规则匹配二级模块编号 `MODULE_ID`
    - 如果未找到或无法自动匹配，按规则处理（用户选择或留空）
 
-### 步骤 2：执行七步分析
+### 步骤 2：执行八步分析
 
-按"七步分析法"逐节完成分析。其中第一~五步和第七步写入输出文档，第六步（需求评审）为 skill 内部分析，评审结论融入第七步的决策。每一节的执行要求：
+按"八步分析法"逐节完成分析。其中第一~六步和第八步写入输出文档，第七步（需求评审）为 skill 内部分析，评审结论融入第八步的决策。每一节的执行要求：
 
 1. **先读模板对应章节**：了解该节需要的输出格式和字段
 2. **分析需求描述**：从用户输入中提取相关信息
@@ -415,7 +436,7 @@ $ARGUMENTS
 - 不要急着给方案，先分析问题本质
 - 每一步的分析结论必须有依据（来自用户输入、项目上下文或合理推断）
 - 如果用户输入信息不足以完成某一节，基于合理推断填写并标注 `[待确认]`
-- 模拟需求评审（第六步）的问题必须基于前 5 步的分析结果，提出有针对性的尖锐问题
+- 模拟需求评审（第七步）的问题必须基于前 6 步的分析结果（含业务对象与异常），提出有针对性的尖锐问题
 
 ### 步骤 3：写入分析文档
 
@@ -439,7 +460,7 @@ $ARGUMENTS
 
 2. **写入文件**：使用 Write 工具将完整的分析文档写入 `OUTPUT_FILE`
    - 文档头部填写模块编号（`MODULE_ID`）、主模块编号（`PARENT_MODULE`）、模块名称、日期等元信息
-   - 按模板结构输出六步分析结果（模拟需求评审的发现融入第六步的风险评估）
+   - 按模板结构输出七章分析结果（模拟需求评审的发现融入「七、最终输出与决策」的风险评估与成熟度判断）
    - 保留模板中的表格格式和章节结构
 
 3. **输出确认信息**：
@@ -453,7 +474,7 @@ $ARGUMENTS
 
 ### 步骤 4：质量检查输出
 
-执行 10 项需求分析质量检查（定义在"七、最终输出与决策"中）：
+执行 10 项需求分析质量检查（定义在"八、最终输出与决策"中）：
 
 1. **逐项验证**：对照 10 项检查清单，逐项标注 ✅/⚠️/❌，并填写补充说明
 2. **关联回溯**：每项检查必须关联到输出文档中对应章节的具体内容，确认不是空占位符
@@ -528,7 +549,7 @@ $ARGUMENTS
 
 ## 输出文件结构
 
-> 输出文档按模板的**六步结构**组织。模拟需求评审（skill 内部第七步）的发现融入「六、最终输出与决策」的风险评估和成熟度判断中，不单独成节。
+> 输出文档按模板的**七章结构**组织。模拟需求评审（skill 内部第七步）的发现融入「七、最终输出与决策」的风险评估和成熟度判断中，不单独成节。
 
 ```markdown
 # 01-业务需求分析：{模块名称}
@@ -578,19 +599,25 @@ $ARGUMENTS
 
 ### 4.3 其他场景流程
 
-## 五、异常和边界场景
+## 五、业务对象说明
+
+### 5.1 对象分类
+
+### 5.2 业务对象清单
+
+## 六、异常和边界场景
 
-### 5.1 异常场景清单
+### 6.1 异常场景清单
 
-### 5.2 边界值检查
+### 6.2 边界值检查
 
-## 六、最终输出与决策
+## 七、最终输出与决策
 
-### 6.1 需求分析质量检查（10 项）
+### 7.1 需求分析质量检查（10 项）
 
-### 6.2 风险与待补充（含评审发现）
+### 7.2 风险与待补充（含评审发现）
 
-### 6.3 决策
+### 7.3 决策
 
 ## 附录：与 02 产品需求说明书的关系
 ```
@@ -600,10 +627,10 @@ $ARGUMENTS
 - [ ] 已解析用户输入（需求描述或文档路径）
 - [ ] 已加载 01-业务需求分析模板
 - [ ] 已扫描 `{ARCH_DIR}/` 并识别匹配的二级模块编号 `MODULE_ID`（或确认为空/用户手动选择）
-- [ ] 七步分析全部完成（真实问题、角色、场景、流程、异常、模拟评审、决策）
+- [ ] 八步分析全部完成（真实问题、角色、场景、流程、业务对象、异常、模拟评审、决策）
 - [ ] 模拟需求评审已在 skill 内部执行（研发/测试/业务三角色提问）
-- [ ] 评审发现已融入「六、最终输出与决策」的风险评估中
+- [ ] 评审发现已融入「七、最终输出与决策」的风险评估中
 - [ ] 10 项质量检查已逐项验证（真实问题 / 问题vs方案 / 核心角色 / 相关角色 / 使用场景 / 业务流程 / 状态变化 / 异常边界 / 研发测试质疑 / 上线指标）
-- [ ] 分析文档已按模板六步结构写入 `{OUTPUT_DIR}/{MODULE_ID}/{MODULE_ID}_{name}_业务需求分析.md`（无模块时写入 `{OUTPUT_DIR}/{name}_业务需求分析.md`）
+- [ ] 分析文档已按模板七章结构写入 `{OUTPUT_DIR}/{MODULE_ID}/{MODULE_ID}_{name}_业务需求分析.md`（无模块时写入 `{OUTPUT_DIR}/{name}_业务需求分析.md`）
 - [ ] 质量检查结果（N/10）和下一步建议已输出
 - [ ] 扩展钩子已根据上述必选执行后钩子规则分发或跳过

package/skills/adspecs-prd/SKILL.md

@@ -166,35 +166,40 @@ $ARGUMENTS
    - spec 目录名称和 git 分支名称是相互独立的 — 它们可能相同但由用户选择
    - spec 目录和文件始终由此命令创建，而非由钩子创建
 
-5. 加载 `.adspecs/templates/02-产品需求说明书模板.md` 以了解所需的结构。
+5. 加载 `.adspecs/templates/02-产品需求说明书模板.md` 并**完整读取**：模板全文是章节骨架、ID 体系与填写格式的唯一权威（速查见下方「模板结构与编写约定」）。若模板文件不存在，仍按「模板结构与编写约定」的 12 部分结构生成，并在完成报告中注明模板缺失。
 
 6. 遵循以下执行流程：
    1. 从参数中解析用户描述
       如果为空：错误 "No feature description provided"
    2. 提取描述中的关键概念
-      识别：角色、操作、数据、约束
+      识别：角色、业务对象、操作、数据、约束
    3. 对于不明确的方面：
       - 基于上下文和行业标准做出合理的推断
       - 仅在以下情况标记为 [NEEDS CLARIFICATION: 具体问题]：
         - 该选择显著影响功能范围或用户体验
         - 存在多种合理的解释且含义不同
         - 没有合理的默认值
+        - §5 业务对象的父子/引用关系"删除或作废时如何处理"无明确业务依据（禁止自行推断）
       - **限制：最多 3 个 [NEEDS CLARIFICATION] 标记**
       - 按影响排序澄清优先级：范围 > 安全/隐私 > 用户体验 > 技术细节
-   4. 填写用户场景与测试部分
+   4. 按模板第 2 部分组织用户故事与验收场景：
+      - 每个用户故事含唯一编号 `US-{n}`、优先级（P1 最高，按用户旅程重要性排序）、故事描述（作为[角色]，我想要[功能]，以便于[价值]）、为何赋予此优先级、独立测试说明、前置/后置条件
+      - 每个故事必须可独立开发/测试/部署/演示（即使只实现它，也应构成有价值的最小可用产品）
+      - 验收场景拆分为独立单行条目并编号 `US-{n}-AC{n}`，格式：**[场景标题]**: **Given** [初始状态]，**When** [操作]，**Then** [预期结果]
       如果没有清晰的用户流程：错误 "Cannot determine user scenarios"
-   5. 生成功能需求
+   5. 生成功能需求（内容落入模板第 3~4 部分：业务场景及流程、功能描述）
       每个需求必须是可测试的
       对未明确的细节使用合理的默认值（在假设部分记录假设）
       按模块拆分，每个模块包含：触发条件、展示内容、操作规则、系统反馈。避免‘便捷、智能’等抽象词。涉及字段时列出名称、含义、来源
-   6. 定义成功标准
+   6. 定义成功标准（落入模板第 7 部分验收标准：不设独立 ID，通过"关联用户故事/关联业务规则"归约到 `US-{n}`/`BR-{n}`）
       按功能模块生成可验证的验收标准。格式：场景/操作/预期结果。覆盖正常、异常、权限、边界情况。
       创建可度量、与技术无关的成果
       包括量化指标（时间、性能、容量）和定性测量（用户满意度、任务完成率）
       每个标准必须可在不知道实现细节的情况下验证
-   7. 识别关键实体（如果涉及数据）
-   8. 状态流转（待处理、处理中、已完成等）必须清晰列出进入/离开条件、触发人、前端展示、通知机制等
-   9. 异常处理表类似：异常场景、触发条件、用户可见内容、系统处理方式、重试机制、数据保存策略等
+   7. 识别关键实体（如果涉及数据）并整理为模板第 5 部分业务对象说明：
+      先按单据类/聚合子/主数据/枚举类分类标注，再按 OBJ 结构（§5.1）或枚举结构（§5.2）输出业务属性、关联对象与参照完整性约束
+   8. 状态流转（待处理、处理中、已完成等）必须清晰列出进入/离开条件、触发人、前端展示、通知机制等——对应模板 §3.4 状态机（状态图 + 状态转换规则矩阵 + 状态说明表）与 §4.3 后置状态变更
+   9. 异常处理表类似：异常场景、触发条件、用户可见内容、系统处理方式、重试机制、数据保存策略等——对应 §4.3 异常处理；本期无法闭环的事项转入第 11 部分风险清单 `R-{n}` 与待确认问题清单 `Q-{n}`
    10. 返回：成功（spec 可进入计划阶段）
 
 7. 使用模板结构将规格说明书写入 `SPEC_FILE`，用从功能描述（参数）派生的具体细节替换占位符，同时保留章节顺序和标题。
@@ -219,21 +224,52 @@ $ARGUMENTS
 
    ## 需求完整性
 
+   **通用项**
    - [ ] 无 [NEEDS CLARIFICATION] 标记残留
    - [ ] 需求可测试且无歧义
-   - [ ] 验收标准可验证可度量
-   - [ ] 验收标准与技术无关（无实现细节）
-   - [ ] 所有验收场景已定义
-   - [ ] 状态流转是否完整（进入/离开/展示/通知）
-   - [ ] 异常和边界情况已识别且场景是否穷举主要情况
-   - [ ] 范围界限清晰
-   - [ ] 功能描述是否具体到研发可直接实现
+   - [ ] 范围界限清晰（§1.3 不包含项逐条列出并标注归属模块）
    - [ ] 依赖和假设已识别
-   - [ ] 权限、数据、兼容性是否说明
-   - [ ] 风险与待确认项是否列出
-   - [ ] 一级模块名称和编号是否与 `docs\10-architecture\01-*_business_scenarios.md` 中对应的模块对齐一致性检查
+   - [ ] 异常和边界情况已识别且穷举主要情况
+   - [ ] 功能描述具体到研发可直接实现
+   - [ ] 一级/二级模块名称和编号与架构文档（`01-*_business_architecture.md` / `01-*_business_scenarios.md`）§2.1 模块清单、§2.2 子模块清单一致
    - [ ] 二级菜单/模块划分合理性检查
 
+   **用户故事与验收（§2、§7）**
+   - [ ] 用户故事含 `US-{n}` 编号、优先级（P1 最高）与独立测试说明
+   - [ ] 验收场景拆为独立单行 Given-When-Then 条目并编号 `US-{n}-AC{n}`
+   - [ ] 验收标准可验证、可度量且与技术无关（§7 不设独立 ID，归约到 `US-{n}`/`BR-{n}`）
+
+   **场景与流程（对应 M4，§3）**
+   - [ ] 每个端到端流程都有完整的流程说明（流程目标/参与角色/步骤表）并配套 Mermaid 流程图
+   - [ ] 流程步骤之间的每一处衔接均明确标注"同步等待"或"异步触发"（衔接类型强制必填）
+   - [ ] 对文档中出现的每一个核心单据，均显式回答"是否需要审批"（明确回答"不需要"同样须显式记录，禁止留空）
+   - [ ] 每个审批流都有完整的审批节点、通过/驳回后的状态流转说明，并配套 Mermaid 流程图
+   - [ ] 状态流转完整（进入/离开条件、触发人、展示/通知机制；§3.4 状态机含状态图 + 转换规则矩阵 + 状态说明表）
+
+   **业务功能（对应 M2、M3，§4.3）**
+   - [ ] 每个业务功能均明确操作角色、主操作对象、引用的关联对象
+   - [ ] 每个业务功能均说明了前置条件
+   - [ ] 每个业务功能均明确区分"后置状态变更"与"下游触发"两个独立字段（下游触发注明衔接类型与所在流程）
+   - [ ] 每个业务功能引用的业务规则，均有独立的规则条目定义（§3.2 `BR-{n}`），而非仅在文字中提及
+   - [ ] 业务规则均标注规则类型（校验类/计算类/推导类/转换类），编号写在规则标题后括号内
+   - [ ] 同一条业务规则被多个功能引用时，已合并为同一 `BR-{n}` 并列出全部引用方
+   - [ ] 输入/输出数据、特殊处理、异常处理等 §4.3 其余字段完整
+
+   **业务对象（对应 M1，§5）**
+   - [ ] 全部业务对象已做单据类/聚合子对象/主数据/枚举类的分类标注并赋 `OBJ-{业务域缩写}-{三位序号}`
+   - [ ] 每个对象的业务属性均说明了类型、长度/精度、是否必填、是否唯一、引用对象
+   - [ ] 每一对存在父子或引用关系的对象，均明确回答"父对象删除/作废时子对象如何处理"（级联处理或独立保留二选一，不允许遗漏或 AI 推断）
+
+   **岗位角色（对应 M5，§1.4、§6）**
+   - [ ] 已列出业务涉及的全部岗位角色
+   - [ ] 每个角色的功能权限完整列出（§6.1 权限矩阵）
+   - [ ] 对每一个查询/列表类功能，在每个相关角色下均明确填写了数据范围说明（§6.2 数据权限；无限制也需显式写明）
+
+   **全局**
+   - [ ] §11.2 待确认问题清单中不存在"待确认"状态的条目
+   - [ ] 风险与待确认项已以 `R-{n}`/`Q-{n}` 表列出（§11）
+   - [ ] 文档中未出现任何 UI/UE 交互层面的描述（页面布局、控件、点击路径等；UI/交互规格由 /adspecs-front-spec 承接）
+
    ## 功能就绪
 
    - [ ] 所有功能需求有清晰的验收标准
@@ -296,6 +332,48 @@ $ARGUMENTS
 
    d. **更新检查清单**: 在每次验证迭代后，以当前的通过/失败状态更新检查清单文件
 
+## 模板结构与编写约定
+
+模板 v2.3（`02-产品需求说明书模板.md`）是 `SPEC_FILE` 章节骨架的唯一权威：**12 个部分、固定顺序、标题层级照抄**，将各部分占位符替换为本次需求的真实内容。逐部分产出要点：
+
+| 部分 | 标题 | 产出要点 | 可选性 |
+| ---- | ---- | -------- | ------ |
+| 第1部分 | 需求概览 | 文档头（版本/创建日期/修订日期/所属模块/数据标准）＋基本信息/背景/范围（"不包含"项须标注归属模块）/涉及角色 | 必填 |
+| 第2部分 | 用户故事 | `US-{n}` 故事（优先级排序、独立测试、前置/后置条件）＋单行 Given-When-Then 验收场景 `US-{n}-AC{n}` | 必填 |
+| 第3部分 | 业务场景及流程 | §3.1 端到端流程（目标/参与角色/步骤表/流程图）＋审批流；§3.2 业务规则；§3.3 业务数据；§3.4 状态机 | 必填（§3.4 仅在存在状态流转时） |
+| 第4部分 | 功能描述 | §4.1 功能清单 `P{模块}-{子模块}-{序号}`、§4.2 结构树（ASCII）、§4.3 每个功能详细说明 | 必填 |
+| 第5部分 | 业务对象说明 | 对象分类＋`OBJ-{业务域缩写}-{三位序号}` 结构（§5.1）/枚举结构（§5.2） | 涉及数据时必填 |
+| 第6部分 | 权限要求 | §6.1 功能权限（每行对应 `PERM-{n}`）、§6.2 数据权限（隔离维度/角色数据范围） | 必填 |
+| 第7部分 | 验收标准 | 归约到 `US-{n}`/`BR-{n}`，无独立 ID；§7.2 非功能验收；§7.3 已知问题或限制 | 必填 |
+| 第8部分 | 参考资料 | 相关文档/相关功能/外部依赖（含异常策略表）/备注 | 按需 |
+| 第9部分 | 术语表 | 核心业务术语（术语/英文/定义/备注） | 按需 |
+| 第10部分 | 假设与约束 | 需求假设/业务约束/技术约束 | 必填 |
+| 第11部分 | 风险与待确认问题 | `R-{n}` 风险清单、`Q-{n}` 待确认问题清单（关联章节/确认方/状态闭环） | 必填 |
+| 第12部分 | 变更记录 | 追加一行（版本/日期/变更人/变更内容），版本号递增 | 必填 |
+
+### 编号约定（以模板「全链路 ID 体系约定」表为准）
+
+- **PRD 编写阶段由 AI 自动赋予**：`US-{n}`、`US-{n}-AC{n}`、`PROC-{业务域缩写}-{三位序号}`、`BR-{n}`、`OBJ-{业务域缩写}-{三位序号}`；业务域缩写由需求内容确定，在 PROC/OBJ 间保持一致。
+- `BR-{n}` 写在规则标题后括号内，如 `规则1: 到货必检制度 (BR-01)`；§4.3 各功能通过"涉及的业务规则"引用已赋编号。
+- `FUNC-{n}`（§4.1 三级编号深度优先映射）与 `PERM-{n}`（权限矩阵每行）由**需求分析阶段**映射/赋予——PRD 编写阶段不预设这两种编号。
+- 功能编号 `P{模块}-{子模块}-{序号}`：一级/二级模块名称与编号必须与 `docs/10-architecture/` 下 `01-*_business_architecture.md`（或 `01-*_business_scenarios.md`）§2.1 模块清单、§2.2 子模块清单**严格一致**（如 P05 仓储物流管理 → P05-01 原辅材料仓库）；无法归入清单模块时向用户确认或标注新模块。
+- 模板正文示例中的编号（如 FUNC-CON-001、RULE-CON-001）仅为演示占位，实际取值以上述 ID 体系约定为准。
+
+### 强制条款（模板中带"必须/不允许"语义的约束）
+
+1. 所有流程图一律 **Mermaid 源代码**输出（顺序/分支用 `flowchart TD`、审批流配合菱形判断节点、跨角色时序可选 `sequenceDiagram`），禁止图片或其他绘图工具格式。
+2. §3.1 每个端到端业务流程必须包含：流程目标、流程参与角色、流程步骤表（步骤/步骤描述/引用的业务功能/衔接类型/分支条件）＋ Mermaid 流程图。
+3. 步骤表"衔接类型"为**强制必填项**，取值仅两种：**同步等待**（结果直接驱动下一步，失败则流程在此中断）／**异步触发**（完成后产生业务事件，允许延迟响应，失败不影响已达成结果）——它直接决定下游 ME 事件建模，撰写和自查时必须重点检查。
+4. §3.1 每个核心业务单据必须显式回答"是否需要人工审批"：需要→按审批流结构输出（适用单据/触发条件/审批节点表/流程图）；不需要→**显式记录**如 `OBJ-CON-001 合同：无需审批，录入后直接生效`，**禁止留空**（留空视为信息缺失而非"无审批"的确认结果）。
+5. §3.2 业务规则必须标注**规则类型**（校验类/计算类/推导类/转换类），填写校验失败提示、适用场景与示例；同一条规则被多个业务功能引用时必须识别为同一条、合并为单一 BR 编号并列出全部引用方（规则复用强制检查），不允许重复定义。
+6. §5 撰写前先对全部业务对象做**分类标注**（单据类/聚合子/主数据/枚举类）；枚举类按 §5.2 取值列表输出，其余按 §5.1 结构输出（对象分类/说明/生命周期状态/业务属性表/关联的聚合子对象/关联的其他业务对象/参照完整性约束），属性引用列使用 OBJ 编号。
+7. §5 **关联关系强制确认**：对任何存在父子或引用关系的业务对象，必须回答"父对象删除或作废时如何处理"，答案仅两种——**级联处理**（组合关系）／**独立保留**（聚合关系）。此决策不能由 AI 从名称或描述自行推断（不同企业的答案可能相反）；没有明确业务依据时计入 [NEEDS CLARIFICATION] 向用户确认，**不允许留空**。
+8. §4.3 每个功能详细说明必填：操作角色、主操作对象、引用的关联对象、前置条件、功能描述、用户操作流程、输入/输出数据、涉及的业务规则、后置状态变更、下游触发（注明衔接类型与所在流程）、特殊处理、异常处理。
+9. §7 验收标准不设独立 ID，每条通过"关联用户故事/关联业务规则"归约到 `US-{n}`/`BR-{n}`；§7.2 非功能验收标准（性能/安全/兼容/可用）给出量化指标。
+10. §11 风险编号 `R-{n}`、问题编号 `Q-{n}` 在章节内递增，不与其它章节 ID 冲突；状态流转：开放 → 已缓解/已确认 → 已关闭。
+
+> 各部分的表格结构、字段细节与填写示例以模板原文为准——生成时必须完整加载模板；本节仅用于编写与质量自查时的快速对照。
+
 ## 必选执行后钩子
 
 **必须在向用户报告完成之前完成本节。**
@@ -354,8 +432,9 @@ $ARGUMENTS
 
 ### 章节要求
 
+- **章节骨架**: 模板 v2.3 的第 1~12 部分为固定骨架；`SPEC_FILE` 保持各部分标题与顺序不变（对照「模板结构与编写约定」），仅替换占位符内容
 - **必填章节**: 每个功能必须完成
-- **可选章节**: 仅在与功能相关时包含
+- **可选章节**: 仅在与功能相关时包含（如 §3.4 状态机仅在存在状态流转时填写）
 - 当某个章节不适用时，完全删除它（不要留下 "N/A"）
 
 ### AI 生成指南