npm stage-only Token：拆分發布自動化與最終核准時應留存的佐證
將 CI 建立套件的權限與將該套件公開發布給使用者的權限分開，可以讓發布的最終責任更加明確。然而，僅僅多加一個核准按鈕，並不代表供應鏈風險就此消失。首先必須釐清核准者到底需要確認哪些內容。
GitHub 於 9 月 18 日宣布，npm 細部存取 Token（granular access token）現已可選擇 stage-only 寫入權限。此流程由自動化機制將版本提交至等待審查狀態，再由維護者透過 2FA 核准公開發布。以下將區分官方變更內容與編輯團隊為落實於維運環境所提出的建議。
阻止直接公開與完全移除寫入權限並不相同
根據官方說明，使用該 Token 可以執行 npm stage publish，但透過 npm publish 進行的直接公開將會被拒絕。即使具備用於自動化的 2FA 略過設定，此限制依然適用。這項功能並不會自動變更既有 Token 的行為，而是採取選擇性導入的方式。
需要注意的是，移動 dist-tag 以及將版本標記為 deprecation 等其他套件寫入權限依然會被保留。切勿將 stage-only 名稱解讀為唯讀或毫無風險的 Token。允許存取的套件範圍、秘密（Secret）儲存位置、使用主體以及廢棄流程，依然需要妥善管理。
界定核准者比對發布內容的基準封裝包
以下內容並非 npm 的強制規定，而是針對小型團隊提出的維運建議。在單一核准請求中，請一併附上原始碼 Commit、目標套件與版本、測試結果、套件內涵蓋的檔案清單以及變更摘要。若核准者必須在 CI 紀錄的多個位置拼湊佐證，審查就很容易淪為形式上的點擊操作。
特別是原始碼審查與發布檔案審查是兩回事。版本庫中原本不存在的檔案可能會在建置過程中被打包進去，必要的檔案也可能遺漏。團隊應以實際提交的產出物為基準建立審查資料，並可確立一項原則：審查後若變更了產出物，就必須將其視為新的審查對象。
在綠燈的 CI 之後依然存在等待狀態
如果既有的自動化流程將指令執行成功直接回報為發布完成，就必須先調整狀態的呈現方式。做法是拆分為提交完成、等待核准、公開完成，並分別記錄各階段的確認依據。在通知訊息中，標示目前階段與負責人，會比單純顯示「成功」二字對維運人員更有實質幫助。
舉個假設的情境，若夜間 CI 提交了新版本，但負責人直到隔天才進行審查，就不應該在提交當下向使用者發送版本發布公告。請將流程串接為在團隊確認公開之後，才接續發布文件或公告。當待審佇列堆積時，由誰負責審查以及何時清理先前的提交，也必須事先達成共識。
先以單一小型套件驗證遷移成效
目前官方說明列出的先決條件包括：既有的 npm 套件、套件公開權限、帳號 2FA、npm CLI 11.15.0 以上版本以及 Node.js 22.14.0 以上版本。在實際遷移之前，應再次確認最新文件，並檢查所使用的 Runner 版本。
建議先在影響範圍較小的單一套件上限制 Token 範圍，完整演練從 staging 提交、維護者審查到確認公開結果的流程。若一旦失敗就立刻切換回擁有廣泛權限的舊 Token 略過檢查，那麼切分權限邊界就失去了意義。系統也必須能夠將核准延遲視為正常狀態來處理。
與 Trusted Publishing 比較的關鍵考量
npm 同時也提供了使用 OIDC 的 Trusted Publishing。首要之務是評估該機制是否符合支援的 CI 環境與團隊的核准方式，沒有理由將 stage-only Token 當作所有團隊的唯一最終解法。對於必須繼續使用 Token 的自動化流程而言，這可以理解為多了一項可循序漸進遷移的選擇。
官方公告指出，其目標是在 2027 年 1 月全面移除 bypass-2FA Token 的直接公開發布功能。與其臆測尚未確定的各項實作細節，不如現在就先梳理適用的 Workflow 清單與負責遷移的人員更為實用。至於時程是否有變更，後續仍應密切注意官方公告。
評估是否導入時的考量重點
本文並非主張社群已有廣泛共識或此舉必然能降低多少事故率，而是以新功能的官方運作為基礎，提出一套可供檢驗的維運流程。能否清楚說明自動化該負責的工作與人工該確認的項目，是判斷是否導入的起點。
今天就能著手進行的工作包括：盤點目前哪裡正在使用發布 Token、寫下判定公開完成的條件，以及定義單次核准所需的佐證依據。唯有將權限限制與審查品質並重視之，staging 階段才能真正發揮效益。