update docs and deps

backlog/tasks/task-57 - Evaluate-anki-integration.ts-for-further-decomposition.md

@@ -4,52 +4,57 @@ title: Evaluate anki-integration.ts for further decomposition
 status: To Do
 assignee: []
 created_date: '2026-02-16 04:47'
-labels: []
+updated_date: '2026-02-22 07:14'
+labels:
+  - maintainability
+  - anki
 dependencies: []
 references:
   - /home/sudacode/projects/japanese/SubMiner/src/anki-integration.ts
   - /home/sudacode/projects/japanese/SubMiner/src/anki-integration/
-priority: low
+priority: medium
 ---
 
 ## Description
 
 <!-- SECTION:DESCRIPTION:BEGIN -->
 
-anki-integration.ts remains the largest file at 1930 lines despite having domain modules extracted to `src/anki-integration/` directory.
+`src/anki-integration.ts` remains a major hotspot after refactors and still centralizes too many adapter and helper responsibilities.
 
 Current state:
 
-- Main file: `src/anki-integration.ts` (1930 lines)
+- Main file: `src/anki-integration.ts` (~1120 lines on 2026-02-22)
 - 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)
+  - workflow and service collaborators already exist under `src/anki-integration/*`
+  - main class still owns media generation wrappers, field parsing helpers, config normalization, and notification plumbing
 
-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.
+This task decides and documents the next decomposition move, then prepares an implementation-ready extraction plan.
 
 <!-- SECTION:DESCRIPTION:END -->
 
+## Action Steps
+
+<!-- SECTION:PLAN:BEGIN -->
+1. Re-map `src/anki-integration.ts` by concern: orchestration, media generation wrappers, field parsing helpers, notification/UI feedback, runtime config patching.
+2. Identify cohesive extraction candidates that reduce class surface without adding indirection noise.
+3. Define target module boundaries and public interfaces for each candidate extraction.
+4. Produce a concrete follow-up implementation plan (candidate files, migration order, regression tests).
+5. If no extraction is justified, record explicit rationale and closure criteria.
+<!-- SECTION:PLAN: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
+- [ ] #1 Current anki-integration responsibilities are documented with concrete line/section mapping.
+- [ ] #2 At least one recommended path is chosen: extraction plan or explicit keep-as-is rationale.
+- [ ] #3 Decision includes maintainability tradeoffs and expected impact on testability/readability.
+- [ ] #4 Follow-up implementation scope (files/tests/sequence) is explicit enough to execute directly.
 <!-- AC:END -->
+
+## Definition of Done
+<!-- DOD:BEGIN -->
+- [ ] #1 Decision + plan/rationale is captured in task notes.
+- [ ] #2 Any proposed extraction references existing collaborators under `src/anki-integration/*`.
+- [ ] #3 Follow-up implementation task(s) are created if extraction is recommended.
+<!-- DOD:END -->