Azure App Onboard Prereq — 儲存庫評估
評估使用者的儲存庫在建置健康狀態、應用程式完整性和 Azure 部署可行性方面的狀況 — 在基礎設施規劃之前。產生由下游階段使用的個別元件 verdict (通過/警告/失敗)。
協調器關係： 由
azure-app-onboard在第 3 步驟呼叫，或獨立用於程式碼就緒檢查。當由協調器呼叫時，請在寫入成品後將控制權返回給azure-app-onboard— 不要直接叫用下游階段。
AppOnboard 管線中的第 1 階段 (共 4 階段)。工作階段：.copilot-azure/sessions/{session-id}/。讀取 context.json。寫入 components[]、repo{}、detectedInfra[]。產生 prereq-output.json。結構描述：prereq-schemas.ts — PrereqOutput、BuildRequirements。支援直接進入。
不使用時機
| 訊號 | 重新導向 |
|---|---|
| 驗證基礎設施 (Bicep/TF/azure.yaml) | azure-validate |
| 產生 IaC | azure-prepare |
| 端對端從構想到生產 | azure-app-onboard |
執行 azd up 或部署 | azure-deploy |
規則
⛔ 絕對禁止 — 絕不允許
npm install、npm test、npx jest、pytest以及所有安裝/建置/測試命令。 在任何情況下，你都不得在預先需求階段執行npm install、npm test、npx jest、pip install、pytest、dotnet build、dotnet restore、dotnet test、go mod download、cargo build或任何套件管理員的安裝、建置或測試命令。不要執行測試套件來驗證程式碼 — 改為靜態檢查測試組態檔案。預先需求階段是唯讀評估 + 僅靜態驗證。 唯一的例外 — 兩種經許可的場景，均需經過同意檢查： (a) 代理程式在遷移/補救期間修改的程式碼 (請參閱 補救協定.md 步驟 6)，或 (b) 代理程式在零程式碼路徑上從頭編寫的程式碼 (請參閱 零程式碼路徑.md)。在任何一種情況下，安裝/建置/測試僅能透過使用者確認的建置驗證檢查 (建置檢查.md 步驟 3) 執行，且僅在使用者回答該特定命令的同意提示之後。一般事先同意永遠不算數。
- ⛔ 完整管線 (步驟 1–8)，無例外。 所有提示直接導向步驟 1。在步驟 5 中作為發現結果的一部分回答特定問題，而不是之前。
- ⛔ 評估不使用子代理程式。 三軸評估是內嵌的。例外： 零程式碼路徑 scaffolding (步驟 2)。
- 程式碼/破壞性修改需要
ask_user。在產生結果前最多問 3 個問題。直接進入：不要重複協調器的意圖問題。
MCP 工具
| 工具 | 用途 |
|---|---|
mcp_azure_mcp_get_azure_bestpractices | 根據 Azure 最佳做法驗證偵測到的堆疊模式 |
mcp_azure_mcp_extension_cli_install | 檢查/安裝必要的 CLI 工具 (az、azd、func) |
工作流程
步驟 1：工作階段檢查
協調器進入點： 工作階段存在 — 讀取 context.json，繼續執行步驟 2。
直接進入點： 檢查 .copilot-azure/sessions/active-session.json：
- 存在 → ⛔ 閱讀 工作階段協定.md 以了解繼續/新鮮檢查。在非使用者回答前不要繼續。
- 遺失 → 建立工作階段：產生 UUID，
New-Item -ItemType Directory -Path ".copilot-azure/sessions/{uuid}" -Force，透過create工具寫入context.json+active-session.json。
然後：az account show → 將 {id, name, tenantId} 合併到 context.json.azure 中。⛔ 在任何掃描之前，工作階段必須存在於磁碟上。
步驟 2：掃描工作區
掃描專案檔案。偵測元件、repo{}、detectedInfra[]、detectedServices[]。分類 Terraform 提供者。檢查 CLI 可用性。堆疊偵測衝突：使用者明確陳述獲勝 (寫入 context.json，標記掃描為覆寫)；僅限掃描 → 與使用者確認；多個堆疊 → 顯示所有堆疊並詢問 (請參閱 元件對應.md)；無程式碼 → 零程式碼路徑.md。
如果沒有專案檔案、沒有 Dockerfile 且沒有 index.html → ⛔ 閱讀 零程式碼路徑.md。
⛔ 雲端 SDK 早期檢查。 搜尋
aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase。如果找到功能性相依性 → 閱讀 雲端 SDK 遷移.md，然後ask_user：「重新導向至 Azure 雲端遷移」 (設定routeToSkill: "azure-cloud-migrate") · 「無論如何繼續評估」 (完成就緒評估 + SDK→Azure 對應，然後在第 8 步驟停止 — 在相依性被交換之前不制定計畫) · 「取消」。
步驟 3：每個元件的評估
| 子步驟 | 動作 | 參考資料 |
|---|---|---|
| 3.1 | 建置檢查 | ⛔ 你必須閱讀 建置檢查.md |
| 3.2 | 完整性檢查 | ⛔ 你必須閱讀 完整性檢查.md |
| 3.3 | 可部署性檢查 | ⛔ 你必須閱讀 可部署性檢查.md |
| 3.3a | 元件對應 (條件式) | 僅在找到 >1 個專案資訊清單 (monorepo) 時閱讀 元件對應.md |
在評估後填充每個元件的 buildRequirements。Verdict 傳播、層級規則和 f1Viable 聚合在 就緒檢查.md 和個別檢查參考資料中說明。
步驟 4：寫入成品 + 就緒檢查
⛔ 驗證 context.json 存在於磁碟上。閱讀 就緒檢查.md (verdict、層級、批次然後核准、快速通道)，然後閱讀 預先需求成品.md (寫入程序、結構描述)。
步驟 5：呈現發現結果
依照 就緒檢查.md § 呈現發現結果 — 在繼續之前顯示按嚴重性分組的 verdict。
步驟 6：補救 (條件式)
⛔ 如果存在任何 ❌ 失敗 verdict、🔧 建議修正，或帶有 fixPhase: "prereq" 的 ⚠️ 警告，你必須閱讀 補救協定.md。包含補救迴圈、靜態驗證、重新評估指令、補救後成品更新，以及建置驗證同意檢查。如果所有 verdict 都是 ✅ 通過或 ⚠️ 警告且不含 fixPhase: "prereq"，則跳至步驟 7。
步驟 7：寫入最終狀態
completedPhases 已包含 "prereq" + currentPhase: null (來自步驟 4)。然後：
⛔ 寫入
lastScanCommit。 執行git rev-parse HEAD，並將完整的 40 個字元 SHA 儲存為context.json.repo.lastScanCommit。必要 — 步驟 1 的停滯檢查會在恢復時與 HEAD 進行比較以偵測變更。
步驟 8：路由
⛔ 強制 — 不要跳過此步驟。
路由欄位： 所有路由會將
routeToSkill和routeReason寫入context.json。
補救後上下文： 如果執行了步驟 6，請以：「補救完成 — {N} 個問題已修正，您的應用程式現在 {overallHealth}。」開頭引導路由提示。