Bekannte Fehlerbilder mit Ursache und Ausweg, Reparatur per Klick, automatische Änderungsvorschläge als Diff und die optionale KI-Reparatur mit Claude.

Scheitert ein Build, steht die Ursache meist irgendwo im Log, nur selten an einer Stelle, die man auf Anhieb findet. Die Build Station liest das Log für dich mit. Erkennt sie ein bekanntes Fehlerbild, erscheint direkt über dem Log ein Streifen mit Ursache, Ausweg und, wo möglich, einem Knopf.

Warning: CocoaPods is installed but broken. Skipping pod install.
CocoaPods not installed or not in valid state.

wird so zu: „CocoaPods ist installiert, aber nicht lauffähig”, darunter der Befehl brew install cocoapods und der Knopf Beheben.

Bekannte Fehlerbilder

Fehlerbild	Weg heraus
CocoaPods kaputt oder fehlt	`brew install cocoapods`
`Podfile.lock` passt nicht zum installierten Stand	`pod install`, notfalls Pods neu aufbauen
veralteter CocoaPods-Index	`pod repo update && pod install`
festgelegte Flutter-Version fehlt in fvm	`fvm install`
fvm nicht auffindbar	`brew install fvm` bzw. Hinweis zum PATH
Gradle-Daemon weggebrochen	`./gradlew --stop`
Platte voll	öffnet den Aufräum-Dialog
Xcode kann nicht signieren	öffnet `Runner.xcworkspace` in Xcode
Abhängigkeiten lassen sich nicht auflösen	`pub upgrade`
Build-Nummer gibt es im Store schon	Erklärung: Nummer erhöhen
Android-Keystore fehlt	Erklärung
Store nimmt die Zugangsdaten nicht an	öffnet die Upload-Einrichtung
JDK passt nicht zu Gradle (`Unsupported class file major version …`)	öffnet den Versions-Check
Gradle zu alt für das Android-Gradle-Plugin	öffnet den Versions-Check
alte `fvm_config.json` widerspricht `.fvmrc`	öffnet den Versions-Check

Je nach Fehlerbild heißen die Knöpfe Beheben, Terminal öffnen, Zwischenergebnisse leeren …, Upload-Einrichtung prüfen … oder Versionen prüfen …. Gibt es mehrere Auswege, stehen die übrigen unter Andere Wege. Nach einer Reparatur führt Erneut bauen direkt zum nächsten Versuch.

Drei Dinge sind dabei Absicht:

Die auslösende Log-Zeile steht dabei. Eine Diagnose ohne Beleg wäre nur eine Behauptung.
sudo führt die Station nie aus. Ein Passwort-Prompt lässt sich aus einer App heraus nicht sinnvoll bedienen. Solche Wege werden angezeigt, nicht gestartet, mit einem Knopf, der ein Terminal im Projekt öffnet.
Reparaturen laufen über die Warteschlange. Ein pod install mitten in einem laufenden Build wäre so schädlich wie ein rm -rf build. Vor dem Ausführen fragt die Station mit den Befehlen nach.

Der Katalog ist bewusst vorsichtig: lieber kein Vorschlag als ein falscher.

Automatische Reparatur

Manche Fehler lassen sich nur durch eine Änderung im Projekt beheben, etwa an einer Gradle-Datei oder an der pubspec.yaml. Für diese zeigt der Streifen einen fertigen Vorschlag als Diff, also Zeile für Zeile, was sich ändern würde.

Fehlerbild	Vorschlag
`Language version 1.6 is no longer supported` (z. B. bei `sentry_flutter` 8.x)	Plugin auf die erste Hauptversion heben, die das Problem behebt. Notlösung: Sprachversion in `android/build.gradle` erzwingen
`:plugin is currently compiled against android-31`	Plugin heben. Notlösung: `compileSdk` aller Plugins anheben
Deployment-Target von macOS oder iOS unter dem Minimum	Podfile und `project.pbxproj` auf das Minimum, danach `pod install`
Kotlin-Version unter dem Minimum von Flutter	`kotlin`-Version in `settings.gradle` anheben
App wendet das Kotlin Gradle Plugin selbst an, Plugins bringen ein eigenes mit	Zeile entfernen bzw. Plugins auf Versionen ohne eigenes KGP heben
eingestelltes Paket, z. B. `flutter_markdown`	durch den Nachfolger ersetzen, Importe inklusive

Ob eine neuere Plugin-Version den Fehler wirklich behebt, prüft die Station nicht an der Versionsnummer. Sie liest die android/build.gradle der Kandidaten direkt aus dem Archiv auf pub.dev. Hängt die neue Version an einer anderen Hauptversion einer direkten Abhängigkeit, etwa sentry zu sentry_flutter, wird die mit angehoben.

Geschrieben wird erst auf Knopfdruck:

Anwenden und neu bauen ändert die Dateien und reiht gleich einen neuen Build ein.
Nur anwenden ändert die Dateien und wartet.

Vorher bleibt jede Datei unangetastet. Jede Anwendung legt eine Sicherung an. Zurücknehmen stellt die Dateien wieder her, solange du sie seitdem nicht weiter bearbeitet hast. Committet wird nie.

Steht nach einer Reparatur derselbe Fehler wieder im Log, sagt der Streifen das und bietet Zurücknehmen an.

Unter Vorwarnungen stehen eingeklappt Dinge, an denen der Build noch nicht scheitert, aber bald scheitern wird.

KI-Reparatur mit Claude

Passt keine Regel, kann Claude den Fehler untersuchen. Das Ergebnis ist ein Vorschlag wie bei den Regeln, mit Diff. Nichts wird automatisch geschrieben.

Einrichten

Leg in der Claude Console unter console.anthropic.com einen API-Schlüssel an.
Trag ihn in der Station unter Einstellungen › KI-Reparatur ins Feld Neuer API-Schlüssel (sk-ant-…) ein und klick Im Schlüsselbund speichern.
Verbindung testen prüft den Schlüssel.

Der Schlüssel liegt im macOS-Schlüsselbund, nie in einer Konfigurationsdatei. Ist die Umgebungsvariable ANTHROPIC_API_KEY gesetzt, hat sie Vorrang.

Im selben Abschnitt stellst du ein:

Einstellung	Vorgabe
Modell	Claude Opus (gründlichste Analyse), alternativ Sonnet (halber Preis) oder Haiku (am günstigsten)
Tageslimit (US-$)	5 $
KI-Runden pro Fehler	3

So läuft eine Analyse

Unter dem Streifen eines gescheiterten Builds steht Mit Claude analysieren. Die KI startet nie von selbst, nur über diesen Knopf und nach einer Rückfrage, die zeigt, was heute schon ausgegeben wurde.

Nach so vielen KI-Runden am selben Projekt, wie unter KI-Runden pro Fehler eingestellt, ohne erfolgreichen Build ist Schluss. Dann geht es von Hand weiter.

Führt eine KI-Reparatur zu einem erfolgreichen Build, bietet die Station an, sie als Regel zu speichern. Beim nächsten gleichen Fehler greift dann die Regel, ohne KI und ohne Kosten.

Was gesendet wird und was nie

An Anthropic gehen:

ein Auszug aus dem Build-Log
die Build-Dateien des Projekts, etwa Gradle-Dateien, Podfile und pubspec.yaml
auf Nachfrage der KI einzelne Dateien aus dem Projekt und dem Paket-Cache

Nie gesendet werden Dateien mit Zugangsdaten, darunter key.properties, local.properties, .env-Dateien, Keystores, .p8, .p12, Zertifikate und Provisioning-Profile, google-services.json, GoogleService-Info.plist und Service-Account-Dateien. Zeilen mit Passwörtern und Tokens werden vor dem Senden geschwärzt.

Kosten

Die KI-Reparatur nutzt deinen eigenen API-Schlüssel, die Kosten laufen über dein Anthropic-Konto. Eine Analyse kostet je nach Fehler meist einige Cent. Nach jeder Analyse zeigt die Station, was sie gekostet hat. Ist das Tageslimit erreicht, startet keine weitere Analyse mehr.

Derselbe Schlüssel kann beim Upload Release Notes aus den Commit-Betreffzeilen vorschlagen. Dabei gehen nur diese Zeilen an Anthropic, kein Code. Siehe Artefakte und Upload.

Pakete vorab prüfen

Viele dieser Fehler kündigen sich an. Im Dialog Versionen im Tab Build zeigt Pakete prüfen (flutter pub outdated) eingestellte Pakete, Plugins mit eigenem Kotlin Gradle Plugin und neue Hauptversionen der direkten Abhängigkeiten, mit denselben Vorschlägen, bevor ein Build daran scheitert. Mehr dazu unter Versionen und Updates.

Wenn nichts davon hilft

Prüf unter Einstellungen › Toolchain, ob alle Werkzeuge gefunden werden.
Stopp unter Einstellungen › Wartung hängende Gradle-Daemons.
Probier einen Clean Build.
Kopier den Befehl aus dem Tab Build und führ ihn im Terminal aus. Was dort scheitert, scheitert nicht an der Station.

Weitere Fälle stehen unter Fehlerbehebung.

Wenn ein Build scheitert