软件工程
用竞争假说诊断软件缺陷
可复现的缺陷，附有依据的根因说明，以及最小已验证修复，或范围清楚的下一步调查。
流程
按这个顺序做。
- 在不改动系统的前提下，捕获症状、预期行为、环境、时机和已知最小复现。
- 收集日志、追踪、失败输入、近期变更和对照案例；把观察事实与解释分开。
- 写一份简短排序的合理原因清单，并为每个识别一项鉴别测试。
- 运行能纳入或排除假设的最低侵入实验，一次只改一个变量。
- 缩小复现并定位故障组件，然后加入修复前会失败的回归测试。
- 应用最小纠正变更，运行回归和周边套件，并记录根因、证据和剩余风险。
先准备
猫会向你要的输入。
- 缺陷报告或症状
- 相关代码与运行时证据访问
- 预期行为
- 安全复现环境
路由器 + 一份 playbook
先路由。只选一份。
Cat Paw 每次任务只加载一份 playbook，不合并多份。先走这个路由器；其余路径是此 workflow 可检查的候选。
- 路由器：
engineering-pack skills/engineering/mattpocock/diagnosing-bugs/SKILL.md
界限
界限跟着提示一起走。
- 仍在收集基线证据时不要改生产，除非缓解获明确授权。
- 把相关当作假设，而不是根因。
- 从日志和报告中脱敏密钥和个人数据。
完成代表
一个可核对的终点。
缺陷可复现，回归测试能演示它，识别原因有实验支持，修复通过相关套件，或书面阻塞点明下一项鉴别测试。
来源
这个流程从哪来。
来源确立 workflow 的模式。如有 Reddit 或社区帖子，视为实务轶事，不是普遍事实。
