fix(#1237): let ps/install work on a roster-v2 fleet, and refuse add/remove honestly

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

This commit is contained in:

fred

2026-08-15 23:24:24 -05:00

parent 7a6fb024b4

commit 463745e314

3 changed files with 379 additions and 8 deletions

									
										packages/mosaic/framework/systemd/user/[email protected]
									
		+8
		
												View File
												
				@@ -4,6 +4,14 @@ Documentation=https://git.mosaicstack.dev/mosaicstack/stack

				Requires=mosaic-tmux-holder.service

				After=mosaic-tmux-holder.service

				PartOf=mosaic-tmux-holder.service

				# Do not attempt a seat before its generated env exists. `install` enables this

				# unit (WantedBy=default.target) but on a roster-v2 fleet the reconciler owns the

				# generated env, so between `install` and the first `apply`/`regen --write` there

				# is a boot window where ExecStart would run against an absent env file and the

				# launcher would fail the unit. A skipped unit is the honest state for "enabled

				# but not yet configured"; systemd re-evaluates the condition on every start, so

				# the seat comes up on the next start once the reconciler has written env.

				ConditionPathExists=%h/.config/mosaic/fleet/agents/%i.env.generated

				[Service]

				Type=oneshot