---
name: development-review
description: 通用开发的 Review 方法 owner；mode=design 审查实现前方案与验收设计，mode=implementation 审查已验证产物；返回 findings 和返工目标，不修改产物或执行发布。
---

# Development Review

## 目标

先明确 mode=design 或 implementation，不因尚无代码跳过方案审查。两个 mode 都按证据输出 findings，由总流程决定下一步。

## 方案 Review（mode=design）

检查目标覆盖、现有能力复用证据、owner/主链路唯一性、重要反例、失败边界、可行性，以及验收是否会放过不完整结果；缺证据即 finding，方案自洽不等于成立。
新项目、技术栈替换及新增关键运行/部署依赖，核对 Design 的技术决策是否有需求/环境依据、真实替代项的取舍（有分叉时）及关键可行性证据；仅列技术名称、凭习惯选择或将必要选择留到编码时均返回 Design。沿用小改与用户指定选择按其适用边界检查，不强制凑候选或追加审批。
从原用户目标独立核对设计的交付与黄金验收使用链路，不仅检查方案自洽：逐步走查动作、系统反馈、继续操作和最终判定，检查交付前提能否落实、AI 自验与用户判断是否分清。只有入口/测试清单、需要审查者补步骤，或全部测试通过仍拿不到原用户结果时，返回 Design。豁免必须符合任务范围与用户行为不变的事实，不能仅因没有 UI、改动在底层或尚未发布而成立；纯内部和用户明确限定的产物交付不强加运行环境。
大型交付从日志的原始输入记录定位相关原件，核对用途、版本、有效修订与必要阶段边界；检查本部分书面方案的“来源 → 有效要求 → 设计 → 验证”对应关系，不能仅检查 AI 的提炼。功能/交互要求不能因原件是 HTML 就降为样式参考；明确只是参考的部分也不自动升级成硬约束。漏项、未解释偏差、缺当前部分书面设计或待决提案冒充有效约定均是 finding。实现 Review 从产物反查同一来源与已确认变更，不能靠实现、测试和后来改写的标准相互一致放过漂移。结论关联对象版本和证据，复用原日志，不另建验收表。

跨架构设计按合同的旧能力／用户目标／候选能力双向对账，独立核对原始来源和旧新真实入口。先确认方案覆盖当前有效目标；旧→新有未解释的用户可见变化，或目标→新有必需能力被列为未来、没有可触发入口或完整使用场景，都是 finding。其它分支的成功测试不能抵销。

性能或成本列为 Required 时，检查门槛是否在实现前按可复现条件固定，候选比较与验收是否覆盖真实用户等待、代表使用量和关键冷/热分支；只有理论推断或单次最佳值是 finding。不因当前任务没有性能取舍而要求例行压测。

核对本次拟实现部分是否已具体设计；整体设计允许后续细节待定，但不得遗留影响当前实现的未决选择。通过结论标明适用范围，不扩展到未审查的待细化部分。问题给出对应设计位置、影响和修正方向；未关闭 finding 返回 Design，通过返回 design-review: passed。后续补充或改变设计后审查受影响部分。不运行代码维护性脚本，不要求子代理，不复制完整方案。以下环节仅适用于 implementation。

## 进入

- 有实现产物时，在验证证据稳定后进入；
- 用户明确要求代码 review、PR review、风险扫描或拟议修复评审时可直接进入；
- 纯文档、措辞和普通元信息只做内容、结构和 diff review，不运行代码维护性脚本；
- 普通局部改动使用轻量 review，L3-L4、跨模块、结构大改或用户明确要求时执行完整 findings-first review。

## 自动检查

源码、脚本、测试或运行链路配置改动先运行一次项目已有的 diff-only maintainability 检查；项目没有该检查时直接按下面的 findings-first 方法审查，不为满足流程临时发明脚本。项目检查的预算、参数与阻塞级别由项目自身定义。不得为消除普通净增长扩大无关范围、压缩可读性或删除类型/协议保护。

## Findings-first 审查

1. 明确 diff、触达文件、相邻合同和受影响测试。
2. 重建改动前后真实用户或调用方可观察行为。
3. 优先检查正确性、边界、状态迁移、异步、数据流、API/UI 合同和运行失败模式。
4. 判断测试是否保护稳定外部行为；只有真实回归路径缺保护时才把缺测试列为 finding。
5. 检查改动是否把单次实例抬成全局机制、把局部经验固化为公共合同，或让抽象层级高于证据；同时检查重复真相、隐藏 fallback、无收益抽象，以及小 diff 保留的错误 owner、重复生命周期和确定迁移债。
6. 双向比较删除无收益路径与继续压缩造成的欠设计，按全生命周期净复杂度选择修正，不预设抽象或最小改动为答案。
7. 对重复 UI 骨架判断是否应采用共享骨架、类型化配置和薄壳组合。
8. 输出按严重级别排序的 findings、证据、风险和可信修复方向。

净增长本身不是 finding；更小实现只有在不新增双 owner、错误边界、迁移债和恢复缺口时才是有效反例。强行压行、隐藏或转移复杂度同样是 finding。

## 条件主观复核

只有以下情况才读取[主观可维护性复核](references/subjective-review.md)：

- 自动检查告警需要主观判断；
- 抽象、owner、文件或目录边界发生明显变化；
- 改动跨模块、规模较大或维护风险明显；
- 用户明确要求二次复核。

自动检查通过后的普通局部改动不追加完整主观复核。

## 通过与返工

- 只要存在一个未关闭 finding，Review 就不通过，返回 `rework` 和 Design 或 Implementation 目标。
- 修改产物后，旧验证证据失效；必须重新验证并再次 Review。
- 只有 findings 清零后才允许输出 `no findings` 或等价通过结论。
- 外部阻塞导致 finding 无法关闭时，明确阻塞项和风险，结论仍然不通过。

## 输出

顺序固定为：

1. 按严重级别排序的 findings；
2. 开放问题或前提假设；
3. `no findings` 或未通过结论、自动检查范围、主要警告和剩余风险。

本阶段不修改实现、不重新执行功能验证，也不 commit、push、release 或 deploy。