Anrry Petrin

necessidade
Ferramentas de IA pra código assumem um repo, um agente, um terminal. Meu dia é o oposto: muitos repos, vários agentes em paralelo. O OpenCherry é o dashboard que faltava: um app desktop que observa cada repo e mostra qual agente está mexendo em quê.

decisões
Um shell Tauri 2 com UI SolidJS sobre um core Rust, depois de um pivô no mesmo dia abandonando uma GUI nativa em Rust: velocidade venceu. O core se divide em quatro crates enxutos: tipos compartilhados, operações git, detecção de agentes, persistência SQLite. O git é híbrido: operações locais rodam no libgit2 embutido, push e pull remotos chamam o git real do usuário, então as credenciais que já existem simplesmente funcionam. Agentes nunca são disparados, só detectados: uma tabela de regras varre a lista de processos e correlaciona cada agente rodando ao repo que ele está tocando. Tudo local, offline-first.

trade-offs
AGPL desde o primeiro commit: reciprocidade acima de adoção corporativa fácil. O contrato TypeScript-Rust na ponte IPC é mantido na mão, uma edição em dois arquivos a cada mudança de comando. A distribuição é um instalador sem sandbox e sem auto-update, porque o trabalho do app é justamente observar outros processos e caminhos arbitrários; sandbox de loja castraria ele.

resultado
Um alpha que já faz o trabalho: Git multi-repo com diffs, staging e sync, correlação de agentes ao vivo pra cinco CLIs, oito temas embutidos mais import de temas, e um binário que é GUI e CLI ao mesmo tempo. Ubuntu e GNOME primeiro. Código aberto em github.com/4nrry/opencherry.

necessidade
Dois anos de trabalho, 97% em repos privados. Mostrar publicamente, manter atualizado com zero manutenção, e fazer de "nada privado vaza" uma propriedade verificável, não uma promessa.

decisões
Um único Cloudflare Worker é dono de tudo: assets estáticos, uma API pequena e um cron que re-sincroniza o GitHub a cada seis horas. O sync materializa um único documento JSON seguro pra publicar. As queries por repositório são geradas a partir de uma allowlist, então nomes de repos privados nunca são sequer pedidos; um sanitizador varre o documento final e a publicação falha fechada em qualquer violação, deixando o último dataset bom servindo.

trade-offs
Atualização a cada seis horas em vez de tempo real. KV em vez de banco, porque o artefato é um documento, não uma carga de queries. Uma blocklist seria mais simples, mas este repo é público e uma blocklist de nomes privados seria ela mesma o vazamento.

resultado
Todo número desta página vem de /api/portfolio.json, e a suíte do sanitizador mais o checador de vazamentos estão no aberto.