/tidy——清除階段
每個倉庫都會積累腐化物：指向已移動或被 gitignore 檔案的連結、意外提交的金鑰、沒有被任何資源引用的資產、安裝時 404 的依賴項。這些問題在日常中並不顯眼，卻總在最糟的時刻浮現（讀者看到 404、CI 失敗、金鑰外洩）。/tidy 是讓你有意識地發現並清除這些問題的階段。
這是一個階段，而非關卡。快速防護措施（check-changelog、check-assets）會在每次推送時阻擋；/tidy 則是當你準備清理時，所進行的廣泛、先報告再處理的掃描。
如何執行
bun run tidy # 當前倉庫 → 摘要 + 建議後續步驟
bun run tidy <path> # 指定倉庫
bun run tidy --all ~/Claude # 指定資料夾下的每個 git 倉庫 → 一個彙總表格
bun run tidy --links # 深入一個類別（--secrets --files --deps）
它掃描四種腐化物，並先顯示範圍（每個類別的數量），讓你永遠不會被大量輸出淹沒：
| 所捕捉的內容 | |
|---|---|
| 🔗 連結 | 指向缺少檔案或僅解析到 gitignored 目標的 markdown/HTML 連結（在作者的硬碟上可以運作，但對其他人則是 404） |
| 🔑 機密 | 高可信度的已提交金鑰模式（AWS、Stripe、GitHub、Google、Slack、私鑰區塊）——標記為需審查，而非自動判定 |
| 🗑 死檔 | 已提交的圖片/資產，但沒有任何資源引用——可以安全刪除 |
| 📦 依賴項 | package.json 中無法在 npm 上解析的依賴項（dead-@inngest/sdk 類） |
流程（報告 → 建議 → 詢問 → 修復）
- 執行。 呈現摘要表格——每個類別、每個倉庫的範圍。
- 建議。 指出哪些類別重要及其原因（損壞的連結是讀者的 404；標記的機密需要輪替；無法解析的依賴項破壞每次安裝）。
- 詢問。 讓操作者選擇要清理的內容。永遠不要假設。
- 在確認後修復——先規劃，再套用。
bun run tidy --fix <repo>會先印出精確的變更計劃（哪些損壞的連結會被解除連結）而不寫入任何內容；重新加上--apply來套用這些編輯。這樣你永遠先看到每個變更。自動修復的範圍刻意狹窄：它只會解除連結損壞或被 gitignore 的文字連結（[text](bad)→text）。機密、依賴項、圖片/HTML 連結以及檔案刪除永遠不會自動套用——它們會作為手動項目列出，並附上指引（輪替金鑰、選擇正確的套件），因為它們的修復涉及判斷，而非行編輯。使用--all廣泛調查，然後一次--fix一個倉庫。
紀律
- 始終先報告。 價值在於看到腐化物，然後才動手。
- 不要將其設為關卡。
/tidy執行較慢（網路依賴項檢查）且範圍廣泛——將其保持為一個階段，而非推送阻擋器。狹窄的防護措施仍是關卡。 - 機密需經過審查。 模式匹配只是提示你去查看，而非最終判定——如果屬實，修復方式是輪替金鑰，而不僅僅是刪除那行程式碼。
- 跳過已凍結的目錄（
_archive/、node_modules/）——它們不屬於你的清理範圍。 - 引擎可攜帶。
scripts/tidy.ts可以針對任何倉庫路徑執行——這正是讓掃描超過 100 個倉庫只需單一命令的原因。