# Defect Verification

> 组织缺陷重现、修复版本定向复测与关联回归，建立 RED、GREEN、REGRESSION 证据并关联来源失败和再验收。用户要复现 Bug、验证修复、复测旧 APK 与新 APK 或判断缺陷是否关闭时使用；实际操作委托当前可用的 app-test/API 能力，不默认修改业务代码。

- Skill: `winhok/defect-verification` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add winhok/defect-verification`
- Raw SKILL.md: https://api.skillmd.com/api/skills/winhok/defect-verification/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- License: MIT
- Author: winhok (https://skillmd.com/u/winhok)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/winhok/defect-verification

---


# 缺陷验证

铁律：缺陷 verified 只证明三阶段复测；来源验收缺口必须经过新的验收计算才能关闭。

读取 [retest.md](references/retest.md) 与 [共享执行契约](../_test-run-shared/references/execution-contract.md)。局部 Bug 可直接开始，无需完整 TestSpec；正式回归使用已评审的范围。

1. 明确 defect ID、原始预期、目标失败特征、关键初始条件、旧版/修复版身份及回归范围。
2. 每阶段建立独立冻结 scope，使用 app-test 或 api-test-automation 执行并登记所有尝试。
3. RED 必须证实目标失败特征；配置、DNS、安装、账号故障是阻塞，不是成功复现。
4. GREEN 在相同关键条件下通过原断言；条件或 oracle 改变须说明并重新确认可比性。
5. REGRESSION 覆盖相关路径、边界、角色和历史风险，按选择依据冻结范围。
6. 用 scripts/verify_defect.py 核验各阶段证据引用，输出 defect-result.json；报告 verified/incomplete/failed，以及未复现或未验证的部分。

来自既有执行/验收失败时，按 retest.md 的 lineage 字段绑定来源 run/check 和 scope 摘要；尚未再验收时保留 not-run。存在再验收记录时传 --current-targets，由工具另算 reacceptance_status 和 closed_check_ids，不能手填结果或把 GREEN 重用为再验收。

交付前检查：来源检查确实失败、目标与 oracle 可比、三个阶段证据完整；分别报告缺陷状态和再验收状态。只整理已有报告时不执行或改写记录；没有外部 Bug 编号时使用本地稳定 ID，不编造外部工单。

缺失旧版可继续修复版检查，保留 missing baseline，最终不得标完整 verified。版本可用包摘要、构建号或可核实部署标识，不强制 Git。根因分析可调用诊断能力，但不是复测通过的替代证据。