@guanlin4924/devflow-pi 0.1.14 → 0.1.16

package/plugins/devflow-core/skills/workflow-orchestrator/scripts/validate_state.rb

@@ -6,6 +6,7 @@ require "optparse"
 require "yaml"
 require_relative "control_io"
 require_relative "phase_ownership"
+require_relative "requirement_graph"
 
 module WorkflowStateValidator
   REQUIRED_STATE_FIELDS = %w[
@@ -76,6 +77,26 @@ module WorkflowStateValidator
     validate_completed_outputs(issues, root, state, step_by_id, completed_ids, artifact_by_path, strict_artifact_status)
     validate_waiting_checkpoint(issues, root, state, step_by_id, artifact_by_path, strict_artifact_status)
     validate_current_in_progress_output_drift(issues, root, state, step_by_id, artifact_by_path)
+    graph_gate = workflow.dig("governance", "requirement_graph_gate").to_s
+    governed_steps = %w[requirement-baseline api-contract integration-verify change-plan execute verify]
+    # A historical completed state is never rolled back solely because it has
+    # no v2 graph/evidence. Its first new governed step, however, must satisfy
+    # the new contract before it can advance.
+    strict_requirement_graph = graph_gate == "enforced" && (governed_steps.include?(state["current_step"]) || completed_ids.any? { |id| governed_steps.include?(id) })
+    observe_requirement_graph(issues, root, state, strict: strict_requirement_graph)
+    # Migration is intentionally non-destructive: pre-v2 completed steps are
+    # visible as unattested, never rewritten, rolled back, or auto-rerun.
+    if state["governance_started_revision"].nil?
+      legacy_steps = completed_ids.select { |id| governed_steps.include?(id) }
+      if legacy_steps.any?
+        issues << issue(
+          "warning",
+          "legacy_unattested",
+          "Historical governed steps predate Evidence Pack v2 and are report-only",
+          steps: legacy_steps
+        )
+      end
+    end
 
     ok = issues.none? { |entry| entry["severity"] == "error" }
     result(ok, state_path, workflow_path, registry_path, issues)
@@ -263,6 +284,43 @@ module WorkflowStateValidator
     end
   end
 
+  # P1 observation mode: existing projects must not become invalid merely
+  # because they predate governance graphs. Once a graph exists, surface its
+  # structural failures through state inspection so operators can fix them
+  # before the corresponding checkpoint is upgraded to fail-closed.
+  def observe_requirement_graph(issues, root, state, strict: false)
+    path, relative = RequirementGraph.graph_path(root, state["current_feature"])
+    unless File.exist?(path)
+      issues << issue(strict ? "error" : "warning", "requirement_graph_missing", "Requirement governance graph is missing", path: relative) if strict
+      return
+    end
+
+    graph, = RequirementGraph.load_graph(root, state["current_feature"])
+    errors = RequirementGraph.validate(graph)
+    if errors.any?
+      issues << issue(
+        strict ? "error" : "warning",
+        "requirement_graph_observe_failed",
+        "Requirement governance graph has structural gaps (observation mode)",
+        path: relative,
+        graph_revision: graph["revision"],
+        errors: errors
+      )
+    end
+    return if Array(graph["stale"]).empty?
+
+    issues << issue(
+      strict ? "error" : "warning",
+      "requirement_graph_needs_recheck",
+      "Requirement governance graph has downstream nodes awaiting recheck (observation mode)",
+      path: relative,
+      graph_revision: graph["revision"],
+      stale: graph["stale"]
+    )
+  rescue ArgumentError => error
+    issues << issue("warning", "requirement_graph_observe_failed", error.message)
+  end
+
   def validate_step_outputs(issues, root, state, step, artifact_by_path, strict_artifact_status, waiting_checkpoint)
     Array(step["outputs"]).each do |output|
       next unless output["required"]
@@ -324,6 +382,7 @@ module WorkflowStateValidator
     validate_frontend_tech_spec_gate(issues, step, data)
     validate_api_supplement_gate(issues, step, data)
     validate_integration_merge_gate(issues, step, data)
+    validate_change_plan_gate(issues, step, data)
     validate_verification_gate(issues, step, data)
   rescue JSON::ParserError => e
     issues << issue("error", "invalid_meta_json", e.message, step: step["id"], path: path)
@@ -423,6 +482,10 @@ module WorkflowStateValidator
 
       issues << issue("error", "baseline_blocking_counter_nonzero", "Requirement baseline has a non-zero blocking counter", step: step["id"], field: field, count: data[field])
     end
+
+    if data["traceability_status"] != "passed"
+      issues << issue("error", "baseline_traceability_not_passed", "Requirement traceability must pass before technical design", step: step["id"], status: data["traceability_status"])
+    end
   end
 
   def validate_api_contract_gate(issues, step, data)
@@ -436,6 +499,10 @@ module WorkflowStateValidator
       issues << issue("error", "api_contract_pending_items", "API contract has unresolved pending contract items", step: step["id"], count: data["pending_contract_count"])
     end
 
+    if data["traceability_status"] != "passed"
+      issues << issue("error", "api_contract_traceability_not_passed", "API contract must retain complete requirement traceability", step: step["id"], status: data["traceability_status"])
+    end
+
     api_required = data["api_required"]
     endpoint_count = data["endpoint_count"].to_i
     if api_required == false && endpoint_count.positive?
@@ -515,6 +582,10 @@ module WorkflowStateValidator
       issues << issue("error", "merge_gate_not_passed", "Integration merge gate status is not passed", step: step["id"], status: data["merge_gate_status"])
     end
 
+    if data["traceability_status"] != "passed"
+      issues << issue("error", "integration_traceability_not_passed", "Integration gate requires complete requirement-to-design traceability", step: step["id"], status: data["traceability_status"])
+    end
+
     %w[
       contract_backend_mismatch_count
       contract_frontend_mismatch_count
@@ -527,6 +598,20 @@ module WorkflowStateValidator
     end
   end
 
+  def validate_change_plan_gate(issues, step, data)
+    return unless step["id"] == "change-plan"
+
+    if data["traceability_status"] != "passed"
+      issues << issue("error", "change_plan_traceability_not_passed", "Change plan requires complete requirement-to-task traceability", step: step["id"], status: data["traceability_status"])
+    end
+
+    %w[uncovered_requirement_count orphan_task_count].each do |field|
+      next if data[field].to_i.zero?
+
+      issues << issue("error", "change_plan_traceability_counter_nonzero", "Change plan has unresolved traceability coverage", step: step["id"], field: field, count: data[field])
+    end
+  end
+
   def validate_verification_gate(issues, step, data)
     return unless step["id"] == "verify"
 

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

@@ -13,6 +13,40 @@ phase_scope:
   failure_branch_enabled: true
   parallel_window_enabled: true
 
+# P2 preset: new work fail-closes at the defined checkpoints. Existing STATE
+# files without governance_started_revision remain legacy_unattested and are
+# only reported until their next newly-started governed step.
+governance:
+  requirement_graph_gate: enforced
+  enforced_checkpoints:
+    - CP-1
+    - CP-API
+    - CP-2
+    - CP-3
+  step_checkers:
+    requirement-baseline:
+      - requirement-graph-check
+      - slice-independence-check
+      - acceptance-coverage-check
+      - change-impact-check
+    api-contract:
+      - requirement-graph-check
+      - contract-coverage-check
+      - change-impact-check
+    integration-verify:
+      - requirement-graph-check
+      - slice-independence-check
+      - contract-coverage-check
+      - change-impact-check
+    change-plan:
+      - requirement-graph-check
+      - slice-independence-check
+      - contract-coverage-check
+      - change-impact-check
+    verify:
+      - acceptance-coverage-check
+      - change-impact-check
+
 artifact_registry:
   source: ".planning/artifacts/index.yaml"
   path_key: path
@@ -126,6 +160,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 +173,7 @@ checkpoints:
       - code_reality_missing_count
       - current_feature
       - depends_on_count
+      - traceability_status
     summary_fields:
       - fp_count
       - br_count
@@ -146,9 +182,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 +233,7 @@ checkpoints:
       - contract_frontend_mismatch_count
       - unhandled_api_supplement_count
       - blocking_issue_count
+      - traceability_status
     summary_fields:
       - merge_gate_status
       - api_required
@@ -203,7 +241,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 +254,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 +424,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 +443,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 +469,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 +637,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/requirement-feasibility-review/SKILL.md

@@ -204,6 +204,10 @@ Before accepting the rebuttal or retracting the finding, re-open the cited raw s
 
 ## Quality Bar
 
+## Governance Graph Candidate
+
+Submit `risk` and `decision` candidates through `devflow_requirement_graph`, and add missing `behavior` candidates only when backed by a cited source. A `pass` review cannot promote candidates, clear stale nodes, or claim machine validation; it supplies structured candidates and evidence for the Core gate and human checkpoint.
+
 The review must make it easy to trace every conclusion back to evidence. Include:
 
 - flow inventory and critical capability chains;

package/plugins/devflow-requirements/skills/workflow-domain-modeling/SKILL.md

@@ -130,6 +130,10 @@ Accepted
 
 ## Meta Output
 
+## Governance Graph Candidate
+
+Submit bounded candidates through `devflow_requirement_graph`: use `term` for shared language and `behavior` for actor, precondition, state transition, invariant, writes, side effects, failure, and recovery. Link candidates only with returned IDs. Never directly edit the canonical graph or mark a node confirmed; unresolved ownership remains a candidate and is reported in metadata.
+
 `领域模型记录.meta.json` minimum fields:
 
 ```json

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:
 
@@ -718,6 +727,10 @@ Completion gate: baseline and baseline.meta.json are written and contain no unre
 
 ### 7.4 产物完整性检查
 
+### 7.4.1 Governance Graph Candidate
+
+Before claiming baseline readiness, submit `requirement`、`rule`、`boundary`、`slice` and `acceptance` candidates through `devflow_requirement_graph`. Each requirement candidate must cite source IDs and reference behavior/acceptance IDs returned by the writer. Run `devflow_requirement_graph(action="validate")` and record its result in baseline metadata. Do not directly create `governance.json`, allocate IDs, or set candidate status to `confirmed`.
+
 ```markdown
 - [ ] 每个原始需求映射到 FP-*/BR-*/BC-* 或 out-of-scope
 - [ ] 追溯表完整，来源→FP 映射可验证

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

@@ -191,6 +191,10 @@ Ask at most one question, only when route cannot be decided without it. If the n
 
 ## Completion Rule
 
+## Governance Graph Candidate
+
+Before completion, inspect `devflow_requirement_graph` for the current feature. Submit only `source` or `code` candidate deltas for source material and repository facts discovered here. Read the returned graph revision after every accepted delta. Do not invent stable IDs, set a candidate to `confirmed`, or write `governance.json` directly.
+
 Only tell `workflow-orchestrator` to complete `requirement-triage` after writing:
 
 ```json

package/src/cli.ts

@@ -14,7 +14,7 @@ function usage(): string {
     "  devflow-pi init [project]",
     "  devflow-pi doctor [project]",
     "  devflow-pi usage [project]",
-    "  devflow-pi [project] [--resume [session-id]] [--prompt <text>] [--mcp]",
+    "  devflow-pi [project] [--resume [session-id]] [--prompt <text>] [--mcp] [--yolo]",
   ].join("\n");
 }
 
@@ -76,6 +76,7 @@ async function main(): Promise<void> {
     originalOmpAgentDir,
     resume: optionalOption(args, "--resume"),
     enableMCP: args.includes("--mcp"),
+    approvalMode: args.includes("--yolo") ? "yolo" : "write",
   });
 }
 

package/src/runtime.ts

@@ -13,6 +13,7 @@ export interface RuntimeOptions {
   hasUI?: boolean;
   enableMCP?: boolean;
   enableLsp?: boolean;
+  approvalMode?: "write" | "yolo";
 }
 
 const MANAGED_SETTINGS: Record<string, unknown> = {
@@ -54,7 +55,6 @@ const MANAGED_SETTINGS: Record<string, unknown> = {
   "lsp.enabled": true,
   "lsp.lazy": true,
   "lsp.diagnosticsOnWrite": true,
-  "tools.approvalMode": "write",
 };
 
 export async function createEmbeddedRuntime(project: ProjectContext, options: RuntimeOptions = {}) {
@@ -92,6 +92,7 @@ export async function createEmbeddedRuntime(project: ProjectContext, options: Ru
     agentDir: productAgentDir,
     overrides: {
       ...MANAGED_SETTINGS,
+      "tools.approvalMode": options.approvalMode ?? "write",
       // OMP 17.2.7 classifies extension-package skills behind the generic
       // third-party toggle. Explicit custom roots keep ambient providers off
       // while guaranteeing the packaged Devflow skills are present.