Refactor startup/logging service wiring and related test/config updates

This commit is contained in:
2026-02-15 21:02:54 -08:00
parent c6ac962f7a
commit bec69d1b71
41 changed files with 722 additions and 281 deletions

View File

@@ -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 -->

View File

@@ -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 -->

View File

@@ -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 -->

View File

@@ -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 -->

View File

@@ -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 -->