Bullgate

• Deixe entrar sem conta nenhuma. Modo visitante com dados de demonstração: quem decide criar conta já sabe o que está comprando.
• A porta de menos atrito primeiro — é a tela abaixo: Google e Apple na frente (o provedor prova o e-mail); o formulário fica atrás de um toque.
• Se o provedor já provou, não pergunte. E-mail repetido vindo de token verificado vincula em silêncio em vez de criar a segunda conta. A melhor tela de conflito é a que ninguém vê.
• Não verifique e-mail para deixar entrar. A conta nasce sem essa prova — o custo é adiado para o dia da recuperação, e é por isso que a parte de recuperação existe.
• O que não é essencial sai do formulário. Telefone vira passo próprio, depois da conta, com «Agora não» de verdade — e a etapa inteira liga e desliga por configuração de servidor, sem publicar versão.

Placar honesto deste bloco: o código por SMS com preenchimento automático está no ar, em produção; o magic link por e-mail e a liberação pelo WhatsApp estão no desenho da plataforma — decididos, ainda não construídos.

• A sessão não carrega nada dentro. O que o app guarda é um bilhete aleatório, sem e-mail, sem permissão, sem nada interpretável — e o servidor guarda só a impressão digital dele. Roubar o bilhete não conta nenhum segredo.
• Encerrar tudo é virar uma chave. Uma troca de senha, um bloqueio, um «desconecta tudo» — e nenhuma sessão antiga revive, nem por fuso horário, nem por repetição de chamada.
• Bloquear é um ato só. Barra a entrada e derruba quem já está dentro, juntos — porque um sem o outro não resolve invasão. E desbloquear devolve o acesso, nunca a sessão antiga: senão o cookie do invasor voltaria junto com o da dona.
• Queda do serviço não desloga ninguém. Se o serviço de identidade cair por minutos, o acesso fecha durante a falha e reabre sozinho — indisponibilidade curta não vira logout da base inteira.
• Bloqueio vale na requisição seguinte. Sem cache escondido: cortar o acesso de alguém corta agora, não «em até 15 minutos».

• Provas, não histórias: saber algo (o CPF, o e-mail antigo), ter algo (o código chegou no telefone ou no e-mail), já ser alguém (uma senha ou um login social que ainda funcionam) ou uma atestação externa de titularidade. Tentativa errada nunca vira prova.
• A regra é declarada, nunca pontuação oculta: sabe o CPF E (tem o telefone OU tem o e-mail). E mudar a regra não muda o jogo no meio da jornada de ninguém.
• Provou → destrava exatamente o que a regra diz. Trocar credenciais, derrubar sessões, absorver a conta duplicada — uma autorização de uso único, que morre ao ser usada. Sem as provas, nenhum operador libera; com as provas, opinião subjetiva não bloqueia.
• Revisão manual não é válvula de escape. Ela só existe quando a regra nomeia a evidência extra que um operador pode validar. Falha técnica vira nova tentativa, nunca decisão sobre quem é o dono.
• CPF comprovado vence e-mail e senha. Quando uma fonte confiável atesta que a pessoa é a titular, ela recupera a conta que tem o CPF — e-mail, senha e telefone cadastrados por terceiro não têm poder de veto. Depois, ela mesma consulta a trilha do que aconteceu, sem depender do suporte.

• A régua inteira, sempre. Todos os planos visíveis com o atual marcado, mesmo para quem já assina. Esconder os outros planos é o que empurra para o cancelamento.
• Timing assimétrico de propósito: subir vale agora (cobra e entrega na hora); descer vale na próxima renovação (nada cobrado no meio, nada confiscado) — é o aviso da tela abaixo, dito antes de abrir a store.
• Nunca uma segunda assinatura em paralelo. Trocar é substituição — as duas stores fazem, mas só se o app pedir do jeito certo. E quem assinou numa store vê o plano em qualquer aparelho, sem receber ali o botão de assinar de novo.
• Desistir da descida sem pagar de novo. A Play recusa «trocar» para o plano atual — a volta passa por um plano gêmeo invisível (mesmo preço, benefício e nome), sempre agendada, nunca cobrada. Só o Android precisa; a Apple resolve pela reescolha no grupo.

• Um período pago, um período de benefício. Cada cobrança da store tem um número próprio, e é ele que libera o benefício — uma vez. Consequência elegante: carência, pausa e cartão em retentativa não cobram → não liberam nada, sem regra especial para cada caso.
• Repetir nunca duplica. Reabrir o app, reenviar a compra, receber o mesmo aviso duas vezes ou fora de ordem — tudo cai na mesma trava e volta «já entregue».
• Excluir a conta não zera a trava. Um recibo anônimo — sem dono, sem nome, sem valor — sobrevive à exclusão e impede que o mesmo pagamento vire benefício de novo numa conta nova. E é justamente por não ter dono que ele pode ficar: não é dado pessoal.

• A disponibilidade de cada ação vem do servidor, com o motivo escrito. «Apple não permite» e «sem assinatura ativa» são fatos do estado — e são textos diferentes de «não suportado», que se leria como ainda não fizemos. Recalcular isso no cliente divergiria no primeiro ajuste.
• Valor sai cru, como está armazenado. O número viaja exato até a tela, sem nenhuma camada arredondar no caminho — arredondar esconderia justamente a divergência que se veio conferir.
• Data em UTC, marcada como UTC, com o relativo ao lado e nunca no lugar — o absoluto confere contra banco e log, o relativo lê sem contar dia de cabeça.
• «Sem registro» onde ninguém mediu — nunca travessão. Travessão se lê como «nunca aconteceu», que é afirmar um fato não medido.
• Pendência não se sinaliza no app de operação. Nada de «em breve» nem botão morto: uma tela só entra quando faz o que promete. O que aparece é indisponibilidade daquela pessoa, com motivo.

• Responder é persistir → transmitir → avisar → entregar, nessa ordem: só se transmite o que já está gravado, e falha de push não desfaz a resposta.
• A falha do WhatsApp volta para a tela do operador com a causa distinguida: janela de 24h fechada (a pessoa precisa escrever primeiro) não é a mesma coisa que token vencido (troca de configuração) — e nenhuma das duas é «tentar de novo às cegas».
• Visitante e WhatsApp não têm pessoa — e a tela diz isso. Casar conversa de WhatsApp com um cadastro só quando o telefone for verificado; antes disso o palpite viria de um campo que qualquer um edita.

• Ativar uma store e não a outra — caso real no ar: a mesma campanha com Apple inativa e Google ativa.
• Absorver as divergências que a store impõe — as boas-vindas têm duração diferente por store porque a Play recusou o formato de 1 mês; a diferença fica registrada, não é forçada uma simetria que a store não aceita.
• Oferta não se apaga, se desativa. O identificador é imutável na store e o histórico de quem recebeu aponta para ela. Desligar preserva a trilha; apagar a quebraria.
• O cadastro valida na entrada o que o envio recusaria depois — inclusive a regra de store mais traiçoeira: o tipo de oferta que a Apple aceita para quem já assinou não serve para quem nunca assinou, e o catálogo recusa essa combinação na hora do cadastro em vez de deixá-la falhar na frente do operador.

o ciclo de vida de cada convite, auditável ponta a ponta:

  criada ──▶ enviada ──▶ aberta ──▶ resgatada
                   └──▶ expirada · cancelada · inelegível · recusada pela store

  «resgatada» é quando a store confirma a cobrança COM a condição —
  tocar no botão não resgata; abrir a folha da store não resgata.

• O desconto não mexe no benefício. Quem aceita 50% recebe o benefício cheio do plano. Desconto que corta benefício é rebaixamento disfarçado, e a pessoa percebe na primeira renovação.
• Aceitar usa a mecânica de sempre. Ficar com desconto compra o próprio plano; subir com desconto é a troca normal. Nunca nasce uma segunda assinatura em paralelo.
• O mesmo desenho vale para compra avulsa: pacote único com desconto, apontando sempre para um produto real da store, e o benefício continuando a nascer só da compra confirmada.

using Bullgate.Access.AspNetCore;

builder.Services.AddBullgateAccess(options =>
{
    options.BaseAddress = new Uri(configuration["Bullgate:Access:BaseUrl"]!);
    options.IntegrationCredential = configuration["Bullgate:Access:IntegrationCredential"]!;
});

builder.Services
    .AddAuthentication(BullgateAccessDefaults.AuthenticationScheme)
    .AddBullgateSession();

app.UseBullgateAccessFailures();
app.UseAuthentication();
app.UseAuthorization();

app.MapBullgateAccess<ProductRegistration, ProductProfile>();

const {
  BullgateAccessProvider,
  useBullgateAccess,
  useBullgateRegistration,
  useBullgatePhoneManagement,
  useBullgatePasswordRecoveryByPhone,
} = createBullgateExpoAccess({
  transport: createBullgateFetchTransport({
    baseUrl: () => process.env.EXPO_PUBLIC_API_URL,
  }),
  nativeClientId: process.env.EXPO_PUBLIC_BULLGATE_NATIVE_CLIENT_ID,
});

• 01 Uso como laboratório Rodar seu app sobre a plataforma, com usuário e cobrança reais, e reportar o que quebrar. Bug de produção vale mais que roteiro de teste.
• 02 Trabalhar como desenvolvedor Pôr a mão no código: .NET, PostgreSQL e React Native — continuidade de conta, billing nas duas stores, oferta dirigida.
• 03 Ideias e sugestões Apontar o que está errado, o que falta, o que ninguém pensou. Não precisa programar para melhorar o produto.
• 04 Infraestrutura Servidor, máquina de build, banco, ambiente de teste, aparelho para validar compra nas stores. Emprestado serve.
• 05 Créditos de IA Crédito de API que sobra no mês, licença ociosa.
• 06 Contas para integrar Adquirente e meio de pagamento, conta bancária, WhatsApp Business, redes sociais. Sandbox ou produção — sem conta real, integração não se testa.
• 07 Custos fixos Conta de desenvolvedor nas stores, certificado, envio de SMS.