a11y: Model preset update while loaded

[fl0rianr]

Scope

• Area: prototype/ui-redesign/
• Milestone: GUI3
• Related issue: a11y: remove preset rails and introduce a completely new and elegant model view concept #2355
• Group F -> branch feat/gui3-forms-icons-a11y
  Grouped by component to avoid merge conflicts.

Task

Allow users to change the preset of a loaded model without first unloading and reloading the model manually.

Currently, changing the preset requires unloading the model and loading it again. This should be replaced by a dedicated Update preset flow.

Expected behavior

Loaded model preset update

When a model is already loaded, the user should be able to change the preset as well.

Once a new preset is selected while the model is loaded, an Update preset button should appear next to the Unload button.

The user can then click Update preset to apply the selected preset to the loaded model.

Update preset mode

The Update preset mode is central and must support two types of preset changes:

Changes that do not require a reload

Preset changes that can be applied live should be updated directly.

Example:

• system prompt changes

These changes should be applied without unloading or reloading the model.

Changes that require a reload

Preset changes that cannot be applied live should trigger a reload flow.

Examples may include larger runtime-affecting changes such as:

• model parameters that require reinitialization
• backend/runtime configuration changes
• changes that cannot safely be applied to an already loaded model

In these cases, clicking Update preset should perform the required reload automatically, instead of requiring the user to manually unload and load the model again.

Lemonade tools support

The same Update preset mode must also be available through Lemonade tools.

When the user asks Lemonade to change the preset, for example:

change the preset

Lemonade should use the same update logic:

• apply live-updateable preset changes directly
• trigger a reload when the selected preset change requires it
• avoid requiring the user to manually unload and reload the model

The tool flow must match the UI behavior so that preset updates behave consistently whether triggered by direct UI interaction or through Lemonade tools.

Acceptance criteria

• A loaded model no longer has to be manually unloaded and reloaded just to change its preset

• Selecting a different preset while the model is loaded enables an Update preset button

• The Update preset button appears next to the Unload button

• Clicking Update preset applies preset changes that do not require a reload directly

• System prompt changes are applied without reloading the model

• Clicking Update preset triggers a reload when the selected preset change requires it

• Reload-requiring preset changes are handled automatically without forcing the user to manually unload and load the model

• The same update preset mode is exposed through Lemonade tools

• Lemonade tool requests such as “change the preset” use the same update logic as the UI

• UI-triggered and tool-triggered preset updates behave consistently

• Programmatic semantics verified for screen readers:

  • roles
  • accessible names
  • states

• Keyboard operability verified where applicable

• Playwright/axe-core a11y tests cover the change

• All tests pass with npm test

• Progress and challenges recorded as comments on this issue

• PR opened against kpoin/ui-testing

Tracked by Squad. Assigned: @squad:mattingly (UI/Frontend), QA: Haise, review: Lovell.

[kpoineal]

📋 Queued behind #2355. This builds directly on the new model detail panel from #2355 (the Update preset button lives next to Unload in that detail view), so we're sequencing it right after the #2355 foundation lands. Will post here when implementation starts. @fl0rianr — flagging that the ''same flow via Lemonade tools'' + automatic-reload portions may touch areas beyond pure frontend; we'll scope those carefully against the 'lemond off-limits during POC' constraint and surface any questions here.

[kpoineal]

#2356 — UI/POC update-preset-while-loaded shipped (PR #2429)

Branch feat/gui3-update-preset-while-loaded → PR #2429 (base kpoin/ui-testing).

(a) What the UI/POC ships

• "Update preset" button in the model detail panel, next to Unload, shown only when a model is loaded AND a different preset is linked than the one it's running (linked ≠ running).
• Live path (sampling, system prompt, tools toggle): applies with no reload → inline "applied live, no reload needed" status.
• Reload path (recipe_options: ctx_size/backend/device/args/steps, or engine_hint): automatic reload flow with a "Reloading…" spinner/status — no manual unload/load.
• Client-local running-preset store + classifyPresetChange() (live/reload/none) decision in the mock.
• a11y: polite role="status" live region, model-naming aria-label (states "(reloads the model)" for reload changes), aria-busy, focus moves to Unload on success, reduced-motion-safe spinner.
• Tests A154–A163 (10 new). All 178 pass, 7 skipped, 0 failed.

(b) Explicitly DEFERRED to the backend team (lemond is off-limits to the UI POC)

• The real reload mechanics — lemond reinitializing the loaded model in place (no client-issued unload/load).
• The Lemonade-tools "change the preset" integration — it must call the same update logic so tool-triggered and UI-triggered updates are identical.

(c) Proposed window.api / HTTP contract (full doc: prototype/ui-redesign/docs/UPDATE_PRESET_CONTRACT.md)

POST /api/v{0,1}/update-preset
{
  "model_name": string,
  "preset_id":  string,
  "mode": "live" | "reload",
  "recipe_options"?: object,   // mode="reload"
  "sampling"?:       object,   // mode="live"
  "system_prompt"?:  string|null // mode="live"
}
// live   → apply request-time fields, NO reinit, 200 when applied
// reload → reinitialize in place (lemond does the unload+load), 200 when ready

api.updatePreset(modelName, presetId, mode: 'live'|'reload', payload?): Promise<unknown>

Live-vs-reload field split (please confirm):

Kind	Fields
reload	recipe_options (ctx_size, backend, device, args, steps, cfg…), engine_hint
live	sampling (temperature/top_p/top_k/repeat_penalty), system_prompt_id, system_prompts, tools_enabled
none	everything else (name, description, applies_to, id)

@fl0rianr — could you confirm (1) the endpoint shape (dedicated update-preset vs. an update_preset flag on load), (2) the live-vs-reload field split above, and (3) whether preset_id stays opaque to lemond (UI resolves fields) or lemond resolves presets from a shared registry? Once confirmed, the backend team can implement the reload + tools wiring consistently with this POC.

[fl0rianr]

solved