add tasks

This commit is contained in:
kyasuda
2026-02-13 18:29:17 -08:00
parent 6dcb979f4c
commit 7856967920
48 changed files with 2275 additions and 2 deletions

View File

@@ -0,0 +1,47 @@
---
id: TASK-30
title: Enable anime streaming via extension repos with configurable mpv playback flow
status: To Do
assignee: []
created_date: '2026-02-13 18:32'
updated_date: '2026-02-13 18:34'
labels: []
dependencies: []
priority: high
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Add a feature to query configured extension repositories for anime titles/episodes from SubMiner, let users select a streamable source, and play it through mpv with minimal friction. The result should be interactive from Electron (and triggered from mpv via existing command bridge), and fully configurable in app config.
The implementation should provide a modular backend resolver and a clear UI flow that mirrors existing modal interaction patterns, while keeping mpv playback unchanged (use loadfile with resolved URL and optional headers/referrer metadata).
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 Create a stable config schema for one or more extension source backends (repos/endpoints/flags) and persist in user config + default template.
- [ ] #2 Resolve an anime search term to candidate series from configured sources.
- [ ] #3 Resolve an episode selection to at least one playable stream URL candidate with playback metadata when available.
- [ ] #4 Provide an interactive user flow in the app to search/select episode and choose stream source.
- [ ] #5 Play the selected stream by invoking the existing mpv command path.
- [ ] #6 Support launching the flow from mpv interactions (keyboard/menu) by forwarding a command/event into the renderer modal flow.
- [ ] #7 Add error states for empty results, no playable source, and repository failures, with clear user messages.
<!-- AC:END -->
## Implementation Notes
<!-- SECTION:NOTES:BEGIN -->
Execution sequence for implementation: 1) TASK-30.1 (config/model), 2) TASK-30.2 (resolver), 3) TASK-30.3 (IPC), 4) TASK-30.4 (UI modal), 5) TASK-30.5 (mpv trigger), 6) TASK-30.6 (validation/rollout checklist).
Rollout recommendation: complete TASK-30.6 only after TASK-30.1-30.5 are done and can be verified in combination.
<!-- SECTION:NOTES:END -->
## Definition of Done
<!-- DOD:BEGIN -->
- [ ] #1 Config schema validated in app startup (bad config surfaces clear error).
- [ ] #2 No hardcoded source/resolver URLs in UI layer; resolver details are backend-driven.
- [ ] #3 Play command path uses existing mpv IPC/runtime helpers.
- [ ] #4 Documentation includes how to configure extension repos and optional auth/headers.
- [ ] #5 Feature is gated behind a config flag and can be disabled cleanly.
<!-- DOD:END -->

View File

@@ -0,0 +1,40 @@
---
id: TASK-30.1
title: Design extension source config model and defaults
status: To Do
assignee: []
created_date: '2026-02-13 18:32'
updated_date: '2026-02-13 18:34'
labels: []
dependencies: []
parent_task_id: TASK-30
priority: high
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Define a backend-agnostic configuration contract for extension repository streaming, including resolver endpoints/process mode, query/auth headers, timeouts, enable flags, and source preference. Wire schema through Config/ResolvedConfig and generated template/defaults so users can manage repos entirely through config.
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 Add new config sections for extension source providers in Config and ResolvedConfig types.
- [ ] #2 Add validation defaults and env-compatible parsing for provider list, auth, header overrides, and feature flags.
- [ ] #3 Update config template and docs text so defaults are discoverable and editable.
- [ ] #4 Invalid/missing config should fail fast with a clear message path.
- [ ] #5 Existing config readers do not regress when no providers are configured.
<!-- AC:END -->
## Implementation Notes
<!-- SECTION:NOTES:BEGIN -->
Phase 1 — Foundation: config contract + validation + defaults
<!-- SECTION:NOTES:END -->
## Definition of Done
<!-- DOD:BEGIN -->
- [ ] #1 Config examples in template/docs include at least one provider entry shape.
- [ ] #2 Defaults remain backward-compatible when key is absent.
- [ ] #3 Feature can be disabled without touching unrelated settings.
<!-- DOD:END -->

View File

@@ -0,0 +1,42 @@
---
id: TASK-30.2
title: Implement extension resolver service (search + episode + stream resolution)
status: To Do
assignee: []
created_date: '2026-02-13 18:32'
updated_date: '2026-02-13 18:34'
labels: []
dependencies:
- TASK-30.1
parent_task_id: TASK-30
priority: high
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Build a dedicated service in main process that queries configured extension repos and normalizes results into a unified internal model, including optional playback metadata. Keep transport abstracted so future backends (local process, remote API, Manatán-compatible source) can be swapped without changing renderer contracts.
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 Create a typed internal model for source, series, episode, and playable candidate with fields for quality/audio/headers/referrer/userAgent.
- [ ] #2 Implement provider abstraction with pluggable fetch/execution strategy from config.
- [ ] #3 Add services for searchAnime, listEpisodes, resolveStream (or equivalent) with cancellation/error boundaries.
- [ ] #4 Normalize all provider responses into deterministic field names and stable IDs.
- [ ] #5 Include resilient handling for empty/no-result/no-URL cases and network faults with explicit error categories.
<!-- AC:END -->
## Implementation Notes
<!-- SECTION:NOTES:BEGIN -->
Phase 2 — Core service: provider integration and stream resolution
<!-- SECTION:NOTES:END -->
## Definition of Done
<!-- DOD:BEGIN -->
- [ ] #1 Resolver never leaks raw provider payload to renderer.
- [ ] #2 Streaming URL output includes reason for failure when unavailable.
- [ ] #3 Service boundaries allow unit-level validation of request/response mapping logic.
- [ ] #4 No blocking calls on Electron UI/main thread; all I/O is async and cancellable.
<!-- DOD:END -->

View File

@@ -0,0 +1,42 @@
---
id: TASK-30.3
title: Expose resolver operations via Electron IPC to renderer
status: To Do
assignee: []
created_date: '2026-02-13 18:32'
updated_date: '2026-02-13 18:34'
labels: []
dependencies:
- TASK-30.2
parent_task_id: TASK-30
priority: high
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Add a typed preload and main-IPC contract for streaming queries and playback resolution so the renderer can initiate search/list/resolve without embedding network/provider logic in UI code.
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 Define IPC handlers in main with input/output schema validation and timeouts.
- [ ] #2 Expose corresponding functions in preload `window.electronAPI` and ElectronAPI types.
- [ ] #3 Reuse existing mpv command channel for playback and add a dedicated request/response flow for resolver actions.
- [ ] #4 Implement safe serialization and error marshalling for resolver-specific failures.
- [ ] #5 Add runtime wiring and lifetime management in app startup/shutdown.
- [ ] #6 Document event/callback behavior for loading/error states.
<!-- AC:END -->
## Implementation Notes
<!-- SECTION:NOTES:BEGIN -->
Phase 3 — API surface: IPC/preload contract for resolver operations
<!-- SECTION:NOTES:END -->
## Definition of Done
<!-- DOD:BEGIN -->
- [ ] #1 Renderer code can query providers without importing Node-only modules.
- [ ] #2 IPC paths have clear names and consistent response shapes across all calls.
- [ ] #3 Error paths return explicit machine-readable codes mapped to user-visible messages.
<!-- DOD:END -->

View File

@@ -0,0 +1,42 @@
---
id: TASK-30.4
title: 'Add interactive streaming modal (search, episode list, source selection, play)'
status: To Do
assignee: []
created_date: '2026-02-13 18:32'
updated_date: '2026-02-13 18:34'
labels: []
dependencies:
- TASK-30.3
parent_task_id: TASK-30
priority: high
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Implement a renderer flow to query configured providers, display results, let user choose series and episode, and trigger playback for a selected stream. The UI should support keyboard interactions and surface backend errors clearly.
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 Create modal UI/state model for query, results list, selected item, episode list, candidate qualities, and loading/error status.
- [ ] #2 Wire renderer actions to new IPC methods for search/episode/resolve.
- [ ] #3 Render one-click or enter-to-play action that calls existing mpv playback pathway.
- [ ] #4 Persist minimal user preference (last provider/quality where possible) for faster repeat use.
- [ ] #5 Provide empty/error states and accessibility-friendly focus/keyboard navigation for lists.
- [ ] #6 Add a no-network mode fallback message when resolver calls fail.
<!-- AC:END -->
## Implementation Notes
<!-- SECTION:NOTES:BEGIN -->
Phase 4 — UX: interactive modal flow and playback callout
<!-- SECTION:NOTES:END -->
## Definition of Done
<!-- DOD:BEGIN -->
- [ ] #1 Modal state is isolated and unsubscribes listeners on close.
- [ ] #2 No direct network logic in renderer beyond IPC calls.
- [ ] #3 Visual style and behavior are consistent with existing modal patterns.
<!-- DOD:END -->

View File

@@ -0,0 +1,45 @@
---
id: TASK-30.5
title: >-
Wire mpv script-message/shortcut trigger into streaming modal and playback
path
status: To Do
assignee: []
created_date: '2026-02-13 18:33'
updated_date: '2026-02-13 18:34'
labels: []
dependencies:
- TASK-30.3
- TASK-30.4
parent_task_id: TASK-30
priority: high
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Allow users to open streaming selection from within mpv via keybind/menu and route that intent into renderer modal and playback flow without requiring separate window focus changes.
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 Add/extend mpv Lua plugin or existing command registry to emit a custom action for opening the streaming picker.
- [ ] #2 Handle this action in main IPC/mpv-command pipeline and forward to renderer modal state.
- [ ] #3 Add at least one default keybinding/menu entry documented in config/plugin notes.
- [ ] #4 Ensure playback launched from the in-player flow uses the same command path and error messages as renderer-initiated flow.
- [ ] #5 Add graceful handling when feature is disabled or no providers are configured.
<!-- AC:END -->
## Implementation Notes
<!-- SECTION:NOTES:BEGIN -->
Phase 5 — In-player entry: mpv trigger/menu integration
<!-- SECTION:NOTES:END -->
## Definition of Done
<!-- DOD:BEGIN -->
- [ ] #1 No duplicate mpv command parsing between picker and legacy commands.
- [ ] #2 Feature can be used in overlay and mpv-only mode where applicable.
- [ ] #3 No dependency on modal open state when launched by mpv trigger.
- [ ] #4 Manual and keybind invocations behave consistently.
<!-- DOD:END -->

View File

@@ -0,0 +1,45 @@
---
id: TASK-30.6
title: >-
Add integration validation plan and rollout checklist for anime streaming
feature
status: To Do
assignee: []
created_date: '2026-02-13 18:34'
updated_date: '2026-02-13 18:34'
labels: []
dependencies: []
parent_task_id: TASK-30
priority: high
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Create a concrete validation task that defines end-to-end acceptance checks for config loading, resolver behavior, IPC contract correctness, UI flow, and mpv-triggered launch. The checklist should be actionable and align with existing project conventions so completion can be verified without guesswork.
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 Define test scenarios for config success/failure cases, including invalid provider config and feature disabled mode.
- [ ] #2 Define search/list/resolve API contract tests and error-code assertions (empty, timeout, auth error, no playable URL).
- [ ] #3 Define renderer UX checks for modal state transitions, loading indicators, empty results, selection, and play invocation.
- [ ] #4 Define in-mpv trigger checks for command/message pathway and fallback behavior when modal disabled/unavailable.
- [ ] #5 Define manual smoke steps for end-to-end play from query to mpv playback using at least one configured source.
- [ ] #6 Document expected logs/telemetry markers for troubleshooting and rollback.
- [ ] #7 Define rollback criteria and what constitutes safe partial completion.
<!-- AC:END -->
## Implementation Notes
<!-- SECTION:NOTES:BEGIN -->
Phase 6 — Validation: rollout, smoke tests, and release readiness checklist
<!-- SECTION:NOTES:END -->
## Definition of Done
<!-- DOD:BEGIN -->
- [ ] #1 Checklist covers happy-path and failure-path for each task dependency.
- [ ] #2 Verification steps are executable without external tooling assumptions.
- [ ] #3 No task can be marked done without explicit evidence fields filled in.
- [ ] #4 Rollout and fallback behavior are documented per deployment/release phase.
<!-- DOD:END -->

View File

@@ -0,0 +1,34 @@
---
id: TASK-30.7
title: >-
Add English-source preference + hard-sub stripping workflow in Aniyomi
streaming path
status: To Do
assignee: []
created_date: '2026-02-13 18:41'
labels: []
dependencies:
- TASK-30.2
- TASK-30.5
parent_task_id: TASK-30
priority: high
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Improve the Aniyomi/anime extension streaming flow to prefer English-capable sources with soft subtitles, and automatically recover when only hard-subbed streams are available by stripping embedded subtitles with ffmpeg and attaching external Jimaku subtitle files into mpv.
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 During source scoring/selection, prefer providers/sources that declare or expose soft subtitles for English audio or subtitle tracks over hard-subbed alternatives.
- [ ] #2 Add a config option for preferred language targets (default English) and fallback policy (favor soft subtitles, then hard-sub fallback).
- [ ] #3 Detect when a resolved stream is hard-sub-only and a soft-sub source is unavailable for the same episode.
- [ ] #4 When hard subs are used, attempt to generate a subtitle-less playback stream path using ffmpeg and feed an external subtitle file (including Jimaku-provided `.ass/.srt`) into the mpv playback path.
- [ ] #5 Preserve stream selection metadata (language tags, subtitle type, availability state) for UI decisions and error messaging.
- [ ] #6 If ffmpeg conversion is not possible/disabled or fails, surface a clear status that explains fallback behavior instead of silent failure.
- [ ] #7 Integrate subtitle source preferences with Jimaku so user-fetched or resolved subtitles are preferred for burn-in removal cases where supported.
- [ ] #8 Add handling for unsupported codecs/containers and provider limitations so direct passthrough is still used when hard-sub stripping is unsafe.
- [ ] #9 Document new behavior in feature docs/FAQ: how sources are ranked, what hard-sub stripping does, and known compatibility limitations.
<!-- AC:END -->

View File

@@ -0,0 +1,31 @@
---
id: TASK-30.8
title: >-
Add observability and tuning metrics for Aniyomi subtitle-source fallback
decisions
status: To Do
assignee: []
created_date: '2026-02-13 18:41'
labels: []
dependencies:
- TASK-30.7
parent_task_id: TASK-30
priority: high
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Add lightweight telemetry/analytics hooks (local logs + optional structured counters) to measure how Aniyomi/anime streaming source selection behaves, including soft-sub preference, hard-sub fallback usage, and ffmpeg+Jimaku post-processing outcomes, to support source ranking tuning.
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 Track per-playback decision metadata including chosen source, language match score, subtitle mode (soft/hard), and reason for source preference ordering.
- [ ] #2 Emit success/failure counters for hard-sub stripping attempts (started/succeeded/failed/unsupported codec) with reason codes.
- [ ] #3 Log whether Jimaku subtitle attachment was available and successfully loaded for ffmpeg-assisted flows.
- [ ] #4 Capture user-visible fallback reasons when preferred English/soft-sub sources are absent and hard-sub path is used.
- [ ] #5 Add a debug/report view or log artifact with counters that can be reviewed in-app or via config/log files.
- [ ] #6 Document metrics definitions so developers can tune source scorer and fallback policy without code changes.
- [ ] #7 Ensure instrumentation has low overhead and is opt-out-safe with existing config flags.
<!-- AC:END -->

View File

@@ -0,0 +1,30 @@
---
id: TASK-30.9
title: Expose subtitle preference and ffmpeg fallback tuning controls in settings UI
status: To Do
assignee: []
created_date: '2026-02-13 18:42'
labels: []
dependencies:
- TASK-30.7
- TASK-30.8
parent_task_id: TASK-30
priority: medium
---
## Description
<!-- SECTION:DESCRIPTION:BEGIN -->
Add user-configurable controls for Aniyomi streaming subtitle behavior, including preferred language profile, soft-vs-hard source preference, ffmpeg-assisted hard-sub removal behavior, and policy toggles so quality and fallback behavior can be tuned without code changes.
<!-- SECTION:DESCRIPTION:END -->
## Acceptance Criteria
<!-- AC:BEGIN -->
- [ ] #1 Add settings UI fields to define preferred subtitle/audiotrack language order (e.g., en, ja) and enable/disable hard-sub fallback mode.
- [ ] #2 Add explicit toggle for enabling hard-sub stripping via ffmpeg and configurable timeout/quality limits to avoid long waits.
- [ ] #3 Expose source ranking preferences for soft-sub vs hard-sub sources and optional fallback to native/transcoded source when preferred modes are unavailable.
- [ ] #4 Persist settings in existing config schema with migration-safe defaults and include clear validation for invalid/unsupported values.
- [ ] #5 Show current effective policy in streaming UI (for debugging): source selected + reason + whether subtitles are soft/hard and if ffmpeg path is active.
- [ ] #6 Add user-facing explanatory text and warnings for ffmpeg dependency, expected CPU/cpu cost, and compatibility limits.
- [ ] #7 Log and display when user-adjusted policy changes alter a previously preferred source choice during runtime.
<!-- AC:END -->