microsoft/azure-app-onboard-prereq

Prérequis Azure App Onboard — Évaluation du dépôt

Évalue le dépôt d'un utilisateur pour la santé de la build, l'intégralité de l'application et la faisabilité du déploiement Azure — avant la planification de l'infrastructure. Produit des verdicts par composant (PASS/WARN/FAIL) consommés par les phases aval.

Relation avec l'orchestrateur : Appelé par azure-app-onboard à l'Étape 3, ou de manière autonome pour les vérifications d'état du code. Lorsqu'il est appelé par l'orchestrateur, retourner le contrôle à azure-app-onboard après l'écriture des artefacts — NE PAS invoquer les phases aval directement.

Phase 1 sur 4 du pipeline AppOnboard. Session : .copilot-azure/sessions/{session-id}/. Lit context.json. Écrit components[], repo{}, detectedInfra[]. Produit prereq-output.json. Schéma : prereq-schemas.ts — PrereqOutput, BuildRequirements. L'entrée directe est supportée.

Quand NE PAS Utiliser

Signal	Redirection
Valider l'infrastructure (Bicep/TF/azure.yaml)	azure-validate
Générer de l'IaC	azure-prepare
De l'idée à la production de bout en bout	azure-app-onboard
Exécuter azd up ou déployer	azure-deploy

Règles

⛔ INTERDICTION ABSOLUE — npm install, npm test, npx jest, pytest, et TOUTES les commandes d'installation/build/test ne sont JAMAIS autorisées. En AUCUN cas vous ne pouvez exécuter npm install, npm test, npx jest, pip install, pytest, dotnet build, dotnet restore, dotnet test, go mod download, cargo build, ou TOUTE commande d'installation par gestionnaire de paquets, de build ou de test pendant la phase de prérequis. N'exécutez PAS de suites de tests pour vérifier le code — vérifiez les fichiers de configuration de test de manière statique. La phase de prérequis est une évaluation en lecture seule + vérification statique uniquement. SEULE exception — deux contextes sanctionnés, tous deux avec consentement : (a) code que l'agent a modifié lors de la migration/réhabilitation (voir remediation-protocol.md étape 6), ou (b) code que l'agent a écrit à partir de zéro sur le chemin zéro-code (voir zero-code-path.md). Dans les deux cas, l'installation/build/test s'exécute UNIQUEMENT via la porte de validation de build confirmée par l'utilisateur (build-check.md Étape 3), après que l'utilisateur a répondu à cette invite de consentement spécifique par commande. Le consentement général préalable ne compte jamais.

1. ⛔ Pipeline complet (Étapes 1–8), sans exception. Toutes les invites → Étape 1 directement. Répondre aux questions spécifiques DANS LE CADRE des résultats (Étape 5), pas avant.
2. ⛔ Pas de sous-agents pour l'évaluation. L'évaluation sur 3 axes est en ligne. Exception : échafaudage du chemin zéro-code (Étape 2).
3. Les modifications destructives/de code nécessitent ask_user. Maximum 3 questions avant les résultats. Entrée directe : ne pas répéter les questions d'intention de l'orchestrateur.

Outils MCP

Outil	Objectif
mcp_azure_mcp_get_azure_bestpractices	Valider les modèles de stack détectés par rapport aux meilleures pratiques Azure
mcp_azure_mcp_extension_cli_install	Vérifier/installer les outils CLI requis (az, azd, func)

Workflow

Étape 1 : Vérification de Session

Entrée orchestrateur : La session existe — lire context.json, passer à l'Étape 2.

Entrée directe : Vérifier .copilot-azure/sessions/active-session.json :

• Existe → ⛔ lire session-protocol.md pour la porte reprise/nouvelle. Ne PAS continuer tant que l'utilisateur n'a pas répondu.
• Manquant → créer la session : générer UUID, New-Item -ItemType Directory -Path ".copilot-azure/sessions/{uuid}" -Force, écrire context.json + active-session.json via l'outil create.

Ensuite : az account show → fusionner {id, name, tenantId} dans context.json.azure. ⛔ La session DOIT exister sur le disque avant tout scan.

Étape 2 : Scanner l'Espace de Travail

Scanner les fichiers de projet. Détecter les composants, repo{}, detectedInfra[], detectedServices[]. Classifier les providers Terraform. Vérifier la disponibilité des CLI. Conflits de détection de stack : la déclaration explicite de l'utilisateur prévaut (écrire dans context.json, marquer le scan comme remplacement) ; scan uniquement → confirmer avec l'utilisateur ; plusieurs stacks → toutes les afficher et demander (voir component-mapping.md) ; pas de code → zero-code-path.md.

Si aucun fichier de projet, aucun Dockerfile, ET aucun index.html → ⛔ lire zero-code-path.md.

⛔ Porte anticipée SDK Cloud. Rechercher aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase. Si des dépendances fonctionnelles sont trouvées → lire cloud-sdk-migration.md, puis ask_user : "Rediriger vers Azure Cloud Migrate" (définir routeToSkill: "azure-cloud-migrate") · "Continuer l'évaluation quand même" (terminer l'évaluation de préparation + mapping SDK→Azure, puis ARRÊTER à l'Étape 8 — pas de plan tant que les dépendances ne sont pas remplacées) · "Annuler".

Étape 3 : Évaluation par Composant

Sous-étape	Action	Référence
3.1	Vérification de build	⛔ Vous DEVEZ lire build-check.md
3.2	Vérification d'intégralité	⛔ Vous DEVEZ lire completeness-check.md
3.3	Vérification de déployabilité	⛔ Vous DEVEZ lire deployability-check.md
3.3a	Mapping de composants (conditionnel)	Lire component-mapping.md UNIQUEMENT SI plus d'un manifeste de projet trouvé (monorepo)

Remplir buildRequirements par composant après évaluation. La propagation des verdicts, les règles de niveau et l'agrégation f1Viable sont dans readiness-gate.md et les références de vérification individuelles.

Étape 4 : Écrire les Artefacts + Porte de Préparation

⛔ Vérifier que context.json existe sur le disque. Lire readiness-gate.md (verdicts, niveaux, batch-puis-approuver, fast-track) puis prereq-artifacts.md (procédures d'écriture, schémas).

Étape 5 : Présenter les Résultats

Selon readiness-gate.md § Présenter les Résultats — afficher les verdicts groupés par sévérité avant de continuer.

Étape 6 : Réhabilitation (conditionnelle)

⛔ Vous DEVEZ lire remediation-protocol.md SI un verdict ❌ FAIL, une 🔧 Correction Recommandée, ou un ⚠️ WARN avec fixPhase: "prereq" existe. Contient la boucle de réhabilitation, la vérification statique, le mandat de réévaluation, les mises à jour d'artefacts post-réhabilitation et la porte de consentement de validation de build. Si tous les verdicts sont ✅ PASS ou ⚠️ WARN sans fixPhase: "prereq", passer à l'Étape 7.

Étape 7 : Écrire l'État Final

completedPhases contient déjà "prereq" + currentPhase: null (depuis l'Étape 4). Ensuite :

⛔ Écrire lastScanCommit. Exécuter git rev-parse HEAD et stocker le SHA complet de 40 caractères dans context.json.repo.lastScanCommit. Requis — la protection d'obsolescence à l'Étape 1 compare ceci à HEAD lors de la reprise pour détecter les changements.

Étape 8 : Routage

⛔ Obligatoire — ne PAS sauter cette étape.

Champs de routage : Tout routage écrit routeToSkill et routeReason dans context.json.

Contexte post-réhabilitation : Si l'Étape 6 a été exécutée, débuter l'invite de routage par : "Réhabilitation terminée — {N} problèmes corrigés, votre application est maintenant {santéGlobale}."