Veritas Kanban: a local-first board that grows an agent control plane
Lightweight orchestration harness built for your AI agents. The unfiltered truth about where your project stands.
At a glance
- What is it?
- Veritas Kanban ships as a Kanban board you run on your own machine, with CLI, MCP, OpenClaw, webhook and governance layers you add later. The interesting part is not the board. It is the v6 runtime control plane the project documents around it, and whether you want that weight.
- Who is it for?
- Adopt Veritas Kanban if you want a local board whose optional layers you switch on one at a time, and if you are willing to read docs/SETUP-PATHS.md and docs/architecture/V6-AGENT-RUNTIME-CONTROL-PLANE.md before wiring an agent to it. Skip it if you need a hosted board your whole team opens in a browser with no local install, or if you only want a task list and no runtime control plane.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Veritas Kanban picks, and who it is aimed at
Most task boards assume a human is the only actor. A card moves because someone dragged it. Veritas Kanban starts from the opposite assumption: cards may be moved by an assistant, and the board may be the surface where an agent's work becomes visible. The README frames it as a local-first task management board with optional AI agent orchestration, and the tagline is blunt about intent: the unfiltered truth about where your project stands. The homepage is sstb.ai, and the author is Brad Groux, who the README identifies as CEO of Digital Meld and host of the Start Small, Think Big podcast. That context matters because it explains the shape of the product. This is not a neutral tool. It is one person's opinion about how agent work should be governed, published as MIT code.
The audience is narrower than the topic list suggests. Topics include kanban, scrum, task-management and project-management, but also agents, codex, hermes, openclaw, local-first, devops-tools and pino. Someone who just wants a Scrum board is not the target. The target is an engineer or small team already running coding agents locally, who wants the tasks those agents work on to live in files on their own disk rather than in a vendor's database. The Quickstart confirms the posture: start with the local board, and add OpenClaw, MCP, Squad Chat webhooks, notifications, workflows and governance gates only when you need that layer. The board is the floor, not the product.
What actually runs: Vite UI, API server, markdown tasks, SQLite parity
The repository is TypeScript, with React and Vite listed as topics and a pnpm workspace layout implied by the install instructions. Two processes appear in the setup steps: a UI on port 3000 and an API on port 3001, with health exposed at /api/health. Tasks are files, not rows in a hosted database. The README's clean-slate instruction is to delete tasks/active/task_example_*.md and refresh, and re-seeding is a single command, pnpm seed, which the README says only works when the board is empty. That file-backed model is the most consequential design decision in the project, because it means your board is diffable, greppable and portable without an export step.
Around that core sits a v6 architecture the docs describe at length. The documentation map lists an Agent Runtime Control Plane covering authority, adapter, lifecycle, approval, tool, credential, Buzz and certification boundaries. Phase Capability Profiles are described as versioned execution-phase authority contracts with deterministic intersections and exact-path plan artifacts. The Phase Transition Journal is described as durable compare-and-set transitions with approval and override controls, restart recovery, REST and CLI operations. A Run Access Summary is described as one redacted, digest-bound view of a run's filesystem, network, tools, integrations, budgets, support and historical authority. Knowledge Collections are described as immutable sources with cited pages, stable identity, bidirectional links, and reversible reviewed ingestion with file and SQLite parity.
That is a lot of machinery, and the phrase file and SQLite parity is worth pausing on. It implies two storage paths that the project intends to keep consistent, which is a maintenance commitment, not a feature you get for free. The README also states that a working board is separate from agent-ready and from external wake and delivery-ready, and points to readiness levels in docs/SETUP-PATHS.md. Read that as an admission that the layers fail independently. A board that loads tells you nothing about whether an agent can safely write to it.
Getting it running: two install paths and one deliberate restraint
There are two documented ways in. The packaged Mac desktop app is a Homebrew cask: brew tap BradGroux/tap followed by brew install --cask veritas-kanban. The README says the app is signed and notarized and that existing desktop users should follow a routine Mac upgrade path covering backup, heartbeat pause, app replacement, launch and exact-version server readiness, in that order. The ordering is not decorative. If you skip the heartbeat pause during an upgrade, the README implies you can end up with a running agent pointed at a server that is mid-replacement.
The source path is four commands: git clone the repository, cd into it, pnpm install, copy server/.env.example to server/.env, then pnpm dev. The README tells you to edit that .env to change VERITAS_ADMIN_KEY, and warns never to commit .env files, using .env.example as the template because it holds safe placeholder values and documents every variable. The board auto-seeds with example tasks on first run.
The restraint is the part I would highlight. The README explicitly says not to configure OpenClaw gateway or browser relay, MCP write access, Squad Chat webhook or external wake behavior, notification delivery channels, or workflow gates and governance policies on day one unless you already know you need them. It also gives you a prompt to hand your agent that instructs it to do the board-only setup and explicitly not configure those layers. That is an unusual thing to publish. Most projects bury the advanced setup in the quickstart because it looks impressive. Here the author tells you to stay on the floor until the floor works, and to run read and write smoke checks before handing the board to an assistant. The MCP guide is documented as covering 42 tools, an architecture, a tool catalog, a security model and those smoke checks.
Where it is the wrong tool, and what the docs do not settle
The clearest limitation is environmental. The packaged install is a Mac cask. The source path assumes Node, pnpm and a machine where you are comfortable running two local services on ports 3000 and 3001. A team that wants a hosted board anyone can open from a browser, with no local runtime and no .env file, is not served by this. The README points to a self-hosted setup path, but self-hosting is a path you take on, not a default you inherit. Likewise, anyone who wants a task list and nothing else is paying complexity for capability they will never enable.
The second limitation is documentation maturity relative to ambition. The v6 material describes approval boundaries, credential boundaries, certification boundaries, digest-bound access summaries and compare-and-set phase transitions. Those are strong claims about a system's guarantees. The supplied README does not show the failure semantics: what happens when a compare-and-set transition loses a race, what a certification boundary rejects, or how the redacted Run Access Summary behaves when a run touches a path outside its declared scope. Those answers may live in docs/architecture/, which the README links. I have not read them, and I have not run the software, so I cannot tell you whether the guarantees hold. Treat the architecture docs as claims to verify against the code, not as settled behaviour.
Third, release cadence. Three releases land within six days in the supplied data: v6.1.7 on 2026-09-04, v6.2.0 on 2026-09-08, v6.2.1 on 2026-09-10. Fast iteration on a control plane that governs what agents may write is a real operational cost. If you pin a version, expect to read the CHANGELOG before each bump. The README's own upgrade guide, with its ordered backup and heartbeat-pause steps, exists because upgrades are not free here.
The honest alternative: a plain markdown board with your own glue
The obvious comparison is not another agent platform. It is a plain file-based board such as a markdown task folder rendered by an editor, or a self-hosted tracker like Vikunja or Focalboard. The difference in approach is where the agent contract lives. A plain board gives you files and stops there. You write whatever script moves a card when an agent finishes, and you own the authority model, the approval step, the access summary and the audit trail, because none of them exist. Veritas Kanban's bet is that those pieces are common enough to ship as a documented control plane with named artifacts: phase capability profiles, a transition journal, a run access summary, knowledge collections.
The trade is real in both directions. With a plain board you get a smaller surface, fewer moving parts, and no versioned authority contracts to keep in sync with your agents. You also get to reinvent compare-and-set transitions and redaction yourself, usually badly, usually after an agent writes somewhere it should not have. With Veritas Kanban you inherit a specific opinion about how agent authority is scoped, and you inherit its release cadence and its two-store parity requirement. If you already run Codex or Claude Code locally and want the board to be the place where their work is visible and bounded, the shipped control plane is the reason to pick this over a markdown folder. If you want a task tracker and nothing more, the markdown folder wins on every axis except the UI.
Licence, maintenance and what an upgrade actually costs you
The licence is MIT, stated in the README badge and in the repository metadata. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice travel with it. That is the whole of what I will say about the legal side; if you are embedding this in a product, read the LICENSE file and get your own advice. The practical implication for adopters is that forking is genuinely available. If the author's roadmap diverges from yours, or the project stops being maintained, you are not stranded.
Maintenance cost is dominated by the optional layers, not the board. A board-only install is pnpm install, a .env file and pnpm dev. Every layer you add brings its own smoke checks, its own configuration and its own failure mode, which is exactly why the README separates board-ready from agent-ready from external wake and delivery-ready. The upgrade guide's ordered steps, backup then heartbeat pause then app replacement then launch then exact-version readiness, tell you what a bad upgrade looks like: an agent still running against a server that moved. Budget for that sequence on every desktop upgrade, and read the CHANGELOG before each version bump given the six-day release window in the supplied data. The pnpm seed command is a small but telling detail: it only works when the board is empty, so re-seeding after you have real tasks means clearing them first. Keep your own backup of tasks/active/ rather than relying on seed to restore anything.
Editorial conclusion
Adopt Veritas Kanban if you want a local board whose optional layers you switch on one at a time, and if you are willing to read docs/SETUP-PATHS.md and docs/architecture/V6-AGENT-RUNTIME-CONTROL-PLANE.md before wiring an agent to it. Skip it if you need a hosted board your whole team opens in a browser with no local install, or if you only want a task list and no runtime control plane. Before committing, verify three things on your own checkout: that pnpm dev brings up the UI at localhost:3000 and a healthy response at localhost:3001/api/health, that the v6 upgrade guide covers your existing install path, and that the MCP tool catalog matches the writes you intend to allow.
Community notes