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…

• 1. Add usage metrics to Beads.
• 2. Ensure Beads CI is running all tests for server v1 production paths.
• 3. Add GasCity dependency test to Beads CI.
• 4. Fix skipped CI tests on the server v1 production path.
• 5. Finish server v2 implementation.
• 6. Add command for migrating from server v1 to v2.
• 7. Deprecate server v1, new Beads repos use v2 by default.
• 8. Beads schema v2.
• 9. Cruft/Dead code cleanup.
• 10. Single database support (decouple Beads database/Git repo).
• 11. Command surface area reduction.
• 12. Beads v2.0.0

Details

Adding usage metrics to Beads

We plan to add application level metrics to Beads that allow Gas City to track usage, trends, and command counts. These metrics will be on by default, but can be disabled via config file or environment variable.

Metrics are a crucial part of the venture capital raising process, so we request you keep them enabled to better support Beads and all Gas Works.

They will not track or monitor your context or your work. To start, we'll be tracking:

• Daily unique Beads users
• Daily bd command counts

Ensure Beads CI is running all tests for server v1 production paths

"Server v1" is shorthand for referring to the storage.DoltStore implementation in Beads that manages a Dolt sql-server. This is in contrast to what we are calling "Server v2", which is a brand new interface and implementation for the management and access to a Dolt sql-server used by Beads.

Currently (v1.0.5) Beads CI does not run all server v1 tests in CI and it's common to see these tests fail during local development, even on main.

We plan to get all server v1 tests running in CI and skip any failing tests. At a later stage we'll work to fix the failing tests and unskip them, greatly increasing our CI coverage and Beads' stability in general.

Add GasCity dependency test(s) to Beads CI

Gas City depends on Beads and we need to ensure that a Beads change doesn't break Gas City. To do this we plan on adding something to CI that builds Gas City against a Beads change and fails loudly if the Beads change would break Gas City.

Exactly what this is still needs to be spec'd out, but we'll do this once we get to this stage of the roadmap.

Fix skipped CI tests on the server v1 production path

Of the skipped Beads CI tests, we plan on identifying the ones most crucial to Gas City, and targeting these for fixes.

Again, the goal is to ensure both Beads and Gas City are more stable and have comprehensive coverage across both repos.

Finish server v2 implementation

The server v2 implementation is currently in progress, though hard-gated as it is not fully implemented or tested.

We plan on finishing the implementation of this server and ensuring it can support all Beads commands used by Gas City.

Add command for migrating from server v1 to v2

Once v2 is implemented and well-tested, we'll allow users to start using it via opt-in, and we plan to add an explicit Beads command for users on server v1 to call which will migrate their existing v1 repos to server v2.

Deprecate server v1, new Beads repos use v2 by default

We then plan to officially deprecate server v1 and initiate new Beads repos with server v2 by default.

Beads schema v2

In order to get to Beads v2.0.0, we need to redesign, cleanup, and simplify Beads' database schema, and make intentional decisions around what should be included and excluded for v2.0.0.

Cruft/Dead code cleanup

Once we settle on the new Bead's database schema, we plan to do general code hygiene on the project by removing dead code, unnecessary cruft, and simplifying the code base as much as possible.

Single database support (decouple Beads database/Git repo)

Importantly, Beads today requires a single database per Git repository, which has some benefits and also some real limitations.

We plan to add support to Beads that allows its database to be decoupled from Git projects, which will enable sharing Beads across projects as a first-class feature.

Command surface area reduction

Beads has a lot of commands, some of which are heavily used, and some of which are not and may not even belong in Beads at all. These such commands may in fact be better implemented by a higher layer orchestrator.

We plan on doing inventory of the Bead's command surface area and determining what commands are essential and meaningful to the product and which can be deprecated / removed for v2.0.0.

Beads v2.0.0

We aim to release Beads v2.0.0 with the intention that it is extremely stable and always "just works" out-of-the-box. The goal is to simplify the product so that users and agents get an excellent, consistent experience and don't need to worry about any of the implementation details they did with Beads v1.x.

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