anrry@4nrry.dev:~$ replay --since "2 years ago"

← hire me · pt-BR

Anrry Petrin

Software engineer. I build IoT platforms, fintech and dev tools, and I ship every day.

···
contributions
···
merged pull requests
···
longest streak, days

connecting to the worker

Each cell is one day of the last two years, synced live from the GitHub API. Most of this work lives in private repositories; the totals count it anyway.

data table: contributions by month
monthcontributions

velocity

The jump

Year one I was finding a rhythm. Year two I rebuilt the way I work around AI agents and shipped ··· the contributions.

orgs

Three orgs, one engineer

I run all three. Names and numbers sync straight from GitHub every six hours.

systems

Systems, not just commits

Volume is easy to chart. This is the part that matters: what the client needed, how I modeled it, and what I traded away to get there.

OpenCherry: a control tower for multi-repo AI coding

Tauri 2 · alpha · AGPL-3.0 · opencherry.dev

need
AI coding tools assume one repo, one agent, one terminal. My day is the opposite: many repos, several agents working in parallel. OpenCherry is the missing dashboard: a desktop app that watches every repo and shows which agent is touching what.

decisions
A Tauri 2 shell with a SolidJS UI over a Rust core, after a same-day pivot away from a native-Rust GUI: velocity won. The core splits into four thin crates: shared types, git operations, agent detection, SQLite persistence. Git is hybrid: local operations run on embedded libgit2, remote push and pull shell out to the user’s real git so existing credentials just work. Agents are never spawned, only detected: a data-driven rule table scans the process list and correlates each running agent to the repo it is touching. Everything is local and offline-first.

trade-offs
AGPL from the first commit: reciprocity over easy corporate adoption. The TypeScript-Rust contract across the IPC bridge is maintained by hand, a two-file edit on every command change. Distribution is an unsandboxed installer with no auto-update, because the app’s whole job is watching other processes and arbitrary paths; a store sandbox would neuter it.

outcome
An alpha that already does the job: multi-repo Git with diffs, staging and sync, live agent correlation for five agent CLIs, eight built-in themes plus theme import, and one binary that is both GUI and CLI. Ubuntu and GNOME first. Code in the open at github.com/4nrry/opencherry.

SolidJS UI WebView Rust core shared types git (embedded libgit2) agent detect (sysinfo) SQLite persistence git CLI remote ops only process table read, never spawn opencherry.db local state Tauri IPC
one IPC bridge, four thin crates, nothing spawned

This site: publishing private work without leaking it

auditable: source on GitHub

need
Two years of work, 97% of it in private repos. Show it publicly, keep it current with zero upkeep, and make "nothing private leaks" a property you can verify, not a promise.

decisions
One Cloudflare Worker owns everything: static assets, a tiny API, and a cron that re-syncs GitHub every six hours. The sync materializes a single public-safe JSON document. Per-repo queries are generated from an allowlist, so private repo names are never even requested; a sanitizer then walks the final document and the publish fails closed on any violation, leaving the last good dataset serving.

trade-offs
Six-hour freshness instead of realtime. KV instead of a database, because the artifact is one document, not a query workload. A blocklist would have been simpler, but this repo is public and a blocklist of private names would itself be the leak.

outcome
Every number on this page comes from /api/portfolio.json, and the sanitizer suite plus leak checker ship in the open.

GitHub API sync (cron, every 6h) allowlist aggregate sanitize gate KV one JSON doc /api/*.json ETag + SWR this page violation = no publish, the last good dataset keeps serving
fail-closed by design: the gate sits before the only write

More case studies landing here soon.

repos

Where the PRs landed

Top repositories by pull requests I authored in the window, colored by org.

data table: repositories
repositoryorgPRs

rhythm

The weekly rhythm

Contributions by weekday, month by month. GitHub's calendar is daily, so this is as granular as honesty allows.

languages

Materials

Bytes across the org codebases and my own public repos. Upstream projects I contribute to are excluded: not my code to count.

open-source

In the open

The public slice: my own projects and the upstream ones I contribute to.

trajectory

How I got here

  1. 01

    Smart Compost, solo

    I joined a small composting startup as the only engineer. Firmware, backend, frontend: whatever the day needed.

  2. 02

    The platform

    One repo became twenty-eight: C++ sensors, NestJS microservices, three frontends, a React Native app, Helm-managed infra.

  3. 03

    Mentoring

    Bruno joined as an intern; today we work as peers. Best multiplier I ever shipped.

  4. 04

    LOTVS Finance

    Started a fintech with a college friend. My single most PR-heavy repository lives there.

  5. 05

    Ocean Words

    Building an English-teaching platform with my girlfriend, who teaches the classes.

  6. 06

    In the open

    OpenCherry, an MCP server on npm, upstream PRs to tools I use daily. This site is one of them: a Worker that replays my own GitHub.