@guanlin4924/devflow-pi 0.1.105 → 0.1.107

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

@@ -3,6 +3,8 @@ name: workflow-backend-tech-spec
 description: "Use when a requirement baseline needs a backend technical design, including API, data model, affected modules, integration points, and risks."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 Original slash-command metadata retained only as workflow invocation guidance.
@@ -109,7 +111,7 @@ allowed-tools:
    - 是否对接了外部系统，需要统一的 Client 接口封装？
    - 是否有独立的配置、认证、错误处理逻辑？
    满足任一条件的，应在方案中定义能力接口（Client interface + 参数/结果结构体），参考已有 `pkg/wx_red_pack`、`pkg/wx_pay` 的模式设计。
-10. **执行被影响方探索**：读取 `references/affected-module-exploration.md`，对 baseline 第8.2节"关联历史功能/模块"表格列出的每个受影响模块，按清单逐项读取代码并产出：现状流程图、现有字段/方法表格、集成点列表、复用/扩展/新增决策。探索产出直接填入输出文档的"现有功能说明"（第四章）和"影响范围"（第六章）。**探索产出检查不通过，不得进入 Phase 3。**
+10. **执行被影响方探索**：读取 `references/affected-module-exploration.md`，对 baseline 第8.2节"关联历史功能/模块"表格列出的每个受影响模块，按清单逐项读取代码并产出：现状流程图、现有字段/方法表格、集成点列表、复用/扩展/新增决策。探索产出直接填入输出文档的"现有功能说明"（第四章）和"影响范围"（第六章）。**探索产出检查不通过时记录缺项与影响，可继续 Phase 3。**
 
 **关键：如果发现多个相似功能，必须询问用户使用哪个。**
 如果与 baseline 中的用户拍板结果冲突，停止并要求重新确认，不要自行改判。
@@ -156,7 +158,7 @@ allowed-tools:
 | FP-003 | OrderWorkflow（新建） | 新建独立模块 | 用户确认 |
 ```
 
-**门禁**：每个 FP 必须有 seam 确认记录，否则不得进入 Phase 3。
+**软门禁**：检查每个 FP 的 seam 确认记录，缺项记为待确认并传入 Phase 3。
 
 ### 第三阶段：生成文档
 
@@ -233,14 +235,14 @@ If an older baseline still points to root `features/{功能名}/`, treat that as
 12. **遵循最佳实践标杆** — 新功能的设计（分层、命名、错误处理、参数封装、测试模式）必须与项目内已有标杆功能保持一致，不得引入与项目验证过的成熟模式相悖的新模式。若需偏离，必须在方案中说明理由
 13. **能力抽象** — 新功能中具有独立复用价值的部分（外部集成、通用业务能力），必须抽象为 `pkg/` 级模块，定义清晰的 Client 接口和参数/结果结构体，形成可被后续功能消费的项目能力资产
 
-## 强制审查门禁（MANDATORY — 不可跳过）
+## 审查软门禁
 
 ### 反问审查
 
 - [ ] 每个不确定的接口设计、库表变更、Job 逻辑是否已向用户确认？（禁止猜测，禁止自行决定）
 - [ ] 涉及调用上游 API 的，是否已向用户索要接口文档并确认对接方案？（不可猜测 API 契约，包括 URL、认证、请求/响应结构、错误码）
 - [ ] 涉及的每个能力点（外部集成、业务逻辑、数据访问、工具方法），是否已在项目内完成复用搜索？**若已有封装却被绕过直接重写，方案不合格。**
-- [ ] `references/affected-module-exploration.md` 的探索产出检查是否全部通过？（现状流程图、字段/方法表格、集成点列表、复用/扩展/新增决策）**若不通过，必须先补充代码探索，不得继续写文档。**
+- [ ] `references/affected-module-exploration.md` 的探索产出检查是否全部通过？（现状流程图、字段/方法表格、集成点列表、复用/扩展/新增决策）**若不通过，记录待补充的代码探索与证据缺口，继续可完成的文档部分。**
 - [ ] 若 `.devflow/planning/code-index/` 存在，复用/影响范围/调用链/读写资源判断是否已查询 code-index 并回读源码 evidence？若未使用，是否说明缺失或过期原因？
 - [ ] 是否已找到项目内最佳实践标杆，并确认新功能的分层结构、命名、错误处理、参数封装模式与标杆一致？（若偏离，理由是否已写明？）
 - [ ] 新功能中具有独立复用价值的部分，是否已识别并抽象为 `pkg/` 级能力模块？接口定义、参数/结果结构体是否清晰？

package/plugins/devflow-design/skills/workflow-design-rule-pack/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-design-rule-pack
 description: Use when workflow-ui-spec or workflow-frontend-tech-spec needs a reusable UI/UX design rule package, ui-ux-pro-max recommendations, or project installation of .devflow/context/spec/design across repositories.
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Workflow Design Rule Pack
 
 This skill provides the reusable source for the project design rule package consumed by `workflow-ui-spec` and `workflow-frontend-tech-spec`.

package/plugins/devflow-design/skills/workflow-feature-breakdown/SKILL.md

@@ -3,6 +3,8 @@ name: workflow-feature-breakdown
 description: "Use when a requirement baseline needs a test-readable feature breakdown across style, functionality, logic, pages, components, fields, actions, and dialogs."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 Original slash-command metadata retained only as workflow invocation guidance.

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

@@ -3,6 +3,8 @@ name: workflow-frontend-tech-spec
 description: "Use when a requirement baseline and UI specification need a frontend technical design covering routes, components, state, APIs, reuse, and risks."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 Original slash-command metadata retained only as workflow invocation guidance.
@@ -89,7 +91,7 @@ allowed-tools:
 8. 查找 UI 组件库、设计系统、样式方案、状态管理和权限控制模式
 9. 识别技术栈插槽：React、Next.js、Vue 或仅 Common Web，并记录未覆盖的框架为待确认/待扩展
 10. 检查三层复用机会：已有页面/组件/交互模式、已有依赖/库、项目设计系统或代码模式；与 baseline 的复用决策保持一致
-11. **执行被影响方探索**：读取 `references/affected-module-exploration.md`，对 baseline 第8.2节"关联历史功能/模块"表格列出的每个受影响的前端页面/组件，按清单逐项读取源码并产出：现有 props/emits/methods/API 调用清单、现有数据流和交互方式、保留/分支/抽离/新增决策。探索产出直接填入输出文档的"影响范围"章节和组件树。**探索产出检查不通过，不得进入 Phase 3。**
+11. **执行被影响方探索**：读取 `references/affected-module-exploration.md`，对 baseline 第8.2节"关联历史功能/模块"表格列出的每个受影响的前端页面/组件，按清单逐项读取源码并产出：现有 props/emits/methods/API 调用清单、现有数据流和交互方式、保留/分支/抽离/新增决策。探索产出直接填入输出文档的"影响范围"章节和组件树。**探索产出检查不通过时记录缺项与影响，可继续 Phase 3。**
 12. 如 `.devflow/context/spec/design/tools/ui-ux-pro-max/scripts/search.py` 存在，可按当前技术栈和 UI 场景补充查询：
     ```bash
     python3 .devflow/context/spec/design/tools/ui-ux-pro-max/scripts/search.py "layout form table accessibility performance" --stack react
@@ -154,7 +156,7 @@ allowed-tools:
 | OrderDetail | 新建 | props: 3 / events: 2 | ✅ 深 | 保持小接口 |
 ```
 
-**门禁**：每个界面/组件必须有 seam 决策记录（复用/扩展/新建），否则不得进入 Phase 3。
+**软门禁**：检查每个界面/组件的 seam 决策记录（复用/扩展/新建），缺项记为待确认并传入 Phase 3。
 
 1. 创建 `.devflow/planning/features/{功能名}/` 目录
 2. 读取 `assets/frontend-spec-template.md` 模板
@@ -192,12 +194,12 @@ If an older baseline still points to root `features/{功能名}/`, treat that as
 11. 与历史相关的判断优先来自 `.devflow/planning/milestones/`、`.devflow/planning/requirements/`、`.devflow/planning/lessons/` 和阶段 `CONTEXT.md`；`features/` 或 `.devflow/context/lessons/` 只作为目标项目存在时的兼容来源
 12. 设计规则优先级为：用户拍板/设计稿事实/需求基线 > 现有代码与项目 token > `.devflow/context/spec/design/tokens/project-tokens.md` > `.devflow/context/spec/design/recommendations/` 与 `ui-ux-pro-max` 推荐。推荐项未经用户确认不得进入实现任务。
 
-## 强制审查门禁（MANDATORY — 不可跳过）
+## 审查软门禁
 
 ### 反问审查
 
 - [ ] 每个不确定的组件选择、路由设计、状态处理是否已向用户确认？（禁止猜测）
-- [ ] `references/affected-module-exploration.md` 的探索产出检查是否全部通过？（现有 props/emits/methods/API 调用清单、保留/分支/抽离/新增决策）**若不通过，必须先补充代码探索，不得继续写文档。**
+- [ ] `references/affected-module-exploration.md` 的探索产出检查是否全部通过？（现有 props/emits/methods/API 调用清单、保留/分支/抽离/新增决策）**若不通过，记录待补充的代码探索与证据缺口，继续可完成的文档部分。**
 - [ ] 若 `.devflow/planning/code-index/` 存在，受影响页面/组件/API/store 的关系定位是否已查询 code-index 并回读源码 evidence？若未使用，是否说明缺失或过期原因？
 - [ ] 方案影响的现有页面/组件是否已描述其**现状**？（先描述现状，再分析影响）
 - [ ] loading/empty/error/permission/disabled/duplicate/responsive 等状态是否均已覆盖或标记待确认？

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

@@ -3,6 +3,8 @@ name: workflow-integration-verify
 description: "Use after both Track A (api-call-guide) and Track B (frontend-tech-spec) complete. Performs Merge Gate verification: cross-check backend API implementation against the API contract and frontend's API calling patterns. Outputs an integration report."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # 联调验证（Merge Gate）
 
 ## 定位
@@ -114,7 +116,7 @@ description: "Use after both Track A (api-call-guide) and Track B (frontend-tech
 1. 将后端、前端、UI、API 契约中的设计项写入 `traceability.json.designs`，每项以 `requirements: ["REQ-…"]` 回指来源。
 2. 所有 API 类型设计必须在 `contract` 中同时写 `request`、`response`、`errors`、`behavior`；禁止只对齐响应字段。
 3. 执行 `python3 <workflow-orchestrator>/scripts/traceability_check.py --file .devflow/planning/requirements/{feature}/traceability.json --stage design`。
-4. 结果不为 passed 时，`merge_gate_status` 必须为 failed，`blocking_issue_count` 必须大于 0，回到对应方案修复；不得进入变更清单。
+4. 结果不为 passed 时，`merge_gate_status` 必须为 failed，`blocking_issue_count` 必须大于 0，建议回到对应方案修复；默认携带未解决项进入变更清单。
 
 ## 产出模板
 

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

@@ -3,6 +3,8 @@ name: workflow-ui-spec
 description: "Use when UI designs, screenshots, Figma exports, Lanhu notes, or manual UI descriptions need a structured UI specification."
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 Original slash-command metadata retained only as workflow invocation guidance.
@@ -262,7 +264,7 @@ UI-SPEC 不写代码细节（那是前端技术方案的事），但必须把 UI
 ## 10. 审查结论
 ```
 
-## 强制审查门禁
+## 审查软门禁
 
 ### 设计完整性
 
@@ -299,4 +301,4 @@ UI-SPEC 不写代码细节（那是前端技术方案的事），但必须把 UI
 | 冲突嗅探 | 设计 Token 是否与现有变量命名/值冲突？ |
 | 需求对齐 | 设计稿中的交互是否与需求基线的用户拍板决策一致？ |
 
-**审查结论不通过时，不得进入功能点梳理阶段。**
+**审查结论不通过时，记录问题与影响，携带诊断进入功能点梳理阶段。**

package/plugins/devflow-implementation/agents/implementation-worker.md

@@ -18,14 +18,8 @@ autoloadSkills:
 
 Implement only the assigned plan slice. Do not re-plan the feature, compare alternatives, or explore unrelated modules. Read only the approved files, their immediate dependencies, and the focused tests needed for this slice. Preserve unrelated work and report deviations instead of silently expanding scope.
 
-Before any protected source access, read the project's required code-index evidence
-files in the exact order listed by INDEX_GATE (typically `.devflow/planning/code-index/INDEX.md`
-followed by the ordered files named by the gate). Do not attempt `grep`, `rg`, or source
-reads first: each subagent has its own evidence session and cannot inherit the parent's
-observations. If the gate lists different files, follow that list exactly.
+Read relevant code-index evidence when available; each subagent has its own evidence session. In default soft mode, a missing/stale index or execution contract is an advisory: report the gap and use bounded source reads to continue the assigned work. Missing or contradictory business facts remain explicit uncertainties. Report INDEX_GATE findings and any unavailable or conflicting execution contract, then continue executable work. Run the smallest focused validation once and report its actual result.
 
-If the execution contract is missing, ambiguous, or contradicted by the code, stop before editing and return `STATUS: escalate` with the conflicting evidence. Run the smallest focused validation once; report failures rather than repeatedly trying speculative fixes.
-
-For a task whose frozen `test-bindings.json` marks `test_mode: tdd_required`, use the Core tool in this exact order: `devflow_tdd_evidence(action="prepare")` before changing declared production paths; create/change the test and record `red`; implement; record `green`; then record `regression`. Do not mark the task done if any phase is missing or fails. The tool may write only its own Core-owned TDD evidence record; this exception does not authorize edits to any other Devflow control-plane file.
+For a task whose frozen `test-bindings.json` marks `test_mode: tdd_required`, use the Core tool in this exact order: `devflow_tdd_evidence(action="prepare")` before changing declared production paths; create/change the test and record `red`; implement; record `green`; then record `regression`. If any phase is missing or fails, preserve that result and report the evidence gap; default soft mode permits subsequent work without claiming TDD passed. The tool may write only its own Core-owned TDD evidence record; this exception does not authorize edits to any other Devflow control-plane file.
 
 Return `STATUS`, changed files, validation evidence, and one escalation/blocker if needed. Never edit `.devflow/planning/STATE.md`, `.devflow/planning/artifacts/index.yaml`, workflow definitions, or checkpoint decisions; the parent session owns those through Devflow tools.

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

@@ -3,6 +3,11 @@ 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."
 ---
 
+Dynamic plan mode: when Core reports `mode: dynamic`, use `workflow-dynamic` as the execution protocol. The selected task supplies scope, dependencies, required outputs and verification. Use this skill's relevant technical guidance, but do not create legacy stage documents/meta pairs, require fixed checkpoints, or advance legacy STATE. Return activity/evidence to `devflow_plan`; only Core records verification.
+
+
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 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,11 @@ name: workflow-execute-phase
 description: "Use when a planned .devflow/planning phase needs implementation, dependency-aware task execution, progress tracking, and verification evidence."
 ---
 
+Dynamic plan mode: when Core reports `mode: dynamic`, use `workflow-dynamic` as the execution protocol. The selected task supplies scope, dependencies, required outputs and verification. Use this skill's relevant technical guidance, but do not create legacy stage documents/meta pairs, require fixed checkpoints, or advance legacy STATE. Return activity/evidence to `devflow_plan`; only Core records verification.
+
+
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 ## Legacy Command Metadata
 
 Original slash-command metadata retained only as workflow invocation guidance.
@@ -128,7 +133,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/agents/code-reviewer.md

@@ -13,6 +13,8 @@ autoloadSkills:
   - code-review
 ---
 
+For a Core dynamic-plan review (task kind `review`, mode `dynamic`), read the requirement main document, production source, tests and Core verification evidence directly. Use only applicable review surfaces. Return strict JSON `{ "summary": "evidence inspected and conclusion", "findings": [] }`; findings must include requirement ID, file/line evidence, triggering scenario, impact and recheck. Missing technical evidence is a finding to collect or repair, not a request for the user to manufacture metadata. An empty findings array requires evidence supporting every linked acceptance requirement. The legacy frozen-test-case and REVIEW.md contract below applies only to legacy fixed workflows. Remain read-only.
+
 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.

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

@@ -3,16 +3,21 @@ 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."
 ---
 
+Dynamic plan mode: when Core reports `mode: dynamic`, use `workflow-dynamic` as the execution protocol. The selected task supplies scope, dependencies, required outputs and verification. Use this skill's relevant technical guidance, but do not create legacy stage documents/meta pairs, require fixed checkpoints, or advance legacy STATE. Return activity/evidence to `devflow_plan`; only Core records verification.
+
+
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 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,16 @@ 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."
 ---
 
+Dynamic plan mode: when Core reports `mode: dynamic`, use `workflow-dynamic` as the execution protocol. The selected task supplies scope, dependencies, required outputs and verification. Use this skill's relevant technical guidance, but do not create legacy stage documents/meta pairs, require fixed checkpoints, or advance legacy STATE. Return activity/evidence to `devflow_plan`; only Core records verification.
+
+
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 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 +32,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 +48,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,11 @@ 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."
 ---
 
+Dynamic plan mode: when Core reports `mode: dynamic`, use `workflow-dynamic` as the execution protocol. The selected task supplies scope, dependencies, required outputs and verification. Use this skill's relevant technical guidance, but do not create legacy stage documents/meta pairs, require fixed checkpoints, or advance legacy STATE. Return activity/evidence to `devflow_plan`; only Core records verification.
+
+
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 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.107";
 export const PROJECT_SCHEMA_VERSION = 1;
 export const OMP_RUNTIME_VERSION = "17.2.7";