Commitarium

Commitarium grew out of a development workflow I was already using. I would discuss a task with Codex and work with it to form a plan. For smaller changes, the same thread could continue with the implementation. Larger changes began with a detailed handoff so that a new thread could take over with the necessary context.

Once the implementation was ready, I had the implementing thread open a pull request and asked Claude to review it. I then carried Claude’s findings back to Codex, waited for the changes or explanations, and returned the result to Claude for another review. That continued until every blocking issue had been addressed.

The workflow worked well, but coordinating it did not. I had become the intermediary between two tools, manually transferring context, reviews and responses from one to the other. Commitarium began as a way to preserve the separation between implementation and review while turning the handoffs into a structured, repeatable process.

A project can be imported from an existing directory or created inside Commitarium. Each project receives its own repository on an internal Forgejo server. Its development stack is then defined—with help from an agent if needed—so that the required tools, packages and dependencies can be prepared before work begins.

Development is organised into work orders. Each one follows the same underlying process:

Clarify
A work order begins with a name and an optional description. The lead discusses it with the user until the goal and scope are clear. Work does not proceed until that goal has been accepted.

Plan
The lead and reviewer turn the accepted goal into an implementation plan. Both agents must agree on the approach, and the work is divided into small slices intended to become individual commits.

Implement
The lead works through the agreed plan in order, validating and committing each slice as it is completed.

Review
The reviewer examines the implementation through its pull request. The lead addresses each finding with a code change or an explanation, and the two continue until the reviewer finds nothing blocking. Issues outside the agreed scope are surfaced to the user as candidates for a separate work order.

Merge
Once the required approvals and checks are complete, the coordinator verifies the repository and pull-request state and performs the merge. The agents cannot merge the protected branch themselves.

Accepted work can then be synchronised into the local project as a single clean commit. Publishing that result upstream is a separate operation, and Commitarium can only push it to a new branch. It cannot modify or force-push an existing upstream branch.

The review phase records why both agents consider the work ready to merge.

Forgejo is more than an internal Git server in Commitarium. It provides a durable engineering record for every work order.

The agents can converse through the coordinator, but the conclusions that matter are recorded in the pull request: the agreed plan, implementation commits, review findings, responses, validation results and final approval. This leaves an ordinary, inspectable development history instead of a long agent conversation that has to be interpreted afterward.

The reviewer always inspects an exact pushed revision. Before review, approval or merge can advance the workflow, the coordinator verifies that the reported Git and Forgejo state actually exists.

Codex and Claude can each act as either the lead or the reviewer. The user also chooses how autonomous a project should be: Commitarium can stop for approval after every phase or allow bounded work to continue through the workflow automatically.

The agents have substantial freedom inside their assigned environments, but the boundaries around those environments are strict. Each agent runs in an isolated Docker container with access to a managed project workspace and its own limited Forgejo identity. They do not receive access to the user’s directories, upstream Git credentials or Docker socket.

A deterministic coordinator written in Go owns the workflow state, recovery and final merge. Forgejo stores the repositories, pull requests and review history. Tauri 2 and Rust provide the native application shell and trusted boundary for host operations, while React provides the interface.

Project-level controls keep agent assignments, autonomy, merging and external handoff explicit.

Commitarium was built for my own development workflow rather than around a hypothetical one. The project itself was developed with Codex and Claude using the same underlying approach: small planned changes, separate review and explicit acceptance before integration.

It is open source under the Apache 2.0 licence and is currently in prerelease. The workflow described here is functional, with installers available for macOS, Windows and Linux. Signing, broader platform testing and further product polish are still in progress.

I have started working on a stronger form of independent validation. The reviewer would create an acceptance test suite without shaping it around the finished implementation, while the lead would implement the agreed behaviour without access to those tests. The resulting code could then be evaluated against criteria neither side had been able to tailor to the other.

I also plan to add a mobile frontend that can pair with the desktop application. As long as the host computer is running Commitarium, the paired device could be used to follow progress, respond when input is required and operate the workflow remotely.