azure-app-onboard-prereq
热门评估源代码是否准备好部署到 Azure — 在基础设施工作之前的检查。评估构建健康度、应用完整性、依赖项和本地服务、技术栈兼容性以及部署可行性。回答关于你的应用在部署前需要什么的问题 — 框架、依赖项和配置。检查依赖项是否兼容，并识别部署阻塞因素和不支持的框架。触发时机："评估我的仓库"、"我的应用准备好部署了吗"、"我的应用部署需要什么"、"部署前我需要什么"、"我的应用需要"、"我能把这个部署到 Azure 吗"、"扫描我的仓库查找问题"、"这个应用可部署吗"、"检查我的应用是否准备好部署到 Azure"、"我需要 Dockerfile 吗"、"什么阻碍了我的部署"、"有阻塞因素吗"、"我的依赖项兼容吗"、"Azure 支持我的框架吗"、"部署前需要更改什么"、"检查我的应用配置"。
评估源代码是否准备好部署到 Azure — 在基础设施工作之前的检查。评估构建健康度、应用完整性、依赖项和本地服务、技术栈兼容性以及部署可行性。回答关于你的应用在部署前需要什么的问题 — 框架、依赖项和配置。检查依赖项是否兼容，并识别部署阻塞因素和不支持的框架。触发时机：\"评估我的仓库\"、\"我的应用准备好部署了吗\"、\"我的应用部署需要什么\"、\"部署前我需要什么\"、\"我的应用需要\"、\"我能把这个部署到 Azure 吗\"、\"扫描我的仓库查找问题\"、\"这个应用可部署吗\"、\"检查我的应用是否准备好部署到 Azure\"、\"我需要 Dockerfile 吗\"、\"什么阻碍了我的部署\"、\"有阻塞因素吗\"、\"我的依赖项兼容吗\"、\"Azure 支持我的框架吗\"、\"部署前需要更改什么\"、\"检查我的应用配置\"。
Azure App Onboard Prereq — 仓库评估
在基础设施规划之前，评估用户仓库的构建健康度、应用完整性和 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以及所有安装/构建/测试命令。
在任何情况下，你都不能在 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 步）中回答具体问题，而不是之前。
- ⛔ 评估不使用子代理。 三轴评估内联进行。例外： 零代码路径脚手架（第 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} 状态。"
⛔ 从上到下评估行 — 第一个匹配获胜。
| # | 条件 | 操作 |
|---|---|---|
| 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 | 直接 + 就绪/有注意事项就绪 + 无 Azure 基础设施 | ask_user："部署到 Azure（完整管道）" → 调用 azure-app-onboard / "现在不" |
| 5 | 直接 + 就绪/有注意事项就绪 + 现有 Azure 基础设施 | ask_user："重新开始" → 调用 azure-app-onboard / "使用现有基础设施" → 调用 azure-prepare / "现在不" |
| 6 | 直接 + 阻塞 | 报告阻塞摘要 + "修复并重新运行。" |
严重性层级（🛑🔶❌🔧⚠️✅）在 readiness-gate.md 中定义。
输出
| 产物 | 位置 | 消费者 |
|---|---|---|
| 会话上下文 | context.json → components[]、repo{}、detectedInfra[]、detectedServices[] |
所有下游阶段 |
| Prereq 输出 | prereq-output.json |
准备阶段（通过 azure-app-onboard） |
| 就绪报告 | .copilot-azure/sessions/{uuid}/readiness-report.md |
用户（离线参考） |
