From f9a4039ad2b76957e05054d3a300758a6501ca13 Mon Sep 17 00:00:00 2001 From: sudacode Date: Mon, 30 Mar 2026 00:30:18 -0700 Subject: [PATCH] chore: add backlog task records --- ...l-for-sibling-video-files-and-mpv-queue.md | 29 ++++++++++ ...-live-websocket-connect-send-regression.md | 56 ++++++++++++++++++ ...tartup-to-initialize-websocket-pipeline.md | 57 +++++++++++++++++++ ...rom-spawning-separate-texthooker-helper.md | 57 +++++++++++++++++++ ...oker-startup-skipping-texthooker-server.md | 33 +++++++++++ 5 files changed, 232 insertions(+) create mode 100644 backlog/tasks/task-255 - Add-overlay-playlist-browser-modal-for-sibling-video-files-and-mpv-queue.md create mode 100644 backlog/tasks/task-256 - Fix-texthooker-page-live-websocket-connect-send-regression.md create mode 100644 backlog/tasks/task-257 - Fix-texthooker-only-mode-startup-to-initialize-websocket-pipeline.md create mode 100644 backlog/tasks/task-258 - Stop-plugin-auto-start-from-spawning-separate-texthooker-helper.md create mode 100644 backlog/tasks/task-259 - Fix-integrated-start-texthooker-startup-skipping-texthooker-server.md diff --git a/backlog/tasks/task-255 - Add-overlay-playlist-browser-modal-for-sibling-video-files-and-mpv-queue.md b/backlog/tasks/task-255 - Add-overlay-playlist-browser-modal-for-sibling-video-files-and-mpv-queue.md new file mode 100644 index 0000000..a8d0997 --- /dev/null +++ b/backlog/tasks/task-255 - Add-overlay-playlist-browser-modal-for-sibling-video-files-and-mpv-queue.md @@ -0,0 +1,29 @@ +--- +id: TASK-255 +title: Add overlay playlist browser modal for sibling video files and mpv queue +status: To Do +assignee: [] +created_date: '2026-03-30 05:46' +labels: + - feature + - overlay + - mpv + - launcher +dependencies: [] +--- + +## Description + + +Add an in-session overlay modal that opens from a keybinding during active playback and lets the user browse video files from the current file's parent directory alongside the active mpv playlist. The modal should sort local files in best-effort episode order, highlight the current item, and allow keyboard/mouse interaction to add files into the mpv queue, remove queued items, and reorder queued items without leaving playback. + + +## Acceptance Criteria + +- [ ] #1 An overlay modal can be opened during active playback from a dedicated keybinding and closed without disrupting existing modal behavior. +- [ ] #2 The modal shows video files from the current media file's parent directory in best-effort episode order and highlights the current file when present. +- [ ] #3 The modal shows the active mpv playlist/queue with enough metadata to identify the current item and queued order. +- [ ] #4 The user can add a directory file to the mpv playlist, remove playlist items, and reorder playlist items from the modal using both mouse and keyboard interactions. +- [ ] #5 Modal state stays in sync after playlist mutations so the rendered queue reflects mpv's current playlist order. +- [ ] #6 Feature coverage includes automated tests for ordering/playlist behavior and docs or shortcut/help updates for the new modal. + diff --git a/backlog/tasks/task-256 - Fix-texthooker-page-live-websocket-connect-send-regression.md b/backlog/tasks/task-256 - Fix-texthooker-page-live-websocket-connect-send-regression.md new file mode 100644 index 0000000..0f29314 --- /dev/null +++ b/backlog/tasks/task-256 - Fix-texthooker-page-live-websocket-connect-send-regression.md @@ -0,0 +1,56 @@ +--- +id: TASK-256 +title: Fix texthooker page live websocket connect/send regression +status: Done +assignee: + - codex +created_date: '2026-03-30 06:04' +updated_date: '2026-03-30 06:12' +labels: + - bug + - texthooker + - websocket +dependencies: [] +priority: medium +--- + +## Description + + +Investigate why the bundled texthooker page loads at the local HTTP endpoint but does not reliably connect to the configured websocket feed or receive/display live subtitle lines. Identify the regression in the SubMiner startup/bootstrap or vendored texthooker client path, restore live line delivery, and cover the fix with focused regression tests and any required docs updates. + + +## Acceptance Criteria + +- [x] #1 Bundled texthooker connects to the intended websocket endpoint on launch using the configured/default SubMiner startup path. +- [x] #2 Incoming subtitle or annotation websocket messages are accepted by the bundled texthooker and rendered as live lines. +- [x] #3 Regression coverage fails before the fix and passes after the fix for the identified breakage. +- [x] #4 Relevant docs/config notes are updated if user-facing behavior or troubleshooting guidance changes. + + +## Implementation Plan + + +1. Add a focused CLI regression test covering `--texthooker` startup when the runtime has a resolved websocket URL, proving the handler currently starts texthooker without that URL. +2. Extend CLI texthooker dependencies/runtime wiring so the handler can retrieve the resolved texthooker websocket URL from current config/runtime state. +3. Update the CLI texthooker flow to pass the resolved websocket URL into texthooker startup instead of starting the HTTP server with only a port. +4. Run focused tests for CLI command handling and texthooker bootstrap behavior; update task notes/final summary with the verified root cause and fix. + + +## Implementation Notes + + +Root cause: the CLI `--texthooker` path started the HTTP texthooker server with only the port, so the served page never received `bannou-texthooker-websocketUrl` and fell back to the vendored default `ws://localhost:6677`. In environments where the regular websocket was skipped or the annotation websocket should have been used, the page stayed on `Connecting...` and never received lines. + +Fix: added a shared `resolveTexthookerWebsocketUrl(...)` helper for websocket selection, reused it in both app-ready startup and CLI texthooker context wiring, and threaded the resolved websocket URL through `handleCliCommand` into `Texthooker.start(...)`. + +Verification: `bun run typecheck`; focused Bun tests for texthooker bootstrap, startup, CLI command handling, and CLI context wiring; browser-level repro against a throwaway source-backed texthooker server confirmed the page bootstraps `ws://127.0.0.1:6678`, connects successfully, and renders live sample lines (`テスト一`, `テスト二`). + +Docs: no user-facing behavior change beyond restoring the intended existing behavior, so no docs update was required. + + +## Final Summary + + +Restored texthooker live line delivery for the CLI/startup path that launched the page without a resolved websocket URL. Shared websocket URL resolution between app-ready startup and CLI texthooker context, forwarded that URL into `Texthooker.start(...)`, added regression coverage for the CLI path, and verified both by focused tests and a browser-level throwaway server that connected on `ws://127.0.0.1:6678` and rendered live sample lines. + diff --git a/backlog/tasks/task-257 - Fix-texthooker-only-mode-startup-to-initialize-websocket-pipeline.md b/backlog/tasks/task-257 - Fix-texthooker-only-mode-startup-to-initialize-websocket-pipeline.md new file mode 100644 index 0000000..bcdce07 --- /dev/null +++ b/backlog/tasks/task-257 - Fix-texthooker-only-mode-startup-to-initialize-websocket-pipeline.md @@ -0,0 +1,57 @@ +--- +id: TASK-257 +title: Fix texthooker-only mode startup to initialize websocket pipeline +status: Done +assignee: + - codex +created_date: '2026-03-30 06:15' +updated_date: '2026-03-30 06:17' +labels: + - bug + - texthooker + - websocket + - startup +dependencies: [] +priority: high +--- + +## Description + + +Investigate and fix `--texthooker` / `subminer texthooker` startup so it launches the texthooker page without the overlay window but still initializes the runtime pieces required for live subtitle delivery. Today texthooker-only mode serves the page yet skips mpv client and websocket startup, leaving the page pointed at `ws://127.0.0.1:6678` with no listener behind it. + + +## Acceptance Criteria + +- [x] #1 `--texthooker` mode starts the texthooker page without opening the overlay window and still initializes the websocket path needed for live subtitle delivery. +- [x] #2 Texthooker-only startup creates the mpv/websocket runtime needed for the configured annotation or subtitle websocket feed. +- [x] #3 Regression coverage fails before the fix and passes after the fix for texthooker-only startup. +- [x] #4 Docs/help text remain accurate for texthooker-only behavior; update docs only if wording needs correction. + + +## Implementation Plan + + +1. Replace the existing texthooker-only startup regression test so it asserts websocket/mpv startup still happens while overlay window initialization stays skipped. +2. Remove or narrow the early texthooker-only short-circuit in app-ready startup so runtime config, mpv client, subtitle websocket, and annotation websocket still initialize. +3. Run focused tests plus a local process check proving `--texthooker` now opens the websocket listener expected by the served page. +4. Update task notes/final summary with the live-process root cause (`--texthooker` serving HTML on 5174 with no 6678 listener). + + +## Implementation Notes + + +Live-process repro on the user's machine: `ps` showed the active process as `/tmp/.mount_SubMin.../SubMiner --texthooker --port 5174`. `lsof` showed 5174 listening but no listener on 6678/6677, while `curl http://127.0.0.1:5174/` confirmed the served page was correctly bootstrapped to `ws://127.0.0.1:6678`. That proved the remaining failure was startup mode, not page injection. + +Root cause: `runAppReadyRuntime(...)` had an early `texthookerOnlyMode` return that reloaded config and handled initial args, but skipped `createMpvClient()`, subtitle websocket startup, annotation websocket startup, subtitle timing tracker creation, and the later texthooker-only branch that only skips the overlay window. + +Fix: removed the early texthooker-only short-circuit so texthooker-only mode now runs the normal startup pipeline, then falls through to the existing `Texthooker-only mode enabled; skipping overlay window.` branch. + +Verification: `bun run typecheck`; focused Bun tests for app-ready startup, startup bootstrap, CLI texthooker startup, and CLI context wiring. Existing local live-binary repro still reflects the old mounted AppImage until rebuilt/restarted. Current-binary workaround is to launch normal startup / `--start --texthooker` instead of plain `--texthooker`. + + +## Final Summary + + +Fixed the second texthooker regression: plain `--texthooker` mode was serving the page but skipping mpv/websocket initialization, so the page pointed at `ws://127.0.0.1:6678` with no listener. Removed the early texthooker-only startup return, kept the later overlay-skip behavior, updated the startup regression test to require websocket/mpv initialization in texthooker-only mode, and re-verified with typecheck plus focused test coverage. + diff --git a/backlog/tasks/task-258 - Stop-plugin-auto-start-from-spawning-separate-texthooker-helper.md b/backlog/tasks/task-258 - Stop-plugin-auto-start-from-spawning-separate-texthooker-helper.md new file mode 100644 index 0000000..c57f0a4 --- /dev/null +++ b/backlog/tasks/task-258 - Stop-plugin-auto-start-from-spawning-separate-texthooker-helper.md @@ -0,0 +1,57 @@ +--- +id: TASK-258 +title: Stop plugin auto-start from spawning separate texthooker helper +status: Done +assignee: + - codex +created_date: '2026-03-30 06:25' +updated_date: '2026-03-30 06:26' +labels: + - bug + - texthooker + - launcher + - plugin + - startup +dependencies: [] +priority: high +--- + +## Description + + +Change the mpv/plugin auto-start path so normal SubMiner startup owns texthooker and websocket startup inside the main `--start` app instance. Keep standalone `subminer texthooker` / plain `--texthooker` available for explicit external use, but stop the plugin from spawning a second helper subprocess during regular auto-start. + + +## Acceptance Criteria + +- [x] #1 Plugin auto-start includes texthooker on the main `--start` command when texthooker is enabled. +- [x] #2 Plugin auto-start no longer spawns a separate standalone `--texthooker` helper subprocess during normal startup. +- [x] #3 Regression coverage fails before the fix and passes after the fix for the plugin auto-start path. +- [x] #4 Standalone external `subminer texthooker` / plain `--texthooker` entrypoints remain available for explicit helper use. + + +## Implementation Plan + + +1. Flip the mpv/plugin start-gate regression so enabled texthooker is folded into the main `--start` command and standalone helper subprocesses are rejected. +2. Update plugin process command construction so `start` includes `--texthooker` when enabled and the separate helper-launch path becomes a no-op for normal auto-start. +3. Run plugin Lua regressions, adjacent launcher tests, and typecheck to verify behavior and preserve explicit standalone `--texthooker` entrypoints. + + +## Implementation Notes + + +Design approved by user: normal in-app startup should own texthooker/websocket; `texthookerOnlyMode` should stay explicit external-only. + +Root cause path: mpv/plugin auto-start in `plugin/subminer/process.lua` launched `binary_path --start ...` and then separately spawned `binary_path --texthooker --port ...`. That created the standalone helper process observed live (`SubMiner --texthooker --port 5174`) instead of relying on the normal app instance. + +Fix: `build_command_args('start', overrides)` now appends `--texthooker` when texthooker is enabled, and the old helper-launch path is reduced to a no-op so normal auto-start remains single-process. + +Verification: `lua scripts/test-plugin-start-gate.lua`, `lua scripts/test-plugin-process-start-retries.lua`, `bun test launcher/mpv.test.ts launcher/commands/playback-command.test.ts launcher/config/args-normalizer.test.ts`, and `bun run typecheck`. Standalone launcher/app entrypoints for explicit `subminer texthooker` / plain `--texthooker` were left untouched. + + +## Final Summary + + +Stopped the mpv/plugin auto-start path from spawning a second standalone texthooker helper. Texthooker now rides on the main `--start` app instance for normal startup, with Lua regressions updated to require `--texthooker` on the main start command and reject separate helper subprocesses. Explicit standalone `subminer texthooker` / plain `--texthooker` entrypoints remain available. + diff --git a/backlog/tasks/task-259 - Fix-integrated-start-texthooker-startup-skipping-texthooker-server.md b/backlog/tasks/task-259 - Fix-integrated-start-texthooker-startup-skipping-texthooker-server.md new file mode 100644 index 0000000..12c1158 --- /dev/null +++ b/backlog/tasks/task-259 - Fix-integrated-start-texthooker-startup-skipping-texthooker-server.md @@ -0,0 +1,33 @@ +--- +id: TASK-259 +title: Fix integrated --start --texthooker startup skipping texthooker server +status: Done +assignee: [] +created_date: '2026-03-30 06:48' +updated_date: '2026-03-30 06:56' +labels: + - bug + - texthooker + - startup +dependencies: [] +priority: high +--- + +## Description + + +Integrated overlay startup with `--start --texthooker` currently takes the minimal-startup path because startup mode flags treat any `args.texthooker` as texthooker-only. That skips app-ready texthooker service startup, so no server binds on port 5174 during normal SubMiner playback launches. + + +## Acceptance Criteria + +- [x] #1 `--start --texthooker` uses full app-ready startup instead of minimal texthooker-only startup +- [x] #2 Integrated playback launch starts the texthooker server on the configured/default port +- [x] #3 Regression tests cover the startup-mode classification and integrated startup behavior + + +## Final Summary + + +Narrowed texthooker-only startup classification so integrated `--start --texthooker` no longer takes the minimal-startup path. Added CLI arg regression coverage, rebuilt the AppImage, installed it to `~/.local/bin/SubMiner.AppImage` with a timestamped backup, restarted against `/tmp/subminer-socket`, and verified listeners on 5174/6677/6678 plus browser connection state `Connected with ws://127.0.0.1:6678`. +