docs: add stats dashboard design docs, plans, and knowledge base

- Stats dashboard redesign design and implementation plans
- Episode detail and Anki card link design
- Internal knowledge base restructure
- Backlog tasks for testing, verification, and occurrence tracking

docs/architecture/README.md

@@ -0,0 +1,37 @@
+<!-- read_when: changing runtime wiring, moving code across layers, or trying to find ownership -->
+
+# Architecture Map
+
+Status: active
+Last verified: 2026-03-13
+Owner: Kyle Yasuda
+Read when: runtime ownership, composition boundaries, or layering questions
+
+SubMiner runs as three cooperating runtimes:
+
+- Electron desktop app in `src/`
+- Launcher CLI in `launcher/`
+- mpv Lua plugin in `plugin/subminer/`
+
+The desktop app keeps `src/main.ts` as composition root and pushes behavior into small runtime/domain modules.
+
+## Read Next
+
+- [Domains](./domains.md) - who owns what
+- [Layering](./layering.md) - how modules should depend on each other
+- Public contributor summary: [`docs-site/architecture.md`](../../docs-site/architecture.md)
+
+## Current Shape
+
+- `src/main/` owns composition, runtime setup, IPC wiring, and app lifecycle adapters.
+- `src/core/services/` owns focused runtime services plus pure or side-effect-bounded logic.
+- `src/renderer/` owns overlay rendering and input behavior.
+- `src/config/` owns config definitions, defaults, loading, and resolution.
+- `src/main/runtime/composers/` owns larger domain compositions.
+
+## Architecture Intent
+
+- Small units, explicit boundaries
+- Composition over monoliths
+- Pure helpers where possible
+- Stable user behavior while internals evolve

docs/architecture/domains.md

@@ -0,0 +1,38 @@
+<!-- read_when: locating ownership for a runtime, feature, or integration -->
+
+# Domain Ownership
+
+Status: active
+Last verified: 2026-03-13
+Owner: Kyle Yasuda
+Read when: you need to find the owner module for a behavior or test surface
+
+## Runtime Domains
+
+- Desktop app runtime: `src/main.ts`, `src/main/`, `src/core/services/`
+- Overlay renderer: `src/renderer/`
+- Launcher CLI: `launcher/`
+- mpv plugin: `plugin/subminer/`
+
+## Product / Integration Domains
+
+- Config system: `src/config/`
+- Overlay/window state: `src/core/services/overlay-*`, `src/main/overlay-*.ts`
+- MPV runtime and protocol: `src/core/services/mpv*.ts`
+- Subtitle/token pipeline: `src/core/services/tokenizer*`, `src/subtitle/`, `src/tokenizers/`
+- Anki workflow: `src/anki-integration/`, `src/core/services/anki-jimaku*.ts`
+- Immersion tracking: `src/core/services/immersion-tracker/`
+- AniList tracking: `src/core/services/anilist/`, `src/main/runtime/composers/anilist-*`
+- Jellyfin integration: `src/core/services/jellyfin*.ts`, `src/main/runtime/composers/jellyfin-*`
+- Window trackers: `src/window-trackers/`
+- Stats app: `stats/`
+- Public docs site: `docs-site/`
+
+## Ownership Heuristics
+
+- Runtime wiring or dependency setup: start in `src/main/`
+- Business logic or service behavior: start in `src/core/services/`
+- UI interaction or overlay DOM behavior: start in `src/renderer/`
+- Command parsing or mpv launch flow: start in `launcher/`
+- User-facing docs: `docs-site/`
+- Internal process/docs: `docs/`

docs/architecture/layering.md

@@ -0,0 +1,33 @@
+<!-- read_when: adding dependencies, moving files, or reviewing architecture drift -->
+
+# Layering Rules
+
+Status: active  
+Last verified: 2026-03-13  
+Owner: Kyle Yasuda  
+Read when: deciding whether a dependency direction is acceptable
+
+## Preferred Dependency Flow
+
+1. `src/main.ts`
+2. `src/main/` composition and runtime adapters
+3. `src/core/services/` focused services
+4. `src/core/utils/` and other pure helpers
+
+Renderer, launcher, plugin, and stats each keep their own local layering and should not become a grab bag for unrelated cross-runtime behavior.
+
+## Rules
+
+- Keep `src/main.ts` thin; wire, do not implement.
+- Prefer injecting dependencies from `src/main/` instead of reaching outward from core services.
+- Keep side effects explicit and close to composition boundaries.
+- Put reusable business logic in focused services, not in top-level lifecycle files.
+- Keep renderer concerns in `src/renderer/`; avoid leaking DOM behavior into main-process code.
+- Treat `launcher/*.ts` as source of truth for the launcher. Never hand-edit `dist/launcher/subminer`.
+
+## Smells
+
+- `main.ts` grows because logic was not extracted
+- service reaches directly into unrelated runtime state
+- renderer code depends on main-process internals
+- docs-site page becomes the only place internal architecture is explained