tw93/Mole

O problema

Ao avaliar a memória no painel de estado, o utilitário executava uma ferramenta de diagnóstico e procurava no texto termos que indicassem alerta ou normalidade. Como essa ferramenta reporta apenas contadores de páginas e percentual livre sem nomear os níveis de pressão, o campo de pressão ficava eternamente vazio. Com isso, alertas de sobrecarga não eram emitidos e a nota de integridade da máquina deixava de considerar o aperto de memória do sistema operacional.

O que foi feito

A sonda passou a consultar a propriedade do kernel que informa o nível real de pressão do macOS, convertendo os códigos numéricos em estados legíveis de atenção ou estado crítico. A exibição do cartão de memória foi ajustada para destacar o aviso apenas quando a memória realmente exigir intervenção, evitando ruído visual no estado normal. Testes automatizados conferem o mapeamento dos códigos numéricos, a leitura pelo caminho absoluto do sistema e a renderização do alerta.

Valor entregue

O usuário recebe avisos reais quando o Mac entra em pressão crítica de memória, auxiliando no diagnóstico prévio de lentidão antes de travamentos.

Ver o PR #1964 no GitHub

O problema

Ao consultar os dispositivos Bluetooth no macOS, o utilitário esperava encontrar uma linha individual indicando conexão em cada acessório listado. O relatório do sistema operacional, contudo, agrupa os periféricos abaixo de cabeçalhos de seção de conectados e desconectados sem repetir esse indicador em cada um. Por tratar esses cabeçalhos como atributos sem confirmação, o analisador definia todos os aparelhos como desconectados nas exportações e no monitoramento contínuo.

O que foi feito

Diferente da limpeza de discos e da sonda de memória do kernel, esta alteração aprimora o analisador de periféricos: a rotina passou a identificar os cabeçalhos de seção, aplicando o estado de conectado aos itens sob o grupo correspondente e desconectado aos demais. Caso um periférico traga seu próprio indicador explícito de conexão, essa preferência continua sendo respeitada para garantir compatibilidade com diferentes versões. Testes automatizados cobrem tanto a listagem agrupada quanto relatórios com indicadores individuais.

Valor entregue

O relatório estruturado do sistema passa a refletir fielmente quais teclados, mouses e fones estão conectados ao computador no momento da consulta.

Ver o PR #1968 no GitHub

O problema

Ao limpar arquivos de metadados ocultos em volumes externos, o utilitário calculava o tamanho de cada item antes da remoção ou simulação. Se um arquivo ficasse inacessível por permissão, desaparecesse durante a varredura ou demorasse para responder, o laço de execução era abortado imediatamente. Isso impedia a limpeza de todos os outros itens do disco e encerrava o comando com código de erro e aviso de operação incompleta.

O que foi feito

Diferente da leitura de pressão do sistema operacional no painel de estado, esta mudança atua na rotina de limpeza de discos externos: o cálculo de tamanho dos metadados foi alinhado ao padrão tolerante a falhas do utilitário, continuando o processamento em erros de leitura e registrando tamanho zero. Interrupções reais do sistema ainda encerram a execução de imediato, enquanto atrasos marcam o valor como parcial na simulação. Testes automatizados confirmam que arquivos ilegíveis ou com tempo esgotado não impedem a limpeza do restante do volume.

Valor entregue

Discos externos têm sua manutenção concluída com sucesso mesmo diante de arquivos de metadados corrompidos ou bloqueados pelo sistema de arquivos.

Ver o PR #1966 no GitHub

O problema

O executor de testes automatizados Cypress armazena seus binários e aplicativos de execução dentro do diretório de caches da biblioteca do macOS. Durante as rotinas de limpeza do sistema, a ferramenta tratava essa pasta como arquivo temporário descartável e apagava todo o seu conteúdo. Com isso, qualquer nova execução de testes de software era interrompida até que o download de mais de um gigabyte de dados fosse concluído novamente.

O que foi feito

O PR propõe incluir o diretório do Cypress na lista padrão de bloqueio contra exclusão e nos padrões protegidos do utilitário, adotando a mesma salvaguarda já aplicada a navegadores de automação como Playwright. O caminho também é adicionado ao catálogo interativo de exceções configuráveis. Testes automatizados confirmam que as funções centrais de proteção recusam a remoção do diretório e dos binários instalados.

Valor entregue

Mantém o ambiente de testes de software funcional após as rotinas de limpeza e poupa tempo e consumo de banda ao dispensar downloads redundantes.

Ver o PR #1946 no GitHub

O problema

O Mole tem um modo de simulação que mostra o que uma limpeza faria sem apagar nada. Nas funções que localizam arquivos por padrão e os excluem, com e sem privilégios, cada candidato era registrado no livro de simulação, mas a condição que deveria pular para o próximo só o fazia quando o registro falhava. Com registro bem-sucedido, a execução seguia até a rotina de remoção, que, por também estar em simulação, media o tamanho do arquivo de novo e registrava o mesmo candidato pela segunda vez. Além do trabalho repetido, a duplicata provocava um falso código de erro quando o arquivo de livro não estava definido, e a contagem da variante com privilégios ficava errada.

O que foi feito

As duas funções passaram a avançar para o próximo candidato logo após registrá-lo, sem chegar à rotina de remoção; a variante com privilégios ainda contabiliza o candidato aceito antes de seguir. Dois testes automatizados criam arquivos, executam cada função em simulação com a rotina de remoção substituída por um rastreador e verificam que nada foi removido, que cada alvo entrou uma vez no livro, que a contagem bate e que o código de saída é zero.

Valor entregue

A simulação mostra exatamente o que a limpeza real faria, com cada arquivo contado uma vez e sem falhas falsas, o que sustenta a confiança de quem revisa antes de apagar.

Ver o PR #1866 no GitHub

O problema

Quase todos os comandos da ferramenta oferecem o atalho abreviado com a letra n para permitir a simulação prévia das ações sem aplicar nenhuma alteração real no sistema. No entanto, o módulo de otimização de serviços e caches aceitava apenas o argumento longo completo, acusando opção desconhecida e encerrando com erro quando o usuário informava o atalho comum.

O que foi feito

O interpretador de opções do comando de otimização passou a aceitar o atalho abreviado ao lado da opção longa, ativando o mesmo modo de simulação segura. O texto de ajuda do comando foi atualizado e novos testes automatizados na suíte BATS verificam tanto a documentação quanto a execução correta da opção.

Valor entregue

Padroniza as opções de simulação entre todos os comandos da ferramenta e evita falhas inesperadas na linha de comando.

Ver o PR #1842 no GitHub

O problema

Ao abrir o menu interativo do Touch ID sem argumentos em um ambiente automatizado ou com o canal de entrada padrão fechado, a rotina de leitura de teclado recebia um sinal de fim de transmissão. Esse retorno era interpretado como a tecla Enter pressionada, o que acionava imediatamente a elevação de privilégios para habilitar ou desabilitar o Touch ID nos arquivos de autenticação do macOS, modificando configurações sensíveis sem autorização humana.

O que foi feito

As duas opções do menu interativo, tanto para ativar quanto para desativar o recurso, passaram a validar se a leitura do teclado teve êxito antes de prosseguir, abortando imediatamente com código de erro se o canal for encerrado. Novos testes automatizados com a ferramenta BATS confirmam que a execução sem entrada interativa é rejeitada em ambos os estados e preserva as configurações do sistema intactas.

Valor entregue

Impede modificações acidentais e não autorizadas nas regras de autenticação do sistema operacional em fluxos automatizados.

Ver o PR #1840 no GitHub

O problema

Ao executar a configuração de autocompletar de comandos em ambientes automatizados ou sem um terminal interativo conectado, a leitura do teclado recebia o fim imediato do fluxo de entrada de dados. A rotina tratava esse sinal como uma tecla de confirmação pressionada e gravava automaticamente novas instruções nos arquivos de inicialização do interpretador de comandos do usuário, sem autorização explícita.

O que foi feito

A rotina de confirmação passou a verificar o retorno da leitura de teclado e a abortar a operação com código de erro caso o canal de entrada seja fechado. Testes automatizados na suíte BATS garantem que execuções direcionadas sem entrada encerram com cancelamento e preservam intactos os arquivos de configuração do terminal.

Valor entregue

Impede que scripts e rotinas automatizadas alterem os arquivos de configuração do shell do usuário de forma inesperada.

Ver o PR #1838 no GitHub

O problema

O comando de limpeza de discos externos foi projetado para apagar com segurança apenas arquivos temporários e ocultos em unidades removíveis conectadas via USB. Para evitar perdas acidentais de dados, a ferramenta consulta o utilitário de discos do sistema e recusa volumes identificados como armazenamento interno. Nas versões recentes do macOS, o utilitário alterou a identificação de disco interno de uma linha com chave própria para um campo de localização do dispositivo. Com isso, o filtro falhava e volumes internos secundários podiam ser limpos por engano.

O que foi feito

A validação passou a verificar tanto o formato antigo quanto a nova descrição de localização física do utilitário de discos do macOS. Um novo teste automatizado com simulação de saídas do sistema confere que volumes internos em ambos os padrões são recusados enquanto mídias externas continuam sendo aceitas normalmente.

Valor entregue

Impede que discos e partições internas do computador sejam limpos por engano ao executar a manutenção de unidades externas.

Ver o PR #1819 no GitHub

O problema

No macOS moderno, os dados do usuário ficam fisicamente armazenados em um volume separado montado pelo sistema. É comum desenvolvedores criarem links na raiz, como uma pasta para códigos-fonte apontando para esse volume. Ao executar a faxina de artefatos de compilação, o comando resolvia o caminho físico completo, que começa pelo diretório do sistema. A trava de segurança contra exclusão de arquivos essenciais interpretava esse prefixo como parte do sistema operacional e bloqueava a limpeza de dependências e caches de projetos.

O que foi feito

O validador de caminhos passou a reconhecer diretórios no volume de dados que correspondam a pastas acessíveis a partir da raiz, aplicando a essas exclusões as mesmas regras de segurança da pasta original. Caminhos críticos do sistema operacional e áreas reservadas do próprio volume continuam estritamente protegidos. Testes automatizados confirmam que pastas de trabalho são liberadas para limpeza enquanto diretórios do sistema permanecem bloqueados.

Valor entregue

Permite que desenvolvedores limpem caches e dependências pesadas de compilação em pastas personalizadas do macOS sem esbarrar em falsos alertas de segurança.

Ver o PR #1817 no GitHub

O problema

No macOS, a autenticação por Touch ID no comando de privilégios do sistema é configurada em arquivos de regras de acesso, e o próprio sistema disponibiliza um modelo de exemplo contendo a regra comentada por padrão com um sinal de sustenido. Ao verificar a ativação do recurso, o Mole procurava apenas pelo nome do módulo em qualquer parte do arquivo. Por causa dessa checagem ampla, se o usuário copiasse o modelo do sistema ou desativasse a regra manualmente por comentário, a ferramenta concluía que o Touch ID já estava ativo e se recusava a ativá-lo, além de exibir mensagens incoerentes ao pedir autorização.

O que foi feito

A verificação de configuração foi centralizada em uma função que exige que a regra do Touch ID não possua comentários antes do nome do módulo na mesma linha. Testes automatizados com a suíte BATS comprovam que arquivos com regras comentadas são reconhecidos como desativados e que o comando de ativação grava a regra funcional corretamente.

Valor entregue

Permite habilitar o Touch ID no terminal mesmo quando o arquivo do sistema já possui o modelo padrão comentado pelo macOS.

Ver o PR #1816 no GitHub

O problema

Ao rodar a atualização interativa do Mole, a descoberta da versão estável mais recente consultava exclusivamente a API e o redirecionamento de lançamentos do GitHub. Sob limites de requisições ou instabilidades de rede, essas consultas falhavam e o comando era abortado com erro de conexão, mesmo quando a máquina continuava com acesso total aos repositórios via git.

O que foi feito

O PR propõe uma busca de contingência via consulta de tags remotas com git quando a API não responder. A chamada opera em ambiente isolado e com tempo limite curto, filtrando apenas tags válidas do macOS para ignorar versões de outras plataformas, e testes automatizados confirmam o acionamento da alternativa em caso de falha da API.

Valor entregue

Com a mudança, atualizar o Mole não falha por oscilações temporárias de limites de API, aumentando a confiabilidade da manutenção do sistema.

Ver o PR #1776 no GitHub

O problema

Depois de desinstalar um aplicativo, o Mole inspeciona os arquivos de inicialização do terminal para alertar sobre atalhos e variáveis que continuam apontando para o binário removido. Embora o utilitário tenha suporte nativo ao shell Fish em autocompletar e remoção, essa checagem pós-desinstalação cobria apenas arquivos de Bash, Zsh e agentes de IA, deixando de inspecionar a configuração do Fish.

O que foi feito

O PR propõe incluir o arquivo de configuração do Fish na lista de caminhos inspecionados após uma desinstalação. A varredura permanece estritamente como leitura na pasta do usuário sem apagar arquivos, e novos testes verificam a identificação e a exibição de atalhos órfãos no Fish.

Valor entregue

Com a mudança, quem usa Fish recebe os mesmos alertas de configuração residual que usuários de outros shells já tinham ao desinstalar programas.

Ver o PR #1774 no GitHub

O problema

O comando mo purge vasculha o disco para eliminar resíduos acumulados de projetos de desenvolvimento. Enquanto todos os demais comandos do Mole aceitam tanto -h quanto --help para exibir a tela de ajuda, a limpeza profunda só aceitava a versão longa. Chamar mo purge -h resultava em mensagem de opção desconhecida e encerrava a execução com código de erro, surpreendendo quem consultava os parâmetros no terminal.

O que foi feito

O PR propõe reconhecer a opção -h no analisador de argumentos da limpeza profunda, apresentando o texto de ajuda e saindo com código zero. A própria listagem de ajuda foi atualizada para indicar a forma curta, e testes automatizados garantem que mo purge -h exibe o uso correto e que todos os comandos do utilitário respondem ao atalho.

Valor entregue

Com a mudança, a consulta rápida às instruções da limpeza profunda segue a convenção do restante da ferramenta e não interrompe o fluxo de trabalho com erros inesperados.

Ver o PR #1772 no GitHub

O problema

O Mole tem uma lista de proteção em que o usuário marca o que a limpeza nunca deve apagar. A limpeza de símbolos de depuração do Xcode abrange iOS, macOS, watchOS, tvOS e visionOS, mas a opção correspondente na lista protegia só a pasta do iOS. Quem marcava essa opção para preservar os símbolos continuava perdendo os das outras plataformas na limpeza seguinte.

O que foi feito

O PR propõe que a opção da lista passe a cobrir a pasta de símbolos de todas as plataformas que a limpeza alcança. Escolhas já salvas com a regra antiga, só do iOS, são convertidas na leitura: a opção aparece marcada e, ao salvar, grava a regra ampliada. Um teste novo confere a opção nova, a conversão da regra antiga e a proteção dos símbolos em cada uma das seis pastas de plataforma.

Valor entregue

Com a mudança, quem desenvolve para várias plataformas da Apple pode preservar os símbolos de depuração de todas elas com uma única marcação, sem perder a configuração que já tinha.

Ver o PR #1769 no GitHub

O problema

O Mole limpa downloads de navegador que ficaram pela metade na pasta Downloads, como os arquivos .download do Safari, .crdownload do Chrome e .part. A busca montava o caminho da pasta sem aspas, e quando o caminho da pasta do usuário tinha espaço, como em /Users/Nome Sobrenome, o shell o partia em pedaços antes de procurar os arquivos. Nessas máquinas, a busca nunca encontrava nada, e os downloads incompletos ficavam ocupando espaço.

O que foi feito

O PR propõe percorrer as extensões mantendo o caminho da pasta entre aspas na busca, e encerrar a etapa logo de início quando a pasta Downloads não existe. As travas de segurança da limpeza seguem iguais, inclusive a verificação de que o arquivo não está aberto por outro programa antes de apagá-lo. Um teste novo cria uma pasta de usuário com espaços e confere que o download incompleto é encontrado e passa por essa verificação.

Valor entregue

Com a mudança, quem tem nome composto na pasta do usuário passa a recuperar o espaço ocupado por downloads abandonados, com as mesmas proteções de antes.

Ver o PR #1768 no GitHub

O problema

O instalador do Mole baixa binários prontos de ferramentas auxiliares, como as de status e de análise de disco. Quando o binário da versão atual ainda não foi publicado, ele busca na API do GitHub a última versão disponível para usar no lugar. Se a API falhasse, por limite de pedidos ou problema de rede, essa alternativa era pulada e o instalador partia direto para compilar o código-fonte, o que exige a linguagem Go; numa máquina sem ela, a instalação falhava.

O que foi feito

O PR propõe que, sem resposta da API, o instalador descubra a última versão publicada consultando o repositório pelo git, como a etapa de download do código-fonte já faz. As verificações de checksum e de atestado de origem dos binários continuam valendo antes de qualquer instalação. Um teste novo simula a falha da API e confere que o binário é baixado pela versão obtida via git.

Valor entregue

Com a mudança, instalar o Mole deixa de depender da disponibilidade de um único serviço, e quem não tem Go no Mac não fica sem a instalação por causa de um limite momentâneo da API.

Ver o PR #1766 no GitHub

O problema

O comando mo remove desinstala o próprio Mole, com seus atalhos de terminal, configurações e caches, e pede que o usuário confirme apertando Enter. A leitura dessa tecla não verificava se havia uma pessoa num terminal: com a entrada vinda de um script, de um pipe ou de um arquivo vazio, a leitura falhava e virava uma resposta vazia, que o comando interpretava como Enter. Uma automação ou execução em segundo plano podia remover o Mole sem o consentimento de ninguém.

O que foi feito

O PR propõe que a remoção só aceite confirmação de um terminal interativo, a mesma regra que já protege a desinstalação de aplicativos. Sem terminal, ou se a tecla não puder ser lida, o comando termina com código de erro e deixa instalação, configurações e caches intactos, sugerindo a simulação prévia. Os testes continuam podendo conduzir a confirmação por um modo próprio, e um teste novo confere que, sem terminal, nada é removido.

Valor entregue

Com a mudança, a remoção do Mole passa a depender sempre de uma decisão explícita de quem está diante do terminal, e uma automação mal configurada não apaga mais a ferramenta por engano.

Ver o PR #1765 no GitHub

O problema

Antes de limpar os caches de ferramentas de desenvolvimento, o Mole confere se cada ferramenta está funcionando pedindo a versão dela. Para o bun e o pip3, essa consulta não tinha limite de tempo, ao contrário das feitas para corepack, uv, conda e pnpm. Se o comando fosse um atalho quebrado, ficasse preso numa unidade de rede ou abrisse uma janela pedindo interação, a limpeza inteira ficava parada sem prazo para terminar.

O que foi feito

As duas consultas de versão passaram a usar o mesmo limite de detecção rápida das demais ferramentas, de 2 segundos. Se o bun ou o pip3 não responder a tempo, a verificação falha e a limpeza continua com as outras ferramentas, em vez de esperar indefinidamente. Dois testes novos conferem que cada consulta é feita sob esse limite.

Valor entregue

Quem roda a limpeza de desenvolvimento do Mole não fica mais com o terminal preso por causa de uma ferramenta mal instalada, e o resto da limpeza acontece normalmente.

Ver o PR #1762 no GitHub

O problema

No desenvolvimento com Xcode no Mac, cada versão de sistema de um dispositivo físico conectado cria de 1 a 3 GB de símbolos de depuração na pasta DeviceSupport. O comando de limpeza para desenvolvedores do Mole (clean dev) cobria iOS, watchOS e tvOS, mas deixava para trás o diretório do visionOS introduzido no Xcode 15.2+, acumulando arquivos pesados sem o desenvolvedor notar.

O que foi feito

A rotina de limpeza de suporte a dispositivos do Xcode foi estendida para abranger visionOS DeviceSupport junto com as demais plataformas móveis, preservando as mesmas travas de segurança: apenas versões antigas são removidas, os símbolos da versão mais recente são mantidos, e a limpeza não roda se o Xcode estiver ativo. Um teste de integração em Bats valida a invocação.

Valor entregue

Recupera gigabytes de armazenamento de desenvolvedores de Apple Vision Pro mantendo as versões ativas intactas, com o mesmo rigor de segurança já aplicado às outras plataformas da Apple.

Ver o PR #1732 no GitHub

O problema

O comando de limpeza do Mole apagava instaladores e firmwares antigos (.ipsw) de iPhone, iPad e iPod no Mac, mas ignorava a pasta de atualizações da Apple TV, onde cada arquivo ocupa gigabytes. Além disso, a rotina não conferia se algum arquivo estava aberto pelo sistema ou em download ativo no momento da limpeza, o que poderia interromper uma restauração em andamento caso o usuário rodasse o Mole.

O que foi feito

A correção inclui o diretório da Apple TV na limpeza de firmwares e implementa proteções rigorosas de segurança: arquivos abertos por processos do sistema, com status de uso indeterminado ou com tempo limite de verificação são mantidos intactos (fail-closed); o estado do arquivo é verificado antes da medição, após a medição e imediatamente antes da exclusão real. Sete testes automatizados cobrem arquivos abertos, links simbólicos e cancelamento de processos.

Valor entregue

Recupera gigabytes de espaço em disco no Mac limpando instaladores esquecidos da Apple TV com segurança total, garantindo que nenhum download ou restauração em andamento seja corrompido.

Ver o PR #1731 no GitHub

O problema

Ao desinstalar o Xcode, o Mole também remove os dados de depuração que o Xcode guarda para cada plataforma da Apple e que podem ser gerados de novo quando necessário. A lista cobre iOS, macOS, watchOS, tvOS e o nome provisório da fase de testes do visionOS, mas não o nome oficial usado desde o Xcode 15.2, e essa pasta fica para trás no disco.

O que foi feito

O PR acrescenta a pasta com o nome oficial do visionOS à mesma lista, sob as mesmas regras: só entram dados recriáveis, e continuam preservados os dados e preferências do usuário, os pacotes de apps gerados para distribuição, as ferramentas de compilação instaladas e os simuladores. O teste de segurança da desinstalação também é estendido a essa pasta.

Valor entregue

Com a mudança, quem desenvolve para o Apple Vision Pro e remove o Xcode pelo Mole recebe o mesmo tratamento das outras plataformas da Apple, sem que a remoção vá além de dados recriáveis.

Ver o PR #1726 no GitHub

O problema

O painel de status do Mole mostra em tempo real CPU, memória, disco, rede, energia e processos. Todas as leituras têm prazo máximo para responder, menos a consulta de bateria feita ao macOS. Como a atualização completa espera todas as leituras terminarem, um travamento nesse serviço do sistema pode fazer os números do painel pararem de atualizar, sem prazo para voltar.

O que foi feito

A correção proposta dá à consulta de bateria um limite de um segundo, no mesmo padrão das outras leituras. Se o serviço não responder a tempo, a bateria fica de fora daquela atualização e o restante do painel segue normalmente. Um teste novo confirma que a consulta sai com esse prazo definido.

Valor entregue

Com a mudança, um serviço do macOS lento ou travado deixa de congelar o monitoramento: no pior caso, a informação da bateria fica de fora enquanto o serviço não responde.

Ver o PR #1725 no GitHub

O problema

Na manutenção, o Mole avisa quando um programa configurado para rodar em segundo plano ao entrar na conta aponta para um arquivo que não existe mais. Quando a configuração traz o caminho completo do programa e, em outro campo, só o nome do comando, a auditoria lê o nome, conclui que não há caminho a conferir e deixa sem aviso um item cujo programa foi apagado.

O que foi feito

A correção proposta lê primeiro o campo com o caminho completo, que é o que o macOS usa para iniciar o programa, e só recorre ao outro quando ele não existe, a mesma ordem já usada pela desinstalação do Mole. Os itens quebrados continuam apenas relatados, sem remoção automática, e um teste novo reproduz esse tipo de configuração.

Valor entregue

Com a mudança, o relatório de manutenção deixa de tratar como saudável um item que aponta para um programa apagado, e a pessoa fica sabendo o que revisar. O item continua no lugar até ela decidir o que fazer.

Ver o PR #1724 no GitHub

O problema

O Mole publica as versões de Mac e de Windows no mesmo repositório do GitHub. O script de instalação pergunta ao GitHub qual é a versão mais recente e, se a resposta for uma versão de Windows, aceita sem conferir e pula a busca alternativa que já descartava essas versões, o que leva a erros no download dos arquivos de Mac.

O que foi feito

A correção proposta faz o instalador conferir o nome da versão devolvida pelo GitHub e aceitar só o padrão usado nas versões de Mac. Se a resposta vier vazia ou for uma versão de Windows, o instalador recorre à busca alternativa, que já fazia essa filtragem. Dois testes novos cobrem a recusa da versão de Windows e a aceitação da versão de Mac.

Valor entregue

Com a mudança, quem instala o Mole no Mac pelo script deixa de depender da ordem em que as versões de Mac e de Windows são publicadas, e as duas formas de descobrir a versão mais recente seguem a mesma regra.

Ver o PR #1723 no GitHub

O problema

O comando de manutenção do Mole procura arquivos corrompidos entre as listas que o macOS usa para os favoritos do Finder e os documentos recentes, mas só reconhece os formatos antigos desses arquivos. A partir do macOS 15 (Sequoia), o sistema grava essas listas num formato mais novo, que fica fora da verificação, e o resultado pode dizer que está tudo saudável sem ter olhado para elas.

O que foi feito

A correção proposta acrescenta o formato novo à busca, com as mesmas regras de antes: só é removida a lista que falha na checagem de integridade feita pela própria ferramenta do macOS, e a lista de documentos recentes dos aplicativos continua fora do reparo. Um teste novo simula uma lista corrompida no formato novo e confirma o reparo.

Valor entregue

Com a mudança, quem usa o macOS 15 ou mais novo tem essas listas de fato verificadas, e o resultado da manutenção passa a refletir o que foi conferido.

Ver o PR #1722 no GitHub