fleetd/docs/CB-402-OpenCode-Adapter.md

CB-402 — Second peer adapter: opencode (Stage B of the Peer Launcher SPI)

Status: ✅ implemented and merged (ded226a) — increments 1–4 of §4 all landed (HerdrPeerLauncher base, kind: discriminator, OpenCodeLauncher, CompositePeerLauncher). ⚠️ Increment 5 — the live dogfood (§5) — has NOT run. It was deferred at merge time pending a daemon restart and a resolved provider, and §7 Q1 (which provider this host has credentials for) is still open; opencode is not installed on the dev host. Gitea issue #7 stays open until the §5 checklist is executed. This is the single known-unverified item going into the cross-host stage. Depends on: CB-401 Stage A (PeerLauncher SPI, merged 3aa69a9) Stage: 4 (Pluggable peers) · Stage B Owner action: design-note → file issue → delegate → primary-verify (per CB-401/306/307)

---

1. Goal

Prove the PeerLauncher SPI actually holds for a non-Claude coding agent by shipping a second, first-class in-tree adapter: opencode (opencode 1.1.31, a provider-agnostic terminal coding agent).

The product direction is heterogeneous coding agents, Claude Code first-class — not a human/mock peer. opencode is the right proof precisely because it differs from Claude Code on every seam the SPI is meant to hide:

Seam	Claude Code	opencode	⇒ SPI proof
Subscription boundary	ANTHROPIC_BASE_URL + SubscriptionGuard.assertWorker() before any herdr call	none — provider-agnostic, off-subscription by nature	the guard is Claude-private, not core
MCP mount	inline --mcp-config '{…}' launch flag	opencode mcp add / config file (OPENCODE_CONFIG) — no inline flag	"mount the bridge MCP" is adapter-private
Instruction injection	--append-system-prompt "<REPLY_CHARTER>"	config instructions / AGENTS.md / --agent — no append flag	the reply-charter mount is adapter-private
Model selection	ANTHROPIC_MODEL env	-m provider/model flag	env-vs-flag is adapter-private
Name / reap scheme	claude-<profile>-<nonce>-<seq>	opencode-<profile>-<nonce>-<seq>	each adapter reaps only its own kind

Everything else — herdr tab/pane placement, the CB-306 spawn-readiness gate, CB-301-ext worktree provisioning, CB-117 orphan reap, teardown, list(), cwd resolution — is transport machinery that is identical for both. That split is the whole design.

Out of scope (deferred to Stage C / later): dynamic external plugin loading behind a trust/capability model, capability enforcement at the verb layer (Stage A only declares caps), and a human/mock peer.

---

2. Current state — one launcher, two concerns mixed

ClaudeCodeLauncher (584 LOC) is the sole PeerLauncher. It interleaves two concerns:

flowchart TB
    subgraph CCL["ClaudeCodeLauncher (584 LOC) — today"]
        direction TB
        T["herdr transport (GENERIC / reusable)<br/>tab-pane placement · spawn-ready gate · worktree<br/>orphan reap · teardown · list · cwd resolution · unique naming"]
        C["Claude-specific (per-agent)<br/>ANTHROPIC_BASE_URL + SubscriptionGuard · ANTHROPIC_MODEL<br/>argv --mcp-config · --append-system-prompt REPLY_CHARTER · 'claude-' name prefix"]
    end
    classDef generic fill:#2f855a,stroke:#22543d,color:#ffffff;
    classDef specific fill:#b7791f,stroke:#7b341e,color:#ffffff;
    class T generic
    class C specific

Figure 1 — the two concerns tangled inside today's single launcher; CB-402 splits them.

There is also a Stage-A deferral to finish: Bridged.main still casts (ClaudeCodeLauncher) workers at the BridgeMcp and BridgedApp constructors. Those two callers only invoke profiles(), defaultProfile(), and list() — all already on the PeerLauncher interface. The cast survives for one reason only: PeerLauncher.list() returns List<?> (element type erased) while the callers use Agent element methods in their roster join. Finishing the migration is therefore small and contained (§4.D).

---

3. Target design

Template-Method base + two thin adapters + a routing composite that keeps the Stage-A seam (one PeerLauncher reference held by SessionManager / BridgeMcp / BridgedApp) intact.

flowchart TB
    IFACE["«interface»<br/>PeerLauncher"]
    COMP["CompositePeerLauncher<br/>routes by profile kind; fans out list/reap/caps"]
    BASE["«abstract»<br/>HerdrPeerLauncher<br/>transport: placement · ready-gate · reap · stop · cwd · naming"]
    CCL2["ClaudeCodeLauncher<br/>hooks: guard+ANTHROPIC_* env · --mcp-config · charter flag · prefix 'claude'"]
    OCL["OpenCodeLauncher<br/>hooks: provider env · OPENCODE_CONFIG file · AGENTS charter · prefix 'opencode'"]

    IFACE -.implemented by.-> COMP
    IFACE -.implemented by.-> BASE
    BASE --> CCL2
    BASE --> OCL
    COMP -->|"kind=claude-code"| CCL2
    COMP -->|"kind=opencode"| OCL

    classDef iface fill:#2b6cb0,stroke:#1a365d,color:#ffffff;
    classDef base fill:#2f855a,stroke:#22543d,color:#ffffff;
    classDef leaf fill:#6b46c1,stroke:#44337a,color:#ffffff;
    class IFACE,COMP iface
    class BASE base
    class CCL2,OCL leaf

Figure 2 — extracted base, two adapters, and a routing composite behind the unchanged SPI.

A. Extract HerdrPeerLauncher (abstract base)

Move all transport machinery down from ClaudeCodeLauncher. What stays generic:

• fields agents, spaces, profiles, defaultProfile, env, nameSeq, the CB-306 gate knobs (spawnReadyTimeoutMs/spawnReadyPollMs/nowMillis/sleeper), and nameNonce;
• profiles(), defaultProfile(), parityOverlay(), effectiveCwd(…), resolveCwd;
• the spawn(SpawnRequest) skeleton: resolve profile → cfg → hook → placement → gate → WorkerHandle;
• spawnInTab / spawnAsPane / tidy / startUniquelyNamed (name built from a hook prefix);
• list(), reapOrphanWorkers() / isForeignWorker / workerNonce (pattern built from the prefix hook), stop() / usesTabPlacement / isAlreadyGone;
• waitUntilInjectableOrThrow, the WorkerHandle record, putIfPresent, resolveEnv, sleepUninterruptibly.

Two adapter hooks (abstract):

/** Label prefix for this peer kind; drives unique naming AND the orphan-reap pattern. */
protected abstract String namePrefix();               // "claude" | "opencode"

/** Build the peer-specific launch: env map + argv. Runs any pre-spawn guard here. */
protected abstract Launch buildLaunch(BridgedConfig.Worker cfg, SpawnRequest req);
record Launch(Map<String,String> env, List<String> argv) {}

capabilities() stays abstract/per-adapter (it already is). The subscription guard is not a base field — it is a constructor dependency of ClaudeCodeLauncher alone.

Reap isolation: the reap pattern becomes Pattern.compile(namePrefix() + "-.*-([0-9a-f]{6})-\\d+"), so the opencode adapter never reaps a claude-* pane and vice-versa. The composite sums both.

B. kind: config discriminator

Add one field to BridgedConfig.Worker:

String kind          // "claude-code" (default) | "opencode"

• Compact-ctor default: kind = blank ? "claude-code" : kind.toLowerCase().
• argv default is currently List.of("claude"); when kind=opencode and the operator left argv unset, default it to List.of("opencode"). (Handle in normalization, keyed off kind, so the record stays declarative.)
• Keep the existing back-compat constructors; kind is additive and optional.

bridged.example.yaml documents a two-kind workers: block.

C. OpenCodeLauncher — the adapter hooks for opencode

namePrefix() → "opencode". buildLaunch(cfg, req):

• Env: no ANTHROPIC_BASE_URL, no SubscriptionGuard call. Pass through provider credentials the operator names (reuse the existing tokenEnv indirection; opencode reads provider keys from env / opencode auth). CB-302 git-token injection is reused unchanged (it is peer-neutral: GITEA_TOKEN/GITEA_HOST).
• MCP mount (non-invasive): opencode has no inline --mcp-config. The adapter writes a throwaway config file and points OPENCODE_CONFIG=<tempfile> in the worker env, containing the bridge MCP server block (opencode HTTP MCP schema, type: "remote") — the opencode analog of Claude Code's inline flag. Nothing is written into the worker's real project or profile.
• Reply-charter: carry REPLY_CHARTER as an instructions entry in that same generated config (or an AGENTS.md written into the per-worker worktree, which is already a throwaway isolated checkout under CB-301-ext). Recommend the config-file route to keep the "touch nothing the user owns" invariant.
• argv: opencode <project-or-cwd> (interactive TUI, the mode a herdr pane drives), plus -m <provider/model> when the profile sets a model.

REPLY_CHARTER is peer-neutral text — hoist it to a shared constant (base or a small PeerCharter), consumed by each adapter through its own injection mechanism.

D. CompositePeerLauncher + finish the Stage-A migration

• Bridged.main groups configured profiles by kind, instantiates one launcher per kind present, and wraps them in CompositePeerLauncher implements PeerLauncher.
• Routing methods (spawn(req), effectiveCwd(req), parityOverlay(name)) dispatch by the profile's kind. Fan-out methods (list(), reapOrphanWorkers(), capabilities(), profiles(), defaultProfile()) merge across sub-launchers. stop(id) tries each (teardown only knows the pane id) — already best-effort/idempotent.
• Migrate BridgeMcp + BridgedApp to the PeerLauncher interface, dropping both (ClaudeCodeLauncher) casts. Only friction is list()'s List<?>; resolve by giving the SPI a typed roster element (small neutral PeerAgent view exposing id()/name()/status) that the CB-304 roster join consumes — or, minimally, narrow at the callsite. Prefer the typed view.

sequenceDiagram
    autonumber
    participant P as Primary
    participant M as BridgeMcp / REST
    participant C as CompositePeerLauncher
    participant O as OpenCodeLauncher
    participant B as HerdrPeerLauncher (base)
    participant H as herdr
    P->>M: bridge_spawn(profile="oc-impl")
    M->>C: spawn(SpawnRequest)
    C->>C: kind(profile)=="opencode"
    C->>O: spawn(req)
    O->>O: buildLaunch → provider env + OPENCODE_CONFIG file + argv
    O->>B: placement + startUniquelyNamed("opencode-…")
    B->>H: agent.start(name, argv, env, tab, cwd)
    B->>H: poll status until injectable (CB-306 gate)
    B-->>O: Agent
    O-->>C: PeerHandle(paneId, terminalId)
    C-->>M: PeerHandle
    M-->>P: session id

Figure 3 — an opencode spawn: composite routes by kind, adapter builds the peer-specific launch, shared base drives herdr + the readiness gate.

---

4. Increment plan (delegate-then-verify friendly)

1. Extract base, no behaviour change. Introduce HerdrPeerLauncher; make ClaudeCodeLauncher extend it with namePrefix()="claude" and buildLaunch() wrapping today's guard+env+argv logic. Green build, identical tests — pure refactor. (IDE refactor where possible; the primary re-runs the gate workers can't.)
2. kind: discriminator. Add the field + normalization + bridged.example.yaml. Default path unchanged (kind=claude-code).
3. OpenCodeLauncher. Implement the three hooks; unit-test buildLaunch (env has no ANTHROPIC_BASE_URL; OPENCODE_CONFIG points at a file carrying the bridge MCP block + charter; argv shape).
4. CompositePeerLauncher + wiring + finish Stage-A migration (drop the two casts).
5. Live dogfood (§5) + wiki as-built (primary-gated submodule commit).

Each increment is independently buildable/mergeable; the feature branch stays unmerged until it is "major" (Stage-B whole), per the CB-401 bar.

---

5. Risks & validation (live dogfood, not assumed)

• opencode TUI ⇄ herdr injection. herdr drives a pane by typing into a TUI. Must confirm opencode's TUI accepts injected keystrokes/submit the way claude does, and reaches an injectable status the CB-306 gate recognizes. Validation: spawn one opencode worker, watch the readiness gate pass, bridge_send a trivial task.
• Bridge MCP visibility in opencode. Confirm OPENCODE_CONFIG (or opencode mcp add) actually surfaces the bridge_* tools inside the opencode session, and that bridge_reply is callable — the reply-charter is worthless if the tool isn't mounted. Validation: the worker completes a task by calling bridge_reply; the reply lands via the CB-307 path.
• opencode MCP/config schema drift. opencode is fast-moving (1.1.31 today). Pin the config schema we generate against the installed version; treat the exact keys (type: "remote" vs "http", instructions shape) as a dogfood-verified fact, not an assumption.
• Provider credentials. opencode needs a configured provider (env key or opencode auth). The dogfood profile must name a provider the host actually has, distinct from the primary's subscription.

---

6. Test plan

• Unit (hermetic): base-extraction regression (existing ClaudeCodeLauncher tests pass unchanged); OpenCodeLauncher.buildLaunch env/argv/config assertions; kind normalization in BridgedConfigTest; CompositePeerLauncher routing + fan-out (merge of profiles(), summed reapOrphanWorkers(), per-kind reap isolation) with fake sub-launchers.
• Live (dogfood, manual): the §5 checklist on the running daemon.
• Gate (primary): IDE diagnostics 0/0 on every changed file, mvn clean install green with the surefire summary captured (not | tail), manual diff review — the authoritative checks a worker cannot self-run.

---

7. Open questions for the lead

1. Provider for the opencode dogfood profile — which provider/model does this host have credentials for that is distinct from the primary's subscription?
2. Charter carrier — generated OPENCODE_CONFIG instructions (recommended) vs an AGENTS.md in the worktree?
3. Merge cadence — hold the whole Stage B on a feature branch to merge as one "major" unit (per CB-401), or land the behaviour-preserving base-extraction (increment 1) to main first to shrink the branch?