../projects / naicom
+========================================================================+

NAICOM

// agent-dispatch daemon · Jira ticket to merged pull request

+========================================================================+
v0.1 · [ACTIVE] · Rust · SvelteKit · Postgres · Docker

The dispatcher behind the way everything else here gets built. A Rust daemon polls the issue tracker, and when a ticket reaches an approval state it spawns a Claude Code operator for the role that state implies — product spec, implementation, architecture review, QA — each in its own git worktree, each closing out with a pull request, a session log, and a comment back on the ticket. A SvelteKit console reads the resulting record.

  • > Ticket state is the trigger: each workflow state routes to one operator role, one branch, one pull request
  • > Per-dispatch git worktrees and session tracking, so concurrent operators never share a checkout
  • > File-based agent memory and a corrections record, both carried forward into later dispatches
  • > Internal deploy — no public domain
----------------------------------------------------------------------------------------

> screens

NAICOM sessions view: a counter strip of lifetime dispatches, sessions running now and 24-hour succeeded, no-op and failed counts; a running-now panel listing code, research and QA sessions against issue keys; a 90-day activity heatmap; and a recent-sessions table with status, role, issue, project, start time, duration and interface.
sessions · every operator run is a row: role, issue, project, start, duration, interface · demo instance
Provenance timeline for one ticket. Rows alternate between session entries, with role, interface, close time and the path of the committed session log, and dispatch entries, with a SUCCEEDED or NO-OP verdict, the dispatch number, role and attempt.
one ticket’s provenance timeline · sessions carry their committed log, dispatches their verdict · demo instance
NAICOM corrections view: a counter strip of corrections recorded, classes, this week, rising classes and repeats, above a table listing each correction class with its count in each of the last two weeks, a total, a signed delta and a repeat count.
the corrections record · mistakes counted by class and week, with the classes getting worse called out · demo instance

> what it does

NAICOM is the dispatcher that turns a tracked ticket into a reviewed pull request. A Rust daemon polls the issue tracker on a loop. When a ticket lands in a state that means work is approved, the daemon spawns a Claude Code operator for the role that state implies — product spec, implementation, architecture review, QA — hands it the ticket as its contract, and records everything it does.

Every dispatch gets its own git worktree and its own branch, so a dozen operators can run at once without sharing a checkout. Each one finishes the same way: a session log committed alongside the code, a pull request opened against the default branch, and a comment back on the ticket saying what shipped and what was verified. Nothing merges on an operator’s own say-so — the pull request still needs a human approval.

> what’s inside

  • >A dispatcher daemon with a REST API, plus a CLI for dispatch, session and memory operations.
  • >Ticket-state routing: one workflow state per operator role, one branch and one pull request per dispatch.
  • >Per-dispatch git worktrees and session tracking, so concurrent operators never collide.
  • >File-based agent memory and a corrections record, both replayed into later dispatches.
  • >A SvelteKit console over Postgres for reading dispatch history, session logs and the corrections record.

> why it exists

An agent that writes code is cheap. An agent whose work can be audited afterwards is not. NAICOM exists for the second half: the branch name, the session log, the pull request and the ticket comment are all written by the same run, and they are the record. Most of this deck — including the site you are reading — is built through it.

Internal deploy — no public domain.

----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
A BMRL Project
27cfd74b0a14e7d4f327a9de26d0e8cc
[0] bmrl* "~/changelog" 0000-00-00 00:00Z