重新整理前風險掃描
在沙箱重新整理即將到來，需要知道哪些內容會遺失時使用。此掃描為唯讀操作。判斷力體現在提問、審查以及後續發出的通知中。
步驟 1：先提問，再行動
在單一訊息中提出以下問題，並等待回答。請勿先執行掃描。
- 是哪個組織，其 CLI 別名是什麼？請確認它是沙箱，而非 Production。此技能從不對 Production 進行掃描。
- 重新整理時間為何，類型是什麼（完整、部分、Developer Pro、Developer）？完整與部分會取代資料。Developer 與 Developer Pro 則不會保留任何資料。
- 是否有此組織的原始碼控制專案？如果有，其在磁碟上的路徑為何？掃描可將組織與之進行比對。
- 哪些人負責整合？檢查清單需指定負責人，因此請提供名稱（僅限內部人員）。
- 此沙箱中是否有任何內容已知不存在於別處？例如手動建立的測試資料、功能開關或示範設定。
步驟 2：執行掃描
node scan.js --org <別名> --out ./out [--project <sfdx 專案路徑>] [--days 90]
腳本會寫入 out/refresh-risk-checklist.md 與 out/refresh-risk.json。如果某項檢查失敗（例如執行使用者缺少權限，或組織中沒有該物件），腳本會在檢查清單中說明並繼續執行。未經詢問，請勿以更多權限重新嘗試。
步驟 3：審查，而非直接轉發
閱讀檢查清單，並運用腳本無法達成的判斷力：
- 哪些項目超出我們的範圍但仍存在風險？仍然將它們標記出來。客戶寧可聽到兩次，也不希望完全沒聽到。
- 哪些項目是雜訊？例如無人使用的已連線應用程式，可以主動捨棄。請直接說明，而非將其列為待辦事項。
- 哪些項目會無聲失敗？整合使用者與 OAuth Token 應優先寫入通知。
- 是否有複製後腳本？如果沒有，建議新增一個。它可以將大部分清單轉換為程式碼。
編輯檢查清單：劃掉雜訊項目、新增負責人、並根據步驟 1 的回答補充任何內容。
步驟 4：草擬通知
以簡潔的文字撰寫客戶通知，長度約一頁：
- 第一行說明重新整理日期與類型。
- 說明將會遺失或重設的內容，分組列出：資料、憑證與整合、排程工作、僅沙箱適用的設定。
- 說明我們需要客戶配合的事項及期限：為超出我們範圍的項目指定負責人、確認我們計畫捨棄的項目。
- 說明我們將採取的行動及時間表：重新整理前的匯出、重新整理後的重新輸入與排程、上線第一天的冒煙測試。
附上檢查清單。在客戶主管先行審閱前，請勿發送任何內容。
規則
- 唯讀。腳本僅查詢與列出。絕不新增任何寫入操作。
- 僅限沙箱。如果別名解析為 Production，請停止並說明原因。
- 絕不在檢查清單中貼入機密。命名憑證的名稱可以，但數值絕對不行。
- 任何離開參與者資料夾的內容中，不得包含客戶名稱。