Goal
Keep saved custom-palette lists coherent across already-open project contexts when a palette is created through a source-neutral flow such as Guided Drawing.
Origin
Discovered during automatic review of #427 / #383:
#427 (comment)
#383 intentionally keeps palette choices dialog-local and must not read from or mutate the active project's palette store. That boundary is correct for Guided Drawing, but an already-open project's regular palette selector currently caches custom palettes at store construction or through that store's own CRUD methods. A palette saved elsewhere may therefore require a reload or new context before it appears there.
Desired outcome
- A successfully saved custom palette becomes discoverable by every relevant open palette selector without reloading the application.
- Refreshing saved-palette metadata does not select the palette, replace project colors, mark the project dirty, or add project history.
- The solution is source-neutral: Guided Drawing, future import flows, and regular palette management share one cache-invalidation contract.
- Multiple open projects remain isolated for project palette state while sharing the global saved-palette catalog safely.
- Save, delete, rename, and update paths cannot leave different open contexts with contradictory catalog views.
- Failure to refresh is observable in the owning UI without duplicating successful writes.
Non-goals
Agent Assessment
Risk: medium.
Worker-ready: no.
This crosses global IndexedDB persistence, per-ProjectContext palette-store caches, multi-tab/open-project lifecycle, and async invalidation semantics. First map every custom-palette CRUD caller and decide the smallest source-neutral notification or catalog ownership model. Human approval is required before implementation because an eager refresh must not mutate project state or introduce hidden cross-context coupling.
Goal
Keep saved custom-palette lists coherent across already-open project contexts when a palette is created through a source-neutral flow such as Guided Drawing.
Origin
Discovered during automatic review of #427 / #383:
#427 (comment)
#383 intentionally keeps palette choices dialog-local and must not read from or mutate the active project's palette store. That boundary is correct for Guided Drawing, but an already-open project's regular palette selector currently caches custom palettes at store construction or through that store's own CRUD methods. A palette saved elsewhere may therefore require a reload or new context before it appears there.
Desired outcome
Non-goals
Agent Assessment
Risk: medium.
Worker-ready: no.
This crosses global IndexedDB persistence, per-ProjectContext palette-store caches, multi-tab/open-project lifecycle, and async invalidation semantics. First map every custom-palette CRUD caller and decide the smallest source-neutral notification or catalog ownership model. Human approval is required before implementation because an eager refresh must not mutate project state or introduce hidden cross-context coupling.