Rueckmeldung 22.08.2026 zur Anfrage-Detailansicht: "das ganze soll viel
uebersichtlicher sein und nicht so durcheinander" und "die leiste rechts
zum hoch und runter, kannst du die mal geil aussehen lassen anstatt
einfach so kake weiss."
1. DAS DURCHEINANDER HATTE EINE URSACHE
Die Kaesten standen in "columns: 2" -- Zeitungsspalten. Die fuellen sich
von selbst: erst Spalte eins bis oben voll, dann Spalte zwei. Wo ein
Kasten landet, haengt allein davon ab, wie lang die vor ihm sind. Bei
einer Anfrage stand "Interne Notizen" oben rechts, bei der naechsten
unten links. Es gab schlicht keine Ordnung, der man haette folgen koennen.
Jetzt ein festes Raster mit einer Aussage:
LINKS = was der Kunde geschickt hat (lesen)
RECHTS = was du damit machst (handeln)
Immer gleich. Nach der zweiten Anfrage weiss man, wo man hinschaut, ohne
zu suchen. Rechts ist schmaler (Knoepfe brauchen weniger Platz als
laufender Text) und klebt beim Scrollen mit -- die Handlungen sind der
Grund, warum man die Ansicht oeffnet, sie duerfen nicht aus dem Bild
wandern.
Reihenfolge rechts korrigiert: "Anfrage uebernehmen" steht jetzt oben.
Es ist der Knopf, den man bei einer neuen Anfrage druecken WILL -- er
stand unter den Notizen und damit ausserhalb des sichtbaren Bereichs.
2. "KEINE ANGABE" WAR DIE HALBE ANSICHT
Jede fehlende Angabe bekam eine eigene Zeile. Der Kasten "Umfang"
enthielt zweimal nichts und war trotzdem so gross wie einer mit Inhalt.
Leere Felder sind aber keine Information, sondern deren Fehlen. Sie
stehen jetzt als EINE leise Zeile am Fuss: "Ohne Angabe: Bereiche,
Funktionen". Aus sechs Zeilen wird eine. Weggelassen werden sie nicht --
man muss sehen, wonach gefragt wurde und was unbeantwortet blieb, genau
daraus entstehen die Rueckfragen.
Neu darueber: "Auf einen Blick" mit Paket, Budget, Wunschtermin und
Alter. Die vier Fragen, die man immer zuerst hat, standen vorher auf drei
Kaesten verteilt. Das Alter als "vor 3 Tagen" statt als Datum -- die
Frage ist nie "welcher Tag war das", sondern "wie lange liegt das schon
hier", und die beantwortet ein Datum erst nach Kopfrechnen.
3. BILDLAUFLEISTE -- und ein Fehler, der fast durchgegangen waere
Auf einer durchgehend dunklen Seite ist eine weisse Bildlaufleiste der
einzige grelle Streifen im Bild. Sie zieht den Blick dorthin, wo nichts
Wichtiges steht, und blendet. Verstoesst gegen die Dauervorgabe
"augenschonend".
Zwei Wege noetig, weil kein Browser beide versteht: color-scheme: dark
fuer Firefox/Safari (wirkt zusaetzlich auf Auswahl- und Datumsfelder, die
sonst weiss aufblitzen), ::-webkit-scrollbar fuer Chrome/Edge.
scrollbar-width/-color bewusst NICHT gesetzt -- sobald es dasteht,
ignoriert Chrome die feineren ::-webkit-Regeln.
Beim ersten Versuch stand dort nur ".wd ::-webkit-scrollbar" -- MIT
Leerzeichen. Das trifft nur Elemente INNERHALB der Seite, nicht den body
selbst. Alle Messungen sahen gut aus; an der einen Leiste, ueber die sich
jemand beschwert hatte, haette sich nichts geaendert. Jetzt beide
Fassungen, mit einem Warnhinweis im CSS.
GEPRUEFT
Neue Datei pruef-detail.mjs: echter Browser, 1440x900 und 390x844, mit
einer absichtlich sehr knappen Anfrage -- genau die sah vorher schlecht
aus. 20 Pruefungen, alle bestanden: Spalten nebeneinander bzw. auf dem
Handy untereinander, rechte schmaler als linke, keine Ueberlappung, kein
waagerechtes Schieben, nichts ragt aus dem Fenster, keine einzelne
"keine Angabe"-Zeile mehr, keine Fehler im Protokoll.
Die Bildlaufleiste liess sich nur in einem ECHTEN Browserfenster pruefen:
Headless-Chromium blendet Leisten grundsaetzlich ueber dem Inhalt ein und
meldet deshalb immer 0 px Breite. Mit sichtbarem Fenster gemessen: 12 px,
alle sechs Regeln vom Browser akzeptiert.
Versionsstempel auf allen 11 Seiten und Cache-Name des Service Workers
auf v3 -- sonst liefert der eigene Zwischenspeicher beim ersten Laden
weiter die alte Fassung aus.
Co-Authored-By: Claude Opus 5 <[email protected]>
Ein 'git add -A' hat 13 Bild-Sicherungskopien (.bak-*, zusammen 2,6 MB),
den lokalen Testserver und eine erzeugte package-lock.json mitgenommen.
Die package-lock.json war der schaedlichste Teil: Auf dem Server existiert
eine eigene, dort erzeugte Fassung. Eine versionierte Datei gleichen Namens
laesst 'git pull' abbrechen -- der Deploy stand sofort still.
Alle drei Muster stehen jetzt in .gitignore.
Erster von vier Schritten fuer zwei Wuensche vom 22.08.2026:
"wenn sie drauf druecken sollen sie auch sehen was ich schon gemacht habe
von dem was im plan war" und "die kunden sollen mir auch nachrichten
hinterlassen koennen".
DATENBANK (3 neue Tabellen, jetzt 18 insgesamt, Fremdschluessel geprueft)
wd_aufgaben -- die Punkte je Projekt. Drei Entscheidungen darin:
* "wer_dran" ist eine eigene Spalte, kein Text. Manche Punkte warten
auf den KUNDEN ("Texte liefern"), und genau die muessen ihm ins Auge
springen. Ohne diese Unterscheidung liest er die Liste als reinen
Fortschrittsbericht und uebersieht seinen eigenen Teil -- der
haeufigste Grund fuer Verzoegerungen ueberhaupt.
* "nicht_enthalten" bildet ab, was NICHT zum Umfang gehoert. Das ist
die haeufigste Streitfrage in jedem Projekt ("ich dachte, das ist
dabei"). Vorher sichtbar aufgeschrieben kostet es nichts, hinterher
kostet es Geld oder den Kunden.
* "kategorie" nutzt dieselben vier Abschnitte wie die Farben im Portal.
Damit bedeutet eine Farbe ueberall dasselbe statt nur huebsch zu sein.
wd_postfach -- Nachrichten OHNE Projektbezug. Bewusst eine EIGENE Tabelle:
wd_nachrichten hat projekt_id als NOT NULL, und SQLite kann das nicht
lockern, ohne die ganze Tabelle zu kopieren -- ein unnoetiges Risiko bei
echten Kundennachrichten. Die neue Tabelle hat ohnehin andere
Anforderungen (Anhaenge, Lesestatus in BEIDE Richtungen, optionaler Bezug
auf eine Aufgabe). Zwei klar getrennte Tabellen sind ehrlicher als eine,
die beides halb kann.
VORLAGEN (56 Punkte ueber 5 Pakete, davon 20 beim Kunden)
Bei jedem Projekt fuenfzehn Punkte von Hand einzutippen fuehrt
zuverlaessig dazu, dass es irgendwann niemand mehr macht -- und dann
steht der Kunde wieder vor der leeren Liste, die der Ausloeser war.
Die Punkte sind in der Sprache formuliert, in der ein KUNDE denkt:
"Aufbau der Seiten festlegen" statt "Informationsarchitektur", "Auf dem
Handy durchtesten" statt "Responsive QA". Er liest diese Liste -- sie
muss ihm etwas sagen, nicht mir.
Die Vorlagen wandern beim ersten Start in die Datenbank und sind ab dann
dort aenderbar. Bereits vorhandene werden NIE ueberschrieben: sonst waeren
von Hand angepasste Vorlagen nach dem naechsten Neustart weg, und niemand
kaeme auf die Idee, dass der Neustart schuld war.
Naechste Schritte: Server-Routen, Verwaltung, Portal.
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung 22.08.2026 mit Bildschirmfoto: "ich will das nicht so ich
will es viel viel viel besser und uebersichtlicher und schoener zentriert
in der mitte."
Berechtigt, und aus mehreren Gruenden. Eine seitlich eingeschobene Leiste
ist fuer so viel Inhalt das falsche Format:
* Der Blick springt beim Oeffnen nach rechts.
* Die Liste dahinter bleibt halb sichtbar und lenkt ab.
* Alles muss sich in eine schmale Spalte quetschen -- auf dem
Bildschirmfoto stand "keine Angabe" dadurch achtmal untereinander,
und die Abwesenheit von Information nahm mehr Platz ein als die
Information selbst.
Jetzt: mittig, 940px breit, zweispaltig ab Tablet. Der Blick bleibt, wo
er ist, und zusammengehoerende Angaben stehen nebeneinander.
Weitere Entscheidungen:
* Mauerwerk-Umbruch (columns) statt Raster. Die Abschnitte sind
unterschiedlich hoch; ein Raster haette grosse Luecken gerissen.
* Jeder Abschnitt bekommt eine eigene Flaeche statt nur einer Trennlinie.
* Die Kopfzeile klebt beim Scrollen oben fest. Bei einer langen Anfrage
weiss man sonst nach dem Scrollen nicht mehr, wessen Daten man liest.
* "keine Angabe" wird kleiner und blasser dargestellt. Es ist die
ABWESENHEIT einer Information und darf nicht aussehen wie eine.
* Die Oeffnen-Animation skaliert dezent aus der Mitte statt von rechts
hereinzufahren, und ist bei prefers-reduced-motion ganz aus.
9/9 Tests weiterhin gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
"wieso sehen die zahlen immer noch so scheisse aus?" -- zu Recht, und die
Ursache war nicht Geschmack, sondern ein Fehler. Nachgemessen sass die
Ziffer 15px NEBEN der Kreismitte.
Ursache: ".po-leer-punkt span" (fuer den Beschreibungstext) trifft auch
den Zahlen-Span und ist spezifischer (Klasse + Element) als
".po-leer-nr" (nur Klasse). Sie erzwang display:block, 14,4px Schrift und
23px Zeilenhoehe -- exakt die gemessenen Werte. Meine eigene
"line-height: 1"-Regel kam gar nicht zum Zug.
Das ist derselbe Spezifitaets-Fehler wie zuvor beim Hauptknopf (blaue
Schrift auf blauem Grund) und bei den Namen auf der Zugangswand. Dreimal
dieselbe Falle, deshalb steht die Begruendung jetzt ausfuehrlich im Code.
Behoben ueber :not(.po-leer-nr) an beiden Textregeln. Nachgemessen:
Versatz waagerecht -15px -> 0px
Versatz senkrecht -8px -> -1,3px
display block -> grid
Schrift/Zeile 14,4/23px -> 18,4/18,4px
Zweite Rueckmeldung: "es soll 4 farben geben wie 4 kategorien zum
prozess". Sehr gute Idee -- sie macht das System erst schluessig. Die
sieben Phasen sind in Wahrheit vier Abschnitte, und die vier
Merkmalskacheln trugen ohnehin schon vier Farben. Jetzt bedeuten diese
Farben ueberall dasselbe:
1 Blau Start Briefing, Angebot
2 Lila Gestaltung Design
3 Gruen Umsetzung Entwicklung, Tests
4 Gold Abschluss Abnahme, Uebergabe
Die Phasenleiste faerbt erledigte Abschnitte in IHRER Farbe statt
pauschal gruen -- man sieht dadurch, wie weit man ist, nicht nur DASS
etwas fertig ist. Die Vorschau laeuft in denselben Farben durch. Die
Legende nennt die vier Abschnitte beim Namen, damit Farbe nicht geraten
werden muss: Farbe allein ist nie Information.
45/45 Handy-Abnahme, i18n vollstaendig.
Co-Authored-By: Claude Opus 5 <[email protected]>
Drei Rueckmeldungen vom 22.08.2026, alle drei berechtigt.
1) "die kisten sollen auch eine spezielle farbe bekommen wenn sie fertig
sind" -- das war inhaltlich der wichtigste Punkt. Vorher sahen
erledigte und gerade laufende Phase fast gleich blau aus. Damit ging
die einzige Aussage verloren, die die Leiste ueberhaupt traegt:
naemlich WO man steht. Jetzt drei klar getrennte Zustaende:
erledigt gruen, ruhig
laeuft grad leuchtendes Blau mit langsamem Puls
kommt noch gedaempft
Die Vorschau erklaert die Logik gleich mit: ihre Leiste wandert von
blau nach gruen, statt nur an- und auszugehen.
Dazu eine Legende in Worten. Farbe allein ist nie Information -- wer
sie nicht unterscheiden kann, liest hier trotzdem, was sie bedeutet.
2) "die zahlen sollen besser im kreis sein" -- vorher ein flacher Kreis
mit Zahl. Jetzt ein doppelter Ring: aussen ein Farbverlauf als Rand,
innen die dunkle Flaeche, dazu ein weicher Schein. Derselbe Kniff wie
bei den Karten (Verlauf ueber border-box); der Kreis wirkt dadurch
plastisch statt aufgemalt. Jede der vier Kacheln hat ihre eigene
Farbe -- vier gleiche Kacheln wirken wie eine Aufzaehlung, vier
unterscheidbare wie ein System.
3) "schrift soll spezieller sein" -- die Kachel-Ueberschrift war so gross
wie der Text darunter und ging unter. Jetzt groesser, in der
Headline-Schrift, enger gesetzt mit leicht negativer Laufweite. Die
Ueberschrift "Gleich geht es los" bekommt einen Farbverlauf.
45/45 Handy-Abnahme, i18n vollstaendig, prefers-reduced-motion beachtet.
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung 22.08.2026 mit Bildschirmfoto: "dass muss noch viel
spezieller, krasser und geiler sein, nicht so einfach".
Der Kern des Problems war nicht die Optik, sondern die Haltung: Die Seite
BESCHRIEB, was hier bald stehen wird ("Eine Leiste zeigt dir, in welcher
Phase dein Projekt ist"). Beschreibungen sind schwach -- man muss sie
lesen und sich dann etwas vorstellen.
Jetzt steht dort eine echte, als Vorschau gekennzeichnete Projektkarte:
Projektnummer, Titel, eine Phasenleiste, die langsam durchlaeuft, die
Marke "Dogfather ist dran" und ein naechster Schritt. Man sieht in zwei
Sekunden, was drei Saetze nicht erklaeren.
Die Karte ist bewusst als Vorschau erkennbar -- gestrichelter Rand,
Etikett oben rechts, gedaempfte Schrift, Nummer P-0000-0000. Sie darf nie
mit einem echten Projekt verwechselt werden.
Dazu ein sehr langsamer Lichtstreifen, der einmal durchwandert. Er sagt
ohne Worte "hier passiert gleich etwas", ohne zu blinken oder zu zappeln
-- augenschonend bleibt Dauervorgabe.
Bei prefers-reduced-motion laeuft nichts, aber die Phasenleiste zeigt
trotzdem drei erledigte Phasen. Ohne das staende dort eine leere graue
Reihe und die Vorschau erklaerte gar nichts mehr -- ein abgeschaltetes
Element muss trotzdem noch seine Aussage transportieren.
45/45 Handy-Abnahme, i18n vollstaendig.
Co-Authored-By: Claude Opus 5 <[email protected]>
Der wichtigste Handgriff im ganzen Bereich -- und der Weg, den man bei
JEDEM echten Kunden geht. Bisher haette man Name, E-Mail, Paket und
Wunschtermin von Hand in die Kundenmaske abgetippt: vier Gelegenheiten
fuer einen Tippfehler, und einer davon ist spaeter nicht mehr
korrigierbar, weil die E-Mail gleichzeitig der Anmeldename ist.
Jetzt steht in der Anfrage-Detailansicht eine Uebernahme mit Vorschau
(Kunde, E-Mail, Projekttitel, Sprache) und einem optionalen Preisfeld,
das die 30 % Anzahlung beim Tippen mitrechnet. Ein Klick legt an:
* den Kundenzugang, freigeschaltet, in der Sprache der Anfrage
* das Projekt, verknuepft mit der Anfrage, mit Wunschtermin und
"Briefing-Termin vereinbaren" als erstem sichtbaren Schritt
* die Anfrage wechselt automatisch auf "angenommen"
Danach springt die Ansicht auf "Kunden" und zeigt sofort den
Einladungslink -- den einzigen Weg, wie der Kunde an sein Passwort kommt.
Die beiden Schritte laufen bewusst nacheinander, nicht parallel: das
Projekt braucht die Kunden-Kennung. Schlaegt der zweite fehl, existiert
der Kunde trotzdem schon. Genau das sagt die Fehlermeldung dann auch
ausdruecklich -- sonst versucht man es blind noch einmal und scheitert an
der doppelten E-Mail-Adresse, ohne zu verstehen warum.
Ist aus einer Anfrage bereits ein Kunde geworden, erscheint statt der
Uebernahme ein Hinweis darauf. Zweimal denselben Kunden anzulegen soll
gar nicht erst angeboten werden.
Dabei denselben Anfuehrungszeichen-Fehler wie schon einmal gemacht und
behoben: das gerade " in „Kunden" beendet die JavaScript-Zeichenkette.
Typografisch richtig ist ohnehin das schliessende " -- beides in einem Zug.
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung 22.08.2026: "mach es noch krasser noch detaillierter noch
viel besser und perfekter und auch die kacheln viel geiler."
Die Kacheln waren eine Reihe stiller Zahlen. Zahlen, die man nur anschauen
kann, sind Dekoration. Jetzt:
* Jede Kachel FILTERT die Liste darunter beim Antippen. Als echter
<button>, nicht als div mit Klickzuhoerer -- sonst ist sie mit der
Tastatur nicht erreichbar und ein Screenreader kuendigt sie nicht als
Bedienelement an.
* Jede Kachel sagt, was zu TUN ist, nicht nur wie viele es sind:
"warten auf dich" / "du bist dran" / "Kunde ist dran" /
"Projekt anlegen".
* Neue Kachel: der aelteste unbearbeitete Vorgang in Tagen. Das ist die
ehrlichste Kennzahl ueberhaupt -- sie sagt nicht, wie viel man
geschafft hat, sondern wie lange jemand schon auf Antwort wartet.
Genau daran misst ein Kunde Zuverlaessigkeit. Ab sieben Tagen rot.
Diese eine Kachel filtert bewusst NICHT und ist deshalb auch kein
Knopf: sie zeigt einen Zustand, keinen Status.
* Eine Null wird gedaempft dargestellt. Sonst konkurriert "0 abgelehnt"
optisch mit "3 neu" -- und genau die Drei ist die, auf die man schauen
soll. Was nichts zu tun gibt, soll auch nicht leuchten.
* Gold bleibt ausschliesslich dem echten Handlungsbedarf vorbehalten.
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung 22.08.2026 mit Bildschirmfoto: die Anfragenliste wirkte blass
und leer. Zu Recht -- sie zeigte Nummer, Name, Paket, Status, Datum. Das
ist korrekt, beantwortet aber nicht die Fragen, die man beim Draufschauen
WIRKLICH hat.
Jetzt steht in jeder Zeile:
* E-Mail direkt sichtbar (vorher musste man die Anfrage dafuer oeffnen)
* Paket, Budgetrahmen, Wunschtermin als eigene Marken
* Sprache, falls es NICHT Deutsch ist -- dann antwortet man auch in der
richtigen Sprache
* ob daraus schon ein Kunde geworden ist
Statt eines Datums steht dort "vor 3 Tagen". Beim Datum muss man selbst
rechnen, wie lange jemand schon wartet -- und genau das ist die Frage,
die zaehlt. Ab sieben Tagen ohne Bearbeitung wird die Angabe rot: eine
Anfrage, die eine Woche liegt, ist ein verlorener Kunde.
Ein farbiger Streifen links codiert den Status zusaetzlich zur Textmarke.
Farbe ALLEIN waere fuer farbfehlsichtige Menschen keine Information --
zusammen mit dem Text ist sie ein schneller Anker beim Ueberfliegen.
Der leere Zustand stellt nicht mehr nur fest, dass nichts da ist, sondern
erklaert, WO Anfragen herkommen, und legt den Link zum Formular gleich
daneben.
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung 22.08.2026 mit Bildschirmfoto aus dem eigenen Testzugang:
"die seite soll jetzt schon bitte richtig krass sein und hoch profissionel,
auch sehr detailliert."
Zwei Luecken, beide geschlossen:
1) Projekte liessen sich nur ueber die Schnittstelle anlegen. Jetzt in der
Verwaltung: pro Kunde ein "+ Projekt" mit Titel, Paket, Preis,
Richttermin und naechstem Schritt. Bewusst als Einblendung direkt bei
der Kundenzeile statt als eigene Seite -- man legt ein Projekt IMMER
fuer einen bestimmten Kunden an, nie im luftleeren Raum. Der Kundenname
steht deshalb gross im Formular, damit es nicht versehentlich dem
Falschen angehaengt wird.
Die 30 % Anzahlung wird beim Tippen live mitgerechnet. Sie wird zwar
serverseitig berechnet, aber wer sie beim Eintippen sieht, merkt eine
falsche Null sofort -- und nicht erst, wenn der Kunde ueberweisen soll.
2) Der leere Zustand im Portal war ein einziger Satz. Das ist eine
verpasste Gelegenheit: Wer dort zum ersten Mal landet, hat gerade sein
Passwort gesetzt und weiss noch nicht, was ihn erwartet -- genau dann
entscheidet sich, ob die Seite souveraen wirkt oder unfertig. Jetzt
zeigt er in vier Punkten, WAS gleich hier stehen wird (Projektstand,
wer am Zug ist, Dateien und Nachrichten, Ideen jederzeit) und schliesst
mit der Zusicherung, dass nichts zu tun ist. Fuenfsprachig.
45/45 Handy-Abnahme, i18n vollstaendig.
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung 22.08.2026: "ich hab auf der verwaltungs seite 2 mal dass ich
den zugangscode eingeben muss und vanvan auch, ich will es nur einmal
eingeben muessen." Berechtigt.
Die Zugangswand hat serverseitig laengst geprueft, WER da ist -- Dogfather
oder VanVan, laut Masterplan S.4 beide gleichberechtigte
Volladministratoren. Ein zweites Passwort danach bringt keinen
zusaetzlichen Schutz, es kostet nur jedes Mal Zeit.
Warum es nicht einfach "Cookie mitschicken" ist: Die Verwaltungsdaten
liegen hinter postfach.dogfather-universe.com, einem ANDEREN Rechnernamen.
Das Sitzungs-Cookie gilt dort nicht -- so sind Cookies gebaut, und das ist
gut so.
Loesung: Die Zugangswand stellt unter /webdesign/api-ausweis einen
kurzlebigen, signierten Ausweis aus, den die interne API anerkennt.
- 15 Minuten gueltig, die Seite holt bei Bedarf still einen neuen
- traegt bereich="wd-admin", damit ein Sitzungs-Token der Zugangswand
hier NICHT durchgeht und umgekehrt
- nur mit gueltiger Zugangssitzung zu bekommen
- gilt AUSSCHLIESSLICH fuer die /webdesign-Endpunkte. Postfach,
Bewerbungen, Supporter und Teamverwaltung bleiben unberuehrt
Fehlt WEBDESIGN_API_SECRET auf einer der beiden Seiten, gilt kein Ausweis
und die Verwaltung fragt wie bisher nach dem Team-Code. Ein fehlender
Konfigurationswert darf niemals eine Tuer oeffnen -- nur eine schliessen.
Genau das prueft der letzte Testfall.
Bei einem 401 wird EINMAL still ein neuer Ausweis geholt und die Anfrage
wiederholt, statt jemanden mitten im Arbeiten rauszuwerfen.
10/10 Tests, darunter: gefaelschte Signatur, fremdes Geheimnis,
abgelaufen, falscher Bereich, erfundene Rolle.
Co-Authored-By: Claude Opus 5 <[email protected]>
Wunsch 22.08.2026: "ich will einen provisorischen zugang fuer mich".
Der richtige Weg dahin war ohnehin ueberfaellig -- Kundenzugaenge
entstehen ausschliesslich hier, es gibt bewusst keine Selbstregistrierung.
Neu:
* Kundenzugang anlegen (Name, E-Mail, Firma, Sprache, sofort freischalten
ja/nein) mit Einladungslink
* "Testzugang fuer mich" -- ein Klick, legt einen als Test erkennbaren
Zugang mit Datumsstempel an. Bewusst NICHT die echte Geschaeftsadresse:
die E-Mail ist gleichzeitig der Anmeldename und laesst sich aus gutem
Grund nicht mehr aendern, ein Test wuerde also spaeter mit einem echten
Kundenkonto kollidieren.
* Zugaenge auflisten, freischalten, sperren, neuen Einladungslink erzeugen
* Projekte anlegen und aendern, Aenderungswuensche beziffern, Nachrichten
Entscheidungen:
* Der Einladungslink geht EINMAL im Klartext raus, direkt beim Anlegen.
In der Datenbank liegt nur sein Hash. Wer ihn verliert, bekommt einen
neuen -- das ist sicherer, als ihn dauerhaft abrufbar zu halten. Die
Oberflaeche sagt das auch klar dazu, sonst klickt man ihn weg und
wundert sich.
* Ein neuer Link entwertet alle offenen alten. Sonst sammeln sich mehrere
gueltige Generalschluessel fuer dasselbe Konto an.
* "Sofort freischalten" ist eine bewusste Handlung. Ohne Haekchen wird der
Zugang angelegt, kommt aber noch nicht hinein -- Masterplan S.12
verlangt, dass Projektkauf oder Betreuung VOR der Freischaltung geprueft
werden.
* Sperren beendet laufende Sitzungen sofort, nicht erst nach Ablauf.
* Die 30 % Anzahlung werden aus dem Preis BERECHNET, nicht eingetippt.
Ein Tippfehler in der Anzahlung faellt sonst erst beim Geldeingang auf.
* Preise kommen als Euro herein und werden sofort in Cent umgerechnet
(Math.round, damit 49.99 nicht zu 4998 wird). Ab da nie wieder Komma.
* Vier klar unterscheidbare Zustaende in der Liste. Wichtig vor allem
"Einladung offen": freigeschaltet, aber noch kein Passwort gesetzt --
der Kunde war also noch nie drin.
* Kopieren faellt auf Markieren zurueck, wenn die Zwischenablage
blockiert ist. Eine Fehlermeldung waere dort nutzlos.
Co-Authored-By: Claude Opus 5 <[email protected]>
Vier Ansichten in einer Seite: Anmeldung, Passwort festlegen ueber den
Einladungslink, Uebersicht, Projektdetail. 71 Textbausteine in fuenf
Sprachen.
Korrektur an einer frueheren Entscheidung: Ich hatte das Portal als "nur
Deutsch" eingestuft wie die Verwaltung. Denkfehler -- die Verwaltung
nutzen Dogfather und VanVan, das PORTAL nutzen Kunden, und die koennen
Franzosen oder Portugiesen sein. Jetzt fuenfsprachig, und die Sprache des
Kunden wird bei der Anmeldung automatisch uebernommen.
Gestaltungsentscheidungen:
* Eine Phasenleiste zeigt auf einen Blick, wo das Projekt steht. Das ist
die haeufigste Frage ueberhaupt und der Grund, warum Kunden anrufen.
Bei pausierten oder abgebrochenen Projekten wird KEINE Leiste gezeigt --
ein Fortschrittsbalken waere dort irrefuehrend.
* Eine Marke sagt, wer gerade am Zug ist ("Wir warten auf dich" /
"Dogfather ist dran"). Das beendet die haeufigste Unklarheit im
Projektverlauf.
* Offene Zahlungen stehen ganz oben und in Gold -- das Einzige, was den
Kunden wirklich zum Handeln auffordert.
* Rueckfrage nur beim ANNEHMEN eines Zusatzangebots, nicht beim Ablehnen.
Annehmen erzeugt eine Zahlungspflicht, Ablehnen ist folgenlos.
* Abgelaufene Sitzung fuehrt zur Anmeldung mit klarer Ansage statt zu
einer leeren Seite, die wie "du hast keine Projekte" aussaehe.
* Der Einladungslink wird nach Gebrauch aus der Adresszeile entfernt --
er ist verbraucht und hat in der Chronik nichts verloren.
* Die Zahlungsknoepfe sagen ehrlich, dass PayPal noch eingerichtet wird,
statt so zu tun als wuerde etwas passieren.
Pruefskript zweimal geschaerft, beide Male waren es Fehlalarme:
* Die Heuristik fuer Nachschlagetabellen hielt gewoehnliche Woerter wie
"abnahme" und "uebergeben" fuer Woerterbuch-Schluessel. Jetzt muss ein
Unterstrich im Namen sein, so wie bei allen echten Schluesseln.
* Eine Ueberschrift gilt jetzt auch als uebersetzt, wenn die Uebersetzung
INNEN sitzt (fester Teil + dynamischer Teil).
i18n vollstaendig, 45/45 Handy-Abnahme.
Co-Authored-By: Claude Opus 5 <[email protected]>
Masterplan S.12. Anmeldung, Uebersicht, Projektdetail, Aenderungswuensche,
Zusatzangebote annehmen/ablehnen, Nachrichten, Profil.
DIE ZENTRALE ENTSCHEIDUNG: Die Trennung zwischen Kunden sitzt NICHT in der
Oberflaeche, sondern in jeder einzelnen Abfrage. Ueberall steht
"WHERE id = ? AND kunde_id = ?" statt "WHERE id = ?", wobei die kunde_id
IMMER aus der Sitzung kommt, nie aus der Anfrage. Wer eine fremde
Projektkennung errät, bekommt dadurch "nicht gefunden" statt Daten. Die
Oberflaeche liegt im Browser des Kunden und ist beliebig manipulierbar --
sie kann diese Aufgabe grundsaetzlich nicht uebernehmen.
Weitere bewusste Entscheidungen:
* KEINE Selbstregistrierung. Masterplan S.12 verlangt, dass Projektkauf
oder Betreuung VOR der Freischaltung geprueft werden. Ein Portal, in das
sich jeder selbst eintraegt, waere das Gegenteil. Kunden werden in der
Verwaltung angelegt und bekommen einen Einladungslink.
* Passwoerter mit scrypt (in Node eingebaut, kein Zusatzpaket). Ein
SHA-256 ueber ein Passwort ist milliardenfach pro Sekunde durchprobierbar;
scrypt ist absichtlich langsam UND speicherhungrig.
* Mindestanforderung ist LAENGE, nicht Zeichenklassen. "Hund1234!" erfuellt
jede Klassenregel und ist trotzdem schlecht; "mein blauer stuhl steht
krumm" erfuellt keine und ist ausgezeichnet.
* Gleiche Fehlermeldung bei unbekannter Adresse und falschem Passwort --
sonst lassen sich Kundenadressen durchprobieren.
* Die Anmeldesperre haengt an der E-Mail, nicht an der IP. Eine IP-Sperre
wuerde mehrere Kunden hinter demselben Firmenanschluss gemeinsam
aussperren -- genau der Fehler, der im Universe am 19.08.2026 auftrat.
* Sperre und Passwortwechsel beenden laufende Sitzungen SOFORT, nicht erst
nach zwoelf Stunden.
* Ein Zusatzangebot laesst sich nur annehmen, wenn es beziffert ist --
sonst entstuende eine Zahlungspflicht ohne Preis.
Dazu der wichtigste Test des Bereichs (test-webdesign-portal.mjs): zwei
echte Kunden, und Kunde B versucht systematisch mit Kunde As echten
Kennungen an dessen Projekt, Nachrichten, Dateien und Zusatzangebote zu
kommen. Prueft ausserdem, dass interne Notizen und interne Arbeitsdateien
auch dem BERECHTIGTEN Kunden verborgen bleiben.
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung 22.08.2026: "alle neben einander bitte". Vorher passten vier
in die Zeile und die fuenfte rutschte allein darunter -- das sieht aus wie
ein Versehen, nicht wie eine Gestaltung.
Ab 700px teilen sich jetzt alle fuenf den Platz zu gleichen Teilen
("flex: 1 1 0" statt "auto"). Mit "auto" waere "Preise & Zahlung" schmal
und "Inhalte & Zusammenarbeit" breit gewesen -- ungleiche Kacheln in einer
Reihe, also genau das, was hier schon einmal bemaengelt wurde.
"min-width: 0" ist dabei noetig, weil Flex-Elemente sonst nicht unter ihre
Inhaltsbreite schrumpfen und die Reihe trotzdem umbrechen wuerde.
Nachgemessen bei 700 / 900 / 1280 / 1440px: 5 Knoepfe, 1 Reihe, alle
gleich breit UND gleich hoch. Unter 700px bleibt der Umbruch -- fuenf
Spalten waeren auf einem Handy unlesbar schmal.
45/45 Handy-Abnahme weiterhin sauber.
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung 22.08.2026: "ich will nicht dass man die hin und her
schieben muss man soll die alle sehen aber nicht schieben muessen."
Richtig, und aus zwei Gruenden: Eine Wischleiste verbirgt, DASS es noch
mehr gibt -- was rechts aus dem Bild ragt, existiert fuer die meisten
Menschen schlicht nicht. Dazu kam ein haesslicher Scrollbalken quer ueber
die Seite. Jetzt brechen die Knoepfe um, alle fuenf sind auf einen Blick
da, auch bei 320px.
Der Text in den Knoepfen darf dabei mitbrechen (white-space: normal) --
ohne das sprengt ein langer Name wie "Buchhaltungs- &
Steuerverwaltungsseiten" auf schmalen Bildschirmen die Zeile und der
waagerechte Ueberlauf waere durch die Hintertuer zurueck.
Dabei mitgefunden: "hyphens: auto" auf Ueberschriften. Auf dem Handy
stand dadurch "Alles, was vorher ge-klaert sein sollte". Der Browser
trennt damit nach Silben, auch wenn ueberhaupt kein Platzproblem
besteht. In Fliesstext ist das ein Gewinn, in grossen Ueberschriften
sieht es billig aus -- und genau die sind das Erste, was jemand sieht.
overflow-wrap: break-word bleibt und faengt echte Ueberlaeufe weiterhin ab.
Pruefskript: die Sprungmarken-Leisten waren als "absichtlich scrollbar"
von der Ueberlaufpruefung ausgenommen. Diese Ausnahme ist raus -- sonst
wuerde ein zurueckkehrender Ueberlauf dort nie auffallen. 45/45 weiterhin
sauber.
Co-Authored-By: Claude Opus 5 <[email protected]>
Masterplan S.13. Anfragen ansehen, filtern, durchsuchen, Status aendern,
interne Notizen, archivieren. 9/9 Sicherheitstests.
Bewusste Entscheidungen:
* NUR AUF DEUTSCH. Der oeffentliche Teil laeuft in fuenf Sprachen, weil
dort Kunden landen. Hier landen ausschliesslich Dogfather und VanVan --
fuenf Sprachen waeren fuenffache Pflege und fuenffache Fehlerflaeche
ohne einen einzigen Nutzer, der sie braucht. Genau wie der bestehende
interne Bereich des Universe.
* Anmeldung ueber die BESTEHENDE Team-Anmeldung (/auth/login) statt einer
zweiten eigenen. Zwei Anmeldungen fuer dieselben zwei Personen waeren
doppelte Pflege und ein zweiter Ort, an dem ein Zugang vergessen werden
kann. Der Code der Zugangswand gilt hier ausdruecklich NICHT --
die Verwaltung steckt hinter zwei getrennten Tueren.
* Sitzungstoken im sessionStorage, nicht localStorage: es verschwindet
beim Schliessen, dieselbe Regel wie an der Zugangswand. Der Test prueft
das ausdruecklich.
* Bei abgelaufener Sitzung geht es zurueck zur Anmeldung statt zu einer
leeren Liste. Eine leere Liste sieht aus wie "keine Anfragen" und ist
damit eine stille Falschaussage.
* Gold nur beim Status "neu" -- also genau dort, wo wirklich etwas zu tun
ist. Wuerde alles leuchten, leuchtet nichts.
* Archivieren statt Loeschen, und die Oberflaeche sagt das auch dazu.
Pruefskript: kennt jetzt bewusst einsprachige Seiten (verwaltung, portal)
und prueft dort nur die Struktur, statt ein fehlendes Woerterbuch zu
melden.
Co-Authored-By: Claude Opus 5 <[email protected]>
Masterplan S.10 "Projektanfrage ohne Informationsverlust" umgesetzt.
End-to-End gegen die echte Datenbank belegt: Anfrage A-2608-0002 liegt drin.
38/38 Browsertests, 45/45 Handy-Abnahme.
Aufbau: 4 Schritte + Zusammenfassung + Dankeseite.
- Zwischenspeicherung nach jedem Tastendruck. Geschlossener Tab, leerer
Akku oder versehentliches Zurueck kosten keine Arbeit. Entwuerfe
verfallen nach 30 Tagen -- ein halbes Jahr alter Entwurf verwirrt mehr
als er hilft.
- Folgefragen erscheinen nur passend zur Auswahl und werden beim
Zurueckwechseln NICHT mitgeschickt, sonst landen alte Shop-Antworten in
einer Onepager-Anfrage.
- Die Zusammenfassung wird aus den Feldern gelesen, nicht aus einem
nebenher gepflegten Objekt -- sie kann dadurch nie etwas anderes
behaupten als das, was tatsaechlich abgeschickt wird.
- Telefon wird zur Pflicht, sobald "Per Telefon" gewaehlt ist. Ein Wunsch,
der nicht erfuellbar ist, ist schlimmer als eine Pflichtangabe.
Drei Fehler, die erst der Test gefunden hat:
1. Der "Zurueck"-Knopf stand auch auf Schritt 1 da. Ursache: das
hidden-Attribut wird nur ueber "display:none" umgesetzt und verliert
gegen jedes eigene display -- und Knoepfe sind inline-flex. Zentral
behoben ueber ".wd [hidden] { display:none !important }".
2. Nach erfolgreichem Absenden legte zeigeSeite() den geloeschten Entwurf
sofort wieder an. Beim naechsten Besuch haette eine bereits gesendete
Anfrage erneut im Formular gestanden.
3. Der Server meldet bei Spamverdacht bewusst Erfolg ohne Nummer. Ein
echter Mensch, der zufaellig sehr schnell war, haette eine Dankeseite
mit "—" gesehen und auf eine Antwort gewartet, die nie kommt. Jetzt
ein ehrlicher Hinweis mit zweitem Weg, und der Entwurf bleibt erhalten.
Pruefskripte geschaerft:
- i18n-Pruefung liest jetzt auch assets/js/wd-<seite>.js, sonst meldet sie
reihenweise "unbenutzt" fuer Schluessel, die aus dem Seitenskript kommen.
- Handy-Abnahme ueberspringt absichtlich unsichtbare Eingabefelder
(Auswahlkacheln, Honigtopf). Fehlalarme sind das Ende jeder Pruefung,
weil man sie irgendwann pauschal ignoriert.
Co-Authored-By: Claude Opus 5 <[email protected]>
Gemeldet 22.08.2026 mit Bildschirmfoto: "immer noch so" -- das Logo im
Marken-Intro stand weiterhin hochkant gestreckt da, obwohl die Korrektur
(height:auto gegen die height-Attribute) laengst live war.
Ursache war NICHT die Korrektur, sondern mein eigener Service Worker. Er
lief fuer /assets/ als "stale-while-revalidate": die gespeicherte Fassung
geht sofort raus, im Hintergrund wird eine frische geholt. Das ist schnell
-- bedeutet aber, dass jede Aenderung an CSS oder JavaScript beim ersten
Aufruf unsichtbar bleibt und erst beim zweiten wirkt. Ein behobener Fehler
sieht dadurch aus wie ein nicht behobener. Die unangenehmste Sorte.
Nachgemessen ist das Logo jetzt 160x161px bei einem natuerlichen
Verhaeltnis von 472x476 -- also unverzerrt. Vorher erzwang das Attribut
height="476" bei 160px Breite ein Verhaeltnis von 0,34 statt 0,99, genau
das lange Gesicht auf dem Bildschirmfoto.
Behoben:
- Stilvorlagen und Skripte laufen jetzt "Netz zuerst", Zwischenspeicher
nur als Notfallnetz. Richtigkeit vor Millisekunden.
- Bilder und Symbole bleiben beim schnellen Weg -- die aendern sich
praktisch nie und bekaemen sonst einen neuen Dateinamen.
- CACHE_NAME auf v2 gesetzt, damit der alte Speicher beim naechsten Start
vollstaendig weggeworfen wird.
- Versionsnummer an allen CSS/JS-Verweisen hochgesetzt, damit es sich auch
ohne Service Worker sofort selbst heilt.
Ausserdem: Woerterbuch fuer das Anfrageformular, 101 Textbausteine in fuenf
Sprachen (vier Schritte, Zusammenfassung, Fehlermeldungen).
Co-Authored-By: Claude Opus 5 <[email protected]>
Rueckmeldung 22.08.2026 per Bildschirmfoto: "die sollen alle gleich
aussehen und nicht einer groesser oder kleiner" und "ich will nicht soooo
viel abstand".
1) Verzerrte, ungleich hohe Projektbilder
Nachgemessen: 576px breit, aber 750px bzw. 696px hoch -- also hochkant
gestreckt und unterschiedlich, obwohl im CSS sauber "aspect-ratio:
16/10" stand. Ursache: die width/height-Attribute im HTML (die dort
bewusst stehen, damit der Browser vor dem Laden den Platz reserviert
und die Seite nicht springt) wirken wie eine CSS-Hoehe und schlagen
aspect-ratio. Fix zentral ueber ".wd img[width][height] { height:
auto }" statt in jeder einzelnen Regel -- so kann es bei einem neuen
Bild nicht vergessen werden.
Jetzt beide 576x360, Karten beide 853px hoch.
2) Zu viel Leerraum
.wd-abschnitt hatte 100,8px oben UND unten, also gut 200px zwischen
zwei Abschnitten. Halbiert auf 57,6px, Hero von 78svh auf 68svh.
Seitenlaenge dadurch 8798px -> 7089px bei gleichem Inhalt.
3) Zwei neue Dauerpruefungen in pruefe-webdesign-handy.mjs, damit genau
diese beiden Fehlerarten nicht wieder per Bildschirmfoto auffallen
muessen:
- verzerrte Bilder (gewuenschtes vs. tatsaechlich gerendertes
Seitenverhaeltnis, 2 % Toleranz)
- ungleich hohe Karten innerhalb EINER Rasterzeile
40/40 Abnahme weiterhin sauber.
Co-Authored-By: Claude Opus 5 <[email protected]>
Zwei Rueckmeldungen vom 22.08.2026, beide behoben und mit Tests abgesichert.
1) "das sieht nicht gut aus" (Bildschirmfoto des Hauptknopfs)
Ursache: ".wd a" ist Klasse+Element und damit spezifischer als die reine
Knopfklasse ".wd-btn--haupt". Die Textfarbe des Knopfs wurde dadurch
ueberstimmt -- hellblaue Schrift auf hellblauem Grund, praktisch
unlesbar. Derselbe Spezifitaetsfehler wie zuvor bei den Namen auf der
Zugangswand. Fix: ".wd a:not(.wd-btn)" plus zweistufig geschriebene
Knopfregeln, damit das nicht wieder passieren kann.
2) "das sieht lang gezogen aus"
Die Pillenform (border-radius 999px) laesst breite Knoepfe
auseinandergezogen wirken, weil der Radius optisch mit der Breite
mitwaechst. Jetzt fester Radius von 14px -- gleiche Form bei jeder
Breite, ruhiger und hochwertiger.
3) "ich will das ich jedes mal den code gefragt werde wenn man die seite
zu macht"
Das Sitzungs-Cookie allein reicht dafuer nicht: Browser stellen genau
solche Cookies beim Wiederherstellen von Tabs zurueck ("Dort
fortfahren, wo du aufgehoert hast"), man landet dann ohne Codeabfrage
wieder mitten in der Seite. Zusaetzlich jetzt eine Sitzungsmarke im
sessionStorage, die beim echten Schliessen verschwindet. Fehlt sie bei
vorhandenem Cookie, wird die Sitzung serverseitig beendet und zur
Zugangswand geleitet. Token-Notbremse von 24 auf 8 Stunden gesenkt.
13/13 Tests im echten Browser, inklusive Schutz vor Endlosschleife.
DEPLOY.md: zwei Checkouts auf dem Server dokumentiert (/home/dogiweb und
/home/dogiintern) und der Vorfall, dass /webdesign nach dem Pull kurz ohne
Zugangsschutz erreichbar war, weil der Dienstneustart fehlte.
Co-Authored-By: Claude Opus 5 <[email protected]>
Umsetzung des "Website Masterplan" (16 Seiten) unter /webdesign.
Zugangsschutz mit EIGENER Schranke (server/webdesign-gate.js) statt gate.js:
gate.js laesst seit dem oeffentlichen Start am 21.08.2026 jeden durch, weil
die Pruefung auf SITE_PUBLIC_LAUNCH_AT als allererste Zeile steht. Haette man
/webdesign dahintergehaengt, waere der ausdruecklich nicht-oeffentliche Bereich
inklusive Preisen und spaeteren Kundendaten ab der ersten Sekunde fuer jeden
lesbar gewesen. Eigenes Sitzungs-Cookie, bereich="webdesign" im Token, damit
ein gueltiges Universe-Cookie hier NICHT gilt. 37/37 Tests.
Sieben oeffentliche Seiten in fuenf Sprachen (de, de-CH mit echtem Dialekt, en,
fr, pt). Preise, Zeitrahmen, Paketnamen und die 30-%-Regel stehen an genau
EINER Stelle in wd-core.js -- der Masterplan verlangt "ueberall
widerspruchsfrei", und vier Kopien laufen bei der ersten Preisaenderung
auseinander.
Als App installierbar auf Handy und PC. Der Service Worker speichert bewusst
KEINE HTML-Seite zwischen: nach dem Abmelden wuerden sonst geschuetzte Seiten
weiter ausgeliefert, ohne dass der Server je gefragt wird. 18/18 Tests.
Handy-Abnahme ueber alle Seiten in fuenf Breiten (320-1440) und fuenf Sprachen:
40/40. Der Test fand 35 echte Fehler (Touch-Ziele unter 44px), behoben im
Designsystem statt einzeln pro Seite.
PayPal (Wunsch 22.08.2026 "sofort auf meinem paypal"): Orders API mit
intent=CAPTURE, also sofortiger Einzug statt blosser Reservierung. Gebuehr und
Nettobetrag getrennt gespeichert. Betraege durchgehend als Ganzzahl in Cent.
Gefaelschte Webhooks werden abgewiesen. Fail closed solange Zugangsdaten
fehlen. 28/28 Tests gegen einen nachgebauten PayPal-Server.
Datenbank: 15 Tabellen mit Praefix wd_, fachlich vollstaendig vom Universe
getrennt.
Co-Authored-By: Claude Opus 5 <[email protected]>
Beim Abgleich zwischen Rechner und Netcup-Server am 22.08.2026 aufgefallen:
20 Bilddateien wurden live von mehreren Seiten benutzt (bewerben-modi.html,
links.html, medien-casper.html, medien-hasidog.html, supporter.html,
stimmen.html u.a.), lagen aber in keiner Git-Ablage -- nur auf diesem
Rechner und auf dem Server. Waeren beide verloren gegangen, waeren diese
Seiten ohne Hintergrund/Avatare dagestanden.
Vor dem Hinzufuegen jede Datei per Pruefsumme gegen den Server abgeglichen
-- alle identisch, kein abweichender Stand wird hier verdeckt.
dogfather-universe-app.ico ist aktuell nirgends verlinkt (vermutlich ein
nie eingebauter Favicon-Entwurf), trotzdem mit gesichert statt verworfen.
Co-Authored-By: Claude Opus 5 <[email protected]>
Die Anleitung nannte als Deploy-Weg weiterhin "npx wrangler deploy". Das ist
seit dem oeffentlichen Start (21.08.2026) falsch und aktiv gefaehrlich: der
Befehl laeuft fehlerfrei durch und meldet Erfolg, erreicht aber nur noch
...workers.dev. Die echte Domain wird von Caddy auf dem Netcup-Server
ausgeliefert (dogiweb.service, localhost:4100). Genau darauf bin ich heute
beim Sprachfenster-Fix hereingefallen -- Deploy "erfolgreich", auf dem Handy
aber unveraendert kaputt.
Neu dokumentiert: der einzige gueltige Weg (commit -> push gitea master:main
-> git pull auf dem Server), die Zweig-Falle master/main, die Pflichtpruefung
gegen die echte Domain statt gegen die Deploy-Meldung, warum die
wrangler-Fehlermeldung "externally managed DNS records" erwuenscht ist, und
als offener Punkt: mehrere live benutzte Hintergrundbilder liegen in keiner
Git-Ablage.
Co-Authored-By: Claude Opus 5 <[email protected]>
Beim Abgleich der beiden Staende (Rechner vs. Netcup-Server) gefunden --
beide Aenderungen liefen bereits live, waren aber nirgends gespeichert und
haetten beim naechsten Deploy vom Rechner aus verloren gehen koennen:
1. gate.html: autofocus im Dogi-Feld entfernt (21.08.2026, Rueckmeldung von
Diene -- der Cursor sprang nach dem Laden zurueck nach oben, die eigene
Kachel scrollte dabei aus dem Bild).
2. verwaltung.html: "Oeffnen"-Knoepfe wurden auf dem Handy vom
overflow:hidden der Karte abgeschnitten (22.08.2026); jetzt
overflow:visible plus etwas mehr Unterabstand.
Inhalt unveraendert vom Server uebernommen, nur hier nachgetragen.
Co-Authored-By: Claude Opus 5 <[email protected]>
Nutzer-Report per Foto: beim Tippen auf "DE" im Handy-Menue erschien das
Sprachfenster halb links ausserhalb des Bildschirms, man konnte keine
Sprache mehr lesen oder treffen.
Ursache: Die Handy-Regel, die alle Aufklapp-Fenster auf statische Position
und volle Breite umstellt, hat den Sprachschalter nicht erreicht -- seine
Desktop-Regel (.sprach-schalter .nav-dropdown, 0-2-0) ist spezifischer,
und eine @media-Abfrage erhoeht die Spezifitaet nicht. Dadurch lief die
Desktop-Animation "sprach-dropdown-in" weiter, die per fill-mode:both
dauerhaft transform: translateX(-50%) setzt. Auf dem Desktop korrekt
(schmales Fenster mittig unter dem Knopf), im Handy-Menue aber toedlich:
das Fenster ist dort bildschirmbreit und wurde um seine halbe Breite nach
links geschoben (gemessen live: x = -148px bei 390px Viewport).
Fix: dieselben Handy-Regeln erneut mit ausreichender Spezifitaet fuer den
Sprachschalter, samt Kommentar zur Begruendung.
Geprueft mit Playwright (echter Browser): 390x844, 360x640, Querformat
844x390 und Tablet 768x1024 -> Fenster jeweils vollstaendig im Bild, alle
5 Sprachen sichtbar; Desktop 1920 unveraendert schmal und zentriert;
Sprachwechsel (English) funktioniert weiterhin.
Co-Authored-By: Claude Opus 5 <[email protected]>
War beim Server-Deploy schon als Konflikt aufgefallen (Diene/das Team hatte
die richtige Schreibweise bereits korrigiert) -- hier fehlte die Korrektur
noch in i18n-zeitreise.js (alle 5 Sprachen) sowie in der HTML-Fallback-
Version, weil mein ursprünglicher Fix von heute Nachmittag ("Cidem" ->
"Cidgem") selbst schon falsch war.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Report mit drei Bildern vom Handy:
1. HERO-BILD SASS NICHT MEHR HINTER DEM TEXT (index.html)
.hero-artwork hat "inset:0" -- füllt also die GESAMTE Höhe von
.hero-cinematic, und diese Sektion umschließt nicht nur die Überschrift,
sondern auch die 3 Welt-Kacheln darunter. Auf dem Handy wird die Sektion
durch den 4-zeilig umbrechenden Titel + Kacheln riesig (~1570px bei
390px Breite) -- das Trio-Bild (16:9, contain-skaliert an die Breite)
wurde dadurch nur ~220px hoch und mittig in dieser riesigen Fläche
zentriert, landete also als schmaler Streifen zwischen den Buttons und
den Welt-Kacheln statt hinter der Überschrift.
Fix: eigenes festes Seitenverhältnis (4:3) für die Bildbox auf dem
Handy, von OBEN verankert statt zentriert, background-size auf "cover"
-- Verlauf eigens für die neue, kürzere Box abgestimmt (die
Desktop-Version wäre zu abrupt gewesen). Über 6 Breiten (320-768px)
mit Playwright gegengeprüft.
2. MENÜ-KNOPF ZU UNAUFFÄLLIG (main.js + main.css, alle Seiten)
"da soll auch menü stehen und die 3 striche" + "die kiste soll auch
leicht eine andere farbe haben so dass sie auffällt, eine leicht blau
tönung". Sichtbares "Menü" neben den drei Strichen ergänzt (neuer i18n-
Schlüssel nav_toggle_label, alle 5 Sprachen) + dezente Babyblau-Tönung
(8% Deckkraft, passend zur Markenfarbe --accent). Dabei einen
unabhängigen, zweiten Bug gefunden und mitbehoben: durch die neue
Knopfbreite/-höhe wurde ein Rechenfehler im geschlossenen Mobilmenü
sichtbar -- "translateY(-110%)" reicht nur, wenn das Panel mindestens
10x so hoch ist wie der Kopfbereich; war das nicht der Fall, ragte die
Unterkante (der Sprachschalter) ein paar Pixel sichtbar ins Bild.
Robusterer Ersatz: -100% + fester 200px-Puffer, unabhängig von Panel-
und Kopfbereichshöhe. Über 3 Breiten gegengeprüft (Panel unsichtbar UND
öffnet weiterhin normal).
3. "ÖFFNEN"-KNOPF AUF DER ZUGANGSSEITE ABGESCHNITTEN (gate.html)
.gate-card trägt "flex: 1 1 220px" für die Desktop-Reihe (220px als
BREITE gedacht). Sobald @media max-width:480px auf flex-direction:column
umschaltet, gilt dieselbe Zahl als HÖHE -- die Karte wurde auf genau
220px Höhe gequetscht. overflow:hidden setzt zusätzlich das normale
Mindestmaß (min-height:auto) auf 0 herunter, wodurch nichts das
Zusammenquetschen verhinderte -- der "Öffnen"-Knopf wurde unten
abgeschnitten. Fix: flex:none in genau diesem Media-Block, Breite bleibt
weiterhin über width:100%/max-width geregelt. An 4 Breiten x 3 Kacheln
(Dogi/VanVan/Diene) gegengeprüft: Karten jetzt 258px statt 220px hoch,
Knopf komplett sichtbar.
Vollständiger Regressionslauf: alle 34 Seiten bei 390px (kein Überlauf,
Menü-Knopf überall erreichbar und beschriftet), Desktop bei 1920px
unverändert (Hamburger weiterhin nur unter der bestehenden 1650px-
Schwelle sichtbar).
Cache-Busting-Version auf 20260821t erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: "ich will dass du auch ein countdown zu der
seite hinzufügst wo wir den zugangscode eingeben müssen. den um 21h heute
abend geht die seite live. kannst du das sogar so anpassen dass es
automatisch läuft?"
server/gate.js:
- Neue Einstellung SITE_PUBLIC_LAUNCH_AT (ISO-Zeitstempel mit Zeitzone).
Ab diesem Moment lässt gateMiddleware ausnahmslos jeden durch -- ganz
ohne Neustart oder manuellen Eingriff, weil jede Anfrage die aktuelle
Serverzeit live neu prüft. Die Freischaltung "passiert" also von selbst
in der Sekunde, in der die Uhrzeit erreicht wird. Vorher bleiben die
Zugangscodes unverändert nötig, damit das Team schon vorher rein kann.
Fail-safe statt fail-open geprüft: ein kaputter/unparsbarer Zeitwert
(z.B. Tippfehler in der .env) lässt die Schranke aktiv, statt die Seite
versehentlich für alle zu öffnen.
- Neuer öffentlicher Endpunkt GET /gate-launch-info (immer erreichbar,
auch ohne gültige Sitzung) liefert launchAt/isLive/serverTime für die
Countdown-Anzeige im Frontend.
gate.html:
- Neue Countdown-Box zwischen Titel-Karte und den Zugangscode-Kacheln
(bleibt unsichtbar, solange kein Starttermin konfiguriert ist). Rechnet
auf der SERVERZEIT statt der eigenen Uhr (einmaliger Zeit-Abgleich beim
Laden), damit eine falsch gehende Besucher-Uhr weder zu früh noch zu
spät zählt. Bei Erreichen von Null folgt ein letzter Abgleich mit dem
Server, bevor automatisch zur Zielseite weitergeleitet wird -- kein
Klick, kein Neuladen nötig.
- Zugangscode-Kacheln (Dogi/VanVan/Diene) bleiben während des Countdowns
unverändert nutzbar.
Getestet: 18 Middleware-Tests (inkl. Fail-safe bei kaputtem Zeitwert,
weiterhin funktionierender Zugangscode vor dem Start) + 10 Playwright-
Tests der Countdown-Oberfläche (Anzeige, Format, automatischer Sprung bei
Ablauf, sofortige Weiterleitung falls schon live, stiller Fallback bei
Netzwerkfehler). Zusätzlich alle 32 echten Seiten auf PC-Installierbarkeit
geprüft (Manifest, Icons, Service Worker, Install-Knopf, echter
Install-Klick-Ablauf simuliert) -- keine Probleme gefunden.
Cache-Busting-Version auf 20260821s erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nachtrag auf Nachfrage ("hast du alles geprüft oder nur die menü
leisten?") -- vorher hatte ich nur Navigation, Seitenbreite, Tippflächen
und Hoch/Querformat geprüft. Jetzt zusätzlich Bilder, Texte, Knöpfe und
die kompletten Abläufe.
Geprüft über alle 35 Seiten bei 393px:
- Bilder: kein einziges kaputtes Bild, keine fehlenden alt-Texte
- Dateien: keine 404er
- Knöpfe/Links: alle beschriftet (keine namenlosen Bedienelemente)
- Text: nichts wird abgeschnitten. Die zunächst gemeldeten "Überläufe"
bei .btn/.card waren Fehlalarme -- sie stammen von den dekorativen
Leucht-Ebenen (::before mit negativem inset), echter Text ragt
nirgends heraus (einzeln gegengeprüft).
Zwei echte Funde behoben:
1. Marken-Unterzeile war mit 8,96px zu klein zum Lesen (hatte ich beim
Handy-Fix selbst so verkleinert). Jetzt 11px -- Platz ist da, seit der
Menü-Knopf eigenständig rechts sitzt. Über acht Breiten gegengeprüft,
Kopfleiste bleibt überall stabil.
2. "Aktiv"-Ankreuzfelder in der Verwaltung waren 22px. Jetzt 26px, die
ganze Beschriftungszeile ist 44px hoch und schaltet mit um.
Abläufe am Handy durchgespielt (echte Fingertipps, Fake-Backend):
- Registrierung über alle drei Schritte inkl. falschem Code
- Login mit falschem und richtigem Zugangscode
- Abmelden auf supporter.html
- Stimme einreichen inkl. Profilbild-Auswahl
- Verwaltung: Team-Mitglied anlegen, Stimme freigeben, alle Bereiche
sichtbar, kein Überlauf
Cache-Busting-Version auf 20260821r erhöht.
Co-Authored-By: Claude Opus 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: "benutz da bitte nur die originalen husky und
hasen. mach nur die zwei. und die auswahl wo die leute selbst ein bild
rein setzen können."
- Auswahl von acht auf zwei reduziert (DogFather-Husky, HasiDog). Die
übrigen Bilddateien bleiben liegen, falls sie je zurücksollen -- es
genügt, die Zeile in data-stimmen-avatare.js und die Id in
ERLAUBTE_AVATARE wieder zu ergänzen.
- Neue Kachel "eigenes Bild" (gestrichelter Rand + Plus), die den
Dateidialog öffnet, das Bild sofort hochlädt und als Vorschau in der
Kachel zeigt.
Bereits freigegebene Stimmen mit einer der entfernten Figuren zeigen
wieder den Anfangsbuchstaben statt eines kaputten Bildes -- die
Auflösung unbekannter Ids liefert null, das war schon so vorgesehen.
Sicherheit des öffentlichen Uploads (bisher war Hochladen bewusst nur
der Verwaltung erlaubt):
- Gleiche multer-Härtung wie der Verwaltungs-Upload: nur JPG/PNG/WebP,
max. 5 MB, zufälliger UUID-Dateiname (kein Originalname).
- Der Server nimmt im Avatar-Feld weiterhin NUR bekannte Ids an oder
eine Adresse, die exakt auf den eigenen Upload-Ordner zeigt und danach
nur aus UUID + Bildendung besteht. Gegengetestet: fremde Domains,
"../"-Ausbruch, .svg/.html, javascript:, angehängte Skripte und http
statt https werden alle abgelehnt.
- Missbrauchsbremse gegen Vollschreiben der Festplatte: max. 10 Uploads
pro Stunde und IP.
- Sichtbar wird ein Bild ohnehin erst, wenn die Stimme freigegeben wird.
Mit Playwright end-to-end geprüft (10 Tests) plus 9 Sicherheitsfälle.
Cache-Busting-Version auf 20260821q erhöht.
Co-Authored-By: Claude Opus 5 <[email protected]>
Wie beim vorherigen Mal lag das nur als Arbeitskopie auf dem Server, nicht
in git. Unverändert übernommen, bevor darauf aufgebaut wird:
- Profilbild-Auswahl für die Stimmen (data-stimmen-avatare.js neu,
stimmen.js, i18n-stimmen.js, stimmen.html, verwaltung.html, main.css)
- Dritte Zugangs-Kachel für Diene (gate.html, server/gate.js)
Co-Authored-By: Claude Opus 5 <[email protected]>
Nutzer-Report 21.08.2026 mit Screenshot: "auf dem handy kann ich oben
nicht aussehen in welche seite ich will welche kategorie welche sprache
garnichts". Drei echte, per Playwright reproduzierte Fehler:
1. MENÜ-KNOPF AUSSERHALB DES BILDSCHIRMS (Hauptproblem)
.brand stand auf flex-shrink:0, war bei 390px aber 352px breit. Mit
Abstand + Knopf brauchte die Leiste 423px bei 367px Platz -- der
Menü-Knopf landete bei x=396px, also komplett außerhalb. Damit war auf
dem Handy die GESAMTE Navigation unerreichbar (keine Seiten, keine
Kategorien, kein Sprachwechsel).
Fix: Knopf per margin-left:auto immer an die rechte Kante; Marke darf
unter 620px schrumpfen (inkl. min-width:0, sonst greift flex-shrink
nicht); unter 400px entfällt die reine Deko-Unterzeile.
2. MENÜ IM QUERFORMAT NICHT ZU ÖFFNEN
Das zugeklappte Panel wird um -110% SEINER EIGENEN Höhe verschoben. Quer
(568x320) ist es nur 258px hoch, die Unterkante lag dadurch bei y=36px --
also unsichtbar genau über dem Menü-Knopf (y=11..55) und hat jede
Berührung abgefangen. Fix: pointer-events:none im geschlossenen Zustand.
3. MENÜPUNKTE AUF KURZEN BILDSCHIRMEN ZUSAMMENGEQUETSCHT
.nav-links ist ein Flex-Container fester Höhe; passte der Inhalt nicht,
schrumpfte Flexbox die Einträge (iPhone SE: 59px -> 29px, Knöpfe 21px).
Fix: flex-shrink:0 auf die Kinder, der Bereich scrollt stattdessen
(overflow-y:auto war bereits gesetzt).
Zusätzlich: Fußzeilen- und Impressum/AGB-Links auf Handys als echte
Tippziele (44px statt 17-20px) -- 18 dicht stehende Links, mit dem Finger
vorher kaum zu treffen. Menü-Trennlinien begradigt (folgten dem
Desktop-Pillenradius und sahen aus wie Schüsseln).
Ergebnis: alle 31 Seiten ohne Überlauf, Menü auf 320-768px, hoch UND quer
nutzbar, kleinster Menüpunkt 46px. Verbleibende kleine Ziele sind reine
Fließtext-Links im Satz (dürfen laut Standard klein bleiben).
Desktop per Regressionstest unverändert geprüft.
Cache-Busting-Version auf 20260821p erhöht.
Co-Authored-By: Claude Opus 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: "bei der ersten registrierung sollen die eine
email bekommen mit einem einmaligen code damit wir auch wissen dass
email stimmt und danach wenn sie den code eingegeben haben sollen die
erst ihren zugangscode auswählen/eintippen können."
Damit wird eine echte Lücke geschlossen: registerSupporter() hat bisher
`email_verified = 1` gesetzt, OHNE dass irgendetwas geprüft wurde -- man
konnte sich mit einer fremden oder erfundenen Adresse registrieren und
kam sofort rein.
Neuer Ablauf in drei Schritten:
1. Name/TikTok/E-Mail -> Konto wird als UNBESTÄTIGT angelegt
(email_verified = 0, noch kein Zugangscode). Es kommt bewusst KEIN
Session-Token zurück -- eingeloggt ist man hier noch nicht.
2. Einmalcode aus der E-Mail eingeben -> verify-email bestätigt und
loggt ein. Die Willkommens-Mail wandert hierher, sie ging vorher an
eine noch ungeprüfte Adresse.
3. Erst jetzt den eigenen Zugangscode festlegen.
Serverseitig abgesichert: setSupporterAccessCode() lehnt ab, solange die
E-Mail nicht bestätigt ist -- der Schritt ist damit nicht nur im
Formular versteckt, sondern auch per Direktaufruf nicht überspringbar.
Wiederverwendet wird die bereits vorhandene Mechanik (issueAuthCode/
verifyAuthCode mit Zweck "verify_email", sendVerifyEmailCode, die Panels
#panel-code und #panel-neuer-code) -- der "Code vergessen?"-Weg nutzt
dieselbe Code-Eingabe und bleibt unverändert; eine neue Variable
codeZweck unterscheidet, welcher Endpunkt aufgerufen wird.
Mit Playwright end-to-end geprüft (14 Tests): Reihenfolge der Aufrufe,
kein Token vor der Bestätigung, falscher Code kommt nicht weiter,
Zugangscode-Feld erst im letzten Schritt, "Code vergessen?" unberührt.
Cache-Busting-Version auf 20260821o erhöht.
Co-Authored-By: Claude Opus 5 <[email protected]>
Diese Änderungen liefen bereits live auf dem Server, lagen dort aber
ausschließlich als nicht eingecheckte Arbeitskopie — bei jedem Deploy
(stash/pull/pop) und bei jedem Serverproblem wären sie verloren gewesen.
Deshalb hier unverändert in git übernommen, bevor darauf aufgebaut wird.
Enthalten (nicht von mir gebaut, nur gesichert):
- Supporter: eigener fester Zugangscode statt Einmalcode-Login
(Migration 0009, lib/crypto.js scrypt-Hash, routes/supporter.js,
abonnieren.html, supporter.html, i18n-abonnieren/-supporter)
- Stimmen: Profilbilder (Migration 0010, routes/testimonials.js)
- Event-Bild-Upload: voller Pfad statt relativem (routes/events.js)
- Neue/überarbeitete Hintergrundbilder für viele Seiten
- Teilen-Funktion (streamplan.js, i18n-index/-streamplan, main.css)
Co-Authored-By: Claude Opus 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: "die 4 kacheln da sollen da weg bitte."
Überschrift, Beschreibungstext und der Knopf zum Modi-Team bleiben --
dadurch kommt das "Team Dogi"-Hintergrundbild dieser Sektion jetzt
unverdeckt zur Geltung. Der zugehörige Render-Code ist ebenfalls raus;
data-modis.js/data-scouts.js bleiben eingebunden, weil die
Statistik-Zeile weiter oben sie weiterhin auszählt (geprüft: zeigt
weiterhin korrekt "8+"). Die Profile selbst gibt es unverändert
vollständig auf team-modis.html.
Cache-Busting-Version auf 20260821n erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: "Weg" stand auf manchen Bildschirmbreiten
allein in einer eigenen Zeile, sah unruhig aus. Non-breaking-Space
zwischen den letzten zwei Wörtern in allen 5 Sprachen -- bricht die
Zeile jetzt nie mehr genau zwischen ihnen um.
Cache-Busting-Version auf 20260821m erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: Tippfehler beim Namen des Kooperationspartners
beim Creator Cup korrigiert, in allen 5 Sprachen plus dem
HTML-Fallbacktext.
Cache-Busting-Version auf 20260821l erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Gleicher Fehler wie in routes/events.js/uploadEventImage (dort gerade
direkt auf dem Server gefunden und gefixt, siehe git stash auf
dogiintern): die Verwaltung und die echte Website laufen auf
dogfather-universe.com (dogiweb), hochgeladene Fotos liegen aber unter
postfach.dogfather-universe.com (dogiintern). Ein relativer Pfad wurde
vom Browser also gegen die falsche Domain aufgelöst -> kaputtes
Bild-Symbol für jedes über die Team-Verwaltung hochgeladene Foto.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: "wenn ich eine änderung mache ist es auch für
jeden für die die schon da sind und die neuen" + "ich will ich titel
und namen von kategorien und seiten ändern können in der verwaltung".
Backend (braucht Filipes manuellen Deploy):
- Migration 0008: team_members bekommt intro/bioHtml/extraCta-Spalten
-- volle Feld-Parität mit den von Hand gepflegten Profilen (Diene/
Patrick/Bananenstift/Marina nutzen diese Felder).
- routes/team.js: neue importLegacyMember()-Funktion -- übernimmt ein
bestehendes Profil 1:1 in die Datenbank, OHNE erneut zu übersetzen
(die vorhandenen, von Hand geschriebenen Übersetzungen bleiben
erhalten). Idempotent: mehrfacher Import erzeugt keine Duplikate.
- routes/site-texts.js (neu): admin-editierbare Kategorie-Namen und
Seitentitel, generischer key->{de,...}-Override über app_settings
(wie "Event des Jahres"), fester Schlüssel-Katalog aus
Sicherheitsgründen. Leeres Feld setzt auf den Standardtext zurück.
- 27 Tests in isolierter Testumgebung geprüft (kein better-sqlite3
lokal kompilierbar).
Frontend:
- window.dogiTeamZusammenfuehren() (main.js): admin-Mitglieder
ÜBERSCHREIBEN jetzt gleichnamige statische Einträge (per slug) statt
sie zu duplizieren -- eine Bearbeitung wirkt dadurch für alle.
- window.dogiSiteTexteLaden() + applyTranslations() erweitert um
data-site-text-key -- Kategorie-Seitentitel (team-modis.html/
team-scouts.html/creator.html/manager.html) sind jetzt live editierbar.
- Verwaltung: "📥 Bestehende Mitglieder importieren"-Knopf (holt VanVan/
Diene/Funny/Miss/Marina/Ghost/Patrick/Bananenstift aus den data-*.js-
Dateien, VanVan bewusst ausgenommen -- eigene Sonderkarte + Seite),
erweitertes Formular (Intro/ausführliche Vorstellung/zweiter Button,
eingeklappt unter "Erweitert"), neue Sektion "Kategorien &
Seitentitel" (4 Karten, sofort wirksam auf Website UND Verwaltung).
Beim Testen einen echten UX-Bug gefunden und gefixt: die "Gespeichert"-
Meldung nach dem Speichern eines Mitglieds wurde von der direkt
anschließenden Formular-Zurücksetzung sofort wieder überschrieben und
war nie sichtbar.
Cache-Busting-Version auf 20260821k erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: "überall wo Modis sind oder Scouts oder
Manager, oder Creator, will ich dass ich die easy über meine
Verwaltungsseite hinzufüge und die automatisch in der Website
hinzugefügt werden ... auch mit Fotos und TikTok Link."
Backend (server-internal, braucht Filipes manuellen Deploy):
- Neue Tabelle team_members (Migration 0007) für alle vier Kategorien
gemeinsam -- ergänzt, überschreibt NIE die von Hand gepflegten
Einträge in data-modis.js/data-scouts.js/data-creator.js.
- routes/team.js: öffentliches Lesen (nur aktive Mitglieder, optional
nach Kategorie gefiltert), TEAM_MANAGE-geschütztes Anlegen/Bearbeiten/
Löschen, Foto-Upload (gleiches Muster wie "Event des Jahres"),
automatische Übersetzung von Rolle/Bio/Zitat wie bei anderen
admin-gepflegten Texten. Slug global eindeutig (mit automatischer
Kollisionsauflösung), TikTok-Kurzname wird zu voller URL ergänzt.
27 Tests in isolierter Testumgebung geprüft (kein better-sqlite3
lokal kompilierbar).
Frontend:
- window.dogiTeamLaden() in main.js: holt admin-gepflegte Mitglieder
einer (oder aller) Kategorien und bringt sie in exakt dieselbe Form
wie die bestehenden data-*.js-Einträge.
- team-scouts.html/team-modis.html/creator.html hängen das Ergebnis
einfach an ihre bestehenden Arrays an und rendern erneut -- exakt
derselbe Look wie die schon bestehenden Profile (Foto/Avatar-Initiale,
Rolle, Zitat, TikTok-Button). creator.html hatte bisher ein "return"
bei leerem CREATORS-Array, wodurch admin-Creator NIE geladen worden
wären -- gefixt. team-modis.html berücksichtigt Rang/Rang-Bezeichnung
für die Pyramide.
- Neue Sektion "Weitere Manager" auf manager.html, komplett unsichtbar
bis der erste Manager angelegt wird (data-manager.js neu, wie
data-creator.js aktuell leer).
- profil.html sucht jetzt kategorieübergreifend auch in admin-gepflegten
Profilen, inkl. korrektem Theme/Zurück-Link auch für Manager.
Verwaltung: neue Sektion "Team verwalten" (TEAM_MANAGE-Berechtigung) --
ein Formular für alle vier Kategorien mit Foto-Sofort-Upload,
TikTok-Feld, Bio/Zitat, bedingten Rang-Feldern (nur Modi), Kategorie-
Filterleiste und Bearbeiten/Löschen pro Eintrag.
Beim Testen mit Playwright einen echten Syntaxfehler gefunden und
gefixt (ASCII-Anführungszeichen statt schließendem „" in einem
Statustext), der das GESAMTE Verwaltungs-Skript und damit die komplette
Seite lahmgelegt hätte.
Cache-Busting-Version auf 20260821j erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Beide heutigen Meldungen ("pr_quote_open...", "ts_profil_ansehen") waren
KEIN Caching-Problem, sondern ein echter Bug in main.js: nach Klick auf
einen internen Link und dann "Zurück" (oder generell jede zweite Seite
innerhalb einer Browser-Sitzung) wurde die seiteneigene i18n-*.js-Datei
nie erneut ausgeführt -> window.I18N_PAGE blieb auf null -> jede
Übersetzung fiel auf den rohen Schlüsselnamen zurück.
Ursache: skripteUebernehmen() erkennt i18n-Dateien am Muster ".js$"
(String-Ende). Seit die Cache-Busting-Version ("?v=...") an jede
Skript-URL angehängt wird, endet der echte src-Wert aber nie mehr auf
".js", sondern auf ".js?v=...". Der Test schlug seitdem für JEDE
i18n-Datei fehl und sie wurde wie eine normale, schon geladene Datei
behandelt und beim nächsten Seitenwechsel übersprungen.
Mit Playwright reproduziert (Klick auf Profil-Kachel + Zurück-Button)
und nach dem Fix erneut verifiziert -- betraf praktisch jede Seite mit
eigenem i18n-*.js beim Navigieren per Klick, nicht nur team-scouts.html.
Cache-Busting-Version auf 20260821i erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: Überschrift + Button "Alle Aktionen & Projekte"
auf index.html weg. data-aktionen.js-Script-Tag (nur noch dafür gebraucht)
und die zugehörigen JS-Renderzeilen ebenfalls entfernt, dazugehörige
i18n-Keys (idx_aktionen_h2/idx_aktionen_btn) aus i18n-index.js aufgeräumt.
aktion-detail.html und data-aktionen.js selbst bleiben unangetastet.
Cache-Busting-Version auf 20260821h erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: Patricks Bio endete nur mit "- euer Patrick",
Bananenstift hat zusätzlich eine zweite Zeile "Scout von Dogfather".
Für Konsistenz zwischen beiden Scout-Profilen in allen 5 Sprachen ergänzt.
Cache-Busting-Version auf 20260821g erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: unter dem Namen/Rolle-Text je ein TikTok-Button
(@patrick180585 bzw. @bananenstift009). Beide nutzen den bereits
bestehenden social-Mechanismus in profil.html (social.tiktok -> echter
.btn-tiktok-Button), kein neuer Code nötig.
Cache-Busting-Version auf 20260821f erhöht (data-scouts.js ist .js und
damit von Cloudflares erzwungenem Edge-Cache betroffen).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: erstes Fan-Treffen von Dogi & Tili (Team
TiliDog) in Wuppertal ergänzt -- gleichzeitig das erste persönliche
Aufeinandertreffen von DogFather und Tili. Als Meilenstein markiert und
chronologisch korrekt zwischen "Juli 2026 — Start als Manager" und
"27. Juli bis 2. August 2026 — Creator Cup" einsortiert.
Cache-Busting-Version auf 20260821e erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Nutzer-Wunsch 21.08.2026: "füge das foto was ich am ende mitschicke
neben den text im screen1". Sektion von einspaltigem Fließtext auf
grid-2 umgebaut, Foto (assets/img/streamer-filipe-portrait.jpg, aus
Pictures/Filipe, auf 1000x1500 verkleinert) rechts daneben mit
frame-gold-Rahmen für Abwechslung zur Casper-Sektion (frame-lila).
Cache-Busting-Version auf 20260821d erhöht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
