格式逐漸漂移
v1.2.3、release-1.2.3、final 混在一起，之後誰也無法確定哪個才是正式版本。
為什麼需要它
tag 看似小事，卻常在發版時變成風險。
手動命名、混合格式與不清楚的歷史 tag，會讓 CI、release note 和協作失去共同依據。
版本順序靠猜
補歷史 tag 或平行開發時，容易建立低於既有版本的 tag，破壞自動化流程。
問題太晚浮現
沒有本機檢視與驗證，問題往往要到 CI 或其他人取得 tag 後才發現。
一條安全路徑
先釐清規格，再決定下一個版本。
檢視現況
從 list 開始，依語意排序並標示不合規、無法解析或重複的 tag；Tagsmith 不會自動改寫歷史。
確認意圖
規格清楚的 SemVer 歷史可以繼續；混合、模糊或非 SemVer 的歷史，先用 init 定義團隊規格。
安全預覽
重新檢視後，再用 next 計算下一個版本；這一步不會改動 repository。
稍後再建立
建立 tag 前會依規格與本機已知歷史驗證。預設不會推送；推送到 remote 是另一個明確、由團隊工作流決定的動作。
從一條線開始
清楚的規格能隨 release 節奏擴展。
SemVer、CalVer、build number
SemVer 是零設定檢視的預設路徑。定義規格後，也可選擇符合團隊節奏的 CalVer 或遞增 build number。
單一 tag line，必要時再擴展
先用一條 tag line 建立共同規則；只有 app、release 等獨立序列真的需要分開時，才加入多條 tag line。
自動化讀取結果
--json 讓 CI 與 script 讀取 Tagsmith 對規格的評估結果；周邊自動化仍負責後續動作。
選用的本機工作流護欄
merge policy 可在本機 git workflow 中協助維護 repository 慣例；它不是 remote branch protection 或伺服器端政策。
產物版本與變更意圖保持一致
可讓 tag line 對照 package.json 的版本，並用可檢視的 commit policy 解釋 patch、minor 或 major 建議；需要時，建立前也可強制使用同一套檢查。
明確採用
試用後，把規格交給團隊共同維護。
當檢視結果符合你的意圖，用 tagsmith init 建立並提交 .tagsmith.json。這份設定檔讓規格成為團隊共識，而不只是個人的習慣。
採用步驟
$ npx @carllee1983/tagsmith init✓ 建立 .tagsmith.json
# 提交團隊的明確規格
$ git add .tagsmith.json