Desenvolva uma plataforma de automação multi-tenant sem misturar tenants ou edições

## Separe os dados de cada tenant e mantenha o código premium fora da edição comunitária Trate o escopo do tenant, as edições do produto, o acesso a recursos e a identidade visual como contratos de segurança e comportamento. ### Imponha o isolamento - Modele explicitamente a propriedade nos níveis de plataforma, projeto e usuário. - Limite cada consulta ao banco de dados pelo identificador correto do projeto ou da plataforma; nunca dependa de quem chama para filtrar os resultados depois. - Exija uma declaração de controle de acesso em cada endpoint. - Aplique a autorização no backend e o middleware de recursos antes do comportamento protegido, retorne a resposta padrão `402` para recursos pagos indisponíveis e espelhe a mesma restrição no guard do frontend e na habilitação das consultas. ### Mantenha a direção entre as edições - Permita que edições premium ou hospedadas ampliem o núcleo comunitário por meio de hooks ou interfaces registrados. - Nunca importe código de aplicação exclusivo da edição premium para o código comunitário. - Mantenha os padrões da edição comunitária sem uma marca específica, aplique a identidade visual configurada nos ambientes hospedados e restrinja a identidade visual empresarial auto-hospedada pela capacidade correspondente do plano. - Verifique o comportamento voltado para clientes em 5 caminhos: edição comunitária auto-hospedada, edição empresarial auto-hospedada, edição hospedada gratuita, edição hospedada paga e edição empresarial hospedada. - Faça com que todos os nomes, cores, logotipos, telas de login e mensagens voltados para clientes sejam definidos pela aparência configurada, em vez de codificar a marca do produto de forma fixa. ## Declare as dependências em cada espaço de trabalho e bloqueie os dados compartilhados entre servidores Deixe explícitos a propriedade das dependências e o comportamento concorrente dos dados para que o sucesso local corresponda à implantação em produção. ### Mantenha os limites dos pacotes - Organize as bibliotecas compartilhadas desde fundações leves e independentes de framework até pacotes pesados no nível da aplicação. - Permita que integrações reutilizáveis e mecanismos de execução dependam somente de pacotes leves; exponha o comportamento necessário da aplicação por meio de uma camada estreita de framework. - Declare cada dependência de tempo de execução no espaço de trabalho que a importa e cada dependência de teste ou ferramenta nas dependências de desenvolvimento desse espaço de trabalho. - Reserve o manifesto raiz para ferramentas de todo o repositório ou verdadeiros requisitos de inicialização. - Fixe as versões de modo consistente e atualize o arquivo de bloqueio com o instalador canônico após alterações nas dependências. ### Proteja a persistência e a concorrência - Registre novas entidades explicitamente quando o mapeador de objetos não as descobrir de forma automática. - Separe os efeitos colaterais em módulos dedicados e invoque-os explicitamente após mutações bem-sucedidas. - Para trabalhos em vários servidores, use um bloqueio distribuído, deduplicação de fila ou bloqueio de linhas com semântica `skip-locked`. - Evite extensões de banco de dados indisponíveis em serviços gerenciados. - Higienize objetos fornecidos externamente antes de armazená-los no banco de dados. ## Evite any e conversões de tipo forçadas, e use os helpers compartilhados do projeto Use interfaces, fluxo de dados, organização de arquivos e utilitários compartilhados que sejam previsíveis. ### Preserve a integridade dos tipos - Não use `any`; use tipos precisos ou `unknown` com guardas de tipo. - Não force valores por meio de conversões de tipo. Corrija o tipo de origem, adicione validação ou restrinja o tipo do valor. - Consulte a documentação da biblioteca antes de usar uma API e substitua tudo o que estiver marcado como obsoleto. - Use um único parâmetro de objeto desestruturado para toda função com mais de 1 parâmetro. - Prefira fluxo de dados imutável entre funções; crie e retorne novas coleções em vez de alterar objetos pertencentes a quem chama. ### Torne as convenções explícitas - Use os helpers de resultado compartilhados do projeto para tratamento de erros síncronos e assíncronos. - Transforme as mensagens de validação voltadas ao usuário em chaves de localização; use chaves compartilhadas para erros comuns de formulário e crie novas chaves quando necessário. - Depois de verificar a branch atual, aumente a versão de patch de um pacote compartilhado para correções ou adições compatíveis e a versão minor para novas exportações ou comportamentos. - Defina helpers não exportados como funções independentes, mantenha a lógica executável primeiro e agrupe constantes e tipos exportados no final, em vez de intercalá-los com a lógica. - Comente por que uma decisão existe, não o que um código autoexplicativo faz. - Exporte vários utilitários simples por meio de 1 objeto nomeado e mantenha os componentes React como exportações nomeadas. ## Envie o HTTP de saída pelo cliente seguro para evitar SSRF e siga as regras da API Aplique semântica explícita de requisições e clientes de rede seguros em cada limite não confiável. ### Padronize os endpoints - Use `POST` para todas as mutações de criação e atualização e `DELETE` para exclusão; nunca use `PUT` ou `PATCH` quando o contrato da API não os incluir. - Dê a cada endpoint uma configuração explícita de acesso de segurança. - Use identificadores, tipos de erro, bases de schema, helpers de coleção e higienizadores de banco de dados canônicos, em vez de implementá-los novamente. ### Evite falsificação de requisições do lado do servidor - Encaminhe as requisições HTTP de saída dos componentes de servidor pelo cliente seguro aprovado. - Nunca use `fetch` sem proteção nem uma fábrica de clientes irrestrita para URLs originadas de entradas do usuário, configurações de administrador, endpoints OAuth ou integrações de terceiros. - Preserve a filtragem de endereços privados, de loopback e de metadados da nuvem. - Mantenha coerção de tipos, validação de URL e higienização de objetos externos no limite. ### Trate migrações como alterações controladas - Leia o guia de migrações do repositório antes de criar ou modificar uma migração. - Siga o processo documentado de geração e estrutura, em vez de inventar o layout da migração. - Mantenha as migrações compatíveis com o ambiente de banco de dados gerenciado suportado. ## Mostre o diálogo global de erro só quando os dados principais da página falharem Mostre falhas globais de consultas somente quando os dados que falharam forem essenciais para a página atual. ### Classifique as consultas pelo impacto - Defina o sinalizador de metadados da consulta que aciona o diálogo global de erro para dados principais da página, como linhas de tabelas ou listas principais. - Não o habilite para dados auxiliares, como sinalizadores de recursos, metadados, buscas individuais, opções de filtro ou detalhes do usuário. - Use esta regra de decisão: mostre o diálogo se, de outra forma, a falha deixaria uma página em branco sem explicação ou uma visualização principal vazia. - Permita que consultas menores falhem silenciosamente quando a interface ao redor continuar útil. - Mantenha desabilitadas as consultas restritas por recursos até que a capacidade correspondente do plano esteja disponível. ## Teste o isolamento entre tenants e cada edição com o executor de tarefas do monorepositório Execute testes focados pelo executor de tarefas canônico do monorepositório e verifique os caminhos que diferem conforme a edição. ### Exercite o código e os dados - Execute testes unitários para código compartilhado e de execução e testes de integração para o comportamento da API. - Use os helpers padrão do ambiente de teste e do contexto da requisição para que a autenticação e o roteamento correspondam ao comportamento em produção. - Garanta que os dados de teste estejam isolados e sejam limpos entre os testes. - Adicione testes de concorrência quando o código usar bloqueios, deduplicação ou seleção no banco de dados com `skip-locked`. - Teste o isolamento entre tenants comprovando que dados de outro projeto ou plataforma não podem ser retornados. ### Use os comandos suportados - Execute o comando obrigatório do repositório para verificar e corrigir o lint antes de considerar a tarefa concluída. - Use o executor de tarefas configurado do monorepositório e comandos com filtro de pacotes; não invoque um sistema de compilação não relacionado. - Quando um frontend hospedado apontar para um backend remoto, evite fluxos OAuth que redirecionem para o domínio hospedado; use credenciais sem redirecionamento ou um backend totalmente local. - Verifique restrições de edição, identidade visual, limites e disponibilidade de recursos em todos os caminhos suportados. ## Rotule a alteração e conclua só depois que as verificações obrigatórias passarem Use a documentação do recurso, rótulos e verificações finais para tornar a alteração compreensível e pronta para lançamento. ### Prepare a implementação - Antes de modificar um recurso, leia a documentação específica dele sobre entidades, serviços, fluxos de dados e restrições de integração. - Mantenha regras críticas de segurança que atravessam o sistema concisas e separadas dos fluxos passo a passo do recurso. - Revise manifestos de dependências, registro de entidades, filtros de tenants, importações entre edições, declarações de acesso e ordem dos efeitos colaterais. ### Prepare a contribuição - Aplique exatamente 1 rótulo principal de alteração que diferencie um recurso, uma correção de erro ou uma alteração interna isenta do registro de mudanças. - Adicione um rótulo separado de área de integração quando a alteração afetar uma integração de terceiros ou do núcleo. - Confirme que o arquivo de bloqueio, a versão do pacote, as chaves de localização, os testes e os artefatos gerados correspondam à implementação. - Execute as verificações obrigatórias de lint, testes e segurança e informe qualquer verificação que não tenha sido executada. - Não declare a conclusão até que o diff final e os resultados da verificação a sustentem.