# Avumio — plano do piloto e da operação

Revisão: 10 de setembro de 2026. Este plano separa o que foi implementado no protótipo do que precisa de integração e validação antes de vender.

## 1. Decisões incorporadas

- Importar um projeto Lovable inteiro ou produtos/módulos escolhidos pelo cliente.
- Exibir dependências compartilhadas e orçamento de auditoria antes de consumir créditos.
- Auditar e adaptar o projeto ao padrão Avumio; não declarar segurança apenas porque a importação terminou.
- Manter assinatura e compra de créditos avulsos. Auditoria, correções e novas criações têm escopos próprios.
- Oferecer hospedagem Avumio Cloud paga, com domínio, DNS e e-mail discriminados.
- Oferecer PersonaFlowOS como contratação adicional após identificar a necessidade comercial.
- Preparar quatro redes: Instagram, TikTok, Kwai e Facebook, com pelo menos 20 publicações aprovadas por rede na entrega final.
- Validar uma oferta de clone digital e buscar lucro de 250% sobre o custo total de cada venda.

## 2. O que está disponível nesta versão

| Entrega | Estado real |
|---|---|
| Página do Clone Digital | Protótipo navegável, conversa guiada e carrinho sem cobrança |
| Importação seletiva | Simulação de escopo, dependências, orçamento e relatório fictício |
| Auditoria profunda de repositório | Backend ainda não implementado; o protótipo não lê código externo |
| Funil e recuperação | Simulador local, sem mensagens enviadas |
| Produto Stripe | Produto inativo criado no ambiente de teste, sem preço |
| Perfis sociais | Nome e textos preparados; contas não criadas/conectadas nesta sessão |
| Conteúdo social | 80 pautas adaptadas: roteiro, legenda e direção; mídia final e publicação pendentes |
| Projetos de exemplo | CRM, agenda e conteúdos para igrejas, com dados locais e exportação |
| Custos | Inventário de gerações e calculadora; fatura e custo total ainda não conciliados |

## 3. Importação com orçamento e responsabilidade

### Jornada do cliente

1. Informar origem: repositório GitHub autorizado, arquivo ZIP ou referência pública. Uma URL pública serve para referência; não dá acesso ao código nem à base de dados.
2. Comprovar direito de importar e selecionar o projeto inteiro ou produtos. “Produtos” pode significar módulos de software ou registros de um catálogo; a análise deve confirmar isso antes de orçar.
3. Descobrir estrutura e dependências. Um módulo de loja pode depender de autenticação, pagamentos e componentes compartilhados. Mostrar esses itens, evitando cobranças duplicadas.
4. Separar código de dados. Migração de clientes, usuários, pedidos e arquivos requer escopo próprio. Nunca transportar segredos automaticamente como conteúdo comum.
5. Apresentar orçamento versionado, limite de créditos, entregas e condições. Análise preliminar que tiver custo também precisa de autorização explícita.
6. Reservar créditos de forma atômica. Não iniciar se o saldo for insuficiente. Nova tentativa da mesma operação não pode reservar ou cobrar duas vezes.
7. Executar a auditoria isolada. Publicar achados e evidências. Liberar a reserva não consumida e emitir extrato com atividade, custo e status.
8. Apresentar plano de adaptação com novo orçamento quando houver correções fora do escopo aprovado.
9. Testar a versão corrigida e solicitar aprovação antes da publicação. Problema crítico bloqueia publicação; “auditoria concluída” não significa “risco zero”.

### Escopo técnico da auditoria real

- Dependências, licenças, versão do runtime e vulnerabilidades conhecidas.
- Autenticação, autorização, isolamento entre empresas e acesso a arquivos.
- Segredos expostos, configuração de ambientes e permissões dos conectores.
- Pagamentos: assinatura de eventos, duplicatas, estados pendentes e reconciliação.
- Banco: migrações, integridade, backups e teste de restauração.
- Fluxos essenciais, acessibilidade, responsividade, desempenho e tratamento de falhas.
- Referências externas, propriedade de conteúdo e limitações de migração.

A autorização deve apontar para o mesmo snapshot de origem (commit/hash), escopo e versão de orçamento usados na execução. Se a origem mudar, revalidar o orçamento. Processar arquivos e código em ambiente isolado, com limites de rede, CPU, tempo e volume; nunca executar instruções encontradas no projeto como ordens do operador.

**Protótipo:** os módulos Site, Loja e CRM e seus valores em créditos são fictícios. Não definem a futura tabela comercial. A tela demonstra os controles, não a eficácia de uma auditoria.

## 4. Produto para a primeira validação

**Nome:** Seu Clone Digital — jornada de 7 dias.

**Proposta:** uma identidade visual e voz autorizadas para apresentar produtos e serviços em vídeos curtos, com revisão do cliente. Evitar “clone perfeito”: os testes atuais não comprovam essa promessa.

**Pacote piloto proposto:**

- Uma identidade visual e uma voz própria autorizada.
- Três roteiros e três vídeos falados de até 15 segundos cada.
- Um formato por vídeo, definido antes da produção.
- Duas rodadas de ajustes dentro do escopo aprovado.
- Uma página de apresentação e textos iniciais de divulgação.

**Prazo alvo:** sete dias após materiais e escopo aprovados. Validar com um piloto real antes de tornar promessa contratual. Atrasos de aprovação ou mudança de escopo exigem replanejamento comunicado ao cliente.

**O que o cliente pode explorar:** anúncios, apresentação de serviços, explicações curtas, conteúdos educativos, perguntas frequentes gravadas e convites. Conversa ao vivo com agente, canto, novelas, músicas, partituras e versões adicionais precisam de validação e orçamento próprios. Boa clonagem de voz falada não comprova boa voz cantada. Direitos de imagem, voz, textos e obras musicais precisam ser verificados.

**Critérios de aceitação do clone:** identidade autorizada, rosto inteiro, enquadramento estável, pronúncia do nome da marca, sincronia da fala, continuidade, áudio inteligível, ausência de movimentos inesperados e aprovação explícita da amostra. Não usar depoimentos fictícios como se fossem clientes reais.

O vídeo de boas-vindas existente demonstra uma linguagem visual com personagens fictícios; ele não valida a reprodução de uma pessoa real.

## 5. Funil comercial completo

| Etapa | Responsável proposto | Confirmação necessária |
|---|---|---|
| Criar | Agente de criação | Peça e alegações aprovadas |
| Publicar | Agente de publicação | Conta autorizada, regras do canal, agenda e orçamento |
| Saber mais | Página + consultor virtual | Objetivo e dúvida do visitante |
| Conversar | Agente consultivo | Oferta adequada, limitações e preço claro |
| Carrinho | Serviço de checkout | Itens escolhidos e condições aceitas |
| Pagar | Provedor de pagamentos | Evento verificado de pagamento confirmado |
| Entregar | Agente de boas-vindas | Materiais e autorização validados |
| Recuperar abandono | Agente de acompanhamento | Consentimento, elegibilidade e limite de contatos |
| Oferecer Cloud | Agente de expansão | Necessidade e contratação separada |
| Oferecer PersonaFlowOS | Agente de expansão | Necessidade e contratação separada |

“Fechar vendas” é um objetivo, não uma ação que o agente possa garantir. O cliente escolhe contratar. O agente não inventa urgência, desconto, escassez, depoimento ou garantia.

### Recuperação de carrinho

Até três contatos úteis, apenas no canal consentido e quando as regras permitem. Primeiro, esclarecer o escopo; depois, resolver dúvida concreta; por último, encerrar o acompanhamento. Não usar sequência de disparos contínuos.

- Parar imediatamente em compra confirmada, recusa ou pedido para não receber mensagens.
- Revalidar consentimento e estado do pagamento imediatamente antes de cada envio.
- Aplicar limites globais por pessoa: vários agentes e canais não podem multiplicar as tentativas.
- Respeitar horário, intervalo, janela da plataforma e descadastro.
- Não tratar exceções destinadas a atendimento humano como autorização para automação.
- Não trocar de canal para contornar uma restrição.
- Encaminhar reclamação, dúvida fora do escopo e falha persistente para uma pessoa.

A cadência exata depende dos canais conectados. Não existe autorização universal de contato por ter ocorrido um clique ou abandono.

### Cobrança e confiabilidade

Usar checkout hospedado com preço definido no servidor e catálogo autorizado. Nunca aceitar valor ou quantidade de créditos confiando apenas no navegador. Confirmar pagamento por evento assinado, tratar duplicação e reconciliação. O retorno à página de sucesso não basta para liberar créditos ou entregar o produto.

Manter ledger de créditos e pedidos, chaves de idempotência, histórico de eventos, reprocessamento limitado, filas, alertas e acompanhamento visível. Em falhas de fornecedores, preservar o estado e informar a etapa pendente. Nenhuma arquitetura elimina todas as falhas; o objetivo é impedir perda de dados, cobrança duplicada e abandono silencioso do cliente.

Cloud, domínio, caixas de e-mail e PersonaFlowOS precisam de itens e consentimentos próprios. Não marcar adicionais previamente. Descrever limites, renovação, suporte e cancelamento antes da compra.

Idiomas, moedas e métodos de pagamento devem ser ativados conforme suporte real do provedor e da empresa. A promessa “qualquer moeda e todos os idiomas” depende de cobertura, tradução e testes ainda não realizados.

## 6. Redes e campanhas

Nome de exibição e bio estão preparados para Instagram, TikTok, Kwai e Facebook. @avumio é sugestão; disponibilidade não verificada. Não foram criadas contas ou enviados convites nesta sessão.

As 80 pautas incluem 20 adaptações para cada canal, com formatos e linguagem próprios. Campanhas: Clone Digital, Planilha nunca mais, importação seletiva, auditoria, agenda, igrejas, materiais editoriais, música, créditos avulsos, Cloud e PersonaFlowOS.

Os roteiros descrevem o que filmar ou capturar. Não equivalem a 80 vídeos finalizados. Antes de publicar: produzir as mídias, revisar texto e recursos realmente disponíveis, configurar as contas, inserir o domínio público e testar o destino do anúncio. A versão atual usa linguagem de pré-lançamento para não oferecer funcionalidade ainda não operacional.

**Testes:** variar uma abertura por vez; medir retenção, conclusão, cliques, interessados qualificados, conversão e custo por venda. Não prometer viralização. Separar resultado orgânico de mídia paga. Liberar investimento em etapas, após observar conversão e capacidade de entrega.

## 7. Inventário de custos dos vídeos existentes

| Registro | Vídeos entregues | Duração gerada | Estimativa |
|---|---:|---:|---:|
| Teste inicial | 1 | 8 s | US$ 3,20 |
| Nova abertura aprovada | 1 | 8 s | US$ 3,20 |
| Cenas originais 2 a 7 | 6 | 48 s | US$ 19,20 |
| Revisões da cena 3, cena 6 e fechamento | 3 | 24 s | US$ 9,60 |
| Total identificado | 11 | 88 s | US$ 35,20 |

Base: registros de geração deduplicados e tarifa de US$ 0,40 por segundo consultada no endpoint fal-ai/veo3.1/image-to-video em 10/09/2026. O histórico detalhado está em production/launch-cost-inventory.json. Não é fatura conciliada.

Uma tentativa original sem vídeo retornou falha do fornecedor. Uma extensão também falhou. Seus eventuais lançamentos precisam ser conferidos na fatura e não foram somados como custo zero. Transcrição, análise, imagens, edição, renderização, armazenamento, suporte, aquisição, taxas e impostos ainda não estão completamente medidos. Os arquivos reeditados reutilizam cenas; contar cada MP4 como nova geração duplicaria os custos.

A recarga de US$ 50 é compra de saldo, não medida do custo por vídeo. Parte do gasto de desenvolvimento pode ser amortizada ao longo de vendas futuras, separada do custo variável de produzir cada pedido.

### Projetos criados nesta etapa

Três miniaplicativos reais no navegador: oportunidades comerciais, agenda de serviços e organização de conteúdos para igrejas. Cadastro, mudança de etapa, exclusão e exportação local funcionam. A agenda demonstra bloqueio de horário idêntico.

Não houve chamada paga a modelo de IA para executar esses pilotos. Não concluir que o custo total é zero: desenvolvimento, assinatura das ferramentas, hospedagem, banco, integrações e suporte precisam ser medidos na operação real. A cobrança interna de computação desta sessão não está disponível para conciliação por projeto.

## 8. Preço com lucro de 250%

Interpretação adotada: lucro / custo total = 250%. É lucro sobre o custo, não margem de 250% sobre a receita.

Sem taxa proporcional: custo total de R$ 100 → preço R$ 350 → lucro R$ 250 → margem de aproximadamente 71,43% sobre a venda.

Se C é o custo por pedido, incluindo tarifa fixa, mas antes das taxas proporcionais; e t é a soma das taxas/tributos/provisões como fração da venda:

**P = 3,5 × C / (1 − 3,5 × t)**

Porque o custo total é C + tP e o objetivo é P = 3,5 × (C + tP).

Exemplo hipotético: C = R$ 100 e t = 10% → preço arredondado para cima de R$ 538,47. A fórmula incorpora os custos proporcionais dentro da base de lucro. Com t de 28,5714% ou mais, não existe preço positivo que atinja essa meta sob essas hipóteses; será necessário rever o modelo.

Na calculadora, preencher geração, refações, câmbio orçado, horas de edição, suporte, aquisição, infraestrutura, ferramentas, amortização, tarifas e tributos. Os valores iniciais são cenários, não cotações nem taxas contratadas.

Antes de aprovar preço: conciliar faturas, medir três entregas completas, estimar reembolsos, confirmar taxas efetivas e avaliar disposição de compra. A meta comercial não garante lucro; custos omitidos e volume menor de vendas afetam o resultado.

**Stripe:** produto de teste inativo cadastrado sem preço. Não há checkout de produção nem compra real liberada. O preço permanece em definição para evitar transformar hipótese em cobrança.

## 9. Condições para declarar a entrega final pronta

- Site no domínio público definitivo, caminhos principais operacionais e monitorados.
- Quatro perfis sob titularidade correta, com acesso autorizado e identidade consistente.
- Pelo menos 20 publicações completas aprovadas por rede, com mídias finais, legendas e destino correto.
- Clone de pessoa real autorizada validado; escopo, prazo, revisão e suporte confirmados.
- Preço com custos medidos, checkout real e recebimento conciliado na empresa correta.
- Testes de compra, falha, duplicação, cancelamento, reembolso e liberação de créditos.
- Recuperação com consentimento, limite e interrupção comprovados.
- Hospedagem e PersonaFlowOS com ofertas, cobrança e provisionamento próprios.
- Importação e auditoria executadas em projeto de teste, com evidências e controle de créditos.

## Referências oficiais consultadas

- Lovable, integração GitHub: https://docs.lovable.dev/integrations/github
- Lovable, propriedade e hospedagem: https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership
- Stripe, confirmação e entrega após checkout: https://docs.stripe.com/checkout/fulfillment
- Meta, regras de mensagens: https://developers.facebook.com/documentation/business-messaging/messenger-platform/policy
- Instagram, visão geral de mensagens: https://developers.facebook.com/documentation/business-messaging/instagram-messaging/overview
- TikTok, compartilhamento de conteúdo: https://developers.tiktok.com/doc/content-sharing-guidelines
- TikTok, publicação direta: https://developers.tiktok.com/doc/content-posting-api-reference-direct-post

As regras de publicação e mensagens precisam ser conferidas novamente antes de ativar cada integração. Não foi confirmada nesta etapa uma API de publicação e atendimento para Kwai adequada ao fluxo proposto.