2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	775aabef38	Standwache: hat sich der Stand WAEHREND des Laufs geaendert? ... Die zweite Sitzung hat die Luecke benannt: Das Arbeitsschloss schuetzt den Commit und die Stempellaeufe, nicht die Pruefläufe. Wer misst, waehrend ein anderer speichert, misst einen Stand, den es nicht mehr gibt. Am 06./07.09.2026 sind so fuenf Gesamtlaeufe wertlos geworden — rund zwei Stunden Wartezeit ohne einen einzigen Befund. Am 01.10. dieselbe Lage, nur anders: zwei Sitzungen im Verzeichnis, eine misst, die andere speichert. Aufgefallen ist es nur, weil die andere es von sich aus gesagt hat. DIE FRAGE IST EINE MESSUNG, KEINE ZUSTAENDIGKEIT „Haelt jemand das Schloss" waere die falsche Frage, und zwar in beide Richtungen: * Sie blockiert zu viel: Wer zwei Stunden am Schloss sitzt, haette in der Zeit keinen Prueflauf mehr. Eine Sicherung, die das eigene Arbeiten anhaelt, wird abgeschafft. * Sie blockiert zu wenig: Filipe am Editor hat kein Schloss, mein eigenes Werkzeug auch nicht. Gefragt wird deshalb: Ist der Stand am Ende noch derselbe wie am Anfang? Das trifft jede Quelle. AN DER NOTBREMSE, NICHT IN 179 DATEIEN Gemessen: 179 von 231 Pruef- und Messdateien rufen `notbremse`. Das ist die eine Stelle, an der alle etwas bekommen — dieselbe Ueberlegung wie bei der Notbremse selbst. Einzelne Dateien nachzuruesten hilft nur bis zur naechsten ohne. Fingerabdruck: Anzahl, Gesamtgroesse und juengste Aenderung von workspace, assets, server, webdesign und den Seiten im Wurzelverzeichnis — 670 Dateien in 27 ms. Kein Hash ueber den Inhalt: Gesucht ist „hat jemand gespeichert", und das aendert immer mindestens die Zeit. BILDER ZAEHLEN NICHT. Die Messdateien legen selbst welche ab; eine Wache, die bei jedem Bildschirmfoto anschlaegt, wird weggeklickt und nimmt die echte Meldung mit. SIE HAELT NICHTS AN. Ein Lauf, dessen Grundlage sich verschoben hat, ist nicht „nicht in Ordnung" — er ist NICHT NACHSEHBAR. Deshalb Rueckgabewert 3 (nicht 1, das waere eine Aussage ueber den Code; und nicht 0, ein gruener Haken ueber einen Stand, den es nicht mehr gibt, waere das Schlimmere) und ein ausdruecklicher Satz, dass das kein Befund ist. GEPRUEFT — pruef-arbeitsschloss 35 -> 48 Pruefungen, 0 Fehler: zwei Aufnahmen hintereinander gleich (sonst waere jede Meldung wertlos) geaenderte Datei -> faellt auf neue Datei -> faellt auf neues Bild -> faellt NICHT auf Lauf mit Aenderung -> Rueckgabe 3, sagt NICHT NACHSEHBAR Lauf ohne Aenderung -> Rueckgabe 0 (Gegenprobe; sonst waere „endet mit 3" auch wahr, wenn sie IMMER 3 meldet) Alles in einem Wegwerf-Verzeichnis mit gefaelschtem Baum — moeglich, weil die Wache ihre Wurzel aus ihrem EIGENEN Pfad ableitet. Waere sie festgeschrieben, liesse sich die Wache nicht pruefen, ohne am echten Haus zu wackeln. UND AM ECHTEN LAUF NACHGEWIESEN: Mitten in pruef-arten eine Datei gespeichert -> Rueckgabe 3, mit Groesse und Uhrzeit. Ohne Eingriff bei neun Laeufen (treff 85, kalender 141, material 159, erwaehnung 129, arten, dabei-optik, tagesblick, aufgabenbrett, kopfleiste, seiteninhalt) kein einziger Fehlalarm. EINE ERWARTUNG VON MIR WAR FALSCH, und die Wache hatte recht: Ich hatte im gefaelschten Baum eine zaehlende Datei erwartet, es sind zwei — die Seite UND die Kopie der Wache selbst im server-Ordner. Der zaehlt mit, und das ist richtig: Eine geaenderte Pruefdatei verschiebt den Stand genauso wie eine geaenderte Seite. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-10-01 23:18:13 +02:00
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