update tasks

backlog/tasks/task-10 - Consolidate-service-naming-conventions-and-barrel-exports.md

@@ -1,47 +0,0 @@
----
-id: TASK-10
-title: Consolidate service naming conventions and barrel exports
-status: To Do
-assignee: []
-created_date: '2026-02-11 08:21'
-updated_date: '2026-02-14 00:50'
-labels:
-  - refactor
-  - services
-  - naming
-milestone: Codebase Clarity & Composability
-dependencies: []
-references:
-  - src/core/services/index.ts
-priority: low
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-The service layer has inconsistent naming:
-- Some functions end in `Service`: `handleCliCommandService`, `loadSubtitlePositionService`
-- Some end in `RuntimeService`: `replayCurrentSubtitleRuntimeService`, `sendMpvCommandRuntimeService`
-- Some are plain: `shortcutMatchesInputForLocalFallback`
-- Factory functions mix `create*DepsRuntimeService` with `create*Service`
-
-The barrel export (src/core/services/index.ts) re-exports 79 symbols from 28 files through a single surface, which obscures dependency boundaries. Consumers import everything from `./core/services` and can't tell which service file they actually depend on.
-
-Establish consistent naming:
-- Exported service functions: `verbNounService` (e.g., `handleCliCommand`)  
-- Deps factory functions: `create*Deps`
-- Consider whether the barrel re-export is still the right pattern vs direct imports from individual files.
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [ ] #1 All service functions follow a consistent naming convention
-- [ ] #2 Decision documented on barrel export vs direct imports
-- [ ] #3 No functional changes
-<!-- AC:END -->
-
-## Implementation Notes
-
-<!-- SECTION:NOTES:BEGIN -->
-Naming convention consolidation should be addressed as part of TASK-27.2 (split main.ts) and TASK-27.3 (anki-integration split). As modules are extracted and given clear boundaries, naming will be standardized at each boundary. No need to do a standalone naming pass — it's wasted effort if the module structure is about to change.
-<!-- SECTION:NOTES:END -->

backlog/tasks/task-11 - Break-up-the-applyInvisibleSubtitleLayoutFromMpvMetrics-mega-function.md

@@ -4,12 +4,14 @@ title: Break up the applyInvisibleSubtitleLayoutFromMpvMetrics mega function
 status: To Do
 assignee: []
 created_date: '2026-02-11 08:21'
+updated_date: '2026-02-15 07:00'
 labels:
   - refactor
   - renderer
   - complexity
 milestone: Codebase Clarity & Composability
-dependencies: []
+dependencies:
+  - TASK-27.5
 references:
   - src/renderer/renderer.ts
 priority: medium
@@ -36,3 +38,9 @@ This can be done independently of or as part of TASK-6 (renderer split).
 - [ ] #3 Platform-specific branches isolated into dedicated helpers
 - [ ] #4 Invisible overlay positioning still works correctly on Linux and macOS
 <!-- AC:END -->
+
+## Implementation Notes
+
+<!-- SECTION:NOTES:BEGIN -->
+Reparented as a dependency of TASK-27.5: the mega-function lives in positioning.ts (513 LOC), which is the exact file TASK-27.5 targets for splitting. Decomposing this function is a natural part of that file split. Should be executed together with TASK-27.5.
+<!-- SECTION:NOTES:END -->

backlog/tasks/task-27 - Refactor-project-structure-to-reduce-architectural-complexity-and-split-oversized-modules.md

@@ -3,10 +3,10 @@ id: TASK-27
 title: >-
   Refactor project structure to reduce architectural complexity and split
   oversized modules
-status: To Do
+status: In Progress
 assignee: []
 created_date: '2026-02-13 17:13'
-updated_date: '2026-02-13 21:07'
+updated_date: '2026-02-15 07:00'
 labels:
   - 'owner:architect'
   - 'owner:backend'

backlog/tasks/task-27.7 - Decompose-anki-integration.ts-core-into-domain-modules-field-grouping-card-creation-polling.md

@@ -0,0 +1,48 @@
+---
+id: TASK-27.7
+title: >-
+  Decompose anki-integration.ts core into domain modules (field-grouping,
+  card-creation, polling)
+status: To Do
+assignee: []
+created_date: '2026-02-15 07:00'
+labels:
+  - refactor
+  - anki
+  - architecture
+dependencies:
+  - TASK-27.3
+references:
+  - src/anki-integration.ts
+  - src/anki-integration-duplicate.ts
+  - src/anki-integration-ui-feedback.ts
+  - src/anki-integration/ai.ts
+parent_task_id: TASK-27
+priority: high
+---
+
+## Description
+
+<!-- SECTION:DESCRIPTION:BEGIN -->
+TASK-27.3 extracted leaf clusters (duplicate-detection 102 LOC, ai-translation 158 LOC, ui-feedback 107 LOC) but the core class remains at 2935 LOC. The heavy decomposition from the original TASK-27.3 plan was never executed.
+
+Remaining extractions from the original plan:
+1. **field-grouping** (~900 LOC) — `triggerFieldGroupingForLastAddedCard`, `applyFieldGrouping`, `computeFieldGroupingMergedFields`, `buildFieldGroupingPreview`, `performFieldGroupingMerge`, `handleFieldGroupingAuto`, `handleFieldGroupingManual`, plus ~15 span/parse/normalize helpers
+2. **card-creation** (~350 LOC) — `createSentenceCard`, `setCardTypeFields`, `extractFields`, `processSentence`, field resolution helpers
+3. **polling/lifecycle** (~250 LOC) — `start`, `stop`, `poll`, `pollOnce`, `processNewCard`
+
+Also consolidate the scattered extraction files into `src/anki-integration/`:
+- `src/anki-integration-duplicate.ts` → `src/anki-integration/duplicate.ts`
+- `src/anki-integration-ui-feedback.ts` → `src/anki-integration/ui-feedback.ts`
+- `src/anki-integration/ai.ts` (already there)
+<!-- SECTION:DESCRIPTION:END -->
+
+## Acceptance Criteria
+<!-- AC:BEGIN -->
+- [ ] #1 anki-integration.ts reduced below 800 LOC (facade + private state wiring only)
+- [ ] #2 Field-grouping cluster (~900 LOC) extracted as its own module under src/anki-integration/
+- [ ] #3 Card-creation and polling/lifecycle extracted as separate modules
+- [ ] #4 All extracted modules consolidated under src/anki-integration/ directory
+- [ ] #5 Existing facade API preserved — external callers unchanged
+- [ ] #6 All existing tests pass; build compiles cleanly
+<!-- AC:END -->

backlog/tasks/task-33 - Restrict-mpv-socket-connection-logs-to-debug-mode-in-Electron.md

@@ -10,8 +10,7 @@ labels:
   - mpv
   - frontend
   - quality
-dependencies:
-  - TASK-28
+dependencies: []
 priority: high
 ---
 

backlog/tasks/task-8 - Reduce-MpvIpcClient-deps-interface-and-separate-protocol-from-application-logic.md

@@ -1,38 +0,0 @@
----
-id: TASK-8
-title: >-
-  Reduce MpvIpcClient deps interface and separate protocol from application
-  logic
-status: To Do
-assignee: []
-created_date: '2026-02-11 08:20'
-labels:
-  - refactor
-  - mpv
-  - architecture
-milestone: Codebase Clarity & Composability
-dependencies: []
-references:
-  - src/core/services/mpv-service.ts
-priority: medium
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-MpvIpcClient (761 lines) in src/core/services/mpv-service.ts has a 22-property `MpvIpcClientDeps` interface that reaches back into main.ts state for application-level concerns (overlay visibility, subtitle timing, media path updates, OSD display).
-
-The class mixes two responsibilities:
-1. **IPC Protocol**: Socket connection, JSON message framing, reconnection, property observation
-2. **Application Integration**: Subtitle text broadcasting, overlay visibility sync, timing tracking
-
-Separating these would let the protocol layer be simpler and testable, while application-level reactions to mpv events could be handled by listeners/callbacks registered externally.
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [ ] #1 MpvIpcClient deps interface reduced to protocol-level concerns only
-- [ ] #2 Application-level reactions (subtitle broadcast, overlay sync, timing) handled via event emitter or external listeners
-- [ ] #3 MpvIpcClient is testable without mocking 22 callbacks
-- [ ] #4 Existing behavior preserved
-<!-- AC:END -->

backlog/tasks/task-9 - Remove-trivial-wrapper-functions-from-main.ts.md

@@ -1,54 +0,0 @@
----
-id: TASK-9
-title: Remove trivial wrapper functions from main.ts
-status: To Do
-assignee: []
-created_date: '2026-02-11 08:21'
-updated_date: '2026-02-14 00:48'
-labels:
-  - refactor
-  - main
-  - simplicity
-milestone: Codebase Clarity & Composability
-dependencies:
-  - TASK-7
-references:
-  - src/main.ts
-priority: low
----
-
-## Description
-
-<!-- SECTION:DESCRIPTION:BEGIN -->
-main.ts contains many trivial single-line wrapper functions that add indirection without value:
-
-```typescript
-function getOverlayWindows(): BrowserWindow[] {
-  return overlayManager.getOverlayWindows();
-}
-function updateOverlayBounds(geometry: WindowGeometry): void {
-  updateOverlayBoundsService(geometry, () => getOverlayWindows());
-}
-function ensureOverlayWindowLevel(window: BrowserWindow): void {
-  ensureOverlayWindowLevelService(window);
-}
-```
-
-Similarly, config accessor wrappers like `getJimakuLanguagePreference()`, `getJimakuMaxEntryResults()`, `resolveJimakuApiKey()` are pure boilerplate.
-
-After TASK-7 (AppState container), many of these can be eliminated by having services access the state container directly, or by using the service functions directly at call sites without local wrappers.
-<!-- SECTION:DESCRIPTION:END -->
-
-## Acceptance Criteria
-<!-- AC:BEGIN -->
-- [ ] #1 Trivial pass-through wrappers eliminated (call service/manager directly)
-- [ ] #2 Config accessor wrappers replaced with direct calls or a config accessor helper
-- [ ] #3 main.ts line count reduced
-- [ ] #4 No functional changes
-<!-- AC:END -->
-
-## Implementation Notes
-
-<!-- SECTION:NOTES:BEGIN -->
-Priority changed from medium to low: this work is largely subsumed by TASK-27.2 (split main.ts). When main.ts is decomposed into composition-root modules, trivial wrappers will naturally be eliminated or inlined. Recommend folding remaining wrapper cleanup into TASK-27.2 rather than tracking separately. Keep this ticket as a checklist reference but don't execute independently.
-<!-- SECTION:NOTES:END -->