# 开发审计规范

创建人员：management.admin
文件职责：提供 project-info 开发审计的本地入口、目标映射和角色分离要求。
管理规范/模板：../../common/dev-doc/开发审计规范.md
引用文件：目录导读.md；编码规范.md；开发事项总纲.md；开发事项计划.md；开发执行日志.md；开发审计报告.md；开发问题记录.md
记录方式：审计结论 append-only；候选记录不得冒充独立审核结论。

## 1. 上位规范

所有开发审核必须遵守 `../../common/dev-doc/开发审计规范.md`。本文件只补充本项目入口，不降低独立审核、证据完整性和可复验要求。

## 2. 审计入口

- 根级编码体系与跨目标事项：`dev-doc/开发审计报告.md`。
- ana 目标开发：`ana-doc/案例审计报告.md`，审核角色 `dev.reviewer.ana.cai`。
- exp 目标开发：`exp-doc/实验审计报告.md`，审核角色 `dev.reviewer.exp.cai`。

## 3. 角色分离

开发负责人不得自审。环境、计划、实现、测试和交付的审核范围必须在审计记录中明确；`PENDING_INDEPENDENT_EXECUTION_REVIEW` 不等于通过。

## 4. 复审收敛与防止层层加码

本节依据 `../../管理系统说明.md` 的审核员体系和 `../../common/dev-doc/开发审计规范.md` 的真问题优先原则补充本项目口径。

1. 同一开发事项连续出现 3 轮 `HOLD` 时，3 轮是强制收敛与升级节点，不是自动通过、证据豁免或通用审核次数硬上限。
2. 到达该节点后，审核员必须停止“每轮只返回一个局部问题”的串行返修方式，在 `开发问题记录.md` 建立跨轮索引，并在自己的 `项目问题反馈.md` 登记流程问题；随后只能选择：一次性给出当前可发现的完整阻断集、建议整体重构或缩小范围、或提交管理/人工裁决。
3. 第一轮审核以及整体重构后的第一轮审核必须以事项完整目标为单位检查。后续新发现阻断项时，审计记录必须说明其为何无法在前轮合理发现；不能只因设计新增了内部细节，就把与用户目标、正式消费者或关键风险无关的边角料升级为新阻断。
4. `required_fixes` 必须是最小、可执行、可验收的修复集合，并区分：必须阻断、实现/测试阶段验证、非阻断建议。已经通过的合同默认冻结；除非出现真实回退或新上游要求，不得反复重审。
5. 重型方案审核只冻结实现所必需的模块边界、公开接口、关键数据合同、失败与重跑安全、性能验收和正式证据边界。内部类名、私有字段顺序、非消费者诊断字段、普通源码/测试的逐字节预冻结，通常不得作为方案阻断。
6. 第 3 轮后仍未收敛但没有新增关键事实时，禁止继续追加只修一个微观字段或单个真值格的设计版本。必须先完成前述升级或范围重置，并在审计入口记录例外依据。