# DeepDive — Claude Design Brief **Audience:** A fresh Claude Design session. Paste this entire file in as the opening message. **Companion doc:** `MULTITOPIC_REDESIGN.md` (in this same folder) contains the full functional architecture. Read it after this brief for depth. **What we need back:** see §7. --- ## 1. Identity & context You're being asked to design **DeepDive**, an iOS app being expanded from a single-topic music discovery app into a multi-topic **research arm** for the **Everplay-Tech** app family. Sister apps in the family — AiMANAC, Satcheli, Mailsloth, baton, DeepDive — each ship as standalone $1–$10 one-time-purchase SKUs on the App Store. They have **no cloud account, no analytics, and no Everplay-Tech-operated backend** (the family's "no phone home" principle — vendor doesn't run cloud infra the customer depends on; pure clients like DeepDive use no backend at all, AiMANAC's backend is run by the customer themselves). When two or more of them are installed on the same device, they share state via an opt-in iOS App Group "trust mesh," gaining cross-app capabilities. Each app must remain **fully functional standalone**; the trust mesh is additive, not load-bearing. DeepDive today (build 28) is an iOS native SwiftUI app for music discovery. Users browse from bands → albums → credits → people, save to a personal Collection ("Milkcrate"), and an on-device LLM (Apple FoundationModels + Phi-4) provides grounded summaries. The app has a strong existing "synth" design language with custom panels, colors, chips, and buttons under `ios/DeepDive/Design/`. The new design extends or pivots that language; it doesn't fight it. The redesign generalizes DeepDive from one topic (Music) to many. The unit of topic behavior is the **Deep Diver** — a topic-specific app-within-an-app. Six Deep Divers ship at install; users author more from inside the app (paste-driven, on-device) or via HELM (a tool layer in AiMANAC) when AiMANAC is also installed. --- ## 2. What's locked — do not redesign these These are decisions XZA has already made. Your design must honor them. ### Behavior - **No persona.** The LLM is a capability, not a character. There is no "concierge," no assistant voice, no "record store employee." The user-facing surface is an explicit **AI Help** button per Deep Diver. Clicking it triggers a contextual LLM call grounded on the user's local data. No personification in copy, naming, or UI. - **Standalone-first.** Every flow must work when DeepDive is the only Everplay-Tech app installed. AiMANAC adds capabilities (Vault backup, HELM-authored Deep Divers, open compendium discovery, richer multi-turn AI Help) but never gates base functionality. - **Paste-input is first-class.** Every input affordance — search, AI Help, Deep Diver authoring, source attachment — accepts **large paste input** (multi-paragraph text, URL lists, JSON manifests). Paste is the user's primary high-bandwidth channel into the app. The design must invent a consistent paste-affordance vocabulary that scales from "type a word" to "paste a 2,000-word essay" without breaking visually. - **User-initiated population.** The app does not auto-crawl or background-fetch. Users issue explicit requests; the app queries attached metadata sources; users navigate the response. Fetches are explicit, scoped, visible. - **On-device-only learning. Behavior data never leaves the device.** Each Deep Diver tracks the user's local engagement (views, dwell, saves, dismisses) in an on-device Backpack. The local LLM reads those counters and tunes the **Suggestions** surface. Composite Deep Divers (Code & Models, Markets & News) have two sub-axes each; a user who only engages one axis sees the other stop pushing while remaining reachable. **Nothing about this loop egresses** — not to an Everplay-Tech server (none exists), not through the trust mesh by default. The design must make attunement *feel* personal without ever signaling surveillance — no "we noticed you…" copy, no behavior dashboards. ### Tech / platform - iOS native SwiftUI; iOS 17+; arm64 simulator only. - On-device LLM: Apple FoundationModels (iOS 26+) → Phi-4 GGUF (local) → deterministic rules fallback. - Offline-first SQLite cache. - Widget extension ships. - CloudKit private DB for Collection backup. - App Group `group.net.llmtech.aimanac` is the shared trust-mesh container when AiMANAC is installed. - The existing synth design system lives in `ios/DeepDive/Design/` (SynthColors, SynthSpacing, GlassPanel, SynthButton, Chips, etc.) — your starting vocabulary. ### Privacy contract — non-negotiable - No analytics. No telemetry. No tracking. No account. - Backpack content stays local by default. App Group mirroring (to share with AiMANAC) is opt-in, default OFF, and one-way (DeepDive → mesh, not the other way unless explicitly granted). - Suggestions must not display anything that reads as surveillance. The user should feel the personalization without being told their behavior was analyzed. --- ## 3. What's new — this is what you're designing DeepDive becomes a multi-Deep-Diver app. Six Divers ship at install. Music remains (refactored). Users can author more. ### The shipped six 1. **Music Deep Diver** (single-axis) — existing app, refactored. Artists → albums → credits → people. MusicBrainz / Discogs / Bandsintown / Wikipedia attached. 2. **Code & Models Deep Diver** (composite — sub-axes `Code` + `Models`) — GitHub + Hugging Face. Code-axis: orgs → repos → contributors → releases. Models-axis: orgs → models → datasets → papers → spaces. **Final display name is yours to propose.** 3. **Markets & News Deep Diver** (composite — sub-axes `Markets` + `News`) — public finance APIs + RSS aggregators + Wikipedia. Markets-axis: tickers → companies → filings. News-axis: topics → sources → articles → mentioned entities. **Final display name is yours to propose.** Marquee case for sub-axis attunement. 4. **Books Deep Diver** (single-axis) — OpenLibrary / Wikidata / Wikipedia. Title → author → editor → translator → publisher → series. 5. **Films Deep Diver** (single-axis) — TMDb / Wikidata / Wikipedia. Title → cast → crew → studio → soundtrack. 6. **Art Deep Diver** (single-axis) — Wikidata / Wikimedia Commons / Smithsonian Open Access / Met Open Access / Wikipedia. Work → artist → movement → period → collection. ### Three concepts to invent visual vocabulary for These don't exist in the current app. You're inventing their visual language. #### a. Composite Deep Diver A Deep Diver with two sub-axes. The user is inside the Diver looking at one axis; the other axis is reachable and present but not currently active. Attunement may shift which axis is dominant over time, but both must remain easily switchable. **Bad patterns:** tab-bar-in-tab-bar (visually crowded, redundant with the app-level picker); hidden in a settings menu (under-discoverable); modal switch (heavy). **The interaction must signal "two related lenses, same Diver."** Slider, toggle, segmented switch, gesture, dual-mode split, animated cross-fade — your call. Whatever you propose, it must work in landscape *and* portrait, with Dynamic Type at max, and with VoiceOver navigation. #### b. Metadata Compendium chip A "Metadata Compendium" is a knowledge source attached to a Deep Diver — MusicBrainz, GitHub, Wikidata, etc. The mental model is **attaching GitHub or Hugging Face as a reference in a Claude Desktop prompt**. Each compendium has: an identity (name, icon, color), a status (healthy / degraded / quota exceeded), capabilities (search / get / list / paginate), and an attachment relationship to one or more Deep Divers. Design needed: how chips look in the Deep Diver header; how the per-compendium status renders (LED? badge? color-coded ring?); how a user adds or detaches a compendium; how the picker for "available compendiums in the registry" feels — a sheet, a grid, a search-as-you-type list? #### c. Suggestions surface (attunement-driven) A surface inside each Deep Diver that proposes "what to look at next," tuned by the user's local engagement counters. The marquee case is the Markets & News composite: a user who only reads News will see News-side suggestions dominate; Markets remains reachable but stops pushing. **Hard constraint:** the surface must not signal surveillance. No "based on your activity," no "we noticed you…," no behavior dashboard. The user should feel the personalization land *as the app's voice*, not as a feedback receipt. Design needed: layout, copy register, item card shape, refresh / dismiss / pin affordances, empty-state when attunement is neutral. ### Other new components - **Deep Diver picker (Home).** The entry point. Six initial Divers + a "Create new" affordance + (when AiMANAC is installed) a section / treatment for HELM-authored Divers. Shape is yours: grid, list, carousel, drawer, tab bar with overflow, something synth-native. - **AI Help button + interaction.** Per-Diver button. Modality (sheet, drawer, inline, full-screen?) and how grounded context is *visibly shown* to the user (so they can see what the LLM is reading) — your design. - **Paste-driven Deep Diver authoring wizard.** Standalone path. The user pastes a topic description (potentially long), pastes / selects sources, optionally pastes a JSON manifest. The on-device LLM helps suggest compendiums (only from a curated registry — see §4). Tone is "compose your own research lens," not "configure software." - **Backpack browser.** The local memory store. The user can inspect recent events, search, and "forget" specific entries (writes a tombstone). Whether the browser is a primary surface or tucked behind settings is your call — but the user must be able to find it without help. - **Cross-topic Collection.** Today there's a single Milkcrate. Going forward: is there one cross-topic Collection? Per-topic groupings? A user-controllable toggle? - **Markdown export UX.** Files-app share sheet vs in-app destination picker vs both. --- ## 4. Standalone vs HELM-mode signaling This is subtle and load-bearing. Two creation flows exist: - **Standalone (always available):** the user creates a Deep Diver via paste. The on-device LLM selects only from a **curated CompendiumRegistry** of known-good public APIs (~15 sources at v1: MusicBrainz, Discogs, Wikipedia, Wikidata, OpenLibrary, TMDb, GitHub, Hugging Face, Smithsonian, Met, Wikimedia Commons, Yahoo Finance, RSS readers, …). This prevents hallucination and keeps the app's promise intact. - **HELM (only when AiMANAC is installed):** HELM can author manifests with **arbitrary** compendiums — pasted compendium specs, web-researched adapters, PDF context ingestion. Open discovery; richer creation. **Design challenge:** when the user is in the standalone creation wizard, they shouldn't feel boxed in. When they're in HELM-mode authoring, they shouldn't feel like the standalone experience was "lesser." Signal the *capability* of HELM mode without making standalone feel cropped. Don't say "upgrade" or "premium" or "unlock." This is not a paywall. Standalone DeepDive is a complete app; HELM is a sibling-app expansion. Find language that respects both. --- ## 5. The flows to design For each, describe the user's mental state, what they see, what they can do, and how it transitions. 1. **First launch — existing music user.** They open Build 29 (or whatever the redesign ships as) for the first time. Their Music collection is intact. They see "Music + 5 new neighbors," not a different app. How does the picker land for someone who hadn't been told this was coming? 2. **First launch — brand-new user.** No music collection, no priors. The picker is their first impression. What do they see? What do they want to tap? 3. **Inside the Music Deep Diver.** The current Discover / Collection / Insights triad — does it survive? Become per-Diver freedom? Collapse to a single sectioned scroll? Up to you, but justify. 4. **Inside the Markets & News Deep Diver (composite).** A user who's never opened it; attunement is neutral. Both sub-axes are equally present. The sub-axis switcher you invent must be visible-but-not-loud. As the user clicks more on News-side items over a session, the Suggestions surface should subtly skew. Show before/after states. 5. **AI Help, in context.** User is reading about a film; they tap AI Help. What pops up? What can they paste in? How is the grounded context shown? How does the LLM's response land without sounding like a persona? 6. **Create a new Deep Diver (standalone, paste-driven).** Walk through the wizard. Show what the user types / pastes; what the LLM suggests; how the user accepts / edits; how the new Diver appears in the picker. 7. **HELM authors a Deep Diver, the user sees it appear** (only relevant if AiMANAC is installed). The Diver lands in the picker with provenance signaling. How does it look? Distinct or transparent? 8. **Backpack browser.** The user wants to find something they viewed last week. Show the entry point, the browser shape, the search/filter, the "forget" action. 9. **Compendium attachment & status.** Inside a Deep Diver, the user opens the compendiums view. Shows attached compendiums + status. They tap to add a new one from the registry. They tap to detach an existing one (with confirmation). 10. **Markdown export.** A user saves an entity (e.g., a film). They want a portable `.md`. Show the flow. 11. **Onboarding to the privacy contract.** Somewhere, briefly, the user should learn — without being lectured — that DeepDive is local-first, no-account, no-telemetry. Where? When? How? 12. **(Optional)** **Website companion** — if you conclude one should exist (see §6), design the in-app affordance that links out and the deep-link return that imports the resulting manifest. --- ## 6. Specific questions you must answer Don't punt these. Commit. Defend. 1. **Topic picker shape.** Grid, list, carousel, drawer, segmented tab bar with overflow, or something synth-native? 2. **In-Deep-Diver navigation pattern.** Keep the existing 3-tab triad? Collapse to a single sectioned view? Per-Diver freedom? 3. **Composite-Diver sub-axis interaction.** Slider, toggle, dual-mode, gesture, segmented switch? Justify. 4. **Suggestions surface.** Visual + interaction + copy register that signals attunement without surveillance. 5. **AI Help button placement + modality.** Where does it live in each view? What pops up when tapped? 6. **Paste-affordance vocabulary.** The consistent way "paste large input here" feels across every input in the app. Show three uses (search, AI Help context, Deep Diver authoring) using the same vocabulary. 7. **Compendium chip + management.** Visual treatment of chips, picker for attaching new ones, status indication. 8. **Backpack browser shape.** Primary surface or tucked away? Searchable? How does "forget" feel without being scary? 9. **Cross-topic Collection.** Unified timeline / per-topic groups / user toggle? 10. **HELM-authored entry treatment.** Badge? Section? Transparent? Don't make standalone feel inferior. 11. **Standalone-vs-HELM-mode signaling in the authoring wizard.** How is "you're in standalone curated mode" vs "you're in HELM open-discovery mode" visible without value-judging either? 12. **Empty-state for a brand-new user-created Deep Diver.** What does the picker thumbnail look like? What does the first view inside the Diver look like before any fetches have happened? 13. **Website companion.** Should one exist? If yes, what's the in-app affordance? How does the manifest return? If no, say no and explain why. 14. **Widget surface.** Per-Deep-Diver widgets vs topic-aware variants of the existing pair? 15. **Theming intensity ceiling.** Each Diver has a color + icon. How loud is theming? Reaches typography? Density? Background? Just accent? --- ## 7. What we need back from you Annotated screen mocks (sketches and annotations are fine; full Figma not required) for each flow in §5, plus: 1. **Component additions / extensions to the synth design system.** New components live in `ios/DeepDive/Design/` alongside SynthColors, SynthSpacing, GlassPanel, SynthButton, Chips. Tell us what to add and what to extend. 2. **A "paste-affordance pattern" definition.** Designed once, used everywhere. One name, one set of states, one interaction model. Show the three example uses called out in §6.6. 3. **Per-Diver theming spec.** Color tokens + icon set + theming-intensity rules per Diver. Use the six initial Divers as your worked examples. 4. **A one-page design rationale.** Why these choices? What did you reject and why? What does each choice commit us to downstream? This is what we'll read first when implementation starts. 5. **Explicit non-goals.** What does this design intentionally *not* try to do? What scope creep is fenced off? Future-XZA will be tempted to add things; non-goals defend the design. When you hand back: don't try to be exhaustive. Honest depth on the load-bearing flows beats shallow breadth across every screen. The hardest design problems are composite Diver navigation, the Suggestions surface, the paste-affordance vocabulary, and the standalone-vs-HELM-mode signaling. Spend your strongest thinking there. --- ## Appendix — files worth reading in the repo before designing - `MULTITOPIC_REDESIGN.md` (this folder) — full functional architecture. - `ios/DeepDive/Design/` — every file. The synth design language. - `ios/DeepDive/ContentView.swift` — current 3-tab root. - `ios/DeepDive/Views/ArtistView.swift` — the largest entity view today (75 KB); the credits-first exploration in concrete form. - `ios/DeepDive/Views/CollectionView.swift` — current Milkcrate. - `ios/DeepDive/Storage/AppGroupExporter.swift` + `ios/DeepDive/Models/DeepDiveExport.swift` — the trust-mesh export shape that survives the redesign. - `ios/DeepDive/Knowledge/KnowledgeOrchestrator.swift` — current LLM routing (Apple FM / Phi-4 / deterministic); the AI Help button will plug in here. - `README.md` (repo root) — the current product description.