Altere e revise um gateway de integração multiprotocolo sem quebrar as verificações de acesso

## Encontre as instruções mais próximas e, em caso de conflito, confie no código em execução Comece pelas orientações gerais do repositório e depois localize as instruções específicas do domínio mais próximas dos arquivos que serão alterados. Testes, plugins, gráficos de implantação, documentação, servidores de protocolo e ambientes de execução sensíveis a desempenho podem ter fluxos distintos. Não aplique as regras de uma área a outra sem evidências. Diferencie as orientações para quem contribui com código das instruções de execução para usuários finais. O material escrito para um modelo ou cliente que usa o sistema implantado não governa automaticamente os agentes que modificam a base de código. Mapeie o sistema antes de editar: - Pontos de entrada da aplicação e configuração do ambiente. - Esquemas de validação, modelos de persistência e migrações. - Serviços de negócio, rotas, middleware e transportes de protocolo. - Autenticação, autorização, plugins e limites de federação. - Testes, documentação, recursos de implantação e interfaces administrativas. Quando as fontes divergirem, priorize o código ativo em execução e a configuração oficial; depois, os alvos de build e as dependências compatíveis; em seguida, os exemplos de ambiente; por fim, a documentação ou os comentários. Confirme a implementação atual antes de repetir contagens numéricas ou limites operacionais que possam ficar desatualizados. Inspecione primeiro os caminhos de código-fonte ativos. Ignore áreas de trabalho temporárias, logs, resultados de cobertura, artefatos gerados e pastas de tarefas adiadas, a menos que a solicitação os inclua expressamente. ## Rode as verificações do projeto e a detecção de segredos após cada alteração Use o executor de tarefas aceito pelo repositório e a cadeia de ferramentas com versões fixadas, em vez de chamar as ferramentas subjacentes com opções improvisadas. Valide o ambiente de desenvolvimento com o exemplo oficial, execute as etapas obrigatórias de preparação ou geração de interfaces e escolha o servidor local ou modo de teste correspondente à tarefa. Depois de alterar o código: 1. Execute as verificações de formatação, lint, tipos, segurança e documentação que cubram diretamente a linguagem e os arquivos alterados. 2. Use verificações direcionadas durante a iteração e, antes de propor a conclusão, execute o controle agregado de qualidade exigido pelo repositório. 3. Para uma linguagem de sistemas secundária ou um ambiente de alto desempenho, execute a verificação do formatador, o linter tratando avisos como erros e os testes do crate ou pacote. 4. Reconstrua os recursos administrativos ou de cliente gerados quando as fontes deles mudarem. 5. Inclua testes de comportamento para toda alteração visível externamente. Use a detecção de segredos como controle. Para um falso positivo confirmado, aplique a supressão em linha autorizada pelo projeto somente onde ela não puder alterar o comportamento de um teste ou exemplo. Nos demais casos, gere novamente e audite a linha de base aprovada. Nunca suprima uma credencial real nem coloque segredos em configurações confirmadas no repositório. Prefira ampliar a linguagem e os recursos existentes de build e automação. Adicione uma dependência ou nova cadeia de ferramentas apenas quando houver uma necessidade concreta que não possa ser atendida com segurança pelo que o projeto já oferece. ## Verifique separadamente o que cada identidade pode ver e fazer, e negue rotas sem regra Mantenha duas camadas de segurança independentes em cada caminho protegido: - A filtragem de escopo determina quais recursos uma identidade pode ver. - A autorização baseada em papéis determina quais ações essa identidade pode executar. Passar por uma camada nunca substitui a outra. Trate o escopo público da plataforma como visibilidade dentro dela, não como permissão para acesso anônimo pela Internet. Normalize cada classe de token por meio de uma única função oficial de política. Para tokens autocontidos ou antigos de API, a ausência de escopo de equipe ou um escopo vazio deve falhar de forma fechada, limitando a visibilidade ao conteúdo público; o bypass administrativo exige tanto um estado explícito de bypass quanto a condição de administrador confirmada. Para identidades baseadas em sessão, a associação e o estado de administrador persistidos no servidor são a autoridade, enquanto as declarações do token só podem restringir o acesso. Uma interseção vazia deve falhar de forma fechada. Identidades provisionadas por um login externo confiável também devem usar o estado de autorização local persistido, em vez de confiar em declarações externas de privilégios. Aplique estes invariantes: - Autentique antes de estabelecer uma sessão de transporte ou encaminhar uma mensagem e depois imponha a autorização da ação antes de processá-la. - Negue por padrão as rotas protegidas que não tenham um mapeamento explícito de autorização. - Derive a propriedade, a equipe e a identidade da sessão do estado autenticado do servidor; nunca confie em campos de propriedade fornecidos pelo cliente. - Nunca aceite credenciais de entrada do cliente por parâmetros de consulta de URL. - Mantenha desativados por padrão os transportes de alto risco e o roteamento irrestrito entre domínios. - Exija uma lista explícita de domínios permitidos para o tráfego entre gateways; uma lista vazia bloqueia todos os destinos. - Exija que os gateways em comunicação confiem no mesmo emissor e propague somente as credenciais necessárias à autorização remota. No intercâmbio delegado de tokens, nunca encaminhe o token recebido do usuário para o serviço subsequente. Troque-o por meio de um servidor de autorização confiável e encaminhe apenas o token obtido. Trate o destino configurado para a troca como um limite de SSRF e de saída: valide-o ao salvar a configuração, restrinja alterações a identidades privilegiadas, registre um identificador de correlação e nunca grave em logs os tokens recebidos em estado bruto nem os tokens trocados. Alterações sensíveis à segurança devem incluir testes de regressão para acesso não autenticado, escopo incorreto, permissão insuficiente, recursos desativados, destinos não permitidos e outros caminhos de negação. ## Mantenha as gravações de rastreamento e auditoria fora da transação principal Entenda o limite transacional pretendido antes de modificar o código de persistência. Dados da solicitação, registros de observabilidade e registros de auditoria podem usar deliberadamente sessões e garantias de atomicidade diferentes. Gravações de observabilidade de melhor esforço podem usar sessões independentes e breves, com confirmação imediata. Isso preserva rastros e eventos quando a solicitação principal falha, mas também significa que a telemetria não é atômica com a solicitação e pode mostrar estados parciais ou em andamento. As consultas ainda devem usar sessões com escopo da solicitação para aplicar os filtros de visibilidade e autorização. O registro de auditoria também pode possuir sua própria sessão e isolar as próprias falhas. Não passe a sessão já confirmada da solicitação para um gravador de auditoria independente apenas por conveniência; uma segunda confirmação ou reversão pode deixar a transação compartilhada inativa e expor um erro depois que o recurso principal já tiver sido persistido. Se um registro de auditoria precisar ser atômico com a gravação principal, trate isso como uma alteração de projeto explícita que exige revisão, nova semântica de falha e testes. O rastreamento independente pode criar várias sessões de banco de dados por solicitação. Meça a concorrência, monitore sinais de esgotamento do pool e dimensione-o para o banco de dados e a carga reais, em vez de copiar afirmações fixas de capacidade. Não classifique uma estratégia deliberada de persistência síncrona em manipuladores assíncronos como um defeito isolado sem evidências. Converter pontos de chamada individuais pode criar semânticas misturadas; proponha, em vez disso, uma migração coordenada do driver e das transações. ## Consulte o head atual antes de adicionar uma migração de banco de dados Antes de criar uma migração, consulte o head de migração atual. O pai da nova revisão deve referenciar esse head confirmado; nunca adivinhe nem copie o identificador do pai de um arquivo antigo. Depois da criação, confirme que o histórico ainda contém exatamente um único head pretendido. Escreva etapas de migração idempotentes quando as instalações puderem diferir. Inspecione o esquema atual antes de modificá-lo, ignore com segurança uma operação quando uma tabela opcional estiver ausente e evite adicionar uma coluna ou objeto que já exista. Mantenha coerentes os caminhos de criação de um banco novo e de upgrade. Se um downgrade depender da configuração de execução, torne-o hermético: 1. Durante o upgrade, armazene cada valor de configuração necessário em dados auxiliares pertencentes à migração e vinculados à revisão. 2. Durante o downgrade, leia o snapshot armazenado, não o ambiente atual. 3. Use a configuração ativa somente como alternativa de compatibilidade documentada para bancos atualizados antes da existência dos snapshots. 4. Remova o snapshot quando o downgrade terminar. Uma migração que leia a configuração apenas para inserir dados iniciais durante o upgrade não precisa de um snapshot para downgrade, a menos que o downgrade também dependa desse valor. Verifique novamente o head depois de editar e execute os testes relevantes da migração e da aplicação. Se o banco de destino estiver atrasado, leve o banco controlado de desenvolvimento ou teste até o head esperado antes de gerar uma nova revisão. Nunca execute esse upgrade corretivo em produção sem autorização explícita e um plano revisado. ## Confirme os resultados reais e peça permissão antes do push Compare o diff final com a solicitação original, as orientações de domínio mais próximas e os invariantes de segurança acima. Confirme os resultados reais de lint, tipos, análises de segurança, testes, migrações, recursos gerados e documentação, quando aplicável. Não alegue sucesso apenas por inspeção. Use a convenção de commits, a política de assinaturas, os links de issues e o modelo de pull request exigidos pelo repositório. Não faça push nem force-push, não modifique a branch de outra pessoa e não altere o estado externo do projeto até receber autorização explícita. Em revisões públicas e comentários de issues: - Comece pelo que está funcionando antes de levantar preocupações. - Separe achados bloqueantes, sugestões e observações menores. - Explique o risco e ofereça perguntas ou opções, em vez de emitir ordens desnecessárias. - Seja direto sem parecer hostil ou robótico. Não adicione atribuições internas do assistente, comentários operacionais ocultos, credenciais nem estimativas especulativas de esforço a diffs do produto ou mensagens públicas. Crie arquivos ou documentação novos somente quando a alteração realmente exigir. Ao classificar o trabalho, diferencie uma solicitação que aguarda informações de quem a relatou, um bloqueio por dependência e um item aceito, mas adiado. Marque uma issue como resolvida apenas depois que a alteração corretiva for integrada, não apenas implementada localmente. Antes de concluir, confirme que os valores sensíveis continuem fora do controle de versão, que os caminhos de negação de segurança tenham testes, que a prioridade das fontes oficiais tenha sido respeitada e que nenhum conteúdo temporário alheio tenha entrado no diff.