@guanlin4924/devflow-pi 0.1.13 → 0.1.15

package/plugins/devflow-core/skills/workflow-orchestrator/templates/feature-development.yaml

@@ -126,6 +126,7 @@ checkpoints:
     producing_step: requirement-baseline
     required_outputs:
       - ".planning/requirements/baseline.md"
+      - ".planning/requirements/{feature}/traceability.json"
     required_meta_output: ".planning/requirements/baseline.meta.json"
     required_meta_fields:
       - review_status
@@ -138,6 +139,7 @@ checkpoints:
       - code_reality_missing_count
       - current_feature
       - depends_on_count
+      - traceability_status
     summary_fields:
       - fp_count
       - br_count
@@ -146,9 +148,10 @@ checkpoints:
       - critical_image_missing_count
       - challenge_pending_count
       - code_reality_missing_count
+      - traceability_status
       - key_decisions
       - risks
-    prompt: "确认需求基线是否准确完整，并允许进入 UI/功能拆解和技术方案阶段。"
+    prompt: "确认需求基线和需求追溯清单均完整；每个 REQ 都有六维验收定义，并允许进入 UI/功能拆解和技术方案阶段。"
     confirm_options:
       - approve
       - needs_fix
@@ -196,6 +199,7 @@ checkpoints:
       - contract_frontend_mismatch_count
       - unhandled_api_supplement_count
       - blocking_issue_count
+      - traceability_status
     summary_fields:
       - merge_gate_status
       - api_required
@@ -203,7 +207,8 @@ checkpoints:
       - contract_frontend_mismatch_count
       - unhandled_api_supplement_count
       - blocking_issue_count
-    prompt: "确认 API 契约、后端方案、前端调用三方一致，并允许进入变更清单。"
+      - traceability_status
+    prompt: "确认 API 契约、后端方案、前端调用三方一致，且所有 REQ 都已有设计覆盖，并允许进入变更清单。"
     confirm_options:
       - approve
       - needs_fix
@@ -215,13 +220,19 @@ checkpoints:
     producing_step: change-plan
     required_outputs:
       - ".planning/features/{feature}/变更清单.md"
+      - ".planning/features/{feature}/变更清单.meta.json"
+    required_meta_output: ".planning/features/{feature}/变更清单.meta.json"
+    required_meta_fields:
+      - traceability_status
+      - uncovered_requirement_count
+      - orphan_task_count
     summary_fields:
       - task_count
       - ddl_count
       - migration_steps
       - verification_steps
       - risks
-    prompt: "确认变更清单中的 DDL、代码任务、上线步骤和验收标准可执行，并允许进入代码执行。"
+    prompt: "确认变更清单中的 DDL、代码任务、上线步骤和验收标准可执行；每项 REQ 都有任务、每项任务都有 REQ 来源，并允许进入代码执行。"
     confirm_options:
       - approve
       - needs_fix
@@ -379,6 +390,9 @@ steps:
       - path: ".planning/requirements/baseline.md"
         type: requirement-baseline
         required: true
+      - path: ".planning/requirements/{feature}/traceability.json"
+        type: requirement-traceability
+        required: true
     meta_output:
       path: ".planning/requirements/baseline.meta.json"
       fields:
@@ -395,6 +409,7 @@ steps:
         pending_items: { type: array, required: false }
         risks: { type: array, required: false }
         key_decisions: { type: array, max: 5, required: false }
+        traceability_status: { type: string, required: true }
     checkpoint: CP-1
 
   - id: api-contract
@@ -420,6 +435,7 @@ steps:
         breaking_change_count: { type: integer, required: true }
         permission_rule_count: { type: integer, required: true }
         error_case_count: { type: integer, required: true }
+        traceability_status: { type: string, required: true }
     checkpoint: CP-API
 
   - id: ui-spec
@@ -587,6 +603,12 @@ steps:
       - path: ".planning/features/{feature}/变更清单.md"
         type: change-plan
         required: true
+    meta_output:
+      path: ".planning/features/{feature}/变更清单.meta.json"
+      fields:
+        traceability_status: { type: string, required: true }
+        uncovered_requirement_count: { type: integer, required: true }
+        orphan_task_count: { type: integer, required: true }
     checkpoint: CP-3
 
   - id: phase-structure

package/plugins/devflow-core/skills/workflow-orchestrator/templates/traceability.json

@@ -0,0 +1,23 @@
+{
+  "schema_version": 1,
+  "feature": "{feature}",
+  "requirements": [
+    {
+      "id": "REQ-001",
+      "title": "原子且可验收的需求",
+      "status": "confirmed",
+      "scope": "in",
+      "dimensions": {
+        "input": "输入、前置条件与参数",
+        "output": "输出、持久化或界面结果",
+        "behavior": "正常业务语义",
+        "orchestration": "遍历、触发、顺序、并发或调度；无则写 N/A",
+        "failure": "异常、兼容、幂等、资源限制；无则写 N/A",
+        "verification": "可执行的验收证据"
+      }
+    }
+  ],
+  "designs": [],
+  "tasks": [],
+  "verification": []
+}

package/plugins/devflow-design/skills/workflow-api-contract/SKILL.md

@@ -27,11 +27,14 @@ description: "Use after requirement-baseline, before dual-track fork. Defines sh
 - `.planning/features/{功能名}/api-contract.md`
 - `.planning/features/{功能名}/api-contract.meta.json`
 
+The meta file must also set `traceability_status: "passed"` only after every API design has been written to `traceability.json.designs` and `traceability_check.py --stage design` succeeds; otherwise set `failed` and do not advance.
+
 ## 输入
 
 - `.planning/requirements/baseline.md` — 需求基线（FP/BR/BC）
 - `.planning/navigation/INDEX.md` 和相关 codebase navigation — 粗定位已有接口
 - `.planning/code-index/`（如存在）— 查询已有 route/handler/API symbol 与 `routes_to` / `calls` 关系，确认接口复用和冲突
+- `.planning/requirements/{feature}/traceability.json` — 每个接口必须回指它的 `REQ-*`，不能只写 FP 标题
 
 使用 code-index 时，必须回读 `evidence_path:evidence_line` 附近源码后再把既有接口写入契约；不得只凭 Markdown navigation 或 relation 摘要判断。
 
@@ -39,7 +42,7 @@ description: "Use after requirement-baseline, before dual-track fork. Defines sh
 
 1. **只定义接口契约，不谈实现细节** — 不写数据表结构、不写具体代码、不写业务流程内部逻辑
 2. **分叉后不变更** — 一旦确定，Track A/B 都基于此契约工作。变更走 `api-supplement` 异常路径
-3. **接口签名必须完整** — 包括 endpoint、method、请求参数（含类型约束）、响应结构（含状态码）
+3. **接口签名必须完整** — 包括 endpoint、method、请求参数（含类型约束）、响应结构（含状态码）、错误契约与行为语义（过滤、排序、权限、幂等/兼容规则）
 4. **数据模型共享** — 核心业务实体定义在这里，前后端共用一个数据模型
 5. **切片对齐** — 若 baseline 包含 `SL-*`，先读取 `skill://workflow-pipeline/references/slice-safety-guide.md`，只为当前执行切片定义 API。后置切片接口不得提前进入契约。
 6. **既有接口优先查事实索引** — 当 `.planning/code-index/` 存在时，先用 Symbol/Relation 定位候选接口、调用方和处理器，再读取源码证据；缺失或过期时再按 navigation 和 `rg` 兜底。

package/plugins/devflow-design/skills/workflow-backend-tech-spec/SKILL.md

@@ -42,6 +42,10 @@ allowed-tools:
 
 # 后端技术方案生成器
 
+## 需求追溯硬约束
+
+读取 `.planning/requirements/{feature}/traceability.json`。每个设计章节必须列 `覆盖 REQ: REQ-*`；定时任务、批处理、导入和通知至少拆为“编排（扫描/触发/锁/重试）”与“业务算法（判定/计算/写入）”两个可独立验证的小节。不得把遍历全部活跃组织、发送通知、文件解析等编排事实藏在算法描述中。
+
 根据需求基线和项目现有代码，生成聚焦于影响分析的后端技术方案。
 
 ## 核心原则

package/plugins/devflow-design/skills/workflow-frontend-tech-spec/SKILL.md

@@ -47,6 +47,10 @@ allowed-tools:
 
 # 前端技术方案生成器
 
+## 需求追溯硬约束
+
+读取 `.planning/requirements/{feature}/traceability.json`。每个页面、状态流、缓存/竞态处理和接口调用必须列出 `覆盖 REQ: REQ-*`；API 调用必须写请求参数、响应消费、错误处理和行为语义，不能只列响应字段或视觉改动。
+
 根据需求基线和前端现有代码，生成前端技术方案文档。
 
 ## 核心原则

package/plugins/devflow-design/skills/workflow-integration-verify/SKILL.md

@@ -34,6 +34,7 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 {
   "api_required": true,
   "merge_gate_status": "passed",
+  "traceability_status": "passed",
   "contract_backend_mismatch_count": 0,
   "contract_frontend_mismatch_count": 0,
   "unhandled_api_supplement_count": 0,
@@ -50,6 +51,7 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 - `.planning/features/{功能名}/后端技术方案.md` — Track A 产出的后端方案
 - `.planning/features/{功能名}/api-supplement-requests.md` —（可选）Track B 提交的 API 补充需求
 - `.planning/code-index/`（如存在）— 用于抽查 API route/handler、frontend API calls、imports/calls 关系，并回读源码 evidence
+- `.planning/requirements/{feature}/traceability.json` — 原子 REQ 的唯一追溯源
 
 ## 核心原则
 
@@ -107,6 +109,13 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 - 可以用已有接口拼吗？
 - 必须新增的对 Track A 影响多大？
 
+### Step 5：需求→设计闭环（不可跳过）
+
+1. 将后端、前端、UI、API 契约中的设计项写入 `traceability.json.designs`，每项以 `requirements: ["REQ-…"]` 回指来源。
+2. 所有 API 类型设计必须在 `contract` 中同时写 `request`、`response`、`errors`、`behavior`；禁止只对齐响应字段。
+3. 执行 `python3 <workflow-orchestrator>/scripts/traceability_check.py --file .planning/requirements/{feature}/traceability.json --stage design`。
+4. 结果不为 passed 时，`merge_gate_status` 必须为 failed，`blocking_issue_count` 必须大于 0，回到对应方案修复；不得进入变更清单。
+
 ## 产出模板
 
 ```
@@ -169,4 +178,5 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 - [ ] 验证结论已写入报告
 - [ ] meta.json 中 `merge_gate_status` 为 `passed`
 - [ ] meta.json 中所有 mismatch / supplement / blocking 计数均为 0
+- [ ] `traceability_check.py --stage design` 通过，且 meta.json 的 `traceability_status` 为 `passed`
 - [ ] 无 API 变更时生成 no-op meta，`api_required` 为 false，`merge_gate_status` 为 `skipped`

package/plugins/devflow-implementation/skills/workflow-change-plan/SKILL.md

@@ -58,6 +58,7 @@ description: "Use after workflow-integration-verify has passed or produced an ap
 5. 读取功能点梳理（如存在）→ 确认 FP 覆盖完整性
 6. 读取 baseline.md 的审查结论和风险标记
 7. 若输入包含 `SL-*` 切片计划，读取 `skill://workflow-pipeline/references/slice-safety-guide.md`，只生成当前执行切片的任务。后置切片只能写入风险/后续范围，不得生成实现任务。
+8. 读取 `.planning/requirements/{feature}/traceability.json`；它是任务覆盖判断的唯一 REQ 清单，不能仅凭技术方案标题推断覆盖。
 
 ### 第二阶段：扫描项目上下文
 
@@ -70,6 +71,8 @@ description: "Use after workflow-integration-verify has passed or produced an ap
 
 输出到 `.planning/features/{feature}/变更清单.md`。
 
+同时输出 `.planning/features/{feature}/变更清单.meta.json`。只有 `traceability_check.py --stage change-plan` 成功时才允许写入 `traceability_status: "passed"`；`uncovered_requirement_count` 和 `orphan_task_count` 必须为 0。
+
 ## 输出结构
 
 ```markdown
@@ -109,6 +112,7 @@ description: "Use after workflow-integration-verify has passed or produced an ap
 - **参考实现**：`path/to/similar/file.py:line`（有则填写）
 - **Code Index 证据**：相关 symbol/relation/evidence（有 `.planning/code-index/` 时填写；无则写"未使用：原因"）
 - **需求来源**：FP-001 / BR-001 / 技术方案第X章
+- **REQ 覆盖**：`REQ-001`（必须是 traceability.json 中的原子 ID；无来源任务必须显式标为获批技术债）
 - **Slice**：SL-001
 - **适用规范**：`.context/spec/backend/service.md` 等（有则填写）
 - **相关经验教训**：lesson ID 或"无"
@@ -119,6 +123,7 @@ description: "Use after workflow-integration-verify has passed or produced an ap
 - **完成标准**：（每条必须使用 `- [ ]` checkbox 格式，可被 code_review 门禁自动验证）
   - [ ] 具体可验证的检查项（可映射到代码中具体元素）
   - [ ] 另一条检查项（可映射到验证命令）
+- **六维验收**：输入、输出、行为、编排、失败、验证各写一条可验证结论；算法与遍历/调度等编排必须分列，不能相互替代。
 - **验证命令**：`pytest tests/test_xxx.py -k test_yyy`
 
 ## 四、配置变更
@@ -158,3 +163,6 @@ graph TD
 - [ ] 若 `.planning/code-index/` 存在，涉及已有代码的任务已标注相关 symbol/relation/evidence 或说明未使用原因
 - [ ] 每个任务包含审查要求、适用规范、需求来源字段（至少标注"无"）
 - [ ] 文件路径与技术方案一致
+- [ ] 变更清单任务同步写入 `traceability.json.tasks`，每项包含 `id`、`requirements` 和六维 `acceptance`
+- [ ] 执行 `traceability_check.py --stage change-plan` 通过；没有漏 REQ，也没有无 REQ 来源的任务
+- [ ] 输出 `变更清单.meta.json`，至少包含 `traceability_status: passed`、`uncovered_requirement_count: 0`、`orphan_task_count: 0`

package/plugins/devflow-requirements/skills/workflow-requirement-baseline/SKILL.md

@@ -107,6 +107,15 @@ Always create or update:
 
 - `.planning/requirements/baseline.md` — unified requirement baseline
 - `.planning/requirements/baseline.meta.json` — structured metadata. Schema defined in `feature-development.yaml` under `steps[requirement-baseline].meta_output.fields`: `review_status`, `fp_count`, `br_count`, `bc_count`, `blocking_pending_count`, `critical_image_missing_count`, `challenge_pending_count`, `code_reality_missing_count`, `current_feature`, `depends_on_count`, plus optional `pending_items`, `risks`, and `key_decisions`.
+- `.planning/requirements/{feature}/traceability.json` — copy the orchestrator `templates/traceability.json` schema and create one atomic `REQ-*` record for every confirmed in-scope requirement. Every record must define `input`、`output`、`behavior`、`orchestration`、`failure`、`verification`; use `N/A` only with a reason when a dimension truly does not apply.
+
+Before the CP-1 result is reported, run:
+
+```bash
+python3 <workflow-orchestrator>/scripts/traceability_check.py --file .planning/requirements/{feature}/traceability.json --stage baseline
+```
+
+Set `baseline.meta.json.traceability_status` to `passed` only when that command succeeds. A failed traceability check is a blocking baseline defect, not a deferred documentation suggestion.
 
 Do not create by default: