@guanlin4924/devflow-pi 0.1.86 → 0.1.89

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

@@ -488,14 +488,6 @@ steps:
       - requirement-feasibility-review
     inputs:
       - ".planning/PROJECT.md"
-      - ".planning/requirements/{feature}/入口分诊.md"
-      - ".planning/requirements/{feature}/决策地图.md"
-      - ".planning/requirements/{feature}/领域模型记录.md"
-      - ".planning/requirements/{feature}/可实现性审查.md"
-      - ".planning/requirements/{feature}/入口分诊.meta.json"
-      - ".planning/requirements/{feature}/决策地图.meta.json"
-      - ".planning/requirements/{feature}/领域模型记录.meta.json"
-      - ".planning/requirements/{feature}/可实现性审查.meta.json"
       - ".planning/navigation/INDEX.md"
     outputs:
       - path: ".planning/requirements/baseline.md"
@@ -504,9 +496,6 @@ steps:
       - path: ".planning/requirements/{feature}/traceability.json"
         type: requirement-traceability
         required: true
-      - path: ".planning/requirements/{feature}/governance.json"
-        type: requirement-governance-graph
-        required: true
     meta_output:
       path: ".planning/requirements/baseline.meta.json"
       fields:
@@ -524,8 +513,6 @@ steps:
         risks: { type: array, required: false }
         key_decisions: { type: array, max: 5, required: false }
         traceability_status: { type: string, required: true }
-        graph_revision: { type: integer, required: true }
-        governance_graph_sha256: { type: string, required: true }
     checkpoint: CP-1
 
   - id: wireframe-proposal
@@ -538,7 +525,9 @@ steps:
     inputs:
       - ".planning/requirements/baseline.md"
       - ".planning/requirements/{feature}/traceability.json"
-      - ".planning/features/{feature}/questions.yaml"
+      - path: ".planning/features/{feature}/questions.yaml"
+        required: false
+        required_at_entry: false
     outputs:
       - path: ".planning/features/{feature}/proposal.yaml"
         type: wireframe-proposal
@@ -556,7 +545,9 @@ steps:
       - wireframe-proposal
     inputs:
       - ".planning/features/{feature}/proposal.yaml"
-      - ".planning/features/{feature}/questions.yaml"
+      - path: ".planning/features/{feature}/questions.yaml"
+        required: false
+        required_at_entry: false
       - ".planning/requirements/{feature}/traceability.json"
     outputs:
       - path: ".planning/features/{feature}/canonical.json"
@@ -600,7 +591,9 @@ steps:
     inputs:
       - ".planning/features/{feature}/canonical.json"
       - ".planning/features/{feature}/wireframe-validation.meta.json"
-      - ".planning/features/{feature}/questions.yaml"
+      - path: ".planning/features/{feature}/questions.yaml"
+        required: false
+        required_at_entry: false
       - ".planning/features/{feature}/wireframes/preview.md"
       - ".planning/features/{feature}/wireframes/flow.svg"
       - ".planning/features/{feature}/wireframes/screens"
@@ -619,8 +612,6 @@ steps:
       - requirement-baseline
     inputs:
       - ".planning/requirements/baseline.md"
-      - ".planning/requirements/{feature}/traceability.json"
-      - ".planning/requirements/baseline.meta.json"
       - ".planning/navigation/INDEX.md"
     outputs:
       - path: ".planning/features/{feature}/api-contract.md"
@@ -649,15 +640,8 @@ steps:
     inputs:
       - ".planning/requirements/baseline.md"
       - ".planning/features/{feature}/api-contract.md"
-      - path: ".planning/requirements/{feature}/governance.json"
-        required_at_entry: true
-        producer: "requirement-baseline/devflow_requirement_graph"
-        validation: requirement-graph
-      - path: ".context/static-runtime-context.json"
-        required_at_entry: false
-        required_at_completion: true
-        producer: "devflow_static_runtime_context(action=collect)"
-        validation: static-runtime-context
+      - ".planning/requirements/{feature}/governance.json"
+      - ".context/static-runtime-context.json"
       - ".planning/navigation/INDEX.md"
     outputs:
       - path: ".planning/features/{feature}/architecture-brief.md"
@@ -686,11 +670,12 @@ steps:
     depends_on:
       - api-contract
       - architecture-feasibility
+    allowed_intervening_predecessors:
+      - backend-tech-spec
+      - api-call-guide
     inputs:
       - ".planning/requirements/baseline.md"
       - ".planning/features/{feature}/api-contract.md"
-      - ".planning/features/{feature}/architecture-brief.md"
-      - ".planning/features/{feature}/architecture-brief.meta.json"
       - ".planning/navigation/INDEX.md"
     outputs:
       - path: ".planning/features/{feature}/UI-SPEC.md"
@@ -704,6 +689,9 @@ steps:
     engine_evidence_gate: enforced
     depends_on:
       - ui-spec
+    allowed_intervening_predecessors:
+      - backend-tech-spec
+      - api-call-guide
     inputs:
       - ".planning/requirements/baseline.md"
       - ".planning/features/{feature}/UI-SPEC.md"
@@ -721,6 +709,9 @@ steps:
       - feature-breakdown
       - api-contract
       - architecture-feasibility
+    allowed_intervening_predecessors:
+      - backend-tech-spec
+      - api-call-guide
     inputs:
       - ".planning/features/{feature}/api-contract.md"
       - ".planning/features/{feature}/architecture-brief.md"
@@ -754,6 +745,11 @@ steps:
     depends_on:
       - api-contract
       - architecture-feasibility
+    allowed_intervening_predecessors:
+      - ui-spec
+      - feature-breakdown
+      - frontend-tech-spec
+      - api-supplement
     inputs:
       - ".planning/features/{feature}/api-contract.md"
       - ".planning/features/{feature}/architecture-brief.md"
@@ -782,6 +778,11 @@ steps:
     depends_on:
       - api-contract
       - backend-tech-spec
+    allowed_intervening_predecessors:
+      - ui-spec
+      - feature-breakdown
+      - frontend-tech-spec
+      - api-supplement
     inputs:
       - ".planning/features/{feature}/api-contract.md"
       - ".planning/features/{feature}/后端技术方案.md"
@@ -807,10 +808,12 @@ steps:
     depends_on:
       - frontend-tech-spec
       - api-contract
+    allowed_intervening_predecessors:
+      - backend-tech-spec
+      - api-call-guide
     inputs:
       - ".planning/features/{feature}/api-contract.md"
       - ".planning/features/{feature}/前端技术方案.md"
-      - ".planning/features/{feature}/后端技术方案.md"
       - ".planning/features/{feature}/UI-SPEC.md"
     outputs:
       - path: ".planning/features/{feature}/api-supplement-requests.md"
@@ -839,7 +842,6 @@ steps:
       - ".planning/features/{feature}/前端技术方案.md"
       - ".planning/features/{feature}/后端技术方案.md"
       - ".planning/features/{feature}/api-supplement-requests.md"
-      - ".planning/features/{feature}/architecture-brief.meta.json"
     outputs:
       - path: ".planning/features/{feature}/integration-report.md"
         type: integration-report
@@ -904,6 +906,7 @@ steps:
       - ".planning/features/{feature}/UI-SPEC.md"
       - ".planning/features/{feature}/前端技术方案.md"
       - ".planning/features/{feature}/后端技术方案.md"
+      - ".planning/features/{feature}/功能点梳理.md"
       - ".planning/toolchain.md"
     outputs:
       - path: ".planning/features/{feature}/验收测试设计.md"
@@ -918,6 +921,12 @@ steps:
       - path: ".planning/features/{feature}/完整API验收测试用例.md"
         type: api-test-cases-view
         required: true
+      - path: ".planning/features/{feature}/测试指导书.md"
+        type: test-guide
+        required: true
+      - path: ".planning/features/{feature}/api-acceptance-bindings.template.json"
+        type: api-acceptance-bindings-template
+        required: true
     meta_output:
       path: ".planning/features/{feature}/验收测试设计.meta.json"
       fields:

package/plugins/devflow-core/skills/workflow-pipeline/SKILL.md

@@ -28,21 +28,27 @@ pipeline 本身不包含执行规则——所有门禁、CP 协议、失败分
 | 7 | domain-modeling | 领域模型 |
 | 8 | requirement-feasibility-review | 可实现性审查 |
 | 10 | requirement-baseline | 需求基线 |
+| 11 | wireframe-proposal | 线框提案 |
+| 12 | wireframe-validate | 线框校验 |
+| 13 | wireframe-render | 线框渲染 |
+| 14 | wireframe-review | 线框审查 |
 | 15 | api-contract | API 契约（分叉前共同事实） |
 | 18 | architecture-feasibility | 架构可行性与方案比较（分叉前共同事实） |
 | 20 | ui-spec | Track B：UI 设计规范 |
 | 30 | feature-breakdown | Track B：功能点梳理 |
-| 40 | backend-tech-spec | Track A：后端方案 |
-| 45 | api-call-guide | Track A：API 调用指南 |
-| 50 | frontend-tech-spec | Track B：前端方案 |
+| 40 | frontend-tech-spec | Track B：前端方案 |
+| 50 | backend-tech-spec | Track A：后端方案 |
+| 55 | api-call-guide | Track A：API 调用指南 |
+| 56 | api-supplement | API 补充 |
 | 58 | integration-verify | Merge Gate：契约/后端/前端三方一致性验证 |
+| 59 | acceptance-test-design | 验收测试设计 |
 | 60 | change-plan | 变更清单 |
 | 70 | phase-structure | Phase 结构初始化 |
 | 80 | execute | 代码执行 |
 | 84 | code-index-refresh | 刷新机器代码索引并审查 |
 | 85 | code-review | 代码审查（完成标准验证） |
 | 86 | generate-mainflow-cases | 主流程自动化用例生成 |
-| 90 | run-acceptance-tests | 冻结 TC 验收执行 |
+| 88 | run-acceptance-tests | 冻结 TC 验收执行 |
 | 100 | release-closeout | 验收通过后的版本收口与里程碑归档 |
 
 - **`--track A`**：后端/API 轨道产物模式。可跑 `requirement-triage → requirement-wayfinder → domain-modeling → requirement-feasibility-review → requirement-baseline → api-contract → architecture-feasibility → backend-tech-spec → api-call-guide`，但不能自动进入 `integration-verify / change-plan / execute`。
@@ -89,7 +95,7 @@ devflow_state(action="inspect")
 | `blocked` | 将阻塞原因报告给用户 |
 | `workflow_complete` | 报告完成，流程结束 |
 
-**降级策略**：如果 `inspect_state.rb` 不可用或 `.planning/STATE.md` 缺少 YAML front matter，回退到手动读取 `.planning/pipeline-state.md`，并提示用户运行 `init_state.rb`。
+**降级策略**：`.planning/STATE.md` 是唯一规范状态源。如果 `inspect_state.rb` 不可用或 STATE 缺少 YAML front matter，报告主流程阻塞并提示运行 `init_workflow.rb --write`、`init_state.rb --write` 修复控制面；不要读取已废弃的 `.planning/pipeline-state.md` 作为状态来源。
 
 ### 轨道参数传递
 

package/plugins/devflow-core/skills/workflow-pipeline/references/pipeline-flow.md

@@ -6,7 +6,7 @@ workflow-pipeline 启动
          ▼
 ┌─────────────────────────────────────┐
 │ Step 0: 断点检测                     │
-│ 读取 pipeline-state.md 恢复进度      │
+│ 读取 STATE.md + inspector 恢复进度   │
 └─────────────────────────────────────┘
          │
          ▼
@@ -129,13 +129,13 @@ workflow-pipeline 启动
 
 ## 断点续接
 
-每次启动时，workflow-pipeline 先读 `.planning/pipeline-state.md`：
+每次启动时，workflow-pipeline 通过 `devflow_state(action="inspect")` 读取规范状态文件 `.planning/STATE.md`，由 inspector 返回当前动作和下一节点：
 
 ```
-1. 解析 state 文件
-2. 跳过所有 done 的步骤
-3. 从第一个 pending/in_progress 的步骤继续
-4. 如果 state 文件不存在，从头开始
+1. 校验 `.planning/STATE.md` 的 YAML front matter、workflow 配置和 artifact registry
+2. 根据 inspector 返回的 `action` 路由到下一步、当前步骤、确认、失败分支或并行窗口
+3. 如果控制面缺失或校验失败，报告阻塞并提示运行 `init_workflow.rb --write`、`init_state.rb --write` 修复
+4. `.planning/pipeline-state.md` 已废弃，不作为恢复状态来源
 ```
 
 ## 简化流程门禁

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

@@ -74,7 +74,22 @@ description: "Use after workflow-integration-verify has passed or produced an ap
 
 同时输出 `.planning/features/{feature}/test-bindings.json`。这是受控的任务—验收用例绑定。生成时它必须使用 `schema_version: 2` 与 `candidate_test_suite: { graph_revision, fingerprint }`，并通过 `test_task_binding_check.py --feature {feature} --stage candidate --json`。每个代码任务必须关联一个或多个候选 `TC-*`，并指定 `tdd_required`、`contract_first`、`integration_only` 或 `manual_justified` 测试模式；非 TDD 模式必须说明原因。`tdd_required` 还必须给出同一测试目标的 RED/GREEN 命令、RED 的预期失败标记、回归命令和生产代码路径。CP-3 会在同一次确认中核验候选绑定、冻结 TC 并写入 Core attestation；之后执行阶段以 `--stage frozen` 校验。所有 Core 实际执行的命令必须是无 shell 的 argv，且 runner 已在初始化生成的 `.planning/toolchain.md` 中被发现；不能用 `python -c`、`node -e` 或任意脚本解释器绕过。
 
-同时输出 `.planning/features/{feature}/变更清单.meta.json`。只有 `traceability_check.py --stage change-plan` 成功时才允许写入 `traceability_status: "passed"`；`uncovered_requirement_count` 和 `orphan_task_count` 必须为 0。
+同时输出 `.planning/features/{feature}/变更清单.meta.json`。只有 Core 随包提供的 `traceability_check.py --file .planning/requirements/{feature}/traceability.json --stage change-plan` 成功时才允许写入 `traceability_status: "passed"`；`uncovered_requirement_count` 和 `orphan_task_count` 必须为 0。
+
+`变更清单.meta.json` 必须在顶层同时写入以下字段（不能只放在嵌套对象中）：
+
+```json
+{
+  "test_case_count": 6,
+  "test_coverage_status": "candidate",
+  "candidate_test_suite_graph_revision": 66,
+  "candidate_test_suite_fingerprint": "<tests.json.view_meta.fingerprint>"
+}
+```
+
+其中数值必须从当前 `.planning/requirements/{feature}/tests.json` 读取，禁止手填旧 revision 或旧 fingerprint。
+
+`test-bindings.json` 必须由 Core 随包提供的 `test_task_binding_check.py --feature {feature} --stage candidate --json` 校验通过。`candidate_test_suite` 必须严格只包含 `graph_revision` 和 `fingerprint` 两个字段，不能附加 `test_case_count` 或 `source`。每个 `implementation_tests` 项必须包含项目相对 `path`；非 `tdd_required` 任务必须在任务顶层提供 `non_tdd_reason`，`manual_justified` 还必须提供 `owner`。校验器的字段名是 `tc_refs`、`implementation_tests` 和 `tdd.red/green/regression`；不能使用旧格式的 `test_cases`、`red_command`、`green_command` 或 `regression_command`。`origin` 必须为 `devflow_change_plan`。
 
 ## 输出结构
 

package/plugins/devflow-implementation/skills/workflow-change-plan/references/output-template.md

@@ -18,7 +18,9 @@
 >
 > 完成标准在执行阶段由 `code_review` 门禁自动逐条验证。每条标准必须描述**可通过静态代码分析验证的具体条件**（精确到类名/方法名/字段名/返回值/文件行），不得使用"确保功能正确"、"用户体验良好"等模糊描述。标准模糊的条目将被标记为 `⚠️ UNVERIFIABLE`，无法通过自动化验证。
 
-> **验收测试绑定：** 除 Markdown 外，必须生成 schema v2 的 `test-bindings.json`。它将每个任务绑定到候选 `TC-*`，并以 `candidate_test_suite: { graph_revision, fingerprint }` 固定候选测试意图；它必须通过 `test_task_binding_check.py --stage candidate`。CP-3 在同一次用户确认中验证该绑定、冻结 TC，并写入 Core-owned `test-suite-freeze.json`；之后才可按 `--stage frozen` 进入执行。所有 `tdd_required` 任务必须声明相同测试目标的 RED/GREEN 命令、RED 失败标记、回归命令与生产代码路径。
+> **变更计划 meta：** `.planning/features/{功能名}/变更清单.meta.json` 顶层必须包含 `test_case_count`、`test_coverage_status`、`candidate_test_suite_graph_revision`、`candidate_test_suite_fingerprint`，值来自当前 `tests.json`，不能只放在嵌套对象中。
+>
+> **验收测试绑定：** 除 Markdown 外，必须生成 schema v2 的 `test-bindings.json`。它将每个任务绑定到候选 `TC-*`，任务字段必须使用 `tc_refs`、`implementation_tests` 和 `test_mode`；`tdd_required` 使用 `tdd.red/green/regression`。文件必须声明 `origin: devflow_change_plan`，并以 `candidate_test_suite: { graph_revision, fingerprint }` 固定候选测试意图；它必须通过 Core 随包提供的 `test_task_binding_check.py --feature <功能名> --stage candidate --json`。CP-3 在同一次用户确认中验证该绑定、冻结 TC，并写入 Core-owned `test-suite-freeze.json`；之后才可按 `--stage frozen` 进入执行。所有 `tdd_required` 任务必须声明相同测试目标的 RED/GREEN 命令、RED 失败标记、回归命令与生产代码路径。
 
 ---
 

package/plugins/devflow-quality/agents/code-reviewer.md

@@ -13,6 +13,12 @@ autoloadSkills:
   - code-review
 ---
 
-Review the actual diff and its affected call paths. Prefer concrete defects over style commentary. For each finding provide severity, file and location, triggering scenario, impact, and a minimal fix direction. Verify whether tests cover the failure.
+Review the actual diff and its affected call paths. Prefer concrete defects over style commentary. Treat the parent agent's task summary as scope guidance, never as acceptance authority: verify each expected behavior against confirmed Core requirements/contracts or an explicit human decision, then independently read the relevant source and test evidence at fixed revisions. For each finding provide severity, authoritative expectation reference, source file and location, triggering scenario, impact, evidence status, and a minimal fix direction. Verify whether tests cover the failure. If an essential business fact is absent or conflicting, stop and return the exact question requiring human confirmation; do not infer a clean result.
 
 Do not edit code, fix findings, or mutate workflow state. If no actionable finding remains, say so and list the validation evidence inspected.
+
+When invoked for the Devflow `code-review` step, return exactly one JSON object suitable for `devflow_review_run`: `target`, `expectations`, `review_plan`, `observations`, and `coverage_evidence`. Include concrete source hashes, lines, excerpts, and Core test-case references where required. Do not wrap the JSON in Markdown or add prose. If a required fact cannot be established, include an explicit `review_questions` array; never invent evidence or output a `clean` claim. The runtime binds this exact output to the named task before Core will consume it.
+
+For a second or third round, preserve the previous `chain_id` in the JSON output. P0/P1 findings must reference already-frozen Core test-case `data.review_impact` and `data.review_trigger` values exactly; do not create or amend those facts during review. If either fact is absent or ambiguous, ask for human confirmation.
+
+For each required review surface, scenario, and plan question, bind a distinct passed, frozen Core test case in `coverage_evidence`. For non-standard tags, the frozen test case must explicitly contain that tag in `data.review_coverage_tags`; otherwise report the coverage gap for human confirmation. Do not fabricate tags or repurpose an unrelated test case to make coverage appear complete.

package/plugins/devflow-quality/skills/code-review/SKILL.md

@@ -5,6 +5,16 @@ description: "Use when code needs review for project conventions, spec complianc
 
 # 代码规范审查技能
 
+## Devflow 工作流中的正式审查协议
+
+当本技能用于 `feature-development` 的 `code-review` 步骤时，下列协议优先于本文后续的普通 Markdown 报告流程：
+
+1. 主 Agent 先读取当前 Core 契约并调用 `devflow_review_preflight`。只有 `ready` 才用 `task` 显式指定 `devflow-code-reviewer`；`human_confirmation` 或 `core_contract_conflict` 必须停下并上报。
+2. 审查 task 只读，独立回读已确认的 Core 图事实、变更清单、索引、实际源码和测试结果。任务输出必须是 `code-reviewer.md` 约定的单个 JSON 对象；主 Agent 不得代写、修改或自报 `clean`。
+3. 主 Agent 用 `devflow_review_submit` 提交该 task 的原始输出。Core 绑定 task 身份、固化审查轮次、派生 `REVIEW.md`，并给出门禁裁决。普通 Markdown 文件、主 Agent 摘要和未经绑定的 `devflow_review_run` 调用都不能使门禁通过。
+4. 若需修复后复审，在下一轮 task 中携带上一轮 `chain_id`，最多三轮。第三轮仍有 P0 时停止当前任务；事实不足时停止并请求人工确认。每轮重新验证源码、契约和证据版本，不复用旧结论。
+5. 主 Agent 向用户交付门禁裁决、证据链、开放 finding 与下一步动作。本文后续的规范扫描和检查清单仍用于审查内容，但其“输出 Markdown”要求仅适用于独立调用本技能，不覆盖正式工作流协议。
+
 逐层对照 `.context/spec/` 规范文档，检查目标代码的合规性，输出可操作的问题清单。若项目存在 `.context/spec/index.md`，先按索引匹配 stack spec 和 codebase spec，再加载具体层级规范。
 
 ## 核心原则

package/plugins/devflow-quality/skills/workflow-gen-test-guide/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: workflow-gen-test-guide
+description: "根据功能点梳理和需求基线生成检查点树形态的测试指导书。规则来源为外部 workflow-pipeline-skills。"
+---
+
+# 测试指导书适配器
+
+本步骤使用仓库内随包分发的旧版测试指导规则作为生成规则来源：
+
+`legacy/SKILL.md`
+
+该目录包含旧版 Skill 所需的完整 `references/` 和 `assets/`。禁止依赖
+任何机器本地绝对路径；换机器、全局安装或打包后必须仍能读取这些资源。
+
+必须先读取 `legacy/SKILL.md`，再按其中引用的相对 `references/`、`assets/` 规则生成：
+
+`.planning/features/{feature}/测试指导书.md`
+
+当前 Devflow 输入路径映射如下（旧版 Skill 的 WORKSPACE_ROOT 逻辑已由适配器显式映射）：
+
+- `.planning/requirements/baseline.md`
+- `.planning/features/{feature}/功能点梳理.md`
+- `.planning/PROJECT.md`
+- `.planning/navigation/INDEX.md`
+
+旧版 Skill 中的旧目录和外部 PRD URL 约定不能直接写入项目；以本适配器列出的
+`.planning/` 路径为准。若旧版资源要求读取不存在的文档，必须在“待确认/缺少内容”分支记录，不得伪造文件或事实。
+
+该步骤只生成检查点树文档，不生成或修改 Core 所有的 `tests.json`、`api-test-matrix.json`、需求图谱和验收测试冻结事实。结构化 `TC-*` 测试仍由后续 `workflow-acceptance-test-design` 负责。
+
+输出必须满足：
+
+- 叶子节点是可核对的一句话检查点；
+- 按测试视角、功能模块、组件、状态/维度组织；
+- 覆盖需求基线和功能点梳理；
+- 对无法确认的内容明确放入待确认或缺少内容分支；
+- 不伪造测试执行结果。