---
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) 结论输出模板

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

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

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

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

## 常见阻塞与判定示例

- **阻塞消除**：先前缺失模块成功导入；测试入口与全量测试通过。
- **阻塞未消除**：核心导出测试失败（如顶层 `__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 结构化回执模板