Labsco
MCP SERVER

A task graph that lives as Markdown in your repository — agents claim ready work, run an observable session, and hand off for review, with the same gates the web UI enforces.

Project & Task Management
Summary
The gates are the same for the agent and for you.

Both front-ends are thin adapters over one rule-set, so an agent cannot close a task by a route that skips the checks a human would have to pass. Closing deliberately blocks while the checks run — the latency is the point, since closing is when verification belongs. Because identity comes from `--actor` at startup rather than from the call, the provenance trail is something an agent cannot spoof by passing a different name.

What it is

A single Go binary that serves one task graph two ways: a web board for you and an MCP server for your agents. The tasks are Markdown files in the repository — YAML frontmatter for the machine, prose for people — so they branch, merge and review like code, and a task's history is its git history. No database.

What you get
  • Reads — `identity` for the bound actor, `list` filtered by `status`, `assignee`, `ready` or `execution`, and `get` for one task with its body, checks and provenance
  • `create` — the engine assigns the id; `deps` must already exist, so the graph never dangles, and `checks` can carry a shell command or be marked manual
  • `claim` to take a task, `transition` to move it, `note` to append an audit breadcrumb without changing state
  • Two gates enforced on every path: a task cannot leave its initial state until its dependencies close, and cannot enter a closed state until its checks pass — `transition` auto-runs the command checks and refuses on any failure
  • `run_checks` to run them without transitioning, with full output written to `.cairn/runs/`
  • Agent sessions — `begin` atomically claims the task and creates a durable attempt with an idempotency key, `heartbeat` reports progress, `finish` requires a review summary and moves to review, `cancel` releases the assignment and leaves the task open; `get_session` and `list_sessions` read them back
  • `ready` derived on read from whether dependencies are satisfied, never stored — so `list(ready=true)` is the agent's "what can I start now" query
  • Every write stamped with the actor that made it
Requirements

No account and no key. `make build` produces `bin/cairn`; there is also a desktop app for macOS, Windows and Linux on the releases page. `cairn web --repo .` opens the board, and its Connect page detects installed agents and writes their MCP config for you — Claude Code, Cursor, Codex, Windsurf, OpenCode, Kilo Code and Pi in one click. By hand, register `cairn serve --actor agent:claude --repo <path>`. Identity is fixed at startup by `--actor` and is not a tool argument, which is how each agent gets its own name in the provenance. Local and single-user by design, with no authentication. MIT.