Sidecat Gen5 development now targets daily use
The sidecat repository now contains Gen5, a clean-sheet
implementation of Sidecat. Its current milestone is straightforward:
make Gen5 capable of running Sidecat's daily development work so the
project can stop relying on Gen4.
This is not a compatibility or migration project. Gen5 does not preserve earlier commands, APIs, wire formats, schemas, packages, stores, data, or workflows. Every Gen5 store starts fresh. Earlier Sidecat generations remain available as design references, but they do not constrain Gen5.
How the repository reports progress
The repository separates accepted design from current implementation status:
- system.md defines the accepted architecture and reports subsystem maturity as unimplemented, foundation, exercised, or qualified.
- features.md tracks complete product outcomes, their status, branches, and qualification boundaries.
- capabilities.md maps the reusable capabilities required by those features.
- proposals/ contains consequential design changes that have not been accepted. Accepted contracts move to specifications, with a corresponding decision record.
As of this post, no subsystem is qualified for a Gen5 release. The repository also generates llms.txt and a full-context companion so tools and new contributors can find the same source documents without reconstructing project state from chat.
The daily-driver milestone
The active priority in BUILD.md is the Gen5 daily-driver cutover. A fresh agent must be able to start or diagnose the daemon, discover and make governed calls, manage project and work records through closure, exchange durable messages, reuse a promoted procedure, publish through governed Git operations, and recover after restart or store restoration.
Qualification requires the production binaries, durable stores, supported client surfaces, a consequence-bearing call, restart and recovery tests, and an actual feature delivered with Gen5 alone. Internal models, isolated tests, command names, or static screens do not meet that bar.
First implementation slice: managed invocation outcomes
The first completed slice is managed invocation outcomes. Before
returning a terminal result, sidecatd retains the operation
request, result or safe failure, consequence state, execution proof, and
receipts in the selected authority store. The client receives a stable
invocation reference and can retrieve the exact retained detail later
without executing the operation again.
The contract also separates a Sidecat invocation request key from an operation's own idempotency key, retains unknown consequences instead of authorizing a blind retry, and makes the same retained outcome inspectable through the CLI, Lisp, and MCP after a daemon restart.
Real sidecat and sidecatd processes now prove
this behavior on the active
F-003 feature branch,
including recovery after the first response is lost. It is a qualified
development checkpoint, not a release.
Current status
Gen5 is pre-alpha and has no release. Gen4 remains the installed development tool while Gen5 is built. The feature map and subsystem maturity table will continue to show which parts are accepted, implemented, and qualified.