mirror of
https://github.com/awizemann/scarf.git
synced 2026-05-10 02:26:37 +00:00
Alan Wizemann
aafd9643a4
Pass-1 revealed that iOS should hold more than one server (users want to hop between a home server and a work server from a single app). Storage was the first block: v1 stored exactly one config under a fixed key and one Keychain item under account "primary". Extend both stores with ID-keyed methods while keeping the v1 singleton API for back-compat during the transition: - IOSServerConfigStore: add listAll, load(id:), save(_🆔), delete(id:). Singleton load/save/delete now operates on the "primary" entry (lowest UUID by string sort) — deterministic, no surprise mutation of other servers when a singleton caller saves. - SSHKeyStore: same treatment. Keychain accounts for v2 entries are `"server-key:<UUID>"`. Migration is one-shot and embedded in `listAll()` on both stores: - UserDefaults: if the v1 key `com.scarf.ios.primary-server-config.v1` is present AND v2 key `com.scarf.ios.servers.v2` is empty, load the v1 config, insert under a fresh ServerID in v2, delete v1. Idempotent — no-op once v1 is gone. - Keychain: if no `server-key:*` accounts exist AND the legacy `"primary"` account does, copy the bundle to a fresh ServerID slot and delete the legacy item. Both migrations preserve the v1 single-server experience: a user who updates the app without re-onboarding still sees exactly one configured server on first launch of the new version, with the same SSH key and the same host details. No data loss. InMemory stores updated to match (dictionary-keyed internally). Mac + iOS schemes both build clean; ScarfCore swift build green. Callers (RootModel, OnboardingViewModel, ChatController, ScarfIOSApp transport factory) still use the singleton API and will migrate to ID-keyed in 3.2-3.5. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>