v0.24.0

→ Die Progress- und Discord-Embeds wurden auf data-first Render mit klaren CTAs und `/maintenance`-Linking umgestellt, weil Statuskommunikation nur hilft wenn sie sofort in die richtige Aktion führt.—Shadow

• Beim Öffnen eines Embeds siehst du direkt belastbare Daten statt flackernder Placeholder.
• Ein Klick aus Discord landet gezielt auf der Wartungsseite statt auf einer unpassenden Landing-Route.

→ Build-ID-Watcher plus no-cache-HTML erzwingen nach Deploy einen sauberen Client-Reload, damit Frontend und Backend auf derselben Release-Basis laufen und du keine Schema-Mismatches spielst.—Shadow

• Wenn der Patch während einer laufenden Session ausgerollt wird, zieht der Client automatisch auf die neue Build-ID.
• Dispatcher müssen nicht manuell hard-reloaden, um wieder gültige API-Calls zu senden.

→ Die Runtime-Memory-Konfiguration wurde auf Heap 2 GB bei Container 3 GB stabilisiert, weil Cgroup-OOM den Prozess vorher hart beenden konnte und du dadurch keine stillen Server-Abbrüche mehr in Lastspitzen bekommst.—Shadow

• Bei hoher Einsatzdichte bleibt der Prozess online, statt ohne klaren OOM-Flag zu verschwinden.
• Das Verhältnis Heap:Container (≈1:1.5) verhindert, dass der Kernel Node vor Docker-Klassifizierung killt.

→ Prisma, Dispatcher und Projektionen werden beim Start eager gewärmt, damit die ersten Aktionen nach Boot ohne Kaltstart-Lag reagieren und Alarmierungen sofort durchgehen.—Shadow

• Direkt nach Neustart feuert dein erster Einsatz ohne den typischen ersten schweren Request.
• Warmup reduziert das Risiko, dass die Anfangsminute einer Schicht träge wirkt.

→ Der Auth-Flow speichert im JWT wieder `email` und `name`, weil der Admin-Check sonst nicht greifen konnte und du dadurch nach dem Login direkt in der richtigen Rolle weiterarbeiten kannst.—Shadow

• Wenn du als Admin einsteigst, bleibt `user.email` in der Session erhalten statt auf `user.id` zu schrumpfen.
• Nach dem Sign-in landest du wieder im Leitstellenbetrieb statt in einem `/maintenance`-Redirect-Loop.

→ Overpass nutzt jetzt Mirror-Rotation, sauberen User-Agent und Stale-Cache-Fallback, weil externe Geodatenquellen schwanken und du dadurch trotzdem weiter auf realen Straßen disponieren kannst.—Shadow

• Wenn ein Overpass-Mirror ausfällt, wechselt der Request automatisch auf einen anderen Endpoint.
• Ist live nichts erreichbar, werden zuletzt valide Cache-Daten genutzt statt die Karte leer zu lassen.

→ In Production sind `TENANCY_V2_ENABLED=true` und ein starkes `INTERNAL_API_SECRET` jetzt Pflicht, weil der Boot sonst blockiert wird und du dadurch keine unsichere Instanz versehentlich online bringst.—Shadow

• Beim Deploy startet der Prisma-Client absichtlich nicht, wenn die ENV-Migration fehlt.
• Das verhindert, dass ein Save ohne aktive Tenancy in den Live-Betrieb rutscht.

→ Die Multi-Tenant-Basis erzwingt Save-Scope unter `/:saveId/...`, damit Daten strikt getrennt bleiben und du parallele Spielstände ohne Cross-Save-Effekte disponieren kannst.—Shadow+Christian Jahnke

• Wenn du drei Einsätze parallel in unterschiedlichen Saves jonglierst, bleibt jede Aktion im richtigen Datenraum.
• `scopedQuery()`, RLS, `SaveContext` und CASL greifen als vierfache Isolation, falls ein Layer ausfällt.

→ Neue ESLint-Regeln stoppen fehlende `saveId`-Envelopes, unscoped Tenant-Queries und Raw-SQL außerhalb Admin-Pfaden schon im CI, damit Fehler nicht erst als Runtime-500 bei Spielern auftauchen.—Shadow

• Wenn ein Hotfix unter Zeitdruck `saveId` vergisst, scheitert der Build direkt statt mitten im Einsatz.
• Bei einem großen Datenumbau (z. B. 50M-Row-Backfill) bleibt Raw-SQL auf freigegebene Admin-Routen begrenzt.

→ Security-, E2E- und Lasttests wurden für Multi-Tenant-Lifecycle und RLS-Overhead ausgebaut, damit Release-Entscheidungen auf gemessener Last statt auf Annahmen basieren und du im Live-Betrieb weniger Überraschungen hast.—Shadow+Christian Jahnke

• 48 Security-Tests über 4 Files plus 8 E2E-Lifecycle-Szenarien validieren die Save-Isolation End-to-End.
• k6- und Micro-Benchmark-Runs liefern vor Deploy belastbare RLS-Overhead-Werte.

→ Kritische Pfade wurden gehärtet, indem `einsatz/generate`-Kontexte getrennt und Timer-Routen auf `INTERNAL_API_SECRET` geprüft werden, damit interne Funktionen nicht extern missbraucht werden und deine Schicht stabil bleibt.—Shadow

• Server-Timer reagieren nur noch auf legitimierte interne Aufrufe statt auf zufällige externe Treffer.
• Privilege-Escalation-Fälle wie C1/C2 wurden vor Merge geschlossen, bevor sie in Live-Runden landen konnten.