---

name: review-blocker-verification description: | 代码评审与回归复核的阻塞点判定标准与执行流程：如何在最小干预下确认“本次修订是否消除先前阻塞点”。 version: 1.0.0 platforms: [linux, macos, windows] metadata: hermes:

tags: [review, regression, qa, quality, blockers]

Review Blocker Verification

适用场景

本技能用于 Reviewer-2 / 第二意见式验收场景，核心目标是回答：

• 本次修订是否清除先前约定的阻塞点？
• 是否还有剩余阻塞项？
• 阻塞是否已修复到可交付边界。

不应被用于泛化 bug 修复设计，偏重于“验证闭环 + 证据化结论”。

总原则

1. 只给结论，不先验判断：先执行最小证据链，再下结论。
2. 阻塞分级判断：
   • 清除：影响链路的核心失败点已修复并可复现通过。
   • 部分清除：部分路径改善，但仍有高置信失败路径。
   • 未清除：关键阻塞仍存在或出现新阻塞。
3. 证据优先：不接受“看起来没问题”；必须有可复现命令输出。
4. 结构化回执：报告中保留 变更范围 / 验证命令 / 输出 / 结论 / 下步 四区块。

复核工作流

1) 差异核查

• git status --short（确认当前工作树状态）
• git diff --name-only（确认覆盖文件）
• 必要时读关键改动文件（入口文件、导出/接口文件、测试文件）。

2) 阻塞复现与回归验证

按优先级执行：

1. 先执行高风险最小集（通常为失败入口 + API 面）
2. 再执行广义回归集合
3. 如存在环境限制，改用可用解释器/命令替代（如偏好 python3 -m unittest）。

典型顺序示例：

• 模块级测试：test_models、test_sanitizer、test_package_import
• 行为测试：test_app、test_readers
• 端到端测试：unittest discover -s ...

3) 模块路径隔离

若出现模块导入失败：

• 使用清晰的路径注入（如 PYTHONPATH=source）避免把环境 import 误判成实现阻塞。
• 仅在路径与依赖问题被明确隔离后再评估业务阻塞。

4) 强制检查点（Reviewer-2 常见）

• 包级导出一致性（__all__ / 顶层 API）
• 关键公开函数是否可导入且可调用
• 错误返回/容错路径是否如预期（如缺少配置、超时、404/403）

经验规则：大量单测通过但 test_package_import 失败时，仍按“阻塞未清除”处理。

5) 结论输出模板

## 结论
- 清除状态：已清除 / 部分清除 / 未清除

## 证据
- 变更文件：...
- 关键失败/通过项：...
- 命令输出：...

## 未清除阻塞（如有）
- 阻塞点：...
- 影响：...
- 建议修复：...

## 下步
- 如继续：...

常见阻塞与判定示例

• 阻塞消除：先前缺失模块成功导入；测试入口与全量测试通过。
• 阻塞未消除：核心导出测试失败（如顶层 __all__ 缺 API）、阻塞路径仍有 FAILED。
• 环境阻塞：pytest not found、python not found 等，仅作为执行环境说明，优先切换可用命令继续验证。

Pitfalls（避免踩坑）

• 只看子集测试通过即宣告完成。
• 忽略 package import contract（最常见“看似全过但接口断裂”）。
• 把环境误报“工具坏了”，却未切换到可用命令继续验证。
• 结论中混入个人猜测，不给出命令级证据。

相关支持文件

• references/blocker-review-checklist.md: 阻塞复核检查项清单（含最小失败归因树）
• references/command-fallback-notes.md: 常见命令不可用时的切换策略与风险标注
• templates/reviewer-2-template.md: reviewer-2 结构化回执模板