# Revisão do fluxo de assinaturas, cobranças e pagamentos Asaas

## Prompt

Analisar e revisar integralmente o fluxo de assinaturas, cobranças e pagamentos integrado ao Asaas, implementando correções — e não apenas uma análise teórica.

O fluxo solicitado abrange: seleção exclusiva de planos ativos; teste grátis opcional de 7 dias, configurável por plano e utilizável uma única vez; criação e sincronização idempotente do cliente Asaas; cobranças Pix, boleto e cartão sempre calculadas pelo backend; recorrência opcional por cartão sem persistência de dados sensíveis; webhooks autenticados, idempotentes, auditáveis, transacionais e reprocessáveis; estados `TRIAL`, `ACTIVE`, `PENDING_PAYMENT`, `OVERDUE`, `SUSPENDED`, `CANCELED` e `EXPIRED`; renovação, cancelamento, estorno, chargeback e inadimplência; histórico e auditoria; scripts SQL versionados em `database/`; compatibilidade com os dados legados; processos agendados; e testes de todos os cenários críticos, inclusive duplicidade e eventos fora de ordem.

A entrega deve apresentar diagnóstico, problemas, melhorias, arquivos alterados, banco, eventos, fluxo final, testes, riscos e checklist.

## Resposta

O fluxo legado foi revisado e corrigido. Os principais riscos encontrados eram: cobrança criada por endpoints `GET` sem proteção contra repetição; preço e cliente aceitos por endpoints genéricos; criação de cliente no Asaas durante o cadastro; cliente externo não persistido de forma confiável; ausência de assinatura local e de estados explícitos; teste grátis implícito e inconsistente; múltiplas cobranças pendentes; confirmação síncrona do cartão usada pelo frontend; webhook sem idempotência/transação, permissivo quando o token não estava configurado e sempre respondendo HTTP 200, inclusive em falhas; falta de prevenção a eventos fora de ordem; ausência de auditoria e reprocessamento; e inexistência de processo de manutenção para trials/vencimentos.

Foi criada e aplicada a migração `database/2026-07-15-001-fluxo-assinaturas-asaas.sql`, com configuração de trial/atividade nos planos, controle de trial nas contas, tabela de assinaturas, ampliação de faturas e pagamentos, eventos de webhook, histórico, tentativas e operações idempotentes. As contas e registros antigos receberam backfill compatível.

O backend agora deriva o valor do plano/fatura, valida que a conta da URL pertence ao JWT, cria ou sincroniza o cliente Asaas apenas quando necessário, persiste o `customer_id`, usa referências externas e locks idempotentes, reutiliza cobrança pendente válida e cancela com segurança uma cobrança anterior ao trocar o meio de pagamento. A tokenização foi vinculada à conta autenticada. Cartão pode criar recorrência no Asaas e permite atualização do cartão e cancelamento da renovação, sem persistir número ou CVV.

O cadastro valida plano ativo e registra a escolha do teste. Quando elegível, cria `TRIAL` sem fatura ou cobrança e marca o trial como utilizado. O frontend mostra a opção conforme o plano. A confirmação de pagamento passou a depender do webhook, e o polling da tela apenas observa o estado da fatura atualizado pelo backend.

O webhook valida obrigatoriamente `asaas-access-token` com comparação segura, persiste o evento pelo `id`, ignora duplicatas concluídas, processa pagamentos e assinaturas em transação, impede regressão por eventos fora de ordem, registra erros para reprocessamento e retorna HTTP não-2xx em falhas. Foram cobertos pagamento criado/pendente, recebido/confirmado, vencido, cancelado/excluído, estorno total/parcial/em andamento, análise de risco, chargeback/disputa e recebimento por cobrança. A renovação do período pago ocorre uma única vez por pagamento.

Foi criado `back/bin/processar-assinaturas.php` para expirar trials, marcar vencimentos, suspender acesso quando aplicável, expirar cancelamentos ao fim do período e reconciliar cancelamentos remotos pendentes. O agendamento no ambiente de produção permanece uma etapa operacional.

Foram adicionados testes de política e integração com MariaDB. Resultado: 41 testes passaram; todos os arquivos PHP alterados passaram em `php -l`; `composer validate` e `composer check-platform-reqs` passaram; Oxlint e ESLint passaram sem erros; e `vue-tsc --build` passou. Nenhuma dependência foi adicionada. O build Vite de produção não foi executado sem a confirmação exigida pelas regras do projeto.

Permanece necessária validação em Sandbox com credenciais e webhook reais antes da publicação, além de configurar `ASAAS_WEBHOOK_TOKEN` forte, agendar o job e decidir quais planos existentes devem habilitar `permite_teste_gratis = 'S'`.

## Prompt

Faz o build.

## Resposta

O build de produção do frontend foi executado com sucesso por meio de `npm run build`. A verificação de tipos com `vue-tsc --build` passou, o Vite transformou 1.156 módulos e gerou os artefatos em `front/dist/` em 45,29 segundos.

O processo apresentou apenas avisos não bloqueantes: base `caniuse-lite` desatualizada, alguns módulos importados simultaneamente de forma estática e dinâmica, e o chunk principal acima de 500 kB. Nenhum erro de build ou de tipagem foi encontrado.