Das Logo lag bisher nirgends im Einsatz — das Favicon war ein handgeschriebenes
Prisma in Gold/Orange, das Wasserzeichen der Willkommens-Karte der blosse
Markenname als Text.
- docs/brand/ mit lockup.png (volles Logo) und mark.png (nur der Wolfskopf)
plus build.py, das beide und alle abgeleiteten Icons erzeugt
- frontend: favicon.svg ersetzt, apple-touch-icon.png dazu und verlinkt
- Zwei Fassungen, weil das Lockup bei 16 px zu einem orangen Balken wird; der
Kopfzuschnitt wurde gegen drei Varianten geprueft
- SVG mit eingebettetem PNG statt Vektorisierung: das Original hat Verlaeufe
und Schattierung, nachgezeichnet wuerde es matschen
- Die Icons auf dunklem Grund sind deckend, sonst legt iOS hinter transparente
Lesezeichen Schwarz oder Weiss und der Wolf ist selbst fast schwarz
Geprueft: beide Dateien werden mit korrektem MIME-Typ ausgeliefert und das SVG
rendert wirklich (128x128), die Link-Tags stehen im gebauten HTML.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Text für den Devlog-Post über hub.d4rkst3r.de: eigene Adresse, Wegweiser
zwischen Hub und Bot-Seite, die neuen Eingabefenster bei /bug und /wunsch,
frei angelegte Seiten. Bilder liegen unter A:\eco\devlog-hub-bilder.
Bewusst ohne Wiederholung des Posts von heute früh — Startseite,
Server-Verlauf, Profil und Willkommens-Karten stehen dort schon.
Co-Authored-By: Claude Fable 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>
In Gitea ist fast jeder Text ein Link (a { color: var(--color-primary) }),
eine Aktivitätsseite besteht praktisch nur daraus. Das volle #f5c518 hat
90 % Sättigung — als Akzent gedacht, nicht für Fließtext, und blendet
entsprechend.
Links, Flächen und Tönungen nutzen jetzt ein entsättigtes Gold (#dcc275,
47 % Sättigung, Kontrast 11:1 auf Schwarz). Das Neon bleibt den Stellen
vorbehalten, wo es wirken soll: Primär-Buttons, aktive Navigation und
Hover — Links leuchten also erst auf, wenn man draufzeigt.
Die Abstufungen (dark-1..7, light-1..7) sind passend zur neuen Basis neu
berechnet. Oben in der Datei steht, wie sich die Intensität nachjustieren
lässt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Repo-Backups: nachts um 04:00 werden alle Gitea-Repos als git-Bundle
gesichert — eine Datei pro Repo mit kompletter Historie, aus der sich
direkt wieder klonen lässt. 14 Tage Rotation wie beim DB-Backup,
Schalter und "Repos jetzt sichern" im System-Tab. Nutzt den bereits
vorhandenen Gitea-Token; Dockerfile installiert dafür git mit.
- Gitea-Theme im D4RKST3R-Look (docs/gitea-theme/): Neon-Gelb/Orange auf
Schwarz, gebaut gegen die Variablen von Gitea 1.26, Diff-Farben bleiben
lesbar. Einbau-Anleitung liegt daneben.
- Auto-Deploy statt manuellem "Pull and redeploy": Workflow für Gitea
Actions (prüft Server-Syntax und Frontend-Build, bevor deployed wird)
plus dokumentierter Runner-loser Weg über den Portainer-Webhook.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Dienste (Gitea, Kanban, Cloud …) werden im System-Tab gepflegt und
erscheinen als Kacheln auf der Startseite; GET /api/services ist
öffentlich, Pflege braucht den settings-Scope
- /brand.css liefert die Design-Tokens (Farben live aus dem Brand-Tab,
ändern sich damit überall mit) plus Basis-Klassen d4rk-card,
d4rk-btn, d4rk-title, d4rk-tag
- /brand-nav.js baut die D4RKST3R-Leiste in jede fremde App ein, mit
Links zum Hub und zu allen gepflegten Diensten; die Links stecken
fertig im Skript, dadurch kein zweiter Request und kein CORS nötig
- Beide Dateien mit offenem CORS-Header und 5 Minuten Cache
- Doku für Anbindung + Schriften in docs/sso.md ergänzt
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Andere Apps (Kanban, Platform …) nutzen ab sofort den Discord-Login des
Bots mit, statt jeweils eigenes OAuth zu bauen — und bekommen die
Discord-Rollen des Users gleich mitgeliefert.
Ablauf: App leitet auf /sso/authorize weiter, der Bot prüft die Session
(ggf. erst Discord-Login) und schickt einen signierten Token zurück, den
die App serverseitig per POST /sso/verify gegen die Nutzerdaten tauscht.
Sicherheit:
- Rücksprung-Ziele müssen einem registrierten Präfix entsprechen
(kein Open Redirect, kein Token-Abgriff über fremde Hosts)
- Token HMAC-signiert, 60 Sekunden gültig, nur einmal einlösbar
- Verify braucht das App-Secret (timing-safe verglichen)
- SSO bleibt Mitgliedern des Discord-Servers vorbehalten
- App-Verwaltung ist Owner-only, Secret wird nur einmal angezeigt
Dazu: sso_apps-Tabelle, Verwaltung im API-Tab, Rücksprung nach dem
Login (return-Cookie, nur interne Pfade), Anleitung in docs/sso.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
D4rkst3randClaude Fable 5