Die Funktionsliste war eine einzige Tabelle mit 46 Zeilen — in der Reihenfolge,
in der die Sachen entstanden sind, also in keiner. Jetzt ist sie nach denselben
Bereichen sortiert wie das Panel: Inhalte, Community, Moderation, Server, dazu
Plattform fuer alles, was keine Discord-Funktion ist. Wer im Panel etwas sucht,
findet den Abschnitt in der README am selben Platz.
Nachgetragen, was seither dazugekommen ist: AutoMod, Raid-Schutz, verknuepfte
Rollen, native Umfragen, Statusseite, Herzschlag, Seiten-Editor, Englisch fuer
die oeffentlichen Seiten. Und die Trennung in zwei Domains stand bisher gar
nicht drin, obwohl sie das Erste ist, was man verstehen muss — sie steht jetzt
ganz oben, mit einer Tabelle welche Seite was zeigt.
Korrigiert: 35 Module waren es mal, es sind 39. 15 Config-Bereiche waren es
mal, es sind 16. Die Seitentabelle fuehrte Hub-Seiten unter der Bot-Domain.
Die Projektstruktur kannte die Haelfte der Dateien nicht. In der
Ersteinrichtung fehlten die Rechte fuer AutoMod und Kanal-Anlegen sowie die
zusaetzlichen OAuth-Redirects.
Dazu ein Inhaltsverzeichnis, eine docs/README.md als Wegweiser, und in
konzept-zwei-seiten.md steht nicht mehr "muss noch aktiviert werden" — es
laeuft seit Ende Juli.
Geprueft mit einem kleinen Skript: 11 Markdown-Dateien, keine toten
Datei-Links, keine toten Anker, keine Tabelle mit falscher Spaltenzahl.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
/features zeigte bisher dieselbe Landing wie /, obwohl die Navigation und
ein Knopf auf der Startseite eine echte Funktionsliste versprachen.
Die Seite listet jetzt alle 35 Bot-Funktionen, nach denselben Gruppen
sortiert wie im Panel, dazu sechs Punkte zum Drumherum (Webinterface,
Texte, API/SSO, eigene Seiten, Team-Rechte, Betrieb).
Die Einträge kommen über das neue öffentliche /api/features aus
src/modules.js — derselben Quelle, aus der die Modul-Schalter kommen. Eine
neue Funktion erscheint damit automatisch auf der Produktseite, statt dass
jemand daran denken muss. Der Endpunkt gibt bewusst nur Name, Beschreibung
und Gruppe heraus, nicht welche Module hier gerade laufen.
Auch die Zahl auf der Startseite kommt von dort, damit nicht zwei Stellen
dieselbe Zahl pflegen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Die Seite hieß Setup und listete 15 Bereiche flach untereinander. Wer
nicht wusste, dass Geburtstage unter „Community" stecken und Willkommens-
Texte unter „Support", hat geklickt bis er es fand.
Die Seitenleiste gruppiert jetzt nach Überblick, Auftritt, Inhalte,
Community, Technik und Zugang. Darüber steht ein Suchfeld, das nicht nur
Beschriftungen durchsucht, sondern auch Stichwörter je Bereich — „geburtstag"
führt zu Community, „ticket" zu Support. Enter springt zum ersten Treffer.
Der aktive Bereich steht in der Adresse (/settings#texte). Damit überlebt er
das Neuladen, und man kann jemandem einen Link auf genau die Stelle schicken.
Der Status-Bereich war die leerste Seite im ganzen Panel: sechs Zahlen. Er ist
jetzt der Einstieg und beantwortet die Frage, die man beim Öffnen wirklich hat
— was läuft noch nicht? Eingeschaltete Module, denen ein Kanal oder eine Rolle
fehlt, stehen dort mit einem Knopf, der direkt an die richtige Stelle springt.
Ist alles eingerichtet, sagt die Seite genau das.
Umbenannt in „Config", weil „Setup" nach einmaliger Einrichtung klingt — die
Seite ist aber der Ort, an dem man dauerhaft alles einstellt.
Schmale Bildschirme: die Leiste wird zur umbrechenden Zeile ohne
Gruppen-Überschriften, das Suchfeld nimmt die volle Breite.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Eine Anwendung, zwei Gesichter — der Server erkennt an der Domain, welche
Seite gefragt ist, und schreibt das als data-site an den <body>. Das
Frontend rendert daraufhin entweder den Community-Hub wie bisher oder die
neue Produktseite.
- Bot-Produktseite (BotApp): Landing mit Feature-Übersicht, Befehls-
referenz, Dashboard unter /dashboard, Orange als Leitfarbe
- Weiterleitungen: Community-Routen auf der Bot-Domain und umgekehrt
werden dauerhaft (301) auf die richtige Adresse geschickt — geteilte
Devlog-Permalinks laufen also nicht ins Leere. Rechtstexte bleiben auf
beiden erreichbar.
- Open-Graph-Tags je Domain, inklusive eigener Vorschau für frei
angelegte Seiten (Entwürfe bekommen bewusst keine)
- Login: neue Einstellung für die Cookie-Domain, damit die Anmeldung auf
beiden Seiten gilt; nach dem Discord-Login landet man wieder auf der
Seite, von der man gestartet ist (vorher immer auf der Hauptadresse)
- Alles greift erst, wenn beide Adressen im Setup eingetragen sind —
bis dahin verhält sich die Anwendung unverändert
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Kein Einladen-Button: der Bot bleibt auf einen Server ausgelegt, die
Produktseite ist Visitenkarte und Dashboard
- /commits gehört auf den Hub (Projekt-Entwicklung, keine Bot-Verwaltung)
- Bot-Seite bekommt Orange als Leitfarbe statt Gelb — gleiche Marke,
aber beim Domainwechsel sofort erkennbar
- Statt des gewünschten Forums (Burning-Board-Stil) ein Seiten-Editor:
ein Forum neben aktivem Discord verwaist erfahrungsgemäß und bringt
Moderationsaufwand; der eigentliche Wunsch — Inhalte ohne Commit
pflegen zu können — wird mit frei anlegbaren Markdown-Seiten erfüllt
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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>
D4rkst3randClaude Opus 5