S1: Einrichtungs-Assistent, Twitch-Auth, Datenbank und Chat-Aufnahme

Zugangsdaten kommen jetzt aus der App statt aus einer .env: ein
Einrichtungs-Assistent auf http://localhost:4792/setup nimmt Client-ID,
Secret und OBS-Passwort entgegen, der OAuth-Rueckruf laeuft auf denselben
Server. Gespeichert wird verschlueselt (AES-256-GCM) in einem Volume,
bewusst nicht in der Datenbank - die wird auf die Windows-Seite gesichert.
Siehe ADR-0005.

Technikbasis vereinfacht: Node 24 bringt node:sqlite, WebSocket, fetch und
die Ausfuehrung von TypeScript mit. Das Projekt hat damit null
Laufzeitabhaengigkeiten und keinen Build-Schritt; pnpm-Workspaces und die
Paketmanifeste sind entfallen, Importe laufen ueber die imports-Map der
Wurzel-package.json. erasableSyntaxOnly verhindert Syntax, die das Type
Stripping stillschweigend entfernen wuerde. Siehe Nachtrag 2 in ADR-0001.

Enthalten:
- packages/core: Config, Layout, Logger mit Secret-Maskierung, Retry, YAML
- packages/db: Migrationen, Repositories, alle SQL-Anweisungen an einem Ort
- packages/twitch: Secret-Speicher, OAuth, Helix mit Token-Bucket, IRC
- apps/ingest: Daemon, Einrichtungsseite, Spike-Erkennung
- 20 Tests (IRC-Parser, Spike-Detektor, Datenbankschicht)

Der Chat verbindet sich anonym, solange nichts hinterlegt ist - damit laesst
sich die Datenaufnahme pruefen, bevor die Twitch-Apps existieren.

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

docs/decisions/ADR-0001-monorepo-typescript.md

@@ -13,12 +13,40 @@ riecht; Teile sind Browser-Overlays, was TypeScript nahelegt.
 Alles in TypeScript auf Node 22, als pnpm-Workspace-Monorepo. ffmpeg und
 whisper.cpp werden als **CLI-Prozesse** aufgerufen, nicht über Sprachbindings.
 
-> **Nachtrag 2026-09-09:** Ursprünglich war faster-whisper (Python) vorgesehen.
-> Der Check der Zielmaschine ergab Python 3.14, für das `ctranslate2` noch keine
-> verlässlichen Wheels liefert. Da ohnehin nur ein Kommandozeilenaufruf
-> gebraucht wird, fällt die Wahl auf **whisper.cpp** — eine einzelne Binary
-> ohne Laufzeitabhängigkeiten. Damit entfällt Python vollständig aus dem
-> Projekt. Siehe [ADR-0004](ADR-0004-docker.md).
+> **Nachtrag 1 (2026-09-09):** Ursprünglich war faster-whisper (Python)
+> vorgesehen. Der Check der Zielmaschine ergab Python 3.14, für das
+> `ctranslate2` noch keine verlässlichen Wheels liefert. Da ohnehin nur ein
+> Kommandozeilenaufruf gebraucht wird, fällt die Wahl auf **whisper.cpp** —
+> eine einzelne Binary ohne Laufzeitabhängigkeiten. Damit entfällt Python
+> vollständig. Siehe [ADR-0004](ADR-0004-docker.md).
+
+> **Nachtrag 2 (2026-09-09, beim Bau von S1):** Der Plan sah pnpm-Workspaces
+> mit einem Paketmanifest je Paket und einen `tsc`-Build vor. Beides ist
+> weggefallen, weil sich beim Bauen zeigte, dass **Node 24 alles Nötige
+> mitbringt**:
+>
+> | Gebraucht | Statt npm-Paket | Eingebaut |
+> |---|---|---|
+> | SQLite | `better-sqlite3` (nativ, node-gyp) | `node:sqlite` |
+> | WebSocket-Client | `ws` | globales `WebSocket` |
+> | HTTP-Aufrufe | `undici`/`axios` | globales `fetch` |
+> | TypeScript ausführen | `tsc`-Build, `tsx` | Type Stripping |
+> | YAML | `yaml` | eigener Leser, 130 Zeilen |
+>
+> Das Projekt hat damit **null Laufzeitabhängigkeiten und keinen
+> Build-Schritt**. `node docker/entrypoint.ts` läuft direkt. Auflösung der
+> paketübergreifenden Importe (`#core/…`, `#db/…`) über die `imports`-Map in
+> der Wurzel-`package.json` — ebenfalls eine Node-Funktion, kein Werkzeug.
+>
+> Konsequenz: Die Paketmanifeste und `pnpm-workspace.yaml` sind gelöscht, es
+> gibt eine `package.json`. `typescript` bleibt als einzige
+> Entwicklungsabhängigkeit für `tsc --noEmit`.
+>
+> **Preis:** Nur *löschbare* TypeScript-Syntax ist erlaubt — keine `enum`,
+> keine Parameter-Properties, keine `namespace`. Das erzwingt
+> `erasableSyntaxOnly: true` in der `tsconfig.json`, und es hat beim ersten
+> Durchlauf sofort einen echten Fund gehabt (`constructor(private capacity)`
+> im Helix-Client, das zur Laufzeit stillschweigend verschwunden wäre).
 
 ## Begründung
 

docs/decisions/ADR-0002-sqlite.md

@@ -10,7 +10,8 @@ Viewer-Samples pro Monat — wenige MB.
 
 ## Entscheidung
 
-SQLite (`better-sqlite3`) im WAL-Modus, eine Datei unter `data/db/`.
+SQLite über das eingebaute **`node:sqlite`** im WAL-Modus, eine Datei im
+Docker-Volume `abdulive-db`.
 
 ## Begründung
 
@@ -18,8 +19,11 @@ SQLite (`better-sqlite3`) im WAL-Modus, eine Datei unter `data/db/`.
   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.
+- `node:sqlite` ist synchron (`DatabaseSync`), was den Code im Ingest erheblich
+  vereinfacht - keine Race Conditions zwischen Ereignisverarbeitung und
+  Schreibvorgang.
+- Es ist **in Node 24 enthalten**: keine native Abhaengigkeit, kein node-gyp,
+  keine Prebuild-Suche im Docker-Build. Siehe Nachtrag 2 in ADR-0001.
 - Die Datenmenge ist um Größenordnungen von SQLites Grenzen entfernt.
 
 ## Konsequenzen

docs/decisions/ADR-0005-zugangsdaten.md

@@ -0,0 +1,87 @@
+# ADR-0005: Zugangsdaten kommen aus der App, nicht aus der `.env`
+
+**Status:** akzeptiert · **Datum:** 2026-09-09
+
+## Kontext
+
+Das Toolkit braucht Client-ID und Client-Secret zweier Twitch-Apps, ein
+obs-websocket-Passwort und später Discord-/Bluesky-Zugänge. Der erste Entwurf
+sah dafür eine `.env`-Datei vor, die von Hand befüllt wird.
+
+Das passt nicht zum Nutzer. Abdu ist Streamer, kein Entwickler. „Kopiere
+`.env.example` nach `.env` und trage sieben Werte ein" ist die Stelle, an der
+ein Werkzeug liegen bleibt. Und es kommt ein zweites Problem dazu, das für
+diesen Anwendungsfall besonders zählt: **Wer eine Klartextdatei mit
+Zugangsdaten öffnet, während er sendet, hat sie live gezeigt.**
+
+## Entscheidung
+
+Zugangsdaten werden über einen **Einrichtungs-Assistenten im Browser**
+eingegeben, unter `http://localhost:4792/setup`. Gespeichert werden sie
+verschlüsselt in `/db/secrets.json` im Docker-Volume.
+
+Die `.env` bleibt bestehen, enthält aber nur noch **optionale** Werte
+(Log-Level, Pfad zum Wiedergabepuffer). Ohne `.env` startet alles.
+
+Damit fällt auch Port 4780 weg: Einrichtung, OAuth-Rücksprung und später
+Sichtungsseite und Dashboard laufen über **einen** Server auf Port 4792. Die
+Redirect-URI in der Twitch-App lautet entsprechend
+`http://localhost:4792/callback`.
+
+## Speicherung
+
+| | |
+|---|---|
+| Ort | `/db/secrets.json`, benanntes Volume `abdulive-db` |
+| Verfahren | AES-256-GCM, Schlüssel in `/db/.secret-key` (Modus 0600) |
+| Schlüssel | wird beim ersten Start erzeugt, nie ausgegeben, nie geloggt |
+| **Nicht** in SQLite | damit das Backup-Skript sie nie mitkopiert |
+
+Die Secrets liegen bewusst **außerhalb der Datenbank**. `scripts/backup.ps1`
+zieht die `.db` aus dem Volume nach `data/db/backup/` — also auf die
+Windows-Seite, wo sie in einer Cloud-Synchronisation landen kann. Was dort
+nichts zu suchen hat, darf gar nicht erst in der Datenbank stehen.
+
+## Was diese Verschlüsselung leistet — und was nicht
+
+Der Schlüssel liegt im selben Volume wie die verschlüsselten Daten. Gegen
+jemanden, der Zugriff auf das Volume hat, schützt das **nicht**, und es wird
+hier auch nicht so getan.
+
+Wogegen es schützt, und das ist der eigentliche Zweck:
+
+- **Versehentliche Anzeige im Stream.** `cat secrets.json` zeigt Kauderwelsch,
+  keine Client-Secrets.
+- **Verirrte Kopien.** Ein Volume-Export oder ein weitergegebener Ordner
+  enthält ohne die Schlüsseldatei nichts Verwertbares.
+- **Grep-Unfälle.** Secrets tauchen in keiner Volltextsuche und in keinem
+  versehentlich geteilten Log auf.
+
+Gegen eine Kompromittierung der Maschine schützt es nicht. Das ist bei einem
+lokalen Einzelplatzwerkzeug auch nicht das Bedrohungsmodell — wer dort Zugriff
+hat, hat auch Zugriff auf OBS, den Browser und die gespeicherten Twitch-Cookies.
+
+## Konsequenzen für die Oberfläche
+
+- Der Einrichtungs-Assistent **zeigt gespeicherte Secrets nie wieder an.**
+  Nach dem Speichern steht dort `••••••  gespeichert` und ein Knopf *Ersetzen*.
+- Über der Seite steht ein Hinweis: **„Diese Seite zeigt Zugangsdaten — nicht
+  im Stream öffnen."**
+- Der Server ist nur lokal erreichbar. **Nicht** dadurch, dass er im Container
+  auf `127.0.0.1` bindet — das wäre dort die Container-Loopback, die Dockers
+  Portweiterleitung nie erreicht, der Dienst wäre schlicht tot. Die Abschottung
+  kommt aus zwei Teilen: der Container bindet auf `0.0.0.0` **innerhalb seines
+  eigenen Netzwerk-Namensraums**, und Compose veröffentlicht den Port
+  ausschließlich als `127.0.0.1:4792`. Außerhalb von Docker bindet der Server
+  weiterhin auf die Loopback-Adresse; gesteuert über `BIND_HOST`, das nur das
+  Image auf `0.0.0.0` setzt.
+- Secrets werden nie geloggt, auch nicht bei Fehlern. Der Logger maskiert
+  bekannte Schlüsselnamen.
+- `check-env` meldet, *ob* Zugangsdaten hinterlegt sind, nie *welche*.
+
+## Preis
+
+Der Einrichtungs-Assistent kostet in S1 ungefähr einen zusätzlichen Tag —
+kleiner HTTP-Server, eine Seite, der Secret-Speicher. Dafür entfällt der
+gesamte `.env`-Schritt aus der Inbetriebnahme, und das Werkzeug lässt sich
+später ohne Texteditor umkonfigurieren.

docs/decisions/README.md

@@ -6,6 +6,7 @@
 | [0002](ADR-0002-sqlite.md) | SQLite statt Postgres | akzeptiert |
 | [0003](ADR-0003-eventsub-websocket.md) | EventSub ueber WebSocket, Chat ueber IRC | akzeptiert |
 | [0004](ADR-0004-docker.md) | Betrieb in Docker, whisper.cpp statt Python | akzeptiert |
+| [0005](ADR-0005-zugangsdaten.md) | Zugangsdaten ueber Einrichtungs-Assistent statt .env | akzeptiert |
 
 Neue Entscheidung: Datei `ADR-<nummer>-<kurzname>.md`, Aufbau Kontext /
 Entscheidung / Begruendung / Konsequenzen.