# #631 — re-seed must preserve user fleet data (CRITICAL data-loss)

- **Issue:** #631 · **Branch:** `fix/631-reseed-preserves-fleet-data`

## Root cause

`mosaic update` auto-runs `install.sh` keep-mode sync (#610). install.sh's rsync `--delete` (keep mode)
honored PRESERVE_PATHS, but `fleet/` wasn't listed → the sync WIPED `~/.config/mosaic/fleet/roster.yaml`
(+ run/, agents/). Any user running `mosaic update` lost their roster. (overwrite mode wipes by design;
the live loss was keep mode.)

## Fix (PRIMARY)

- install.sh PRESERVE_PATHS += `fleet/*.yaml`, `fleet/agents`, `fleet/run` — the framework still SEEDS
  fleet/examples + fleet/roles + fleet/roster.schema.json (synced), but user files survive.
- Made the cp-fallback (no-rsync) GLOB-AWARE so `fleet/*.yaml` preserves every user roster there too;
  fixed the restore to re-glob per-pattern (so only the user file is restored, not the whole fleet/ dir).
- file-adapter.ts (TS installer): mirrored the preserve list for parity. (TS syncDirectory is copy-only,
  never --delete, so it never had the bug — belt-and-suspenders + parity.)

## Fix (SECONDARY)

- `refreshActiveFleetUnits()` (update-checker.ts): the re-seed updates ~/.config/mosaic/systemd/user but
  systemd runs ~/.config/systemd/user, so unit fixes (#627) didn't take effect. After the re-seed,
  `mosaic update` now copies the fresh mosaic-\*.service → the active dir + daemon-reload (best-effort,
  only when a fleet is already installed). Wired into the cli.ts update flow.

## Verification

- bash F6 fixture (6 checks: roster/custom-yaml/agents/run survive + examples refreshed + schema seeded);
  20/20 migration matrix green. TS file-adapter test (roster/run/agents survive keep sync). 2 unit tests
  for refreshActiveFleetUnits. tsc/eslint/prettier/sanitize clean.