Struktur, Doku und S0-Toolchain fuer das abdulive-Toolkit

Monorepo-Geruest fuer neun Streamer-Tools plus den Ingest-Daemon, der
unter sechs davon liegt. Enthaelt:

- docs/: Ueberblick, Architektur, Twitch-Integration, Datenmodell,
  Roadmap, Setup, Hebel-Analyse und den MVP-Plan "Clip-Knopf"
- docs/projects/: je eine Spezifikation pro Tool
- docs/decisions/: vier ADRs (TS-Monorepo, SQLite, EventSub/IRC, Docker)
- docker/: Image mit ffmpeg und whisper.cpp, abhaengigkeitsfreier
  Entrypoint mit check-env, fetch-model und calibrate
- config/layout.yaml: aus einem VOD-Screenshot eingemessener
  Facecam-Ausschnitt (440x330 oben links, Chat-Overlay ab x=1270)

Noch kein Anwendungscode - Scheibe S0 aus docs/07-mvp-plan.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013VTGjd92LsDDWF3frd9FTB

docs/decisions/ADR-0002-sqlite.md

@@ -0,0 +1,34 @@
+# ADR-0002: SQLite statt Postgres
+
+**Status:** akzeptiert · **Datum:** 2026-09-09
+
+## Kontext
+
+Mehrere Prozesse schreiben und lesen dieselben Daten. Datenvolumen: bei ~10
+Zuschauern und 4 Streams pro Woche etwa 20.000 Chat-Nachrichten und 15.000
+Viewer-Samples pro Monat — wenige MB.
+
+## Entscheidung
+
+SQLite (`better-sqlite3`) im WAL-Modus, eine Datei unter `data/db/`.
+
+## Begründung
+
+- Kein Server, kein Docker, kein Zustand außerhalb einer Datei. Backup ist ein
+  Dateikopie-Vorgang (`VACUUM INTO`).
+- WAL erlaubt beliebig viele gleichzeitige Leser neben einem Schreiber. Genau
+  unsere Topologie: Der Ingest schreibt, alle anderen lesen.
+- `better-sqlite3` ist synchron, was den Code im Ingest erheblich vereinfacht —
+  keine Race Conditions zwischen Event-Verarbeitung und Schreibvorgang.
+- Die Datenmenge ist um Größenordnungen von SQLites Grenzen entfernt.
+
+## Konsequenzen
+
+- **Nur ein schreibender Prozess.** Der Ingest ist der einzige Schreiber für
+  `events`, `chat_messages`, `viewer_samples`, `streams`, `user_streams`.
+  Andere Apps schreiben ausschließlich in ihre eigenen Tabellen (`clips`,
+  `posts`, `redemptions`, `raids`). Diese Aufteilung ist verbindlich.
+- Schreibende Zugriffe immer in Transaktionen bündeln, `busy_timeout` auf 5000 ms.
+- Migration auf Postgres wäre nötig, wenn das Dashboard je remote laufen soll.
+  Steht nicht an; die Repository-Schicht in `packages/db` kapselt SQL genug,
+  dass es machbar bliebe.