用途：当 Rails 项目出现 bug、报错或回归，但复现路径与修复顺序尚不清晰时使用。核心原则是不猜测修复，先复现缺陷、选定合适的失败测试，再规划最小安全修复。
主要能力：捕获报告（重述预期行为、实际行为与复现步骤）；界定范围（请求处理、领域逻辑、任务、引擎集成或外部依赖）；收集证据（日志、错误信息、边界输入、近期变更、缺失的守卫）；选择首个失败测试（在用户或运维可见的边界处）；定义最小修复路径（指出可能文件与最窄行为变更）；交接后续技能。
输出结构：观察到的行为、预期行为、可能边界、要添加的首个失败测试、最小安全修复路径、后续技能。
边界参考：HTTP 症状（状态码、JSON、重定向）用请求测试；数据症状（错误值、校验）用模型或服务测试；时序症状（缺失任务、邮件）用任务测试；引擎路由或生成器回归用 dummy 应用中的引擎测试。
用法示例：先写失败测试再实现修复，例如运行 bundle exec rspec spec/requests/orders/create_spec.rb。
限制与注意：不要在请求层可见的 bug 上写单元测试；不要把复现、重构与新功能捆绑；不稳定的证据不能当作可修复的信号；解释中出现“可能”“也许”说明复现尚未完成。资料未提供具体安装命令与收费信息。