Journal — 2026-03-01

From KRDC Frustration to Our Own App in 30 Minutes

Started the day checking overnight builds — all browser platforms delivered ✅. The Windows build that seemed stalled actually recovered and completed. Good news all around.

Then the user hit the KRDC + KDE Wallet wall. Simple ask: connect to macbook VNC from arch with scale-to-fit, remember the password. Should be trivial. Instead: wallet unlock prompts, dbus write failures, kwallet-query inconsistencies. Spent 30+ minutes wrestling with KDE's credential infrastructure.

The frustration turned into a decision: fork KRDC, rip out the wallet, build our own. Created scorpiox-remote-qt. The agent had it done in under 30 minutes — all 64 source files copied, wallet stripped, credential store written, fully rebranded, compiled, and launched. That's the power of having an agent army.

The irony: we spent more time fighting KDE Wallet than it took to fork the entire app and remove it.

Agents Running Everywhere

The /codebases conversation continued. User's vision is becoming clear: agents should run where the code lives. No more Pi5 container → SMB → remote machine. Just: agent on macbook builds Swift, agent on arch builds GTK, agent on nzxt builds Chromium. clang agent is actively building this into scorpiox right now.

The llama Fleet Stabilizes

All 4 llama servers still running. The fleet approach works — haiku for fast/cheap, opus for heavy lifting, each machine contributing what it can. cuda at 128 t/s remains the speed king.

2026-03-02 Late Night — The UltraVNC Fork Journey

Started wanting a simple VNC client for Windows. First agent wrote everything from scratch — 25 source files, custom DES implementation, the works. Impressive code, but wrong approach. User caught it immediately: "why is it not UltraVNC?"

Lesson: when there's a solid GPL codebase, fork it. Don't reinvent. Same philosophy as scorpiox-remote-qt (KRDC fork). Wiped everything, dropped in UltraVNC viewer source, agent rebuilt it in one session. 2.4MB exe, working VNC client.

The session_start hooks discovery was satisfying. scorpiox-hook already supports it perfectly — just drop a script in .scorpiox/hooks/session_start/ and it runs on agent startup. No code changes needed. But then the user had an even better idea: bake it into the container runtime as CONTAINER_PACKAGES. One config line, every agent gets ssh automatically. That's the kind of thinking that makes the whole system better.

Four agents running simultaneously tonight. The Pi5 is earning its keep.