ZeasyAlexandClaude Opus 5
d09e2b945a
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
2.2 KiB
2.2 KiB
Ü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
- 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.
- 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.
- Jedes Tool ist einzeln benutzbar. Kein Tool wartet auf ein anderes, außer auf den Ingest-Daemon.
- 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.
- 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.