dogfather-universe

641 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	68bc116c36	Die Rolle "Spicy Media" -- und drei Fehler, die nur ihre Pruefung fand DIE PERSONENTABELLE WURDE NEU GEBAUT. Eine Rolle ist ein erlaubter Wert in einer Spalte, und der steckt in einem CHECK -- den kann SQLite nicht aendern. Auf `personen` zeigen ZWEIUNDFUENFZIG Fremdschluessel. Deshalb wird der Bauplan NICHT abgeschrieben, sondern gelesen: Der CREATE-Text kommt aus sqlite_master, darin wird ausschliesslich die Rollenliste ersetzt, und die Kopierliste kommt aus PRAGMA table_info. Die beiden aelteren Umstellungen schreiben ihre Spalten von Hand ab -- `personen` hat seit damals SIEBEN dazubekommen (bild, ueber_mich, tiktok ...). Wer hier abschreibt, verliert alle Profilbilder. ZWEI FRAGEN, DIE MAN AUSEINANDERHALTEN MUSS: siehtAlles() = DogFather ODER Spicy Media -> Listen, Uebersichten istDogFather() = nur DogFather -> loeschen, Rollen, Codes Es waere weniger Arbeit gewesen, istDogFather() um "spicy" zu erweitern -- und genau das waere der Fehler: Spicy Media koennte dann DogFather loeschen. DER CHAT BRAUCHTE NICHTS. Er haengt allein an der Teilnehmerliste und kennt kein "das Management sieht alles". Spicy Media sieht fremde Gespraeche nicht, weil es dafuer keinen Weg gibt -- nicht, weil eine Abfrage es verbietet. DREI ECHTE FEHLER, alle von pruef-spicy gefunden, keiner vorher sichtbar: 1. MEIN EIGENER KOMMENTAR STAND IM BAUPLAN. SQLite hebt den CREATE-Text woertlich auf, samt Kommentaren. Ich hatte "'spicy' steht HIER mit drin" hineingeschrieben -- und die Erkennung suchte genau dieses Wort im ganzen Text. Ergebnis: Die Umstellung hielt die Tabelle fuer erledigt, obwohl die CHECK-Regel noch die alte war. Jetzt wird die Regel herausgeschnitten und NUR darin gesucht; der Kommentar steht ausserhalb des SQL. 2. DER SICHERUNGSNAME HATTE NUR MINUTEN. `VACUUM INTO` weigert sich, eine vorhandene Datei zu ueberschreiben -- zu Recht. Zwei Umstellungen in derselben Minute wollten in dieselbe Datei, die zweite scheiterte, und weil ohne Sicherung nicht umgestellt wird, blieb sie aus. Es sah nach "lief" aus (die Datei lag ja da) und war keine. Jetzt mit Sekunden. 3. EINE FRISCHE DATENBANK LEGTE DIE ALTE ROLLENLISTE AN und stellte beim allerersten Start sofort um -- Tabelle neu bauen, Sicherung schreiben, fuer nichts. Ein Bauplan, der sofort umgebaut werden muss, ist der falsche. Und ein vierter in der Pruefung selbst: Der Chat-Aufbau benutzte einen falschen Weg, das Gespraech entstand gar nicht -- "Spicy Media sieht 0 Gespraeche" war trotzdem gruen, weil es keine gab. Jetzt ist das Anlegen selbst eine Pruefung, und eine Gegenprobe zeigt, dass Max es sehr wohl sieht. DAZU: Manager sehen die Kachel "Personen & Zugaenge" -- die SEITE geht auf, die Schnittstellen nicht. Alles unter /verwaltung haengt weiter an `nurAdmin` und antwortet 404; sie sehen genau den Teil, fuer den es einen Weg gibt. Spicy Media legt Creator UND Manager an (zweite enge Tuer, Rolle steht auch dort nicht im Aufruf; ein Manager kommt durch sie nicht). Der Rollentext des Managers stimmte nicht mehr -- er legt jetzt Creator an. pruef-spicy: 36 Pruefungen, alle gruen. Ausserdem gruen: personen-liste (33), creator-anlegen (29), sicht (48), css-klassen (15), alle-wege (19), haerte (20), manager-sicht (43). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-07 04:56:07 +02:00
DogFatherGitandClaude Opus 5	0404f8c0c1	Dreizehn Lecks: eine Managerin sah die Creator aller anderen Wunsch: "jeder manager soll auch immer nur seine und die seiner scouts zugeteilten creator und creator daten sehen. und nicht die der anderen." DIE KETTE WAR GEBAUT -- SIE WURDE NUR NICHT BENUTZT Manager -> seine Scouts -> deren Creator steht seit dem 01.09.2026 an genau einer Stelle (betreuteIds). Die Frage war eine andere: Benutzt sie auch JEDER Weg, der Creator-Daten herausgibt? Ueber zwanzig Stellen prueften die ROLLE statt der ZUTEILUNG -- "ist Leitung? dann alles". NICHT GELESEN, SONDERN GEMESSEN server/pruef-manager-sicht.mjs baut zwei Managerinnen mit vollstaendig getrennten Creators. Bei der fremden heisst ALLES "GEHEIM..." -- Aufgabe, Termin, Bereichseintrag, Datei, Steckbrief, Content-Saeule. Danach wird jede der 31 Leseschnittstellen abgefragt und die ganze Antwort danach durchsucht. Ein Leck faellt damit auf, egal wo es sitzt und egal, ob ich es beim Lesen uebersehen haette. GEFUNDEN: DREIZEHN. Alle geschlossen: Kalender fremde Fristen -- besonders unangenehm, weil es nicht wie ein Leck aussieht: eine kleine orange Marke mit einem Titel, in dem fremde Vorhaben stehen Personenauswahl alle Namen im Zuweisungsfeld Dateien alle Namen in der Freigabe-Auswahl Uebersicht Gesamtuebersicht ueber ALLE Creator Report Auswahl UND Auswertung ueber den ganzen Bestand Start-Check alle Creator zur Auswahl Steckbriefe Bild, Kanaele, "ueber mich" von allen Profile alle Profile, samt interner Notiz Schulung Schulungsstand aller Creator Suche Creator-Profile aller -- die unauffaelligste Stelle: Man sucht etwas anderes und bekommt fremde Namen Content-Balance Themensaeulen fremder Kanaele (die Abfrage daneben war korrekt eingeschraenkt, DIESE hatte eine eigene Bedingung) darfCreator eine einzige Zeile -- sie hing an Profil, Start-Check und Uebersicht gleichzeitig. Es reichte, eine Nummer in die Adresse zu schreiben. Die Antwort steht jetzt an EINER Stelle: sichtbareCreatorIds und sichtbarePersonenIds in workspace.js. Rueckgabe null heisst "alle" und gilt allein DogFather -- bewusst kein leeres Feld: Eine leere Liste bedeutet "niemand", und die Verwechslung der beiden macht aus einer Sperre eine Freigabe. ZWEI DINGE, DIE ICH MIR SELBST NACHTRAGEN MUSS 1. Beim Stopfen fehlte einmal ein Import. Der Weg warf einen Fehler, antwortete 503 -- und weil in einer Fehlermeldung kein "GEHEIM" steht, meldete die Pruefung "kein Leck". Sie war gruen, weil der Weg KAPUTT war. Die Pruefung zaehlt jetzt beides: nichts durchsickern UND antworten. 2. Ein Fehlalarm: Die Suche gibt den SUCHBEGRIFF in ihrer Antwort zurueck. Wer nach "GEHEIM" sucht, findet das Wort zwangslaeufig -- auch bei null Treffern. Ich haette um ein Haar ein Leck "repariert", das es nie gab. Das Echo wird jetzt entfernt, bevor gemessen wird. FOLGEN, bewusst in Kauf genommen: * Ein Manager ohne Zuteilung sieht keinen Creator. Die Uebersicht sagt ihm das jetzt in einem Satz, statt leer zu bleiben. * Er kann nur noch IN SEINEN Creator-Bereichen schreiben (darfCreator). ZWEI PRUEFUNGEN UMGEDREHT statt geloescht -- eine geloeschte Pruefung hinterlaesst keine Spur davon, dass hier einmal etwas anderes galt: pruef-uebersicht ("Manager sieht dasselbe" -> "nur seine zugeteilten", mit beiden Faellen) und pruef-scout-zuteilung ("sieht die ganze Personenliste" -> "landet auf der Startseite"). GEPRUEFT: 43 neue Pruefungen, dazu 23 bestehende Laeufe gruen -- Startansicht 133, Rollen 97, Kalender 84, Serien 67, Steckbrief 65, Handy 50, Sicht 48, Ampel 47, Content 45, Aufgabenbrett 44, Schulung 41, Bereiche 37, Scout-Zuteilung 36, Uebersicht 35, Personenliste 33, Freie Namen 32, Team 30, Protokoll-Loeschen 20, Personenformular 20, Formulare 19, Betreuung 18, Code 17, Grosscheck 15. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-03 01:01:00 +02:00
DogFatherGitandClaude Opus 5	5960f6e3c4	Unterweisungen mit beidseitiger Bestaetigung - und einer echten Sperre Der Wunsch: "jeder Scout, Manager oder DogFather muss mit seinen Creatorn die PDFs durchgehen, und beide druecken dann auf verifiziert, so dass wir den Beweis haben -- und das ist danach auch nicht mehr zu aendern." Das ist kein Haekchen, das ist ein NACHWEIS. Wer so etwas baut, muss drei Fragen beantworten, sonst ist er wertlos: WER hat bestaetigt? Beide Seiten getrennt, mit Name, Zeitpunkt und IP. Eine einzelne Bestaetigung reicht nicht -- "ich habe es ihm gezeigt" und "er hat es mir gezeigt" sind zwei verschiedene Aussagen, und erst zusammen ergeben sie einen Beweis. Bestaetigt nur einer, steht die Unterweisung sichtbar als HALB da, in einer eigenen warnenden Farbe. Diese Zwischenstufe sichtbar zu machen ist der Punkt: Ein Nachweis, bei dem nur einer unterschrieben hat, sieht sonst aus wie fertig -- und man merkt es erst, wenn jemand danach fragt. WORAUF genau? Nicht auf "die Regeln", sondern auf eine bestimmte Datei. Beim Bestaetigen wird der SHA-256 der PDF-Datei mitgespeichert. Tauscht spaeter jemand die Datei aus, passt der Fingerabdruck nicht mehr, und die Seite sagt das auch ("Das Dokument wurde seit der Bestaetigung ausgetauscht"). Ohne diesen Wert waere die Bestaetigung ein Zettel ohne Bezug. IST ES UNVERAENDERT? Eine abgeschlossene Bestaetigung laesst sich nicht mehr aendern und nicht loeschen -- und zwar nicht, weil der Code es nicht anbietet, sondern weil die DATENBANK es ablehnt. Zwei Trigger mit RAISE(ABORT). Ein Schutz, der nur im Code steht, ist beim naechsten neuen Weg zur Datenbank wieder weg. DER VOLLZUG WURDE DURCHGESPIELT. Aus RunOne stammt die Lehre, dass ein Weg, den man nicht rueckgaengig machen kann, tagelang live sein und NIE gelaufen sein kann. Die Pruefung bestaetigt deshalb wirklich, schliesst ab, und versucht dann eine Aenderung -- ueber die Schnittstelle UND direkt auf der Datenbank. Beide werden abgelehnt. Und die GEGENPROBE dazu: Der Trigger wird entfernt, dieselbe Aenderung versucht -- sie geht durch -- und der Trigger wieder gesetzt. Eine Sperre, die man nicht hat scheitern sehen, ist keine Sperre. Der Server entscheidet anhand der ROLLE, welche Seite gesetzt wird -- nicht der Absender. Sonst koennte ein Creator die Bestaetigung seines Betreuers eintragen, und der ganze Nachweis waere wertlos. Eine bereits gesetzte Seite wird nie ueberschrieben; ein Datum laesst sich also auch nicht nachtraeglich verschieben. Die Dokumente kommen aus der Wissens-Bibliothek, es gibt keinen zweiten Upload-Weg. Sonst gaebe es Dateien, die nur hier existieren -- und niemand wuesste, welche Fassung die richtige ist. Eine Unterweisung wird nie geloescht, nur abgeschaltet: Die Nachweise haengen daran. EIN EIGENER FEHLER, VON DER BROWSERPRUEFUNG GEFUNDEN: Der Aufruf der Zusatzbloecke stand NACH einem return. laden() steigt frueh aus, wenn die Liste leer ist -- und dann wurden Vorlagen und Unterweisungen nie gebaut. Also ausgerechnet auf der leeren Seite, fuer die sie gedacht sind. Jetzt stehen sie in einem finally. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-01 16:39:00 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

68bc116c36

Die Rolle "Spicy Media" -- und drei Fehler, die nur ihre Pruefung fand

DIE PERSONENTABELLE WURDE NEU GEBAUT. Eine Rolle ist ein erlaubter Wert
in einer Spalte, und der steckt in einem CHECK -- den kann SQLite nicht
aendern. Auf `personen` zeigen ZWEIUNDFUENFZIG Fremdschluessel.

Deshalb wird der Bauplan NICHT abgeschrieben, sondern gelesen: Der
CREATE-Text kommt aus sqlite_master, darin wird ausschliesslich die
Rollenliste ersetzt, und die Kopierliste kommt aus PRAGMA table_info.
Die beiden aelteren Umstellungen schreiben ihre Spalten von Hand ab --
`personen` hat seit damals SIEBEN dazubekommen (bild, ueber_mich,
tiktok ...). Wer hier abschreibt, verliert alle Profilbilder.

ZWEI FRAGEN, DIE MAN AUSEINANDERHALTEN MUSS:
  siehtAlles()   = DogFather ODER Spicy Media -> Listen, Uebersichten
  istDogFather() = nur DogFather              -> loeschen, Rollen, Codes
Es waere weniger Arbeit gewesen, istDogFather() um "spicy" zu erweitern
-- und genau das waere der Fehler: Spicy Media koennte dann DogFather
loeschen.

DER CHAT BRAUCHTE NICHTS. Er haengt allein an der Teilnehmerliste und
kennt kein "das Management sieht alles". Spicy Media sieht fremde
Gespraeche nicht, weil es dafuer keinen Weg gibt -- nicht, weil eine
Abfrage es verbietet.

DREI ECHTE FEHLER, alle von pruef-spicy gefunden, keiner vorher sichtbar:

1. MEIN EIGENER KOMMENTAR STAND IM BAUPLAN. SQLite hebt den CREATE-Text
   woertlich auf, samt Kommentaren. Ich hatte "'spicy' steht HIER mit
   drin" hineingeschrieben -- und die Erkennung suchte genau dieses Wort
   im ganzen Text. Ergebnis: Die Umstellung hielt die Tabelle fuer
   erledigt, obwohl die CHECK-Regel noch die alte war. Jetzt wird die
   Regel herausgeschnitten und NUR darin gesucht; der Kommentar steht
   ausserhalb des SQL.

2. DER SICHERUNGSNAME HATTE NUR MINUTEN. `VACUUM INTO` weigert sich, eine
   vorhandene Datei zu ueberschreiben -- zu Recht. Zwei Umstellungen in
   derselben Minute wollten in dieselbe Datei, die zweite scheiterte, und
   weil ohne Sicherung nicht umgestellt wird, blieb sie aus. Es sah nach
   "lief" aus (die Datei lag ja da) und war keine. Jetzt mit Sekunden.

3. EINE FRISCHE DATENBANK LEGTE DIE ALTE ROLLENLISTE AN und stellte beim
   allerersten Start sofort um -- Tabelle neu bauen, Sicherung schreiben,
   fuer nichts. Ein Bauplan, der sofort umgebaut werden muss, ist der
   falsche.

Und ein vierter in der Pruefung selbst: Der Chat-Aufbau benutzte einen
falschen Weg, das Gespraech entstand gar nicht -- "Spicy Media sieht 0
Gespraeche" war trotzdem gruen, weil es keine gab. Jetzt ist das Anlegen
selbst eine Pruefung, und eine Gegenprobe zeigt, dass Max es sehr wohl
sieht.

DAZU: Manager sehen die Kachel "Personen & Zugaenge" -- die SEITE geht
auf, die Schnittstellen nicht. Alles unter /verwaltung haengt weiter an
`nurAdmin` und antwortet 404; sie sehen genau den Teil, fuer den es
einen Weg gibt. Spicy Media legt Creator UND Manager an (zweite enge
Tuer, Rolle steht auch dort nicht im Aufruf; ein Manager kommt durch
sie nicht). Der Rollentext des Managers stimmte nicht mehr -- er legt
jetzt Creator an.

pruef-spicy: 36 Pruefungen, alle gruen. Ausserdem gruen: personen-liste
(33), creator-anlegen (29), sicht (48), css-klassen (15), alle-wege (19),
haerte (20), manager-sicht (43).

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

2026-09-07 04:56:07 +02:00

DogFatherGitandClaude Opus 5

0404f8c0c1

Dreizehn Lecks: eine Managerin sah die Creator aller anderen

Wunsch: "jeder manager soll auch immer nur seine und die seiner scouts
zugeteilten creator und creator daten sehen. und nicht die der anderen."

DIE KETTE WAR GEBAUT -- SIE WURDE NUR NICHT BENUTZT
Manager -> seine Scouts -> deren Creator steht seit dem 01.09.2026 an
genau einer Stelle (betreuteIds). Die Frage war eine andere: Benutzt sie
auch JEDER Weg, der Creator-Daten herausgibt? Ueber zwanzig Stellen
prueften die ROLLE statt der ZUTEILUNG -- "ist Leitung? dann alles".

NICHT GELESEN, SONDERN GEMESSEN
server/pruef-manager-sicht.mjs baut zwei Managerinnen mit vollstaendig
getrennten Creators. Bei der fremden heisst ALLES "GEHEIM..." -- Aufgabe,
Termin, Bereichseintrag, Datei, Steckbrief, Content-Saeule. Danach wird
jede der 31 Leseschnittstellen abgefragt und die ganze Antwort danach
durchsucht. Ein Leck faellt damit auf, egal wo es sitzt und egal, ob ich
es beim Lesen uebersehen haette.

GEFUNDEN: DREIZEHN. Alle geschlossen:

  Kalender          fremde Fristen -- besonders unangenehm, weil es
                    nicht wie ein Leck aussieht: eine kleine orange
                    Marke mit einem Titel, in dem fremde Vorhaben stehen
  Personenauswahl   alle Namen im Zuweisungsfeld
  Dateien           alle Namen in der Freigabe-Auswahl
  Uebersicht        Gesamtuebersicht ueber ALLE Creator
  Report            Auswahl UND Auswertung ueber den ganzen Bestand
  Start-Check       alle Creator zur Auswahl
  Steckbriefe       Bild, Kanaele, "ueber mich" von allen
  Profile           alle Profile, samt interner Notiz
  Schulung          Schulungsstand aller Creator
  Suche             Creator-Profile aller -- die unauffaelligste Stelle:
                    Man sucht etwas anderes und bekommt fremde Namen
  Content-Balance   Themensaeulen fremder Kanaele (die Abfrage daneben
                    war korrekt eingeschraenkt, DIESE hatte eine eigene
                    Bedingung)
  darfCreator       eine einzige Zeile -- sie hing an Profil,
                    Start-Check und Uebersicht gleichzeitig. Es reichte,
                    eine Nummer in die Adresse zu schreiben.

Die Antwort steht jetzt an EINER Stelle: sichtbareCreatorIds und
sichtbarePersonenIds in workspace.js. Rueckgabe null heisst "alle" und
gilt allein DogFather -- bewusst kein leeres Feld: Eine leere Liste
bedeutet "niemand", und die Verwechslung der beiden macht aus einer
Sperre eine Freigabe.

ZWEI DINGE, DIE ICH MIR SELBST NACHTRAGEN MUSS

1. Beim Stopfen fehlte einmal ein Import. Der Weg warf einen Fehler,
   antwortete 503 -- und weil in einer Fehlermeldung kein "GEHEIM" steht,
   meldete die Pruefung "kein Leck". Sie war gruen, weil der Weg KAPUTT
   war. Die Pruefung zaehlt jetzt beides: nichts durchsickern UND
   antworten.

2. Ein Fehlalarm: Die Suche gibt den SUCHBEGRIFF in ihrer Antwort
   zurueck. Wer nach "GEHEIM" sucht, findet das Wort zwangslaeufig --
   auch bei null Treffern. Ich haette um ein Haar ein Leck "repariert",
   das es nie gab. Das Echo wird jetzt entfernt, bevor gemessen wird.

FOLGEN, bewusst in Kauf genommen:
  * Ein Manager ohne Zuteilung sieht keinen Creator. Die Uebersicht sagt
    ihm das jetzt in einem Satz, statt leer zu bleiben.
  * Er kann nur noch IN SEINEN Creator-Bereichen schreiben (darfCreator).

ZWEI PRUEFUNGEN UMGEDREHT statt geloescht -- eine geloeschte Pruefung
hinterlaesst keine Spur davon, dass hier einmal etwas anderes galt:
pruef-uebersicht ("Manager sieht dasselbe" -> "nur seine zugeteilten",
mit beiden Faellen) und pruef-scout-zuteilung ("sieht die ganze
Personenliste" -> "landet auf der Startseite").

GEPRUEFT: 43 neue Pruefungen, dazu 23 bestehende Laeufe gruen --
Startansicht 133, Rollen 97, Kalender 84, Serien 67, Steckbrief 65,
Handy 50, Sicht 48, Ampel 47, Content 45, Aufgabenbrett 44, Schulung 41,
Bereiche 37, Scout-Zuteilung 36, Uebersicht 35, Personenliste 33,
Freie Namen 32, Team 30, Protokoll-Loeschen 20, Personenformular 20,
Formulare 19, Betreuung 18, Code 17, Grosscheck 15.

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

2026-09-03 01:01:00 +02:00

DogFatherGitandClaude Opus 5

5960f6e3c4

Unterweisungen mit beidseitiger Bestaetigung - und einer echten Sperre

Der Wunsch: "jeder Scout, Manager oder DogFather muss mit seinen
Creatorn die PDFs durchgehen, und beide druecken dann auf verifiziert,
so dass wir den Beweis haben -- und das ist danach auch nicht mehr zu
aendern."

Das ist kein Haekchen, das ist ein NACHWEIS. Wer so etwas baut, muss
drei Fragen beantworten, sonst ist er wertlos:

WER hat bestaetigt? Beide Seiten getrennt, mit Name, Zeitpunkt und IP.
Eine einzelne Bestaetigung reicht nicht -- "ich habe es ihm gezeigt" und
"er hat es mir gezeigt" sind zwei verschiedene Aussagen, und erst
zusammen ergeben sie einen Beweis. Bestaetigt nur einer, steht die
Unterweisung sichtbar als HALB da, in einer eigenen warnenden Farbe.
Diese Zwischenstufe sichtbar zu machen ist der Punkt: Ein Nachweis, bei
dem nur einer unterschrieben hat, sieht sonst aus wie fertig -- und man
merkt es erst, wenn jemand danach fragt.

WORAUF genau? Nicht auf "die Regeln", sondern auf eine bestimmte Datei.
Beim Bestaetigen wird der SHA-256 der PDF-Datei mitgespeichert. Tauscht
spaeter jemand die Datei aus, passt der Fingerabdruck nicht mehr, und
die Seite sagt das auch ("Das Dokument wurde seit der Bestaetigung
ausgetauscht"). Ohne diesen Wert waere die Bestaetigung ein Zettel ohne
Bezug.

IST ES UNVERAENDERT? Eine abgeschlossene Bestaetigung laesst sich nicht
mehr aendern und nicht loeschen -- und zwar nicht, weil der Code es
nicht anbietet, sondern weil die DATENBANK es ablehnt. Zwei Trigger mit
RAISE(ABORT). Ein Schutz, der nur im Code steht, ist beim naechsten
neuen Weg zur Datenbank wieder weg.

DER VOLLZUG WURDE DURCHGESPIELT. Aus RunOne stammt die Lehre, dass ein
Weg, den man nicht rueckgaengig machen kann, tagelang live sein und NIE
gelaufen sein kann. Die Pruefung bestaetigt deshalb wirklich, schliesst
ab, und versucht dann eine Aenderung -- ueber die Schnittstelle UND
direkt auf der Datenbank. Beide werden abgelehnt.

Und die GEGENPROBE dazu: Der Trigger wird entfernt, dieselbe Aenderung
versucht -- sie geht durch -- und der Trigger wieder gesetzt. Eine
Sperre, die man nicht hat scheitern sehen, ist keine Sperre.

Der Server entscheidet anhand der ROLLE, welche Seite gesetzt wird --
nicht der Absender. Sonst koennte ein Creator die Bestaetigung seines
Betreuers eintragen, und der ganze Nachweis waere wertlos. Eine bereits
gesetzte Seite wird nie ueberschrieben; ein Datum laesst sich also auch
nicht nachtraeglich verschieben.

Die Dokumente kommen aus der Wissens-Bibliothek, es gibt keinen zweiten
Upload-Weg. Sonst gaebe es Dateien, die nur hier existieren -- und
niemand wuesste, welche Fassung die richtige ist. Eine Unterweisung wird
nie geloescht, nur abgeschaltet: Die Nachweise haengen daran.

EIN EIGENER FEHLER, VON DER BROWSERPRUEFUNG GEFUNDEN: Der Aufruf der
Zusatzbloecke stand NACH einem return. laden() steigt frueh aus, wenn
die Liste leer ist -- und dann wurden Vorlagen und Unterweisungen nie
gebaut. Also ausgerechnet auf der leeren Seite, fuer die sie gedacht
sind. Jetzt stehen sie in einem finally.

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

2026-09-01 16:39:00 +02:00