Diese Adresse führte bis September 2026 eine Anwendung: Zeitnahme, Kader,
Trails, Renntage. Die heißt jetzt Kurbeler, liegt unter kurbeler.de und führt
den Stammtisch als eines von mehreren Teams. Was hier bleibt, ist die Adresse
— und die soll niemanden ins Leere laufen lassen.
Übrig sind drei vorgerenderte Seiten: Wappen, ein Satz, ein Knopf, dazu
Impressum und Datenschutz. Kein Konto, keine Datenbank, kein Formular, keine
Cookies, keine Schriften oder Karten von fremden Servern. Die
Datenschutzerklärung ist deshalb kurz und nicht die von Kurbeler mit
Streichungen — eine Erklärung, die von Konten und Benachrichtigungen spricht,
wäre auf dieser Seite schlicht falsch.
`adapter-static` statt `adapter-node`, ausgeliefert von nginx: Für drei Seiten
ohne eine dynamische Angabe einen JavaScript-Prozess laufen zu lassen, der auf
Anfragen wartet, um jedes Mal dieselbe Datei herauszugeben, wäre Beschäftigung
ohne Arbeit. Von den Abhängigkeiten bleiben die zwölf, die zum Bauen nötig
sind; zur Laufzeit keine einzige. Das Bild ist damit 492 kB statt elf
Megabyte — zwei alte Grafiken von je 2,4 MB lagen ungenutzt in `static/`.
Das Backend bleibt unangetastet. Es wird vom Wegweiser nicht benutzt, aber
darin liegen die Daten des alten Deployments.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LTw6xVYgjMy9AQtfs1Gdyu
Das Coolify-Deployment scheiterte an zwei Stellen:
1. npm ci brach mit EBADENGINE ab. Coolify baute mit Node 22.11.0, vite und
@sveltejs/vite-plugin-svelte verlangen aber >=22.12; engine-strict=true
aus der .npmrc macht daraus einen Abbruch statt einer Warnung. Das
engines-Feld schreibt die Anforderung jetzt im Repo fest, statt sie einer
Einstellung in der Coolify-UI zu überlassen.
2. Selbst nach erfolgreichem npm ci wäre der Start gescheitert: adapter-auto
erkennt Coolify nicht ("Could not detect a supported production
environment") und erzeugt gar kein build/ — der Startbefehl "node build"
findet dann nichts. Jetzt adapter-node, adapter-auto entfällt.
Verifiziert in einer frischen Kopie ohne node_modules, mit derselben Kette
wie im Deployment: npm ci läuft durch, npm run build erzeugt build/index.js,
node build antwortet auf / und /login mit HTTP 200.
Dabei fiel ein dritter Punkt auf, der keine Code-Änderung braucht, aber im
Deployment gesetzt sein muss: PUBLIC_PB_URL wird zur Buildzeit eingesetzt.
Fehlt sie, bricht der Build mit "PUBLIC_PB_URL is not exported by
virtual:env/static/public" ab. Steht jetzt in frontend/README.md und CLAUDE.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die SvelteKit-App liegt unter frontend/, das Backend unter backend/ als
eigenständige PocketBase-Instanz mit Dockerfile, docker-compose und
versioniertem Schema.
- PocketBase-URL über PUBLIC_PB_URL konfigurierbar, Default bleibt die
produktive Instanz https://api.stammtisch-hersbruck.de
- Schema als Snapshot-Migration der sechs fachlichen Collections
(users, teams, events, runs, riders, times), abgezogen von der
produktiven Instanz. Verifiziert: ein Erststart gegen leere pb_data
legt alle sechs an, Felder und API-Rules stimmen überein.
- pb_data und pb_migrations als Bind-Mounts, damit Daten persistieren und
im Admin-UI erzeugte Migrationen im Repo landen
- Veraltete Dokumentation entfernt: pocketbase_schema.json nannte
Collections (stages, results, organizers), die es nicht gibt
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
