Disponibilidade de material de suporte

Esta cópia do catálogo contém as orientações embutidas abaixo, mas não inclui os seguintes caminhos de suporte. Eles são pré-requisitos externos, não arquivos empacotados:

• <support-root>/references/definition-of-done.md
• <support-root>/references/security-checklist.md
• <support-root>/references/performance-checklist.md
• <support-root>/references/accessibility-checklist.md

Obtenha o material necessário da fonte upstream declarada ou de uma instalação fornecida pelo usuário dessa fonte. Resolva cada caminho em relação a essa instalação, inspecione seu conteúdo e verifique quaisquer licenças aplicáveis e pré-requisitos de execução. Não execute um comando nem afirme que um procedimento referenciado foi seguido até que seu arquivo necessário exista. Não fabrique os scripts ausentes nem trate um arquivo não relacionado com o mesmo nome como equivalente. Etapas independentes totalmente documentadas aqui podem prosseguir dentro do escopo autorizado do usuário; relate qualquer etapa dependente como indisponível.

Envio e Lançamento

Visão Geral

Envie com confiança. O objetivo não é apenas implantar — é implantar com segurança, com monitoramento em vigor, um plano de reversão pronto e um entendimento claro do que significa sucesso. Cada lançamento deve ser reversível, observável e incremental.

Quando Usar

• Implantando um recurso em produção pela primeira vez
• Lançando uma mudança significativa para os usuários
• Migrando dados ou infraestrutura
• Abrindo um programa beta ou de acesso antecipado
• Qualquer implantação que apresente risco (todas elas)

O Checklist Pré-Lançamento

Qualidade do Código

• Todos os testes passam (unitários, de integração, e2e)
• Build é bem-sucedido sem avisos
• Lint e verificação de tipo passam
• Código revisado e aprovado
• Nenhum comentário TODO que deva ser resolvido antes do lançamento
• Nenhuma instrução de depuração console.log no código de produção
• O tratamento de erros cobre os modos de falha esperados

Segurança

• Nenhum segredo no código ou controle de versão
• npm audit não mostra vulnerabilidades críticas ou de alta gravidade
• Validação de entrada em todos os endpoints voltados para o usuário
• Verificações de autenticação e autorização em vigor
• Cabeçalhos de segurança configurados (CSP, HSTS, etc.)
• Limitação de taxa em endpoints de autenticação
• CORS configurado para origens específicas (não wildcard)

Desempenho

• Core Web Vitals dentro dos limites "Bom"
• Nenhuma consulta N+1 em caminhos críticos
• Imagens otimizadas (compressão, tamanhos responsivos, lazy loading)
• Tamanho do bundle dentro do orçamento
• Consultas ao banco de dados possuem índices apropriados
• Cache configurado para ativos estáticos e consultas repetidas

Acessibilidade

• Navegação por teclado funciona para todos os elementos interativos
• Leitor de tela pode transmitir o conteúdo e a estrutura da página
• Contraste de cor atende ao WCAG 2.1 AA (4.5:1 para texto)
• Gerenciamento de foco correto para modais e conteúdo dinâmico
• Mensagens de erro são descritivas e associadas aos campos do formulário
• Nenhum aviso de acessibilidade em axe-core ou Lighthouse

Infraestrutura

• Variáveis de ambiente definidas em produção
• Migrações de banco de dados aplicadas (ou prontas para aplicar)
• DNS e SSL configurados
• CDN configurado para ativos estáticos
• Logging e relatórios de erro configurados
• Endpoint de health check existe e responde

Documentação

• README atualizado com quaisquer novos requisitos de configuração
• Documentação da API atualizada
• ADRs escritos para quaisquer decisões arquitetônicas
• Changelog atualizado
• Documentação voltada para o usuário atualizada (se aplicável)

Estratégia de Feature Flag

Envie por trás de feature flags para desacoplar implantação de lançamento:

// Feature flag check
const flags = await getFeatureFlags(userId);

if (flags.taskSharing) {
  // New feature: task sharing
  return <TaskSharingPanel task={task} />;
}

// Default: existing behavior
return null;

Ciclo de vida da feature flag:

1. DEPLOY with flag OFF     → Code is in production but inactive
2. ENABLE for team/beta     → Internal testing in production environment
3. GRADUAL ROLLOUT          → 5% → 25% → 50% → 100% of users
4. MONITOR at each stage    → Watch error rates, performance, user feedback
5. CLEAN UP                 → Remove flag and dead code path after full rollout

Regras:

• Cada feature flag tem um proprietário e uma data de expiração
• Limpe as flags em até 2 semanas após o lançamento completo
• Não aninhe feature flags (cria combinações exponenciais)
• Teste ambos os estados da flag (ligada e desligada) em CI

Rollout Gradual

…