FAQ de verificação de deploy e primeiro login do Emdash CMS

Publicado em 2026-04-08 por Emdash Cms Everything

O que verificar primeiro após o deploy?

Sequência de aceitação em três camadas:

1. Front-end acessível: a página inicial retorna o conteúdo esperado.
2. Admin acessível: /_emdash/admin carrega.
3. Dados graváveis: criar e ler um item de conteúdo.

Só acessibilidade de rotas não completa o deploy.

Por que o front pode funcionar e a inicialização do admin falhar?

Causas comuns:

• incompatibilidade de bindings (DB, MEDIA, etc.)
• variáveis de ambiente ou segredos ausentes
• configuração não suportada mantida para o plano Free

Ordem de triagem recomendada: bindings primeiro, variáveis de ambiente depois, restrições de tier por último.

O que acontece no primeiro login no admin?

Tipicamente:

• criação da identidade de admin
• registro de credenciais (como Passkey)
• escrita do estado inicial do sistema

Depende do navegador e da conta. Conclua em rede estável e navegador suportado.

O que checar primeiro se a configuração de Passkey falhar?

Nesta ordem:

• suporte do navegador e disponibilidade de Passkey
• precisão do relógio do sistema
• problemas de cross-origin ou cabeçalhos de proxy reverso

Não comece suspeitando do banco — a maioria das falhas de auth é cliente ou proxy de borda.

O que é um script mínimo de aceitação em produção?

Fluxo repetível:

1. Abrir a home do front e registrar a resposta.
2. Entrar no admin e completar a configuração inicial.
3. Criar e publicar um conteúdo de teste.
4. Enviar um arquivo de mídia e verificar a recuperação.
5. Confirmar que o conteúdo publicado aparece no front.

Isso valida rota, auth, escrita, armazenamento e leitura.

O deploy parece bem-sucedido, mas falta conteúdo. Por onde começar?

Diagnóstico mais curto:

1. O item está publicado (não rascunho)?
2. O front consulta a coleção esperada?
3. Verificar logs de runtime por erros de consulta ou permissão.

A maioria dos casos de conteúdo ausente é estado ou caminho de consulta, não indisponibilidade da plataforma.

Como as equipes institucionalizam a qualidade de aceitação?

Incluir no fluxo de release:

• pré-merge: aceitação em três camadas em local ou staging
• pós-release: engenheiro de plantão executa o script mínimo em até 10 minutos
• pós-incidente: adicionar uma nova verificação determinística para evitar recorrência

Lançamentos confiáveis vêm de controles de processo, não de memória tribal.

Trecho de comandos de verificação

# Exemplos de checagens em runtime
curl -I https://your-site.workers.dev
curl -I https://your-site.workers.dev/_emdash/admin
npx wrangler tail your-worker-name