adspecs 0.1.35 → 0.1.36

package/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
     {
       "name": "adspecs",
       "description": "AI Coding研发协同开发插件",
-      "version": "0.1.35",
+      "version": "0.1.36",
       "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.36",
   "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.36",
   "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.36",
   "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.36",
   "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.36",
   "description": "AI first 工程规范驱动开发插件 — 支持 npm 安装和 CLI 初始化",
   "bin": {
     "adspecs": "bin/adspecs.js"

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 生成指南