microsoft/azure-app-onboard-prereq

Azure App Onboard Prereq — Evaluación del Repositorio

Evalúa el repositorio de un usuario para determinar la salud de compilación, integridad de la aplicación y viabilidad de despliegue en Azure, antes de la planificación de infraestructura. Produce veredictos por componente (PASS/WARN/FAIL) que consumen fases posteriores.

Relación con el orquestador: Es invocada por azure-app-onboard en el Paso 3, o de forma independiente para verificaciones de preparación del código. Cuando la invoca el orquestador, debe devolver el control a azure-app-onboard después de escribir los artefactos — NO invocar fases posteriores directamente.

Fase 1 de 4 en el pipeline de AppOnboard. Sesión: .copilot-azure/sessions/{session-id}/. Lee context.json. Escribe components[], repo{}, detectedInfra[]. Produce prereq-output.json. Esquema: prereq-schemas.ts — PrereqOutput, BuildRequirements. Se admite entrada directa.

Cuándo NO Usar

Señal	Redirección
Validar infraestructura (Bicep/TF/azure.yaml)	azure-validate
Generar IaC	azure-prepare
De extremo a extremo (idea a producción)	azure-app-onboard
Ejecutar azd up o desplegar	azure-deploy

Reglas

⛔ PROHIBICIÓN ABSOLUTA — npm install, npm test, npx jest, pytest, y TODOS los comandos de instalación/compilación/prueba NUNCA están permitidos. Bajo NINGUNA circunstancia puede ejecutar npm install, npm test, npx jest, pip install, pytest, dotnet build, dotnet restore, dotnet test, go mod download, cargo build, o CUALQUIER comando de instalación, compilación o prueba del gestor de paquetes durante la fase de prerequisitos. NO ejecute suites de pruebas para verificar código — verifique archivos de configuración de pruebas de forma estática. La fase de prerequisitos es solo evaluación de solo lectura + verificación estática. ÚNICA excepción — dos contextos autorizados, ambos con consentimiento: (a) código que el agente modificó durante la migración/remediación (consulte remediation-protocol.md paso 6), o (b) código que el agente escribió desde cero en la ruta de código cero (consulte zero-code-path.md). En cualquier caso, la instalación/compilación/prueba se ejecuta SOLO a través de la puerta de validación de compilación confirmada por el usuario (build-check.md Paso 3), después de que el usuario responda a esa solicitud de consentimiento específica por comando. El consentimiento general previo nunca cuenta.

1. ⛔ Pipeline completo (Pasos 1–8), sin excepciones. Todas las indicaciones → Paso 1 directamente. Responda preguntas específicas COMO PARTE de los hallazgos (Paso 5), no antes.
2. ⛔ Sin subagentes para evaluación. La evaluación de 3 ejes es en línea. Excepción: andamiaje de ruta de código cero (Paso 2).
3. Las modificaciones de código/destructivas requieren ask_user. Máximo 3 preguntas antes de los resultados. Entrada directa: no repita las preguntas de intención del orquestador.

Herramientas MCP

Herramienta	Propósito
mcp_azure_mcp_get_azure_bestpractices	Validar los patrones de stack detectados contra las mejores prácticas de Azure
mcp_azure_mcp_extension_cli_install	Verificar/instalar las herramientas CLI necesarias (az, azd, func)

Flujo de Trabajo

Paso 1: Verificación de Sesión

Entrada del orquestador: La sesión existe — lea context.json, proceda al Paso 2.

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

• Existe → ⛔ lea session-protocol.md para la puerta de reanudación/nueva. NO continúe hasta que el usuario responda.
• Falta → cree sesión: genere UUID, New-Item -ItemType Directory -Path ".copilot-azure/sessions/{uuid}" -Force, escriba context.json + active-session.json mediante la herramienta create.

Luego: az account show → fusione {id, name, tenantId} en context.json.azure. ⛔ La sesión DEBE existir en disco antes de cualquier escaneo.

Paso 2: Escanear el Espacio de Trabajo

Escanee en busca de archivos de proyecto. Detecte componentes, repo{}, detectedInfra[], detectedServices[]. Clasifique proveedores de Terraform. Verifique la disponibilidad de CLI. Conflictos de detección de stack: la declaración explícita del usuario gana (escriba en context.json, marque el escaneo como anulación); solo escaneo → confirme con el usuario; múltiples stacks → muestre todos y pregunte (consulte component-mapping.md); sin código → zero-code-path.md.

Si no hay archivos de proyecto, ni Dockerfile, ni index.html → ⛔ lea zero-code-path.md.

⛔ Puerta de acceso temprana para SDKs de nube. Busque aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase. Si se encuentran dependencias funcionales → lea cloud-sdk-migration.md, luego ask_user: "Redirigir a Azure Cloud Migrate" (establezca routeToSkill: "azure-cloud-migrate") · "Continuar evaluación de todos modos" (finalice la evaluación de preparación + mapeo SDK→Azure, luego DETÉNGASE en el Paso 8 — sin plan hasta que se intercambien las dependencias) · "Cancelar".

Paso 3: Evaluación por Componente

Subpaso	Acción	Referencia
3.1	Verificación de compilación	⛔ DEBE leer build-check.md
3.2	Verificación de integridad	⛔ DEBE leer completeness-check.md
3.3	Verificación de capacidad de despliegue	⛔ DEBE leer deployability-check.md
3.3a	Mapeo de componentes (condicional)	Lea component-mapping.md SOLO SI se encuentra >1 manifiesto de proyecto (monorepo)

Complete buildRequirements por componente después de la evaluación. La propagación de veredictos, las reglas de nivel y la agregación de f1Viable están en readiness-gate.md y las referencias de verificación individuales.

Paso 4: Escribir Artefactos + Puerta de Preparación

⛔ Verifique que context.json exista en disco. Lea readiness-gate.md (veredictos, niveles, lote-y-aprobar, vía rápida) luego prereq-artifacts.md (procedimientos de escritura, esquemas).

Paso 5: Presentar Hallazgos

Según readiness-gate.md § Presentar Hallazgos — muestre los veredictos agrupados por gravedad antes de continuar.

Paso 6: Remedición (condicional)

⛔ DEBE leer remediation-protocol.md SI existe algún veredicto ❌ FAIL, 🔧 Corrección Recomendada, o ⚠️ WARN con fixPhase: "prereq". Contiene el bucle de remediación, verificación estática, mandato de reevaluación, actualizaciones de artefactos posteriores a la remediación y la puerta de consentimiento de validación de compilación. Si todos los veredictos son ✅ PASS o ⚠️ WARN sin fixPhase: "prereq", salte al Paso 7.

Paso 7: Escribir Estado Final

completedPhases ya tiene "prereq" + currentPhase: null (del Paso 4). Luego:

⛔ Escriba lastScanCommit. Ejecute git rev-parse HEAD y almacene el SHA completo de 40 caracteres como context.json.repo.lastScanCommit. Obligatorio: el guardián de obsolescencia en el Paso 1 lo compara con HEAD al reanudar para detectar cambios.

Paso 8: Enrutar

⛔ Obligatorio — no omita este paso.

Campos de enrutamiento: Todo enrutamiento escribe routeToSkill y routeReason en context.json.

Contexto posterior a la remediación: Si se ejecutó el Paso 6, inicie la indicación de enrutamiento con: "Remediación completa — {N} problemas corregidos, su aplicación ahora está {overallHealth}."