The gap you found in 0.0.39 production validation:mosaic update installs the new npm CLI but never re-seeds ~/.config/mosaic/ from the package's bundled framework/. So the shipped custom Pi harness (agent-name export + native HB) stays dormant until a manual re-seed — operators (and w-jarvis) get the new CLI on a stale framework.
What this does
After a successful mosaic update install that includes @mosaicstack/mosaic:
Re-seeds the framework from the freshly-installed package's install.sh in MOSAIC_SYNC_ONLY=1 MOSAIC_INSTALL_MODE=keep — the P4 data-safe reconcile (framework-owned overwrite + backup-once; SOUL/USER/*.local/credentials preserved). Default-on; --no-reseed opts out. This is the R13 fix — shipped launcher/runtime changes now activate.
Relaunches durable agents — --relaunch restarts rostered agents (systemctl --user restart mosaic-agent@<name>) so they pick up the new launcher/extension; default prints clear activation guidance (restarting running agents is disruptive, so it's opt-in).
update-checker.ts: resolveBundledFrameworkRoot, buildReseedCommand, runFrameworkReseed, readRosterAgentNames, buildRelaunchCommands (pure builders + a best-effort runner that reports rather than throws).
cli.tsupdate: --no-reseed / --relaunch flags + the post-install steps; only re-seeds when the framework-bearing package actually updated.
Sync data-safety already proven (P4 5-fixture matrix + the live dragon-lin validation, zero data loss).
Note
Best validated on a real host with a fleet (w-jarvis): mosaic update --relaunch → confirm start-agent-session.sh + mosaic-extension.ts in ~/.config/mosaic match the new package and agents come back on the native HB. The re-seed uses the local installed package (no network).
## F3-m3 — `mosaic update` re-seeds framework + relaunches agents (closes R13)
**The gap you found in 0.0.39 production validation:** `mosaic update` installs the new npm CLI but never re-seeds `~/.config/mosaic/` from the package's bundled `framework/`. So the shipped custom Pi harness (agent-name export + native HB) stays **dormant** until a manual re-seed — operators (and w-jarvis) get the new CLI on a **stale framework**.
### What this does
After a successful `mosaic update` install that includes `@mosaicstack/mosaic`:
1. **Re-seeds the framework** from the freshly-installed package's `install.sh` in `MOSAIC_SYNC_ONLY=1 MOSAIC_INSTALL_MODE=keep` — the **P4 data-safe reconcile** (framework-owned overwrite + backup-once; `SOUL`/`USER`/`*.local`/`credentials` preserved). Default-on; `--no-reseed` opts out. **This is the R13 fix** — shipped launcher/runtime changes now activate.
2. **Relaunches durable agents** — `--relaunch` restarts rostered agents (`systemctl --user restart mosaic-agent@<name>`) so they pick up the new launcher/extension; default prints clear activation guidance (restarting running agents is disruptive, so it's opt-in).
Flow: `update CLI → re-seed framework (data-safe) → relaunch agents (opt-in)`.
### Implementation
- `update-checker.ts`: `resolveBundledFrameworkRoot`, `buildReseedCommand`, `runFrameworkReseed`, `readRosterAgentNames`, `buildRelaunchCommands` (pure builders + a best-effort runner that reports rather than throws).
- `cli.ts` `update`: `--no-reseed` / `--relaunch` flags + the post-install steps; only re-seeds when the framework-bearing package actually updated.
### Verification
- **6 new unit tests** (reseed command/env, relaunch commands, roster parse, missing-installer guard) + **19 runtime + 26 launch** tests green. tsc/eslint/prettier clean.
- Sync data-safety already proven (P4 5-fixture matrix + the live dragon-lin validation, zero data loss).
### Note
Best validated on a real host with a fleet (w-jarvis): `mosaic update --relaunch` → confirm `start-agent-session.sh` + `mosaic-extension.ts` in `~/.config/mosaic` match the new package and agents come back on the native HB. The re-seed uses the local installed package (no network).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Closes R13 (F3-m3). mosaic update installed the new npm CLI but never
re-seeded ~/.config/mosaic from the package's bundled framework/, so shipped
launcher/runtime changes (agent-name export + native HB) stayed DORMANT until
a manual re-seed — operators got the new CLI on a stale framework.
- update-checker.ts: resolveBundledFrameworkRoot, buildReseedCommand (install.sh
in MOSAIC_SYNC_ONLY=1 MOSAIC_INSTALL_MODE=keep — the P4 data-safe reconcile:
framework-owned overwrite + backup-once; SOUL/USER/*.local/credentials kept),
runFrameworkReseed, readRosterAgentNames, buildRelaunchCommands.
- cli.ts update: after a successful CLI install that includes @mosaicstack/mosaic,
re-seed the framework (default-on; --no-reseed to skip). Then --relaunch restarts
rostered agents (systemctl --user restart mosaic-agent@<name>), else prints clear
activation guidance. Only re-seeds when the framework-bearing package updated.
Flow: update CLI -> re-seed framework (data-safe) -> relaunch agents (opt-in).
Verified: 6 new unit tests + 19 runtime + 26 launch tests green; tsc/eslint/
prettier clean. Sync data-safety already proven (P4 matrix + live validation).
Refs #609
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01EsgTQzV5YUGk1JtCLP4B83
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
F3-m3 —
mosaic updatere-seeds framework + relaunches agents (closes R13)The gap you found in 0.0.39 production validation:
mosaic updateinstalls the new npm CLI but never re-seeds~/.config/mosaic/from the package's bundledframework/. So the shipped custom Pi harness (agent-name export + native HB) stays dormant until a manual re-seed — operators (and w-jarvis) get the new CLI on a stale framework.What this does
After a successful
mosaic updateinstall that includes@mosaicstack/mosaic:install.shinMOSAIC_SYNC_ONLY=1 MOSAIC_INSTALL_MODE=keep— the P4 data-safe reconcile (framework-owned overwrite + backup-once;SOUL/USER/*.local/credentialspreserved). Default-on;--no-reseedopts out. This is the R13 fix — shipped launcher/runtime changes now activate.--relaunchrestarts rostered agents (systemctl --user restart mosaic-agent@<name>) so they pick up the new launcher/extension; default prints clear activation guidance (restarting running agents is disruptive, so it's opt-in).Flow:
update CLI → re-seed framework (data-safe) → relaunch agents (opt-in).Implementation
update-checker.ts:resolveBundledFrameworkRoot,buildReseedCommand,runFrameworkReseed,readRosterAgentNames,buildRelaunchCommands(pure builders + a best-effort runner that reports rather than throws).cli.tsupdate:--no-reseed/--relaunchflags + the post-install steps; only re-seeds when the framework-bearing package actually updated.Verification
Note
Best validated on a real host with a fleet (w-jarvis):
mosaic update --relaunch→ confirmstart-agent-session.sh+mosaic-extension.tsin~/.config/mosaicmatch the new package and agents come back on the native HB. The re-seed uses the local installed package (no network).🤖 Generated with Claude Code