Azure App Onboard Prereq — Évaluation du référentiel

Évaluez le référentiel d'un utilisateur pour la santé de la compilation, l'exhaustivité 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 suivantes.

Relation orchestrateur : Appelé par azure-app-onboard à l'étape 3, ou autonome pour les vérifications de disponibilité du code. Appelé par l'orchestrateur, restituez le contrôle à azure-app-onboard après l'écriture des artefacts — N'INVOQUEZ PAS directement les phases suivantes.

Phase 1 sur 4 dans le 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. Entrée directe supportée.

Quand ne pas utiliser

Règles

⛔ PROHIBITION ABSOLUE — npm install, npm test, npx jest, pytest, et TOUTES les commandes install/build/test sont JAMAIS autorisées. En AUCUN cas vous ne devez exécuter npm install, npm test, npx jest, pip install, pytest, dotnet build, dotnet restore, dotnet test, go mod download, cargo build, ou AUCUNE commande de gestionnaire de paquets, compilation ou test pendant la phase prereq. Ne testez PAS les suites de tests pour vérifier le code — vérifiez plutôt les fichiers de configuration de test statiquement. La phase prereq est une évaluation en lecture seule + vérification statique uniquement. SEULE exception — deux contextes autorisés, tous deux contrôlés par consentement : (a) code que l'agent a modifié lors de la migration/correction (voir remediation-protocol.md étape 6), ou (b) code que l'agent a écrit de zéro sur le chemin zero-code (voir zero-code-path.md). Dans l'un ou l'autre cas, les exécutions install/build/test se font UNIQUEMENT via la porte de validation de compilation confirmée par l'utilisateur (build-check.md étape 3), après que l'utilisateur répond à cette invite spécifique de consentement par commande. Le consentement préalable général ne compte jamais.

1. ⛔ Pipeline complet (étapes 1–8), sans exceptions. Tous les prompts → étape 1 directement. Répondez aux questions spécifiques EN TANT QUE PARTIE des conclusions (étape 5), pas avant.
2. ⛔ Pas de sous-agents pour l'évaluation. L'évaluation 3 axes est inline. Exception : scaffolding zero-code-path (étape 2).
3. Les modifications de code/destructrices nécessitent ask_user. Max 3 questions avant les résultats. Entrée directe : ne répétez pas les questions d'intention de l'orchestrateur.

Outils MCP

Workflow

Étape 1 : Vérification de la session

Entrée orchestrateur : Session existe — lire context.json, procéder à l'étape 2.

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

• Existe → ⛔ lire session-protocol.md pour la porte de reprise/nouvelle. Ne procédez PAS jusqu'à ce que l'utilisateur réponde.
• Manquant → créer 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.

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

Étape 2 : Scan de l'espace de travail

Scannez les fichiers de projet. Détectez les composants, repo{}, detectedInfra[], detectedServices[]. Classifiez les fournisseurs Terraform. Vérifiez la disponibilité de l'interface CLI. Conflits de détection de pile : la déclaration explicite de l'utilisateur gagne (écrire dans context.json, marquer le scan comme remplacé) ; scan uniquement → confirmer avec l'utilisateur ; piles multiples → afficher tous et demander (voir component-mapping.md) ; pas de code → zero-code-path.md.

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

⛔ Porte anticipée du SDK cloud. Grep pour aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase. Si deps fonctionnelles trouvées → lire cloud-sdk-migration.md, puis ask_user : "Redirection vers Azure Cloud Migrate" (définir routeToSkill: "azure-cloud-migrate") · "Continuer l'évaluation de toute façon" (terminer l'évaluation de disponibilité + mappage SDK→Azure, puis ARRÊTER à l'étape 8 — pas de plan jusqu'à ce que les deps soient échangées) · "Annuler".

Étape 3 : Évaluation par composant

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

Étape 4 : Écrire les artefacts + Porte de disponibilité

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

Étape 5 : Présenter les conclusions

Selon readiness-gate.md § Present Findings — montrer les verdicts regroupés par sévérité avant de procéder.

Étape 6 : Correction (conditionnel)

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

Étape 7 : Écrire l'état final

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

⛔ Écrire lastScanCommit. Exécuter git rev-parse HEAD et stocker le SHA complet de 40 caractères en tant que context.json.repo.lastScanCommit. Obligatoire — la garde de fraîcheur à l'étape 1 compare à HEAD à la reprise pour détecter les changements.

Étape 8 : Route

⛔ Obligatoire — ne sautez PAS cette étape.

Champs de routage : Tous les écritures de routage écrivent routeToSkill et routeReason dans context.json.

Contexte post-correction : Si l'étape 6 s'est exécutée, lancez le prompt de routage avec : « Correction complète — {N} problèmes résolus, votre application est maintenant {overallHealth}. »

⛔ Évaluez les lignes de haut en bas — le premier match gagne.

Les tiers de sévérité (🛑🔶❌🔧⚠️✅) sont définis dans readiness-gate.md.

Sorties