Se o botão Publish ou Update mostrar "Your Cloud Balance is insufficient to publish" ou "Your Cloud Balance is insufficient to update," sua carteira Cloud ficou sem saldo.

Para corrigir isso:

1. Vá para Settings > Cloud & AI para verificar seu saldo atual.

2. Selecione Top up now e adicione fundos à sua carteira Cloud.

3. Volte ao painel Publish e tente novamente.

Observação: sua carteira Cloud é separada dos créditos da sua assinatura. A carteira Cloud financia serviços de hospedagem e implantação, enquanto os créditos da assinatura são usados para conversas com agentes de IA.

1. Verifique a visualização de uso de armazenamento e identifique os maiores chats, projetos e arquivos.
2. Baixe ou faça backup de qualquer coisa que você possa precisar depois.
3. Exclua apenas os itens desnecessários. Se a exclusão de chat oferecer a remoção dos dados de disco associados, selecione essa opção somente após confirmar que os dados podem ser descartados com segurança.
4. Atualize a página e confirme que o armazenamento disponível aumentou.
5. Volte para Publish e tente novamente uma vez.

A exclusão pode ser permanente e pode quebrar um projeto que faça referência a um arquivo removido. Se o uso não diminuir, entre em contato com o Support com a visualização de armazenamento, plano, link do projeto e horário da falha na publicação.

Aguarde a conclusão da verificação de segurança e depois revise cada item sinalizado antes de publicar.

1. Selecione Resolve All e inspecione o comportamento afetado. Corrija problemas envolvendo segredos expostos, autenticação, permissões, dados do usuário ou acesso externo inseguro antes do uso em produção.
2. Se um segredo pode ter sido exposto, remova-o do projeto e faça sua rotação por meio do provedor relevante antes de publicar.
3. Execute a verificação novamente e valide o fluxo afetado.
4. Use Publish Anyway apenas quando um revisor responsável entender e aceitar o risco restante, não crítico. Registre o motivo e evite ignorar um risco não resolvido em um site de produção.

Se você não conseguir determinar o impacto de um achado, não publique. Entre em contato com o Support ou com o responsável pela sua segurança com o texto do achado e evidências sanitizadas.

1. Teste separadamente a URL de produção da plataforma e o domínio personalizado. Compare também a página raiz com a página específica ou o caminho de API que falha.
2. Registre o código de status exato, a URL completa, horário e fuso horário, e se a falha é constante ou intermitente.
3. Verifique o status da implantação mais recente e se uma alteração recente em dependência, variável de ambiente, banco de dados ou serviço externo coincide com o início da falha.
4. Capture erros relevantes do Console e da Network.

Se a falha continuar, entre em contato com o Support com as etapas de reprodução, a versão afetada e diagnósticos sanitizados. Antes de enviar um HAR, saída de comando ou captura de tela, remova cookies, cabeçalhos Authorization, tokens, parâmetros secretos de consulta, dados pessoais e informações de pagamento.

Se sua implantação expirar ou o site ao vivo ficar temporariamente indisponível:

1. Verifique se tanto o subdomínio Prod da plataforma quanto o Preview estão inacessíveis, ou apenas um deles.

2. Mantenha a página de erro atual visível — não clique repetidamente em Publish.

3. Verifique se você modificou recentemente dependências, pontos de entrada de inicialização ou conexões com banco de dados, pois essas alterações podem afetar a implantação.

Se o problema persistir, entre em contato com o Support e inclua:

- Link do projeto e URL ao vivo

- Horário da falha e seu fuso horário

- Número da versão e captura de tela da página de erro

- Se o Preview está funcionando normalmente

- Se você modificou recentemente dependências, entrada de inicialização ou conexão com banco de dados

Se o painel Publish mostrar "latest" com o botão acinzentado, ou ficar travado em "Building":

1. Não clique repetidamente em Publish — isso não vai acelerar o processo e pode criar tarefas de build duplicadas.

2. Aguarde alguns minutos e atualize a página.

3. Se o status não mudar após atualizar, entre em contato com o Support.

Inclua o seguinte ao entrar em contato com o Support:

- Link do chat

- Captura de tela completa do painel Publish (incluindo URL da página, número da versão e status do botão)

- Horário da ocorrência e seu fuso horário

- Número da versão exibido no momento

- Em qual etapa começou a mostrar "Building" ou o botão ficou acinzentado

1. Verifique se a imagem está ausente no Visualizador de App, no site publicado ou em ambos.
2. Selecione Reload App Viewer uma vez. Se o problema ocorrer apenas no site ao vivo, confirme que a versão mais recente foi publicada ou atualizada.
3. Informe ao Agente a página, a imagem que deveria aparecer e de onde a imagem veio originalmente. Peça para ele verificar se o projeto atual ainda usa o nome e o local corretos da imagem.
4. Se a imagem original foi removida ou renomeada, faça upload ou selecione novamente a imagem pretendida e depois teste a página novamente.
5. Se a imagem usa Armazenamento do App ou outro serviço conectado, confirme que o serviço pretendido está conectado e que o arquivo ainda existe lá.

Se a imagem ainda não carregar, entre em contato com o Atoms Support com o Chat Link, a URL da página afetada, o nome ou origem da imagem e uma captura de tela. Não inclua links de acesso privado, senhas, chaves ou tokens.

Se o pacote self-host exportado for baixado com sucesso, mas não funcionar ao executar:

1. Verifique o README incluído no pacote de exportação para ver os requisitos de ambiente e as etapas de configuração.

2. Verifique se seu ambiente de execução corresponde aos requisitos (versão do SO, versão do Docker, versão do Node.js).

3. Execute o comando de inicialização e revise toda a saída em busca de mensagens de erro.

Se o problema persistir, entre em contato com o Support e inclua:

- Versão da exportação e horário do download

- SO em execução e versão do Docker

- Comando completo executado e saída completa

- Script ou caminho de API que falhou

- Método de implantação esperado

Importante: anexe um exemplo de configuração sanitizado, mas NÃO inclua senhas, segredos ou tokens.

O Visualizador de App e o site publicado mostram estágios diferentes do seu projeto. Salvar uma alteração visual não atualiza o site ao vivo por si só.

1. Em Design, selecione Save e aguarde a conclusão da tarefa atual do Agente ou do build.
2. Abra Publish. A publicação usa a versão mais recente do projeto; não há seletor de versão no painel Publish.
3. Selecione Publish para a primeira liberação ou Update para uma liberação posterior. Aguarde até que o painel mostre Up to date.
4. Abra o site ao vivo em uma nova aba e recarregue-o uma vez.
5. Se o endereço padrão da Atoms mostrar a alteração, mas um domínio personalizado não, verifique a conexão do domínio em vez de publicar a mesma versão repetidamente.

Se o site ao vivo ainda mostrar a versão errada, entre em contato com o Atoms Support com o Chat Link, a URL ao vivo, a versão que você pretendia publicar, o horário e fuso horário, e capturas de tela do Visualizador de App e do site ao vivo.

1. Contenha o risco imediato. Se a liberação expuser dados sensíveis ou criar um comportamento inseguro, abra App Status e use Pause para um app Atoms Cloud elegível ou Unpublish para remover o acesso público. Se não houver risco ativo, evite causar uma indisponibilidade desnecessária.
2. Registre o domínio afetado, horário da publicação, versão atual, versão pretendida e impacto no negócio.
3. Depois que a tarefa atual do agente parar, abra Versions, escolha a última versão conhecida como boa e selecione Restore this version.
4. Verifique a versão restaurada no Preview, incluindo fluxos críticos de login, pagamento e dados, e depois publique ou atualize-a.

Restaurar uma versão do projeto pode não reverter alterações no banco de dados de produção ou ações externas. Não sobrescreva nem exclua dados de produção para imitar um rollback. Entre em contato com o Support imediatamente quando houver dados, credenciais, pagamentos ou alterações destrutivas envolvidos.

1. Pare ou aguarde a tarefa atual do agente; uma versão não pode ser restaurada enquanto houver trabalho conflitante ativo.
2. Abra Versions, localize a última versão conhecida como boa e selecione Restore this version.
3. Revise o projeto restaurado no Preview e teste os fluxos críticos que mudaram.
4. Publique ou atualize somente depois que o resultado no Preview estiver correto.

A restauração de uma versão do projeto não necessariamente reverte registros do banco de dados de produção, alterações de esquema, variáveis de ambiente, pagamentos, e-mails ou outras ações externas. Se a liberação alterou dados de produção ou a versão de destino não estiver disponível, pare e entre em contato com o Support com os dois números de versão, o domínio afetado e o resultado necessário de preservação de dados.

Pause e Unpublish são duas ações diferentes:

Pause (somente projetos Atoms Cloud):

- O app fica indisponível para visitantes.

- Os recursos do servidor permanecem alocados e a cobrança continua.

- Você pode retomar o app a qualquer momento em App Status.

Unpublish (todos os projetos):

- O site fica completamente offline. Qualquer pessoa usando a URL publicada perde o acesso.

- Para projetos Atoms Cloud, os recursos do servidor são liberados.

- Você pode publicar o projeto novamente depois, mas os visitantes não poderão acessá-lo até que isso aconteça.

Use Pause para uma retirada temporária com reinício rápido. Use Unpublish para remover totalmente o site.

Se o navegador mostrar "too many redirects" ou a página continuar recarregando sem exibir conteúdo:

1. Tente o subdomínio Prod padrão da plataforma (não o seu domínio personalizado) para determinar se o loop de redirecionamento é causado pela configuração do domínio ou pelo próprio aplicativo.
2. Se o subdomínio Prod padrão funcionar, verifique as configurações de DNS do seu domínio personalizado e seu registrador de domínio em busca de regras de redirecionamento que possam entrar em conflito com a plataforma.
3. Limpe o cache do navegador ou teste em uma janela anônima para descartar redirecionamentos em cache.

Se o problema persistir, entre em contato com o Support e inclua:

- URL completa mostrando o loop de redirecionamento

- Se o subdomínio Prod padrão está acessível

- Nome do domínio e provedor de DNS

- Captura de tela completa do erro

Se seu app funciona no Preview, mas falha em produção devido a variáveis de ambiente ausentes ou vazias:

1. Verifique se a variável de ambiente foi salva antes ou depois da última publicação. Se foi salva depois, você precisa publicar novamente para que a alteração tenha efeito.
2. Verifique se a variável está definida para o ambiente correto (Development vs. Production).
3. Verifique se a mensagem de erro do serviço downstream dá alguma pista — por exemplo, "unauthorized" geralmente significa que uma chave de API está vazia ou incorreta naquele ambiente.

Se o problema persistir, entre em contato com o Support e inclua:

- Link do projeto ou URL ao vivo

- O nome da chave afetada e em qual ambiente está o problema

- O erro completo do serviço downstream

- Uma captura de tela sanitizada da página de configuração

- Se a configuração foi salva antes ou depois da publicação

Importante: forneça apenas os nomes das chaves. NÃO envie valores secretos, senhas ou tokens.

Os achados podem usar redação semelhante enquanto apontam para locais diferentes. Redação semelhante não significa necessariamente que os resultados sejam duplicados.

1. Compare o nome do achado e o local mostrado para cada resultado.
2. Revise cada local único em vez de descartar a redação repetida.
3. Se vários achados tiverem a mesma causa subjacente, corrija essa causa e depois verifique cada local novamente.
4. Execute a verificação de segurança novamente na versão atualizada.

Se o mesmo achado e local ainda aparecerem mais de uma vez, entre em contato com o Atoms Support com o Chat Link, horário da verificação e fuso horário, número de achados e uma captura de tela com informações ocultadas. Remova quaisquer senhas, chaves, tokens ou outras informações sensíveis que possam aparecer em um achado.

Uma verificação concluída sem achados relatados é uma checagem útil, mas não pode garantir que todo problema de segurança ou de execução tenha sido encontrado. A verificação analisa a versão selecionada do projeto; seu app ainda precisa ser testado da forma como usuários reais o utilizarão.

Antes de publicar, teste as jornadas importantes no seu app, incluindo login, papéis de usuário, acesso a dados privados, pagamentos e serviços conectados. Use contas de teste separadas para diferentes papéis e confirme que cada conta pode acessar apenas as informações e ações destinadas a ela.

Se você descobrir um problema em produção que possa expor contas, dados privados, pagamentos ou credenciais, pare de usar ou restrinja o acesso ao recurso afetado primeiro. Faça a rotação de qualquer credencial que possa ter sido exposta e depois entre em contato com o Atoms Support com o Chat Link, a versão afetada, etapas para reproduzir o problema, horário e fuso horário, e uma captura de tela com informações ocultadas. Não compartilhe a credencial exposta em si.

Se a verificação relatar que uma ação somente de administrador pode estar desprotegida, trate o achado como não resolvido até confirmar que usuários não autorizados não podem usá-la. Ocultar um botão de administrador não é suficiente se a ação ainda puder ser solicitada de outra forma.

1. Abra o achado e identifique a ação ou local que ele nomeia.
2. Decida quais papéis autenticados devem ter permissão para usar essa ação.
3. Peça ao Agente para verificar a permissão do usuário quando a ação for solicitada, e não apenas quando o botão for exibido.
4. Teste a ação estando desconectado, com uma conta de teste normal e com uma conta de teste de administrador autorizada.
5. Confirme que tentativas rejeitadas não revelam dados privados nem fazem alterações, e depois execute a verificação de segurança novamente.

Não publique o recurso afetado se uma conta não autorizada ainda puder usar a ação. Entre em contato com o Atoms Support com o Chat Link, o texto do achado, a versão afetada e uma captura de tela com informações ocultadas se você não conseguir resolvê-lo.

HTTPS protege as informações enquanto elas trafegam entre um usuário e um serviço. Se a verificação relatar um problema de HTTPS, use o achado exato para identificar o endereço, recurso, callback ou configuração de domínio afetado.

1. Abra o achado e anote o local e endereço exatos que ele informa.
2. Peça ao Agente para substituir essa conexão específica pelo endereço seguro suportado pelo provedor, ou para corrigir a configuração de domínio relacionada.
3. Não ignore avisos de certificado nem altere um endereço às cegas se o serviço externo não documentar um equivalente seguro.
4. Teste novamente a jornada do usuário afetada e confirme que nenhuma senha, token, detalhe de pagamento ou informação privada é enviada por uma conexão insegura.
5. Execute a verificação de segurança novamente na versão atualizada.

Se o achado envolver um domínio personalizado ou certificado que você não consegue corrigir, entre em contato com o Atoms Support com o Chat Link, a URL afetada, o texto do achado, horário e fuso horário, e uma captura de tela com informações ocultadas.

Row Level Security, ou RLS, é um recurso do Supabase que controla quais linhas do banco de dados cada usuário pode ler ou alterar. Esse achado é relevante apenas quando o projeto usa Supabase e a verificação identifica uma tabela cujas regras de acesso precisam ser revisadas.

1. Abra o achado e identifique a tabela que ele nomeia.
2. Anote quem deve poder visualizar, adicionar, editar ou excluir os dados dessa tabela.
3. Peça ao Agente para criar as políticas Supabase menos permissivas que deem suporte a essas jornadas de usuário.
4. Teste estando desconectado e com uma conta de teste separada para cada papel. Confirme que cada conta pode acessar apenas as linhas e ações pretendidas.
5. Execute a verificação de segurança novamente após aplicar as políticas.

Não desative o RLS nem permita todos os usuários apenas para limpar o aviso. Antes de fazer uma alteração que possa afetar dados existentes, confirme o plano e mantenha um backup ou exportação segura, quando apropriado. Nunca compartilhe chaves do Supabase ou credenciais do banco de dados no Chat ou em capturas de tela.