Altere um grande monorepositório de plataforma de dados multilíngue e prepare pull requests

## Confira os remotos Git e escolha o branch certo antes da primeira edição Antes da primeira edição ou teste de uma sessão: 1. identifique o fork pessoal e os remotos upstream oficiais; se as funções deles não estiverem claras, solicite a configuração do layout remoto padrão; 2. verifique o registro de data e hora do branch padrão do upstream e atualize-o quando a referência local estiver desatualizada; 3. inspecione a árvore de trabalho e peça ao usuário que proteja as alterações não confirmadas antes de mudar de contexto; 4. escolha o branch de acordo com a tarefa. Para uma revisão existente, determine o head branch, use um branch local correspondente quando houver um e informe a mudança. Se não houver correspondência, pergunte se deve buscar o branch ou usar um branch local com outro nome. Para novas edições, ofereça como opção recomendada um worktree isolado criado a partir do branch padrão do upstream, ou um novo branch baseado nele. Para trabalhos somente de teste, use o branch padrão do upstream. ## Regenere as saídas de referência dos testes e os arquivos de protocolo em vez de editá-los As saídas golden de teste pertencem ao test harness que as gera. Leia a documentação da suíte antes de executar ou atualizar essas saídas, nunca edite diretamente os arquivos gerados de resultados esperados e regenere-os por meio do fluxo de trabalho aceito. Revise cuidadosamente a diferença resultante antes de aceitá-la. As definições de protocolo pertencem à sua fonte de esquema. Leia a documentação armazenada com essas definições antes de alterar mensagens ou campos e não inclua os artefatos de protocolo gerados nas edições manuais. ## Mantenha o código em ASCII e dentro do limite de linha antes da CI Mantenha identificadores, código e comentários em ASCII, a menos que o conteúdo de uma string literal ou de um fixture de teste realmente exija outros caracteres. Verifique por amostragem se os arquivos alterados contêm travessões tipográficos, aspas curvas, reticências ou espaços não separáveis, que muitas vezes entram despercebidos nos comentários. Mantenha as linhas do código-fonte dentro do limite do repositório, geralmente de 100 caracteres. Uma verificação rápida dos arquivos-fonte adicionados e modificados pode estimar as exceções para imports, declarações de package e URLs, mas serve apenas como indício. Os linters específicos de cada linguagem continuam sendo a autoridade. ## Escolha a menor base de teste JVM que atenda ao teste Selecione a menor base de teste que forneça o comportamento necessário. Testes simples de runtime ou de utilitários devem usar a suíte principal apenas com helpers comuns de tempo limite, arquivo temporário, logging e erros. Testes de plano lógico, analisador, otimizador ou planejador devem usar uma base de teste de planos sem iniciar uma sessão SQL. Testes de SQL ou de tabelas devem usar a base de teste de consultas e incluir explicitamente um provedor de sessão como mixin. Escolha uma sessão no mesmo processo para testes SQL comuns e um provedor apoiado por warehouse somente quando o comportamento de warehouse for necessário. Não assuma o custo de um fixture mais amplo apenas porque testes próximos o utilizam. ## Escolha a base de teste Python certa para testes locais, remotos e mistos Testes Python simples devem usar a base padrão de testes unitários. Testes no nível de contexto podem criar um novo contexto de execução por teste para obter isolamento ou reutilizar um contexto por classe para ganhar velocidade. Testes de SQL e DataFrame devem usar a base compartilhada de sessão classic, enquanto testes de extensões de DataFrame podem adicionar execução colunar e asserções especializadas. Testes de protocolo remoto exigem uma decisão separada: use um fixture mock somente de planos quando não for necessário um servidor, uma sessão remota reutilizada para o comportamento remoto real ou um fixture misto classic e remote para verificar a paridade. Trate utilitários SQL, asserções de erros estruturados e helpers de igualdade como mixins ou helpers independentes, em vez de bases de teste, a menos que criem o runtime necessário. ## Compile e teste só o módulo alterado, e pergunte antes da suíte completa Builds e testes podem ser caros. Se o usuário tiver solicitado testes explicitamente, execute-os. Caso contrário, antes de iniciar uma longa verificação da suíte completa, pergunte se mais edições são esperadas. Prefira a ferramenta de build incremental mais rápida do repositório, compile somente o módulo afetado e seu código de teste e execute uma única suíte ou um caso nomeado durante as iterações. Mantenha um shell de build incremental aberto quando isso reduzir o tempo de testes repetidos do módulo. Para suítes Python que dependem de um backend compilado, primeiro gere o perfil de recursos necessário, ative o ambiente virtual escolhido pelo usuário ou o padrão documentado e crie esse ambiente somente quando ele não existir. Use os seletores de suíte e de caso do executor de testes do projeto. ## Liste todas as falhas da CI antes de corrigir qualquer uma Liste todas as verificações com falha no commit em revisão antes de investigar uma falha específica. Uma verificação de resumo de testes aprovada ou ausente não comprova que toda a CI esteja correta; linters, licenças, dependências, verificações de compatibilidade, compilação e geração de documentação podem falhar em jobs separados, sem anotações de teste. Para jobs de teste, use as anotações de falha para obter a suíte, o caso e a mensagem. Para jobs que não sejam de teste, identifique a etapa com falha e leia o log específico desse job. Evite baixar logs muito grandes de testes fragmentados quando as anotações estruturadas já contiverem as evidências úteis. ## Confira se um pull request fechado foi, na verdade, integrado com merge Não presuma que uma revisão marcada como fechada foi rejeitada. Alguns projetos fazem merge por meio de ferramentas personalizadas; por isso, o serviço de hospedagem pode exibir uma revisão integrada com sucesso como fechada e sem um registro de data e hora nativo de merge. Use o helper de estado de merge do projeto para determinar se a alteração foi incorporada e quais branches principais ou de manutenção a contêm. Trate aberto, integrado e fechado sem integração como resultados distintos e informe autenticação ausente, histórico raso, revisões desconhecidas ou remotos upstream ausentes como limitações do ambiente. ## Escreva o título e a descrição do pull request no formato do projeto Siga a convenção de títulos do projeto para identificadores de issue e tags de componentes, incluindo as exceções documentadas para alterações em rascunho, em andamento, pequenas ou triviais. Deduza o título a partir da diferença. Quando faltar um issue obrigatório, crie-o por meio do helper do projeto com o componente exato e um tipo de issue ou uma referência ao item pai; depois, exiba com destaque o issue criado e seus campos para revisão. Leia o template de pull request do repositório antes de redigir a descrição e preencha todas as seções. Use o nome completo do componente quando o rastreador de issues o exigir, em vez da tag de título abreviada. ## Faça push só para o seu fork e peça permissão antes de gravar algo fora Nunca faça `push` para o repositório upstream oficial; faça `push` somente para o fork do colaborador. Não aplique `force-push` nem `amend` a commits que já estejam no remoto, a menos que o usuário solicite explicitamente. Se o branch remoto tiver avançado, execute `fetch` e `rebase` antes do `push`. Obtenha aprovação explícita antes de gravações externas, como enviar commits, criar um pull request, criar um issue ou publicar comentários. Use o cliente autenticado aceito pelo projeto. Se ele não estiver disponível, prepare uma URL de revisão ou instruções exatas de transferência, em vez de contornar o fluxo de trabalho obrigatório. ## Use o número de versão do branch que publica a mudança primeiro Quando o código precisar de uma anotação de versão, uma versão de configuração ou uma exclusão de compatibilidade, use a versão do branch em que a alteração for publicada primeiro e remova o sufixo snapshot. Para uma revisão baseada em um branch de manutenção, use a versão desse branch. Para uma revisão baseada no branch principal, use a versão do branch de lançamento mais recente quando as alterações normalmente receberem backport para ele. Use a versão do branch principal somente em trabalhos exclusivos dele, como uma alteração incompatível ou binariamente incompatível, ou uma atualização de dependência que não justifique um backport crítico. Se o caminho de publicação não estiver claro, pergunte em vez de deduzi-lo apenas a partir do branch principal. ## Leia a política de segurança do projeto antes de informar um problema de segurança Antes de informar um problema de segurança, leia a política de segurança e o modelo de ameaças do repositório. Confirme o escopo declarado, os casos excluídos e os casos documentados que não constituem descobertas, para que o resultado de um scanner seja avaliado em relação às garantias reais do projeto. Mantenha a investigação de segurança separada da triagem comum de bugs, preserve as evidências e não exponha credenciais nem dados locais confidenciais ao documentar uma descoberta.