Azure 应用载入前提条件 — 仓库评估
评估用户的仓库的构建健康度、应用完整性和 Azure 部署可行性 — 在基础设施规划之前。生成供下游阶段使用的每个组件判定结果（通过/警告/失败）。
协调器关系： 由
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) 代理在迁移/补救期间修改的代码（请参见 remediation-protocol.md 第 6 步），或 (b) 代理在零代码路径上从头编写的代码（请参见 zero-code-path.md）。在这两种情况下，安装/构建/测试仅在用户确认的构建验证门（build-check.md 第 3 步）之后运行，并在用户回答该特定逐命令的同意提示之后。一般预先同意永远不算。
- ⛔ 完整流水线（第 1-8 步），无例外。 所有提示 → 直接进入第 1 步。作为调查结果的一部分（第 5 步）回答具体问题，而不是在此之前。
- ⛔ 评估不使用子代理。 三轴评估为内联。例外： 零代码路径搭建（第 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 步：补救（有条件）
⛔ 如果存在任何 ❌ 失败判定、🔧 建议修复或 ⚠️ 带有 fixPhase: "prereq" 的警告，则必须阅读 remediation-protocol.md。包含补救循环、静态验证、重新评估命令、补救后的工件更新以及构建验证同意门。如果所有判定均为 ✅ 通过或 ⚠️ 警告且无 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}。”