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 Opus 5