---
id: SMH-SPEC-FLET0001
type: spec
title: "Fleet"
---

# Fleet

## Intent

Many smith hosts form one fleet: a frontend attaches to any peer and works, with machines, tools, and plugin instances multiplexed across hosts.

## Membership and trust

Fleet membership is signed node admission; a peer trust tier sits beside project trust and plugin grants.
Secure transport is node-key based; relays are infrastructure, self-hostable, never a required third party.

## Session ownership

Every session has a home daemon.
The home owns the write path; single-writer law is preserved.
Other peers replicate read-only or stream.
Clients roam; ownership routes writes.
Distributed merge is explicitly not attempted.

## Sync scope

Sessions and plugin sets sync across the fleet.
Filesystems and environments are out of core scope; plugins handle them.
Plugin generations are content-hashed and fleet-coherent: the same generation identity is valid on every peer.

## Remote effects

Effect records carry executor and target attribution as additive fields.
Remote effects keep durable intent, completion, three-state evidence, and causal chains.
Cancellation reaches remote effects; a destroyed remote instance records `unknown`, never silently drops.
Provider requests route only to hosts holding the needed credentials; secrets never cross the wire.

## Acceptance criteria

- A session opened on one peer completes its turns on that peer regardless of where clients attach.
- Read-only replication on any peer reconstructs the full transcript.
- A remote effect's record names executor and target with complete evidence.
- A peer without credentials for a model is skipped by routing, not failed into.
- Removing a peer from the fleet invalidates its admission without rekeying others.
- Fleet operation requires no third-party service.