Prontidão para Produção (MVP → Produção)

O que Prontidão para Produção (MVP → Produção) faz?

Objetivo: informar ao proprietário, com evidências, se o produto está pronto para usuários reais, o que bloqueia o lançamento e o menor conjunto de trabalho para fechar as lacunas. Dimensionado para o produto — nunca uma lista genérica de 200 itens.

Regras rígidas

1. Evidência ou é Desconhecido. Cada item é PASS / GAP / N/A / UNKNOWN, e PASS precisa de prova (caminho de arquivo, configuração, execução de CI, dashboard, link de documentação). Nunca marque PASS baseado em alegação de README.
2. Dimensione por nível. Não exija DR multi-região para uma versão beta de 50 usuários. Marque cada lacuna com o nível em que é necessária.
3. Verifique as regras da plataforma ao vivo. As regras de loja de aplicativos, OAuth, pagamento e remetente de e-mail mudam anualmente. Antes de citar um requisito de loja/fornecedor, verifique a documentação oficial do fornecedor (pesquisa na web) e cite o link + a data da verificação.
4. Reutilize, não duplique. Se pm-ai-shipping:ship-check, security-audit-static, performance-audit-static ou derive-tests estiverem disponíveis, execute-os para obter evidências em nível de código e incorpore os resultados. Esta skill é responsável por tudo ao redor do código.
5. Saída simples. O proprietário lê um scorecard de uma página; os detalhes vão no apêndice e no backlog.
6. Governança dentro do fluxo de trabalho, não no final. Prefira verificações que ocorrem onde o trabalho acontece (CI, templates de PR, pre-commit, proteções no produto) em vez de reuniões de revisão realizadas antes do lançamento. Um gate que só é executado no final se torna o gargalo.
7. Entregue ≠ adotado. A maioria dos produtos estagna após o lançamento porque as pessoas e os processos não mudaram, não porque o código falhou. A prontidão inclui o plano de adoção (domínio 13), não apenas o sistema.

Níveis de prontidão

Nível	Significado	Barreira típica
T1 Beta público	Usuários reais, baixa escala, pode tolerar algum tempo de inatividade	Sem vazamento de segredos, autenticação sólida, backups restauram, erros rastreados, páginas legais, rollback funciona
T2 GA	Usuários pagantes, expectativas de SLA	+ SLOs/alertas/plantão, testado sob carga, runbooks, caminho de suporte, fallbacks de integração
T3 Enterprise / regulamentado	Contratos B2B, PHI/PCI/crianças, auditorias	+ SSO/SCIM, logs de auditoria, DPAs/BAAs, teste de penetração, controles SOC 2 / HIPAA, exercícios de DR

Fluxo de trabalho

Passo 0 — Perfil do produto (pergunte uma vez, agrupe as perguntas)

Capture: nível alvo e data de lançamento; a única métrica de sucesso e seu alvo (o que torna este lançamento um sucesso, medido como, até quando); proprietário nomeado e partes interessadas para aprovação (produto, engenharia, segurança, jurídico/privacidade, suporte, marketing — sinalize jurídico/privacidade no primeiro dia se dados pessoais, saída de IA ou usuários regulamentados estiverem envolvidos); superfícies (web, iOS, Android, desktop, API pública, CLI, extensão de navegador, ferramenta de desenvolvimento/plugin/biblioteca distribuída para outros desenvolvedores); hospedagem/stack; tipos de dados (PII, PHI, pagamento, dados de menores); usuários (B2C/B2B), regiões (EUA/UE/outros); recursos de IA/LLM; pagamentos; toda integração externa (APIs consumidas, webhooks recebidos, marketplaces/lojas de aplicativos publicados, SSO/IdPs). Escaneie o repositório primeiro (manifestos de pacotes, templates de env, imports de SDK) para pré-preencher a lista de integrações, depois peça ao proprietário apenas para confirmar/preencher lacunas.

O perfil seleciona quais módulos se aplicam. Registre-o no topo do relatório.

Passo 1 — Coletar evidências

Repositório (código, configuração de CI, IaC, templates de env, migrações), dashboards/conectores de hospedagem se disponíveis (Vercel, Railway, Supabase, Render, etc.), rastreador de issues, documentação existente. Execute as skills de auditoria disponíveis. Anote o que não pôde ser inspecionado → UNKNOWN.

Passo 2 — Avaliar domínios principais (sempre) + módulos aplicáveis

Pontue cada item. Gravidade: BLOCKER (não pode lançar no nível alvo) / HIGH (corrigir nas primeiras 2 semanas) / LATER.

Passo 3 — Entregar

1. Scorecard (1 página): Go / Go-with-conditions / No-go; contagem de bloqueadores; tabela RAG por domínio; principais 5 riscos em linguagem simples.
2. Backlog de lacunas: um ticket por lacuna — título, por que é importante, critério de aceitação, evidência necessária para fechar, nível, gravidade, tamanho aproximado (P/M/G). Se Linear/Jira/GitHub Issues estiver conectado, ofereça-se para criá-los como um projeto/milestone; senão, uma tabela.
3. Kit de hardening (sob consulta): gere gate de qualidade de CI específico do repositório, arquivo de regras do agente (CLAUDE.md/.cursorrules), .env.example, rascunhos de runbook — construídos a partir do que o repositório realmente usa, não de um template genérico.
4. Modo de reexecução: em execuções posteriores, compare com o último relatório e mostre apenas o que mudou.

Domínios principais (sempre avaliados)

1. Segredos e configuração — nenhum segredo no código ou no histórico do git (gitleaks/trufflehog em todo o histórico); .env ignorado, .env.example presente; segredos de produção no armazenamento de segredos da plataforma; chaves separadas para dev/staging/produção; plano de rotação e quem pode rotacionar; etapas de resposta a vazamento de chave.

2. Identidade e acesso — provedor de autenticação comprovado ou biblioteca bem avaliada (sem criptografia artesanal); autorização no lado do servidor em cada rota de dados (verifique IDOR / filtros de tenant ausentes / RLS permissivo); tempos de vida de sessão/token e revogação; limites de taxa em login, cadastro, redefinição de senha, OTP; MFA para administradores; contas de serviço com privilégio mínimo; ações de administrador registradas.

3. Segurança de borda e aplicativo — HTTPS + HSTS; cabeçalhos de segurança (CSP, frame-ancestors, etc.); CORS restrito; validação de entrada nos limites; limites/tipos de arquivo de upload; proteções SSRF em buscadores de URL; WAF/proteção contra bots no T2+; varredura de dependências + lockfiles; SAST no CI; SBOM e verificação de licença no T3.

4. Dados — backups automatizados e uma restauração testada (registre o tempo real de restauração); recuperação pontual onde o banco de dados suportar; migrações compatíveis com versões anteriores (expandir → migrar → contrair); staging sem PII bruta de produção; caminho de retenção + exclusão (a exclusão de conta de usuário realmente exclui em banco de dados, armazenamento, logs, fornecedores); criptografia em repouso/em trânsito confirmada como padrão.

5. Confiabilidade — timeouts em toda chamada de saída; retentativas com backoff + jitter apenas em operações idempotentes; chaves de idempotência para pagamentos/webhooks/jobs; trabalho em segundo plano em uma fila durável; degradação graciosa quando uma dependência está fora do ar; SLOs definidos (disponibilidade, latência) no T2+; teste de capacidade/carga no pico esperado ×3 no T2+.

6. Observabilidade — rastreamento de erros com marcação de versão (ex.: Sentry); logs estruturados com IDs de requisição/rastreamento e omissão de PII; métricas principais (taxa, erros, duração) por endpoint; verificações de uptime de fora; alertas baseados em sintomas roteados para um humano que realmente os verá; dashboards para o dia do lançamento.

7. CI/CD e lançamento — verificações obrigatórias na main (lint, typecheck, testes, varredura de segredos, auditoria de dependências); ambiente de preview/staging; rollback com um clique comprovado pelo menos uma vez; feature flags para recursos arriscados; migrações executadas com segurança no deploy; notas de lançamento/changelog; proteção de branch.

8. Testes — testes em caminhos críticos (autenticação, pagamentos, gravações de dados, permissões) em vez de % de cobertura; testes de integração contra banco de dados real; smoke E2E nas principais jornadas do usuário executado pós-deploy; testes de contrato ou fixtures gravadas para APIs externas.

9. Desempenho e custo — Core Web Vitals / orçamentos de inicialização de aplicativo; verificação de N+1 e índice ausente; cache/CDN; alertas de gastos por fornecedor e limites máximos (nuvem, LLM, SMS, e-mail); custo estimado por usuário ativo; cenários de abuso que podem gerar custos (spam de cadastro, loops de prompt de LLM, bombeamento de SMS).

10. Operações e suporte — proprietário/plantão nomeado mesmo que seja uma pessoa; processo de incidente (gravidade, comunicações, postmortem); runbooks para os principais 5 modos de falha; página de status no T2+; canal de suporte e SLA; ferramentas administrativas para tarefas comuns de suporte (para que correções não precisem de SQL bruto).

11. Legal e confiança — Termos, Política de Privacidade compatíveis com os fluxos de dados reais; consentimento de cookies onde necessário (UE/Reino Unido); DPAs com fornecedores que processam dados pessoais; lista de subprocessadores no T3; meta de acessibilidade (WCAG 2.2 AA) e uma auditoria básica; conformidade de licença de código aberto; liberação de marca registrada/nome para o nome do produto.

12. Prontidão do produto — análises no funil de ativação (com consentimento); onboarding e estados vazios; e-mails transacionais entregáveis (veja módulo Web); documentação de ajuda/FAQ; precificação/faturamento ativos se pago; ciclo de feedback; kill switch para recursos problemáticos.

13. Adoção e modelo operacional — métrica de sucesso e critérios de saída do piloto escritos antes do lançamento (o que o move de piloto para 'escala' ou 'cancelar'); fluxo de trabalho de lançamento documentado com aprovadores nomeados por nível de risco (mudanças de baixo risco = um revisor, alto risco = mais) e um tempo de resposta acordado para que a aprovação não emperre; comunicação de lançamento (o que está mudando, o que não está, limites conhecidos); primeiro grupo de usuários/campeões e uma maneira de ouvi-los; ajuda no produto, modelos ou exemplos para que os usuários aprendam dentro da ferramenta; ciclo de feedback (feedback do usuário + métricas de uso) com uma cadência de revisão (ex.: 30/60/90 dias, depois trimestralmente); proprietário para suporte contínuo à medida que o uso cresce.

Módulos condicionais

M1. Integrações que você consome (uma planilha por fornecedor) — conta/chaves de produção (não sandbox) e quem possui a conta; limites de taxa e cotas vs. pico esperado; teto de preço e alertas; tipo de autenticação e renovação de token; verificação de assinatura de webhook, proteção contra repetição, handlers idempotentes, retry/backoff e dead-letter; versão da API fixada + monitoramento de descontinuação (inscreva-se no changelog); timeout + circuit breaker + fallback visível ao usuário; inscrito na página de status do fornecedor; ToS permite seu uso (revenda, treinamento de IA, scraping); plano de saída — você possui seus dados/prompts/configurações e pode exportá-los, contrato sem lock-in plurianual sem cláusulas de rescisão; residência de dados/DPA; requisitos de verificação/revisão de aplicativo OAuth (ex.: escopos confidenciais/restritos do Google, verificação de editor da Microsoft, revisão de aplicativo Slack/Zoom) — verifique as regras atuais ao vivo.

M2. API pública que você expõe — OpenAPI/especificação publicada; política de versionamento e descontinuação; chaves de API/OAuth com escopos, rotação, revogação; limites de taxa e cotas por chave; paginação, chaves de idempotência em POST; formato de erro consistente; ambiente sandbox; webhooks que você enga são assinados, retentados e reproduzíveis; documentação do desenvolvedor + changelog; medição de uso se faturado.

M3. Mobile e lojas de aplicativos — Verifique cada uma contra a documentação oficial atual antes de citar:

• Apple: Diretrizes de Revisão de Aplicativos; rótulos de privacidade nutricionais correspondem à coleta real; manifesto de privacidade incl. SDKs de terceiros; exclusão de conta no aplicativo se contas puderem ser criadas; regra 'Sign in with Apple' ao oferecer login de terceiros; regras de IAP para bens digitais; testes externos do TestFlight; conformidade de exportação.
• Google Play: prazo atual da API alvo; formulário de segurança de dados; requisito de teste fechado para novas contas de desenvolvedor pessoais; Play App Signing e custódia da chave de upload; link de exclusão de conta da web.
• Ambos: relatórios de falhas; mecanismo de atualização forçada/suave para mudanças de API interruptivas; links deep/universais; credenciais de push de propriedade da conta da empresa; ativos de listagem da loja, classificação etária, URL de suporte, URL de privacidade; buffer de rejeição de revisão no plano de lançamento (planeje dias, não horas).

M4. Web e e-mail — domínio personalizado, DNS de propriedade da conta da empresa, bloqueio de registrador + renovação automática; fundamentos de SEO (títulos, sitemap, robots, tags OG) se a descoberta for importante; páginas 404/500; autenticação de remetente de e-mail SPF, DKIM, DMARC e cancelamento de inscrição com um clique para e-mails em massa (verifique as regras atuais de remetente do Gmail/Yahoo); tratamento de bounce/reclamação; fluxos de e-mail transacional vs. marketing separados.

M5. Recursos de IA / LLM — abstração de provedor ou gateway com modelo de fallback; timeouts e retentativas em 429/5xx; saída estruturada validada por esquema (Zod/Pydantic); conjunto de avaliação de casos reais executado no CI antes de alterações de prompt/modelo; defesas contra injeção de prompt onde o modelo lê conteúdo não confiável ou pode chamar ferramentas (ferramentas com privilégio mínimo, confirmação humana para ações destrutivas); limites de custo por usuário e global; tratamento de PII e configurações de retenção de dados do provedor; datas de descontinuação de modelo rastreadas; divulgação de IA aos usuários onde exigido; proteções de qualidade/marca na saída gerada (termos proibidos, verificações de tom, revisão humana escalonada por risco); UI informa aos usuários os limites ('verifique fatos', fontes mostradas para alegações); alterações de prompt/modelo testadas primeiro em uma sandbox em dados históricos ou de amostra, depois lançadas para uma pequena parcela do tráfego antes de todos; revisão programada (ex.: semestral) de modelo/fornecedor.

M6. Pagamentos — checkout hospedado para minimizar escopo PCI; estado orientado por webhook (nunca confie em redirect do cliente); cumprimento idempotente; reembolsos, disputas, dunning; coleta de impostos por região; relógio de teste/sandbox coberto; reconciliação de receita.

M7. Dados regulamentados — PHI → HIPAA: BAA com cada fornecedor que toca PHI, registro de acesso, mínimo necessário. PCI além de checkout hospedado → escopo SAQ. Crianças → COPPA/limite de idade. Usuários da UE/Reino Unido → base legal do GDPR, processo DSAR, transferências. Califórnia → CCPA/CPRA. Sinalize para revisão jurídica; não dê conclusões legais.

M8. B2B / enterprise — isolamento de tenant testado (teste de acesso entre tenants); SSO (SAML/OIDC) e SCIM no T3; exportação de logs de auditoria; modelo de funções/permissões; exportação de dados; pacote de questionário de segurança (arquitetura, subprocessadores, teste de penetração, políticas); SLA de uptime e créditos.

M9. Marketplaces onde você publica — Chrome Web Store, diretórios de aplicativos Slack/Teams/Zoom, Shopify, registros MCP/plugins, etc.: requisitos de listagem, prazos de revisão, justificativa de permissão, divulgações de privacidade — verifique ao vivo.

M10. Ferramentas de desenvolvedor, bibliotecas, plugins e código aberto — licença escolhida deliberadamente (copyleft como AGPL pode bloquear adoção empresarial; permissiva como MIT/Apache se espalha mais rápido) e NOTICE/licenças de terceiros corretas; SECURITY.md com um canal de divulgação privado; versionamento semântico, CHANGELOG e um caminho de atualização/migração testado para quaisquer dados armazenados ou formato de configuração; matriz de plataformas suportadas realmente testada no CI (SO × versões de runtime × cada cliente/IDE que afirma suportar); instalação verificada a partir de uma máquina limpa para cada caminho documentado; nomes de pacotes reservados em cada registro (PyPI, npm, marketplaces de plugins); releases assinados / proveniência de build; telemetria desligada ou opt-in e documentada; CONTRIBUTING, código de conduta, templates de issue/PR; uma seção 'o que isso não é' para que os usuários não o utilizem incorretamente.

Template de scorecard

PRODUTO: <nome>   ALVO: T1/T2/T3   LANÇAMENTO: <data>   VEREDITO: GO | GO-WITH-CONDITIONS | NO-GO
Bloqueadores: N   Alto: N   Desconhecido: N

...

[truncado para tradução]