315eb08cc4c8e8adb2b1b276ae64414d2fe4e344
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
4a5c69cfc6 |
Die drei Altlasten: ein echter Befund, zwei Pruefungen mit Zahlen von gestern
Alle drei standen seit dem 22.09. in der Notiz und waren mit `git stash` als vorbestehend nachgewiesen. Nachgemessen, einzeln behoben. 1. pruef-jeder-hat-eine-seite -- EIN ECHTER BEFUND "alle 9 Rollen sind zugeordnet -- fehlt: linke" Die LINKE HAND fiel im Steckbrief in den Sammelplatz "Weitere": Auf der Uebersicht ueber die Menschen des Hauses stand sie unter einer Ueberschrift ohne Bedeutung, neben niemandem. Sie gehoert dorthin, wo die rechte Hand steht -- beide fuehren Team Dogi mit. Beim Nachgehen fiel dieselbe Luecke an einer zweiten Stelle auf: In ROLLEN_GRUPPE (der Auswahl, mit wem man schreiben kann) fehlte sie ebenfalls und haette eine eigene Ueberschrift mit genau einem Namen darunter bekommen -- also die Rangordnung, die zwei Zeilen hoeher ausdruecklich vermieden werden sollte. WARUM DIE PRUEFUNG DAS FINDEN KONNTE und ein Mensch nicht: Sie geht ALLE Rollen des Hauses durch, nicht die vier, die zufaellig angelegt sind. Eine Zuordnung, die man an den vorhandenen Leuten prueft, ist eine Aussage ueber die Testdaten. 2. pruef-rollen -- DIE MESSUNG WAR FALSCH, NICHT DIE KACHEL "DogFather Kachel https://crew... LANDET AUF start.html" DogFather bekommt auf der Agenturadresse die Kachel "Zu Team Dogi". Ihr Ziel MUSS eine vollstaendige Adresse sein -- das andere Haus liegt auf einem anderen Rechnernamen. Im Server steht das ausdruecklich (`aussen: true` an der Kachel, samt Begruendung). Die Pruefung klebte jedes Ziel an `BASIS + "/workspace/"`. Bei einer vollstaendigen Adresse kommt dabei Unsinn heraus. Sie kannte ausserdem nur ZWEI Ausgaenge. Ob die andere Tuer aufgeht, laesst sich von hier nicht sagen -- der Browser kennt nur BASIS. Das ist der dritte Ausgang, und er wird jetzt als solcher gemeldet: 314 Pruefungen, 0 Fehler, 1 nicht nachsehbar. Geprueft wird stattdessen, was hier zu pruefen IST: dass die Adresse zu einem Haus fuehrt, das dieses Haus kennt (aus CREW_ADRESSE, nicht abgeschrieben). 3. pruef-kachelraster -- ZWEI ZAHLEN VON GESTERN, UND EIN MESSFEHLER "10 Community-Kacheln" (erwartet 8) und "die doppelt breite Kachel steht an erster Stelle (Platz 0)" `=== 8` stand in der Ueberschrift, im Text und in der Bedingung. Am 22.09. sind Kacheln dazugekommen, und die Pruefung wurde rot, ohne dass am Raster etwas kaputt war. Schwerer wog der zweite Teil: Sie suchte "die Community-Gruppe" ueber deren Ueberschrift, mit der letzten Gruppe als Rueckfall. Fuer DogFather griff der Treffer (1 Kachel), fuer einen Modi der Rueckfall (10) -- und beides hiess in der Meldung "Community-Kacheln". Eine Pruefung, die je nach Rolle etwas anderes misst, kann ihr Ergebnis nicht erklaeren. Jetzt werden ALLE Gruppen gemessen, mit Namen in der Meldung, und die Frage ist ueberall dieselbe: Hat das Raster ein Loch? Die Kachelzahl steht in der Meldung, nicht in der Bedingung. Die Regel "eine doppelt breite Kachel steht vorn" bleibt -- es gibt heute keine solche Gruppe mehr, aber sie gilt fuer die naechste, und die ZAHL der geprueften Gruppen steht daneben. Gemessen sieht DogFather 5 Gruppen (1, 6, 11, 4, 1 Kacheln), ein Modi 6. Kein Loch in einer davon. 15 Pruefungen, 0 Fehler. Mitgelaufen und gruen: pruef-steckbrief, pruef-rechtetafel (19), pruef-chat. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
25de892fdb |
screen5: Aus dem Treff wird das Rudel, aus der Zentrale die IrrenAnstalt
Filipe, 22.09.2026: "ersetze die zentrale durch, Die IrrenAnstalt.
genau so geschrieben bitte. und alles was treff heißt oder wo treff
steht soll durch Rudel ersetzt werden bitte."
Die Schreibweise "IrrenAnstalt" mit grossem A in der Mitte ist so
gewollt. Das steht als Hinweis daneben, damit sie beim naechsten Mal
niemand "korrigiert".
WAS UMBENANNT WURDE: alles, was jemand LIEST -- Kachelnamen,
Ueberschriften, Markenzeilen, Saetze, Meldungen, Aufgabenvorlagen.
116 Zeilen in 42 Dateien.
WAS BLEIBT: Adressen (treff-regeln.html), Bezeichner (TREFF_ROLLEN),
Datenbankwerte (bereich = 'treff'), Abfrageteile (b=treff). Eine
Adresse umzubenennen bricht jedes Lesezeichen, und ein Datenbankwert
umzuschreiben waere eine Umstellung ohne Gegenwert. Dieselbe
Entscheidung wie heute frueh bei Dogi-Media, wo material.html auch
material.html geblieben ist.
DREI GRAMMATIKFEHLER IM EIGENEN ENTWURF, alle vor dem Ausliefern
gefunden -- ein blindes Ersetzen reicht hier nicht:
1. "der Treff" ist maennlich, "das Rudel" saechlich. Ohne Tabelle
waere ueberall "Der Rudel" gestanden. (Und "Treffer" waere zu
"Rudeler" geworden, "Treffen" zu "Rudelen" -- deshalb greift die
Regel nur bei Wortgrenze und nie vor einem Kleinbuchstaben.)
2. BINDESTRICH-ZUSAMMENSETZUNGEN. In "der Treff-Chat" gehoert der
Artikel zu "Chat", nicht zu "Treff". Der erste Durchlauf machte
daraus "das Rudel-Chat", "das Rudel-Kacheln" und "ein Rudel-Raum".
Jetzt greift die Artikelregel nur, wenn das Wort allein steht.
3. GESCHUETZTE LEERZEICHEN. In den Markenzeilen steht
`Der Treff`, damit die zwei Woerter nicht umbrechen. Das
Muster hat daran vorbeigegriffen: "Der Rudel", auf fuenf
Seiten. Jetzt wird das Trennzeichen mitgefasst und unveraendert
wieder eingesetzt.
Gefunden wurden alle drei, weil jede einzelne der 116 Zeilen vor dem
Schreiben als ALT/NEU ausgegeben und gelesen wurde -- und danach
gezielt nach falschen Artikeln gesucht ("den Rudel", "der Rudel",
"einen Rudel"). Uebrig blieben sechs Treffer, und die sind alle
richtig: "einen Rudel-Raum", "der Rudel-Chat", "den Rudel-Regeln" --
Zusammensetzungen, bei denen der Artikel zum letzten Wort gehoert.
UND ZWEI PRUEFUNGEN, die die Umbenennung nicht mitbekommen haetten:
`/Treff/.test(...)` und `/Treff/i.test(...)`. Ein regulaerer Ausdruck
ist keine Zeichenkette -- sie haetten ab sofort nach einem Wort
gesucht, das die Seite nicht mehr sagt, und waeren still rot geworden,
ohne dass etwas kaputt ist.
Geprueft, alle gruen: pruef-treff, pruef-treffchat,
pruef-deutsche-texte, pruef-uebernahme, pruef-crew-adresse,
pruef-willkommen, pruef-wege-nach-draussen, pruef-vorlagen,
pruef-start-ansicht, pruef-struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
63f2b2bc55 |
Jeder hat einen Steckbrief -- und die Kacheln stehen in der richtigen Reihenfolge
Filipe: "jeder soll ein steckbrief haben, jeder der ein account hat, rechte hand, modis und community, jeder soll genau wie ich foto und so hinzufuegen koennen." Und: "ich will das oben die sachen fuer dogfather sind, dan die sachen fuer modis und dan community bereich." 1. JEDER HAT EINEN STECKBRIEF. In rechte.js fehlte "gast" -- und damit ausgerechnet die groesste Gruppe. Die Seite selbst konnte es die ganze Zeit: `/mein` fragt nach der eigenen Nummer und kennt gar keine Rolle. Es fehlte nur die Tuer und die Kachel. DABEI EIN ZWEITER FUND, der schon laenger da war: In assets/js/steckbrief.js stand eine Liste aus drei Gruppen (Management, Scouting, Creator). Wer in keine passte, verschwand LAUTLOS aus der Uebersicht -- betroffen waren die rechte Hand und die Modis. Ein Modi, der die Seite oeffnete, sah seine eigenen Leute nicht. Kein Fehler, keine leere Liste, sie waren einfach nicht da. Die Zuordnung kommt jetzt vom Server (`abschnittFuer`). Damit kann sie nicht mehr veralten, und in der ausgelieferten Datei steht keine Liste von Rollennamen mehr -- was ohnehin Hausregel ist. Wer kuenftig vergessen wird, landet sichtbar unter "Weitere" statt zu verschwinden; die Gegenprobe dafuer steht in der Pruefung. "Wer hier mitarbeitet" heisst jetzt "Wer hier dabei ist" -- ein Mitglied arbeitet nicht mit, es schaut zu. 2. DIE REIHENFOLGE. Die Moderationskachel trug dieselbe Gruppe wie die sieben Bretter und landete deshalb HINTER ihnen: Wer moderiert, musste an der ganzen Community vorbeiscrollen. Sie hat jetzt eine eigene Gruppe und steht davor. ERST ZU VIEL GEMACHT, DANN KORRIGIERT: Mein erster Entwurf schrieb auch die Reihenfolge der Arbeitsgruppen fest. Die ist an mehreren Stellen bewusst gewaehlt und begruendet -- pruef-start-ansicht hat es sofort gemeldet, zu Recht. Jetzt wandern nur noch Moderation, Community und "Fuer dich" ans Ende; alles andere bleibt, wo es war. 3. ZWEI PRUEFUNGEN, DIE ZUFAELLIG GRUEN WAREN. pruef-kachelraster zaehlte Reihen ueber die Y-Koordinate und wartete feste 500 ms. Die Kacheln laufen aber gestaffelt ein -- mit einer Gruppe mehr war die Messung zu frueh und meldete vier Reihen, wo drei sind. Das Bildschirmfoto derselben Seite zeigte ein makelloses Raster. Jetzt misst sie mit `reducedMotion: reduce`, also den Endzustand. pruef-start-ansicht scrollte 600 px und nahm an, danach liege keine Kachel mehr unter dem Zeiger. Dieselbe Falle wie eine feste Umbruchschwelle: eine Rechnung von gestern. Sie fragt jetzt, was gemeint ist -- leuchtet die ALTE Kachel noch? GEMESSEN: pruef-jeder-hat-eine-seite (neu) 65 Pruefungen 0 Fehler, pruef-steckbrief, pruef-start-ansicht, pruef-kachelraster, pruef-community-sicht alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
299ef0d506 |
Eigenes Profil fuer jeden - mit Bild und Kanaelen
SCREEN 1: Jeder im Workspace hat jetzt seinen eigenen Steckbrief -- Creator, Scout, Manager und DogFather gleichermassen. Ein Bild, ein Satz ueber sich, und die Kanaele, auf denen er unterwegs ist. Er steht ganz oben auf profil.html, ueber der Creator-Akte; die ist etwas anderes (die fuehren die Betreuer, den Steckbrief fuehrt man selbst). Das Bild erscheint sofort ueberall: in der Kopfleiste jeder Seite und in der Begruessung. /api/ich liefert es deshalb gleich mit -- das spart auf jeder Seite eine zweite Abfrage und verhindert, dass die Plakette erst als Buchstabe erscheint und dann umspringt. Faellt das Bild aus, steht der Buchstabe da: Er wird nicht ersetzt, sondern liegt darunter. WARUM KEINE ECHTE TIKTOK-ANMELDUNG. "Mit TikTok verbinden" klingt nach OAuth. Das waere: ein Entwicklerkonto mit App-Freischaltung, eine Pruefung durch TikTok (Wochen, widerrufbar), je Person ein Zugriffstoken, das ablaeuft, erneuert werden muss und -- wenn es abhandenkommt -- fremden Zugriff auf ein fremdes Konto bedeutet. Dafuer bekaeme man Follower-Zahlen. Gebraucht wird hier aber "Wer ist das, und wo finde ich ihn?". Dafuer genuegt der oeffentliche Name. Gespeichert wird deshalb NUR das Handle -- kein Token, kein Passwort, nichts, was abhandenkommen kann. Daraus wird ein Verweis auf den Kanal. Vier Kanaele: TikTok, Instagram, YouTube, Twitch. Sollen spaeter echte Zahlen dazukommen, ist das ein eigenes Vorhaben -- der Name hier bleibt dann trotzdem richtig. Eingefuegt werden darf, was Leute wirklich in der Zwischenablage haben: "@name", "https://www.tiktok.com/@name" oder der Name allein. Alles wird auf den Namen zurueckgefuehrt, statt eine Fehlermeldung zu zeigen. SICHERHEIT beim Bild -- die drei Stellen, an denen Profilbilder typischerweise scheitern: 1. Der Typ wird an der SIGNATUR der Datei geprueft, nicht am Content-Type, den der Absender behauptet. Ein umbenanntes SVG mit Skript darin kaeme sonst durch und liefe im Namen der Domain -- mit der Sitzung des Betrachters. 2. Auf der Platte bekommt jede Datei einen Zufallsnamen. Kein Name kann Pfade verlassen oder etwas ueberschreiben. 3. Ausgeliefert mit nosniff und einer eigenen, alles verbietenden Inhaltsregel. Das Bild liegt als Datei neben der Datenbank, nicht darin: Bilder in SQLite blaehen jede Sicherung auf, und die laeuft jede Nacht. Niemand schreibt einem anderen ins Profil -- auch DogFather nicht. Ein Satz ueber sich und der eigene Kanalname gehoeren der Person. Wer wen SEHEN darf, folgt der bekannten Regel: Leitung alle, Scout seine Creator, Creator sich und seine Betreuer. Fremde Profile sind 404, nicht 403. ZWEI FUNDE DURCH DIE PRUEFUNG: - Der TikTok-Link, den die App beim Teilen kopiert, endet auf "?lang=de&is_from_webapp=1". Der wurde abgelehnt: "sieht nicht richtig aus" -- obwohl es der offizielle Link ist. Jetzt werden Parameter und Anker mit abgeschnitten. - Ein zu grosses Bild ergab "500 Serverfehler" statt einer Ansage. Der PayloadTooLargeError lief bis in die allgemeine Fehlerbehandlung durch. Jetzt 413 mit dem Satz, wie viel erlaubt ist. Von Hand haette das vermutlich nie jemand probiert. Vor der Schemaaenderung wurde eine geprueft vollstaendige Sicherung gezogen (VACUUM INTO, Integritaet ok, 6 Personen). Co-Authored-By: Claude Opus 5 <[email protected]> |