fleet/fleetd
3
0
Fork 0
Code Issues 73 Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Page: 8 Roadmap
Pages
1 Architecture 10 Cross Host Messaging 11 Features 12 Claude to OpenCode 13 User Guide 14 Fleet Manager 15 REST API Reference 16 Security and Trust Boundary 2 Message Server 3 Approaches 4 Setup 5 Operations 6 Team 7 Use Cases 8 Roadmap 9 Implementation CB 548 Lead Quorum Design Home
Clone
24
8 Roadmap
Dai Ha edited this page 2026-08-31 10:29:05 +07:00
Unescape Escape
Table of Contents
This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

8. Roadmap and delivery record

Read this page as a delivery record, not as a system guide. Each item appears in one status group only. The groups separate code that exists from work that was planned or rejected. For the current operator surface, use Features and User Guide.

Status at a glance

This page was checked against the source tree on 2026-08-31. A claim marked built and live has code evidence below. “Live” means it is in the built daemon path, not that this page checked a particular host deployment.

Status Meaning
Built and live The current daemon creates or registers the feature.
Built, not switched on The code is complete, but no host enables it today.
Planned The old roadmap proposed it. It is not current daemon behaviour.
Tried and dropped Research or an old design that was not shipped.

Built and live

The MCP fleet surface

FleetMcp registers these tools: fleet_ack, fleet_ask, fleet_list, fleet_poll, fleet_profiles, fleet_reply, fleet_send, fleet_spawn, fleet_status, fleet_stop, and fleet_whoami. fleet_read is not registered. The fleet_send schema also supports coordId for peer-lead coordination. See fleetd/src/main/java/dev/ltms/fleet/mcp/FleetMcp.java:1088-1245.

The current tool set covers a delegation, a worker question, an asynchronous ticket, inbox acknowledgement, member lifecycle, profile discovery, and caller identity. The tool descriptions are the current contract. See fleetd/src/main/java/dev/ltms/fleet/mcp/FleetMcp.java:1088-1245.

Two launcher kinds

Profiles support claude-code and opencode. Fleetd builds launcher adapters for the configured kinds and puts them behind CompositePeerLauncher. See fleetd/src/main/java/dev/ltms/fleet/Fleetd.java:159-201 and fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java:265-270,314-345.

This is the shipped replacement for the old Claude-only plan. A member’s role and profile stay separate. The role states whether it is an architect, developer, or reviewer. See fleetd/src/main/java/dev/ltms/fleet/peer/MemberRole.java:6-53.

Member worktrees and developer pull requests

fleet_spawn can request an isolated worktree. The tool states that a developer member opens its own pull request. See fleetd/src/main/java/dev/ltms/fleet/mcp/FleetMcp.java:1148-1173.

Fleetd gives SessionManager a GitWorktrees instance. GitWorktrees creates the linked worktree, configures its credential helper, and neutralizes inherited tool configuration. See fleetd/src/main/java/dev/ltms/fleet/Fleetd.java:218-229 and fleetd/src/main/java/dev/ltms/fleet/session/GitWorktrees.java:111-132.

The developer role’s contract says it provisions a worktree, commits, pushes, and opens its own pull request. See fleetd/src/main/java/dev/ltms/fleet/peer/MemberRole.java:37-44.

Durable replies use AMQP when configured

The current durable inbox choice is AMQP. broker is the configuration block for an external AMQP broker. When it is absent, the inbox is in memory. See fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java:49-50,656-714.

At startup, Fleetd selects the reply inbox from broker and can open AmqpReplyInbox. See fleetd/src/main/java/dev/ltms/fleet/Fleetd.java:399,811 and fleetd/src/main/java/dev/ltms/fleet/msg/AmqpReplyInbox.java:79-145.

This deployment enables AMQP reply durability through its configured LavinMQ broker. Without a usable broker configuration, the daemon falls back to the in-memory inbox. See fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java:656-714,1915.

Cross-host lead-to-lead coordination

Lead-to-lead coordination works through a separate coordinator: block. A lead uses fleet_send with coordId; the tool publishes to the peer lead’s durable mailbox. See fleetd/src/main/java/dev/ltms/fleet/mcp/FleetMcp.java:597-641,1088-1108 and fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java:74-78,718-760.

This feature is only for coordination between peer leads. It is not a way to delegate work sideways. The restriction is in the tool description at fleetd/src/main/java/dev/ltms/fleet/mcp/FleetMcp.java:1093-1107.

This deployment has a coordinator: block with selfId, so its peer-lead mailbox is enabled. An absent or empty block opens no mailbox. See fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java:746-760,1944-1948.

Current delivery path

The current source builds the delivery path around the following dependencies. This is a code map, not a promise about a host’s running configuration.

flowchart LR
    P["Profile kind"] --> L["Launcher adapter"]
    L --> S["SessionManager"]
    S --> W["GitWorktrees (when requested)"]
    M["FleetMcp tools"] --> S
    B["broker config"] --> R["ReplyInbox"]
    C["coordinator config"] --> H["LeadChannel"]
    M --> H

Figure: current code links profiles, member sessions, optional worktrees, reply delivery, and peer-lead coordination.

Evidence for the launcher and session links is fleetd/src/main/java/dev/ltms/fleet/Fleetd.java:159-229. Evidence for the MCP links is fleetd/src/main/java/dev/ltms/fleet/mcp/FleetMcp.java:1088-1245.

Built, not switched on

Separate herdr daemon for members

memberHerdrSocket lets the daemon connect members through a second herdr daemon. When the key is blank or absent, members use the lead socket instead. See fleetd/src/main/java/dev/ltms/fleet/Fleetd.java:148-158 and fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java:34-37.

The current repository does not switch this option on anywhere. Therefore this page does not describe it as active on a host. An operator must set memberHerdrSocket and restart the daemon for it to take effect.

Planned

External launcher plugins

The old roadmap proposed dynamic external plugin loading for launcher adapters. The current code confirms only two accepted kinds: claude-code and opencode. See fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java:1688-1731.

There is no plugin discovery and no trust model for third-party launchers in the current source. This stays planned; it is not an extension point today.

Multi-host member federation

The roadmap once described cross-host member spawning, a federated roster, and member routing between gateway daemons. None of those member-federation features are in the current source. Do not infer them from the shipped coordId lead channel, which carries lead-to-lead coordination only.

The limited feature that is built is peer-lead coordination through coordinator:. See fleetd/src/main/java/dev/ltms/fleet/mcp/FleetMcp.java:597-641.

Exact old stages, ticket counts, versions, and deployment claims

The earlier page gave dates, ticket ranges, test counts, herdr protocol versions, release tags, and host deployment results. Those are historical records, and this rewrite checked claims against the source tree rather than against source control history or a running host. They are not repeated here as current facts.

For the same reason, this page does not claim that a launchd or systemd unit is installed, that a broker is running, or that a feature was dogfooded. Those need deployment evidence, not only source evidence.

Tried and dropped

AgentAPI

AgentAPI was a research fallback in older plans. It was never built. The current profile validation accepts only claude-code and opencode. See fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java:1688-1731.

Do not present AgentAPI as an adapter, a fallback, or an operator choice.

Redis Streams, NATS JetStream, and an embedded durable queue

Older plans considered Redis Streams, NATS JetStream, and an embedded queue. They were not the shipped durable inbox. The current configuration and startup path use an AMQP broker and AmqpReplyInbox; otherwise they use an in-memory inbox. See fleetd/src/main/java/dev/ltms/fleet/config/FleetConfig.java:49-50,656-714,1915 and fleetd/src/main/java/dev/ltms/fleet/Fleetd.java:399,811.

Neither Redis Streams nor NATS JetStream appears anywhere in the current source. They are discarded options, not supported configuration choices.

REST-first and SSE roadmap

The old page described every feature as a REST endpoint with MCP as a thin wrapper, and it proposed Server-Sent Events (SSE). The daemon registers no SSE route, and MCP and REST are two faces over one shared MessageService rather than one wrapping the other. Treat that old shape as a design idea, not as the current system.

Historical delivery sequence

The project moved from a small single-host delegation plan toward the current fleet daemon. The useful history is the decision path below. It does not claim that every old stage, ticket, or test result is still current.

  1. The first plan focused on one delegated review flow.
  2. Later work added member lifecycle, profiles, and worktree isolation.
  3. The launcher boundary became provider-neutral enough for claude-code and opencode.
  4. Reply delivery gained an optional AMQP-backed inbox.
  5. Peer leads gained a separate coordination channel.
  6. A second herdr daemon became an optional member-routing setup.

The current code supports steps 2 through 6 as described in the status sections. The original review demo details, old ccs commands, and the AgentAPI fallback do not describe the current system.

What this rewrite did not promote

These are not current, shipped behaviour, so they stay planned or are left out: external launcher plugins, multi-host member federation, a REST-first core, SSE, exact release and test figures, live deployment results, old herdr versions, and old ccs profile commands.

The build targets Java 25 (fleetd/pom.xml:16, maven.compiler.release), and the source uses Java 25 features such as unnamed lambda parameters. An older version of this page said Java 21.

Related pages

📖 fleet

Home — overview & the decision

Chapters

  1. Architecture — system · 2 invariants · 2 modes
  2. Message Server — the fleetd design
  3. Approaches — transports compared, why herdr
  4. Setup — ⚫ superseded by 13
  5. Operations — ⚫ superseded by 13
  6. Team — orchestrating a mixed fleet
  7. Use Cases — the review scenario + mechanisms
  8. Roadmap — delivery record: what is live, what is off, what was dropped
  9. Implementation — as-built code map · classes · flows · state machines
  10. Cross-Host Messaging — broker topology · exchanges · queues per entity
  11. Features — what it can do · the knob that turns it on · why · the gotcha
  12. Claude → OpenCode — porting a workspace to a second host
  13. User Guide — 🟢 install · configure · run · delegate · the traps
  14. Fleet Manager — many fleets on one host, over REST
  15. REST API Reference — all 14 routes, roles, and bodies
  16. Security & Trust Boundary — the guard · authz · what a member inherits

Design proposals (not built)

🟢 herdr-centric fleetd · AgentAPI = research, never built