- 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]>