# Aceitação da integração do aplicativo > Probes em modo de conta agora obtêm asserções de identidade de curta duração. Estado negativo de compra no Launch é apenas evidência de compra, não prova de negação de execução pelo Licentivo. A prova de execução exige o probe do SDK oficial; não implica implantação em produção ou publicação do SDK. Consulte [limite da conta](/pt/launch-documents/account-purchase-boundary/). Há dois níveis separados de evidência: verificações automatizadas locais controladas e probes externos no sandbox do comerciante. Um substituto de teste, leitura de catálogo bem-sucedida, configuração gerada ou verificação de saúde aprovada nunca comprova pagamento real, emissão de licença ou ativação. A configuração de serviços externos foi explicitamente adiada nesta iteração de desenvolvimento. ## Verificações automatizadas locais Execute a partir da raiz do repositório: ```powershell go test ./... go vet ./... node --check internal/httpapi/web/app.js node --check internal/httpapi/web/integration.js node --check internal/httpapi/web/integration-prompts.js node --test scripts/integration-prompts.test.mjs scripts/integration-state.test.mjs python scripts/test_acceptance.py ./scripts/test-mysql.ps1 ``` O auxiliar MySQL cria novo servidor e bancos isolados em `.cache`; não deve apontar para banco de cliente. Um `go test ./...` simples ignora cenários de banco sem DSNs isolados. Testes e builds de SDK/pacotes são descritos em [integration-packages.md](/pt/launch-documents/integration-packages/). Preserve saída dos testes e versões das ferramentas com o registro de release. A matriz local inclui autenticação, verificação condicional de e-mail, titularidade de produto/ambiente, estado pending/expired/suspended, replay de evento de pagamento, reconciliação de licenciamento, renovações/reembolsos, troca de conta, persistência protegida de sessão e decisões de fallback offline. Testes de ciclo de vida usam runtimes controlados; a verificação criptográfica real em execução continua responsabilidade do SDK oficial e é testada separadamente antes da release. Para **Ferramentas operacionais → Integração rápida com AI**, verifique as nove linguagens, seleção de plataforma/projeto/recurso, rascunho não configurado e prompt gerado a partir de configuração pública validada. Compare cópia e download com o prompt visível e garanta que trocar produto ou ambiente não retenha configuração validada anterior. Prompts devem excluir sessões, senhas, credenciais de licença/dispositivo em execução e chaves de gerenciamento; gerar ou copiar prompt não deve chamar serviço AI. O comando de teste Node do pacote de fonte acima exercita o gerador puro. Um prompt gerado, ou código produzido depois por ferramenta AI, ainda precisa dos testes de linguagem e das etapas externas de aceitação abaixo. ## Preparar aceitação externa no sandbox 1. Implante uma instância Launch de teste dedicada com origem HTTPS acessível e webhooks do provedor. Mantenha vendas live desativadas. 2. Configure credenciais sandbox de **um** provedor de pagamento e uma conexão Licentivo de leitura/gravação. Registros sandbox de pagamento são isolados, mas ainda usam o serviço Licentivo configurado e podem criar licenças/dispositivos reais de teste. Use produto/política e clientes de teste dedicados. 3. Publique um plano sandbox e use **Integração do programa** para exportar `launch-config.json` e `product.json` validado para `.local/acceptance/`. 4. Instale localmente apenas o pacote Launch Python revisado: `python -m pip install ./sdk/python`, ou instale seu wheel. Sua implementação privada do SDK está incluída. 5. Use um recurso de teste não medido como `export`. `--activate` inicia o SDK oficial, chama `refresh_online()` sincronicamente, exige estado online ativo e invoca sua API de operação protegida. Um grant offline em cache sozinho não passa neste probe; ele não testa medição. Credenciais são solicitadas sem eco. A automação pode fornecer `LAUNCH_ACCEPTANCE_EMAIL` e `LAUNCH_ACCEPTANCE_PASSWORD` no ambiente privado do processo. Não coloque senhas em argumentos, relatórios, capturas ou arquivos commitados. A ferramenta revoga sua sessão temporária de desktop após cada probe autenticado, mas não desativa dispositivos na saída normal. ```powershell python scripts/acceptance.py preflight --config .local/acceptance/launch-config.json --report .local/acceptance/01-preflight.json python scripts/acceptance.py verify --config .local/acceptance/launch-config.json --expect not_purchased --report .local/acceptance/02-no-purchase.json ``` A ferramenta recusa configuração de ambiente live, HTTP não loopback, redirecionamentos com credenciais, produtos incompatíveis e configuração pública com segredos de execução. Rejeita asserções de ativação/pedido fora de `verify` e opções de criação de checkout fora de `checkout` antes de enviar solicitações. Relatórios existentes nunca são sobrescritos. Relatórios contêm evidências permitidas, não respostas brutas, tokens de acesso ou chaves de licença. Servidor ou SDK ausente gera probe com falha, não sucesso sintético. Probes locais do comerciante usam `scope: local_sandbox_probe` e `licensing_scope: not_called`. `verify --activate` contata o serviço oficial externo de licenciamento mesmo com o comerciante em localhost; essa combinação é registrada como `local_merchant_external_licensing_probe` com `licensing_scope: official_external_service`. ## Primeiro pagamento e ativação Crie um checkout de teste no site do comerciante, ou crie um com UUID estável da operação: ```powershell $operation = [guid]::NewGuid().ToString() python scripts/acceptance.py checkout --config .local/acceptance/launch-config.json --provider stripe --plan-version-id PLAN_VERSION_UUID --operation-id $operation --report .local/acceptance/03-checkout.json ``` Substitua provedor e versão de plano pelo seu plano sandbox publicado. Guarde e reutilize o mesmo UUID de operação ao repetir criação incerta de checkout. A ferramenta imprime o ID do pedido. Conclua esse pedido próprio no centro de conta do comerciante usando o checkout sandbox oficial do provedor. Interações com a interface do provedor deliberadamente não são simuladas pelo probe. Após o provedor confirmar o pagamento e o webhook ser recebido: ```powershell python scripts/acceptance.py verify --config .local/acceptance/launch-config.json --order-id ORDER_UUID --expect-order paid --expect active --activate --product-config .local/acceptance/product.json --feature export --report .local/acceptance/04-activation.json ``` Isso verifica a conta autenticada, o pedido sandbox próprio, entitlement, correspondência credencial/produto e uma operação protegida real do SDK oficial. Autorização pendente é tentada no máximo cinco vezes em janela limitada (padrão 30 segundos, máximo 120), respeitando `Retry-After`. Falha inesperada de autorização é registrada sem expor o texto bruto do erro do SDK. ## Matriz de aceitação do ciclo de vida Para cada par linguagem/OS lançado, guarde registro datado com revisão da fonte, versões Launch/client/SDK, ambiente do provedor, rótulo anonimizado do cliente, IDs dos pedidos, resultado esperado, resultado observado e nome do relatório relevante. Marque linhas não executadas como **not run**. Não marque a matriz inteira como aprovada pelo probe do primeiro pagamento. | Cenário | Procedimento | Evidência necessária | | --- | --- | --- | | Registro / verificação | Registre sem compra; repita com verificação habilitada e desabilitada | Verificação desabilitada não bloqueia; habilitada retorna `EMAIL_VERIFICATION_REQUIRED` até conclusão | | Sem compra | Execute `verify --expect not_purchased` | Credencial negada; nenhuma operação protegida executa | | Primeira compra | Conclua pagamento sandbox e execute o probe de ativação | Provedor confirma pagamento; um entitlement pago, uma licença sincronizada, operação SDK bem-sucedida | | Reinício | Feche o exemplo da linguagem escolhida com login lembrado, inicie novo processo e restaure | Sem solicitação de senha; mesmo cache de conta/produto e grant assinado válido | | Inicialização offline | Após ativação lembrada bem-sucedida, desative rede para esse processo/máquina de teste e reinicie | Grant assinado em cache permite apenas operações autorizadas pela política; política no-offline/floating recusa inicialização | | Expiração offline / retrocesso do relógio | Use política de teste curta e máquina de teste descartável | SDK rejeita estado expirado/revertido; callback do recurso não executa | | Renovação / upgrade | Compre renovação ou upgrade cotado na loja sandbox | Pedido/cobertura corretos; nova validade/recursos visíveis após sincronização e atualização do SDK | | Reembolsar | Solicite/aprove reembolso sandbox integral; aguarde confirmação do provedor | Reembolso do provedor e cobertura local coincidem; `verify --expect suspended` ou `--expect expired` conforme apropriado; outra cobertura paga permanece utilizável | | Logout / troca de conta | Saia de A, entre como B sem compra; reinicie e examine o comportamento | Sessão/cache salvo de A removido; B não pode usar licença, dispositivos ou recursos de A | | Isolamento de produto / ambiente | Use outro produto e alterne separadamente configurações sandbox/live | Credenciais e caches não atravessam escopos de identidade; o probe externo recusa live | | Dispositivos cheios / liberação | Ative no máximo de dispositivos de teste distintos da política; tente mais um e depois libere explicitamente um | SDK rejeita dispositivo excedente e permite substituição após liberação confirmada; fechamento comum não consome cota de liberação | | Recuperação | Reinicie Launch durante emissão pendente, reproduza webhook sandbox assinado | Uma cobertura/licença de pedido, reconciliação eventual; sem checkout ou cobrança duplicados | Efeitos de reembolso/suspensão sobre grant offline já emitido permanecem limitados pela política offline assinada do SDK oficial. Não se afirma revogação imediata enquanto desconectado. Uma longa indisponibilidade do Launch no vencimento do contrato pode atrasar a suspensão upstream; consulte [limitações do contrato](/pt/launch-documents/licentivo-contract/). ## Conclusão e evidências retidas Cada relatório de probe define deliberadamente `acceptance_complete: false`: registra apenas as verificações realmente executadas naquela chamada. Revise a matriz e os registros do provedor antes de aceitar uma release. Configure serviços externos depois e retome os comandos acima; não substitua resultados ausentes por indicador de aprovação nem habilite vendas live apenas porque testes locais passaram.