项目实现审查

在开发完成后，对照技术设计独立检查实际代码和运行行为，判断设计是否被正确、完整实现。完成一轮与改动风险相称的技术验收，列出本轮发现的所有有价值问题，并指出问题应回到哪个阶段处理。

核心原则

• 审查实际实现，不重新编写需求、技术方案或任务计划。
• 技术设计是实现符合性的主要判断依据；需求、已确认迁移基线中的目标兼容项和改动前可查证的既有行为是回归判断依据。没有正式文档时使用当前任务中已经明确的目标和真实项目基线，不为了审查补造文档。
• 不只阅读代码差异，还要检查与改动直接相关的调用链、配置、数据流和运行结果，确认代码真实接入。
• 独立设计并执行验证，不能直接复用执行阶段的完成结论。执行阶段的自测结果只能作为线索和补充证据。
• 列出本轮发现的所有实质问题，不只报告最严重的问题，也不为了凑数量记录格式偏好或无关建议。
• 严重程度决定问题是否阻塞完成以及处理优先级；问题根因决定回到执行、计划还是方案阶段。
• 审查只报告问题和回退建议，不在审查过程中静默修改代码、任务或方案。

读取材料

优先读取实际采用的需求、功能迁移基线（如有）、技术设计、任务清单（如有）、完整代码差异、相关项目文件和执行阶段的自测结果。任务清单或设计文档已有直接链接时沿链接读取，不根据相似文件名猜测，避免混入其他并行需求。

先确认本次审查对应的提交、代码差异或工作区范围，区分本次实现与用户已有的无关改动。正式需求、设计或计划文档都不是启动审查的硬性前提，但必须有足够明确的目标和实现方向，否则无法判断“正确、完整”。