dogfather-universe

DogFatherGit/dogfather-universe

Fork 0

Commit Graph

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	e0d8e6d55d	Tagesblick: Termine als Karten, und vier Fehler, die dabei auffielen Filipe zu der Liste mit einem einzigen Termin darin: "das soll viel geiler und krasser aussehen bitte." Er hatte recht, und der Grund war der Einzelfall. Ein Zeitstrahl lebt davon, dass er etwas VERBINDET -- bei einem Eintrag verbindet er nichts. Uebrig blieben eine magere Zeile, ein Strich ins Leere und Weissraum bis zur Plakette am rechten Rand. Jetzt traegt jede Karte fuer sich: eigene Flaeche mit farbiger Kante, die Uhrzeit gross und in der Farbe der Terminart (vorher war sie kleiner als der Titel -- dabei ist sie das, was man sucht), ein Balken fuer die Dauer, und "JETZT" am naechsten Termin statt eines etwas helleren Hintergrunds. Erledigtes bekommt einen Haken und verliert die Farbe, bleibt aber voll lesbar; vorher wurde alles blasser, was auch den Text traf. Kein Neon dazu. Die Wirkung kommt aus Kontrast und Hierarchie. VIER FEHLER, DIE DIE PRUEFUNGEN GEFUNDEN HABEN 1. ZEITZONE, in NEUN Pruefungen. Um 00:10 meldete pruef-teilnehmer ploetzlich 13 Fehlschlaege an einer Datei, die seit Stunden niemand angefasst hatte: Ortszeit: 06.09.2026, 00:10 UTC: 05.09.2026, 22:10 Sie bildeten ihr Tagesdatum mit toISOString() -- also UTC -- legten ihre Termine auf gestern und suchten heute. ZWEI STUNDEN AM TAG waren sie damit rot, im Winter eine. Wer nur tagsueber laeuft, sieht das nie. Jetzt gibt es helfer-zeit.mjs mit derselben Rechenweise wie die Anwendung, und pruef-struktur sucht das Muster kuenftig automatisch. 2. MEIN UMSTELL-SKRIPT VERSAGTE STILL. Es pruefte `if "helfer-zeit.mjs" not in s` -- und mein eigener Kommentar enthielt den Dateinamen. Ergebnis: keine einzige der neun Dateien bekam den Import, alle waeren zur Laufzeit abgestuerzt. `node --check` findet das nicht. Aufgefallen, weil danach nachgezaehlt wurde statt der Erfolgsmeldung zu glauben. 3. DIE KACHEL LIESS DIE SEITE SPRINGEN. Der Layout-Sprung auf start.html stieg von 0 auf 0,96 -- zweimal bestaetigt. Sie erschien erst nach dem Laden und schob alles darunter weg. Das ist kein Schoenheitsfehler, sondern der Grund, warum man auf den falschen Knopf drueckt. Gemessen wurden die echten Hoehen (1 Termin 169 px, 3 → 327, 5 → 486). Daraus zwei Konsequenzen: Platz vorher reservieren, und hoechstens DREI Termine zeigen -- das halbiert die Spanne und ist die klarere Aussage. Der Rest steht als "1 weiterer Termin heute" darunter, nicht stillschweigend abgeschnitten. Von 0,96 auf 0,163. 4. SCHRIFTGROESSE, zweimal am selben Tag: erst die Art-Plaketten mit 10,56 px, dann -- nach der Korrektur -- die neue Jetzt-Marke mit 10,88. Beide Male gemeldet von pruef-handy und pruef-grosscheck, beide Male erst nach einem mehrminuetigen Browserlauf. ZWEI PRUEFUNGEN, DIE SICH SELBST IM WEG STANDEN pruef-tempo-workspace meldete "NEUE Doppelabfrage: start.html 2x /workspace/api/termine". Nachgemessen an einem einzelnen Seitenaufruf: genau eine Anfrage. Die Pruefung startete ihren Zaehler, bevor die Anmeldung zur Ruhe gekommen war, und schrieb der Seite an, was die vorherige noch offen hatte. pruef-tagesblick fiel zum zweiten Mal auf dieselbe Falle herein: Sie mass die Artfarbe an einem vorbeigezogenen Termin, der absichtlich grau ist. Diesmal an der Wurzel geloest -- die Daempfung wird fuer die Messung kurz abgeschaltet und sofort zurueckgesetzt. Damit ist die Zuordnung fuer JEDEN Termin geprueft, unabhaengig von der Uhrzeit des Laufs, und zusaetzlich beweist die Pruefung, dass die Daempfung greift. NEU: Schriftgroessen werden jetzt AN DER QUELLE geprueft, in Sekunden statt Minuten. Im Bestand stehen 43 solche Stellen; sie alle rot zu melden haette die Pruefung ab Tag eins wertlos gemacht. Deshalb eine Grundlinie wie beim Layout-Sprung: Sie haelt den Stand fest und schlaegt an, sobald es MEHR werden. Heute haette das zweimal gegriffen. Die Browserpruefung bleibt daneben -- sie sieht, was am Ende auf dem Schirm steht, die CSS-Pruefung nur, was gemeint war. Gesamtlauf: 56 von 56 Dateien, 2002 von 2002 Punkten. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-06 01:32:33 +02:00
DogFatherGitandClaude Opus 5	540b5d8838	Freie Namen, ein Call-Knopf, und drei Seiten, die fuer Scouts kaputt waren DREI SACHEN AUF EINMAL, alle aus derselben Sitzung. 1. AUSSUCHEN ODER SELBST EINTRAGEN Wunsch: "ich will da auch sachen selber noch eintragen koennen, also aussuchen und selbst eintragen." Jede Personenauswahl (Kalender, Aufgaben, Bereiche, Content, Dateien) nimmt jetzt auch einen getippten Namen an -- eine Agentur, eine Marke, einen Gast ohne Konto. Dazu bekommt JEDE Auswahl ab acht Eintraegen ein Suchfeld: tippen statt scrollen. Gebaut IM vorhandenen Auswahl-Bauteil (wahl.js), nicht daneben. Der erste Anlauf war ein zweites Bauteil -- es hat sich prompt mit dem ersten gebissen, beide haben denselben <select> eingepackt. Ein zweites haette ausserdem anders ausgesehen und waere beim naechsten Umbau nur an einer von zwei Stellen nachgezogen worden. Der freie Name steht in einer EIGENEN Spalte je Feld; die Verknuepfung bleibt leer. Entweder eine Person ODER ein Name, nie beides. Filipe hat ausdruecklich auch bei den Creator-Feldern freie Namen gewollt, nachdem der Nachteil benannt war: Der Eintrag gehoert dann zu keinem Konto. Damit daraus kein STILLER Ausfall wird, faellt jede Abfrage, die bisher den Namen der verknuepften Person las, jetzt auf den freien Text zurueck (externSql) -- gekennzeichnet als "(extern)". Der Eintrag verschwindet dadurch aus keiner Liste, keiner Suche und keiner Uebersicht. 2. WO FUEHRE ICH DEN CALL? Den Knopf gab es, aber nur wenn jemand von Hand einen Link ins Ortsfeld getippt hatte UND das Gespraech noch bevorstand. Stand dort "Hier", war nichts zum Anklicken da. Jetzt hat das Team einen festen Call-Raum (Discord-Sprachkanal), den das Management einmal hinterlegt. Danach hat JEDER Call den Knopf -- und er bleibt, solange das Gespraech laufen kann, nicht nur bis zur Startzeit. Ein eigener Link am Termin schlaegt den festen Raum. 3. WAS EINE ROLLE SIEHT, MUSS AUCH FUNKTIONIEREN Gemeldet: "cigdem kriegt als manager gewisse sachen nicht auf die sie sieht, check jede rolle ab." Neue Pruefung server/pruef-rollen.mjs schickt SECHS Rollen-Zustaende ueber alle 16 Seiten und misst Konsolenfehler, fehlgeschlagene Serveraufrufe, tote Verweise, haengende Ladeanzeigen und wortlos leere Seiten. 96 Durchgaenge. Der sechste Zustand ist der wichtige: eine Rolle OHNE zugeteilte Creator -- der Normalfall am ersten Tag und Cigdems echte Lage. Genau dort fielen die Seiten durch, waehrend dieselben Seiten MIT Zuteilung tadellos waren. VIER ECHTE FEHLER GEFUNDEN UND BEHOBEN: a) Eine Aufgabe, die eine Managerin ohne Creator anlegte, war fuer sie im selben Moment unsichtbar -- creator_id und verantwortlich_id leer, und "von mir selbst angelegt" stand in keiner Sichtbarkeitsregel. Nur DogFather sah sie noch. Kein Fehler, keine Meldung, die Aufgabe war einfach weg. Dasselbe bei den Bereichseintraegen. Beide Regeln kennen jetzt erstellt_von. Niemand sieht dadurch etwas Fremdes -- nur das Eigene. b) Ein Scout ohne zugeteilten Creator bekam auf die GESAMTE Report-Seite 404, obwohl sie fuer ihn verlinkt ist. Die Seite antwortet jetzt sauber und leer, statt sich zu verweigern. c) Start-Check und Report blieben fuer immer auf "wird geladen" stehen, wenn es nichts zu laden gab. d) Das Creator-Profil war fuer Scouts ohne Zuteilung wortlos leer -- der erklaerende Satz stand nur in der grauen Unterzeile. Ausserdem meldete die bestehende Lesbarkeitspruefung zwei neue Beschriftungen von mir als zu klein fuers Handy (10,88 statt 11,5 px). Behoben, und dieselbe Groesse an der Serien-Karte gleich mit -- dort waere es erst aufgefallen, sobald jemand eine Wiederholung anlegt. GEPRUEFT: pruef-rollen 97, pruef-freie-namen 32 (mit Gegenproben: Ben sieht Cigdems Aufgabe NICHT; die Saeulen-Zuordnung nimmt ausdruecklich KEINEN freien Namen). Alle bestehenden Laeufe gruen: Startansicht 133, Kalender 84, Serien 67, Protokoll 52, Handy 50, Sicht 48, Ampel 47, Content 45, Aufgabenbrett 44, Sprung 43, Personen-Loeschen 40, Bereiche 37, Uebersicht 33, Workspace-Seiten 32, Formulare 19, Betreuung 18, Grosscheck 15, Lesbarkeit 14. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-02 20:10:09 +02:00

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

e0d8e6d55d

Tagesblick: Termine als Karten, und vier Fehler, die dabei auffielen

Filipe zu der Liste mit einem einzigen Termin darin: "das soll viel
geiler und krasser aussehen bitte."

Er hatte recht, und der Grund war der Einzelfall. Ein Zeitstrahl lebt
davon, dass er etwas VERBINDET -- bei einem Eintrag verbindet er nichts.
Uebrig blieben eine magere Zeile, ein Strich ins Leere und Weissraum bis
zur Plakette am rechten Rand.

Jetzt traegt jede Karte fuer sich: eigene Flaeche mit farbiger Kante,
die Uhrzeit gross und in der Farbe der Terminart (vorher war sie
kleiner als der Titel -- dabei ist sie das, was man sucht), ein Balken
fuer die Dauer, und "JETZT" am naechsten Termin statt eines etwas
helleren Hintergrunds. Erledigtes bekommt einen Haken und verliert die
Farbe, bleibt aber voll lesbar; vorher wurde alles blasser, was auch
den Text traf.

Kein Neon dazu. Die Wirkung kommt aus Kontrast und Hierarchie.

VIER FEHLER, DIE DIE PRUEFUNGEN GEFUNDEN HABEN

1. ZEITZONE, in NEUN Pruefungen. Um 00:10 meldete pruef-teilnehmer
   ploetzlich 13 Fehlschlaege an einer Datei, die seit Stunden niemand
   angefasst hatte:

       Ortszeit:  06.09.2026, 00:10
       UTC:       05.09.2026, 22:10

   Sie bildeten ihr Tagesdatum mit toISOString() -- also UTC -- legten
   ihre Termine auf gestern und suchten heute. ZWEI STUNDEN AM TAG waren
   sie damit rot, im Winter eine. Wer nur tagsueber laeuft, sieht das
   nie. Jetzt gibt es helfer-zeit.mjs mit derselben Rechenweise wie die
   Anwendung, und pruef-struktur sucht das Muster kuenftig automatisch.

2. MEIN UMSTELL-SKRIPT VERSAGTE STILL. Es pruefte
   `if "helfer-zeit.mjs" not in s` -- und mein eigener Kommentar
   enthielt den Dateinamen. Ergebnis: keine einzige der neun Dateien
   bekam den Import, alle waeren zur Laufzeit abgestuerzt. `node --check`
   findet das nicht. Aufgefallen, weil danach nachgezaehlt wurde statt
   der Erfolgsmeldung zu glauben.

3. DIE KACHEL LIESS DIE SEITE SPRINGEN. Der Layout-Sprung auf
   start.html stieg von 0 auf 0,96 -- zweimal bestaetigt. Sie erschien
   erst nach dem Laden und schob alles darunter weg. Das ist kein
   Schoenheitsfehler, sondern der Grund, warum man auf den falschen
   Knopf drueckt.

   Gemessen wurden die echten Hoehen (1 Termin 169 px, 3 → 327, 5 →
   486). Daraus zwei Konsequenzen: Platz vorher reservieren, und
   hoechstens DREI Termine zeigen -- das halbiert die Spanne und ist
   die klarere Aussage. Der Rest steht als "1 weiterer Termin heute"
   darunter, nicht stillschweigend abgeschnitten. Von 0,96 auf 0,163.

4. SCHRIFTGROESSE, zweimal am selben Tag: erst die Art-Plaketten mit
   10,56 px, dann -- nach der Korrektur -- die neue Jetzt-Marke mit
   10,88. Beide Male gemeldet von pruef-handy und pruef-grosscheck,
   beide Male erst nach einem mehrminuetigen Browserlauf.

ZWEI PRUEFUNGEN, DIE SICH SELBST IM WEG STANDEN

pruef-tempo-workspace meldete "NEUE Doppelabfrage: start.html 2x
/workspace/api/termine". Nachgemessen an einem einzelnen Seitenaufruf:
genau eine Anfrage. Die Pruefung startete ihren Zaehler, bevor die
Anmeldung zur Ruhe gekommen war, und schrieb der Seite an, was die
vorherige noch offen hatte.

pruef-tagesblick fiel zum zweiten Mal auf dieselbe Falle herein: Sie
mass die Artfarbe an einem vorbeigezogenen Termin, der absichtlich grau
ist. Diesmal an der Wurzel geloest -- die Daempfung wird fuer die
Messung kurz abgeschaltet und sofort zurueckgesetzt. Damit ist die
Zuordnung fuer JEDEN Termin geprueft, unabhaengig von der Uhrzeit des
Laufs, und zusaetzlich beweist die Pruefung, dass die Daempfung greift.

NEU: Schriftgroessen werden jetzt AN DER QUELLE geprueft, in Sekunden
statt Minuten. Im Bestand stehen 43 solche Stellen; sie alle rot zu
melden haette die Pruefung ab Tag eins wertlos gemacht. Deshalb eine
Grundlinie wie beim Layout-Sprung: Sie haelt den Stand fest und
schlaegt an, sobald es MEHR werden. Heute haette das zweimal gegriffen.
Die Browserpruefung bleibt daneben -- sie sieht, was am Ende auf dem
Schirm steht, die CSS-Pruefung nur, was gemeint war.

Gesamtlauf: 56 von 56 Dateien, 2002 von 2002 Punkten.

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

2026-09-06 01:32:33 +02:00

DogFatherGitandClaude Opus 5

540b5d8838

Freie Namen, ein Call-Knopf, und drei Seiten, die fuer Scouts kaputt waren

DREI SACHEN AUF EINMAL, alle aus derselben Sitzung.

1. AUSSUCHEN ODER SELBST EINTRAGEN
   Wunsch: "ich will da auch sachen selber noch eintragen koennen, also
   aussuchen und selbst eintragen."

   Jede Personenauswahl (Kalender, Aufgaben, Bereiche, Content, Dateien)
   nimmt jetzt auch einen getippten Namen an -- eine Agentur, eine Marke,
   einen Gast ohne Konto. Dazu bekommt JEDE Auswahl ab acht Eintraegen
   ein Suchfeld: tippen statt scrollen.

   Gebaut IM vorhandenen Auswahl-Bauteil (wahl.js), nicht daneben. Der
   erste Anlauf war ein zweites Bauteil -- es hat sich prompt mit dem
   ersten gebissen, beide haben denselben <select> eingepackt. Ein
   zweites haette ausserdem anders ausgesehen und waere beim naechsten
   Umbau nur an einer von zwei Stellen nachgezogen worden.

   Der freie Name steht in einer EIGENEN Spalte je Feld; die Verknuepfung
   bleibt leer. Entweder eine Person ODER ein Name, nie beides.

   Filipe hat ausdruecklich auch bei den Creator-Feldern freie Namen
   gewollt, nachdem der Nachteil benannt war: Der Eintrag gehoert dann zu
   keinem Konto. Damit daraus kein STILLER Ausfall wird, faellt jede
   Abfrage, die bisher den Namen der verknuepften Person las, jetzt auf
   den freien Text zurueck (externSql) -- gekennzeichnet als "(extern)".
   Der Eintrag verschwindet dadurch aus keiner Liste, keiner Suche und
   keiner Uebersicht.

2. WO FUEHRE ICH DEN CALL?
   Den Knopf gab es, aber nur wenn jemand von Hand einen Link ins
   Ortsfeld getippt hatte UND das Gespraech noch bevorstand. Stand dort
   "Hier", war nichts zum Anklicken da.

   Jetzt hat das Team einen festen Call-Raum (Discord-Sprachkanal), den
   das Management einmal hinterlegt. Danach hat JEDER Call den Knopf --
   und er bleibt, solange das Gespraech laufen kann, nicht nur bis zur
   Startzeit. Ein eigener Link am Termin schlaegt den festen Raum.

3. WAS EINE ROLLE SIEHT, MUSS AUCH FUNKTIONIEREN
   Gemeldet: "cigdem kriegt als manager gewisse sachen nicht auf die sie
   sieht, check jede rolle ab."

   Neue Pruefung server/pruef-rollen.mjs schickt SECHS Rollen-Zustaende
   ueber alle 16 Seiten und misst Konsolenfehler, fehlgeschlagene
   Serveraufrufe, tote Verweise, haengende Ladeanzeigen und wortlos leere
   Seiten. 96 Durchgaenge.

   Der sechste Zustand ist der wichtige: eine Rolle OHNE zugeteilte
   Creator -- der Normalfall am ersten Tag und Cigdems echte Lage.
   Genau dort fielen die Seiten durch, waehrend dieselben Seiten MIT
   Zuteilung tadellos waren.

   VIER ECHTE FEHLER GEFUNDEN UND BEHOBEN:

   a) Eine Aufgabe, die eine Managerin ohne Creator anlegte, war fuer sie
      im selben Moment unsichtbar -- creator_id und verantwortlich_id
      leer, und "von mir selbst angelegt" stand in keiner
      Sichtbarkeitsregel. Nur DogFather sah sie noch. Kein Fehler, keine
      Meldung, die Aufgabe war einfach weg. Dasselbe bei den
      Bereichseintraegen. Beide Regeln kennen jetzt erstellt_von.
      Niemand sieht dadurch etwas Fremdes -- nur das Eigene.

   b) Ein Scout ohne zugeteilten Creator bekam auf die GESAMTE
      Report-Seite 404, obwohl sie fuer ihn verlinkt ist. Die Seite
      antwortet jetzt sauber und leer, statt sich zu verweigern.

   c) Start-Check und Report blieben fuer immer auf "wird geladen"
      stehen, wenn es nichts zu laden gab.

   d) Das Creator-Profil war fuer Scouts ohne Zuteilung wortlos leer --
      der erklaerende Satz stand nur in der grauen Unterzeile.

   Ausserdem meldete die bestehende Lesbarkeitspruefung zwei neue
   Beschriftungen von mir als zu klein fuers Handy (10,88 statt 11,5 px).
   Behoben, und dieselbe Groesse an der Serien-Karte gleich mit -- dort
   waere es erst aufgefallen, sobald jemand eine Wiederholung anlegt.

GEPRUEFT: pruef-rollen 97, pruef-freie-namen 32 (mit Gegenproben:
Ben sieht Cigdems Aufgabe NICHT; die Saeulen-Zuordnung nimmt
ausdruecklich KEINEN freien Namen). Alle bestehenden Laeufe gruen:
Startansicht 133, Kalender 84, Serien 67, Protokoll 52, Handy 50, Sicht
48, Ampel 47, Content 45, Aufgabenbrett 44, Sprung 43,
Personen-Loeschen 40, Bereiche 37, Uebersicht 33, Workspace-Seiten 32,
Formulare 19, Betreuung 18, Grosscheck 15, Lesbarkeit 14.

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

2026-09-02 20:10:09 +02:00