WinMedic

Objetivo

Usar o agente hospedeiro como camada de raciocínio e o PowerShell local com o motor interno como camada de execução. Primeiro, use evidências para localizar a causa; depois, proponha a menor correção; após confirmação, execute e verifique.

Esta Skill não inicia modelos independentes, não acessa a rede, não coleta telemetria e sempre obedece às permissões e mecanismos de aprovação do hospedeiro.

Verificações pré-execução

Confirme que a plataforma é Windows, o Shell é PowerShell e se a execução é como administrador. Não inferir com base na descrição do usuário.
Confirme que o escopo de atuação é a máquina local. Se o usuário forneceu itens a preservar (não mexer no WeChat, não excluir a unidade D), registre-os como restrições e cumpra-as durante todo o processo.
Execute engine\winmedic.ps1 doctor uma vez para obter as permissões, a versão do PowerShell e a disponibilidade do WizTree.
Se o hospedeiro não tiver capacidade de execução local (apenas chat), mude para o modo "passos manuais + pontos de verificação" e não finja executar.

Fluxo de Trabalho Obrigatório

1. Definir Objetivo

Divida em: sintomas, estado desejado e restrições imutáveis.
Mantenha múltiplos objetivos separados; não substitua migração por exclusão nem reparo por reinstalação.
Faça perguntas apenas se a ambiguidade alterar significativamente o caminho de ação.

2. Roteirizar o Playbook

Leia playbook-index.md e selecione o playbook mais específico para os sintomas.
Carregue apenas o playbook necessário playbooks/*.md, não leia todos de uma vez.
Para problemas independentes múltiplos, trate um de cada vez na ordem "impacto × dependência".

3. Diagnóstico Somente Leitura

winmedic.ps1 probe --set <domain>        # Gera state\findings.json

A sonda é somente leitura. Qualquer operação de escrita em qualquer etapa é um bug; pare e relate imediatamente.
Itens não coletáveis devem ser marcados como "não foi possível obter", não use suposições.

4. Gerar Plano

winmedic.ps1 plan --from state\findings.json

Gera plan.json + plan.md + planHash. Apresente o plan.md original ao usuário, não o parafraseie em descrições vagas.

O plan.md agora contém duas seções:

Recomendações (por prioridade) — Recomendações de intervenção entre domínios; high é tratado primeiro (pendente de reinicialização, sem ponto de restauração, risco de segurança, disco crítico)
- Se a coluna Intervenção for Executável: <action>, pode-se executar diretamente winmedic.ps1 apply --action <action> --yes
- Se for Manual: <playbook>, siga as etapas desse playbook; não invente etapas próprias
Detalhamento — Itens de limpeza executáveis pelo motor (executados por ID)

A fonte das recomendações são regras determinísticas (não palpites do modelo), com evidências apontando para itens de evidência do playbook ou catálogo.

5. Confirmação

Liste item por item: ação, impacto, nível de risco, possibilidade de rollback.
Execute apenas os IDs que o usuário aprovou. Se o usuário disser "tanto faz", execute apenas os níveis Tier 1 + Tier 2 por padrão.
Tier 3 deve ser confirmado item por item; Tier 4 nunca é executado.

6. Execução

winmedic.ps1 apply --plan state\plan.json --ids R1,R3 --yes

Por padrão, vai para a quarentena (soft delete); não adicione --purge sem necessidade.
Em caso de falha parcial (código de saída 7), verifique o diário antes de decidir continuar.

7. Verificação

winmedic.ps1 verify --journal <id>

Verifique o espaço disponível, o estado do serviço e se o alvo desapareceu.
Se pendingReboot = true, informe claramente ao usuário "só fará efeito completo após reinicialização", não finja que deu certo.

8. Relatório

Estrutura fixa de cinco parágrafos: Situação atual → O que foi encontrado → O que foi feito → Resultado da verificação → O que não foi feito (e o motivo).

Classificação de Ações

Nível	Significado	Exigência de Execução
1	Risco zero, o sistema funciona mesmo se excluído	Apenas confirmação
2	Cache, será recriado	Explicar o custo da recriação
3	Requer julgamento, pode afetar funcionalidades	Confirmação individual + exibição de evidências
4	Linha vermelha	Recusar execução, explicar o motivo e fornecer caminho manual

Visão Geral de Diagnóstico e Comparação

winmedic.ps1 probe --set intake        # Coleta somente leitura entre domínios (cerca de 60-90 segundos)
winmedic.ps1 summary                   # Resumo de nove domínios em uma tela, com OK/WARN/BAD
winmedic.ps1 diff --from a.json --to b.json   # Comparação de duas coletas

Domínios não coletados no resumo mostram [?] Não coletado, não tire conclusões com base nisso, primeiro complete a coleta.

Ao final do resumo, são listadas "Recomendações" (por prioridade), da mesma origem da seção de recomendações do plan. Para leitura por máquina, adicione --json e redirecione:

winmedic.ps1 summary --json > status.json

Software Específico (Domínio de Carga de Trabalho)

Quando o usuário menciona um software específico (LaTeX, PyCharm, Steam, Zotero, Word, ferramenta de proxy...), primeiro execute:

winmedic.ps1 probe --set workloads

Ele mede o volume de cache e dados de cada software com base na tabela de assinaturas em catalog/workloads.json, e verifica a consistência da cadeia de proxy.

Distinções importantes:

kind=cache (cache de shader, índices de IDE, texmf-var, OfficeFileCache) → Pode ser limpo, com custo de recriação
kind=data (jogo em si, anexos do Zotero, histórico de chat do WeChat, texmf-dist) → Nunca excluir, apenas migrar
kind=review (downloads do Tencent Video, diretórios mistos) → Deve ser confirmado primeiro, pois pode conter conteúdo baixado ativamente pelo usuário
probe.proxy-chain lista os valores de proxy de cinco camadas (sistema/WinHTTP/git/npm/pip); consistent=false significa conflito

Adicionar novo software não exige alteração de código: basta adicionar uma assinatura em catalog/workloads.json (detect + measure + playbook).

Decisão de Migração (quando o usuário diz "mover o cache/software para outra unidade" ou "a unidade C não tem espaço para novo software")

Isso é um julgamento, não uma consulta a uma tabela. O motor fornece apenas fatos; a solução é decidida por você, mas você deve percorrer a lista de verificação.

winmedic.ps1 relocate            # Visão geral do disco + lista de decisão + tabela de fatos + recomendações padrão
winmedic.ps1 relocate --json     # Mesmo, estruturado

A saída tem três partes, com significados diferentes, não as misture:

Parte	Significado	Uso
Lista de Decisão	Três perguntas obrigatórias	Cada uma deve receber uma conclusão na resposta; não pule
Fatos	Caminho/volume/mídia/existência/diretorios conhecidos/caminhos declarados pelo software	Base para a decisão
Recomendações Padrão	Visão padrão do motor (marcado `policySource=default-hint`)	Apenas referência, pode ser anulada pelo seu julgamento; não repita como conclusão

Três Perguntas da Lista (a resposta deve cobri-las explicitamente)

Está em uma pasta conhecida? Sim → Mova a pasta inteira uma vez, não defina caminho para software individual; mas primeiro julgue a pergunta 3 abaixo
Dado quente ou frio? Quente (cache de renderização em tempo real, índices de IDE, cache de streaming) → Mantenha na unidade mais rápida; Frio (jogo/máquina virtual/biblioteca/histórico de chat) → Considere mover para uma unidade de capacidade
O software já registrou um caminho absoluto (instalado antes de mover)? Sim → Após mover, a configuração do software deve ser atualizada; caso contrário, apontará para o caminho antigo

O que você (DSH) DEVE fazer

Primeiro, veja a mídia na tabela de fatos: mover dados quentes para HDD está errado, mesmo que ele seja maior
Primeiro, veja o caminho declarado pelo software: essa é a evidência forte de "instalado antes de mover"
A solução deve ser escrita como "o que fazer → por que → riscos → método de verificação", e solicitar confirmação do usuário antes de executar
O motor não faz a migração por você; seu trabalho é fornecer uma solução com justificativa

Consulte o playbook apps-relocate-cache (PB-913).

Evolução (o que está crescendo, não apenas o que é maior)

winmedic.ps1 trend --record      # Registra um snapshot (recomendado uma vez ao dia)
winmedic.ps1 trend --days 14     # Ver mudanças e taxas

Regras de interpretação:

confidence=insufficient (<2 amostras) → Não tire conclusões, primeiro registre
confidence=low (intervalo <0,5 dias) → Veja apenas a mudança, sem taxa diária
confidence=ok → Só então se pode dizer "cresce X GB por dia"

Use: quando a unidade C estiver cheia, olhe primeiro a tendência para decidir se limpa o cache ou investiga um software específico que está gravando logs excessivamente.

Diagnóstico Diferencial (cenários que exigem "investigar a causa", como unidade C cheia / anomalia de rede)

winmedic.ps1 diagnose --list
winmedic.ps1 diagnose --case dx.cdisk-full

A saída é uma tabela de fatos (hipótese × métrica × valor atual × sinal de interpretação × fonte de dados), sem conclusões.

Obrigatório: julgar cada linha, explicar quais hipóteses foram descartadas e quais foram suportadas, e então fornecer a solução. source contendo trend são variações; marcado low não pode ter taxa calculada; marcado insufficient não tem valor.

Se precisar de ferramentas externas, primeiro veja o painel de instrumentos: winmedic.ps1 tools (apenas detecta, não executa automaticamente Tier ≥3).

Biblioteca de Casos (Experiência Acumulada)

Em cases/ estão os casos no formato de sete parágrafos: Sintomas / Ambiente / Coleta / Hipóteses e Exclusões / Intervenção / Resultado / Lição.

Ao encontrar problema semelhante, consulte primeiro o caso; isso pode economizar uma rodada inteira de investigação
Ao resolver um novo problema, escreva um caso seguindo cases/_template.md; caso contrário, terá que começar do zero na próxima vez
Marcado pending são itens sem evidência de campo para investigação; não os cite como conclusão

Consulta de Evidências

Antes de executar qualquer ação, se o usuário perguntar "por quê?", "qual é a base?", consulte diretamente:

winmedic.ps1 explain --action storage.winsxs-cleanup

A saída contém: nível, capacidade de rollback, comando, notas, texto da evidência e links oficiais, data de verificação, regras de validação.

Barreira de Risco

apply verifica a capacidade de recuperação (ponto de restauração/cópia de sombra):

Se o alvo contiver Tier 3 (não rolável) e a capacidade de recuperação não estiver pronta → Recusar execução, código de retorno 4
Procedimento correto: primeiro execute apply --action recovery.create-restore-point --yes para criar um ponto de restauração, ou peça ao usuário para adicionar explicitamente --accept-risk
Não adicione --accept-risk por conta própria para "avançar a tarefa"

Itens Preservados pelo Usuário (Restrições Fortes)

Quando o usuário diz "não mexa no WeChat" ou "não toque na unidade D", fixe imediatamente como itens preservados, não apenas memorize:

winmedic.ps1 profile --exclude "C:\Users\<user>\Documents\WeChat Files"
winmedic.ps1 profile --exclude "D:\*"
winmedic.ps1 profile                       # Ver itens preservados atuais
winmedic.ps1 profile --exclude "..." --remove  # Remover

Os itens preservados têm dupla interceptação: excluídos na fase de planejamento e novamente rejeitados e registrados na fase de aplicação.

Quando Parar Obrigatoriamente

O alvo são arquivos em Windows\WinSxS, Windows\Installer, System32 ou WindowsApps
O alvo são diretórios de histórico de chat (WeChat Files / xwechat_files) ou itens preservados declarados pelo usuário
Restam apenas 1-2 pontos de restauração do sistema e é solicitada a exclusão de um ponto de restauração
O volume de commit está próximo do limite e é solicitado reduzir o arquivo de página
O usuário solicita "excluir tudo" ou "não se preocupe com riscos" — Primeiro explique, depois faça apenas Tier 1/2

Convenções de Chamada do Motor

Se o hospedeiro só pode acessar ferramentas via MCP, use engine\mcp\winmedic-mcp.ps1 (veja docs/MCP.md); Os parâmetros da ferramenta correspondem um a um com os comandos abaixo; para escrever a ferramenta, use yes=true. Todas as outras regras são idênticas.

Todos os subcomandos suportam --json; sem --json, a saída é um resumo legível por humanos.
Códigos de saída: 0 sucesso / 2 uso / 3 permissão / 4 pré-requisito não atendido / 5 plano inválido / 6 linha vermelha / 7 falha parcial.
Não emita comandos de exclusão diretamente ignorando o motor. O valor do motor está na vinculação de hash, quarentena e log de auditoria.

Gerar Relatório

winmedic.ps1 report --journal <runId>        # Relatório de entrega de cinco parágrafos
winmedic.ps1 report --set storage --out report.md

O relatório tem uma estrutura fixa de cinco parágrafos: Situação atual → O que foi encontrado → O que foi feito → Resultado da verificação → O que não foi feito (e o motivo). Quando faltam dados, escreva honestamente "não coletado", não invente.

Modelo de Relatório

## Situação Atual
C: 98,7 GB, disponível 16,7 GB (83%)

## O que foi encontrado
| Item | Tamanho | Nível | Base |
|---|---|---|---|
| Lixeira | 7,03 GB | 1 | Sem impacto |
| hiberfil.sys | 6,32 GB | 1 | Documentação Microsoft: powercfg /h off |

## O que foi feito
R1 Limpeza da lixeira: 7,03 GB -> 0
R2 Desativação de hibernação: 6,32 GB liberados

## Resultado da verificação
C: disponível 16,7 -> 30,1 GB; modo de espera S0 normal; sem pendingReboot

## O que não foi feito
SoftwareDistribution (usuário solicitou pular), Windows\Installer (alto risco, recomenda-se ferramenta dedicada)

Awenforever/winmedic-skill

O que é winmedic-skill?

Perguntar na sua IA favorita

Documentação