anian0/project-development-review-v2

项目开发审查 v2

独立审查项目开发文档，找出会导致后续计划粗糙、实现脱节、mock 完成或验收失败的问题。审查优先发现风险，不补写正文。

先读取

• ../project-development-v2-common/references/delivery-contract.md
• ../project-development-v2-common/references/no-simulation-policy.md
• references/review-gates.md
• references/review-report-template.md

按被审查对象再读取：

• 需求文档：读取来源材料和 ../requirements-workshop-v2/references/requirements-analysis-gates.md。
• 技术方案：读取对应需求文档和 ../tech-design-v2/references/tech-design-quality-gates.md。
• 实施计划：读取对应需求、技术方案和 ../implementation-planning-v2/references/plan-quality-gates.md。
• 执行结果：读取计划、相关任务文件、证据日志、代码改动和 ../plan-execution-v2/references/execution-checklist.md。
• 跨文档审查：同时读取需求、技术方案、计划和执行证据。

核心规则

• 以发现阻塞问题为主，不重写整份文档。
• 先列问题，再给总结；无问题时明确说没有发现阻塞问题。
• 每条发现必须包含文件位置、问题、影响和建议修复。
• 优先检查 R-* -> A-* -> C-* -> T-* -> V-* 链路。
• 对“已确认”“已覆盖”“无矛盾”等结论要找证据，不能直接相信文档自述。
• 发现技术方案或计划引用不存在的 API、字段、页面、事件、表或命令时，标为阻塞。
• 发现任务 done 缺少 done 前硬门禁、真实依赖接入、负向验证、测试资产合规或独立审核证据时，标为阻塞。
• 发现 mock、fallback、stub、固定回复、硬编码测试 ID 或不可验证闭环时，标为阻塞或高风险。
• 不要为了审查而提出无关问题；只有答案会改变下一阶段处理方式时才列为待确认。

审查模式

需求审查

检查：

• 需求是否描述用户能力或系统能力，而不是模块清单。
• 每个本期 R-* 是否有可观察 A-*。
• 每个本期 R-* 是否有用户可见闭环：入口、操作、成功可见结果、失败反馈、结果或状态可见位置。
• 有页面、入口、日志、状态或反馈时，是否有页面/入口覆盖表；无 UI 时是否显式声明可观察入口。
• 每个 A-* 是否标注验收关注点，能支撑技术方案拆成验证场景。
• MVP 范围是否清楚区分本期必须做、后续候选和不做范围。
• 关键对象、边界、事实源、失败隔离和不做范围是否清楚。
• Agent/AI 类需求是否说明任务类型、Agent/LLM 选择理由、角色边界、工具需求、自主度和失败风险。
• 特别关注点是否记录用户明确强调的约束、风险或偏好。
• 是否列出技术阶段必须确认的问题。
• 是否有未经确认却影响设计的假设。

技术方案审查

检查：

• 每个 R-* 和 A-* 是否有真实设计落点。
• 新技术、新模块、旧功能扩展是否有技术依据清单；缺少依据时是否列为风险、待决策或 not_verified 风险。
• 每个 C-* 是否有分类、类型、当前状态、目标状态、具体修改和关联 R/A/V，而不是抽象模块名。
• 每个 A-* 是否拆成可验证场景，并绑定 V-*。
• 需求中的关键字段、动作、状态、错误和来源追溯是否进入 API、数据、UI 或验证。
• 需求包含页面、用户入口、日志、状态或反馈时，是否有逐页 UI 契约和页面覆盖表；无 UI 时是否显式声明。
• 每个关键 V-* 是否有测试资产建议位置，能交接给 workplace/<version>/test/。
• 特别关注点是否从需求继承到技术方案和交接清单。
• 服务边界、部署形态、失败隔离、事实源和 API 风格是否前后一致。
• 每个 V-* 引用的 API、表、字段、页面、事件和命令是否已定义。
• 技术决策是否基于代码证据，是否遗漏可选方案和取舍。

计划审查

检查：

• 每个 C-* 是否有任务，每个 V-* 是否有任务或全局验证。
• 任务是否足够小，能直接执行，不要求执行者重新设计。
• 前端页面、状态、错误反馈、API 字段和 UI smoke 是否有任务。
• 是否有统一测试资产规划，且每个 V-* 能追踪到测试文件、验证脚本、UI smoke 或可观察步骤。
• 新增测试、fixtures、review 清单和 smoke 脚本是否被规划到 workplace/<version>/test/ 下。
• 每个任务是否有测试场景表和具体验收内容；不能只写“运行测试”或“检查页面”。
• 技术方案包含 UI 时是否有前端任务；无 UI 时是否明确声明。
• 任务文件是否自含，是否禁止用“参见 index.md/其他任务”省略核心上下文。
• 是否包含相邻接口摘要、特别关注点和交接清单。
• 跨服务、前后端、异步、日志、历史、Memory/Knowledge、Tool、Agent 配置是否有最终闭环任务。
• 是否存在用 mock、清单、人工口头检查或降级路径冒充完成。

跨文档一致性审查

检查：

• 需求 R-* / A-* 是否在技术方案有 C-* / V-*。
• 技术方案 C-* / V-* 是否在计划有 T-*。
• 计划任务是否能证明需求验收，而不是只证明模块存在。
• 文档之间的路径、状态、链接、范围和命名是否一致。
• 已完成状态是否有真实证据支撑。
• 执行证据是否包含测试资产合规、独立任务审核、最终审核和失败重试记录。

执行结果审查

检查单个任务或整份计划的执行结果：

• index.md 和任务文件状态是否与证据日志一致。
• 每个 done 任务是否有 done 前硬门禁记录：反模拟扫描、真实依赖接入、正向/负向验证、测试资产合规、独立任务审核。
• 证据日志是否包含实际命令、关键输出、修改文件、UI/API 观察和与计划偏差。
• 任务要求数据库、MCP/tool、调度、daemon、共享契约、diagnostics、日志或 UI 时，是否证明真实接入和可回查。
• 验收包含失败、超时、无效引用、隔离、诊断、禁用、撤回、压缩或来源追溯时，是否覆盖负向路径。
• 新增测试、fixtures、review 清单和 smoke 脚本是否位于计划指定的 workplace/<version>/test/ 下，或有计划例外。
• 反模拟扫描命中项是否已解释且解释成立；否则不得接受 done。
• not_verified、blocked、skipped 是否没有被包装成整体完成。
• 最终闭环/放行任务是否真实执行，且能追溯到 R-* / A-* / C-* / V-*。

输出

使用 references/review-report-template.md。保持简洁，默认只列阻塞和高风险问题；中低风险只在影响下一阶段时列出。

严重级别：

• BLOCKER：进入下一阶段会导致方案不可实施、验收无法证明或实现方向错误。
• HIGH：可能导致遗漏核心能力、返工或实现与需求脱节。
• MEDIUM：影响可读性、执行效率或局部验收可靠性。
• LOW：不阻塞，但建议整理。

完成标准

• 已说明审查对象和审查模式。
• 已列出所有阻塞和高风险发现，或明确没有发现。
• 每条发现都有具体位置和修复建议。
• 已给出是否可以进入下一阶段的结论。
• 没有把“建议补充文档”当作唯一修复；必须说明补什么契约、字段、验证或任务。