Die Abholung laeuft taeglich um 03:30 -- nach der Sicherung des Bots (ab 03:00)
und vor der von d4rk_media (04:30), damit nicht zwei Vorgaenge gleichzeitig auf
derselben Platte arbeiten.
Ueber die geplante Aufgabe gemessen, nicht von Hand: Ergebnis 0, Archiv auf
Platte Nr. 1 statt Nr. 0, Pruefsumme identisch, 55 Tabellen und 86
Einstellungen im ausgepackten Archiv, last_zweitziel steht in der Datenbank.
Zwei Dinge liegen ausserhalb des Repos und stehen deshalb im Bericht, damit sie
nach einem Neuaufsetzen nicht fehlen: die Arbeitskopie unter
Desktop\d4rkbot (vorher gab es gar keine, der Bot lief nur aus Portainers
Checkout) und die Aufgabe "d4rkbot Sicherung abholen". Sie startet pwsh ueber
den stabilen Ausfuehrungsalias und nicht ueber den Pfad mit Versionsnummer --
genau daran hing bei d4rk_media eine Sicherung, die beim naechsten
PowerShell-Update aufgehoert haette zu laufen.
Offen bleibt: beide Kopien liegen im SELBEN RECHNER. Gegen einen Plattenausfall
hilft das jetzt, gegen Feuer oder eine verschluesselte Maschine nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei falsche Diagnosen hintereinander, beide aus einem Zwischenstand
geschlossen, waehrend der Vorgang noch lief. Was wirklich passiert ist:
12:48:18 Push 93156e5
12:48 Portainer hat die Dateien im Stack-Verzeichnis
12:57 hier gemessen: Abbild 15 h alt, Container von gestern
-> daraus "er baut nicht" geschlossen. FALSCH.
13:01:02 Abbild neu gebaut
13:01:14 Container neu gestartet
13:02 pruefeSicherung im Container: 2, melden.js da, Panel HTTP 200
Zwischen Push und laufendem neuen Code liegen rund DREIZEHN MINUTEN -- Portainer
fragt in Intervallen nach, nicht sofort. Die Messung um 12:57 fiel mitten in
dieses Fenster: die Dateien waren schon da, das Abbild noch nicht neu. Aus dem
Schnappschuss habe ich einen Systemfehler gemacht.
Das ist genau der Fehler, gegen den der Bericht geschrieben ist -- eine
plausible Erklaerung, die zum Schnappschuss passt, behauptet, bevor der Vorgang
zu Ende war.
pull_policy: build bleibt drin, aber NICHT mehr aus dem Grund im Commit davor.
Es repariert nichts; es macht das Neubauen nur ausdruecklich, damit ein
handgetipptes `docker compose up -d` dasselbe tut wie die Automatik. Folgenlos
entfernbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der erste Verdacht ("kein Runner") war die halbe Wahrheit. Portainers
GitOps-Weg funktioniert, nachgemessen in seinem eigenen Datenverzeichnis:
/d/compose/1/src/melden.js 12:48 <- die Uhrzeit des Pushes
/d/compose/1/stack.env 12:57 <- Portainer hat neu geschrieben
docker images d4rkbot:latest 00:21 <- das Abbild 15 Stunden alt
Portainer holt den neuen Stand also brav ins Stack-Verzeichnis und ruft dann
docker compose up -d. UND DAS BAUT NUR, WENN DAS ABBILD FEHLT. d4rkbot:latest
gab es -- also kein Bau, kein neuer Container, und der Bot lief weiter mit dem
Code von vorgestern.
Kein Runner, kein Webhook, keine Fehlermeldung: es sah nach "nichts zu tun"
aus. Das ist die unangenehme Sorte Fehler -- man pusht, hakt es ab, und der
Fehler, den man gerade behoben hat, laeuft weiter.
pull_policy: build laesst compose bei jedem Ausrollen neu bauen. Geprueft mit
docker compose config (v5.3.1 nimmt es an und gibt es aufgeloest zurueck).
Einmal noch von Hand, denn die Zeile wirkt erst, wenn sie selbst ausgerollt
ist: Portainer -> Stack ecobot -> Pull and redeploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach dem Push von 93156e5 nachgesehen, ob der Bot den neuen Stand bekommt:
Push registriert updated_at 12:48:18Z
Workflow-Laeufe "total_count": 0 <- keiner, nie
Act-Runner auf dem Wirt kein Container
d4rkbot neu gestartet? nein, laeuft seit 11.08. 22:21
Code im Container grep pruefeSicherung -> 0
has_actions ist am Repo AN, es gibt also nur niemanden, der die Laeufe
abarbeitet -- und der Webhook-Weg, der ohne Runner auskaeme, ist offenbar auch
nicht eingerichtet.
Pushen allein rollt also nichts aus. Das gehoert aufgeschrieben, weil ein
Deploy, von dem man GLAUBT dass er laeuft, schlimmer ist als gar keiner: man
pusht, hakt es ab, und der Fehler, den man gerade behoben hat, laeuft weiter.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Befund 2, 3 und 4 aus docs/befunde-2026-08-12.md. Befund 1 bleibt offen, Befund
5 war falsch und ist zurueckgezogen.
DER BOT SAGT JETZT BESCHEID. src/melden.js ist neu und enthaelt, was vorher in
watchdog.js eingeschlossen war: dmAdmin. Genau deshalb hat alles andere im Bot
geschwiegen oder in die Konsole geschrieben -- und eine Konsolenzeile in einem
Container liest niemand.
Dazu dmAdminEinmalig: meldet nur bei ZUSTANDSWECHSEL. Sonst wuerde eine
Pruefung, die alle zehn Minuten laeuft, denselben Ausfall alle zehn Minuten
melden, und nach der dritten DM liest man sie nicht mehr. Der Merker steht in
den Einstellungen und nicht im Arbeitsspeicher -- ein Bot, der nach jedem
Update neu startet, haette sonst nach jedem Update wieder eine frische Meinung.
Gemessen gegen eine KOPIE der Datenbank, sechs Schritte, alle wie beabsichtigt.
DER WACHHUND AUF last_backup. pruefeSicherung() meldet, wenn die letzte
Sicherung aelter als 26 Stunden ist, wenn sie fehlgeschlagen ist, oder wenn es
nie eine gab. Im Fehlerfall steht NICHT last_backup als Zeitpunkt im Embed: der
wird nur bei Erfolg gesetzt, dort staende also der letzte GUTE Lauf, und das
liesse die Sicherung frischer aussehen als sie ist.
DER TAG FAELLT NICHT MEHR AUS. Vorher "if (now.getHours() !== 3) return" -- wer
waehrend dieser einen Stunde unten war, hatte den Tag verloren, und ein Bot,
der nach jedem Update neu startet, ist genau dieser Fall. Jetzt zaehlt nur: es
ist nach 03:00 und heute war noch keine.
DAS ARCHIV WIRD AUSGEPACKT UND GEZAEHLT. integrity_check plus Tabellenzahl
gegen die laufende Datenbank. Faellt das durch, wird das Archiv GELOESCHT (im
Sicherungsordner saehe es sonst aus wie eine Sicherung), die Rotation laeuft
nicht, und last_backup bleibt stehen.
An echten Archiven gemessen, mit zwei Gegenproben, damit die Pruefung nicht nur
"ja" sagen kann:
2026-08-10 817 KB 54 Tabellen 86 ms
2026-08-11 886 KB 54 Tabellen 64 ms
2026-08-12 970 KB 55 Tabellen 78 ms (laufend: 55)
halbes gzip -> "unexpected end of file"
Muell -> "incorrect header check"
Die 54 gegen 55 sind kein Fehler, sondern eine gewachsene Tabelle zwischen dem
11. und dem 12. Verglichen wird zeitgleich, also stoert das nicht -- wissen
sollte man es, bevor jemand alte Archive gegen die heutige Zahl haelt.
BEFUND 5 WAR FALSCH. pruneMessageCache wird sehr wohl aufgerufen, taeglich, in
mod-tools.js:239 -- und stand schon zum Zeitpunkt der Durchsicht dort. Gezaehlt
wurden "Aufrufe ausserhalb von db.js", und die Sammel-Importzeile ist als
Import durchgegangen, waehrend der Aufruf zwanzig Zeilen tiefer nicht mitkam.
Das ist genau der Fehler, den zu vermeiden dieser Bericht dasteht; die anderen
vier sind deshalb einzeln nachgemessen worden und stimmen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gesucht wurde nach denselben Fehlermustern, die beim Bau von d4rk_media
aufgefallen sind. 24105 Zeilen liest niemand am Stueck; gesucht wurde gezielt
nach nie aufgerufenen Aufraeumfunktionen, Wachen an '*', SQL mit eingesetzten
Zeichenketten, fetch auf fremde Adressen, ungelesenen Antwortkoerpern,
Schleifen mit Zeitlimit und Sicherungen ohne Gegenprobe.
AN DIESEM BOT WURDE NICHTS GEAENDERT. Die Entscheidungen gehoeren dem
Betreiber.
DER WICHTIGSTE BEFUND: Datenbank (5,0 MB) und alle vierzehn Sicherungen
(5,7 MB) liegen im SELBEN Volume ecobot_ecobot_data. Geht es verloren, geht
beides zusammen verloren -- das ist keine Sicherung, das ist eine Kopie. Der
eingebaute Ausweg (Upload in einen privaten Discord-Kanal) laeuft nie, weil
backup_channel_id nicht gesetzt ist.
DAZU: niemand prueft last_backup. Es wird geschrieben und im Panel ANGEZEIGT,
aber nichts vergleicht es mit heute. Und weil der Zeitplan auf getHours() === 3
steht, faellt der Tag still aus, wenn der Bot waehrend dieser Stunde unten ist
-- bei einem Bot, der nach jedem Update neu startet, kein Sonderfall. Die
Maschinerie dafuer ist vollstaendig da (dmAdmin, brandEmbed, Incidents) und
wird nicht benutzt.
WEITER: "zu gross fuer Discord" endet in einem console.warn, das niemand liest;
die Archive wachsen um rund 70 KB je Tag auf eine Grenze von 9 MB zu. Das
Archiv wird nie ausgepackt und gegengeprueft. Und pruneMessageCache wird
nirgends aufgerufen -- exakt dasselbe Muster wie pruneEvents in d4rk_media,
heute mit 18 Zeilen harmlos.
WAS GEPRUEFT WURDE UND IN ORDNUNG IST, damit es niemand ein zweites Mal prueft:
db.backup() statt Dateikopie ist richtig und WAL-sicher; das gefaehrlich
aussehende ORDER BY ${ord} ist eine feste Weissliste; die oeffentliche
Serverliste zaehlt ihre Felder einzeln auf; die zwei bekannten Geheimnisse
gehen nur als Ja/Nein hinaus; der Spielserver-Monitor nutzt bereits
Promise.all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher gab es fuer Mods nur einen Link auf das Sammelpaket des Hosters — vier
Gigabyte, auch wenn sich zwei Dateien geaendert haben. Jetzt liest der Bot die
Modliste aus der Statusabfrage, die er ohnehin holt, und meldet im Kanal, was
neu, aktualisiert oder entfernt wurde. Beim ersten Durchlauf bleibt es still,
sonst kaeme eine Meldung ueber 110 "neue" Mods.
Geaendert heisst: andere Version oder anderer Hash. Beides einzeln reicht
nicht — manche Modder bessern nach, ohne die Version zu erhoehen.
Dazu die Seite /mods/<server>: jeder Mod mit Version und Groesse, Suche ueber
Titel, Dateiname und Autor, und ein Download je Zeile. Der laeuft durch den
Bot, damit der Zugangs-Code des Spielservers nicht in einem Link landet — mit
dem Code liesse sich auch der ganze Spielstand lesen. Angefragt wird nur, was
wirklich in der Modliste steht; ueber den Dateinamen kommt man an nichts
anderes heran.
Groessen lernt der Bot beim Weiterleiten. Der Spielserver beantwortet kein
HEAD (501) und ignoriert Range, es gibt also keinen billigen Weg, sie vorher
zu erfahren — und 4 GB nur fuers Anzeigen zu holen waere keiner.
Nebenbei gefunden und behoben: 'server.mods' und 'commands.tag' gab es je
zweimal in den Sprachdateien. Der spaetere Eintrag gewinnt still, deshalb
stand auf dem neuen Knopf woertlich "%s Mods (110)" und auf der Befehlsseite
die Beschreibung von /tag statt der Kopfzeile.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Fuhrpark stand bisher nur als Gesamtzahl im Karten-Embed. Jetzt bekommt
jeder Hof eine eigene Nachricht im selben Kanal, die bei jedem Durchlauf
bearbeitet statt neu gepostet wird: Land, Fahrzeuge mit Wert und
Betriebsstunden, was in die Werkstatt muss, was gewaschen gehoert und was
geladen ist.
Die Fahrzeuge kommen aus vehicles.xml, blockweise gelesen — Verschleiss und
Schmutz stehen in Kindelementen und gehoeren sonst dem falschen Fahrzeug.
Gemietete Missionsfahrzeuge bleiben draussen, sie verfaelschen Anzahl und
Wert. Faellt die Datei einmal aus, bleiben die Embeds stehen, statt dass ein
Hof verschwindet und gleich darauf doppelt gepostet wird.
Damit tauchen auch Hoefe auf, die noch kein Land gekauft haben: die Liste der
Hoefe kommt aus Parzellen und Fuhrpark zusammen.
Dazu raus, was nur den Kanal vollgeschrieben hat: die Meldung zum
Monatswechsel und die zum Landkauf. Der Monat wird still weitergestellt — er
steht ohnehin im Embed. Damit faellt der Ereignis-Kanal weg und mit ihm die
gespeicherte Besitzliste.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Bot rief einen neuen Monat aus, obwohl im Spiel keiner war. Zwei Fehler,
die zusammen genau das ergeben:
statsLesen las die Uhrzeit als `Number(server.dayTime) || 0`. Eine Antwort
ohne dayTime — Server startet neu, Proxy schiebt eine Fehlerseite dazwischen,
XML halb geschrieben — wurde damit zu 0. Und tagUmgeschlagen prueft auf
`jetzt < vorher`. Null ist kleiner als jeder Vortagswert, also sah jede
kaputte Antwort wie Mitternacht aus.
Beides behoben: fehlt die Angabe, ist sie jetzt null und nicht 0 — "weiss
nicht" ist kein Tageswechsel. Und ein Wechsel muss die Form eines echten
Mitternachtssprungs haben: vom spaeten Abend in den fruehen Morgen, beide
Werte innerhalb eines Tages. Ein Zappeln um ein paar Minuten faellt jetzt
durch. Eine Antwort ohne Uhrzeit ueberschreibt ausserdem den letzten guten
Stand nicht mehr, sonst ginge der echte Sprung danach verloren.
Beim Nachmessen zeigte sich, dass meine Doku an der Stelle falsch war: dayTime
ist nicht live, sondern ein Schnappschuss. Fuenf Abrufe ueber zwei Minuten mit
einem Spieler online ergaben denselben Wert (37028620) — der Server schreibt
das XML im "Web API Interval" neu, hier alle 360 Sekunden. Steht jetzt richtig
in docs/ls-feed.md, samt dem verbleibenden Restrisiko: ein Serverneustart
setzt die Uhr auf den gespeicherten Stand zurueck und kann in seltenen Faellen
einen Monat zu viel zaehlen.
Geprueft: echter Sprung, normaler Tagesverlauf, Erstlauf, fehlende Angabe als
0/null/NaN, kleiner Ruecksprung, Ruecksprung am Vormittag, unsinnige Groessen,
und dass eine fehlende dayTime im XML als null ankommt statt als 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Kanalauswahl blieb leer, obwohl "einsatzbereit" gruen daneben stand — ein
Widerspruch, der die Ursache schon verraet: der Wert lag in der Datenbank, das
Formular bekam ihn nur nie zu sehen. Ich hatte beim letzten Mal das Speichern
repariert und uebersehen, dass currentSettings() dieselbe von Hand gepflegte
Liste fuehrt. Jetzt holt auch sie die Schluessel aus dem Modul-Register.
Geheimes bleibt aussen vor: gitea_api_token steht unter requires, faellt aber
durch die Namenspruefung und wird weiterhin nur als "ist gesetzt" gemeldet.
Dazu die Uebersetzung. Im Embed standen wheat, clover_windrow und seeds, weil
der Feed nun mal Englisch spricht. Jetzt Weizen, Rotklee (Schwad) und Saatgut,
mit lesbarem Rueckfall fuer alles, was nicht in der Liste steht — 371 Sorten
uebersetzt niemand von Hand.
Und der Monat. Die zwoelf Perioden sind schlicht Monate, EARLY_SPRING ist
Maerz. Also nimmt das Feld jetzt "September", "sept" oder "9" statt
EARLY_AUTUMN; Mehrdeutiges wie "Ju" wird abgelehnt statt geraten.
Weiterzaehlen kann der Bot selbst, seit klar ist, dass ein Monat ueber einen
Tag laeuft. Nicht ueber playTime — die steht im Savegame und wird nur beim
Autosave geschrieben: ueber zwei Stunden gemessen stieg sie um 50, waehrend
die Spieluhr 18,7 Stunden weiterlief. dayTime in der Statusabfrage ist dagegen
live, und jeder Ruecksprung um Mitternacht ist ein Monatswechsel. Steht der
Server leer, steht die Spielzeit — und der Monat bleibt richtigerweise stehen.
Geprueft: alle zwoelf Monate hin und zurueck, Abkuerzungen, Monatszahlen,
Mehrdeutiges, acht Sorten Unsinn, der Jahreswechsel von Februar auf Maerz, der
Ruecksprung um Mitternacht samt Erstlauf, und dass jede Sorte der
Standardauswahl einen deutschen Namen hat.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Parzellen lagen im Wald. Ich hatte -mapSize/2 bis +mapSize/2 angenommen —
naheliegend beim Namen, aber falsch: die Koordinaten laufen von -mapSize bis
+mapSize. Damit wurde jede Parzelle um Faktor zwei vom Mittelpunkt weggezogen.
Schlimmer als der Fehler war meine Pruefung. Der Zonentest hat die Koordinaten
auf ihre eigene Bounding-Box normiert und danach geschaut, ob die Felder in der
richtigen Ecke liegen. Das besteht bei JEDEM Massstab, weil die Anordnung
zueinander ja stimmt. 14 von 15 Treffern klangen ueberzeugend und sagten
ueber den Massstab genau nichts aus.
Gemessen wurde es dann so: die eingebrannte Legende steht sowohl im Feed-Bild
als auch im Ingame-Screenshot, damit laesst sich der eine aufs andere
umrechnen. Vier Parzellen an den vier Ecken ergaben eine Weltbreite von 7822
bei mapSize 4096 — Faktor 1,91 bei rund 5 Prozent Ablesegenauigkeit.
Dabei ist noch etwas herausgekommen: die Marken H1..H8 auf dem Luftbild sind
als Passpunkte hervorragend, nicht wertlos, wie ich in der Doku behauptet
hatte. Mit richtigem Massstab liegen alle acht Hofparzellen unter 13 px von
ihrer Marke; mit falschem rund 200. Das ist jetzt der Test — acht Passpunkte,
die jede kuenftige Verschiebung sofort auffliegen lassen, statt eines
Zonenvergleichs, der alles durchwinkt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Feed eines LS-Servers gibt viel mehr her als die Spielerzahl, die der
Monitor bisher davon benutzt hat: in denselben 49 KB stehen 163 Parzellen mit
Besitzer und Hektar, 130 Felder, jedes Fahrzeug samt Ladung und die Position
jedes Spielers. Und das Luftbild liefert der Server auch, in jeder Groesse bis
4096.
Also eine Karte: gekaufte Parzellen nach Hof eingefaerbt, Kreisflaeche gleich
Hektar, Fahrzeuge und Spieler live, dazu eine Hof-Uebersicht mit Flaeche und
Wert. Wechselt Land den Besitzer, kommt eine Meldung — beim allerersten
Durchlauf bewusst nicht, sonst haette der Botstart eine Meldung pro bereits
gekaufter Parzelle abgesetzt.
Dazu die Preiskurven aus der economy.xml: je Fruchtart, was sie in welcher der
zwoelf Perioden bringt, als Balkenzeile mit "jetzt verkaufen" oder "+43 Prozent
im Hochwinter".
Was NICHT geht, und zwar grundsaetzlich: welche Frucht auf welchem Feld steht
und wie weit sie ist. Das liegt in einer binaeren Density-Map, die kein
Endpunkt herausgibt. Ich habe 18 Dateinamen durchprobiert, es gibt genau drei.
Die Mods, die das anzeigen, sind reine HUD-Overlays ohne Ausgang. Und keiner
der fuenf anderen LS-Bots kann es, obwohl einer davon Geld kostet. Das steht
mit allen Belegen in docs/ls-feed.md, damit die Frage nicht dreimal kommt.
Beim Bauen aufgefallen:
- istLsServer() gab den Zugangs-Code zurueck statt true — die &&-Kette liefert
den letzten wahren Wert. Beim ersten Log-Aufruf haette der Code im Klartext
im Protokoll gestanden.
- Die Karte als PNG war 2,5 MB, als JPEG 268 KB. Es ist ein Luftbild.
- Nach Preisschwankung sortiert gewinnt Spargel: 26 bis 7540 Euro, und Weizen
taucht gar nicht mehr auf. Die Liste arbeitet jetzt mit einer Auswahl.
- Die Jahreszeit steht in keinem Endpunkt. Schaetzbar waere sie, aber nur
solange niemand die Zeitskala aendert — also eine Einstellung.
Geprueft gegen echte Serverdaten: Zerlegen der Statusabfrage inklusive
Vollstaendigkeit aller 163 Parzellen, Ladung ohne Diesel und leere Slots,
Hof-Uebersicht ohne verlorene Parzellen, Preiskurve mit vollem und leerem
Balken an der richtigen Stelle, flache Kurve ohne Division durch Null,
Besitzwechsel inklusive Erstlauf und neu hinzugekommener Parzelle,
Hof-Namen aus der Einstellung, SVG ohne NaN und mit maskierten Namen, und der
Merker in der Datenbank inklusive kaputtem JSON.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LS25 fehlte, aber nicht nur LS25: die Auswahl im Panel war eine von Hand
gepflegte Liste mit neunzehn Eintraegen, und fuenf davon gab es bei gamedig
gar nicht — "arkse", "ark", "sevendaystodie", "minecraftbe" und "terraria".
Wer eines davon auswaehlte, bekam einen Server, der dauerhaft offline stand,
ohne dass irgendwo ein Grund stand. Die echten IDs heissen ase, sdtd, mbe und
terrariatshock.
Also nicht LS25 nachtragen, sondern die Liste abschaffen: sie kommt jetzt aus
gamedig selbst, 360 Eintraege, sortiert, mit Suche. Jedes Update bringt neue
Spiele automatisch mit. Dazu der Standard-Query-Port als Vorschlag, sobald man
ein Spiel waehlt. Bestehende Eintraege mit den toten IDs werden beim Start
einmalig umgebogen.
Farming Simulator hat noch eine zweite Huerde: der Server antwortet nur mit
Zugangs-Code, und den hat queryServer nie durchgereicht. LS25 waere also auch
mit richtiger ID offline geblieben. Jetzt gibt es eine Spalte dafuer, das Feld
erscheint nur bei Spielen, die einen brauchen (Farming Simulator, Terraria —
bei Satisfactory optional), und Speichern ohne Code wird abgelehnt statt
stillschweigend hingenommen. Der Code steht nicht in der oeffentlichen API.
Nebenbei aufgefallen: input[type=password] war im CSS nirgends erfasst. Das
erste solche Feld kam voellig ungestylt daher.
Die /server-Seite dazu:
- Auslastungs-Balken mit eigener Farbe statt des XP-Balkens vom Level-System.
Gruen frei, gelb ab 80 Prozent, rot voll — die Zahl steht rechtsbuendig,
mittig laege sie bei 50 Prozent genau auf der Fuellkante.
- Map, Version und Ping als Chips. Vorher standen sie mit Punkten getrennt in
der Statuszeile und wurden auf dem Handy zu Brei.
- Wer gerade drauf ist. Die Namen holt der Monitor ohnehin schon fuers Embed,
auf der Seite standen sie nur nirgends.
- Welches Spiel es ueberhaupt ist. Das stand nirgends ausser im Emoji.
- Offline-Karten waren bisher leer bis auf das Wort. Jetzt steht dort, seit
wann — soweit der Verlauf reicht, sonst gar nichts statt einer Schaetzung.
- Zeitachse und Peak-Linie am Verlauf. Eine Flaeche ohne Bezugspunkt sagt
nicht, wie hoch hoch ist.
- Plaetze insgesamt in der Uebersicht oben.
Geprueft: Token speichern und aendern, Spielnamen inklusive unbekannter ID,
Token-Bedarf pro Protokoll, Liste ohne Doppler, alle Icon-Schluessel gegen
gamedig, "zuletzt online" ignoriert Offline-Proben, und die Migration mit einer
Datenbank im alten Stand. Beide Seiten am laufenden Frontend angesehen, auch
auf Handybreite.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Bewusst Discords eigenes Poll-Objekt statt einer Nachbildung mit Knoepfen —
Oberflaeche, Auszaehlen und Ergebnisanzeige macht Discord dann selbst, auch
auf dem Handy. Wir bauen nur die Frage zusammen.
Bis zu vier Antworten (Discord erlaubt zehn, vier halten den Befehl
uebersichtlich), Laufzeit von einer Stunde bis einer Woche, Mehrfachauswahl
optional. Rechte: ManageMessages.
Zwei gleiche Antworten werden abgefangen. Discord stoert das nicht, aber
abstimmen kann darauf niemand sinnvoll.
Nicht zu verwechseln mit /wunsch: das sammelt Feature-Wuensche dauerhaft und
zeigt sie auf der Roadmap. /umfrage ist die schnelle Frage zwischendurch und
laeuft von selbst ab. Steht so auch als Kommentar im Befehl.
Geprueft gegen die installierte discord.js-Fassung (14.27) statt gegen die
Dokumentation: Feldnamen aus den Typdefinitionen gelesen, und die fertige
Nutzlast durch discord.js' eigene Serialisierung gejagt. Kommt als
poll_media / allow_multiselect / layout_type 1 raus, genau wie Discords API
es erwartet.
Dazu: 18 Befehle laden ohne Namenskollision, Befehl steht auf der
oeffentlichen Liste in beiden Sprachen, Zahl auf der Produktseite von 17
auf 18.
Nutzungsbedingungen als Entwurf unter docs/ — Text fuer den Seiten-Editor,
keine Rechtsberatung.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Zwei Stellen, an denen die Marke bisher fehlte.
Willkommens-Karte: Das Wasserzeichen war der Markenname als Text mit 5 %
Deckkraft — jetzt der Katzenkopf. Die Datei wird einmal beim Start gelesen
statt bei jedem Beitritt, und fehlt sie, rendert die Karte wie bisher ohne
Wasserzeichen. Der Schalter heisst entsprechend "Logo im Hintergrund".
Link-Vorschau: og:image war nur gesetzt, wenn ein Devlog einen Screenshot
hatte. Startseite, Roadmap, Funktionen und jedes Devlog ohne Bild kamen in
Discord als graue Textzeile. Jetzt faellt alles ohne eigenes Bild auf
og-default.png zurueck (1200x630, Lockup auf Schwarz mit Akzentstreifen),
und twitter:card ist durchgehend summary_large_image.
Die Laufzeit-Datei liegt unter src/bot/assets/, nicht in docs/ — das
Dockerfile kopiert nur src/ und frontend/dist/.
Geprueft: librsvg zeichnet das eingebettete <image> wirklich (42726 Pixel
unterscheiden sich gegen eine Fassung ohne), das OG-Bild landet im dist.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Zwei Korrekturen am vorigen Commit:
- Ich hatte das Maskottchen durchgehend als Wolfskopf beschrieben. Es ist eine
Katze. Betrifft README und die Kommentare in build.py.
- Gitea setzt neben favicon.svg noch ein <link rel="alternate icon"> auf
favicon.png. Die Datei fehlte, dort stand also weiter die Gitea-Tasse —
am Livesystem geprueft, das Bild kam in Gitea-Gruen (96,153,38) zurueck.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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 Opus 5