DeployAntes de publicar um sistema em producao
Um checklist para validar build, variaveis, banco, containers, proxy, DNS, SSL, rotas da SPA e arquivos tecnicos antes da virada.
Use quando
- O sistema sera publicado em VPS, Docker, Nginx ou proxy compartilhado
- Existe risco de conflito com outro sistema no mesmo servidor
- O dominio precisa apontar para uma nova infraestrutura
Verifique antes
- Build do frontend e backend concluido sem erro
- Migrations revisadas e backup do banco confirmado
- Variaveis de ambiente separadas de segredos versionados
- Portas internas, redes Docker e proxy documentados
- Rotas de API, SPA, sitemap.xml, robots.txt, ads.txt e feed.xml validadas
- Plano simples de rollback definido antes da mudanca
Sinais de alerta
- Container rodando e tratado como prova unica de sucesso
- DNS, SSL ou Nginx validados apenas localmente
- Ninguem sabe qual imagem ou commit esta em producao
Evidencia util: Guarde commit, tag da imagem, saida do build, URLs testadas, horario da publicacao e logs das primeiras requisicoes.
APIsAntes de alterar uma API REST em Spring Boot
Um roteiro de validacao para contratos, DTOs, erros, seguranca, logs, clientes consumidores e compatibilidade entre versoes.
Use quando
- Um endpoint sera refatorado, dividido ou exposto para outro sistema
- A API tem respostas inconsistentes ou regras espalhadas
- Clientes externos dependem do contrato atual
Verifique antes
- Contrato de entrada e saida descrito com exemplos reais
- Validacoes e mensagens de erro padronizadas
- Autenticacao, autorizacao e dados sensiveis revisados
- Logs com identificador, endpoint, status e tempo de resposta
- Clientes consumidores mapeados antes da quebra de contrato
- Teste manual ou automatizado cobrindo caminho feliz e erro esperado
Sinais de alerta
- Mudanca feita diretamente no controller sem revisar regra de negocio
- Erro 500 usado como resposta para problema de validacao
- Nenhum consumidor da API foi identificado antes da alteracao
Evidencia util: Guarde exemplos de request/response, status esperados, campos obrigatorios e decisao sobre versionamento.
SuporteAo investigar lentidao, erro 500 ou incidente
Um checklist para transformar relato solto em evidencia tecnica: rota, horario, usuario, log, banco, integracao externa e impacto.
Use quando
- O problema aparece em producao, mas nao se repete facilmente em ambiente local
- A equipe nao sabe se o gargalo esta no banco, na API ou em servico externo
- Usuarios relatam erro, mas os logs nao explicam a causa
Verifique antes
- Rota, payload, usuario, horario e ambiente registrados
- Log da requisicao localizado do inicio ao fim
- Tempo de banco, processamento e chamadas externas separado quando possivel
- Mudancas recentes de deploy, configuracao ou dados verificadas
- Impacto em usuarios, faturamento ou operacao descrito
- Correcao validada com comparacao antes e depois
Sinais de alerta
- A primeira acao e aumentar servidor sem medir gargalo
- Logs mostram apenas mensagem generica
- A correcao e aplicada sem criterio para saber se funcionou
Evidencia util: Guarde trecho de log, status HTTP, tempo de resposta, hipotese testada, correcao aplicada e resultado observado.
LegadosAntes de modernizar um sistema legado
Um checklist para mapear regras, fluxos criticos, banco, integracoes, rotinas e riscos antes de escolher refatoracao, convivencia ou reescrita.
Use quando
- A empresa depende de um sistema antigo que poucos entendem
- A modernizacao foi sugerida antes de mapear o que nao pode quebrar
- Mudancas pequenas geram medo de impacto em outras telas ou processos
Verifique antes
- Fluxos que sustentam receita, atendimento ou operacao diaria listados
- Regras de negocio principais descritas com exemplos
- Tabelas, arquivos, jobs e integracoes externas mapeados
- Pontos sem dono tecnico identificados
- Partes que podem ser isoladas sem reescrever tudo separadas
- Criterio para refatorar, substituir ou manter documentado
Sinais de alerta
- A equipe fala em reescrever antes de entender regras escondidas
- Conhecimento essencial existe apenas em memoria ou conversas antigas
- Nao existe ambiente seguro para testar mudancas
Evidencia util: Guarde mapa de fluxos, regras criticas, riscos conhecidos, pontos de integracao e decisao de modernizacao por etapa.
IA aplicadaAntes de usar IA, RAG ou automacao com documentos
Um checklist para separar produtividade real de risco: fontes, permissao, revisao humana, testes, privacidade e limite de resposta.
Use quando
- A empresa quer usar IA para documentacao, suporte, codigo ou base interna
- Documentos estao espalhados, duplicados ou desatualizados
- A resposta da IA precisa citar origem ou obedecer regras internas
Verifique antes
- Fontes confiaveis separadas de rascunhos e documentos antigos
- Permissoes e dados sensiveis revisados antes da indexacao
- Perguntas de teste criadas com respostas esperadas
- Criterio de revisao humana definido para codigo ou decisao tecnica
- Limites de uso explicitos para evitar resposta fora de contexto
- Logs ou historico de uso avaliados sem expor dados indevidos
Sinais de alerta
- IA usada como substituta de documentacao inexistente
- Base de conhecimento mistura arquivo valido com versao antiga
- Codigo gerado por IA vai para deploy sem revisao de contexto
Evidencia util: Guarde fontes usadas, perguntas de validacao, respostas esperadas, decisoes humanas e limites assumidos.
SegurancaAo revisar seguranca, dependencias e segredos
Um checklist para tratar dependencias, SBOM, imagens Docker, tokens, senhas, variaveis e pipeline como parte da operacao.
Use quando
- O projeto tem bibliotecas antigas sem plano de atualizacao
- Segredos aparecem em arquivos locais, historico, prints ou variaveis soltas
- Pipeline publica sem build, teste ou revisao minima
Verifique antes
- Segredos fora do Git e separados por ambiente
- Dependencias diretas e transientes inventariadas
- Imagem Docker, base image e bibliotecas criticas revisadas
- Acessos de usuarios e servicos ajustados ao menor privilegio
- Pipeline executa build e verificacoes antes de publicar
- Plano de atualizacao com rollback para bibliotecas sensiveis
Sinais de alerta
- Senha real em application.yml, historico de commit ou anotacao compartilhada
- Dependencia critica sem manutencao ou sem dono claro
- Ambiente de producao depende de permissao ampla demais
Evidencia util: Guarde inventario de dependencias, variaveis por ambiente, decisoes de atualizacao e resultado das validacoes.
EditorialAo publicar conteudo tecnico para leitores e busca
Um checklist para revisar utilidade, autoria, fontes, links internos, exemplos e transparencia antes de tratar uma pagina como conteudo permanente.
Use quando
- O site precisa parecer um portal util, nao apenas uma vitrine comercial
- A pagina sera usada em SEO, AdSense, Google Ads ou captura de leads
- O conteudo usa referencias externas, tendencias ou ferramentas novas
Verifique antes
- A pagina responde uma duvida real com texto proprio
- Fontes externas sao usadas como contexto, nao como copia
- Autoria, politica editorial e paginas de confianca estao acessiveis
- Links internos levam para artigos, hubs, materiais, FAQ ou glossario
- CTAs aparecem depois de conteudo util e nao confundem com anuncio
- Titulo, descricao, canonical e dados estruturados estao coerentes
Sinais de alerta
- Pagina curta criada apenas para capturar trafego ou exibir anuncio
- Texto generico sem exemplo, criterio, risco ou proximo passo
- Afiliado, download ou servico aparece antes de contexto suficiente
Evidencia util: Guarde tema, objetivo da pagina, fontes consultadas, links internos e validacao de build antes de publicar.