ArvinAbrahamian1/production-app

Aplicativo de Produção

A Ideia

Toda grande empresa converge para a mesma estrutura: um edge na frente, um frontend implantável, um backend separado atrás de um gateway, workers consumindo de uma fila, um sistema relacional de registro, um cache, uma espinha dorsal de eventos ou jobs, armazenamento de objetos e observabilidade em torno de tudo. Shopify, Notion, Figma, Instacart e Airbnb diferem em linguagens e fornecedores, não na estrutura.

A estrutura não muda entre um MVP de fim de semana e uma empresa com um time de plataforma. Apenas o provedor por trás de cada caixa muda. Portanto, esta skill constrói a estrutura completa desde o primeiro dia com provedores gerenciados baratos, impõe uma lista curta de regras de portabilidade e mantém um manual por camada para trocar o provedor quando um gatilho mensurável for acionado. Feito dessa forma, sair do Vercel e Supabase para Kubernetes e RDS é uma série de mudanças de configuração e cópias de dados, nunca uma reescrita.

Como Usar Esta Skill

1. Leia a descrição do projeto. Faça as perguntas de intake abaixo apenas para o que ela omitir.
2. Escolha um provedor por camada com references/providers-and-tiers.md. Comece no tier 1, a menos que uma regra de seleção diga o contrário.
3. Escreva docs/PLAN.md a partir do modelo abaixo, incluindo o diagrama adaptado de references/architecture.md, e mostre-o antes de criar a estrutura.
4. Crie a estrutura e construa na ordem abaixo.
5. Antes do lançamento, execute references/launch-checklist.md e reporte apenas as falhas com correções.
6. Quando um gatilho for acionado posteriormente, abra references/migrations.md e mova aquela camada. Nunca mova duas camadas na mesma semana.

Para um aplicativo existente: faça uma auditoria primeiro. Mapeie o repositório para a estrutura, liste as lacunas ordenadas por risco (vazamento de dados, interrupção, abuso, dependência de fornecedor, custo) e pare. As mudanças vêm depois que o proprietário escolher da lista.

Intake

Pergunte apenas o que a descrição não responder, em uma única mensagem.

1. Quem são os usuários e qual é o tenant: a unidade que possui os dados (uma empresa, um prédio, um revendedor, uma única pessoa)?
2. O que é pesado: feeds, mensagens, uploads, vídeo, eventos, pesquisa? Linhas ou arquivos aproximados por dia e crescimento.
3. Web, iOS, Android ou uma combinação? Qual é lançado primeiro?
4. Necessidades em tempo real: chat, presença ao vivo, edição colaborativa ou a sondagem é suficiente?
5. Dinheiro: assinaturas, pagamentos únicos, pagamentos de marketplace, nenhum?
6. Algo regulamentado ou sensível: pagamentos armazenados, saúde, menores de idade, localização, compradores governamentais ou empresariais que solicitarão SOC 2?
7. Geografia do público: um país ou global?
8. Restrições: créditos de nuvem existentes, um provedor existente, uma linguagem obrigatória.

As respostas direcionam as regras de seleção em references/providers-and-tiers.md.

A Estrutura

Cada camada tem uma função, uma referência de grande empresa e a única regra que a mantém portátil. Os fornecedores por tier estão em references/providers-and-tiers.md.

1. Edge: DNS, TLS, CDN, DDoS, WAF, limitação de taxa, filtragem de bots, na frente de cada host. Grandes empresas: Cloudflare, Akamai, Fastly, CloudFront com AWS WAF. Regra: você possui a zona DNS; cada provedor fica atrás de um CNAME, então trocar um provedor é uma mudança de DNS.
2. Frontend: um implantável separado, estático ou renderizado no servidor, sem lógica de negócios e sem acesso ao banco de dados. Grandes empresas: um aplicativo React ou Next.js construído em um contêiner e servido através do CDN. Regra: o frontend é construído como um contêiner Node padrão ou pacote estático e se comunica apenas com a API pública.
3. Gateway: um balanceador de carga ou gateway de API que termina o TLS do edge, roteia por caminho e impõe limites amplos. Grandes empresas: ALB, Envoy, NGINX ingress, Kong. Regra: a API nunca depende de recursos do gateway que não possa reproduzir em seu próprio middleware.
4. Backend: um serviço monolítico atrás do gateway, dividido em serviços apenas quando as equipes colidem. Grandes empresas: Rails na Shopify e GitHub, Django no Instagram, Node na Notion, gRPC internamente, GraphQL ou REST externamente. Regra: um contêiner Docker com um endpoint de integridade, configuração a partir de env, nenhum SDK do fornecedor na lógica de negócios.
5. Workers e fila: processos separados de longa duração consumindo jobs; um mecanismo de workflow quando os jobs têm várias etapas ou esperas humanas. Grandes empresas: Sidekiq e consumidores Kafka na Shopify, Temporal na Netflix e Duolingo, Kafka na Notion. Regra: os jobs são idempotentes, carregam IDs, não blobs, e a fila é Redis padrão ou protocolo Kafka.
6. Banco de dados relacional: um Postgres (ou MySQL) primário como sistema de registro, réplicas para leituras, sharding apenas além dos limites de uma única máquina. Grandes empresas: RDS Postgres com PgBouncer na Notion e Figma, 100 ou mais shards MySQL na Shopify. Regra: apenas protocolo wire do Postgres, migrações SQL no repositório, funções e RLS em SQL, nada que funcione apenas na API de um provedor.
7. Cache: Redis ou Memcached para leituras frequentes, contadores de limite de taxa, locks, sessões. Regra: protocolo Redis padrão, chaves com escopo de tenant e versionadas, o aplicativo deve funcionar com o cache vazio.
8. Armazenamento de objetos: S3 ou um bucket compatível com S3 para cada arquivo; nunca o banco de dados. Regra: apenas a API S3, chaves prefixadas por tenant, servidas através de URLs assinadas ou CDN.
9. Identidade: um provedor de identidade emitindo JWTs, uma tabela users de propriedade do aplicativo. Grandes empresas: interno mais Okta ou Auth0 para SSO empresarial. Regra: a API verifica os tokens por conta própria via JWKS e possui a tabela de usuários, para que o emissor possa mudar.
10. Eventos e análises: análises de produto e, posteriormente, um data warehouse alimentado por captura de dados de alteração. Grandes empresas: Kafka no Snowflake ou BigQuery. Regra: o warehouse lê do banco de dados, nunca faz gravações duais do aplicativo.
11. Observabilidade: logs estruturados, erros, métricas, traces, uptime, alertas vinculados a um runbook. Grandes empresas: Datadog, Grafana, Honeycomb, Sentry, OpenTelemetry. Regra: o aplicativo emite OpenTelemetry e logs JSON, então o backend é uma configuração de exportador.
12. Entrega: CI em cada push, infraestrutura como código, deploys canário ou blue-green, feature flags, rollback rápido. Grandes empresas: Terraform, Buildkite ou GitHub Actions, ArgoCD ou Spinnaker, LaunchDarkly. Regra: qualquer coisa clicada em um dashboard é escrita em infra/ no mesmo dia, e Terraform a partir do tier 2.

Regras de Portabilidade

Elas são o que torna a mudança posterior barata. Custam quase nada no tamanho MVP e são a diferença entre uma migração de fim de semana e uma reescrita de um trimestre.

1. Frontend e backend são repositórios separados e implantações separadas desde o primeiro commit. Eles se comunicam através de uma API HTTP versionada com esquemas compartilhados.
2. O backend e o worker são imagens Docker que rodam em qualquer lugar onde um contêiner roda. Sem funções serverless para a API: funções Vercel, manipuladores Lambda e funções de borda são a única coisa que não pode ser migrada para um contêiner posteriormente sem reescrever.
3. Comunique-se com a infraestrutura através de padrões apenas: protocolo wire Postgres, protocolo Redis, API S3, SMTP ou uma API HTTP de e-mail por trás de uma interface, JWKS para tokens, OpenTelemetry para telemetria. A biblioteca cliente própria de um provedor é permitida apenas em um módulo adaptador fino que pode ser trocado.
4. Nenhum recurso do provedor na lógica de negócios: sem chamadas PostgREST, sem cliente Supabase ou Firebase no backend, sem APIs de cache específicas do Vercel, sem Workers KV. O frontend pode usar o SDK de autenticação de um provedor apenas para login.
5. O aplicativo possui seu esquema: migrações SQL no repositório, aplicadas por uma ferramenta de migração, nunca por um painel de controle. Funções, RLS e funções são arquivos SQL que o repositório pode reproduzir em qualquer Postgres.
6. O aplicativo possui seus usuários: uma tabela users espelhada do provedor de identidade no primeiro login, com IDs de provedores armazenados como uma coluna. Os dados de permissão vivem nas tabelas do aplicativo.
7. A configuração são variáveis de ambiente validadas na inicialização. Os segredos vivem no cofre de segredos da plataforma, mas chegam ao aplicativo como env, para que o cofre possa mudar.
8. Você possui a zona DNS (Cloudflare). Cada provedor é um destino CNAME. Nada é apontado para os nameservers de um provedor.
9. As chaves de armazenamento de objetos e o layout do bucket são os mesmos no R2 e no S3; o código usa o SDK S3 com uma configuração de endpoint.
10. Cada camada tem uma exportação documentada: pg_dump e replicação lógica para o banco de dados, rclone para objetos, um dump Redis nunca é necessário porque o cache é descartável e a fila drena.
11. Endpoints de integridade, desligamento gracioso no SIGTERM e apatridia horizontal existem desde o primeiro dia, porque toda plataforma, do Railway ao Kubernetes, depende deles.
12. Telemetria e logs são OpenTelemetry e JSON desde o primeiro dia; agentes de fornecedores não são instalados no código.

Tiers

Três tiers por camada. Os gatilhos são mensuráveis; a tabela completa com fornecedores, custo e as regras de seleção está em references/providers-and-tiers.md.

• Tier 1, MVP: provedores gerenciados que levam minutos para configurar e custam menos de cerca de $150 por mês no total. Frontend no Vercel, contêiner backend no Railway, Postgres no Supabase, Redis no Railway, objetos no R2, edge no Cloudflare, Sentry e Better Stack. Até que haja clientes pagantes que perguntem sobre uptime, ou os números abaixo.
• Tier 2, crescimento: a mesma estrutura em sua própria conta de nuvem onde for importante: Postgres no RDS ou Aurora Multi AZ com PgBouncer ou RDS Proxy, contêineres no ECS Fargate ou um pequeno EKS, ElastiCache, S3 ou R2, Terraform para tudo, uma réplica de leitura, Temporal para workflows. Gatilho: um cliente pagante solicita um SLA ou SOC 2, ou 5 mil usuários ativos mensais sustentados com CPU do banco de dados acima de 60%, ou a conta do PaaS ultrapassa $500 por mês, ou um segundo engenheiro entra.
• Tier 3, escala: o que Shopify e Notion executam. Kubernetes com autoscaling, primário fragmentado ou particionado, Kafka como espinha dorsal de eventos, warehouse por CDC, leituras multirregião, Datadog ou Grafana, um time de plataforma. Gatilho: 1.000 requisições por segundo sustentadas, um primário próximo a 1 TB ou limitado por gravação após réplicas e cache, um requisito multirregião ou uma equipe de operações existe para executá-lo.

Mover tiers é por camada, não tudo de uma vez. O banco de dados geralmente se move primeiro, depois o backend, e o frontend por último, porque o frontend é o mais barato de deixar onde está.

Ordem de Construção

1. Esquema, migrações, funções, RLS (references/database.md, references/security.md).
2. Verificação de identidade e middleware de contexto de tenant.
3. Rotas principais da API com validação e idempotência em gravações.
4. Middleware de limitação de taxa e cache (references/rate-limiting.md, references/caching.md).
5. Workers e filas; qualquer coisa lenta ou externa sai do caminho da requisição (references/jobs-and-queues.md).
6. Frontend contra a API.
7. Mobile contra a mesma API.
8. Logs, métricas, traces, verificações de integridade, alertas (references/observability-and-reliability.md).
9. Portão de lançamento, teste de carga em três vezes o pico esperado, um teste de restauração (references/launch-checklist.md).

Modelo PLAN.md

# <Projeto> Plano
## Produto em três frases
## Usuários, tenant, funções
## Provedores por camada         (tier por camada, porquê, o gatilho que o move, de providers-and-tiers.md)
## Modelo de dados                 (tabelas, tenant_id marcado, índices, tabelas particionadas)
## Superfície da API                (rotas por recurso, nível de autenticação, nível de limite de taxa)
## Jobs em segundo plano            (fila, gatilho, chave de idempotência, política de retry)
## Terceiros              (serviço, propósito, nome do segredo, limite, modo de falha)
## Mapa de cache                (o quê, chave, TTL, quais gravações o invalidam)
## Modelo de ameaça               (top 5 casos de abuso e o controle para cada)
## Suposições de escala          (usuários, linhas, requisições por minuto no lançamento e em 10x)
## Custo no lançamento             (por provedor, por mês)
## Plano de saída por provedor     (o playbook migrations.md que se aplica, em uma linha cada)
## Diagrama

Regras Inegociáveis

1. Toda tabela de propriedade do tenant tem tenant_id; RLS habilitado e forçado; a API define o tenant por transação a partir de associação verificada, nunca da entrada da requisição.
2. Os clientes nunca tocam no banco de dados ou possuem chaves privilegiadas. Tudo passa pela API.
3. Toda entrada validada no limite com chaves desconhecidas rejeitadas; toda consulta parametrizada.
4. A API e os workers se conectam através de um pooler com pequenos pools; timeouts de declaração definidos por função.
5. Limites de taxa no edge e na API, chaveados por usuário, tenant e IP. Chaves de cache com escopo de tenant e versionadas.
6. Segredos no cofre da plataforma, um conjunto por ambiente, nunca no git ou em um bundle mobile. Produção e staging são projetos e contas separadas.
7. PITR ativado e uma restauração testada uma vez.
8. Assinatura de webhooks verificada, proteção contra repetição, idempotente, respondida em menos de dois segundos.
9. Timeouts em toda chamada de saída; retries com jitter apenas em trabalho idempotente; jobs com falha visíveis para um humano.
10. ID da requisição e ID do tenant em cada linha de log; alertas sobre taxa de erro, latência p95, contagem de 5xx, idade da fila, jobs com falha, conexões com o banco de dados.

Mobile

1. Aplicativo React Native ou Expo existente: permanece.
2. Novo aplicativo, apenas iOS ou iOS primeiro: Swift e SwiftUI nativos. Grandes empresas foram para nativo em 2026 (Shopify de volta para Swift e Kotlin, Notion para SwiftUI) porque agentes de codificação removeram o custo da segunda base de código; o mesmo vale para uma equipe pequena. Kotlin apenas quando o Android é realmente construído.
3. Novo aplicativo que deve lançar iOS e Android no mesmo dia com uma ou duas pessoas: Expo.
4. De qualquer forma, o aplicativo se comunica apenas com a API, mantém tokens em armazenamento seguro e não envia nada secreto no bundle.

Arquivos de Referência

• references/providers-and-tiers.md: a tabela por camada (prática de grandes empresas, fornecedores tier 1, 2, 3, gatilho, custo) e as regras de seleção que transformam uma descrição de projeto em escolhas.
• references/migrations.md: o manual passo a passo para mover cada camada para um tier superior.
• references/architecture.md: o diagrama com rótulos de tier, os três caminhos de requisição, layouts de repositório, ambientes, configuração de edge e plataforma.
• references/security.md: tenancy e RLS, identidade, segredos, cabeçalhos, entrada, uploads, webhooks, criptografia, exclusão e exportação, mobile, log de auditoria, incidentes.
• references/rate-limiting.md: quatro camadas com números e o middleware.
• references/caching.md: cada camada de cache, esquema de chave, TTLs, invalidação, proteção contra estampida.
• references/database.md: regras de esquema, funções, pooling, m...