dogfather-universe

515 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	ca10479909	Fertige Vorlagen zum Uebernehmen - Content-Ideen und LIVE-Punkte Der Wunsch stand an fuenf Stellen gleichlautend: "ich will dass da schon fertige Sachen stehen". Eine leere Seite mit einem Knopf "Neuer Eintrag" verlangt vom Creator genau das, was er noch nicht kann -- zu wissen, was ueberhaupt hineingehoert. WARUM VORLAGEN UND KEINE VORAUSGEFUELLTEN DATEN. Man koennte beim Anlegen eines Creators dreissig Eintraege in seine Datenbank schreiben. Das waere falsch: Sie waeren ab dem ersten Tag "seine" Eintraege und damit Altlast; aendert Filipe spaeter eine Formulierung, gilt sie nur fuer neue Creator; und die Liste saehe voll aus, obwohl noch nichts geschehen ist -- das Gegenteil einer ehrlichen Uebersicht. Vorlagen bleiben deshalb VORSCHLAEGE, bis jemand sie uebernimmt. Sie stehen im Code, gelten fuer alle sofort, und werden erst dann zu Daten, wenn sie gebraucht werden. Was uebernommen ist, ist ein ganz normaler Eintrag -- aenderbar, loeschbar, und von spaeteren Aenderungen an der Vorlage unberuehrt. INHALTE, fachlich begruendet: 13 Content-Ideen, jede mit AUSFORMULIERTEM Aufhaenger und Format. Die ersten ein bis drei Sekunden entscheiden ueber die Verbreitung -- "mach was Persoenliches" hilft niemandem, "Das haette ich am Anfang gern gewusst" kann man sagen. Verteilt nach 70/20/10 (Wert, Community, Eigenwerbung). 21 LIVE-Punkte in drei Abschnitten. Der mittlere ist der wichtigste und gibt es sonst nirgends: Was WAEHREND der Sendung auffaellt, ist am naechsten Tag weg. Diese Punkte sind so formuliert, dass man sie in einem Moment anklicken kann, in dem man eigentlich keine Zeit hat. Die Vorbereitung ist die laengste Liste, weil ein LIVE dort steht und faellt. Ton zuerst -- der Grund Nummer eins, warum Leute wieder gehen. "ICH BRAUCHE HILFE" wird eine AUFGABE, keine Nachricht. Eine Nachricht ist gelesen und dann weg; eine Aufgabe bleibt stehen, bis sie jemand erledigt, geht an den zustaendigen Betreuer (ohne Betreuer an die Leitung -- eine Bitte um Hilfe darf nicht ins Leere laufen), traegt hohe Prioritaet und eine Frist von drei Tagen. Ohne Frist bleibt sie liegen; das ist der Unterschied zwischen einer Aufgabe und einem Zettel. "CONTENT-PLANUNG" HEISST JETZT "CONTENT-IDEEN". "Planung" klang nach Terminen und Tabellen; was dort wirklich passiert, ist das Sammeln und Weiterentwickeln von Ideen. Der Kalender daneben plant. EIN CREATOR DARF SEINE EIGENEN EINTRAEGE AENDERN -- aber nur im Bereich Content. Wenn er sich eine Idee uebernimmt, ist das SEINE Idee; sie danach nicht umbenennen zu duerfen waere absurd. LIVE, Technik, Community und Schutz bleiben die Betreuungsakte, dort aendert er nichts. Ein erster Anlauf hatte die Ausnahme fuer alle Bereiche erlaubt -- die Pruefung pruef-bereiche-lesend hat das sofort gemeldet. DREI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN: - Der Vorlagenblock vergass nach dem Uebernehmen, was schon geholt war: Die Liste wird neu geladen, der Block neu gebaut, und die Markierung am Element war jedes Mal weg. Jetzt merkt sich das Modul die Auswahl. - Die Regel fuer eigene Eintraege war zu breit (siehe oben). - Die Marken im Vorlagenblock waren auf dem Handy 10,2 px klein. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-01 16:27:30 +02:00
DogFatherGitandClaude Opus 5	2bebab156b	Profilbild gebaendigt, Steckbrief von der Creator-Akte getrennt ZWEI FEHLER, DIE FILIPE GESEHEN HAT. 1. DAS PROFILBILD LAG UEBER DER HALBEN SEITE. Als Patrick sein Bild hochlud, zog sich ein roter Balken quer ueber die Startseite. Ursache: Die CSS-Regel .wer__bild hat GEFEHLT. Das Element wurde in kopf.js erzeugt, die Regel dazu nie geschrieben -- und ein <img> ohne Groessenangabe nimmt seine natuerliche Groesse an, bei einem Handyfoto also mehrere tausend Pixel. Dazu fehlte overflow: hidden am Traeger. WARUM KEINE PRUEFUNG DAS GEFUNDEN HAT: Sie lud ein 1x1-Pixel-PNG hoch. Klein, schnell, von Hand gebaut -- und voellig unfaehig, irgendetwas zu ueberdecken. Die Pruefung war gruen, der Fehler war da, und gesehen hat ihn der Nutzer. Sie arbeitet jetzt mit einem 1200x1200-Bild, also in der Groesse, die wirklich hochgeladen wird, und misst danach: Bleibt das Bild in seinem 28-px-Feld, ragt es irgendwo heraus, laeuft die Seite ueber. Gegenprobe gemacht -- ohne die Regel meldet sie 1200x1200 in 28x28 und 918 px Ueberlauf. 2. ZWEI PERSONEN AUF EINEM BILDSCHIRM. Auf der Profilseite stand oben "Profil: SpongBobSchwammKopf" und mittendrin "MEIN PROFIL: Dogfather". Niemand konnte sagen, welche Angabe zu wem gehoert. Es sind auch wirklich zwei verschiedene Dinge: MEIN STECKBRIEF gehoert MIR -- Bild, ein Satz ueber mich, meine Kanaele. Fuehre ich selbst. CREATOR-PROFILE die BETREUUNGSAKTE eines anderen Menschen -- Ziele, 90-Tage-Plan, interne Notizen. Fuehren die Betreuer. Scouts, Manager und DogFather haben jetzt zwei getrennte Kacheln und eine eigene Seite (steckbrief.html, serverseitig geschuetzt). Ein Creator behaelt beides zusammen -- er hat nur eine Seite und sieht dort ausschliesslich sich selbst. Die Logik liegt in einer eigenen Datei statt hinten an profil.js: Sie gehoert der angemeldeten Person, nicht der Akte. ACHTZEHN KACHELN, ACHTZEHN FARBEN. Die neue Kachel haette sich ihren Farbton mit den Creator-Profilen geteilt -- zwei Nachbarn in derselben Farbe. Statt eine Farbe dazuzuerfinden, wurde tools/kachel-farben.mjs fuer 18 Winkel neu gerechnet, samt der neuen Nachbarschaft im Raster. Der kleinste Abstand zweier Nachbarn liegt weiterhin bei 100 Grad. Gefunden hat das die Startseitenpruefung ("17 Farben auf 18 Kacheln"). Die Trennung wird jetzt fuer JEDE Rolle geprueft: welche Kacheln sie sieht, dass auf der Akte kein fremder Steckbrief steht, und dass die eigene Seite die richtige Person zeigt. Eine alte Pruefung, die das Gegenteil verlangte, wurde ersetzt statt stehen gelassen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-01 15:04:23 +02:00
DogFatherGitandClaude Opus 5	1fe443e59c	Handy durchgeprueft, Lichtfarbe je Kachel, haengendes Licht behoben DAS LICHT BLIEB HAENGEN -- vier Ursachen, jede einzeln behoben: 1. EIN WETTLAUF. Zwischen dem Anmelden eines Bildaufbaus und seinem Ablauf konnte der Zeiger die Karte laengst verlassen haben. Dann hatte pointerout schon aufgeraeumt, und der Bildaufbau schaltete das Licht gleich wieder AN. Der haeufigste Fall und der unauffaelligste. 2. UEBER EINE LUECKE VERLASSEN. Wer eine Karte nicht ueber eine Nachbarkarte verliess, sondern ueber den Zwischenraum, loeste kein Ereignis aus, das die alte Karte kannte. 3. GESCROLLT, OHNE DIE MAUS ZU BEWEGEN. Die Karte wandert unter dem stehenden Zeiger weg -- es kommt gar kein Zeigerereignis. Jetzt wird beim Scrollen nachgesehen, ob die beleuchtete Karte noch unter dem Zeiger liegt. 4. FENSTER ODER TAB VERLASSEN. Auch dort kommt nichts mehr. Es gibt jetzt genau EINE beleuchtete Karte -- mehr kann es nicht geben, es gibt ja nur einen Zeiger. Beim Wechsel geht die alte aus, bevor die neue angeht. DIE FARBE GEHOERT ZUR KACHEL. Auf der Wissensseite leuchteten alle sechs Welten violett, weil die Farbe dort --w heisst und der ganze uebrige Workspace --ton benutzt. Das Licht griff auf --ton zu, fand nichts und nahm den Farbton der SEITE. Dieselbe Luecke bei den Aufgaben-Spalten (--sfarbe), den Kalenderkarten (--afarbe) und den Kalenderzeilen (--zfarbe). Alle vier setzen jetzt --ton mit. Nachgewiesen an echten Bildpunkten, nicht am Quelltext: Der Zeiger wird auf die Aufgaben-Kachel gesetzt (dort muss Rot ueberwiegen: 85 zu 22) und auf die Kalender-Kachel (dort Blau: 71 zu 13). Ein Zeichenkettenvergleich haette das nicht gekonnt -- der Browser rechnet color-mix() aus und schreibt je nach Fassung rgb(), color() oder oklab() zurueck. DAS HANDY, komplett durchgeprueft: neue pruef-handy.mjs faehrt alle fuenfzehn Seiten auf DREI echten Geraetegroessen ab (320 px iPhone SE, 390 px iPhone, 412 px Android) und misst fuenf Dinge, die am Rechner unsichtbar sind. Gefunden und behoben: * ZWEI ECHTE UEBERLAEUFE (startcheck +27 px, automation +33 px). Die Seite liess sich waagerecht schieben -- auf einem Telefon der schlimmste Fehler. Ursachen: zwoelf Raster mit festem Mindestmass (minmax(280px, 1fr) kann nicht schrumpfen -> min(280px, 100%)), zwoelf feste Mindestbreiten an Auswahlfeldern, und ein "flex: none" an den Stufen-Knoepfen, das jedes Schrumpfen verbot. "width: 100%" allein reichte dort nicht. * BERUEHRZIELE unter 24 px (WCAG 2.2, Kriterium 2.5.8). Auswahlfelder waren 18 bis 22 px hoch. Jetzt 44 px -- die Empfehlung von Apple und Google, und der Daumen ist nun einmal breiter als ein Mauszeiger. Nebenbei behebt die Schriftgroesse 16 px das Hineinzoomen von iOS. * SCHRIFT unter 11,7 px an 52 Stellen. Gesucht wurden sie nicht von Hand -- das waere ein Ratespiel gewesen und haette die Haelfte uebersehen -- sondern durch Durchsuchen der Stildateien nach font-size unter 0,73rem. ZWEI FEHLER IN DEN EIGENEN PRUEFUNGEN gefunden und behoben: Die Schriftregel griff zuerst gar nicht (start.css wird VOR den Seitenstilen geladen, bei gleicher Staerke gewinnt die spaetere -- jetzt mit body.start qualifiziert), und die Lichtpruefung scrollte 600 px und stellte nicht zurueck, sodass die folgende Pruefung ins Leere zeigte. GEGENPROBE gemacht: Mit absichtlich eingebauten Fehlern (8-px-Schrift, 500 px breiter Inhalt) meldet die Handypruefung sofort Rot. Eine Pruefung, die immer bestaetigt, bestaetigt nichts. Alle achtzehn Pruefungen laufen gruen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-01 14:48:48 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

ca10479909

Fertige Vorlagen zum Uebernehmen - Content-Ideen und LIVE-Punkte

Der Wunsch stand an fuenf Stellen gleichlautend: "ich will dass da schon
fertige Sachen stehen". Eine leere Seite mit einem Knopf "Neuer Eintrag"
verlangt vom Creator genau das, was er noch nicht kann -- zu wissen, was
ueberhaupt hineingehoert.

WARUM VORLAGEN UND KEINE VORAUSGEFUELLTEN DATEN. Man koennte beim
Anlegen eines Creators dreissig Eintraege in seine Datenbank schreiben.
Das waere falsch: Sie waeren ab dem ersten Tag "seine" Eintraege und
damit Altlast; aendert Filipe spaeter eine Formulierung, gilt sie nur
fuer neue Creator; und die Liste saehe voll aus, obwohl noch nichts
geschehen ist -- das Gegenteil einer ehrlichen Uebersicht.

Vorlagen bleiben deshalb VORSCHLAEGE, bis jemand sie uebernimmt. Sie
stehen im Code, gelten fuer alle sofort, und werden erst dann zu Daten,
wenn sie gebraucht werden. Was uebernommen ist, ist ein ganz normaler
Eintrag -- aenderbar, loeschbar, und von spaeteren Aenderungen an der
Vorlage unberuehrt.

INHALTE, fachlich begruendet:
  13 Content-Ideen, jede mit AUSFORMULIERTEM Aufhaenger und Format. Die
  ersten ein bis drei Sekunden entscheiden ueber die Verbreitung --
  "mach was Persoenliches" hilft niemandem, "Das haette ich am Anfang
  gern gewusst" kann man sagen. Verteilt nach 70/20/10 (Wert, Community,
  Eigenwerbung).

  21 LIVE-Punkte in drei Abschnitten. Der mittlere ist der wichtigste
  und gibt es sonst nirgends: Was WAEHREND der Sendung auffaellt, ist am
  naechsten Tag weg. Diese Punkte sind so formuliert, dass man sie in
  einem Moment anklicken kann, in dem man eigentlich keine Zeit hat.

  Die Vorbereitung ist die laengste Liste, weil ein LIVE dort steht und
  faellt. Ton zuerst -- der Grund Nummer eins, warum Leute wieder gehen.

"ICH BRAUCHE HILFE" wird eine AUFGABE, keine Nachricht. Eine Nachricht
ist gelesen und dann weg; eine Aufgabe bleibt stehen, bis sie jemand
erledigt, geht an den zustaendigen Betreuer (ohne Betreuer an die
Leitung -- eine Bitte um Hilfe darf nicht ins Leere laufen), traegt hohe
Prioritaet und eine Frist von drei Tagen. Ohne Frist bleibt sie liegen;
das ist der Unterschied zwischen einer Aufgabe und einem Zettel.

"CONTENT-PLANUNG" HEISST JETZT "CONTENT-IDEEN". "Planung" klang nach
Terminen und Tabellen; was dort wirklich passiert, ist das Sammeln und
Weiterentwickeln von Ideen. Der Kalender daneben plant.

EIN CREATOR DARF SEINE EIGENEN EINTRAEGE AENDERN -- aber nur im Bereich
Content. Wenn er sich eine Idee uebernimmt, ist das SEINE Idee; sie
danach nicht umbenennen zu duerfen waere absurd. LIVE, Technik,
Community und Schutz bleiben die Betreuungsakte, dort aendert er nichts.
Ein erster Anlauf hatte die Ausnahme fuer alle Bereiche erlaubt -- die
Pruefung pruef-bereiche-lesend hat das sofort gemeldet.

DREI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN:
- Der Vorlagenblock vergass nach dem Uebernehmen, was schon geholt war:
  Die Liste wird neu geladen, der Block neu gebaut, und die Markierung
  am Element war jedes Mal weg. Jetzt merkt sich das Modul die Auswahl.
- Die Regel fuer eigene Eintraege war zu breit (siehe oben).
- Die Marken im Vorlagenblock waren auf dem Handy 10,2 px klein.

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

2026-09-01 16:27:30 +02:00

DogFatherGitandClaude Opus 5

2bebab156b

Profilbild gebaendigt, Steckbrief von der Creator-Akte getrennt

ZWEI FEHLER, DIE FILIPE GESEHEN HAT.

1. DAS PROFILBILD LAG UEBER DER HALBEN SEITE. Als Patrick sein Bild
   hochlud, zog sich ein roter Balken quer ueber die Startseite.

   Ursache: Die CSS-Regel .wer__bild hat GEFEHLT. Das Element wurde in
   kopf.js erzeugt, die Regel dazu nie geschrieben -- und ein <img> ohne
   Groessenangabe nimmt seine natuerliche Groesse an, bei einem Handyfoto
   also mehrere tausend Pixel. Dazu fehlte overflow: hidden am Traeger.

   WARUM KEINE PRUEFUNG DAS GEFUNDEN HAT: Sie lud ein 1x1-Pixel-PNG hoch.
   Klein, schnell, von Hand gebaut -- und voellig unfaehig, irgendetwas
   zu ueberdecken. Die Pruefung war gruen, der Fehler war da, und gesehen
   hat ihn der Nutzer. Sie arbeitet jetzt mit einem 1200x1200-Bild, also
   in der Groesse, die wirklich hochgeladen wird, und misst danach: Bleibt
   das Bild in seinem 28-px-Feld, ragt es irgendwo heraus, laeuft die
   Seite ueber. Gegenprobe gemacht -- ohne die Regel meldet sie
   1200x1200 in 28x28 und 918 px Ueberlauf.

2. ZWEI PERSONEN AUF EINEM BILDSCHIRM. Auf der Profilseite stand oben
   "Profil: SpongBobSchwammKopf" und mittendrin "MEIN PROFIL: Dogfather".
   Niemand konnte sagen, welche Angabe zu wem gehoert.

   Es sind auch wirklich zwei verschiedene Dinge:
     MEIN STECKBRIEF  gehoert MIR -- Bild, ein Satz ueber mich, meine
                      Kanaele. Fuehre ich selbst.
     CREATOR-PROFILE  die BETREUUNGSAKTE eines anderen Menschen --
                      Ziele, 90-Tage-Plan, interne Notizen. Fuehren die
                      Betreuer.

   Scouts, Manager und DogFather haben jetzt zwei getrennte Kacheln und
   eine eigene Seite (steckbrief.html, serverseitig geschuetzt). Ein
   Creator behaelt beides zusammen -- er hat nur eine Seite und sieht
   dort ausschliesslich sich selbst. Die Logik liegt in einer eigenen
   Datei statt hinten an profil.js: Sie gehoert der angemeldeten Person,
   nicht der Akte.

ACHTZEHN KACHELN, ACHTZEHN FARBEN. Die neue Kachel haette sich ihren
Farbton mit den Creator-Profilen geteilt -- zwei Nachbarn in derselben
Farbe. Statt eine Farbe dazuzuerfinden, wurde tools/kachel-farben.mjs
fuer 18 Winkel neu gerechnet, samt der neuen Nachbarschaft im Raster.
Der kleinste Abstand zweier Nachbarn liegt weiterhin bei 100 Grad.
Gefunden hat das die Startseitenpruefung ("17 Farben auf 18 Kacheln").

Die Trennung wird jetzt fuer JEDE Rolle geprueft: welche Kacheln sie
sieht, dass auf der Akte kein fremder Steckbrief steht, und dass die
eigene Seite die richtige Person zeigt. Eine alte Pruefung, die das
Gegenteil verlangte, wurde ersetzt statt stehen gelassen.

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

2026-09-01 15:04:23 +02:00

DogFatherGitandClaude Opus 5

1fe443e59c

Handy durchgeprueft, Lichtfarbe je Kachel, haengendes Licht behoben

DAS LICHT BLIEB HAENGEN -- vier Ursachen, jede einzeln behoben:

1. EIN WETTLAUF. Zwischen dem Anmelden eines Bildaufbaus und seinem
   Ablauf konnte der Zeiger die Karte laengst verlassen haben. Dann hatte
   pointerout schon aufgeraeumt, und der Bildaufbau schaltete das Licht
   gleich wieder AN. Der haeufigste Fall und der unauffaelligste.
2. UEBER EINE LUECKE VERLASSEN. Wer eine Karte nicht ueber eine
   Nachbarkarte verliess, sondern ueber den Zwischenraum, loeste kein
   Ereignis aus, das die alte Karte kannte.
3. GESCROLLT, OHNE DIE MAUS ZU BEWEGEN. Die Karte wandert unter dem
   stehenden Zeiger weg -- es kommt gar kein Zeigerereignis. Jetzt wird
   beim Scrollen nachgesehen, ob die beleuchtete Karte noch unter dem
   Zeiger liegt.
4. FENSTER ODER TAB VERLASSEN. Auch dort kommt nichts mehr.

Es gibt jetzt genau EINE beleuchtete Karte -- mehr kann es nicht geben,
es gibt ja nur einen Zeiger. Beim Wechsel geht die alte aus, bevor die
neue angeht.

DIE FARBE GEHOERT ZUR KACHEL. Auf der Wissensseite leuchteten alle sechs
Welten violett, weil die Farbe dort --w heisst und der ganze uebrige
Workspace --ton benutzt. Das Licht griff auf --ton zu, fand nichts und
nahm den Farbton der SEITE. Dieselbe Luecke bei den Aufgaben-Spalten
(--sfarbe), den Kalenderkarten (--afarbe) und den Kalenderzeilen
(--zfarbe). Alle vier setzen jetzt --ton mit.

Nachgewiesen an echten Bildpunkten, nicht am Quelltext: Der Zeiger wird
auf die Aufgaben-Kachel gesetzt (dort muss Rot ueberwiegen: 85 zu 22)
und auf die Kalender-Kachel (dort Blau: 71 zu 13). Ein
Zeichenkettenvergleich haette das nicht gekonnt -- der Browser rechnet
color-mix() aus und schreibt je nach Fassung rgb(), color() oder oklab()
zurueck.

DAS HANDY, komplett durchgeprueft: neue pruef-handy.mjs faehrt alle
fuenfzehn Seiten auf DREI echten Geraetegroessen ab (320 px iPhone SE,
390 px iPhone, 412 px Android) und misst fuenf Dinge, die am Rechner
unsichtbar sind. Gefunden und behoben:

  * ZWEI ECHTE UEBERLAEUFE (startcheck +27 px, automation +33 px). Die
    Seite liess sich waagerecht schieben -- auf einem Telefon der
    schlimmste Fehler. Ursachen: zwoelf Raster mit festem Mindestmass
    (minmax(280px, 1fr) kann nicht schrumpfen -> min(280px, 100%)),
    zwoelf feste Mindestbreiten an Auswahlfeldern, und ein "flex: none"
    an den Stufen-Knoepfen, das jedes Schrumpfen verbot. "width: 100%"
    allein reichte dort nicht.
  * BERUEHRZIELE unter 24 px (WCAG 2.2, Kriterium 2.5.8). Auswahlfelder
    waren 18 bis 22 px hoch. Jetzt 44 px -- die Empfehlung von Apple und
    Google, und der Daumen ist nun einmal breiter als ein Mauszeiger.
    Nebenbei behebt die Schriftgroesse 16 px das Hineinzoomen von iOS.
  * SCHRIFT unter 11,7 px an 52 Stellen. Gesucht wurden sie nicht von
    Hand -- das waere ein Ratespiel gewesen und haette die Haelfte
    uebersehen -- sondern durch Durchsuchen der Stildateien nach
    font-size unter 0,73rem.

ZWEI FEHLER IN DEN EIGENEN PRUEFUNGEN gefunden und behoben: Die
Schriftregel griff zuerst gar nicht (start.css wird VOR den Seitenstilen
geladen, bei gleicher Staerke gewinnt die spaetere -- jetzt mit
body.start qualifiziert), und die Lichtpruefung scrollte 600 px und
stellte nicht zurueck, sodass die folgende Pruefung ins Leere zeigte.

GEGENPROBE gemacht: Mit absichtlich eingebauten Fehlern (8-px-Schrift,
500 px breiter Inhalt) meldet die Handypruefung sofort Rot. Eine
Pruefung, die immer bestaetigt, bestaetigt nichts.

Alle achtzehn Pruefungen laufen gruen.

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

2026-09-01 14:48:48 +02:00