Clankkers

At a glance

• Outcome — A local control plane that runs coding-agent work as durable, auditable jobs with explicit human approval gates, instead of ad-hoc terminal sessions.
• Status — Working internal orchestration system, under qualification. It is not production SaaS and I don’t present it as one.
• Role — Solo. Evolved from my earlier Shipwright codebase; I own the architecture, acceptance criteria, integration, review, debugging, and live validation, with AI-assisted implementation.
• Stack — Go core; SQLite event spine and projections; CLI/TUI; HTTP and MCP surfaces; a TypeScript/React cockpit.
• Source — Private; presented here as a case study.
• What works today — The long-lived daemon, event store and projections, process supervision, worktree/delivery logic, human gates, permissions, idempotent commands, and audit/recovery paths.
• Validation — Extensive Go tests across the store, reducers, adapters, recovery, commands, TUI, and bridge behavior.
• Limitations — Real-workflow and operator evidence is still being accumulated; qualification of the supported v1 surface is incomplete.

Overview

Running coding agents seriously creates an operations problem: work needs to survive restarts, destructive actions need a human in the loop, and after the fact you need to be able to answer “what happened, in what order, approved by whom?” Clankkers is my answer — a local-first control plane where agent work flows through a SQLite event spine, every command is idempotent, and sensitive steps stop at durable human gates until an operator approves them.

It grew out of Shipwright, an earlier orchestration codebase of mine, rather than appearing fully formed; the event-sourced core, recovery behavior, and gate model are where most of the design iteration went.

What works today

• A long-lived daemon supervising agent processes, with worktree and delivery management.
• A SQLite event spine with projections, so state is replayable and auditable rather than mutable-in-place.
• CLI, TUI, HTTP, and MCP surfaces over the same core.
• Durable human gates and permissions on sensitive operations, and idempotent commands so retries are safe.
• Restart recovery — the system is designed to come back from a kill without losing or duplicating work, and that behavior is tested.

What “under qualification” means

The honest state: the system works and is tested heavily at the unit and subsystem level, but I’m still accumulating evidence from real workflows and real operator use before calling the v1 surface supported. Generated contracts and AI-assisted implementation are part of the history; the authored-work claim I stand behind is the architecture, the event and recovery model, the acceptance criteria, and the debugging.