軟體工程
用競爭假說診斷軟體缺陷
可重現的缺陷，附有依據的根因說明，以及最小已驗證修復，或範圍清楚的下一步調查。
流程
照這個順序做。
- 在不更動系統下，擷取症狀、預期行為、環境、時點與已知最小重現。
- 蒐集日誌、追蹤、失敗輸入、近期變更與對照案例；把觀察事實與詮釋分開。
- 寫一組排序後的合理成因，並為每個找出一項區辨測試。
- 執行能納入或排除假設的最低侵入實驗，一次只改一個變數。
- 縮小重現並定位故障元件，再加入修復前會失敗的回歸測試。
- 套用最小矯正變更、執行回歸與周邊套件，並記錄根本原因、證據與剩餘風險。
先準備
貓會向你要的輸入。
- 缺陷報告或症狀
- 相關程式與執行期證據存取
- 預期行為
- 安全重現環境
路由器 + 一份 playbook
先路由。只選一份。
Cat Paw 每次任務只載入一份 playbook，不合併多份。先走這個路由器；其餘路徑是此 workflow 可檢查的候選。
- 路由器：
engineering-pack skills/engineering/mattpocock/diagnosing-bugs/SKILL.md
界線
界線跟著提示一起走。
- 除非緩解獲明確授權，蒐集基準證據時不要更動正式環境。
- 把相關當假設，而非根本原因。
- 從日誌與報告遮罩密鑰與個人資料。
完成代表
一個可核對的終點。
缺陷可重現、回歸測試能證明、已識別成因有實驗支撐，修復通過相關套件，或書面阻礙點名下一個區辨測試。
來源
這個流程從哪來。
來源確立 workflow 的模式。若有 Reddit 或社群貼文，視為實務軼事，不是普遍事實。
