ROADMAP / ENGINEERING_ORDER
Build the hard core before the product shell
The roadmap is implementation-first: the C-based Sykes VCS Engine, compression, Sykes DB and its shared LSM component, simulation, a local Neovim plus opencode flow, replication and consensus, Editor Plugins, DB Inspector, the Sykes VCS Application, and only then the hosted GitHub replacement. The point is to earn trust through working software first.
Build the Sykes VCS Engine in memory
The first milestone is to make the C-based Sykes VCS Engine work with actual CRDT operations, not a Git-shaped abstraction. This includes the operation structure, an in-memory tree for representation and fast lookups, and operation creation for editing paths.
- Define and structure CRDT operations
- Create the in-memory tree for representation, lookups, and operation creation
- Make insert, delete, undo, and redo work in memory
- Keep the current work clearly marked as prototype-level, not production-ready
Make compression correct before making it clever
Keystroke-level history only works if compression is correct. The direction is a mix of RLEs, different encodings, and columnar layout so the operation log stays small without losing fidelity.
- RLE and alternative encodings are part of the compression path
- Columnar representation is being explored for compact operation storage
- Insert compression works
- Delete, undo, redo, and the remaining operation families still need correct compression
Build Sykes DB on the shared LSM component
Sykes needs its own database instead of forcing CRDT history into Git objects. The current direction is LSM-based and heavily inspired by TigerBeetle engineering discipline, but the final design is still being shaped by CRDT-specific constraints.
- LSM-based storage engine is the current direction
- Keep LSM as a focused shared storage component beneath Sykes DB
- Explore fixed-size rows to keep storage and recovery predictable
- Make CRDT operations the native database workload
- Expose database state and storage behavior to Sykes DB Inspector
- Optimize for important CRDT-history KPIs rather than general-purpose flexibility
Simulate editing before trusting the system
The simulator is also heavily inspired by TigerBeetle. Its goal is to generate realistic write and edit workloads, stress the CRDT model, stress storage, and later replay real edits from the Sykes-VCS codebase itself.
- Generate edit streams for testing the CRDT model
- Current edit generation works but is still suboptimal
- Use simulation to find storage and merge edge cases before users do
- Later feed real Sykes-VCS codebase edits into the simulator
Replicate across internal and external networks
After the local model, compression, database, and simulator are solid enough, Sykes needs replication and consensus. The system has to work across internal networks and external networks because source control must survive real deployment conditions.
- Design replication around the CRDT operation stream and database log
- Build consensus for multi-replica durability and coordination
- Support local/internal network deployments
- Support external network replication for hosted and distributed setups
Connect editors through Sykes VCS Editor Plugins
File observation is not enough for Sykes-VCS. Editors and AI tools need harnesses or plugins that can emit the right operations, preserve intent, and expose provenance. The current proof path is a local Neovim + opencode + Sykes-VCS flow.
- Keep improving the Neovim integration for documents and text operations
- Keep improving opencode change communication into the Sykes flow
- Build proper editor plugins instead of relying on filesystem watchers
- Preserve authorship and operation provenance at the source of edits when users want that view
Build the Sykes VCS Application
The Sykes VCS Application is the user-facing component, not only a set of terminal commands and editor integrations. It should use the shared UI component to make history, collaboration, provenance, branching, and review understandable across the main operating systems.
- Design the Application around CRDT history and collaboration
- Use the shared UI component for reusable interface implementation
- Support all main operating systems
- Make undo, redo, provenance, and merge state visible to users
- Keep the UI serious enough for professional software teams
Build the hosted GitHub replacement
Once the core version-control system, database, replication, editor harnesses, and GUI are strong, the next layer is the hosted GitHub replacement: a service for repositories, collaboration, privacy, reliability, and company-owned source data.
- Offer hosted repositories, organizations, reviews, and collaboration workflows
- Provide a familiar service surface while replacing the Git assumptions underneath
- Protect customer data and company privacy by design
- Keep self-hosting as a first-class option alongside the hosted service
ROADMAP_RULE
Every component depends on a correct operation log
The Application, DB Inspector, Editor Plugins, agent interfaces, replication, and hosted service only work if the Engine operations are correct, compact, durable, and observable. The roadmap keeps that dependency visible: prove the model, store it, inspect it, simulate it, replicate it, expose it to tools, and then turn it into a full GitHub replacement.