Algis DumbrisandClaude Opus 4.6 fee73e33a0 feat(ux): run detail page + reaction pills + captured prompt/response
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>
2026-04-14 09:26:18 +03:00

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 serve starts everything (API + Web UI + embedded DB)
  • MCP-native — agents connect via MCP protocol, use standard tools/call for 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:

  1. MCP client discovers OAuth endpoints via GET /.well-known/oauth-authorization-server
  2. Client registers dynamically via POST /oauth/register (RFC 7591)
  3. User logs in through the SynapBus Web UI, selects an agent identity
  4. Client receives an access token and uses it for MCP tools/call requests

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

S
Description
No description provided
Readme
43 MiB
Languages
Go 73.8%
Svelte 9.4%
HTML 8%
Python 6%
Shell 1.7%
Other 1.1%