用途：bug-hunting 用于两类场景。反应式模式处理“修复这个缺陷”“测试失败”“生产报错”等已知问题；主动式模式处理“审查这段代码”“找出缺陷”“审计”等预防性排查。两种模式都遵循同一套五阶段流程，只是入口不同。
核心原则：主张不等于证据，证据不等于根因，根因不等于修复。三条铁律不可协商：无确认根因不得提出修复；无证据不得下结论；修源头而非症状。
五个阶段：0 侦察，先明确预期行为、缺陷类型（逻辑错误、竞态、数据损坏、集成失败、性能、安全）、涉及组件与常见缺陷，预期不清则先澄清；1 证据收集，读完所有报错与堆栈、稳定复现、检查近期改动、在组件边界加诊断，并把证据分为已确认、疑似、理论三类，此阶段不做修复；2 影响面测绘，记录主缺陷并至少找出 2 个同区域可疑点，按严重度分级（严重、高、中、低）；3 根因追溯，沿调用链向上回溯到源头而非崩溃点，形成单一假设并最小化验证，假设未确认则回到阶段 1，连续 3 次以上失败应视为架构问题并暂停讨论；4 解决，先写会失败的测试，再逐个修复根因，采用纵深防御多层校验，验证通过且无回归。
证据用语规则：禁止“几乎肯定”“大概是”“看起来是”“根因就是 X”“无论原因修复都安全”“以后再查”等表述，须改为陈述实际证据或标注疑似/理论。
危险信号：如“先快速修一下以后再查”“相关性太强不可能是巧合”“修复只有一行不会有事”“专家已确认根因”“我不完全理解但应该能行”，以及每修一处又冒出别处新问题，都应停下回到阶段 0。
反应式模式下若上下文记忆文件含 Pocket Education 标题，需先用 npx -y pocketto-pi edu --json --contract 3 确认，再询问用户自行引导修复还是由技能修复，用户明确选择前不得动手；不改变代码的主动审计不受此限。
配套参考文档包括证据收集、影响面测绘、根因追溯、纵深防御；相关技能有 TDD（用于阶段 4 第一步写失败测试）与验证（重跑完整测试套件、确认问题解决且无回归）。
限制：资料未提供具体平台、价格、安装方式或效果数据，暂未提供。