Persönliche Übersicht

Anmeldungen importieren

Namen je Auswahl einfügen. Eine Zeile = ein Spieler. Leerzeichen werden bereinigt. Vor dem Übernehmen zeigt die App Treffer, unbekannte Namen und doppelte Einträge.

Warteliste / nicht eingeplant

Schluchtsturm-Anmeldungen importieren

Eine Zeile = ein Spieler. Treffer, unbekannte Namen und doppelte Anmeldungen werden vor dem Übernehmen geprüft.

Warteliste / nicht eingeplant

Ergebnisse / Spieltag abschließen

Füge nur die Namen der Spieler ein, die tatsächlich teilgenommen haben. Die App vergleicht sie mit der vorherigen Planung und markiert fehlende bzw. ungeplante Teilnehmer automatisch.

Vorschau

Teilnahme manuell erfassen

Alternative zum Teilnehmer-Import: Lade die Spieler aus der aktuellen Planung, setze den tatsächlichen Status manuell und übernimm das Ergebnis anschließend in die Historie.

Zug besetzen

Spieltage

Jeder Wüsten- und Schluchtsturm bekommt einen eigenen gespeicherten Stand. Beim Öffnen eines anderen Spieltags wird der aktuelle Stand automatisch gesichert.

Neuen Spieltag anlegen

Heldenkräfte aktualisieren

Name und Kraft einfügen – getrennt durch Tab, Semikolon oder Komma. Bestehende Spieler werden aktualisiert; unbekannte Namen werden nur angezeigt und nicht automatisch angelegt.

Regeln

WÜSTENSTURM-REGELN

1. Direkte Hauptteam-Anmeldungen belegen zuerst die Hauptteamplätze.
2. „Egal“ füllt freie Hauptteamplätze intelligent auf 13 und 22 Uhr. Zuerst zählt der größere Platzbedarf; bei gleichem Bedarf wird das aktuell schwächere Team aufgefüllt.
3. Sind Hauptplätze danach noch frei, werden passende Ersatz-Anmeldungen ins Hauptteam hochgezogen.
4. Ersatzteam: nicht-depriorisierter Hauptteam-Überhang kommt zuerst.
5. Danach kommen nicht-depriorisierte ausdrückliche Ersatz-Anmeldungen.
6. Erst danach kommen depriorisierte Hauptteam-Überhänge und depriorisierte Ersatz-Anmeldungen.
7. „Vorrang nächste Runde“ wirkt innerhalb der jeweiligen Vergabestufe.
8. Spielerpool / Stärke / Zufall / Manuell bestimmt die Reihenfolge innerhalb dieser Stufe.
9. „Egal“ ist eine Hauptteam-Anmeldung und wird intelligent auf 13/22 Uhr verteilt; freie Plätze und Teamstärke werden berücksichtigt. Ein Egal-Spieler wird nicht automatisch ins Ersatzteam verschoben.

SCHLUCHTSTURM
10. Team A/B belegt zunächst das gewünschte Hauptteam.
11. Überhang eines Hauptteams füllt zuerst freie Hauptplätze des anderen Teams.
12. Danach füllt „Egal“ freie Hauptteamplätze intelligent nach Bedarf und Teamstärke.
13. Erst danach dürfen ausdrückliche Ersatz-Anmeldungen freie Hauptteamplätze auffüllen.
14. Nicht-depriorisierte Spieler stehen veranstaltungsweit immer vor depriorisierten geeigneten Spielern – auch wenn dafür ein Wechsel ins andere Ersatzteam nötig ist.
15. Im Ersatzteam gilt: Hauptteam-Überhang vor ausdrücklicher Ersatz-Anmeldung.
16. Ist ein Ersatzteam voll und das andere hat Platz, dürfen übrige Ersatzkandidaten wechseln.
17. „Egal“ ist Hauptteam-Anmeldung und wird nicht automatisch ins Ersatzteam verschoben.

ERGEBNISSE
18. Fehlende Hauptteam-Spieler werden nur dann automatisch als „Nicht teilgenommen“ markiert, wenn sie ursprünglich verbindlich für ein Hauptteam angemeldet waren. Reine Ersatz-Anmeldungen, die automatisch ins Hauptteam aufgefüllt wurden, werden bei Fehlen als „Nicht eingesetzt“ behandelt.
19. „Nicht teilgenommen“ führt nur bei ursprünglicher Hauptteam-Anmeldung (WS: 13 Uhr, 22 Uhr oder Egal; SS: Team A, Team B oder Egal) zu 14 Tagen Depriorisierung. Eine reine Ersatz-Anmeldung erhält durch automatisches Auffüllen ins Hauptteam keine No-Show-Strafe.
20. Fehlende Ersatzspieler werden standardmäßig nur als „Nicht eingesetzt“ markiert und nicht automatisch bestraft.
21. Wartelistenspieler ohne Einsatz erhalten nach Bestätigung Vorrang für die nächste Runde.
22. Wartelistenspieler in der Teilnehmerliste werden als „Eingesprungen“ erkannt.
23. Jeder Status kann vor dem Abschließen manuell korrigiert werden.

PLANUNG & SICHERHEIT
24. Manuelle Verschiebungen werden als eigener Planstand gespeichert und deutlich als „manuell geändert“ markiert.
25. Eine gesperrte Planung wird als Snapshot gespeichert und durch spätere Änderungen an Anmeldung oder Heldenkraft nicht verändert.
26. Die Ergebniserfassung verwendet bei gesperrten Spieltagen den veröffentlichten Snapshot.
27. Regeltests prüfen die wichtigsten Sonderfälle mit derselben Berechnungslogik wie die echte Planung.

SPIELTAGE
28. Wüstensturm und Schluchtsturm besitzen getrennte aktive Spieltage.
29. Beim Öffnen oder Anlegen eines anderen Spieltags wird der aktuelle Stand automatisch gespeichert.
30. Ein neuer Spieltag kann leer, mit der aktuellen Anmeldung oder mit der Anmeldung des letzten gleichartigen Spieltags gestartet werden.
31. Abgeschlossene Spieltage werden archiviert und erhalten einen gesperrten Planungssnapshot.
32. Archivierte Spieltage können später wieder geöffnet werden, ohne den aktuellen Spieltag zu verlieren.
33. Ergebnisse werden dem aktiven Spieltag zugeordnet; WS ist nach 13+22 Uhr bzw. Gesamt, SS nach A+B bzw. Gesamt automatisch abgeschlossen.

COCKPIT
34. Das Cockpit zeigt Anmeldezahlen, Überbuchungen, freie Hauptteamplätze, Wartelisten, Vorrang und Depriorisierungen.
35. Gesperrte/archivierte Planungen und der Stand der Ergebniserfassung werden direkt im Cockpit angezeigt.
36. Warnungen im Cockpit sind Hinweise; die eigentliche Platzvergabe folgt weiterhin ausschließlich der zentralen Planungslogik.

ONLINE / MEHRBENUTZER
37. V12 lädt den gemeinsamen App-Zustand aus Supabase; lokale Browserdaten dienen nur noch als Cache/Notfallkopie.
38. Änderungen werden mit einer Revisionsnummer gespeichert. Bei gleichzeitigen Änderungen wird ein Konflikt erkannt und der aktuelle Cloud-Stand neu geladen.
39. Realtime-Aktualisierungen übernehmen neue gemeinsame Stände automatisch in geöffnete Browser.
40. Leser dürfen nur ansehen/exportieren; Planer und Admins dürfen den gemeinsamen Stand speichern. Benutzerrollen werden serverseitig in Supabase verwaltet.
41. Der erste bestätigte Benutzer kann einmalig die Admin-Rolle übernehmen. Weitere Benutzer starten als Leser.
42. Niemals einen Supabase service_role-Schlüssel in config.js oder die Webseite eintragen.
43. Benutzer besitzen einen Anzeigenamen/Spielernamen. Die E-Mail-Adresse dient nur der Anmeldung und wird nicht als sichtbarer Name in der Kopfzeile verwendet.
44. Der Admin kann pro Spielerprofil-Feld festlegen, ob Leser, Planer und Admins dieses Feld sehen.
45. Der Spielername bleibt unabhängig von der Sichtbarkeitsmatrix immer sichtbar.
46. Profil-Sichtbarkeit ist eine Darstellungsregel der App und kein Ersatz für eine getrennte serverseitige Speicherung vertraulicher Daten.

SPIELER-VERWALTUNG
47. Spieler-Stammdaten werden nur von Admins verwaltet.
48. Bei Namenskorrekturen bleibt die Spieler-ID unverändert; Historienzeilen mit Spieler-ID werden auf den korrigierten Namen aktualisiert.
49. Deaktivierte Spieler bleiben sichtbar, werden aber nicht automatisch eingeplant.
50. „Aus Spielerpool entfernen“ ist historien-sicher: Der Spieler wird aus neuen Anmeldungen/Planungen ausgeblendet, bleibt aber für Historie und archivierte Spieltage erhalten.
51. Entfernte Spieler können von einem Admin wiederhergestellt werden.

NEUE SPIELER
52. Neue Spieler werden nur von Admins angelegt.
53. Die App vergibt automatisch die nächste freie stabile Spieler-ID und setzt den Spieler ans Ende der Pool-Reihenfolge.
54. Neue Spieler starten ohne Historie, ohne Vorrang und ohne Depriorisierung.
55. Unbekannte Namen im WS-/SS-Anmeldungsimport und Heldenkraft-Import können direkt als neue Spieler angelegt werden.
56. Vor dem Anlegen prüft die App auf bereits vorhandene bzw. sehr ähnlich geschriebene aktive Spielernamen.

DASHBOARD
57. „Aktuelle Mitglieder“ zählt alle Spieler, die aktiv und nicht aus dem Spielerpool entfernt sind.

WOCHENWECHSEL
58. „Neue Woche starten“ ist eine Admin-Funktion und erstellt zuerst automatisch ein Backup.
59. Vorrang und Depriorisierung können für alle Spieler gemeinsam zurückgesetzt werden.
60. Die aktuellen WS-/SS-Anmeldungen können gemeinsam geleert und neue aktive Spieltage mit neuen Daten angelegt werden.
61. Alte Spieltage bleiben im Archiv erhalten.
62. Die Historie kann beim Wochenwechsel optional vollständig gelöscht oder separat im Historie-Reiter gelöscht werden.
63. Spieler, Heldenkräfte, Aktivstatus, Benutzer und Profil-Sichtbarkeit bleiben beim Wochenwechsel erhalten.

ROLLEN & REITER
64. Admins können für jeden Reiter separat festlegen, ob Leser, Planer oder Admins ihn sehen dürfen.
65. Die Reiter-Sichtbarkeit verändert keine Schreibrechte; Leser bleiben schreibgeschützt und Admin-Funktionen bleiben Admins vorbehalten.
66. Für jede Rolle muss mindestens ein Reiter sichtbar bleiben.
67. Admins erreichen die Reiterverwaltung zusätzlich über „Reiter verwalten“ in der Kopfzeile, auch wenn der Reiter „Benutzer“ ausgeblendet wurde.

SICHERHEIT BACKUP / RESET
68. JSON-Schnellsicherung, Backup laden, manuelle Backup-Erstellung, Backup-Download, Wiederherstellung, Löschen und Zurücksetzen sind ausschließlich Admin-Funktionen.
69. Für Leser und Planer werden diese Bedienelemente ausgeblendet; die Funktionen prüfen zusätzlich intern die Admin-Rolle.
70. Automatische Backup-Versionen bei Planungs-/Spieltag-Aktionen können weiterhin im Hintergrund erzeugt werden.

SICHERHEIT PLANUNGS-EXPORT
71. Leser dürfen Planungen ansehen, aber weder Discord-Export noch CSV-Export verwenden.
72. Discord- und CSV-Export sind ausschließlich für Planer und Admins verfügbar.
73. Die Export-Schaltflächen werden für Leser ausgeblendet und die Exportfunktionen prüfen zusätzlich intern die Schreibrolle.

LESERANSICHT PLANUNG
74. Für Leser wird in WS- und SS-Planung die komplette rechte Funktionsleiste ausgeblendet.
75. Dazu gehören Status „Offen/Gesperrt“, manuelle Änderungen zurücksetzen, Planung sperren/entsperren, Discord-Export, CSV-Export und „Neu berechnen“.
76. Leser sehen weiterhin die eigentliche Teamaufstellung und die für ihre Rolle freigegebenen Planungsinformationen.
77. Alle Änderungs-/Exportfunktionen bleiben zusätzlich intern über die Rollenprüfung geschützt.

SPIELERVERWALTUNG
78. „Neuen Spieler hinzufügen“ ist ausschließlich für Admins sichtbar und nutzbar.
79. Leser und Planer sehen diesen Button nicht; die Funktion selbst bleibt zusätzlich durch die Admin-Prüfung geschützt.

SPIELER-GASTZUGANG
80. Spieler benötigen kein eigenes Benutzerkonto; der Zugang erfolgt über einen gemeinsamen Allianz-Code.
81. Planer und Admins melden sich weiterhin mit E-Mail und Passwort an.
82. Der Allianz-Code wird serverseitig nur als Hash gespeichert und ist nach dem Setzen nicht auslesbar.
83. Gäste erhalten einen getrennten, bereinigten Spieler-Datensatz und niemals den vollständigen app_state.
84. Für Gäste sind ausschließlich sichere Leser-Reiter möglich: Cockpit, Spielerprofil, WS Planung, SS Planung, Historie und Regeln.
85. Interne Spieler-ID, Pool-Reihenfolge, manuelle Reihenfolge und interne Notizen werden im Gastzugang niemals veröffentlicht.
86. Die Spieleransicht wird nach Änderungen automatisch aktualisiert und kann von Admins/Planern zusätzlich manuell veröffentlicht werden.
87. Die öffentliche HTML-Datei enthält ab V12.3 keine eingebauten Spieler- oder Historiedaten mehr.
88. Der vollständige Cloudzustand wird ab V12.3 nicht mehr im Browser-localStorage zwischengespeichert.

LESERANSICHT COCKPIT
89. Die Schaltflächen „Planung berechnen“ und „SS berechnen“ im Cockpit sind für Leser/Gäste ausgeblendet.
90. Nur Planer und Admins können die Planung aus dem Cockpit neu berechnen; die Funktionen bleiben zusätzlich intern durch Schreibrechte geschützt.

MANUELLE TEILNAHME
91. Planer und Admins können Ergebnisse alternativ ohne Namensimport im Reiter „Teilnahme manuell“ erfassen.
92. Die Spielerliste wird aus der aktuellen/gesperrten Planung der gewählten Ergebnisgruppe geladen.
93. Jeder Spieler muss vor dem Historisieren einen tatsächlichen Status erhalten; „Nicht erfasst“ kann nicht gespeichert werden.
94. Mit „Standardstatus setzen“ werden Hauptteam-Spieler auf „Teilgenommen“, Ersatz auf „Nicht eingesetzt“ und Warteliste auf „Warteliste / nicht eingesetzt“ gesetzt; anschließend können einzelne Spieler korrigiert werden.
95. Ungeplante Teilnehmer können manuell ergänzt und als „Ungeplant teilgenommen“ historisiert werden.
96. Sperren, Vorrang und Historieneinträge folgen exakt denselben Statusregeln wie beim bisherigen Ergebnis-Import.
97. Bereits historisierte oder sich überschneidende Ergebnisgruppen können nicht erneut historisiert werden.
98. Der Reiter ist standardmäßig nur für Planer und Admins sichtbar und wird niemals an den Spieler-Gastzugang ausgeliefert.

PWA / APP-INSTALLATION
99. UNNO kann als Progressive Web App auf Windows-PCs, Android und iPhone/iPad installiert werden.
100. Android und unterstützte Desktop-Browser bieten eine direkte App-Installation an; auf iPhone/iPad erfolgt die Installation über Safari → Teilen → „Zum Home-Bildschirm“.
101. Die installierte App verwendet dieselbe Cloud-/Gastzugangslogik wie die Webversion.
102. Der Service Worker cached nur die App-Oberfläche und statische Dateien; Supabase-API-, Auth- und Gastdaten werden nicht offline gecacht.
103. Bei einer neuen Webversion zeigt die installierte App einen Update-Hinweis und kann sich kontrolliert aktualisieren.

REITER-REIHENFOLGE
104. Admins können die Reihenfolge aller Reiter global ändern.
105. Die Sortierung ist per Drag & Drop sowie mit ↑ / ↓ möglich.
106. Die Reihenfolge gilt für Leser, Planer und Admin; ausgeblendete Reiter werden für die jeweilige Rolle einfach übersprungen.
107. Sichtbarkeit und Reihenfolge bleiben getrennte Einstellungen.
108. Die Standard-Reihenfolge kann jederzeit wiederhergestellt werden.

ALLIANZ-RANG
109. In den Spieler-Stammdaten kann für jeden Spieler ein Allianz-Rang R5, R4, R3, R2 oder R1 hinterlegt werden.
110. Der Allianz-Rang kann ausschließlich von Admins geändert werden.
111. Admins können den Rang direkt in der Stammdatentabelle oder im Bearbeiten-Fenster setzen; beim Anlegen neuer Spieler kann er ebenfalls ausgewählt werden.
112. Für bestehende Spieler ohne hinterlegten Rang bleibt das Feld zunächst leer („–“).
113. Der Allianz-Rang ist ein internes Stammdatenfeld und wird nicht an den Spieler-Gastzugang veröffentlicht.

SPIELER-STAMMDATEN SORTIEREN
114. Die Spieler-Stammdatentabelle kann durch Klick auf die Spaltenüberschriften sortiert werden.
115. Sortierbar sind ID, Spielername, Rang, Heldenkraft, Aktiv, Depriorisierung, Vorrang, Pool-Reihenfolge und Notiz.
116. Ein erneuter Klick auf dieselbe Spalte wechselt zwischen aufsteigend und absteigend.
117. Die aktive Sortierung wird mit ▲ bzw. ▼ angezeigt.
118. Die Sortierung verändert keine Stammdaten und gilt nur für die aktuelle Ansicht.

NOTIZEN FÜR PLANER
119. Interne Spielernotizen dürfen von Planern und Admins erstellt und bearbeitet werden.
120. In den Spieler-Stammdaten ist die Notiz-Spalte für Planer/Admins direkt editierbar.
121. Ist „Interne Spieler-Notiz“ im Spielerprofil für die Rolle sichtbar, kann die Notiz dort ebenfalls bearbeitet werden.
122. Änderungen an einer Notiz verändern oder entsperren keine WS-/SS-Planung und führen zu keiner Neuberechnung.
123. Alle übrigen Spieler-Stammdaten bleiben für Planer gesperrt und weiterhin Admin-Funktionen.
124. Spieler/Gäste erhalten interne Spielernotizen weiterhin niemals über den Gastzugang.

SCHILD AM SAMSTAG
125. Der Reiter „Schild“ dokumentiert transparent, welcher Spieler an welchem Samstag sein Schild vergessen hat.
126. Planer und Admins erfassen einen Vorfall mit einem einzigen Klick auf den Spieler; Datum, Spieler und Ersteller werden automatisch gespeichert.
127. Pro Spieler und Samstag ist nur ein Schild-Eintrag möglich.
128. Das ausgewählte Datum muss ein Samstag sein.
129. Planer und Admins können Einträge nachträglich bearbeiten, einem anderen Spieler/Datum zuordnen oder löschen.
130. Die Übersicht zeigt je Spieler Anzahl, bisherige Samstage und den letzten Vorfall.
131. Die Farbkennzeichnung dient nur der schnellen Übersicht: 0, 1, 2 und 3+ Vorfälle werden unterschiedlich hervorgehoben.
132. Leser/Gäste dürfen den Schild-Reiter ansehen, aber keine Einträge anlegen, bearbeiten oder löschen.
133. Interne Bemerkung und „Erfasst von“ werden nicht an den Gastzugang veröffentlicht.
134. Die Schild-Historie wird zusätzlich im Spielerprofil als Anzahl und Datumsübersicht angezeigt.

SCHILD IN SPIELER-STAMMDATEN
135. In den Spieler-Stammdaten zeigt die Spalte „Schild 3 Monate“, wie oft ein Spieler innerhalb der zurückliegenden drei Monate sein Schild vergessen hat.
136. Der Wert wird automatisch aus der Schild-Historie berechnet und kann nicht manuell verändert werden.
137. Der Zeitraum ist rollierend: aktuelles Datum minus drei Monate bis einschließlich heute.
138. Die Spalte ist sortierbar; damit können Spieler mit den meisten Schild-Vorfällen schnell gefunden werden.

VS-MINDESTPUNKTE
139. Der Reiter „VS“ dokumentiert transparent, welcher Spieler in einer VS-Woche die vereinbarte Mindestanzahl an VS-Punkten nicht erreicht hat.
140. Die VS-Woche wird über ihren Montag ausgewählt; ein Klick auf „Mindestpunkte nicht erreicht“ speichert den Eintrag.
141. Pro Spieler und VS-Woche ist nur ein Eintrag möglich.
142. Planer und Admins dürfen VS-Einträge anlegen, nachträglich bearbeiten, einem anderen Spieler/Woche zuordnen oder löschen.
143. Leser/Gäste dürfen die VS-Historie ansehen, aber nicht verändern.
144. Interne Bemerkungen und „Erfasst von“ werden nicht an den Gastzugang veröffentlicht.
145. Im Spielerprofil werden Anzahl und letzte VS-Wochen mit verfehlten Mindestpunkten angezeigt.
146. Die Spieler-Stammdaten enthalten die Spalte „VS 3 Monate“.
147. „VS 3 Monate“ zeigt automatisch die Anzahl der VS-Wochen mit verfehlten Mindestpunkten innerhalb der rollierenden letzten drei Monate.
148. Die Spalte „VS 3 Monate“ ist sortierbar und kann nicht manuell verändert werden.

URLAUBSPLANER
149. In den Spieler-Stammdaten gibt es die Spalte „Urlaub“.
150. Planer und Admins können für einen Spieler einen oder mehrere Urlaubszeiträume mit Von-/Bis-Datum und optionaler Bemerkung erfassen.
151. Liegt das aktuelle Datum innerhalb eines Urlaubszeitraums, wird die komplette Spielerzeile farblich hervorgehoben und als „Im Urlaub“ gekennzeichnet.
152. Zukünftiger Urlaub wird in der Spalte als „Geplant ab …“ angezeigt.
153. Vergangene Urlaubszeiträume bleiben erhalten und können nachträglich bearbeitet oder gelöscht werden.
154. Überschneidende Urlaubszeiträume desselben Spielers sind nicht zulässig.
155. Die Urlaubsspalte ist sortierbar; aktuell Urlaubende werden vor zukünftigen Urlauben angezeigt.
156. Urlaub dient zunächst nur als transparente Information und verändert keine WS-/SS-/VS-/Schild-Planung automatisch.
157. Urlaubszeiträume und interne Urlaubsnotizen werden nicht an den Spieler-Gastzugang veröffentlicht.

URLAUB APPWEIT SICHTBAR
158. Ein Spieler, der am aktuellen Tag im Urlaub ist, wird appweit visuell gekennzeichnet.
159. Die Kennzeichnung erscheint in Schild, VS, WS-/SS-Anmeldungen, WS-/SS-Planungen, Ergebnisvorschauen, manueller Teilnahme, Historie und weiteren Ansichten, die den zentralen Spielerlink verwenden.
160. Tabellenzeilen und Spieler-Karten werden zusätzlich farblich hervorgehoben; am Namen erscheint „🏖 Urlaub“.
161. Im Spieler-Gastzugang wird nur die Information „aktuell im Urlaub“ veröffentlicht; konkrete Urlaubszeiträume und Urlaubsnotizen bleiben intern.
162. Die Urlaubskennzeichnung ist weiterhin rein informativ und beeinflusst keine automatische Teamverteilung, Priorität oder Eventlogik.

NO-SHOW-STRAFE BEI ERSATZ-ANMELDUNG
163. Eine automatische Beförderung von einer Ersatz-Anmeldung ins Hauptteam ändert nicht die ursprüngliche Verbindlichkeit der Anmeldung.
164. WS: Nur ursprüngliche Anmeldungen „13 Uhr“, „22 Uhr“ oder „Egal“ können bei „Nicht teilgenommen“ automatisch 14 Tage depriorisiert werden.
165. WS: Ursprüngliche Anmeldungen „13 Uhr Ersatz“ oder „22 Uhr Ersatz“ erhalten keine automatische Depriorisierung, auch wenn die Planung sie wegen freier Plätze ins Hauptteam auffüllt.
166. SS: Entsprechend gelten „Team A“, „Team B“ und „Egal“ als Hauptteam-Anmeldung; „Team A Ersatz“ und „Team B Ersatz“ bleiben straffreie Ersatz-Anmeldungen.
167. Diese Regel gilt identisch für Ergebnis-Import und manuelle Teilnahme.
168. Beim Ergebnis-Import wird ein fehlender, automatisch hochgezogener Ersatzspieler standardmäßig als „Nicht eingesetzt“ statt „Nicht teilgenommen“ gesetzt.

ANMELDUNGEN ZURÜCKSETZEN
169. In „WS Anmeldung“ und „SS Anmeldung“ gibt es jeweils einen separaten Button zum Zurücksetzen aller aktuellen Anmeldungen.
170. Vor jedem Zurücksetzen muss eine Bestätigung erfolgen; ohne Bestätigung werden keine Daten verändert.
171. WS-Reset setzt ausschließlich `choice` auf „Keine Anmeldung“; SS-Reset setzt ausschließlich `ssChoice` auf „Keine Anmeldung“.
172. Historie, Vorrang, Depriorisierung, manuelle Reihenfolge, Heldenkraft, Rang, Notizen, Urlaub, Schild- und VS-Daten bleiben unverändert.
173. Nach dem Reset wird nur die betroffene Planung neu berechnet; WS und SS beeinflussen sich gegenseitig nicht.
174. Archivierte Spieltage können nicht über diesen Button zurückgesetzt werden.
175. Die Reset-Buttons sind nur für Planer und Admins sichtbar und nutzbar.

FARBEN DER ANMELDUNG
176. WS- und SS-Anmeldungen werden je Auswahl farblich unterschieden.
177. Die Farbe liegt direkt auf dem Auswahlfeld und bleibt deshalb auch bei gleichzeitig aktiver Urlaubsmarkierung sichtbar.
178. WS: 13 Uhr = grün, 13 Uhr Ersatz = gelb, 22 Uhr = blau, 22 Uhr Ersatz = orange, Egal = lila, Keine Zeit = rot, Keine Anmeldung = neutral.
179. SS: Team A = grün, Team A Ersatz = gelb, Team B = blau, Team B Ersatz = orange, Egal = lila, Keine Zeit = rot, Keine Anmeldung = neutral.
180. Beim manuellen Ändern der Anmeldung wird die Farbe sofort ohne Neuladen aktualisiert.

ALLIANZ-ZUG
181. Der Reiter „Allianz-Zug“ verwaltet pro Datum einen Zug-Führer und einen VIP.
182. Zug-Führer und VIP müssen unterschiedliche Spieler sein.
183. Planer und Admins dürfen Zug-Einträge anlegen, aktualisieren und löschen; Leser/Gäste haben eine Leseansicht.
184. Die Fairness-Übersicht zählt Zug-Führer, VIP und Zug gesamt automatisch aus der Zug-Historie.
185. Empfehlungen priorisieren zuerst Spieler mit weniger Einsätzen in der jeweiligen Rolle und danach Spieler, deren letzter Einsatz länger zurückliegt.
186. Aktuell urlaubende Spieler bleiben auswählbar, werden aber appweit mit 🏖 Urlaub markiert.
187. In den Spieler-Stammdaten gibt es die sortierbaren Spalten „Zug-Führer“, „VIP“ und „Zug gesamt“.
188. Im Spielerprofil werden Zug-Führer-, VIP- und Gesamtanzahl sowie der letzte Zug angezeigt.
189. Alte Zug-Einträge können über die Historie geladen, korrigiert oder gelöscht werden.
190. Interne Zug-Bemerkungen und „Erfasst von“ werden nicht an den Gastzugang veröffentlicht.

BENACHRICHTIGUNGEN
191. Die Benachrichtigungszentrale wird über die Glocke 🔔 im Kopfbereich geöffnet.
192. Die Auswahl „Mein Spieler“ und die Benachrichtigungsthemen werden pro Gerät lokal gespeichert.
193. Für den Gastzugang wird ein stabiler pseudonymer `notifyKey` veröffentlicht; die interne Spieler-ID bleibt weiterhin verborgen.
194. Browser-Benachrichtigungen werden nur nach ausdrücklicher Freigabe des Nutzers aktiviert.
195. Der private VAPID-Schlüssel darf niemals in Browser-Dateien, `config.js` oder den Gastzustand gelangen.
196. Echte Hintergrund-Pushs nutzen einen Service Worker sowie serverseitige Supabase Edge Functions.
197. Push-Abonnements werden in einer RLS-geschützten Tabelle gespeichert und sind nicht direkt für anon/authenticated lesbar.
198. V12.4.15 enthält zunächst Zentrale, Präferenzen, Geräte-Abonnement und Testweg; automatische Ereignis-Trigger werden separat aktiviert.
199. Das Deaktivieren von Push kündigt das Browser-Abonnement und deaktiviert den zugehörigen Geräte-Datensatz serverseitig, soweit erreichbar.

PLANUNGS-PUSH BEIM SPERREN
200. Bei der ersten Sperrung einer WS-/SS-Planung werden persönliche Einteilungs-Pushs ausgelöst.
201. Hauptteam, Ersatz und Warteliste werden mit ihrer konkreten Einteilung benachrichtigt; nicht eingeplante Spieler erhalten nichts.
202. Nach Entsperren, Änderung und erneuter Sperrung werden nur Spieler mit einer tatsächlichen Einteilungsänderung erneut benachrichtigt.
203. Auch neu eingeplante bzw. aus der Planung entfernte Spieler gelten als Änderung.
204. Unveränderte Spieler erhalten beim erneuten Sperren keinen zweiten Push.
205. Erste Veröffentlichungen verwenden die Geräteeinstellung „WS-/SS-Einteilung“, spätere Änderungen „Änderungen meiner Einteilung“.
206. Der letzte erfolgreich benachrichtigte Planstand wird je Event und Datum intern gespeichert, damit Änderungen sicher erkannt werden.
207. Planungs-Pushs dürfen serverseitig ausschließlich von angemeldeten Planern/Admins ausgelöst werden.
208. Kann die gesperrte Planung nicht zuerst in der Cloud gespeichert werden, wird kein Push versendet.
209. Scheitert der Push-Versand, bleibt die Planung gesperrt und der Planer erhält eine Fehlermeldung; ein erneuter Versuch ist durch Entsperren und erneutes Sperren möglich.

MOBILER KOPFBEREICH
210. Auf Smartphones zeigt der Kopf dauerhaft nur App-Name, aktuellen Reiter, Benachrichtigungsglocke und Menü-Schaltfläche.
211. Cloud-/Benutzerfunktionen und die Reiternavigation befinden sich auf Smartphones in einem aufklappbaren Menü.
212. Die mobile Reiternavigation wird als zweispaltiges Raster dargestellt und ist vertikal scrollbar.
213. Nach Auswahl eines Reiters schließt sich das mobile Menü automatisch.
214. Der Name des aktuell geöffneten Reiters wird direkt unter „UNNO Spielplanung“ angezeigt.
215. Auf Desktop bleibt die Navigation offen und direkt erreichbar.

ÜBERSICHTS-UPGRADE V12.5.6
216. „Mein Bereich“ zeigt die persönlichen aktuellen WS-/SS-Zuordnungen, Zug, Urlaub sowie ausgewählte Spielerstatistiken.
217. Die Auswahl in „Mein Bereich“ verwendet dieselbe Geräte-Spielerzuordnung wie die Benachrichtigungszentrale.
218. „Planung prüfen“ kontrolliert vor Veröffentlichung bekannte Konflikte und Warnmerkmale.
219. Ein kritischer oder warnender Prüfhinweis verhindert die Sperrung nicht automatisch, wird aber vor dem Sperren deutlich angezeigt.
220. „Push-Status“ ist ausschließlich für Planer/Admins sichtbar.
221. Push-Status „Gesendet“ bedeutet technisch „vom Push-Dienst angenommen“ und ist keine Garantie, dass das Betriebssystem die Meldung sichtbar dargestellt hat.
222. Das Änderungsprotokoll ist intern und wird nicht an den Gastzugang veröffentlicht.
223. Das Cockpit zeigt unter „Heute beachten“ aktuelle offene Aufgaben und Warnungen.
224. `version.json` wird für die Serverversionsprüfung immer ohne PWA-Cache geladen.
225. „Neue Version laden“ aktualisiert den Service Worker und leert die statischen App-Caches.

BROADCAST-TEST
226. Planer/Admins dürfen im Reiter „Push-Status“ eine manuelle Testnachricht an alle aktiv registrierten Push-Geräte senden.
227. Vor dem Broadcast muss eine Sicherheitsabfrage bestätigt werden.
228. Ein Gerät wird nur erreicht, wenn es ein aktives Push-Abonnement besitzt.
229. Persönliche Themenfilter gelten nicht für einen ausdrücklich vom Planer/Admin ausgelösten Broadcast-Test.
230. Broadcast-Versand darf serverseitig ausschließlich von angemeldeten Planern/Admins ausgelöst werden.
231. Der Versand wird im Push-Status und im Änderungsprotokoll dokumentiert.

ALLIANZ-ZUG TÄGLICH
232. Der Allianz-Zug wird im Cockpit täglich geprüft und ist nicht an einen bestimmten Wochentag gebunden.
233. Für den aktuellen Tag gilt ein Allianz-Zug erst als vollständig, wenn Zug-Führer und VIP beide vergeben sind.
234. Fehlt eine oder beide Rollen, zeigt „Heute beachten“ den aktuellen Tag und die fehlende Rolle an.
235. Erst wenn der heutige Zug vollständig vergeben ist, prüft das Cockpit den folgenden Tag.

SCHILD-ERINNERUNG ALS PUSH
236. Planer/Admins können für den im Schild-Reiter ausgewählten Samstag eine Schild-Erinnerung per Push auslösen.
237. Zielgruppe sind aktive, nicht entfernte Allianzmitglieder.
238. Die persönliche Geräteeinstellung „Schild-Erinnerung“ wird beim Versand berücksichtigt.
239. Ist „Schild-Erinnerung“ auf einem Gerät deaktiviert, erhält dieses Gerät die Erinnerung nicht.
240. Vor dem Versand muss eine Sicherheitsabfrage bestätigt werden.
241. Das Versandresultat wird im Push-Status und Änderungsprotokoll dokumentiert.

ALLIANZ-ZUG PUSH
242. Sobald Zug-Führer und VIP eines Tages vollständig eingetragen sind, werden die eingetragenen Personen automatisch über ihre jeweilige Rolle informiert.
243. Ein unvollständiger Allianz-Zug löst noch keinen Push aus.
244. Wird ein zunächst unvollständiger Zug später vervollständigt, werden Zug-Führer und VIP beide benachrichtigt.
245. Bei einem bereits vollständig veröffentlichten Zug löst eine reine Notizänderung keinen weiteren Push aus.
246. Wird Zug-Führer oder VIP geändert, wird nur die neu eingetragene Person dieser Rolle erneut benachrichtigt.
247. Die persönliche Geräteeinstellung „Allianz-Zug“ wird beim Versand berücksichtigt.
248. Allianz-Zug-Pushs werden im Push-Status und Änderungsprotokoll dokumentiert.

SELBSTTEST / PUSH-SYNCHRONISIERUNG
249. Bei einem bereits aktiven Push-Abonnement werden Änderungen an Spielerzuordnung und Push-Themen automatisch serverseitig synchronisiert.
250. Der Allianz-Zug-Push verwendet einen separaten Verarbeitungsstand je Datum, damit Notizänderungen keine Doppelmeldungen auslösen und ein echter Serverfehler erneut versucht werden kann.
251. Der Allianz-Zug-Verarbeitungsstand wird erst nach erfolgreicher Antwort der Push-Funktion aktualisiert.
252. Beim Löschen eines Allianz-Zug-Eintrags wird dessen Push-Verarbeitungsstand entfernt.
253. Der integrierte Selbsttest prüft neben den Planungsregeln auch No-Show-, Push- und Allianz-Zug-Sonderfälle.


EXPORT
37. Der Discord-Export verwendet immer den aktuell gültigen Planstand, inklusive manueller Änderungen oder gesperrtem Snapshot.

SPIELERPROFIL
38. Spielerprofile leiten Statistik und Status aus der globalen Historie und den aktuellen Stammdaten ab.

HISTORIE
39. Die Historie kann nach Event, Zeitraum, Spieler/Text und Status gefiltert werden.
40. Ist für einen Historieneintrag ein gespeicherter Spieltag vorhanden, kann dessen Planung direkt wieder geöffnet werden.

BACKUPS
41. Beim Sperren einer Planung und beim Abschließen eines Spieltags wird automatisch eine Backup-Version erstellt.
42. Lokal werden höchstens 12 Backup-Versionen gespeichert; sie können wiederhergestellt, heruntergeladen oder gelöscht werden.

MANUELLE PLANUNG
43. Ungesperrte Teamlisten können zusätzlich per Drag & Drop sortiert und zwischen Hauptteam, Ersatz und Warteliste verschoben werden. Die bisherigen Buttons bleiben als Alternative erhalten.

MOBILE ANSICHT
44. Auf Smartphones und Tablets wird die Navigation horizontal scrollbar, Bedienelemente werden vergrößert und Tabellen bleiben horizontal scrollbar. Die ↑/↓- und Verschieben-Funktionen bleiben als Touch-Alternative zu Drag & Drop erhalten.