更新堆疊規格 是做什麼的？
你更新事實（版本、日期、測量、來源）。你向作者提議決策並等待確認。若有指定參數，則只檢查指定的工具；否則檢查所有工具。
1. 盤點
從 stack-spec.md 列出：
- 第 §2 節中每一行及其版本號；
- 第 §3 和 §4 節中的所有版本、發布日期或穩定性聲明（例如「stable」、「release candidate」、「alpha」、「experimental」或工具旁的版本號碼）；
- 每個「Revisit when」的條件，作為待測試的觸發條件；
- 文件標頭的版本日期。
2. 對照主要來源進行檢查
使用註冊表、發布說明、官方文件。絕不依賴記憶。
- npm：使用
npm view <pkg> dist-tags time --json。當前版本 = 最新且已發布至少 14 天的版本；列出更年輕的發行版作為「即將發布」。 - nixpkgs 工具（Node.js、Biome、nixfmt、Wrangler、Playwright 瀏覽器）：使用
nix eval --raw nixpkgs#<pkg>.version搭配nixos-unstable，並參考該專案的發布頁面。 - 平台功能（Cloudflare、瀏覽器支援）：查閱官方文件頁面及其日期。
針對每個工具，記錄：規格中的版本號、當前版本，以及是否存在介於兩者之間的主要版本（或規格等待的版本）。
3. 分類每個變更
完整閱讀每個新主要版本的變更日誌或遷移指南，以及規格所依賴的文件。然後分類：
- 事實（版本號、日期、套件數量）：直接更新。
- 原因（已修復的已知缺點、新引入的缺點）：更新原因的敘述文字；並在報告中列出。
- 決策（選擇本身、現在更好的替代方案、已觸發的「Revisit when」觸發條件）：不要編輯。報告：變更內容、來源、選項及其成本、建議。等待確認。
4. 編輯
- 保持規格的風格：簡潔、規則優先、原因隨後、使用 ISO 日期；將已變更的決策文字標記為「Amended <日期>: …」。
- 新事實 → 在編號清單末尾新增來源，並標註「checked <日期>」。絕不重新編號來源；僅在沒有任何引用時才刪除來源。
- 絕不重新編號章節。新主題成為其所屬章節的下一個子章節；請詢問作者該站點是否已使用該編號，並回報所選的編號。
- 更新文件標頭的版本日期。
- 不得提及任何使用此規格的站點、使用者或儲存庫。
5. 驗證與提交
- 每個新變更或已變更的 URL 都必須能正常解析：使用
curl -sIL <url>驗證。 - 不得提及任何使用此規格的站點、使用者或儲存庫。
- 使用 Jujutsu 進行簽署提交，每個主題一個提交（例如「記錄 Astro 8」、「提議 TypeScript 7」），提交訊息需說明變更內容、原因以及檢查過的來源。除非要求，否則不要推送。
6. 報告
針對每個工具，呈現：規格中的版本 → 當前版本。然後列出：已更新的事實、已更改的原因、提議的決策與建議、尚未超過 14 天的即將發布版本。