microsoft/azure-app-onboard-prereq

Azure App Onboard Pré-requisito — Avaliação de Repositório

Avalia um repositório do usuário quanto à saúde da build, integridade do aplicativo e viabilidade de implantação no Azure — antes do planejamento de infraestrutura. Produz vereditos por componente (PASS/WARN/FAIL) consumidos por fases posteriores.

Relação com o orquestrador: Chamado por azure-app-onboard na Etapa 3, ou de forma independente para verificações de prontidão de código. Quando chamado pelo orquestrador, retorne o controle ao azure-app-onboard após escrever os artefatos — NÃO invoque fases posteriores diretamente.

Fase 1 de 4 no pipeline AppOnboard. Sessão: .copilot-azure/sessions/{session-id}/. Lê context.json. Escreve components[], repo{}, detectedInfra[]. Produz prereq-output.json. Esquema: prereq-schemas.ts — PrereqOutput, BuildRequirements. Entrada direta suportada.

Quando NÃO Usar

Sinal	Redirecionamento
Validar infraestrutura (Bicep/TF/azure.yaml)	azure-validate
Gerar IaC	azure-prepare
Ideia até produção completa	azure-app-onboard
Executar azd up ou implantar	azure-deploy

Regras

⛔ PROIBIÇÃO ABSOLUTA — npm install, npm test, npx jest, pytest e TODOS os comandos de instalação, build e teste NUNCA são permitidos. Em NENHUMA circunstância você pode executar npm install, npm test, npx jest, pip install, pytest, dotnet build, dotnet restore, dotnet test, go mod download, cargo build ou QUALQUER comando de instalação de gerenciador de pacotes, build ou teste durante a fase de pré-requisito. NÃO execute suítes de teste para verificar código — verifique arquivos de configuração de teste estaticamente. A fase de pré-requisito é uma avaliação somente leitura + verificação estática. ÚNICA exceção — dois contextos autorizados, ambos com consentimento: (a) código que o agente modificou durante migração/remediação (veja remediation-protocol.md etapa 6), ou (b) código que o agente escreveu do zero no caminho zero-code (veja zero-code-path.md). Em ambos os casos, a execução de instalação/build/teste ocorre APENAS através do portão de consentimento de validação de build confirmado pelo usuário (build-check.md Etapa 3), após o usuário responder ao prompt de consentimento específico por comando. Consentimento geral prévio nunca conta.

1. ⛔ Pipeline completo (Etapas 1–8), sem exceções. Todos os prompts → Etapa 1 diretamente. Responda perguntas específicas COMO PARTE dos resultados (Etapa 5), não antes.
2. ⛔ Sem subagentes para avaliação. A avaliação de 3 eixos é inline. Exceção: scaffolding do zero-code-path (Etapa 2).
3. Modificações de código/destrutivas requerem ask_user. Máximo 3 perguntas antes dos resultados. Entrada direta: não repita as perguntas de intenção do orquestrador.

Ferramentas MCP

Ferramenta	Propósito
mcp_azure_mcp_get_azure_bestpractices	Validar padrões de stack detectados contra as melhores práticas do Azure
mcp_azure_mcp_extension_cli_install	Verificar/instalar ferramentas CLI necessárias (az, azd, func)

Fluxo de Trabalho

Etapa 1: Verificação de Sessão

Entrada do orquestrador: Sessão existe — leia context.json, prossiga para a Etapa 2.

Entrada direta: Verifique .copilot-azure/sessions/active-session.json:

• Existe → ⛔ leia session-protocol.md para o portão resume/fresh. NÃO prossiga até o usuário responder.
• Ausente → crie sessão: gere UUID, New-Item -ItemType Directory -Path ".copilot-azure/sessions/{uuid}" -Force, escreva context.json + active-session.json via ferramenta create.

Em seguida: az account show → mescle {id, name, tenantId} em context.json.azure. ⛔ A sessão DEVE existir em disco antes de qualquer varredura.

Etapa 2: Varrer Workspace

Varra por arquivos de projeto. Detecte componentes, repo{}, detectedInfra[], detectedServices[]. Classifique provedores Terraform. Verifique disponibilidade de CLI. Conflitos de detecção de stack: a declaração explícita do usuário vence (escreva em context.json, marque a varredura como sobrescrita); apenas varredura → confirme com o usuário; múltiplas stacks → mostre todas e pergunte (veja component-mapping.md); nenhum código → zero-code-path.md.

Se não houver arquivos de projeto, nem Dockerfile E nem index.html → ⛔ leia zero-code-path.md.

⛔ Portão inicial de Cloud SDK. Procure por aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase. Se dependências funcionais forem encontradas → leia cloud-sdk-migration.md, depois ask_user: "Redirecionar para Azure Cloud Migrate" (defina routeToSkill: "azure-cloud-migrate") · "Continuar avaliação mesmo assim" (finalize a avaliação de prontidão + mapeamento SDK→Azure, então PARE na Etapa 8 — sem plano até que as dependências sejam trocadas) · "Cancelar".

Etapa 3: Avaliação por Componente

Sub-etapa	Ação	Referência
3.1	Verificação da build	⛔ Você DEVE ler build-check.md
3.2	Verificação de integridade	⛔ Você DEVE ler completeness-check.md
3.3	Verificação de implantabilidade	⛔ Você DEVE ler deployability-check.md
3.3a	Mapeamento de componentes (condicional)	Leia component-mapping.md SOMENTE SE >1 manifesto de projeto encontrado (monorepo)

Popule buildRequirements por componente após a avaliação. A propagação de vereditos, regras de tier e agregação f1Viable estão em readiness-gate.md e nas referências das verificações individuais.

Etapa 4: Escrever Artefatos + Portão de Prontidão

⛔ Verifique se context.json existe em disco. Leia readiness-gate.md (vereditos, tiers, batch-then-approve, fast-track) depois prereq-artifacts.md (procedimentos de escrita, esquemas).

Etapa 5: Apresentar Resultados

Conforme readiness-gate.md § Apresentar Resultados — mostre os vereditos agrupados por severidade antes de prosseguir.

Etapa 6: Remediação (condicional)

⛔ Você DEVE ler remediation-protocol.md SE houver algum veredito ❌ FAIL, 🔧 Correção Recomendada ou ⚠️ WARN com fixPhase: "prereq". Contém loop de remediação, verificação estática, mandato de reavaliação, atualizações de artefatos pós-remediação e o portão de consentimento de validação de build. Se todos os vereditos forem ✅ PASS ou ⚠️ WARN sem fixPhase: "prereq", pule para a Etapa 7.

Etapa 7: Escrever Estado Final

completedPhases já tem "prereq" + currentPhase: null (da Etapa 4). Em seguida:

⛔ Escreva lastScanCommit. Execute git rev-parse HEAD e armazene o SHA completo de 40 caracteres como context.json.repo.lastScanCommit. Obrigatório — proteção contra obsolescência na Etapa 1 compara com HEAD ao retomar para detectar alterações.

Etapa 8: Roteamento

⛔ Obrigatório — não pule esta etapa.

Campos de roteamento: Todo roteamento escreve routeToSkill e routeReason em context.json.

Contexto pós-remediação: Se a Etapa 6 foi executada, inicie o prompt de roteamento com: "Remediação concluída — {N} problemas corrigidos, seu aplicativo agora está {overallHealth}."