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]>
Nutzer-Wunsch 20.08.2026: "eine richtig geile kachel ... wo die leute mit
namen und tiktok namen mir eine nachricht schreiben können die ich in die
verwaltung kriege, und dann kann ich die ausgewählten über die
verwaltungsseite auf die website hinzufügen ... das wird mega persoenlich
zu den fans, bitte wirklich krass geil speziell."
- Neue, augenschonend gestaltete Einreich-Kachel auf stimmen.html: Name,
TikTok-Name (optional), Nachricht -- landet NIE automatisch oeffentlich,
sondern immer erst als Entwurf in der Verwaltung.
Warmer Babyblau/Rosé-Farbverlauf, wandernder Lichtschein, pulsierendes
Herz -- ersetzt die 3 ewigen "Hier steht bald..."-Platzhalterkarten.
- Neue Verwaltungs-Sektion "💬 Stimmen verwalten": Warteschlange (offene
zuerst), Freigeben/Ablehnen/Löschen pro Eintrag.
- Freigegebene Stimmen erscheinen automatisch in einer neuen, spezielleren
Zitat-Kartenoptik (großes Anführungszeichen, Name + TikTok-Chip) --
Abschnitt bleibt komplett unsichtbar, solange keine einzige freigegeben
wurde.
- Backend: neue Tabelle `testimonials` (Migration 0006), routes/
testimonials.js (oeffentliches Einreichen + Lesen freigegebener,
admin-Warteschlange + Status/Loeschen mit neuer TESTIMONIALS_MANAGE-
Berechtigung). 18 automatisierte Tests gegen eine Fake-DB bestanden.
- Alles per Playwright visuell durchgespielt: leerer Zustand, Einreichen
-> Erfolgsmeldung, freigegebene Stimmen-Anzeige, Verwaltungs-Warteschlange
mit allen Aktionen.
Backend-Teil (server-internal/, cloudflare-worker/migrations/) noch ohne
Deploy-Zugriff -- Dogi muss ihn manuell auf dogiintern ausrollen.
Co-Authored-By: Claude Opus 5 <[email protected]>
Naechste "Ausbaustufe" aus Dogfather_VanVan_Supporter_Abo.odt Abschnitt 20
(siehe Supporter-Abo-System.md), auf Nutzerwunsch "perfektioniere meine
Verwaltungsseite": Dogi/VanVan koennen in verwaltung.html eine Frage mit
2-6 Antwortoptionen auf Deutsch erstellen, automatische Uebersetzung beim
Speichern (gleiches Muster wie "Event des Jahres"). Jede aktive DogiCrew-
Person sieht die Abstimmung in ihrem Supporter-Bereich, stimmt genau einmal
ab (UNIQUE-Constraint in der DB, nicht nur Anwendungslogik), sieht danach
die Live-Ergebnisse. Admin-Seite zeigt Ergebnisbalken live, kann schliessen/
wiedereroeffnen/loeschen.
- Neue Migration 0005_supporter_polls.sql (supporter_polls,
supporter_poll_votes), neue Berechtigung POLLS_MANAGE.
- server-internal/routes/polls.js: 30 End-to-End-Tests gegen eine
Fake-DB bestanden (better-sqlite3 laesst sich lokal nicht kompilieren).
- verwaltung.html: neue "Abstimmungen"-Kiste im bestehenden
vw-overview-box-Stil (violett/pink Ergebnisbalken).
- supporter.html: neue "Aktuelle Abstimmung"-Karte im bestehenden
Gold-Look, Optionen -> Stimme -> Ergebnisbalken, alle 5 Sprachen.
Backend-Teil (server-internal/, cloudflare-worker/migrations/) noch ohne
Deploy-Zugriff -- Dogi muss ihn manuell auf dogiintern ausrollen.
Co-Authored-By: Claude Opus 5 <[email protected]>
- streamer.html: kompletter Inhalt ersetzt durch Dogis ausführliche
persönliche Vorstellung ("Wer ist DogFather? - Mehr als nur ein Name").
Enthält erstmals öffentlich: Filipe, 34, Portugiese, seit Februar 2026
in Luxemburg, Partnerin Franzi. Abschnitte: Der Mensch hinter DogFather,
DogFather als Streamer, Casper, Team Dogi/VanVan, DogFather als Manager
(Scouts Patrick & Bananenstift verlinkt), Was macht DogFather aus,
Schluss-Statement mit Signatur. Schlanke Buttonzeile am Ende erhalten
fuer Navigation (Videos/Galerie/Team Dogi).
- Neue Standing Rule: "DogFather" wird IMMER mit großem F geschrieben
(nicht "Dogfather"). Site-weit korrigiert in 29 Dateien (Anzeige-Text,
Alt-Texte, Meta-Beschreibungen, Kommentare) - technische Bezeichner
(Dateinamen, data-theme-Werte, CSS-Klassen, @dogfather0804-Handle)
bleiben bewusst unangetastet, da alle klein geschrieben sind und somit
von der Ersetzung gar nicht erst betroffen waren.
Ticketanizers Inbound-Ticket-API erzeugt bei API-Tickets nachweislich
keinen echten Discord-Kanal (nur Web-Inbox + Rollen-Ping im Log-Kanal,
auch nach manuellem Uebernehmen nicht) - das wurde heute gemeinsam mit
Dogi live in der Ticketanizer-Inbox und in Discord verifiziert. Deshalb
zusaetzlich ein normaler Discord-Webhook pro Zielkanal, der die komplette
Bewerbung garantiert sichtbar direkt postet.
Kanal-Zuordnung (von Dogi aus Discord kopiert):
modi -> #modi-bewerbung (DISCORD_WEBHOOK_MODI)
kooperation -> #kooperations-bewerbung (DISCORD_WEBHOOK_KOOPERATION)
scout + creator -> #scout-bewerbung gemeinsam (DISCORD_WEBHOOK_SCOUT_MANAGER)
- Neu: cloudflare-worker/src/lib/discord-webhooks.js
- applications.js: postet jetzt parallel zu Ticketanizer (Promise.all,
weiterhin ueber ctx.waitUntil im Hintergrund, blockiert nie die Antwort)
- Alle 3 Secrets bereits live gesetzt und deployed
- Getestet mit allen 4 Bewerbungstypen (modi/kooperation/scout/creator) -
laut Log alle erfolgreich gepostet, Testdaten aus D1 wieder entfernt
- README.md: Einschraenkung von Ticketanizer dokumentiert + neue
Webhook-Einrichtungsanleitung
Fremde Bewerber koennen theoretisch kurz hintereinander absenden (z.B.
wenn Dogi live "bewerbt euch jetzt" sagt) und dabei dasselbe Rate-Limit
treffen, das beim Testen aufgefallen ist. Jetzt wird ein 429 automatisch
bis zu 2x mit kurzer Pause wiederholt (Retry-After-Header wird beachtet,
sonst 2s/5s Standard-Wartezeit), bevor endgueltig aufgegeben wird - laeuft
komplett im Hintergrund ueber ctx.waitUntil, blockiert nie die Antwort an
den Bewerber. Die Bewerbung selbst landet ohnehin immer sicher in der
eigenen Datenbank, unabhaengig vom Ticketanizer-Ergebnis.
Getestet mit 3 gleichzeitigen Bewerbungen - alle liefen sauber durch.
Bisher wurden Fehler beim Ticket-Anlegen komplett stillschweigend
verschluckt (bewusst, damit es die Bewerbung nie blockiert) - das machte
es aber unmöglich zu sehen, WARUM ein Ticket nicht ankam. Jetzt wird
jeder Versuch (Erfolg wie Fehler, inkl. HTTP-Status und Antworttext)
über console.log/console.error protokolliert, sichtbar per
`wrangler tail`.
Umgestellt von der ursprünglichen Discord-Webhook-Idee auf die offizielle
Ticketanizer-Inbound-Ticket-API (api.ticketanizer.com/v1/tickets) - erzeugt
echte Tickets statt nur Nachrichten, landen dadurch direkt im richtigen
Ticketanizer-Bereich in Discord.
- Neu: cloudflare-worker/src/lib/ticketanizer.js. panel_id pro Bewerbungs-
bereich fest hinterlegt (aus dem Ticketanizer-Dashboard abgelesen):
Modi=4, Kooperation=5, Scout=6, Creator=7 (dort "Manager-Bewerbung")
- Alte discord.js entfernt (Ansatz verworfen)
- applications.js: Aufruf entsprechend umbenannt/angepasst
- README.md: Einrichtungsanleitung aktualisiert (TICKETANIZER_API_KEY
statt 4x DISCORD_WEBHOOK_*)
- Ticketanizer bleibt rein informativ, kein Ausfallpunkt - Bewerbung wird
immer in der eigenen Datenbank gespeichert, unabhängig vom Ticket-Erfolg
- Secret TICKETANIZER_API_KEY bereits live gesetzt und deployed; End-to-
End mit 3 Test-Bewerbungen geprüft (HTTP Ok geloggt), Testeinträge aus
der DB wieder entfernt
Jede eingehende Bewerbung landet weiterhin wie bisher in der D1-Datenbank,
wird zusätzlich aber (falls eine Webhook-URL hinterlegt ist) als formatierte
Discord-Nachricht in den passenden Kanal gepostet - pro Bewerbungsbereich
(Modi/Scout/Creator/Kooperation) eine eigene Webhook-URL, exakt wie auf der
Website getrennt. Läuft über normale Discord-Webhooks, kompatibel mit
Ticketanizer, falls dessen Kanäle eigene Ziel-URLs im selben Format anbieten.
- Neu: cloudflare-worker/src/lib/discord.js (Embed-Aufbau, Feld-Labels
pro Formular, Farbe je Bewerbungsart)
- applications.js: submitApplication ruft den Versand nach dem Speichern
auf, über ctx.waitUntil() damit die Antwort an den Nutzer nicht wartet
- worker.js: ctx wird jetzt an fetch() durchgereicht
- Discord ist rein informativ - fehlt die Webhook-URL oder ist Discord
kurz nicht erreichbar, wird die Bewerbung trotzdem ganz normal
gespeichert
- README.md: Einrichtungsanleitung (wrangler secret put DISCORD_WEBHOOK_*)
- bewerben.html: neuer Reiter "Modi" mit eigenem Formular (Name, E-Mail,
Discord/TikTok-Handle, Community-Erfahrung, Verfuegbarkeit, Motivation)
- Reiter wechselt jetzt nicht nur das Hintergrundbild, sondern auch die
Farbwelt: Creator/Scout/Kooperation bleiben Spicy-Media-rot (Agentur),
Modi wird babyblau (Team Dogi) -- passend zur bestehenden Regel
"Rot ist NUR die Agentur"
- Direkt-Link bewerben.html#modi oeffnet die Bewerbung gleich auf dem
richtigen Reiter; team-modis.html hat jetzt einen "Als Modi bewerben"
Knopf, der genau dahin fuehrt
- Worker: "modi" als vierter erlaubter Bewerbungstyp, laeuft ueber
dieselbe Sichtbarkeits-Berechtigung wie Scout/Kooperation (der feste
Rechte-Katalog aus dem Anforderungsdokument kennt nur zwei Bewerbungs-
Sichtbereiche -- es wurde bewusst KEIN neuer Permission-Key erfunden)
Co-Authored-By: Claude Opus 5 <[email protected]>
- Neues Modul lib/tiktok-live.js liest den Live-Status direkt von der
oeffentlichen TikTok-Live-Seite (SIGI_STATE -> liveRoom.status,
2 = live, alles andere = offline; bestaetigt durch yt-dlp)
- Cron-Trigger im Worker prueft jede Minute und schreibt das Ergebnis
nach app_settings; schlaegt ein Abruf fehl, bleibt der letzte gute
Stand stehen statt faelschlich auf offline zu springen
- /live-status liefert jetzt Quelle, Titel und Zeitpunkt der Pruefung
- Punkt ist rot wenn offline, gruen+pulsierend wenn live, grau solange
der Status laedt; Startseite aktualisiert alle 30 s ohne Neuladen
- Handschaltung bleibt als Notfall-Vorrang mit 3-Stunden-Ablauf, plus
Knopf "Zurueck zur Automatik" im Postfach
Co-Authored-By: Claude Opus 5 <[email protected]>
- Footer hat jetzt einen eigenen Block "Intern" mit Links zum
Bewerbungs-Postfach und zu Zugaenge & Rollen (vorher nur ein
winziger Link ganz unten)
- Postfach-Login verlinkt auf die Zugaenge-Seite
- Neue Tabelle app_settings + Endpunkt /admin/owner/set-code:
der Hauptadministrator kann seinen Code selbst aendern, mit
Bestaetigung des aktuellen Codes; gespeichert wird nur der Hash
- Neuer Tab "Mein Zugang" in zugaenge.html (nur fuer den Owner)
Co-Authored-By: Claude Opus 5 <[email protected]>
DogFatherGitandClaude Sonnet 5