Local-Only User Profiles

Decisions taken

1. The core choice: store-per-profile

Two ways to scope SwiftData per user:

• (A) Add profileID to every model, filter every query.
• (B) Give each profile its own store file.

Application Support/
  profiles.json                    ← registry (outside every profile)
  Profiles/
    <uuid>/Peregrine.store         ← SwiftData, all 8 @Model types
    <uuid>/Peregrine.store-wal/-shm

+ per profile: UserDefaults(suiteName: "profile.<uuid>")

2. Three stores, three answers

2.1 UserDefaults redirection

Two kinds of reader, two mechanisms:

• @AppStorage readers (lineupStreamSpeed, lineup.answerMode, heckler.setting, contentMode) are redirected wholesale by .defaultAppStorage(session.defaults) on the root view. No call-site changes.
• Direct UserDefaults.standard readers — GameFamiliarity (~30 call sites across every game view) and ShakedownGameView:197-208. Not @AppStorage, so defaultAppStorage doesn't reach them.

Rather than thread a defaults: argument through 30+ call sites, one injection point in Core:

public enum ProfileScope {
    /// The active profile's defaults. Set once at activation;
    /// `.standard` only before a profile is chosen (and in unit tests).
    public static var defaults: UserDefaults = .standard
}

GameFamiliarity's existing parameter defaults change from = .standard to = ProfileScope.defaults — its explicit-injection test seam is preserved and all 30 call sites keep working unchanged.

2.2 What deliberately stays global

• Keychain API key. One key, yours, paid by you. Per-profile keys would mean every tester needs their own Anthropic account — absurd for a playtest. Consequence: a tester could burn your API credit by capturing. Mitigation included — profiles carry a kind (.owner/.tester/.test) and Capture is hidden for non-owners. Testers play the corpus; they don't build it.
• CaptureInbox (App Group share-extension drop-box). A transient queue between two processes, not durable state. It drains into whichever profile is active. Since Capture is owner-only, that's effectively always you. Accepted, not solved.

3. Files

New — PeregrineCore/…/Profiles/

New — Peregrine/Profiles/ (app target)

Modified

4. Launch behaviour

launch
 ├─ -demoData present?  → activate fixed UI-test profile
 │                        (uuid 00000000-…-0001, created on demand;
 │                         -resetDemoData wipes it first). Picker skipped.
 └─ otherwise           → ProfilePickerView
                            last-played listed first as "Continue as <name>";
                            everything else below.

5. One addition beyond what you chose

6. Build order

1. Core: PlayerProfile, ProfileRegistry, ProfileScope + registry unit tests (round-trip, corrupt-file recovery, atomic write).
2. GameFamiliarity / ShakedownGameView defaults redirection. Build green, behaviour unchanged — ProfileScope.defaults is still .standard.
3. ProfileManager + per-profile container/defaults construction.
4. PeregrineApp restructure + UI-test bypass. Verify existing UI tests pass here — highest-risk step.
5. ProfilePickerView + ProfileEditorView (create / blank / copy-library).
6. Reset + Delete.
7. ProfileArchive + export share sheet.
8. ProfileSeeder DEBUG presets.
9. xcodegen generate, build, run the UI test suite.

Final review

Edge cases this plan handles poorly

• CaptureInbox has no profile. Share-extension images drain into whoever is active. Mitigated by owner-only Capture, not solved. If a tester ever needs capture, this needs revisiting.
• Deleting the active profile. Must null the session and release the ModelContainer before removing files, or SQLite holds open handles. Handled explicitly — but it's the kind of thing that fails only on device.
• A profile whose store fails to open (corrupt, schema drift from a downgrade). Current code fatalErrors on container failure; per-profile that means one bad profile bricks launch. I'll surface it as a broken row in the picker with a "Reset this profile" affordance instead of trapping.
• No archive import. Export writes JSON out; there's no path to load a tester's archive back in as a profile. Deferred deliberately — that's a real feature (schema versioning, conflict handling), not a small one. If replaying playtest data on your device matters, say so and I'll scope it separately.

Worth considering

If corpus duplication becomes annoying, the alternative is profileID on the seven progress models with Question left global — but that requires severing the Question.drills relationship (store questionID: UUID on DrillResult instead). Cleaner data model, meaningfully more invasive. Not now.

As built — where the plan was wrong

Four things the plan missed. The first two would have silently destroyed existing data; both were caught by running the thing on a simulator rather than by reading the code.

One existing test changed: testAPIKeySavesToKeychain now launches with -demoData, because a bare launch legitimately opens the picker now. No other existing test was touched.

Also added beyond the plan

• -resetProfiles (DEBUG): wipes the registry, every profile store and every profile defaults suite. Without it the picker itself was untestable — every other suite passes -demoData precisely to skip it.
• ProfileUITests — 9 tests: the gate, creation, name validation, switching, cross-profile isolation, re-entry, registry durability, seeded presets.
• ProfileRegistryTests — 17 Core tests: round-trip, tolerant decoding, corruption recovery, layout invariants, defaults isolation.