Verificação de lançamento
Você está ajudando um desenvolvedor Flutter a publicar uma versão que não será rejeitada pela Google Play ou pela revisão da App Store. Seja concreto: nomeie o arquivo e a alteração exata para cada problema.
Passo 1: execute a verificação pré-lançamento determinística
Na raiz do projeto Flutter, execute:
bash "${CLAUDE_PLUGIN_ROOT}/scripts/preflight.sh" $ARGUMENTS
O script imprime linhas OK / WARN / FAIL agrupadas por seção (Versão, Changelog, Análise estática, Testes, Resquícios de depuração, Android, iOS) e sai com código 1 em caso de qualquer FAIL. Pode levar um minuto quando os testes são executados. Se o usuário estiver claramente no meio do desenvolvimento e quiser apenas uma olhada rápida, passe --skip-tests.
Passo 2: investigue cada FAIL e WARN
Para cada item, abra o arquivo que o script nomeia e confirme a descoberta antes de relatá-la. Correções comuns:
| Descoberta | Correção |
|---|---|
| Versão sem número de build | Altere version: 1.2.0 para version: 1.2.0+1 no pubspec.yaml. |
| Tag já existe para esta versão | Execute o skill bump-version. |
applicationId com.example ou bundle id | Use flutter pub run change_app_package_name:main com.suaempresa.app ou edite android/app/build.gradle(.kts) e as três entradas PRODUCT_BUNDLE_IDENTIFIER em ios/Runner.xcodeproj/project.pbxproj. |
| Release assinada com chave de depuração | Adicione o carregamento de key.properties e um signingConfig de release; veja references/android-signing.md. |
key.properties ou *.jks rastreados pelo git | Adicione ao .gitignore, depois git rm --cached <arquivo>; troque a senha do keystore se o repositório for público. |
Sem PrivacyInfo.xcprivacy | Crie ios/Runner/PrivacyInfo.xcprivacy; modelo em references/privacy-manifest.md. |
debuggable=true, tráfego de texto claro, URLs localhost | Remova antes do lançamento. |
| Erros do analisador / testes falhando | Corrija-os; não sugira pular. |
Passo 3: verifique coisas que o script não pode
Observe o projeto e considere:
- SDK alvo: a Google Play exige que novos aplicativos e atualizações visem um nível de API Android recente (o requisito contínuo da Play é aproximadamente o lançamento do ano anterior). Verifique
targetSdkemandroid/app/build.gradle(.kts)ou o padrão do Flutter. - Ícone e splash do aplicativo: o ícone padrão do Flutter é motivo de rejeição na revisão e uma desinstalação instantânea para os usuários. Verifique a configuração de
flutter_launcher_icons/flutter_native_splashou as pastas mipmap. - Permissões: se o manifesto tiver algo além de INTERNET, sugira executar o skill
permission-audit. - Assets da loja: graphic feature 1024x500 (Play), capturas de tela para cada classe de dispositivo exigida, URL da política de privacidade (exigido se o aplicativo coletar qualquer dado ou solicitar permissões sensíveis).
- Exclusão de conta: ambas as lojas exigem um caminho de exclusão de conta no aplicativo se ele suportar criação de conta.
- Login para revisores: se houver uma tela de login, lembre o usuário de fornecer uma conta de demonstração nas notas de revisão.
Leia references/store-rejections.md para a lista completa de motivos comuns de rejeição e suas correções quando o usuário perguntar por que foi rejeitado ou quiser uma revisão mais aprofundada.
Passo 4: relate
Retorne um relatório curto:
- Veredito: PRONTO / NÃO PRONTO.
- Corrigir obrigatoriamente (itens FAIL, cada um com arquivo e alteração exata).
- Corrigir recomendadamente (itens WARN que importam para este aplicativo).
- Próximos comandos: geralmente
flutter build appbundle --releaseeflutter build ipa --release, precedidos porbump-versionechangelogquando a versão já foi publicada.
Mantenha conciso. Não repita linhas OK a menos que o usuário peça a saída completa.