2 Commits (048e4e85d5ceb6bbb9f6a6d2b2efbc259cc331ff)

Author	SHA1	Message	Date
Broque Thomas	cc44254bf9	Personalized playlist pipeline: auto-sync discover-page playlists ... Follow-up to the personalized-playlists standardization PR. New `personalized_pipeline` automation action syncs selected discover- page playlists (Hidden Gems / Discovery Shuffle / Time Machine / Genre / Daily Mix / Fresh Tape / The Archives / Seasonal Mix) to the active media server + queues missing tracks for download. Same pattern as the existing mirrored `playlist_pipeline` but two phases instead of four — no REFRESH (no external source to re-pull) and no DISCOVER (manager-backed snapshots are already metadata- matched). Pipeline shape: SNAPSHOT → SYNC → WISHLIST Where SNAPSHOT either reads the persisted track list from `PersonalizedPlaylistManager` (default) or refreshes it first when `refresh_first=true` (cron use case: regenerate Hidden Gems nightly and sync the fresh set). Shared helper extraction: PHASE 3 (SYNC loop) + PHASE 4 (WISHLIST tail) lifted out of mirrored `playlist_pipeline` into `core/automation/handlers/_pipeline_shared.py` as `run_sync_and_wishlist(deps, automation_id, playlists, sync_one_fn, sync_id_for_fn, ...)`. Both pipelines call it. Mirrored injects `auto_sync_playlist` as the per-playlist sync function; personalized injects a thin wrapper that launches `_run_sync_task` directly with a pre-built tracks_json. Same sync-state polling / progress emission / status counting / wishlist trigger logic — 0 duplication. Files added: - core/automation/handlers/_pipeline_shared.py - core/automation/handlers/personalized_pipeline.py - tests/automation/test_handlers_personalized_pipeline.py Files changed: - core/automation/handlers/playlist_pipeline.py: PHASE 3+4 replaced with shared helper call (~100 lines deleted, 1 helper invocation added; behavior identical). - core/automation/deps.py: new `build_personalized_manager` field (lazy builder so the pipeline gets a fresh PersonalizedPlaylistManager per run). - core/automation/handlers/__init__.py + registration.py: register `personalized_pipeline` action with the shared `pipeline_running` guard so it can't overlap mirrored. - core/automation/blocks.py: new `personalized_pipeline` block declaration with config_fields (kinds multi-select, refresh_first, skip_wishlist). - web_server.py: thread `_build_personalized_manager` into AutomationDeps construction. - All 5 automation test fixtures: `_build_deps` adds `build_personalized_manager=lambda: None` stub. - tests/automation/test_handler_registration.py: EXPECTED_ACTION_NAMES + EXPECTED_GUARDED_ACTIONS gain `personalized_pipeline`. Trigger schema: { "_automation_id": "...", "kinds": [ {"kind": "hidden_gems"}, {"kind": "time_machine", "variant": "1980s"}, {"kind": "seasonal_mix", "variant": "halloween"} ], "refresh_first": false, "skip_wishlist": false } Tests (14 new, 178 automation total): - _track_to_sync_shape: basic shape, source ID fallback chain, no-id returns empty string - empty config / non-list kinds / empty kinds list all return error + clear pipeline_running flag - _build_payloads_for_kinds: skips invalid entries, skips kinds with no tracks, refresh_first vs ensure dispatch, payload shape + sync_id format, manager exception swallowed continues - _sync_personalized_playlist: launches background thread + returns status='started' - happy path: stubbed sync_states drives helper to completion, flag cleaned up Full suite: 3383 passed. Note: the trigger UI block declares config_fields but the frontend doesn't yet render the `personalized_playlist_select` multi-select type — usable today via API; polished UI ships in a follow-up frontend PR.	2 weeks ago
Broque Thomas	d3768610d7	Extract automation handlers (kettui-bar): engine-boundary tests ... Per-handler boundary tests pin each handler's body in isolation. Adding engine-boundary tests that pin the REGISTRATION layer: - every expected action name registered, no drops, no extras - guarded actions register a guard, unguarded ones don't - every registered handler is callable - every guard returns a bool - all four progress callbacks registered in the right slots - progress_init / progress_finish / record_history / on_library_scan_completed are invocable through the engine's stored callable shape (not just the bare extracted function) - finish callback respects _manages_own_progress flag at the engine boundary too - library_scan_completed wiring registers a callback on the scan manager and that callback fires engine.emit when invoked - every handler returns a `{'status': ...}` dict on a minimal config trigger -- proves no handler raises into the engine, even when its guard / short-circuit / error path is the one taken Uses a minimal _RecordingEngine that captures registrations + a _RecordingScanMgr that captures completion callbacks. No real AutomationEngine, no real Flask app, no real DB. The kettui standard for refactor PRs: don't ship "behavior preserved" claim that's only validated at the function boundary -- exercise the engine seam too. EXPECTED_ACTION_NAMES + EXPECTED_GUARDED_ACTIONS frozen sets at the top: any future drift (rename / drop / add a handler / change which ones are guarded) fails this test immediately so refactor PRs can't quietly mutate the registration shape. 13 new tests, 164 automation tests pass total.	2 weeks ago