mirror of
https://github.com/ksyasuda/SubMiner.git
synced 2026-02-27 18:22:41 -08:00
Refactor startup/logging service wiring and related test/config updates
This commit is contained in:
@@ -1,51 +0,0 @@
|
||||
---
|
||||
id: TASK-43
|
||||
title: Add community subtitle timing database for shared sync corrections
|
||||
status: To Do
|
||||
assignee: []
|
||||
created_date: '2026-02-14 02:13'
|
||||
labels:
|
||||
- feature
|
||||
- community
|
||||
- subtitles
|
||||
- sync
|
||||
dependencies: []
|
||||
priority: low
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!-- SECTION:DESCRIPTION:BEGIN -->
|
||||
Allow users to share their subtitle timing corrections to a community database, so other users watching the same video file get pre-synced subtitles automatically.
|
||||
|
||||
## Motivation
|
||||
Subtitle synchronization (alass/ffsubsync) is one of the most friction-heavy steps in the mining workflow. Users spend time syncing subtitles that someone else has already synced for the exact same video. A shared database of timing corrections keyed by video file hash would eliminate redundant work.
|
||||
|
||||
## Design
|
||||
1. **Video identification**: Use a partial file hash (first + last N bytes, or a media fingerprint) to identify video files without uploading content
|
||||
2. **Timing data**: Store the timing offset/warp parameters produced by alass/ffsubsync, not the full subtitle file
|
||||
3. **Upload flow**: After a successful sync, offer to share the timing correction (opt-in)
|
||||
4. **Download flow**: Before syncing, check the community database for existing corrections for the current video hash
|
||||
5. **Trust model**: Simple upvote/downvote on corrections; show number of users who confirmed a correction works
|
||||
|
||||
## Technical considerations
|
||||
- Backend could be a simple REST API with a lightweight database (or even a GitHub-hosted JSON/SQLite file for v1)
|
||||
- Privacy: only file hashes and timing parameters are shared, never video content or personal data
|
||||
- Subtitle source (jimaku entry ID) can serve as an additional matching key
|
||||
- Rate limiting and abuse prevention needed for public API
|
||||
- Could integrate with existing jimaku modal flow
|
||||
|
||||
## Phasing
|
||||
- v1: Local export/import of timing corrections (share as files)
|
||||
- v2: Optional cloud sync with community database
|
||||
<!-- SECTION:DESCRIPTION:END -->
|
||||
|
||||
## Acceptance Criteria
|
||||
<!-- AC:BEGIN -->
|
||||
- [ ] #1 Video files are identified by content hash without uploading video data.
|
||||
- [ ] #2 Timing corrections (offset/warp parameters) can be exported and shared.
|
||||
- [ ] #3 Before syncing, the app checks for existing community corrections for the current video.
|
||||
- [ ] #4 Upload of timing data is opt-in with clear privacy disclosure.
|
||||
- [ ] #5 Downloaded corrections are applied automatically or with one-click confirmation.
|
||||
- [ ] #6 Trust signal (confirmation count) is shown for community corrections.
|
||||
<!-- AC:END -->
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
id: TASK-53
|
||||
title: Consolidate fragmented JLPT utility modules
|
||||
status: Done
|
||||
assignee: []
|
||||
created_date: '2026-02-16 04:47'
|
||||
updated_date: '2026-02-16 04:57'
|
||||
labels: []
|
||||
dependencies: []
|
||||
references:
|
||||
- >-
|
||||
/home/sudacode/projects/japanese/SubMiner/src/core/services/jlpt-token-filter-config.ts
|
||||
- >-
|
||||
/home/sudacode/projects/japanese/SubMiner/src/core/services/jlpt-excluded-terms.ts
|
||||
- >-
|
||||
/home/sudacode/projects/japanese/SubMiner/src/core/services/jlpt-ignored-mecab-pos1.ts
|
||||
priority: medium
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!-- SECTION:DESCRIPTION:BEGIN -->
|
||||
The JLPT-related functionality is currently split across three tiny files that create unnecessary navigation overhead and add cognitive load when working with JLPT token filtering.
|
||||
|
||||
Files to consolidate:
|
||||
- `src/core/services/jlpt-token-filter-config.ts` (24 lines)
|
||||
- `src/core/services/jlpt-excluded-terms.ts` (30 lines)
|
||||
- `src/core/services/jlpt-ignored-mecab-pos1.ts` (46 lines)
|
||||
|
||||
These three files are tightly coupled (one imports from another) and all deal with JLPT token filtering logic. They should be merged into a single `jlpt-token-filter.ts` module with clear section comments.
|
||||
|
||||
Benefits:
|
||||
- Reduces file count by 2
|
||||
- Eliminates circular import potential
|
||||
- Easier to understand JLPT filtering logic holistically
|
||||
- Simplifies barrel exports from services/index.ts
|
||||
<!-- SECTION:DESCRIPTION:END -->
|
||||
|
||||
## Acceptance Criteria
|
||||
<!-- AC:BEGIN -->
|
||||
- [ ] #1 Merge jlpt-token-filter-config.ts, jlpt-excluded-terms.ts, and jlpt-ignored-mecab-pos1.ts into a single jlpt-token-filter.ts file
|
||||
- [ ] #2 Update all imports across the codebase to use the consolidated module
|
||||
- [ ] #3 Update services/index.ts barrel exports
|
||||
- [ ] #4 Ensure all existing tests pass
|
||||
- [ ] #5 Verify no functionality is lost in consolidation
|
||||
<!-- AC:END -->
|
||||
|
||||
## Final Summary
|
||||
|
||||
<!-- SECTION:FINAL_SUMMARY:BEGIN -->
|
||||
Consolidated JLPT filtering utilities into `src/core/services/jlpt-token-filter.ts` and updated all imports to use the new module. Added consolidated exports to `src/core/services/index.ts` for the JLPT token filter API (`shouldIgnoreJlptForMecabPos1`, `shouldIgnoreJlptByTerm`, POS metadata, etc.). Deleted the three fragmented files:
|
||||
- `jlpt-token-filter-config.ts`
|
||||
- `jlpt-excluded-terms.ts`
|
||||
- `jlpt-ignored-mecab-pos1.ts`
|
||||
|
||||
Validation:
|
||||
- `pnpm exec tsc --noEmit` passes after the refactor.
|
||||
- `node --test dist/core/services/tokenizer-service.test.js` runs with 19/20 passing; one failure (`tokenizeSubtitleService uses Yomitan parser result when available`) appears to be pre-existing in current tree and matches earlier full test run failure.
|
||||
- Full `pnpm run test:fast` still fails, but failures are outside this consolidation scope (e.g., overlay-shortcut-handler logger message shape and tokenizer Yomitan-parse-path test), consistent with baseline failures in this working state.
|
||||
<!-- SECTION:FINAL_SUMMARY:END -->
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
id: TASK-54
|
||||
title: Audit and consolidate micro-services under 50 lines
|
||||
status: In Progress
|
||||
assignee: []
|
||||
created_date: '2026-02-16 04:47'
|
||||
updated_date: '2026-02-16 04:59'
|
||||
labels: []
|
||||
dependencies: []
|
||||
references:
|
||||
- /home/sudacode/projects/japanese/SubMiner/src/core/services/
|
||||
priority: medium
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!-- SECTION:DESCRIPTION:BEGIN -->
|
||||
The core/services directory contains 67 files, many of which are very small services that may create unnecessary abstraction overhead. This task involves auditing services under 50 lines and determining if they should be consolidated with related services.
|
||||
|
||||
Candidates for review (all under 50 lines):
|
||||
- mpv-state.ts (25 lines) - could merge with mpv-service.ts
|
||||
- secondary-subtitle-service.ts (32 lines) - could merge with subtitle-related services
|
||||
- runtime-config-service.ts (50 lines) - pure utility functions that could merge with config service
|
||||
- mpv-control-service.ts (49 lines) - MPV command functions could merge with mpv-service.ts
|
||||
|
||||
Approach:
|
||||
1. Identify logical groupings (mpv-related, subtitle-related, config-related)
|
||||
2. Determine which micro-services are truly independent vs which are fragments
|
||||
3. Consolidate related micro-services into cohesive modules
|
||||
4. Maintain clear function exports for tree-shaking
|
||||
|
||||
Benefits:
|
||||
- Reduces file navigation overhead
|
||||
- Groups related functionality logically
|
||||
- Makes service boundaries clearer
|
||||
<!-- SECTION:DESCRIPTION:END -->
|
||||
|
||||
## Acceptance Criteria
|
||||
<!-- AC:BEGIN -->
|
||||
- [ ] #1 Audit all services under 50 lines in src/core/services/
|
||||
- [ ] #2 Identify logical groupings for consolidation
|
||||
- [ ] #3 Merge related micro-services into cohesive modules
|
||||
- [ ] #4 Update all imports across codebase
|
||||
- [ ] #5 Update barrel exports in services/index.ts
|
||||
- [ ] #6 Run full test suite to ensure no regressions
|
||||
<!-- AC:END -->
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: TASK-55
|
||||
title: Normalize service naming conventions across core/services
|
||||
status: To Do
|
||||
assignee: []
|
||||
created_date: '2026-02-16 04:47'
|
||||
labels: []
|
||||
dependencies: []
|
||||
references:
|
||||
- /home/sudacode/projects/japanese/SubMiner/src/core/services/index.ts
|
||||
priority: low
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!-- SECTION:DESCRIPTION:BEGIN -->
|
||||
The core/services directory has inconsistent naming patterns that create confusion:
|
||||
- Some files use `*Service.ts` suffix (e.g., `mpv-service.ts`, `tokenizer-service.ts`)
|
||||
- Others use `*RuntimeService.ts` or just descriptive names (e.g., `overlay-visibility-service.ts` exports functions with 'Service' in name)
|
||||
- Some functions in files have 'Service' suffix, others don't
|
||||
|
||||
This inconsistency makes it hard to predict file/function names and creates cognitive overhead.
|
||||
|
||||
Standardize on:
|
||||
- File names: `kebab-case.ts` without 'service' suffix (e.g., `mpv.ts`, `tokenizer.ts`)
|
||||
- Function names: descriptive verbs without 'Service' suffix (e.g., `createMpvClient()`, `tokenizeSubtitle()`)
|
||||
- Barrel exports: clean, predictable names
|
||||
|
||||
Files needing audit (47 services):
|
||||
- All files in src/core/services/ need review
|
||||
|
||||
Note: This is a large-scale refactor that should be done carefully to avoid breaking changes.
|
||||
<!-- SECTION:DESCRIPTION:END -->
|
||||
|
||||
## Acceptance Criteria
|
||||
<!-- AC:BEGIN -->
|
||||
- [ ] #1 Establish naming convention rules (document in code or docs)
|
||||
- [ ] #2 Audit all service files for naming inconsistencies
|
||||
- [ ] #3 Rename files to follow convention (kebab-case, no 'service' suffix)
|
||||
- [ ] #4 Rename exported functions to remove 'Service' suffix where present
|
||||
- [ ] #5 Update all imports across the entire codebase
|
||||
- [ ] #6 Update barrel exports
|
||||
- [ ] #7 Run full test suite
|
||||
- [ ] #8 Update any documentation referencing old names
|
||||
<!-- AC:END -->
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
id: TASK-56
|
||||
title: Extract remaining main.ts runtime functions to dedicated modules
|
||||
status: To Do
|
||||
assignee: []
|
||||
created_date: '2026-02-16 04:47'
|
||||
labels: []
|
||||
dependencies: []
|
||||
references:
|
||||
- /home/sudacode/projects/japanese/SubMiner/src/main.ts
|
||||
priority: medium
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!-- SECTION:DESCRIPTION:BEGIN -->
|
||||
main.ts is still 1481 lines after previous refactoring efforts. While significant progress has been made, there are still opportunities to extract runtime functions into dedicated modules to further reduce its size and improve maintainability.
|
||||
|
||||
Current opportunities:
|
||||
1. **JLPT dictionary lookup functions** (lines 470-535) - initializeJlptDictionaryLookup, ensureJlptDictionaryLookup, getJlptDictionarySearchPaths
|
||||
2. **Media path utilities** (lines 552-590) - updateCurrentMediaPath, updateCurrentMediaTitle, resolveMediaPathForJimaku
|
||||
3. **Overlay visibility helpers** (lines 1273-1360) - updateVisibleOverlayVisibility, updateInvisibleOverlayVisibility, syncInvisibleOverlayMousePassthrough
|
||||
|
||||
These functions are largely self-contained and could be moved to:
|
||||
- `src/main/jlpt-runtime.ts`
|
||||
- `src/main/media-runtime.ts`
|
||||
- `src/main/overlay-visibility-runtime.ts`
|
||||
|
||||
Goal: Reduce main.ts to under 1000 lines (target: ~800-900 lines)
|
||||
|
||||
Benefits:
|
||||
- Faster navigation and comprehension of main.ts
|
||||
- Easier to test extracted modules independently
|
||||
- Clearer separation of concerns
|
||||
<!-- SECTION:DESCRIPTION:END -->
|
||||
|
||||
## Acceptance Criteria
|
||||
<!-- AC:BEGIN -->
|
||||
- [ ] #1 Extract JLPT dictionary lookup functions to dedicated module
|
||||
- [ ] #2 Extract media path utilities to dedicated module
|
||||
- [ ] #3 Extract overlay visibility helpers to dedicated module
|
||||
- [ ] #4 Update main.ts imports to use new modules
|
||||
- [ ] #5 Ensure all functionality remains intact
|
||||
- [ ] #6 Run full test suite
|
||||
- [ ] #7 Verify main.ts line count is reduced to under 1000 lines
|
||||
<!-- AC:END -->
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
id: TASK-57
|
||||
title: Evaluate anki-integration.ts for further decomposition
|
||||
status: To Do
|
||||
assignee: []
|
||||
created_date: '2026-02-16 04:47'
|
||||
labels: []
|
||||
dependencies: []
|
||||
references:
|
||||
- /home/sudacode/projects/japanese/SubMiner/src/anki-integration.ts
|
||||
- /home/sudacode/projects/japanese/SubMiner/src/anki-integration/
|
||||
priority: low
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
<!-- SECTION:DESCRIPTION:BEGIN -->
|
||||
anki-integration.ts remains the largest file at 1930 lines despite having domain modules extracted to `src/anki-integration/` directory.
|
||||
|
||||
Current state:
|
||||
- Main file: `src/anki-integration.ts` (1930 lines)
|
||||
- Extracted modules:
|
||||
- card-creation.ts (727 lines)
|
||||
- known-word-cache.ts (398 lines)
|
||||
- field-grouping.ts (79 lines)
|
||||
- polling.ts (36 lines)
|
||||
- duplicate.ts (30 lines)
|
||||
- ui-feedback.ts (29 lines)
|
||||
- ai.ts (4.2k)
|
||||
|
||||
This task is to evaluate whether the main anki-integration.ts file can be further decomposed or if 1930 lines is acceptable for a main integration class.
|
||||
|
||||
Evaluation criteria:
|
||||
1. Are there remaining cohesive units that could be extracted?
|
||||
2. Is the remaining code primarily orchestration logic (which is acceptable to be longer)?
|
||||
3. Would further splitting improve or hurt readability?
|
||||
4. Are there internal classes or helpers that could be standalone?
|
||||
|
||||
Deliverable: A decision document with recommendations - either proceed with further decomposition or document why the current state is acceptable.
|
||||
<!-- SECTION:DESCRIPTION:END -->
|
||||
|
||||
## Acceptance Criteria
|
||||
<!-- AC:BEGIN -->
|
||||
- [ ] #1 Review anki-integration.ts structure and identify remaining cohesive units
|
||||
- [ ] #2 Evaluate if extraction would improve or hurt maintainability
|
||||
- [ ] #3 Document decision with rationale
|
||||
- [ ] #4 If proceeding: create extraction plan with specific modules to create
|
||||
- [ ] #5 If not proceeding: document architectural justification for keeping as-is
|
||||
<!-- AC:END -->
|
||||
Reference in New Issue
Block a user