ChandraChaan/release-check

Was macht release-check?

Du hilfst einem Flutter-Entwickler, einen Release zu veröffentlichen, der nicht von Google Play oder dem App Store abgelehnt wird. Sei konkret: Nenne die Datei und die genaue Änderung für jedes Problem.

Schritt 1: Führe den deterministischen Preflight aus

Führe im Stammverzeichnis des Flutter-Projekts Folgendes aus:

bash "${CLAUDE_PLUGIN_ROOT}/scripts/preflight.sh" $ARGUMENTS

Das Skript gibt OK-/WARN-/FEHLER-Zeilen aus, gruppiert nach Abschnitten (Version, Changelog, Statische Analyse, Tests, Debug-Überreste, Android, iOS) und beendet sich mit Exit-Code 1 bei jedem FEHLER. Es kann eine Minute dauern, wenn Tests laufen. Wenn der Benutzer sich offensichtlich mitten in der Entwicklung befindet und nur einen schnellen Überblick möchte, übergib --skip-tests.

Schritt 2: Untersuche jeden FEHLER und jede WARNUNG

Öffne für jeden Punkt die Datei, die das Skript nennt, und bestätige den Befund, bevor du ihn meldest. Häufige Korrekturen:

Befund	Korrektur
Version hat keine Build-Nummer	Ändere version: 1.2.0 zu version: 1.2.0+1 in pubspec.yaml.
Tag existiert bereits für diese Version	Führe den Skill bump-version aus.
com.example applicationId oder bundle id	Verwende flutter pub run change_app_package_name:main com.yourco.app oder bearbeite android/app/build.gradle(.kts) und die drei Einträge PRODUCT_BUNDLE_IDENTIFIER in ios/Runner.xcodeproj/project.pbxproj.
Release wird mit Debug-Schlüssel signiert	Füge das Laden von key.properties und ein release-signingConfig hinzu; siehe references/android-signing.md.
key.properties oder *.jks wird von git verfolgt	Füge zu .gitignore hinzu, dann git rm --cached <datei>; ändere das Keystore-Passwort, wenn das Repository öffentlich ist.
Keine PrivacyInfo.xcprivacy	Erstelle ios/Runner/PrivacyInfo.xcprivacy; Vorlage in references/privacy-manifest.md.
debuggable=true, Klartext-Traffic, localhost-URLs	Entferne vor der Veröffentlichung.
Analysefehler / fehlgeschlagene Tests	Behebe sie; schlage nicht vor, sie zu überspringen.

Schritt 3: Überprüfe Dinge, die das Skript nicht kann

Sieh dir das Projekt an und bedenke:

• Ziel-SDK: Google Play verlangt für neue Apps und Updates eine aktuelle Android-API-Stufe (die rollierende Anforderung von Play ist etwa die Veröffentlichung des Vorjahres). Überprüfe targetSdk in android/app/build.gradle(.kts) oder den Flutter-Standard.
• App-Symbol und Splash: Das Standard-Flutter-Symbol führt zu einer Ablehnung im Review und zu sofortigen Deinstallationen durch Benutzer. Überprüfe die Konfiguration von flutter_launcher_icons / flutter_native_splash oder die mipmap-Ordner.
• Berechtigungen: Wenn das Manifest mehr als INTERNET enthält, schlage vor, den Skill permission-audit auszuführen.
• Store-Assets: Feature-Grafik 1024x500 (Play), Screenshots für jede erforderliche Geräteklasse, Datenschutzrichtlinien-URL (erforderlich, wenn die App Daten sammelt oder sensible Berechtigungen anfordert).
• Konto-Löschung: Beide Stores verlangen einen integrierten Konto-Löschpfad, wenn die App die Kontoerstellung unterstützt.
• Anmeldung für Prüfer: Wenn es einen Anmeldebildschirm gibt, erinnere den Benutzer daran, in den Review-Notizen ein Demo-Konto bereitzustellen.

Lies references/store-rejections.md für die vollständige Liste der häufigsten Ablehnungsgründe und deren Korrekturen, wenn der Benutzer fragt, warum seine App abgelehnt wurde, oder eine tiefere Überprüfung wünscht.

Schritt 4: Bericht erstatten

Gib einen kurzen Bericht zurück:

1. Urteil: BEREIT / NICHT BEREIT.
2. Muss korrigiert werden (FEHLER-Punkte, jeweils mit Datei und genauer Änderung).
3. Sollte korrigiert werden (WARN-Punkte, die für diese App relevant sind).
4. Nächste Befehle: normalerweise flutter build appbundle --release und flutter build ipa --release, gefolgt von bump-version und changelog, wenn die Version bereits ausgeliefert wurde.

Halte es knapp. Wiederhole keine OK-Zeilen, es sei denn, der Benutzer fragt nach der vollständigen Ausgabe.