Snapshot Dialogs — Redesign Mockup

Side-by-side comparison: current Snapshot toolbar, Save dialog, Load dialog, and the autosave-newer choice modal — and the proposed post-redesign state. Discussion-only; not implemented yet. Flow doc: snapshot-dialogs-redesign.md.

Removed — surface goes away Added / moved — new inline control Server fix — backend logic change

1. Snapshot toolbar (sidebar row)

CurrentSettings cog occupies the 4th slot
Koolook_v03· saved
The cog opens a dedicated Settings dialog whose only job is to set the library path — a setting users only think about while saving or loading. Two-step path: open cog → change path → close → reopen Save/Load.
ProposedCog removed; library path moves inline
Koolook_v03· saved
Library-path control moves to the Save and Load dialogs (sections 2 & 3 below). Users see and change the path in the same place they pick where to save / load from.

2. Save dialog — preset already tracked

CurrentLibrary path is a small read-only subtitle
To save somewhere else, the user has to close this, open Settings, change the path, then re-open Save. Three round-trips for one action.
ProposedInfo at top is non-interactive; every action lives in the bottom command bar
Library row is purely informational (no attached buttons). Every action moves to a single command bar at the bottom: utility action Save to… on the left, dismiss + alternatives + primary on the right. "Save to…" replaces "Change…" so the verb makes it unambiguous against "Open folder" in the Load dialog.

3. Load dialog

CurrentLibrary row at top with 📂 Open button
No way to switch library from here. User has to close, open Settings cog, change path, reopen Load.
Proposed — default state"Open folder ↗" pinned to the top of the path box so a long path can't cover it
Top-row layout: label on the left, Open folder ↗ link on the right. The link sits above the path so a long absolute path can't overlap the link area. Load from… stays the only proper button — text link vs. button is the visual distinction between "change app state" and "just open something outside the app."
Proposed — recovery expandedWhat clicking ▸ Recovery auto-saves reveals
Recovery section is hidden by default. Clicking a preset row (e.g. Koolook_v03 or starter) opens the recovery dropdown and reveals only that preset's <preset>_autosave/ folder — other presets' autosaves are not shown here. Inside the folder, exactly one row is rendered: whichever of Pre-load or Periodic is the newest (the system picks). Row shows kind badge + timestamp + small picks/workflows meta; the on-disk filename is implementation detail and stays hidden. The group header keeps its Open folder ↗ link for manual inspection/backup. Final decision: row clicks select only. When this section opens because the selected snapshot has newer recovery, the Load dialog header changes to Auto-save is newer than the saved version and the footer presents NO - load saved / YES - load latest.
Proposed — delete confirmClick × on a row → command bar transforms into the confirm question; Close becomes Yes
No new modal — same Load dialog stays open. The targeted row gets a red outline so the user can see exactly what they're about to delete. The bottom bar transforms: Load from… hides, Confirm delete "<name>"? appears on the left, Close becomes Yes (red) on the right. Esc or clicking another row cancels. Same pattern can extend to autosave row deletes in the Recovery section.

4. Autosave-newer YES / NO modal — superseded reference

ProposedDefault view shows only what the user needs to decide; details hide behind ⓘ
Superseded final decision: this separate modal is no longer the target UX. Keep the decision inside the Load dialog instead: selecting a snapshot with newer recovery opens the bottom Recovery auto-saves section, changes the header to Auto-save is newer than the saved version, and exposes footer buttons NO - load saved / YES - load latest. The row shapes above remain useful visual references for the named-vs-latest comparison, but the extra modal layer is intentionally dropped.

5. Button state pattern (consistent across every dialog)

PatternThe primary button's label, color, and disabled-ness reflect what the user is about to do
Default
Clean state. Save writes over the currently tracked preset; nothing about the destination has changed.
Dirty — folder changed
User picked a different destination via "Save to…". Label spells out the consequence so the click isn't a surprise.
In progress
Write in flight. Button disables to prevent double-submit; color shifts to neutral-blue so it doesn't read "danger".
Done
After a successful write, briefly. Same pattern as the Settings dialog's idle "Saved" state.
Final decision: the four-state cycle applies to true committing primary actions, such as the Save button that writes snapshot data. Save to… and Load from… are utility navigation buttons that open the folder picker; they stay stable rather than cycling through write-state labels.

6. Folder-browse picker — what opens when you click Save to… / Load from…

ConstraintWhy this isn't the OS-native picker
ProposedSame bottom-command-bar pattern; paste-path input at top (per PR #132)
Choose snapshot library folder
📁Koolook_v03_autosave
📁default_autosave
📄Koolook_v03.json
📄starter.json
Navigate-into model — standard folder-picker behaviour. The path input shows where you currently are, not what you've selected from a sibling list. Clicking a subfolder drills into it; ↑ Up climbs one level. The body lists that folder's contents: subfolders (clickable, amber 📁) and files (greyed-out 📄, inert — shown only so the user can confirm "yes, this is the folder I expected"). Use this folder commits whatever path is currently shown in the input. Three ways to set the path: (1) paste a path → Enter, (2) click subfolders to drill down + ↑ Up to climb, (3) New folder… creates one in place. The input always shows the end of the path when it overflows (leading /Users/… clips off the left, never the trailing folder name) and is copy-paste-editable for clipboard paths (per PR #132).

Step-flow — clicking "Save to…" or "Load from…"

1
User clicks Save to… in Save dialog (or Load from… in Load dialog).
2
Picker opens at the current library location. Path input pre-filled.
3
User navigates: type/paste a path, click subfolders, or hit New folder…
4
Selected-folder bar updates as the user navigates — always shows what "Use this folder" will commit.
5
Click Use this folder → server persists libraryPath, picker closes.
6
Parent dialog's library row reflects the new path. Load: list refreshes. Save: primary button label flips to "Save to new folder" (per Section 5 dirty state).

Locked-in decisions

Still open for review