dogfather-universe

532 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
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
DogFatherGitandClaude Opus 5	e7b277b7fc	Die Startseite log nicht -- sie war nur alt. Und Protokolle lassen sich loeschen Drei Meldungen aus einer Nachricht. 1. "WIRD IMMER NOCH ANGEZEIGT" Ein Protokoll war geschrieben, die Startseite meldete trotzdem weiter "1 Gespraech hat noch kein Protokoll". NACHGESTELLT statt vermutet: Der Server lag die ganze Zeit richtig. Der Hinweis erscheint, sobald ein vergangenes Gespraech kein Protokoll hat, und verschwindet in dem Moment, in dem eines geschrieben ist -- nachgemessen, beides. Falsch war der BILDSCHIRM. Browser legen eine verlassene Seite vollstaendig beiseite (bfcache) und holen sie beim Zurueckgehen unveraendert hervor, mitsamt allen Zahlen vom ersten Laden. Kein Skript laeuft dabei erneut. Wer ein Protokoll schreibt und dann auf "Zurueck" tippt, sieht zwangslaeufig den Stand von vorher. Das ist kein Schoenheitsfehler: Eine Zahl, die etwas Falsches behauptet, ist schlimmer als gar keine -- man glaubt ihr ja. Und sie kostet danach Vertrauen in ALLE Zahlen. kopf.js laedt eine zurueckgeholte Seite jetzt neu. Nur dann (`event.persisted`), nicht bei jedem Anzeigen -- sonst waere es eine Endlosschleife. Gilt fuer jede Workspace-Seite, nicht nur die Startseite. 2. PROTOKOLLE LOESCHEN -- NUR DOGFATHER Bewusst istDogFather und nicht istLeitung: Ein Manager hat sonst ueberall dieselben Rechte, hier ausdruecklich nicht. Wer ein Protokoll entfernen darf, kann nachtraeglich bestimmen, was besprochen wurde. Geloescht wird NUR das Protokoll. Das Gespraech bleibt im Kalender und rutscht wieder zu "Protokoll fehlt" -- die Handlung ist damit umkehrbar: neu schreiben, fertig. Die daraus entstandenen AUFGABEN bleiben ebenfalls stehen; sie sind echte Arbeit, die jemand uebernommen hat, und mit einem Klick auf ein Protokoll zu verschwinden waere ein stiller Datenverlust an ganz anderer Stelle. Der Knopf steht nur bei DogFather. Ein Knopf, der bei anderen erscheint und dann abgewiesen wird, ist eine Einladung zum Aergernis. 3. IMMER NUR EINS OFFEN Vorher liessen sich beliebig viele Protokolle gleichzeitig aufklappen -- die Seite wurde so lang, dass die Liste darunter aus dem Blick geriet. Ein neu geoeffnetes Gespraech schliesst jetzt das vorherige. Beim Laden ist alles zu. GEPRUEFT: server/pruef-protokoll-loeschen.mjs, 20 Pruefungen. Die Zurueck-Pruefung misst an EINZAHL gegen MEHRZAHL ("1 Gespraech HAT" gegen "2 Gespraeche HABEN") -- die Zahl selbst steht in einem eigenen Feld und taucht im Fliesstext nicht auf. Drei Gegenproben: dass der Hinweis nach dem Reparieren ueberhaupt noch anschlaegt (sonst waere "verschwunden" auch bei kaputtem Hinweis gruen), dass eine Managerin 403 bekommt und das Protokoll danach unveraendert dasteht, und dass der Loeschknopf bei ihr gar nicht erst gezeichnet wird. Bestehende Laeufe gruen: Startansicht 133, Rollen 97, Kalender 84, Serien 67, Protokoll-Klappe 52, Handy 50, Ampel 47, Freie Namen 32, Code 17. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-02 23:45:45 +02:00
DogFatherGitandClaude Opus 5	fc26597083	Wer sich einen neuen Code gibt, sperrt sich nicht mehr selbst aus Gemeldet: "ich hab einen neuen code fuer mich gemacht aber ich wurde raus gekickt bevor ich den neuen code kopieren konnte jetzt komm ich nicht mehr rein." DER FEHLER Ein neuer Code beendete ALLE Sitzungen der Person -- auch die, in der der Code gerade auf dem Bildschirm stand. Der naechste Aufruf der Seite lief in ein "nicht angemeldet", die Umleitung zur Anmeldung nahm den Kasten samt Code mit, und der Code ist nirgends noch einmal abrufbar (in der Datenbank steht nur seine Pruefsumme). Ergebnis: ausgesperrt, Rueckweg nur ueber einen Eingriff auf dem Server. Bitter daran: Die Rueckfrage sagte das sogar an ("Deine aktuelle Sitzung wird sofort beendet") -- als Warnung formuliert, nicht als Fehler erkannt. Ein Ablauf, den man nur mit gutem Timing ueberlebt, ist keiner. DREI RIEGEL, NICHT EINER 1. DIE EIGENE SITZUNG BLEIBT. codeNeu() beendet weiterhin alle Sitzungen der Person -- ausser der einen, aus der heraus der Code gerade erneuert wird. Sicherheitlich kostet das nichts: Wer den Code tauscht, hat sich mit genau dieser Sitzung soeben ausgewiesen und haelt sie in Haenden. Alle ANDEREN Geraete fliegen weiterhin hinaus -- das ist der Sinn der Uebung und wird eigens geprueft. 2. DER KASTEN BLEIBT STEHEN. Solange ein frischer Code angezeigt wird, springt die Personenseite nicht mehr von selbst zur Anmeldung. Selbst wenn eine Sitzung aus einem anderen Grund endet (Zeitablauf, Neustart), bleibt der Code lesbar, bis er weggeklickt ist -- mit einem Hinweis, ihn jetzt abzuschreiben. Ein Code, den man nicht mehr lesen kann, ist schlimmer als gar keiner. 3. EINE TUER VON AUSSEN: tools/notfall-code.sh. Setzt auf dem Server einen neuen Code, zeigt ihn an und loescht die Sperre nach acht Fehlversuchen gleich mit. Weigert sich, als root zu laufen (sonst gehoerten die Hilfsdateien der Datenbank danach root und der Dienst koennte nicht mehr schreiben). Dokumentiert als "Fall 0" in WIEDERHERSTELLUNG.md -- dem ersten Fall, den man aufschlaegt, wenn nichts kaputt ist ausser dem Zugang. KEIN fest hinterlegter Notfall-Code in der Anwendung: Der waere eine Hintertuer, die dauerhaft offensteht, fuer jeden der sie findet, ohne dass es auffiele. Dieser Weg verlangt Zugang zum Server, hinterlaesst einen Protokolleintrag, und es gibt nichts zu erraten. Die Rueckfrage sagt jetzt, was wirklich passiert, statt vor etwas zu warnen, das nicht mehr eintritt. GEPRUEFT: server/pruef-code.mjs, 17 Pruefungen -- darunter die Gegenprobe, dass das ZWEITE Geraet derselben Person sehr wohl abgemeldet wird (ohne sie waere die Reparatur auf dem Weg, einen neuen Code zur Formalie zu machen), dass der alte Code nicht mehr gilt, dass beim Erneuern eines FREMDEN Codes weiterhin alles hinausfliegt, und dass die Seite nach dem Erzeugen nicht zur Anmeldung springt. Das Notfall-Skript ist mit beiden Wegen getestet (Treffer und unbekannter Name). Bestehende Laeufe gruen: Rollen 97, Personen-Liste 33, Sicht 48. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-02 23:05:29 +02:00

Author

SHA1

Message

Date

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

DogFatherGitandClaude Opus 5

e7b277b7fc

Die Startseite log nicht -- sie war nur alt. Und Protokolle lassen sich loeschen

Drei Meldungen aus einer Nachricht.

1. "WIRD IMMER NOCH ANGEZEIGT"
   Ein Protokoll war geschrieben, die Startseite meldete trotzdem weiter
   "1 Gespraech hat noch kein Protokoll".

   NACHGESTELLT statt vermutet: Der Server lag die ganze Zeit richtig.
   Der Hinweis erscheint, sobald ein vergangenes Gespraech kein Protokoll
   hat, und verschwindet in dem Moment, in dem eines geschrieben ist --
   nachgemessen, beides.

   Falsch war der BILDSCHIRM. Browser legen eine verlassene Seite
   vollstaendig beiseite (bfcache) und holen sie beim Zurueckgehen
   unveraendert hervor, mitsamt allen Zahlen vom ersten Laden. Kein
   Skript laeuft dabei erneut. Wer ein Protokoll schreibt und dann auf
   "Zurueck" tippt, sieht zwangslaeufig den Stand von vorher.

   Das ist kein Schoenheitsfehler: Eine Zahl, die etwas Falsches
   behauptet, ist schlimmer als gar keine -- man glaubt ihr ja. Und sie
   kostet danach Vertrauen in ALLE Zahlen.

   kopf.js laedt eine zurueckgeholte Seite jetzt neu. Nur dann
   (`event.persisted`), nicht bei jedem Anzeigen -- sonst waere es eine
   Endlosschleife. Gilt fuer jede Workspace-Seite, nicht nur die
   Startseite.

2. PROTOKOLLE LOESCHEN -- NUR DOGFATHER
   Bewusst istDogFather und nicht istLeitung: Ein Manager hat sonst
   ueberall dieselben Rechte, hier ausdruecklich nicht. Wer ein Protokoll
   entfernen darf, kann nachtraeglich bestimmen, was besprochen wurde.

   Geloescht wird NUR das Protokoll. Das Gespraech bleibt im Kalender und
   rutscht wieder zu "Protokoll fehlt" -- die Handlung ist damit
   umkehrbar: neu schreiben, fertig. Die daraus entstandenen AUFGABEN
   bleiben ebenfalls stehen; sie sind echte Arbeit, die jemand uebernommen
   hat, und mit einem Klick auf ein Protokoll zu verschwinden waere ein
   stiller Datenverlust an ganz anderer Stelle.

   Der Knopf steht nur bei DogFather. Ein Knopf, der bei anderen
   erscheint und dann abgewiesen wird, ist eine Einladung zum Aergernis.

3. IMMER NUR EINS OFFEN
   Vorher liessen sich beliebig viele Protokolle gleichzeitig aufklappen
   -- die Seite wurde so lang, dass die Liste darunter aus dem Blick
   geriet. Ein neu geoeffnetes Gespraech schliesst jetzt das vorherige.
   Beim Laden ist alles zu.

GEPRUEFT: server/pruef-protokoll-loeschen.mjs, 20 Pruefungen. Die
Zurueck-Pruefung misst an EINZAHL gegen MEHRZAHL ("1 Gespraech HAT" gegen
"2 Gespraeche HABEN") -- die Zahl selbst steht in einem eigenen Feld und
taucht im Fliesstext nicht auf. Drei Gegenproben: dass der Hinweis nach
dem Reparieren ueberhaupt noch anschlaegt (sonst waere "verschwunden"
auch bei kaputtem Hinweis gruen), dass eine Managerin 403 bekommt und das
Protokoll danach unveraendert dasteht, und dass der Loeschknopf bei ihr
gar nicht erst gezeichnet wird. Bestehende Laeufe gruen: Startansicht 133,
Rollen 97, Kalender 84, Serien 67, Protokoll-Klappe 52, Handy 50, Ampel
47, Freie Namen 32, Code 17.

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

2026-09-02 23:45:45 +02:00

DogFatherGitandClaude Opus 5

fc26597083

Wer sich einen neuen Code gibt, sperrt sich nicht mehr selbst aus

Gemeldet: "ich hab einen neuen code fuer mich gemacht aber ich wurde raus
gekickt bevor ich den neuen code kopieren konnte jetzt komm ich nicht mehr
rein."

DER FEHLER
Ein neuer Code beendete ALLE Sitzungen der Person -- auch die, in der der
Code gerade auf dem Bildschirm stand. Der naechste Aufruf der Seite lief in
ein "nicht angemeldet", die Umleitung zur Anmeldung nahm den Kasten samt
Code mit, und der Code ist nirgends noch einmal abrufbar (in der Datenbank
steht nur seine Pruefsumme). Ergebnis: ausgesperrt, Rueckweg nur ueber
einen Eingriff auf dem Server.

Bitter daran: Die Rueckfrage sagte das sogar an ("Deine aktuelle Sitzung
wird sofort beendet") -- als Warnung formuliert, nicht als Fehler erkannt.
Ein Ablauf, den man nur mit gutem Timing ueberlebt, ist keiner.

DREI RIEGEL, NICHT EINER

1. DIE EIGENE SITZUNG BLEIBT. codeNeu() beendet weiterhin alle Sitzungen
   der Person -- ausser der einen, aus der heraus der Code gerade erneuert
   wird. Sicherheitlich kostet das nichts: Wer den Code tauscht, hat sich
   mit genau dieser Sitzung soeben ausgewiesen und haelt sie in Haenden.
   Alle ANDEREN Geraete fliegen weiterhin hinaus -- das ist der Sinn der
   Uebung und wird eigens geprueft.

2. DER KASTEN BLEIBT STEHEN. Solange ein frischer Code angezeigt wird,
   springt die Personenseite nicht mehr von selbst zur Anmeldung. Selbst
   wenn eine Sitzung aus einem anderen Grund endet (Zeitablauf, Neustart),
   bleibt der Code lesbar, bis er weggeklickt ist -- mit einem Hinweis,
   ihn jetzt abzuschreiben. Ein Code, den man nicht mehr lesen kann, ist
   schlimmer als gar keiner.

3. EINE TUER VON AUSSEN: tools/notfall-code.sh. Setzt auf dem Server einen
   neuen Code, zeigt ihn an und loescht die Sperre nach acht Fehlversuchen
   gleich mit. Weigert sich, als root zu laufen (sonst gehoerten die
   Hilfsdateien der Datenbank danach root und der Dienst koennte nicht
   mehr schreiben). Dokumentiert als "Fall 0" in WIEDERHERSTELLUNG.md --
   dem ersten Fall, den man aufschlaegt, wenn nichts kaputt ist ausser
   dem Zugang.

   KEIN fest hinterlegter Notfall-Code in der Anwendung: Der waere eine
   Hintertuer, die dauerhaft offensteht, fuer jeden der sie findet, ohne
   dass es auffiele. Dieser Weg verlangt Zugang zum Server, hinterlaesst
   einen Protokolleintrag, und es gibt nichts zu erraten.

Die Rueckfrage sagt jetzt, was wirklich passiert, statt vor etwas zu
warnen, das nicht mehr eintritt.

GEPRUEFT: server/pruef-code.mjs, 17 Pruefungen -- darunter die Gegenprobe,
dass das ZWEITE Geraet derselben Person sehr wohl abgemeldet wird (ohne sie
waere die Reparatur auf dem Weg, einen neuen Code zur Formalie zu machen),
dass der alte Code nicht mehr gilt, dass beim Erneuern eines FREMDEN Codes
weiterhin alles hinausfliegt, und dass die Seite nach dem Erzeugen nicht
zur Anmeldung springt. Das Notfall-Skript ist mit beiden Wegen getestet
(Treffer und unbekannter Name). Bestehende Laeufe gruen: Rollen 97,
Personen-Liste 33, Sicht 48.

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

2026-09-02 23:05:29 +02:00