Algis DumbrisandClaude Opus 4.6
04e4e3ca37
Adds everything needed to run a real multi-Gemini-model reactive agent
loop end-to-end on SynapBus.
internal/harness/subprocess/config.go:
* AgentConfig.GeminiMD — content of workdir/GEMINI.md
* MaterialiseAgentConfig writes GEMINI.md AND workdir/.gemini/settings.json
when gemini_md is set. The settings file carries the same mcp_servers
list as .mcp.json (so a Gemini child running from the workdir gets
the exact MCP surface the operator configured, not the user's
~/.gemini/settings.json).
* 2 new config_test cases: GEMINI.md + .gemini/settings.json round
trip, GEMINI.md with empty mcp_servers still writes the settings
file (explicitly clearing any inherited home config).
internal/harness/registry.go — BUG FIX:
Resolve() now honours agent.HarnessName (explicit selection) BEFORE
the inference chain, matching the reactor's own agentBackendKind
policy. Previously, when multiple backends were registered,
Resolve would pick "webhook" for every non-K8s agent — even when the
agent's HarnessName was "subprocess" — because the original fallback
chain put webhook first. This is why the first cold-topic-explainer
run failed with "webhook: agent has no webhook config". Discovered
during e2e testing.
internal/admin/socket.go + cmd/synapbus/admin.go:
New `messages.send` admin command (socket + CLI). Sends a DM as any
agent through the messaging service, bypassing the REST/MCP auth
layers. Local-only via the admin Unix socket, so the threat model is
"whoever can reach the socket is already admin".
CLI:
synapbus messages send --from X --to Y --body "..." [--priority N]
synapbus messages send --from X --to Y --body-file path
echo "..." | synapbus messages send --from X --to Y
Used by the harness shell wrappers (so Gemini subprocess agents can
DM each other) and by run_task.sh (to kick off a chain as a human
user without implementing the REST session flow).
examples/cold-topic-explainer/ (NEW):
Runnable 3-agent Gemini demo that exercises the subprocess harness,
reactive triggers, recursive update, and all the preconditions (depth,
budget, cooldown) end-to-end on a separate isolated synapbus instance.
Layout:
README.md — usage + troubleshooting + cost notes
start.sh — builds synapbus, launches on port 18088 with
./data, creates user + agents + harness configs,
marks agents reactive via sqlite3
run_task.sh — sends initial DM algis → decomposer-pro, polls
reactive_runs + messages for the FINAL: reply,
prints the result or dumps reactive_runs on
timeout for debugging
stop.sh — SIGTERM + 5s grace + SIGKILL fallback
wrapper.sh — shared subprocess local_command: reads
message.json + GEMINI.md, calls gemini headless
with --approval-mode yolo, strips the
"MCP issues detected" noise prefix, routes the
cleaned response to the next agent via
`synapbus messages send` over the admin socket
configs/
decomposer-pro.json — gemini-3.1-pro-preview
(gemini-2.5-pro is currently capacity-
exhausted on Google's side)
writer-flash.json — gemini-2.5-flash
critic-lite.json — gemini-2.5-flash-lite
.gitignore — data/, bin/, synapbus.log, .synapbus.pid
The wrapper does NOT rely on gemini's MCP tool-calling (which was
unreliable in testing). Gemini is used as a pure text generator; the
shell decides routing based on AGENT_ROLE:
- decomposer → NEXT_AGENT (writer)
- writer → NEXT_AGENT (critic)
- critic → OWNER_AGENT if response starts with FINAL:,
REVISE_AGENT otherwise
E2E VERIFICATION (real run, real Gemini, not a mock):
Topic: "how does SynapBus unify message delivery, reactive agent
triggers, and harness runs on a single SQLite database?"
Result (from data/synapbus.db after one successful run):
harness_runs:
#1 decomposer-pro subprocess success 106s
#2 writer-flash subprocess success 155s
#3 critic-lite subprocess success 10s
reactive_runs: 3 rows, all succeeded, trigger_from chain:
algis → decomposer-pro → writer-flash → critic-lite
messages:
#1 algis → decomposer-pro (topic)
#2 decomposer-pro → writer-flash (Q1/Q2/Q3 breakdown)
#3 writer-flash → critic-lite (3-paragraph draft)
#4 critic-lite → algis (FINAL: + polished 3-paragraph explainer)
Critic converged in one pass (all scores ≥ 8), so the writer↔critic
refinement loop didn't need to recurse — but the plumbing for it
(REVISE: branch in wrapper.sh, depth limit in reactor) is wired and
ready. Flipping the critic's acceptance bar exercises the recursion.
Full `go test ./...` remained green through all changes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
81 lines
2.5 KiB
Bash
Executable File
81 lines
2.5 KiB
Bash
Executable File
#!/bin/bash
|
|
# run_task.sh — kick off a cold-topic-explainer run and wait for the final.
|
|
#
|
|
# Usage: ./run_task.sh "topic describing what to explain"
|
|
#
|
|
# Sends the initial DM from algis → decomposer-pro via the admin
|
|
# socket, then polls for a DM to algis whose body starts with "FINAL:".
|
|
|
|
set -euo pipefail
|
|
|
|
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
DATA_DIR="$SCRIPT_DIR/data"
|
|
BIN="$SCRIPT_DIR/bin/synapbus"
|
|
SOCKET="$DATA_DIR/synapbus.sock"
|
|
|
|
TOPIC="${1:-how does the SynapBus reactor coalesce bursts of DMs into one follow-up run via the pending_work flag?}"
|
|
TIMEOUT_SEC="${TIMEOUT:-240}"
|
|
POLL_INTERVAL_SEC=2
|
|
|
|
if [ ! -S "$SOCKET" ]; then
|
|
echo "admin socket $SOCKET not found — run ./start.sh first" >&2
|
|
exit 1
|
|
fi
|
|
|
|
say() { printf '\033[1;35m[task]\033[0m %s\n' "$*"; }
|
|
|
|
say "topic: $TOPIC"
|
|
say "kicking off via: algis → decomposer-pro"
|
|
|
|
printf '%s' "$TOPIC" | "$BIN" --socket "$SOCKET" messages send \
|
|
--from algis \
|
|
--to decomposer-pro \
|
|
--priority 7 \
|
|
--body-file /dev/stdin \
|
|
>/dev/null
|
|
|
|
say "waiting up to ${TIMEOUT_SEC}s for FINAL: DM to algis ..."
|
|
|
|
deadline=$(( $(date +%s) + TIMEOUT_SEC ))
|
|
while [ $(date +%s) -lt "$deadline" ]; do
|
|
# Query the DB directly — fast and avoids re-auth churn.
|
|
final=$(sqlite3 -separator '|' "$DATA_DIR/synapbus.db" "
|
|
SELECT id, body FROM messages
|
|
WHERE to_agent='algis'
|
|
AND from_agent='critic-lite'
|
|
AND body LIKE 'FINAL:%'
|
|
ORDER BY id DESC LIMIT 1;
|
|
" 2>/dev/null || true)
|
|
|
|
if [ -n "$final" ]; then
|
|
id=$(printf '%s' "$final" | cut -d'|' -f1)
|
|
body=$(printf '%s' "$final" | cut -d'|' -f2-)
|
|
say "FINAL arrived (message #$id)"
|
|
echo
|
|
printf '%s\n' "$body"
|
|
echo
|
|
say "success"
|
|
exit 0
|
|
fi
|
|
|
|
# Show a brief status line while we wait.
|
|
running=$(sqlite3 "$DATA_DIR/synapbus.db" "
|
|
SELECT agent_name FROM reactive_runs WHERE status='running';
|
|
" 2>/dev/null | tr '\n' ',' | sed 's/,$//')
|
|
done_count=$(sqlite3 "$DATA_DIR/synapbus.db" "
|
|
SELECT COUNT(*) FROM reactive_runs
|
|
WHERE status IN ('succeeded','failed');
|
|
" 2>/dev/null || echo 0)
|
|
printf '\r running=[%s] done=%s ' "$running" "$done_count"
|
|
|
|
sleep "$POLL_INTERVAL_SEC"
|
|
done
|
|
|
|
echo
|
|
say "timed out — dumping recent reactive_runs for debugging:"
|
|
sqlite3 -header -column "$DATA_DIR/synapbus.db" "
|
|
SELECT id, agent_name, trigger_from, status, error_log
|
|
FROM reactive_runs ORDER BY id DESC LIMIT 20;
|
|
"
|
|
exit 2
|