Per-mode 'Saved Configs' / Presets (distinct from cross-workflow favorites)

[thomas-stegemann]

Why

Two concepts have been conflated under "favorites" in the workbench's evolution:

1. A favorited resource — URI + method + a request shape. Protocol-independent, cross-workflow. ("This /pets endpoint matters to me.")
2. A named workflow configuration — a complete setup for one workflow. Bench params, scan profile, mock setup, parallel-session config. Workflow-specific. ("My standard 100-session p95 bench against staging.")

Concept #1 lives at the cross-workflow level — split out to #139's Home/Launchpad design.

Concept #2 lives per-workflow. This issue is about #2.

Proposal — per-mode "Saved Configs" (Profiles / Presets / Templates)

Every workflow mode that has a setup form gets a small "Saved configs" affordance:

• Recordings: save a named replay setup (which env, which assertions, stagger, retry policy).
• Mocks: save a named mock spinup config (recording id + port range + chaos params).
• Benchmarks (Benchmarks: first-class surface (single / collection / recording / random / scheduled) #131): save a named bench profile (single / collection / recording / random + concurrency + warmup + percentile targets).
• Parallel sessions (Parallel sessions for recordings / collections (phase 1 local, phase 2 distributed) #132): save a session-sharding preset (count + stagger + per-session env policy).
• Security (Threat-Model + Fuzz): save a scan profile (tier toggle, ranked-only filter, template set).
• Proxy: save a MITM preset (target allowlist, capture filters, replay-on-match rules).
• Catalogue (URL / service catalogue providers (local / http / consul / kubernetes / agent) #136): save a catalogue-source config (provider type + URL + auth).

Storage

Per-mode store under bowire_presets_<mode> (localStorage today; per-workspace store once #116 lands). Each preset entry:

{
  "id": "uuid",
  "name": "100-session staging p95",
  "createdAt": "...",
  "lastUsedAt": "...",
  "config": { /* mode-specific config blob */ }
}

UI

• A "Save preset…" button at the bottom of each workflow's setup form.
• A picker at the top: "Load preset…" → dropdown of saved configs for this mode.
• A small "★ Set as default" toggle per preset — default config auto-applies on mode entry.

Distinct from favorites

• Favorites = resource markers (cross-workflow, single store, bowire_favorites).
• Presets = workflow configs (per-mode, bowire_presets_<mode>).
• Naming uses "preset" / "profile" in the UI — never "favorite" — to avoid confusion.

Acceptance

• Each workflow mode with a setup form supports saving + loading presets.
• Per-mode localStorage slot (bowire_presets_<mode>).
• "Save preset…" + "Load preset…" + "Set as default" affordances.
• Presets appear in their mode's sidebar list (peer with the mode's other items).
• No naming conflict with favorites: docs + UI consistently use "preset" / "profile" / "template" — never "favorite" for this concept.

Composes with

• Per-mode favorites filter (drop the standalone Favorites tab) #139 Cross-workflow favorites + Home mode — favorites are resources; presets are configs. Different stores, different stems.
• Activity rail (left) — switch workbench focus by use case (dev / security / perf / mocks / …) #133 Activity rail — each mode declares whether it supports presets.
• Workspaces — named, switchable contexts that bundle URLs / envs / collections / AI config #116 Workspaces — presets scope per-workspace.

Out of scope

• Importing presets from a remote registry — separate concern, possibly catalogue-driven (URL / service catalogue providers (local / http / consul / kubernetes / agent) #136).
• Sharing presets between users — workspace-scoped is local-only for v1.