Alterar um grande sistema de dados em Python sem quebrar a execução preguiçosa

## Seguir o comportamento pedido até a camada responsável por ele Antes de alterar uma grande base de código Python para dados ou computação paralela, crie um mapa específico para a tarefa em vez de ler o repositório indiscriminadamente. Identifique as camadas envolvidas: 1. Coleções públicas ou interfaces voltadas ao usuário. 2. Expressões simbólicas ou grafos de alto nível usados para planejamento e otimização. 3. Tarefas materializadas de baixo nível e arestas de dependência. 4. Escalonadores ou infraestruturas de execução. 5. Camadas de configuração, despacho, serialização e utilitários. Rastreie o comportamento solicitado desde o ponto de entrada público até a menor camada de implementação responsável por ele. Leia os testes e a configuração relacionados antes de editar. Navegue de acordo com a tarefa: - Comportamento de escalonamento: APIs públicas de computação, utilitários de grafos, representações de tarefas e, depois, adaptadores de escalonadores. - Otimização de grafos: protocolos de grafos de alto nível, camadas blockwise ou de expressões e, depois, materialização. - Recursos de arrays ou dataframes: API da coleção, implementação da operação, despacho e, depois, testes específicos. - Alterações de configuração: acessores em tempo de execução, configuração padrão, esquema e documentação. - Compatibilidade com infraestruturas de execução: interface da infraestrutura, registro de pontos de entrada, despacho e testes de compatibilidade. Trate nomes de módulos, contagens de linhas e versões de dependências presentes nas notas do repositório como referências para navegação, não como fatos permanentes. Confirme localmente o código-fonte e os manifestos atuais. Mantenha explícitos os limites entre subsistemas. Uma alteração em uma coleção pública pode exigir atualizações correspondentes nos metadados, no grafo, no escalonador, nos testes e na documentação, mas não edite camadas não relacionadas. ## Usar os ambientes do repositório e escolher o menor escopo de testes Use o gerenciador de ambientes e os comandos declarados pelo repositório. Não presuma que uma instalação global do Python corresponda às combinações de dependências compatíveis. Antes da implementação: 1. Examine o manifesto do projeto e os ambientes disponíveis. 2. Selecione o menor ambiente que represente o recurso afetado. 3. Localize os testes, fixtures, marcadores e auxiliares de asserção existentes mais próximos. 4. Registre as dependências opcionais, os sinalizadores de recurso e as políticas de avisos relevantes. Prefira os wrappers de comandos fornecidos pelo repositório para: - um único teste que esteja falhando; - o arquivo de testes do módulo afetado; - verificações de lint e análise estática; - doctests de exemplos públicos; - ambientes com dependências mínimas ou recursos opcionais; - verificações mais amplas, equivalentes às da integração contínua, somente quando a alteração as justificar. Respeite comportamentos rigorosos dos testes, como tratar avisos como erros, falhas esperadas estritas, limites de tempo e marcadores específicos do ambiente. Use os auxiliares compartilhados de igualdade para coleções preguiçosas quando eles considerarem metadados, tipos, partições ou tolerância numérica. Para dependências opcionais, use os auxiliares de importação e de omissão do projeto em vez de condicionais improvisadas. Considere as versões mínimas e mais recentes compatíveis ao usar novas APIs. Não instale pacotes, altere ambientes nem habilite testes que dependam da rede, a menos que a tarefa autorize isso. Relate uma dependência ausente como limitação do ambiente em vez de alterar silenciosamente a máquina. ## Manter a execução preguiçosa: não chamar `compute()` ao montar grafos Preserve a invariante central dos sistemas de grafos preguiçosos: o código de construção do grafo deve descrever a computação sem executá-la. Nunca chame métodos de materialização imediata, como `compute()` ou `persist()`, ao definir operações de coleções, camadas de grafos ou expressões simbólicas. A materialização deve ocorrer em um limite explícito do usuário ou da execução. Durante a construção do grafo: - deduza os resultados a partir dos metadados sempre que possível; - mantenha as dependências das tarefas explícitas e determinísticas; - preserve chaves estáveis e o comportamento de tokenização; - evite operações de entrada e saída ocultas ou a seleção implícita do escalonador; - mantenha a separação entre a otimização simbólica e a execução de baixo nível. Siga as convenções do repositório: - adicione anotações de tipo completas ao novo código; - mantenha consistentes as importações de compatibilidade e as anotações adiadas; - use importações somente para tipos, protegidas por condições, para evitar ciclos; - organize de forma previsível as importações da biblioteca padrão, de terceiros e locais; - use o estilo de docstring documentado e exemplos executáveis nas APIs públicas; - siga a nomenclatura estabelecida para auxiliares privados, testes e funções de despacho. Ao adicionar uma infraestrutura de execução, expressão, camada ou opção de configuração, atualize todos os pontos de registro necessários e inclua um teste específico que comprove que o despacho ou o planejamento alcança a nova implementação. Os sinalizadores de recurso que afetam o registro durante a importação ou o planejamento de consultas devem ser definidos antes da primeira importação do módulo relevante. Teste tanto o comportamento habilitado quanto o desabilitado quando ambos continuarem compatíveis. Evite refatorações amplas ao corrigir um defeito específico. Preserve os comportamentos não relacionados e faça a menor alteração que explique o novo resultado do teste. ## Ampliar os testes passo a passo e nunca lançar versões sem permissão Faça a verificação em escopo crescente: 1. Reproduza a falha anterior com um teste específico. 2. Execute o arquivo de testes mais próximo ou a suíte do subsistema. 3. Execute as verificações de lint, tipos ou doctest diretamente afetadas pela edição. 4. Exercite as variantes relevantes de recursos opcionais, dependências mínimas ou sinalizadores de recurso. 5. Use a suíte completa somente quando a alteração atravessar limites arquitetônicos amplos. Verifique os modos de falha comuns: - ciclos de importação e ordem de registro; - sinalizadores de recurso alterados após a primeira importação; - metadados que não correspondem aos resultados computados; - pacotes opcionais indisponíveis em alguns interpretadores; - restrições de versões de dependências divergentes entre pacotes relacionados; - padrões de configuração ausentes no esquema; - exemplos de doctest que deixaram de funcionar; - testes que passam somente com um escalonador ou uma infraestrutura de execução. Antes de relatar a conclusão, revise o diff e informe quais verificações realmente foram executadas, quais passaram e quais não foram executadas. Não deduza o sucesso apenas pela inspeção do código. O trabalho de lançamento constitui um limite de autoridade separado. Nunca crie um lançamento, publique pacotes, envie tags, carregue artefatos nem modifique sistemas externos de lançamento, a menos que haja autorização explícita. Se a preparação do lançamento for autorizada, verifique as entradas do changelog, as versões e restrições entre pacotes, a saída do empacotamento e a sequência documentada pelo repositório antes de qualquer alteração de estado externo. Quando houver uma solicitação para se comunicar com outras pessoas, apresente evidências e opções sem se passar pelo usuário nem inventar as decisões dele.