PC Monitor: construindo um app desktop do zero com Claude

O que é o PC Monitor

É um app desktop para Windows que mostra uso de CPU, RAM e disco em tempo real — cards e gauges coloridos por severidade, mini-histórico em gráfico, ícone na bandeja do sistema, tema claro/escuro. Construído com Electron e JavaScript puro: sem TypeScript, sem framework de front-end, sem bundler. O código está público no GitHub.

Tem dois vídeos no canal sobre ele: um mostra a criação do zero, do prompt inicial até uma v1 funcional; o outro mostra o começo da evolução do projeto, com foco em como criar instruções pra IA seguir durante o desenvolvimento. Os links estão no final do post.

Por que sem framework

Pra um utilitário pequeno, rodando isolado num processo Electron, framework e bundler seriam complexidade sem retorno. HTML/CSS/JS direto, com CSS Grid/Flexbox e Custom Properties pros temas, resolve bem e sem dependência extra. Não é regra geral — é a ferramenta certa pra esse tamanho de problema, não a mais familiar ou a mais na moda.

Como o Claude entrou em cada fase

No primeiro vídeo, o Claude ajudou a sair do zero até uma v1 funcional — estrutura do projeto, coleta de métricas (CPU/RAM/disco via a lib systeminformation), a UI básica.

No segundo, o foco muda: em vez de só pedir código, comecei a escrever um CLAUDE.md no próprio repositório — um arquivo de instruções que a IA lê antes de mexer em qualquer coisa. Tem convenção de nomenclatura:

Nomenclatura de variáveis, constantes, objetos, classes e métodos deve
sempre usar nomes auto-explicativos. Não use nomes genéricos e difíceis
de entender como x, a, b, z, n1, n2, etc. Essa regra vale também para
abreviações técnicas comuns, mesmo em código de baixo nível (Canvas,
matemática, loops): prefira canvasContext a ctx, devicePixelRatio a dpr,
valueIndex a i/idx.

(reparei escrevendo esse post que é quase a mesma regra que uso aqui no vagnerdev.com — não foi combinado, é só o jeito que eu penso sobre código legível de verdade.)

Tem também a arquitetura documentada (processo main vs. renderer, o que cada módulo faz, o que não pode fazer — o preload.js roda em sandbox e não pode usar require(), por exemplo) e as restrições que valem a pena lembrar antes de sugerir uma mudança.

Um problema real: o instalador sem ícone

Nem tudo é vídeo bonito de "funcionou de primeira". Ao empacotar o instalador Windows, o electron-builder precisa baixar um pacote de assinatura de código que tem symlinks de macOS — e o Windows só extrai isso com Developer Mode ativado ou terminal como administrador, nenhum dos dois disponível no ambiente que eu tinha na hora.

Solução pragmática: desabilitar a assinatura e a gravação de ícone/metadados no por enquanto, documentar o porquê e como reverter quando eu tiver o ambiente certo, e seguir. Isso virou uma entrada no do projeto — não escondido, documentado, com efeito colateral conhecido (o fica com o ícone padrão do Electron) e um caminho claro pra resolver depois.