Umsetzungsplan: Wo es hingehört, was es kostet, was es braucht

0Kurz

Alles Neue ist Hub-Code und Hub-Daten: neue Tabellen in hub.db, neue Module in hub/src/, neue Kacheln in Zentrale und Kundenportal. Kein neuer Container, keine neue Datenbank, kein neuer Dienst, mit einer Ausnahme (Telefon-Partner, falls gewollt, und der bleibt extern). Performance ist bei unserer Größe kein Thema, wenn drei Regeln eingehalten werden (Teil 3). Sicherheit hängt an fünf Punkten, die alle schon Muster im Hub haben (Teil 4). Die Übersichtlichkeit gewinnen wir nicht durch weniger Funktionen, sondern durch ein Modul „Assistent" mit einer Kachel, einer Tabelle je Zweck und einer lebenden Wiki-Seite (Teil 5). Der erste Sprint ist P2 + P3 (Kontakte, Opt-in, Anlass-Engine, Check-in-Quellen), weil beides Konzepte trägt.

1Ist-Zustand, gemessen am 13.09.2026

Befund vom 13.09., der nichts mit dem Hub zu tun hat: Load 15 bei 12 Kernen, Swap voll. Ursache: 140 verwaiste Headless-Chromium-Prozesse (Playwright aus Claude-Sitzungen, Elternprozess systemd, 9 Stunden bis 5 Tage alt, je bis 100 % CPU). Am 13.09. bereinigt. Regel ab jetzt: Browser-Prüfungen immer mit Timeout und browser.close() im finally; zusätzlich ein Host-Wächter (Timer, stündlich), der Headless-Prozesse ohne Elternprozess und älter als 30 Minuten beendet. Das ist der einzige echte Performance-Punkt, den ich gefunden habe.

2Wo das Neue hingehört

Alles im Hub, alles in hub.db, deployt mit rollout.sh, gesichert vom Nacht-Backup. Keine neue Datenbank: ein zweites SQLite oder ein Postgres würde nur Konsistenzprobleme (Transaktionen über zwei Dateien) und einen zweiten Backup-Pfad bringen, ohne einen Vorteil bei 19 MB. Kein neuer Container: die Anlass-Engine ist ein Tick im Hub wie zwanzig andere; ein eigener Dienst wäre nur sinnvoll, wenn er unabhängig deployt oder skaliert werden müsste, und beides ist nicht der Fall.

3Performance: drei Regeln statt Sorgen

Größenordnung: 21 Kunden, ein Club hat 500 bis 1.500 Mitglieder, eine Kette 5.000. Zehn angebundene Clubs sind 10.000 Kontakte, 20.000 Anlass-Versände im Jahr, 50.000 Check-in-Ereignisse im Monat (flüchtig). Für SQLite im WAL-Modus sind das Millisekunden, wenn:

1. Ereignisse nicht speichern, sondern verarbeiten. Check-ins werden im Event-Verarbeiter zu zwei Feldern am Kontakt (Zeitstempel, Wochenschnitt) und dann verworfen. Kein Verlauf, keine wachsende Tabelle, und es hält die Magicline-Zusage („no visit history is stored"). Die events-Tabelle des Hubs (heute 22.000 Zeilen) bekommt einen Aufräumlauf (älter als 90 Tage weg, Zusammenfassungen bleiben); das steht ohnehin an.
2. Ein Schreiber, kurze Transaktionen. SQLite hat einen Schreiber gleichzeitig. Der Tick der Anlass-Engine liest je Kunde die fälligen Regeln (Index auf kontakte(customer_key, letzter_anlass_am)), schreibt je Versand eine Zeile, sendet außerhalb der Transaktion. Poller (Agilea 5 min, aidoo nachts) schreiben nur Änderungen. Kein Job hält eine Transaktion offen, während er auf Meta oder Agilea wartet. Genau so arbeiten heute Nachtabgleich und Event-Verarbeiter.
3. Cockpit-Zahlen vorrechnen. Bestand, Zu-/Abgang, Beitragsumsatz und Vertragsanalyse werden einmal täglich je Kunde berechnet und als JSON in einer Cache-Tabelle abgelegt (wie berichte-cache heute), das Portal liest nur. Live-Zahlen (offene Leads, Gespräche heute) sind kleine Zählabfragen mit Index. Nie eine Portal-Seite, die 5.000 Verträge aggregiert, während der Kunde wartet.

Außenlast: Meta-Vorlagenversand bei 320 Mitgliedern mit Opt-in sind 640 Aufrufe im Monat, Agilea-Polling 288 Aufrufe am Tag je Club (Antwort klein, Filter nach Zeit), Magicline-Webhooks kommen ohnehin. Nichts davon ist nennenswert; Deckel je Kunde und Tag (Meta-Qualitätsbewertung) sind Produktregel, nicht Lastschutz.

Wenn wir in zwei Jahren bei 100 Clubs sind, ist der erste Engpass nicht SQLite, sondern der eine Hub-Prozess für alles (Web, Ticks, Poller). Dann trennt man die Ticks in einen zweiten Hub-Container mit derselben Datei (SQLite WAL erlaubt mehrere Prozesse auf einem Host) oder wechselt den Speicher. Das ist ein Tag Arbeit, wenn er kommt, und muss heute nicht vorgebaut werden.

4Sicherheit: fünf Punkte

1. Einwilligung als Daten, nicht als Haken. kontakte speichert Wortlaut, Zeitpunkt, Quelle, Kanal und Stopp-Zeitpunkt; die Engine sendet Werbung nur mit gesetztem Opt-in, Service (Termin, Bestätigung) nur an Kontakte aus einem laufenden Vorgang. „STOPP" wird im Eingang erkannt, bevor der Bot antwortet. Löschung eines Kontakts kaskadiert Versände (Muster Lead-Löschung mit DSGVO-Export existiert).
2. Mandantentrennung. Jede neue Route im Portal nimmt customerKey ausschließlich aus portalUserOf(); jede neue Tabelle hat customer_key in der ersten Spalte und im Index; Tests prüfen die Fremdzugriffe (Muster Scouting: „identische Antwort wie unbekannter Kunde"). Zentrale-Routen bleiben hinter Session oder Admin-Token.
3. Eingehende Webhooks nur signiert. Meta: HMAC gegen den Roh-Body (gebaut). Magicline: x-api-key je Studio (gebaut). Agilea und aidoo werden gepollt, es gibt keinen offenen Eingang. Telefon-Partner (falls): nur mit Geheimnis im Header und Whitelist der Absender-IP.
4. Geheimnisse und Rechte. API-Keys der Studiosoftware bleiben verschlüsselt in der Anbieter-Registry (HUB_VERTRAEGE_SECRET_KEY), Meta-Token im .env (Kundennummern per Embedded Signup, Kunde sieht keinen Token). Neue Env-Variablen: keine, außer der Wahl des Copilot-Modells. Der Agilea-Restapi-Benutzer liest alles (Befund 25.08.): Poller-Anfragen bleiben auf checkInHistory mit Filter, keine Volltextabzüge.
5. Bot-Leitplanken. Mitglieder-Modus liest Vertragsdaten nur nach Magic-Link-Verifikation (Standard) oder nach ausdrücklicher Kundenentscheidung „Nummer reicht"; handelnde Aktionen (Kurs, Stilllegung, Tarifwechsel) mit frischer Bestätigung; Copilot für Kunden bereitet vor und sendet nie ohne Klick; Gesundheitsdaten werden nicht erfragt; KI-Kennzeichnung bleibt im Kopf jeder Unterhaltung. AVV-Baustein „WhatsApp-Assistent" und Datenschutz-Text im Template gehören zu P6, nicht ans Ende.

Zwei Dinge außerhalb des Codes, die wichtiger sind als jede Zeile: SSH mit Passwort-Login auf beiden Servern (Befund Juli, auf FACEFORCE mit fail2ban gemildert) und die Disziplin bei Headless-Browsern (Teil 1). Beides steht auf der Betriebsliste, nicht in diesem Projekt.

5Übersichtlichkeit: was wir festlegen, bevor die erste Zeile entsteht

• Ein Modul, ein Name. Alles aus diesem Projekt heißt assistent: Portal-Bereich assistent, Zentrale-Karte „Assistent", Tabellen mit Präfix kontakte, anlaesse, anlass_versand, kampagnen, Module anlassCore.ts, anlass.ts, kontakte.ts, cockpitCore.ts, cockpit.ts. Keine Streuung in postfach.ts oder leads.ts hinein, nur Aufrufe nach außen.
• Kern getrennt von Rand. Regelauswertung, Frequenzlogik, Kennzahlen: reine Funktionen in *Core.ts mit Tests, ohne db.js-Import (Regel seit dem Scouting-Vorfall: Tests dürfen nie die echte hub.db berühren). Routen, DB, Versand in *.ts.
• Eine Karte pro Kunde. In der Kundenakte eine Karte „Assistent" mit vier Reitern (Kontakte und Opt-in, Anlässe, Versände, Zahlen) statt vier Karten. Im Portal eine Startseite (Cockpit) und ein Bereich „Assistent" mit denselben Reitern in Kundenfassung.
• Schalter im Katalog. Neue Funktionen als Module in studioSoftwareCore.ts (Kann, Nutzt, Fehlt) und im Produkt-Katalog; nichts, was sich nur per SQL einschalten lässt.
• Suche und Hilfe pflegen. KM_STICHWORTE für die zentrale Suche und die Hilfe-Seite je Etappe, nicht am Ende.
• Eine lebende Wiki-Seite „Assistent Stand und To-Dos" nach dem Muster der Postfach-Seite, nach jedem Teilschritt fortgeschrieben; die beiden Konzepte bleiben die Referenz.
• Aufräumen im selben Zug. Was durch den Assistenten überflüssig wird, fliegt raus: Typeform-artige Sonderwege, doppelte Erinnerungslogik (Mail-Erinnerung und WhatsApp-Erinnerung aus derselben Regel), tote Terminquellen (MyTime #1/#2). Weniger Wege = mehr Übersicht.

6Reihenfolge und erster Sprint

Voraussetzungen, die nicht Code sind: Meta-Review business_management (Tobias), erster Magicline-Produktionsclub aktiviert (Impuls oder K5), Agilea-Live-Freigabe für Life X (Renés Go, Live-Sperre im Code lösen), aidoo-Fragen an Jens (Bestandsliste, Check-in-Liste), Florian-Fragen (Werber-Feld, Gutschrift).

7Was ich vor S1 noch klären würde

1. Regel-Liste statt Node-Editor (Vorschlag ja).
2. Verifikation im Mitglieder-Modus: Magic-Link als Standard (Vorschlag ja).
3. Preis und Modulname (aus dem Assistent-Konzept).
4. Headless-Wächter als Host-Timer einrichten (Vorschlag ja, 30 Minuten).