A Board Should Be a Ledger, Not the Automation Engine
A Board Should Be a Ledger, Not the Automation Engine
We have tried enough boards to identify the real problem: the visible board was repeatedly asked to be the queue, scheduler, process supervisor, artifact broker, reviewer, and historical record. Those are different jobs. When a small local model failed or a handoff was malformed, the result was not merely a bad card; it was an ambiguous system state.
This is an assessment of the two apparent paths now in front of us: the board options published through ClawHub and the public ClawhubKanban repository. The recommendation is deliberately conservative: adopt neither as an execution engine. A thin board can be useful, but the coordinator must own orchestration.
First, a terminology correction
ClawHub is a registry for skills and packages; it is not itself a built-in task-board runtime. Searching its public catalog does surface board products, including Mission Control and PikaBoard. That makes them candidates to evaluate, not components that are already integrated with this OpenClaw installation.
Mission Control: useful interface, wrong control plane
Mission Control is a GitHub-backed dashboard. Its intended flow is explicit: a human moves a card, GitHub receives a push, a webhook transforms it, and the agent begins work. Its prerequisites include GitHub CLI, Tailscale, and a Tailscale Funnel. The task file in Git becomes the source of truth and moving a card into In Progress triggers execution.
That is coherent for one trusted agent and a human-managed GitHub project. It is a poor fit for a local-model fleet. It couples visibility directly to execution, adds a public-facing webhook/funnel path, and makes Git commits part of every state transition. The registry inspection also currently labels the release as security-suspicious despite a separate clean moderation summary. That is enough reason not to install it without a dedicated source and security review.
PikaBoard: closer, but not a free pass
PikaBoard presents itself as an agent-first API with a local dashboard and token authentication. Its simpler task states and HTTP API make it a more plausible ledger candidate than Mission Control. But its own documentation declares the board the source of truth and encourages per-agent boards. That directly conflicts with a coordinator-owned process chain: separate agent queues make dependency, evidence, and approval state easier to fragment.
It is worth a clean, isolated evaluation later. It is not worth installing into the working fleet before its schema is shown to support project-level stages, artifact links, explicit approvals, and an execution model where a card move cannot launch work.
ClawhubKanban: public repository, but not a clean upstream alternative
ClawhubKanban is already public, and our local checkout points at that same repository. It is not an independent upstream product we can simply pull to escape our customization. The checkout also contains a large uncommitted customization set, so it is not a reliable basis for judging a clean release.
More importantly, even the committed project design is an execution engine: agents claim cards, leases are refreshed by heartbeats, a dispatcher launches OpenClaw agent turns, artifacts are copied between worker and reviewer workspaces, comments carry delivery information, and Karen is placed in a stale-card/review loop. The later customization added more dispatcher, retrospective, deliverables, intake, and lifecycle-guard behavior. Removing the dirty changes would reduce complexity, but it would not fix the architectural mismatch.
Its useful ideas should survive: explicit acceptance criteria, one-file artifact contracts, dependency links, review states, and failure history. Its execution authority should not.
The contract for the next board
The board should record: project, stage, owner, immutable artifact links, approval decision, and failure reason. It should not claim work, hold leases, launch agents, relay prompts, copy artifacts, or decide that a retry is warranted.
- Simon creates and owns one parent work order.
- Simon directly launches a bounded worker and receives its artifact.
- The artifact—not a comment—is the handoff to the next worker.
- A deterministic validator and a reviewer accept or reject the artifact.
- A credentialed publisher performs the only external mutation after approval.
- The board records all of that for humans and later audits.
This also makes local models more reliable. Their cards become small, tool-limited tasks with one input set and one required output, rather than invitations to navigate a distributed workflow system.
Recommendation
Do not revive the customized ClawhubKanban and do not replace it with Mission Control. Preserve ClawhubKanban only as historical data and a source of reusable card templates. Keep Wayfare frozen but intact for a later, separate product review. If we decide to try a public board, evaluate PikaBoard or another clean project in an isolated sandbox against the thin-ledger contract before attaching any agents, credentials, or production workflows.
The success criterion is not a prettier queue. It is one coordinator, durable artifacts, explicit approval boundaries, and no ambiguity about what has actually run.
Sources and inspection basis
- ClawhubKanban public repository — repository and committed design inspection.
- Mission Control on ClawHub — registry metadata and published documentation inspected on August 13, 2026.
- PikaBoard on ClawHub — registry metadata and published documentation inspected on August 13, 2026.
