microsoft/azure-app-onboard-prereq

Azure App Onboard Prereq — Repository-Bewertung

Bewertet ein Repository im Hinblick auf Build-Health, Vollständigkeit der Anwendung und die Machbarkeit einer Azure-Bereitstellung – bevor mit der Infrastrukturplanung begonnen wird. Erzeugt komponentenbezogene Ergebnisse (PASS/WARN/FAIL), die von nachgelagerten Phasen verwendet werden.

Beziehung zum Orchestrator: Wird von azure-app-onboard in Schritt 3 aufgerufen oder eigenständig für Code-Readiness-Checks. Wenn vom Orchestrator aufgerufen, kehren Sie nach dem Schreiben der Artefakte zu azure-app-onboard zurück – führen Sie keine nachgelagerten Phasen direkt aus.

Phase 1 von 4 in der AppOnboard-Pipeline. Sitzung: .copilot-azure/sessions/{session-id}/. Liest context.json. Schreibt components[], repo{}, detectedInfra[]. Erzeugt prereq-output.json. Schema: prereq-schemas.ts — PrereqOutput, BuildRequirements. Direkter Einstieg wird unterstützt.

Wann NICHT zu verwenden ist

Signal	Weiterleitung
Infrastruktur validieren (Bicep/TF/azure.yaml)	azure-validate
IaC generieren	azure-prepare
Von der Idee bis zur Produktion (End-to-End)	azure-app-onboard
azd up ausführen oder bereitstellen	azure-deploy

Regeln

⛔ ABSOLUTES VERBOT – npm install, npm test, npx jest, pytest sowie ALLE Installations-, Build- und Testbefehle sind NIEMALS erlaubt. Auf KEINEN Fall dürfen Sie npm install, npm test, npx jest, pip install, pytest, dotnet build, dotnet restore, dotnet test, go mod download, cargo build oder IRGENDEINEN Paketmanager-Installations-, Build- oder Testbefehl während der Prereq-Phase ausführen. Führen Sie keine Test-Suiten aus, um den Code zu überprüfen – prüfen Sie stattdessen statisch auf Testkonfigurationsdateien. Die Prereq-Phase ist eine reine Lese-Bewertung + statische Überprüfung. EINZIGE Ausnahme – zwei genehmigte Kontexte, beide zustimmungsabhängig: (a) Code, den der Agent während der Migration/Remediation geändert hat (siehe remediation-protocol.md Schritt 6), oder (b) Code, den der Agent von Grund auf neu geschrieben hat (siehe zero-code-path.md). In beiden Fällen erfolgt die Installation/Build/Test-Ausführung NUR über das vom Benutzer bestätigte Build-Validierungs-Gate (build-check.md Schritt 3), nachdem der Benutzer die spezifische Zustimmungsaufforderung pro Befehl beantwortet hat. Eine allgemeine vorherige Zustimmung zählt nicht.

1. ⛔ Vollständige Pipeline (Schritte 1–8), keine Ausnahmen. Alle Eingabeaufforderungen → direkt zu Schritt 1. Beantworten Sie spezifische Fragen ALS TEIL der Ergebnisse (Schritt 5), nicht davor.
2. ⛔ Keine Unter-Agenten für die Bewertung. Die 3-Achsen-Bewertung erfolgt inline. Ausnahme: Zero-Code-Path-Gerüstbau (Schritt 2).
3. Code-/zerstörerische Änderungen erfordern ask_user. Maximal 3 Fragen vor den Ergebnissen. Direkter Einstieg: Wiederholen Sie nicht die Absichtsfragen des Orchestrators.

MCP-Tools

Tool	Zweck
mcp_azure_mcp_get_azure_bestpractices	Erkannte Stack-Muster anhand von Azure-Best Practices validieren
mcp_azure_mcp_extension_cli_install	Erforderliche CLI-Tools (az, azd, func) überprüfen/installieren

Arbeitsablauf

Schritt 1: Sitzungsprüfung

Orchestrator-Einstieg: Sitzung vorhanden – context.json lesen, mit Schritt 2 fortfahren.

Direkter Einstieg: .copilot-azure/sessions/active-session.json prüfen:

• Vorhanden → ⛔ session-protocol.md für Fortsetzungs-/Neuentscheidung lesen. Nicht fortfahren, bis der Benutzer antwortet.
• Fehlt → Sitzung erstellen: UUID generieren, New-Item -ItemType Directory -Path ".copilot-azure/sessions/{uuid}" -Force, context.json + active-session.json mit dem create-Tool schreiben.

Dann: az account show → {id, name, tenantId} in context.json.azure einfügen. ⛔ Die Sitzung MUSS vor dem Scannen auf der Festplatte vorhanden sein.

Schritt 2: Arbeitsbereich scannen

Scannen Sie nach Projektdateien. Erkennen Sie Komponenten, repo{}, detectedInfra[], detectedServices[]. Klassifizieren Sie Terraform-Provider. Überprüfen Sie die CLI-Verfügbarkeit. Stack-Erkennungskonflikte: Explizite Benutzerangabe gewinnt (in context.json schreiben, Scan als Überschreibung markieren); nur Scan → mit Benutzer bestätigen; mehrere Stacks → alle anzeigen und fragen (siehe component-mapping.md); kein Code → zero-code-path.md.

Wenn keine Projektdateien, kein Dockerfile UND kein index.html vorhanden sind → ⛔ zero-code-path.md lesen.

⛔ Cloud-SDK-Frühwarnung. Durchsuchen Sie das Repository nach aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase. Wenn funktionale Abhängigkeiten gefunden werden → cloud-sdk-migration.md lesen, dann ask_user: "Weiterleitung zu Azure Cloud Migrate" (routeToSkill: "azure-cloud-migrate" setzen) "Bewertung trotzdem fortsetzen" (Readiness-Bewertung abschließen + SDK→Azure-Mapping durchführen, dann bei Schritt 8 STOPPEN – kein Plan, bis die Abhängigkeiten ausgetauscht sind) "Abbrechen".

Schritt 3: Komponentenbasierte Bewertung

Unterschritt	Aktion	Referenz
3.1	Build-Prüfung	⛔ Sie MÜSSEN build-check.md lesen
3.2	Vollständigkeitsprüfung	⛔ Sie MÜSSEN completeness-check.md lesen
3.3	Bereitstellungsprüfung	⛔ Sie MÜSSEN deployability-check.md lesen
3.3a	Komponentenzuordnung (bedingt)	component-mapping.md NUR lesen, wenn >1 Projektmanifest gefunden (Monorepo)

Füllen Sie buildRequirements pro Komponente nach der Bewertung aus. Die Weitergabe von Ergebnissen, Stufenregeln und die f1Viable-Aggregation sind in readiness-gate.md und den einzelnen Prüfreferenzen beschrieben.

Schritt 4: Artefakte schreiben + Readiness-Gate

⛔ Überprüfen Sie, ob context.json auf der Festplatte vorhanden ist. Lesen Sie readiness-gate.md (Ergebnisse, Stufen, Batch-dann-Genehmigung, Fast-Track) dann prereq-artifacts.md (Schreibverfahren, Schemas).

Schritt 5: Ergebnisse präsentieren

Gemäß readiness-gate.md § Ergebnisse präsentieren – zeigen Sie die Ergebnisse, gruppiert nach Schweregrad, an, bevor Sie fortfahren.

Schritt 6: Behebung (bedingt)

⛔ Sie MÜSSEN remediation-protocol.md lesen, falls ein ❌ FEHLGESCHLAGEN-Ergebnis, eine 🔧 Empfohlene Korrektur oder ein ⚠️ WARN mit fixPhase: "prereq" vorhanden ist. Enthält die Remediation-Schleife, statische Überprüfung, erneute Bewertungsanforderung, Aktualisierung der Artefakte nach der Behebung und das Build-Validierungs-Gate. Wenn alle Ergebnisse ✅ BESTANDEN oder ⚠️ WARN ohne fixPhase: "prereq" sind, fahren Sie mit Schritt 7 fort.

Schritt 7: Endzustand schreiben

completedPhases enthält bereits "prereq" + currentPhase: null (aus Schritt 4). Dann:

⛔ lastScanCommit schreiben. Führen Sie git rev-parse HEAD aus und speichern Sie den vollständigen 40-stelligen SHA als context.json.repo.lastScanCommit. Erforderlich – die Staleness-Prüfung in Schritt 1 vergleicht dies beim Fortsetzen mit HEAD, um Änderungen zu erkennen.

Schritt 8: Weiterleitung

⛔ Zwingend – diesen Schritt nicht überspringen.

Weiterleitungsfelder: Alle Weiterleitungen schreiben routeToSkill und routeReason in context.json.

Kontext nach der Behebung: Wenn Schritt 6 ausgeführt wurde, leiten Sie die Weiterleitungsaufforderung ein mit: "Behebung abgeschlossen – {N} Probleme behoben, Ihre App ist jetzt {overallHealth}."