dev-plan-review

# Dev Plan Review Skill ## 定位 本 Skill 分为**两阶段**执行，确保方案在用户确认前已通过基础检查： ```text 阶段一（CP2 前·AI 内部自检）：PR-1 需求完整性 → 🔴 不通过则修正后重检，不呈给用户 阶段二（CP2 后·详细验证）：PR-2~PR-7 → 🔴 阻断回 CP2 → 全通过 → [影响评估] → CP3 ``` > 🔴 不可跳过。`docs` 子类型（豁免）和 `plan-review` 子类型（防递归）除外。 > > **R9 / R12**：顺序「方案 → PR-1 → 确认 CP2 → PR-2~PR-7 → CP3 → 编码」。请求用户「确认 CP2」时磁盘须有 PR-1 通过证据（`03-方案复审*` 或 sessions `PR-1=✅`）；否则 Stop `processGaps+=pr1-skipped`。R10：控制面写路径 CP2 门见 `cp-gate` + lifecycle `checkCpGate`。 > ⚠️ 边界说明：本 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，并须保留未执行项和恢复入口： - `inva...