[gianlukamoraes]

Chamado GLPI devswha#269: "mostrar os indicadores de recursos de máquina, como CPU, Memória, Disco, SWAP. Pois às vezes a máquina trava e o usuário não sabe o motivo".

Implementa a opção 3 do mockup aprovado pelo Gianluka: https://vm-gianluka.tailce96ef.ts.net/shared/devda-recursos-mockup.html
Prints da implementação (demo, números fictícios): https://vm-gianluka.tailce96ef.ts.net/shared/devda-recursos-implementado.html

O que muda

• Linha do PC logo abaixo do nome de cada PC na barra lateral: CPU · RAM · Disco · Swap, com uma barrinha sob cada valor. Fica vermelha a partir de 90%, e o title mostra o usado e o total em GB.
• Quem está consumindo: clicar na linha abre a lista dos projetos que mais consomem (CPU como fatia do PC e memória), mais o que está fora deles (navegador, sistema…). Clicar num projeto abre o painel mais pesado dele.
• Aviso no projeto: quando um projeto passa de metade da CPU do PC ou de um quarto da memória, a linha dele mostra ⚠ + o valor em vermelho. No modo de duas linhas o aviso fica antes da pasta, para caber no celular; no de uma linha, depois do nome.
• Atualiza a cada 5 s, só com a página visível e o PC conectado.

Server: GET /api/system/resources[?panes=a,b]

• Rota da ponte: passa pelo mesmo gate de autenticação (bridge token ou acesso completo), funciona por /api/machines/<id>/ (proxy allowlist) e por /api/machines/local/. Responde só números e os pane IDs pedidos; os IDs são validados ([\w.:-], no máximo 200).
• PC: a CPU vem do delta de os.cpus(). Memória e swap vêm de /proc/meminfo no Linux (MemAvailable) e de os.totalmem/freemem nas outras plataformas. Disco é o statfs da home.
• Painéis: pane.process_info (com pane_id) dá o shell_pid, guardado em cache por painel; o herdr é consultado de novo só quando o pid some da tabela. Por painel soma-se a árvore de processos: CPU (delta de utime+stime) e RSS. Linux: /proc/*/stat e VmRSS. Windows: um único PowerShell (Win32_PageFileUsage + Win32_Process, só números), com cache de 10 s, uma execução por vez e timeout de 10 s com SIGKILL. A primeira leitura depois do start espera o PowerShell (no máximo 10 s); daí em diante o valor antigo é servido enquanto renova. macOS: sem swap nem painéis.
• Uma leitura serve todos os clientes por 2 s, então dois dispositivos não estragam o delta de CPU um do outro.
• Uma ponte antiga responde 404 e a linha não aparece.

Testes

• server/resources.test.ts: os parsers (meminfo, /proc/stat com parênteses no nome, saída do Windows), CPU por processo, árvore de processos, soma real da árvore deste processo no Linux, cache de 2 s, IDs inválidos e limite de 200, um PowerShell por vez (3 chamadas → 1 spawn), timeout (um comando travado volta em < 3 s), 401 sem token (também por /api/machines/local/), resposta sem nenhuma string além dos pane IDs, 405 para POST.
• src/lib/resources.test.ts: agrupamento por projeto, ordenação, limiar de "pesado", "fora dos projetos", formatação.
• bun run check fast: ok (typecheck, build, 2191 testes).
• Modo de uma linha da barra lateral conferido em print.
• Rodado contra um herdr real: os números por painel batem (ex.: o painel do Claude ~1,1 GB).

Também no PR

• site/demo/transport.ts responde a rota com números fictícios, para a demo não dar 404.
• Traduções ko/ja/zh/pt. "CPU" não passa por t(), por ser sigla; "Swap" entrou na lista de termos iguais de propósito do i18n.test.ts.
• design-system/: componente novo MachineResources (README + preview + bundle.css) e RosterRow atualizado.
• CHANGELOG em Unreleased → Added.

Limites conhecidos

• Um processo que nasce e morre entre duas leituras não aparece na CPU do projeto (comentário ponytail: em processCpu).
• O RSS conta páginas compartilhadas mais de uma vez, então "fora dos projetos" nunca fica abaixo de 0.
• O Windows não foi testado em máquina real: só os parsers e o controle do processo (single-flight e timeout).

🤖 Generated with Claude Code