fred
463745e314
On a roster-v2 fleet, `ps`, `install`, `install-systemd`, `add` and `remove` all failed in the v1 parser. The consequence was that a greenfield v2 box could never get its unit templates placed, so nothing downstream could start. The read-only commands get a narrow version-agnostic view of the roster (version, socket name, holder session, and per agent name/alias/runtime). This is deliberately not a v2 -> v1 downshift. A downshifted FleetRoster would be accepted by generateAgentEnvValues, which would make a third writer of fleet/agents/<name>.env.generated through the v1 mapping and break the #791 single-SSOT invariant that projectRosterV2AgentGeneratedEnv is documented to hold. The view is too small to write a roster or an env file back from, so that misuse is unavailable rather than merely discouraged. So on a v2 roster `install` places the tool files and the unit templates, enables the units, and writes no generated env at all. Env belongs to `apply` and `regen`, both already v2-native. That change alone would have traded an init-time failure for a boot-time one. `install` enables mosaic-agent@<name>.service (WantedBy=default.target) without starting it, so a reboot between `install` and the first `apply` would run ExecStart against an absent env file and fail every seat unit, further from its cause. The unit template now carries ConditionPathExists=%h/.config/mosaic/fleet/agents/%i.env.generated which skips an enabled-but-unconfigured unit cleanly and starts it on the next start once the reconciler has written env. On v1 it is a no-op, since v1 `install` writes env itself. Found in review by scooby. `add` and `remove` are not routed to `create` and `delete`. They are different operations: the v1 pair edits the roster and drives systemd, the v2 pair is documented as changing desired state without runtime actions. `add` also collects four fields where a v2 agent requires eleven, so routing it would mean inventing an operator's provider, alias, reasoning and tool policy. On v2 both now fail with the real two-step sequence instead. Tests: 8 new, 7 of which are red before this change. Includes the greenfield case scooby asked for — `ps` on a fresh v2 install with nothing running is rc=0 and lists every agent stopped, since that is the command an operator runs to find out why there is no seat. Note for anyone verifying this: a correct fix here shows `install` rc=0 and `start` rc=0 and still no live seat. #1240 (tmux absent) is upstream, #1241 (start reports lifecycle-complete over dead panes) and the missing agent runtime are downstream. A dead pane after this change is not a regression here. Refs #1237, #791, #1240, #1241
Mosaic tmux Fleet PoC
This directory contains the first durable tmux-backed fleet primitives for the Mosaic software-factory model.
The lifecycle model follows the organization-neutral AI Guide playbook
mosaicstack/aiguide:playbooks/tmux-fleet.md (commit 2a0b0b5): a dedicated
holder owns the tmux server/socket; agent units join it and stop only their own
exact-match session.
Layout
mosaic-tmux-holder.service— user-mode holder that owns the named tmux server.[email protected]— user-mode template for one reusable agent session.[email protected]— generic Pi operator-interaction template that fails fast when its pinned runtime policy is incomplete or changed.test-fleet-units.sh— validates unit syntax and required relationships.
The agent template calls:
~/.config/mosaic/tools/fleet/start-agent-session.sh <agent-name>
which starts or reuses a tmux session on MOSAIC_TMUX_SOCKET.
Generated environment and local data
The roster-derived projection is written outside the package at:
~/.config/mosaic/fleet/agents/<agent>.env.generated
Systemd does not read either environment file. It starts the launcher with a fixed cleared bootstrap
environment; before it creates, queries, or stops an exact agent tmux session, start-agent-session.sh
strictly parses the generated projection and the optional local data file:
~/.config/mosaic/fleet/agents/<agent>.env.local
The local file may contain only safe machine-specific data (MOSAIC_RUNTIME_BIN, heartbeat paths or
interval, and Claude configuration paths). It cannot override roster-derived keys, carry a command,
or contain secret-like/unknown keys. Both files must be private regular files. Do not hand-edit the
generated projection; update the roster and regenerate it instead. A legacy <agent>.env is
consumed only for regeneration, strict relocation, or private quarantine and is never launch input.
See docs/fleet/reference/generated-env-boundary.md for the full contract.
Manual canary sequence
Use the roster and the supported installer; do not pre-create the agent environment directory or
edit a generated projection. mosaic fleet install validates the roster, installs the units and
helpers, and writes private roster-derived projections before any service is started.
# Create a site-owned canary roster. Inspect an existing roster before using --force.
mosaic fleet init --profile minimal --write
mosaic fleet install
systemctl --user daemon-reload
mosaic fleet start canary-pi
tmux -L mosaic-fleet ls
For an operator-interaction service, first put <agent-name> in the roster with the pinned Pi
runtime, model, reasoning, and operator-interaction tool policy. Re-run mosaic fleet install after
that roster change so it writes <agent-name>.env.generated; ambient MOSAIC_AGENT_* values are not
launch authority. The generic unit instance uses that generated identity, and no service source is
renamed for an instance:
mosaic fleet install
systemctl --user daemon-reload
systemctl --user start mosaic-interaction-agent@<agent-name>.service
~/.config/mosaic/tools/fleet/print-interaction-effective-policy.sh <agent-name>
Do not use tmux kill-server without -L mosaic-fleet; this pattern is meant
to avoid disturbing the user's default tmux server.