Commit graph

2 commits

Author SHA1 Message Date
Daniel Michelberger
f316058367 fix: Deployment reparieren — adapter-node und Node-Anforderung festschreiben
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>
2026-08-06 14:52:00 +02:00
Daniel Michelberger
1061a8b9ad chore: Repo-Struktur mit frontend/ und backend/ aufsetzen
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>
2026-08-06 13:16:43 +02:00