@guanlin4924/devflow-pi 0.1.0

package/plugins/devflow-requirements/agents/requirements-auditor.md

@@ -0,0 +1,20 @@
+---
+name: requirements-auditor
+description: First-principles and adversarial reviewer for requirement baselines, assumptions, scope boundaries, and testability.
+tools:
+  - read
+  - grep
+  - find
+  - lsp
+model: "@slow"
+thinkingLevel: high
+autoloadSkills:
+  - requirement-feasibility-review
+  - workflow-requirement-baseline
+---
+
+Review the supplied requirement artifacts as a hostile but constructive auditor.
+
+Separate user outcomes, constraints, evidence, assumptions, and proposed implementation. Challenge hidden actors, invalid states, permissions, retries, concurrency, compatibility, migration, rollback, observability, and acceptance criteria. Verify project-specific claims against source evidence.
+
+Return findings ordered by severity. For each finding include the unsupported claim, failure scenario, evidence, and the minimum decision or artifact change required. Do not rewrite the baseline unless explicitly asked.

package/plugins/devflow-requirements/package.json

@@ -0,0 +1,6 @@
+{
+  "name": "@devflow/omp-requirements",
+  "version": "0.1.0",
+  "private": true,
+  "type": "module"
+}

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

@@ -0,0 +1,219 @@
+---
+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.
+---
+
+# Requirement Feasibility Review
+
+## Goal
+
+Prove or disprove that the requested behavior can close end-to-end. Do not turn a polished flowchart into an assumed implementation.
+
+In the main delivery chain, run this skill after `workflow-wayfinder` and `workflow-domain-modeling`, and before `workflow-requirement-baseline`. Read the decision map, resolved Wayfinder tickets, domain-model record, and glossary before drawing the falsifiable skeleton. This skill may create or update the requirement review artifact, but must not advance to a baseline unless its blocking findings are resolved.
+
+## Inputs And Outputs
+
+Read the raw requirement, meeting decisions, relevant existing requirement artifacts, and only the project/context sources needed to verify claims. Treat a later confirmed meeting decision as higher priority than an earlier conflicting PRD statement.
+
+If the project has `.planning/requirements/{feature}/`, create or update:
+
+- `可实现性审查.md`
+- `可实现性审查.meta.json`
+
+Otherwise return the same structure in the response. Read [references/review-method.md](references/review-method.md) and [references/review-template.md](references/review-template.md) before writing an artifact.
+
+Maintain a separate evidence-and-boundary ledger throughout the review. Every conclusion must be one of:
+
+- `SOURCE_FACT`: exact source text plus locator proves it;
+- `CONFIRMED_DECISION`: the user or an authoritative decision maker chose it;
+- `ACCEPTED_IMPLEMENTATION_DIRECTION`: an explicitly authorized or behavior-preserving technical choice;
+- `DERIVED_QUESTION`: a consequence that the source leaves unspecified;
+- `ASSUMPTION`: a temporary bridge that cannot close the baseline gate.
+
+Never write a derived question or implementation direction as if it were a source fact.
+
+Use this minimum metadata shape:
+
+```json
+{
+  "feature_name": "",
+  "status": "in_review | needs_decision | blocked | ready_for_baseline",
+  "baseline_gate": "pass | blocked | needs_decision",
+  "reviewed_at": "",
+  "source_summary": [],
+  "claim_count": 0,
+  "proven_count": 0,
+  "gap_count": 0,
+  "critical_finding_ids": [],
+  "next_action": ""
+}
+```
+
+## Workflow
+
+### 1. Atomize The Source Rules Before Summarizing
+
+Do not start from a compressed flow. Extract every normative source statement into a rule ledger first. Preserve its source location and authority. A note, parenthesis, example, exception, historical-data statement, or appendix is a rule when it changes an outcome, state, audience, constraint, or recovery path.
+
+Force a separate rule for wording such as `注`, `若/如果`, `除非`, `历史`, `已存在`, `仅`, `必须`, `禁止`, `例外`, `兼容`, `重新`, `变更`, and their semantic equivalents.
+
+Every rule must ultimately map to one or more of: a skeleton node, state transition, data mapping, external call, authorization rule, exception path, acceptance scenario, gap, or decision. An unmapped rule blocks a claim of flow completeness.
+
+When two source statements appear to conflict, first test whether they govern different actors, data classes, or lifecycle phases. Prefer the more specific rule for its exact scope, and narrow a broader statement only when that preserves both statements without inventing behavior. Record the reconciliation and its scope; raise `CONFLICT` only if no non-invented separation exists.
+
+Also classify each statement as `background/problem`, `normative rule`, `trigger/process`, `example/mock`, or `exception/history`. Evaluate the complete behavior chain before raising a gap: a background risk may already be resolved by a later validation or confirmation process. Use this authority order when scopes overlap: confirmed decision → normative rule → trigger/process → scoped exception/history → example/mock/OCR → background motivation. Never invent a separate threshold, popup, state, field, or API from background wording when a higher-authority end-to-end mechanism already fulfills it.
+
+Before creating `DERIVED_QUESTION`, `CONFLICT`, or `ASSUMPTION`, document at least two surviving interpretations and the material outcome each changes. If the full source supports one coherent interpretation, record it as a reconciled source rule instead of asking the user. When illustrative numbers conflict with an explicit formula or validation rule, the explicit rule governs and the example must be flagged as non-normative.
+
+When a reviewer says a rule is absent, incomplete, or contradictory, locate the raw source before classifying the finding. A compact meeting summary, previous review conclusion, or flowchart is a navigation aid—not proof. Record separately: (a) the exact source-supported rule, and (b) the narrower derived question that remains.
+
+### 2. Build A Falsifiable Skeleton
+
+Create only the high-level stages and material state boundaries. Label every stage as `evidenced`, `inferred`, `to_expand`, or `issue_placeholder`; never present an inferred happy path as a confirmed requirement.
+
+### 3. Expand The Skeleton Breadth-First
+
+Expand every unfinished skeleton node by exactly one causal layer per pass: prerequisite, decision, state, external boundary, recovery branch, or downstream consumer. Repeat passes until no material branch or intermediate state is newly introduced.
+
+Before classifying an external API input as missing, trace every documented upstream interaction of that node, especially “select type → enter form → submit”. Build a field provenance list: `required API input → candidate form field / existing account field / operation source → collection timing → validation`. A required input is a real gap only when no documented upstream source can provide it, or when the source cannot be unambiguously bound to the external identity.
+
+For every user-visible or downstream field, maintain a separate provenance matrix: `field → local submission / external verification result / external detailed record / derived value → permitted use`. Do not infer that a verifier must return full identity data when local submitted data is sufficient for display or document filling; conversely, do not treat locally submitted data as proof that an external verification succeeded.
+
+Register an unknown immediately as a typed issue placeholder (`GAP`, `DECISION`, `DEPENDENCY`, `CONFLICT`, `ASSUMPTION`) rather than inventing a connecting step. Continue enumerating independent branches; stop and ask one question when the missing fact makes the next truthful layer impossible.
+
+Treat an explicit scope exclusion as a state-changing decision. Mark its affected branches `out_of_scope`, remove it from the current blocking chain, and state which existing behavior remains in force. Do not keep requesting decisions for an excluded capability.
+
+### 4. Freeze The Claim Set
+
+Extract atomic claims in this form:
+
+```text
+Actor + trigger + promised outcome + condition + system boundary
+```
+
+Example: “A new enterprise administrator can click enterprise verification and complete onboarding through an e-sign provider.”
+
+Record source and authority for every claim: confirmed meeting decision, PRD, user statement, observed code, external official documentation, or inference. Never silently promote an inference to a requirement.
+
+### 5. Build The Capability Chain
+
+For each material claim, work backwards from the promised outcome. Require evidence for every link:
+
+```text
+actor identity
+→ authority
+→ required inputs and their source
+→ internal state transition
+→ external/API capability
+→ callback or response
+→ persistence and mapping
+→ user-visible recovery
+→ policy/permission enforcement
+```
+
+Mark the first missing link as a gap. A click, mockup, or endpoint name is not evidence of a complete chain.
+
+### 6. Apply First-Principles Proof Obligations
+
+For every branch that changes business state, answer these questions with evidence:
+
+1. **Identity** — Who is acting? Is the system identity, legal entity, login account, and external-provider account unambiguously mapped?
+2. **Authority** — Why may this actor perform the action? Cover roles, legal representative/agent authority, ownership, and delegated permissions.
+3. **Inputs** — What exact inputs does the downstream system require? Who supplies each field, when, and how is it verified?
+4. **State** — What is the source of truth before and after the action? Define allowed states and idempotency key where applicable.
+5. **Boundary** — Can the external system/API actually perform the requested operation under the purchased version, app scope, and identity model?
+6. **Evidence** — Which callback, query, or immutable record proves success? Do not use a browser return redirect as final success evidence.
+7. **Recovery** — What happens on pending, failure, refusal, expiration, duplicate callbacks, missing callbacks, and interrupted login?
+8. **Enforcement** — At which entry points must the resulting policy be enforced: login, menu, create, promotion, payment, withdrawal, export, admin edit, or API?
+
+When a requirement uses one overloaded business word (for example authorization, approval, verification, activation, confirmation, or synchronization), split it into independently verifiable capabilities before raising a finding. Typical dimensions are: identity proof, data-access consent, action consent, delegated/representative authority, and lifecycle/state transition. Record the actor, timing, scope, data boundary, and success evidence for each. Do not infer that satisfying one capability satisfies another merely because the UI or vendor uses the same word.
+
+For authentication, authorization, signature, approval, or similar third-party legal/eligibility actions, separately prove two layers: **local product permission** (who can enter, initiate, create related accounts, or view results) and **external qualification** (who is a legal representative, authorized agent, seal holder, or otherwise eligible). Never infer external legal qualification from a local role. Conversely, third-party qualification checks do not remove the need to define local entry, preconditions, and failure handling.
+
+### 7. Run Adversarial Review
+
+Attack every “obvious” step with the smallest realistic counterexample. At minimum test relevant variants below:
+
+| Attack | Ask |
+|---|---|
+| Missing prerequisite | What if a required phone, email, entity name, account ID, consent, or mapping does not exist? |
+| Identity split | What if login account, legal entity, payer, signer, recipient, and external account differ? |
+| Role split | What if an employee account performs an action intended for a primary administrator? |
+| State split | What if the external provider is complete but local state is pending, stale, duplicated, or absent? |
+| Time split | What if a contract expires, template changes, a callback arrives late, or a user resumes days later? |
+| History split | What if legacy data cannot be automatically matched, has multiple subjects, or has no record? |
+| Bypass | Can another page, API, role, or cached session bypass the stated gate? |
+| Scope split | Does a vendor feature exist generally but not for this app, purchased edition, environment, or authorization scope? |
+
+State the counterexample, the broken promise, and the minimal requirement or technical decision that resolves it.
+
+### 8. Gather Evidence Correctly
+
+- Read project indexes, navigation, and relevant specs before source inspection.
+- Use the code index for candidate symbols and relations, then read narrow source evidence.
+- Before reading external documentation, record the requirement-selected provider, product family, integration scheme, API version, app/tenant, and environment. Evidence from another version or product family may suggest a candidate approach, but cannot prove or disprove the selected integration.
+- For external capabilities, use current primary documentation and the actual enabled product/version where accessible. “The vendor has an API” is insufficient evidence.
+- Distinguish **supported by official docs**, **confirmed enabled for this project**, **observed in code**, and **not verified**.
+- Do not inspect deeply merely to avoid a decision. Stop once evidence establishes the gap or capability boundary.
+
+### 9. Run The Reverse Coverage Gate And Classify Findings
+
+For each source rule, identify the exact flow/state node or issue ID that realizes it. For each flow node, identify the source rules or explicitly labeled inference that justify it. A flow is incomplete when either direction is missing.
+
+As a final consistency check, verify that no issue was created from a background statement already realized by a later flow node, and that no example/mock/OCR value overrides an explicit rule. Remove stale questions and findings before calculating `gap_count` or the baseline verdict.
+
+Only after this reverse pass classify and route findings.
+
+Classify each claim:
+
+| Verdict | Meaning | Required action |
+|---|---|---|
+| `proven` | Every material link has evidence | Keep as confirmed requirement |
+| `feasible_with_decision` | Technology supports it, but a business rule is missing | Ask one decision-changing question or create a grilling ticket |
+| `feasible_with_gap` | A required input, mapping, state, or screen is absent | Add a concrete requirement gap; do not claim the flow works |
+| `unverified_dependency` | Vendor/project entitlement or contract is unknown | Create a research/validation ticket |
+| `not_feasible_as_written` | A required link cannot be satisfied under current constraints | Reframe requirement or choose another approach |
+
+Only say “the requirement is implementable” when all critical claims are `proven`, or their explicitly accepted gaps are planned and non-blocking.
+
+Use self-directed technical choices only under one of these conditions:
+
+1. the user explicitly delegated the choice; or
+2. the choice preserves every source-visible outcome, adds no business policy, and only selects a minimal technical mechanism.
+
+Mark these as `ACCEPTED_IMPLEMENTATION_DIRECTION`, including its scope, why it is behavior-preserving, and its replacement trigger. Do not use a technical preference to resolve a question about money, legal responsibility, data ownership, user rights, exception population, or scope; ask instead.
+
+### 10. Ask And Stop Correctly
+
+- Ask at most one question at a time; ask the highest-level unresolved decision first.
+- Ask for a decision, not a technical detail the system can discover.
+- If a missing prerequisite invalidates the next step, stop there. Do not continue a fictional happy path.
+- Separate “a solution exists” from “the current requirement includes the solution.”
+
+### 11. Process A Rebuttal Without Defending The Prior Finding
+
+When the user challenges a finding:
+
+1. State the exact broken link the finding claimed, not its label.
+2. Test whether the rebuttal supplies that link using first principles: actor, authority, input source, state transition, external capability, and success evidence.
+3. If it does, mark the original gap resolved or narrow it; record the new confirmed rule and update every impacted flow node and coverage row.
+4. If it only solves a different capability, keep the unsolved link but rewrite the finding in precise terms.
+5. Extract the error pattern into a provider-neutral guardrail in the skill. Never copy the current vendor, field name, or product terminology into the generic workflow.
+
+Before accepting the rebuttal or retracting the finding, re-open the cited raw source and state its exact locator. If the source supports the old rule but not the added implication, retain only the implication as the issue. If it supports neither, retract the finding and remove all stale references from the skeleton, coverage matrix, metadata, and next-action field.
+
+## Quality Bar
+
+The review must make it easy to trace every conclusion back to evidence. Include:
+
+- flow inventory and critical capability chains;
+- a claim ledger with source authority;
+- adversarial counterexamples;
+- a gap/decision register with severity and exact next action;
+- an explicit baseline gate verdict.
+
+Do not declare a flow complete merely because its skeleton has been drawn. Completion requires: all material skeleton nodes expanded, each critical node proven against the capability chain, and no normative source rule left unmapped.
+
+Do not mark the review `ready_for_baseline` while any `ASSUMPTION`, unaccepted implementation direction, unresolved conflict, or critical derived question remains. A `pass` gate reports review readiness only; it must never itself create or advance a requirement baseline.
+
+Do not write implementation plans, API contracts, or code unless the user separately requests them.

package/plugins/devflow-requirements/skills/requirement-feasibility-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Requirement Feasibility Review"
+  short_description: "Audit requirements before baseline with evidence"
+  default_prompt: "Use $requirement-feasibility-review to audit this requirement before baseline."

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

@@ -0,0 +1,257 @@
+# 可实现性审查方法设计
+
+## 目标与非目标
+
+目标是证明一项需求承诺能否从触发到结果闭环，并在进入基线前暴露缺少的业务规则、数据前提、状态转换、外部能力和权限约束。
+
+不以生成漂亮流程图、复述 PRD 或补写实现方案为目标。流程图是待验证结构，不是结论本身。
+
+## 一、审查对象模型
+
+### 1.1 原文规则
+
+最小审查单位是规则，而不是页面或功能模块。
+
+```text
+Rule = 来源位置 + 触发/条件 + 主体 + 承诺结果 + 约束/例外 + 证据级别
+```
+
+规则必须保留原文位置。以下内容强制拆为规则：条件句、注释、脚注、括号、存量兼容、例外名单、时间条件、禁止项、错误说明和跨系统说明。
+
+### 1.1.1 证据与判断边界台账
+
+任何结论先归类，后进入流程：
+
+| 类别 | 可作为什么 | 必须具备什么 | 不可伪装成什么 |
+|---|---|---|---|
+| `SOURCE_FACT` | 已确认业务规则 | 原文摘录和精确位置 | 推断或摘要 |
+| `CONFIRMED_DECISION` | 已确认选择/范围 | 用户或有权决策者的确认 | 原 PRD 原话 |
+| `ACCEPTED_IMPLEMENTATION_DIRECTION` | 实现收敛方向 | 授权或不改变任一业务结果的证明 | 已确认业务政策 |
+| `DERIVED_QUESTION` | 待审查问题 | 它从哪条原文规则推导而来 | 原文缺失本身 |
+| `ASSUMPTION` | 临时骨架占位 | 回收动作和截止点 | 审查通过依据 |
+
+每个“缺口”必须写成两段：先列原文已确认的最小规则及位置，再列该规则没有回答的具体问题。禁止把后者改写成“原文没有规则”。
+
+### 1.2 流程节点
+
+```text
+Node = 业务目的 + 前置状态 + 行动者 + 输入 + 状态变化 + 输出/证据
+```
+
+节点分为阶段节点、决策节点、状态节点、外部边界节点、恢复节点和问题占位节点。未知事实不可伪装成普通节点。
+
+### 1.3 问题占位
+
+```text
+Issue = ID + 类型 + 断裂链路 + 影响范围 + 严重度 + 需要谁决定/验证
+```
+
+类型仅使用：
+
+- `GAP`：所需输入、数据映射、页面、状态或规则缺失；
+- `DECISION`：存在多个合理业务语义，必须选一；
+- `DEPENDENCY`：外部产品、版本、权限、配置或历史数据尚未证实；
+- `CONFLICT`：权威来源彼此冲突；
+- `ASSUMPTION`：为暂时画图而作的推断，必须回收验证。
+
+### 1.4 概念同名的能力拆分
+
+需求中的“授权、审核、验证、确认、激活、同步”等词经常覆盖不同能力，不能把它们当成单一状态。对每个同名概念按下表拆分：
+
+| 能力维度 | 要证明的问题 | 常见发生位置 | 不应推导出的结论 |
+|---|---|---|---|
+| 身份证明 | 行动者或主体是谁 | 注册、验证、操作页 | 身份已证明不等于可读取其数据 |
+| 数据访问同意 | 系统可否读取、存储或转发某类数据 | 授权页、隐私同意、回调 | 可读取数据不等于可代为操作 |
+| 行为意愿/确认 | 行动者是否知情并同意某次动作 | 提交、签署、支付、审批页 | 同意本次动作不等于持续数据授权 |
+| 代理/代表权限 | 行动者能否代表另一主体操作 | 委托、审批、角色分配 | 可代理一次不等于拥有主体所有权 |
+| 生命周期状态 | 该能力是否仍有效、可撤销或需续期 | 状态查询、定时检查、重新确认 | 曾经有效不等于当前仍有效 |
+
+对每一维记录：行动者、时间、范围、数据边界、成功证据、失效与恢复。不得因任一维已满足，就删除其他维度的证明。
+
+### 1.5 内部权限与外部资格分层
+
+认证、授权、签署、审批等场景至少有两层：本地产品权限决定谁可进入、发起、创建关联账号或查看结果；外部平台资格决定谁具备法人、受托、印章或其他法定资格。不得从本地角色直接推导外部资格，也不得把外部校验当作本地入口、前置或失败处理无需设计的理由。两层均需分别记录规则、证据和异常路径。
+
+## 二、分层构建算法
+
+### 阶段 0：规则提取和来源定级
+
+1. 读取 PRD、会议结论、用户补充、既有需求工件、代码事实和外部官方材料。
+2. 逐句提取所有会改变系统行为的规则，不生成流程。
+3. 为每条规则编号并记录来源优先级。发生冲突时，以后续已确认会议或用户确认覆盖较早的 PRD。
+4. 标记尚未映射的规则；此时不得声称流程完整。
+
+当来源看似冲突时，先检验其是否分别作用于不同角色、数据类别或生命周期阶段。对精确范围采用更具体的规则；只有在不虚构行为且能同时保留两条原文时，才可将宽泛表述收窄解释。必须记录该解释及其边界；无法分层时才登记为 `CONFLICT`。
+
+输出：规则台账。
+
+#### 质疑与回溯门禁
+
+当任何人质疑“这条描述从哪里来”时，暂停扩展该结论：
+
+1. 回到原始 PRD、会议逐字稿或用户原话；
+2. 给出精确段落、行号、页码或时间戳；
+3. 拆开“原文已说”与“审查者由此推导”；
+4. 只有原文不支持时才撤回；原文支持但推导过度时，只撤回推导；
+5. 同步修改问题表、骨架、覆盖表、元数据和下一问题。
+
+不得因被质疑就立即顺从性撤回，也不得用审查摘要替代原始证据。
+
+### 阶段 0.1：外部能力边界锁定
+
+凡涉及第三方能力，先建立边界卡：
+
+```text
+供应商 → 产品族 → 接入方案 → API 版本 → App/租户 → 环境 → 已购权限
+```
+
+后续每条官方文档证据必须标注其所属边界。不同产品族、不同版本或不同接入方案的接口不能互相替代；它们最多是待验证候选方案。若需求已经指定版本，先查该版本文档，再讨论其他版本。
+
+### 阶段 1：待证伪骨架
+
+1. 只从规则台账中抽取不可省略的业务阶段和跨系统状态边界。
+2. 将每个节点标为 `evidenced`、`inferred`、`to_expand` 或 `issue_placeholder`。
+3. 不添加没有来源的“通常会有”的登录、校验、回调、落库或页面步骤。
+4. 将无法连接的规则保留为问题占位，而不是删除。
+
+输出：最高层骨架与节点状态。
+
+### 阶段 2：广度优先扩充骨架
+
+对所有 `to_expand` 节点循环执行“一层扩充”：
+
+1. 先补该节点的前置条件和输入来源；
+2. 再补决策分支和状态；
+3. 再补外部调用、回调/查询证据和本地持久化；
+4. 再补恢复路径、历史兼容和下一节点消费者；
+5. 给新节点标注来源规则或 `ASSUMPTION`；未知即建立问题占位。
+
+对于每个外部调用，必须先完成“输入血缘检查”，再声称字段缺失：
+
+```text
+外部必填字段
+→ 上游已有账号字段 / 选择后的表单字段 / 运营配置字段
+→ 采集时机
+→ 校验与外部身份绑定规则
+```
+
+不得把“选择类型后进入对应表单”压缩为“选择类型后直接跳转外部平台”。详细交互规则优先用于补全骨架；页面标题、摘要或演示文案不能覆盖已明确的表单与提交步骤。
+
+同时建立“字段用途与证据矩阵”：
+
+```text
+字段
+→ 来源（本地提交 / 外部状态 / 外部详情 / 派生）
+→ 用途（展示 / 合同填充 / 外部调用 / 准入判断 / 审计）
+→ 是否需要外部真实性证明
+```
+
+外部验证服务可以只承担“状态证明”，本地表单可以承担展示和下游填充；两者不得混用。只有需求明确要求展示外部详情，或下游必须使用外部返回的身份标识时，才要求读取外部详情数据。
+
+### 阶段 4.1：反驳回归
+
+当需求方反驳审查问题时，不为原结论辩护，而是执行固定回归：
+
+```text
+原问题断言的链路缺口
+→ 反驳提供的新证据或规则
+→ 是否填补同一缺口
+→ 解决 / 缩小 / 保留但改写
+→ 回写规则台账、骨架、证明卡、覆盖矩阵和技能护栏
+```
+
+如果反驳成立，必须说明先前遗漏了哪一类输入、状态、例外或能力维度，并抽象为通用检查项；不得把当前业务系统、外部供应商、字段名称或角色名称写进通用技能。
+
+本阶段按轮次进行。先让所有主链路拥有同等深度，再进入下一层；不得只深挖一个看似熟悉的节点。
+
+停止条件：连续一轮没有新增材料节点、状态分支或跨系统边界，或某个阻塞问题使下一层不可能诚实构建。
+
+输出：包含中间节点、条件分支、系统边界和问题占位的流程拓扑。
+
+### 阶段 2.1：范围排除与最小实现方向
+
+若用户确认某能力“不做”或“不在本期”，记录为 `CONFIRMED_DECISION / out_of_scope`：说明它影响的节点、当前保留的旧行为、以及未来重新审查触发条件。不得继续把它列为本期阻塞。
+
+若用户允许自行决定实现方式，优先选择最小侵入、可替换、集中维护、不会改变原文可观察结果的方案。将其记为 `ACCEPTED_IMPLEMENTATION_DIRECTION`，并写明：
+
+```text
+授权范围 / 保持不变的业务结果 / 技术机制 / 配置或数据来源 / 何时需要升级为产品决策
+```
+
+技术方案不得替代对资金、主体、法律责任、例外名单或数据归属的业务确认。
+
+### 阶段 3：深度证明节点
+
+对已收敛的每个材料节点建立证明卡：
+
+```text
+身份与主体
+→ 权限/授权
+→ 精确输入及来源/校验
+→ 前后状态和幂等
+→ 内外部能力
+→ 成功证据和落库映射
+→ 失败、暂停、超时、重复、历史恢复
+→ 所有入口的策略拦截
+```
+
+任意箭头缺失时，记录第一个断点，节点不可判定为 `proven`。
+
+输出：节点证明卡和能力链结论。
+
+### 阶段 4：反向覆盖和反方攻击
+
+执行两项独立检查：
+
+1. **规则到流程**：每条规则必须落到节点、状态、数据、接口、权限、异常、验收或问题之一。
+2. **流程到规则**：每个节点必须有来源规则，或显式标记为推断；无依据节点不得混入确认流程。
+
+反方至少攻击：前提缺失、身份分裂、角色越权、内外状态不一致、时间/版本变化、存量数据、入口绕过、外部版本或授权范围不一致。
+
+输出：覆盖矩阵、反方案例和问题清单。
+
+## 三、阻塞与提问策略
+
+先登记所有可独立发现的问题。遇到以下情形立即停止当前分支，并只提出一个能改变结构的最高优先级问题：
+
+- 没有身份键，无法查询、授权或关联外部系统；
+- 缺少主体/资金/签约责任归属，后续规则不能安全推断；
+- 两个同等权威来源给出相反的状态或权限结论；
+- 外部能力在已购版本、app、环境或 scope 下尚未证实；
+- 选择任一默认方案都会改变用户、资金、合规或数据归属。
+
+不阻断拓扑构建的问题继续登记，待结构收敛后统一给出清单。
+
+## 四、基线门禁
+
+只有同时满足以下条件才可标记 `ready_for_baseline`：
+
+1. 所有规范性原文规则已有覆盖位置或已接受的问题处置；
+2. 所有关键节点完成能力链证明；
+3. 没有未解决的阻塞 `GAP`、`CONFLICT` 或 `DEPENDENCY`；
+4. 所有 `ASSUMPTION` 均已验证、删除或升级为显式决策；
+5. 对抗案例没有暴露可绕过的关键承诺。
+
+6. 每个结论都能回溯到 `SOURCE_FACT`、`CONFIRMED_DECISION` 或已接受的、行为保持的实现方向；不存在未回收的 `ASSUMPTION`。
+
+否则仅能给出 `needs_decision` 或 `blocked`，不得推进需求基线。
+
+`ready_for_baseline` 只表示审查结论已经收束；除非用户明确要求，绝不自动创建或进入需求基线。
+
+## 五、外部身份场景示例
+
+规则“历史已验证的用户查询验证信息并直接显示完成”至少要求以下链条：
+
+```text
+本地业务账号
+→ 可归属的外部身份键
+→ 历史状态查询
+→ 外部主体与本地主体匹配
+→ 同步证据与映射
+→ 脱敏展示
+→ 进入后续签约
+```
+
+若本地账号不保证外部查询键，且所选外部接口又以该键查询，必须创建 `GAP`，不能将“跳转验证页面”画成该规则的实现。
+
+但若验证前的已确认表单已采集外部查询键，则先将该字段列为候选来源，并审查其与本地账号、本地主体及外部身份的绑定规则；不能直接判定“没有输入来源”。

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

@@ -0,0 +1,80 @@
+# 可实现性审查：{feature}
+
+## 审查范围与结论
+
+- 审查对象：
+- 基线门禁：`pass | blocked | needs_decision`
+- 关键结论：
+
+## 来源优先级
+
+| 来源 | 权威级别 | 说明 |
+|---|---|---|
+| | confirmed_meeting / prd / user_statement / code / official_docs / inference | |
+
+## 证据与判断边界台账
+
+| ID | 结论 | 类别（SOURCE_FACT / CONFIRMED_DECISION / ACCEPTED_IMPLEMENTATION_DIRECTION / DERIVED_QUESTION / ASSUMPTION） | 原始证据与定位 | 适用范围/回收条件 |
+|---|---|---|---|---|
+| E-001 | | | | |
+
+## 原文规则台账（先于流程）
+
+| Rule ID | 原文摘录与位置 | 规则类型 | 权威来源 | 初始覆盖状态 |
+|---|---|---|---|---|
+| R-001 | | 主路径 / 条件 / 例外 / 历史 / 权限 / 数据 / 异常 / 展示 | | 未映射 |
+
+## 待证伪骨架与逐层扩充
+
+| 节点 ID | 阶段或状态 | 状态（evidenced / inferred / to_expand / issue_placeholder） | 来源规则 | 本轮新增层 | 关联问题 |
+|---|---|---|---|---|---|
+| N-001 | | | | | |
+
+> 先广度优先补齐中间节点、分支和系统边界；完成后才深拆节点。不得把推断的 happy path 标为已确认。
+
+## 流程与能力链
+
+| Claim | Capability chain | Verdict | Evidence | First gap |
+|---|---|---|---|---|
+
+## 节点证明卡
+
+| 节点 ID | 身份与权限 | 输入及来源 | 状态变化与幂等 | 外部能力与证据 | 恢复与入口拦截 | Verdict |
+|---|---|---|---|---|---|---|
+| N-001 | | | | | | |
+
+## 对抗式审查
+
+| Counterexample | Broken promise | Verdict | Minimal resolution |
+|---|---|---|---|
+
+## 缺口与决策登记
+
+| ID | Severity | Type | Missing fact or decision | Owner | Next action | Blocks baseline |
+|---|---|---|---|---|---|---|
+
+> 每条问题补充：已确认原文规则/定位；该规则尚未回答的派生问题；不能以派生问题否定原文规则。
+
+## 范围排除与实现方向
+
+| ID | 类别 | 决定/方向 | 授权或来源 | 保持不变的业务结果 | 替换触发条件 |
+|---|---|---|---|---|---|
+| D-001 | out_of_scope / accepted_implementation_direction | | | | |
+
+## 反向覆盖门禁
+
+| Rule ID | 实现位置（节点/状态/接口/验收/问题） | 覆盖结论 | 未覆盖原因 |
+|---|---|---|---|
+| R-001 | | covered / issue_registered / uncovered | |
+
+| 节点 ID | 支撑来源规则或推断 ID | 结论 |
+|---|---|---|
+| N-001 | | evidenced / explicitly_inferred / unsupported |
+
+## 已确认规则
+
+- 
+
+## 不应假设
+
+-