← Back to projects

Haven

View on GitHub

A local-first AI-native backlog manager for shaping fuzzy ideas into ready work, with specs, evidence, ownership, handoffs, and Markdown artifacts agents can use.

Haven

Technologies

RustSQLiteMCP

Haven is a local-first AI-native backlog manager for work that spans humans, agents, repositories, and real life.

It keeps the shape of the backlog in a structured graph, while leaving the working material as Markdown files that humans and agents can read and edit directly. The goal is not to be another delivery dashboard. The goal is to make the backlog itself more useful: clearer intent, better readiness, visible dependencies, explicit ownership, and evidence when work is done.

For the longer backstory, I have written a separate article: Introducing Haven. For exact install commands, release notes, and current platform details, the source of truth is the Haven GitHub repo.

The Problem

Most tools with a backlog are really built for lifecycle management: assign the issue, plan the sprint, track the status, review the PR, report the delivery.

That work matters, but it starts after a lot of the product thinking has already happened. For a long-lived solo product, especially one worked on with AI agents, the harder problem is often earlier. What ideas are parked, and why? Which items are committed but not ready? What needs a decision before anyone should build it? Which agent-owned work is ready and unblocked? What happened to the old version of this idea? What evidence proves that finished work is actually finished?

Without a durable backlog, the work gets scattered across chat scrollback, PLAN.md files, repo-local notes, issue trackers, and whatever an agent happened to write during a session. Haven is built around those continuity questions. It is not a place for an agent to dump its thoughts. It is the durable backlog the human and agents share.

Key Features

  • AI-readable backlog graph with items, dependencies, readiness, commitment, ownership, lineage, waiting state, and completion evidence
  • Markdown artifacts for specs, research, decisions, handoff notes, delivery evidence, and project documents
  • CLI and MCP access so humans and agents read and update the same backlog
  • Ready-work dispatch through haven next and haven dispatch
  • Decision provenance for splits, merges, parking, reprioritisation, and deprioritisation
  • Human and AI ownership with handoff state and waiting reasons
  • Handoff to team tools — your AI can push an item out to Jira, Linear, or GitHub and reconcile its status back, with no integration to wire up
  • Local-first store under ~/.haven

Built With

  • Rust for the CLI, local services, and core graph operations
  • SQLite for the local structured work graph
  • Markdown artifacts under ~/.haven for human-readable working material
  • MCP so agents such as Claude and Codex can read and update the same backlog

How Haven Is Shaped

Haven is a single Rust binary with a hybrid local store under ~/.haven. The structured part lives in SQLite. The working material lives beside it as ordinary Markdown files that stay local, grep-able, and directly editable.

The same operations are exposed through a CLI for the human and an MCP server for agents. Both use the same store, so a terminal session and a local agent are looking at the same state.

At a product level, the loop is capture, define, commit, dispatch, hand off, verify, and complete with evidence. haven next only returns work that is committed, ready, and unblocked. When nothing is eligible, Haven can explain why.

Where Haven Fits

Haven is most useful when the work is too structured for a TODO list, but too early, private, cross-repo, or agent-facing for a hosted team tracker.

It is deliberately not a replacement for GitHub, Linear, Jira, or an agent orchestrator. A merged PR is better evidence than any tracker field. A team tracker is better when ten people need reporting, analytics, and management workflows. Haven is for the durable solo-builder graph underneath the work.

It doesn't replace those trackers, but it can reach them. When work needs to live where a team can see it, your AI can hand an item off to Jira, Linear, or GitHub — creating the ticket there, recording where it went, and reconciling the status back into Haven. There is no integration to set up: the agent you already use is the bridge.

Haven and Codezilla sit at different points in the same AI-assisted development loop. Haven remembers the durable work. Codezilla is where a person sees and steers the active local agent sessions doing that work.

Getting Started

The current install methods and command syntax live in the Haven README on GitHub. The public local-first version supports Homebrew, an install script for prebuilt binaries, and building from source.

The longer product story is in Introducing Haven.

Status

Haven is in daily use — I run my own work through it. The local CLI, SQLite graph, artifact store, generated backlog projection, dispatch logic, lineage model, completion flow, and 27-tool MCP server are working end to end.