mirror of
https://github.com/ksyasuda/SubMiner.git
synced 2026-03-27 06:12:05 -07:00
1.9 KiB
1.9 KiB
id, title, status, assignee, created_date, labels, milestone, dependencies, references, parent_task_id, priority
| id | title | status | assignee | created_date | labels | milestone | dependencies | references | parent_task_id | priority | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| TASK-239.1 | Add profile-aware config foundations and profile selection flow | To Do | 2026-03-26 20:49 |
|
m-2 |
|
TASK-239 | high |
Description
Introduce the foundation for local multi-profile use so users can keep separate setups for different workflows without hand-editing or swapping config files manually. Keep the first slice intentionally narrow: named local profiles, explicit selection, separate config/data paths, and safe migration from the current single-profile setup. Do not couple this task to cloud sync or remote profile sharing.
Acceptance Criteria
- #1 Users can create/select a named local profile and launch SubMiner against that profile explicitly.
- #2 Each profile uses separate config and data storage paths for settings and profile-scoped runtime state that should not bleed across workflows.
- #3 Existing single-profile users migrate safely to a default profile without losing settings.
- #4 The active profile is visible in the launcher/app surface where it materially affects user behavior.
- #5 Tests cover profile resolution, migration/defaulting behavior, and at least one end-to-end selection path.
Implementation Plan
- Design a minimal profile storage layout and resolution strategy that works for launcher and desktop runtime entrypoints.
- Add profile selection plumbing before changing feature behavior inside individual services.
- Migrate config/data-path resolution to be profile-aware while preserving a safe default-profile fallback.
- Verify with config/launcher tests plus targeted runtime coverage.