ottyl/tickets/049-inline-profiles-into-settings-json.md

049 — Store profiles inline in settings.json instead of a separate profiles.json

Summary

Profile data is currently persisted as its own file, separate from settings.json. Settings (src/settings.rs:68) only holds a Profiles pointer struct (names, active_profile, profiles_dir, src/settings.rs:56-63) while the actual Profile/Dashboard/param and metric declarations live in ProfileStore, serialized as a single profiles.json inside profiles_dir (src/profile.rs:1 doc comment, profiles_store_path at src/profile.rs:491-492, loaded/saved via ProfileStore::load/save at src/profile.rs:503,557). Every mutation path in ProfileStore (create, delete, record_param_declaration, record_metric_declaration, create_dashboard, save_dashboard, delete_dashboard, set_active, etc.) takes both a store_path and, separately, settings/settings_path to keep the two files in sync. This ticket folds profile storage into settings.json so there's a single source of truth file instead of two files that must be kept consistent.

Scope

• Move the profile list (currently ProfileStore.profiles: Vec<Profile>) into Settings itself, replacing the Profiles { names, active_profile, profiles_dir } pointer struct with the actual profile data (keep active_profile as a field alongside it).
• Update ProfileStore (or fold it directly into Settings) so all mutation methods read/write through the single settings.json via Settings::save/Settings::load, instead of maintaining a separate store_path/profiles_store_path.
• Write a one-time migration: on load, if a legacy profiles.json exists under the configured profiles_dir and settings.json has no inline profiles yet, read it in, merge into Settings, save, and (after a successful save) remove or rename the old file so it isn't re-migrated.
• Update every call site currently passing both a settings path and a profiles store path (src/api.rs, main.rs, tests in src/profile.rs) to the new single-path API.
• Keep CSS import/export (src/settings.rs import_css/link_css, which already write separate CSS files referenced from settings.json) as-is — this ticket is scoped to profiles only.

Acceptance criteria

• A fresh install has exactly one persisted file, settings.json, containing profiles, dashboards, and declarations inline — no profiles.json is created.
• An existing installation with a legacy profiles_dir/profiles.json is migrated automatically on next load: profiles appear inline in settings.json, and the old file is removed/renamed so migration doesn't repeat on subsequent loads.
• All existing profile/dashboard/declaration CRUD behavior (create, delete, set active, record param/metric declarations, dashboard CRUD) is unchanged from the user's perspective, verified by porting the existing src/profile.rs tests to operate against Settings directly.

Depends on

None.