Skip to main content

What is autodev?

autodev is a repository-native planning board and an autonomous delivery fleet for software work. It is designed to turn a ready story into a landed change while retaining the facts needed to explain every decision along the way. The same binary also provides a local operator workspace, typed coordinator workflows, durable conversations, and an optional central store daemon for many registered repositories.

Pre-release

The current 0.1.0 implementation is actively developed and still has known integrity, confinement, recovery, and product-boundary gaps. Read Current limitations before relying on a fleet record.

The planning board keeps intent in Markdown with typed frontmatter: stories, acceptance criteria, dependencies, epics, designs, decisions, and shared terminology remain readable and reviewable in git. The fleet keeps operational state separately: waves, workers, transcripts, evidence, reviews, gate results, and delivery records live in a typed runtime store.

One delivery, end to end​

A normal delivery looks like this:

ready story
  -> pinned wave
  -> agent turn in an isolated worktree
  -> observed commit and mechanical evidence
  -> independent review
  -> integration on the current branch tip
  -> repository gate on the post-merge tree
  -> delivery record and board update

The important word is observed. A worker does not complete a story merely by saying it is done. The fleet reads commits from git, derives the write set, runs repository-level verification, records the review, and gates the tree that is about to remain on the base branch. The current pre-release boundaries are disclosed in Current limitations.

The board and the fleet​

SurfaceResponsibilityDurable form
BoardIntent, scope, dependencies, acceptance, and workflow stateMarkdown and frontmatter committed to git
FleetExecution, retries, evidence, review, integration, and delivery factsA local SQLite store, or a daemon-owned store for a registered workspace
Control workspaceLive investigation, diffs, workflows, requests, connectors, and recovery actionsA projection over the board and fleet records; browser state is not a second truth

This separation lets people edit and review the plan with ordinary repository tools without using planning prose as a substitute for runtime truth. A story can change while work is in flight; the wave continues against the story contract and base commit it pinned at dispatch.

Harness-independent by design​

autodev currently communicates with coding agents through their installed command-line tools. The repository can bind worker and judge roles to native Codex and Claude Code adapters, or use the generic command adapter for a headless CLI such as Pi, OpenCode, or another wrapper, without teaching the planning model about a particular vendor. The bridge launches a local process and streams its transcript; the host still owns verification and acceptance.

Direct model-provider API access is planned, but it is not part of the current execution path. See Connect coding-agent CLIs for the supported bridge contract and setup examples.

One binary, two optional services​

The CLI works directly in an unregistered repository; reading a board never requires a daemon. For operators managing several repositories, autodev daemon start can become the single runtime-store owner and each repository joins it with autodev workspace register. An unregistered repository may keep using its local store. A registered workspace uses the daemon's global store exclusively and reports it unreachable when the recorded endpoint is down; it never substitutes a second local history.

One process serves both. autodev daemon start binds the versioned JSON API on 127.0.0.1:7788 and the embedded operator client plus its control websocket on 127.0.0.1:7777, and drives every registered workspace. Register first, then start that one process:

autodev workspace register . --import   # omit --import when no local history exists
autodev daemon start --single-user

See Central daemon and workspaces and Use the operator workspace for the two surfaces and their trust boundaries.