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/00-overview.md

@@ -0,0 +1,46 @@
+# Überblick
+
+## Ausgangslage
+
+abdulive_ ist ein kleiner Twitch-Kanal in der Phase 5–30 gleichzeitiger
+Zuschauer. In dieser Phase gelten andere Regeln als bei größeren Kanälen:
+
+- **Twitch selbst bringt kaum Entdeckung.** Die Browse-Seite sortiert nach
+  Viewerzahl. Unter 30 CCV ist man dort faktisch unsichtbar. Reichweite muss
+  von außen kommen.
+- **Jeder einzelne Zuschauer zählt überproportional.** Bei 10 Leuten ist der
+  Unterschied zwischen "hat zugeschaut" und "kommt wieder" der ganze Kanal.
+- **Zeit ist der Engpass, nicht Ideen.** Alles, was manuell passieren muss,
+  passiert unregelmäßig oder gar nicht.
+
+Daraus folgen drei Wirkrichtungen, und jedes Tool hier gehört in genau eine:
+
+| Richtung | Frage | Tools |
+|----------|-------|-------|
+| **Reichweite** | Wie finden mich neue Leute? | Clip-to-Shorts, Go-Live-Broadcaster, Raid-Tool |
+| **Bindung** | Warum kommen sie wieder? | Community-Gedächtnis, Chat-Steuerung, Punktesystem, Recap |
+| **Steuerung** | Was funktioniert überhaupt? | Analytics-Dashboard, VOD-Kapitel |
+
+## Leitprinzipien
+
+1. **Ein Ingest, viele Konsumenten.** Chat und Events werden genau einmal
+   eingelesen. Jedes Tool liest aus derselben Datenbank bzw. demselben
+   Event-Bus. Kein Tool baut sich eine zweite IRC-Verbindung.
+2. **Alles läuft lokal.** Ein Rechner, ein Prozessverbund, SQLite. Kein Cloud-
+   Deployment, keine Container-Orchestrierung. Das ist keine Sparmaßnahme,
+   sondern die richtige Größe.
+3. **Jedes Tool ist einzeln benutzbar.** Kein Tool wartet auf ein anderes,
+   außer auf den Ingest-Daemon.
+4. **Nichts postet ungefragt nach außen.** Alles, was den Kanal verlässt
+   (Social-Posts, Uploads, Raids), erzeugt standardmäßig einen Entwurf, den
+   Abdu freigibt. Auto-Post ist ein Schalter, kein Default.
+5. **Rohdaten werden nie weggeworfen.** Jede Chat-Nachricht, jeder Viewer-Sample
+   landet in der DB. Auswertungen kann man nachträglich ändern, Daten nicht
+   nachträglich erheben.
+
+## Was hier bewusst *nicht* gebaut wird
+
+- Kein Multi-Tenant-System. Ein Kanal.
+- Kein eigener Chatbot-Ersatz für Moderation (Nightbot/StreamElements bleiben,
+  wo sie sind, solange sie reichen).
+- Keine Web-Auth/Userverwaltung im Dashboard — es läuft auf `localhost`.