Konzept für die Trennung von Bot-Produktseite und Community-Hub

Entwurf zur Abstimmung, noch nichts umgesetzt: Seitenstruktur beider
Domains, Host-Routing statt zweitem Deployment, geteilter Login über
.d4rkst3r.de, Weiterleitungen für alte Permalinks, zwei URL-Einstellungen
statt einer.

Enthält auch die Abwägung zur Repo-Frage: getrennte Repositories würden
bedeuten, dass der Hub für alles, was heute direkter Zugriff ist
(Rollen holen und setzen, Wünsche posten, Monitor-Ergebnisse, Devlogs,
Level), HTTP-Schnittstellen zum Bot braucht — die Web-API nutzt an 33
Stellen den laufenden Discord-Client. Vorschlag stattdessen: ein Repo mit
getrennten Frontend-Ordnern (shared/hub/bot) und zwei Builds.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/konzept-zwei-seiten.md

@@ -0,0 +1,165 @@
+# Konzept: Bot-Produktseite und Community-Hub trennen
+
+**Stand:** 31.07.2026 · Entwurf zur Abstimmung, noch nichts umgesetzt.
+
+## Warum
+
+Heute liegt alles auf `bot.d4rkst3r.de`: Devlogs, Roadmap, Galerie, Level,
+Events, Member-Profile — und die Bot-Einstellungen. Die Adresse führt in die
+Irre. Wer `bot.` liest, erwartet eine Bot-Dokumentation und klickt vielleicht
+gar nicht erst, obwohl dahinter der Community-Hub steckt.
+
+Vorbild sind MEE6 und Carl-bot: eine **Produktseite** erklärt den Bot und
+bietet das Dashboard — die Community-Inhalte leben woanders.
+
+## Aufteilung
+
+### `bot.d4rkst3r.de` — Produktseite
+
+Zielgruppe: Leute, die wissen wollen, was der Bot kann, und du selbst zum
+Konfigurieren.
+
+| Route | Inhalt |
+|---|---|
+| `/` | Landing: „Das kann der Bot" — Hero, Feature-Kacheln, Einladen-Button |
+| `/features` | Alle Funktionen ausführlich, gruppiert (Community, Moderation, Feeds, Server) |
+| `/commands` | Slash-Command-Referenz, aus dem Code erzeugt |
+| `/docs` | Kurzanleitungen: API v1, SSO, Webhooks, Design-System |
+| `/dashboard` | die heutige Setup-Seite (Login + Berechtigung nötig) |
+| `/impressum`, `/datenschutz` | Rechtstexte (auf beiden Domains identisch) |
+
+Die 16 Slash-Commands, die es aktuell gibt: `ping`, `bug`, `wunsch`,
+`geburtstag`, `giveaway`, `rank`, `remind`, `tag`, `warn`, `warns`, `timeout`,
+`purge`, `devlog-backfill`, `galerie-backfill`, `playtester-setup`,
+`ticket-setup`.
+
+### `hub.d4rkst3r.de` — Community
+
+Zielgruppe: Member und Interessierte.
+
+| Route | Inhalt |
+|---|---|
+| `/` | Startseite mit Live-Zahlen, Bereichs-Kacheln, neuestem Devlog |
+| `/devlogs`, `/devlogs/:id` | Archiv mit Volltextsuche und Permalinks |
+| `/roadmap` | Meilensteine, Community-Wünsche, Heatmap |
+| `/server` | Live-Status der Game-Server |
+| `/galerie` | Community-Screenshots |
+| `/level` | XP-Bestenliste und Aktivitäts-Chart |
+| `/events` | Discord-Events |
+| `/changelog` | Releases |
+| `/profil` | eigenes Profil, Rollen-Selfservice, Datenlöschung |
+| `/commits` | Commit-Archiv (nur Owner) |
+| `/feed.xml` | RSS |
+
+## Ein Repo oder zwei?
+
+Naheliegend wäre, für den Hub ein eigenes Repository anzulegen. Davon rate ich
+ab — nicht aus Bequemlichkeit, sondern weil die Community-Seite ohne den
+laufenden Bot gar nicht funktioniert:
+
+* `/api/profile` holt Rollen und Beitrittsdatum live über `guild.members.fetch()`
+* `/api/myroles/toggle` vergibt Discord-Rollen über den Client
+* `POST /api/wishes` postet den Wunsch als Embed in den Voting-Kanal
+* `/api/servers` liest die letzten Monitor-Ergebnisse aus dem Arbeitsspeicher
+  des Bot-Prozesses
+* Devlogs, Level, Galerie, Commits und Events kommen direkt aus der
+  SQLite-Datei, die der Bot schreibt
+
+Insgesamt greift die Web-API an **33 Stellen** auf den laufenden Discord-Client
+zu. Bei getrennten Repos müsste all das über HTTP laufen: Der Hub bräuchte für
+jede dieser Stellen einen API-Endpunkt beim Bot, dazu Authentifizierung,
+Fehlerbehandlung und Zeitüberschreitungen. Die Alternative — beide Anwendungen
+schreiben dieselbe SQLite-Datei — funktioniert nur auf demselben Host und ist
+bei gleichzeitigen Schreibzugriffen fehleranfällig.
+
+Das hieße: deutlich mehr Code, zwei Deployments, zwei Update-Zyklen — für einen
+Betreiber, der alles allein pflegt.
+
+**Vorschlag stattdessen:** ein Repository, aber sauber getrennte Ordner.
+
+```
+src/                 Bot, API, Datenbank  (unverändert)
+frontend/
+  shared/            Design-System, Icons, gemeinsame Komponenten
+  hub/               Community-Seite       → eigener Build
+  bot/               Produktseite          → eigener Build
+```
+
+Zwei getrennte Builds, ein Server liefert je nach Domain den passenden aus. Das
+gibt die gewünschte Klarheit — jede Seite hat ihren eigenen Ordner und ihr
+eigenes Bundle — ohne die Kosten einer echten Trennung. Und falls du den Hub
+später doch herauslösen willst, ist die Grenze dann schon gezogen.
+
+## Technischer Ansatz
+
+**Eine Anwendung, zwei Gesichter.** Ein Container, eine Datenbank. Der Server
+erkennt am `Host`-Header, welche Seite gefragt ist:
+
+* **Backend** (`src/web/server.js`): liefert je nach Host die passenden
+  Open-Graph-Tags aus. Die Injektion dafür gibt es schon, sie bekommt nur eine
+  Fallunterscheidung.
+* **Frontend**: zwei Builds aus `frontend/hub/` und `frontend/bot/`, die sich
+  Design-System und Komponenten aus `frontend/shared/` teilen. Der Server
+  liefert je nach Domain das passende `index.html` aus.
+* **API** bleibt unverändert und für beide Domains erreichbar.
+
+### Alte Links auffangen
+
+Geteilte Devlog-Permalinks zeigen heute auf `bot.d4rkst3r.de/devlogs/…`. Diese
+Adressen dürfen nicht ins Leere laufen: Ruft jemand eine Community-Route auf
+der Bot-Domain auf, antwortet der Server mit einer dauerhaften Weiterleitung
+(301) auf dieselbe Route unter `hub.`. Umgekehrt ebenso für `/dashboard`.
+
+### Login über beide Domains
+
+Damit man sich nur einmal anmeldet, wird das Sitzungs-Cookie künftig für
+`.d4rkst3r.de` gesetzt statt nur für `bot.`. Dann gilt es auf beiden
+Subdomains.
+
+Was das bedeutet: Das Cookie wird technisch auch an `git.` und `cdn.`
+mitgesendet. Die ignorieren es, aber es verlässt damit die eine Anwendung.
+Vertretbar ist das, weil es signiert und für JavaScript unlesbar ist
+(`httpOnly`) — mitlesen könnte es nur, wer bereits Serverzugriff auf einer
+Subdomain hat. Umgesetzt wird es als Einstellung, damit es sich zurückdrehen
+lässt.
+
+### Neue Einstellungen
+
+Heute gibt es genau eine „Öffentliche URL". Nach der Trennung braucht es zwei:
+
+| Einstellung | Zweck |
+|---|---|
+| `hub_url` | Community-Adresse — speist Devlog-Buttons, RSS, Open-Graph-Bilder, `brand-nav.js` |
+| `bot_url` | Produktseite — Ziel für Dashboard-Links und OAuth-Rücksprung |
+
+Alles, was heute `publicUrl()` benutzt, wird auf `hubUrl()` umgestellt; nur die
+Login-Umleitung und Dashboard-Verweise nutzen `botUrl()`.
+
+## Was zu tun ist
+
+1. **Kanban von `hub.` entfernen** — dort läuft noch das alte Board.
+2. **Proxy:** `hub.d4rkst3r.de` auf denselben Container zeigen lassen wie `bot.`
+3. **Discord-Portal:** Redirect-URI für beide Domains eintragen
+4. Frontend in `shared/`, `hub/` und `bot/` aufteilen, zwei Builds einrichten
+5. Host-Routing in Backend und Frontend (siehe oben)
+6. Bot-Landing, Feature- und Command-Seite bauen
+7. Setup-Seite nach `/dashboard` umhängen
+8. Weiterleitungen für alte Links
+9. Cookie-Domain umstellen
+10. `hub_url`/`bot_url` in den Einstellungen ergänzen und alle Verwendungen umziehen
+
+Schritte 1–3 machst du, 4–10 übernehme ich. Aufwand geschätzt: Schritt 4 und 5
+sind der größte Block (Umbau der Ordnerstruktur), 6 ist reine Neuentwicklung,
+der Rest sind Kleinigkeiten.
+
+## Offene Fragen
+
+* **Soll die Bot-Seite den Bot zum Einladen anbieten?** Ein „Auf deinen Server
+  einladen"-Button hieße, dass Fremde den Bot nutzen können. Dafür müsste er
+  mit mehreren Servern umgehen — aktuell ist er auf einen ausgelegt. Ohne
+  Button wird die Seite zur Visitenkarte („so ist er gebaut"), was für ein
+  Portfolio auch Sinn ergibt.
+* **Gehört `/commits` auf den Hub oder auf die Bot-Seite?** Vorschlag: Hub, es
+  gehört zur Projekt-Entwicklung.
+* **Braucht die Bot-Seite eine eigene Farbnote**, um sich vom Hub abzuheben —
+  oder bleibt beides identisch gebrandet?