mosaicstack/stack
1
0
Fork 0
Code Issues 36 Pull Requests 2 Actions Packages Projects Releases 15 Wiki Activity

mosaic update: framework reseed skipped when CLI is updated outside mosaic update (stale tools/, incl. tmux helpers) #642

New Issue
Open
opened 2026-06-24 03:10:14 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-06-24 03:10:14 +00:00
Owner
Copy Link

Symptom

After updating the CLI to a new version, the framework files in ~/.config/mosaic/ (guides, launcher, and tools/ — including the tmux helpers agent-send.sh/send-message.sh) remain at the OLD version. Observed in the field jumping a workstation 0.0.31 → 0.0.41: CLI read 0.0.41 but tmux tool was absent/stale.

Root cause

mosaic update only re-seeds the framework when the update itself installs a newer @mosaicstack/mosaic. From packages/mosaic/src/cli.ts (update handler):

const mosaicUpdated = outdated.some(r => r.package === FRAMEWORK_RESEED_PACKAGE); // '@mosaicstack/mosaic'
if (mosaicUpdated && opts.reseed !== false) { runFrameworkReseed(); }

So the reseed is skipped whenever the CLI reaches the new version by any path other than mosaic update doing the npm install in that same run:

  • npm i -g @mosaicstack/mosaic@X directly (no postinstall → no reseed), or
  • mosaic update when mosaic is already current (nothing "outdated" → mosaicUpdated false).

The framework (incl. tools/tmux/) is shipped in the package (files: ["dist","framework"]) — it's purely the sync-into-~/.config step that doesn't fire.

Manual workaround

MOSAIC_SYNC_ONLY=1 MOSAIC_INSTALL_MODE=keep bash "$(npm root -g)/@mosaicstack/mosaic/framework/install.sh"

Proposed fix

Reseed based on on-disk framework version lag, not the npm "outdated" signal: compare ~/.config/mosaic/.framework-version against the installed package's bundled framework version and reseed (keep-mode) whenever it trails — independent of how the CLI got upgraded. Optionally also run this reconcile on CLI startup / session-start.sh.

Why it matters

A stale framework means shipped launcher/runtime/tooling changes silently don't activate — agents run old behavior while reporting the new version. (Surfaced during the dragon-lin 0.0.41 reseed work, 2026-06-23.)

## Symptom After updating the CLI to a new version, the framework files in `~/.config/mosaic/` (guides, launcher, **and `tools/` — including the tmux helpers `agent-send.sh`/`send-message.sh`**) remain at the OLD version. Observed in the field jumping a workstation 0.0.31 → 0.0.41: CLI read 0.0.41 but tmux tool was absent/stale. ## Root cause `mosaic update` only re-seeds the framework when the update *itself* installs a newer `@mosaicstack/mosaic`. From `packages/mosaic/src/cli.ts` (update handler): ```ts const mosaicUpdated = outdated.some(r => r.package === FRAMEWORK_RESEED_PACKAGE); // '@mosaicstack/mosaic' if (mosaicUpdated && opts.reseed !== false) { runFrameworkReseed(); } ``` So the reseed is **skipped** whenever the CLI reaches the new version by any path other than `mosaic update` doing the npm install in that same run: - `npm i -g @mosaicstack/mosaic@X` directly (no postinstall → no reseed), or - `mosaic update` when mosaic is *already* current (nothing "outdated" → `mosaicUpdated` false). The framework (incl. `tools/tmux/`) is shipped in the package (`files: ["dist","framework"]`) — it's purely the *sync-into-~/.config* step that doesn't fire. ## Manual workaround ``` MOSAIC_SYNC_ONLY=1 MOSAIC_INSTALL_MODE=keep bash "$(npm root -g)/@mosaicstack/mosaic/framework/install.sh" ``` ## Proposed fix Reseed based on **on-disk framework version lag**, not the npm "outdated" signal: compare `~/.config/mosaic/.framework-version` against the installed package's bundled framework version and reseed (keep-mode) whenever it trails — independent of how the CLI got upgraded. Optionally also run this reconcile on CLI startup / `session-start.sh`. ## Why it matters A stale framework means shipped launcher/runtime/tooling changes silently don't activate — agents run old behavior while reporting the new version. (Surfaced during the dragon-lin 0.0.41 reseed work, 2026-06-23.)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#642
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?