Documentation
Install Devplane, start a change against a spec, and make “done” mean your own gate passed against the tree as it stands.
Run any ACP agent in its own worktree, verify its change with your own checks, see weakened tests first, and keep a record of who decided what. One local binary.
Start with the quickstart and the workbench. Troubleshooting maps symptoms to commands; CI verify brings the verdict to pull requests.
Getting started
Install it, and get the board on screen.
Install Install Devplane on your platform — the desktop app, the installer, npm or cargo — check it works, upgrade it, and remove every trace of it. Quickstart From nothing to a verified change, step by step: install, start the host, make a practice repository with a failing test, let an agent fix it, and read how it was verified. The workbench A tour of Devplane's interface: the regions, a change's six views, the review, the inbox, the palette and the keys that matter. Troubleshooting What a symptom means and the command that fixes it: the gate is off, the port is taken, a session is not watched, GitHub is not read, a verified change went stale, the ledger is empty after an upgrade.
Guides
The loop, end to end.
Watching sessions How Devplane sees agent sessions it did not start: the roster, command hooks, OpenTelemetry and the optional status line — per vendor, and what each state means. Driving agents Start, prompt, watch, stop and resume any agent that speaks the Agent Client Protocol — and add one that is not built in with one entry in a file. Verified done A change is an isolated checkout, an agent in it, and your own gate as the definition of done. Verified means that gate passed against the tree exactly as it stands. Working to a specification Name the spec folder a change answers, send an agent the tasks you choose, and make your own gates the verdict inside Spec Kit's workflow. The decision log What Devplane did or refused, on whose authority, and with which rule or check — kept after everything else is pruned. CI verify Run the base's own check on every pull request, and lead the job summary with the checks the change weakened. One workflow step; nothing posted to the pull request.
Reference
Every flag, key and rule.
CLI reference Every Devplane command and flag. Reading works with nothing running; a command that needs the host says so. Configuration The complete devplane.toml reference. Every key is read by the code; an unknown key is a parse error rather than a silent default. Permissions Devplane approves nothing on its own. It refuses a tool call (deny) or puts one in front of you (ask), in Claude Code's rule syntax, per repository, and allows only what you wrote in your own grant — failing closed when the rules will not load. Architecture A map for contributors: one binary and one store, the hook writes, the host folds, the pure core reaches nothing outside. Processes, the store, the API routes, recovery and the window. Security The trust model: what stays on your machine, what guards the local API, where the permission gate fails closed, and what Devplane does not defend against.