Files

T

Dai Ha 2e138a199b CB-634: one shared "fleet" workspace + rename bridged -> fleetd cutover

Two changes ship together here.

1. One shared herdr workspace. The lead and every worker now live in one
   workspace called "fleet", so the operator sees one "session" with many
   windows, not two. Before, the lead sat in a "leads" workspace and workers
   in "bridged-workers", which read as two sessions. The lead is still told
   apart from workers by its exact tab label ("lead: <name>"), so putting them
   in one space is safe. LeadTabScanner keeps the exclude-by-label mechanism
   for split layouts; Fleetd now passes an empty exclude set.

2. Rename the daemon from "bridged" to "fleetd" (the binary, config, scripts,
   launchd/systemd units, module dir, and MCP mount).
   - Module dir bridged/ -> fleetd/; jar finalName -> fleetd.jar.
   - Log line, comments, docs, and CLAUDE.md updated to say fleetd.
   - Scripts renamed: redeploy-bridged.sh -> redeploy-fleetd.sh,
     bridged-launchd-wrapper.sh -> fleetd-launchd-wrapper.sh.
   - Deploy units renamed: dev.ltms.bridged.plist -> dev.ltms.fleetd.plist,
     bridged.service -> fleetd.service; launchd Label -> dev.ltms.fleetd.
   - Config default bridged.yaml -> fleetd.yaml; the legacy bridged.yaml is
     still read as a fallback, and still gitignored.
   - MCP: drop the deprecated bridge_* tool twins; only fleet_* remain. The
     server name is "fleet". The mount name in the local .mcp.json becomes
     "fleet" (gitignored, not in this commit).
   - Env var defaults BRIDGED_API_TOKEN -> FLEETD_API_TOKEN, fixture
     BRIDGED_WORKER_TOKEN -> FLEETD_WORKER_TOKEN.

Kept on purpose: the BRIDGED_MEMBER marker. Renaming it is a coupled change to
the credential-scrub security control (an operator secrets.sh may guard on it),
so it stays until that migration is done on its own.

Metrics were already fleet_* (CB-632); MetricNamesTest still guards that no
name says bridged_.

The canonical CLAUDE.md block and the wiki template stay byte-identical
(wiki working tree edited, committed to the wiki repo separately).

949 tests pass (mvn clean install). 4 fewer than before = the 4 removed
bridge_* alias tests.

2026-08-25 04:01:08 +02:00

1.9 KiB

Raw Blame History

claude-bridge (Claude Code plugin)

Makes a project bridge-ready: mounts the fleetd MCP gateway and applies standard Claude Code settings, so the session can orchestrate a fleet of delegated workers.

This plugin ships no credentials. Every secret is referenced by environment-variable name; the values stay with the user. Nothing the plugin writes is unsafe to commit.

What it is not

The plugin is the client-side setup, not the bridge. fleetd is a separate daemon and herdr is a separate PTY multiplexer, each with its own lifecycle and install. The plugin mounts an already-running daemon and tells you what is missing when one isn't there — it deliberately does not try to install system services on your behalf.

Install

/plugin marketplace add ltms/claude-bridge
/plugin install claude-bridge@claude-bridge

Then, in the project you want to onboard:

/claude-bridge:setup

What you get

Component	Effect
`.mcp.json`	mounts `fleetd` at `http://127.0.0.1:8765/mcp` for any session with the plugin enabled
`skills/setup`	`/claude-bridge:setup` — preflight, project settings, credential guidance, and verification

Because the plugin carries its own .mcp.json, an installed plugin needs no project-level MCP file at all. The setup skill writes one only when you want the mount to work without the plugin — for teammates who haven't installed it, or for CI.

Verifying a setup

The setup skill ends by requiring a real spawn, not a health check. /healthz only reports that the daemon can reach herdr; a protocol mismatch between the daemon's adapter and the herdr binary leaves health green while every spawn fails. Only a spawn that reaches ready proves the fleet.

Local development

claude --plugin-dir ./plugin
claude plugin validate ./plugin

/reload-plugins picks up edits without restarting the session.

1.9 KiB Raw Blame History