Replit: do planejamento ao teste do primeiro aplicativo

Interface em inglês no vídeo: a gravação oficial incorporada tem cerca de dez minutos e demonstra o aplicativo Taste no Replit Agent 4. O passo a passo abaixo segue a documentação consultada em 4 de novembro de 2026, sem pressupor que toda conta tenha a mesma interface da gravação.

Um catálogo abre, os cartões aparecem e o botão de favoritos muda de cor. Isso ainda deixa perguntas: o filtro funciona junto com os favoritos? O detalhe mostra o livro certo? O link enviado a outra pessoa abre? No Replit, o primeiro aplicativo fica mais fácil de avaliar quando você transforma essas perguntas em critérios antes de pedir a construção.

Este guia acompanha um exemplo fictício: um catálogo para um clube de leitura, com três livros inventados e favoritos mantidos apenas durante o uso. Ele serve para explicar planejamento, checkpoints, testes em Preview e publicação. Nenhum aplicativo foi criado ou testado para escrever este artigo. As instruções de produto foram conferidas na documentação oficial em 4 de novembro de 2026.

Defina um primeiro resultado verificável

O clube fictício quer apresentar três títulos: “Mapa das Janelas”, “O Jardim Azul” e “Cartas do Farol”. Cada cartão precisa mostrar título, categoria e uma descrição curta. A pessoa deve filtrar a lista, abrir um detalhe e marcar um favorito. O projeto inicial termina aí: sem inscrição, pagamento, envio de mensagens ou integração com uma biblioteca real.

Essa fronteira permite avaliar uma experiência completa sem simular uma operação que ainda não existe. Se o botão disser “Reservar exemplar”, o público poderá entender que existe uma reserva. Para este protótipo, “Adicionar aos favoritos” descreve melhor o efeito esperado. A interface deve explicar que a seleção é temporária; se depois houver necessidade de salvar escolhas entre visitas, isso vira outro requisito.

O guia oficial de primeiro aplicativo recomenda definir um resultado, critérios observáveis e limites para o que ainda não será construído. Para organizar essas instruções antes de abrir o produto, o guia de briefing para agentes de código ajuda a descrever objetivo e conclusão, embora os controles do Replit sejam próprios.

Comece pelo Website no Replit

A documentação de início exige uma conta e usa o Replit Agent em Free Mode para um projeto pequeno. O nome desse modo não autoriza presumir hospedagem, serviços ou qualquer quantidade de trabalho sem cobrança. Confira as condições mostradas na sua conta antes de aceitar uma mudança de modo ou adicionar recursos.

No fluxo descrito pelo guia, abra uma conversa e escolha Website como o artefato. Algumas interfaces mostram Output; outras oferecem Add attachment, Create something new e Website. No desktop também pode existir o caminho New, na barra lateral. A indicação importante é o resultado selecionado: um site ou aplicativo web para esse exercício.

Escolha o modo indicado na sua interface e envie um pedido de escopo pequeno. A documentação mostra o Agent planejando, construindo e iniciando a visualização. Acompanhe a conversa até existir uma versão acessível em Preview. Uma mensagem de conclusão ajuda a localizar a entrega, mas a verificação das funções virá quando você usar o aplicativo.

O vídeo oficial mostra uma demonstração do aplicativo Taste no Replit Agent 4, com interface em inglês. Os trechos conferidos apresentam o Canvas, versões de uma página e o aplicativo de referências visuais. É uma gravação do fornecedor, não uma execução do catálogo fictício deste artigo; os controles podem diferir dos disponíveis na sua conta.

Escreva o pedido inicial com critérios de conclusão

O pedido abaixo é autoral e fictício. Ele descreve o comportamento esperado; não é uma transcrição de uma execução nem a promessa de que uma única mensagem produzirá uma versão pronta.

Crie um catálogo web para um clube de leitura fictício. Use somente três livros de exemplo: Mapa das Janelas, categoria crônica; O Jardim Azul, categoria conto; Cartas do Farol, categoria crônica. Mostre título, categoria e descrição curta em cada cartão. Permita filtrar por categoria, abrir o detalhe do livro e adicionar ou remover favoritos durante a sessão. Inclua uma visualização dos favoritos. A interface deve funcionar em largura de celular. Não adicione login, banco de dados, reserva de exemplares, pagamento ou serviços externos. Explique na tela que os dados são fictícios e que os favoritos são temporários.

Depois, peça que o Agent indique quais partes implementou e onde você deve conferi-las. Não acrescente catálogo ilimitado, painel administrativo e conta de usuário ao perceber o primeiro cartão bonito. Essas mudanças alteram o tamanho do projeto e introduzem decisões sobre armazenamento, acesso e operação.

Antes de enviar, releia cada verbo: filtrar, abrir, adicionar, remover e visualizar. Todos podem virar uma ação manual de teste. Já “moderno”, “completo” e “profissional” não dizem o que deve acontecer ao clicar. Você pode descrever aparência, mas precisa de critérios funcionais para decidir se a primeira versão cumpriu o pedido.

Teste a primeira versão no Preview

Abra o Preview e percorra o catálogo como visitante. Comece pela lista completa; depois filtre por crônica e confira se aparecem os dois títulos previstos. Abra “Cartas do Farol” e veja se o detalhe corresponde ao cartão selecionado. Volte à lista e repita com “O Jardim Azul”, evitando aprovar uma navegação que funciona apenas para o primeiro item.

Adicione um título aos favoritos, abra essa visualização e remova-o. Confira se o estado do botão acompanha a mudança nas duas telas. Em seguida, combine ações: filtre, escolha um livro, volte e abra os favoritos. Essas sequências revelam problemas que não aparecem quando cada botão é avaliado isoladamente.

Reduza o Preview para uma largura de celular, conforme o próprio quickstart recomenda. Leia as descrições, abra o menu, role e tente tocar nos controles. Observe se o filtro esconde o botão de voltar ou se o título fica cortado. Registre o tamanho e a sequência do erro para o próximo pedido.

Confira também a seleção vazia: remova todos os favoritos e abra essa visualização. No exemplo proposto, ela deve explicar que ainda não há livros selecionados e oferecer um caminho de volta ao catálogo. Uma tela em branco deixa a pessoa sem saber se a lista está vazia ou se o aplicativo falhou. Esse é um critério que você deve solicitar e verificar, não um comportamento que este artigo tenha observado em um app construído.

Monte uma sequência de teste que permita repetir o erro

No catálogo fictício, comece cada rodada pelo mesmo ponto: lista completa e nenhum favorito selecionado. Anote esse estado inicial junto ao pedido. Se uma rodada começar com dois livros já marcados e outra começar vazia, uma diferença na tela pode ser apenas consequência da preparação, não uma correção feita pelo Agent.

Uma sequência útil seria abrir o filtro de crônicas, marcar “Mapa das Janelas”, trocar o filtro para contos e marcar “O Jardim Azul”. Depois, abra os favoritos. A expectativa do exercício é ver os dois títulos, pois essa visualização representa a seleção feita, independentemente do filtro usado antes. Se você preferir outro comportamento, escreva essa regra antes de solicitar a implementação.

Remova “Mapa das Janelas” na tela de favoritos e volte à lista completa. O cartão correspondente deve indicar que ele já não está selecionado. Repita a remoção com o segundo livro e confira o estado vazio. Em vez de uma área em branco, o pedido pode prever uma mensagem como “Você ainda não selecionou livros”, acompanhada de uma forma de voltar ao catálogo.

Por fim, escolha o que “temporário” significa nesse protótipo. Para este exemplo, defina que recarregar a página reinicia a seleção e peça que a interface explique isso. Essa é uma regra fictícia de projeto, não uma característica garantida do Replit. Se o aplicativo conservar favoritos após recarregar, compare a implementação com a regra escrita antes de aceitar o resultado.

Quando surgir um defeito, registre ação, expectativa e observação: “Depois de remover o título nos favoritos e voltar à lista, o cartão continua marcado”. Evite enviar apenas “os favoritos estão errados”. A sequência concreta ajuda a pedir uma mudança delimitada e permite repetir a mesma verificação depois, sem inventar um novo critério a cada rodada.

Encontre o checkpoint que corresponde à mudança

Os checkpoints são pontos de recuperação criados automaticamente pelo Agent em momentos do desenvolvimento. A documentação de checkpoints e rollbacks explica que eles preservam arquivos e contexto do projeto, incluindo informações que vão além do código. Há descrições e horários para ajudar a localizar cada estado.

No exemplo, procure o checkpoint correspondente à lista e aos detalhes que você já verificou, antes de pedir uma mudança nos favoritos. Leia a descrição e confira a sequência. Se a identificação não estiver clara, investigue qual alteração pertence a cada ponto antes de escolher um destino de recuperação.

A documentação apresenta checkpoints na aba Agent, no painel Git e na visualização de histórico. Ela também recomenda commits Git manuais para um histórico de longo prazo. Para um primeiro projeto, o objetivo imediato é relacionar pedido, alteração e verificação: “este estado tem o filtro funcionando”, em vez de apenas “este é o mais recente”.

Confira o alcance de um rollback antes de confirmar

Na aba Agent, o caminho documentado é localizar um checkpoint, selecionar Rollback to here, revisar o aviso e confirmar. Depois da restauração, volte ao aplicativo e repita as verificações. Um retorno de código não comprova, sozinho, que o fluxo esperado ficou correto.

O cuidado principal está no banco: por padrão, o rollback não o altera. Para incluir o banco de desenvolvimento, a documentação manda selecionar Database em Additional rollback options. A restauração do banco de produção tem um procedimento separado; não acontece automaticamente por esse controle.

Isso importa quando o projeto crescer. Se uma versão mudar o código e o formato dos dados, recuperar somente uma parte pode deixar os dois incompatíveis. No catálogo fictício inicial não há banco. Em um aplicativo real com dados, antes de confirmar a recuperação, avalie o escopo, as alterações posteriores e quem depende delas. O guia de permissões e governança para agentes de código ajuda a formular essas responsabilidades, sem substituir as instruções do Replit.

Escolha entre corrigir a mudança e voltar a um checkpoint

Imagine que a primeira versão já filtra corretamente, mas uma alteração de aparência esconde o botão de voltar no celular. Existem duas decisões diferentes: pedir uma correção pontual sobre o estado atual ou retornar a um estado anterior e refazer a alteração. O checkpoint ajuda a localizar essa fronteira; ele não decide qual opção faz mais sentido para o projeto.

Antes de voltar, compare o que funcionava no checkpoint escolhido com o que foi acrescentado depois. Se o filtro e os favoritos foram implementados após aquele ponto, retornar pode remover também essas melhorias. No exemplo, registre três referências: último estado em que o menu funcionou, mudança que introduziu o problema e estado atual que precisa ser preservado para comparação.

Depois de um rollback, não confira somente a aparência do menu. Repita o percurso principal: lista, filtro, detalhe, favoritos e retorno. A documentação recomenda verificar o estado restaurado; para este catálogo, esse percurso representa a verificação concreta. Um checkpoint com nome ou horário promissor ainda precisa corresponder à versão que você pretendia recuperar.

Se o projeto evoluir e ganhar banco, faça outra pergunta antes de confirmar: a intenção é recuperar código ou também dados de desenvolvimento? O procedimento documentado trata a restauração do banco de desenvolvimento como uma escolha adicional, e a recuperação de produção tem outro caminho. Não use um rollback de código como prova de que um dado apagado em produção foi recuperado.

No protótipo sem banco deste artigo, basta registrar o estado esperado e o que foi observado depois da operação. Em um projeto com armazenamento, acrescente quais dados devem existir e em qual ambiente. Essa separação evita que uma tela restaurada seja interpretada como confirmação de uma recuperação que não foi conferida.

Peça uma correção delimitada e repita o teste

Se remover um favorito na tela de detalhe não atualizar a lista, descreva exatamente isso: “Adicionei Cartas do Farol, abri o detalhe e removi o favorito. Na lista, ele continua marcado. Faça as duas visualizações refletirem a mesma seleção, mantendo filtros e navegação”. Esse pedido delimita a falha e preserva comportamentos que já foram verificados.

Após a alteração, repita a sequência original e uma combinação próxima, como remover o item pela lista de favoritos. Se os dois caminhos funcionarem, confira também o filtro e o detalhe. A recomendação do quickstart é fazer melhorias focadas; ela evita misturar uma correção de estado com uma reformulação completa da interface.

Quando a falha não estiver bem localizada, informe o que esperava, o que aconteceu e como reproduzir. Não transforme um sintoma em um diagnóstico inventado sobre o código. O Agent pode investigar a implementação; você continua responsável por confirmar o comportamento que pediu.

Revise domínio e acesso antes de selecionar Publish

O guia de publicação do Replit distingue o Preview, privado por padrão e temporário, de uma implantação de produção. Copiar o endereço de desenvolvimento não é o procedimento para distribuir publicamente o aplicativo.

No fluxo documentado, Publish fica no canto superior direito do editor enquanto você trabalha em Build. As configurações detalhadas ficam em Tools, Publishing, na seção Replit Cloud. Revise o domínio gerado e o nível de acesso. Public, Password protected, Workspace only e Invite only têm finalidades diferentes; escolha conforme quem deve usar a entrega e confira as opções disponíveis na sua conta.

Antes de confirmar, revise também as configurações de segurança, recursos e consumo exibidas. A documentação apresenta verificações de segurança na publicação, mas isso não transforma um protótipo em sistema aprovado para qualquer operação. O projeto fictício não contém dados privados nem serviços externos; um projeto com usuários reais precisa de decisões próprias sobre essas funções.

Confira a URL real e publique novamente quando mudar

Depois que a publicação terminar, abra a URL fornecida e percorra novamente lista, filtro, detalhe e favoritos. Faça essa conferência fora da visualização de desenvolvimento. O status de publicação informa que o processo terminou; não responde se o visitante encontra o livro correto ou consegue voltar ao catálogo no celular.

O editor e a versão de produção ficam separados. Se você corrigir uma descrição ou um botão no projeto, essa alteração não substitui automaticamente o aplicativo público. Teste no Preview e use Republish quando estiver pronto. A documentação informa que a nova versão mantém a URL; depois, abra esse endereço e confira o comportamento alterado.

Se a publicação falhar, examine o status e os logs para identificar a etapa antes de repetir a tentativa. Evite continuar mexendo em várias funções enquanto tenta entender qual versão foi entregue. Registre o que você publicou e quais ações verificou naquela URL.

Para acompanhar a entrega após o lançamento, a documentação distingue Monitoring de Growth. Monitoring mostra informações de funcionamento, como status HTTP, tempo de resposta, CPU e memória. Growth acompanha audiência e navegação. Um catálogo sem visitantes pode ainda não ter dados úteis nesses painéis. Se houver erro ao abrir uma página, investigue o funcionamento antes de interpretar a ausência de visitas como problema de divulgação. A configuração e a leitura desses painéis pertencem à implantação que você realmente publicou.

Faça uma conferência de publicação com o link que será compartilhado

Antes de publicar o catálogo fictício, escreva uma lista curta do que um visitante precisa encontrar: três livros de exemplo, filtro por categoria, detalhes corretos, favoritos temporários e aviso de que não há reserva. Use essa mesma lista no endereço publicado. A comparação deve avaliar a experiência do visitante, além da conclusão exibida no editor.

Abra a URL de publicação em um contexto adequado ao acesso escolhido. Se a intenção é acesso público, confira a página sem depender da sessão usada para editar. Se o projeto tiver acesso restrito, a expectativa é diferente: verificar o bloqueio e a entrada permitida faz parte da entrega. Não confunda conseguir abrir sua própria página com comprovar o acesso de outra pessoa.

Para reconhecer uma versão nova, escolha uma alteração pequena e visível, como trocar o título “Livros” por “Catálogo do clube”. Prepare e confira essa mudança no Preview. Depois do Republish, abra novamente a URL pública e procure o título novo. Esse exercício hipotético ajuda a identificar qual versão está no ar sem presumir que toda edição do projeto foi publicada.

Se o título novo aparecer, continue o teste funcional: filtre crônicas, abra um detalhe e adicione um favorito. Uma identificação visual confirma apenas aquela mudança. Se a publicação falhar, consulte o estado e os registros indicados pela documentação antes de repetir a operação. Registre a etapa que falhou, sem anunciar a versão como disponível enquanto a URL real não cumprir os critérios escolhidos.

Adicione dados e contas quando o fluxo exigir

Se o clube quiser guardar favoritos entre visitas, o requisito mudou. Será necessário decidir como identificar a pessoa e onde salvar sua seleção. Se quiser registrar empréstimos, entram disponibilidade, atualização dos registros e tratamento de conflitos. Essas decisões merecem outra etapa, com exemplos e testes próprios.

O quickstart oferece login, banco, pagamentos e integrações como próximos caminhos. Não é necessário adicioná-los para demonstrar toda ideia. Primeiro confirme qual problema continua sem solução no catálogo simples. Para a parte visual, o guia de interfaces no Google Stitch pode apoiar a discussão; para organizar uma primeira experiência de produto, veja também o guia introdutório de aplicativos com IA.

Perguntas frequentes sobre o primeiro app no Replit

O Preview do Replit já é o aplicativo público?

Não. A documentação descreve o Preview como privado por padrão, temporário e voltado ao desenvolvimento. Para distribuir a entrega, use Publish, revise o acesso e teste a URL de produção fornecida.

O rollback restaura automaticamente o banco de dados?

Não. O banco fica fora do rollback por padrão. O banco de desenvolvimento pode ser incluído em Additional rollback options, selecionando Database. A restauração do banco de produção tem procedimento separado.

Uma correção no editor aparece automaticamente no aplicativo publicado?

Não. Teste a mudança no Preview e use Republish para criar uma nova versão de produção. Depois confira a alteração na URL pública, que permanece a mesma conforme o guia oficial.

O primeiro aplicativo precisa de login e banco?

Depende da função desejada. O catálogo fictício deste guia usa apenas dados de exemplo e seleção temporária. Salvar informações entre visitas ou identificar usuários exige novos requisitos; não presuma que essas funções já existam.

O Replit é gratuito para qualquer projeto?

Este guia não faz essa promessa. O quickstart usa Free Mode em um exemplo pequeno, mas modos, recursos, publicação e consumo devem ser conferidos na conta e nas condições atuais antes de aceitar cobranças ou ampliar o projeto.

Fontes oficiais

A demonstração de Taste incorporada acima está na publicação oficial Live from Replit HQ: Agent 4 Launch Pt. 1. Ela ilustra uma aplicação criada no produto; os passos do catálogo fictício continuam baseados nos guias de início, checkpoints e publicação consultados abaixo.

Consulta em 4 de novembro de 2026: Build your first app, Checkpoints and Rollbacks e Publish your app. O catálogo e os pedidos são exemplos fictícios autorais; as verificações propostas não são relato de execução do produto.