Shared REPL as Gossip Protocol: Multi-Machine Agentic Development

A persistent Clojure nREPL server, bound to 0.0.0.0 on a LAN host, becomes a shared evaluation context for multiple participants: human operators (via Emacs/CIDER), AI agents (via tmux send-keys into nREPL; the earlier emacsclient -e path is superseded, see 11), and monitoring systems (via health checks). The REPL holds loaded namespaces, bound vars, and cached data structures in memory. Participants read the same state without message passing.

This is not a distributed system in the Kleppmann sense. There is one JVM, one heap, one evaluation context. The "distribution" is in the access pattern: multiple machines reach the same REPL over the network. The durable state lives in git. The REPL is the ephemeral materialized view.

In gossip protocols, nodes converge on shared state by exchanging observations. Each node maintains a local view and periodically reconciles with peers. There is no central coordinator.

The nREPL model inverts this: one shared heap, multiple observers. But the access pattern resembles gossip in three ways:

1. Eventual consistency. When one participant loads a namespace, all subsequent participants see it. The convergence is immediate (shared heap) rather than eventual (network propagation), but the principle is the same: no participant needs to explicitly notify others.
2. No coordinator. There is no queue, no broker, no orchestrator deciding who evaluates what. Any participant can require a namespace, bind a var, or query data at any time. Conflicts are resolved by Clojure's concurrency primitives (atoms, refs) or by convention (last writer wins on def).
3. Crashing is safe. If a participant disconnects (laptop closes, agent session ends), the REPL state persists. The JVM holds the heap. Reconnecting picks up where the previous session left off. This is the "crashing is safe" property of gossip: partial failures don't corrupt shared state.

The analogy breaks down at durability: gossip protocols replicate state across nodes for fault tolerance. The nREPL model has a single point of failure (the JVM). Durability comes from git, not from replication.

                    ┌─────────────────────────────────┐
                    │     JVM (nexus:42527)            │
                    │     Clojure 1.12 + nREPL         │
                    │                                  │
                    │  loaded: wal-sh.site.logs         │
                    │          wal-sh.tools.transform   │
                    │          wal-sh.verify.chain      │
                    │          wal-sh.site.beads        │
                    │                                  │
                    │  bound:  entries, issues, drawers │
                    │                                  │
                    │  data:   .beads/issues.jsonl      │
                    │          .verify/chain.jsonl      │
                    │          logs/wal.sh/https/       │
                    └───┬──────────┬──────────┬────────┘
                        │          │          │
              ┌─────────┘    ┌─────┘    ┌─────┘
              │              │          │
   ┌──────────▼──┐  ┌───────▼────┐  ┌──▼──────────────┐
   │ nexus tmux  │  │ laptop     │  │ nexus            │
   │ shared      │  │ CIDER      │  │ Claude Code      │
   │ (Emacs)     │  │ (Emacs)    │  │ (tmux send-keys) │
   │             │  │            │  │ (emacsclient -e) │
   │ human       │  │ human      │  │ agent            │
   │ reviews     │  │ explores   │  │ audits           │
   └─────────────┘  └────────────┘  └──────────────────┘
              │              │          │
              └──────────────┴──────────┘
                        │
                    git push/pull
                        │
              ┌─────────▼─────────┐
              │   github.com      │
              │   (durable log)   │
              └───────────────────┘

All four roles share the same REPL heap. The operator and explorer are indistinguishable at the nREPL level: both are CIDER clients sending eval requests. The agent uses a lower-level interface (tmux into nREPL; emacsclient -e is superseded because queued calls wedge the Emacs daemon) but reaches the same nREPL. The monitor only checks liveness, not state.

The REPL heap is the shared memory. It holds:

The REPL heap is ephemeral. A JVM restart loses all loaded namespaces, bound vars, and cached data. Durability comes from git:

The Kleppmann pattern: git is the replicated log, the REPL is the local materialized view. Each machine checks out the log (git pull), materializes a view (require, def), and operates on the view. Writes go back through the log (git commit, git push).

The single-JVM model means failures are total (crash loses everything) or absent (the heap is consistent by construction). There are no partial failure modes, no split-brain, no quorum. This is a feature: the distributed systems problems are pushed to git, where they are well-understood.

Hydra monitors nexus nREPL via monit:

check host nexus-nrepl with address 192.168.86.100
  if failed port 42527 type tcp with timeout 5 seconds
    then alert

Future: eval-based health check that verifies namespace count and data freshness:

;; Health probe (speculative)
(let [nss (count (filter #(or (.startsWith (str %) "wal-sh")
                              (.startsWith (str %) "pocket-es"))
                         (map ns-name (all-ns))))]
  {:status (if (pos? nss) :ok :degraded)
   :namespaces nss
   :uptime-ms (- (System/currentTimeMillis) (.getStartTime (java.lang.management.ManagementFactory/getRuntimeMXBean)))})

The REPL is for asking questions you don't yet know to ask. Tests are where you put answers you've already found. The REPL comes first.

This means every namespace – including browser-side .core modules – should be explorable from the REPL. Even if global-pollution.core has no DOM to render into, calling (classify-pollution-type "ad-tag") interactively reveals edge cases the test suite hasn't imagined yet. The REPL is not a substitute for tests. Tests are a reification of what the REPL taught you.

This principle has consequences for the gossip model:

1. All 56 namespaces stay in the completion list. Don't filter "browser-only" modules out of the REPL. If someone wants to poke at the pure logic, that's valid exploration.
2. Zero-arg defaults are ergonomics, not convenience. If a function requires three args to call, it's hostile to exploration. The person at the REPL doesn't know the argument shape yet – that's why they're at the REPL.
3. The gossip value of the shared REPL is discovery, not coordination. When the agent loads wal-sh.site.beads and binds (def issues (beads/issues)), the human reconnecting later sees those issues already in the heap. They didn't ask for them. The REPL presented a question they didn't know to ask: "what's the current issue state?" That's gossip.
4. Cached atoms are shared observations. The defonce pattern (logs !entries, beads !issues, annotations !drawers) means each participant's exploration leaves a residue that the next participant inherits. The REPL accumulates knowledge across sessions. (reload!) is the explicit "I know the world changed, refresh my view."

Any datum reachable from the REPL is reachable from six interfaces. The access path varies; the answer does not.

Verified end-to-end with a sentinel test: one curl to production (/static/t.gif?e=js-error&msg=test-sentinel&token=Walsh-Research), then extracted via all six paths. Each returned the same record.

This structure is nearly universal. Any system with:

• a persistent evaluation context (REPL, database connection, shell session)
• a durable log (access log, git, append-only file)
• multiple interfaces to the evaluation context (CLI, editor, agent, API)

has the same six-path property. The REPL is the substrate that unifies them. grep and clj and CIDER and tmux are different lenses on the same heap. The question "did the sentinel land?" has one answer regardless of which lens you use to ask it.

The practical consequence: never build a dashboard when a REPL query will do. The dashboard freezes one question. The REPL lets you ask the next question you haven't thought of yet.

• (Kleppmann 2017) ch. 5-6: replication, partitioning, the log as shared state
• (Meadows 2008) "model utility depends on realistic behavior patterns"
• (Hickey 2014) the REPL as communication channel (implicit in the design)
• (Higginbotham 2015) ch. 1-4: interactive Clojure development
• (Miller, Halloway, and Bedra 2018) REPL-driven workflow, nREPL architecture

Point-in-time snapshot (2026-06-17). This mapping will evolve as the tooling matures.

The four representations of one fact:

1. Chat transcript (.beads/interactions.jsonl, Claude Code JSONL): the tool call happened, with input and output.
2. MCP trace (ProvenanceGuard schema, provenance.cljc): the tool output carries a source_id that links claim to source.
3. Org heading (property drawer on the heading): the claim is annotated with :VERIFIED_AT:, :VERIFIED_BY:, :VERDICT:, :SOURCE:. Human-readable, grep-able, git-tracked.
4. Verification ledger (.verify/chain.jsonl): append-only hash chain binding the change hash + verifier + verdict to the previous block. Tamper-evident.

These are not competing systems. They are four views of the same event at different abstraction levels. The REPL (wal-sh.site.provenance, wal-sh.site.chat, wal-sh.site.annotations, wal-sh.verify.chain) can query across all four and cross-reference them.