在部署到 Azure 前评估代码仓库是否就绪（构建健康…

当你需要判断一个代码仓库能否部署到 Azure、有哪些阻塞项和依赖需求时，用只读静态评估给出逐组件 PASS/WARN/FAIL 结论。

适用场景

解决思路

1. 先做会话检查：若由编排器进入，读取 context.json 后继续；若为直接进入，检查 .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. 扫描工作区：查找项目文件，识别 components、repo{}、detectedInfra[]、detectedServices[]，对 Terraform provider 分类，检查 CLI 可用性；栈检测冲突时以用户明确声明为准（写入 context.json 并标记为 override），仅扫描得出则向用户确认，多栈则全部展示并询问，无代码则走 zero-code-path.md；若无项目文件、无 Dockerfile 且无 index.html，则读取 zero-code-path.md。
3. 执行云 SDK 早期门禁：grep 查找 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 映射后停在 Step 8，依赖未替换前不出计划）、“取消”之间选择。
4. 逐组件评估：3.1 构建检查（必须读 build-check.md）；3.2 完整性检查（必须读 completeness-check.md）；3.3 可部署性检查（必须读 deployability-check.md）；3.3a 仅当发现多于一个项目清单（monorepo）时读 component-mapping.md 做组件映射；评估后为每个组件填充 buildRequirements。
5. 写入产物并执行就绪门禁：确认 context.json 已落盘，读取 readiness-gate.md（结论、层级、批量后批准、快速通道），再读 prereq-artifacts.md 按其写入流程与 schema 写产物。
6. 展示发现：按 readiness-gate.md § Present Findings，在继续前按严重程度分组展示各组件结论。
7. 条件性修复：若存在任何 ❌ FAIL、🔧 Recommended Fix，或带 fixPhase: "prereq" 的 ⚠️ WARN，则必须读 remediation-protocol.md，按其修复循环、静态验证、重新评估要求、修复后产物更新和构建验证同意门禁执行；若全部为 ✅ PASS 或无 fixPhase: "prereq" 的 ⚠️ WARN，则跳到 Step 7。
8. 写入最终状态：确认 completedPhases 已含 "prereq" 且 currentPhase: null；运行 git rev-parse HEAD，把完整 40 位 SHA 写入 context.json.repo.lastScanCommit，用于恢复时的陈旧性检查。
9. 执行路由（不可跳过）：把 routeToSkill 和 routeReason 写入 context.json；若 Step 6 执行过，路由提示以“Remediation complete — {N} issues fixed, your app is now {overallHealth}.”开头；按行从上到下匹配，首个命中生效：1) routeToSkill 已设置 → ask_user 询问“Redirect to {routeToSkill}”/“Not now”，流水线停止；2) cloudSdkFindings[] 非空（用户选了继续评估）→ 把云 SDK→Azure 替换映射作为 🔶 阻塞项展示，并用指定提示询问重定向到 azure-cloud-migrate 或停止，流水线停止且不提供“继续到 prepare”；3) 编排器进入且无 routeToSkill → 告知用户已评估就绪并调用 azure-app-onboard，不停止、不等待输入；4) 直接进入且 ready/readyWithCaveats 且无 Azure 基础设施 → ask_user 询问“Deploy to Azure (full pipeline)”则调用 azure-app-onboard，否则“Not now”；5) 直接进入且 ready/readyWithCaveats 且已有 Azure 基础设施 → ask_user 询问“Start fresh”则调用 azure-app-onboard、“Use existing infra”则调用 azure-prepare、“Not now”；6) 直接进入且 blocked → 报告阻塞摘要并提示“Fix and re-run.”。
10. 严格遵守只读约束：绝不运行 npm install、npm test、npx jest、pip install、pytest、dotnet build、dotnet restore、dotnet test、go mod download、cargo build 或任何包管理器安装/构建/测试命令；不要跑测试套件验证代码，改为静态检查测试配置文件；唯一例外是代理在迁移/修复中修改过的代码或零代码路径中从零编写的代码，且必须经用户在 build-check.md Step 3 的逐命令同意提示确认后，才可通过构建验证门禁运行。
11. 评估全程内联执行，不使用子代理（零代码路径脚手架 Step 2 除外）；代码或破坏性修改需 ask_user，结果前最多问 3 个问题；直接进入时不要重复编排器已问过的意图问题；所有提示直接进入 Step 1，具体问题作为 Step 5 发现的一部分回答。
12. 按需使用 MCP 工具：用 mcp_azure_mcp_get_azure_bestpractices 对照 Azure 最佳实践校验检测到的栈模式，用 mcp_azure_mcp_extension_cli_install 检查/安装所需 CLI 工具（az、azd、func）。
13. 产出并交付：把会话上下文写入 context.json 的 components[]、repo{}、detectedInfra[]、detectedServices[] 供所有下游阶段消费；把 prereq-output.json 供 prepare 阶段（经 azure-app-onboard）消费；把就绪报告写到 .copilot-azure/sessions/{uuid}/readiness-report.md 供用户离线参考。

适用边界 · 注意事项

• 需要验证基础设施（Bicep/TF/azure.yaml）时，改用 azure-validate。
• 需要生成 IaC 时，改用 azure-prepare。
• 需要端到端从想法到生产、或要运行 azd up/部署时，改用 azure-app-onboard 或 azure-deploy。