From 3941abcca88fd925a11b22a10cb2eecbd2fa5db1 Mon Sep 17 00:00:00 2001 From: dave Date: Sat, 4 Apr 2026 20:15:28 +0000 Subject: [PATCH] huskies: create 477_spike_distributed_build_agents_via_bft_crdts_over_websocket --- ...ike_distributed_build_agents_via_bft_crdts_over_websocket.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.huskies/work/1_backlog/477_spike_distributed_build_agents_via_bft_crdts_over_websocket.md b/.huskies/work/1_backlog/477_spike_distributed_build_agents_via_bft_crdts_over_websocket.md index bc14377d..bb168e1e 100644 --- a/.huskies/work/1_backlog/477_spike_distributed_build_agents_via_bft_crdts_over_websocket.md +++ b/.huskies/work/1_backlog/477_spike_distributed_build_agents_via_bft_crdts_over_websocket.md @@ -18,7 +18,7 @@ Story markdown files (content/AC), worktrees, and config files remain on the fil 1. **CRDT integration**: The BFT CRDT crate goes in `crates/`. How does the CRDT document schema map to the current pipeline state model (stages, agent assignments, retry counts, blocked flags)? The CRDT replaces `.huskies/work/` stage directories as the source of truth for pipeline state. -2. **Work claiming**: Two nodes see a story enter current simultaneously. Design a CRDT-native claim mechanism (e.g. node ID + timestamp in the CRDT doc) so exactly one node runs the coder. What happens on conflict? +2. **Work claiming**: Two nodes see a story enter current simultaneously. Each writes a claim (node ID) into the CRDT doc. The CRDT merges deterministically — one node wins, losing nodes see the merged state and kill their Claude Code process. Design the merge rule (lowest node ID? earliest timestamp?) and the "loser stops work" mechanism. Worst case: a few seconds of wasted API time on the losing node before merge propagates. 3. **WebSocket transport**: Each node runs `huskies` and connects to peers via WebSocket. Node discovery: static config (`peers = ["ws://laptop-2:3001"]`), mDNS, or rendezvous? What's simplest for a home LAN setup?