Acerto com a CLI wslc 2.9.9: o que ela mudou, e o que ela ganhou

[blackfoxsoftware]

O que aconteceu

O Windows Update subiu a wslc de 2.9.4 para 2.9.9 e quebrou o app. O --format json virou NDJSON — um objeto por linha, sem array em volta — e network list renomeou Id para ID. A view Redes morria em Unexpected non-whitespace character after JSON.

Junto vieram duas falhas silenciosas, que não davam erro nenhum na tela:

O que estava quebrado	Por quê
CPU e memória sempre vazias no motor CLI	o stats falhava no JSON e caía em --no-stream, que deixou de existir
Três das quatro limpezas nem rodavam	nenhum prune da 2.9.9 aceita --force — e image/volume prune precisam de --all, senão limpam só as pendentes e os anônimos

Agora toda listagem passa por parseJsonLines, que aceita as duas formas: a CLI é instalada pelo Windows Update, não por nós, e o app não escolhe qual versão vai encontrar.

O comando que faltava inteiro

A auditoria desta vez foi feita contra a árvore de --help da CLI, recursivamente, e não contra uma lista nossa. Foi assim que apareceu o container cp — que duas auditorias anteriores deixaram passar justamente por enumerarem o que já conhecíamos.

Ele entra como diálogo próprio, nos dois sentidos, e não é igual ao docker (medido contra o loja-web):

• entrando, o destino precisa ser uma pasta que já existe — caminho de arquivo dá ERROR_PATH_NOT_FOUND se não existir, e extraction point is not a directory se existir. A wslc não renomeia.
• saindo, o destino pode ser um arquivo novo, que ela cria.

O rótulo diz "Pasta de destino" só do lado que morde. Some no motor nativo: não há nenhuma API de cópia entre as 62 do header.

Duas decisões de interação

Os logs abriam despejando o arquivo inteiro desde o primeiro byte, porque só mandávamos --follow. O botão da lista agora pede uma cauda de 500 linhas, e o título do painel diz qual recorte está em tela — a diferença entre "o log todo" e "as últimas 500" não aparece em lugar nenhum, e quem procura uma linha que não está ali precisa saber por quê. "Logs com opções…" escolhe linhas, hora e intervalo. No motor nativo o log vem por callback, sem recorte, e lá o título não promete o que não pode entregar.

A remoção forçada não virou item de menu. A ação normal continua onde estava e, quando a CLI recusa por "em execução" ou "em uso", o botão Remover mesmo assim aparece no próprio aviso da falha — quem clica já leu o motivo. O dublê de mock.ts passou a seguir as mesmas duas regras da CLI, senão esse caminho só existiria contra a máquina de verdade.

O resto da 2.9.8/2.9.9

network connect com as cinco opções novas (alias, IP, link, link-local, driver-opt) · --ip-range no create · as nove opções do image build numa aba Avançado · container create como "criar sem iniciar" · --ip/--mount/--pull no run · as cinco do exec · sinal e espera no stop · labels de volume.

Atenção a um nome: o -f de volume rm e network rm não é força — a ajuda da CLI diz "não gere erro se não existir". É idempotência, e por isso só é usado na remoção em massa, onde a lista pode ter envelhecido entre ler e remover. Força de verdade só existe em container rm e image rm.

Outros nomes curtos em que a wslc não copiou o docker, todos lidos no --help do próprio comando: -n no logs (não --tail), -t/--time no stop (não --timeout), -o como --output no build enquanto em volume/network create é --opt.

Verificado nesta máquina

• npm run check — 383 testes de unidade (eram 352), typecheck, lint e formatação
• npx playwright test — 178 E2E (eram 165)
• cada flag sondada contra a wslc 2.9.9 instalada antes de entrar no código, incluindo os caminhos destrutivos num container e numa rede descartáveis; o cenário loja-* ficou intacto
• o que é exclusivo da CLI some da tela no motor nativo, em vez de falhar depois de clicado

Um teste do terminal era uma corrida latente e foi corrigido junto: getByText('conectado') casava tanto o chip de status quanto o "Conectado a…" que o shell imprime, e quebrava por strict mode dependendo de quem chegasse primeiro.