用途：调查 bug、崩溃、断言失败或意外行为时，先写一个能复现问题的测试，而不是长时间阅读源码做推理。核心原则是：一个会失败的 20 行测试，比读两小时源码更有价值。
主要能力与做法：标准流程为读错误信息，定位最小触发条件（哪个操作、哪个对象、什么状态），写测试设置该状态并执行操作，运行测试，让结果引导下一步。写测试前只需弄清三件事：要测试的对象或 API、放在哪个测试文件、如何构建和运行，用约 20-30 次工具调用完成这种有边界的定位。
辅助手段：可先用 git log --oneline -20 -- path/to/relevant/files 查看近期改动形成假设，找可疑提交后还应检查其前后至少 10 个提交，注意相关不等于因果，可疑提交是待验证假设而非结论。优先改编已有的、能正常运行的测试，尤其当 bug 由开关或配置触发时，克隆现有测试改一个变量往往最快。
验证与范围：测试通过不等于功能被执行，需在输出中确认目标代码路径确实运行（日志、子请求、错误信息、指标等）；若移除相关配置测试仍通过，说明测试无效。不必复现完整生产调用栈，只需复现机制，用公共 API 搭出被怀疑的状态并触发操作即可。
适用场景：workerd 及 KJ、Cap'n Proto 代码库的缺陷排查。该仓库有 KJ_TEST("description") 与 .wd-test 测试基础设施，构建运行可用 bazel test //path:target --test_arg='-f...' --test_output=all，多数问题可用自包含 KJ_TEST 复现。
限制与风险信号：反复读同一文件两次以上、在写测试前构建多层调用模型、多次说“先理解 X 再写测试”，都属过度分析。编译较慢时也不应推迟写测试，可在构建等待期间做服务于下一轮的定向阅读。其他具体限制暂未提供。