用途：在 Ruby/Rails 代码库调查 bug、错误或回归时使用。核心要求是先建立可复现路径，再动手修复，硬性规定不得在没有复现路径的情况下猜测修复方案。
主要流程（须依次完成并输出七项内容）：1）捕获报告，重述实际行为、预期行为与复现步骤；2）界定范围，判断问题位于请求处理、领域逻辑、后台任务、集成边界还是外部依赖；3）收集证据，如日志、错误信息、边界输入、近期改动或缺失的防护；4）选择首个失败测试，并给出修复前运行的确切命令；5）定义最小安全修复路径，指出可能的文件与最窄的行为改动；6）产出骨架测试，在实现修复前先运行；7）交接，继续走 test-planning-process、tdd-process 与实现技能。
测试边界选择：HTTP/API 症状用集成或请求测试、控制器测试；数据/逻辑症状用单元或服务测试；时序/异步症状用后台 worker 或单元测试；集成或依赖回归用组件/集成测试。默认优先在用户或运维可见的边界复现。
示例（以 POST /orders 下单失败为例）：首个失败测试为 spec/requests/orders_spec.rb（或 test/integration/orders_test.rb），命令为 bundle exec rspec spec/requests/orders_spec.rb（或 bundle exec ruby test/integration/orders_test.rb）；预期 RED 是尚未返回 422 与 “Out of stock”，或服务直接抛错；最小修复路径为 Orders::CreateOrder 处理库存守卫，返回 { success: false, error: "Out of stock" } 且不创建订单。Minitest 等价写法见 assets/examples.md。除 bug 报告指向外，不应把该示例替换为定价、纯模型或纯类场景。
限制与注意事项：请求级可见的 bug 不要只写单元测试；不要把复现、重构与新功能捆在一起；不稳定的证据不能视为可以打补丁的绿灯，需先稳定复现；若解释依赖“大概”“也许”，说明复现步骤尚未完成。除非明确要求，输出语言须为英文。可按需参考 BOUNDARY_GUIDE.md 与 assets/examples.md。