BasedHardware/omi

Problem In the macOS conversation detail, choosing Change for the summary opens a fixed-size Select App sheet containing every memory-capable marketplace app. The sheet has no search field and no installed-only view, so users with a small set of installed summary apps must scroll through the full catalog to switch between them. This differs from web/mobile, where summary selection is focused on apps installed for the current account. Featurebase report (2026-09-11): “Search/show connected apps for summaries” — 1 requester. The supplied screenshot shows the unfiltered macOS sheet. Reproduction Install two or more apps that can generate conversation summaries. Open a conversation in the macOS desktop app. In the summary header, choose Change. Observe that the selector lists all memory-capable marketplace apps with no search or installed-only control. Current-main evidence desktop/macos/Desktop/Sources/MainWindow/Pages/ConversationDetailView.swift passes: appProvider.apps.filter {

Product impact: UX / Polish — locked conversation cards are hard to read in the Flutter app. Steps: Open Home with locked conversations, using light mode. Current: A dark translucent strip covers part of each card. The conversation title remains readable behind “Upgrade to Unlimited,” so the two labels overlap. Expected: A subtle frosted preview obscures the locked conversation details, with a small, readable lock and upgrade action. It should work in light and dark mode and with larger text. iPhone screenshot: Fix and verified iPhone screenshots: #20044.

Leftovers from the #12697 review, all still present on main: Stale provenance string. backend/utils/llm/working_observations.py persists "source": "utils.llm.working_memory.extract_l1_memory_archive_items_from_text", but that module was deleted. Point it at the surviving utils.llm.working_observations function. Nothing parses the old string. Stale doc citations. backend/docs/memory/domain_model.md still cites the deleted working_memory.py, l2_memory_routes.py and durable_memory_patches.py (4 references) as current code locations. Update them to the surviving canonical modules. Dead exports. memory_contracts.py exports L2MemoryRoute, SourceBackedMemoryCandidate and DURABLE_MEMORY_PATCH_FACT_SOURCE, which have no remaining external callers. Remove them, or wire them in if a caller should exist. Acceptance criteria One PR fixes all three; confirm each with git grep against current main first. The dead-code ratchet and backend tests (via backend/test.sh) pass.

Context Omi extracts action items from conversations using LLMs. However, if a conversation is processed without calendar context, the LLM has to parse transcripts with generic labels like "Speaker 0" or "Speaker 1". The extraction engine currently cannot associate these labels with actual user identities, causing two primary issues: Vague Action Items: The LLM writes tasks without specific ownership (e.g. "Send the quarterly sales report") rather than attributing them correctly (e.g. "Send report to John"). Attribution Errors: The LLM frequently extracts tasks assigned to other participants because it cannot distinguish the primary user from the other speakers. In real-world usage, as shown in user transcription feeds, the app groups audio segments into generic speaker blocks like Speaker 1, Speaker 2, and Speaker 3. Because the LLM has no knowledge of who these speakers represent in relation to the primary user, it cannot reliably target the user's actual tasks. Important Note: Whi

Context In meetings with 3 or more participants, the current online speaker diarization algorithm fails to accurately separate speakers. Speaker labels get merged or swapped, which compromises transcription accuracy and downstream features like action item extraction. A real-world example of this issue in action shows generic tags like Speaker 1, Speaker 2, and Speaker 3 displayed in the transcription feed. Under Speaker 1, the text simply reads "You.", illustrating how the system struggles to resolve who the primary user is versus other meeting participants. Important Note: While the screenshot illustrates this in the mobile app UI, the solution must be entirely backend-driven and platform-agnostic. Do not build any dependencies on client-side screen layout or UI state. Visual Comparison: Online vs. Offline Clustering graph TD subgraph "1. Online Centroid-Based (Current: Centroid Drift)" S1["Segment 1: Spk A"] --> C1(Centroid A) S2["Segment 2: Spk B