I was looking at a bug report about calendar feed generation in Groups.io. ICS is one of those specs where interoperability with other calendar systems is a constant source of complexity - the spec is opaque and every client interprets it a little differently. I’d fixed a similar bug a month earlier, so I went back to the commit. The diff was there, but the Claude Code session that had helped me figure out the problem was gone. I was trying to reason through it with only half my brain.

This keeps happening. I’ve been using Claude Code for close to a year now working on Groups.io; it’s been incredibly helpful to me. But there’s a bunch of knowledge tied up in those sessions that isn’t getting preserved. I commit bug fixes, but all the knowledge around finding and fixing the bugs is lost. I commit new features, and the thought processes that went into developing them is gone. Revisiting a commit a month later means staring at a diff with no context for why those changes were made.

I’ve spent the last several months re-working my development environment. The result is Trellis, my open source development environment. It makes it easy to switch worktrees, view production logs, run distributed traces, and spin up Claude Code sessions. Crucially, it makes it easy for Claude to safely run investigations of bugs in production. As part of this work, I wanted to address this issue of not preserving Claude Code sessions with commits, which is where Cases come in.

A Case is a directory. It’s got a notes.md file with a human summary, a Claude transcript, a set of distributed trace results - everything involved in researching and fixing a bug or developing a new feature. It gets committed alongside the code changes.

cases/2026-02-24__fix-mybucket-get/
  case.json
  notes.md
  transcripts/claude__session-3f8c.json
  traces/web.app01-g2.130812...json

Most Claude sessions are throwaway, same as most terminal sessions. Cases are for the ones worth keeping. You don’t write a postmortem for every alert; you write one when it matters.

It’s not just bugs. When I’m building a new feature, the Claude session often has the design reasoning — why I went with approach A instead of B, what constraints I was working around, what I tried that didn’t work. That’s the kind of context that’s invisible in a diff but matters six months later when someone (probably me) needs to change it.

Because they’re in the repository, they’re available to all developers. They show up in PRs alongside the diff, so reviewers can see not just what changed but why. They show up in git log, so when you’re trying to understand a commit six months later, the investigation is right there. And they travel with the branch - no external wiki to keep in sync, no links to go stale.

Trellis can also read them and re-hydrate Claude Code sessions for continued work later. If that had existed when I hit the ICS issue again, I could have picked up where I left off instead of starting over.

One design choice worth mentioning: Claude in Trellis has read-only access to production systems. It can query logs, run distributed traces, and read crash reports, but it can’t restart services or modify anything. That’s deliberate. Investigation tools should be safe to run freely. And once you’re committing transcripts as permanent records, it matters that the AI wasn’t doing anything you’d need to audit for side effects. The transcript is the audit trail.

I built this into my development environment, Trellis. But the idea isn’t Trellis-specific.

If AI is part of how you build software, its work shouldn’t vanish when you close the tab.

If the investigation is worth doing, the record of it is worth keeping. And if it’s worth keeping, it should live where the rest of your work lives.

If you want to see this in action, here’s a short demo.

I’ve been running Groups.io for over a decade. It’s not a weekend project — it has millions of users and a lot of moving parts. I write the code, run the dev environment, deploy to production, and get woken up when something breaks. The neat “dev vs ops” distinction doesn’t really apply. It’s just me switching hats all day.

For years, I glued things together with shell scripts, tmux sessions, and manual steps. It worked, but it was fragile. I’d switch branches, start the services I needed, dig through logs, SSH into production, then jump back to local code. The context lived in my head, and if I lost track, I paid for it.

The tools weren’t the problem. Tmux is great. SSH is great. Grep is great. The problem was that they didn’t know about each other. Every time I switched contexts — a different branch, a different machine, a different problem.

I wanted one environment for the whole loop. Local services, remote logs, SSH sessions, worktrees — all navigable from the same place. Switch worktrees, and the running services, terminals, and logs switch with you. Tail production logs or grep rotated files on remote hosts without opening a new terminal and losing your place.

So I built it.

Trellis is a control plane for the dev-to-production workflow. It runs your local services, restarts them when binaries change, scopes terminals and logs to what you’re working on, and keeps everything in sync with the active branch. It gives you remote log access — tailing, grepping, even searching across multiple machines for a trace ID. It’s keyboard-first, runs on localhost, and doesn’t try to replace your cloud or orchestrator.

It’s intentionally simple and boring. It just makes the workflow feel like one thing instead of six disconnected tools.

I built Trellis for myself. After a while, I realized other people were solving the same problems with the same duct tape. So I open-sourced it.

trellis.dev

I saw the freeourfeeds.com announcement yesterday, which proposes raising $30M to build out the AT Protocol - the protocol that would allow Bluesky to be federated. The goal is to foster an ecosystem of federated and interconnected apps.

However, I don’t think this is necessary or the best focus for the community right now. In my view, Bluesky’s core value to users comes from:

• The existing community of users
• Bluesky’s Trust and Safety work
• The moderation tools available, and the community block/mute lists that people share
• Users’ personally curated block/mute lists built up over time

Notably, Bluesky’s growing popularity isn’t primarily driven by its federation possibilities.

Here’s what makes Bluesky truly exciting: app developers can leverage all these valuable features right now. There’s no need to wait for a foundation to be funded or for the AT protocol to be fully built out. Bluesky already exposes these crucial elements through their API. They’re also finalizing OAuth support (as detailed at docs.bsky.app/blog/oauth-atproto), which will make building apps on their API even more straightforward.

If I weren’t focused on Groups.io, I’d build a WhatsApp replacement on top of the Bluesky API. It wouldn’t be complicated. Similarly, creating an Instagram alternative would be quite feasible.

The key advantage? Use Bluesky as your identity provider. One of the most challenging aspects of running a user-centered service is handling trust, safety, and moderation - Bluesky gives you this infrastructure for free.

Admittedly, building on another service carries inherent risks. However, I believe the current climate makes these risks worthwhile. We’re in an era of widespread dissatisfaction with existing social services, which could provide tailwinds for new alternatives. Even if Bluesky were to restrict their APIs in the future, you would have already bootstrapped your service by then.

So what are you waiting for? Get out there and build!