# Entscheidungen

Stand der Quellenprüfung: 21. Oktober 2026. Verwendet wurden offizielle
Dokumentationen und die npm-Registry für konkrete Paket-Metadaten.

## D-001: SvelteKit 3 und Node-Unterstützung

Die Anwendung verwendet SvelteKit 3, Svelte 5, TypeScript und Vite 8. Das
Projekt wurde gemäß aktueller Empfehlung mit `npx sv create` angelegt. Die
Kit-Konfiguration liegt bei SvelteKit 3 in `vite.config.ts`, nicht in einer
`svelte.config.js`.

Die lokale Mindestversion ist Node 22.17. Das Cloudron-Image nutzt Node 24 LTS.
Der vorhandene lokale Lauf wurde mit Node 22.23.1 geplant.

Quellen:

- <https://svelte.dev/docs/kit/creating-a-project>
- <https://svelte.dev/docs/kit/migrating-to-sveltekit-3>
- <https://svelte.dev/docs/cli/sv-create>
- npm-Metadaten für `@sveltejs/kit` 3.1.0 am 21.10.2026

## D-002: Offizieller Node-Adapter

`@sveltejs/adapter-node` erzeugt den Produktionsserver in `build/`. Gebaut wird
mit `npm run build`, gestartet mit `node build`. `HOST` und `PORT` konfigurieren
den Server. Der Adapter behandelt SIGTERM/SIGINT und kontrolliertes Herunter-
fahren; ein eigener Server ist für Etappe 1 nicht erforderlich.

Quelle: <https://svelte.dev/docs/kit/adapter-node>

## D-003: SQLite mit better-sqlite3

`better-sqlite3` 13.x wird als gekapselter synchroner Treiber verwendet. Das
Paket ist MIT-lizenziert und verlangt Node 22 oder neuer. Gegenüber
`node:sqlite` wird damit in Etappe 1 keine API verwendet, die in der offiziellen
Node-24-Dokumentation noch als Release Candidate gekennzeichnet ist. Die
Datenbankgrenze bleibt in `src/lib/server` gekapselt.

Migrationen sind eigene nummerierte SQL-Dateien und laufen transaktional. WAL
wird in Etappe 1 nicht aktiviert; für die kleine Redaktion ist das
Rollback-Journal zunächst ausreichend und vereinfacht die frühe
Betriebsprüfung.

Quellen:

- <https://nodejs.org/docs/latest-v24.x/api/sqlite.html>
- <https://www.sqlite.org/lang_transaction.html>
- npm-Metadaten für `better-sqlite3` 13.0.3 am 21.10.2026

## D-004: Cloudron-Paket

Das Paket nutzt `manifestVersion: 2`, internen HTTP-Port 3000 und `/healthz`.
`localstorage.sqlite.paths` nennt `/app/data/sendewerk.sqlite`, damit Cloudron
eine konsistente Sicherung der aktiven SQLite-Datei erstellen kann. Das
Startskript stellt Verzeichnisse und Besitzrechte her, migriert als Benutzer
`cloudron` und ersetzt sich zuletzt per `exec` durch den Node-Prozess.

Das Image ist auf die am 21.10.2026 offiziell dokumentierte datierte Node-24-
Basis samt Digest gepinnt. Außer `/app/data`, `/run` und `/tmp` wird das
Laufzeitdateisystem als read-only behandelt.

Quellen:

- <https://docs.cloudron.io/packaging/>
- <https://docs.cloudron.io/packaging/manifest/>
- <https://docs.cloudron.io/packaging/addons/#localstorage>
- <https://docs.cloudron.io/packaging/cheat-sheet/>

## D-005: Theme ohne serverseitiges Nutzerkonto

Etappe 1 speichert `light`, `dark` oder `system` in `localStorage`. Ein kurzes
Inline-Skript in `app.html` setzt das resultierende Theme vor dem ersten Paint
auf dem Wurzelelement. Dies vermeidet einen falschen Theme-Blitz und benötigt
vor Etappe 2 weder Cookie noch Konto. Die Einstellung bleibt bei Neuladen im
gleichen Browser erhalten.

## D-006: Etappe-1-Vorschauen statt Attrappen

Vorschauseiten lesen echte persistente SQLite-Seed-Daten, bieten aber keine
funktionslosen Speichern- oder Live-Schaltflächen. Ein sichtbarer Hinweis
grenzt Gestaltungsvorschauen von den späteren Fachfunktionen ab. Damit wird
keine noch nicht implementierte Funktion als fertig dargestellt.