Files
stack/packages/mosaic/framework/systemd/user
mosaic-coder 8de52b7b59
Some checks failed
ci/woodpecker/pr/ci Pipeline failed
fix(wake): #925 framework-ship canon fallback-wake (systemd timer + schema bound + A10 install/validate) — F7 out of the box
Framework-ship the canon-side FALLBACK WAKE (F7 replacement-before-retirement)
so hosts get it out of the box instead of hand-wiring it per host. ADDITIVE;
honors #869 / Gate A/B discipline.

1. New framework units systemd/user/mosaic-wake-fallback.{timer,service}: a
   low-frequency SAFETY drain (oneshot service running the canon drain
   `digest.sh render --from-store`) fired by a per-class cadence timer,
   INDEPENDENT of the event-driven detector, so a stalled detector/daemon can
   never silently starve delivery. Owned via the existing `systemd/**` glob in
   framework-manifest.txt (Gate A) — no new owned path, no second authority.
2. Optional additive per-class `fallback_cadence` bound in
   wake-watch-list.schema.json (config, not code). Backward-compatible within
   schema_version 1, so [schema_min, schema_max] stays [1,1] and the detector's
   Gate B range check is unchanged.
3. A10 wake-install.sh enumerates + links + validates the two units into the
   user systemd search path (idempotent, fail-closed); write-fallback-cadence
   writes the per-class cadence as a blank-reset drop-in (exactly one
   effective OnUnitActiveUSec).
4. F7 install-validate: the §5 legacy reap now REFUSES unless the canon
   fallback wake is proven live (installed + schedulable floor always; enabled
   + proven-firing when a live user manager is probeable, mirroring #913).

Red-first: test-wake-install.sh I11 (F7 reap-refuses-without-live-fallback),
I12 (stalled detector still drains), I13 (install links+validates units),
I14 (per-class cadence blank-reset = exactly one); test-wake-detector.sh D9
(optional fallback_cadence in-range accepted; out-of-range still fails loud).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0158NZqN2n2ymKFeJAZ4GUCb
2026-07-26 08:07:03 -05:00
..

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.
  • mosaic-agent@.service — user-mode template for one reusable agent session.
  • mosaic-interaction-agent@.service — 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.