agent-core-java 设计评审 Rubric：用六组可执行检查项守住 DevFlow 组件设计的契约完整与复杂度底线

在 agent-core-java 仓库的 .claude/skills/devflow-review/ 技能体系中，设计评审 Rubric 是 R2 门禁（设计阶段完成后、进入实现前）的逐项检查清单。它回答一个问题：拿着这份设计，实现者还需要"发明"什么吗？复杂度配得上规格吗？本文以仓库内实际存在的 design-review-rubric.md 为骨架，结合 devflow-design、两份设计模板与评审流程源码，完整展开这份 Rubric 的每一组检查项、判定规则与 verdict 路由，帮助你把它直接用于自己的组件设计评审。

为什么需要一份设计评审 Rubric

DevFlow 把「产出高质量代码」拆成三层质量：第一层 SDD（devflow-specify）保证做对的事，第二层 TDD（devflow-tdd）保证功能被证明正确，第三层 Clean Code（devflow-clean-code）保证代码本身写得好（见 using-devflow/SKILL.md）。devflow-design 是设计阶段，负责用结构、接口契约、错误模型和测试设计为第三层奠基。而设计产物是否真的满足这些要求，不能由作者自说自话——必须由独立评审按 Rubric 逐项核对。

设计评审 Rubric 的三个关键定位：

• 评审对象：组件根下 features/<id>/design.md，以及（影响组件边界时）component-design-draft.md（或团队覆盖路径）。
• 上游输入：已确认的 spec.md、组件根下既有 docs/component-design.md（或团队覆盖路径）。作者侧标准见 devflow-design 与两份模板的「高质量设计增补」章节。
• 核心怀疑：拿着这份设计，实现者还需要"发明"什么吗？复杂度配得上规格吗？

第一句怀疑指向契约完整：如果实现者拿到设计后还要自己决定接口语义、错误码含义、失败后状态，设计就是没做完。第二句怀疑指向结构与复杂度：设计里的每个抽象、每个配置项、每个间接层，都必须有真实的用例或变化轴支撑，否则就是给长期维护预埋成本。

评审对象与输入：评审前先锁定四样东西

Rubric 的检查不是对着空气打分。评审者进入检查前，需要确认以下输入齐备：

输入	位置（默认路径）	用途
工作项设计	组件根下 features/<id>/design.md	评审主体
组件设计修订（如适用）	组件根下 features/<id>/component-design-draft.md	触及组件边界时的评审对象
规格	组件根下 features/<id>/spec.md	设计必须覆盖的上游契约
组件设计基线	组件根下 docs/component-design.md（或团队覆盖路径）	工作项设计必须引用的基线，不得重新定义组件级架构

作者侧标准在 devflow-design/SKILL.md 与两份模板的「高质量设计增补」章节中：工作项级模板的 第 7 章「高质量设计增补」（接口契约细化六项、错误模型、数据所有权、SOLID 自检、简单性检验），组件级模板的 第 9 章「高质量设计增补」（职责与边界、错误与降级、资源与数据所有权、抽象与演进成本）。Rubric 的作用就是反向核验这些章节是否真的写到位。

检查项一：契约完整（不过 = critical）

这一组检查项只有一个目标：让实现者拿着设计不用再猜。任何一条不过，评审 verdict 至少是 需修改。

• [ ] 每个对外接口六项齐全：输入前置/输出后置/错误语义/副作用/并发时序/兼容性
• [ ] 错误模型三件事已定：错误分类与策略、传播策略（哪层翻译哪层处理）、失败路径状态保证
• [ ] 没有「错误处理：返回错误码」式的一笔带过；没有「出错后状态未定义」
• [ ] 跨边界数据的分配/释放/存活期已明确

六项接口契约：可冷读的契约，而不是签名列表

Rubric 要求的"六项齐全"，在 devflow-design 里被定义为描述可观察行为的六项契约：输入与前置条件、输出与后置条件、错误语义、副作用、并发与时序、兼容性（见 devflow-design/SKILL.md）。"可冷读"是硬标准：拿着契约不看实现就能写出测试。

Rubric 明确反对"这不是契约，只是签名"的写法。仓库里的正反例一目了然：

/* ❌ 这不是契约，只是签名 */
int mode_set(int mode);

/* ✅ 可冷读的契约（最终落在头文件注释 + design.md）*/
/**
 * 请求切换运行模式。线程安全；不可在中断上下文调用。
 *
 * @param mode  目标模式，必须是 MODE_NORMAL 或 MODE_SAFE。
 * @return OK              已接受请求；下一控制周期内完成切换并发出
 *                         ModeChanged 事件（见 design.md §事件语义）。
 *         ERR_INVALID_ARG mode 非法；内部状态不变，不发事件。
 *         ERR_BUSY        上一次切换尚未完成；调用方应退避重试。
 * 副作用：成功路径更新 mode 状态并向事件队列投递一条 ModeChanged。
 */
int mode_set(mode_t mode);

（示例出自 devflow-design/SKILL.md）

工作项设计模板的 7.1 接口契约细化 给出了逐接口填写的表格骨架：输入含义与单位、合法范围、NULL 语义、调用上下文限制；返回值与成功后状态变化；每个错误码的触发条件及出错后系统状态；副作用；线程安全性、可重入性、阻塞与超时；modify/remove 时的迁移策略与废弃计划。

错误模型三件事：错误处理是设计决策，不是临场发挥

Rubric 要求设计阶段就把错误模型定清楚，devflow-design 给出了三件事的具体判据（见 devflow-design/SKILL.md）：

1. 错误分类与策略：调用方编程错误（传 NULL、非法枚举）→ 校验并返回明确错误码；可预期的运行时失败（资源暂不可用、超时）→ 返回错误码并给调用方恢复/退避路径；环境/硬件故障 → 进入设计好的降级模式并上报诊断事件；不可恢复的内部矛盾 → 按项目故障策略受控终止。
2. 传播策略：错误在哪一层被翻译、哪一层被处理。默认取向是在模块边界翻译一次（"flash 写失败"→"配置保存失败"），中间层只透传；底层错误码原样穿透到顶层是泄漏，每层都包一遍是噪音。
3. 失败路径状态保证：每个可失败操作明确失败后已发生的副作用是回滚、保留还是半完成，并写进接口契约。

Rubric 把两个写法直接列为不过项：「错误处理：返回错误码」式的一笔带过（哪些错误码？出错后状态？谁恢复？）和「出错后状态未定义」（按 critical 处理）。

跨边界数据的分配/释放/存活期

每块跨边界的数据（缓冲区、句柄、回调上下文）在设计里必须回答三个问题：谁分配、谁释放、指针在调用返回后是否仍可用。devflow-design 给出的默认取向是"谁分配谁释放"；跨边界传递用复制或显式转移所有权。回调注册类接口必须写明注销后是否还可能被回调一次（in-flight callback）以及 ctx 指针的生命周期由谁保证；长生命周期模块持有外部传入指针是红色信号（见 devflow-design/SKILL.md）。

检查项二：结构与复杂度

• [ ] 每个模块职责一句话说得清；按变化理由组织，无明显的霰弹式修改预埋
• [ ] 依赖方向单向；无新增循环依赖；公共头文件无实现泄漏
• [ ] 每个抽象/间接层/配置项指得出真实用例或真实变化轴；无单实现接口、无"以后可能需要"
• [ ] SOLID 自检落到具体设计结论：SRP/OCP/DIP 问题有变化理由与依赖证据；LSP/ISP 问题有契约或调用方证据
• [ ] 无调用方知识泄漏：调用方不依赖无关接口、内部字段、私有宏或隐式调用顺序
• [ ] 反向检验：有没有更简单的结构也能满足规格？有 → critical finding

一句话职责与按变化理由划分

devflow-design 的判据是：每个模块的职责必须能用一句不含「和」「以及」的话说清，句子里有两个动词短语就是两个职责（见 devflow-design/SKILL.md）：

❌ ConfigManager：负责加载配置、校验配置、监听配置变化，以及把变化通知给订阅者
✅ ConfigStore：持有当前生效配置，提供原子读取
✅ ConfigLoader：从存储读取并校验配置块
✅ ConfigNotifier：把配置变化分发给订阅者

组织原则是按变化理由划分，而不是按技术层次：协议格式变化时要改的代码放一起，业务规则变化时要改的代码放一起。"所有回调放 callbacks、所有结构体放 types.h"这类按形态分类，一次行为变更要横跨所有文件，就是 Rubric 说的"霰弹式修改预埋"。

依赖方向与实现泄漏

Rubric 的三条：依赖方向单向（底层不得 include 上层；互相依赖 → 提取第三方共同依赖或用回调/事件反转）、无新增循环依赖、公共头文件无实现泄漏（头文件只放契约，内部细节进 .c / detail 命名空间）。devflow-design 的耦合可操作判断表（见 devflow-design/SKILL.md）还提供了知识泄漏、数据泥团、特性依恋、扇出过大等坏信号与对应动作。

抽象必须有真实用例：Rule of Three 与单实现接口是负债

Rubric 问的是"每个抽象/间接层/配置项指得出真实用例或真实变化轴"。仓库里的抽象纪律非常明确（见 devflow-design/SKILL.md）：

• Rule of three：第三个真实用例出现前，重复通常比错误的抽象便宜；错误抽象一旦被依赖，纠正成本远高于消除重复。
• 单实现接口是负债：只有一个实现的 interface/抽象基类，在没有第二个真实实现（不含测试 mock 的伪需求）或明确的稳定契约要求前，就是纯开销。
• 可配置性不是免费的：每个"以后可能要改"的配置项/策略钩子/插件点，现在就要文档、测试和维护。

反例（当前只需要写日志到文件，却设计了插件框架）与正例（满足当前规格的最少结构）在技能文档中完整给出。"以后可能需要"作为某个抽象层的唯一理由，是评审的风险信号。

SOLID 自检落到具体设计结论

Rubric 要求 SOLID 不是口号，每条结论必须回到职责、契约、依赖方向或真实变化轴。devflow-design 的 SOLID 翻译表（见 devflow-design/SKILL.md）把五条原则映射为 DevFlow 判据与常见坏信号：SRP 看职责句是否含"和/以及"；OCP 看真实变化轴是否有稳定扩展点；LSP 看替换实现是否削弱接口契约；ISP 看调用方是否被迫依赖大而全接口；DIP 看高层策略是否避开硬件/协议/存储细节（并拒绝无第二用例的单实现接口）。模板的 7.4 SOLID 结构自检 要求逐项填写"检查结论 + 需要的动作/N/A 理由"。

反向检验：更简单的结构也能满足规格吗

这是结构与复杂度组的收尾检查，也是唯一直接产出 critical finding 的判据：有没有更简单的结构也能满足规格？有 → critical finding。它与模板 7.5「简单性检验：为什么不是更简单的方案」互为表里——作者侧强制回答"更简单的候选方案为什么不满足当前规格（而不是'以后可能不够用'）"，评审侧则反过来验证这个回答是否成立。设计的第一律就是简单性：满足当前规格的最少结构就是好结构（见 devflow-design/SKILL.md）。

检查项三：与上游一致

• [ ] 设计覆盖 spec 全部范围；没有悄悄做了 spec 之外的事
• [ ] 设计级别判定正确：触及对外接口/依赖/状态机时，组件设计草稿已先行修订并经模块架构师确认；工作项设计只引用组件基线，未重新定义组件级架构
• [ ] modify/remove 需求的兼容策略在设计中落地
• [ ] traceability.md 的组件设计章节/设计章节/测试设计用例列已填且与文档一致（断链 = critical）
• [ ] spec Acceptance 与 design Case ID 双向可追溯：每条 Acceptance 至少映射到一个 Case ID；每个 Case ID 都能回指 spec 需求/Acceptance；无孤儿用例或漏测验收

覆盖全部范围，不做 spec 之外的事

设计的职责边界是"覆盖 spec 全部范围"且"不悄悄做 spec 之外的事"。前者对应"漏测"（spec 有要求、设计没承接），后者对应"走私"（设计里塞了规格没有的功能）。规格阶段的纪律在 devflow-specify/SKILL.md 中：Statement 用 EARS 句式、Acceptance 用 Given/When/Then、Change Type 按对既有可观察行为的影响分类（new/modify/remove）。设计的评审就要核验：每个 FR/NFR/IFR 条目是否都有对应的设计承接，设计里是否出现规格之外的接口或行为。

设计级别判定：组件级 vs 工作项级

DevFlow 把设计分两级（见 devflow-design/SKILL.md）：

级别	工件	何时需要
组件级设计	features/<id>/component-design-draft.md → ship 时 promote 到 docs/component-design.md	工作项影响组件边界：对外接口 / 组件依赖 / 状态机 / 组件职责变化，或组件设计基线缺失、过期
工作项级设计	features/<id>/design.md	每个工作项（微小修改可按 using-devflow 裁剪）

硬性顺序：影响组件边界时，必须先修订组件设计草稿并经评审与模块架构师确认，再写工作项设计；工作项设计只能引用组件基线，不得重新定义组件级架构。Rubric 检查的就是这个顺序是否被遵守——"在工作项设计里'顺便'定义了组件级架构"是设计评审的风险信号。

modify/remove 的兼容策略

规格阶段的 Change Type 判定（见 devflow-specify/SKILL.md）要求：modify 必须写旧行为基线，Acceptance 覆盖保留的行为与批准的破坏；remove 必须写被移除行为、已知消费者、删除后的可观察语义。Rubric 要求这些兼容策略在设计中落地——具体到接口契约的兼容性一项（旧调用方迁移策略、错误码集变化、废弃计划），以及测试设计中 modify 的回归用例、remove 的删除后语义用例。

traceability：spec-design-code 一致性的显式约束

traceability.md 是贯穿全流程的追溯矩阵（模板见 traceability-template.md）：specify 初始化时填需求条目、Change Type、上游锚点；design 阶段追加组件设计章节、设计章节、测试设计用例列；tdd 阶段追加任务、代码文件/函数、测试代码、验证证据。任何一列对不上，说明工件之间已经漂移。Rubric 将"traceability.md 的组件设计章节/设计章节/测试设计用例列已填且与文档一致"作为硬性检查，断链 = critical。devflow-review 抽查它，devflow-ship 关闭前终验它。

Acceptance 与 Case ID 双向可追溯

规格的每条 Acceptance 必须至少映射到一个 Case ID；每个 Case ID 都能回指 spec 需求/Acceptance；不允许出现孤儿用例（有 Case ID 但回指不到 spec）或漏测验收（有 Acceptance 但没有任何 Case ID 覆盖）。这是"无孤儿用例或漏测验收"的双向可追溯要求。

检查项四：方案取舍

• [ ] 有真实可选方案时有对比（改动范围/复杂度/兼容/回滚/维护）且有推荐与理由
• [ ] 单方案写了「为什么不是更简单的 X」
• [ ] 无伪选项（同一方案三种措辞、陪跑方案）

devflow-design 对方案取舍的纪律（见 devflow-design/SKILL.md）：

• 只在真实存在多个合理方案时写选项对比，每个方案至少回答：改动范围、复杂度、对既有调用方的兼容性、失败时回滚成本、长期维护影响；然后给出推荐和理由——列完选项不推荐等于把设计工作推给评审者。
• 只有一个合理方案时，写一段「为什么不是 X」：X 是评审者最可能问的替代方案（通常是"更简单的做法"或"更通用的做法"）。这不是形式——它强迫作者检验是否真的考虑过更简单的路径。
• 伪选项是常见造假：三个方案其实是同一方案的不同措辞，或者两个陪跑方案明显荒谬。

两份设计模板都把方案选择放在实现设计之前（组件模板的 5.0 Design Options、工作项模板的 4.0 Design Options），并要求记录 Recommended Option、Rationale、确认负责人与确认状态；只有一个显然方案时写 Single obvious option 并说明为什么不展开多方案。

检查项五：测试设计（不过 = critical）

• [ ] spec 每条验收标准映射到用例；FR 有正向+异常；NFR 的 Response Measure 有可量化用例
• [ ] 第 6.1 Case ID 汇总表是 canonical 测试设计入口；第 6.2+ 子表只展开既有 Case ID，不产生无法追溯的新用例
• [ ] modify 有回归用例；remove 有删除后语义用例
• [ ] 每个用例有层级与 mock 边界；mock 只在真实边界（硬件/外部组件/时钟），不 mock 内部纯逻辑
• [ ] 没有写不出用例的需求残留（有 → 规格不可测试，打回 specify）

从验收标准到用例的映射

设计文档必须含测试设计章节——这是规格通向 TDD 的桥。每条 FR/IFR 至少一个正向 + 一个异常/边界用例；每条 NFR 的 QAS Response Measure 对应一个可量化用例（如 p95 ≤ 5ms），不是"跑了没崩"。规格阶段的 QAS 五要素（Stimulus Source / Stimulus / Environment / Response / Response Measure）要求 Response Measure 必须有阈值或可判定准则（见 devflow-specify/SKILL.md）。

Canonical Case ID 表：只有一张

模板第 6.1「测试点汇总」是 TDD 的唯一用例索引，Case ID 必须使用稳定的 TC-xxx；第 6.2-6.6 子表只能展开第 6.1 中已存在的 Case ID，不得新增无法回指第 6.1 的用例（见 devflow-ar-design-template.md）。这条 canonical 规则随后被 devflow-tdd 严格执行：plan 覆盖的 Case ID 集合必须等于 design 测试设计表的 Case ID 全集，缺失或新增都说明工件漂移（见 devflow-tdd/SKILL.md）。

测试设计的表格结构（来自 devflow-design/SKILL.md）示例：

Case ID	覆盖需求	场景（Given/When/Then 摘要）	层级	预期结果
TC-001	FR-001	SAFE 下 SetMode(NORMAL) → 切换+事件	unit	返回 OK；周期内 ModeChanged=NORMAL
TC-002	FR-001	SetMode(非法值) → 拒绝	unit	ERR_INVALID_ARG；状态与事件无变化
TC-003	NFR-001	1000 次切换延迟测量	integration	p95 ≤ 5ms（QAS 阈值）

层级与 mock 边界

每个用例写明层级（unit / integration / simulation）与 mock 边界：只 mock 硬件、外部组件、慢速依赖、时钟；不 mock 模块内部纯逻辑；不为测试给生产类加 test-only 方法。这条纪律在 devflow-tdd 的测试质量内建与 devflow-clean-code 的可测试维度中被反复强调。

写不出用例的需求 = 规格不可测试

"没有写不出用例的需求残留"是测试设计组的收尾红线：写不出用例 → 规格不可测试 → 打回 devflow-specify。devflow-design 的原文是："写不出用例的需求 = 规格不可测试 → 回 devflow-specify"（见 devflow-design/SKILL.md）。这条检查把评审结论路由到上游，而不是让设计者在规格漏洞上硬扛。

Verdict 指引：需修改还是重新设计

Rubric 的 Verdict 指引只有两条规则，但路由清晰：

• 契约/测试设计 critical → 需修改；结构方向性错误（边界划错、复杂度失控）→ 重新设计
• 发现规格本身的漏洞 → finding 标注上游问题，verdict 重新设计 并指向 devflow-specify

这与 devflow-review 的 verdict 三选一一致（见 devflow-review/SKILL.md）：通过（无 critical/important，或仅剩已被人接受的 minor）、需修改（findings 可定向修复，修复后复审）、重新设计（问题出在上游，打回对应阶段）。

建议返工阶段按问题本质填写（见 devflow-review/SKILL.md）：

问题本质	返工阶段
规格不可测试、缺业务事实、Change Type / Existing Behavior 错	devflow-specify
设计契约、错误模型、测试设计、组件边界错误	devflow-design
R3 中的测试断言、RED 证据、实现 bug、代码整洁问题	devflow-tdd

finding 的严重级与分类

每条 finding 要写：位置 + 问题 + 为什么是问题 + 严重级 + 分类 + 建议返工阶段。严重级三档：critical（不修不能继续：会导致做错事、留 bug 或不可审）、important（完成前应修）、minor（建议改进）。分类三档决定谁来解决（见 devflow-review/SKILL.md）：

• LLM-FIXABLE：信息已足够，作者可按 finding 定向修复，不问人；
• USER-INPUT：缺业务事实、优先级、验收阈值、外部来源确认，只问 finding 指向的最小问题；
• TEAM-EXPERT：需要模块架构师、资深工程师或团队规则裁决，把问题封装成 1-2 个具体决策点上抛。

evals 中专门有一项验证这种分类纪律：一条模糊句子 → LLM-FIXABLE 不问人；一个缺失的业务阈值 → USER-INPUT 只问那一个问题；一个组件边界决策 → TEAM-EXPERT 上抛为具体决策点（见 evals.json 的 finding-classification-controls-human-questions）。

在 R2 门禁中使用这份 Rubric：从独立评审到 Resolution 闭环

Rubric 不是孤立的打分表，它嵌在评审工作流里（见 devflow-review/SKILL.md）。三条不变量：

1. 作者不自审：写产物的会话/agent 不能给自己出 verdict；评审由独立 subagent 或新会话执行，只能依赖产物本身——这正是"可冷读"的检验方式。
2. 评审者不动手修：评审产出 findings 和 verdict，修改由作者执行，裁判不下场。
3. 没有记录的评审等于没有评审：每轮评审必须在 reviews/ 落盘一份记录；findings 的修复过程必须回写同一份记录（Resolution 闭环）。口头说"评审过了"而 reviews/ 里没有对应文件，按未评审处理。

评审记录写入组件根/工件根下 features/<id>/reviews/<目标>-review-<日期>.md，复审追加轮次后缀（-r2、-r3）。每份记录包含：评审对象（含版本/commit）、findings 表（含 Resolution 列、分类、建议返工阶段）、verdict、抽查记录。

findings 闭环：作者侧职责

verdict 为 需修改/重新设计 时，作者按 findings 返工并逐条回写 Resolution 列（见 devflow-review/SKILL.md）：

• 修复了：怎么改的 + commit 锚点；
• 人接受不修：理由 + 谁接受的；
• 升级为债务：登记去向（plan.md 债务节 / 新工作项）。

返工顺序是：先收集 USER-INPUT 与 TEAM-EXPERT 的答案（同一决策面合并成最少问题，不把整份评审记录丢给人）→ 再修 LLM-FIXABLE findings（只改 finding 指向的行、章节、测试或代码）→ 回填 Resolution 后发起复审。Resolution 列有空着的 critical/important，门禁不算通过——devflow-ship 的 DoD 会核验这一点（见 definition-of-done.md）。复审必须核对上一轮 Resolution 与实际 diff 一致，问题不能在新记录里"凭空消失"。

同一 R 节点最多自动返工复审 3 轮；第 3 轮仍有未闭环 critical/important，或持续出现新的同级问题，停止自动循环，把剩余问题、已修证据和需要人裁决的具体问题呈给人。

attended / unattended 运行模式

按 using-devflow/SKILL.md 的约定：attended（默认）在 R 节点通过后停下，把评审记录与 verdict 呈给人；unattended 不停顿，但独立评审、落盘记录、critical 阻塞返工与复审照常执行，人工确认列记 N/A(unattended)，供人事后统一审计。两种模式都不移除任何质量动作。plan.md 门禁表维护评审状态：pending 表示等待评审，passed 表示评审通过，rework 表示必须先回作者阶段修复（门禁表模板见 plan-template.md）。

评审者纪律与风险信号速查

Rubric 之外，devflow-review 对评审者本身有纪律要求（见 devflow-review/SKILL.md）：

• 按 rubric 逐项过，不凭整体印象打分；rubric 之外发现的问题照样列出；
• 每条 critical/important finding 给出具体位置和可执行的修复方向，不写"质量有待提高"；
• 抽查重于通读：代码评审优先读错误路径与资源路径——那是问题密度最高的地方；
• 不确定的判断标注"待人裁决"，不假装确定；
• 发现产物间漂移（代码与 design 不符、测试与 spec 不符）→ 一律 critical：要么改产物，要么改工件，不允许默默不一致。

设计评审相关的风险信号：工作项触及对外接口/依赖/状态机却没有组件设计修订；设计文档里只有结构图和文件清单，没有接口契约和错误语义（实现者仍然要猜）；「错误处理：返回错误码」一笔带过；"以后可能需要"作为抽象层的唯一理由；单实现接口、单子类继承；方案对比是同一方案的三种措辞；测试设计只有正向路径，或某条验收标准没有对应用例；改了对外接口语义却没有兼容性章节（见 devflow-design/SKILL.md）。

把这份 Rubric 落到你自己的设计评审中

从仓库的实际用法看，这份 Rubric 是一份可以直接执行的检查清单，而不是抽象原则。建议的落地方式：

1. 评审前锁定输入：design.md（及 component-design-draft.md）、spec.md、组件设计基线、作者侧的高质量设计增补章节，四样齐备再开评。
2. 按五组检查项逐项过：契约完整 → 结构与复杂度 → 与上游一致 → 方案取舍 → 测试设计，每组都标注了哪些不过即 critical。
3. 先抓 critical 面：六项契约是否齐全、错误模型三件事是否定清、Case ID 双向追溯是否成立、写不出用例的需求是否残留——这四项直接决定 verdict 是 需修改 还是打回。
4. 结构问题用反向检验收口：对每个抽象/间接层/配置项，先问"有没有更简单的结构也能满足规格"。
5. 产出可执行的 finding：位置 + 问题 + 为什么是问题 + 严重级 + 分类 + 建议返工阶段，并落盘到 reviews/，跟踪 Resolution 闭环到复审通过。

这份 Rubric 与同目录下的 spec-review-rubric.md、test-review-rubric.md、code-review-rubric.md 共同构成 DevFlow 四道评审门禁的检查体系：规格评审的核心怀疑是"两个不同的人读这份规格，会做出同一个东西吗"，设计评审的核心怀疑是"实现者还需要发明什么吗、复杂度配得上规格吗"，测试评审的核心怀疑是"这些测试会放过哪种错误实现"，代码评审的核心怀疑是"这段代码哪里在对读者撒谎"。设计评审站在规格与实现之间——它既要向上核验规格覆盖，又要向下保证实现不需要再做发明，这正是它在 DevFlow 流程中不可替代的位置。