08
Bug Hunt · workflow

repo-bug-hunt

08-repo-bug-hunt.md
🐛
P1 source: claude-sessions created: 2026-06-13
◉

WHAT IS THIS

定位

全库 bug 巡猎 workflow。它不是普通 code review，而是按模块和 lens 主动构造失败场景，并要求每个 finding 有可复现证据。

⚡

TRIGGERS

触发场景
▸需要系统性找隐藏 bug。
▸大功能合并前想做高强度 QA。
▸代码已有测试，但用户路径仍不稳。
▸想把 improve skill 的发现变成可复现 findings。
↹

INPUT & OUTPUT

输入 / 产出
↘ INPUT
  • 仓库结构。
  • 最近 diff 或目标模块。
  • 测试命令。
  • 关键用户路径。
  • 已知历史 bug。
↗ OUTPUT
  • 去重后的 bug findings。
  • 每个 finding 的 PoC 或复现步骤。
  • 严重度和修复优先级。
  • 可选 patch 计划。
🪜

STEPS

编排步骤
  1. 1
    模块分片
    按 domain、route、package、service 分片，不按文件随机分。
  2. 2
    Lens 分配
    每个模块至少从 correctness、state、error handling、security、performance、testability 里选两个 lens。
  3. 3
    独立找 bug
    Agent 不互相影响，避免同一种假设污染全部结果。
  4. 4
    证据化
    每个 finding 必须提供复现命令、测试用例、输入样例或明确代码路径。
  5. 5
    Verifier 复核
    第二组 agent 或主线程验证 finding 是否真实。无法复现的降级为 risk。
  6. 6
    去重和排序
    合并同根因问题，按用户影响和修复成本排序。
⚙

AGENT ROLES

Agent 分工
⚙
Module Hunters
按模块找 bug。
⚙
Lens Reviewers
按 correctness/security/performance 等 lens 找 bug。
⚙
Verifiers
只复现，不新增 finding。
⚙
Triage Agent
去重、排序、归类。
·

FINDING 标准

finding 标准
  • 有具体文件和代码路径。
  • 有用户可感知影响。
  • 有触发条件。
  • 有复现方式或可写成测试。
  • 有明确修复方向。
    • 不合格 finding：
  • 只是风格建议。
  • 没有触发条件。
  • 只说“可能有风险”。
  • 依赖不存在的输入。
✓

ACCEPTANCE GATE

验收 gate
⊘

FAILURE HANDLING

失败处理
⊘
如果无法运行项目，转为 static audit，并明确可信度下降。
⊘
如果 finding 只能靠猜测，标为 risk，不标 bug。
⤳
如果发现高危安全问题，转入 →#09。
⌘

TEMPLATE

报告模板
TEMPLATE
## Findings

| Severity | Module | Bug | Repro | Fix direction |
| --- | --- | --- | --- | --- |

## Risks

| Module | Risk | Missing evidence |
| --- | --- | --- |