EARLY BUILD
not production ready
VERSION_CONTROL / CLEAN_BREAK
Version control beyond the Git workflow
Sykes-VCS is an early-development, clean-break replacement for Git, aimed first at solo developers, small teams, and people working with AI agents. The goal is full collaboration with your team and agents while fixing Git pain around forgotten commits, missing pushes, unnecessary merge conflicts, and opaque agentic work.
CRDT_CORE C_SYSTEMS
SYNC GOAL
CORE C
SOLO + SMALL TEAMS
first target audience
AGENT WORK
first-class design concern
EXPLANATION
Git stores snapshots. Sykes is designed for collaboration.
Git is excellent, but Sykes-VCS is not trying to be Git-compatible. It is a clean break for source control that treats collaboration, multi-machine work, and AI-agent edits as core problems instead of add-ons. The system is still early, but the design target is CRDT operation history backed by a database built for that shape of data.
BUILD_STATUS: EARLY_DEVELOPMENT
A clean Git replacement
Sykes-VCS is intentionally not a Git compatibility layer. Compatibility would carry too many old assumptions forward, so the goal is a clean switch for people who want a different model.
Multi-machine work
The first pain to fix is everyday source control friction: working across machines, forgetting to commit or push, and hitting unnecessary merge conflicts because the system only sees late snapshots.
CRDT operation storage
Sykes DB is being designed as a narrow database for CRDT operation history. The ambition is excellent durability, performance, and storage behavior by accepting less flexibility.
Quality over speed
Time to market is not the focus. Sykes is a large one-person systems project, so the build process favors a robust, performant, reliable, durable system over a fast launch.
[SYS] Building the Sykes VCS Engine in C... [EARLY]
[SYS] Building domain-specific CRDT database... [IN_PROGRESS]
[SYS] Testing keystroke-granular source history... [PROTOTYPE]
[SYS] Targeting local Neovim + opencode flow... [NEXT]
PROJECT_STAGE
EARLY DEVELOPMENTNEXT_DEMO
NVIM + OPENCODE LOCAL FLOWQUALITY_BAR
ROBUST BEFORE FAST SHIPPINGSTACK_MODEL
FOCUSED C COMPONENTSroot@sykes:~$
sykes roadmap --next-local-demo SYKES_SYSTEM / COMPONENT_ARCHITECTURE
Focused applications, tools, and shared components
Sykes VCS is written in C and organized as focused components. The Application owns the user experience, the Engine owns CRDT editing rules, Sykes DB owns durable history, and the DB Inspector exposes database state for development and debugging. Editor Plugins connect real editing environments to the Engine.
A shared component layer supports the system without blurring those responsibilities. It currently includes the Base Layer, UI, LSM, and room for additional focused components. The first public proof point remains a local Neovim, opencode, and Sykes VCS flow.
application component Sykes VCS Application
the user-facing version-control application for history, collaboration, and review
sykes-vcs.com/application / Explore Applicationengine component Sykes VCS Enginethe anchor-based CRDT engine for edit creation, validation, and collaboration
sykes-vcs.com/engine / Explore Enginedatabase component Sykes DBthe special-purpose database for durable CRDT operation history
sykes-vcs.com/db / Explore Sykes DBinspection component Sykes DB Inspectorthe developer tool for inspecting and debugging database state and behavior
sykes-vcs.com/db-inspector / Explore Inspectoreditor integration component Sykes VCS Editor Pluginseditor-facing adapters that send structured source edits into the Engine
sykes-vcs.com/plugins / Explore PluginsTRUST_MODEL
Trust has to be earned by the build
Sykes-VCS is not something anyone should trust for production yet. It is an ambitious, one-person systems project, and trust has to come from visible progress, working demos, and eventually a product that proves itself. The hand-written approach is about full accountability, learning, and owning the engineering decisions, not a statement about AI capabilities.