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
This commit is contained in:
commit
d09e2b945a
98 files changed
+3273
No files matched your search
@@ -0,0 +1,103 @@
|
||||
# Hebel-Analyse: womit anfangen
|
||||
|
||||
## Bewertung aller neun Ideen
|
||||
|
||||
Bewertet nach vier Achsen. **Wirkung** = erwarteter Effekt auf Kanalwachstum in
|
||||
den nächsten 3 Monaten. **Aufwand** = Entwicklungszeit bis zu einer Version, die
|
||||
im echten Stream läuft. **Risiko** = Wahrscheinlichkeit, dass es technisch oder
|
||||
sozial nicht funktioniert. **Abhängig von** = was vorher stehen muss.
|
||||
|
||||
| Tool | Wirkung | Aufwand | Risiko | Abhängig von | Hebel |
|
||||
|---|---|---|---|---|---|
|
||||
| **Ingest-Daemon** | — (indirekt) | 2–3 Tage | niedrig | — | **Voraussetzung** |
|
||||
| **Clip-to-Shorts** | sehr hoch | 8–12 Tage | mittel | Ingest, OBS | **★★★★★** |
|
||||
| **Community-Gedächtnis** | hoch | 2–3 Tage | niedrig | Ingest | **★★★★★** |
|
||||
| **Go-Live-Broadcaster** | mittel | 1–2 Tage | niedrig | Ingest | ★★★★☆ |
|
||||
| **Analytics-Dashboard** | mittel (indirekt) | 4–6 Tage | niedrig | Ingest | ★★★☆☆ |
|
||||
| **Raid-/Netzwerk-Tool** | mittel–hoch | 3–4 Tage | niedrig | Ingest | ★★★☆☆ |
|
||||
| **Stream-Recap** | mittel | 2 Tage | niedrig | Ingest, Analytics | ★★★☆☆ |
|
||||
| **Chat steuert Dinge** | mittel | 5–8 Tage | mittel | Overlay-Server | ★★☆☆☆ |
|
||||
| **Punktesystem + Shop** | niedrig–mittel | 4–6 Tage | mittel | Overlay, Loyalty | ★★☆☆☆ |
|
||||
| **VOD-Kapitel** | niedrig | 2 Tage | niedrig | Ingest | ★☆☆☆☆ |
|
||||
|
||||
## Die Antwort
|
||||
|
||||
**Der größte Hebel ist die Clip-to-Shorts-Pipeline.** Deine Einschätzung stimmt:
|
||||
Bei 5–30 Zuschauern ist Twitchs eigene Entdeckung praktisch tot, weil die
|
||||
Browse-Seite nach Viewerzahl sortiert. Off-Platform-Kurzvideo ist der einzige
|
||||
Kanal, in dem ein kleiner Account nichtlineare Reichweite bekommen kann — ein
|
||||
Short kann 50.000 Leute erreichen, während der Stream 11 hat. Kein anderes Tool
|
||||
in dieser Liste hat diese Größenordnung.
|
||||
|
||||
**Aber du kannst nicht mit ihr anfangen.** Sie braucht einen Trigger, und der
|
||||
Trigger braucht eine Chat-Verbindung, Stream-Session-Erkennung und einen
|
||||
Event-Bus. Das ist der Ingest-Daemon — 2–3 Tage, die ohnehin zur Clip-Pipeline
|
||||
gehören.
|
||||
|
||||
Und genau das macht die Reihenfolge einfach: **Wenn der Ingest steht, kostet das
|
||||
Community-Gedächtnis noch zwei Tage extra**, weil es fast nur Auswertung
|
||||
vorhandener Daten ist. Damit hast du in einem Monat beide Seiten abgedeckt:
|
||||
|
||||
- **Clips bringen Leute rein** (Reichweite)
|
||||
- **Community-Gedächtnis sorgt dafür, dass sie bleiben** (Bindung)
|
||||
|
||||
Das eine ohne das andere verpufft. Ein viraler Clip, der 300 Leute in einen
|
||||
Stream spült, in dem niemand ihre Namen kennt, bringt am nächsten Tag null
|
||||
Rückkehrer. Umgekehrt bindet die beste Community-Pflege niemanden, der nie
|
||||
ankommt.
|
||||
|
||||
## Zwei Dinge, die du an der Clip-Pipeline anders bauen solltest, als es
|
||||
## zunächst naheliegt
|
||||
|
||||
**1. Nicht auf Chat-Spikes triggern — jedenfalls nicht zuerst.**
|
||||
Bei 10 Zuschauern ist die Nachrichtenrate so niedrig, dass "Spike" statistisch
|
||||
kaum von Rauschen zu trennen ist. Drei Leute, die gleichzeitig "lol" schreiben,
|
||||
sind bereits eine Verdreifachung. Der Detektor läuft von Anfang an mit und
|
||||
schreibt jeden Kandidaten mit Score in die DB — aber **scharf geschaltet wird er
|
||||
erst, wenn du an echtem Material siehst, wo die Schwelle liegen muss.** Als
|
||||
Trigger reichen anfangs `!clip` im Chat und ein Hotkey für dich. Der Hotkey ist
|
||||
ohnehin das beste Signal, das es gibt: Du weißt am besten, wann gerade etwas
|
||||
Gutes passiert ist.
|
||||
|
||||
**2. Nicht die Twitch-Clip-API als Videoquelle nehmen, sondern den
|
||||
OBS-Replay-Buffer.** Der Twitch-Clip ist ein Transcode des fertig komponierten
|
||||
1920×1080-Bildes — Facecam und Gameplay musst du per Crop wieder auseinander
|
||||
schneiden, und die Qualität ist schon einmal durch einen Encoder gelaufen. Der
|
||||
Replay-Buffer liefert dir dieselben 30–90 Sekunden in Aufnahmequalität, sofort,
|
||||
ohne API-Wartezeit. Und wenn du in OBS eine zweite Aufnahmespur oder eine
|
||||
Vertical-Szene einrichtest, sind Cam und Gameplay dort bereits getrennt — dann
|
||||
entfällt das ganze Crop-Problem. Den Twitch-Clip erzeugst du trotzdem
|
||||
gleichzeitig, weil er eine teilbare URL hat.
|
||||
|
||||
Beides steht ausführlich in [`projects/clip-shorts.md`](projects/clip-shorts.md).
|
||||
|
||||
## Was ich in dieser Reihenfolge nach hinten schieben würde
|
||||
|
||||
**Punktesystem und Chat-Minispiele.** Beides ist Spaß und beides macht viel
|
||||
Arbeit, aber es wirkt nur auf Leute, die schon da sind — und bei 10 Zuschauern
|
||||
sind das zu wenige, als dass ein Shop-Ökosystem trägt. Punkte werden erst
|
||||
interessant, wenn genug Leute regelmäßig da sind, dass sie überhaupt genug
|
||||
sammeln können. Das ist ein Werkzeug für 30–50 CCV, nicht für 10.
|
||||
|
||||
**VOD-Kapitel.** Nettes Detail, aber die VODs eines kleinen Kanals werden kaum
|
||||
geschaut. Der Aufwand ist klein, deshalb kommt es trotzdem irgendwann — aber
|
||||
nicht in den ersten zwei Monaten. Sinnvoll wird es in dem Moment, in dem du
|
||||
anfängst, VODs auf YouTube zweitzuverwerten.
|
||||
|
||||
## Konkreter Vorschlag für die ersten vier Wochen
|
||||
|
||||
| Woche | Was | Ergebnis |
|
||||
|---|---|---|
|
||||
| **1** | Ingest-Daemon + DB-Schema + Auth | Jede Nachricht, jeder Viewer-Sample landet in der DB. Ab hier sammelst du Daten, auch wenn noch nichts damit passiert. |
|
||||
| **2** | Clip-Pipeline Teil 1: `!clip` + Hotkey → OBS-Replay → `raw.mp4` | Auf Knopfdruck liegt ein Clip auf der Platte. |
|
||||
| **3** | Clip-Pipeline Teil 2: 9:16-Crop + Whisper-Untertitel + Freigabe-Ansicht | Fertige Upload-Kandidaten nach jedem Stream. |
|
||||
| **4** | Community-Gedächtnis + Go-Live-Broadcaster | Erstchatter werden erkannt, du siehst im Overlay, wer reinkommt, und der Stream-Start wird automatisch angekündigt. |
|
||||
|
||||
Danach, nach Bedarf: Analytics-Dashboard (Woche 5–6, wertet dann bereits vier
|
||||
Wochen echte Daten aus — deshalb lohnt es sich, den Ingest jetzt zu bauen und
|
||||
das Dashboard später), dann Raid-Tool, dann Recap.
|
||||
|
||||
**Der wichtigste Satz in diesem Dokument:** Der Ingest-Daemon in Woche 1 sammelt
|
||||
Daten, die du später nicht rückwirkend erheben kannst. Selbst wenn danach zwei
|
||||
Monate nichts passiert, ist er die beste Investition, weil jedes spätere Tool
|
||||
dann sofort auf einem Berg echter Daten aufsetzt statt bei null anzufangen.
|
||||
Reference in new issue
Block a user