Planejar a modernização e publicar com reversão

Um site que quebra em produção volta ao ar em segundos, com um clique de reversão. A hospedagem guarda cada publicação como um arquivo pronto, e por isso consegue promover a versão anterior de volta à principal.

Esse clique só existe porque um comando único barrou o defeito antes do envio. E o comando não depende da sua memória: uma esteira automática repete a mesma checagem a cada proposta de mudança.

O agente, o assistente de inteligência artificial que escreve código a partir do seu pedido, devolve trabalho com falhas previsíveis. Quando ninguém checa antes de publicar, são sempre as mesmas: tipo frouxo, aviso ignorado, nenhum teste.

Publicar é pôr a nova versão no ar para o cliente, e o defeito que escapa até ali já custa venda. O roteiro que faz o agente testar a tela como usuário fecha o buraco que a checagem automática não vê.

Encadeie três checagens num comando só, chamado verify, e rode-o antes de todo envio. São elas: a checagem de tipos, o padrão de código (a revisão automática de estilo, como o corretor ortográfico) e os testes.

Mire dez segundos de espera. Portão lento é portão que alguém pula na sexta-feira apertada, e portão pulado não protege ninguém. Ordene os passos para que o primeiro que falhar impeça os seguintes.

As ferramentas por trás desse comando mudaram em 2026. O Vite 8 com Rolldown 1.0 é o empacotador de motor único, estável desde março e maio de 2026. Empacotador é a ferramenta que junta os arquivos do site num pacote leve, como embalar o produto antes do envio.

O ganho é de cerca de 25 vezes num projeto de 19 mil módulos, e de duas a cinco vezes num projeto pequeno. Quem já está no Next.js 16 não escolhe: o Turbopack vem como padrão, salvo se a configuração antiga for complicada, caso em que o Rspack serve.

No padrão de código, o Biome substitui duas ferramentas antigas e lê tipos sem rodar o compilador completo. Fora do Tailwind (as classes utilitárias de estilo), o CSS passa pelo Lightning CSS.

O Storybook 10 é o catálogo onde cada componente (a peça reutilizada, como o botão) é testado sozinho, fora da tela em que ele aparece.

Os testes seguem a lógica de portão em degraus. O Vitest roda os testes de unidade em segundos. O Playwright abre o navegador de verdade para o teste de ponta a ponta e compara a foto do SVG compilado entre duas propostas. É o que pega o gráfico que sumiu sem ninguém tocar nele.

Dentro do Playwright, o axe-core é o portão de acessibilidade, a checagem de que a tela serve a quem usa leitor de tela ou só o teclado. Ele cobre de 30% a 40% dos critérios de sucesso, e o resto continua sendo revisão humana.

Esse mesmo motor move o relatório do Lighthouse e o painel do Chrome. Por isso ferramentas que parecem independentes devolvem o mesmo resultado. Pa11y e Lighthouse CI fecham o degrau, e o MSW simula o dado que viria da rede, para o teste não depender do servidor.

Rodar a checagem só na sua máquina é frágil: você esquece, ou o que passa no seu notebook falha em outro. O GitHub Actions é a esteira que vem com o repositório e roda os mesmos comandos numa máquina limpa a cada proposta. O arquivo diz a ordem: instalar as dependências travadas, rodar o verify e o build.

Um portão só protege quando bloqueia. Sem a proteção do ramo principal ligada, a checagem só avisa, e aviso ignorado não impede nada de entrar.

Fixe a versão do Chromium que a esteira usa: atualização de motor muda paginação e fonte. Dispare o PDF ou a foto só após um marcador de estado estável, nunca no evento de carregamento: tela que ainda espera dado gera arquivo pela metade.

A chave que autoriza publicar nunca entra no repositório. Se ela já foi enviada num commit, apagar o arquivo não resolve, porque o histórico a preserva; o conserto é trocar a chave no provedor. A esteira concentra credenciais de todos os ambientes: num levantamento de 2026, 59% das máquinas comprometidas eram executores de checagem.

Na Vercel (a hospedagem que pega o repositório e publica a cada envio), cada publicação fica guardada como um arquivo pronto. Promova a anterior de volta à principal e o site volta à versão de ontem em segundos: um susto de cinco minutos em vez de uma madrugada.

O último portão é o agente testando a tela como usuário. A skill webapp-testing (o roteiro que ensina o agente a testar a aplicação local com Playwright em Python) fixa a ordem: reconhecer antes de agir.

Use o ajudante with_server.py para subir o servidor e rodar o script; rode --help antes e trate os scripts como caixa-preta, porque a fonte deles polui a conversa. Para HTML estático, o agente lê o arquivo e acha os seletores (o endereço de cada elemento, por texto, papel, CSS ou id).

Para aplicação dinâmica, ele sobe o servidor, navega e espera a rede sossegar. Só então tira o print ou inspeciona o DOM (a árvore de elementos da página) e escolhe os seletores. Inspecionar o DOM antes de a rede sossegar é a armadilha: o seletor mira o que ainda não existe. Chromium sempre sem janela, navegador fechado no fim.

Um envio com erro de tipo que derruba o cálculo do frete não chega ao site quando o verify bloqueia a entrada na esteira. O roteiro do agente fotografa a caixa vazia no mesmo dia.

Antes de aprovar a próxima publicação, peça o verify encadeado como condição obrigatória na esteira. Trave a versão do Chromium que ela usa e confirme que a chave de publicação mora no cofre da plataforma, nunca no repositório.

Depois rode o roteiro Playwright que testa a tela como o cliente vê. Só aprove o envio quando ele passar com a rede já sossegada.

Modernizar um sistema antigo por etapas, sem parar de atender

Com os portões automatizados, a modernização de um site existente pode ser fatiada em ondas, com orçamento fixado antes da primeira e dois agentes em pastas separadas.

Cinco ondas de melhoria, com um portão de verificação entre uma e a próxima, modernizam um site antigo sem parar de atender. Onda é uma rodada de trabalho com um objetivo só, fechada por uma checagem.

A ordem protege o negócio: primeiro a medição, depois o caminho do cliente, o visual, o movimento e o desempenho. Cada onda fecha antes de a seguinte começar.

Cada agente é um assistente de inteligência artificial que escreve código a partir do seu pedido. Dê a cada um a sua própria pasta, e nenhum apaga o trabalho do outro dentro da mesma onda. A onda zero fixa a régua antes de qualquer mudança, e a matriz do manual escolhe a stack de destino pelo cenário do relatório.

Uma onda cuida de uma camada só, e nada mais. Atacar as frentes juntas produz, semanas depois, a mesma lista de problemas com coisas quebradas em cima.

A primeira onda só mede: nenhum arquivo muda, e o resultado é um relatório com três números de partida. Entre uma onda e a próxima existe o portão de qualidade (a checagem automática que barra a mudança ruim antes do cliente). Se ele reprova, a onda volta e corrige, e o programa pode parar no meio sem perder o entregue.

Antes da primeira onda existe a onda zero, que fixa a régua com que as outras serão medidas. Ela tem três peças. O orçamento de desempenho é o teto de peso e de tempo de carregamento escrito antes de qualquer tela, como o orçamento da obra antes do primeiro tijolo.

O profiling mede onde o tempo é gasto; o OpenTelemetry é o padrão aberto que registra o que a tela faz em produção, como o odômetro do carro. Produto visual sem esse controle desde a primeira semana degrada em silêncio. Sem a onda zero, a onda cinco chega sem saber se o site ficou mais rápido ou apenas diferente.

Um teto numérico orienta o agente melhor do que "deixe leve". O portão de cada onda compara o número medido com o teto da onda zero.

A stack de destino (o conjunto de ferramentas que constrói e serve a tela) depende do cenário, e a matriz do manual decide numa linha. O board mensal fechado (o relatório da reunião de conselho) pede HTML estático com D3 ou Observable Plot e CSS de impressão.

O investor update pede Astro 7 com MDX e PDF via Playwright. O marketing diário pede React ou Vue com ECharts, Plotly ou ApexCharts 7, ligados às APIs (as portas de dados). O portal recorrente para diretoria pede Next.js 16 ou Astro com camada semântica (a definição de cada métrica em código versionado) e controle de acesso por linha.

Já o relatório offline seguro cabe num HTML único com DuckDB-Wasm e dados locais; a prova de conformidade pede Typst 0.15. Site que atende dois cenários recebe duas ondas de visual, uma por stack de destino, em vez de uma stack de compromisso que serve mal aos dois.

Dentro de uma onda, dois agentes trabalham juntos desde que cada um tenha a própria pasta e a própria lista de arquivos. O git worktree (um comando do próprio git que cria uma segunda pasta de trabalho ligada ao mesmo repositório) faz a pasta. Cada uma fica no seu ramo e as duas dividem o mesmo histórico, sem duplicar código.

Pasta separada evita a sobrescrita; o escopo disjunto (a lista de arquivos que é só de um agente) evita o conflito na hora de juntar. Se dois agentes citam o mesmo arquivo, o recorte foi mal feito, mesmo com pastas diferentes. Quem precisa de algo fora do próprio escopo relata o que falta, em vez de editar por conta própria.

Escreva um pedido único com a onda zero embutida: descreva o site atual, fixe o teto de tempo e de peso e diga onde a medição entra. Peça as cinco ondas na ordem, com o seu aprovado entre uma e a próxima.

Para dividir uma onda entre dois agentes, crie uma pasta irmã por ramo com o git worktree. Dê a cada agente sua lista de arquivos e incorpore um ramo de cada vez ao final.

Guia prático: teste A/B do topo da landing page com Vercel Flags

Teste A/B mostra duas versões da mesma página a públicos sorteados e compara o resultado. Feito por script no navegador, ele troca o conteúdo depois que a página aparece, e a Vercel registra que isso piora LCP e CLS justamente na página testada. Com uma flag avaliada no servidor, cada visitante recebe a versão dele já pronta.

Flag é a chave que liga ou desliga um trecho da página sem nova publicação. A documentação do Vercel Flags, atualizada em 15 de setembro de 2026, cobre o ciclo inteiro pelo terminal: criar a flag com as variantes, definir no código com o Flags SDK, enviar o valor ao Web Analytics, dividir o tráfego no painel e arquivar ao final. A integração com o Web Analytics está em beta, em todos os planos.

O portão verify e a reversão de um clique deste capítulo continuam sendo a rede de proteção: a variante nova só entra no ar depois de passar por eles.

Guia prático: piloto pequeno, refazer só o que mudou e checklist antes de publicar

O curso de edição de vídeo estudado em 07/10/2026 trabalha com três hábitos que servem igual a uma página. O primeiro é o piloto: vídeo acima de 5 minutos começa pelos 3 primeiros, e o longo, por 60 a 90 segundos em resolução menor. No caso real, os 3 minutos viraram 48 segundos editados e, só depois de aprovados, o método foi aplicado ao resto. A regra do material: erro no piloto custa minutos; no final, horas.

O segundo é refazer só o que mudou. O vídeo longo é montado por capítulos, e a revisão manda renderizar só os capítulos alterados. Na página, o equivalente é corrigir uma seção sem mexer nas outras e conferir só o que a mudança tocou.

O terceiro é o checklist antes de publicar. A skill do curso tem 10 itens antes de declarar pronto, e o roteiro de publicação no YouTube tem 9, abrindo com uma frase que vale para qualquer entrega: o agente edita, mas quem assina é você. O arquivo final tem nome que o identifica, e não há dúvida sobre qual versão sobe.

Guia prático: portões que seguram a publicação, da proposta ao tráfego real

A aula montou o comando verify e a esteira do GitHub Actions. Depois do merge ainda há três momentos em que a versão nova pode parar: antes de o build começar, antes de ir para o domínio e enquanto recebe só uma fração das visitas. Você sai com asserções do Lighthouse CI que reprovam, uma linha de base que só desce e a liberação gradual da Vercel para a campanha grande.

Aplicar os recursos ao projeto