"Retrospective"
- 工具的預設行為決定使用者習慣 — 從版本錯置看工具設計的 opinion 責任
規範與工具預設不一致時工具會贏。預設路徑就是團隊的實際流程，接受自由輸入的介面設計時要負起 opinion 責任。
- 改善類工作放進新功能版本 — 版本歸屬判斷的工具化
根因分析、重構等改善工作被塞進功能版本、語意混亂。主張工具該依工作類型建議版本歸屬（semver 的 MINOR / PATCH 語意可被工具表達）。
- 並行 AI Agent 修改同一檔案的衝突模式與協調策略
並行派多個開發者或 AI agent 同一批 ticket，反覆修改同一個檔案、卡在 branch protection 與 file-modified-since-read。問題在派發策略沒考慮檔案層級的衝突。
- 版本狀態殘留：為什麼已完成的版本在看板上顯示未完成
看板顯示早已完成的版本仍為 active、誤導查看者。根因是發布工具只檢查當前版本完成度、不掃前版本的狀態殘留；工具的檢查範圍決定了系統的一致性邊界。
- 新增欄位忘記同步 reset — 跨測試狀態洩漏的系統性根因
測試結果取決於執行順序、看似功能 bug 實為上一個 test case 狀態沒清乾淨。根因是新增 private 欄位時沒同步更新 reset，隱含契約沒被顯性化。
- 驗證導向的 CLI 工具文章：官方 docs 查核放過的落差類型
CLI 工具教學的指令正確性不能只靠官方文件查核、要實機驗證時回來。官方文件驗的是「文件說的是否正確」、驗不了「文件沒說的是否存在」。
- Migration Playbook 方法論的演化紀錄：Stage 0 variant 規劃把 collapse 率從 60% 降到 0%
跨 vendor migration playbook 需要獨立寫作方法論的依據，以及這套方法論從三輪 batch dogfood 中演化出來的驗證證據。
- Vendor 深度技術文章方法論的演化紀錄：同 vendor 系列的開場輪替驗證
vendor overview 飽和後要寫單一功能深度文章、需要選題與結構依據時回來。這套方法論的驗證來源與 cadence variant 在高風險場景（同 vendor sub-tool 系列）的實證。
- Cards-Skills 系統的活案例：從一個 search bug 到 14 張新卡的閉環
report 卡片 + skill 作為自我修正的活知識庫：從一個 search bug 走完閉環的 case study。教訓：test 過不等於對齊意圖、dogfooding 失敗靠外部提問現形、修 bug 是 case study 起點。