診斷 App Store 提交封鎖問題，並使用 asc 操作審查健康狀態，包括就緒驗證、修復路由、狀態監控、取消與重試決策。當驗證失敗、版本處於無效狀態、審查狀態不明或卡住、或需要修復並重試失敗的提交時使用。關於暫存、上傳、發布與提交執行，請使用 asc-release-flow。
App Store 提交健康狀態
使用此技能來解釋為何發布無法繼續，以及管理現有的審查提交。將健康的發布執行交回給 asc-release-flow。
職責邊界
此技能負責：
- 就緒驗證與封鎖診斷；
- 公開 API、網頁工作階段與手動修復路由；
- 審查狀態與歷史記錄；
- 取消與重試決策。
請勿從此技能進行暫存、上傳、發布或提交健康的發布。
回答順序
- 說明版本是就緒、被封鎖，還是已在審查中。
- 列出每個封鎖項目及其證據。
- 區分公開 API 修復與網頁工作階段及手動工作。
- 給出一個下一步指令。不要傾倒整個修復目錄。
確認目標
- 解析
APP_ID、版本字串或VERSION_ID、BUILD_ID、平台，以及任何已知的SUBMISSION_ID。 - 使用
asc auth login或ASC_*環境變數設定驗證。 - 僅在儲存庫測試與獨立驗證時使用
ASC_BYPASS_KEYCHAIN=1，而非一般使用者工作階段。 - 一旦目標解析完成，優先使用 ID；當應用程式、版本或產品解析不明確時停止。
診斷就緒狀態
首先執行標準的就緒報告：
asc validate --app "APP_ID" --version "1.2.3" --platform IOS --output table
當已知時使用 --version-id "VERSION_ID"。當警告必須導致自動化失敗時，加上 --strict。
向審查專用醫生詢問有序的說明：
asc review doctor --app "APP_ID" --version "1.2.3" --platform IOS --output table
當報告指向建置或版本時，收集直接證據：
asc builds info --build-id "BUILD_ID" --output table
asc versions view --version-id "VERSION_ID" --include-build --include-submission --output table
對於數位商品，僅執行相關的產品驗證器：
asc validate iap --app "APP_ID" --output table
asc validate subscriptions --app "APP_ID" --output table
將 asc validate 提供的有序修復計畫視為修復佇列。在進入下一個類別之前，修復並驗證一個類別的封鎖項目。
路由修復
當封鎖項目是建置處理、中繼資料、截圖、審查詳細資料、加密、內容權利、年齡分級、可用性或版本範圍的產品中繼資料時，使用公開 API 指令。
當診斷識別出這些常見封鎖項目之一或首次發布的可用性缺口時，請閱讀 references/readiness-repairs.md。
僅在 IAP 或訂閱驗證失敗、Apple 要求首次審查附件、或版本化產品必須加入現有審查提交時，閱讀 references/digital-goods.md。
僅在驗證報告 App 隱私權建議或無法透過公開 API 確認發布狀態時，閱讀 references/app-privacy.md。
當驗證報告 Game Center 元件或版本封鎖時，將其交給 asc-release-flow 並要求多項目參考的 Prepare every item 章節。不要將 Game Center 路由到一般就緒或數位商品修復。
僅在公開 API 無法涵蓋的缺口時使用網頁工作階段指令，並說明需要已驗證的 Apple 網頁工作階段。當使用者拒絕網頁工作階段自動化時，保留手動的 App Store Connect 備用方案。
判斷版本是否健康
當以下條件滿足時，版本即可返回 asc-release-flow：
asc validate沒有封鎖問題；- 附加的建置狀態為
VALID； - 中繼資料、截圖、應用程式資訊、審查詳細資料、內容權利、加密、年齡分級、定價與可用性已解決；
- 相關的
asc validate iap和/或asc validate subscriptions檢查沒有封鎖問題，且所需的數位商品版本已準備就緒； - 任何 Game Center 版本項目已透過
asc-release-flow的多項目提交參考檢查過； - App 隱私權已確認或已發布。
不要僅因為一個驗證器成功退出就稱版本就緒。報告任何仍需要網頁工作階段或手動檢查的警告。
監控審查
當提交 ID 未知時，使用應用程式範圍的狀態：
asc review status --app "APP_ID" --version "1.2.3" --platform IOS --output table
當可用時，使用確切的提交或版本 ID：
asc submit status --id "SUBMISSION_ID" --output table
asc submit status --version-id "VERSION_ID" --output table
使用發布儀表板來查看周圍的建置與審查訊號：
asc status --app "APP_ID" --include builds,appstore,submission,review --output table
使用歷史記錄來區分當前的停滯與先前被拒絕或完成的提交：
asc review history --app "APP_ID" --version "1.2.3" --paginate --output table
取消不健康的提交
在取消之前，先解析確切的活躍提交。先預覽狀態，然後要求確認：
asc submit status --id "SUBMISSION_ID" --output table
asc submit cancel --id "SUBMISSION_ID" --confirm
當透過版本解析時，包含應用程式以進行現代的審查提交查詢：
asc submit status --version-id "VERSION_ID" --output table
asc submit cancel --version-id "VERSION_ID" --app "APP_ID" --confirm
當確切的審查提交已知時，較低層級的等效指令也有效：
asc review submissions-cancel --id "SUBMISSION_ID" --confirm
不要僅因為審查時間比預期長就取消提交。先確認狀態與使用者的意圖。
決定何時重試
沒有專用的重試指令。請使用以下順序：
- 僅在必須撤回活躍提交時才取消。
- 修復已證實的封鎖項目。
- 重新執行
asc validate及相關的產品驗證器。 - 確認沒有活躍提交已佔用該版本或審查項目。
- 將健康的版本及任何保留的
SUBMISSION_ID交給asc-release-flow進行提交執行。重複使用已檢查過的READY_FOR_REVIEW草稿；僅在沒有相符的草稿或活躍提交時才建立提交。
常見失敗路由
| 症狀 | 首要證據 | 修復路由 |
|---|---|---|
| 版本處於無效狀態 | asc validate, asc review doctor |
有序的就緒修復 |
| 匯出合規必須獲得核准 | 建置資訊與加密宣告 | 就緒修復 |
| 找到多個應用程式資訊 | asc apps info list --app "APP_ID" |
解析確切的應用程式資訊 ID |
| IAP 或訂閱未就緒 | 產品驗證器 | 數位商品參考 |
| Game Center 元件或版本未就緒 | asc validate 診斷 |
asc-release-flow 多項目準備章節 |
| App 隱私權發布狀態不明確 | 驗證建議 | App 隱私權參考 |
| 審查似乎卡住 | 審查狀態加上歷史記錄 | 監控；僅在有證據與核准時取消 |
護欄
- 不要使用已移除的
submit-preflight或submit-create捷徑。 - 不要從此技能提交；將健康執行返回給
asc-release-flow。 - 不要將網頁工作階段自動化視為公開 App Store Connect API 的涵蓋範圍。
- 在確認先前的提交狀態與封鎖修復之前，不要重試。
- 使用
--output table進行人類診斷，使用 JSON 進行自動化。 - 對於 macOS，使用
--platform MAC_OS，同時保持相同的健康生命週期。
