Der erste echte Lauf des internen Deploy-Blocks (28.08.2026) förderte zwei
harmlose, aber verunsichernde Punkte zutage:
- npm ci warnt "allow-scripts ... better-sqlite3": Die allowScripts-Sperre
blockiert den nativen Build, aber prebuild-install liefert ein fertiges
Binary. Dienst lädt danach die DB einwandfrei -> in Ordnung. Als Kontrolle
dokumentiert.
- sleep 2 war zu kurz: Der health-Check lief, bevor der Dienst auf 4200
hörte -> kurzzeitig 502 / "activating", obwohl gleich darauf alles läuft.
Auf sleep 6 erhöht, mit Hinweis, wann ein 502 wirklich ein Problem ist.
Deploy selbst war erfolgreich: Bremse greift live (20 durch, 21. -> 429),
multer 2.2.0 + node-cron 4.6.0 installiert, better-sqlite3 lädt.
Co-Authored-By: Claude Opus 5 <[email protected]>
Der Block scheiterte in der Praxis am ersten "cd /home/dogiintern/...":
Das Verzeichnis ist 700, selbst dogi kommt per cd nicht hinein, nur
dogiintern über sudo -u. Jetzt git -C statt cd, und das npm ci in einer
sudo -u dogiintern bash -c 'cd ... && npm ci'-Shell. Mit Warnhinweis,
warum kein cd davor stehen darf.
Co-Authored-By: Claude Opus 5 <[email protected]>
- Vollständiger kopierfertiger Deploy-Block für server-internal MIT npm ci:
pull -> npm ci -> Lade-Test der nativen Module -> restart -> Selbsttest,
als eine &&-Kette, die bei jedem Fehler VOR dem Neustart abbricht (alter
Dienst läuft dann unberührt weiter). Bisher stand dort nur pull + restart
ohne npm ci -- genau die Lücke, durch die Code und Pakete auseinanderliefen.
- Wächter: 18 -> 19 Punkte (Sicherungsprüfung dazugekommen).
- Zwei offene Punkte ergänzt: ausstehender Server-Neustart (Kernel/OpenSSL
liegen bereit) und der ausstehende server-internal-Deploy.
- Veralteten Datenschutz-404-Eintrag abgehakt (heute live 401 verifiziert).
Co-Authored-By: Claude Opus 5 <[email protected]>
Nach einem Tag mit vielen Aenderungen beschrieb die Anleitung weder,
was neu automatisch laeuft, noch stimmte ihre Liste offener Punkte.
NEU AUFGENOMMEN
- Zwei Zahlen beim Webdesign-Deploy: CACHE_NAME in sw.js UND die Nummer
in der Registrierungsadresse. Mit Begruendung, warum eine allein nicht
reicht -- Cloudflare ersetzt das "no-cache" des Servers durch vier
Stunden, gemessen am 26.08.2026.
- Was per Cron laeuft: Sicherung (taeglich 03:15) und Waechter (alle
fuenf Minuten), samt Probeschalter und der Grenze, die bleibt.
- Die Verwaltung als eigene App, und warum ihr Manifest in der
Ausnahmeliste der Zugangswand stehen muss.
OFFENE PUNKTE NACHGEPRUEFT STATT ABGESCHRIEBEN
Der Eintrag "Hintergrundbilder liegen nur auf dem Server" stimmt nicht
mehr: Alle genannten Dateien und der Avatar-Ordner sind versioniert,
"git status --untracked-files=all -- assets/" meldet auf dem Server
null. Als erledigt gekennzeichnet, nicht geloescht -- eine Liste, in der
Erledigtes ungekennzeichnet steht, wird beim naechsten Mal gar nicht
mehr gelesen.
Der CORS-Punkt war schaerfer formuliert als die Lage: Die Antwort
enthaelt KEIN Access-Control-Allow-Credentials, und die Verwaltung
weist sich ueber "Authorization: Bearer" aus statt ueber ein Cookie.
Ein Browser schickt bei einer fremden Seite also weder Cookies noch das
Token mit; erreichbar sind nur die ohnehin oeffentlichen Endpunkte.
Sauberer waere eine feste Herkunftsliste -- das ist Haertung, keine
Reparatur, und gehoert als eigener Vorgang mit Live-Test angefasst.
Ergaenzt: express 5 ist vorbereitet aber bewusst nicht umgestellt, und
die Datenschutz-Endpunkte warten auf einen Pull in /home/dogiintern.
Co-Authored-By: Claude Opus 5 <[email protected]>
Ohne Lock-Datei darf jede Installation andere Fassungen ziehen:
"^4.21.2" erlaubt alles unter 5.0. Auf dem Server laeuft deshalb
express 4.22.2, waehrend in der package.json 4.21.2 steht -- geprueft
wird also nie genau das, was ausgeliefert wird. Solche Unterschiede
fallen nicht beim Deploy auf, sondern im Betrieb, und dann sucht man
den Fehler im eigenen Code.
WARUM SIE AUSGESCHLOSSEN WAR
Ein "git pull" auf dem Server scheiterte daran: Git ueberschreibt keine
unverfolgte Datei -- unabhaengig davon, ob ihr Inhalt derselbe ist. Der
Ausschluss hat den Deploy repariert und dabei den Zweck der Datei
beseitigt.
Nachgemessen statt vermutet: Die Datei hier und die auf dem Server sind
Byte fuer Byte identisch (SHA-256 a50b028d…). Es gab also nie einen
inhaltlichen Konflikt, nur einen formalen. Er loest sich, indem die
Datei einmal vom Server entfernt und danach aus dem Repo geholt wird.
DEPLOY.md ergaenzt: auf dem Server "npm ci" statt "npm install". ci
loescht node_modules vorher und baut streng nach der Lock-Datei; es
schreibt sie nie um und bricht ab, wenn sie nicht zur package.json
passt -- statt still etwas anderes zu installieren.
server-internal/ folgt, sobald die dortige Lock-Datei vorliegt. Dieses
Verzeichnis liegt unter /home/dogiintern mit Rechten 700.
Co-Authored-By: Claude Opus 5 <[email protected]>
Zwei Rueckmeldungen vom 22.08.2026, beide behoben und mit Tests abgesichert.
1) "das sieht nicht gut aus" (Bildschirmfoto des Hauptknopfs)
Ursache: ".wd a" ist Klasse+Element und damit spezifischer als die reine
Knopfklasse ".wd-btn--haupt". Die Textfarbe des Knopfs wurde dadurch
ueberstimmt -- hellblaue Schrift auf hellblauem Grund, praktisch
unlesbar. Derselbe Spezifitaetsfehler wie zuvor bei den Namen auf der
Zugangswand. Fix: ".wd a:not(.wd-btn)" plus zweistufig geschriebene
Knopfregeln, damit das nicht wieder passieren kann.
2) "das sieht lang gezogen aus"
Die Pillenform (border-radius 999px) laesst breite Knoepfe
auseinandergezogen wirken, weil der Radius optisch mit der Breite
mitwaechst. Jetzt fester Radius von 14px -- gleiche Form bei jeder
Breite, ruhiger und hochwertiger.
3) "ich will das ich jedes mal den code gefragt werde wenn man die seite
zu macht"
Das Sitzungs-Cookie allein reicht dafuer nicht: Browser stellen genau
solche Cookies beim Wiederherstellen von Tabs zurueck ("Dort
fortfahren, wo du aufgehoert hast"), man landet dann ohne Codeabfrage
wieder mitten in der Seite. Zusaetzlich jetzt eine Sitzungsmarke im
sessionStorage, die beim echten Schliessen verschwindet. Fehlt sie bei
vorhandenem Cookie, wird die Sitzung serverseitig beendet und zur
Zugangswand geleitet. Token-Notbremse von 24 auf 8 Stunden gesenkt.
13/13 Tests im echten Browser, inklusive Schutz vor Endlosschleife.
DEPLOY.md: zwei Checkouts auf dem Server dokumentiert (/home/dogiweb und
/home/dogiintern) und der Vorfall, dass /webdesign nach dem Pull kurz ohne
Zugangsschutz erreichbar war, weil der Dienstneustart fehlte.
Co-Authored-By: Claude Opus 5 <[email protected]>
Die Anleitung nannte als Deploy-Weg weiterhin "npx wrangler deploy". Das ist
seit dem oeffentlichen Start (21.08.2026) falsch und aktiv gefaehrlich: der
Befehl laeuft fehlerfrei durch und meldet Erfolg, erreicht aber nur noch
...workers.dev. Die echte Domain wird von Caddy auf dem Netcup-Server
ausgeliefert (dogiweb.service, localhost:4100). Genau darauf bin ich heute
beim Sprachfenster-Fix hereingefallen -- Deploy "erfolgreich", auf dem Handy
aber unveraendert kaputt.
Neu dokumentiert: der einzige gueltige Weg (commit -> push gitea master:main
-> git pull auf dem Server), die Zweig-Falle master/main, die Pflichtpruefung
gegen die echte Domain statt gegen die Deploy-Meldung, warum die
wrangler-Fehlermeldung "externally managed DNS records" erwuenscht ist, und
als offener Punkt: mehrere live benutzte Hintergrundbilder liegen in keiner
Git-Ablage.
Co-Authored-By: Claude Opus 5 <[email protected]>
DogFatherGitandClaude Opus 5