Document direct deployment and add safe Nakama helper

DEPLOYMENT-SCHNELLWEG.md

@@ -0,0 +1,53 @@
+# Void Bastion: Git- und Serververöffentlichung
+
+Stand: 9. Oktober 2026. Diese Anleitung enthält bewusst keine Passwörter, privaten Schlüssel oder API-Tokens.
+
+## Zuständigkeiten
+
+| Teil | Quelle | Ziel | Transport |
+|---|---|---|---|
+| Homepage und geschützte Statistikseite | `outputs/void-bastion-website-git` | Gitea `Emporex/Void-Bastion-Website` → Netcup `gergames.de/void-bastion` | Git über repositorygebundenen SSH-Deploy-Key; Netcup-Plesk-Git-Anbindung |
+| Online-Spielserver/Nakama | `outputs/void-bastion/server/nakama/runtime/build/index.js` | Unraid `/mnt/user/appdata/void-bastion-online/nakama/modules/build/index.js` | bestehender SSH-Alias `unraid-codex`, `tools/deploy-nakama.ps1` |
+| Windows-Spiel | Godot-Projekt `outputs/void-bastion` | Gitea-Release mit Setup-EXE; Homepage verlinkt neuestes Release | separater Windows-Build-/Release-Prozess |
+
+Die Website und der Nakama-Server sind unterschiedliche Systeme. Ein Git-Push zur Website aktualisiert nicht automatisch den Heimserver. Ein Nakama-Upload aktualisiert nicht automatisch Netcup.
+
+## Website: direkt per Git arbeiten
+
+Der aktuelle Arbeitsklon ist `outputs/void-bastion-website-git`. Sein `origin` zeigt per SSH auf Port 2202 des lokalen Unraid-Gitea. In der **lokalen** `.git/config` steht `core.sshCommand` mit dem repositorygebundenen Schlüssel `C:/Users/Domin/.ssh/id_ed25519_void_bastion_site` und der separat geprüften Host-Key-Datei `known_hosts_void_bastion_gitea`. Der private Schlüssel ist nicht im Repository. Der Gitea-Schlüssel hat Schreibrechte **nur** für `Emporex/Void-Bastion-Website`. Er ist auf diesem PC ohne Passphrase gespeichert und durch die Windows-Dateirechte auf Benutzer, Administratoren und System begrenzt. Ein laufender SSH-Agent ist hierfür nicht nötig. Bei Verlust des PCs den Deploy-Key in Gitea widerrufen.
+
+```powershell
+cd 'C:\Users\Domin\Documents\Codex\2026-10-02\ich\outputs\void-bastion-website-git'
+git pull --ff-only
+git status
+# Nur beabsichtigte Dateien bearbeiten und gezielt stagen, z. B.:
+git add intern/statistik/index.php
+git commit -m "Beschreibung der Änderung"
+git push origin main
+```
+
+Vor jedem Push `git status` und `git diff --cached` prüfen. Keine Zugangsdaten committen. `intern/statistik/stats-config.local.php` bleibt ausschließlich auf dem Webhosting und ist in `.gitignore` ausgeschlossen.
+
+Netcup-Plesk ist bereits mit dem Gitea-Repository `Emporex/Void-Bastion-Website`, Branch `main`, und dem Ziel `gergames.de/void-bastion` verbunden. **Ein Push nach Gitea ist derzeit nicht als automatische Netcup-Bereitstellung bestätigt.** Am 9. Oktober war die neue Code-Listenfunktion im Gitea-Commit `3e6132e` und auf Nakama vorhanden (fünf gespeicherte Codes), während sie auf der eingeloggten Live-Statistikseite laut Betreiber fehlte. Für das Website-Repository war in Gitea kein Webhook eingerichtet. Die Alpha-9-Anzeige auf der Homepage kommt separat über `latest-release.php` aus der Releases-API und beweist keine PHP-Bereitstellung. Bis ein automatischer Deploy-Endpunkt verifiziert und eingerichtet ist, nach Website-Push im Plesk-Git-Bereich für *diese Domain* „Pull“ und „Bereitstellen“ ausführen und die Live-Seite prüfen. Andere Domains oder das webhostingweite FTP/SSH-Konto nicht für automatische Uploads benutzen.
+
+Ein künftiger Wechsel des PCs benötigt den lokalen privaten Schlüssel aus einem sicheren Backup **oder** einen neu ausgestellten Deploy-Key auf Gitea. Vor der ersten Verbindung den Gitea-SSH-Host-Key erneut mit dem am Server veröffentlichten Schlüssel vergleichen (derzeit ED25519-Fingerabdruck `SHA256:WFM5G2yjTwTlJqF8OmBqx4N2O4/8L35vJ4Qu4zrC/J0` für `[192.168.178.20]:2202`). Die vollständige Verzeichnisstruktur und lokale `.git/config` lassen sich nicht allein aus einem Quellcode-ZIP wiederherstellen.
+
+## Nakama: prüfen und gezielt veröffentlichen
+
+Im Godot-Projektordner:
+
+```powershell
+& '.\tools\deploy-nakama.ps1'
+& '.\tools\deploy-nakama.ps1' -Apply
+```
+
+Ohne `-Apply` läuft zuerst der Server-Simulationstest und dann ein SHA-256-Vergleich; es wird nichts hochgeladen. Mit `-Apply` lädt das Skript nur bei einer Änderung hoch, prüft den Hash, sichert die bisherige Serverdatei mit Zeitstempel, ersetzt sie, startet **nur** den Nakama-Container neu und wartet auf dessen `healthy`-Status. Bei einem Fehler nach der Aktivierung nicht blind erneut starten; zuerst Logs prüfen und bei Bedarf die gemeldete Sicherungsdatei wiederherstellen. Der Unraid-SSH-Zugang ist serverweit mächtig: Pfade und Containername im Skript nicht ohne Prüfung ändern.
+
+Am 9. Oktober 2026 stimmten lokaler und aktiver Server-Bundle-Hash `2f76ec101b672912d102b607c651b105afa366e1c488e9da7fdc0187378742dc` überein. Die RPCs `create_unlock_code` und `list_unlock_codes` waren im Nakama-Startlog registriert. Die PHP-Codeverwaltung liegt bereits in Gitea-Commit `3e6132e` auf `main`; ihr Netcup-Deployment ist noch separat zu bestätigen.
+
+## Absicherung und Wiederherstellung
+
+- Keine Zugangsschlüssel in Git, Doku, Chat oder Build-Artefakte kopieren.
+- Git-Push über den Website-Deploy-Key und Server-Upload über `unraid-codex` sind bewusst getrennt.
+- Für die Website bleiben die geschützte lokale PHP-Konfiguration und die Netcup-Git-Zuordnung auf Netcup; ein Git-Klon allein ist kein vollständiges Hosting-Backup.
+- Für Nakama gehören PostgreSQL-Backups und die Server-Konfiguration in das bestehende Unraid-Backup. Das Deploy-Skript sichert nur die bisherige JavaScript-Datei, nicht die Datenbank.

tools/deploy-nakama.ps1

@@ -0,0 +1,62 @@
+param(
+    [switch]$Apply
+)
+
+$ErrorActionPreference = 'Stop'
+$bundle = (Resolve-Path (Join-Path $PSScriptRoot '..\server\nakama\runtime\build\index.js')).Path
+$test = (Resolve-Path (Join-Path $PSScriptRoot '..\server\nakama\tests\runtime_sim_test.js')).Path
+$remoteFile = '/mnt/user/appdata/void-bastion-online/nakama/modules/build/index.js'
+$remoteHost = 'unraid-codex'
+
+function Assert-LastExit([string]$step) {
+    if ($LASTEXITCODE -ne 0) { throw "$step fehlgeschlagen (Exitcode $LASTEXITCODE)." }
+}
+
+& node $test
+Assert-LastExit 'Nakama-Simulationstest'
+
+$localHash = (Get-FileHash -LiteralPath $bundle -Algorithm SHA256).Hash.ToLowerInvariant()
+$remoteHashLine = & ssh -o BatchMode=yes $remoteHost "sha256sum $remoteFile"
+Assert-LastExit 'Server-Hashprüfung'
+$remoteHash = ($remoteHashLine -split '\s+')[0].ToLowerInvariant()
+
+Write-Output "Lokal:  $localHash"
+Write-Output "Unraid: $remoteHash"
+if ($localHash -eq $remoteHash) {
+    Write-Output 'Nakama ist bereits auf dem aktuellen Stand.'
+    exit 0
+}
+if (-not $Apply) {
+    Write-Output 'Nur geprüft. Zum Veröffentlichen erneut mit -Apply ausführen.'
+    exit 0
+}
+
+$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
+$upload = "$remoteFile.upload-$stamp"
+$backup = "$remoteFile.pre-$stamp"
+
+& scp -o BatchMode=yes $bundle "${remoteHost}:$upload"
+Assert-LastExit 'Upload'
+$uploadedHashLine = & ssh -o BatchMode=yes $remoteHost "sha256sum $upload"
+Assert-LastExit 'Upload-Hashprüfung'
+if (($uploadedHashLine -split '\s+')[0].ToLowerInvariant() -ne $localHash) {
+    throw 'Upload-Hash stimmt nicht überein. Aktive Serverdatei wurde nicht verändert.'
+}
+
+& ssh -o BatchMode=yes $remoteHost "cp -p $remoteFile $backup && mv $upload $remoteFile && docker restart void-bastion-nakama"
+Assert-LastExit 'Sicherung, Aktivierung oder Neustart'
+
+$healthy = $false
+for ($attempt = 1; $attempt -le 15; $attempt++) {
+    Start-Sleep -Seconds 2
+    $status = & ssh -o BatchMode=yes $remoteHost 'docker inspect -f "{{.State.Health.Status}}" void-bastion-nakama'
+    if ($LASTEXITCODE -eq 0 -and $status.Trim() -eq 'healthy') {
+        $healthy = $true
+        break
+    }
+}
+if (-not $healthy) {
+    throw "Nakama ist nach dem Neustart nicht healthy. Sicherung auf Unraid: $backup. Nicht automatisch zurückgerollt."
+}
+
+Write-Output "Nakama läuft healthy. Wiederherstellbare Sicherung: $backup"