xtream-electron

# Xtream Electron ## Read First - `docs/architecture/xtream-portal-compatibility.md` - `docs/architecture/portal-detail-navigation.md` - `docs/architecture/sqlite-db-worker.md` - `docs/architecture/vod-multi-source.md` ## Ownership And Runtime Routed screens live in `libs/portal/xtream/feature`; API, cache, Signal Store, and data sources in `libs/portal/xtream/data-access`; collection services and reusable multi-source discovery/resolution in `libs/portal/shared/data-access`; reusable views in `libs/portal/shared/ui`; pure contracts/helpers only in `libs/portal/shared/util`. Screen-session multi-source orchestration stays in the Xtream feature. Select `ElectronXtreamDataSource` only through `RuntimeCapabilitiesService.supportsXtreamSqliteDataSource`; otherwise use the PWA data source. A generic `window.electron` check is not the capability contract; existing favorites/recent branches that still use one are migration debt, not precedent. ## Data And Navigation Contracts - Xtream identity is playlist + normalized content type + provider `xtream_id`; collection keys include type and ID. Never resolve colliding live/movie/series IDs by number alone. Distinguish SQLite row IDs from provider `xtream_id` / `stream_id` / `series_id`. - Browse and search use canonical item routes. Favorites/recent use collection-owned inline detail. Preserve enough provider/route identity to recover hidden categories without sending a local database ID to the API. - Sparse VOD publishes the fallback selection first and recovers its provider category in the background. A playable source is one complete positive stream-ID + extension pair; never combine fields from incomplete candidates. - VOD multi-source is capability-gated, owner-scoped, Electron-only Xtream-to-Xtream movie behavior. Its reusable core belongs in portal shared data access; the screen session/host belongs in the Xtream feature. `XtreamStore` composes portal, content, selection, search, EPG, player, favorites, recent items, and playback positions. On the SQLite path, large import/search/delete/restore work remains worker-backed. Renderer-visible DB progress and cancellation use `operationId`. Xtream API requests use `requestId`, import sessions use `sessionId`, and the DB worker also has an internal transport request ID; never conflate any of them. ## Validation Run both data-source specs plus affected Xtream store/feature tests. Use the closest atomized flow: - `web-e2e:e2e-ci--src/xtream.e2e.ts` - `electron-backend-e2e:e2e-ci--src/xtream-responsiveness.e2e.ts` - `electron-backend-e2e:e2e-ci--src/xtream-vod-details.e2e.ts` - `electron-backend-e2e:e2e-ci--src/vod-multi-source.e2e.ts`