Haven

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 README on GitHub.

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:

1. What ideas are parked, and why?
2. Which items are committed but not ready?
3. What needs a decision before anyone should build it?
4. Which agent-owned work is ready and unblocked?
5. What happened to the old version of this idea?
6. 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.

What You Use It For

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.

Use it to:

1. Capture fuzzy ideas without committing to them.
2. Attach specs, research, decisions, and evidence to the item they belong to.
3. Split, merge, supersede, and group work as your thinking changes.
4. Keep ready separate from committed, so agents do not build half-shaped work.
5. Ask an agent what it can pick up next from the real backlog.
6. Hand work between human and AI with the waiting state recorded.
7. Keep private planning material out of public repos without making it invisible to your tools.

Getting Started

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

The stable flow is:

1. Install the haven binary from GitHub.
2. Run setup to create the local store under ~/.haven and configure the first project.
3. Run the doctor check to confirm the CLI, MCP server, and local wiring are healthy.
4. Let Haven register the MCP server and bundled skill for agents such as Codex or Claude.
5. Optionally link a repository, which creates a generated Haven/ workspace while keeping the canonical backlog outside the repo.

After that, you can use Haven directly from the terminal or conversationally through an AI agent. The important commands conceptually are haven next for ready work, haven dispatch for agent-oriented context, haven docs for project anchors, and item operations for capture, grooming, handoff, and completion.

How Haven Is Shaped

Haven is a single Rust binary with a hybrid local store under ~/.haven.

The structured part lives in SQLite: projects, items, statuses, ownership, commitment, dependencies, grouping, lineage, handoffs, artifact pointers, and completion evidence. That gives Haven a queryable work graph rather than a folder of loosely related notes.

The content lives beside it as ordinary files: specs, research, decisions, handoff notes, delivery evidence, and other documents an agent may need to read or edit. Those files stay local, grep-able, and directly editable. The database knows which artifacts belong to which items, but the file contents do not round-trip through the database.

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, a local agent, and a remote agent are looking at the same state.

The repo README has the up-to-date command syntax. At a product level, the loop is capture, define, commit, dispatch, hand off, verify, complete with evidence.

The local store works offline with no account. Cloud sync is the next product step: structured rows through Supabase, file artifacts as Storage blobs, and Auth0 for identity. A web roadmap view then gives the same backlog a product-facing surface away from the terminal.

The Product Model

Haven separates two questions that backlog tools often blur together: how well something is understood, and whether I have decided to do it.

An item can move from rough discovery, to definition, to ready. Separately, it can be committed and prioritised, or it can remain floating. A well-specified idea can sit parked for months. A committed bet can still be fuzzy and need definition before anyone should pick it up.

Because those states are separate, haven next only returns work that is committed, ready, and unblocked. When nothing is eligible, Haven can explain why: not committed yet, not specified yet, blocked by another item, waiting on a person, or waiting on an external event.

The graph is designed for change. Dependencies are real edges, not prose buried in a note. Items can split, merge, or get superseded; that lineage is recorded, and an old reference can resolve forward to whatever the item became. "What happened to that idea?" should not depend on memory or archaeology through old notes.

The same model can hold more than development tasks. A legal sign-off, a license key request, a research question, a manual review, or a decision owed to someone else can all be ordinary items. That matters because real projects are not just code.

Human And Agent Ownership

Every item can say who currently owns it: human or AI. Moving work between them is one operation, and the handoff carries a note.

That sounds small, but it changes the shape of agent-assisted work. Instead of asking an agent to infer whether it is still responsible for something from a chat transcript, the item itself records the baton pass. Completing work also requires evidence, such as a test run, a PR link, or a short delivery note, and Haven reports what the completion just unblocked.

This keeps agents useful without pretending they are the whole system. Haven does not launch agents or run code. Orchestrators, coding agents, CI jobs, and humans sit above it and use the queue. Haven holds the work, its state, and the record of what it became.

The Graph Follows You

Because the store is its own thing, rather than files inside a repository, the backlog can be reached from wherever the work is happening.

That might be a terminal on a development machine. It might be Claude on a phone, using remote MCP to walk the roadmap, capture ideas, groom items, and decide what should happen next. It might be a hosted coding environment pulling the next AI-owned item, doing the work, and completing it with evidence attached.

The important point is that the backlog is not repo-scoped. One graph can span a whole product: several repositories, plus the work that has no repository at all. The working documents still live as plain files, but they live in the Haven store rather than being accidentally committed into public project history.

Scope

Haven is single-player at launch. One person's identity owns the store, and agents act as clients of that same backlog. That assumption is deliberate: it keeps sync, permissions, and conflict handling small enough to make the product reliable.

Multi-user collaboration is planned, but it is a product boundary rather than a feature flag. The graph already models work that spans people through gates, approvals, dependencies, and handoffs. Turning that into a team product means doing identity, permissions, and conflict handling properly.

Haven is also 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.

Relationship To Codezilla

Haven and Codezilla sit at different points in the same AI-assisted development loop.

Haven holds the durable work: what exists, what matters, what is blocked, who owns the next move, and what evidence proves something is done. Codezilla is the workspace for active local agent sessions. One remembers the work; the other helps a human steer the running sessions.

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.

The public version is local-first and single-player. Sync is on the short-term horizon; multi-user collaboration comes after the single-player product is solid.