Roadmap

Here's what we're planning for Beads between now and September 1st, 2026. All of this is, by definition, aspirational so may change over time. Your mileage may vary. Some assembly required. Void where prohibited. You get it…

First up, we're adding application-level usage metrics to Beads — daily unique users and bd command counts — so Gas City can track adoption and trends. Metrics will be on by default but can be disabled via config or environment variable. They won't touch your context or your work, but they are a crucial part of the venture capital raising process, so we'd appreciate you keeping them enabled.

On the quality front, the big near-term focus is CI coverage. Server v1 — the storage.DoltStore implementation that manages a Dolt sql-server — currently has tests that don't run in CI and routinely fail even on main. We plan to get all of those tests running, skip the ones that are still broken, and then systematically fix the skipped ones, starting with the tests most critical to Gas City. We'll also be adding a Gas City dependency test to Beads CI, so that any Beads change that would break Gas City fails loudly before it lands. The details of exactly how that'll work still need to be spec'd, but the goal is clear: both repos should be stable and comprehensively covered.

While that's happening, we're finishing the server v2 implementation. It's currently in progress but hard-gated — not fully implemented or tested yet. Once it's ready and well-tested, we'll let users opt in, add an explicit migration command for moving existing v1 repos to v2, and then officially deprecate v1 so that new Beads repos start on v2 by default.

With v2 as the foundation, we'll turn our attention to Beads schema v2 — a ground-up redesign to simplify and clean up the database schema and make intentional decisions about what belongs in a v2.0.0 release. That unblocks a general code hygiene pass to remove dead code and unnecessary cruft, and a meaningful reduction in Beads' command surface area: some commands are heavily used, some aren't, and some probably belong in a higher-layer orchestrator rather than in Beads itself. We'll take inventory and cut what doesn't belong.

We're also planning to decouple the Beads database from the Git repository. Today Beads requires one database per Git repo, which has its benefits but also real limitations. Adding support for a shared, decoupled database will make cross-project Beads usage a first-class feature.

All of that adds up to Beads v2.0.0: extremely stable, always "just works" out-of-the-box, and simple enough that users and agents get a consistent experience without needing to think about the implementation details that made v1.x tricky at times.

Of course, all of this comes from your input, so don't be shy about sharing your thoughts about the future of Beads.