2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	bede91921d	Der sechste Bereich, und zwei Pruefungen, die den Lauf lahmgelegt haben ... DER AGENTUR-BEREICH (Stufe 4 des Plans) Kernprinzip 04 des Konzepts lautet woertlich "Die Agentur bleibt angebunden" -- und dafuer gab es bis heute nichts. Fuenf Bereiche standen, der sechste fehlte vollstaendig. Damit stand nirgends, welche Kampagne laeuft, welche Schulung ansteht und wie ein Anliegen an die Agentur ausgegangen ist. Das lief ueber private Nachrichten: nicht auffindbar, nicht nachvollziehbar, beim naechsten Mal von vorn. Vier Arten, und die vierte ist der Punkt: kampagne, schulung, anliegen und ZUSTAENDIGKEIT. Die letzte ist keine Verlegenheit, sondern das, was das Konzept ausdruecklich fordert -- Betreuung und Umsetzung sind unsere Seite, offizielle Wege sind Agenturseite. Solange das nur im Kopf steht, wird es bei jedem Streitfall neu verhandelt. Der Umbau war das eigentliche Risiko, nicht der Bereich: Ein CHECK laesst sich in SQLite nicht aendern, die Tabelle muss neu gebaut werden -- und dabei werden ALLE vorhandenen Eintraege umgeschrieben. Deshalb geht pruef-agentur.mjs (31 Pruefungen) den Weg wirklich: Sie baut eine Datenbank im ALTEN Stand nach, fuellt sie mit allen fuenf Bereichen, laesst die echte Anwendung darueberlaufen und zaehlt danach jede Zeile UND jedes Feld nach -- auch die seltenen Spalten (hook, creator_extern), die man beim Abschreiben des Bauplans vergisst. Wichtigste Gegenprobe: Der CHECK muss danach noch BEISSEN. Eine Umstellung, die nebenbei die Schranke entfernt, sieht aus wie ein Erfolg und ist der schlimmere Ausgang. Nebenbei drei abgeschriebene Bereichslisten beseitigt (Wochenbericht, Suche, Report-Ziele). Im Wochenbericht waere der neue Bereich sonst schlicht nicht vorgekommen -- ohne Fehler, ohne Luecke, einfach nicht da. ZWEI PRUEFUNGEN, DIE DEN GESAMTLAUF ZUM STILLSTAND BRACHTEN pruef-call-kategorien.mjs hing DREI STUNDEN. Ursache war ein Zeitzuender in ihr selbst: Sie legte Calls auf "heute 18:00" und erwartete zwei davon unter "Heute". Ab 18 Uhr sind die vorbei, der Server schiebt sie nach "Protokoll fehlt", und die Oberflaeche unterteilt erst ab FUENF anstehenden. Uebrig blieben vier, die Bloecke verschwanden, und die Pruefung wartete auf einen Klick auf einen Block, den es nicht gab. Genau die Sorte Fehler, vor der die Projektnotiz vom 06.09. warnt: Sie war um 17:59 gruen und um 18:01 rot, ohne dass sich am Code etwas geaendert hatte. Jetzt liegen alle Zeiten RELATIV zu jetzt, und die Erwartung wird mit derselben Vorschrift gerechnet, die calls.js benutzt -- statt Zahlen, die nur zu einer bestimmten Tageszeit stimmen. Und der Grund, warum daraus ein Stillstand statt eines Fehlers wurde: index.js setzt bewusst zwei Auffangnetze (uncaughtException, unhandledRejection). Fuer den Betrieb richtig -- ein Fehler darf die Website nicht offline nehmen. Fuer eine Pruefung fatal: Sie importiert index.js in denselben Prozess und erbt die Netze. Ihr eigener Absturz wird dann nur protokolliert, und der Express-Server haelt den Prozess danach ewig am Leben. Kein Fehler, kein Ergebnis, kein Ende. Deshalb zwei Abhilfen, die zusammengehoeren: * server/helfer-notbremse.mjs -- haengt eigene Zuhoerer DANEBEN (process.on ergaenzt, es ersetzt nicht) und beendet den Lauf mit Fehler; dazu ein Wecker. In alle 42 Browserpruefungen eingebaut. Der Betrieb bleibt unveraendert. * tools/alles-pruefen.mjs gibt jeder Datei eine Frist von 600 s. Wer sie reisst, wird abgebrochen und ZAEHLT ALS FEHLGESCHLAGEN, mit der letzten Ausgabe davor als Beleg. Einzelne Dateien nachzuruesten hilft nur bis zur naechsten ohne Notbremse -- deshalb sitzt sie dort, wo sie fuer alle gilt, auch fuer die, die es noch nicht gibt. AUSSERDEM: pruef-breiten.mjs pruefte 16 Seiten aus einer Liste von Hand, chat.html und leistung.html fehlten darin. Der Chat war bei keiner einzigen der neun Breiten je gemessen worden. Wie bei pruef-handy kommt die Liste jetzt aus dem Verzeichnis. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-06 22:06:49 +02:00
DogFatherGitandClaude Opus 5	4637aa24e7	Chat zwischen Creator, Scouts und Managern ... Wunsch Filipe, 06.09.2026: *"eine kategorie chat, wo die creator mit ihren manager nachrichten austauschen koennen, wie erinnerungen, fragen und noch vieles mehr."* Auf Nachfrage entschieden: Zweier-Gespraeche UND Gruppen; Manager und Scouts duerfen sich auch ohne gemeinsamen Creator schreiben. WER MIT WEM steht an EINER Stelle: schreibbareIds() in workspace.js. Bewusst getrennt von einladbareIds() (Terminwahl): Dort geht es darum, wen man zu einem Kalendereintrag dazustellen darf -- harmlos. Ein Chat legt ein dauerhaftes Gespraech an, schickt eine Benachrichtigung und macht den eigenen Namen sichtbar. Zwei Fragen, zwei Funktionen. Ein Creator erreicht seine Betreuer und DogFather, KEINEN fremden Creator. Eine Gruppe ist kein Schlupfloch: Jede Nummer wird einzeln gegen dieselbe Regel geprueft. SOFORT STATT NACHFRAGEN IM TAKT (SSE). Ein Chat, der alle fuenf Sekunden fragt, ist fuenf Sekunden langsam und stellt bei zehn Angemeldeten 7200 Anfragen in der Stunde fuer Nachrichten, die es meistens nicht gibt. Kein WebSocket: Hier fliesst alles in eine Richtung, und SSE uebersteht einen Verbindungsabriss von selbst. DIE ZAHL STEHT AUF JEDER SEITE, nicht nur im Chat. Eine Nachricht, die man erst sieht, wenn man den Chat aufmacht, ist keine Nachricht -- sie ist ein Fundstueck. Push aufs Handy nur an die, die NICHT gerade zusehen. Wer die Seite offen hat, sieht es ohnehin; ihm zusaetzlich etwas aufs Handy zu schicken ist der schnellste Weg, dass er Benachrichtigungen abschaltet. WAS BEWUSST NICHT GEHT: * Niemand liest fremde Gespraeche mit -- auch DogFather nicht. Ein Chat, in dem der Chef stillschweigend mitliest, ist kein Chat. Er kann jederzeit jedem schreiben, aber sichtbar. * Eine abgeschickte Nachricht laesst sich nicht aendern, nur zuruecknehmen. Wer Absprachen nachtraeglich umschreiben kann, macht den Verlauf wertlos. Zurueckgenommenes hinterlaesst einen Hinweis statt eines Lochs. DAZU: CALL-LISTE NACH ZEIT GEGLIEDERT Wunsch mit Bild von "STEHT AN 27": *"die liste soll kategorisiert sein und werden mit einem button zum auf und zu machen."* Jetzt Heute / Diese Woche / Naechste Woche / Spaeter, offen nur der erste gefuellte Block. Nach ZEIT und nicht nach Titel: Auf dem Bild waren fast alle "Community-Talk" -- nach Titel gruppiert haette man zwei Ueberschriften und darunter dieselbe lange Liste. DER FUND, DER DIE FUNKTION GERETTET HAT: Ein zugeklappter Block zeigte seinen Inhalt trotzdem -- 367 Pixel Hoehe bei open=false. <details> versteckt seinen Inhalt naemlich nur, solange niemand dem Inhalt eine eigene display-Angabe gibt, und .gruppe__karten traegt display:grid. Der Knopf haette sich bewegt und sonst nichts getan. Im Bildschirmfoto fiel es nicht auf, weil der Ausschnitt genau darueber endete. Ausserdem gefunden und behoben: * Ein Wettlauf beim Abschicken: War der Ereignisstrom schneller als die Antwort auf das POST, stand die eigene Nachricht zweimal im Verlauf. * Die Chatseite war zu hoch -- die Kopfleistenhoehe stand als fester Wert (62 px) im CSS, am Handy ist sie doppelt so hoch. Das Eingabefeld stand halb unter dem Bildschirmrand. Jetzt gemessen. * Der Platzhalter "Enter schickt ..." brach am Handy um UND stimmte dort nicht: Ohne Tastatur schickt Enter absichtlich nicht. * Der Dialog benutzte Klassen aus aufgaben.css, das chat.html nicht lud -- gemeldet von pruef-css-klassen, bevor jemand einen ungestylten Dialog zu sehen bekam. Pruefungen: pruef-chat (44 Punkte, Rechte und Sichtbarkeit), pruef-chat-optik (24, zwei echte Browser schreiben sich), pruef-call-kategorien (16). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-06 16:28:58 +02:00