Parent: autonomous-swarm. Depends on project-server (hosts it) and lead-authority
(who may direct). Replaces the plan to depend on the Go skein for any of this.

Why

The Go skein's useful ideas are mechanical, not LLM: a stage/gate graph with evidence, stall
rules, send-once nudges with backoff, claim reaping, a roster, a spawn path, a board. Its
failure was a resident process that owned its own agency and its own state. With a project
server that already owns every agent session, the same ideas fit as a module that reads
server state and the database and does five things only: send one message, write one
record, raise one pending decision, spawn or stop an agent, start or stop a loop. It never
runs a model turn of its own, and every judgement call goes to the lead.

What Changes (ideas absorbed from skein, by source)

The coordinator is a plain tick (default 30 s) that is idempotent and writes only through
the ledger, so it can run in whichever server instance holds the coordinator lease (database
row with TTL and heartbeat) and move on failure. With a shared project server there is
normally exactly one holder.

Trust and authority

The coordinator acts for the lead. It holds no authority of its own: the lead-authority
grant names it as a delegate with scope nudge (and spawn if the operator adds it).
Messages it sends carry the lead frame because the server attributes the sender, not because
the text says so. It cannot widen permissions or publish; standing-publish-authority's
merge driver is a separate, policy-gated action it may request but not perform.

Non-goals

• No LLM in the coordinator; no scope, plan or priority decisions.
• No replacement for the lead: "what to build next" is the lead's, from specs.
• No dependency on the Go skein. Interop with skein over A2A may remain, optional.

Risks

1. Rebuilding the resident-process failure. Mitigation: all coordinator state in the DB;
   lease-based; restart replays; negative-control soak asserts an idle coordinator writes
   nothing.
2. Nudge storms. Mitigation: dedupe key, budget, positive-control test.
3. Coordinator misreads a healthy long turn as stalled. Mitigation: per-gate StallAge
   thresholds and the roster's busy signal (exact, not windowed) gate every rule.

Impact

New coordinator/* (gates, rules, nudge, lease, tools), crew-loop board hooks,
session/peers.ts roster consumers, tool registry, TUI view, tests.

Design: swarm coordinator

D1. Shape

tick():                                  # idempotent, bounded, no model calls
  require lease(coordinator)             # DB row {holder, ttl, heartbeat}
  grant = lead.grant(); if none: record `no-lead` decision; pause nudging; return
  view  = roster() ⨝ claims ⨝ changes ⨝ gate evidence
  for cond in rules(view): act(cond)     # act ∈ {message once, write record,
                                         #        decision, spawn/stop agent, start/stop loop}

Everything it does is recorded in coordinator_ledger(key, at, action, outcome); a restart
rebuilds from the ledger and the DB.

D2. Rules (from skein D7, kept)

Dedupe (slug, agent, gate, reason); backoff tick×2^n; after 3, stop and escalate once.
"Send once" is a tested invariant with a positive control.

D3. Gates and evidence

Gate list and evidence kinds per proposal. coordinator/gates.ts is data, validated at load
(closed schema). complete for a change fails closed and returns the missing evidence: a
completion token alone is never sufficient. Optional gates (deploy, live-test) per project
config. Review evidence is .skein/review.json; merge evidence is the merge driver's record.

D4. Lead and delegation

The lead directs; the coordinator mechanises. A directive "take change X" becomes: claim X
for the target agent, start a queue loop for X on it (verified completion), expect an ack,
send nothing further until the budget says so. Completion arrives as the one notice from
loop-done-handoff.

D5. Tools for the lead

swarm_status (board, roster, claims, decisions), swarm_assign(agent, slug),
swarm_nudge(agent, text) (one message, deduped), swarm_stop(agent). All read the
server's state; none writes authority. Available to in-server sessions as tools; for a Claude
Code lead through a small MCP shim to the project server's HTTP API (spike 0.3).

D6. Why in the server, not a separate process

The server already owns sessions, loops, the roster, the inbox and the DB; the coordinator
needs exactly that and nothing else, so a second process would re-create the split state
that hurt before. It stays small and replaceable because its only inputs and outputs are the
DB and the server API.

D7. Standalone mode

Without a project server (standalone processes), the coordinator runs in whichever instance
holds the lease and reads the roster through the sidecar registry. Degraded: no headless
spawn, no in-process delivery. This is the migration path and keeps --standalone useful.