Altere uma CLI de desenvolvimento web feita de JavaScript e código nativo na camada certa

## Encontre a camada dona de um comportamento da CLI e siga os caminhos global e local Antes de editar, associe a solicitação ao componente responsável pelo comportamento: - pontos de entrada JavaScript ou TypeScript controlam o comportamento de alto nível da CLI local e as exportações dos pacotes; - crates nativos controlam o binário global independente, o bootstrap do runtime, a integração com o gerenciador de pacotes, instaladores, migrações e utilitários de processo compartilhados; - o binding nativo controla a ponte entre a CLI JavaScript local e as implementações nativas dos comandos; - pacotes centrais expõem as superfícies integradas de build, teste, documentação e empacotamento; - as ferramentas do repositório controlam registros locais, auxiliares de build, fixtures e suporte a releases; - a documentação e as orientações de projeto geradas são produtos separados com fontes diferentes. Rastreie separadamente as rotas global e local de um comando quando ambas puderem implementar a mesma operação para o usuário. Uma correção em uma rota permanece incompleta se a outra continuar inconsistente. Não edite orientações de projeto geradas quando a tarefa tratar apenas das instruções para colaboradores do repositório. Prefira documentos canônicos de arquitetura e configuração a explicações copiadas. ## Separe os comandos embutidos das tarefas do executor de tarefas Diferencie os comandos integrados da cadeia de ferramentas do executor de tarefas. Um comando integrado de teste, build, lint ou formatação pode chamar uma implementação incluída, enquanto um comando de execução inicia um script de pacote ou uma tarefa configurada com o mesmo nome. Trate scripts de pacote como alvos de execução de primeira classe. Use configuração explícita somente quando uma tarefa precisar de dependências, cache, configuração de comando, rastreamento de entradas ou rastreamento de ambiente. Cada nome de tarefa deve ter um único proprietário. Não defina o mesmo nome nos scripts de pacote e na configuração das ferramentas. Mantenha a configuração de tarefas no arquivo canônico atual; não reintroduza formatos independentes de configuração já desativados. Mantenha as importações públicas de teste na superfície de pacote suportada e gere shims de compatibilidade pelo script de build responsável. Não recrie pacotes desativados nem presuma que uma dependência externa faça parte do workspace local. Antes de alterar o routing, inspecione a ajuda dos comandos, as versões das ferramentas incluídas, as exportações dos pacotes e a documentação de tarefas mais próxima. ## Escolha os testes mínimos que cobrem o tipo de alteração Use o menor conjunto de validações que cubra o comportamento alterado: - documentação ou orientação para agentes: verifique caminhos, comandos, links e espaços em branco referenciados; - comportamento da CLI JavaScript: execute a verificação do repositório, testes unitários e testes direcionados do pacote; - comportamento da CLI nativa ou de um crate: execute verificações, testes e lint nativos; - apresentação de comandos ou design de interação: execute testes direcionados de snapshot em pseudoterminal e revise o diff; - comportamento da CLI global: refaça o build e instale o binário global local, depois verifique sua versão e os comandos afetados; - comportamento de release ou empacotamento: execute o build de release; - integração antes do merge: faça o bootstrap da CLI, execute todos os testes e inspecione o status do repositório. Use o modo de correção somente quando as reescritas de formatação ou lint estiverem intencionalmente no escopo. Para mudanças de comportamento, localize o teste existente mais próximo antes de editar e adicione cobertura na mesma área. Não execute suítes amplas e sem relação com alterações exclusivas de documentação. Também não afirme que o routing da CLI está correto apenas com base em testes unitários quando houver dispatch de ferramentas incluídas. ## Adicione testes de snapshot em pseudoterminal que rodem no Unix e no Windows Coloque novos casos de linha de comando e fluxos interativos na estrutura de snapshots em pseudoterminal do repositório. Defina cada caso com uma matriz explícita de argumentos, não com uma string de shell. Use comandos auxiliares da estrutura em vez de utilitários básicos específicos da plataforma, para que a mesma fixture se comporte igualmente em Unix e Windows. Declare se o caso se destina à CLI local, à global ou a ambas; casos locais exigem uma distribuição local recém-compilada. Diferenças de snapshot devem falhar com um diff revisável e produzir um arquivo candidato de resultado. Atualize snapshots somente pelo modo explícito de gravação e revise o resultado gravado como código antes do commit. Em mudanças na experiência dos comandos, teste o comportamento específico e sua transcrição. Em comportamento de instalação ou migração, forneça o checkout empacotado pela interface de registro local do repositório, em vez de contornar o comportamento real do gerenciador de pacotes. Mantenha explícitos os marcos interativos e os passos de teclas, para que uma falha identifique a fase que divergiu. ## Siga as regras de lint de cada linguagem e altere arquivos gerados só pelo gerador No código nativo, siga as restrições de lint, os auxiliares compartilhados de saída, a configuração do ambiente, o tratamento de caminhos e o estilo dos comandos próximos. Em TypeScript, use o compilador canônico, os auxiliares de saída no terminal e a configuração de tarefas do repositório. Não duplique regras da linguagem na orientação para colaboradores quando a fonte oficial for o linter, a configuração do compilador ou uma referência do código. Trate bindings, shims, arquivos de agentes, distribuições e resultados de snapshots gerados como artefatos com proprietário definido. Altere-os somente pelo gerador correspondente ou pelo fluxo explícito de aceitação de snapshots. Limite o diff à camada proprietária solicitada e deixe intactos os arquivos rastreados ou não rastreados que não tenham relação com a tarefa. Se um arquivo gerado mudar inesperadamente, investigue a fonte ou o gerador em vez de aplicar um patch ao derivado. Ao validar uma CLI global instalada, use o caminho de bootstrap documentado e confirme a versão resolvida. Não conclua que um build de pacote também atualizou o binário instalado. ## Depure comparando o caminho nativo global com o caminho JavaScript local Comece registrando as versões dos componentes incluídos e inspecionando a ajuda geral e a ajuda específica de cada comando. Em defeitos de routing, compare o caminho nativo global com o caminho local de JavaScript e binding. Em defeitos de configuração, compare a extração estática com a resolução alternativa em JavaScript. Em defeitos do gerenciador de pacotes, inspecione a superfície de comandos, a camada de instalação e os snapshots de terminal relacionados. Em defeitos de check, lint, formatação, verificação de tipos ou testes, valide o comando de ponta a ponta. O routing das ferramentas incluídas pode fazer testes isolados de pacote passarem enquanto a configuração do usuário é silenciosamente ignorada. Quando uma falha depender da variante local ou global, reproduza ambas explicitamente. Quando depender de um resultado gerado, refaça o build do derivado exato antes de concluir que a correção na fonte não funciona. Use as orientações de navegação para encontrar os arquivos oficiais; não permita que um guia curto para agentes substitua a documentação detalhada de arquitetura, migração, tarefas ou snapshots.