A instabilidade do ambiente global: O caso do desaparecimento da Gemini CLI

Recentemente, enfrentei um problema crítico no meu ambiente de desenvolvimento que serve de alerta para todos que dependem de ferramentas globais via Node/NPM. De um dia para o outro, o comando gemini simplesmente parou de ser reconhecido pelo sistema, disparando o erro: 'gemini' não é reconhecido como um comando interno ou externo...

O Labirinto do Diagnóstico
O que parecia uma simples atualização de ambiente se tornou um "buraco de coelho" técnico:

Sumiço Inexplicável: O comando, que era parte integrante do meu workflow (especialmente para projetos como o Cidade Digital e automações de API), evaporou das Variáveis de Ambiente (PATH).

Conflito de Pacotes: Ao tentar reinstalar, encontrei uma confusão de nomes de pacotes (@google/generative-ai vs @google/generative-ai-docs vs gemini-chat-cli). Onde a SDK foi instalada com sucesso, a CLI (que provê o binário) falhava ou resultava em Erro 404.

Barreiras de Autenticação: O NPM passou a exigir tokens expirados para pacotes que deveriam ser públicos (npm notice Access token expired or revoked), travando o fluxo de recuperação.

Falha das Ferramentas Nativas: Ferramentas de reparo como winget não localizaram a instalação atual para upgrade, criando um estado de "limbo" onde o Node está na versão 22.20.0, mas os pacotes globais estão inacessíveis.

Reflexão Técnica
Este incidente reforça que ambientes de desenvolvimento no Windows, especialmente quando integrados a serviços de nuvem ou atualizações frequentes do Node, são frágeis. O PATH pode ser corrompido, e a gestão de pacotes globais do NPM ainda é um ponto único de falha.

Status atual: Em processo de reconstrução manual do PATH e mapeamento dos binários diretamente via npm config get prefix.

Alguém mais passou por esse reset de pacotes globais após o update do Node 22?

The report concerns a missing global Gemini CLI on Windows, Node 22.20.0, and the npm config get prefix entry point, but names no repository file or test. Start by determining whether the failure belongs to this GitHub Action, then reproduce the PATH and package-installation state; done should be a clearly scoped repository fix with a reproducible test.