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	d8720debc1	Personen & Automationen gehoeren DogFather allein -- und das Formular laeuft nicht mehr ueber ... ZWEI MELDUNGEN. 1. "DAS SIEHT JA MAL RICHTIG SCHEISSE AUS" Die Rollenauswahl im Formular "Neue Person" lief unten aus dem Formular heraus und legte sich ueber die Personenliste darunter. Die Ursache war keine schlampige Gestaltung, sondern eine Regel, die fuer etwas anderes gemacht ist: `.neu__raster > *` (aufgaben.css) gibt JEDEM direkten Kind ein Raster mit fester Zeilenhoehe von 44 px, damit Beschriftung und Eingabefeld in allen Spalten auf einer Linie sitzen. Fuer ein einzeiliges Feld ist das genau richtig. Die Rollenauswahl ist aber kein Feld, sondern ein Block aus vier hohen Karten -- die passten nicht in 44 px, und was nicht hineinpasst, steht eben daneben. Das Formular ist jetzt aus dem Spaltenraster geloest und liest sich von oben nach unten: NAME (schmal, ein Name braucht keine 1200 px), ROLLE (volle Breite, vier gleich breite Karten), Knoepfe. Das ist nicht nur reparierter Ueberlauf, sondern auch die Reihenfolge, in der man die Sache tatsaechlich entscheidet. Dazu zwei Kleinigkeiten, die den Unterschied machen: Das Namensfeld war ohne Rasterzeile 60 px hoch geworden (`height: 100%` einer Zeile, die es nicht mehr gibt) -- hoeher als die Knoepfe daneben, was nach Versehen aussieht, weil es eins war. Und die gewaehlte Rolle traegt jetzt ein HAEKCHEN, nicht nur einen etwas helleren Rahmen: Genau die Art Unterschied, die im Kontrastmodus verschwindet und fuer farbunsichere Augen nie existiert hat. 2. "DIE MANAGER SOLLEN DIESE KATEGORIEN GARNICHT SEHEN" "Personen & Zugaenge" und "Automationen" gehoeren ab sofort allein DogFather. Bei den Personen war es ohnehin ein Widerspruch im eigenen Haus: In der Rollenauswahl steht seit jeher "Manager -- dieselben Rechte wie DogFather, AUSSER der Personenverwaltung". Die Kachel stand trotzdem bei ihm, und die Schranke liess ihn hinein: Codes erneuern, sperren, Zuteilungen aendern. Eine Beschreibung, die etwas anderes sagt als die Software, ist schlimmer als beides einzeln -- man weiss danach nicht mehr, welcher von beiden man glauben soll. Umgesetzt auf DREI Ebenen, weil Wegnehmen was man SIEHT kein Rechteentzug ist: 1. die Kachel erscheint nicht mehr 2. die Seite leitet zur Startseite zurueck (GESCHUETZT) 3. die Schnittstellen antworten mit 404 -- Personenverwaltung, Systemzustand, KI-Schalter FOLGE, die bewusst in Kauf genommen wird: Die Betreuungs-Zuteilung liegt auf der Personenseite. Ab jetzt kann also NUR DogFather festlegen, wer welchen Creator betreut. GEPRUEFT: server/pruef-personen-formular.mjs, 20 Pruefungen. Das Aussehen wird gemessen, nicht angesehen: Endet die Rollenauswahl innerhalb des Formulars? Ragt eine Karte seitlich hinaus? Liegt etwas ueber der Liste? Sind alle vier Karten gleich breit (272-272 px)? Traegt die gewaehlte ein Haekchen? Dazu zwei Gegenproben: DogFather kommt weiterhin an beide Bereiche (sonst waere jede Sperr-Zeile auch bei einem fuer ALLE kaputten Bereich gruen), und die Managerin arbeitet ansonsten unveraendert weiter. Bestehende Laeufe gruen: Rollen 97, Handy 50, Sicherung 41, Personenliste 33, Team 30, Formulare 19, Code 17, Grosscheck 15. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-03 00:00:41 +02:00