Created tickets relating to legends, reserved params, timeline ordering, css, etc

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

@@ -0,0 +1,57 @@
+# 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.