phughk/ottyl
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Remove ticket 049 (implemented: profiles stored inline in settings.json)

Browse Source 
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XFUNZwCvz3kcod3352ZR2o
This commit is contained in:
Hugh Kaznowski
2026-09-06 02:03:49 +01:00
co-authored by Claude Sonnet 5
parent 7a38d008fd
commit 7efaaa12f1
1 changed files with 0 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tickets/049-inline-profiles-into-settings-json.md
-57
View File
@@ -1,57 +0,0 @@
# 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.