2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	372a0eb95a	Ampel und Rueckmeldungen - bewerten darf nur die Betreuung ... Der Wunsch: "der Creator sieht, ob es gut ist oder schlecht. Und wenn nicht gut, dann muss es verbessert werden -- und nur der Ansprechpartner kann das aendern. Die Creator koennen nur Nachrichten hinterlassen zum Kommunizieren." ZWEI GETRENNTE DINGE, und sie getrennt zu halten ist der ganze Punkt: DIE AMPEL ist eine Beurteilung. Sie gehoert dem Betreuer, und nur er setzt sie. Koennte ein Creator sich selbst auf gruen stellen, waere sie wertlos -- dann stuende ueberall gruen. Der Server lehnt es mit 403 ab und sagt dabei, wer es kann. DIE NACHRICHT ist ein Gespraech. Sie gehoert beiden. Ein Creator, der auf eine Bewertung nicht antworten kann, bekommt ein Urteil statt einer Betreuung. DREI STUFEN, NICHT FUENF. Eine Zahl von 1 bis 5 klingt genauer und ist es nicht: Niemand kann den Unterschied zwischen 3 und 4 erklaeren, und am Ende steht ueberall die 3. Die Frage lautet "reicht das schon?", und darauf gibt es drei ehrliche Antworten -- passt so, noch verbessern, noch nicht angesehen. "NOCH VERBESSERN" VERLANGT EINE BEGRUENDUNG. Eine Bewertung, mit der der Creator nichts anfangen kann, ist nicht streng, sondern nur entmutigend. Der Server lehnt sie ohne Grund ab; die Oberflaeche fragt deshalb gleich danach, statt hinterher eine Fehlermeldung zu zeigen. "Passt so" braucht keinen -- da gibt es nichts zu erklaeren. Die Stufe steht IMMER an der Karte, auch fuer den Creator, auch wenn sie "noch nicht angesehen" lautet. Er soll sehen, wo er steht, ohne fragen zu muessen. Der Grund steht daneben in voller Breite, nicht in einer Ecke. FREMDE NACHRICHTEN BLEIBEN STEHEN -- auch fuer DogFather. Ein Gespraech nachtraeglich umzuschreiben waere schlimmer, als eine unbedachte Aeusserung stehen zu lassen. Wer etwas richtigstellen will, schreibt eine neue. VORLAGEN AUCH FUER COMMUNITY UND TECHNIK (Screens 11 und 12): 14 Moderations-, Aktions- und Konfliktpunkte, 12 Technikpunkte. Ton steht vorn, weil schlechter Ton der Grund Nummer eins ist, warum Leute einen Stream verlassen. Die drei Bereiche laufen jetzt ueber EINE Zuordnung statt drei fast gleicher Bloecke -- sonst weicht der dritte irgendwann ab. Die beiden alten Zweige wurden entfernt: Toter Code, den man stehen laesst, wird beim naechsten Mal fuer lebenden gehalten. Die Ampeln einer ganzen Liste kommen in EINER Abfrage. Zwanzig Eintraege einzeln zu fragen waeren zwanzig Anfragen, und die Seite ruckelte sichtbar beim Aufbau. Die Sichtbarkeitspruefung laeuft dabei je Eintrag, nicht einmal pauschal -- ein fremder Eintrag taucht auch in der Sammelabfrage nicht auf. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-01 16:49:56 +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