Stufe 1+2: Zahlen ueber das Geschaeft, und eine Fruehwarnung

Der grosse Befund aus dem Plan vom 31.08.2026: Der Workspace
organisiert ARBEIT hervorragend, wusste ueber das GESCHAEFT aber
nichts. Keine Diamanten, keine LIVE-Tage, keine Verweildauer. Damit
hing die ganze Betreuung in der Luft -- der Start-Check bewertete ohne
zu messen, der Report fragte "was hat funktioniert" ohne Beleg, das
90-Tage-Ziel war ein Satz statt eines Fortschritts.

STUFE 1 -- LEISTUNG

Eine Zeile je Creator und TAG (nicht Woche: Feineres laesst sich immer
zusammenfassen, Groeberes nie aufteilen). Diamanten, LIVE-Dauer,
gueltiger Tag, Zuschauer im Schnitt und in der Spitze, Verweildauer,
Schenker, neue Follower -- und eine NOTIZ. Ohne sie sieht man in drei
Monaten einen Einbruch und weiss nicht mehr, dass die Person Grippe
hatte.

DIE VERWEILDAUER IST DIE LEITZAHL (Recherche 06.09.2026): 2026 haengt
der Algorithmus alles an der Completion Rate, und sie gehoert als
BETRIEBSkennzahl behandelt -- sie soll die naechste Runde steuern,
nicht die letzte erklaeren.

Jede Zahl kommt mit Vergleich, Verlauf und Einordnung. Eine Zahl ohne
diese drei ist eine Eitelkeitszahl: Sie sieht nach Auskunft aus und ist
keine, weil man nichts entscheiden kann.

Zwei Wege hinein: Schnelleingabe und CSV-Import aus dem offiziellen
Export, mit Vorschau vor dem Uebernehmen.

STUFE 2 -- FRUEHWARNUNG

Sechs benannte Signale (Zahlen fallen, LIVE-Tage brechen weg, lange
nicht angemeldet, kein Gespraech, Aufgabenstau, Start-Check haengt) und
daraus EIN ruhiger Satz: "Bei Nora wuerde ich diese Woche nachfassen."

BEWUSST KEIN SCORE. Eine Note von 1 bis 100 wirkt objektiv und ist es
nicht; sie verfuehrt dazu, Menschen nach einer Zahl zu behandeln. Am
Score kann man nichts tun, am Signal schon. Deshalb Saetze statt
Punkte, und jedes Signal einzeln nachvollziehbar.

Ein CREATOR sieht die Fruehwarnung nicht: Das ist eine
Arbeitsgrundlage fuer die Betreuung, keine Mitteilung an die
betroffene Person.

ZWEI ECHTE FEHLER, VON DER PRUEFUNG GEFUNDEN

1. ZAHLENFORMAT, Faktor tausend daneben. "1.250" wurde als 1,25
   gelesen und "1,234" als 1,234. Die Regel "das letzte Trennzeichen
   ist das Dezimalzeichen" liefert bei nur EINEM Trennzeichen fuer
   beide Faelle das Falsche -- und die Zahl sieht danach trotzdem
   plausibel aus. Jetzt entscheidet, wie viele Ziffern dahinter stehen:
   genau drei heisst Tausendertrenner.

2. DIE ZIELE-ROUTE WURDE VERSCHLUCKT. Express nimmt die erste passende
   Route, und `:tag` passt auch auf "ziele" -- ein PUT auf .../ziele
   landete in der Tages-Route und scheiterte am Datumsmuster. Die
   Meldung sagte "ungueltig", was auf die Zahlen deutet, nicht auf den
   Weg. Reihenfolge getauscht.

Beides waere still gewesen: falsche Zahlen sehen richtig aus, und ein
Ziel, das sich nicht setzen laesst, probiert man zweimal und laesst es
dann.

pruef-leistung.mjs: 47 Punkte, darunter jede Rechnung einzeln
nachgerechnet (Durchschnitte ohne Tage ohne Wert, Prozent von null,
Wochengrenzen), Import zweimal eingelesen, deutsche und englische
Zahlenformate, Rechte, und die Gegenprobe, dass die Fruehwarnung bei
Unauffaelligkeit SCHWEIGT.

Co-Authored-By: Claude Opus 5 <[email protected]>

server/workspace.js

@@ -975,6 +975,90 @@ export function db() {
       );
       CREATE INDEX IF NOT EXISTS idx_wissen_kat ON wissen (kategorie);
 
+      /* =================================================================
+         LEISTUNG — die Zahlen, an denen die Betreuung haengt (06.09.2026)
+
+         DER GROSSE BEFUND aus dem Plan vom 31.08.2026: Der Workspace
+         organisiert ARBEIT sehr gut, aber es gibt keine einzige Zahl
+         ueber das GESCHAEFT. Damit haengt die ganze Betreuung in der
+         Luft -- der Start-Check bewertet ohne zu messen, der Report
+         fragt "was hat funktioniert" ohne Beleg, das 90-Tage-Ziel ist
+         ein Satz statt eines Fortschritts.
+
+         EINE ZEILE JE CREATOR UND TAG. Tag und nicht Woche: Feineres
+         laesst sich immer zusammenfassen, Groeberes nie aufteilen. Wer
+         mit Wochenwerten anfaengt, kann spaeter nie mehr sagen, ob der
+         Einbruch am Dienstag oder am Wochenende lag.
+
+         WELCHE FELDER -- und warum genau diese (Recherche 31.08. und
+         06.09.2026, TikTok LIVE Backstage):
+
+           diamanten       die Zahl, an der TikTok und die Agentur den
+                           Erfolg messen
+           dauer_min       Grundlage fuer "gueltige Tage"/"aktive Stunden"
+           gueltiger_tag   der Zaehler, an dem Ranghochstufungen haengen
+           zuschauer_avg   sagt, ob es TRAEGT
+           zuschauer_max   sagt, was MOEGLICH waere
+           verweildauer_s  DIE LEITZAHL (Recherche 06.09.2026): 2026
+                           haengt der Algorithmus alles daran, und sie
+                           gehoert als Betriebskennzahl behandelt --
+                           sie soll die naechste Runde steuern, nicht
+                           die letzte erklaeren
+           schenker        wie BREIT die Unterstuetzung steht, nicht nur
+                           wie hoch. Ein Grossspender ist ein Risiko,
+                           zwanzig kleine sind ein Fundament
+           follower_neu    waechst der Kanal oder dreht er sich im Kreis
+           notiz           ein Satz Kontext ("PK gegen X", "krank")
+
+         WARUM DIE NOTIZ DAZUGEHOERT: Ohne sie sieht man in drei Monaten
+         einen Einbruch und weiss nicht mehr, dass die Person Grippe
+         hatte. Zahlen ohne Umstaende fuehren in die Irre.
+
+         PRIMAERSCHLUESSEL (creator_id, tag): Derselbe Creator am
+         selben Tag kann nur EINE Zeile haben. Das ist die halbe Miete
+         beim Import -- wer eine Datei zweimal einliest, ueberschreibt
+         dann, statt zu verdoppeln. Verdoppelte Zahlen sind schlimmer
+         als fehlende: Sie sehen richtig aus. */
+      CREATE TABLE IF NOT EXISTS leistung (
+        creator_id     INTEGER NOT NULL REFERENCES personen(id) ON DELETE CASCADE,
+        tag            TEXT NOT NULL,          /* JJJJ-MM-TT, Ortszeit */
+        diamanten      INTEGER,
+        dauer_min      INTEGER,
+        gueltiger_tag  INTEGER NOT NULL DEFAULT 0,
+        zuschauer_avg  INTEGER,
+        zuschauer_max  INTEGER,
+        verweildauer_s INTEGER,                /* Sekunden, die Leitzahl */
+        schenker       INTEGER,
+        follower_neu   INTEGER,
+        notiz          TEXT,
+        erfasst        TEXT NOT NULL,
+        erfasst_von    INTEGER REFERENCES personen(id) ON DELETE SET NULL,
+        /* Woher der Wert kommt. Wichtig, wenn eine Zahl seltsam
+           aussieht: von Hand getippt oder aus dem Export? */
+        quelle         TEXT NOT NULL DEFAULT 'hand'
+                       CHECK (quelle IN ('hand','import')),
+        PRIMARY KEY (creator_id, tag)
+      );
+      CREATE INDEX IF NOT EXISTS idx_leistung_tag ON leistung (tag DESC);
+
+      /* ZIELE je Creator. Aus dem 90-Tage-Plan, den es im Profil schon
+         als FREITEXT gibt -- daraus wird hier eine pruefbare Groesse.
+         "Mehr Reichweite" ist kein Ziel, "4 LIVE-Tage pro Woche" ist
+         eines.
+
+         Eine Zeile je Creator, nicht je Ziel und Zeitraum: Ein Ziel,
+         das sich woechentlich aendert, ist keines. Wer es anpasst,
+         ueberschreibt -- der Verlauf steht ohnehin in der Tabelle
+         "leistung". */
+      CREATE TABLE IF NOT EXISTS leistung_ziele (
+        creator_id        INTEGER PRIMARY KEY REFERENCES personen(id) ON DELETE CASCADE,
+        diamanten_woche   INTEGER,
+        tage_woche        INTEGER,
+        verweildauer_s    INTEGER,
+        gesetzt           TEXT NOT NULL,
+        gesetzt_von       INTEGER REFERENCES personen(id) ON DELETE SET NULL
+      );
+
       /* Start-Check / Erstanalyse (Konzept, Seite 5). Eine Zeile je
          geprueftem Punkt -- ungeprueft heisst: gar keine Zeile. So sieht
          man am Bestand sofort, wie weit die Analyse ist, ohne leere