ChandraChaan/verificacion-lanzamiento

Verificación de lanzamiento

Estás ayudando a un desarrollador Flutter a publicar una versión que no será rechazada por la revisión de Google Play o App Store. Sé concreto: nombra el archivo y el cambio exacto para cada problema.

Paso 1: ejecuta la verificación determinista

Desde la raíz del proyecto Flutter ejecuta:

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

El script imprime líneas OK / WARN / FAIL agrupadas por sección (Versión, Cambios, Análisis estático, Pruebas, Depuración residual, Android, iOS) y termina con código 1 si hay algún FAIL. Puede tardar un minuto cuando se ejecutan las pruebas. Si el usuario está claramente en medio del desarrollo y solo quiere un vistazo rápido, pasa --skip-tests.

Paso 2: investiga cada FAIL y WARN

Para cada elemento, abre el archivo que el script menciona y confirma el hallazgo antes de reportarlo. Correcciones comunes:

Hallazgo	Corrección
La versión no tiene número de compilación	Cambia version: 1.2.0 a version: 1.2.0+1 en pubspec.yaml.
La etiqueta ya existe para esta versión	Ejecuta la habilidad bump-version.
com.example applicationId o bundle id	Usa flutter pub run change_app_package_name:main com.tucompañia.app o edita android/app/build.gradle(.kts) y las tres entradas PRODUCT_BUNDLE_IDENTIFIER en ios/Runner.xcodeproj/project.pbxproj.
La versión se firma con clave de depuración	Agrega la carga de key.properties y un signingConfig de release; consulta references/android-signing.md.
key.properties o *.jks rastreados por git	Agrégarlos a .gitignore, luego git rm --cached <archivo>; rota la contraseña del almacén de claves si el repositorio es público.
No hay PrivacyInfo.xcprivacy	Crea ios/Runner/PrivacyInfo.xcprivacy; plantilla en references/privacy-manifest.md.
debuggable=true, tráfico en texto claro, URLs locales	Elimínalos antes de la publicación.
Errores del analizador / pruebas fallidas	Arréglelos; no sugieras omitirlos.

Paso 3: verifica cosas que el script no puede

Observa el proyecto y considera:

• SDK objetivo: Google Play requiere que las apps nuevas y las actualizaciones apunten a un nivel de API de Android reciente (el requisito variable de Play es aproximadamente la versión del año anterior). Verifica targetSdk en android/app/build.gradle(.kts) o el valor predeterminado de Flutter.
• Ícono de la app y splash: el ícono predeterminado de Flutter es motivo de rechazo en la revisión y una desinstalación instantánea para los usuarios. Verifica la configuración de flutter_launcher_icons / flutter_native_splash o las carpetas mipmap.
• Permisos: si el manifiesto tiene algo más que INTERNET, sugiere ejecutar la habilidad permission-audit.
• Activos de la tienda: gráfico destacado 1024x500 (Play), capturas de pantalla para cada clase de dispositivo requerida, URL de política de privacidad (requerida si la app recopila datos o solicita permisos sensibles).
• Eliminación de cuentas: ambas tiendas requieren una ruta de eliminación de cuentas dentro de la app si esta permite la creación de cuentas.
• Inicio de sesión para revisores: si hay una pantalla de inicio de sesión, recuerda al usuario que proporcione una cuenta de demostración en las notas de revisión.

Lee references/store-rejections.md para obtener la lista completa de razones de rechazo comunes y sus correcciones cuando el usuario pregunte por qué fue rechazado o quiera una revisión más profunda.

Paso 4: reporta

Devuelve un informe breve:

1. Veredicto: LISTO / NO LISTO.
2. Debe corregirse (elementos FAIL, cada uno con archivo y cambio exacto).
3. Debería corregirse (elementos WARN que importan para esta app).
4. Comandos siguientes: normalmente flutter build appbundle --release y flutter build ipa --release, precedidos de bump-version y changelog cuando la versión ya se publicó.

Mantente conciso. No repitas las líneas OK a menos que el usuario solicite la salida completa.