CB-530..536, CB-538 groundwork: leads as peers, and a fleet that can find itself

Two leads now work as peers rather than one primary plus workers. The arc: CB-530/531 lead identity: `leaders:` names panes, `leadScan:` discovers them by tab label (LeadTabScanner, TTL-cached, worker spaces excluded). CB-532 leads can message each other AND be answered. Principal.leader now carries its terminal, so ownsSession() can be true for a lead; the "and you must be a worker" conjunct beside it protected nothing. Retires `primary:` — reply nudges follow the delegating lead, a binding recorded at bridge_send where both halves are known. CB-533 ClaudeCodeLauncher passes --model. argv is usually a wrapper (`ccs <profile>`) that re-exports its own model family, so ANTHROPIC_MODEL alone was silently overruled. CB-534 a lead is deliverable. The CB-113 readiness gate only opened for terminals in WorkerPresence, which only workers ever enter, so every lead->lead send waited out the ~60s grace and failed having never been typed. The gate guards a *spawned* peer's boot window; a lead is never spawned. CB-535 bridge_list returns `leads` alongside `workers`, with `self` on the caller's row. An empty worker roster no longer reads as "no peers". CB-536 CLAUDE.md: lead<->lead is coordinate-only, never sideways delegation. Propagated byte-identically to wiki/7-Use-Cases.md. MIXED PROVENANCE — recorded deliberately rather than hidden. This tree also carries in-progress CB-537 (context separation) authored by the peer lead gpt-sol-5.6 and its worker: Capability.CONTEXT_RESET, SessionManager.clearAfterTurn, and the Injector/TurnListener/CompletionResolver/launcher changes around it. That work was done in this shared working tree rather than a worktree, and is entangled with the above in BridgedConfig.java, Bridged.java and ClaudeCodeLauncher.java, so neither lead could stage its own half without sweeping in the other's. Committing the whole green state is the honest resolution; the peer branches from here. Note for whoever picks CB-537 up: the design in this commit is SUPERSEDED. Both leads agreed to replace the global `clearAfterTurn` boolean with per-delivery policy (inherit|fresh|thread) applied PRE-delivery, because a post-turn reset races by construction — Injector.onStatus clears awaitingCompletion and dequeues the next message in the same tick. `fresh` is also a correctness guarantee, so an adapter without a reset capability must refuse it rather than log a no-op. mvn clean install: Tests run: 464, Failures: 0, Errors: 0, Skipped: 0. BUILD SUCCESS.
2026-08-13 09:38:24 +02:00
parent ef1e014b41
commit bc13b8e92c
34 changed files with 2350 additions and 115 deletions
@@ -4,6 +4,7 @@ import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;

 import java.util.Optional;
+import java.util.concurrent.ConcurrentHashMap;
 import java.util.concurrent.atomic.AtomicReference;

 /**
@@ -25,6 +26,15 @@ public final class PrimaryRegistry {
    private final AtomicReference<String> terminal = new AtomicReference<>();
    private final boolean pinned;

+    /**
+     * CB-532: worker terminal → the lead that delegated to it. The single slot above answers "who is
+     * THE primary", a question with no correct answer once two leads orchestrate the same fleet:
+     * whichever called {@code bridge_send} first captured every nudge, including nudges for the
+     * other lead's delegations. This map answers the question that actually matters — "who is
+     * waiting on THIS worker" — and is what lets {@code primary.terminal} be retired.
+     */
+    private final ConcurrentHashMap<String, String> leadByTarget = new ConcurrentHashMap<>();
+
    /**
     * @param pinnedTerminal an optional pinned terminal from config ({@code null}/blank = unpinned)
     */
@@ -56,6 +66,43 @@ public final class PrimaryRegistry {
        }
    }

+    /**
+     * Record that {@code leadTerminal} delegated to worker {@code target} (CB-532).
+     *
+     * <p>Called at {@code bridge_send} time, where both halves are known: the target is the tool's
+     * argument and the lead is resolved from the connection. Last writer wins — if a second lead
+     * takes over a worker, replies follow the lead that most recently delegated to it, which is the
+     * one waiting.
+     */
+    public void recordDelegation(String target, String leadTerminal) {
+        if (target == null || target.isBlank() || leadTerminal == null || leadTerminal.isBlank()) {
+            return;
+        }
+        leadByTarget.put(target, leadTerminal);
+    }
+
+    /** Forget a worker's delegating lead — call on release, so a torn-down session leaks nothing. */
+    public void forgetDelegation(String target) {
+        if (target != null) {
+            leadByTarget.remove(target);
+        }
+    }
+
+    /**
+     * Where a nudge about {@code target}'s reply should go: the lead that delegated to it, falling
+     * back to the single known primary.
+     *
+     * <p>The fallback matters after a daemon restart, which loses the map while the durable inbox
+     * keeps the reply. With one lead the fallback is unambiguous and correct. With several and no
+     * recorded delegation there is no right answer, so this returns empty rather than guessing —
+     * delivery degrades to pull, which is exactly what the durable inbox is for, instead of
+     * interrupting the wrong lead with someone else's result.
+     */
+    public Optional<String> nudgeTargetFor(String target) {
+        String lead = target == null ? null : leadByTarget.get(target);
+        return lead != null ? Optional.of(lead) : Optional.ofNullable(terminal.get());
+    }
+
    /** The known primary terminal, or empty if not yet learned (and not pinned). */
    public Optional<String> primaryTerminal() {
        return Optional.ofNullable(terminal.get());