# ADR-0006: Ein Dach — lokale Weboberfläche, lokale Arbeitsprozesse

**Status:** akzeptiert · **Datum:** 2026-09-09

## Kontext

Die ursprüngliche Architektur ([`01-architecture.md`](../01-architecture.md))
sah neun weitgehend eigenständige Apps vor, die über einen Event-Bus reden, und
drei getrennte Langläufer (Ingest, Overlay-Server, Dashboard). Beim Bau von S1
hat sich gezeigt, dass das für diese Größe zu viel Struktur ist.

Die Frage, die dahinter steht: Soll alles über **eine Weboberfläche** bedienbar
sein, mit lokalen Komponenten dort, wo tatsächlich lokal gearbeitet werden muss
(Video, OBS, Chat)?

## Entscheidung

Ja. Das Toolkit ist eine **lokale Web-Anwendung**: ein Prozess, der die
Oberfläche ausliefert und die Dauerverbindungen hält, plus **Kindprozesse für
schwere oder abstürzgefährdete Arbeit**.

```
  Browser (localhost:4792)          OBS  ────────┐
        │  eine Oberflaeche,                     │ obs-websocket
        │  neun Werkzeuge als Seiten             │
        ▼                                        ▼
  ┌──────────────────────────────────────────────────────┐
  │  toolkit  (ein Node-Prozess, ein Container)          │
  │                                                      │
  │  Weboberflaeche · Einrichtung · Sichtung · Dashboard │
  │  Ingest: IRC, EventSub, Helix-Polling                │
  │  Module: Community, Loyalty, Raid, Recap, Kapitel    │
  │  Overlay-Server fuer die OBS-Browser-Quellen         │
  └───────────────┬──────────────────────────────────────┘
                  │  spawn, ueberwacht, darf abstuerzen
                  ▼
        ffmpeg · whisper.cpp        SQLite (Volume)
```

## Begründung

**Die Trennlinie verläuft nicht zwischen Werkzeugen, sondern zwischen
Verbindungshalten und Rechenarbeit.** Die neun Werkzeuge teilen sich
Chat-Verbindung, Datenbank und Oberfläche — sie zu trennen erzeugt nur
Verbindungsverdopplung und Abstimmungsaufwand. Was dagegen wirklich getrennt
gehört, ist alles, was minutenlang die CPU belegt oder abstürzen kann: ffmpeg
und whisper. Die laufen als Kindprozesse und dürfen scheitern, ohne die
Chat-Aufnahme mitzureißen.

**Eine Oberfläche ist der eigentliche Gewinn.** Neun Werkzeuge, die man einzeln
starten und einzeln aufrufen muss, benutzt man nach zwei Wochen nicht mehr. Ein
Tab mit Navigation ist der Unterschied zwischen Werkzeugkasten und
Bastelkeller.

**Lokal, nicht Cloud.** Die Oberfläche liegt auf demselben Rechner wie OBS. Das
ist keine Einschränkung, sondern Voraussetzung: Replay-Buffer, Szenenwechsel und
Videoverarbeitung brauchen die lokale Maschine ohnehin. Es gibt nichts zu
verteilen.

## Konsequenzen

- **Der Ingest darf nie sterben.** Er läuft im selben Prozess wie die
  Oberfläche, also gilt: jede Route hat eigenes Fehlerabfangen, kein
  Oberflächenfehler beendet den Prozess. Rechenarbeit läuft ausschließlich in
  Kindprozessen.
- **Die Oberfläche ist eine Sicht auf Zustand, kein Ort für Zustand.** Alles
  Dauerhafte steht in SQLite. Ein Neustart der Oberfläche verliert nichts.
- **Neustart heißt Chat-Lücke.** Wer während eines Streams eine Änderung
  ausrollt, verliert ein paar Sekunden Chat. Das ist hinnehmbar; wenn es stört,
  lässt sich der Ingest später als eigener Prozess herauslösen — die Naht dafür
  ist die Datenbank und existiert bereits.
- **Kein Fernzugriff, keine Anmeldung.** Der Dienst ist an `127.0.0.1` des
  Hosts gebunden. Falls Abdu später vom Handy auf das Dashboard schauen will,
  ist der Weg ein Tunnel (Tailscale, Cloudflare Tunnel) — **nicht** ein
  geöffneter Port mit selbstgebauter Anmeldung.
- **Gefahr Rumpelkammer.** Neun Werkzeuge unter einer Navigation werden
  unbrauchbar, wenn die Oberfläche einfach wächst. Gegenmaßnahme: die Startseite
  zeigt den aktuellen Stream und die anstehenden Entscheidungen (Clips zum
  Freigeben, Raid-Vorschläge, Erstchatter), nicht eine Liste von Werkzeugen.
- Die Prozessliste in [`01-architecture.md`](../01-architecture.md) ist damit
  überholt und wurde ersetzt.