/dev-plan-review

name: dev-plan-review
description: 技术方案验证（两阶段质量门禁）— PR-1 CP2 前自检 + PR-2～PR-7 详细验证，阻断不合格方案进入编码

Dev Plan Review Skill

定位

本 Skill 分为**两阶段**执行，确保方案在用户确认前已通过基础检查：

阶段一（CP2 前·AI 内部自检）：PR-1 需求完整性 → 🔴 不通过则修正后重检，不呈给用户
阶段二（CP2 后·详细验证）：PR-2~PR-7 → 🔴 阻断回 CP2 → 全通过 → [影响评估] → CP3

> 🔴 不可跳过。`docs` 子类型（豁免）和 `plan-review` 子类型（防递归）除外。 > > **R9 / R12**：顺序「方案 → PR-1 → 确认 CP2 → PR-2~PR-7 → CP3 → 编码」。呈交方案时独立 `03-方案复审*` 与 `.memory/review-execution-pr1.json` 引用同一候选摘要和 ReviewState；生成与回读方式见 `review-checklist`。sessions 通过符号、报告示例或通过话术不能替代证据。缺失时 Stop 只投影 `processGaps+=pr1-skipped` 诊断；R10 精确任务状态校验和宿主权限边界见 `cp-gate`。

> ⚠️ 边界说明：本 Skill 只负责**编码前**的方案质量门禁，不覆盖执行后的关键产物复审；执行后的稳定性确认由 `10-dev.instructions.md` 中的“ECR 执行闭环复审”规则负责。

PR-1 与 PR-2~PR-7 各阶段开始前必须由 `review-checklist` Owner 形成 candidate-bound `ReviewExecutionPlanV1`；BlockerSnapshot、执行命令与零发现结论形成 `ReviewEvidenceReceiptV1`。方案或规则/Skill/Probe/影响图变化后旧 receipt 立即 stale，不得因文件少复用旧阶段结论。

CP2 候选进入阶段二前必须先通过 `RequiredCandidateEvidenceGate`：技术方案中存在 fresh `CandidateReviewBundleV1`，且 `phaseKind=CP2`、`TDMatrix`、`BlockerSnapshot`、`ClaimEvidenceMatrix` 均完整。机器负向样本由 `scripts/lib/candidate-review-bundle.js` 与 `npm run test:candidate-review-bundle` 覆盖；缺失、陈旧、软确认绕过或 open blocker 均回 CP2 修订。

豁免

• `dev-docs` 子类型：豁免（文档产物，不涉及代码实施）
• `dev-plan-review` 子类型：豁免（自身即为审查，防递归）
• `dev-scenario-test` 子类型：豁免（已有独立质量门控）

执行顺序与 Blocker 聚合规则

> 🔴 **BlockerAggregationGate**：检查仍按编号顺序执行，但同一阶段必须继续完成所有**安全独立检查**，一次形成完整 `BlockerSnapshot` 后再回退修正。禁止因为发现首个红项就隐藏后续可独立发现的问题。

每个 `BlockerSnapshot` 至少记录 `stage / blockerId / evidence / affectedSurface / remediation / skippedChecks / stopReason`。只有以下情形允许 fail-fast，并须保留未执行项和恢复入口：

• `invalid-premise`：输入、目标项目或权威事实源无效，继续检查只会产生无意义结论；
• `destructive-side-effect`：下一项检查会产生破坏性或未经授权的外部副作用；
• `evidence-contamination`：测试环境、候选产物或证据链已污染，后续结果不再可信。

发现 blocker 后先收集本阶段剩余安全独立项，冻结快照，再统一修正并重跑完整阶段。任何 blocker 未关闭时仍禁止跨越 CP2/CP3。

PR-1 全量检查 → 聚合 BlockerSnapshot → 有 blocker 则统一修正并完整重检
    ↓ zero blocker
→ CP2 用户确认
    ↓
PR-2~PR-4 全量安全独立检查 → 聚合 BlockerSnapshot
    ↓ zero blocker
PR-5 影响标记（仅标记，不阻断）
    ↓
PR-6 架构质量（🟡 标注，不阻断）
    ↓
PR-7 测试与风险（🟡 标注，不阻断）
    ↓ 全通过
→ [impact-review] → CP3

阻断条件

以下任一 🔴 项未通过 → 记录到当前 `BlockerSnapshot`；完成本阶段其余安全独立检查后统一回退修正：

• PR-1 有需求点遗漏（阶段一：AI 内部修正后重检；阶段二不再重检 PR-1）
• PR-1 缺少 `§7.1 产品事实源→技术验证映射（需求验收映射）`，导致 CP1 需求方输入锚点 / 双方确认后的产品事实源 / 产品直接提供的 `01-产品需求.md` 无法追踪到设计点、验证路线或 CP3 任务
• PR-2 技术选型不兼容或存在"待定"步骤
• PR-2 非单文件小修、控制面、多模块、接口契约、数据/状态模型或模板-校验链任务缺少 `§2.0 目标架构与模块边界`、契约矩阵、数据/状态模型，且未写 `N/A + skipReason`
• PR-2 **ControlPlaneContractFirstGate**：Hook/MCP/CLI/descriptor/manifest/plugin 生命周期/CP 状态机/validate 语义/多宿主分发任务缺少 **Current→Target ContractMatrix**（字段、writer、reader、error/compat、迁移）或 `runtimeOwners`，且未写 `N/A + skipReason` → 🔴
• PR-2 **ClosureEvidenceGate**：方案或承接审查宣称 closed/可实施时，P0 项缺少双列 `designEvidence` + `runtimeOwners` + `negativeProbe`；仅 design 不得标 closed
• PR-2 非纯文案或单文件小修的方案缺少 `§2.7 最小实现与注释策略`、CP1 `WorkflowPlanDecisionV1.designDepth` 继承、复杂度预算，或新增抽象缺少真实消费者 / 既有本地模式 / 边界隔离 / 已确认契约依据
• PR-2 在 CP1 为 `简单够用` 或用户未要求复杂化时自行升级为 `中等` / `企业级`，但缺少用户确认、多方案取舍和维护成本说明
• PR-2 三方 provider / connector / SDK 接入类方案未先区分业务功能接口与底层 provider adapter，缺少 provider metadata、内部 payload、上游 request 映射、标准化 result、错误 detail 字段级合同，或首个 provider 反向定义公共 contract
• PR-2 包 / 库 / adapter / CLI 方案缺少代码实现层 + 包工程层检查，且未写 `N/A + skipReason`
• PR-2 缺少物化验证计划：方案只有泛泛“测试策略”，没有可 grep 的验证计划、命令/矩阵路线、验收标准、退出条件或 TestRoute 输入；涉及性能、并发、发布、文档站、前端、缓存/异步数据时未逐项写 N/A 或证据路线
• PR-2 缺少 `CandidateReviewBundleV1`、`TDMatrix`、`BlockerSnapshot` 或 `ClaimEvidenceMatrix`，或 `scripts/lib/candidate-review-bundle.js` 可分类为 `review-incomplete` / `blocked` / `stale` / `confirm-blocked`
• PR-2 条件治理 Gate 命中但未按 `../spec-governance/gate-registry.json` 记录 `gateGroup / ownerSkill / validationRoute / skipReason`（或聚合 `N/A + skipReason`）。PR-2 只保留触发索引，执行正文与字段归 Owner Skill：

| gateGroup / 触发面 | ownerSkill（入口） | 阻断要点（摘要） | |------|------|------| | 覆盖率 / 外部 runtime·plugin·registry·fingerprint / 风险簇升级 | `test-router` · `quality-strategy` · 领域 Owner | 缺 CoverageGateDecision、生命周期/fingerprint 矩阵或风险分层路线 | | `docs-ia-readability` · `user-manual` · `docs-semantics-examples` | `user-manual-authoring` · `dev-docs` · `document-sync` | 缺 page role / sidebar 任务模型、用户主路径或示例/语义真相 | | `expert-output-quality` · `expert-owner-skills` | `expert-output-quality` + 对应专家 Owner | 缺生产推荐路径/fixture 边界，或缺 ownerSkill 触发证据 | | `CodeTruthEvidenceMatrixGate` · `SolutionFitAgainstRepoGate` · **CodeTruthAtCpEntryGate（PF-139）** | `expert-output-quality` + repo 事实源 + `discipline-execution-probe` | 缺 repo path / symbol / currentBehavior / negativeProbe / reusePoint / consumer / rollback / statusQuoCost；控制面 CP 入口宣称可确认/定稿但无矩阵 → `classifyCodeTruthMatrixAtCpSample` fail | | `agent-capability-completeness` · `consumer-validation` · `module-performance-maintenance` | 对应 Owner Skill | 假全量：缺 completeness 对象、跨仓分母或模块性能维护证据 | | `brand-visual-quality` | `brand-visual-quality` | 缺母版谱系/主题几何/微尺寸单色/人工结论 | | 跨项目/最新/确认吸纳（`absorption-layering` · `confirmed-completeness` 等） | `spec-absorption` · `spec-governance` | 缺 registry 分组判定或 layerChecks / consumerProof | | `configuration-ergonomics` · 配置 canonical namespace · Profile runtime 同步 | `developer-experience-architecture` · `load-profile` | 缺最小配置、namespace/alias 或 ProfileImpactCheck 同步 | | `contract-release-authority` | `api-contract-architecture` · `release-verification` | 缺 publishedState / 消费者证据 / 兼容决策 | | `frontend-runtime`（含 UI 体验/Figma/preview/i18n） | `audit-project` · `test-router` · 前端相关 Owner | 缺体验判定或 Figma/preview/状态/资产证据 | | 依赖 / 框架 / SDK / 平台 API | （本 Skill PR-2 直接查） | 缺 `OfficialDocsEvidence`；升级未拆业务源码平滑性 vs 依赖层落地 |

• PR-2 触发依赖/框架/SDK/平台 API 引入或升级，但缺少 `OfficialDocsEvidence`
• PR-2 依赖升级 / 兼容任务未拆分 `业务源码平滑性` 与 `依赖层落地条件`
• PR-3 违反安全底线（C01/C03）或项目架构约束
• PR-3 涉及项目事实变化但未执行 `ProfileImpactCheck`
• PR-4 有未加权限控制的敏感操作

检查清单

PR-1 需求完整性

| 检查项 | 通过标准 | |--------|----------| | 方案是否覆盖了 CP1 双方确认的所有需求点？ | 无遗漏；未确认的需求方原始诉求不得进入实现范围 | | CP1 需求方输入锚点 / 产品事实源是否已映射到设计点、验证路线和 CP3 任务？ | 已在 `§7.1 产品事实源→技术验证映射（需求验收映射）` 逐项列出；若产品直接提供完