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
47 lines
2.2 KiB
Markdown
47 lines
2.2 KiB
Markdown
# Ü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`.
|