事件

版本看板顯示 v0.2.0 有未完成任務。查證後發現 v0.2.0 的 38 張工作項目全部完成、v0.2.1 的 7 張全部完成、v0.2.2 的 1 張已結案——但三個版本在版本清單中仍標記為 active。

這些版本在數個月前就完成了所有工作，但從未被標記為 completed。看板忠實地反映了版本清單的狀態，所以持續顯示「有未完成工作」。

根因：工具的檢查範圍太窄

版本發布工具在發布 v0.3.0 時，只做一件事：「v0.3.0 的所有 ticket 都完成了嗎？」答案是「是」，就繼續發布。

它從不問：「比 v0.3.0 更早的版本中，有沒有哪個版本的 ticket 早已全部完成，但 status 仍為 active？」

這個檢查加起來不難（遍歷版本清單、對每個 active 版本計算 ticket 完成率、完成率 100% 但 status 不是 completed 就報 warning）。但沒有人想到要加——因為在設計工具時，焦點在「當前版本的發布流程」，不在「全局狀態一致性」。

教訓

資料庫設計中，如果只在寫入時驗證單筆資料的格式而不檢查跨表一致性，orphan record 就會累積。版本管理工具的 pre-flight check 是同一個 pattern——它是內部流程的「外鍵約束」。範圍太窄，殘留就會累積。

工具只檢查當前版本，一致性就只在當前版本內維持。歷史版本的狀態漂移不會被發現——直到有人手動查看看板。

修正

在版本發布的 pre-flight check 加入全局掃描：

1$ version-release check
2[OK] v0.3.0：所有 ticket 完成，可發布
3[WARN] v0.2.0：38 張 ticket 全部完成但 status 仍為 active
4[WARN] v0.2.1：7 張 ticket 全部完成但 status 仍為 active

修正成本極低（一個迴圈 + 一個 warning），但能在問題累積前暴露。