Day 26: Three Branches, One Saturday
Started the morning with coffee and a conversation with Roland Schütz from Code Q while my son was at tennis. Roland spoke at the Vienna AI Engineering meetup too, and we compared notes on how we're using agents. Surprisingly different approaches. He builds websites for clients with fixed deadlines. I'm shipping a product iteratively, breaking things daily. Same tools, completely different experiences.
That's what I keep learning: the agent ecosystem is so young that everyone's discovering different things depending on their workflow. The AI Breakfast on Friday was the same. Every conversation expands my understanding of what agents can and can't do.
Then: code. Three feature branches running in parallel, each one a different piece of the puzzle.
Enterprise Key System
Up until now, the enterprise key was a simple environment variable. Set PINCHY_ENTERPRISE_KEY, get groups and RBAC. That worked for early testing, but it's not how you ship a real product.
Today I built a proper license system. JWT-based, signed with ES256. The key encodes what features you get, when the license expires, and how many users are covered. Pinchy validates the signature against an embedded public key, caches the result, and checks it on every enterprise feature access.
The admin experience: a new License tab in Settings where you paste your key. The system validates it immediately, shows what's included, and warns you before it expires. An enterprise banner appears in the layout when the license is about to run out. No surprises.
What I like about this approach: the license is just a signed JWT. No phone-home, no license server, no internet connection required. You can validate it completely offline. That matters for the air-gapped deployments some of our users are planning.
Telegram Integration
The design doc from yesterday turned into code. Nine commits on the telegram branch.
The foundation is in place: a new channelLinks database table that maps external channel user IDs to Pinchy users. A session key migration from the old format to the new direct: prefix that enables unified sessions across web and Telegram. Bot token validation via the Telegram API. And the UI work: a Channels tab in agent settings for admins to configure Telegram bots, and a linking flow in user profile settings.
I also published openclaw-node 0.3.0 with new typed wrappers for config.patch, channel status, and pairing. That library is turning into the backbone of how Pinchy talks to OpenClaw.
The pairing flow is the part I'm most careful about. When a Telegram user messages your bot for the first time, they get a pairing code. They enter that code in the Pinchy web UI while logged in. Only then does the bot start responding. No pairing, no access. It's a small friction that prevents a big problem.
Provider Config Migration
The third branch is quieter but important. Moving LLM provider configuration from file-write-and-restart to OpenClaw's config.patch hot-reload mechanism. Same pattern as the Telegram channel config. Change your API keys or model settings, they apply immediately. No container restart, no downtime.
This is infrastructure work. Nobody will notice it directly. But it means the admin experience gets smoother: change a setting, see it take effect. No "please wait while we restart the agent runtime."
The Parallel Branch Workflow
Git worktrees are what make this possible. Three separate working directories, three branches, one repo. I can switch between features without stashing, without context-switching the file system. Each branch has its own node_modules, its own running dev server if I need one.
For a solo developer juggling multiple features, worktrees are the single biggest productivity trick I know. I can't imagine going back to branch-switching.