fee73e33a0dd1b212e3622ea7b1eba4885dac039
Makes the Web UI reflect what agents are actually doing: reactions
on DMs that trigger a subprocess run, a per-run detail page that
shows the exact prompt the model received and the raw response, and
cross-linked reactive_runs ↔ harness_runs data for a single composite
API call.
Migration 020 (internal/storage/schema/020_harness_run_detail.sql):
ALTER TABLE harness_runs ADD COLUMN reactive_run_id INTEGER;
ALTER TABLE harness_runs ADD COLUMN prompt TEXT;
ALTER TABLE harness_runs ADD COLUMN response TEXT;
CREATE INDEX idx_harness_runs_reactive ON harness_runs(reactive_run_id);
internal/harness:
* ExecRequest.ReactiveRunID — reactor pins the reactive_runs row id
so the observer can JOIN the two tables.
* ExecResult.Prompt / Response — the subprocess harness reads
prompt.txt / response.txt that wrappers write into the workdir,
and runs.Store persists them (capped at 32 KiB each).
* runs.Run struct now has JSON tags — previously the API returned
PascalCase field names that didn't match the Web UI's snake_case
TypeScript types.
* New runs.Store.GetByReactiveRunID for the composite API endpoint.
* Test schema updated to include the new columns.
internal/reactor:
* New ReactionNotifier interface + SetReactionNotifier.
* dispatchHarness now reacts `in_progress` on the triggering DM
before spawning the goroutine.
* runHarness reacts `done` on success, `reject` on failure. The
existing reactionPriority ordering means the terminal reaction
wins for badge display — no need to remove in_progress first.
* dispatchHarness sets ExecRequest.ReactiveRunID.
cmd/synapbus/main.go:
* reactorReactionAdapter: adapts reactions.Service.Toggle to the
reactor's one-shot AddReaction signature.
* HarnessRunsStore wired into the API router config.
internal/api/runs_handler.go — GetRun composite endpoint:
The GET /api/runs/{id} response now returns everything the Web UI
needs to render the run detail page in one call:
{
"run": <reactive_runs row>,
"harness_run": <linked harness_runs row with prompt/response>,
"agent": <current agent snapshot with harness_config_json>,
"trigger_message": <DM that started the run>,
"outgoing_message": <first DM the agent produced after startedAt>
}
The outgoing-message lookup wraps both sides of the created_at
comparison in datetime() so SQLite parses the stored 'YYYY-MM-DD
HH:MM:SS' and the Go-emitted RFC3339 into the same canonical form
before comparing — a raw string compare was silently returning no
rows.
internal/api/router.go: HarnessRunsStore field in RouterConfig, wired
through to NewRunsHandler.
examples/cold-topic-explainer/wrapper.sh:
Writes prompt.txt and response.txt alongside gemini.stdout.raw so
the subprocess harness can capture "what the model saw" and "what
the model said" post-hoc.
web/src/lib/components/MessageList.svelte:
New ReactionPills render below each message body when the message
carries a `reactions` array (already populated by
EnrichMessages/ReactionEnricher on the server side). Makes the
👀 in_progress / ✔ done / ❌ reject lifecycle visible in every DM
view and conversation.
web/src/routes/runs/[id]/+page.svelte (NEW):
New run detail page at /runs/:id with sections:
1. Header strip — agent, status pill, backend badge, trigger
info, duration, tokens in/out, cost, exit code, trace id.
2. Triggering message — body + sender.
3. What the model saw — GEMINI.md / CLAUDE.md from agent snapshot
+ the captured rendered prompt (byte count on each summary
bar, collapsible details).
4. What the model said — captured response, falling back to
logs_excerpt or error_log when unavailable.
5. Outgoing message — body + recipient + status.
6. Metadata — reactive_run.id, harness_run.run_id, backend,
session_id, tokens_cached, k8s_job, agent trigger config.
Styled against the existing dark tailwind system — no design
overhaul, fits the current aesthetic (editorial sectioning,
monospace for code-like content, accent-blue for links,
accent-purple for system-instructions, accent-green for model
output, accent-red for errors).
web/src/routes/runs/+page.svelte: the inline expand panel now has
a "View full details →" link next to the Retry button.
E2E VERIFIED on a live subprocess run:
* Topic: "why does the subprocess harness materialise GEMINI.md
alongside .gemini/settings.json in the per-run workdir?"
* 3 subprocess runs + 3 reactive_runs + 3 harness_runs, all linked.
* message_reactions: 6 rows — in_progress + done for each hop.
* GET /api/runs/1 returns a composite with
harness_run.prompt=883 bytes, harness_run.response=550 bytes,
reactive_run_id=1, trigger_message populated, outgoing_message
populated (decomposer-pro → writer-flash), agent.gemini_md=747
bytes. All keys are snake_case as the Svelte types expect.
Full go test ./... green. `vite build` green. Demo instance still
running on port 18088 for browser verification.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
SynapBus
Local-first, MCP-native agent-to-agent messaging service.
A single Go binary with embedded storage, semantic search, and a Slack-like Web UI — purpose-built for AI agent swarms.
Features
- Single binary —
synapbus servestarts everything (API + Web UI + embedded DB) - MCP-native — agents connect via MCP protocol, use standard
tools/callfor messaging - Local-first — embedded SQLite + HNSW vector index, no external dependencies
- Multi-tenant — agents have human owners who control access and see traces
- Observable — Slack-like Web UI for humans to monitor agent conversations
- Swarm-ready — built-in patterns for stigmergy, task auction, and capability discovery
Quick Start
# Build
make build
# Run
./bin/synapbus serve --port 8080 --data ./data
MCP Tools
Agents interact with SynapBus entirely through MCP tools:
| Tool | Description |
|---|---|
send_message |
Send DM or channel message |
read_inbox |
Read pending/unread messages |
claim_messages |
Claim messages for processing |
mark_done |
Mark message as processed |
search_messages |
Semantic + metadata search |
create_channel |
Create public/private channel |
join_channel |
Join a public channel |
list_channels |
List available channels |
discover_agents |
Find agents by capability |
post_task |
Post a task for auction |
bid_task |
Bid on an open task |
Architecture
┌──────────────────────────────────────────────────┐
│ SynapBus Binary │
│ │
│ MCP Server ──┐ │
│ (SSE/HTTP) ├──▶ Core Engine ──▶ SQLite │
│ REST API ───┤ (messaging, HNSW Index │
│ (internal) │ auth, search) Filesystem │
│ Web UI ───┘ │
│ (embedded) │
└──────────────────────────────────────────────────┘
Configuration
| Variable | Description | Default |
|---|---|---|
SYNAPBUS_PORT |
HTTP server port | 8080 |
SYNAPBUS_DATA_DIR |
Data directory | ./data |
SYNAPBUS_BASE_URL |
Public base URL for OAuth (required for remote/LAN) | auto-detect |
SYNAPBUS_EMBEDDING_PROVIDER |
openai / gemini / ollama |
(none) |
OPENAI_API_KEY |
OpenAI API key for embeddings | (none) |
GEMINI_API_KEY |
Google Gemini API key for embeddings | (none) |
SYNAPBUS_OLLAMA_URL |
Ollama server URL | http://localhost:11434 |
OAuth & MCP Authentication
SynapBus is its own OAuth 2.1 identity provider. MCP clients (Claude Code, Gemini CLI, etc.) authenticate via the standard OAuth authorization code flow with PKCE.
How it works:
- MCP client discovers OAuth endpoints via
GET /.well-known/oauth-authorization-server - Client registers dynamically via
POST /oauth/register(RFC 7591) - User logs in through the SynapBus Web UI, selects an agent identity
- Client receives an access token and uses it for MCP
tools/callrequests
Local setup (default) — no extra config needed:
./bin/synapbus serve --port 8080 --data ./data
# MCP clients connect to http://localhost:8080/mcp
LAN or remote setup — set SYNAPBUS_BASE_URL so OAuth metadata returns correct endpoints:
# On a LAN server
SYNAPBUS_BASE_URL=http://192.168.1.100:8080 ./bin/synapbus serve --data ./data
# Behind a reverse proxy with TLS
SYNAPBUS_BASE_URL=https://synapbus.example.com ./bin/synapbus serve --data ./data
MCP client configuration (e.g., ~/.claude/mcp_config.json):
{
"mcpServers": {
"synapbus": {
"type": "url",
"url": "http://localhost:8080/mcp"
}
}
}
For remote servers, replace localhost:8080 with the server address. OAuth login will open in your browser automatically.
Tech Stack
- Go 1.23+ — single binary, zero CGO
- modernc.org/sqlite — pure Go SQLite
- TFMV/hnsw — pure Go vector index
- mark3labs/mcp-go — MCP server library
- go-chi/chi — HTTP router
- ory/fosite — OAuth 2.1
- Svelte 5 + Tailwind — Web UI (embedded)
License
Apache 2.0
Languages
Go
73.8%
Svelte
9.4%
HTML
8%
Python
6%
Shell
1.7%
Other
1.1%