azure-app-onboard-prereq
熱門評估原始碼是否準備好部署到 Azure — 在基礎設施工作之前的檢查。評估建置健康度、應用程式完整性、相依性與本機服務、技術堆疊相容性，以及部署可行性。回答關於應用程式在部署前需要什麼的問題 — 框架、相依性和設定。檢查相依性是否相容，並識別部署阻礙與不支援的框架。適用時機：「評估我的儲存庫」、「我的應用程式準備好部署了嗎」、「我的應用程式需要什麼才能部署」、「部署前我需要什麼」、「我的應用程式需要」、「我可以把這個送到 Azure 嗎」、「掃描我的儲存庫找問題」、「這個應用程式可部署嗎」、「檢查我的應用程式是否準備好上 Azure」、「我需要 Dockerfile 嗎」、「什麼阻礙了我的部署」、「有任何阻礙嗎」、「我的相依性相容嗎」、「Azure 支援我的框架嗎」、「部署前需要改變什麼」、「檢查我的應用程式設定」。
"評估原始碼是否準備好部署到 Azure — 在基礎設施工作之前的檢查。評估建置健康度、應用程式完整性、相依性與本機服務、技術堆疊相容性，以及部署可行性。回答關於應用程式在部署前需要什麼的問題 — 框架、相依性和設定。檢查相依性是否相容，並識別部署阻礙與不支援的框架。適用時機：「評估我的儲存庫」、「我的應用程式準備好部署了嗎」、「我的應用程式需要什麼才能部署」、「部署前我需要什麼」、「我的應用程式需要」、「我可以把這個送到 Azure 嗎」、「掃描我的儲存庫找問題」、「這個應用程式可部署嗎」、「檢查我的應用程式是否準備好上 Azure」、「我需要 Dockerfile 嗎」、「什麼阻礙了我的部署」、「有任何阻礙嗎」、「我的相依性相容嗎」、「Azure 支援我的框架嗎」、「部署前需要改變什麼」、「檢查我的應用程式設定」。」
Azure App Onboard Prereq — 儲存庫評估
在使用者的儲存庫中評估建置健康度、應用程式完整性，以及 Azure 部署可行性 — 在基礎設施規劃之前。產生每個元件的判定結果（PASS/WARN/FAIL），供後續階段使用。
協調器關係： 由
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以及所有安裝/建置/測試指令一律不允許。
在任何情況下，您都不得在 prereq 階段執行npm install、npm test、npx jest、pip install、pytest、dotnet build、dotnet restore、dotnet test、go mod download、cargo build或任何套件管理員的安裝、建置或測試指令。不要執行測試套件來驗證程式碼 — 請改為靜態檢查測試設定檔。Prereq 階段是唯讀評估 + 僅靜態驗證。
唯一例外 — 兩種經同意控管的授權情境： (a) 代理程式在遷移/修正期間修改的程式碼（請參閱 remediation-protocol.md 步驟 6），或 (b) 代理程式在零程式碼路徑上從頭撰寫的程式碼（請參閱 zero-code-path.md）。在任一情況下，安裝/建置/測試僅能透過使用者確認的建置驗證閘道（build-check.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：
- 存在 → ⛔ 閱讀 session-protocol.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，標記為覆寫）；僅掃描 → 與使用者確認；多個堆疊 → 顯示所有並詢問（請參閱 component-mapping.md）；無程式碼 → zero-code-path.md。
如果沒有專案檔案、沒有 Dockerfile，且沒有 index.html → ⛔ 閱讀 zero-code-path.md。
⛔ Cloud SDK 早期閘道。 搜尋
aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase。如果找到功能性相依性 → 閱讀 cloud-sdk-migration.md，然後ask_user：「重新導向至 Azure Cloud Migrate」（設定routeToSkill: "azure-cloud-migrate"）· 「無論如何繼續評估」（完成就緒評估 + SDK→Azure 對應，然後在步驟 8 停止 — 在相依性被替換之前不制定計畫）· 「取消」。
步驟 3：每個元件的評估
| 子步驟 | 動作 | 參考資料 |
|---|---|---|
| 3.1 | 建置檢查 | ⛔ 您必須閱讀 build-check.md |
| 3.2 | 完整性檢查 | ⛔ 您必須閱讀 completeness-check.md |
| 3.3 | 可部署性檢查 | ⛔ 您必須閱讀 deployability-check.md |
| 3.3a | 元件對應（條件式） | 僅當找到 >1 個專案資訊清單（monorepo）時，才閱讀 component-mapping.md |
評估後為每個元件填入 buildRequirements。判定結果傳播、層級規則和 f1Viable 彙總在 readiness-gate.md 和個別檢查參考資料中。
步驟 4：寫入成品 + 就緒閘道
⛔ 確認 context.json 存在於磁碟上。閱讀 readiness-gate.md（判定結果、層級、批次後批准、快速通道），然後閱讀 prereq-artifacts.md（寫入程序、結構描述）。
步驟 5：呈現發現結果
根據 readiness-gate.md § 呈現發現結果 — 在繼續之前，按嚴重性分組顯示判定結果。
步驟 6：修正（條件式）
⛔ 如果存在任何 ❌ FAIL 判定結果、🔧 建議修正或 ⚠️ WARN 且 fixPhase: "prereq"，您必須閱讀 remediation-protocol.md。包含修正迴圈、靜態驗證、重新評估要求、修正後成品更新，以及建置驗證同意閘道。如果所有判定結果都是 ✅ PASS 或 ⚠️ WARN 且沒有 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}。」開頭引導路由提示。
⛔ 從上到下評估列 — 第一個符合者獲勝。
| # | 條件 | 動作 |
|---|---|---|
| 1 | routeToSkill 已設定（任何進入點） |
ask_user：「重新導向至 {routeToSkill}」/「現在不要」。⛔ 管線停止 — 不要繼續進行架構規劃。 |
| 2 | cloudSdkFindings[] 非空（使用者選擇「無論如何繼續評估」） |
將 cloud-SDK → Azure 交換對應呈現為 🔶 阻礙，然後使用以下確切提示 ask_user：「🔶 Cloud SDK 遷移必要 — 這些相依性必須在應用程式可以部署到 Azure 之前進行交換。（重新導向至 azure-cloud-migrate / 停止 — 手動交換並重新執行）」 — 重新導向設定 routeToSkill: "azure-cloud-migrate"，停止則中斷。⛔ 管線停止 — 不要繼續進行架構規劃，也不要提供「繼續準備」選項；在相依性被交換之前，應用程式無法部署。 |
| 3 | 協調器 + 無 routeToSkill |
告訴使用者：「✅ 您的應用程式已評估完畢並準備就緒 — 讓我們規劃您的 Azure 部署。」然後呼叫 azure-app-onboard。⛔ 不要停止，不要等待使用者輸入，不要敘述內部交接。使用者在範圍分類時已同意完整管線。 |
| 4 | 直接 + ready/readyWithCaveats + 無現有 Azure 基礎設施 | ask_user：「部署到 Azure（完整管線）」→ 呼叫 azure-app-onboard /「現在不要」 |
| 5 | 直接 + ready/readyWithCaveats + 有現有 Azure 基礎設施 | ask_user：「重新開始」→ 呼叫 azure-app-onboard /「使用現有基礎設施」→ 呼叫 azure-prepare /「現在不要」 |
| 6 | 直接 + blocked | 報告阻礙摘要 +「修復後重新執行。」 |
嚴重性層級（🛑🔶❌🔧⚠️✅）定義於 readiness-gate.md。
輸出
| 成品 | 位置 | 消費者 |
|---|---|---|
| 工作階段上下文 | context.json → components[]、repo{}、detectedInfra[]、detectedServices[] |
所有後續階段 |
| Prereq 輸出 | prereq-output.json |
prepare 階段（透過 azure-app-onboard） |
| 就緒報告 | .copilot-azure/sessions/{uuid}/readiness-report.md |
使用者（離線參考） |
