@guanlin4924/devflow-pi 0.1.105 → 0.1.106

package/plugins/devflow-implementation/skills/workflow-bug-fix/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-bug-fix
 description: "Use when a bug must be traced through workflow artifacts, root-caused, fixed, verified, and captured as a lesson when needed."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 ```yaml

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

@@ -1,8 +1,10 @@
 ---
 name: workflow-change-plan
-description: "Use after workflow-integration-verify has passed or produced an approved no-op report. Generates an AI-executable change list with DDL, code tasks, and rollout steps from the reconciled backend/frontend/API design. This is NOT an API call guide — see workflow-api-call-guide for that."
+description: "Use after workflow-integration-verify, carrying its findings or no-op report into planning. Generates an AI-executable change list with DDL, code tasks, and rollout steps from the reconciled backend/frontend/API design. This is NOT an API call guide — see workflow-api-call-guide for that."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # 变更清单生成器
 
 基于后端/前端技术方案，生成 AI 可直接执行的原子化变更清单，供 execute 阶段使用。

package/plugins/devflow-implementation/skills/workflow-execute-phase/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-execute-phase
 description: "Use when a planned .devflow/planning phase needs implementation, dependency-aware task execution, progress tracking, and verification evidence."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 Original slash-command metadata retained only as workflow invocation guidance.
@@ -128,7 +130,7 @@ The worker must not treat existing code as more authoritative than explicit proj
 When the change list includes task-level `适用规范`, `相关经验教训`, `执行前门禁`, `测试策略`, or `审查要求`, those fields are mandatory execution inputs.
 When the change list includes `需求来源` or `CR-*` decision references, the worker must keep implementation inside those confirmed decisions and mention any deviation before editing.
 
-If a code task lacks a task-level test strategy, planned command, execution command placeholder, skip-automation classification, or frozen `TC-*` binding, the worker must stop before editing and report the task as blocked for change-list backfill. Do not invent a silent testing scope during implementation.
+If a code task lacks a task-level test strategy, planned command, execution command placeholder, skip-automation classification, or frozen `TC-*` binding, the worker records the missing test strategy or binding as an advisory for change-list backfill and continues executable work in soft mode. Do not invent a silent testing scope during implementation.
 </rule_activation_gate>
 
 <execution_discipline>

package/plugins/devflow-intel/skills/code-index-query/SKILL.md

@@ -3,6 +3,8 @@ name: code-index-query
 description: Query a generated .devflow/planning/code-index machine index to answer code structure questions. Use when the OMP development agent needs callers, callees, entrypoint flows, imports, resource reads/writes, tested_by links, or symbol locations before reading source evidence.
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Code Index Query
 
 Use this skill to answer source-structure questions from `.devflow/planning/code-index/`.

package/plugins/devflow-intel/skills/workflow-code-index/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-code-index
 description: Build, refresh, validate, or audit a generic code intelligence index for any project. Use when the OMP development agent needs AST/LSP-style symbol, call, relation, JSONL/SQLite, incremental-change, or other machine-readable code facts before source tracing.
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Workflow Code Index
 
 Build a generic code intelligence index for the current project. This skill is project-agnostic: do not hardcode codebase names, business modules, paths, or language stacks.

package/plugins/devflow-intel/skills/workflow-context-sync/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-context-sync
 description: Execute project-context reconciliation only when the context-sync Stop hook reports CONTEXT_SYNC_REQUIRED, or when the user explicitly requests a context refresh. Consume the hook's changed-file list and Light/Medium/Full verdict, update only the required code index, navigation, or specs, validate, then acknowledge the exact hook session.
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Workflow Context Sync
 
 Use this skill to keep project facts trustworthy after code changes. It is a coordinator, not a new indexing system: classify the change, choose the smallest safe sync level, call existing workflow skills or their deterministic commands, validate, and report.

package/plugins/devflow-intel/skills/workflow-update-navigation/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-update-navigation
 description: "Use when code changes require incremental updates to .devflow/planning/navigation files before audit, archive, or future workflow steps."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 Original slash-command metadata retained only as workflow invocation guidance.
@@ -177,7 +179,7 @@ test -s .devflow/planning/code-index/AUDIT.md  # when the code index exists
 When `.devflow/planning/code-index/` exists, call `devflow_code_index(action="validate")` and
 `devflow_code_index(action="audit")` before the shell artifact checks.
 
-The code-index commands are required only when `.devflow/planning/code-index/` exists or this workflow refreshed it. Pass only when every selected navigation file and `INDEX.md` is non-empty, `validate` and `audit` exit with code 0, and `AUDIT.md` contains no blocking finding. Also complete every Phase 6 checklist item; commands validate artifact integrity, while the checklist validates change-list coverage. If any check fails, do not advance to audit or archive: correct the navigation/index discrepancy and rerun the failed checks.
+The code-index commands are required only when `.devflow/planning/code-index/` exists or this workflow refreshed it. Pass only when every selected navigation file and `INDEX.md` is non-empty, `validate` and `audit` exit with code 0, and `AUDIT.md` contains no blocking finding. Also complete every Phase 6 checklist item; commands validate artifact integrity, while the checklist validates change-list coverage. If any check fails, record the navigation/index discrepancy and suggested rerun as an advisory, then continue to audit or archive with the unresolved findings visible.
 
 ## Downstream Read Contract
 

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

@@ -3,16 +3,18 @@ name: code-review
 description: "Use when code needs review for project conventions, spec compliance, behavioral risks, missing tests, change-list completion criteria verification, or post-refactor validation."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # 代码规范审查技能
 
 ## Devflow 工作流中的正式审查协议
 
 当本技能用于 `feature-development` 的 `code-review` 步骤时，下列协议优先于本文后续的普通 Markdown 报告流程：
 
-1. 主 Agent 先读取当前 Core 契约并调用 `devflow_review_preflight`。只有 `ready` 才用 `task` 显式指定 `devflow-code-reviewer`；`human_confirmation` 或 `core_contract_conflict` 必须停下并上报。
+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 时停止当前任务；事实不足时停止并请求人工确认。每轮重新验证源码、契约和证据版本，不复用旧结论。
+4. 若需修复后复审，在下一轮 task 中携带上一轮 `chain_id`，最多三轮。第三轮仍有 P0 时保留开放问题并结束本轮审查；事实不足时标记待确认，默认允许后续流程携带这些诊断继续。每轮重新验证源码、契约和证据版本，不复用旧结论。
 5. 主 Agent 向用户交付门禁裁决、证据链、开放 finding 与下一步动作。本文后续的规范扫描和检查清单仍用于审查内容，但其“输出 Markdown”要求仅适用于独立调用本技能，不覆盖正式工作流协议。
 
 逐层对照 `.devflow/context/spec/` 规范文档，检查目标代码的合规性，输出可操作的问题清单。若项目存在 `.devflow/context/spec/index.md`，先按索引匹配 stack spec 和 codebase spec，再加载具体层级规范。

package/plugins/devflow-quality/skills/workflow-acceptance-test-design/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-acceptance-test-design
 description: "Use after integration verification and before change planning to derive a frozen, requirement-baseline-driven acceptance test suite (TC-*) for API, page, permission, boundary, resilience, migration, and performance verification."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # 验收测试设计
 
 在代码执行前，基于已确认的需求、契约和架构约束提出独立的 `TC-*` 验收测试候选。测试意图必须独立于实现：禁止读取 `SUMMARY.md`、实现源码、git diff 或 agent 交付自述来决定测试范围。
@@ -62,7 +64,7 @@ description: "Use after integration verification and before change planning to d
 - `manual` 额外写 `manual_reason` 和 `owner`；`blocked` 额外写 `blocked_by` 和 `owner`。
 - `replay`：可用稳定步骤再次触发，必须写 `replay_scope`（`component|page|api|integration`）。页面优先拆到组件、页面、接口或集成边界，不要求 AI 在真实环境盲目重试。
 - `causal`：用于已由 HAR、控制台、DOM 快照、服务日志或请求链路证明首个偏差、但暂不能稳定重放的缺陷。必须写 `causal_evidence_refs`（已有 `SRC-*` / `CODE-*`）和 `first_divergence`；后续执行绑定还必须提供实际证据文件，Core 会哈希留档。没有这些证据不能称为“已证实”。
-- `observation`：用于当前无法重放也无法证明根因的偶发问题。必须写 `observation_plan` 的 `signal`、`owner`、`window`、`alert_condition`，且 `automation_mode` 必须为 `blocked`。它会阻止版本收口，不能被“人工已看过”替代。
+- `observation`：用于当前无法重放也无法证明根因的偶发问题。必须写 `observation_plan` 的 `signal`、`owner`、`window`、`alert_condition`，且 `automation_mode` 必须为 `blocked`。它作为版本收口的未解决风险保留，不自动阻止收口，也不能被“人工已看过”替代为通过。
 - 当 TC 承接结构性专项义务时，额外带对应引用并建立同样的 `verified_by` edge：`api_refs`（API→`api`）、`workload_refs`（WSH/WLC→`performance` 或 `migration`）、`risk_refs`（架构 RISK→`resilience`）。跨数据域的 REQ 必须有 `permission` TC，BC 必须有 `boundary` TC。
 - 页面/API 的具体 selector、endpoint URL、测试数据和 runner 命令属于后续执行绑定，不得改变本步骤的步骤或 oracle。
 - 高风险边界、权限、迁移、外部依赖和工作负载事实必须产生相应 TC；`test-obligation-check` 是机器判定，不接受“无架构影响”的模型自述。环境未准备好只能标记 blocked，不得省略。

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

@@ -3,6 +3,8 @@ name: workflow-gen-test-guide
 description: "根据功能点梳理和需求基线生成检查点树形态的测试指导书。规则来源为外部 workflow-pipeline-skills。"
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # 测试指导书适配器
 
 本步骤使用仓库内随包分发的旧版测试指导规则作为生成规则来源：

package/plugins/devflow-quality/skills/workflow-generate-mainflow-cases/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-generate-mainflow-cases
 description: "Use after code review, as the binding-phase prerequisite of run-acceptance-tests, to compile one deterministic devflow-test-dsl/v1 file per frozen automated ui/api_flow TC, validate the whole generated-cases directory, get an independent AI review, and propose execution_plan approvals for the user."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # 主流程自动化用例生成（Playwright DSL）
 
 为冻结套件中 `automation_mode: automated` 且 `execution_surface` 为 `ui` 或 `api_flow` 的正向主流程 TC 生成确定性的 `devflow-test-dsl/v1`，每个 TC 一个文件，交给 Devflow Playwright Runtime 执行。**这是 `run-acceptance-tests` 的真实前置条件**：没有 DSL 并经用户批准 `execution_plan` 的自动化 ui/api_flow TC 只会 `blocked(dsl_not_approved)`，不能进入收口。不生成异常、边界、权限、安全、性能专项；这些 TC 按 `run-acceptance-tests` 的降级规则处理。

package/plugins/devflow-quality/skills/workflow-human-acceptance/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-human-acceptance
 description: "Use after code review to execute frozen manual TC cases, capture human evidence, submit them as human_result approvals for the user to confirm, and synchronize findings to developers for final acceptance aggregation."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # 人工验收与开发者同步
 
 本步骤在 `code-review` 完成后运行。它只执行冻结套件中 `automation_mode: manual` 的 `TC-*`，并将实际结果、问题和复测要求同步给开发者。不得修改 TC 的步骤、oracle 或范围。自动化 `ui|api_flow` TC 的 DSL 生成与 `execution_plan` 批准属于 `run-acceptance-tests` 的绑定阶段（`workflow-generate-mainflow-cases`），不在本步骤内。

package/plugins/devflow-quality/skills/workflow-regression-test-design/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-regression-test-design
 description: "Use from an idle project to derive a user-confirmed, frozen regression acceptance suite for an existing feature without requiring a requirement baseline."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # 存量功能回归验收测试设计
 
 本步骤为已经上线或已有实现的功能建立可复现的回归验收套件。它不补造需求，也不把当前实现自动宣布为正确；它把代码、代码索引、外部契约和用户确认的现有行为整理为候选 `TC-*`，然后交给 Core 在 CP-3 冻结。

package/plugins/devflow-quality/skills/workflow-release-closeout/SKILL.md

@@ -1,8 +1,10 @@
 ---
 name: workflow-release-closeout
-description: "在冻结需求验收测试全部通过后，执行 Devflow 自有的版本收口与里程碑归档。"
+description: "汇总冻结需求验收测试的真实结果、缺项与风险，执行 Devflow 自有的版本收口与里程碑归档。"
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Devflow 版本收口
 
 ## 目标
@@ -19,19 +21,19 @@ description: "在冻结需求验收测试全部通过后，执行 Devflow 自有
 - `.devflow/planning/STATE.md`
 - `.devflow/planning/navigation/INDEX.md`
 
-## 归档前置条件（全部满足）
+## 归档检查（软门禁）
 
 1. 每个冻结的 `TC-*` 都有执行结果，且结果引用当前测试集 revision/fingerprint。
-2. 不存在 `failed`、`blocked`、未执行或环境缺失的 TC。这是硬门禁：即使默认 soft 模式，Core 在确认/完成 `release-closeout` 时也会重新校验并以 `acceptance_results_not_passed` 拒绝。
+2. 检查是否存在 `failed`、`blocked`、未执行或环境缺失的 TC。Core 在确认/完成 `release-closeout` 时重新校验；默认将 `acceptance_results_not_passed` 记录为 advisory，允许带风险收口。
 3. 变更清单任务已完成，TDD/回归证据已存在或有明确豁免。
 4. `code-index` 已刷新，`AUDIT.md` 通过，索引没有 stale blocker。
 5. 需求基线、架构风险和契约没有未处理的阻塞项。
 
-任何一项不满足，都必须停止收口，返回 `workflow-bug-fix` 或 `workflow-run-acceptance-tests`，不能生成“已完成”归档。
+未满足项写入归档的未解决问题、实际测试结果和后续处理建议，可继续收口；流程完成不表示验收全通过。按需安排 `workflow-bug-fix` 或 `workflow-run-acceptance-tests`。
 
 ## 收口动作
 
-1. 调用 `devflow_run_acceptance_tests(action="validate_results", feature=...)`，让 Core 重新校验 `acceptance-results.json`（suite pins、`execution_surface` 兼容、当前仍有效的 `execution_plan`/`environment_profile`/`human_result`/`mode_override` 批准、运行目录与工件哈希）；运行后 DSL 或 profile 被修改、批准被替换，都会使已记录结果失效，需要回到 `run-acceptance-tests` 重跑；不通过则停止收口。通过后读取该文件（读取即可，不得写入），计算通过/失败/阻塞数量，展示逐 TC 的 `oracle_source`、按来源计数、`legacy_unclassified`、有效降级记录和逐 TC `dsl_approval`。`characterization` 用例只证明行为未变化，不证明正确性。任何 `dsl_approval: none` 必须对应 blocked；若其被标为 passed、结果未全 passed 或存在未批准降级，立即拒绝收口。人工 TC 的 passed 只来自已确认的 `human_result` approval，`human-acceptance-results.json` 草稿不算证据。失败分析和证据读取只依据 `result.json` 与 `acceptance-results.json`；Agent 不得读取 trace、截图、网络工件或 `runtime.log`，这些由用户本地查看（hook 会拒绝 Agent 读取）。
+1. 调用 `devflow_run_acceptance_tests(action="validate_results", feature=...)`，让 Core 重新校验 `acceptance-results.json`（suite pins、`execution_surface` 兼容、当前仍有效的 `execution_plan`/`environment_profile`/`human_result`/`mode_override` 批准、运行目录与工件哈希）；运行后 DSL 或 profile 被修改、批准被替换，都会使已记录结果失效，记录为失效并建议回到 `run-acceptance-tests` 重跑；默认保留警告并继续收口。校验后读取该文件（读取即可，不得写入），计算通过/失败/阻塞数量，展示逐 TC 的 `oracle_source`、按来源计数、`legacy_unclassified`、有效降级记录和逐 TC `dsl_approval`。`characterization` 用例只证明行为未变化，不证明正确性。任何 `dsl_approval: none` 必须对应 blocked；若其被标为 passed、结果未全 passed 或存在未批准降级，记录验收一致性风险，不宣称验收通过。人工 TC 的 passed 只来自已确认的 `human_result` approval，`human-acceptance-results.json` 草稿不算证据。失败分析和证据读取只依据 `result.json` 与 `acceptance-results.json`；Agent 不得读取 trace、截图、网络工件或 `runtime.log`，这些由用户本地查看（hook 默认提示风险，严格模式拒绝读取）。
 2. 更新 `.devflow/planning/navigation/INDEX.md`，记录本次 code-index revision 和验收结果 fingerprint。
 3. 在 `.devflow/planning/milestones/` 写入本版本的 ROADMAP、需求覆盖、测试结果、变更清单和已接受风险摘要。
 4. 更新 `.devflow/planning/PROJECT.md` 的当前版本与下一步目标。

package/plugins/devflow-quality/skills/workflow-run-acceptance-tests/SKILL.md

@@ -3,11 +3,13 @@ name: workflow-run-acceptance-tests
 description: "Execute the frozen TC acceptance suite after code review. Use the requirement baseline and frozen TC nodes for test intent; use current code only to bind execution adapters."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # 冻结验收测试执行
 
 此步骤在代码审查后运行。它的目标是执行冻结的 `TC-*`，而不是根据交付总结重新猜测要测什么。
 
-对 `execution_surface: ui|api_flow` 的自动化 TC，`workflow-generate-mainflow-cases` 是本步骤绑定阶段的**真实前置条件**（不是新的主链步骤，也不是可选的开发者同步）：先用它为每个这类 TC 编译 `.devflow/planning/generated-cases/{feature}/TC-xxxx.json`、校验整个目录、独立 AI 审查并提交逐 TC `execution_plan` 批准。没有 DSL 或没有有效批准的 TC 只能 `blocked(dsl_not_approved)`，不得进入收口。
+对 `execution_surface: ui|api_flow` 的自动化 TC，`workflow-generate-mainflow-cases` 是本步骤绑定阶段的**真实前置条件**（不是新的主链步骤，也不是可选的开发者同步）：先用它为每个这类 TC 编译 `.devflow/planning/generated-cases/{feature}/TC-xxxx.json`、校验整个目录、独立 AI 审查并提交逐 TC `execution_plan` 批准。没有 DSL 或没有有效批准的 TC 只能 `blocked(dsl_not_approved)`，记录原因后可继续带风险收口。
 
 ## 输入边界
 
@@ -27,7 +29,7 @@ description: "Execute the frozen TC acceptance suite after code review. Use the
 
 ## 过程
 
-1. 用 `devflow_acceptance_tests(feature)` 检查测试集已由 CP-3 冻结。若有 stale 或候选 TC，停止并回到需求/测试设计。
+1. 用 `devflow_acceptance_tests(feature)` 检查测试集已由 CP-3 冻结。若有 stale 或候选 TC，记录测试集缺项并建议回到需求/测试设计；继续处理可执行用例，不宣称这些用例已冻结。
 2. 读取冻结 TC 与其 oracle、`oracle_source`/`oracle_evidence`、前置数据、身份、自动化模式和 `execution_surface`。结果与交接报告必须逐 TC 展示 `oracle_source`，并按来源汇总；`characterization` 用例只证明行为未变化。
    对 `api_refs`、`workload_refs` 和 `risk_refs` 指向的专项用例，保留其契约、性能/迁移或韧性义务；没有适配器或环境时必须写为 blocked，不能用普通主流程替代。
 3. 读取代码审查报告、代码索引和实际源码，仅为每个 TC 绑定运行适配器；不得改变 TC 的断言、范围或预期。对每个自动化 `ui|api_flow` TC，若 `generated-cases/{feature}/TC-xxxx.json` 不存在或已过期（TC 重冻结、代码变更），先调用 `workflow-generate-mainflow-cases`；它无法生成的正向 UI/API TC（无稳定 locator、无法准备或隔离数据、纯视觉判断）按下一步降级，异常/边界/权限/性能专项 TC 也不由它生成。
@@ -43,16 +45,16 @@ description: "Execute the frozen TC acceptance suite after code review. Use the
    - 环境阻塞用例必须有 owner 与阻塞源。
    - `evidence_strategy=causal` 的自动用例额外写 `evidence_files`（项目根目录内的 HAR、控制台、DOM 快照、截图或日志文件相对路径）。Core 在执行前校验文件存在且未越出项目根目录，并把内容哈希写入结果；不能只填 Markdown 描述。
    - `evidence_strategy=observation` 只能保持 `blocked`，其观测计划是风险收口输入，不是测试通过证据。
-5. 调用 `devflow_run_acceptance_tests(action="validate", feature=...)`。它校验 adapter 与 `execution_surface` 的兼容矩阵、`devflow_playwright` 禁用键、DSL 存在且合法、`tc_sha256` 与覆盖。不通过时修正绑定，不得绕过。
+5. 调用 `devflow_run_acceptance_tests(action="validate", feature=...)`。它校验 adapter 与 `execution_surface` 的兼容矩阵、`devflow_playwright` 禁用键、DSL 存在且合法、`tc_sha256` 与覆盖。不通过时记录并修正绑定；暂时无法执行的用例保留 blocked，继续其余工作。
 6. 对每个 manual TC，检查用户已在 `/devflow` → “待审批”中确认 `human_result`；Core 按当前 suite fingerprint、`tc_sha256` 和证据哈希重新校验。缺失或失效时保持 blocked。
 7. 调用 `devflow_run_acceptance_tests(action="run", feature=...)`。该 Core 工具执行 automated TC（`devflow_playwright` 在净化环境和独立运行目录中执行，并校验 Runtime 完整性与结果 nonce），合并已校验的 manual TC 结果，并记录命令/证据哈希、退出码、`dsl_approval`、`execution_surface`、`legacy_unclassified` 和降级记录。
-8. 失败、未执行或 blocked 的 TC 只能报告为 `blocked`/`failed`，不得进入版本收口。验收未全 passed 是硬门禁：即使默认 soft 模式，`run-acceptance-tests` 完成和 `release-closeout` 确认时 Core 也会重新校验结果并以 `acceptance_results_not_passed` 拒绝。可用 `devflow_run_acceptance_tests(action="validate_results", feature=...)` 预先检查。该校验会对照当前批准、DSL/profile 哈希与运行目录重新验证每条记录：运行后修改 DSL 或 profile、或批准被新的批准替换，都会使已记录的 passed 失效，必须重跑。
+8. 失败、未执行或 blocked 的 TC 只能报告为 `blocked`/`failed`，可携带风险进入版本收口。验收未全 passed 是软门禁：`run-acceptance-tests` 完成和 `release-closeout` 确认时 Core 重新校验结果，默认以 `acceptance_results_not_passed` 记录 advisory 并允许推进。可用 `devflow_run_acceptance_tests(action="validate_results", feature=...)` 预先检查。该校验会对照当前批准、DSL/profile 哈希与运行目录重新验证每条记录：运行后修改 DSL 或 profile、或批准被新的批准替换，都会使已记录的 passed 失效，必须重跑。
 
-失败分析和证据读取只依据 Runtime 的 `result.json` 与 Core 的 `acceptance-results.json`。Agent 不得读取 trace、截图、网络工件或 `runtime.log`；这些工件由用户在本地查看（hook 会拒绝 Agent 读取）。
+失败分析和证据读取只依据 Runtime 的 `result.json` 与 Core 的 `acceptance-results.json`。Agent 不得读取 trace、截图、网络工件或 `runtime.log`；这些工件由用户在本地查看（hook 默认提示风险，严格模式拒绝读取）。
 
 ## 输出
 
 - `.devflow/planning/features/{feature}/acceptance-test-bindings.json`
 - `.devflow/planning/test-runs/{feature}/acceptance-results.json`
 
-`acceptance-results.json` 是 Core 指定写入的本地执行缓存（Agent 不得写入，可读取用于展示）；Markdown 结论不能替代它，收口以 Core 对它的重新校验（`validate_results`）为准。失败分析和证据读取仍只使用 `result.json` 与 `acceptance-results.json`；trace、截图、网络工件和 `runtime.log` 由用户本地查看，Agent 不得读取（hook 会拒绝）。Hook 会拦截常规 Write/Edit/Bash 误写，但不是对同一系统用户下任意进程的安全隔离；未配置外部受保护信任根时，不得宣称结果在密码学意义上不可伪造。
+`acceptance-results.json` 是 Core 指定写入的本地执行缓存（Agent 不得写入，可读取用于展示）；Markdown 结论不能替代它，收口以 Core 对它的重新校验（`validate_results`）为准。失败分析和证据读取仍只使用 `result.json` 与 `acceptance-results.json`；trace、截图、网络工件和 `runtime.log` 由用户本地查看，Agent 不得读取（hook 默认提示风险，严格模式拒绝）。Hook 默认提示常规 Write/Edit/Bash 误写风险，严格模式拦截，但不是对同一系统用户下任意进程的安全隔离；未配置外部受保护信任根时，不得宣称结果在密码学意义上不可伪造。

package/plugins/devflow-requirements/skills/requirement-feasibility-review/SKILL.md

@@ -3,6 +3,8 @@ name: requirement-feasibility-review
 description: Review a PRD, meeting transcript, feature request, or workflow before requirement baseline to determine whether every promised user outcome is implementable. Use when requirements involve identities, roles, permissions, external APIs, contracts, payments, asynchronous callbacks, historical migration, or unclear handoffs; apply first-principles proof obligations and adversarial counterexamples, then produce evidence-backed gaps and decisions instead of inventing missing rules.
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Requirement Feasibility Review
 
 ## Goal

package/plugins/devflow-requirements/skills/workflow-demand-clarify/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-demand-clarify
 description: "Use when a workflow-wayfinder Grilling ticket needs a focused one-session L1-L4 business clarification. Turns fuzzy requirements into a confirmed, traceable decision scheme. It is not a bypass around the mandatory wayfinder → domain-modeling → feasibility-review chain."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 Original slash-command metadata retained for workflow guidance.

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

@@ -3,6 +3,8 @@ name: workflow-domain-modeling
 description: "Use as the mandatory domain-modeling step after workflow-wayfinder and before requirement-feasibility-review; also use during later clarification or planning when domain terms, business concepts, status names, ownership, or decision records may be ambiguous. Challenges the glossary, stress-tests relationships, updates .devflow/planning/CONTEXT.md, and creates ADR notes only for hard-to-reverse surprising trade-offs."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Workflow: Domain Modeling（领域模型主动维护）
 
 本技能不是被动记录词汇，而是主动维护项目共同语言：挑战术语、压测边界、减少下游命名和业务理解偏差。需求主链中，它消费 Wayfinder 的 Known Land、Frontier 和已解决 ticket，并将可实现性审查所需的主体、所有权、状态和反例显式化。

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

@@ -1,8 +1,10 @@
 ---
 name: workflow-requirement-baseline
-description: "Use after the mandatory requirement chain workflow-requirement-triage → workflow-wayfinder → workflow-domain-modeling → requirement-feasibility-review when raw requirements, PRDs, meeting notes, or feature requests need decomposition, conflict checks, and a unified baseline. Do not enter baseline before the feasibility review passes."
+description: "Use after the mandatory requirement chain workflow-requirement-triage → workflow-wayfinder → workflow-domain-modeling → requirement-feasibility-review when raw requirements, PRDs, meeting notes, or feature requests need decomposition, conflict checks, and a unified baseline. Carry unresolved feasibility findings into the baseline as explicit risks."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 Original slash-command metadata retained only as workflow invocation guidance.
@@ -109,6 +111,8 @@ Always create or update:
 - `.devflow/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`, `key_decisions`, and `ui_change_required`.
 - `.devflow/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.
 
+Source provenance is owned by Core's `requirement-wayfinder` source unitization: `.devflow/planning/requirements/{feature}/source_units.yaml` records `source_document` and `source_document_fingerprint`. Wireframe approval reads this record and verifies the current source file hash. The baseline template and Core graph traceability views do not require a duplicate fingerprint in `traceability.json`; do not invent or manually copy one to make approval pass. If provenance is missing or stale, repair it through the source-producing workflow. Older projects without source units may still use their existing traceability fingerprint for compatibility.
+
 Before the CP-1 result is reported, run:
 
 ```bash
@@ -599,7 +603,7 @@ Do not ask generic checklist questions. Ask questions tied to specific feature p
 FP-003 导出文件字段和格式：导出字段以列表当前展示字段为准，还是需要额外字段？
 ```
 
-If the user cannot answer a blocking question, keep the item in `待确认事项`, mark the baseline review conclusion as not passed, and stop before downstream handoff. If the question is non-blocking, keep it in `待确认事项` and continue with impact clearly recorded.
+If the user cannot answer a blocking question, keep the item in `待确认事项`, mark the baseline review conclusion as not passed, and hand off the unresolved question and its impact without claiming confirmation. If the question is non-blocking, keep it in `待确认事项` and continue with impact clearly recorded.
 
 Completion gate: blocking questions are answered. Non-blocking questions may be recorded as pending with impact and current handling.
 

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

@@ -3,6 +3,8 @@ name: workflow-requirement-triage
 description: "Use as the lightweight first step for a new request, bug report, PRD, or feature idea. Classify the request, check shallow duplicate and prior out-of-scope/rejected decisions, then route a viable request into workflow-wayfinder; do not perform deep requirement validation or route directly to baseline."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Workflow: Requirement Triage（需求入口分诊）
 
 在需求主链开始时，只判断：这个需求是否应该继续、是否已经实现、是否曾被拒绝。正常需求一律进入 `workflow-wayfinder`，由后续领域建模和可实现性审查决定是否可进入基线。

package/plugins/devflow-requirements/skills/workflow-wayfinder/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-wayfinder
 description: "Use when a requirement is too large or foggy for one clarification session before baseline. Builds a decision map with destination, frontier, fog, out-of-scope, and small Research/Prototype/Grilling/Task tickets that can be resolved one at a time before entering requirement baseline."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Workflow: Wayfinder（需求探索地图）
 
 本技能是需求主链的固定第二步。无论需求表面上是否简单，都先建立探索地图；目标不是写 baseline，而是把目标、已知事实、边界、迷雾和可逐个解决的 ticket 显式化。

package/src/constants.ts

@@ -1,5 +1,5 @@
 export const PRODUCT_NAME = "Devflow Pi";
-export const PRODUCT_VERSION = "0.1.105";
+export const PRODUCT_VERSION = "0.1.106";
 export const PROJECT_SCHEMA_VERSION = 1;
 export const OMP_RUNTIME_VERSION = "17.2.7";
 

package/templates/omp/AGENTS.md

@@ -2,9 +2,13 @@
 
 This repository uses an OMP-native, project-scoped software delivery runtime.
 
+## Gate policy
+
+Workflow hard gates have been removed: workflow prerequisites, artifact/index checks, contracts, reviews, acceptance results, recovery checks and CP confirmation are advisory. Preserve failed/blocked results and missing evidence, report risks, and continue executable work. Continuation is never test success or human approval. There is no strict workflow or mandatory CP approval mode. Actual operation errors, unreadable control state and revision conflicts must still be resolved for the affected operation.
+
 ## Control plane
 
-- Start only through `/devflow start <feature>|<phase>` after `/devflow doctor` passes; resume with `/devflow resume`.
+- Start only through `/devflow start <feature>|<phase>` after checking `/devflow doctor` and reporting its diagnostics; resume with `/devflow resume`.
 - Inspect workflow state with `devflow_state`; do not infer state from chat history.
 - Initialize delivery with `devflow_bootstrap`.
 - Mutate checkpoints and steps only with `devflow_transition`.
@@ -35,4 +39,4 @@ An index accelerates discovery; it never overrides source code, executable tests
 - A model assertion is not validation evidence.
 - Record exact commands and results for tests, builds, migrations, and acceptance checks.
 - When context reconciliation is requested, follow `skill://workflow-context-sync`, validate the required level, then acknowledge through `devflow_context_sync`.
-- Human checkpoints never pass silently in headless mode.
+- Soft checkpoints continue with `continued_with_warning`, including in headless mode. When explicit CP confirmation is enabled, wait for it and never synthesize human approval.