@guanlin4924/devflow-pi 0.1.105 → 0.1.107

package/plugins/devflow-core/runtime/hooks/context_sync_gate.py

@@ -5,6 +5,7 @@ from __future__ import annotations
 
 import argparse
 import json
+import os
 import subprocess
 import sys
 from pathlib import Path
@@ -163,7 +164,8 @@ def stop_hook() -> int:
     print(
         json.dumps(
             {
-                "decision": "block",
+                "decision": "approve",
+                "soft_gate": True,
                 "reason": reason,
                 "stop_block_count": stop_block_count,
             },

package/plugins/devflow-core/runtime/hooks/hook_common.py

@@ -444,8 +444,8 @@ def tool_requests_protected_source(
 
 # Core control store protection (approval records live in control.db). This is
 # misuse prevention, not a defence against a hostile same-user process. It is
-# always on: neither DEVFLOW_SOFT_GATES, the policy mode nor hook-config can
-# disable it; hook-config may only add extra protected path globs.
+# always detected; index_gate emits warnings rather than
+# denial. Hook-config may only add extra protected path globs.
 CONTROL_STORE_NAME_RE = re.compile(r"^control\.db(?:$|[-.])", re.IGNORECASE)
 CANONICAL_ACCEPTANCE_RE = re.compile(
     r"(?:^|/)\.devflow/planning/test-runs/[^/]+/acceptance-results(?:\.meta)?\.json$",
@@ -713,7 +713,7 @@ def tool_touches_control_store(event: dict[str, Any], root: Path) -> tuple[bool,
 
 # MCP authorization and audit data are user-local security state.  This guard
 # is deliberately narrower than DEVFLOW_HOME: only mcp.json and mcp-audit/
-# are protected, and the decision is independent of soft-gate policy.
+# are detected here; index_gate applies the soft/strict policy to the finding.
 def path_is_mcp_protected(raw: str, cwd: Path) -> bool:
     candidate = Path(_expand_shell_path(str(raw)))
     if not candidate.is_absolute():
@@ -792,8 +792,9 @@ def tool_touches_mcp_config(event: dict[str, Any], root: Path) -> tuple[bool, li
 
 
 # Run artifacts are user-local evidence, not agent-readable source.  Keep this
-# guard separate from the control-store guard: it is always on and its only
-# read exception is the Core-produced result.json summary.
+# guard separate from the control-store guard: detection always runs and its
+# only read exception is the Core-produced result.json summary. The caller
+# chooses warning or denial according to the soft/strict policy.
 def _run_root(cwd: Path) -> Path:
     # macOS commonly exposes /var as a symlink to /private/var; use the
     # canonical cwd so lexical and realpath checks compare in one namespace.

package/plugins/devflow-core/runtime/hooks/index_gate.py

@@ -1,9 +1,10 @@
 #!/usr/bin/env python3
-"""PreToolUse hook: deny control-store access and block protected source access until indexes were observed."""
+"""PreToolUse checks: report access risks without workflow blocking."""
 
 from __future__ import annotations
 
 import json
+import os
 
 from hook_common import (
     direct_tool_paths,
@@ -22,50 +23,42 @@ from hook_common import (
 )
 
 
-def deny(reason: str) -> int:
-    print(
-        json.dumps(
-            {
-                "hookSpecificOutput": {
-                    "hookEventName": "PreToolUse",
-                    "permissionDecision": "deny",
-                    "permissionDecisionReason": reason,
-                }
-            },
-            ensure_ascii=False,
-        )
-    )
+def advise(reason: str) -> int:
+    print(json.dumps({"hookSpecificOutput": {
+        "hookEventName": "PreToolUse", "permissionDecision": "allow",
+        "additionalContext": "Workflow warning: " + reason,
+    }}, ensure_ascii=False))
     return 0
 
 
 def main() -> int:
     event = read_event()
     root = project_root(event)
-    # Hard protection, evaluated before any soft/strict policy handling.
+    # Check protected targets first; advise() reports findings.
     mcp_blocked, mcp_paths = tool_touches_mcp_config(event, root)
     if mcp_blocked:
-        return deny(
+        return advise(
             "MCP_CONFIG_PROTECTED: $DEVFLOW_HOME/mcp.json and $DEVFLOW_HOME/mcp-audit/ are reserved for "
-            "Devflow MCP authorization and audit records; ordinary agent file and shell access is denied "
-            "regardless of DEVFLOW_SOFT_GATES. Blocked target: " + ", ".join(mcp_paths) + "."
+            "Devflow MCP authorization and audit records; use the runtime authorization tools. "
+            "Access findings are advisory. Target: " + ", ".join(mcp_paths) + "."
         )
     control_blocked, control_paths = tool_touches_control_store(event, root)
     if control_blocked:
-        return deny(
+        return advise(
             "CONTROL_STORE_PROTECTED: Devflow control.db, the Devflow data-home projects tree and writes to canonical "
-            "acceptance results are reserved for Core runtime tools; this misuse-prevention hook denies ordinary agent file and "
-            "shell access to them regardless of DEVFLOW_SOFT_GATES, but is not a same-user process sandbox. "
+            "acceptance results are reserved for Core runtime tools; this misuse-prevention hook warns about ordinary agent file and "
+            "shell access, but is not a same-user process sandbox. "
             "Canonical acceptance-results*.json may be read with the Read/Grep file tools. "
-            f"Use devflow_approval(action=\"propose\"|\"list\") for approvals. Blocked target: {', '.join(control_paths)}."
+            f"Use devflow_approval(action=\"propose\"|\"list\") for approvals. Target: {', '.join(control_paths)}."
         )
     run_blocked, run_paths = tool_touches_run_artifacts(event, root)
     if run_blocked:
-        return deny(
+        return advise(
             "RUN_ARTIFACTS_PROTECTED: .devflow/runs/ contains trace, screenshots, runtime logs and other "
-            "user-local evidence that Agent tools may not read, write or access through bash. Trace and screenshots "
+            "user-local evidence; ordinary Agent access warns in soft mode and is denied in strict mode. Trace and screenshots "
             "are for the user to inspect locally with Playwright in a terminal; Agent failure analysis must read "
             "the Core-produced result.json summary instead. Only pure-read access to a feature execution's "
-            "result.json is allowed. Blocked target: " + ", ".join(run_paths) + "."
+            "result.json needs no access warning. Target: " + ", ".join(run_paths) + "."
         )
     policy = load_policy(root)
     session_id = ensure_session(root, event)
@@ -79,7 +72,7 @@ def main() -> int:
     missing = [path for path in required if path not in observed]
     strict = str(policy.get("mode", "strict")).lower() == "strict"
     if strict and required and missing and blocked:
-        return deny(
+        return advise(
             "INDEX_GATE_BLOCKED: protected source access requires observed index evidence. "
             f"Read these files first, in order: {', '.join(missing)}. "
             f"Blocked target: {', '.join(paths)}. The gate records successful tool reads, not assistant promises."

package/plugins/devflow-core/skills/wireframe-proposal/SKILL.md

@@ -3,6 +3,8 @@ name: wireframe-proposal
 description: Generate or revise a low-fidelity wireframe proposal from controlled requirements. Use during the wireframe-proposal workflow step.
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Wireframe Proposal
 
 Run only when Core reports `wireframe-proposal` as the current step. A no-UI decision is evaluated and recorded by Core after CP-1; do not infer it from requirement prose, edit workflow state, or self-skip this step.

package/plugins/devflow-core/skills/wireframe-render/SKILL.md

@@ -3,6 +3,8 @@ name: wireframe-render
 description: Render validated canonical wireframe JSON into deterministic Markdown and SVG previews. Use after wireframe-validate.
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Wireframe Render
 
 Run only when Core reports `wireframe-render` as the current step. A no-UI decision is evaluated and recorded by Core after CP-1; do not infer it from requirement prose, edit workflow state, or self-skip this step.

package/plugins/devflow-core/skills/wireframe-review/SKILL.md

@@ -3,6 +3,8 @@ name: wireframe-review
 description: Present validated wireframe previews and unresolved questions for explicit user review. Use at the wireframe-review checkpoint.
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Wireframe Review
 
 Run only when Core reports `wireframe-review` as the current step. A no-UI decision is evaluated and recorded by Core after CP-1; do not infer it from requirement prose, edit workflow state, or self-skip this step.

package/plugins/devflow-core/skills/wireframe-validate/SKILL.md

@@ -3,6 +3,8 @@ name: wireframe-validate
 description: Run deterministic validation for a wireframe proposal and build canonical JSON. Use after wireframe-proposal.
 ---
 
+门禁策略：默认软门禁，门禁行为以本段为准。本文及引用材料中的前置检查、审查、质量、完成条件和 CP 确认用于诊断；未满足时记录缺项、风险与后续处理，继续可执行的工作，不自动阻断阶段推进。保留真实的 failed/blocked/未审批状态，不把继续执行写成通过或人工批准。硬门禁及其恢复开关已移除。
+
 # Wireframe Validate
 
 Run only when Core reports `wireframe-validate` as the current step. A no-UI decision is evaluated and recorded by Core after CP-1; do not infer it from requirement prose, edit workflow state, or self-skip this step.

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

@@ -0,0 +1,41 @@
+---
+name: workflow-dynamic
+description: Execute a Core-owned dynamic requirement plan, maintain one readable requirement document, route technical findings to repair skills, and ask only genuine business decisions. Use when the inspector reports mode dynamic; existing fixed workflows keep their own contracts.
+---
+
+# Dynamic requirement delivery
+
+Use `devflow_plan inspect` as the scheduling authority. Present task titles and progress in the user's language. Do not edit STATE, synthesize test results, or use legacy complete-step/checkpoint tools.
+
+## Intent and planning
+
+Read the single document returned by Core and inspect relevant source. Update that document for scope, approach, and acceptance requirements. Each acceptance clause has a stable heading such as `### R-1: Do not send another batch after the deadline`. Preserve IDs across wording changes. Cosmetic whitespace does not change the obligation. Removing an obligation requires a genuine scope decision; never delete a failed obligation to finish.
+
+Propose tasks with `revise`, including its inspected `expected_revision` and a plain-language change reason. Fields are `id`, `title`, `kind`, `requirements`, `dependencies`, `inputs`, `outputs`, `checks`. Allowed kinds: discover, implement, verify, review. Each check declares an executable `argv` array and optional timeout seconds. Inputs must include the relevant production code, tests, and configuration: a test file alone is insufficient. Prefer directories where additional source files affect behavior. Every acceptance clause needs a verification task. Code changes need an independent review task that depends on the implementation and verification tasks.
+
+Generate only applicable work. A backend-only feature has no UI, wireframe, browser-test, or frontend-document task. If applicability is unclear, investigate it before proposing that branch. Do not generate no-op documents. Tasks may produce source, tests, migrations, schemas or genuinely needed design assets; their existence must have a consumer.
+
+## Execution
+
+1. Inspect and claim the task selected by Core. Use the returned task ID and attempt for all subsequent results.
+2. Read its exact Skill ID. In dynamic mode use that skill's technical procedures, but the dynamic task supplies scope, inputs, outputs and acceptance. Legacy stage lists, mandatory Markdown/meta pairs and checkpoint instructions do not apply.
+3. For discovery/implementation/repair, do the work and call `report` with a factual summary. This records activity completion, not an acceptance pass.
+4. For verification, call `verify`. Core executes the declared commands and captures exit status and output. Do not substitute a shell transcript or self-reported pass. Use tests that assert the actual expected behavior, including production paths and meaningful failure scenarios.
+5. For review, dispatch a read-only `devflow-code-reviewer` task with the requirement document, task, source paths and recorded verification evidence. Ask for strict JSON `{"summary":"...","findings":[...]}`; each finding identifies the violated requirement, evidence, affected scope and suggested recheck. Submit its task-call ID using `review_result`; Core accepts only the captured child result, not your rewritten report.
+6. Continue ready tasks. Failed checks automatically create a bounded repair task. Read the finding and invoke its repair skill, then allow Core to rerun the original verification. Do not reset repair budgets by renaming tasks.
+
+## Changes, waiting, and recovery
+
+Keep stable task IDs. To cancel unnecessary work, retain the task with `cancelled: true` and a reason and rewire its consumers in the same proposal. Preserve verification coverage. A failed required behavior is a repair, not an irrelevant task.
+
+After a requirement edit, inspect and revise only affected work. Old evidence remains history and cannot certify changed inputs. Never weaken checks merely to obtain a pass.
+
+Use `decision` only for business alternatives, scope reduction, residual-risk choices, or actions outside existing authorization. Supply one clear question and two or three options with consequences; place the recommendation first. Core displays and records the actual user choice. Missing metadata, stale indexes, missing tests and repairable code defects are technical work, not user decisions. A cancelled choice stays pending; it is not approval. Continue independent tasks if possible.
+
+For removed acceptance clauses, include their IDs in `remove_requirements` and identify the exact `approval_option` in the decision. Only that actual user selection authorizes removing those clauses; bind the subsequent revision with `scope_decision_id`. A generic confirmation or a choice to retain scope is not permission to remove acceptance requirements.
+
+For an interrupted running/checking task, inspect actual effects first. Use `recover` with the findings only after establishing the previous operation is no longer running and retry is appropriate. Do not rerun uncertain external writes. Repair exhaustion remains failed: explain what was attempted and actionable next choices without claiming delivery complete.
+
+If an external dependency is unavailable, use `wait` with the task attempt and concrete reason. After read-only evidence establishes readiness, use `resume`; this creates eligibility for a new attempt. Do not classify missing generated documents as external dependencies.
+
+Summarize the readable task board and remaining decisions. Detailed machine evidence stays in Core; do not generate another report document for each invocation.

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

@@ -3,6 +3,14 @@ name: workflow-orchestrator
 description: Use when the user asks to continue, resume, advance, inspect, or route a .devflow/planning-based workflow; when the OMP development agent must decide the next workflow skill from project state; or when a checkpoint must be handled before proceeding.
 ---
 
+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 审批条件均为诊断建议：保留失败证据和缺项，允许继续执行。用户说“下一步”即可推进，无需额外批准弹窗；不得把继续执行记录成人工批准，也不得把失败、未执行的测试改写为通过。真实读写/执行失败、无法解析的状态和并发版本冲突须如实报告。硬门禁及其恢复开关已移除。
+
+
 # Workflow Orchestrator
 
 ## Overview
@@ -13,9 +21,9 @@ This skill is the **single source of truth for all execution-time rules**: gate
 
 ## Chain-skill mode (current)
 
-The active workflow uses `governance.hard_gate_mode: chain`. In this mode the chain skill owns dispatch and sequencing. Core contract, checker, output, and review gates are diagnostic only and must not hard-block skill execution. Call the current step skill, verify its declared inputs and outputs, collect its result, and continue the chain; preserve missing facts and failed checks as structured findings for the next skill or the user. Do not invoke Core gate APIs to force a step through, and stop only for unsafe writes, corrupted control-plane state, missing required human input, or an explicit checkpoint.
+The chain skill owns dispatch and sequencing. Core contract, checker, output, and review gates are diagnostic only and must not hard-block skill execution. Call the current step skill, verify its declared inputs and outputs, collect its result, and continue the chain; preserve missing facts and failed checks as structured findings for the next skill or the user. Do not invoke Core gate APIs to force a step through, and report operations that cannot execute because of unsafe paths, corrupted state, or genuinely missing execution inputs. CP confirmation is advisory by default.
 
-This is a migration mode. Setting `hard_gate_mode: core` re-enables the former Core hard-gate behavior.
+Hard workflow gates and their configuration switches have been removed.
 
 ## Quick Start
 
@@ -60,10 +68,10 @@ When the invocation contains `<devflow-runtime-directive>`, run the workflow con
 1. Inspect state and execute exactly the returned action.
 2. After a successful step transition and artifact synchronization, inspect state again.
 3. Continue with the newly returned action and load only that step's Skill.
-4. Stop only when the inspector returns `await_user_confirmation`, `blocked`, or `workflow_complete`; also stop on an explicit user interruption or an unrecoverable tool failure.
-5. At `await_user_confirmation`, present the checkpoint and yield to the user. Resume the same loop only after an explicit confirmation and successful `devflow_transition`.
+4. On `await_user_confirmation`, follow the soft checkpoint rules below and continue without fabricating approval. Stop on `workflow_complete`, an explicit user interruption, an unrecoverable operation failure, or an actual control-plane error reported as `blocked`.
+5. When explicit CP confirmation is enabled, present the checkpoint and yield to the user at `await_user_confirmation`; resume after confirmation and a successful `devflow_transition`. Otherwise report the checkpoint diagnostics and continue through the soft transition.
 
-Do not interpret “automatic” as permission to cross a checkpoint, weaken a gate, retry a stale revision without re-inspection, or continue after a blocked action. If context pressure requires a new turn, preserve project truth in `.devflow/planning`, finish required context synchronization, and use `/devflow resume` rather than inventing state from the conversation.
+Apply the configured gate policy during automatic execution. Preserve diagnostics and approval facts; re-inspect before retrying a stale revision. An operation that actually failed remains failed. If context pressure requires a new turn, preserve project truth in `.devflow/planning`, finish required context synchronization, and use `/devflow resume` rather than inventing state from the conversation.
 
 ## Step Execution Protocol
 
@@ -80,58 +88,37 @@ Each step execution follows this fixed sequence:
 
 **After execution:**
 6. Verify the step's outputs exist and record the revision returned by `devflow_state(action="inspect")`. **Do not call `devflow_transition` or write `xd://devflow_transition`: the Devflow Runtime owns the user confirmation and the atomic state transition after this agent turn.**
-7. If the YAML step has `meta_output`, verify the `.meta.json` file exists and has the required fields. If missing, mark the step as `blocked` with reason "missing_meta_output".
+7. If the YAML step has `meta_output`, verify the `.meta.json` file exists and has the required fields. If missing, record an advisory with reason "missing_meta_output" and continue without inventing metadata.
 8. `devflow_transition` validates the proposed state before writing and rejects inconsistent updates. Never repeat the transition after it reports success.
 9. Call `devflow_artifact(action="sync", preserve=false)` only when the registry still shows stale `planned`/`generated` statuses for completed steps.
 
 ## Checkpoint Rules
 
-Never cross CP checkpoints silently. CP definitions (prompts, options, fields) are in the active workflow YAML (`feature-development.yaml` → `checkpoints`).
-
-When the inspector returns `await_user_confirmation`:
-
-1. Read the checkpoint definition from YAML: `checkpoints.<cp-id>`.
-2. Prefer structured checkpoint fields when present:
-   - `producing_step`
-   - `required_outputs`
-   - `required_meta_output`
-   - `required_meta_fields`
-   - `summary_fields`
-   - `prompt`
-   - `confirm_options`
-   - `skip_policy`
-3. Read the producing step's `meta_output` or checkpoint `required_meta_output` → `.meta.json` to get structured field values (e.g., `fp_count`, `br_count`).
-4. Verify the listed required outputs exist.
-5. Check artifact registry content_valid status for the listed outputs.
-6. Use `ask` to present the CP prompt, filling in the `summary_fields` from `.meta.json` data.
-7. If the user confirms, inspect the current revision and call `devflow_transition(action="confirm-checkpoint", expectedRevision=<revision>)`.
-8. If the user asks for fixes or rejects the checkpoint, keep `.devflow/planning/STATE.md` at `status: waiting_checkpoint`, inspect the current revision, call `devflow_transition(action="checkpoint-decision", decision="needs_fix", expectedRevision=<revision>)`, and route to the requested remediation.
-
-CP skip rules:
-- CP-1, CP-API, CP-2, CP-3, CP-4: **never skip**.
-- CP-2 is the Merge Gate. It cannot be skipped in the dual-track workflow.
+CP definitions (prompts, options, fields) are in the active workflow YAML (`feature-development.yaml` → `checkpoints`). By default, report missing outputs and checks, then use the Core transition to continue with `continued_with_warning`; no additional approval prompt is required. This records continuation, never human approval. Explicit review decisions remain available when the user requests them; they are not prerequisites for continuation.
+
+When the inspector returns `await_user_confirmation`, inspect the current revision, report missing outputs and check results, and continue through the Core transition with `continued_with_warning`. Do not create an approval record or freeze candidate facts merely to advance. If the user requests fixes or rejects an output, follow that request.
 
 ## Global Gate Rules
 
-After each step completes, verify the step's gate before advancing:
+After each step completes, evaluate the following checks and carry any failures forward as advisories:
 
-| Step | Gate | Block if |
+| Step | Check | Advisory handoff |
 |------|------|---------|
-| requirement-triage | triage.meta.json `status` is `routed` AND `route` is `ready_for_wayfinder` | Reject advance to requirement-wayfinder |
-| requirement-wayfinder | 决策地图.meta.json `status=ready_for_baseline` AND `ready_for_baseline=true` | Reject advance to domain-modeling |
-| domain-modeling | 领域模型记录及 meta 存在且标识当前功能 | Reject advance to requirement-feasibility-review |
-| requirement-feasibility-review | 可实现性审查.meta.json `status=ready_for_baseline`、`baseline_gate=pass`、`blocking_gap_count=0` 且无 critical finding；`gap_count` 记录全部发现数 | Reject advance to requirement-baseline |
-| requirement-baseline | baseline.md review conclusion is "通过" AND baseline.meta.json `review_status` / `traceability_status` are `passed` AND blocking counters are all 0 | Reject advance to api-contract |
-| api-contract | api-contract.meta.json `review_status` / `traceability_status` are `passed` AND `pending_contract_count` is 0 | Reject advance to dual tracks |
-| architecture-feasibility | Core-derived `architecture-brief.md` / meta exist. If `assessment_level=full`, require `assessment_status=ready` and `comparison_status=confirmed`; a lightweight incomplete result may proceed only as an explicitly unresolved downstream input. | Reject advance to dual tracks for an incomplete full assessment |
-| ui-spec | UI-SPEC.md review conclusion is "通过" | Reject advance to feature-breakdown |
-| feature-breakdown | 功能点梳理.md review conclusion is "通过" | Reject advance to tech-specs |
-| api-call-guide | api-call-guide.meta.json `frontend_consumable` and `mock_ready` are true, pending_items is empty | Reject merge gate |
-| frontend-tech-spec + backend-tech-spec | Both review conclusions are "通过" | Reject integration-verify |
-| integration-verify | integration-report.meta.json `merge_gate_status` / `traceability_status` are `passed` and all mismatch/blocking counters are 0 | Reject advance to change-plan |
-| change-plan | 变更清单.md review conclusion is "通过" AND 变更清单.meta.json traceability_status is `passed` with zero uncovered/orphan counts | Reject advance to execute |
-
-If `hard_gate_mode` is `core`, a gate failure requires re-execution. In the current `chain` mode, retain the failure as a diagnostic finding and let the chain skill decide whether the next skill can consume the artifact; do not use Core hard gates to stop the chain.
+| requirement-triage | triage.meta.json `status` is `routed` AND `route` is `ready_for_wayfinder` | Carry findings to requirement-wayfinder |
+| requirement-wayfinder | 决策地图.meta.json `status=ready_for_baseline` AND `ready_for_baseline=true` | Carry findings to domain-modeling |
+| domain-modeling | 领域模型记录及 meta 存在且标识当前功能 | Carry findings to requirement-feasibility-review |
+| requirement-feasibility-review | 可实现性审查.meta.json `status=ready_for_baseline`、`baseline_gate=pass`、`blocking_gap_count=0` 且无 critical finding；`gap_count` 记录全部发现数 | Carry findings to requirement-baseline |
+| requirement-baseline | baseline.md review conclusion is "通过" AND baseline.meta.json `review_status` / `traceability_status` are `passed` AND blocking counters are all 0 | Carry findings to api-contract |
+| api-contract | api-contract.meta.json `review_status` / `traceability_status` are `passed` AND `pending_contract_count` is 0 | Carry findings to dual tracks |
+| architecture-feasibility | Core-derived `architecture-brief.md` / meta exist. If `assessment_level=full`, require `assessment_status=ready` and `comparison_status=confirmed`; a lightweight incomplete result may proceed only as an explicitly unresolved downstream input. | Carry findings to dual tracks for an incomplete full assessment |
+| ui-spec | UI-SPEC.md review conclusion is "通过" | Carry findings to feature-breakdown |
+| feature-breakdown | 功能点梳理.md review conclusion is "通过" | Carry findings to tech-specs |
+| api-call-guide | api-call-guide.meta.json `frontend_consumable` and `mock_ready` are true, pending_items is empty | Carry findings to merge review |
+| frontend-tech-spec + backend-tech-spec | Both review conclusions are "通过" | Carry findings to integration-verify |
+| integration-verify | integration-report.meta.json `merge_gate_status` / `traceability_status` are `passed` and all mismatch/blocking counters are 0 | Carry findings to change-plan |
+| change-plan | 变更清单.md review conclusion is "通过" AND 变更清单.meta.json traceability_status is `passed` with zero uncovered/orphan counts | Carry findings to execute |
+
+Retain failures as diagnostic findings and continue with usable artifacts. Report any operation that cannot execute.
 
 ## Requirement Writeback Gate
 
@@ -180,7 +167,7 @@ When the inspector returns `run_parallel_window`:
 
 ## State Writeback Rules
 
-Use `devflow_transition` for deterministic state updates. Direct file edits and direct calls to writer scripts are blocked by the OMP extension.
+Use `devflow_transition` for deterministic state updates. The OMP extension warns about direct file edits and direct calls to writer scripts without blocking workflow progress. Use Core tools to preserve consistent state and revision checks.
 
 Common operations:
 
@@ -247,7 +234,7 @@ Steps with `meta_output` in the workflow YAML must produce a `.meta.json` file a
 1. After step execution, check if the YAML step has `meta_output`.
 2. If yes, verify the `.meta.json` file at `meta_output.path` exists.
 3. Verify all `required: true` fields are present and non-null.
-4. If missing or incomplete, mark step as blocked and do not advance.
+4. If missing or incomplete, retain the failed check and missing evidence as an advisory and continue with the available inputs.
 
 The `.meta.json` data feeds CP prompts — e.g., CP-1 reads `baseline.meta.json` to show `fp_count: 7` instead of having the AI count manually.
 
@@ -257,7 +244,7 @@ This skill must be portable. Do not require manually-created `.devflow/planning`
 
 If `.devflow/planning/STATE.md` is missing and project context files are also missing, route to `workflow-project-context` instead of asking for `init_state.rb`. If `.devflow/planning/STATE.md` is missing but project context files already exist, keep the existing `init_state.rb` recovery path.
 
-If `.devflow/planning/STATE.md` contains blockers with `type: PENDING_TEMPLATE`, stop normal dispatch and report the missing depth spec template. The blocker must name the codebase, topic, matched path, missing template path, and impact.
+If `.devflow/planning/STATE.md` contains findings with `type: PENDING_TEMPLATE`, report the missing depth spec template and continue normal dispatch in soft mode. Include the codebase, topic, matched path, missing template path, and impact.
 
 Use these generators: