Separate Search Row Identity from Canonical Podcast Data

Problem Search/trending currently use feedURL for two different jobs:

1. Canonical podcast data.
2. Stable UI identity for a result row.

When an iTunes result maps to an already-saved podcast whose canonical feedURL differs, using the real feedURL fixes the model but destabilizes the list. Using the search feedURL stabilizes the list but makes the bridged Podcast partially synthetic.

Background tasks (BGProcessingTask / BGAppRefreshTask) schedule and execute correctly on dev builds but fail silently on TestFlight/release builds. BGTaskScheduler.submit() returns success (no throw), but the system daemon dasd rejects the request internally.

A. Task blocks where errors silently disappear

These are Task blocks containing try with no error handling at all. The errors vanish into the void.

┌──────────────────────────────┬─────────┬─────────────────────────────┬────────────────────────────────────────┐ │ File │ Line │ Function │ What fails silently │ ├──────────────────────────────┼─────────┼─────────────────────────────┼────────────────────────────────────────┤ │ ManagingEpisodes.swift │ 80-85 │ queueEpisodeOnTop │ getOrCreateEpisodeID + queue.unshift │ ├──────────────────────────────┼─────────┼─────────────────────────────┼────────────────────────────────────────┤

You want a persistent Claude Code remote-control session running in the background on your Mac, accessible from your phone at any time. This avoids needing to manually open a terminal and run claude remote-control every time.

File: ~/Library/LaunchAgents/com.jubi.claude-remote.plist

A LaunchAgent that:

• If discussing Swift, SwiftUI, and iOS: Consult the apple-docs and apple-deep-docs mcps for up to date information.

• Never create commits or push unless the humans explicitly ask.
• Assume the working tree may hold user edits; respect them and avoid resets or reverts.
• Stay sandbox-friendly: ask for elevated access only when instructions require files outside the workspace.

• Don't actually try to build or test unless the user explicitly asks.

⏺ Summary of All Three Bug Reports

All three reports are from the same user listening over Bluetooth AirPods with episodes played from local cache while the app is backgrounded. Two are related to the same root cause, and one is a distinct bug.

Bug 1 & 3: Audio Repeating (Feb 18 & Feb 21) — !con Error

Both "repeating" reports are manifestations of the known !con error (OSStatus 560164718). The new finding: the audio loops/repeats for ~10-15 seconds before

❯ can you walk me through these xcode tasks

⏺ Sure. Here's the step-by-step walkthrough:

1. Create the Widget Extension Target

2. In Xcode, go to File > New > Target

3. Search for Widget Extension

4. Name it PodHavenWidget

5. Uncheck "Include Live Activity" and "Include Configuration App Intent"

⏺ Based on my analysis, none of the changes since commit 1183550f4fbc would have caused this issue. Here's why:

Changes to playback code:

1. All the PlayManager/PodAVPlayer changes are our debugging additions - These are purely additive (logging, error handling, isCurrentItem check). They don't
   modify any core playback behavior.
2. The only pre-debugging change was d08b406f which makes pause() async to save position immediately - this doesn't affect playback mechanics.

Other changes:

• HTMLText parsing improvements
• Chapter navigation (new feature)