PROJEKTAKTE – SSV-MESCHEDE JUDO APP
KONSOLIDIERTER ECHTBETRIEBS- UND DRIVE-ARBEITSSTAND
Stand der Konsolidierung: 27.08.2026 23:48
Letzter unveränderlicher ZIP-Rücksprungstand: 2026 08 27 23 48_SSV-Meschede_Judo_App_Projektstand.zip

0. ZWECK DIESER AKTE

Diese Datei ist ab diesem Projektstand die alleinige zentrale fachliche und technische Projektdokumentation für die SSV-Meschede Judo App.
Sie ersetzt die bisherige append-only Projektakte sowie die vier früher zusätzlich mitgeführten DOCX-Handbücher.
Die alten Migrationsunterlagen sind für die laufende Entwicklung nicht mehr maßgeblich und werden nicht mehr in neuen Projektständen mitgeführt.
Frühere Projekt-ZIPs bleiben unverändert als historische Rücksprungstände erhalten.

Ziel dieser konsolidierten Akte ist, dass eine andere fachkundige Person zusammen mit ChatGPT den aktuellen Stand nachvollziehen und weiterentwickeln kann, ohne frühere Chats lesen zu müssen.

Bei Widersprüchen gilt weiterhin diese Rangfolge:
1. aktuelle ausdrückliche Nutzeranweisung
2. diese aktuelle Projektakte
3. Masterprompt.txt
4. aktueller Code
5. ältere Projektstände und historische Chats

Diese Akte beschreibt den aktuellen Zustand und die noch offenen Punkte. Historische Reparaturversuche und überholte Zwischenstände wurden bewusst entfernt.

1. AKTUELLER GESAMTSTATUS

Produkt: SSV Meschede Judo App
Plattform: Google Sheets + gebundenes Google Apps Script
Version: 2.0
Produktivumgebung: PROD
Testumgebung: TEST / Spielwiese / APP-RANDORI
Zeitzone: Europe/Berlin

PROD-Kandidat dieses Projektstands:
- Code.gs: Drive-Arbeitsstand 27.08.2026 23:26, Gratulations-Abo und Geburtstagserfassung zusätzlich enthalten
- Index.html: Drive-Arbeitsstand 27.08.2026 23:38, inklusive Korrektur des zunächst gesperrten Gratulations-Abo-Hauptschalters
- DateRangeDialog.html: unverändert
- sichtbare App-Version nach Bereitstellung: Version 2.0 · Stand 27.08.2026

TEST-Kandidat dieses Projektstands:
- Code.gs: Drive-Arbeitsstand 27.08.2026 23:26, Gratulations-Abo und Geburtstagserfassung zusätzlich enthalten
- Index.html: Drive-Arbeitsstand 27.08.2026 23:38, inklusive Korrektur des zunächst gesperrten Gratulations-Abo-Hauptschalters
- DateRangeDialog.html: unverändert
- sichtbare App-Version nach Bereitstellung: TEST · Version 2.0 · Stand 27.08.2026 · 07:07

Wichtig: TEST wurde vom Nutzer mit dem neuen `Code.gs` und `Index.html` manuell bereitgestellt und anschließend mit dem korrigierten `Index.html` erneut bereitgestellt. Der Hauptschalter ist danach bedienbar. Beim Speichern der Einstellungen tritt aktuell jedoch der Fehler `Error: Spalte fehlt: Zugänge / Sitzungsversion` auf. TEST ist für P6.11 deshalb noch nicht abgenommen. PROD läuft im gebundenen Apps-Script weiterhin mit dem bestätigten Stand 20:31. Die 82 Geburtstagseinträge und neuen Spalten im PROD-Sheet sind bereits live. TEST behält seine harten allgemeinen E-Mail-/Backup-Sperren.

2. LETZTER PRAKTISCH BESTÄTIGTER BETRIEBSSTAND

Aktuelle Bereitstellungsgrenze 27.08.2026 23:48:
- TEST läuft praktisch mit `Code.gs` Stand 23:26 und `Index.html` Stand 23:38. Die Gratulations-Abo-Oberfläche ist sichtbar und der Hauptschalter nach der ersten Korrektur bedienbar. Beim Speichern erscheint jedoch `Error: Spalte fehlt: Zugänge / Sitzungsversion`. P6.11 ist damit weiterhin offen.
- PROD läuft im gebundenen Apps-Script praktisch weiterhin mit dem bestätigten Stand 20:31.
- Die aktuellen PROD-Quellen im Drive enthalten das Gratulations-Abo, sind aber noch nicht in PROD bereitgestellt. Die PROD-Sheet-Datenmigration mit 82 Geburtstagen und den neuen Abo-Spalten ist bereits real erfolgt.
- PROD `Linkverwaltung` enthält inzwischen die regulär erzeugten Personal-/Mitgliedschaftsfälle. Für P6.9 wurden die noch aktiven alten Inaktivitätsfälle am 27.08.2026 gezielt beendet; der Nachtlauf vom 28.08.2026 ist die neue Erstberechnung. TEST bleibt hiervon unberührt.

- Die Version 2.0 wurde am 22.08.2026 im Vorstand vorgestellt und freigegeben.
- PROD wurde am 23.08.2026 mit dem freigegebenen Stand tatsächlich bereitgestellt und anschließend als Admin geöffnet.
- Die PROD-Triggerstruktur wurde praktisch konsolidiert und kontrolliert.
- Systembericht und Backup-Konfiguration wurden in PROD praktisch gespeichert und nach erneutem Öffnen bestätigt.
- Die Quartals-Uhrzeit `10:00` wurde nach technischer Korrektur praktisch erfolgreich gespeichert und nach erneutem Öffnen korrekt angezeigt. Dieser Punkt ist erledigt.
- Der manuelle TEST-Lauf der bisherigen Inaktivitätsprüfung war trotz erster Performancekorrekturen weiterhin praktisch nicht akzeptabel und blieb erneut länger als eine Minute im Ladezustand.
- Der Nutzer hat die Fachlogik daraufhin präzisiert: Ferien, Feiertage und trainingsfreie Zeiten sind für diese Prüfung ausdrücklich irrelevant. Die bisherige 56-Tage-Zählung mit Abzug solcher Tage wird verworfen.
- Freigegeben und umgesetzt ist jetzt eine reine Kalendertageprüfung. Der Grenzwert ist als Admin-Einstellung `PERSON_INAKTIV_AUTOMATIK_TAGE` pflegbar und startet bei 63 Tagen. Die anschließende Bestätigungsfrist bleibt fest bei 7 Tagen.
- Die letzte Trainingsteilnahme wird aus einem einzigen Lauf über Trainings und Trainingsanwesenheiten ermittelt. Es gibt keine tageweise Ferien-/Pausenprüfung und nur noch einen vollständigen Kandidatenkontext je Automatiklauf.
- Historischer, praktisch getesteter TEST-Stand: Der frühere Admin-Button `Inaktivitätsprüfung jetzt ausführen` nutzte dieselbe Kernlogik wie PROD und zeigte die Laufzeit an. Dieser Button wird im V2-Stand durch den neuen Admin-Button `Personal-/Prüfungslauf ausführen` ersetzt.
- Der manuelle TEST-Lauf nach der Umstellung auf 63 reine Kalendertage wurde praktisch erneut ausgeführt. Der Nutzer bestätigt, dass der Lauf nun funktioniert und akzeptiert diesen Stand zunächst für den Echtbetrieb.
- Der erste reale PROD-Nachtlauf mit dieser Logik ist am 24.08.2026 erfolgreich gelaufen. Der Systembericht meldete den zentralen Nachtlauf um 02:25 mit Status OK. Archiv-Nachlauf und PIN-Synchronisation liefen um 02:24 mit OK, Drive-/Jahresarchiv um 02:25 mit OK und einem erzeugten Element, Datenbereinigung um 02:25 mit OK und dem erwarteten Hinweis, dass die Monatsbereinigung 2026-08 bereits erledigt war.
- Die Inaktivitätsautomatik meldete um 02:25 Status OK mit `created: 24` und `autoInactivated: 0`. Das Sheet-Backup meldete ebenfalls um 02:25 Status OK und erfolgreichen XLSX-Versand.
- Die Triggerkontrolle vom 23.08.2026 20:34 meldete Status OK. Der Quartalsautomatik-Trigger wird im Systembericht als vorhanden geführt. Damit sind erster PROD-Nachtlauf, Inaktivitätslauf, Backup, Archiv und Existenz der Quartalsautomatik praktisch bestätigt.
- Dass die Zeile `Systemstatus-E-Mail` im gerade erzeugten Systembericht selbst noch `noch nicht protokolliert` zeigt, ist logisch: Der Bericht wird erzeugt, bevor sein eigener aktueller Versand als letzter Lauf gespeichert werden kann. Dies ist kein Fehler und kein offener Punkt.
- Der persönliche Prüfungs-Mail-Pilot wurde im TEST anschließend praktisch mit frei eingegebener Testadresse und Gebühren-PDF geprüft. Der Nutzer bestätigt am 24.08.2026 ausdrücklich: Die Test-Prüfungs-E-Mail hat funktioniert wie vorgesehen.
- Auf dieser bestätigten Basis wurden die Prüfungs-Kommunikation sowie die Schutzoption gegen die Inaktivitätsautomatik in diesem Projektstand technisch für TEST und PROD zusammengeführt. Die neuen PROD-Funktionen sind technisch geprüft, aber ein realer produktiver Prüfungs-Mailversand ist noch nicht praktisch bestätigt.
- Die Kontaktdaten-Konsolidierung wurde am 24.08.2026 abgeschlossen. Grundlage war die vom Nutzer manuell geprüfte Arbeits-XLSX, ergänzt um die anschließend im Chat ausdrücklich festgelegten Korrekturen zu Jonas Kaiser, Moritz Kaiser und Jasper Riepe.
- Vor dem Schreiben wurden die betroffenen Live-Zeilen in PROD gegen den Ausgangsstand geprüft. Anschließend wurden bei 34 Personen ausschließlich die Kontaktfelder J:Q im Blatt `Personen` aktualisiert. Andere Personenfelder blieben unberührt.
- Die Kontaktmigration wurde nach dem Schreiben direkt aus dem PROD-Sheet zurückgelesen und bestätigt. Jasper Riepe wurde selbstständig anhand der vorliegenden bekannten Daten korrigiert.
- Die frühere Schreibkorrektur bei Moritz Kaiser wurde inzwischen im Live-PROD vorgenommen. Der aktuelle Wert lautet `Mutter ( Judith)`. Der Schreibfehler `Muitter` ist damit erledigt; das zusätzliche Leerzeichen innerhalb der Klammer ist lediglich ein verbleibender Datenpflegehinweis.
- Bei sechs weiterhin relevanten Mitgliedern ist bewusst noch keine E-Mail-Adresse bekannt: Emna Nuira, Johannes Spork, Lina Dogan, Lio Krick, Yurii Mykhailiuk und Juna Frausenga. Jarno Ebermann und Jarno Wiegele sind inaktiv, Luke Sassenberg und Niklas Brasse wurden vom Nutzer als Gäste eingeordnet.
- Bei der früheren Ausgabe der Kontroll-XLSX trat der bekannte URL-kodierte Dateinamenfehler erneut auf. Die bloße Verhaltensregel wurde deshalb verworfen. Der Projekt-Prüfhelfer besitzt zusätzlich einen allgemeinen technisch gesperrten Einzeldatei-Handoff über `--handoff-file`.
- Am 25.08.2026 wurde die separate native Live-Checkliste `SSV-Meschede Judo App – Checkliste` im Drive-Hauptordner der Judo-App eingerichtet. Sie besitzt `START`, `Aktuell` und `Erledigt`, native Erledigt-Checkboxen, strukturierte Prioritäts-/Statusfelder und eine smartphonefreundliche `Schnelle Idee`-Erfassung.
- Die Startseite der Live-Checkliste zeigt die ersten zwölf offenen Aufgaben dynamisch aus `Aktuell`. Nichtleere Schnellideen werden beim nächsten Arbeitslauf gelesen und eingeordnet, lösen aber niemals automatisch eine Umsetzung aus.
- Jeder neue Judo-Projektstand führt zusätzlich einen XLSX-Snapshot der Live-Checkliste unter `Checkliste/SSV-Meschede_Judo_App_Checkliste.xlsx` mit. Der native Google-Sheet-Link bleibt dauerhaft gleich.

TEST-REVISION 25.08.2026 – inzwischen praktisch weitgehend abgenommen:
- Aus dem Vorstandsgespräch wurde die Personenlogik neu gefasst: regulär aktiv, `Gelegentlich aktiv`, inaktiv im Archiv und externe Gäste.
- Die bisherige individuelle Ausnahmeliste gegen die Inaktivitätsautomatik wird in TEST durch den fachlichen Status `Gelegentlich aktiv` ersetzt.
- Für regulär aktive bestätigte Mitglieder gilt in TEST 94 Kalendertage ohne Training, anschließend 7 Tage Entscheidungsfrist. Aktionen: `Aktiv lassen`, `Gelegentlich aktiv`, `Jetzt inaktiv setzen`. Ohne Reaktion folgt die Archivierung.
- `Mitgliedschaft offen` wird nicht als fünfte Kategorie geführt. Nach 8 Wochen ohne Training folgt eine Warnung, danach 7 Tage Reaktionsfrist. Neue Teilnahme hebt die Warnung auf. Bestätigte Mitgliedschaft wechselt in die 94-Tage-Regel ab dem letzten Training.
- Externe können bevorzugt nur als Sammelposition `Externe Gäste` mit Anzahl erfasst werden. Namentlich erfasste Externe werden nach 8 Wochen ohne Training automatisch aus dem Personenbestand entfernt und ihre Trainingsteilnahmen zu `Externe Gäste` anonymisiert.
- Inaktive Personen werden aus dem operativen Blatt `Personen` in `Archiv_Personen` verschoben. Historische Bezüge bleiben erhalten. Sobald keine personenbezogene Historie mehr vorhanden ist, wird der komplette Personendatensatz gelöscht.
- Die Personalkartei blendet Inaktive und Externe standardmäßig aus. Beide besitzen getrennte Anzeige-Checkboxen. `Gelegentlich aktiv` wird violett markiert, `Mitgliedschaft offen` gelb/orange, Externe dunkelgrau mit weißer Schrift und Inaktive hellrot mit dunkler Schrift plus rotem Status-Chip. Normale aktive Mitglieder erhalten keinen Status-Chip.
- Für `Gelegentlich aktiv` wird die technische Trainingsgruppe `Selten da, aber immer wieder gern gesehen` verwendet. Rückkehr zu regulär aktiv erfolgt ausschließlich manuell.
- Die Inaktivitätsmail besitzt drei Aktionslinks. Die Web-App-Basisadresse wird validiert und gespeichert. Kann keine gültige Web-App-Adresse ermittelt werden, wird keine Mail mit defekten Aktionslinks erzeugt. Damit wird der am 24.08.2026 praktisch beobachtete Google-Drive-Fehler der bisherigen Links gezielt abgefangen.
- VERWORFEN seit 27.08.2026 20:36: Im Wettkampfeditor wurde zwischenzeitlich eine Schaltleiste mit 1., 2., 3., 4./5., 6./7. Platz oder ohne Platzierung verwendet. Diese Sammelplatz-Logik ist nicht mehr maßgeblich. Aktuell gelten wieder die Einzelplätze 1 bis 7.
- Sicherheitsgrenze: Hat eine temporäre externe oder noch nicht bestätigte Person bereits andere personenbezogene Historie außerhalb von Training, wird die automatische Komplettlöschung ausgesetzt, statt Fremdschlüssel oder fachliche Historie zu zerstören. Dieser Sonderfall muss vor PROD praktisch bewertet werden.

KONSOLIDIERUNG DER PARALLELEN CHATSTÄNDE 25.08.2026:
- Verglichen wurden die beiden neuesten Drive-Archivstände `2026 08 24 23 41_SSV-Meschede_Judo_App_Projektstand.zip` und `2026 08 25 00 35_SSV-Meschede_Judo_App_Projektstand.zip`.
- Der Stand 23:41 dokumentiert insbesondere die abgeschlossene Kontaktdatenmigration und die vollständig eingerichtete Drive-Archivsystematik.
- Der Stand 00:35 enthält den neueren TEST-Code für Personensystematik, Inaktivitätslinks und Wettkampf-Platzierungsleiste.
- Der PROD-XLSX-Snapshot sowie alle PROD-Laufzeitdateien sind zwischen beiden Ständen bytegleich. Es existiert deshalb kein fachlicher Datenkonflikt in PROD.
- Für die Konsolidierung wird der neuere TEST-Laufzeitstand 00:35 beibehalten. Die detaillierten und weiterhin gültigen Drive-/Übergaberegeln aus 23:41 werden vollständig wieder aufgenommen.
- Die Konsolidierung selbst ändert keinen PROD- oder TEST-Laufzeitcode.


3. AKTUELLER DATENSTAND PROD

Verbindlicher Daten-Snapshot dieses Projektstands:
PROD/PROD_Judo App 2.0.xlsx

Quelle: direkter Export des aktuellen produktiven Google-Sheets am 27.08.2026 21:12.
SHA-256 dieses Snapshots:
ceb69d556099e76318196ef7f3fe3bef3b881459d8df1061771ee9d8f64f8753

Der Snapshot enthält 52 Tabellenblätter und bildet den produktiven Datenstand nach der Kontaktdatenmigration ab. Er enthält unter anderem den vollständigen aktuellen Gewichtsklassenbestand, die Liga-Verbindungstabellen und die aktualisierten Kontaktfelder.

Wichtig:
- Dieser PROD-Snapshot ist für Datenstruktur und tatsächlichen Datenbestand maßgeblich.
- Die Projekt-ZIP ist dadurch vertraulich. Sie enthält personenbezogene Daten, Zugangsdaten/PIN-Felder, Kontaktinformationen und technische Verbindungsdaten.
- Keine Inhalte dieses XLSX ungeprüft öffentlich weitergeben.

4. TEST-DATENSTAND

Der TEST-Datenbestand ist nicht Teil des neuen kompakten Übergabestands.
Grund: Der bisher beigelegte TEST-XLSX-Snapshot war strukturell älter als der aktuelle PROD-Stand und könnte bei einer Übergabe irreführen.

Verbindliche Regel:
- TEST-Code wird vollständig mitgeführt.
- TEST-Fachdaten sind nicht maßgeblich und dürfen aus PROD neu aufgebaut beziehungsweise über die bestehende Spielwiesen-Synchronisierung aktualisiert werden.
- Ein neues TEST-Sheet muss technisch als TEST gekennzeichnet sein und mit dem TEST-Code eingerichtet sein, bevor die PROD→TEST-Synchronisierung verwendet wird.
- `Spielwiese aktualisieren` arbeitet ausschließlich PROD → TEST und darf niemals in Gegenrichtung schreiben.
- TEST-spezifische Einstellungen bleiben beim Synchronisieren geschützt.

4A. LIVE-CHECKLISTE UND SCHNELLE IDEEN

Dauerhafte operative Aufgabenoberfläche:
- Google Sheet: `SSV-Meschede Judo App – Checkliste`
- Drive-Pfad: `Judo App → SSV-Meschede Judo App – Checkliste`
- Datei-ID: `1llcvhUpzWvtw2hBHgDDItlc97ABR1vUeEIorOHX2jgc`
- Blätter: `START`, `Aktuell`, `Erledigt`

`START` enthält eine kompakte Prioritätenübersicht und sechs freie Zeilen für schnelle Ideen. Diese Ideen sind reine Eingaben und lösen keine automatische Umsetzung aus. Beim nächsten Arbeitslauf werden sie gelesen, eingeordnet und erst danach als Aufgabe übernommen oder verworfen.

`Aktuell` ist die vollständige offene Liste mit Erledigt-Checkbox, Priorität, ID, Bereich, Aufgabe, Status, Notiz und Datumsfeldern. `Erledigt` ist die Abschlussliste. Nutzerseitige Änderungen im Live-Sheet sind bei Aufgabenstatus aktueller als ein älterer Projekt-Snapshot.

Jeder neue Judo-Projektstand enthält einen XLSX-Snapshot unter `Checkliste/SSV-Meschede_Judo_App_Checkliste.xlsx`. Der native Sheet-Link bleibt dauerhaft gleich und wird nicht durch das Neuaufbauen von `Aktueller Projektstand/Judo App` ersetzt.

5. PROJEKTDATEIEN UND TECHNISCHE ARCHITEKTUR

Die Apps-Script-Web-App besteht je Umgebung genau aus drei Laufzeitdateien:
- Code.gs
- Index.html
- DateRangeDialog.html

Code.gs enthält:
- Datenmodell und Schemaaufbau
- Validierungen
- Geschäftslogik
- Rechteprüfung
- PIN-/Sitzungslogik
- Server-RPCs
- E-Mail-Funktionen
- Trigger und Automationen
- Backup, Archiv und Bereinigung
- PROD→TEST-Synchronisierung
- Statistik- und Exportlogik
- Liga-Import-/Verbindungslogik

Index.html enthält:
- gesamte Web-App-Oberfläche
- Clientzustand und Routing
- smartphoneorientiertes Layout
- Formulare, Listen und Modals
- Bottom-Navigation
- APP-RANDORI in TEST
- clientseitige Caches und Ladezustände
- eingebettetes Vereinslogo als Wasserzeichen

DateRangeDialog.html enthält den gemeinsam verwendeten Datumsbereichsdialog.

Zusätzliche Projektdateien:
- 00_START_HIER.txt
- Masterprompt.txt
- Projektakte.txt
- Projektstand_erstellen_und_pruefen.py
- Judo.ai
- Judo_umgekehrt_freigestellt.ai
- Judo_umgekehrt_freigestellt.png
- Designreferenzen
- aktueller PROD-XLSX-Snapshot

6. UMGEBUNGSTRENNUNG UND SICHERHEIT

PROD:
- APP.ENVIRONMENT = PROD
- E-Mail-Ausgabe aktiv
- Backup aktiv
- produktive Trigger/Archive/Bereinigung aktiv
- Spielwiese kann aus PROD aktualisiert werden

TEST:
- APP.ENVIRONMENT = TEST
- EMAIL_ENABLED = false
- BACKUP_ENABLED = false
- normale produktive E-Mail- und Backup-Pfade sind serverseitig gesperrt
- freigegebene Ausnahme: persönliche Prüfungs-Muster-E-Mail bei Neuanlage. Empfänger ist ausschließlich eine im Prüfungsformular manuell eingegebene Testadresse. Reale Personen-/Kontaktadressen werden im TEST dafür nie verwendet.
- APP-RANDORI ist sichtbar vorgeschaltet
- TEST enthält Performance-Diagnostik, soweit weiterhin im Code vorhanden
- TEST enthält für Admin den neuen Button `Personal-/Prüfungslauf ausführen` in der Personalkartei.
- Der manuelle Personal-/Prüfungslauf arbeitet fachlich wie PROD, verschickt im TEST aber ausschließlich an eine im Dialog frei eingegebene TEST-E-Mail-Adresse. Reale hinterlegte Empfänger werden im TEST nicht angeschrieben.

PROD und TEST dürfen niemals an dasselbe Google Sheet gebunden werden.
Der Code prüft die Umgebungskennung des Sheets gegen die Code-Umgebung.

7. LOGIN, ZUGÄNGE UND SITZUNGEN

Person und App-Zugang sind getrennte Objekte.

Unterstützt werden:
- persönliche PIN-Zugänge
- Sammel-/Notzugang mit PIN und anschließender Auswahl der handelnden Trainerperson

Persönliche Sitzung:
- maximal 8 Stunden Inaktivität

Sammelzugang:
- maximal 60 Minuten Inaktivität
- nur aktive Personen mit persönlichem Trainer-App-Zugang stehen bei `Wer bin ich?` zur Auswahl
- die Auswahl ist keine persönliche Authentifizierung
- der Sammelzugang behält feste Minimalrechte

Sicherheitsgrenzen:
- nach 8 lokalen Fehlversuchen 15 Minuten Sperre
- zusätzliche globale Fehlversuchsbegrenzung
- Fehlermeldungen dürfen keine PIN-Zuordnung verraten
- Wartungsmodus sperrt Nicht-Admins einschließlich laufender Sitzungen

Erfolgreiche Loginereignisse können für den Systembericht mit Person, Zeitpunkt und Zugangsart protokolliert werden. Fehlversuche werden nur aggregiert und ohne PIN-Inhalte erfasst.

8. ROLLEN UND RECHTE

Aktive App-Rollen im aktuellen PROD-Sheet:
- Trainer
- Vorstand
- Anzugverwaltung
- Admin

Admin besitzt alle Rechte. Die Adminrolle ist technisch geschützt.

Grundprinzip:
- App-Rolle ist nicht identisch mit der fachlichen Einsatzrolle Trainer/Übungsleiter/Trainer-Assistent.
- Rechte werden serverseitig geprüft. Die UI allein ist keine Sicherheitsgrenze.
- historische Einsatzrollen und Prüfungsberechtigungen werden in eigenen Verlaufstabellen geführt.

Trainer darf unter anderem Training und Wettkampf erfassen/bearbeiten, operative Personenanlage nutzen und Gruppenzuordnungen beenden.
Vorstand erweitert dies um Personenverwaltung, Statistiken, Quartalsabrechnung, ÜL-Daten und weitere Verwaltungsfunktionen.
Anzugverwaltung erhält gezielten Zugriff auf die Anzugverwaltung.
Admin verwaltet zusätzlich System, Zugänge, Rollen, TEST-Verbindung und technische Funktionen.

9. NAVIGATION UND BEDIENKONZEPT

Smartphone-first für Trainer und operative Nutzung.
Ausgewählte Verwaltungs-/Statistikbereiche bleiben bewusst desktoporientiert.

Bottom-Navigation:
- Start
- Trainings
- Wettkämpfe
- Mehr

Start-Hauptbereiche für Berechtigte:
- Training: Orange
- Wettkampf: Blau
- Auswertungen: Gold
- Personalkartei: Grün
- Prüfungen: Violett

Rot bleibt Warnungen, Fehlern und kritischen Zuständen vorbehalten.

`Zurück`:
- in allen angemeldeten App-Ansichten außer Start sichtbar
- nutzt den internen Routenverlauf
- sichere Rückfallebene ist Start
- Bottom-Navigation wird in den Verlauf einbezogen

Kopfmenü:
- Aktualisieren
- Passwort/PIN-Funktion abhängig vom Zugang
- Abmelden

UI-Grundsätze:
- Navy-Grundstil
- einheitliche Kachelgrößen
- Desktop-Hubs maximal drei Kacheln nebeneinander
- iPhone/iPad-Safe-Area berücksichtigt
- keine unnötigen verschachtelten vertikalen Scrollbereiche
- lange Listen mit Suche, Filterung und mobilen Auswahlfenstern

Vereinslogo:
- verbindliche Originalquelle `Judo_umgekehrt_freigestellt.png`
- SHA-256: f47abe59f1e5d0e432e2173d00b03f8b19b22c0db05aa03c834ba56773c7cc8e
- bytegenau in PROD/TEST Index.html eingebettet
- globales dezentes Wasserzeichen in angemeldeten Ansichten
- keine Nachzeichnung und keine Farb-/Graustufenfilter

10. STARTSEITE UND HINWEISE

Die Startseite lädt zuerst die für den aktuellen Tag wichtigen Daten und vermeidet große Startpakete.
Sekundärdaten und Hinweise werden nachgelagert geladen.

Angezeigt werden unter anderem:
- Trainings heute
- Trainerteam und Teilnehmerzahl
- nächste Wettkämpfe
- fehlende erwartete Trainings
- Schnellaktion für aktuelles Training
- Hinweis-/Aufgabenzähler für Berechtigte

Schnellaktion Training:
- ab 10 Minuten vor geplantem Trainingsbeginn
- bis 20 Minuten nach geplantem Trainingsende
- vorhandenes Training → bearbeiten
- nicht vorhandenes Training → anlegen

Fehlende Trainings:
- Dashboard verwendet 14 Tage
- Hinweiscenter besitzt den weitergehenden Aufgabenpfad
- gespeicherte Trainings, Ausfälle, Kalenderausnahmen und trainingsfreie Zeiten werden berücksichtigt

Hinweisbereiche:
- Training
- Personal
- Prüfung
- Anzug
- weitere System-/Verwaltungsfälle je Berechtigung

Erledigte Hinweise bleiben gemäß Einstellung 90 Tage sichtbar.

11. TRAININGSMODUL

Grundablauf:
1. Datum und Trainingsgruppe
2. verantwortlicher Trainer und optional Übungsleiter/Assistent
3. Stammteilnehmer und Gäste
4. Bemerkung
5. speichern

Wesentliche Regeln:
- Dublettenschutz für Gruppe + Datum
- serverseitige erneute Prüfung unter Dokumentensperre
- parallele Bearbeitung darf neueren Stand nicht unbemerkt überschreiben
- verantwortlicher Trainer ist grundsätzlich eindeutig
- einzelne Gruppen dürfen ausdrücklich Training ohne verantwortlichen Trainer zulassen
- fachliche Trainingsdauer und formelle ÜL-Meldedauer sind getrennt
- ein normales gespeichertes Training entspricht für Vergütung genau 1 TE
- ÜL-Meldedauer kann durch Berechtigte in 0,5-Stunden-Schritten abweichen
- grundsätzlich ehrenamtliche Gruppen erzwingen den Ehrenamtsstatus

Teilnehmer:
- Stammgruppe direkt verfügbar
- Gäste über phonetische/mehrfeldige Personensuche
- Suche berücksichtigt Nachname, Vorname und Rufname
- neue Personen können im Trainingskontext schlank angelegt werden
- Gäste können als Stammteilnehmer übernommen werden, wenn das bestehende Recht vorliegt

Stammteilnehmer aus Gruppe entfernen:
- `Aus Gruppe entfernen` beendet nur die aktuelle Gruppenzuordnung
- historische Trainings bleiben unverändert
- `Trainiert nicht mehr im SSV` setzt durch Trainer nicht direkt inaktiv, sondern erzeugt einen bestätigungspflichtigen Vorgang für Vorstand/Admin

Performance:
- Trainingsanlage wurde intensiv optimiert und wird subjektiv als sehr schnell bewertet
- Gruppenwechsel läuft lokal
- Datumswechsel verwendet einen kleinen Datumskontext statt Vollreload
- nach Speichern kein unnötiger Bootstrap-Aufruf
- Caches werden gezielt als veraltet markiert und erst beim tatsächlichen nächsten Bedarf neu geladen
- synchrones Änderungsprotokoll bleibt Teil des sicheren Speichervorgangs

12. TRAININGSGRUPPEN – AKTUELLER PROD-STAND

Aktive Gruppen:
- Minis: Dienstag 16:15–18:00, Standard ÜL 1,5 h
- Anfänger: Montag 16:00–17:30, Mittwoch 16:45–18:00, Standard ÜL 1,5 h
- Fortgeschrittene: Montag 17:30–19:00, Mittwoch 18:00–19:15, Standard ÜL 1,5 h
- Erwachsene: Montag 19:00–20:30, Mittwoch 19:15–20:30, Standard ÜL 1,5 h
- Technik: keine feste Standardzeit, Standard ÜL 1,5 h
- Workout: Dienstag 19:00–20:30, Standard ÜL 1,5 h
- Bezirks- / Landestraining: Standard ÜL 0 h, ohne verantwortlichen Trainer erlaubt
- Freies Training: Dienstag 18:00–19:00, Standard ÜL 1,0 h, grundsätzlich ehrenamtlich, ohne verantwortlichen Trainer erlaubt
- Ligamannschaft: Standard ÜL 1,5 h, grundsätzlich ehrenamtlich, ohne verantwortlichen Trainer erlaubt
- Sonstiges: Standard ÜL 1,5 h, grundsätzlich ehrenamtlich, ohne verantwortlichen Trainer erlaubt

Archivgruppe:
- zz_sonstiges (Archiv), inaktiv

13. PERSONEN UND PERSONALKARTEI

Verbindliches Zielmodell ab der TEST-Revision 25.08.2026:
- `Aktiv`: reguläres bestätigtes Mitglied. Standardstatus, kein zusätzlicher Status-Chip.
- `Gelegentlich aktiv`: bestätigtes Mitglied, das bewusst sehr selten trainiert, aber weiterhin dazugehört. Beispiele aus der Konzeptdiskussion waren Jan, die Hamänner oder Yannick. Technische Sondergruppe: `Selten da, aber immer wieder gern gesehen`. Keine automatische Inaktivierung. Rückkehr zu regulär aktiv nur manuell.
- `Inaktiv`: Archivstatus für Personen, mit deren Rückkehr aktuell nicht gerechnet wird. Der Datensatz wird sofort aus dem operativen Blatt `Personen` entfernt und vollständig nach `Archiv_Personen` verschoben. Historische Teilnahmen und andere vorhandene Historie bleiben namentlich erhalten.
- `Extern`: Person aus einem anderen Verein. Bevorzugt überhaupt nicht namentlich dauerhaft erfassen, sondern im Training als Sammelposition `Externe Gäste` mit Anzahl. Eine namentliche Erfassung bleibt möglich und wird als extern gekennzeichnet.
- `Mitgliedschaft offen`: kein fünfter Personenstatus, sondern weiterhin ein Merkmal für Schnupperer/neue Personen ohne bestätigte Mitgliedschaft.

Lösch- und Rückkehrlogik:
- Inaktive bleiben vollständig im Archiv, solange irgendeine personenbezogene Historie im aktuellen System auf sie verweist. Sobald keine solche Historie mehr vorhanden ist, wird der gesamte Datensatz gelöscht. Keine Teil-Löschung einzelner Kontaktfelder.
- Rückkehrer werden aus `Archiv_Personen` reaktiviert, solange der Archivdatensatz noch existiert. Nach vollständiger Löschung erfolgt eine Neuanlage.
- Namentlich erfasste Externe werden nach 8 Wochen ohne Training vollständig gelöscht. Ihre bisherigen Trainingsteilnahmen werden vorher nur noch als `Externe Gäste` gezählt. Jede neue Teilnahme startet die 8 Wochen neu.
- Personen mit `Mitgliedschaft offen` erhalten nach 8 Wochen ohne Training eine Warnung und anschließend 7 Tage Reaktionszeit. Ohne Reaktion werden Personendaten gelöscht und bisherige Trainingsteilnahmen als `Schnupperteilnahmen` anonymisiert. Bei noch nie erfolgtem Training laufen die 8 Wochen ab Anlagedatum.
- Eine neue Trainingsteilnahme während der Warnfrist hebt die Löschwarnung auf und startet die 8 Wochen neu. Wird die Mitgliedschaft bestätigt, gilt stattdessen die 94-Tage-Regel ab dem letzten Training.
- Sonderfall nach vollständiger Löschung: Kommt ein früherer Schnupperer später zurück, wird er neu angelegt. Ein administrativ gepflegtes erstes Training kann bei Bedarf neu gesetzt werden. Die alte personenbezogene Trainingsteilnahme bleibt bewusst anonymisiert.
- Sicherheitsgrenze im TEST: Existiert bei einem temporären Datensatz bereits personenbezogene Historie außerhalb von Training, wird die automatische Komplettlöschung ausgesetzt. Damit werden keine Wettkampf-, Prüfungs- oder sonstigen Referenzen zerstört.

Personalkartei Hauptmenü:
- Standardansicht: regulär aktive, gelegentlich aktive und Personen mit offener Mitgliedschaft.
- getrennte Checkbox `Inaktive anzeigen`
- getrennte Checkbox `Externe anzeigen`
- normale aktive Mitglieder ohne Statuskennzeichnung
- `Gelegentlich aktiv`: violetter Status-Chip
- `Mitgliedschaft offen`: gelb/orange hervorgehoben
- Externe nur nach aktivierter Checkbox, dunkelgraue Kachel mit weißer Schrift
- Inaktive nur nach aktivierter Checkbox, hellrote Kachel mit dunkler Schrift und rotem Chip `Inaktiv`

Personensuche berücksichtigt Nachname, tatsächlichen Vornamen und Rufname. Bei abweichendem Rufnamen wird der tatsächliche Vorname zusätzlich angezeigt.

14. INAKTIVITÄTS- UND BEREINIGUNGSAUTOMATIK

PROD-Stand:
- PROD bleibt bis zur praktischen TEST-Freigabe unverändert auf der bisher bestätigten 63-Tage-Logik mit 7-Tage-Frist und individueller Schutzoption.

TEST-Zielsystematik:
- Nur regulär aktive bestätigte Mitglieder nehmen an der 94-Tage-Prüfung teil.
- `Gelegentlich aktiv`, Externe und `Mitgliedschaft offen` sind ausdrücklich nicht Teil dieser 94-Tage-Prüfung.
- Trainer-/ÜL-/Assistentenfunktionen sowie Vorstand/Admin bleiben entsprechend der bestehenden Schutzlogik von einer automatischen Inaktivierung ausgenommen.
- Maßgeblich sind reine Kalendertage. Ferien, Feiertage und trainingsfreie Zeiten werden nicht abgezogen.
- Bezugsdatum ist die letzte Trainingsteilnahme. Nach `Aktiv lassen` beginnt die 94-Tage-Frist ab dieser Entscheidung neu.
- Nach 94 Tagen erhalten die konfigurierten Inaktivitäts-Empfänger einen Vorgang mit 7 Tagen Entscheidungsfrist.
- `Aktiv lassen`: Person bleibt regulär aktiv und die 94-Tage-Frist startet neu.
- `Gelegentlich aktiv`: reguläre aktive Gruppenzuordnungen werden beendet und die Person wird der technischen Gruppe `Selten da, aber immer wieder gern gesehen` zugeordnet.
- `Jetzt inaktiv setzen`: sofortige Verschiebung nach `Archiv_Personen` und Entfernung aus operativen Listen.
- Ohne Reaktion nach 7 Tagen: automatische Inaktivierung/Archivierung.
- Neue Trainingsteilnahme innerhalb der 7 Tage beendet den offenen Vorgang.

Temporäre Personen:
- Extern: 56 Tage ohne Training, dann automatische Löschung ohne Vorwarnung. Trainingsteilnahmen werden zuvor in die Sammelzahl `Externe Gäste` überführt.
- Mitgliedschaft offen: 56 Tage ohne Training, dann Warnung an denselben Inaktivitätsverteiler. Nach weiteren 7 Tagen ohne Reaktion vollständige Löschung und Anonymisierung zu `Schnupperteilnahmen`.
- Noch nie trainiert: 56 Tage ab Anlagedatum.
- Mitgliedschaft während der Warnfrist bestätigt: Warnung endet, anschließend gilt 94 Tage ab letzter Trainingsteilnahme.

Inaktive Archivpersonen:
- Der Nachtlauf prüft, ob noch personenbezogene Historie vorhanden ist.
- Ohne verbleibende Historie wird der vollständige Archivdatensatz gelöscht.
- Historische Auswertungen zeigen den Namen weiterhin, solange der Archivdatensatz existiert.

Linkkorrektur:
- Der erste reale PROD-Inaktivitätsversand am 24.08.2026 enthielt praktisch unbrauchbare Links, die beim Öffnen auf eine Google-Drive-Fehlerseite führten.
- TEST validiert die Web-App-Basisadresse und speichert eine bestätigte Adresse. Die drei Aktionslinks werden nur erzeugt, wenn eine gültige Apps-Script-Web-App-Adresse verfügbar ist. Im Fehlerfall wird der Versand gestoppt statt defekte Links zu versenden.

TEST-Status:
- technisch umgesetzt und statisch geprüft
- TEST-E-Mail-Sperre bleibt aktiv
- praktische Prüfung im echten TEST-Sheet steht noch aus
- erst danach darf eine Übernahme nach PROD erfolgen

Verworfen bzw. ersetzt:
- 63 Tage als zukünftiger Zielwert. Dieser Wert bleibt nur noch im unveränderten PROD-Altsstand bis zur Freigabe der neuen TEST-Logik.
- individuelle Schutzcheckbox als zukünftiges Fachmodell. Sie wird in TEST durch `Gelegentlich aktiv` ersetzt.
- allgemeine dauerhafte Gast-Personen als Standardweg
- Ferien-/Feiertagsabzug
- tageweise Inaktivitätsberechnung

15. WETTKAMPFMODUL

Wettkampfgrunddaten:
- Datum
- Wettkampfname
- Austragungsort
- allgemeine Betreuungsdauer
- Bemerkung
- Wettkampfart über strukturierte Tabelle

Teilnehmer:
- Person
- Altersklasse
- Gewichtsklasse
- Platzierung
- individuelle Bemerkung
- offizielles Waagegewicht getrennt
- einzelne Kampfergebnisse G/V

Neue TEST-Bedienung Platzierung – VERWORFEN seit 27.08.2026 20:36:
- Überschrift `Platzierung:`
- exklusive Einzelauswahl im Checkbox-/Schaltleisten-Stil
- `1. Platz` mit goldener Medaillenoptik
- `2. Platz` mit silberner Medaillenoptik
- `3. Platz` mit bronzener Medaillenoptik
- `4./5. Platz`
- `6./7. Platz`
- `ohne Platzierung`
- Es kann technisch nur eine Platzierung gleichzeitig ausgewählt werden. Die serverseitige Normalisierung akzeptiert auch bisherige Einzelwerte 4/5 und 6/7 kompatibel.

Weitere Regeln:
- dieselbe Person darf am selben Datum nicht gleichzeitig in zwei Wettkämpfen als Teilnehmer geführt werden
- Externe werden in TEST aus der internen Wettkampf-Personenauswahl ausgeschlossen
- Altersklasse wird vorgeschlagen, bleibt änderbar
- Gewichtsklasse aus zentralen Regeln
- `Individuelle GK` nur in zulässigem Format
- reguläre Gewichtsklassen dürfen beim Wiederöffnen nicht als individuell umgedeutet werden

Performance:
- Wettkampf-Speichern wurde von einem deutlich langsameren Ausgangszustand spürbar verbessert
- Neuanlage schreibt Kindtabellen blockweise
- Speichern liefert die Zusammenfassung im selben RPC zurück
- Detailcache für Teilnahmen, Ergebnisse, Waage und Betreuung bleibt bestehen

16. WETTKAMPFANMELDUNG UND RÜCKMELDUNG

Unterstützt werden:
- interne Wettkampfvorbereitung
- Einladungen über Vorlagen
- persönliche öffentliche Rückmeldelinks
- Teilnahme/Nichtteilnahme
- Gewichtsrückmeldung
- Nachsendung von Ausschreibungsinformationen
- Aktualisierungen
- Abschlussinformation
- technische Linkverwaltung und Ablaufstatus

Öffentliche Links ändern sensible Zustände nicht allein durch bloßes Öffnen, wenn eine Bestätigung erforderlich ist.
TEST-E-Mail-Ausgabe bleibt grundsätzlich gesperrt. Spezifische historische Testausnahmen dürfen die allgemeine Sperre nicht aufheben.

17. WETTKAMPFBETREUUNG, TE UND ÜL-STUNDEN

Vergütung:
- Wettkampfbetreuung mindestens 1 TE
- jede angefangene 90-Minuten-Einheit zählt als weitere TE
- Beispiele: 10 min = 1 TE, 90 min = 1 TE, 91 min = 2 TE, 181 min = 3 TE

ÜL-Stundenmeldung:
- tatsächliche Betreuungsdauer
- mindestens 1,5 h
- auf nächste halbe Stunde aufrunden
- 1:30 = 1,5 h
- 1:31 = 2,0 h

Vorbereitung wird nicht separat vergütet oder als ÜL-Stunde gemeldet.
Reisekosten und Spesen werden je Betreuung mit Bezeichnung geführt.

18. PRÜFUNGEN

Prüfungsmodell:
- Prüfungsvorgang mit Datum, Prüfer 1 und optional Prüfer 2
- mehrere Prüfungsfälle je Vorgang
- Person und neue Graduierung
- Kommentar
- Prüfungsgebühr bezahlt
- DokuMe übertragen
- Historien-Verknüpfung

Rechte:
- Admin
- Vorstand
- aktuell prüfungsberechtigte Personen

Gebührenstatus:
- berechtigte Prüfungsnutzer können bezahlt markieren
- Rücknahme nur Vorstand/Admin

DokuMe:
- ausschließlich Vorstand/Admin

Prüfungscontrolling:
- Zeitraum
- Filter
- Favoriten
- Export/Versand

UI-Korrekturen abgeschlossen:
- Suchtreffer kontrastreich und getrennt
- Direktlink gibt sichtbare Rückmeldung
- Prüfungsstatus aktualisiert sich nach Änderungen
- Speichern besitzt sichtbare Ladeanzeige
- offene Prüfung kann bis zur Erledigung von Gebühr/DokuMe optisch hervorgehoben werden

Persönliche Prüfungs-E-Mail:
- Der TEST-Pilot ab 23.08.2026 23:20 wurde praktisch erfolgreich geprüft. Der Nutzer bestätigte am 24.08.2026, dass die Test-Prüfungs-E-Mail wie vorgesehen funktioniert.
- Bei der Neuanlage eines TEST-Prüfungsvorgangs bleibt das optionale Feld `TEST-E-Mail-Empfänger`. Muster-E-Mails gehen ausschließlich an die dort unmittelbar eingegebene Testadresse. Reale Personen- oder Kontaktadressen werden im TEST nie verwendet. `EMAIL_ENABLED = false` bleibt unverändert.
- Betreff im TEST: `TESTMUSTER · Glückwunsch zu deiner bestandenen Gürtelprüfung`. PROD verwendet `Glückwunsch zu deiner bestandenen Gürtelprüfung`.
- Persönliche Anrede verwendet Rufname, ersatzweise Vorname. Bei `weiblich` wird `Liebe`, bei `männlich` `Lieber`, sonst `Hallo` verwendet. Bei Prüfung am aktuellen Tag steht `heute`, sonst `am TT.MM.JJJJ`.
- Der fachlich abgestimmte Standardtext enthält Glückwunsch, Hinweis auf den weiteren Judo-Weg, 15 Euro Prüfungsgebühr, Zweck der Gebühr sowie den Hinweis zur Überweisung und zum Vor-/Nachnamen im Verwendungszweck.
- Der Mailtext ist jetzt unter Systemeinstellungen → Kommunikation → `Prüfungen` bearbeitbar. Pflichtplatzhalter `{{ANREDE}}`, `{{ZEITPUNKT}}` und `{{KYU_GRAD}}` müssen erhalten bleiben. Optional stehen `{{VORNAME}}` und `{{NAME}}` zur Verfügung. Damit bleiben persönliche Anrede, Prüfungszeitpunkt und Grad technisch gesichert.
- Die Prüfungsgebühr-PDF wird nicht im Code gespeichert. In derselben Kachel wird `PRUEFUNG_GEBUEHR_PDF_DRIVE` als Google-Drive-Link oder Datei-ID gepflegt. Beim Speichern wird geprüft, dass die Datei erreichbar und eine PDF ist.
- Die bestehende Einstellung `Wer soll bei Prüfungen benachrichtigt werden?` ist ebenfalls in derselben Kachel gebündelt. Damit liegen Empfänger der internen Prüfungsbenachrichtigung, persönlicher Mailtext und Gebühren-PDF an einer Stelle und erscheinen nicht als verstreute Einzelzeilen im allgemeinen Einstellungsformular.
- Die Kachel schreibt `PRUEFUNG_MAIL_TEXT` und `PRUEFUNG_GEBUEHR_PDF_DRIVE` erst beim bewussten Speichern. Dadurch ist keine Laufzeitschema-Migration beim Login erforderlich. Der bekannte Exklusivbearbeitungs-Timeout aus dem ersten Versuch bleibt damit beseitigt.
- TEST-spezifische Werte im E-Mail-Bereich bleiben durch die vorhandene Schutzlogik bei `Spielwiese aktualisieren` erhalten.

PROD-Empfängerlogik für die persönliche Prüfungs-E-Mail:
- Empfängerpriorität: eigene E-Mail-Adresse → Kontakt 1 → Kontakt 2.
- Ist keine Adresse vorhanden, wird keine E-Mail versendet. Der Prüfer erhält stattdessen eine vollständige Nachrichtenvorschau mit Kopierfunktion, um den Text beispielsweise per WhatsApp zu versenden. Die Gebühren-PDF muss bei einem manuellen WhatsApp-Versand zusätzlich mitgesendet werden.
- Kann eine vorhandene Adresse nicht versendet werden oder die PDF nicht geladen werden, wird der betroffene Fall ebenfalls als manueller Fallback mit kopierbarer Nachricht ausgegeben. Die bereits gespeicherte Prüfung wird dadurch nicht zurückgerollt.
- Der produktive persönliche Versand wird nur bei einer neu angelegten Prüfung ausgelöst, nicht bei einer späteren Bearbeitung desselben Vorgangs. Die bestehende interne Prüfungsbenachrichtigung an die konfigurierten Verantwortlichen bleibt davon getrennt erhalten.
- PROD-Code und PROD-Oberfläche enthalten diese Logik ab diesem Projektstand. Ein erster realer PROD-Prüfungs-Mailversand ist noch nicht praktisch bestätigt. Vor dem ersten Echtversand muss in PROD unter Kommunikation → Prüfungen die Gebühren-PDF hinterlegt beziehungsweise bestätigt und die Kachel einmal gespeichert werden.

Fehlerhistorie 23./24.08.2026:
- Die erste Ergänzung der PDF-Einstellung erhöhte die Runtime-Schema-Version und versuchte dadurch eine globale Schema-Migration im Loginpfad. Bei gebundener Exklusivbearbeitung lief der Login nach 25 Sekunden in einen Timeout.
- Korrektur 24.08.2026 06:13: Login, Sammelzugang-Abschluss und Sitzungswiederaufnahme lösen dafür keine Runtime-Schema-Migration mehr aus. Die PDF-Einstellung wurde nur beim bewussten Admin-Speichern angelegt. Diese Architektur wird mit der neuen gebündelten Prüfungs-Kachel beibehalten.

Noch offen für Prüfungen:
- Zusätzlich zu internen Prüfern soll später die Option `Externer Prüfer` mit Freitextname angeboten werden. Hintergrund: Prüfungen ab dem 1. Kyu werden häufig außerhalb des Vereins abgelegt. Dieser Punkt ist fachlich vorgemerkt, aber in diesem Projektstand bewusst noch nicht umgesetzt.

19. ANZUGVERWALTUNG

Datenbereiche:
- Bestand
- Leihvorgänge
- Leihpositionen
- Rückgaben

Pro Kleidungsstück:
- Typ
- Größe
- Zustand
- Bestandsstatus
- optionale individuelle Nummer
- Anschaffungsdaten

Leihvorgänge können mehrere Positionen enthalten.
Ausgabe- und Rückgabezustände werden getrennt dokumentiert.
Kaution und Rückzahlung werden am Vorgang geführt.
Offene Leihen werden nach aktuell 180 Tagen auffällig markiert.

20. ABRECHNUNG UND EHRENAMT

Vergütungssätze aktueller PROD-Stand:
- Trainer: 10 EUR je TE
- Übungsleiter: 8 EUR je TE
- Trainer-Assistent: 4 EUR je TE

Ehrenamtszeiträume werden personenbezogen in der Personalkartei unter `Abrechnung & Ehrenamt` gepflegt.

Trainer-Abrechnung:
- Filter Alle
- Vergütung
- Ehrenamt / Spende

Der Filter bezieht sich auf Euro-Beträge, nicht auf Stunden oder TE.

Quartalsabrechnung:
- Kassierer und Ansprechpartner werden über Personen-IDs aus geeigneten aktiven persönlichen Zugängen gewählt
- automatischer Start nach konfigurierbarer Zahl NRW-Werktage nach Quartalsende
- aktueller Standard: 6 Werktage
- aktuelle Uhrzeit: 10:00
- Bestätigungs- und Historienstatus werden getrennt gespeichert
- Kassenübersicht, Einzelabrechnung und Historie vorhanden
- Druck/PDF besitzt Seitenumbrüche nach Zusammenfassung und je Trainer sowie Abschlussinformation `gedruckt am/von`

Bestätigter und technisch korrigierter Fehler 23.08.2026:
- Sheets kann den Datentyp Uhrzeit als Date-Wert liefern
- Uhrzeitwerte werden deshalb zentral nach HH:mm normalisiert
- Einstellungen-Cache wurde hierfür versioniert
- praktische Wiederholungsprüfung mit `10:00` erfolgreich abgeschlossen

21. AUSWERTUNGEN UND STATISTIK

Auswertungen sind berechtigungsabhängig und überwiegend bedarfsgesteuert.
Sammelzugang ist von persönlichen/administrativen Statistiken ausgeschlossen.

Bereiche:
- Teilnehmerstatistik
- Verbandsmeldung / ÜL-Stunden
- Trainerabrechnung
- Erfolgreichster Wettkämpfer
- Wettkampfstatistik
- Altersklassenauswertung
- Prüfungscontrolling
- Ligabetrieb

Statistikmodul bleibt grundsätzlich Desktop-first.
Kompakte mobile Statistikansichten sind nicht automatisch Bestandteil des aktuellen Produkts und benötigen neue fachliche Freigabe.

Wertungspunkte aktueller PROD-Stand ab 2026:
- Platz 1: 8
- Platz 2: 5
- Platz 3: 3
- Platz 4 bis Platz 7: 1
- ohne Platzierung: 1

22. ALTERSKLASSEN UND GEWICHTSKLASSEN

Altersklassenregeln aktueller PROD-Stand 2026–2029:
- U11: 7–10 Jahre
- U13: 11–12 Jahre
- U15: 13–14 Jahre
- U18: 15–17 Jahre
- Frauen: ab 18, weiblich
- Männer: ab 18, männlich

Gewichtsklassen werden aus der versionierten Tabelle `Gewichtsklassenregeln` gelesen.
Der aktuelle PROD-Snapshot enthält 223 belegte Zeilen einschließlich Kopfzeile und damit den umfangreichen aktuellen Regelbestand.

Cache-/Bestandsregel:
- offizielle Gewichtsklassen müssen kanonisch verglichen werden
- alte Cachewerte dürfen reguläre GK nicht zu `Individuelle GK` machen
- Änderungen an den Regeln invalidieren die relevanten Caches

23. LIGA-ANBINDUNG

Die Haupt-Judo-App besitzt Tabellen für den Import aus der separat geführten Liga-App:
- Liga-Verbindungen
- Liga-Mannschaft
- Liga-Kampftage
- Liga-Personentage
- Liga-Gegnereinsätze

Die separate Liga-App ist ein eigenes Teilprojekt und nicht Bestandteil dieser ZIP.
Die Haupt-App übernimmt saisonbezogene Liga-Daten über definierte Verbindung und API-Token.

Zurückgestellt in der Haupt-App:
- Ausbau der Liga-Statistik in der Personalkartei
- fachliche Auswertung von Abmeldestatus/Abmeldegründen im Ligamannschaft-Training
- weitere mobile Ligastatistik nur nach neuer Freigabe

24. SYSTEMEINSTELLUNGEN UND ADMINSTRUKTUR

Admin-Hauptbereiche:
- Systemeinstellungen
- Trainingsarchiv
- Trainingsgruppen
- Zugriffsverwaltung
- Linkverwaltung
- Vorlagen
- Trainingsfreie Zeiten & Kalender

Systemeinstellungen enthalten nur globale Regeln und Automationsparameter, keine fachlichen Arbeitsmodule, die bereits eigene Einstiege besitzen.

Globale Einstellung `PERSON_INAKTIV_AUTOMATIK_TAGE`:
- Bereich `Automatik`
- Bezeichnung `Inaktivitätsprüfung nach Tagen`
- Datentyp Ganzzahl, Pflegeart Admin
- Mindestwert 1
- Bedeutung: reine Kalendertage seit maßgeblichem Bezugsdatum. Ferien, Feiertage und trainingsfreie Zeiten werden nicht abgezogen.
- PROD bleibt bis zur Freigabe der neuen Systematik auf dem praktisch bestätigten bisherigen Wert 63.
- TEST setzt im Rahmen der neuen Personenmigration den Zielwert 94. Dieser Wert ist fachlich abgestimmt, aber noch praktisch im TEST zu prüfen.

Prüfungs-Kommunikation ab diesem Projektstand:
- Unter Systemeinstellungen → Kommunikation gibt es eine eigene Kachel `Prüfungen`.
- Dort werden gemeinsam gepflegt: `Wer soll bei Prüfungen benachrichtigt werden?`, der bearbeitbare persönliche Prüfungs-Mailtext `PRUEFUNG_MAIL_TEXT` und die Gebühren-PDF-Verknüpfung `PRUEFUNG_GEBUEHR_PDF_DRIVE`.
- Mailtext und PDF-Verknüpfung liegen im Bereich `E-Mail`. Dadurch bleiben TEST-spezifische Werte bei der PROD→TEST-Synchronisierung geschützt.
- Mailtext und PDF-Zeile werden nicht im Loginpfad migriert, sondern nur beim bewussten Speichern dieser Kachel angelegt oder aktualisiert.
- Die PDF-Verknüpfung akzeptiert Google-Drive-Link oder Datei-ID und prüft beim Speichern die erreichbare PDF-Datei.

Systemverwaltete Inaktivitätsausnahmen:
- PROD besitzt weiterhin den bisherigen Schlüssel `PERSON_INAKTIV_AUSNAHMEN`, solange die neue TEST-Systematik noch nicht produktiv freigegeben ist.
- In TEST ist diese Fachlogik verworfen und durch `Gelegentlich aktiv` plus die technische Sondergruppe `Selten da, aber immer wieder gern gesehen` ersetzt.
- Nach späterer PROD-Freigabe soll die alte individuelle Schutzcheckbox nicht parallel zum neuen Fachstatus fortbestehen.

Vorlagen:
- Wettkampf-Einladungsvorlagen
- Gewichtsklassen-Vorlagen

Regel-/Stammtabellen bleiben getrennt:
- Wettkampfarten
- Altersklassen
- Gewichtsklassen
- Wertungspunkte
- Vergütungssätze

Trainingsfreie Zeiten & Kalender bündelt:
- Trainingsausfälle
- Ferien/Feiertage/Kalenderausnahmen
- gruppenbezogene Trainingspausen
- NRW-Kalenderaktualisierung

Diese Kalender-/Pausendaten haben ausdrücklich keinen Einfluss auf die Inaktivitätsautomatik.

Historische Kompatibilitätszeilen wie `BACKUP_UHRZEIT` und `BACKUP_INTERVALL_TAGE` können im Sheet noch vorhanden sein. Die aktuelle Bedienlogik verwendet für Backups Wochentage, Wochenintervall, Startdatum und Empfänger. Solche alten Einstellungszeilen nicht ohne Codeprüfung löschen.

25. AUTOMATIKEN UND TRIGGER

Praktisch kontrollierter PROD-Triggerbestand am 23.08.2026:
- handleSheetEdit
- scheduledCalendarRefresh
- scheduledQuarterStart
- scheduledBillingHistoryCleanup
- scheduledNightlyTechnicalMaintenance
- scheduledWeeklyTriggerCheck

Der alte deaktivierte `manualYearArchiveWorker` wurde gelöscht.

Praktisch bestätigt am 24.08.2026:
- zentraler Nachtlauf 02:25: OK
- Archiv-Nachlauf / offene Archivjobs 02:24: OK
- PIN-Synchronisation PROD → TEST 02:24: OK
- Drive-/Jahresarchiv 02:25: OK, 1 Element
- Datenbereinigung 02:25: OK, Monatsbereinigung 2026-08 bereits erledigt
- Inaktivitätsautomatik 02:25: OK, 24 neue Vorgänge, 0 automatische Inaktivierungen
- Sheet-Backup 02:25: OK
- Triggerkontrolle 23.08.2026 20:34: OK
- Quartalsautomatik-Trigger: vorhanden
- `Systemstatus-E-Mail` darf im gerade versendeten Bericht selbst noch ohne letzten Protokollzeitpunkt erscheinen. Das ist systembedingt und kein Fehler.

Zentraler Nachtlauf:
- täglich im Apps-Script-Fenster 02:00–03:00, Zielzeit nahe 02:30
- bündelt technische Nachtaufgaben

Nachtlaufbereiche:
- offene Archivjobs
- PIN-Synchronisation PROD → TEST
- Drive-/Jahresarchiv
- Datenbereinigung
- Inaktivitätsautomatik
- Sheet-Backup
- Systemstatus-E-Mail

Weitere Trigger:
- wöchentliche Triggerkontrolle Sonntag nahe 03:00
- Kalenderaktualisierung jährlich
- Quartalsautomatik
- Bereinigung Abrechnungshistorie

Praxisstatus:
- Der erste reale PROD-Nachtlauf nach Bereitstellung der neuen Inaktivitätslogik wurde am 24.08.2026 kontrolliert und war fehlerfrei. Dieser Punkt ist erledigt.
- Die Quartalsautomatik-Triggerkonfiguration wurde im Systembericht als vorhanden bestätigt. Dieser Punkt ist erledigt.

26. SYSTEMBERICHT

PROD-Systembericht ist aktiviert.
Aktueller Betriebsversuch:
- persönlicher Admin-Empfänger im Sheet ausgewählt
- Startdatum 23.08.2026
- Wochenintervall 1
- für die erste Beobachtungsphase alle Wochentage aktiviert
- alle verfügbaren Inhaltsblöcke einschließlich Login-Historie aktiviert

Mögliche Inhalte:
- Triggerstatus
- Fehler
- Backup
- Archiv
- Bereinigung
- Inaktivitätsautomatik
- PIN-Sync
- Quartal
- Personen-/Prüfungs-/Wettkampfhinweise
- Exporte
- Triggerreparaturen
- Mailfehler
- Einstellungen
- Zugänge
- Aktiv/Inaktiv
- Gruppen
- Trainings
- Wettkämpfe
- Login-Historie

TEST kann den Bericht simulieren, ohne E-Mail und ohne produktive Statusänderung.

27. BACKUP, ARCHIV UND BEREINIGUNG

Aktuelle PROD-Konfiguration:
- automatisches Sheet-Backup: Montag, alle 1 Woche
- Startdatum: 23.08.2026
- fachlich entspricht dies der gewünschten Nacht Sonntag → Montag im zentralen Nachtlauf

Archiv:
- Drive-Hauptordner: `Judo App Archiv`
- Initialarchivierung wurde am 15.08.2026 als erledigt dokumentiert
- Wochenarchive und Jahresdaten werden getrennt behandelt

Aufbewahrung im aktuellen PROD-Sheet:
- Training/Wettkampf: 26 Monate
- abgeschlossene Anzugvorgänge: 36 Monate
- Abrechnungsdaten: 24 Monate

Datenbereinigung darf nicht vor erfolgreicher Archivabsicherung laufen.
Fehlerzustände können die automatische Bereinigung sperren.

Manueller Jahresarchiv-Export:
- Auswahl Vorjahr und/oder laufendes Jahr
- Ausgabe als XLSX
- Dateiname `YYYY_Judo App Archiv.xlsx`
- Grunddaten enthalten für berücksichtigte Personen den vollständigen Personenstamm, nicht nur ausgewählte Felder

28. PRODUKTIVE EINSTELLUNGEN – WICHTIGE FACHWERTE

Aktuelle Werte aus dem hochgeladenen PROD-Snapshot:
- Training überfällig nach: 14 Tage
- Mitgliedsstatus prüfen nach: 42 Tage
- Prüfung offen nach: 42 Tage
- erledigte Hinweise sichtbar: 90 Tage
- Anzugleihe auffällig nach: 180 Tage
- Training-Loginhinweis vor Beginn: 10 Minuten
- Training-Loginhinweis nach Ende: 20 Minuten
- Quartalsautomatik: 6 NRW-Werktage nach Quartalsende
- Quartalsautomatik Uhrzeit: 10:00
- Inaktivitätsautomatik: neuer Standard 63 Kalendertage, Admin-pflegbar. Diese neue Zeile ist im eingefrorenen PROD-Snapshot noch nicht enthalten und wird nach Bereitstellung durch die Laufzeitschema-Prüfung ergänzt.
- Archiv Sportdaten: 26 Monate
- Archiv Anzug: 36 Monate
- Archiv Abrechnung: 24 Monate

Personenbezogene Empfänger, E-Mail-Adressen, Kontodaten, PINs, API-Token und konkrete Verbindungs-URLs werden nicht zusätzlich in dieser Textakte wiederholt. Sie liegen im vertraulichen PROD-Snapshot beziehungsweise in der produktiven Google-Umgebung.

29. DATENINTEGRITÄT UND PARALLELITÄT

Grundregeln:
- stabile IDs statt Namen als Schlüssel
- Namen sind Anzeigeinformationen
- historische Zustände in Verlaufstabellen
- serverseitige Validierung trotz Clientvalidierung
- Dokumentensperren bei konkurrierenden Schreibvorgängen
- Dublettenschutz im letzten Speicherschritt
- direkte Sheet-Änderungen werden über `handleSheetEdit` validiert
- technische Lesespalten werden automatisch gepflegt
- ungültige direkte Sheet-Eingaben werden zurückgesetzt beziehungsweise gelöscht
- Adminrolle darf nicht entkräftet werden
- wichtige X-Felder erlauben nur X oder leer
- Datumsbereiche dürfen nicht rückwärts laufen
- Kampfergebnisse benötigen passende Teilnahme und lückenlose Kampfnummern

Änderungsprotokoll:
- synchroner Bestandteil wichtiger Schreibvorgänge
- bewusst nicht als asynchrone Komfortfunktion umgesetzt, weil Protokolle bei Abbruch verloren gehen könnten
- Feld-für-Feld-Vollchangelog ist nicht Ziel des Systems

30. PERFORMANCE-ARCHITEKTUR

Allgemeiner Standard aus den Messreihen 21.–22.08.2026:
- keine unnötigen Warmups
- keine schweren Hintergrundaufrufe direkt nach Login
- Daten bedarfsgesteuert laden
- kleine Kontext-RPCs statt komplette Editor-Neuladung
- keine Vollbestände lesen, wenn gezielte ID-/Datumsläufe reichen
- clientseitige Daten nach einmaligem Laden lokal filtern, wenn fachlich sicher
- Caches versionieren und gezielt invalidieren
- nach Speichern keine unnötigen Folge-RPCs
- Performanceentscheidungen anhand realer Messungen, nicht nach Gefühl allein

Akzeptierte Praxis:
- Training läuft subjektiv sehr schnell
- Wettkampf ist nach Optimierungen deutlich besser, Restmessung der zweiten Editorstufe wurde vertagt
- Personalkartei bleibt langsamer als Training, wird aber aktuell akzeptiert
- Start-Weißbild von wenigen Sekunden wurde im Smartphone-Test akzeptiert, solange anschließend korrekter Inhalt erscheint

31. MOBILE UND DESKTOP-GRENZEN

Smartphone-first:
- Start
- Training
- Wettkampf
- normale Prüfungsabläufe
- Anzugverwaltung
- Mehr/Admin soweit praktikabel

Bewusst desktoporientiert:
- großes Statistikmodul
- Personalkartei in komplexen Verwaltungsansichten
- Prüfungs-Controlling

Bekannte Restfeinheit:
- mobiles Datumsfeld bei `Trainingsausfälle` funktional korrekt, optisch später erneut bewerten

32. EINFÜHRUNG UND NUTZERINFORMATION

Abgeschlossen:
- Version 2.0 im Vorstand vorgestellt
- Vorstand hat die Einführung freigegeben
- Stefan kennt die App aus einer frühen Version, die aktuelle Version ist wesentlich weiterentwickelt

Noch offen:
- breitere Trainer-/Nutzergruppe informieren
- APP-RANDORI als Testmöglichkeit kommunizieren
- Nutzerinformation finalisieren
- Trainer-Kurzanleitung finalisieren/aktualisieren
- ggf. weitere rollenspezifische Kurzanleitungen später

Kommunikationsgrundsätze:
- keine technischen Rollenbegriffe als Hauptansprechpartner in nutzergerichteten Texten
- konkrete Personen als Ansprechpartner nennen
- Erstinformation darf erklären, dass bei der Datensichtung der letzten Wochen vermeidbare Fehleingaben und Unzulänglichkeiten der alten App aufgefallen sind
- PIN-E-Mail und Spam-Ordner erwähnen
- Link zur TEST-/APP-RANDORI-Umgebung und zur Kurzanleitung bereitstellen

33. VERWORFENE ODER BEWUSST NICHT WEITERVERFOLGTE LÖSUNGEN

- keine zusätzliche Training.html-Datei
- keine ungeprüfte Übernahme von Alt-App-Technik
- keine zweite vereinfachte TEST-Logik für die Inaktivitätsprüfung
- keine umgebungsunabhängige öffentliche Inaktivitätsprüfungs-Wrapperfunktion
- feste 56-Tage-Schwelle für die Inaktivitätsautomatik verworfen
- Abzug von Ferien, Feiertagen und trainingsfreien Zeiten bei der Inaktivitätsprüfung verworfen
- keine direkte Trainer-Inaktivierung über `Trainiert nicht mehr im SSV`
- keine E-Mail-Auslösung durch bloßes Öffnen eines sensiblen Links
- keine separate Backup-Uhrzeit neben dem gebündelten Nachtlauf
- keine duplizierten Admin-Funktionen in Systemeinstellungen und Fachmodulen
- keine Vorlagen als globale Systemeinstellungen
- keine Ehrenamtszeiträume als globale Systemeinstellung
- keine Auswertungen/Prüfungen zusätzlich doppelt unter `Mehr`
- keine weitere Personalkartei-Performancejagd ohne konkretes Praxisproblem
- keine Millisekundenoptimierung des sicheren Trainingsspeicherns ohne messbares Praxisproblem
- keine automatische Übernahme eines früheren Waagegewichts als aktuelles Wettkampfgewicht
- keine Nachzeichnung des Vereinslogos
- keine NIIMBOT-Direktansteuerung aus der Haupt-App
- keine bloße Zusage oder manuelle Sorgfaltsregel mehr als Absicherung gegen falsche Dateinamen. Dieser Ansatz ist nach wiederholtem Auftreten des Fehlers verworfen und durch einen technischen Handoff ersetzt.

34. AKTUELLE PRIO-LISTE – LIVE-CHECKLISTE UND DOKUMENTATIONSSPIEGEL

Operative Live-Datei:
- `SSV-Meschede Judo App – Checkliste`
- Drive: `Judo App → SSV-Meschede Judo App – Checkliste`
- Google-Sheet-ID: `1llcvhUpzWvtw2hBHgDDItlc97ABR1vUeEIorOHX2jgc`
- Tabellenblätter: `START`, `Aktuell`, `Erledigt`
- Projektstand-Snapshot: `Checkliste/SSV-Meschede_Judo_App_Checkliste.xlsx`

Verbindliche Arbeitsweise:
- Das native Google Sheet ist die alltägliche, dauerhaft verlinkte Aufgabenoberfläche.
- `START` zeigt die wichtigsten offenen Aufgaben automatisch und enthält sechs Eingabezeilen für `Schnelle Idee`.
- `Aktuell` enthält die vollständige Liste. Die Spalte `Erledigt` ist als Checkbox bedienbar.
- `Erledigt` sammelt abgeschlossene Aufgaben.
- Vor jeder Planung, Frage, Umsetzung und Projektstand-Erzeugung muss zusätzlich zum Projektaktenstand die Live-Checkliste gelesen werden.
- Nutzeränderungen in der Live-Checkliste sind für Aufgabenstatus und Schnellideen maßgeblich, sofern keine neuere ausdrückliche Chat-Anweisung widerspricht.
- Nichtleere Schnellideen werden beim nächsten Arbeitslauf fachlich eingeordnet. Keine Schnellidee löst automatisch eine Umsetzung aus.
- Abgehakte Aufgaben werden beim nächsten konsolidierten Projektstand in `Erledigt` überführt und hier im Dokumentationsspiegel nachgezogen.
- Die folgende Liste bleibt als vollständiger fachlicher Dokumentationsspiegel in der Projektakte erhalten. Die tägliche Bedienung erfolgt nicht mehr hier, sondern im Live-Sheet.

PRIO 1 – TEST-Freigabe der neuen Personen-/Gast-/Inaktivitäts-Systematik:
[x] P1.1 TEST-Schema real öffnen/initialisieren und `Archiv_Personen`, Sammelspalten sowie Gruppe `Selten da, aber immer wieder gern gesehen` prüfen.
[x] P1.2 Personalkartei praktisch prüfen: Standardansicht, `Inaktive anzeigen`, `Externe anzeigen`, Status-Chips und vereinbarte Farben.
[ ] P1.3 94-Tage-Vorgang praktisch prüfen: `Aktiv lassen`, `Gelegentlich aktiv`, `Jetzt inaktiv setzen` und automatische Archivierung nach 7 Tagen.
[x] P1.4 Einen echten TEST-Inaktivitätslink prüfen. Kein Link darf auf eine Google-Drive-Fehlerseite führen.
[ ] P1.5 Externe praktisch prüfen: Sammelerfassung mit Anzahl, optionale namentliche Erfassung, 8-Wochen-Löschung und Anonymisierung.
[x] P1.6 `Mitgliedschaft offen` praktisch geprüft: 8 Wochen, Warnung, 7 Tage, neue Teilnahme, Mitgliedschaftsbestätigung, Löschung/Anonymisierung und sichtbare Trennung von `Externe Gäste` und `Schnupperteilnahmen`.
[x] P1.7 Archivbereinigung kontrolliert geprüft. Archivierte Person mit weiterer personenbezogener Historie bleibt erhalten und ist bei `Inaktive anzeigen` aufrufbar.
[ ] P1.8 Wettkampf-Platzierungsleiste mobil und Desktop nach Rückkehr zu Einzelplätzen 1–7 erneut prüfen, inklusive Speichern und Wiederöffnen.
[ ] P1.9 `Als externe Person einstufen` technisch umgesetzt und praktisch weitgehend geprüft. Korrektur der historischen Trainingsanzeige auf `Externe Gäste` ist enthalten, praktische Wiederholungsprüfung bleibt offen.

PRIO 2 – Personalkartei Bedienlogik, hohe Priorität:
[ ] P2.1 Feld `Aktuelle Gruppen` ist in TEST direkt klickbar. Mehrfachauswahl enthält auch inaktive Trainingsgruppen. Praktische Prüfung offen.
[ ] P2.2 Automatische Inaktivsetzung ohne aktuelle Gruppe ist in TEST umgesetzt. Ausnahmen: Trainer, ÜL, Assistent, Vorstand, Admin und fachlich notwendigerweise Externe. Praktische Prüfung offen.
[ ] P2.3 Gürtel/Aktuelle Graduierung öffnet in TEST direkt die Prüfungshistorie. Separate Kachel `Prüfungshistorie` entfernt. Praktische Prüfung offen.
[ ] P2.4 `Trainerqualifikation` ist in TEST direkt klickbar und führt zur Bearbeitung/Verlaufssicht. Praktische Prüfung offen.
[ ] P2.5 `Prüfberechtigung` ist in TEST direkt klickbar und führt zur Bearbeitung/Verlaufssicht. Praktische Prüfung offen.
[ ] P2.6 `Rechterolle im System` ist in TEST direkt klickbar. Admin kann bearbeiten, sonst lesende Detailansicht. Praktische Prüfung offen.
[ ] P2.7 `Telefon`, `E-Mail`, `Kontakt 1` und `Kontakt 2` sind in TEST direkt klickbar und öffnen die jeweilige Kontaktdatenbearbeitung. Praktische Prüfung offen.

PRIO 3 – PROD/TEST-Transparenz und Projektstand:
[ ] P3.1 Konzept festlegen, wie auf den ersten Blick sichtbar wird, wenn PROD- und TEST-Projektstände voneinander abweichen. Optische Lösung ausdrücklich erst im nächsten Chat klären, jetzt noch nicht vorfestlegen.
[ ] P3.2 Nach festgelegtem Konzept die Unsynchronitätsanzeige technisch und dokumentarisch umsetzen.

PRIO 4 – bestehende Produktivkontrollen / Prüfungen:
[x] P4.1 Kein aktiver Prüfpunkt mehr. Gebühren-PDF und Mailtext ausschließlich anlassbezogen bei der nächsten realen Prüfung kontrollieren.
[x] P4.2 Kein aktiver Prüfpunkt mehr. Produktiven Versand ausschließlich beim nächsten realen PROD-Prüfungsvorgang kontrollieren.
[ ] P4.3 Beim Feld Prüfer `Externer Prüfer` mit Freitextname konzipieren und nach ausdrücklicher Freigabe umsetzen.
[ ] P4.4 Bei Wettkampfvorbereitung vor dem E-Mail-Versand deutlich anzeigen, welche vorgesehenen Teilnehmer keine E-Mail erhalten, weil keine E-Mail-Adresse hinterlegt ist. Betroffene Teilnehmernamen müssen für die bearbeitende Person eindeutig sichtbar sein.

PRIO 5 – Einführung und spätere Feinheiten:
[ ] P5.1 Nutzer-/Trainerinformation finalisieren und verteilen.
[ ] P5.2 Trainer-Kurzanleitung auf den endgültigen Version-2.0-Stand bringen.
[ ] P5.3 Datumsfeld `Trainingsausfälle` mobil optisch neu bewerten.
[ ] P5.4 Ligamannschaft-Abmeldestatus und Abmeldegründe nur nach neuer fachlicher Freigabe ausbauen.
[ ] P5.5 Liga-Statistik in der Personalkartei nur nach neuer fachlicher Freigabe konzipieren.
[ ] P5.6 Kompakte mobile Statistikansichten nur nach neuer fachlicher Freigabe entwickeln.

ERLEDIGT / BESTÄTIGTER DATENSTAND:
[x] Kontaktdatenmigration in PROD für 34 Personen technisch abgeschlossen und zurückgelesen.
[x] Aktueller Liga-Projektstand `2026 08 25 06 24_SSV-Meschede_Judo_Liga_App.zip` im Drive archiviert und unter `Aktueller Projektstand/Liga` aufgebaut.

Datenpflege-Hinweis:
- Bei Moritz Kaiser ist der frühere Schreibfehler `Muitter` korrigiert. Aktueller Live-Wert: `Mutter ( Judith)`; das zusätzliche Leerzeichen bleibt als kleine Datenpflegeauffälligkeit.
- Für sechs relevante Mitglieder ist weiterhin keine E-Mail-Adresse bekannt. Dies ist ein bekannter Datenstand und kein technischer Fehler.

ERLEDIGT / NEUE PROJEKTORGANISATION 25.08.2026:
[x] Separate native Live-Checkliste mit den Blättern `START`, `Aktuell` und `Erledigt` eingerichtet.
[x] Smartphonefreundliche `Schnelle Idee`-Eingabe auf `START` eingerichtet.
[x] XLSX-Snapshot der Live-Checkliste als fester Bestandteil jedes Judo-Projektstands festgelegt.
[x] Versionierte XLSX-Snapshots der vier Live-Sheets als dauerhafte Projektstand-Regel eingerichtet.

35. NICHT MEHR OFFEN – HÄUFIGE ALT-PUNKTE

Folgende frühere Punkte sind erledigt und dürfen nicht erneut als offene Aufgaben behandelt werden:
- globaler Zurück-Button
- Vereinslogo-Wasserzeichen
- Safe-Area
- mobile Kopfzeile
- Wettkampf-Tabulatorfehler
- Prüfungs-Suchkontrast und Trefferabstand
- Prüfungs-Speicherladeanzeige
- Prüfungs-Direktlink-Rückmeldung
- Prüfungsstatus-Aktualisierung
- Quartalsdruck mit Seitenumbrüchen/Footer
- abgeschnittene E-Mail-Optionen in der Personalkartei
- zweizeilige Funktionsnamen in der Quartalsabrechnung
- Personensuche nach Vorname/Rufname
- einheitliche Kachelgrößen in Verwaltungsmenüs
- Wasserzeichen mit originalem PNG statt nachgezeichneter Variante
- PROD-Triggerkonsolidierung
- Systembericht-Konfiguration
- Backup-Wochenplanung
- TEST-Admin-Button für die Inaktivitätsprüfung technisch umgesetzt
- manueller TEST-Inaktivitätslauf nach Umstellung auf 63 reine Kalendertage praktisch erneut ausgeführt und vom Nutzer zunächst akzeptiert
- Quartals-Uhrzeit `10:00` praktisch gespeichert und nach erneutem Öffnen korrekt bestätigt
- erster realer PROD-Nachtlauf am 24.08.2026 mit Status OK bestätigt
- reale PROD-Inaktivitätsautomatik im Nachtlauf mit Status OK bestätigt
- Archiv-Nachlauf, PIN-Synchronisation, Drive-/Jahresarchiv, Datenbereinigung und Sheet-Backup im ersten kontrollierten Nachtlauf mit Status OK bestätigt
- Quartalsautomatik-Trigger im Systembericht als vorhanden bestätigt
- fehlender eigener Protokollzeitpunkt der gerade versendeten Systemstatus-E-Mail als logisch und nicht fehlerhaft eingeordnet
- Login-/Sitzungswiederaufnahmefehler durch unnötige Runtime-Schema-Migration für die Prüfungs-PDF am 24.08.2026 beseitigt
- TEST-Prüfungs-E-Mail mit frei eingegebener Testadresse und PDF-Anhang praktisch erfolgreich bestätigt
- Prüfungs-Kommunikation in eigener Kachel gebündelt: interne Benachrichtigungsempfänger, bearbeitbarer persönlicher Mailtext und Gebühren-PDF
- persönliche Prüfungs-E-Mail technisch nach PROD übernommen, einschließlich Empfängerpriorität eigene E-Mail → Kontakt 1 → Kontakt 2 und manueller Fallback ohne Adresse
- frühere Schutzoption gegen die automatische Inaktivitätsprüfung im bisherigen PROD technisch umgesetzt. Für die neue TEST-Systematik fachlich durch `Gelegentlich aktiv` ersetzt
- Kontaktdaten aus der manuell geprüften Konsolidierungsdatei und den ausdrücklich nachgetragenen Chat-Korrekturen am 24.08.2026 in PROD migriert
- 34 Personen im Blatt `Personen` ausschließlich in den Kontaktspalten J:Q aktualisiert und anschließend direkt aus PROD zurückgelesen
- Jonas Kaiser mit Christian Kaiser als Kontakt 1 ergänzt, Moritz Kaiser mit eigener E-Mail und Christian Kaiser als Kontakt 1 ergänzt, Jasper Riepe anhand der vorhandenen bekannten Familiendaten korrigiert

36. ÜBERGABE AN EINE ANDERE PERSON / NEUEN CHAT

Für den Start eines neuen Chats dient die neueste vollständig geprüfte Projekt-ZIP als unveränderlicher Rücksprung- und Übergabestand. Die operative Weiterentwicklung erfolgt anschließend direkt im Drive-Ordner `Aktueller Projektstand/Judo App`.

Startreihenfolge:
1. hochgeladene ZIP strukturell prüfen und 00_START_HIER.txt vollständig lesen
2. Masterprompt.txt vollständig lesen
3. Projektakte.txt vollständig lesen
4. `Aktueller Projektstand/Judo App` in Google Drive als operative Arbeitsgrundlage öffnen
5. nur die für die aktuelle Aufgabe relevanten Laufzeitdateien und Abhängigkeiten analysieren
6. PROD-Snapshot nur gezielt und datenschutzbewusst öffnen

Die alten Migrationsdateien und alten DOCX-Dokumentationen sind für die laufende Entwicklung nicht erforderlich.
Sie bleiben in älteren ZIP-Ständen als historische Rücksprungquelle erhalten.

Ein kompletter Wiederaufbau in einem fremden Google-Konto ist von einer normalen Entwicklungsübergabe zu unterscheiden. Dafür müssten zusätzlich die Google-seitigen Berechtigungen, Web-App-Bereitstellung und Autorisierungen neu eingerichtet werden. Zugangsdaten oder Geheimnisse gehören nicht in die Projektakte.

37. DATEINAMEN- UND HANDOFF-REGEL

Projekt-ZIP exakt:
YYYY MM DD HH mm_SSV-Meschede_Judo_App_Projektstand.zip

- Europe/Berlin
- echte Leerzeichen
- kein Prozentzeichen
- keine `%20`-Dublette
- Zeitstempel unmittelbar vor Erstellung
- Erzeugung und Prüfung ausschließlich über `Projektstand_erstellen_und_pruefen.py` oder gleichwertige technische Prüfung
- nach Endprüfung nicht umbenennen
- Nach dem Fehler im Stand 23.08.2026 23:47 muss der Handoff zusätzlich technisch bestätigen, dass der Ausgabeordner exakt eine freizugebende Projekt-ZIP enthält und keine URL-kodierte `%20`-Dublette existiert. Der Chat-Link verwendet den realen Dateipfad mit echten Leerzeichen und wird nicht manuell URL-kodiert.
- Am 24.08.2026 trat derselbe Fehler bei der ausgegebenen Kontaktdaten-XLSX erneut auf. Frühere Zusagen, der Fehler sei durch reine Verhaltensregeln künftig ausgeschlossen, haben sich damit als unzureichend erwiesen.
- Deshalb gilt die technische Sperre ab jetzt für jede ausgegebene Datei, nicht nur Projekt-ZIPs. Jede Einzeldatei muss in einem leeren Handoff-Ordner liegen und mit `Projektstand_erstellen_und_pruefen.py --handoff-file <Pfad>` oder gleichwertig geprüft werden.
- Der allgemeine Datei-Handoff muss mindestens prüfen: exakt eine Datei im Handoff-Ordner, Datei nicht leer, realer Basename ohne Prozentzeichen, keine `%20`-Dublette. Erst danach dürfen `DATEI_PRUEFUNG_BESTANDEN`, `HANDOFF_BEREIT` und `CHAT_LINK_RAW` ausgegeben werden.
- Für den sichtbaren Download wird `CHAT_LINK_RAW` bytegenau übernommen. Der Link wird nicht mehr manuell konstruiert oder URL-kodiert.
- Neue dauerhafte Regel ab 25.08.2026: Projekt-ZIPs werden nach vollständiger technischer Prüfung standardmäßig ausschließlich unter `Judo App → Projektstände → Judo App` in Google Drive archiviert und nicht mehr im Chat ausgegeben.
- Im Drive-Archiv werden maximal 10 Judo-Projekt-ZIPs behalten.
- Zwischen zwei Abschluss-Projektständen wird `Aktueller Projektstand/Judo App` direkt und dateiselektiv weiterentwickelt. Nicht betroffene Dateien bleiben unangetastet.
- Nach erfolgreicher Abschlussprüfung werden Drive-Arbeitsstand und neue ZIP vollständig gegeneinander geprüft. Nur bei festgestellter Abweichung wird `Aktueller Projektstand/Judo App` aus der ZIP neu aufgebaut.
- Der benachbarte Bereich `Liga` darf dabei weder gelöscht, verändert noch verschoben werden.
- Eine Projekt-ZIP wird nur auf ausdrücklichen Wunsch zusätzlich im Chat ausgegeben. Dann bleibt der technisch gesperrte Handoff verpflichtend.


37A. GOOGLE-DRIVE-ARCHIV FÜR PROJEKTSTÄNDE

Verbindlicher Basisordner:
`Judo App` → `Projektstände`

Verbindliche Struktur:
- `Projektstände` → `Judo App`: rollierendes Archiv der Judo-App-Projekt-ZIPs
- `Projektstände` → `Liga`: rollierendes Archiv der Liga-App-Projekt-ZIPs
- `Projektstände` → `Aktueller Projektstand` → `Judo App`: operativer Arbeitsstand auf Basis der neuesten freigegebenen Judo-App-ZIP plus seitdem ausdrücklich freigegebene Änderungen
- `Projektstände` → `Aktueller Projektstand` → `Liga`: operativer Arbeitsstand des separaten Liga-Teilprojekts

Regel:
- Jede neu freigegebene Projekt-ZIP wird zuerst lokal nach den Regeln des jeweiligen Teilprojekts vollständig technisch geprüft.
- Nur ein bestandener Projektstand wird unverändert in den passenden Drive-Archivzweig hochgeladen.
- Der Drive-Dateiname entspricht exakt dem geprüften ZIP-Basename. Vorhandene Projektstände werden nicht überschrieben.
- Nach dem Upload wird der jeweilige Archivzweig erneut gelesen und der neue Dateiname bestätigt.
- Je Teilprojekt werden höchstens zehn Projekt-ZIPs behalten. Wenn nach bestätigtem Upload mehr als zehn passende ZIPs im betroffenen Zweig vorhanden sind, wird nur die älteste überzählige ZIP dieses Zweigs gelöscht.
- Andere Dateien, der jeweils andere Teilprojektzweig und die entpackten Arbeitsstände werden von dieser Rotation nicht verändert.
- Die Rotation erfolgt ausschließlich im Zusammenhang mit einer neuen Projektstand-Ausgabe. Es gibt keinen unabhängigen Hintergrundlauf.
- Google Drive ist ab 24.08.2026 das verbindliche Standardziel für Projektstand-Ausgaben. Nach vollständig bestandener technischer Prüfung wird die neue Projekt-ZIP standardmäßig nur im passenden Drive-Archivzweig abgelegt. Eine zusätzliche ZIP-Ausgabe im Chat erfolgt nur noch auf ausdrücklichen Nutzerwunsch.
- Die vollständige lokale ZIP-Erzeugung, technische Prüfung und erneute Öffnung bleibt für jeden ausdrücklich angeforderten Abschluss-/Übergabestand Pflicht. Sie entfällt dagegen während normaler einzelner Bearbeitungsschritte.
- `Aktueller Projektstand/Judo App` ist zwischen zwei Abschluss-ZIPs die operative Arbeitsgrundlage. Pro Aufgabe werden nur betroffene Dateien und notwendige Abhängigkeiten gelesen, geändert und geprüft.
- Nicht betroffene Dateien bleiben unverändert und werden nicht vorsorglich neu erzeugt oder ersetzt. Damit soll insbesondere das wiederholte Verarbeiten großer `Code.gs`, `Index.html`, Snapshots und Referenzdateien vermieden werden.
- Beim Abschluss wird die neue Judo-ZIP aus dem aktuellen Drive-Arbeitsstand erzeugt. Nach der vollständigen Prüfung wird die Übereinstimmung mit dem Drive-Arbeitsstand kontrolliert. Ein kompletter Neuaufbau von `Aktueller Projektstand/Judo App` erfolgt nur bei Abweichungen.
- Der Liga-Arbeitsstand bleibt davon vollständig getrennt und unverändert.
- Die ZIP bleibt unveränderlicher Rücksprung- und Prüfnachweis. Der Drive-Ordner ist bewusst veränderlicher Arbeitsstand.

Praktisch eingerichtet am 24.08.2026:
- vorhandener Hauptordner `Judo App` bestätigt
- gemeinsamer Unterordner `Projektstände` eingerichtet
- getrennte Archivzweige `Judo App` und `Liga` eingerichtet
- vorhandene Judo-App-Archivstände in den Zweig `Projektstände/Judo App` verschoben
- gemeinsamer Arbeitsordner `Aktueller Projektstand` mit Teilprojektordnern `Judo App` und `Liga` wird geführt
- die aktuelle Liga-ZIP ist in diesem Arbeitslauf nicht als Datei verfügbar. Deshalb wird kein Liga-Stand erfunden oder aus älteren Demo-/Referenzdateien rekonstruiert. Sobald die aktuelle Liga-Projekt-ZIP verfügbar ist, wird sie nach derselben Systematik archiviert und entpackt

Neue verbindliche Ausgabeentscheidung vom 24.08.2026:
- Drive ersetzt die bisherige standardmäßige Chat-ZIP-Ausgabe.
- Der Chat erhält nach einem normalen Projektstand nur eine kurze Bestätigung über Änderungen, unveränderte Bereiche, Drive-Ablage und erfolgreiche Prüfung.
- Ein Downloadlink oder eine ZIP-Datei im Chat wird nur erzeugt, wenn der Nutzer dies ausdrücklich verlangt.
- Diese Regel gilt gleichermaßen für Judo-App und Liga-App.
- Zusätzliche verbindliche Chat-Rückmeldung nach jedem erfolgreich gespeicherten Projektstand: exakter ZIP-Dateiname, Dateien innerhalb der ZIP mit neuem Stand und grobe Auflistung der Neuerungen.

38. AKTUELLER PROD-SHEET-KATALOG UND SCHEMA

Die nachfolgende Liste wurde direkt aus dem am 24.08.2026 nach der Kontaktdatenmigration frisch exportierten PROD-XLSX ausgelesen. Bereichsangaben zeigen den aktuell verwendeten Zellbereich dieses Snapshots.

- Personen (A1:AC125): Personen-ID | Nachname | Vorname | Rufname | Geschlecht | Geburtsjahr | Erstes Training manuell | Vereinsbezug | Mitgliedschaft bestätigt | Eigene Telefonnummer | Eigene E-Mail-Adresse | Kontakt 1 Name | Kontakt 1 Telefonnummer | Kontakt 1 E-Mail-Adresse | Kontakt 2 Name | Kontakt 2 Telefonnummer | Kontakt 2 E-Mail-Adresse | Bevorzugte Wettkampf-E-Mail-Quelle | Höchste Einsatzrolle | Lizenz vorhanden | Prüfungsberechtigt | Graduierungsübersicht ausgenommen | Kontoinhaber | IBAN | Datensatz gesperrt | Angelegt am | Angelegt von | Zuletzt geändert am | Zuletzt geändert von
- Liga-Verbindungen (A1:K3): Liga-Verbindungs-ID | Saison | Verbindung | Bezeichnung | Web-App-URL | API-Token | Aktiv | Mannschaft | Liga | Zuletzt importiert am | Letzter Importstatus
- Liga-Mannschaft (A1:F16): Liga-Mitglied-ID | Liga-Verbindungs-ID | Saison | Personen-ID | Vorgesehene Gewichtsklasse | Nicht einsetzbar
- Liga-Kampftage (A1:H5): Liga-Kampftag-ID | Liga-Verbindungs-ID | Saison | Kampftag-ID | Nummer | Datum | Ort | Gegneranzahl
- Liga-Personentage (A1:J61): Liga-Personentag-ID | Liga-Verbindungs-ID | Saison | Kampftag-ID | Personen-ID | Status | Kämpfe | Siege | Niederlagen | Unterbewertung
- Liga-Gegnereinsätze (A1:K121): Liga-Gegnereinsatz-ID | Liga-Verbindungs-ID | Saison | Kampftag-ID | Personen-ID | Begegnung | Gegnerverein | Kämpfe | Siege | Niederlagen | Unterbewertung
- Zugänge (A1:J21): Zugangs-ID | Zugangsart | Personen-ID | Person | Bezeichnung | PIN | Rechte-Rollen-ID | Status | Letzter Login | Sitzungsversion
- Einstellungen (A1:G65): Einstellungs-Schlüssel | Bereich | Bezeichnung | Wert | Datentyp | Pflegeart | Erläuterung
- Änderungsprotokoll (A1:H322): Protokoll-ID | Zeitpunkt | Quelle | Zugangs-ID | Datensatzart | Datensatzschlüssel | Aktion | Kurzdetails
- Wettkampfarten (A1:D4): Wettkampfart-ID | Bezeichnung | Aktiv | Sortierreihenfolge
- Wettkampf-Einladungsvorlagen (A1:D1): Einladungsvorlage-ID | Name | Einleitung | Abschlusstext
- Wettkampf-GK-Vorlagen (A1:E1): Vorlage | Altersklasse | Geschlecht | Sortierreihenfolge | Gewichtsklasse
- Quartalsabrechnungen (A1:Q1): Quartals-ID | Jahr | Quartal | Von-Datum | Bis-Datum | Status | Gestartet am | Gestartet von | Automatisch | Letzte Verarbeitung am | Kassenmail gesendet am | Kassenmail Fehler | Kassenmail Vorschau | Abgeschlossen am | Abgeschlossen von | Abschlussmail gesendet am | Testsimulation
- Quartalsabrechnungsstatus (A1:P1): Status-ID | Quartals-ID | Personen-ID | Auszahlung | Spende | App-Zugang-Status | E-Mail-Adresse | E-Mail-Status | E-Mail gesendet am | E-Mail-Fehler | E-Mail-Vorschau | Bestätigungsstatus | Bestätigt am | Bestätigungsart | Bestätigt durch Personen-ID | Bemerkung
- Abrechnungshistorie (A1:V1): Historien-ID | Quartals-ID | Jahr | Quartal | Von-Datum | Bis-Datum | Personen-ID | Name | Auszahlung | Spende | Positionen-JSON | E-Mail-Status | E-Mail gesendet am | E-Mail-Fehler | Bestätigungsstatus | Bestätigt am | Bestätigungsart | Bestätigt durch | Bemerkung | Abgeschlossen am | Abgeschlossen von | Manueller Abschluss
- Vergütungssätze (A1:E4): Vergütungssatz-ID | Satzart | Betrag je Übungseinheit | Gültig ab | Gültig bis
- Linkverwaltung (A1:M25): Link-ID | Linkart | Thema | Bezug-ID | Personen-ID | Token | URL | Gültig ab | Gültig bis | Status | Erstellt am | Erstellt von | Verwendet am
- Wettkampfanmeldungen (A1:L1): Wettkampf-ID | Status | Rückmeldung schließt am | Daten-JSON | Ersteinladung gesendet am | Ausschreibung nachgesendet am | Aktualisierung gesendet am | Abschlussmail gesendet am | Angelegt am | Angelegt von | Zuletzt geändert am | Zuletzt geändert von
- Wettkampfwaagen (A1:C1): Wettkampf-ID | Personen-ID | Waagegewicht kg
- Trainingsgruppen (A1:O12): Gruppen-ID | Gruppenname | Status | Standard ÜL-Meldestunden | Grundsätzlich ehrenamtlich | Training ohne verantwortlichen Trainer erlaubt | Montag | Dienstag | Mittwoch | Donnerstag | Freitag | Samstag | Sonntag | Standardtage gültig ab | Sortierreihenfolge
- Trainings (A1:K228): Trainings-ID | Datum | Gruppen-ID | Trainingsgruppe | ÜL-Meldestunden | Gruppe grundsätzlich ehrenamtlich beim Speichern | Bemerkung | Angelegt am | Angelegt von | Zuletzt geändert am | Zuletzt geändert von
- Wettkämpfe (A1:J22): Wettkampf-ID | Datum | Wettkampfname | Austragungsort | Allgemeine Dauer Minuten | Bemerkung | Angelegt am | Angelegt von | Zuletzt geändert am | Zuletzt geändert von
- Wettkampfteilnahmen (A1:H163): Wettkampf-ID | Wettkampf | Personen-ID | Person | Altersklasse | Gewichtsklasse | Platzierung | Bemerkung
- Wettkampfergebnisse (A1:G467): Kampfergebnis-ID | Wettkampf-ID | Wettkampf | Personen-ID | Person | Kampfnummer | Ergebnis
- Rechte-Rollen (A1:AE5): Rechte-Rollen-ID | Rollenname | Aktiv | Fehlende Trainings anzeigen | Training erfassen | Training bearbeiten | ÜL-Meldestunden ändern | Trainingsausfall erfassen | Trainingsausfall verwalten | Person anlegen | Personenname korrigieren | Kontaktdaten anzeigen | Person reaktivieren | Gruppenzuordnung hinzufügen | Gruppenzuordnung beenden | Person inaktiv setzen | Wettkampf erfassen | Wettkampf bearbeiten | Wettkampfdauer ändern | Wettkampfkosten bearbeiten | Prüfung erfassen | Prüfung löschen | Teilnehmerstatistik ansehen | Teilnehmerstatistik exportieren | Verbandsmeldung ansehen | Verbandsmeldung exportieren | Quartalsabrechnung ansehen | Quartalsabrechnung exportieren | Wettkampfstatistik ansehen | Anzugverwaltung | Wettkampfstatistik exportieren
- Personenstatus (A1:F127): Status-ID | Personen-ID | Person | Status | Gültig ab | Gültig bis
- Datenbereinigungsprotokoll (A1:E1): Zeitpunkt | Datenbereich | Betroffener Zeitraum | Gelöschte Datensätze | Ergebnis
- Anzugbestand (A1:I1): Kleidungsstück-ID | Typ | Größe | Zustand | Bestandsstatus | Individuelle Nummer | Anschaffungsdatum | Anschaffungspreis | Bemerkung
- Anzugleihen (A1:H1): Leihvorgang-ID | Personen-ID | Ansprechpartner | Telefon | E-Mail | Kaution | Bemerkung | Status
- Anzugleihpositionen (A1:J1): Leihposition-ID | Leihvorgang-ID | Kleidungsstück-ID | Ausgabedatum | Ausgabezustand | Ausgabebemerkung | Rückgabedatum | Rückgabezustand | Rückgabebemerkung | Ausgemustert
- Anzugrückgaben (A1:F1): Rückgabe-ID | Leihvorgang-ID | Rückgabedatum | Leihpositionen | Kaution zurückgezahlt | Bemerkung
- Prüfungsvorgänge (A1:J1): Vorgangs-ID | Prüfungsdatum | Prüfer 1 Personen-ID | Prüfer 2 Personen-ID | Allgemeiner Kommentar | E-Mail versendet am | Angelegt am | Angelegt von | Zuletzt geändert am | Zuletzt geändert von
- Prüfungsfälle (A1:P1): Prüfungsfall-ID | Vorgangs-ID | Personen-ID | Neue Graduierung | Kommentar | Prüfungsgebühr bezahlt | Zahlung bestätigt am | Zahlung bestätigt von | In DokuMe übertragen | DokuMe bestätigt am | DokuMe bestätigt von | Historien-Prüfungs-ID | Angelegt am | Angelegt von | Zuletzt geändert am | Zuletzt geändert von
- Prüfungsfilterfavoriten (A1:I1): Favoriten-ID | Sichtbarkeit | Besitzer-Zugangs-ID | Name | Filter-JSON | Angelegt am | Angelegt von | Zuletzt geändert am | Zuletzt geändert von
- Hinweisstatus (A1:I10): Hinweisstatus-ID | Hinweisart | Quellschlüssel | Personen-ID | Gruppen-ID | Status | Erledigt am | Erledigt von | Details
- Prüfungen (A1:K184): Prüfungs-ID | Personen-ID | Person | Prüfungsart | Neue Graduierung | Prüfungsdatum | Prüfungscode | In DokuMe übertragen | DokuMe übertragen am | Erfasst am | Erfasst von
- Prüfungsberechtigungsverlauf (A1:G1): Prüfungsberechtigungsverlauf-ID | Personen-ID | Prüfungsberechtigt | Gültig ab | Gültig bis | Erfasst am | Erfasst von
- Archiv_Trainings (A1:L2): Trainings-ID | Datum | Gruppen-ID | ÜL-Meldestunden | Gruppe grundsätzlich ehrenamtlich beim Speichern | Bemerkung | Angelegt am | Angelegt von | Zuletzt geändert am | Zuletzt geändert von | Archiviert am | Archiviert von
- Archiv_Trainingsanwesenheiten (A1:G3): Trainings-ID | Personen-ID | Rolle | Einzeleinsatz ehrenamtlich | Im Training neu angelegt | Archiviert am | Archiviert von
- Einsatzrollenverlauf (A1:H4): Einsatzrollenverlauf-ID | Personen-ID | Person | Einsatzrolle | Gültig ab | Gültig bis | Erfasst am | Erfasst von
- Gruppenzuordnungen (A1:I187): Zuordnungs-ID | Personen-ID | Person | Gruppen-ID | Trainingsgruppe | Gültig ab | Gültig bis | Angelegt am | Angelegt von
- Trainingsanwesenheiten (A1:G2596): Trainings-ID | Training | Personen-ID | Person | Rolle | Einzeleinsatz ehrenamtlich | Im Training neu angelegt
- Trainingsausfälle (A1:F32): Ausfall-ID | Datum | Gruppen-ID | Trainingsgruppe | Grund | Erfasst am
- Wettkampfbetreuungen (A1:I39): Wettkampf-ID | Wettkampf |  | Personen-ID | Person | Individuelle Betreuungsdauer Minuten | Einzeleinsatz ehrenamtlich | Reisekosten und Spesen | Kostenbezeichnung
- Ehrenamtszeiträume (A1:F3): Ehrenamts-ID | Personen-ID | Person | Gültig ab | Gültig bis | Grund
- Altersklassenregeln (A1:I7): Altersklassenregel-ID | Gültig ab Jahr | Gültig bis Jahr | Mindestalter im Bezugsjahr | Höchstalter im Bezugsjahr | Altersklasse | Geschlecht | Aktiv | Sortierreihenfolge
- Gewichtsklassenregeln (A1:H223): Gewichtsklassenregel-ID | Gültig ab Jahr | Gültig bis Jahr | Altersklasse | Geschlecht | Gewichtsklasse | Aktiv | Sortierreihenfolge
- Wertungspunkte (A1:I2): Wertungs-ID | Gültig ab Jahr | Gültig bis Jahr | Punkte Platz 1 | Punkte Platz 2 | Punkte Platz 3 | Punkte Platz 4 bis Platz X | Höchste Platzierung für Sammelwertung | Punkte ohne Platzierung
- Kalenderausnahmen (A1:G71): Kalenderausnahme-ID | Von-Datum | Bis-Datum | Art | Bezeichnung | Herkunft | Quellschlüssel
- Trainingsfreie Zeiten (A1:F1): Trainingsfreie-Zeit-ID | Von-Datum | Bis-Datum | Gruppen-ID | Trainingsgruppe | Grund
- Abschlusszeiträume (A1:D2): Abschluss-ID | Von-Datum | Bis-Datum | Sperrgrund
40. DAUERHAFTE UMSETZUNGS-, DATEIERZEUGUNGS- UND ABSCHLUSSREGEL – 25.08.2026

- Eine neue Datei oder Projekt-ZIP wird nicht automatisch aus dem laufenden Gespräch erzeugt. Konzeptarbeit, Rückfragen, To-do-Ergänzungen oder sonstige Abstimmungen bleiben zunächst Gesprächsstand.
- Ist eine Nutzeranweisung mehrdeutig und könnte sowohl als Konzept-/Gesprächswunsch als auch als Umsetzungsauftrag verstanden werden, wird ausschließlich kurz gefragt: `Umsetzen?`
- Antwortet der Nutzer ausdrücklich mit `Umsetzen` oder gibt er bereits von sich aus einen ebenso unmissverständlichen Befehl wie `Erzeugen`, `Dateien erstellen` oder `Projektstand aktualisieren`, beginnt die Umsetzung sofort ohne weitere Bestätigungsfrage.
- Nach erfolgreicher Erzeugung, technischer Prüfung und Speicherung nennt die Abschlussmeldung den exakten ZIP-Dateinamen, alle Dateien innerhalb der ZIP mit neuem Stand, eine grobe Auflistung der Neuerungen und zusätzlich die benötigte Dauer vom Zeitpunkt der ausdrücklichen Nutzeranweisung bis zur fertigen Abschlussmeldung im Chat.
- Judo-Projekt-ZIPs werden weiterhin standardmäßig nur unter `Judo App → Projektstände → Judo App` archiviert. `Aktueller Projektstand/Judo App` wird zwischen Abschlussständen dateiselektiv weiterentwickelt und beim Abschluss gegen die neue ZIP geprüft. Ein vollständiger Neuaufbau erfolgt nur bei Abweichungen. `Liga` bleibt unberührt.
- Der Liga-Projektstand ist inzwischen vorhanden: `2026 08 25 06 24_SSV-Meschede_Judo_Liga_App.zip` wurde technisch geprüft, unter `Projektstände/Liga` archiviert und unter `Aktueller Projektstand/Liga` entpackt aufgebaut.
- Bei jedem ausdrücklich angeforderten Abschluss-/Übergabestand werden zusätzlich die vier aktuellen Live-Sheets als XLSX ohne Apps Script in einer versionierten `Sheet-Versionen`-Ablage des jeweiligen Teilprojekts gesichert. Je Live-Sheet werden höchstens die zehn neuesten Snapshots behalten. Die Snapshot-Historie bleibt vom dateiselektiven Arbeitsstand getrennt und wird beim Abschluss kontrolliert fortgeführt.


41. NEUER BEDIENWUNSCH PERSONALKARTEI – 25.08.2026

- Hohe Priorität, noch nicht umgesetzt.
- Die zentralen Informationsflächen der Personenkopfkarte sollen zugleich direkte Einstiegspunkte in die jeweilige Bearbeitung bzw. Historie werden.
- Gruppen: Klick auf `Aktuelle Gruppen` öffnet eine Auswahl aller Gruppen einschließlich inaktiver Gruppen. Keine Gruppenzuordnung bedeutet inaktiv, außer bei Trainer, ÜL, Assistent, Vorstand oder Admin.
- Graduierung: Klick auf Gürtel/Aktuelle Graduierung öffnet die Prüfungshistorie. Die separate Prüfungshistorien-Kachel soll entfallen.
- Trainerqualifikation, Prüfberechtigung, Rechterolle sowie die vier Kontaktfelder werden ebenfalls direkt klickbar.

42. OFFENER PUNKT PROD-/TEST-SYNCHRONITÄT – 25.08.2026

- Wenn PROD- und TEST-Projektstand voneinander abweichen, muss dies künftig auf den ersten Blick erkennbar sein.
- Die konkrete optische bzw. dokumentarische Darstellung ist bewusst noch nicht festgelegt und wird im nächsten Chat konzeptionell entschieden.
- Bis dahin keine eigenmächtige UI- oder Kennzeichnungsentscheidung treffen.

43. VERSIONIERTE SHEET-SNAPSHOTS – 25.08.2026

- Die vier Live-Sheets werden zusätzlich zu den Projekt-ZIPs als reine XLSX-Exporte ohne Apps Script versioniert gesichert: `PROD_Judo App 2.0`, `Spielwiese_Judo App 2.0`, `PROD_2026 Ligabetrieb`, `Spielwiese_2026 Ligabetrieb`.
- Die Ablage erfolgt im jeweiligen Teilprojekt unter `Aktueller Projektstand/.../Sheet-Versionen`.
- Dateinamen enthalten Datum und Uhrzeit Europe/Berlin sowie den Live-Sheet-Namen.
- Pro Live-Sheet werden maximal zehn Snapshots behalten. Erst nach erfolgreichem Upload eines neuen Snapshots wird die älteste überzählige Version desselben Live-Sheets gelöscht.
- Diese Snapshots enthalten keine Apps-Script-Dateien und ersetzen weder die Projekt-ZIP noch den darin enthaltenen verbindlichen Codebestand.

44. DATEISELEKTIVE DRIVE-ARBEITSWEISE – VERBINDLICHE ENTSCHEIDUNG 25.08.2026

Ausgangslage:
- Die bisherige Arbeitsweise erzeugte bei nahezu jedem freigegebenen Bearbeitungsschritt erneut einen vollständigen Projektstand. Dadurch wurden auch große, unveränderte Dateien wiederholt gelesen, verarbeitet, geprüft und neu in den Drive-Arbeitsstand übernommen.
- Die Projekt-ZIP selbst ist mit rund 8 MB nicht das Hauptproblem. Der größere Aufwand entsteht durch die wiederholte Vollverarbeitung des kompletten Projektstands.

Neue verbindliche Arbeitsweise:
- Der Nutzer lädt zum Start eines neuen Chats weiterhin die neueste vollständig geprüfte Judo-Projekt-ZIP hoch. Sie dient ausschließlich als sicherer Einstieg, Prüfnachweis und Rücksprungstand.
- Nach Abschluss der Chatstart-Prüfung wird direkt mit `Aktueller Projektstand/Judo App` in Google Drive weitergearbeitet.
- Für jeden Arbeitsauftrag werden nur die fachlich und technisch relevanten Dateien gelesen. Bei einer Änderung werden nur die tatsächlich betroffenen Dateien plus notwendige Dokumentation aktualisiert.
- Nicht betroffene Laufzeitdateien, Logos, Designreferenzen, XLSX-Snapshots und sonstige Projektbestandteile bleiben unangetastet und müssen während dieses Arbeitsschritts nicht erneut verarbeitet werden.
- Eine neue Gesamt-ZIP wird nicht nach jedem Bearbeitungsschritt erzeugt. Sie entsteht erst auf ausdrücklichen Auftrag zum Projektabschluss beziehungsweise für den nächsten Chat.
- Beim Abschluss wird aus dem aktuellen Drive-Arbeitsstand genau eine vollständige ZIP erzeugt, mit `Projektstand_erstellen_und_pruefen.py` vollständig geprüft, im Judo-Archiv abgelegt und als neuer unveränderlicher Rücksprungstand verwendet.
- Nach bestandener Prüfung werden ZIP und Drive-Arbeitsstand vollständig auf Übereinstimmung geprüft. Nur wenn sie voneinander abweichen, wird der Judo-Arbeitsordner aus der ZIP neu aufgebaut.
- `Aktueller Projektstand/Liga` bleibt von Judo-Arbeitsschritten vollständig unberührt.

Verworfen:
- Vollständige ZIP-Erzeugung und kompletter Neuaufbau des Judo-Arbeitsordners nach jedem einzelnen Bearbeitungsschritt.
- Vorsorgliches Einlesen oder Neuübertragen unveränderter Projektdateien ohne fachlichen oder technischen Bedarf.

Erwarteter Effekt:
- Weniger wiederholte Dateioperationen und Prüfungen im laufenden Chat.
- Schnellere Bearbeitung vor allem bei Aufgaben, die nur einen kleinen Teil von `Code.gs`, `Index.html` oder der Dokumentation betreffen.
- Die Sicherheit bleibt erhalten, weil jeder Chatwechsel weiterhin über einen vollständig geprüften Gesamtstand abgesichert wird.

39. HISTORISCHE GRENZE

Diese Akte ist absichtlich keine vollständige Chronik aller Entwicklungsversuche.
Historische Zwischenstände, Migrationsprüfungen, verworfene Reparaturansätze und ältere Messserien wurden nur übernommen, wenn daraus heute noch eine verbindliche Regel, eine bekannte Grenze oder ein offener Punkt folgt.

Für eine historische Rekonstruktion bleiben die früheren Projekt-ZIPs die Quelle.
Für jede neue Arbeit gilt ausschließlich der aktuelle konsolidierte Stand.

45. KONSERVATIVE CODE.GS-BEREINIGUNG PROD UND TEST – 25.08.2026

Verbindliche Sprachregel:
- Spricht der Nutzer ohne Umgebungszusatz von `der Code.gs` oder `der Index.html`, sind grundsätzlich die aktuellen Fassungen in PROD und TEST gemeint.
- Nur bei ausdrücklich genannter Umgebung oder fachlich eindeutig umgebungsspezifischem Auftrag darf einseitig gearbeitet werden.

Ausgeführte Bereinigung:
- PROD und TEST wurden getrennt gegen ihre jeweilige `Index.html` und `DateRangeDialog.html` auf Referenzen geprüft.
- Entfernt wurden ausschließlich private Hilfsfunktionen ohne jeden erkennbaren Verweis, die abgeschlossene alte Migrationsroutine `runPreparedProbeImport` mit ihrer ausschließlich dazugehörigen Helferkette, die dazugehörigen fest verdrahteten `MIGRATION_*`-Datenblöcke sowie die ungenutzte Konstante `TRAINER_ROLES`.
- Andere öffentliche, manuell startbare oder triggergeeignete Funktionen blieben trotz fehlender statischer Referenz bewusst erhalten.
- PROD `Code.gs`: 782.067 Byte → 750.136 Byte, 42 Funktionsdefinitionen entfernt. Davon 11 Funktionen der abgeschlossenen Migration und 31 private, unreferenzierte Hilfsfunktionen.
- TEST `Code.gs`: 1.268.848 Byte → 1.235.268 Byte, 44 Funktionsdefinitionen entfernt. Davon 11 Funktionen der abgeschlossenen Migration und 33 private, unreferenzierte Hilfsfunktionen.
- Das eingebettete TEST-Stadtbild bleibt zwingender Bestandteil. Der 490.080 Zeichen große eingebettete Bilddatenblock ist vor und nach der Bereinigung byteidentisch. SHA-256: `e6b1724b3ec3bddd8ff9cf92b0767104ca875806b0d413bd20d68b32a5b307e4`.
- `Index.html` und `DateRangeDialog.html` wurden nicht verändert.

Prüfung:
- Beide bereinigten `Code.gs` bestehen die JavaScript-Syntaxprüfung.
- Kein entfernter Funktions- oder Konstantenname wird anschließend noch in der jeweiligen `Code.gs`, `Index.html` oder `DateRangeDialog.html` referenziert.
- Nach dem Schreiben in Google Drive wurden beide Dateien erneut heruntergeladen und per SHA-256 gegen die lokal geprüften Fassungen verglichen. Beide stimmen bytegenau überein.
- Eine echte Apps-Script-Laufzeit-/Deploymentprüfung wurde in diesem Arbeitsschritt nicht ausgeführt. Vor PROD-Einsatz neuer fachlicher Änderungen bleibt der übliche praktische TEST erforderlich.

Verworfen:
- Das TEST-Stadtbild als vermeintlichen Dateiballast zu entfernen.
- Sämtliche statisch unreferenzierten öffentlichen Funktionen pauschal zu löschen. Apps-Script-Trigger, manuelle Adminfunktionen und externe Aufrufe machen dies ohne Einzelfallnachweis zu riskant.

46. KONSERVATIVE INDEX.HTML-BEREINIGUNG PROD UND TEST – 25.08.2026

Ausgeführte Bereinigung:
- PROD und TEST wurden getrennt vollständig statisch auf tote Client-Bestandteile geprüft.
- Entfernt wurden in beiden Fassungen ausschließlich die fünf nirgends referenzierten Funktionen `chooseDate`, `durationPartsHtml_`, `openFirstTrainingOverrideDialog`, `parseDurationInput_` und `startTodayTrainingEditorPreload_`.
- Zusätzlich wurde die nirgends verwendete globale Konstante `INITIAL_MAINTENANCE` entfernt.
- Der ausschließlich zu `chooseDate` gehörende statische Datumsdialog `datePromptModal` wurde ebenfalls entfernt. Nach Entfernung der Funktion bestanden keinerlei externe Referenzen auf diesen Dialog mehr.
- Andere Funktionen, DOM-Bereiche, CSS-Regeln, Bibliotheken oder Datenblöcke blieben unangetastet, sobald eine Nutzung nicht zweifelsfrei ausgeschlossen werden konnte.
- PROD `Index.html`: 1.115.808 Byte → 1.111.346 Byte.
- TEST `Index.html`: 1.572.667 Byte → 1.568.205 Byte.
- Beide Dateiheader tragen danach `Stand: 25.08.2026 10:36`.

Schutz bestätigter Bildbestandteile:
- Das TEST-Stadtbild bleibt zwingend erhalten.
- Sämtliche eingebetteten Bilddaten sind vor und nach der Bereinigung byteidentisch.
- TEST-Stadtbild, eingebetteter Base64-Payload: SHA-256 `4069b37ad2febee6276e7b9b9a1a8576fff6b990e90bc7a039d2afb61d0b22ac`.
- Auch das eingebettete Vereinslogo blieb unverändert.

Prüfung:
- Beide Scriptblöcke beider Fassungen bestehen nach Auflösung der jeweiligen TEST-/PROD-Templatezweige die JavaScript-Syntaxprüfung.
- Kein entfernter Funktions-, Konstanten- oder Dialogname verbleibt in der jeweiligen Datei.
- Der konservative Referenzcheck findet danach keine weitere Funktionsdeklaration oder globale Variablendeklaration, die nur aus ihrer eigenen Deklaration besteht.
- Beide Dateien wurden nach dem Schreiben in Google Drive erneut heruntergeladen und per SHA-256 gegen die lokal geprüften Fassungen verglichen.
- PROD Drive-Rücklesung ist bytegenau identisch, SHA-256 `bff98beaf2d3e06fe0fe34536f353f8fd97f0e6b1c585fc175bdd7996a5a53d3`.
- TEST Drive-Rücklesung ist bytegenau identisch, SHA-256 `0ea8c01bbfdb601bfb323874fe8992236a9dac4027e983a6c650587a74628f51`.
- Eine echte Browser-/Web-App-Laufzeitprüfung wurde in diesem Arbeitsschritt nicht ausgeführt.

Nicht verändert:
- `Code.gs` blieb gegenüber der unmittelbar vorherigen konservativen Bereinigung unverändert.
- `DateRangeDialog.html` blieb unverändert.
- Keine ZIP wurde erzeugt.



47. ABSCHLUSSBEFEHL UND TEILPROJEKT-ROUTING – 25.08.2026

Verbindlich entschieden:
- `Projektstand aktualisieren` ist ab sofort der eindeutige Befehl für einen vollständigen Judo-Abschlusslauf: Drive-Arbeitsstand konsolidieren, Dokumentation aktualisieren, Judo-Live-Sheet-Snapshots erzeugen, vollständige ZIP technisch erstellen und erneut prüfen, im Judo-Archiv ablegen, 10er-Rotation durchführen und Drive-Arbeitsstand gegen die ZIP abgleichen.
- `Umsetzen` bleibt der Befehl für den normalen dateiselektiven Arbeitslauf. Eine Gesamt-ZIP wird dadurch nicht automatisch erzeugt.
- Neue Chats gelten ohne andere Angabe standardmäßig der Judo-App.
- Beginnt ein neuer Chat mit `Liga-App`, wird ausschließlich im Teilprojekt `Aktueller Projektstand/Liga` gearbeitet. Judo bleibt unangetastet.
- Judo und Liga werden nur bei ausdrücklichem Wunsch gemeinsam bearbeitet.

Abschlussstand dieses Laufs:
- PROD und TEST `Code.gs` wurden konservativ von eindeutig toten Bestandteilen bereinigt. TEST-Stadtbild blieb unverändert.
- PROD und TEST `Index.html` wurden konservativ von eindeutig toten Bestandteilen bereinigt. UI und bestätigte Bildbestandteile blieben unverändert.
- Die dateiselektive Drive-Arbeitsweise ist damit praktisch erprobt.
- Für diesen Projektabschluss werden frische Judo-Sheet- und Checklisten-Snapshots erzeugt. Liga wird nicht verändert.
- `Projektstand_erstellen_und_pruefen.py` wurde an die bestätigte Bereinigung angepasst: der veraltete Pflichtmarker `personFileIndexStatusMeta_` wurde entfernt, weil genau diese tote Funktion zuvor nachweislich gelöscht wurde.

48. PROJEKTSTAND AKTUALISIERT – 25.08.2026

Abschluss dieses Laufs:
- Nutzerbefehl `Projektstand aktualisieren` wurde als vollständiger Judo-Abschlusslauf ausgeführt.
- Abschluss-ZIP: `2026 08 25 11 04_SSV-Meschede_Judo_App_Projektstand.zip`.
- Enthalten sind die konservativ bereinigten PROD-/TEST-Fassungen von `Code.gs` und `Index.html`, die unveränderten `DateRangeDialog.html`, alle Designreferenzen und Logoquellen, die aktuelle Dokumentation, das Prüfskript sowie frische Judo-Snapshots.
- PROD-Live-Sheet und Live-Checkliste wurden unmittelbar vor der ZIP-Erzeugung frisch als XLSX exportiert.
- Spielwiese-Judo wurde zusätzlich frisch als versionierter XLSX-Snapshot für `Sheet-Versionen` exportiert.
- Die Liga-App und ihre Dateien wurden in diesem Lauf nicht verändert.
- Der fertige ZIP-Inhalt wird nach Erzeugung in ein leeres Prüfverzeichnis entpackt und ausschließlich aus dieser erneut geöffneten Fassung geprüft.

49. VERBINDLICHE ABARBEITUNG PRAKTISCHER PRÜFAUFGABEN – 25.08.2026

Verbindlich entschieden:
- Vor jeder praktischen Prüfaufgabe wird zuerst das Prüfziel kurz und eindeutig genannt.
- Danach werden die geplanten Schritte und das erwartete Ergebnis sehr kurz erläutert.
- Erst anschließend teilt der Nutzer mit, ab welchem Punkt Unterstützung benötigt wird. Vorher erfolgt keine Schritt-für-Schritt-Anleitung.
- Technische Vorprüfungen durch den Assistenten müssen ausdrücklich als solche benannt werden und ersetzen keinen praktischen Nutzertest.
- Die angeleitete Prüfung darf nicht ohne fachlich nachgewiesenen Zusammenhang in einen anderen Funktionsbereich wechseln.
- Zusätzlich gilt verbindlich der gestufte Schnellmodus: Zuerst Aufgabe anhand von Gespräch und dokumentiertem Stand einordnen. Für Prüfziel, groben Ablauf und Sollzustand werden keine Dateien erneut geöffnet, wenn nichts unklar ist.
- Technische Prüfung erfolgt erst dort, wo sie für den nächsten konkreten Schritt erforderlich ist, und dann nur in der unmittelbar relevanten Datei, Funktion oder im konkreten Sheet-Bereich. Tiefe Codeanalyse nur bei Fehlern, Änderungen oder echter fachlicher Unsicherheit.
- Die vollständige Projekt-ZIP bleibt Chatstart-/Rücksprungstand und wird nicht für kleine Arbeitsschritte erneut verarbeitet.

Anlass:
- Bei P1.1 wurde zunächst nur ein technischer Teilstand des TEST-Sheets geprüft und anschließend irrtümlich ein fachlich unpassender Wettkampf-Schritt angeleitet. Dieses Vorgehen ist verworfen.

50. P1.1 – TEST-PERSONENSYSTEM: SCHEMAKORREKTUR SAMMELSPALTEN – 25.08.2026

Praktische Prüfung:
- `Archiv_Personen` wurde im TEST-Sheet praktisch geöffnet und als vorhanden bestätigt.
- Die technische Gruppe `Selten da, aber immer wieder gern gesehen` wurde im Blatt `Trainingsgruppen` praktisch als vorhanden bestätigt. Ihr Status `inaktiv` ist fachlich ausdrücklich gewünscht, weil sie nur als technische Zuordnungsgruppe dient und nicht in der normalen Trainingsauswahl erscheinen soll.
- Im Blatt `Trainings` fehlten dagegen die vorgesehenen Sammelspalten `Externe Gäste` und `Schnupperteilnahmen`. P1.1 war damit zunächst nicht bestanden.

Ursache:
- `REQUIRED_HEADERS` enthielt beide Sammelspalten bereits, die laufende Initialisierung ergänzte fehlende Kernspalten im vorhandenen Blatt `Trainings` jedoch nicht.
- `Archiv_Trainings` besaß beide Sammelspalten bereits korrekt.

Umgesetzt in TEST:
- Das Live-TEST-Sheet `Spielwiese_Judo App 2.0` wurde direkt korrigiert. Hinter `Gruppe grundsätzlich ehrenamtlich beim Speichern` wurden die beiden Spalten `Externe Gäste` und `Schnupperteilnahmen` eingefügt. Bestehende Trainingsdaten wurden dabei nur nach rechts verschoben und inhaltlich nicht verändert.
- Der TEST-Arbeitsstand `Code.gs` wurde ergänzt um eine idempotente Schemaabsicherung für diese beiden Spalten. Sie wird über `ensureProjectExtensionSchemas_()` sowohl beim Sheet-Öffnen als auch im Runtime-Schemaweg erreicht.
- `RUNTIME_SCHEMA_VERSION` wurde auf `2026-08-25-01` angehoben, damit die neue Absicherung nicht an einer bereits gesetzten Runtime-Schemaversion vorbeiläuft.
- TEST-`Code.gs` trägt danach den Arbeitsstand `25.08.2026 14:27`.
- PROD wurde ausdrücklich nicht verändert. Die gesamte neue Personenlogik bleibt bis zur vollständigen praktischen TEST-Freigabe TEST-only.

Technische Prüfung:
- TEST-`Code.gs` besteht nach der Änderung die JavaScript-Syntaxprüfung.
- Nach dem Schreiben in Google Drive wurde die Datei erneut heruntergeladen. SHA-256: `5f246b002edb8f969d85e17e0de8fe1c97727aa8734b5c4086e3d6638dc8a6b3`.
- Das TEST-Sheet wurde nach der direkten Strukturänderung erneut gelesen. Die physische Reihenfolge lautet jetzt: `Trainings-ID`, `Datum`, `Gruppen-ID`, `Trainingsgruppe`, `ÜL-Meldestunden`, `Gruppe grundsätzlich ehrenamtlich beim Speichern`, `Externe Gäste`, `Schnupperteilnahmen`, `Bemerkung`, `Angelegt am`, `Angelegt von`, `Zuletzt geändert am`, `Zuletzt geändert von`.
- Stichproben der bestehenden Trainingszeilen zeigen unveränderte IDs, Daten, Gruppen, ÜL-Meldestunden und Migrations-Metadaten an den nun nach rechts verschobenen Positionen.

Status P1.1:
- Technische Korrektur durchgeführt.
- Praktische Nachprüfung im geöffneten TEST-Sheet durchgeführt. Der Nutzer bestätigt die beiden neuen Sammelspalten sowie die gewünschte technische Gruppe.
- P1.1 ist praktisch bestanden und erledigt.

50. VERBINDLICHE ARBEITSZWILLINGE IM AKTUELLEN PROJEKTSTAND – 25.08.2026

Entscheidung:
Im Ordner `Aktueller Projektstand` werden für Judo App und Liga-App zusätzlich zu den echten Projektdateien Text-Arbeitszwillinge geführt. Ziel ist die einfache lokale Öffnung per Doppelklick und die eindeutige manuelle Übernahme in Google Apps Script.

Judo App TEST:
- `01_Test_Code.gs.txt`
- `02_Test_Index.html.txt`
- `03_Test_DateRangeDialog.html.txt`

Judo App PROD:
- `01_Prod_Code.gs.txt`
- `02_Prod_Index.html.txt`
- `03_Prod_DateRangeDialog.html.txt`

Für die Liga-App gilt dieselbe Namenssystematik analog für TEST und PROD. Die echten Projektdateien `Code.gs`, `Index.html` und `DateRangeDialog.html` bleiben parallel bestehen und werden nicht umbenannt. Jeder Arbeitszwilling muss inhaltlich exakt der zugehörigen echten Projektdatei entsprechen und bei jeder Änderung im selben Arbeitsschritt aktualisiert werden. Projekt-ZIPs enthalten weiterhin die technisch korrekten echten Projektdateien.

Status: verbindlich festgelegt.

51. PRAKTISCHE TESTPRÜFUNG P1.2 BIS P1.4 – 25.08.2026

P1.2 Personalkartei:
- Standardansicht und die Filter `Inaktive anzeigen` und `Externe anzeigen` wurden praktisch geprüft.
- Inaktive Personen werden bei aktiviertem Filter klar hellrot mit Status `Inaktiv` angezeigt.
- Personen in der 7-Tage-Entscheidungsfrist werden deutlich abweichend als `Inaktiv in 7 Tagen` dargestellt.
- `Mitgliedschaft offen` ist eigenständig erkennbar.
- Die praktische Detailprüfung tatsächlich externer Personen bleibt bewusst Bestandteil von P1.5.
- P1.2 ist praktisch bestanden und erledigt.

P1.3 94-Tage-Inaktivitätsvorgang:
- Der manuelle TEST-Lauf `Inaktivitätsprüfung jetzt ausführen` wurde erneut praktisch gestartet. Der Lauf dauerte ungefähr 30 Sekunden. Diese Laufzeit wurde vom Nutzer ausdrücklich als vollkommen in Ordnung akzeptiert.
- Der Lauf erzeugte echte Entscheidungslinks mit 7-Tage-Frist.
- `Gelegentlich aktiv` wurde mit Jakob Mecaj, Personen-ID `P00035`, praktisch geprüft. Danach erschien die Personalkartei klar violett mit Status `Gelegentlich aktiv`. Teiltest bestanden.
- `Aktiv lassen` wurde mit Jan Krick, Personen-ID `P00036`, praktisch geprüft. Danach erschien Jan wieder als normal aktive Person ohne rote Fristmarkierung. Teiltest bestanden.
- `Jetzt inaktiv setzen` wurde mit Jonas Hamann, Personen-ID `P00048`, praktisch geprüft. Der Datensatz wurde aus `Personen` entfernt und nach `Archiv_Personen` verschoben. Nach einem Neuladen der App erschien Jonas bei aktiviertem `Inaktive anzeigen` korrekt als inaktiv. Dieses Aktualisierungsverhalten wurde vom Nutzer akzeptiert. Teiltest bestanden.
- Noch offen ist ausschließlich die kontrollierte praktische Bestätigung der automatischen Archivierung nach Ablauf der 7-Tage-Frist. P1.3 bleibt deshalb `In Arbeit`.

P1.4 echter TEST-Inaktivitätslink:
- Ein vom aktuellen TEST-Lauf erzeugter echter Inaktivitätslink wurde praktisch geöffnet.
- Die Seite zeigte korrekt die drei Entscheidungen `Aktiv lassen`, `Gelegentlich aktiv` und `Jetzt inaktiv setzen` einschließlich Entscheidungsfrist.
- Es trat keine Google-Drive-Fehlerseite auf.
- P1.4 ist praktisch bestanden und erledigt.

52. NEUE FACHLICHE ENTSCHEIDUNG – VERSEHENTLICH INTERN ANGELEGTE EXTERNE PERSON – 25.08.2026

Ausgangslage:
- In seltenen Fällen kann ein Trainer eine tatsächlich externe Person versehentlich als interne Person anlegen.
- Diese Person würde nach 94 Tagen ohne Training in der Inaktivitätsprüfung erscheinen.
- Für diesen seltenen Fall, nach Einschätzung des Nutzers etwa 2 bis 5 Personen pro Jahr, soll eine saubere Datenhygiene ohne aufwendige rückwirkende Umschreibung historischer Trainings möglich sein.

Verbindlich fachlich entschieden, noch nicht umgesetzt:
- Die Inaktivitätsentscheidung erhält zusätzlich die Auswahl `Als externe Person einstufen`.
- Frühere Trainingsanwesenheiten werden nicht rückwirkend umgebaut.
- Die technische Personen-ID bleibt als anonymer historischer Schlüssel erhalten.
- Name, Rufname, Geburtsdaten, Kontaktdaten und alle sonstigen personenbezogenen Stammdaten dieser Person werden aus dem dauerhaften Personenbestand entfernt.
- Die technische ID wird ab der Umstellung fachlich nur noch als `Externer Gast` interpretiert.
- Historische Auswertungen zeigen für diese ID ausschließlich `Externer Gast`. Der frühere Name wird nicht dauerhaft mitgeführt.
- Die Person erscheint danach nicht mehr als interne Person in der Personalkartei.
- Taucht sie später erneut im Training auf, wird sie wie ein externer Gast behandelt.
- Die Lösung soll vorhandene historische Trainingszeilen unangetastet lassen und dadurch Fehlerquellen sowie unnötige Massenänderungen vermeiden.
- Vor der technischen Umsetzung müssen alle weiteren personenbezogenen Referenzen dieser Personen-ID geprüft werden. Eine vorhandene Prüfungs-, Wettkampf-, Abrechnungs- oder sonstige Historie darf nicht blind zerstört werden.
- Die versehentliche Formulierung `94 Wochen` im Gespräch war ein Versprecher. Maßgeblich bleiben 94 Kalendertage.

Checkliste:
- Dafür wurde der neue Hochprioritäts-Punkt P1.9 `Als externe Person einstufen` angelegt.
- Umsetzung erst nach ausdrücklicher Freigabe.

53. CHECKLISTEN- UND ARBEITSSTAND ZUM ABSCHLUSS – 25.08.2026

- Die native Live-Checkliste wurde konsolidiert.
- P1.1, P1.2 und P1.4 sind als erledigt markiert und zusätzlich in `Erledigt` dokumentiert.
- P1.3 steht auf `In Arbeit`. Die drei manuellen Entscheidungswege sind bestanden, die automatische Archivierung nach 7 Tagen bleibt offen.
- P1.9 wurde als neuer hoher Punkt für die fachlich beschlossene externe Umstufung ergänzt.
- Die verbindlichen Arbeitszwillinge für Judo TEST und PROD wurden beim Abschluss tatsächlich im Drive-Arbeitsordner angelegt und bytegleich aus den jeweiligen echten Projektdateien erzeugt.
- `Masterprompt.txt` bleibt inhaltlich unverändert, da in diesem Lauf keine neue dauerhafte Arbeitsregel beschlossen wurde.
- PROD-Laufzeitcode bleibt unverändert. TEST-Laufzeitcode enthält weiterhin ausschließlich die bereits dokumentierte P1.1-Schemaabsicherung.

54. PROJEKTSTAND VOLLSTÄNDIG AKTUALISIERT – 25.08.2026

- Nutzerauftrag `Projektstand vollständig aktualisieren` wurde als vollständiger Judo-Abschlusslauf ausgeführt.
- Abschluss-ZIP: `2026 08 25 16 02_SSV-Meschede_Judo_App_Projektstand.zip`.
- Der ZIP-Inhalt basiert auf dem aktuellen Drive-Arbeitsstand.
- Frische XLSX-Snapshots von PROD, TEST und der Live-Checkliste wurden erzeugt. Im ZIP wird entsprechend der bestehenden Struktur der aktuelle PROD-Snapshot sowie der aktuelle Checklisten-Snapshot mitgeführt. Der TEST-Snapshot wird versioniert unter `Sheet-Versionen` im Drive-Arbeitsstand abgelegt.
- Liga wurde nicht verändert.
- Der technische Projektstand-Prüfer wurde an die aktuelle TEST-Runtime-Schema-Version `2026-08-25-01` angepasst. Die vorherige feste Prüferwartung `2026-08-24-02` war nach der bereits erfolgten TEST-Schemaänderung veraltet.
- Die ZIP wurde ausschließlich mit `Projektstand_erstellen_und_pruefen.py` erzeugt und anschließend aus einem neuen leeren Prüfverzeichnis erneut geprüft.
- Abschlussprüfung: `PRUEFUNG_BESTANDEN`.


55. P1.5 – EXTERNE: PRAKTISCHE PRÜFUNG, VALIDIERUNGSFEHLER UND UI-KORREKTUR – 25.08.2026

Praktische Prüfung:
- Die Sammelerfassung `Externe Gäste` mit Anzahl wurde im TEST praktisch geprüft. Speichern und Wiederöffnen funktionieren. Dieser Teil von P1.5 ist bestanden.
- Der Nutzer beanstandete ausschließlich die Position des Sammelfelds. Verbindlich entschieden: Die Sammelposition wird nur im Teilnehmer-Tab `Gäste` angezeigt und dort als oberste Listenzeile integriert. Die Datenlogik bleibt unverändert.
- Anschließend wurde die optionale namentliche Erfassung eines externen Gasts praktisch geprüft. Beim Speichern trat ein Datenvalidierungsfehler in `Personen!H128` auf. Die Zelle erlaubte nur `Mitglied`, `Mitgliedschaft offen` und `Gast`, während die neue TEST-Logik `Extern` schreibt.

Ursache:
- Der neue TEST-Code kennt `Extern` bereits als fachlichen Vereinsbezug. Die bestehende Google-Sheets-Datenvalidierung des Live-TEST-Sheets war jedoch noch auf dem älteren Wertebestand.
- Die Runtime-Schemamigration `2026-08-25-01` stellte die neue Vereinsbezug-Validierung nicht gezielt sicher. Dadurch konnte eine namentlich externe Person trotz korrekter Fachlogik nicht gespeichert werden.

Umgesetzt in TEST:
- Im Live-TEST-Sheet `Spielwiese_Judo App 2.0` wurde die Datenvalidierung der Spalte `Personen!H2:H999` gezielt auf `Mitglied`, `Mitgliedschaft offen`, `Gast`, `Extern` erweitert. `Gast` bleibt vorerst als Legacy-Wert zulässig, damit bestehende Altwerte nicht ungültig werden.
- TEST-`Code.gs` erhält eine idempotente Absicherung dieser Validierung und hebt `RUNTIME_SCHEMA_VERSION` auf `2026-08-25-02` an. Damit wird die Korrektur nach manueller Übernahme in Google Apps Script dauerhaft über den Runtime-Schemaweg abgesichert.
- Die allgemeine Google-Sheets-Validierungsdefinition für `Vereinsbezug` wurde ebenfalls auf die vier zulässigen Übergangswerte angeglichen.
- TEST-`Index.html` zeigt die Sammelposition `Externe Gäste` nur noch im Tab `Gäste` und dort als erste Listenzeile. Der Wert wird intern unabhängig vom aktuell sichtbaren Tab gehalten, damit Tabwechsel oder Speichern den Wert nicht verlieren.
- Neu namentlich angelegte Externe werden im aktuellen Trainingseditor unmittelbar als Gast behandelt und nicht fälschlich als Gruppenteilnehmer dargestellt.
- PROD bleibt unverändert.

Technische Prüfung:
- Die Live-Datenvalidierung wurde nach dem Schreiben direkt erneut gelesen. Sowohl `Personen!H2` als auch `Personen!H128` enthalten jetzt die vier Werte `Mitglied`, `Mitgliedschaft offen`, `Gast`, `Extern` bei strikter Validierung.
- TEST-`Code.gs` besteht die JavaScript-Syntaxprüfung.
- Die JavaScript-Blöcke des geänderten TEST-`Index.html` bestehen nach Entfernung der Google-Template-Tags für die reine Syntaxprüfung die Node-Syntaxprüfung.
- Die praktische Wiederholungsprüfung der namentlichen Externen-Erfassung in der Web-App bleibt offen, bis die geänderten TEST-Dateien manuell in Google Apps Script übernommen wurden.

Status P1.5:
- Sammelerfassung praktisch bestanden.
- Fehlerursache der namentlichen Erfassung technisch behoben.
- UI-Korrektur umgesetzt.
- P1.5 bleibt `In Arbeit`, bis namentliche Erfassung sowie spätere 8-Wochen-Löschung und Anonymisierung praktisch bestätigt sind.


56. P1.5 – EXTERNE: 8-WOCHEN-LÖSCHUNG PRAKTISCH GEPRÜFT, DOPPELLÖSCHUNG KORRIGIERT – 25.08.2026

Praktische Prüfung:
- `Willi Mensch 2` wurde als namentlicher externer Teilnehmer in einem TEST-Training vom 08.06.2026 angelegt und gespeichert.
- Beim manuellen Prüflauf erschien anschließend `Datensatz nicht gefunden`. Die App zeigte den externen Datensatz wegen des abgebrochenen Refreshs zunächst weiterhin an.
- Direkte Prüfung im Live-TEST-Sheet bestätigte jedoch: Der Personendatensatz war bereits vollständig gelöscht, die personenbezogene Trainingsanwesenheit entfernt und das Training vom 08.06.2026 korrekt auf `Externe Gäste = 1` anonymisiert. Die fachliche Lösch- und Anonymisierungslogik funktionierte damit.

Ursache:
- `deletePersonRecordFully_()` löschte `Personen` und `Archiv_Personen` bereits im allgemeinen Durchlauf über alle Blätter und versuchte anschließend beide Blätter nochmals explizit per `deleteByKey_()` zu löschen. Der zweite Löschversuch erzeugte `Datensatz nicht gefunden`.

Umgesetzt in TEST:
- `deletePersonRecordFully_()` überspringt `Personen` und `Archiv_Personen` im allgemeinen Durchlauf und entfernt die Stammdatensätze anschließend idempotent über `deleteRowsByExactKey_()`. Dadurch ist ein bereits fehlender Datensatz kein Fehler mehr.
- Nur TEST-`Code.gs` wurde geändert. `Index.html` und `DateRangeDialog.html` bleiben unverändert.
- Der Drive-Arbeitsstand `TEST/Code.gs` und der Arbeitszwilling `01_Test_Code.gs.txt` wurden aktualisiert.

Technische Prüfung:
- TEST-`Code.gs` besteht die JavaScript-Syntaxprüfung.
- Der erneut aus Google Drive geladene TEST-`Code.gs` ist bytegleich mit der geprüften lokalen Fassung. SHA-256: `1098a06cb078df64e4083511dd5a1a54003cd654dabf2ab821b171423884ac5c`.

Status P1.5:
- Sammelerfassung bestanden.
- Namentliche Erfassung bestanden.
- 8-Wochen-Löschung und Anonymisierung fachlich praktisch bestanden.
- Wiederholung des Prüflaufs nach Übernahme des korrigierten `Code.gs` ist noch erforderlich, um zu bestätigen, dass die Fehlermeldung und der veraltete UI-Zustand nicht mehr auftreten.

58. P1.6/P1.7/P1.9 – GESAMMELTE TEST-KORREKTUR NACH PRAKTISCHER PRÜFUNG – 25.08.2026

P1.7 Archiv-/Inaktiv-Anzeige:
- Rudin Hamo, Personen-ID `P00108`, wurde am 25.08.2026 im TEST manuell inaktiv gesetzt.
- Der Datensatz wurde fachlich korrekt aus `Personen` nach `Archiv_Personen` verschoben und erhielt im `Personenstatus` ab 25.08.2026 den Status `inaktiv`.
- Rudin besitzt weiterhin personenbezogene Historie außerhalb Training, insbesondere eine dokumentierte Prüfung. Damit ist er ein geeigneter Schutzfall für P1.7.
- Direkt nach der Archivierung meldete die geöffnete Personalkartei jedoch `Person nicht gefunden`. Auch bei aktivierter Checkbox `Inaktive anzeigen` war Rudin nicht auffindbar.
- Ursache: `allPersonRows_()` berücksichtigt `Archiv_Personen` bereits korrekt, aber die Script-Cache-Zuordnung enthielt für `Archiv_Personen` keinen Schlüssel `ARCHIVED_PEOPLE`. Nach einer Archivierung konnte deshalb bis zum Cacheablauf ein veralteter leerer Archivbestand gelesen werden.
- Korrektur in TEST: `Archiv_Personen` invalidiert jetzt ausdrücklich `ARCHIVED_PEOPLE`. Auch die globale Cachebereinigung entfernt diesen Schlüssel. Anonymisierte externe Archiv-Stubs werden aus der Personalkarteiliste ausgeblendet.
- P1.7 bleibt bis zur praktischen Wiederholungsprüfung offen. Erwartung: Rudin erscheint nach Neuladen sofort unter `Inaktive anzeigen`, seine Personalkartei lässt sich öffnen und seine Prüfungshistorie bleibt erhalten.

P1.6 sichtbare Schnupperteilnahmen:
- Die bereits fachlich funktionierende Anonymisierung zu `Schnupperteilnahmen` wird jetzt im Trainingseditor sichtbar gemacht.
- Im Tab `Gäste` steht direkt unter `Externe Gäste` eine eigene, nicht bearbeitbare Zeile `Schnupperteilnahmen` mit der gespeicherten Anzahl.
- Der Teilnehmerzähler im Trainingseditor berücksichtigt jetzt neben namentlichen Teilnehmern und `Externe Gäste` auch `Schnupperteilnahmen`.
- `Externe Gäste` und `Schnupperteilnahmen` bleiben getrennte Sammelwerte.
- P1.6 bleibt bis zur praktischen Sichtprüfung offen.

P1.9 `Als externe Person einstufen`:
- Die zuvor verbindlich beschlossene vierte Entscheidung wurde im TEST umgesetzt.
- Die 94-Tage-Inaktivitätsentscheidung bietet zusätzlich `Als externe Person einstufen`. Auch die erzeugte Inaktivitätsmail enthält dafür einen eigenen Aktionslink.
- Vor der Umstellung werden offene operative Abhängigkeiten geprüft. Die Umstellung wird blockiert bei offener Anzugleihe, offenem Prüfungsvorgang, offener Wettkampfanmeldung oder offener Quartalsabrechnung.
- Bei zulässiger Umstellung wird die Person inaktiv archiviert. Die technische Personen-ID bleibt erhalten, historische Trainingszeilen bleiben unverändert.
- Der dauerhafte Personenstamm wird auf einen anonymen Archiv-Stumpf reduziert. Personenbezogene Stammdaten, Kontakt- und Bankdaten werden entfernt. Der Stub wird technisch gesperrt und fachlich als `Extern` geführt.
- Historische Anzeigen, die die Personen-ID auflösen, liefern für diesen Stub ausschließlich `Externer Gast`.
- Der anonymisierte Stub wird nicht mehr in der Personalkarteiliste angeboten.
- Doppelt gespeicherte Kontaktdaten werden in persönlichen Zugängen, abgeschlossenen Anzugleihen, Quartalsstatus und Abrechnungshistorie bereinigt. In Wettkampfanmeldungen werden personenbezogene Kontakt-Overrides und Rückmeldetoken der betroffenen Person entfernt. Historische Fachzeilen selbst werden nicht gelöscht.
- P1.9 bleibt bis zur kontrollierten praktischen Prüfung offen.

Technische Prüfung:
- TEST-`Code.gs` besteht die JavaScript-Syntaxprüfung mit Node.
- Die JavaScript-Blöcke des geänderten TEST-`Index.html` bestehen nach Entfernung der Google-Template-Tags die Node-Syntaxprüfung.
- Geändert werden ausschließlich TEST-`Code.gs`, TEST-`Index.html`, die beiden TEST-Arbeitszwillinge und diese `Projektakte.txt`.
- PROD und Liga bleiben unverändert.

Nächster Schritt:
- Geänderte TEST-Dateien in Google Apps Script übernehmen und neu bereitstellen.
- Danach zuerst P1.7 mit dem bereits archivierten Rudin Hamo wiederholen.


59. P1.6/P1.7 PRAKTISCH BESTANDEN, P1.9 REAKTIVIERUNG KORRIGIERT – 25.08.2026

P1.7 praktische Wiederholungsprüfung:
- Nach Übernahme des korrigierten TEST-Stands erscheint Rudin Hamo bei aktivierter Option `Inaktive anzeigen` sofort in der Personalkartei.
- Die archivierte Personalkartei lässt sich öffnen. Status `Inaktiv`, letzte Trainingsdaten und die dokumentierte Prüfung bleiben sichtbar.
- P1.7 ist damit praktisch bestanden.

P1.6 sichtbare Schnupperteilnahmen:
- Im Training vom 08.06.2026 werden im Tab `Gäste` getrennt `Externe Gäste = 1` und `Schnupperteilnahmen = 1` angezeigt.
- P1.6 ist damit praktisch bestanden.

P1.9 Reaktivierung vor der Einstufung als extern:
- Beim Versuch, den archivierten Rudin Hamo zu reaktivieren, trat ein Datenvalidierungsfehler in `Personenstatus!B133` auf.
- Ursache: Die Spalte `Personen-ID` in `Personenstatus` ist strikt gegen den aktiven Bereich `Personen!A2:A999` validiert. Beim bisherigen Ablauf wurde der neue Status geschrieben, solange die Person noch ausschließlich in `Archiv_Personen` lag.
- Korrektur in TEST: Bei einem Statuswechsel auf `aktiv` wird der archivierte Personenstamm jetzt zuerst nach `Personen` zurückgeführt. Erst danach werden der bisherige Status geschlossen und der neue aktive Status geschrieben. Damit ist die bestehende strikte Datenvalidierung während des Schreibvorgangs erfüllt.
- Beim Statuswechsel auf `inaktiv` bleibt die bisher richtige Reihenfolge bestehen: Status schreiben, operative Zuordnungen schließen, Zugang sperren, danach archivieren.
- P1.9 bleibt bis zur praktischen Wiederholungsprüfung der Reaktivierung und anschließenden Einstufung als externe Person offen.

Technische Prüfung:
- Geändert wurde nur TEST-`Code.gs` sowie diese `Projektakte.txt`.
- TEST-`Index.html` und `DateRangeDialog.html` bleiben unverändert.
- TEST-`Code.gs` besteht die JavaScript-Syntaxprüfung mit Node.

Nächster Schritt:
- TEST-`Code.gs` neu in Google Apps Script übernehmen und bereitstellen.
- Rudin Hamo erneut reaktivieren. Danach P1.9 mit `Als externe Person einstufen` fortsetzen.


60. GROSSER UMSETZUNGSSTAND 26.08.2026 – PROD-KANDIDAT UND P2-TESTKANDIDAT

Ausgangslage und Freigabe:
- Der Nutzer hat am 26.08.2026 ausdrücklich einen größeren zusammenhängenden Umsetzungslauf einschließlich vollständigem neuem Projektstand freigegeben.
- Ziel ist, am Morgen nur noch die betroffenen Apps-Script-Dateien manuell einzuspielen, neu bereitzustellen und anschließend die praktischen Prüfungen fortzusetzen.
- Der tatsächlich live bereitgestellte PROD-Stand wurde in diesem Arbeitslauf nicht direkt verändert. Die neue PROD-Fassung in diesem Projektstand ist ein technisch geprüfter Einspielkandidat.

P1.9 – historische anonymisierte Trainingsteilnahmen:
- Die fachliche Einstufung als externe Person mit anonymem Archiv-Stumpf und erhaltener technischer Personen-ID bleibt bestehen.
- Der praktische Test mit Klaus-Jürgen Hipp zeigte: Die Gesamtzahl im historischen Training blieb korrekt, der anonymisierte Teilnehmer wurde in der Teilnehmerliste jedoch nicht sichtbar als externer Gast dargestellt.
- Korrektur in TEST und im neuen PROD-Kandidaten: Eine historische Trainingsteilnahme, deren Personen-ID auf einen anonymisierten externen Archiv-Stumpf zeigt, bleibt technisch unverändert in `Trainingsanwesenheiten` bestehen, wird in der Oberfläche und den Trainingsergebnissen aber als Teil der Sammelposition `Externe Gäste` behandelt.
- Bestehende historische Trainingszeilen werden nicht massenhaft umgeschrieben. Dadurch bleibt die Referenzintegrität erhalten.
- Beim Bearbeiten eines solchen Trainings wird der historische anonymisierte Anteil nicht nochmals in den gespeicherten Sammelwert geschrieben. Doppelzählungen werden dadurch vermieden.
- `Schnupperteilnahmen` bleiben unabhängig davon als eigener Sammelwert erhalten. Bei der Umsetzung wurde zusätzlich abgesichert, dass dieser Wert beim Bearbeiten eines Trainings nicht verloren geht.
- P1.9 bleibt bis zur erneuten praktischen Sichtprüfung eines betroffenen historischen Trainings `In Arbeit`.

P2.1 bis P2.7 – Personalkartei, technisch vollständig in TEST umgesetzt:
- P2.1: `Aktuelle Gruppen` ist direkt klickbar. Das Auswahlfenster enthält alle Trainingsgruppen einschließlich inaktiver Gruppen und erlaubt Mehrfachauswahl.
- P2.2: Nach Änderungen oder Löschungen aktueller Gruppenzuordnungen wird geprüft, ob eine aktive Person noch mindestens eine aktuelle Gruppe hat. Fehlt jede aktuelle Gruppe, wird sie automatisch inaktiv gesetzt. Trainer, ÜL, Assistent, Vorstand und Admin sind ausgenommen. Externe sind zusätzlich technisch ausgenommen, weil sie fachlich bewusst ohne reguläre Trainingsgruppe geführt werden dürfen.
- P2.3: Die aktuelle Graduierung ist direkt klickbar und öffnet die Prüfungshistorie. Die separate Kachel `Prüfungshistorie` wurde aus der Personenkopfkarte entfernt.
- P2.4: `Trainerqualifikation` ist direkt klickbar und führt zur bestehenden Bearbeitung beziehungsweise Verlaufssicht.
- P2.5: `Prüfberechtigung` ist direkt klickbar und führt zur bestehenden Bearbeitung beziehungsweise Verlaufssicht.
- P2.6: `Rechterolle im System` ist direkt klickbar. Admin kann die Rolle ändern, andere Berechtigte erhalten eine lesende Detailansicht.
- P2.7: `Telefon`, `E-Mail`, `Kontakt 1` und `Kontakt 2` öffnen direkt die jeweilige Kontaktdatenbearbeitung.
- Für P2.1 bis P2.7 ist die technische Umsetzung abgeschlossen. Alle sieben Punkte bleiben bis zum praktischen Nutzertest `In Arbeit`.

PROD – neue Inaktivitäts-/Personenlogik als Einspielkandidat:
- Der bisherige 63-Tage-Stand wird im neuen PROD-Code durch die fachlich beschlossene 94-Tage-Regel für regulär aktive bestätigte Mitglieder ersetzt. Die anschließende Entscheidungsfrist bleibt 7 Tage.
- `Gelegentlich aktiv` wird über die technische Gruppe `Selten da, aber immer wieder gern gesehen` geführt und von der automatischen Inaktivierung ausgenommen.
- `Mitgliedschaft offen` und namentlich geführte Externe verwenden die beschlossene 56-Tage-/7-Tage-Logik mit Bereinigung beziehungsweise Anonymisierung.
- Archivierung und Reaktivierung nutzen die bereits in TEST korrigierte Reihenfolge, damit die strikte Datenvalidierung in `Personenstatus` nicht verletzt wird.
- Der zentrale PROD-Nachtlauf verwendet nach dem Einspielen dieselbe neue Kernlogik wie die manuellen und Link-basierten Entscheidungen.
- Der neue PROD-Code enthält weiterhin die produktiven Trigger-, E-Mail-, Backup-, Archiv- und Systemstatusfunktionen. TEST-spezifische Sperren oder TEST-Wrapper werden nicht nach PROD übernommen.
- Die Wettkampf-Platzierungsleiste P1.8 bleibt bewusst TEST-only, da ihre praktische Prüfung noch aussteht.

PROD – Schutz gegen fehlerhafte Inaktivitätslinks:
- Die Basisadresse für Inaktivitätslinks wird nur akzeptiert, wenn sie dem Apps-Script-Web-App-Schema `https://script.google.com/macros/s/.../exec` beziehungsweise dem zulässigen Entwicklungsendpunkt entspricht.
- Bei fehlender oder ungültiger Basisadresse wird kein defekter Aktionslink erzeugt.
- Beim nächsten PROD-Lauf werden noch aktive Inaktivitätslinks mit einer falschen beziehungsweise veralteten Basis erkannt und verworfen, sobald eine gültige aktuelle Web-App-Basis bekannt ist.
- Damit soll insbesondere verhindert werden, dass erneut ein Link auf eine Google-Drive-Fehlerseite erzeugt wird.
- Diese PROD-Änderung ist technisch geprüft, aber erst nach manuellem Einspielen und Bereitstellen praktisch wirksam.

Technische Prüfungen dieses Kandidatenstands:
- TEST-`Code.gs` besteht die JavaScript-Syntaxprüfung mit Node.
- Die JavaScript-Blöcke von TEST-`Index.html` bestehen nach Entfernung der Google-Template-Tags die Node-Syntaxprüfung.
- PROD-`Code.gs` besteht die JavaScript-Syntaxprüfung mit Node.
- Die JavaScript-Blöcke von PROD-`Index.html` bestehen nach Entfernung der Google-Template-Tags die Node-Syntaxprüfung.
- Die internen Helferabhängigkeiten des neuen PROD-Codes wurden gegen fehlende interne Funktionsdefinitionen geprüft.
- Die neue PROD-Fassung wurde selektiv aus dem bestehenden PROD-Stand erweitert. PROD-spezifische Nachtlauf-, Trigger-, E-Mail-, Backup- und Archivfunktionen wurden beibehalten.

Neue offene Aufgabe Wettkampfkommunikation:
- P4.4 wurde in die Live-Checkliste aufgenommen.
- Bei der Wettkampfvorbereitung muss vor dem E-Mail-Versand deutlich angezeigt werden, welche vorgesehenen Teilnehmer keine E-Mail erhalten, weil keine E-Mail-Adresse hinterlegt ist.
- Die bearbeitende Person muss die betroffenen Teilnehmernamen eindeutig erkennen können.
- P4.4 ist nur dokumentiert und in diesem Umsetzungslauf nicht technisch umgesetzt.

Praktische Prüfungen nach Einspielen:
- PROD: normalen Login und Startseite kontrollieren, anschließend Systemeinstellungen und Nachtlauf-/Inaktivitätskonfiguration plausibilisieren. Der erste produktive Lauf der neuen Personenlogik ist gesondert zu kontrollieren.
- TEST: P1.9 am bereits anonymisierten historischen Trainingsfall erneut prüfen.
- TEST: P2.1 bis P2.7 der Reihe nach praktisch prüfen.
- TEST: P1.8 Wettkampf-Platzierungsleiste bleibt als separater praktischer Test offen.
- TEST: P1.3 automatische Archivierung nach Ablauf der 7-Tage-Frist bleibt praktisch offen.
- TEST: P1.5 Wiederholungsprüfung nach der technischen Doppellöschungs-Korrektur bleibt offen.

Dateistand dieses Projektstands:
- TEST geändert: `Code.gs`, `Index.html`.
- PROD geändert: `Code.gs`, `Index.html`.
- Unverändert: beide `DateRangeDialog.html`.
- `Projektakte.txt`, `00_START_HIER.txt`, Live-Checkliste und deren XLSX-Snapshot werden auf diesen Stand konsolidiert.
- `Masterprompt.txt` bleibt inhaltlich unverändert, da keine neue dauerhafte Arbeitsregel beschlossen wurde.
- Die vier vorgeschriebenen Live-Sheet-Snapshots wurden am 26.08.2026 05:30 versioniert in den jeweiligen `Sheet-Versionen`-Ordnern abgelegt: `PROD_Judo App 2.0`, `Spielwiese_Judo App 2.0`, `PROD_2026 Ligabetrieb` und `Spielwiese_2026 Ligabetrieb`. Die Liga-Laufzeitdateien selbst wurden nicht verändert.

60. PROD-LOGINBLOCKER NACH MORGENDEPLOYMENT SOFORT KORRIGIERT – 26.08.2026

Praktischer Fehler:
- Nach Einspielen des vorbereiteten PROD-Stands und erneuter Bereitstellung schlug die PIN-Anmeldung unmittelbar mit `TypeError: Cannot read properties of undefined (reading 'length')` fehl.
- Der Fehler hatte höchste Priorität, da damit der produktive App-Zugang blockiert war.

Ursache:
- Beim nächtlichen Zusammenführen der neuen Personen-/Archivsystematik wurde `Archiv_Personen` zwar in `SHEETS`, Standardreihenfolge und Runtime-Schema aufgenommen, die zugehörige Headerdefinition in `REQUIRED_HEADERS` wurde im PROD-Code jedoch versehentlich nicht mit übernommen.
- Beim ersten Login lief `ensureRuntimeSchemaFast_()` und darüber `ensureProjectExtensionSchemas_()`. Für `Archiv_Personen` war `REQUIRED_HEADERS[name]` deshalb `undefined`. Der anschließende Zugriff auf `headers.length` erzeugte exakt den sichtbaren TypeError.
- TEST war von diesem konkreten Fehler nicht betroffen, weil die Headerdefinition dort vorhanden war.

Korrektur:
- Die vollständige `Archiv_Personen`-Headerdefinition wurde in PROD ergänzt, identisch zur bereits funktionierenden TEST-Definition.
- Keine Änderung an `Index.html` erforderlich.
- PROD-`Code.gs` und Arbeitszwilling `01_Prod_Code.gs.txt` wurden im Drive aktualisiert.

Technische Prüfung:
- korrigierter PROD-Code besteht die JavaScript-Syntaxprüfung mit Node.
- statisch geprüft: `REQUIRED_HEADERS['Archiv_Personen']` ist vorhanden und der Runtime-Schema-Aufruf besitzt damit für dieses Blatt eine definierte Headerliste.
- Drive-Rückleseprüfung: aktualisierter PROD-`Code.gs` ist bytegleich mit der lokal geprüften Hotfix-Datei. SHA-256: `5dafde0e3859d40320b519239bbaaff95d259493f12974e294e72fa000a252f2`.

Praktische Restprüfung:
- Der Nutzer muss ausschließlich den korrigierten PROD-`Code.gs` aus dem Drive-Arbeitsstand in Apps Script übernehmen und neu bereitstellen.
- Danach PIN-Anmeldung erneut prüfen. Erst diese praktische Wiederholungsprüfung schließt den Fehler endgültig.

61. DIREKTE PERSONENSTATUS-AKTIONEN IN DER PERSONALKARTEI – 26.08.2026

Auslöser:
- Der Nutzer stellte praktisch fest, dass Bestandsmitglieder in der Personalkartei nicht unmittelbar in `Gelegentlich aktiv` beziehungsweise die technische Gruppe `Selten da, aber immer wieder gern gesehen` überführt werden konnten.
- Zusätzlich sollte in demselben Aktionsbereich eine einfache Extern-Markierung gesetzt und wieder entfernt werden können.
- Die Umsetzung wurde ausdrücklich sofort für PROD und TEST freigegeben.

Umsetzung in PROD und TEST:
- Neben `Aktiv/Inaktiv setzen` steht bei regulär aktiven bestätigten Mitgliedern nun die direkte Aktion `Selten da, aber immer wieder gern gesehen` zur Verfügung.
- Die Aktion verwendet die bestehende fachliche Kategorie `Gelegentlich aktiv`. Reguläre aktuelle Gruppenzuordnungen werden beendet und die technische Gruppe `Selten da, aber immer wieder gern gesehen` wird zugeordnet.
- Damit greift dieselbe bereits beschlossene Schutzlogik gegen die automatische 94-Tage-Inaktivierung. Es entsteht kein paralleler Sonderstatus.
- Zusätzlich steht in der Personalkartei die direkte Aktion `Als Extern markieren` zur Verfügung. Bei bereits extern markierten Personen lautet sie `Extern-Markierung entfernen`.

Abgrenzung zur P1.9-Anonymisierung:
- Die neue direkte Extern-Markierung ist ausdrücklich nur eine Änderung des Vereinsbezugs. Personenbezogene Stammdaten bleiben erhalten.
- Beim Markieren als extern werden aktuelle reguläre Gruppenzuordnungen beendet.
- Beim Entfernen der Extern-Markierung wird die Person wieder als bestätigtes `Mitglied` geführt. Frühere Gruppenzuordnungen werden nicht automatisch wiederhergestellt.
- Die P1.9-Aktion `Als externe Person einstufen` aus der Inaktivitätsentscheidung bleibt davon getrennt. Sie anonymisiert personenbezogene Daten und ist für die dauerhafte historische Extern-Umstufung vorgesehen.
- Ein bereits anonymisierter technischer Datensatz `Externer Gast` kann über die neue Schnellaktion nicht wieder in eine personenbezogene Person umgewandelt werden.

Technische Prüfung:
- TEST-`Code.gs` besteht die JavaScript-Syntaxprüfung.
- PROD-`Code.gs` besteht die JavaScript-Syntaxprüfung.
- Die JavaScript-Blöcke beider `Index.html` bestehen die Syntaxprüfung nach Entfernung der Google-Template-Tags.
- Die Änderungen wurden in den Drive-Laufzeitdateien von PROD und TEST sowie in den zugehörigen Arbeitszwillingen aktualisiert.

Praktische Restprüfung:
- PROD und TEST jeweils neu bereitstellen.
- In der Personalkartei bei einem regulären Mitglied die neue Aktion `Selten da, aber immer wieder gern gesehen` kontrollieren.
- `Als Extern markieren` und anschließend `Extern-Markierung entfernen` kontrolliert an einem geeigneten Testdatensatz prüfen.

62. PROD-PERSONALKARTEI-NAVIGATION HOTFIX – 26.08.2026

Praktischer Fehler:
- Nach dem Einspielen der neuen PROD-Dateien ließ sich die Kachel `Personalkartei` anklicken und die Modulüberschrift wechselte auf `PERSONALKARTEI`, der eigentliche Seiteninhalt blieb jedoch unverändert auf der Startansicht stehen.
- TEST funktionierte im gleichen Ablauf korrekt.
- Der Fehler hatte höchste Priorität, weil die produktive Personalkartei dadurch nicht erreichbar war.

Ursache:
- In der PROD-Funktion `renderPeople()` war beim Zusammenführen der TEST-/PROD-Stände eine TEST-spezifische Bedingung mit der Variable `IS_TEST` stehen geblieben.
- `IS_TEST` ist im PROD-Frontend nicht definiert.
- `setTitle('Personalkartei')` wurde noch ausgeführt. Beim anschließenden Auswerten des Personalkartei-Templates verursachte `IS_TEST` jedoch einen JavaScript-ReferenceError, bevor `#main` mit dem Personalkartei-Inhalt ersetzt werden konnte. Dadurch entstand exakt das beobachtete Mischbild aus neuer Überschrift und alter Startansicht.
- TEST enthielt diese fehlerhafte Referenz nicht und war deshalb nicht betroffen.

Korrektur:
- Die TEST-spezifische Schaltfläche `Inaktivitätsprüfung jetzt ausführen` wird in PROD nicht mehr über eine nicht definierte Laufzeitvariable bedingt eingebaut. Der betreffende TEST-Ausdruck wurde aus PROD vollständig entfernt.
- TEST blieb unverändert.
- Geändert wurde ausschließlich PROD-`Index.html` sowie der zugehörige Arbeitszwilling `02_Prod_Index.html.txt`.
- PROD-`Code.gs` und beide `DateRangeDialog.html` blieben unverändert.

Technische Prüfung:
- Statisch geprüft: Im korrigierten PROD-`Index.html` existiert keine Referenz auf `IS_TEST` mehr.
- Die JavaScript-Blöcke des korrigierten PROD-`Index.html` bestehen nach Entfernung der Google-Template-Tags die Node-Syntaxprüfung.
- Die Personalkartei-Funktion `renderPeople()` ist weiterhin vorhanden und baut den Seiteninhalt ohne TEST-Bedingung auf.
- SHA-256 der lokal geprüften PROD-`Index.html`-Hotfix-Datei: `835e8700aaa414db6323488a5b0a2155df567af6db8c0c01fef4cfb093518db0`.

Praktische Restprüfung:
- Ausschließlich den aktuellen PROD-`Index.html` aus dem Drive-Arbeitsstand in Apps Script übernehmen und PROD neu bereitstellen.
- Danach Startseite öffnen, `Personalkartei` anklicken und prüfen, dass Such-/Filteransicht vollständig erscheint.

63. KRITISCHE BEFUNDE DER SYSTEMPRÜFUNG BEHOBEN – 26.08.2026 09:36

Auftrag:
- Nach der eingehenden Prüfung von PROD und TEST wurden ausschließlich die als kritisch eingestuften Befunde sofort zur Umsetzung freigegeben.
- Danach sollen die übrigen Hoch-/Mittel-/Performance-/Datenhygiene-Befunde erneut priorisiert zur Entscheidung vorgelegt werden.
- Die Befunde mussten vor gesicherter Ausgabe mindestens zwei Revisionsschleifen durchlaufen.

Kritischer Fix A – `Gelegentlich aktiv` setzt die Inaktivitätsprüfung sofort und dauerhaft aus:
- `Gelegentlich aktiv` beziehungsweise die technische Gruppe `Selten da, aber immer wieder gern gesehen` bleibt weiterhin die einzige fachliche Kennzeichnung für diese Ausnahme.
- Die 94-Tage-Kandidatenlogik schließt diese Personen aus.
- Beim Setzen von `Gelegentlich aktiv` werden vorhandene aktive oder abgelaufene `PERSON_INAKTIV_AUTO`-Vorgänge der Person sofort beendet.
- Bereits vor dem Fix erzeugte alte Entscheidungslinks werden zusätzlich vor jeder Entscheidung erneut gegen die aktuelle Kandidatenlogik geprüft. Ist die Person inzwischen gelegentlich aktiv, geschützt oder wieder ausreichend aktiv, kann der alte Link keine Statusänderung mehr auslösen.
- Die Personalkartei blendet einen alten Inaktivitäts-Countdown für gelegentlich aktive oder geschützte Personen nicht mehr ein.
- Beim normalen App-Start werden über die Hintergrundregistrierung der aktuellen Web-App-Adresse noch vorhandene Inaktivitätslinks für gelegentlich aktive beziehungsweise geschützte Funktionsträger bereinigt. Damit wird auch der bereits bestehende Fall Agnes Gaschik nach Bereitstellung des neuen Codes ohne erneutes manuelles Setzen bereinigt.

Kritischer Fix B – Funktionsträger vollständig aus der 94-Tage-Automatik herausnehmen:
- Von der automatischen Inaktivitätsprüfung ausgeschlossen sind nun Personen mit aktueller Funktion `Trainer`, `Übungsleiter` oder `Trainer-Assistent`.
- Zusätzlich sind Personen mit aktivem App-Zugang und Rolle `Vorstand` oder `Admin` ausgeschlossen.
- Der Schutz greift sowohl bei der Kandidatenermittlung als auch bei der erneuten Gültigkeitsprüfung eines bereits vorhandenen Inaktivitätslinks.
- Bereits vorhandene Inaktivitätslinks solcher Funktionsträger werden beim normalen App-Start bereinigt und beim nächsten Automatiklauf ebenfalls verworfen.

Kritischer Fix C – Web-App-Basis für Aktionslinks absichern:
- `webAppBaseUrl_()` bevorzugt nun die aktuell von Apps Script gemeldete Service-URL und verwendet einen gespeicherten Wert nur noch als Rückfall.
- In PROD wird ausschließlich ein `/exec`-Endpunkt akzeptiert. Ein `/dev`-Endpunkt wird produktiv nicht als Linkbasis verwendet.
- Das Frontend meldet nach dem Login zuerst die tatsächlich im Browser geöffnete Web-App-Adresse zurück. Die bisherige Priorisierung eines möglicherweise veralteten Template-Werts wurde entfernt.
- Ändert sich die Web-App-Basis, werden noch aktive Inaktivitätslinks mit abweichender Basis beendet. Neue Inaktivitätslinks werden anschließend nur noch aus der aktuellen Basis erzeugt.

Kritischer Fix D – drei sichtbare Wettkampffunktionen in PROD wieder mit Serverlogik verbinden:
- `Meldeliste anzeigen` besitzt in PROD wieder die zugehörige Serverfunktion.
- `Meldeliste per E-Mail versenden` besitzt in PROD wieder die zugehörige Serverfunktion einschließlich produktiver E-Mail-Sperr-/Berechtigungsprüfung.
- `Handliste als PDF` besitzt in PROD wieder die zugehörige Serverfunktion.
- Übernommen wurden ausschließlich die in TEST bereits vorhandenen und vom PROD-Frontend aufgerufenen Funktionen samt unmittelbar erforderlicher Helfer. Die TEST-only-Wettkampfsimulation wurde nicht nach PROD übernommen.

Technische Revisionsschleife 1 – Ergebnis BESTANDEN:
- Für PROD und TEST geprüft: `Gelegentlich aktiv` beendet alte Inaktivitätslinks.
- Für PROD und TEST geprüft: Kandidatenlogik schließt alle festgelegten Funktionsträger aus.
- Für PROD und TEST geprüft: alte Entscheidungslinks werden vor Ausführung erneut auf fachliche Gültigkeit geprüft.
- Für PROD und TEST geprüft: Personalkartei zeigt bei gelegentlich aktiven/geschützten Personen keinen alten Countdown mehr.
- Für PROD und TEST geprüft: aktuelle Browser-/Service-Web-App-Adresse hat Vorrang vor gespeicherter Altadresse.
- Für PROD geprüft: alle drei fehlenden Wettkampfserverfunktionen vorhanden.

Technische Revisionsschleife 2 – Ergebnis BESTANDEN:
- JavaScript-Syntax von PROD- und TEST-`Code.gs` erneut unabhängig geprüft.
- Die sieben kritischen Kernfunktionen für Inaktivitäts- und Web-App-Logik sind zwischen PROD und TEST inhaltlich identisch.
- Alle Frontend-RPC-Aufrufe wurden gegen vorhandene Serverfunktionen geprüft. In PROD bleiben ausschließlich zwei bewusst TEST-only referenzierte, aber im PROD-Ablauf nicht aufrufbare Funktionen ohne Serverdefinition: `runInactiveMemberAutomationTest` und `simulateCompetitionDayTest`.
- Die neu nach PROD übernommene Wettkampf-Meldelisten-/PDF-Logik wurde auf alle benötigten Serverabhängigkeiten geprüft. Keine fehlende Abhängigkeit gefunden.
- Produktiver E-Mail-Versand der Meldeliste besitzt weiterhin die bestehende E-Mail-Freigabeprüfung.
- Keine der beiden Index-Dateien priorisiert mehr die alte Template-Web-App-Adresse vor der tatsächlich geöffneten Browseradresse.

Aktualisierte verbleibende Befunde nach den kritischen Fixes:

HOCH:
1. Regel `keine aktuelle Trainingsgruppe -> inaktiv` ist noch nicht in allen Zustandswechseln vollständig abgesichert. Kritische Übergänge sind insbesondere Extern -> Mitglied, Gelegentlich -> regulär aktiv sowie Wegfall einer bisherigen Funktionsträger-Ausnahme. Eine aktive reguläre Person kann dadurch ohne Gruppe zurückbleiben.
2. Die Personalkartei wird im Frontend teilweise Rollen/Zugangsarten angeboten, die der Server beim tatsächlichen Öffnen ablehnt. Besonders Trainer- und Sammelzugangspfade müssen fachlich und technisch vereinheitlicht werden.

MITTEL:
3. Im aktuellen PROD-Datenbestand liegen 11 Personen mit aktuellem Status `inaktiv` weiterhin im operativen Blatt `Personen` statt im vorgesehenen `Archiv_Personen`. Die IDs wurden gegen den aktuellen Live-Export erneut bestätigt.
4. Mehrere Statuswechsel am selben Kalendertag können einen ungültigen historischen Zeitraum erzeugen. Im aktuellen TEST-Datenbestand existiert dafür bereits ein konkreter Fall bei `P00108`: `inaktiv` ab 25.08.2026 mit `Gültig bis 24.08.2026` und zusätzlich neuer Status `aktiv` ab 25.08.2026.
5. Die PROD-Validierungslogik rund um den Vereinsbezug `Extern` ist an mehreren Stellen historisch gewachsen. Die tatsächlichen Zellvalidierungen und alle Schreibpfade sollen noch einmal gemeinsam geprüft und vereinheitlicht werden.

PERFORMANCE:
6. Die Inaktivitätsprüfung benötigt im TEST bei der aktuellen Datenmenge typischerweise ungefähr 20–26 Sekunden. Ein beobachteter Ausreißer lag bei rund 73 Sekunden. Funktional ist der Lauf deutlich besser als die frühere Minutenblockade, bleibt aber ein relevanter Performancepunkt vor weiterem Datenwachstum.

TEST-DATENHYGIENE:
7. Im aktuellen TEST-Blatt `Personen` ist die Personen-ID `P00140` doppelt vorhanden. PROD besitzt keine doppelte Personen-ID.
8. Im TEST existiert weiterhin mindestens ein auffälliger Wettkampf-Testwert, der im Rahmen der P1.8-Prüfung gezielt bereinigt beziehungsweise bewertet werden soll. Numerische Alt-Platzierungen 1–7 selbst sind dabei kein Fehler und dürfen nicht pauschal beanstandet werden.

Positiv erneut bestätigt:
- PROD besitzt keine doppelte Personen-ID.
- Im aktuellen PROD-Datenexport wurde kein ungültiger Personenstatus-Zeitraum gefunden.
- Die bereits zuvor geprüften Kernreferenzen zeigten keine grundlegenden verwaisten Personen-/Trainings-/Wettkampf-/Prüfungsbezüge.
- Die aktuellen kritischen Codeänderungen sind syntaktisch fehlerfrei und haben zwei getrennte technische Revisionsschleifen bestanden.

Dateistand:
- PROD geändert: `Code.gs`, `Index.html`.
- TEST geändert: `Code.gs`, `Index.html`.
- Beide `DateRangeDialog.html` unverändert.
- Praktische Wirksamkeit in Apps Script beginnt erst nach manueller Übernahme und erneuter Bereitstellung durch den Nutzer.


## 65. Praktische Bestätigung PROD: „Gelegentlich aktiv“ stoppt Inaktivitätsprüfung (26.08.2026)

- Nutzer hat nach Einspielen und Bereitstellen des kritischen Fix-Blocks Agnes Gaschik in PROD geprüft.
- Erwartetes Ergebnis bestätigt: Status „Gelegentlich aktiv“ sichtbar, kein Countdown „Inaktiv in … Tagen“ mehr.
- Damit ist der sichtbare PROD-Pfad für die dauerhafte Aussetzung der Inaktivitätsprüfung praktisch bestätigt.
- Die übrigen kritischen Fixes bleiben technisch mit zwei Revisionsschleifen geprüft, benötigen aber noch eigene praktische Stichproben.


## 66. PRIO 1 – Inaktivitätsmeldungen einmalig vollständig neu berechnen (26.08.2026)

Neue fachliche Anforderung:
- Aufgrund der umfassend geänderten Regeln zur Ermittlung und Behandlung länger inaktiver Personen soll der bisherige technische Prüf- und Meldestatus einmal vollständig zurückgesetzt werden.
- Zurückgesetzt beziehungsweise beendet werden ausschließlich die bislang erzeugten Inaktivitätsmeldungen und zugehörigen `PERSON_INAKTIV_AUTO`-Einmallinks. Bereits fachlich korrekt gesetzte Personenstatus wie `inaktiv`, `extern` oder `gelegentlich aktiv` werden dadurch nicht rückgängig gemacht.
- Der nächste PROD-Nachtlauf soll anschließend wie eine Erstberechnung auf Basis des dann aktuellen Regelwerks arbeiten.
- Für jede nach dieser Erstberechnung tatsächlich prüfpflichtige Person sollen neue, gültige Einmallinks erzeugt werden.
- Die daraus entstehenden Inaktivitätsmeldungen sollen im selben Nachtlauf an beide in den Kommunikationseinstellungen hinterlegten Ansprechpartner für die Inaktivitätsprüfung versendet werden.
- Ziel ist ein sauberer Neustart ohne Altvorgänge oder alte Fristen aus dem früheren Regelstand.

Status:
- Prio 1.
- Fachlich aufgenommen.
- Noch nicht technisch umgesetzt.
- Umsetzung vor dem nächsten vorgesehenen PROD-Nachtlauf erforderlich, sobald der Nutzer sie ausdrücklich freigibt.


## Entscheidung 26.08.2026 – P6.9 Erstberechnung Inaktivität
- Zielzustand präzisiert: Der kommende produktive Inaktivitätslauf wird behandelt, als hätte es zuvor noch nie eine Nachtlauf-E-Mail zur Inaktivitätsprüfung gegeben.
- Sämtliche bisherigen laufenden 7-Tage-Fristen aus früheren Inaktivitätsmeldungen werden verworfen.
- Sämtliche bisherigen PERSON_INAKTIV_AUTO-Einmallinks werden ungültig.
- Bereits fachlich korrekt gesetzte Personenstatus wie inaktiv, extern oder gelegentlich aktiv bleiben unverändert bestehen. Ebenso bleiben Gruppen, Trainingshistorie und sonstige Stammdaten bestehen.
- Der nächste PROD-Nachtlauf bewertet alle aktuell relevanten Personen vollständig nach dem dann gültigen Regelwerk neu.
- Für jede Person, die dabei neu die Voraussetzungen erfüllt, beginnt eine vollständig neue 7-Tage-Frist.
- Zu jedem neu erzeugten Vorgang wird ein neuer Einmallink erzeugt und an beide hinterlegten Ansprechpartner der Inaktivitätsprüfung versendet.
- Umsetzung noch nicht freigegeben. Strategiegespräch läuft.

## Entscheidung 26.08.2026 – P6.9 Empfänger- und Einmallinklogik
- Für jeden neu erzeugten Inaktivitätsvorgang erhält jeder der beiden hinterlegten Ansprechpartner einen eigenen technisch getrennten Einmallink.
- Beide Links gehören fachlich zum selben Vorgang derselben Person.
- Solange noch keine Entscheidung getroffen wurde, sind beide Links gültig.
- Die erste gültig gespeicherte Entscheidung gewinnt und beendet den gesamten Vorgang atomar.
- Der jeweils andere Link wird dadurch sofort wirkungslos und darf keine abweichende zweite Entscheidung mehr auslösen.
- Beim späteren Öffnen des zweiten Links wird keine technische Fehlermeldung gezeigt, sondern ein verständlicher Hinweis, dass der Vorgang bereits erledigt wurde, einschließlich des bereits wirksam gewordenen Ergebnisses und Zeitpunkts.
- Intern wird protokolliert, welcher Empfängerlink die Entscheidung ausgelöst hat und wann.
- Parallelität wird serverseitig abgesichert, damit nahezu gleichzeitige Klicks niemals zwei widersprüchliche Statusänderungen speichern können.
- Versandform: je Ansprechpartner genau eine Sammelmail mit allen aktuell betroffenen Personen. In dieser Sammelmail enthält jede Person ausschließlich den individuellen Link dieses Empfängers.
- Es werden ausdrücklich nicht zwei Einzelmails pro Person verschickt. Bei zwei Ansprechpartnern entstehen somit grundsätzlich zwei Sammelmails pro Nachtlauf.
- Sind beide hinterlegten Ansprechpartner technisch dieselbe E-Mail-Adresse, wird der Versand sinnvoll dedupliziert, ohne die fachliche Zwei-Empfänger-Logik künstlich zu verdoppeln.
- P6.9 ist damit fachlich vollständig spezifiziert. Technische Umsetzung bleibt bis zur ausdrücklichen Freigabe offen.

## Entscheidung 26.08.2026 – P6.2 Rechte der Personalkartei
- Fachlich bestätigt: Die Personalkartei ist ein Verwaltungsmodul und wird ausschließlich für Vorstand und Admin freigegeben.
- Trainer erhalten keinen allgemeinen Zugriff auf die Personalkartei. Sie behalten nur die für ihre operativen Abläufe notwendigen Personenfunktionen direkt in den jeweiligen Modulen, insbesondere im Training.
- Der Sammel-/Notzugang behält seine festen Minimalrechte und erhält keinen allgemeinen Zugriff auf die Personalkartei.
- Frontend und Server müssen diese Regel identisch durchsetzen. Es darf keine Kachel oder Navigation angeboten werden, die anschließend serverseitig abgewiesen wird.
- Diese Regel entspricht der bisher gemeinten, aber bislang noch nicht ausdrücklich abgestimmten Rollenlogik.
- Technische Umsetzung von P6.2 bleibt bis zur späteren ausdrücklichen Umsetzungsfreigabe offen.

## Entscheidung 26.08.2026 – P3.1/P3.2 Sichtbarkeit PROD-/TEST-Stand
- Die ursprünglich erwogene Unsynchronitätsanzeige innerhalb der App wird verworfen.
- Stattdessen zeigt die Systemstatus-E-Mail ganz oben deutlich den tatsächlich eingesetzten Laufzeitstand beider Umgebungen an.
- Anzeige mindestens als `PROD-Stand: TT.MM.JJJJ HH:MM` und `TEST-Stand: TT.MM.JJJJ HH:MM`.
- Maßgeblich ist der tatsächlich eingesetzte Laufzeit-/Code-Stand, nicht das Änderungsdatum des Sheets und nicht ein Login- oder Nutzungszeitpunkt.
- Eine zusätzliche textliche Bewertung wie `TEST ist neuer als PROD` ist nicht erforderlich. Der Nutzer erkennt dies direkt aus den beiden Zeitständen.
- P3.1 ist damit fachlich entschieden.
- P3.2 bleibt als technische Umsetzung in der Systemstatus-E-Mail offen und wird erst nach ausdrücklicher Umsetzungsfreigabe ausgeführt.

## Entscheidung 26.08.2026 – P4.3 Externer Prüfer
- Fachlich bestätigt: Im Feld `Prüfer` wird zusätzlich die Auswahl `Externer Prüfer` angeboten.
- Bei Auswahl erscheint direkt darunter ein Pflicht-Freitextfeld für den Namen des externen Prüfers.
- Der externe Prüfer wird nicht als Person im Personenstamm angelegt.
- Gespeichert und in der Prüfung angezeigt wird die eindeutige Kombination `Externer Prüfer: <Name>`.
- Technische Umsetzung bleibt bis zur ausdrücklichen Umsetzungsfreigabe offen.

## Neue Anforderung 26.08.2026 – Mitgliedschaft offen: Nachtlauf/Systemstatus und Wiedervorlage
Aktueller geprüfter Codezustand:
- Der Hinweis `Trainiert seit … Mitgliedsstatus prüfen` gehört aktuell zum Hinweiscenter/Glocke. Der dortige Standardwert `HINWEIS_MITGLIEDSCHAFT_NACH_TAGEN` beträgt 42 Tage.
- Dieser `Trainiert seit …`-Hinweis ist aktuell nicht Bestandteil der Systemstatus-E-Mail.
- Daneben existiert bereits eine andere Nachtlauf-Logik für `Mitgliedschaft offen`: 56 Tage ohne Training, danach 7-Tage-Löschwarnung und gegebenenfalls Anonymisierung/Löschung. Diese Logik ist fachlich von der Erinnerung an einen noch fehlenden Mitgliedsantrag zu unterscheiden.
- Die historisch gewachsene Hinweislogik behandelt an einzelnen Stellen noch `Gast` und `Mitgliedschaft offen` unterschiedlich. Bei der späteren Umsetzung muss dies vereinheitlicht werden, damit keine Person durch unterschiedliche Altlogiken fällt.

Gewünschter Zielzustand:
- Offene Mitgliedschaften sollen nicht nur über die Glocke sichtbar sein, sondern zusätzlich in die Systemstatus-E-Mail des Nachtlaufs aufgenommen werden.
- Für einen solchen offenen Mitgliedschaftsfall werden zwei Wiedervorlage-Aktionen angeboten: `Wiedervorlage in 2 Wochen` und daneben optisch kleiner `Wiedervorlage in 6 Wochen`.
- Hintergrund: Eine mündliche Zusage `Ich gebe den Antrag ab` darf den Fall nicht dauerhaft aus dem Blick nehmen. Liegt der Antrag nach Ablauf der Wiedervorlage weiterhin nicht vor beziehungsweise wurde die Mitgliedschaft nicht bestätigt, muss der Fall erneut erscheinen.
- Wiedervorlage bedeutet ausdrücklich nicht `erledigt` und bestätigt keine Mitgliedschaft.
- Technische Umsetzung noch nicht freigegeben.

## Neue Anforderung 26.08.2026 – Mitgliedschaftsbestätigung mit Datum und bestätigender Person
- Bei neu angelegten Personen erhalten die konfigurierten Verantwortlichen weiterhin die Benachrichtigung mit direktem Vorgangszugriff und können die Mitgliedschaft bestätigen, unabhängig davon, bei wem der Antrag eingegangen ist.
- Künftig muss jede positive Mitgliedschaftsbestätigung dauerhaft mit Datum/Zeitpunkt und Identität der bestätigenden Person gespeichert werden.
- In der Personalkartei wird oben rechts unter dem sinngemäßen Feld `Trainiert bei uns seit` zusätzlich angezeigt: `Mitgliedschaft bestätigt am` und `durch`.
- Diese Protokollierung muss für alle Bestätigungswege gelten, insbesondere Personalkartei/Hinweiscenter und Direktlink aus der E-Mail.
- Aktueller technischer Befund: Der heutige Direktlink ist für alle Empfänger identisch und schreibt nur `DIREKTLINK`. Damit kann aktuell nicht festgestellt werden, welcher Empfänger geklickt hat.
- Für eine belastbare Identität muss der spätere Direktlink daher empfängerbezogen sein oder eine Anmeldung verlangen. Bevorzugt wird die empfängerbezogene Linklösung, damit der bestehende einfache E-Mail-Ablauf erhalten bleibt.
- Technische Umsetzung noch nicht freigegeben.

## Neue Anforderung 26.08.2026 – Prüfungsbestätigungen mit Datum und bestätigender Person
- In jedem Prüfungsfall sollen beide Bestätigungen sichtbar mit Datum und Name des Bestätigenden geführt werden: `Prüfungsgebühr bezahlt` sowie `In DokuMe übertragen`.
- Der aktuelle Datenbestand besitzt dafür bereits die Felder `Zahlung bestätigt am/von` und `DokuMe bestätigt am/von`.
- Bei Bestätigung innerhalb der angemeldeten App wird bereits der Zugangsbezug gespeichert.
- Beim heutigen Prüfungs-Direktlink wird dagegen nur `DIREKTLINK` als Bestätigender gespeichert. Dadurch ist dort keine konkrete Person erkennbar.
- Ziel ist eine einheitliche Anzeige mit aufgelöstem Namen und Datum unabhängig vom Bestätigungsweg. Für Direktlinks ist deshalb ebenfalls eine empfängerbezogene Zuordnung erforderlich, sofern keine Anmeldung verlangt werden soll.
- Technische Umsetzung noch nicht freigegeben.

## NOTSTANDSSICHERUNG – 26.08.2026 14:02

Anlass:
- Der Nutzer hat nach Abbruch des vorherigen Chats wegen erreichter maximaler Gesprächslänge ausdrücklich `Notstand sichern` angeordnet.
- Ziel ist ein unveränderlicher Rücksprungstand des tatsächlich vorhandenen Drive-Arbeitsstands, bevor die mögliche Restlücke des ausgelaufenen Chats rekonstruiert wird.

Gesicherte Grundlage:
- PROD `Code.gs`: Drive-Arbeitsstand 26.08.2026 09:39.
- PROD `Index.html`: Drive-Arbeitsstand 26.08.2026 09:39.
- TEST `Code.gs`: Drive-Arbeitsstand 26.08.2026 09:39.
- TEST `Index.html`: Drive-Arbeitsstand 26.08.2026 09:40.
- beide `DateRangeDialog.html`: unveränderter vorhandener Stand.
- `Projektakte.txt`: letzter vorheriger Drive-Schreibstand 26.08.2026 11:09.
- `Masterprompt.txt`: unverändert übernommen.
- PROD-Live-Sheet für diese Sicherung frisch als XLSX exportiert. SHA-256: `b8ffc8501932ab180a09b5569bad167b205ab7f9931c2eba66a8864319d15723`.
- Live-Checkliste für diese Sicherung frisch als XLSX exportiert. SHA-256: `83a68a51a9e179dfe5b356c7b061738698edb7eaad16f32da830211acca7e695`.
- Bei der technischen Zweitprüfung wurde die alte Dokumentationsangabe `51 Tabellenblätter` korrigiert: Der frische PROD-Snapshot enthält 52 Tabellenblätter einschließlich `Archiv_Personen`.
- Design- und Logo-Referenzen unverändert aus dem letzten vollständigen Rücksprungbestand übernommen.

Abgrenzung:
- Durch die Sicherung wurde kein PROD- oder TEST-App-Code verändert.
- Nicht behauptet wird, dass ausschließlich im ausgelaufenen Chat nach 11:09 Uhr besprochene, aber nie nach Drive geschriebene Inhalte enthalten sind. Diese mögliche Lücke ist gesondert zu rekonstruieren.

Neuer unveränderlicher Rücksprungstand:
- `2026 08 26 14 02_SSV-Meschede_Judo_App_Projektstand.zip`

Nächster Arbeitsschritt:
- Zuerst die mögliche Lücke nach 11:09 Uhr rekonstruieren. Danach anhand der aktuellen Live-Checkliste fortfahren. Bereits dokumentierte Entscheidungen nicht erneut erfragen.

## 67. KONSOLIDIERTER FACH- UND QUELLCODESTAND – 26.08.2026 16:24

Diese Sektion ersetzt für die nachfolgend genannten Themen die früheren Hinweise `noch nicht technisch umgesetzt` bzw. `Umsetzung noch nicht freigegeben`. Der Nutzer hat die Umsetzung ausdrücklich freigegeben und die vollständige Erzeugung der TEST- und PROD-Quellcodedateien angeordnet.

### 67.1 Starthinweise / Glocke
- Neue Admin-Systemeinstellung `Hinweise beim ersten Start als Popup anzeigen`.
- Aktiv: Hinweise werden nach dem Start im Hintergrund geladen und beim ersten Start des Tages wie bisher automatisch geöffnet.
- Inaktiv: Hinweise werden identisch im Hintergrund geladen, öffnen sich aber nicht automatisch. Die Glocke zeigt die offenen Hinweise weiterhin an und ermöglicht die Bearbeitung.
- Personalkartei und Hinweiscenter bleiben für Vorstand/Admin vorgesehen.

### 67.2 Grundprinzip personengebundener Bestätigungslinks
- E-Mail-Links für `Neue Person`, Prüfungsbestätigungen und Inaktivitätsentscheidungen sind empfängerbezogen.
- Ein Link bestätigt genau eine konkrete positive Aktion im Namen des technisch zugeordneten Empfängers. Eine frei umschaltbare öffentliche Verwaltungsseite ist verworfen.
- Alte gemeinsame Direktlinks für Mitgliedschaft und Prüfung dürfen keine Daten mehr verändern. Beim Öffnen wird auf die neue personengebundene Systematik bzw. die angemeldete App verwiesen.
- Wird dieselbe Aktion bereits über einen anderen persönlichen Link erledigt, kann ein später geöffneter Link nichts mehr verändern und zeigt verständlich Ergebnis, bestätigende Person und Zeitpunkt.
- Eine fehlerhafte Bestätigung kann innerhalb der angemeldeten Verwaltungsoberfläche durch Vorstand/Admin korrigiert werden. Dadurch wird kein neuer E-Mail-Link erzeugt und ein bereits verbrauchter Link wird nicht wieder aktiviert.

### 67.3 Fall 1 – Trainer legt im Training eine neue interne Person an
- Die Person wird als `Mitgliedschaft offen` angelegt, sofern sie nicht ausdrücklich als extern erfasst wird.
- Die in `Kommunikation -> Neue Person` konfigurierten Verantwortlichen erhalten jeweils eine eigene Benachrichtigung mit eigenem persönlichen Link zur positiven Mitgliedschaftsbestätigung.
- Die erste wirksame Bestätigung setzt `Mitglied`, speichert Datum/Uhrzeit sowie die bestätigende Person und beendet alle parallelen Bestätigungslinks dieses Vorgangs.
- In der Personalkartei wird `Mitgliedschaft bestätigt am` und `durch` sichtbar geführt.
- Nach der einstellbaren Frist `HINWEIS_MITGLIEDSCHAFT_NACH_TAGEN`, derzeit 42 Tage, erscheint der offene Mitgliedschaftsfall in der Glocke und zusätzlich in der fälligen Systemstatus-/Nachtlauf-Mail.
- In der Glocke und in der Nachtlauf-Mail werden angeboten: `Mitgliedschaft bestätigen`, `Wiedervorlage in 2 Wochen`, `Wiedervorlage in 6 Wochen`.
- Wiedervorlage ist keine Erledigung und keine Mitgliedschaftsbestätigung. Nach Ablauf erscheint der Fall erneut, sofern die Mitgliedschaft weiterhin offen ist.
- Unabhängig davon gilt die 56-Tage-Schutzlogik für `Mitgliedschaft offen`: 56 Kalendertage ohne Training, danach 7-Tage-Löschwarnung. Auch diese Warnung bietet `Mitgliedschaft bestätigen`, `Wiedervorlage in 2 Wochen` und `Wiedervorlage in 6 Wochen`.
- Eine Wiedervorlage beendet den laufenden 7-Tage-Löschvorgang und verhindert eine Löschung während der Wiedervorlage. Nach Ablauf wird bei weiterhin offenem Fall erneut ein neuer 7-Tage-Warnvorgang erzeugt.
- Ohne Bestätigung, neue Teilnahme oder Wiedervorlage erfolgt nach Ablauf des 7-Tage-Vorgangs die Löschung und Anonymisierung der bisherigen Trainingsteilnahmen zu `Schnupperteilnahmen`, sofern keine schützenswerte sonstige personenbezogene Historie die automatische Löschung blockiert.

### 67.4 Fall 2 – Trainer legt einen externen Gast an
- Die Person wird als `Extern` geführt.
- Für Externe wird vorerst keine `Neue Person`-Bestätigungsmail an Vorstand/Admin versendet, da kein Mitgliedschaftsvorgang zu entscheiden ist.
- Namentlich geführte Externe werden nach 56 Kalendertagen ohne weitere Trainingsteilnahme automatisch bereinigt. Trainingsteilnahmen werden davor zu `Externe Gäste` anonymisiert.
- Neue Teilnahme startet die 56-Tage-Frist neu.
- Besteht andere personenbezogene Historie, wird die automatische Komplettlöschung aus Sicherheitsgründen ausgesetzt.

### 67.5 Fall 3 – Vorstand/Admin legt eine neue Person über die Personalkartei an
- Wird `Mitgliedschaft offen` gewählt, gilt derselbe Bestätigungs- und Erinnerungsprozess wie in Fall 1.
- Wird `Mitglied` direkt bei der Anlage gewählt, gilt die Mitgliedschaft unmittelbar als durch den aktuell angemeldeten Vorstand/Admin bestätigt. Datum/Uhrzeit und bestätigende Person werden sofort gespeichert. Es wird keine zusätzliche Bestätigungsmail erzeugt.
- Wird `Extern` gewählt, gilt Fall 2 und es wird keine `Neue Person`-Bestätigungsmail erzeugt.
- Eine seltene Fehlbestätigung kann später in der Personalkartei korrigiert werden. Es wird kein neuer E-Mail-Link erzeugt.

### 67.6 Fall 4 – Prüfung wird angelegt
- Die persönliche Erfolgs-/Prüfungs-E-Mail an den Prüfling bzw. dessen hinterlegte Kontaktadresse bleibt fachlich getrennt von den internen Verwaltungsbestätigungen.
- Die unter `Kommunikation -> Prüfungen` hinterlegten internen Empfänger erhalten jeweils eine eigene E-Mail mit eigenen persönlichen Links für jeden Prüfungsfall.
- Zwei voneinander unabhängige positive Aktionen: `Prüfungsgebühr bezahlt bestätigen` und `In DokuMe übertragen bestätigen`.
- Jede Bestätigung speichert Datum/Uhrzeit und den konkreten Bestätigenden. Die vorhandenen Datenfelder `Zahlung bestätigt am/von` und `DokuMe bestätigt am/von` werden genutzt.
- In der Prüfungsansicht werden für beide Punkte Datum und aufgelöster Name des Bestätigenden angezeigt.
- Ein späterer zweiter Klick auf eine bereits erledigte Aktion ändert nichts und zeigt Ergebnis, Person und Zeitpunkt.
- Rücknahme einer Fehlbestätigung erfolgt ausschließlich innerhalb der angemeldeten App durch Vorstand/Admin. Es wird kein neuer E-Mail-Link erzeugt.
- Nach der einstellbaren Frist `HINWEIS_PRUEFUNG_OFFEN_NACH_TAGEN`, derzeit 21 Tage, erscheint jeder noch unvollständige Prüfungsfall in der Glocke und zusätzlich in der fälligen Systemstatus-/Nachtlauf-Mail. Die Mail weist konkret aus, ob Gebühr, DokuMe oder beides fehlt.
- Der Prüfungsfall ist erst vollständig erledigt, wenn beide Punkte bestätigt sind.

### 67.7 Fall 5 – reguläres Mitglied hört auf zu trainieren
- Nur regulär aktive bestätigte Mitglieder nehmen an der 94-Tage-Prüfung teil.
- `Gelegentlich aktiv`, Externe, `Mitgliedschaft offen` sowie Trainer, Übungsleiter, Trainer-Assistenten, Vorstand und Admin sind von dieser 94-Tage-Automatik ausgeschlossen.
- Maßgeblich sind reine Kalendertage ab letzter Trainingsteilnahme bzw. ab einer Entscheidung `Aktiv lassen`.
- Nach 94 Tagen erzeugt der Nachtlauf einen 7-Tage-Entscheidungsvorgang und versendet je hinterlegtem Inaktivitäts-Ansprechpartner eine eigene Sammelmail mit den für diesen Empfänger individuellen Links.
- Je Person stehen bereit: `Aktiv lassen`, `Gelegentlich aktiv`, `Jetzt inaktiv setzen`.
- `Aktiv lassen` startet die 94-Tage-Frist ab dieser Entscheidung neu.
- `Gelegentlich aktiv` beendet reguläre aktuelle Gruppenzuordnungen, weist die technische Gruppe `Selten da, aber immer wieder gern gesehen` zu und nimmt die Person aus der Automatik.
- `Jetzt inaktiv setzen` archiviert sofort.
- Die erste gültig gespeicherte Entscheidung gewinnt atomar. Alle parallelen Links derselben Person werden sofort wirkungslos.
- Der zweite Empfänger sieht beim späteren Öffnen Ergebnis, bestätigende Person und Zeitpunkt und kann keine abweichende Entscheidung mehr speichern.
- Eine neue Trainingsteilnahme innerhalb der 7-Tage-Frist beendet den offenen Vorgang.
- Ohne Entscheidung und ohne neue Teilnahme erfolgt nach 7 Tagen die automatische Inaktivierung/Archivierung.

### 67.8 Einmaliger Tag-0-Neustart der Inaktivitätsautomatik
- Beim ersten PROD-Lauf des neuen Regelstands werden alle bisherigen laufenden `PERSON_INAKTIV_AUTO`-Vorgänge und Einmallinks beendet.
- Frühere 7-Tage-Fristen werden verworfen.
- Korrekte bestehende Personenstatus, Gruppen, Trainingshistorie und Stammdaten werden nicht zurückgesetzt.
- Danach werden alle aktuell relevanten Personen vollständig nach dem neuen Regelwerk neu bewertet und erforderliche 7-Tage-Vorgänge frisch erzeugt.
- Der Reset ist technisch als einmalige Migration abgesichert und darf nicht bei jedem Nachtlauf wiederholt werden.

### 67.9 Personalkartei – TEST-Funktionen nach PROD übernommen
- Personalkartei server- und frontendseitig nur Vorstand/Admin.
- `Aktuelle Gruppen` direkt anklickbar, Mehrfachauswahl, einschließlich inaktiver Gruppen.
- Nach Änderungen/Löschungen von Gruppenzuordnungen wird die Regel `aktive reguläre Person ohne aktuelle Trainingsgruppe -> inaktiv` auch in den relevanten Korrekturpfaden angewendet, soweit keine definierte Funktionsausnahme greift.
- Aktuelle Graduierung, Trainerqualifikation, Prüfungsberechtigung und Systemrolle bleiben als direkt aufrufbare Detail-/Bearbeitungspfade erhalten.
- Eigene Kontaktdaten sowie Kontakt 1 und Kontakt 2 sind direkt bearbeitbar.
- Extern-Validierung in PROD wurde auf den bereits in TEST verwendeten Wertebestand normalisiert.

### 67.10 Technischer Quellcodestand und Prüfstatus
- TEST und PROD `Code.gs` bestehen die JavaScript-Syntaxprüfung mit Node.
- Die JavaScript-Blöcke beider `Index.html` bestehen nach Entfernung der Google-Template-Tags die Node-Syntaxprüfung.
- In beiden Code-Dateien wurden doppelte Funktionsdefinitionen geprüft: keine gefunden.
- 44 gezielte statische Sollprüfungen zu Popup, Glocke/Wiedervorlage, personengebundenen Links, Auditfeldern, Tag-0, Inaktivitäts-First-Wins, Personalkarteirechten, Extern-Validierung und Nachtlauf-Hinweisen wurden bestanden.
- PROD `Code.gs` SHA-256: `614a60ff52f0ee1574f9599a7674bc3b43419238420bb643097255f055909136`
- PROD `Index.html` SHA-256: `3c9f356d5a950bc127d12bd91404a959db7b97fb9eb16715d2aec90daee450ae`
- TEST `Code.gs` SHA-256: `ded6815014543ea160a741f9986f6edb80d592fc02d95adabea4eac6fac33658`
- TEST `Index.html` SHA-256: `a62c4e19a16f082d6ba451f5122aadc0d143fba9c62f6a636f4db9a568020156`
- `DateRangeDialog.html` bleibt in beiden Umgebungen unverändert.
- Diese Sektion dokumentiert den erzeugten Drive-Quellcodestand. Die tatsächliche Apps-Script-Laufzeit wird erst nach manueller Übernahme der jeweiligen Dateien und erneuter Bereitstellung der Web-App wirksam.

### 67.11 Weiterhin getrennt offen
- P3.2 Anzeige der tatsächlich bereitgestellten PROD-/TEST-Laufzeitstände in der Systemstatus-E-Mail bleibt als eigene technische Aufgabe offen.
- P4.3 `Externer Prüfer` bleibt als eigene technische Aufgabe offen.
- Praktische End-to-End-Prüfungen nach Einspielen der neuen TEST-/PROD-Dateien bleiben erforderlich. Die oben genannten Prüfungen sind statische technische Prüfungen des erzeugten Quellcodes.

## PROD-KORREKTUR – 26.08.2026 16:49 – PERSONALKARTEI / EXTERN / WETTKAMPF-PLATZIERUNG

Praktisch gemeldeter PROD-Fehler:
- Beim Klick auf `Als Extern markieren` erschien `Error: Spalte fehlt: Personen / Mitgliedschaft bestätigt am`.
- Ursache: Die neuen Protokollspalten `Mitgliedschaft bestätigt am` und `Mitgliedschaft bestätigt von` waren bereits im Code als Pflichtspalten vorgesehen, die Runtime-Schema-Version war aber nicht erhöht worden. Dadurch wurde die Schemaergänzung im bestehenden PROD-Sheet nicht ausgelöst.
- Korrektur: Runtime-Schema-Version auf `2026-08-26-03` erhöht. Eine eigene sichere Migration ergänzt ausschließlich fehlende Mitgliedschafts-Protokollspalten in `Personen` und `Archiv_Personen`. Bestehende Daten werden dabei nicht verschoben oder umbeschriftet.

Zusätzlich praktisch festgestellt und korrigiert:
- Die bereits in TEST umgesetzte direkte Bedienlogik der Personalkartei war in PROD nur teilweise vorhanden. PROD übernimmt jetzt die TEST-Darstellung und Bedienung für `Aktuelle Gruppen`, `Aktuelle Graduierung`, `Trainerqualifikation`, `Prüfungsberechtigung`, `Rechterolle im System` sowie Telefon, E-Mail, Kontakt 1 und Kontakt 2. Die jeweils vorgesehenen Bereiche sind direkt anklickbar.
- Die separate Prüfungs-Kachel in der Personalkartei entfällt entsprechend der bereits festgelegten TEST-Systematik. Die Prüfungshistorie wird über `Aktuelle Graduierung` geöffnet.
- VERWORFEN seit 27.08.2026 20:36: Die zwischenzeitlich nach PROD übernommene Platzierungsleiste mit `4./5. Platz` und `6./7. Platz` ist nicht mehr maßgeblich.
- VERWORFEN seit 27.08.2026 20:36: Die zwischenzeitliche PROD-Normalisierung auf `4/5` und `6/7` wurde vollständig zurückgenommen. Maßgeblich sind wieder die Einzelwerte 1 bis 7.
- VERWORFEN seit 27.08.2026 20:36: Auch die Gastlink-Speicherlogik verwendet keine Sammelplatz-Normalisierung mehr, sondern ausschließlich Einzelplätze 1 bis 7.

Technische Prüfung vor Drive-Ablage:
- `Code.gs` PROD und TEST per Node-Syntaxprüfung geprüft.
- Inline-JavaScript in beiden `Index.html` nach Entfernung der Apps-Script-Template-Tags per Node-Syntaxprüfung geprüft.
- Gezielte Sollprüfungen für Schema-Migration, alle sechs direkten Personalkartei-Bereiche, vier Kontaktfelder, Platzierungsdarstellung, Platzierungs-Speicherung, Wertung und Rangliste bestanden.
- TEST-spezifische Funktionen bleiben TEST-spezifisch. Es wurde nicht die vollständige TEST-Datei ungeprüft nach PROD kopiert.

Nächster praktischer Schritt:
- Neue `Code.gs` und `Index.html` in PROD einspielen und Web-App neu bereitstellen.
- PROD neu öffnen. Dadurch läuft die Runtime-Schema-Migration einmalig und ergänzt die beiden fehlenden Personenspalten.
- Danach praktisch prüfen: `Als Extern markieren`, direkte Personalkartei-Bereiche und Wettkampf-Platzierungsleiste.



## PROD-SCHEMAFEHLER MITGLIEDSCHAFTSBESTÄTIGUNG – 26.08.2026 17:10

### Praktischer Befund
- PROD zeigte beim Versuch „Als Extern markieren“ weiterhin: `Spalte fehlt: Personen / Mitgliedschaft bestätigt am`.
- Nutzer-Screenshot vom 26.08.2026 bestätigt den Fehler nach erneuter PROD-Bereitstellung.

### Geprüfte Ursache
- Im echten PROD-Blatt `Personen` fehlte `Mitgliedschaft bestätigt am` tatsächlich.
- Die Spalte direkt hinter `Zuletzt geändert am` war fälschlich als `Mitgliedschaft bestätigt von` beschriftet, enthielt aber weiterhin die historischen Werte von `Zuletzt geändert von` wie `MIGRATION`.
- Ursache im Code: `ensureRuntimeSchemaFast_()` führte bei einem neuen Laufzeitschema `ensurePersonSchema_()` nicht aus. Neue Personenspalten konnten deshalb beim normalen Web-App-Start nicht zuverlässig ergänzt werden.
- Zusätzlich durfte `Archiv_Personen` nicht über ein bloßes Überschreiben der Kopfzeile auf ein erweitertes Schema gebracht werden, weil dadurch bei vorhandenen Archivzeilen die Bedeutung bestehender Spalten verschoben würde.

### Korrektur
- PROD `Personen`: falsche Überschrift auf `Zuletzt geändert von` zurückgesetzt.
- PROD `Personen`: `Mitgliedschaft bestätigt am` und `Mitgliedschaft bestätigt von` direkt hinter `Mitgliedschaft bestätigt` als echte neue Spalten eingefügt. Bestehende Daten wurden dadurch nur verschoben, nicht überschrieben.
- TEST `Personen`: dieselben beiden Spalten an derselben fachlichen Position eingefügt.
- TEST `Archiv_Personen`: dieselben beiden Spalten ebenfalls sicher eingefügt. Vorhandene Archivdatensätze bleiben spaltenrichtig.
- PROD `Archiv_Personen` war bereits leer und mit den korrekten neuen Überschriften vorhanden.
- Laufzeitcode PROD und TEST: `RUNTIME_SCHEMA_VERSION` auf `2026-08-26-03` erhöht.
- `ensureRuntimeSchemaFast_()` ruft künftig `ensurePersonSchema_()` ausdrücklich auf.
- Neue Schutzfunktion ergänzt, die die beiden Mitgliedschafts-Protokollspalten sicher einfügt und den konkret festgestellten Legacy-Fehlheader repariert.
- `Archiv_Personen` wird künftig separat und datenerhaltend erweitert statt seine komplette Kopfzeile ungeprüft umzuschreiben.

### Prüfung
- PROD- und TEST-Code mit Node-Syntaxprüfung geprüft: bestanden.
- Direkter PROD-Datenbestand vor Korrektur geprüft und Fehlheader samt `MIGRATION`-Werten eindeutig nachgewiesen.
- Praktischer PROD-Retest `Als Extern markieren` bleibt unmittelbar als nächster Test offen.


## HEADERCACHE-HOTFIX – 26.08.2026 17:24

### Praktischer Befund
- Der Fehler `Spalte fehlt: Personen / Mitgliedschaft bestätigt am` trat nach korrekter Schema-Reparatur und erneuter TEST-/PROD-Bereitstellung weiterhin auf.
- Direkte Prüfung der echten Sheets bestätigte gleichzeitig, dass `Personen` und `Archiv_Personen` die Spalten `Mitgliedschaft bestätigt am` und `Mitgliedschaft bestätigt von` inzwischen korrekt enthalten.
- PROD meldete als tatsächlich verwendeten App-Stand `PROD 20260826-1717`. TEST meldete `TEST 20260826-1717`. Damit war ausgeschlossen, dass nur eine alte Bereitstellung oder ein anderes Sheet getestet wurde.

### Geprüfte Ursache
- `sheetHeaderState_()` cached Tabellenüberschriften bis zu sechs Stunden unter `HDR_V2_*`.
- Der Cache aus der Zeit vor der Schemaerweiterung enthielt für `Personen` noch keinen Eintrag `Mitgliedschaft bestätigt am`.
- Nach der realen Korrektur des Sheets wurde dieser alte Headercache weiterverwendet. Deshalb konnten Schreib-/Lesewege weiterhin fälschlich `Spalte fehlt` melden, obwohl die Spalte physisch vorhanden war.
- Das erklärt das identische Verhalten in TEST und PROD nach dem Einspielen des 17:10-Standes.

### Korrektur
- Headercache-Version von `HDR_V2` auf `HDR_V3` angehoben. Damit werden alle alten Headercache-Einträge sofort technisch getrennt und nicht weiterverwendet.
- `sheetHeaderState_()` akzeptiert einen lokalen oder gemeinsamen Cacheeintrag künftig nur noch, wenn darin alle aktuell für das betreffende Blatt definierten Pflichtspalten vorhanden sind.
- Fehlt eine Pflichtspalte nur im Cache, wird der Cacheeintrag verworfen und die reale Kopfzeile frisch aus dem Sheet gelesen.
- Damit ist die Headerprüfung bei künftigen Schemaerweiterungen selbstheilend und nicht mehr bis zu sechs Stunden von einem veralteten Cache abhängig.
- TEST und PROD erhalten dieselbe Korrektur. `Index.html` ist nicht betroffen und bleibt unverändert.

### Prüfung
- Beide korrigierten `Code.gs` wurden als JavaScript syntaktisch geprüft: bestanden.
- Echte Header in TEST und PROD vor dem Code-Hotfix nochmals direkt geprüft: `Mitgliedschaft bestätigt am` und `Mitgliedschaft bestätigt von` sind vorhanden.
- Praktischer Retest nach erneuter Bereitstellung des 17:24-Code-Standes bleibt offen.

## 68. PROJEKTSTAND GESICHERT – 26.08.2026 17:40

Anlass:
- Nutzer ordnet ausdrücklich an, den aktuellen Stand hier zu sichern und die gesamte verbleibende praktische Prüfung in einem neuen Chat fortzusetzen.
- In diesem Chat erfolgt nach dieser Sicherung keine weitere Funktionsprüfung und keine weitere fachliche Änderung.

Praktisch bestätigter Stand nach dem Headercache-Hotfix:
- PROD: `Als Extern markieren` wurde praktisch erfolgreich bestätigt. Der frühere Fehler `Spalte fehlt: Personen / Mitgliedschaft bestätigt am` trat auf diesem Schreibweg nicht mehr auf.
- TEST: eine offene Mitgliedschaft wurde praktisch erfolgreich bestätigt. Der frühere Spaltenfehler trat auf diesem Schreibweg nicht mehr auf.
- PROD: eine Mitgliedschaftsbestätigung konnte nicht praktisch geprüft werden, weil aktuell kein echter geeigneter Datensatz mit dieser Möglichkeit vorhanden ist. Das ist kein Fehlbefund. Der Test bleibt offen und darf nicht durch Manipulation eines echten Mitglieds erzwungen werden.
- TEST: `Als Extern markieren` wurde nach dem finalen Hotfix noch nicht praktisch bestätigt.

Aktueller Quellcodestand:
- PROD `Code.gs`: Stand 26.08.2026 17:24.
- PROD `Index.html`: Stand 26.08.2026 16:49.
- TEST `Code.gs`: Stand 26.08.2026 17:24.
- TEST `Index.html`: Stand 26.08.2026 16:49.
- Beide `DateRangeDialog.html` unverändert.
- PROD und TEST verwenden `RUNTIME_SCHEMA_VERSION = '2026-08-26-03'` und Headercache `HDR_V3`.

Prüfauftrag für den nächsten Chat – nichts davon als bereits bestanden behandeln:

A. Unmittelbare Regressionstests der heutigen Änderungen:
1. TEST: Person sicher als extern markieren und Ergebnis in Personalkartei, Gruppen und Datenbestand prüfen.
2. PROD: Mitgliedschaftsbestätigung nur dann praktisch prüfen, wenn ein echter sachlich geeigneter offener Fall vorhanden ist. Keine künstliche Änderung eines echten Mitglieds nur für den Test.
3. PROD: direkte Personalkartei-Bereiche vollständig prüfen. Dazu `Aktuelle Gruppen`, `Aktuelle Graduierung`, `Trainerqualifikation`, `Prüfungsberechtigung`, `Rechterolle im System`, Telefon, E-Mail, Kontakt 1 und Kontakt 2.
4. PROD: neue Wettkampf-Platzierungsdarstellung und Speichern von `1.`, `2.`, `3.`, `4./5.`, `6./7.` und `ohne Platzierung` prüfen.
5. Mitgliedschaftsbestätigung auf sichtbare Dokumentation von Datum/Uhrzeit und bestätigender Person prüfen.
6. Prüfungen auf personengebundene Bestätigungen `Prüfungsgebühr bezahlt` und `In DokuMe übertragen` prüfen. Erster gültiger Abschluss muss gewinnen. Ein späterer Link darf nichts mehr ändern und muss verständlich anzeigen, wer wann bestätigt hat.
7. Korrektur einer versehentlichen Bestätigung innerhalb der angemeldeten App prüfen. Es darf dadurch kein neuer Bestätigungslink erzeugt und kein alter Link reaktiviert werden.
8. Neue-Person-Mail prüfen. Interne neue Person bekommt personengebundene Bestätigungslinks. Extern angelegte Person erzeugt keine Neue-Person-Mail.
9. Wiedervorlagen `2 Wochen` und `6 Wochen` bei offenen Mitgliedschaften sowohl in der Glocke als auch im Nachtlauf-/Systemstatusweg prüfen. Dasselbe Prinzip bei der 56-Tage-Schutzwarnung prüfen.
10. Prüfungshinweise nach der einstellbaren Frist sowohl in der Glocke als auch im Nachtlauf-/Systemstatusweg prüfen.
11. Systemeinstellung `Hinweise beim ersten Start als Popup anzeigen` in beiden Zuständen prüfen. Hintergrundladen und Glocke müssen in beiden Zuständen funktionieren.
12. Einmaligen `Tag 0`-Neustart der Inaktivitätsautomatik einschließlich alter Linkinvalidierung, neuer 7-Tage-Vorgänge und personengebundener First-Wins-Links kontrolliert prüfen.

B. Noch offene Befunde aus der Systemprüfung, nach Priorität abarbeiten:

HOCH / kritisch zu testen:
1. Regel `aktive reguläre Person ohne aktuelle Trainingsgruppe -> inaktiv` in allen relevanten Übergängen praktisch prüfen. Besonders Extern -> Mitglied, Gelegentlich aktiv -> regulär aktiv und Wegfall einer Funktionsträger-Ausnahme.
2. Rechte der Personalkartei praktisch prüfen. Nur Vorstand/Admin dürfen die allgemeine Personalkartei öffnen und bearbeiten. Trainer und Sammelzugang dürfen keinen allgemeinen Zugriff erhalten.
3. Schutz der 94-Tage-Automatik für `Gelegentlich aktiv` und Funktionsträger praktisch prüfen. Trainer, Übungsleiter, Trainer-Assistent, Vorstand und Admin dürfen nicht fälschlich in den normalen Inaktivitätsvorgang geraten.
4. Web-App-Basis und alte Aktionslinks prüfen. Alte oder bereits erledigte Links dürfen keine neuen Änderungen auslösen.
5. Die wiederhergestellten PROD-Wettkampffunktionen `Meldeliste anzeigen`, `Meldeliste per E-Mail versenden` und `Handliste als PDF` praktisch prüfen.

MITTEL:
6. Die im PROD-Datenbestand festgestellten 11 aktuell inaktiven Personen im operativen Blatt `Personen` prüfen und fachlich entscheiden, ob und wie sie nach `Archiv_Personen` überführt werden. Keine pauschale Datenverschiebung ohne Prüfung.
7. Gleichzeitige Statuswechsel am selben Kalendertag prüfen. Konkreter TEST-Fall `P00108` mit widersprüchlichem Zeitraum bleibt Referenz.
8. Extern-Validierung und alle Schreibwege rund um `Extern` nach der Normalisierung praktisch gegentesten.

PERFORMANCE:
9. Inaktivitätsprüfung mit realistischer TEST-Datenmenge erneut messen. Bisher typischerweise ungefähr 20–26 Sekunden, einmal rund 73 Sekunden. Funktion und Wartezeit getrennt bewerten.

TEST-DATENHYGIENE / einfache Datenprüfung:
10. Doppelte TEST-Personen-ID `P00140` gezielt prüfen und bereinigen, sofern weiterhin vorhanden. PROD hatte keine doppelte Personen-ID.
11. Auffälligen Wettkampf-Testwert im Rahmen P1.8 gezielt bewerten. Historische numerische Platzierungen 1–7 sind nicht automatisch fehlerhaft.

Weitere fachlich offene Punkte, die nicht mit einem bestandenen Test verwechselt werden dürfen:
- P3.2 tatsächliche bereitgestellte PROD-/TEST-Laufzeitstände in der Systemstatus-E-Mail technisch umsetzen und prüfen.
- P4.3 Auswahl `Externer Prüfer` mit verpflichtendem Freitextnamen technisch umsetzen und prüfen.
- P4.4 Wettkampfvorbereitung soll vor Versand Teilnehmer mit fehlender E-Mail sichtbar machen.

Testvorgehen im neuen Chat:
- Vor jedem praktischen Test kurz und eindeutig sagen, welche Funktion, welcher Datenbestand und welches erwartete Ergebnis geprüft werden.
- Nur einen konkreten Testschritt gleichzeitig an den Nutzer geben.
- Keine fachfremden Tests einschieben.
- Ergebnisse sofort als bestanden, fehlgeschlagen, nicht testbar oder vertagt dokumentieren.
- Bei Fehlern zuerst Ursache in Code, Sheet, Datenbestand und Cache eingrenzen. Keine Reparatur auf Verdacht.
- Nach Abschluss der offenen Testserie Befunde neu priorisieren und erst dann weitere Umsetzung vorschlagen.

Sicherungsdatei:
- `2026 08 26 22 46_SSV-Meschede_Judo_App_Projektstand.zip`
- PROD-Snapshot SHA-256: `3e4702e7bf0ae5cacbdbd3c641b21bc6f74e7aceb984c16e6ec7a2b989bf9f15`
- Checklisten-Snapshot SHA-256: `761624c81b6be86171e1b91745932ce3471b71d7f5fcfbee74d8576791c66960`
- PROD Code SHA-256: `0b0b629c398159e5f370de64a73a0b5b69efdb28c0984eecfc5cc06d15650c2b`
- PROD Index SHA-256: `fa6a3f539c1e48a4afc88527dd3152dec5112fdab4c1d07b4015b6a4df704e1f`
- TEST Code SHA-256: `8d205710dd5bff164924cc510a9021edf0e81a33414566deb2cfdc87de341ad2`
- TEST Index SHA-256: `ec4399fa3478de7bc666dde6727c99a35a1bf3274cd16f2ed815943ad85c1323`

Nächster Arbeitsschritt:
- Neuer Chat. Dort ausschließlich die noch offenen praktischen Tests und Risikoprüfungen systematisch abarbeiten. Keine neue Funktion vorziehen, solange die aktuelle Teststrecke nicht geklärt ist.

## 69. PRAKTISCHE RESTTESTUNG – 26.08.2026 ABENDS

Anlass:
- Die nach Abschnitt 68 offenen praktischen Tests wurden am Abend des 26.08.2026 fortgesetzt.
- Während der Testführung wurden mehrere zuvor zu breit oder redundant formulierte Prüfschritte korrigiert.
- Dauerhafte neue Prüfregel: Vor jedem Einzelschritt ist zu prüfen, ob gegenüber dem bereits belegten Zustand überhaupt neue Erkenntnis entstehen kann. Unveränderte Wiederholungsläufe oder bereits durch Screenshots belegte Kontrollen werden nicht erneut verlangt.
- Dauerhafte PROD-Regel: In PROD werden keine künstlichen Testdaten oder Teständerungen erzeugt. Schreibende PROD-Prüfungen erfolgen nur an ohnehin real anstehenden legitimen Vorgängen oder nach ausdrücklich separater Freigabe.

### 69.1 PROD Tag-0-Neustart Inaktivitätsautomatik – P6.9 weiter offen
Praktisch geprüft:
- PROD-App startet normal.
- Systemeinstellung `Inaktivitätsprüfung nach Tagen` steht korrekt auf `94`.
- In `Linkverwaltung` existierten vor dem nächsten Nachtlauf weiterhin aktive `PERSON_INAKTIV_AUTO`-Vorgänge vom 24./25.08.2026, unter anderem mit Gültigkeit bis 31.08./01.09.2026.
- Ein solcher alter Link wurde vom Nutzer für die Nachkontrolle nach dem Nachtlauf gesichert.
- Ein manueller PROD-Einzellauf ist nicht vorgesehen. Die interne Funktion `runInactiveMemberAutomation_` ist wegen des abschließenden Unterstrichs bewusst nicht über die Apps-Script-Funktionsauswahl startbar.
- Ein kompletter PROD-Nachtlauf wurde nicht künstlich manuell ausgelöst, weil dadurch weitere produktive Nachtlaufblöcke, Backups und Mails angestoßen würden.

Offen:
- Nach dem regulären PROD-Nachtlauf am 27.08.2026 ab ca. 02:30 prüfen:
  1. bisherige alte `PERSON_INAKTIV_AUTO`-Links sind ungültig,
  2. Tag-0-Neuberechnung hat neue 7-Tage-Vorgänge nach aktuellem 94-Tage-Regelwerk erzeugt,
  3. Empfänger-/Einmallinklogik entspricht dem freigegebenen First-Wins-Konzept.
- P6.9 bleibt deshalb `In Arbeit`.

### 69.2 TEST 94-Tage-Automatik – P1.3 praktisch vollständig bestanden
Praktische Befunde:
- Manueller TEST-Lauf `Inaktivitätsprüfung jetzt ausführen` erzeugte neue `PERSON_INAKTIV_AUTO`-Zeilen vom 26.08.2026 mit Gültigkeit bis 02.09.2026.
- Ein unmittelbar wiederholter Lauf erzeugte keine Doppelvorgänge: 0 neue Fristen, 0 archiviert, 0 Externe gelöscht, 0 Mitgliedschaftswarnungen.
- Aktion `Aktiv lassen` wurde korrekt gespeichert. Der rote Inaktivitäts-Countdown verschwand.
- Aktion `Gelegentlich aktiv` wurde korrekt gespeichert.
- Ein zweiter bereits erzeugter Link derselben Person zeigte korrekt `Vorgang bereits erledigt`. First-Wins ist damit praktisch bestätigt.
- Aktion `Sofort inaktiv` archivierte die Testperson korrekt. Sie war anschließend nur noch über `Inaktive anzeigen` sichtbar.
- Für den 7-Tage-Endfall wurde bei TEST-Person P00036 (Jan Krick) die Gültigkeit aller aktiven `PERSON_INAKTIV_AUTO`-Links kontrolliert auf den Vortag gesetzt. Der nächste manuelle Lauf meldete `1 archiviert`; Jan Krick war danach nur noch als inaktiv sichtbar.
- P1.3 ist damit fachlich vollständig praktisch bestanden und in der Live-Checkliste auf `Erledigt` gesetzt.

### 69.3 Neuer Fehler: öffentlicher Inaktivitätslink endet nach erfolgreicher Entscheidung im Weißbild – P6.12
Praktisch reproduziert:
- Nach `Aktiv lassen` erschien nur für einen sehr kurzen Moment eine Erfolgsmeldung mit Bezug auf die 94 Tage. Danach war die Seite vollständig weiß.
- Dasselbe Verhalten trat nach `Gelegentlich aktiv` auf.
- Die gewählte Aktion selbst wurde jeweils korrekt gespeichert. Der Fehler betrifft die Abschlussdarstellung des öffentlichen Links, nicht die fachliche Speicherung.
- Ein bereits erledigter Zweitlink zeigte dagegen korrekt und dauerhaft `Vorgang bereits erledigt`.

Bewertung:
- Neuer offener Hoch-Punkt P6.12.
- Soll: Nach jeder öffentlichen Entscheidung muss das Ergebnis dauerhaft sichtbar bleiben. Kein Weißbild und kein Anlass für den Nutzer, wegen fehlender Rückmeldung erneut zu klicken.

### 69.4 Performance Inaktivitätsprüfung – P6.6 weiter offen
- Der kontrollierte TEST-Lauf für den simulierten Fristablauf benötigte `42,4 s`.
- Funktional war das Ergebnis korrekt.
- Die Laufzeit liegt deutlich über dem bisher typischen Bereich von etwa 20–26 Sekunden, aber unter dem früheren Ausreißer von rund 73 Sekunden.
- Funktion und Performance sind getrennt zu bewerten. P6.6 bleibt offen.

### 69.5 Schutzstatus `Gelegentlich aktiv` und Funktionsträger
- `Gelegentlich aktiv` blieb auch nach mehreren manuellen TEST-Inaktivitätsläufen unverändert. Dieser Schutz ist praktisch bestätigt.
- Nutzer stellt klar: `Gelegentlich aktiv` ist fachlich zwingend mit der technischen Gruppe `Selten da, aber immer wieder gern gesehen` gekoppelt. Eine Person mit diesem Status ohne diese Gruppe ist kein gültiger Sollzustand.
- Für Trainer/Übungsleiter/Assistent/Vorstand/Admin stand kein geeigneter TEST-Fall mit mindestens 94 Tagen ohne Training zur Verfügung. Dieser Rollen-Schutz ist deshalb aktuell nicht praktisch testbar und wird nicht künstlich in PROD erzeugt.

### 69.6 Regel `regulär aktiv ohne Trainingsgruppe -> inaktiv` – P6.1 als echte Lücke bestätigt
Praktischer TEST-Fall:
- Willi Mensch war zunächst `extern`.
- `Extern` wurde entfernt und die Person als regulär aktiv gespeichert, ohne eine Trainingsgruppe zuzuweisen.
- Ergebnis: Willi Mensch blieb regulär `aktiv` und gruppenlos.

Bewertung:
- Damit ist die bereits aus der Systemprüfung bekannte Lücke P6.1 praktisch bestätigt.
- Dies ist keine bestandene Funktion.
- Der zuvor in Abschnitt 68 als möglicher Testfall genannte Übergang `Gelegentlich aktiv -> regulär aktiv` war fachlich nicht besprochen und technisch nicht implementiert. Er darf deshalb nicht als vorhandene Sollfunktion vorausgesetzt oder getestet werden.
- Fachlich bleibt lediglich verbindlich: Ein regulär aktiver Nicht-Funktionsträger darf nicht gruppenlos zurückbleiben.
- Der konkrete Übergang zurück von `Gelegentlich aktiv` zu regulär aktiv muss erst fachlich definiert werden, bevor daraus ein Testfall wird.

### 69.7 Personalkartei-Rechte – P6.2 teilweise praktisch bestanden
Praktisch geprüft:
- Normaler Trainerzugang: Kachel `Personalkartei` nicht sichtbar.
- Sammelzugang `Wer bin ich?`: Kachel `Personalkartei` nicht sichtbar.

Bewertung:
- Frontend-Sichtbarkeit für beide unberechtigten Zugangstypen bestanden.
- P6.2 bleibt `In Arbeit`, weil serverseitige Rechtepfade bzw. direkte Aufrufe noch gesondert geprüft werden müssen.

### 69.8 TEST `Als extern markieren` praktisch bestanden
- Willi Mensch wurde nach dem vorstehenden P6.1-Test wieder über `Als extern markieren` auf `Extern` gesetzt.
- Der Vorgang wurde korrekt gespeichert und der Ausgangszustand damit wiederhergestellt.
- Der nach Abschnitt 68 noch offene unmittelbare Regressionstest `TEST: Als Extern markieren` ist bestanden.
- P2.8 bleibt insgesamt `In Arbeit`, weil die übrigen direkten Statusaktionen noch nicht vollständig praktisch geprüft wurden.

### 69.9 Offene Mitgliedschaft / 56-Tage-Schutz
- Der Versuch, diesen Punkt am Abend erneut zu prüfen, wurde als redundant abgebrochen.
- P1.6 war bereits vor diesem Testabend vollständig praktisch bestanden und enthält Warnung, 7-Tage-Frist, neue Teilnahme, Mitgliedschaftsbestätigung und Löschschutz.
- Ein unveränderter erneuter Inaktivitätslauf hätte gegenüber diesem bereits belegten Zustand keinen neuen Erkenntnisgewinn geliefert.
- Separat offen bleibt P6.10: Wiedervorlage 2/6 Wochen und Systemstatus-/Glockenweg.

### 69.10 PROD-Personalkartei nur lesend geprüft
Praktische Stichprobe Benedikt Kasper:
- `Aktuelle Gruppen` zeigte korrekt `Erwachsene`.
- Bearbeitungsansicht lud die bestehenden Kontaktdaten.
- Angezeigt wurden unter anderem Graduierung `7. Kyu`, Trainerqualifikation `Keine Funktion`, Prüfberechtigung `nicht berechtigt` sowie das Rollenfeld.
- In PROD wurde bewusst nichts gespeichert oder künstlich verändert.

Bewertung:
- Reine Anzeige/Ladefähigkeit dieser Personalkartei-Bereiche ist in der Stichprobe unauffällig.
- Die vollständigen direkten Bearbeitungswege P2.1 bis P2.7 sind dadurch nicht pauschal bestanden.
- Nutzerregel ab jetzt ausdrücklich: PROD enthält keine Testdaten und wird nicht für künstliche Schreibtests verwendet.

### 69.11 Nächster sinnvoller Teststand
Am 26.08.2026 spätabends wurde die Testserie bewusst beendet.

Priorität für den nächsten Arbeitsstart:
1. Nach dem regulären Nachtlauf zuerst P6.9 Tag-0-Neustart in PROD abschließen. Dabei den bereits gesicherten alten Link und die neu erzeugten `PERSON_INAKTIV_AUTO`-Vorgänge prüfen.
2. Danach in TEST mit P1.8 Wettkampf-Platzierungsleiste fortsetzen: Darstellung, Speichern/Wiederöffnen und Altwerte 4/5 bzw. 6/7. Keine künstlichen Wettkampf-Schreibtests in PROD.
3. Anschließend P6.12 Weißbild nach öffentlicher Inaktivitätsentscheidung eingrenzen und erst nach ausdrücklicher Freigabe korrigieren.

Nicht erneut prüfen:
- P1.3 94-Tage-Entscheidungen und automatische 7-Tage-Archivierung sind bestanden.
- P1.6 56-Tage-/offene-Mitgliedschaft-Grundlogik ist bereits bestanden.
- Frontend-Verbergen der Personalkartei bei Trainer- und Sammelzugang ist praktisch bestätigt.
- TEST `Als extern markieren` ist praktisch bestätigt.

## 70. PROJEKTSTAND GESICHERT – 26.08.2026 22:46

Anlass:
- Nutzer beendet die heutige Testung wegen der späten Uhrzeit und ordnet ausdrücklich `Projektstand erzeugen` an.
- Dieser Projektstand konsolidiert ausschließlich den tatsächlich erreichten Prüf- und Dokumentationsstand. Seit der ZIP von 17:40 wurde kein PROD- oder TEST-Laufzeitcode verändert.

Seit Abschnitt 68 neu dokumentiert:
- P1.3 94-Tage-Automatik vollständig praktisch bestanden einschließlich First-Wins und automatischer Archivierung nach Fristablauf.
- Neuer Hoch-Befund P6.12: öffentlicher Inaktivitätslink endet nach erfolgreicher Entscheidung im Weißbild, obwohl die Aktion korrekt gespeichert wird.
- P6.6 letzter gemessener TEST-Lauf: 42,4 s, funktional korrekt, Performance weiter offen.
- Schutz `Gelegentlich aktiv` praktisch bestätigt; Status ist zwingend mit `Selten da, aber immer wieder gern gesehen` gekoppelt.
- Funktionsträger-Schutz mangels geeignetem TEST-Fall nicht vollständig praktisch testbar.
- P6.1 praktisch als Lücke bestätigt: Extern → Mitglied kann regulär aktiv ohne Trainingsgruppe zurücklassen.
- P6.2 Frontend praktisch teilweise bestanden: Personalkartei bei normalem Trainer und Sammelzugang nicht sichtbar; serverseitige Rechtewege bleiben offen.
- TEST `Als extern markieren` praktisch bestanden und Testperson in Ausgangszustand zurückgeführt.
- PROD-Personalkartei nur lesend stichprobenartig geprüft. Keine künstlichen PROD-Schreibtests.
- P6.9 Tag-0-Neustart bleibt bis zum regulären Nachtlauf 27.08.2026 offen. Ein vorher aktiver alter Link ist für den Nachtest gesichert.
- Redundante Wiederholung eines bereits belegten unveränderten Tests ist künftig ausdrücklich unzulässig.
- Neue dauerhafte Regel: PROD enthält keine künstlichen Testdaten. Schreibende PROD-Prüfungen nur an real anstehenden Vorgängen oder nach ausdrücklicher separater Freigabe.

Live-Checkliste:
- P1.3 auf `Erledigt` gesetzt.
- P2.8 mit bestandenem TEST-Extern-Teiltest aktualisiert.
- P6.1 mit dem real bestätigten Extern→Mitglied-Gruppenlos-Befund aktualisiert.
- P6.2 auf `In Arbeit` mit bestandenem Frontend-Rechtetest aktualisiert.
- P6.6 um Messwert 42,4 s ergänzt.
- P6.9 auf `In Arbeit` und Nachtlauf-Nachprüfung konkretisiert.
- P6.12 neu als Hoch-Punkt angelegt.

Dauerhafte Regeländerungen in `Masterprompt.txt`:
- Keine künstlichen Testdaten oder rein testbedingten Schreibvorgänge in PROD.
- Vor jedem Prüfschritt zwingend prüfen, ob er gegenüber dem bereits belegten Zustand neue Erkenntnis erzeugen kann.
- Fehlt ein geeigneter TEST-Fall, wird er als nicht praktisch testbar dokumentiert, statt PROD zu manipulieren oder nicht besprochene Sollfunktionen zu erfinden.

Aktueller Quellcodestand unverändert:
- PROD `Code.gs`: Stand 26.08.2026 17:24.
- PROD `Index.html`: Stand 26.08.2026 16:49.
- TEST `Code.gs`: Stand 26.08.2026 17:24.
- TEST `Index.html`: Stand 26.08.2026 16:49.
- Beide `DateRangeDialog.html` unverändert.
- PROD und TEST verwenden `RUNTIME_SCHEMA_VERSION = '2026-08-26-03'` und Headercache `HDR_V3`.

Sicherungsdatei:
- `2026 08 26 22 46_SSV-Meschede_Judo_App_Projektstand.zip`
- PROD-Snapshot SHA-256: `3e4702e7bf0ae5cacbdbd3c641b21bc6f74e7aceb984c16e6ec7a2b989bf9f15`
- Checklisten-Snapshot SHA-256: `88072daf7fad9641660a039e6cc4e0d307e43e8a8160dedad1789f35ed8f7ee5`
- PROD Code SHA-256: `0b0b629c398159e5f370de64a73a0b5b69efdb28c0984eecfc5cc06d15650c2b`
- PROD Index SHA-256: `fa6a3f539c1e48a4afc88527dd3152dec5112fdab4c1d07b4015b6a4df704e1f`
- TEST Code SHA-256: `8d205710dd5bff164924cc510a9021edf0e81a33414566deb2cfdc87de341ad2`
- TEST Index SHA-256: `ec4399fa3478de7bc666dde6727c99a35a1bf3274cd16f2ed815943ad85c1323`

Nächster Arbeitsschritt:
1. Nach dem regulären PROD-Nachtlauf vom 27.08.2026 zuerst P6.9 kontrollieren: alter Link ungültig, neue Tag-0-Vorgänge, Empfänger-/First-Wins-Logik.
2. Danach ausschließlich in TEST P1.8 Wettkampf-Platzierungsleiste weiterprüfen.
3. P6.12 Weißbild technisch eingrenzen und erst nach ausdrücklicher Freigabe korrigieren.

Liga:
- vollständig unberührt.


## 71. KRITISCHER LINK-HOTFIX UND SAMMELMAIL VORBEREITET – 27.08.2026 05:38

### 71.1 Praktischer PROD-Nachtlauf 27.08.2026
Der reguläre PROD-Nachtlauf hat den fachlichen Tag-0-Neustart grundsätzlich ausgelöst.

Praktisch bestätigt durch den Nutzer:
- Die 94-Tage-Fälle kamen wie gewünscht gemeinsam in einer E-Mail.
- Die 56-Tage-Fälle wurden dagegen unerwünscht jeweils als einzelne E-Mail versendet. Jede dieser Einzelmails enthielt drei persönliche Aktionslinks.
- Beim Öffnen beliebiger Aktionslinks aus den erzeugten E-Mails erschien auf dem iPhone die Google-Drive-Meldung `Datei kann derzeit nicht geöffnet werden`.

Verbindliche Präzisierung des Nutzers:
- Sämtliche Personalhinweise und überfälligen Prüfungshinweise eines Laufs werden pro Empfänger in genau einer Sammel-E-Mail gebündelt.
- `Prüfungshinweis` bedeutet ausschließlich: Eine Prüfung ist seit der konfigurierten Frist noch nicht vollständig abgeschlossen, weil `DokuMe` und/oder `Prüfungsgebühr` offen sind.
- Normale unmittelbare Prüfungs-Kommunikation wie neue Prüfung oder Ergebnis-Mail gehört nicht in diese nächtliche Sammelmail.
- Mehrere 56-Tage-Fälle dürfen keine Einzelmails mehr erzeugen.

### 71.2 Ursache des Linkfehlers technisch bestätigt
Live-PROD `Linkverwaltung` zeigte für sämtliche am 27.08.2026 neu erzeugten Personen- und Mailaktionslinks weiterhin die Deployment-Basis
`https://script.google.com/macros/s/AKfycbwtAlXov_kNyj680ZzCZmRu2JQJwa_VX_s7NaggI2E81_GArA1F/exec`.

Ursache im bisherigen Code:
- `webAppBaseUrl_()` bevorzugte bei jedem Lauf `ScriptApp.getService().getUrl()`.
- Der Nachtlauf konnte dadurch die zuvor beim echten Öffnen registrierte aktuelle `/exec`-Adresse mit einer veralteten Deployment-Adresse überschreiben.
- Der gestern begonnene Schutz war deshalb technisch unvollständig.

Korrektur in PROD und TEST:
- Die beim echten Web-App-Aufruf registrierte und validierte Adresse `CURRENT_WEB_APP_URL_V1` ist ab jetzt die primäre Quelle.
- `ScriptApp.getService().getUrl()` ist nur noch Fallback, wenn keine gültige gespeicherte Adresse vorhanden ist.
- Sämtliche relevanten URL-Erzeuger wurden auf die zentrale `webAppBaseUrl_()`-Auflösung vereinheitlicht.
- In jeder Codefassung verbleibt genau eine direkte Verwendung von `ScriptApp.getService().getUrl()`, ausschließlich als kontrollierter Fallback innerhalb `webAppBaseUrl_()`.

### 71.3 Nächtliche Personal-/Prüfungshinweise auf Sammelmail umgestellt
PROD und TEST `Code.gs` wurden auf denselben Fachstand gebracht.

Die neue Sammellogik bündelt pro konfiguriertem Empfänger und Lauf:
- neue 94-Tage-Inaktivitätsfälle,
- neue 56-Tage-Löschwarnungen bei offener Mitgliedschaft,
- fällige Wiedervorlagen zur offenen Mitgliedschaft,
- überfällige Prüfungen mit offenem DokuMe und/oder offener Prüfungsgebühr.

Regeln:
- Ein Empfänger, der für mehrere Bereiche zuständig ist, erhält eine gemeinsame E-Mail mit allen für ihn bestimmten Punkten.
- Persönliche Aktionslinks bleiben empfängergebunden.
- Eine 56-Tage-Löschwarnung verdrängt für denselben Fall den allgemeinen Mitgliedschaftshinweis, damit kein Doppelhinweis entsteht.
- Bereits versendete Zyklen werden intern protokolliert, damit nicht bei jedem Nachtlauf dieselbe Sammelmail erneut entsteht.
- Fehlschläge beim Mailversand bleiben wiederholbar.
- Personal-/Prüfungshinweise wurden aus der normalen Systemstatus-Mail entfernt, damit dieselben Punkte nicht doppelt per E-Mail erscheinen.
- Auch die TEST-Systemstatus-Simulation zeigt diesen separaten Personal-/Prüfungsblock nicht mehr.

### 71.4 Alle bisherigen Linktokens bewusst verworfen
Ausdrückliche Nutzeranweisung:
- alle bisher erzeugten Links in PROD und TEST vollständig entfernen und ungültig machen,
- keine Altlinks in den nächsten Lauf übernehmen.

Live durchgeführt und zurückgelesen:
- PROD `Linkverwaltung`: alle Datenzeilen gelöscht, ausschließlich die Kopfzeile bleibt.
- TEST `Linkverwaltung`: alle Datenzeilen gelöscht, ausschließlich die Kopfzeile bleibt.
- Damit sind sämtliche über `Linkverwaltung` verwalteten alten Tokens nicht mehr auflösbar.

Zusätzliche Sicherheitsprüfung auf außerhalb von `Linkverwaltung` gespeicherte öffentliche Tokens:
- PROD `Wettkampfanmeldungen`: keine `feedbackToken` und keine `guestToken` vorhanden.
- TEST `Wettkampfanmeldungen`: in einem nicht versendeten Wettkampf-Entwurf waren noch acht `feedbackToken` gespeichert.
- Diese acht TEST-Tokens wurden ebenfalls vollständig aus dem JSON entfernt.
- TEST enthält danach weder `feedbackToken` noch `guestToken`.

Damit wurden alle im aktuellen Datenmodell festgestellten bereits erzeugten öffentlichen Aktions-/Rückmeldetokens in PROD und TEST verworfen.

### 71.5 Technische Prüfung des neuen Quellstands
Finaler Quellstand:
- PROD `Code.gs`: Stand 27.08.2026 05:38.
- TEST `Code.gs`: TEST · Version 2.0 · Stand 27.08.2026 · 05:38.
- `Index.html` und `DateRangeDialog.html` wurden in diesem Arbeitsblock nicht verändert.

Prüfungen:
- JavaScript-Syntax beider vollständiger `Code.gs` mit Node bestanden.
- PROD Drive-Datei und PROD-Spiegeldatei wurden mit derselben vollständigen Fassung aktualisiert.
- TEST Drive-Datei und TEST-Spiegeldatei wurden mit derselben vollständigen Fassung aktualisiert.
- Rücklesung der operativen Drive-Codefassungen bytegleich mit den geprüften lokalen Fassungen.
- PROD SHA-256: `c625a997e58f99aaa5a36a8a422a7a4f5ae4e8b63c4bc76bd8a411e830206790`.
- TEST SHA-256: `d93a6c7cba96eef122338b03c56ff3f89ce93c43524a622a72a60535d02f55b1`.

### 71.6 Wichtige Bereitstellungsgrenze
Der verbundene Google-Drive-Zugriff kann die Projektdateien und Live-Sheets bearbeiten, besitzt aber keinen Zugriff auf die gebundenen Google-Apps-Script-Projekte oder deren Web-App-Deployments. Eine installierbare Google-Apps-Script-Verbindung steht ebenfalls nicht zur Verfügung.

Deshalb gilt ausdrücklich:
- Die Quellfassungen in `Aktueller Projektstand` sind umgesetzt und technisch geprüft.
- Die Live-Sheets sind bereinigt.
- Der neue Code läuft noch NICHT in den gebundenen PROD-/TEST-Apps, solange der Nutzer `Code.gs` nicht in beide Apps-Script-Projekte übernommen und jeweils neu bereitgestellt hat.
- Erst nach der jeweiligen neuen Bereitstellung muss die entsprechende Web-App einmal über ihre aktuelle `/exec`-Adresse normal geöffnet werden. Dadurch wird die tatsächlich aktuelle Adresse als primäre Linkbasis registriert.
- Vor dieser manuellen Übernahme darf kein neuer Nachtlauf als Abnahme des Hotfixes gewertet werden.

Nächster Schritt:
- Noch keine Planung des nächsten Nachtlaufs.
- Zuerst den Stand 27.08.2026 05:38 in TEST und PROD manuell in `Code.gs` übernehmen und beide Web-Apps neu bereitstellen.
- Danach jeweils die aktuelle App einmal normal öffnen und erst dann den weiteren Prüfablauf gemeinsam festlegen.

## 72. PERSONAL-/PRÜFUNGSHINWEISE V2 UND FINALER ÜBERGABESTAND – 27.08.2026 07:29

Anlass:
- Die am frühen Morgen des 27.08.2026 vorbereitete Sammelmail-/Linkkorrektur wurde vom Nutzer noch nicht in TEST oder PROD eingespielt.
- Vor der Bereitstellung wurde der gesamte Personal-/Prüfungsablauf fachlich neu geordnet. Der V2-Stand ersetzt den Zwischenstand aus Abschnitt 71 vollständig, soweit dort noch empfängergebundene Einzel-Aktionslinks oder die Übernahme ausschließlich von `Code.gs` vorgesehen waren.
- Die alten Linktokens waren bereits vorher vollständig aus `Linkverwaltung` in PROD und TEST entfernt. Zusätzlich waren die acht noch vorhandenen, nicht versendeten TEST-Wettkampf-Feedbacktokens entfernt worden.

### 72.1 Verbindliche Sammelmail
- Pro Lauf entsteht genau eine gemeinsame E-Mail für die Personal- und überfälligen Prüfungshinweise.
- Der reguläre Nachtlauf adressiert diese eine E-Mail an den in den Systemeinstellungen hinterlegten Admin und die dort hinterlegte zweite Vorstandsperson.
- Der manuelle Lauf verwendet standardmäßig dieselben beiden Empfänger. Der Admin kann die zweite Person vor dem manuellen Versand abwählen.
- In TEST werden die hinterlegten realen Empfänger niemals angeschrieben. Dort wird für den manuellen Mailtest eine freie TEST-E-Mail-Adresse eingegeben.
- Bereits offene Personalfälle werden im normalen Nachtlauf nicht jede Nacht erneut versendet. Eine erneute Meldung erfolgt erst bei einer fälligen Wiedervorlage oder durch den ausdrücklich gestarteten manuellen Admin-Lauf.
- Prüfungsfälle verwenden ihre persistenten Dauerlinks. Ein manueller Lauf erzeugt keinen neuen Prüfungslink.

### 72.2 Genau ein Link je Fall
Verworfen ist die bisherige Variante mit mehreren direkten Aktionslinks in der E-Mail sowie empfängergebundenen Parallel-Links.

Inaktivitätsprüfung:
- genau ein gemeinsamer Falllink
- `Aktiv lassen` setzt die Inaktivitätsfrist neu auf Tag 0
- `Person sofort auf Inaktiv setzen`
- `Person als „gelegentlichen Teilnehmer“ markieren` und damit verbindlich der Gruppe `Selten da, aber immer wieder gern gesehen` zuordnen
- `Wiedervorlage in 2 Wochen`

Mitgliedschaft ungeklärt:
- genau ein gemeinsamer Falllink
- `Mitgliedschaft bestätigen`
- `Person hat nur mal reingeschnuppert`
- `Wiedervorlage in 2 Wochen`
- `Wiedervorlage in 6 Wochen`

Offene Prüfung:
- genau ein persistenter Dauerlink je Prüfungsfall
- der Link öffnet den vorhandenen Prüfungsfall
- Prüfungsgebühr und DokuMe können im Rahmen der bestehenden Prüfungsrechte weiterhin auf erledigt oder wieder offen gesetzt werden
- zusätzlich `Wiedervorlage in 2 Wochen`
- der Dauerlink bleibt bis zur vollständigen Erledigung des Prüfungsfalls derselbe

### 72.3 Anmeldung, Rechte und First-Wins
- Personalentscheidungen dürfen ausschließlich durch `Admin` oder `Vorstand` ausgeführt werden.
- Ein gültiger Personal-Falllink erweitert keine allgemeinen Rechte der Personalkartei.
- Ist keine gültige App-Sitzung vorhanden, erfolgt zuerst die normale Anmeldung. Danach wird zum konkreten Fall zurückgeführt.
- Beide vorgesehenen Empfänger verwenden denselben Personal-Falllink. Die erste gültige Entscheidung schließt den Fall.
- Ein späterer Aufruf zeigt nur noch das Ergebnis sowie entscheidende Person, Datum und Uhrzeit. Eine zweite Entscheidung ist nicht möglich.
- Prüfungs-Dauerlinks verlangen ebenfalls die normale Anmeldung, nutzen aber die bestehenden Rechte des Prüfungsbereichs. Die Personal-First-Wins-Regel gilt für Prüfungsfälle nicht, weil DokuMe und Prüfungsgebühr bis zum Abschluss mehrfach geändert werden dürfen.

### 72.4 Wiedervorlagen und Fristen
- Eine laufende Wiedervorlage wird auch durch einen manuellen Lauf respektiert und nicht vorzeitig wieder versendet.
- Inaktivitätsprüfung: Wiedervorlage 14 Tage. Währenddessen erfolgt keine automatische Inaktivsetzung. Danach wird neu geprüft und nur bei weiterhin bestehendem Grund wieder vorgelegt.
- Mitgliedschaft ungeklärt: Wiedervorlage wahlweise 14 oder 42 Tage. Danach wird neu geprüft.
- Prüfung: Wiedervorlage 14 Tage. Der vorhandene Dauerlink bleibt bestehen. Ist der Prüfungsfall vorher vollständig, entfällt die Wiedervorlage.
- Ein manueller Lauf verändert die bereits laufende 7-Tage-Entscheidungsfrist eines offenen Inaktivitätsfalls nicht. Beim Ersetzen des Personal-Falllinks wird die ursprüngliche Frist übernommen.

### 72.5 Informationsumfang in der Sammelmail
Bei Inaktivitätsprüfung und Mitgliedschaft ungeklärt werden je Person zusätzlich angezeigt:
- Datum des letzten Trainingstags als Teilnehmer
- Gruppe des letzten Trainingstags
- bei mehreren Gruppen am selben letzten Kalendertag alle Gruppen
- Gesamtzahl der unterschiedlichen Trainingstage als Teilnehmer

Trainer-, ÜL- oder Assistenteneinsätze zählen dafür nicht. Zwei Teilnahmen am selben Kalendertag zählen zusammen als ein Trainingstag.

### 72.6 `Nur mal reingeschnuppert`
- Existieren nur Trainingsteilnahmen, wird der Personendatensatz vollständig entfernt und die bisherigen Teilnahmen werden zu anonymen `Schnupperteilnahmen`.
- Existiert mindestens eine dokumentierte Prüfung oder ein Wettkampfbezug, wird die Person nicht gelöscht, sondern wie ein inaktives Mitglied archiviert.
- Andere Schutzereignisse wurden fachlich nicht vorgesehen, weil sie bei einer reinen Schnupperperson praktisch nicht entstehen können.

### 72.7 Manueller Personal-/Prüfungslauf
- Neuer Button `Personal-/Prüfungslauf ausführen` in der Übersicht der Personalkartei, ausschließlich für Admin sichtbar und serverseitig Admin-geschützt.
- Es wird ausdrücklich nicht der vollständige technische Nachtlauf gestartet. Backups, Archive, PIN-Synchronisierung und sonstige Technikblöcke bleiben unberührt.
- Der manuelle Lauf berechnet nur Personal-/Prüfungsfälle neu, ersetzt aktuelle Personal-Falllinks und versendet die neue Sammelmail.
- Bereits ausgeführte fachliche Entscheidungen werden nicht rückgängig gemacht.
- Prüfungs-Dauerlinks werden nicht ersetzt.
- Wiedervorlagen und vorhandene 7-Tage-Fristen bleiben bestehen.

### 72.8 Technische Umsetzung und Prüfung
Geänderte Laufzeitdateien:
- PROD `Code.gs`
- PROD `Index.html`
- TEST `Code.gs`
- TEST `Index.html`

Unverändert:
- beide `DateRangeDialog.html`
- Liga vollständig unberührt
- `Masterprompt.txt`, da keine neue dauerhafte Arbeitsregel hinzugekommen ist

Technisch geprüft:
- vollständige JavaScript-Syntax von PROD und TEST `Code.gs` mit Node
- Pflichtmarker für neuen Personal-/Prüfungslauf, Personal-Fallseiten, Prüfungs-Dauerlink und Sammelversand
- Drive-Spiegeldateien für PROD/TEST `Code.gs` und `Index.html` stimmen bytegleich mit den geprüften Arbeitsfassungen überein
- aktueller PROD-Snapshot enthält die erforderlichen Kernblätter und eine leere `Linkverwaltung` ohne Datenzeilen
- Checklisten-Snapshot enthält `START`, `Aktuell` und `Erledigt` und dokumentiert P6.9, P6.10, P6.12 sowie den neuen praktischen Abnahmepunkt P6.13
- `Sheet-Versionen` wurde zum Projektabschluss mit frischen XLSX-Snapshots von PROD und TEST vom 27.08.2026 07:27 ergänzt. Dort liegen danach sechs PROD- und sechs TEST-Snapshots. Die Grenze von höchstens zehn Snapshots je Live-Sheet ist eingehalten.

Prüfsummen dieses Projektstands:
- PROD-Snapshot SHA-256: `fc2931b006397b8d28c4002c432f4111363f2733522e5419432197e5e0418131`
- Checklisten-Snapshot SHA-256: `03d8844e9e8721b1201f274dea6eceb1a483e3f8f3f3392fcf4ef03df6c3de3b`
- PROD Code SHA-256: `c29b72392e604473b87573af494b7216b3953c8d1f56739c5d549128cb29d298`
- PROD Index SHA-256: `49070ba38a17218da394ca90cfb091d2431f67152e6dd44f52c2dd5b1d449070`
- TEST Code SHA-256: `b802e56f7b31e39bc0b464cd48f7a9e93eddc3a8ce1c8096f1c050c313b62152`
- TEST Index SHA-256: `98e93161b5213326fa078c1fb9782426bd35daf1c6ee11935c4675878e7a22ce`

### 72.9 Bereitstellungsgrenze und nächster Schritt
- Der Nutzer hat weder den Zwischenstand aus Abschnitt 71 noch diesen V2-Stand bereits in die gebundenen Apps-Script-Projekte eingespielt.
- Deshalb dürfen die neuen Funktionen noch nicht als praktisch freigegeben gelten.
- Nächster Schritt ist die vollständige manuelle Übernahme von `Code.gs` und `Index.html` aus diesem Projektstand zuerst in TEST und anschließend in PROD mit jeweiliger neuer Web-App-Bereitstellung.
- Danach die Web-App jeweils einmal normal über die aktuelle Bereitstellungsadresse öffnen, damit die aktuelle URL als Linkbasis registriert wird.
- Anschließend P6.13 gezielt in TEST praktisch prüfen. Erst danach den nächsten regulären PROD-Nachtlauf als Abnahme der neuen Sammelmail-/Falllinklogik bewerten.

Sicherungsdatei:
- `2026 08 27 07 29_SSV-Meschede_Judo_App_Projektstand.zip`

Liga:
- vollständig unberührt.

## 73. PROD-MANUALLAUF PRAKTISCH GEPRÜFT UND NEUER EXTERN-SONDERFALL – 27.08.2026

### 73.1 Praktische Kontrolle des manuellen PROD-Personal-/Prüfungslaufs
- Der Nutzer hat den neuen manuellen PROD-Personal-/Prüfungslauf am 27.08.2026 selbst gestartet.
- Das Änderungsprotokoll weist um 08:47:48 den Lauf `PERSON_EXAM_MANUAL` durch `Z00014` aus.
- Protokolliertes Ergebnis: 19 Personalfälle, davon 8 Inaktivitätsprüfungen und 11 Fälle `Mitgliedschaft ungeklärt`, 0 offene Prüfungsfälle, 1 verwendeter Mail-Empfänger.
- Die acht Inaktivitätsfälle stimmen mit dem aktuellen PROD-Datenbestand und der konfigurierten Schwelle von 94 Kalendertagen überein. Betroffen waren P00035, P00062, P00067, P00075, P00090, P00092, P00096 und P00122.
- Die elf Fälle `Mitgliedschaft ungeklärt` stimmen mit den aktuell aktiven 56-Tage-Löschwarnungsfällen überein. Die jüngsten davon lagen bei 57 Kalendertagen seit dem letzten Trainingstag als Teilnehmer.
- Für jeden der 19 sichtbaren Personalfälle existiert genau ein neuer gemeinsamer Falllink. Die elf zusätzlichen Zeilen `PERSON_OFFEN_LOESCHUNG` besitzen keine URL und sind interne 7-Tage-Prozesszeilen, keine zusätzlichen Benutzerlinks.
- Es existieren keine aktiven `MAIL_ACTION`-Altlinks und aktuell keine `EXAM_CASE`-Dauerlinks. `Prüfungsfälle` enthält derzeit nur die Kopfzeile, daher sind 0 Prüfungsfälle in der Sammelmail konsistent.
- Die aktuelle Linkbasis ist bei den neuen Personalfalllinks einheitlich die produktive `/exec`-Bereitstellung.
- Während der Kontrolle wurde P00062 über `Wiedervorlage in 2 Wochen` bearbeitet. Der Falllink steht anschließend korrekt auf `verwendet`, Ergebnis `Wiedervorlage am 10.09.2026`, Entscheidung durch `Z00014`. Gleichzeitig steht in `Hinweisstatus` ein aktiver `INAKTIV_WVL` bis 10.09.2026. Damit ist dieser Teil der neuen Wiedervorlagelogik praktisch bestätigt.
- Der manuelle Lauf hat laut Änderungsprotokoll keine unerwartete Archivierung, Löschung oder automatische Inaktivsetzung ausgelöst.
- Der Lauf verwendete 1 Empfänger, obwohl in den Systemeinstellungen zwei Personen hinterlegt sind. Das ist nur dann erwartungsgemäß, wenn die zweite Person beim manuellen Start bewusst abgewählt wurde.

### 73.2 Verworfen: vermeintliche Datenabweichung bei Niklas Brasse
- Im PROD-Sheet ist Niklas Brasse `P00096` derzeit als bestätigtes Mitglied geführt und deshalb korrekt in der Inaktivitätsprüfung gelandet.
- Im Sheet sind genau zwei Trainingstage als Teilnehmer hinterlegt: 12.01.2026 in `Fortgeschrittene` und 09.02.2026 in `Erwachsene`.
- Daraus ergibt sich fachlich als letzter Trainingstag 09.02.2026, letzte Gruppe `Erwachsene`, insgesamt 2 Trainingstage.
- Die zunächst behauptete Abweichung der Fallanzeige war eine Fehlinterpretation des Screenshots und wird ausdrücklich verworfen.
- Der vom Nutzer gezeigte Fall zeigt tatsächlich korrekt `Letztes Training: 09.02.2026`, `Gruppe: Erwachsene` und `Trainingstage als Teilnehmer: 2`.
- Die bestehende Berechnung `personalParticipantTrainingInfo_()` ist damit für diesen konkreten Fall bestätigt. Es wurde keine unnötige Reparatur an dieser Berechnung vorgenommen.

### 73.3 Neuer verbindlicher Sonderfall `Als externer Teilnehmer festlegen`
- Nutzerentscheidung: Sowohl bei `Inaktivitätsprüfung` als auch bei `Mitgliedschaft ungeklärt` muss zusätzlich die Aktion `Als externer Teilnehmer festlegen` angeboten werden.
- Anlass ist Niklas Brasse: Er wurde beim Training als `neues Mitglied` angelegt, ist tatsächlich aber Teilnehmer eines anderen Vereins.
- Die Aktion ordnet die Person als `Extern` ein, beendet die Mitgliedschaftsbestätigung, schließt aktuelle Gruppenzuordnungen und beendet den bearbeiteten Personal-Fall.
- Die Person wird bei dieser Entscheidung nicht sofort anonymisiert oder gelöscht. Sie bleibt zunächst als namentlich erfasster externer Teilnehmer erhalten.
- Nutzerbestätigung: Danach gelten exakt die bestehenden Regeln für externe Teilnehmer. Ist die bestehende Externen-Frist bereits überschritten, darf der nächste reguläre Bereinigungslauf die Person nach den vorhandenen Schutzprüfungen entfernen und ihre Trainingsteilnahmen als `Externe Gäste` anonymisieren.
- Schutzlogik bleibt unverändert: Besteht andere personenbezogene Historie, setzt `personHasNonTrainingHistory_()` die automatische vollständige Löschung aus.
## 74. EXTERN-SONDERFALL IN PERSONALFÄLLEN UMGESETZT – 27.08.2026 11:35

### 74.1 Umsetzung
- In PROD und TEST wurde die gemeinsame Personal-Fallseite erweitert.
- `Inaktivitätsprüfung` bietet jetzt zusätzlich `Als externen Teilnehmer festlegen`.
- `Mitgliedschaft ungeklärt` bietet jetzt zusätzlich `Als externen Teilnehmer festlegen`.
- Die Aktion ist weiterhin ausschließlich nach normaler Anmeldung und nur für `Admin` oder `Vorstand` ausführbar.
- Die Entscheidung verwendet dieselbe bestehende fachliche Extern-Markierung wie die Personalkartei und keine sofortige Anonymisierung.
- Bei Inaktivitätsfällen wird eine eventuell vorhandene Inaktivitäts-Wiedervorlage beendet.
- Bei Mitgliedschaftsfällen wird ein eventuell vorhandener interner Löschwarnungsprozess beendet.
- Der bearbeitete Personal-Fall und parallele aktuelle Personalfalllinks werden anschließend geschlossen und die entscheidende Person bleibt protokolliert.

### 74.2 Prüfung der vermeintlichen Fallanzeige-Abweichung
- Der Screenshot und die Live-PROD-Daten wurden erneut gegeneinander geprüft.
- Für Niklas Brasse stimmen Anzeige und Sheet überein: letzter Trainingstag 09.02.2026, Gruppe `Erwachsene`, 2 Trainingstage als Teilnehmer.
- Die vorher dokumentierte Abweichung war falsch und ist in Abschnitt 73.2 ausdrücklich als verworfen markiert.
- Keine Änderung an der Trainingstags-/Letzte-Gruppe-Berechnung, da dort kein Fehler vorliegt.

### 74.3 Technische Prüfung und Bereitstellungsgrenze
- JavaScript-Syntax von PROD und TEST `Code.gs` mit Node geprüft.
- Geprüft, dass beide Personal-Fallarten den neuen UI-Button und die Serveraktion `external` enthalten.
- Geprüft, dass die neue Aktion den bestehenden Externenstatus setzt und nicht `externalizePersonLocked_()` mit sofortiger Anonymisierung verwendet.
- `DateRangeDialog.html` bleibt unverändert.
- Liga bleibt vollständig unberührt.
- Dieser Arbeitsstand ist neuer als die Sicherungs-ZIP `2026 08 27 07 29_SSV-Meschede_Judo_App_Projektstand.zip`.
- Die neuen Änderungen sind nur im Drive-Arbeitsstand vorbereitet. Sie sind noch nicht in die gebundenen Apps-Script-Projekte übernommen oder bereitgestellt.
- Nächste praktische Prüfung nach Übernahme: einen Inaktivitätsfall und einen Fall `Mitgliedschaft ungeklärt` jeweils über `Als externen Teilnehmer festlegen` bearbeiten und anschließend Vereinsbezug, geschlossenen Falllink und Verhalten des nächsten Bereinigungslaufs kontrollieren.


## 75. SCHNELLIDEE „GRATULATIONS-ABO“ FÜR DEN VORSTAND – 27.08.2026

- HISTORISCHER AUSGANGSPUNKT. Seit Abschnitt 93 fachlich geklärt und zur Umsetzung freigegeben.
- Frühere Fassung: zunächst Schnellidee ohne Umsetzungsfreigabe.
- Arbeitstitel: `Gratulations-Abo` für den Vorstand.
- Grundidee: Im regulären Nachtlauf erhält der Vorstand eine E-Mail zu Mitgliedern, die am jeweiligen Tag Geburtstag haben.
- Vor einer Umsetzung sind die fachlichen Details noch zu klären, insbesondere Empfängerkreis, Umgang mit fehlendem oder nur teilweise bekanntem Geburtsdatum, Altersangabe, Datenschutz/Anzeigeumfang, Mehrfachgeburtstage und gewünschter Mailtext.
- Die Idee wurde zusätzlich in der Live-Checkliste unter `START` → `SCHNELLE IDEE` aufgenommen.
- VERWORFEN seit Abschnitt 93: Die Annahme, dass die fachlichen Details noch offen seien. Die Details sind inzwischen geklärt und der Drive-Arbeitsstand wurde umgesetzt.

## 76. LINKVERWALTUNG ALS KOMPAKTE ARBEITSLISTE – 27.08.2026 12:19

### 76.1 Verbindliche Fachentscheidung
- `Linkverwaltung` ist künftig eine technische Arbeitsliste für aktuell noch relevante Links und ausdrücklich kein dauerhaftes Archiv.
- Die fachliche Historie einer Entscheidung bleibt in den jeweiligen Fachblättern und im Änderungsprotokoll erhalten. Sie darf nicht davon abhängen, dass der technische Linkdatensatz dauerhaft bestehen bleibt.
- Bei jedem regulären Personal-/Prüfungslauf im Nachtlauf und bei jedem manuellen Personal-/Prüfungslauf wird die Linkverwaltung zentral bereinigt und physisch kompaktiert.

### 76.2 Aufbewahrungsregeln
- Aktive gültige Links bleiben erhalten.
- Durch einen manuellen Personallauf ersetzte oder anderweitig ungültig gewordene Personal-Falllinks werden nach Abschluss desselben Laufs physisch entfernt.
- Verwendete Personal-Falllinks bleiben bis zu ihrem ursprünglichen `Gültig bis` erhalten. Dadurch kann die zweite berechtigte Vorstandsperson den bereits entschiedenen Fall noch öffnen und sehen, wer wann welche Entscheidung getroffen hat.
- Besitzt ein verwendeter Personal-Falllink ausnahmsweise kein ursprüngliches Ablaufdatum, gilt als technische Auffangfrist 7 Kalendertage ab Entscheidung. Danach wird er entfernt.
- Prüfungs-Dauerlinks bleiben ausschließlich solange erhalten, wie der zugehörige Prüfungsfall unvollständig ist. Nach vollständigem Abschluss werden sie entfernt.
- Interne Personal-Prozesslinks ohne Benutzer-URL bleiben nur solange erhalten, wie ihr Fachprozess noch aktiv beziehungsweise innerhalb seiner Frist ist.
- Sonstige Linkarten werden nur entsprechend ihrer jeweils eigenen Gültigkeit aufbewahrt. Ungültige, abgelaufene oder verbrauchte technische Links werden entfernt, sofern ihre Linkart keine fachlich begründete weitere Aufbewahrung verlangt.

### 76.3 Technische Umsetzung
- PROD und TEST besitzen jetzt eine gemeinsame zentrale Kompaktierungsroutine für `Linkverwaltung`.
- Die Routine läuft nach dem fachlichen Personal-/Prüfungszyklus. Dadurch werden fällige Fälle zuerst korrekt verarbeitet und erst anschließend nicht mehr benötigte Linkzeilen entfernt.
- Auch bei einem Fehler während des Mailversands wird die abschließende Linkbereinigung des bereits abgeschlossenen Fachlaufs ausgeführt.
- Die Kompaktierung schreibt ausschließlich die weiterhin benötigten Linkzeilen zusammenhängend unter die Kopfzeile zurück. Leere Zwischenräume und dauerhaft anwachsende Altzeilen werden dadurch vermieden.
- Der manuelle Personal-/Prüfungslauf protokolliert zusätzlich die Zahl der bei diesem Lauf entfernten Linkzeilen.
- Der reguläre Nachtlauf verwendet vorhandene noch gültige Falllinks weiter. Der manuelle Lauf darf Personal-Falllinks bewusst erneuern, ohne die fachliche 7-Tage-Frist neu zu starten.

### 76.4 Einmalige Bereinigung des aktuellen PROD-Bestands
- Vor der Bereinigung wurde `Linkverwaltung` direkt aus PROD kontrolliert.
- Es wurden 18 eindeutig veraltete Zeilen mit Ergebnis `Durch manuellen Lauf ersetzt` identifiziert und anschließend physisch aus der Live-PROD-Linkverwaltung entfernt.
- Die direkte Rückleseprüfung danach ergab 0 verbleibende Zeilen mit `Durch manuellen Lauf ersetzt`.
- Die beiden tatsächlich verwendeten Entscheidungen P00062 `Wiedervorlage am 10.09.2026` und P00096 `Als externer Teilnehmer festgelegt` sind davon ausdrücklich nicht betroffen und werden bis zu ihrem ursprünglichen Ablaufdatum 03.09.2026 aufbewahrt.
- Aktive aktuelle Personal-Falllinks und die internen aktiven 7-Tage-Prozesszeilen bleiben ebenfalls erhalten.
- TEST besitzt aktuell nur die Kopfzeile in `Linkverwaltung` und benötigt keine einmalige Datenbereinigung.

### 76.5 Bereitstellungsgrenze
- Geändert wurden `Code.gs` in PROD und TEST, diese Projektakte, die fachliche Ideen-/Aufgabenpflege sowie einmalig die technisch veralteten Linkzeilen in der Live-PROD-`Linkverwaltung`.
- `Index.html`, `DateRangeDialog.html`, `Masterprompt.txt` und Liga bleiben unverändert.
- Die neue automatische Linkkompaktierung ist zunächst nur im Drive-Arbeitsstand enthalten. Sie wird erst nach manueller Übernahme und neuer Bereitstellung der jeweiligen `Code.gs` in den gebundenen Apps-Script-Projekten wirksam.



## 77. ABSCHLUSSSTAND FÜR CHATWECHSEL – 27.08.2026

### 77.1 Konsolidierter Stand
- Dieser Abschlussstand baut auf Abschnitt 72 auf und enthält zusätzlich den in Abschnitt 74 umgesetzten Extern-Sonderfall sowie die in Abschnitt 76 umgesetzte zentrale Linkkompaktierung.
- Der Nutzer hat den bisherigen produktiven Personal-/Prüfungslauf praktisch als plausibel bestätigt. Die jüngsten Drive-Codefassungen nach Abschnitt 74 und 76 wurden jedoch im Chat nicht ausdrücklich als in die gebundenen Apps-Script-Projekte übernommen bestätigt.
- Deshalb ist im neuen Chat vor der praktischen Abnahme zuerst der tatsächlich laufende TEST-/PROD-Code mit diesem Projektstand abzugleichen.
- Die Live-PROD-Linkverwaltung wurde einmalig um 18 eindeutig ersetzte Zeilen bereinigt. Verwendete Entscheidungen und gültige aktuelle Links blieben erhalten.
- TEST-Linkverwaltung war zum Zeitpunkt der Umsetzung bereits leer und benötigte keine einmalige Bereinigung.
- HISTORISCH, seit Abschnitt 93 überholt: Die Schnellidee `Gratulations-Abo` wurde fachlich geklärt und zur Umsetzung freigegeben.

### 77.2 Nächste drei verbindlich empfohlene Arbeitsschritte
1. Personal-/Prüfungsstrecke in TEST vollständig abnehmen. Dabei insbesondere Sammelmail, genau ein Falllink je Fall, Login und Rollen, First-Wins, Wiedervorlagen, Prüfungs-Dauerlink, manueller Lauf, Extern-Einstufung, Linkkompaktierung und TEST-Mail-Sperre prüfen.
2. P6.1 und P6.2 schließen. Damit werden Statuslogik ohne Trainingsgruppe sowie Personalkartei-Rechte fachlich und serverseitig konsistent.
3. P2.1 bis P2.8 als zusammenhängenden Personalkartei-Abnahmeblock praktisch prüfen.

### 77.3 Sicherungen und Projektstand
- Frischer PROD-XLSX-Snapshot aus dem nativen Live-Sheet wurde für diesen Abschlussstand erzeugt und im operativen PROD-Ordner aktualisiert.
- Frischer Snapshot der nativen Live-Checkliste wurde für diesen Abschlussstand erzeugt und im Checklisten-Ordner aktualisiert.
- Unter `Sheet-Versionen` wurden neue Sicherungen `2026 08 27 13 52_PROD_Judo App 2.0.xlsx` und `2026 08 27 13 52_Spielwiese_Judo App 2.0.xlsx` angelegt.
- Projekt-ZIP: `2026 08 27 13 53_SSV-Meschede_Judo_App_Projektstand.zip`
- PROD-Snapshot SHA-256: `137efd30f453193e767d24d156568c56c4aca10e088946dcbdac3f8dab4f1bf0`
- Checklisten-Snapshot SHA-256: `2f3e8e6354dd1ee5a0da217ca091b873e1cedd85f656ff614ca46619885755a7`
- PROD Code SHA-256: `ad7dde0e8b6760b4112efeb28b93f116abbfbd7543b8580b85f9bc95a9da3286`
- PROD Index SHA-256: `c3d512aa0617dcbcb9cf4680b31752bc15daca1fb03b5570788d85aa150fd4d5`
- TEST Code SHA-256: `86502d8c68ddabc9fc06b404c3dbd9a546cab2202c949b029729b6e36b3c822a`
- TEST Index SHA-256: `513dcb719d20bdec1a849afcde8a3d8b029541467f41aba4fcfc843f37923915`

### 77.4 Prüfroutine
- `Projektstand_erstellen_und_pruefen.py` wurde für diesen Stand ergänzt. Neben den bisherigen Personal-/Prüfungshinweisen prüft er jetzt zusätzlich Pflichtmarker für `Als externer Teilnehmer festgelegt`, die zentrale Funktion `compactManagedLinks_()` und das Protokollfeld der entfernten Links.
- Die endgültige ZIP darf erst nach erneuter Öffnung und Meldung `PRUEFUNG_BESTANDEN` archiviert und als Chatwechselstand bezeichnet werden.

## 78. SAMMELKORREKTUR PERSONALKARTEI, WETTKAMPF, PRÜFUNGEN UND PERFORMANCE – 27.08.2026 18:01

### 78.1 Praktisch abgeschlossene Abnahmen
- P2.2 bis P2.8, P6.1, P6.2, P6.11 und P4.5 wurden praktisch bestanden. Normale Trainer sehen die Personalkartei nicht.
- P2.1 Mehrfachzuordnung und Wiederöffnen war bereits praktisch bestanden; nur die neue `ZZ_`-Ausblendung bleibt nach Bereitstellung kurz zu prüfen.

### 78.2 Personalkartei-Übersicht
- Verworfen ist die bisherige kreuz und quer angeordnete Suche/Sortierung mit Sondercheckboxen.
- Neu: kompakte Kopfzeile mit Suche, Sortierung und `+ Neu`; für Admin bleibt der manuelle Personal-/Prüfungslauf verfügbar.
- Statusfilter: `Aktiv`, `Mitgliedschaft offen`, `Gelegentlich aktiv`, `Inaktiv`, `Extern`. Standard: erste drei an, Inaktiv/Extern aus.
- Sortierung: `Rufname`, `Vorname`, `Nachname`. Die Karten werden in optisch getrennten A/B/C-Blöcken nach dem jeweils gewählten Sortierfeld dargestellt. Leere Buchstaben entfallen; Raster responsiv 3/2/1 Spalten.

### 78.3 Aktuelle Gruppen
- Gruppen mit Präfix `ZZ_` werden in der Auswahl ausgeblendet.
- Bestehende verdeckte `ZZ_`-Zuordnungen bleiben beim Speichern erhalten und werden nicht stillschweigend gelöscht. Andere fachlich relevante inaktive Gruppen bleiben auswählbar.

### 78.4 Historische Wettkampfteilnehmer
- P1.8: Altwerte `4./5.` und `6./7.` waren korrekt. Speichern war durch den leeren Namen des heute inaktiven historischen Teilnehmers Otto Sanchez Marcelo (`P00102`) blockiert.
- Beim Bearbeiten bestehender Wettkämpfe werden gespeicherte Teilnehmer und Betreuer jetzt zusätzlich aus dem vollständigen Personen-/Archivbestand ergänzt, auch wenn sie heute inaktiv sind. Anonymisierte Externe werden nicht wieder personalisiert.
- Neue Wettkämpfe bleiben auf die operative aktive Personenauswahl beschränkt. P1.8 Speichern/Wiederöffnen bleibt praktisch nachzuprüfen.

### 78.5 Prüfungs-UI
- Rote/grüne Gebühr- und DokuMe-Schalter verwenden weiße fette Schrift.
- Vollständig abgeschlossene Prüfungs-Direktlinks zeigen `PRÜFUNG ABGESCHLOSSEN`; die vereinfachte Abschlussansicht bleibt erhalten.

### 78.6 Performance ohne Fachlogikänderung
- Beobachtet: manueller Personal-/Prüfungslauf im TEST 84,2 s und 68,4 s.
- `prepareMembershipCaseLinks_()` und `prepareInactiveCaseLinks_()` vermeiden wiederholte Vollreads der Linkverwaltung pro Fall und arbeiten nach einem initialen Read mit In-Memory-Gruppierungen.
- Personal-Direktlinks laden Trainingsteilnahmen gezielt nur für die betroffene Person statt global für alle Personen.
- Verworfen wurde eine weitergehende Vereinfachung der Fachlogik. Fristen, Wiedervorlagen, First-Wins, Rechte, Bereinigung und Nachtlaufregeln bleiben unverändert. Praktische Laufzeitmessung bleibt offen.

### 78.7 Prüfung und Abgrenzung
- PROD/TEST `Code.gs` sowie die JavaScript-Blöcke beider `Index.html` bestehen Syntaxprüfungen mit Node.
- Der Projektprüfer kontrolliert zusätzlich neue Pflichtmarker für Filter, `Vorname`, Alphabetblöcke, `ZZ_`-Erhalt, historische Wettkampfpersonen, gezielte Direktlinkdaten und `PRÜFUNG ABGESCHLOSSEN`.
- `DateRangeDialog.html` und `Masterprompt.txt` unverändert. Liga vollständig unberührt.
- Drive-Arbeitsquellen werden auf diesen Stand aktualisiert. Apps-Script-Deployments können über Drive nicht automatisch bereitgestellt werden.

Sicherungsdatei:
- `2026 08 27 18 01_SSV-Meschede_Judo_App_Projektstand.zip`
- PROD-Snapshot SHA-256: `f66546c2b001bf09f8e785212e902673aec3460e27ecac436d93da04c12f76f9`
- Checklisten-Snapshot SHA-256: `afbab649e6d32296aee47fd7bfcf91b339160b1c5e4ddc969c37452183651b88`
- PROD Code SHA-256: `3872a749f9c3d2ed1e4e35b8e0dce61edbcfc281812933513636e51644d3b00a`
- PROD Index SHA-256: `89381172c0d31d93b2fd161a11bffb67b74cfb2191e19d8369c00d0338f3bcda`
- TEST Code SHA-256: `f8ceaa31de3b7f5bac2e5e02bef68f3a7423d7bb4e035482fca6d3de6151db7d`
- TEST Index SHA-256: `ac272fc62bfaed40bcc3abc76da491f929096e63dd2e78af54444dd554dbdd57`

Nächster Schritt:
1. `Code.gs` und `Index.html` zuerst vollständig in TEST übernehmen und neu bereitstellen.
2. Personalkartei Desktop, `ZZ_`-Ausblendung und P1.8 mit Otto Sanchez Marcelo prüfen.
3. Prüfungs-UI prüfen und Personal-/Prüfungslauf neu messen.
4. Danach PROD übernehmen und neu bereitstellen.

## 79. P1.8 HISTORISCHE EXTERNE WETTKAMPFTEILNEHMER – 27.08.2026 18:46

### 79.1 Praktischer Befund
- Die erste Korrektur aus Abschnitt 78.4 löste Otto Sanchez Marcelo (`P00102`) beim historischen Wettkampf vom 01.02.2026 wieder namentlich auf.
- Das unveränderte Speichern scheiterte anschließend weiterhin mit `Ungültiger Wettkampfteilnehmer.`
- Ursache war nicht mehr Otto, sondern Leander Neufeld (`P00062`), der am 01.02.2026 regulärer Teilnehmer war und durch einen späteren fingierten TEST-Fall inzwischen den aktuellen Vereinsbezug `Extern` besitzt.
- Der Nutzer bewertet diesen konkreten Fall als theoretischen, durch die Testdaten entstandenen Sonderfall. Die Absicherung soll dennoch korrekt funktionieren.

### 79.2 Korrektur
- Serverregel für Wettkampfteilnehmer in PROD und TEST vereinheitlicht.
- Eine aktuell externe Person bleibt beim Bearbeiten eines bestehenden Wettkampfs zulässig, wenn dieselbe Personen-ID bereits als Teilnehmer dieses Wettkampfs gespeichert war.
- Eine aktuell externe Person darf weiterhin nicht neu zu einem Wettkampf hinzugefügt werden.
- Damit bleibt die operative Extern-Sperre erhalten, ohne historische Datensätze beim unveränderten Speichern zu blockieren.
- `Index.html`, `DateRangeDialog.html`, `Masterprompt.txt` und Liga bleiben unverändert.

### 79.3 Prüfung und Bereitstellungsgrenze
- PROD und TEST `Code.gs` auf JavaScript-Syntax geprüft.
- Zielbedingung statisch geprüft: vorhandener historischer Externer zulässig, neuer Externer unzulässig, reguläre Person zulässig.
- Drive-Arbeitsquellen und Code-Spiegel werden auf denselben Stand gebracht.
- Apps-Script-Deployments können über Drive nicht automatisch bereitgestellt werden. P1.8 bleibt bis zur manuellen Übernahme in TEST, neuer Bereitstellung und praktischem Speichern/Wiederöffnen `In Arbeit`.


### 79.4 Praktische Abnahme abgeschlossen – 27.08.2026
- Der historische Wettkampf vom 01.02.2026 ließ sich nach der Korrektur fehlerfrei speichern.
- Nach Schließen und erneutem Öffnen waren Teilnehmer und Kampfergebnisse vollständig erhalten.
- Damit ist P1.8 praktisch bestanden und erledigt.
- Nächster sinnvoller offener praktischer Prüfschritt ist P2.1: `ZZ_`-Gruppen müssen in der Gruppenauswahl ausgeblendet sein, vorhandene verdeckte technische Zuordnungen dürfen beim Speichern jedoch nicht verloren gehen.


## 81. P7.1 PRAKTISCHE TEST-NACHPRÜFUNG BESTANDEN – 27.08.2026

- Nach Bereitstellung des Fixes hat der Nutzer die Personalkartei erneut praktisch geprüft.
- Sortierung nach Rufname, Vorname und Nachname funktioniert anstandslos.
- Die Statusfilter reagieren auch bei Sortierung nach Nachname korrekt.
- P7.1 ist damit praktisch bestanden und erledigt.

## 82. P6.6 PERFORMANCE PERSONAL-/PRÜFUNGSLAUF – 27.08.2026

- Praktische TEST-Messung nach den jüngsten Performancekorrekturen: `96,5 s`.
- Ergebnis funktional: 1 Inaktivität, 22 Mitgliedschaft, 0 Prüfungen.
- Die Laufzeit ist schlechter als die zuvor beobachteten 84,2 s und 68,4 s und praktisch nicht akzeptabel.
- P6.6 bleibt offen. Keine weitere Wiederholungsmessung ohne vorherige technische Ursachenanalyse.

## 83. P6.6 PERFORMANCE ALS AKZEPTIERTE GRENZE ABGESCHLOSSEN – 27.08.2026

- Nutzerentscheidung nach praktischer TEST-Messung von `96,5 s`: keine weitere Performanceoptimierung dieses Laufs.
- Begründung: Der Personal-/Prüfungslauf erfolgt im regulären Betrieb nachts ohne Bedienwartezeit. Der manuelle Start wird nach stabiler Inbetriebnahme voraussichtlich nur selten benötigt.
- Die funktionale Ausführung war korrekt. Die Laufzeit wird deshalb trotz ihres hohen Werts als aktuell akzeptierte technische Grenze behandelt.
- Die Aussage aus Abschnitt 82, die Laufzeit sei praktisch nicht akzeptabel, ist damit fachlich überholt. Maßgeblich ist diese neuere Entscheidung.
- P6.6 ist erledigt und wird nur wieder geöffnet, wenn Nachtläufe fehlschlagen oder die Laufzeit künftig deutlich weiter steigt.

## 84. P1.5 EXTERNE PRAKTISCH ABGESCHLOSSEN – 27.08.2026

- Die Wiederholungsprüfung wurde mit dem fachlich passenden TEST-Training `25.08.2026 – Minis` durchgeführt.
- Der zuvor verwendete Termin `08.06.2026 – Erwachsene` war als Prüffall ungeeignet, weil Willi Mensch (`P00141`) erst am 25.08.2026 angelegt wurde und die Gästesuche Personen korrekt nach dem Trainingsdatum begrenzt.
- `Willi Mensch (extern)` wurde beim passenden Termin namentlich angeboten, als Gast ausgewählt, fehlerfrei gespeichert und nach erneutem Öffnen weiterhin korrekt als ausgewählter Gast angezeigt.
- P1.5 ist damit praktisch bestanden und erledigt.

## 85. P6.4 STATUSWECHSEL AM SELBEN KALENDERTAG – 27.08.2026 20:13

### 85.1 Befund
- Der TEST-Fall Rudin Hamo (`P00108`) enthält nach `inaktiv → aktiv` am 25.08.2026 den ungültigen Zeitraum `25.08.2026 bis 24.08.2026`.
- Die vollständige TEST-Prüfung zeigte zusätzlich denselben Fehler bei Arian Müller (`P00006`) am 27.08.2026.
- PROD wurde vollständig geprüft. Dort existiert aktuell kein Statuszeitraum mit `Gültig bis` vor `Gültig ab`.
- Ursache: `changePersonStatusLocked_()` beendete jeden offenen Status pauschal mit `Wechseldatum minus 1 Tag` und legte anschließend einen neuen Status an. Bei einem zweiten Wechsel am selben Kalendertag entstand dadurch ein negativer Zeitraum.

### 85.2 Entscheidung und Korrektur
- Fachliche Entscheidung: Ein bereits am selben Kalendertag begonnener offener Status wird bei einem weiteren Statuswechsel dieses Tages ersetzt, nicht auf den Vortag beendet.
- PROD und TEST verwenden dafür denselben korrigierten Schreibpfad.
- Offene ältere Statuszeiträume werden weiterhin regulär mit `Wechseldatum minus 1 Tag` beendet.
- Beginnt der aktuell offene Status bereits am Wechseldatum, wird dessen Statuswert aktualisiert und kein zusätzlicher Statusdatensatz erzeugt.
- Damit kann `Gültig bis` durch diesen Schreibpfad nicht mehr vor `Gültig ab` fallen.
- Bestehende TEST-Altfehler PS00140 (`P00108`) und PS00146 (`P00006`) wurden gezielt entfernt. Die jeweils direkt anschließenden offenen Aktiv-Zeiträume bleiben bestehen.
- PROD-Daten bleiben unverändert, weil dort kein entsprechender Altfehler gefunden wurde.

### 85.3 Prüfung und Bereitstellungsgrenze
- PROD und TEST `Code.gs` wurden nach der Änderung auf JavaScript-Syntax geprüft.
- `Index.html`, `DateRangeDialog.html`, `Masterprompt.txt` und Liga bleiben unverändert.
- Drive-Arbeitsquellen und Code-Spiegel wurden auf Stand 27.08.2026 20:13 aktualisiert und anschließend erneut gegengeprüft.
- Apps-Script-Deployments können über Drive nicht automatisch bereitgestellt werden. P6.4 bleibt bis zur praktischen TEST-Nachprüfung des gleich­tägigen Statuswechsels `In Arbeit`.



## 86. WETTKAMPF-PLATZIERUNGEN ZURÜCK AUF EINZELPLÄTZE 1 BIS 7 – 27.08.2026 20:36

### 86.1 Auslöser und Befund
- Bei der praktischen P6.4-Nachprüfung ließ sich die TEST-Person `Test 123` (`P00139`) nicht aus der Personalkartei öffnen. Die App meldete `Platzierung ist nicht gültig`.
- Ursache war nicht die Personalkartei selbst. `getPersonFile()` lädt die Wettkampfhistorie der Person. Dort wurde eine als `4/5` angezeigte Platzierung serverseitig als ungültig erkannt.
- Die technische Zellprüfung zeigte: Google Sheets hatte `4/5` im deutschen Gebietsschema als Datum interpretiert und intern als Datumsserienwert `46146` gespeichert. `6/7` war entsprechend als Datumsserienwert `46209` gespeichert.
- Im TEST waren insgesamt sechs solche beschädigten Sammelplatzwerte vorhanden. PROD enthielt zum Prüfzeitpunkt keine Sammelwerte `4/5` oder `6/7` und keine entsprechend beschädigten Datumswerte.

### 86.2 Aktuelle Nutzerentscheidung
- Die bisherige Sammelplatz-Entscheidung `4/5` und `6/7` ist ausdrücklich VERWORFEN.
- Maßgeblich sind ab sofort wieder ausschließlich die Einzelplatzierungen `1`, `2`, `3`, `4`, `5`, `6` und `7` sowie `ohne Platzierung`.
- Diese Entscheidung ersetzt alle älteren Projektaktenstellen, in denen `4/5` oder `6/7` als fachliche Sammelwerte vorgesehen waren.
- Wertungspunkte bleiben fachlich unverändert. Einzelplätze 4 bis 7 werden weiterhin anhand der bestehenden Tabelle `Wertungspunkte` und deren konfigurierter Höchstplatzierung für die Sammelwertung bewertet.

### 86.3 Technische Umsetzung
- TEST und PROD `Code.gs` akzeptieren und speichern bei Wettkampfplatzierungen nur noch ganze Zahlen von 1 bis 7 oder keinen Wert.
- Standard-Wettkampfpfad und Gastlink-Wettkampfpfad verwenden dieselbe strikte Platzierungsprüfung.
- TEST und PROD `Index.html` bieten im Wettkampfeditor wieder die Einzeloptionen 1 bis 7 sowie `ohne Platzierung` an.
- Personalkartei, Wettkampfstatistik und Ranglistendarstellung verwenden keine Sammelplatz-Texte mehr.
- Die Spalte `Wettkampfteilnahmen / Platzierung` ist in TEST und PROD technisch auf Zahlen zwischen 1 und 7 begrenzt und als ganze Zahl formatiert. Dadurch kann Google Sheets `4/5` oder `6/7` nicht mehr als Datum einschleusen.
- Quellstände `Code.gs` und `Index.html` für TEST und PROD sowie die Drive-Spiegel wurden auf Stand `27.08.2026 20:31` aktualisiert.
- Die JavaScript-Syntax von beiden `Code.gs` sowie der relevanten Inline-Skripte beider `Index.html` wurde technisch geprüft und bestanden.

### 86.4 TEST-Datenkorrektur
- Die echten historischen Einzelwerte wurden aus der Google-Sheets-Versionshistorie vor Einführung der Sammelplätze zurückgewonnen.
- `Jakob Mecaj` (`P00035`), Wettkampf 01.02.2026: wieder Platz 5.
- `Joshua Middel` (`P00050`), Wettkampf 01.02.2026: wieder Platz 5.
- `Khaled Abdul Hadi` (`P00055`), Wettkampf 01.02.2026: wieder Platz 5.
- `Lasse Kaiser` (`P00060`), Wettkampf 01.02.2026: wieder Platz 7.
- `Theo Derksen` (`P00119`), Wettkampf 01.02.2026: wieder Platz 5.
- Für den künstlichen TEST-Fall `Test 123` (`P00139`) war aus der verfügbaren Versionshistorie kein eindeutiger Einzelplatz 4 oder 5 mehr rekonstruierbar. Dieser Platzierungswert wurde deshalb bewusst geleert statt einen Wert zu erfinden.
- Die korrigierten TEST-Zellen wurden zurückgelesen. Alle fünf rekonstruierbaren Werte liegen wieder numerisch als 5 beziehungsweise 7 vor. Der künstliche nicht rekonstruierbare Wert ist leer. Die Datumsformatierung ist entfernt.
- PROD-Wettkampfplatzierungen wurden inhaltlich nicht verändert. Dort wurde nur die strengere Validierung 1 bis 7 gesetzt.

### 86.5 Abnahmegrenze und nächste Schritte
- P1.8 wird wieder geöffnet, weil die frühere praktische Abnahme die inzwischen verworfene Sammelplatz-Bedienung 4/5 und 6/7 betraf. Die neue Einzelplatzleiste 1 bis 7 muss in TEST praktisch erneut geprüft werden.
- P6.4 bleibt `In Arbeit`. Der gleich­tägige Statuswechsel-Fix aus Abschnitt 85 ist technisch weiterhin enthalten. Seine praktische Nachprüfung wurde lediglich durch den unabhängigen Wettkampf-Platzierungsfehler blockiert.
- Nach Bereitstellung des TEST-Stands 20:31 wird zuerst geprüft, ob `Test 123` wieder fehlerfrei aus der Personalkartei geöffnet werden kann. Anschließend wird P6.4 mit derselben TEST-Person fortgesetzt.
- PROD wird erst nach erfolgreicher TEST-Abnahme der neuen Einzelplatzlogik neu bereitgestellt.

## 87. P6.4 PRAKTISCHE NACHPRÜFUNG BESTANDEN – 27.08.2026 20:54

- Nach Bereitstellung von TEST `Code.gs` und `Index.html` Stand 20:31 wurde `Test 123` (`P00139`) in der Personalkartei erfolgreich geöffnet. Der zuvor durch die fehlerhafte Sammelplatzierung blockierte Personenaufruf funktioniert wieder.
- Für die praktische P6.4-Nachprüfung wurde `Test 123` am 27.08.2026 zunächst auf inaktiv gesetzt und am selben Kalendertag wieder reaktiviert. Dabei wurde die Gruppe `Minis` gewählt.
- Anschließende technische Prüfung des TEST-Blatts `Personenstatus`: Der vorherige aktive Status `PS00132` läuft vom 24.08.2026 bis 26.08.2026. Der neue aktive Status `PS00149` beginnt am 27.08.2026 und ist offen. Ein negativer Zeitraum `Gültig bis < Gültig ab` ist nicht entstanden.
- Damit ist der Fix für gleich­tägige Statuswechsel praktisch bestätigt. P6.4 ist erledigt.
- Nächster sinnvoller TEST-Punkt: P1.8 erneut praktisch abnehmen, da die bisherige Freigabe auf der inzwischen verworfenen Sammelplatzlogik 4/5 und 6/7 beruhte. Geprüft werden die Einzelplätze 1 bis 7 einschließlich Speichern und Wiederöffnen.



## 88. P1.8 EINZELPLÄTZE 1 BIS 7 PRAKTISCH BESTANDEN – 27.08.2026 21:02

- Nach Bereitstellung des TEST-Stands 20:31 wurde der Wettkampf `25.08.2026 · Test0009` geöffnet.
- Beim künstlichen TEST-Fall `Test 123` (`P00139`) war die zuvor nicht eindeutig rekonstruierbare Platzierung erwartungsgemäß leer.
- Der Nutzer wählte `4. Platz` und speicherte den Wettkampf erfolgreich. Die technische Rückprüfung im TEST-Blatt `Wettkampfteilnahmen` bestätigte für `P00139` den numerischen Wert `4`, nicht einen Datumswert.
- Nach Schließen und erneutem Öffnen des Wettkampfs blieb `4. Platz` korrekt markiert.
- Damit sind Darstellung, Speichern und Wiederöffnen der neuen Einzelplatzlogik praktisch bestätigt. P1.8 ist erneut erledigt.
- Die verworfenen Sammelplätze `4/5` und `6/7` bleiben dauerhaft außer Betrieb. Maßgeblich sind ausschließlich die Einzelplätze 1 bis 7 oder keine Platzierung.
- PROD-Code enthält dieselbe technische Einzelplatzlogik, wurde aber in diesem Arbeitsschritt nicht neu bereitgestellt.


## 89. P6.8 AUFFÄLLIGER WETTKAMPF-TESTWERT ERLEDIGT – 27.08.2026 21:02

- Der im Rahmen der TEST-Datenhygiene offen geführte auffällige Wettkampf-Testwert wurde mit der P1.8-Nachprüfung abschließend bewertet und bereinigt.
- Betroffen war der künstliche TEST-Fall `Test 123` (`P00139`) im Wettkampf `25.08.2026 · Test0009`. Der frühere Sammelwert `4/5` war von Google Sheets als Datum interpretiert worden.
- Der nicht eindeutig rekonstruierbare künstliche Wert wurde zunächst bewusst geleert. Anschließend wurde praktisch `4. Platz` neu gespeichert. Die technische Rückprüfung bestätigte den numerischen Wert `4`, und nach Wiederöffnen blieb `4. Platz` korrekt markiert.
- Die echten historischen Altwerte wurden bereits zuvor aus der Versionshistorie auf ihre ursprünglichen Einzelplätze zurückgeführt.
- Damit ist P6.8 erledigt. Historische numerische Einzelplätze 1 bis 7 bleiben ausdrücklich gültige Werte.


## 90. P6.7 TEST-DATENHYGIENE BEWUSST VERWORFEN – 27.08.2026

- Im TEST-Blatt `Personen` existieren zwei vollständig identische Zeilen mit der Personen-ID `P00140` für `Willi Witzig`. Beide besitzen außer den Basisnamensdaten keine Status-, Gruppen-, Kontakt- oder Anlagedaten.
- PROD besitzt keine doppelte Personen-ID.
- Nutzerentscheidung 27.08.2026: Dieser reine TEST-Datenfehler wird nicht weiter bereinigt. Sobald ein lauffähiger PROD-Endstand erreicht ist, wird der TEST-Datenbestand ohnehin mit dem geprüften PROD-Datenbestand überschrieben.
- Eine manuelle Bereinigung von `P00140` hätte deshalb keinen fachlichen oder betrieblichen Nutzen und wäre unnötige Arbeit am wegfallenden TEST-Datenbestand.
- P6.7 ist damit nicht technisch bereinigt, sondern fachlich als nicht mehr erforderlich verworfen und in der Live-Checkliste erledigt gesetzt.
- Die Entscheidung gilt ausdrücklich nur für diese reine TEST-Datenhygiene. Doppelte Personen-IDs in PROD oder ein nach dem späteren PROD→TEST-Abgleich erneut entstehender Duplikatfehler wären weiterhin ein echter Datenintegritätsfehler.

## 91. PROD-KANDIDAT KONSOLIDIERT UND PROJEKTSTAND ABGESCHLOSSEN – 27.08.2026 21:24

### 91.1 PROD-Stand
- Nutzerauftrag: den freigegebenen Stand für PROD konsolidieren und anschließend einen vollständigen Projektstand erzeugen.
- Die aktuellen PROD-Quellen `Code.gs` und `Index.html` tragen Stand `27.08.2026 20:31` und enthalten die in TEST praktisch bestätigten Korrekturen aus P6.4 sowie die Einzelplatzlogik 1 bis 7.
- Die Spalte `Wettkampfteilnahmen / Platzierung` in PROD ist bereits auf numerische Werte 1 bis 7 begrenzt. PROD enthielt bei der Prüfung keine beschädigten Sammelplatz-Datumswerte.
- `DateRangeDialog.html` bleibt unverändert.
- Die gebundene PROD-Web-App kann über den verfügbaren Drive-Arbeitszugriff nicht automatisch neu bereitgestellt werden. Die manuelle Übernahme der beiden aktuellen PROD-Quellen und die anschließende PROD-Bereitstellung bleiben deshalb der einzige noch notwendige technische Übergabeschritt für diesen Code-Stand.

### 91.2 Live-Checkliste konsolidiert
- Beim Abschlusslauf wurden alle 29 bereits gesetzten Erledigt-Checkboxen aus `Aktuell` in das Blatt `Erledigt` überführt.
- In `Aktuell` verbleiben nur offene oder wartende Punkte. Dazu gehören insbesondere P3.2, P4.1 bis P4.4, P5.2 bis P5.6, P6.3, P6.5, P6.9 und P6.10.
- P6.7 bleibt bewusst als verworfene reine TEST-Datenbereinigung abgeschlossen.

### 91.3 Projektstand und Sicherungen
- Aktueller Projektstand: `2026 08 27 21 24_SSV-Meschede_Judo_App_Projektstand.zip`.
- PROD-Live-Sheet und TEST-Live-Sheet wurden für den versionierten Drive-Sicherungsstand erneut als XLSX exportiert.
- Die beiden Liga-Live-Sheets wurden gemäß der allgemeinen Sicherungsregel ebenfalls erneut als XLSX gesichert. Liga-Code und Liga-Fachstand wurden dabei nicht verändert.
- Der Projektstand enthält den aktuellen PROD-XLSX-Snapshot und den nach der Checklisten-Konsolidierung neu erzeugten Checklisten-Snapshot.
- `Masterprompt.txt` ist unverändert.
- `Projektstand_erstellen_und_pruefen.py` wurde um konkrete Prüfpunkte für den gleich­tägigen Statuswechsel-Fix und die Einzelplatzoptionen 1 bis 7 ergänzt.

Sicherungsdatei:
- `2026 08 27 21 24_SSV-Meschede_Judo_App_Projektstand.zip`
- PROD-Snapshot SHA-256: `ceb69d556099e76318196ef7f3fe3bef3b881459d8df1061771ee9d8f64f8753`
- Checklisten-Snapshot SHA-256: `9bbfabc93dcf897432b033a1f9baaf26625064132856cfd6cefe27f10ec54a9a`
- PROD Code SHA-256: `f4b4fd0b868d23cc65e9b0af961527018dee05595db50d8be7191bda0fbb038a`
- PROD Index SHA-256: `91082e58b6d6e55d4c3cf723e066d09b58297a16f52142e8600c74b83697c78a`
- TEST Code SHA-256: `93c17f8bff52b6605af2f17bd662cbd2b93830542c565f464a286018448dc954`
- TEST Index SHA-256: `d65e061fb0773d4459dfa1b329bb01d0915a90bf45e62acf07a70429a3b9402f`

### 91.4 Nächster Schritt
- `PROD/Code.gs` und `PROD/Index.html` manuell in das gebundene PROD-Apps-Script-Projekt übernehmen und PROD neu bereitstellen.
- Danach zuerst P4.1 beziehungsweise die noch offenen produktionsnahen Punkte aus der Live-Checkliste bearbeiten.

## 92. P6.3 ARCHIVBEREINIGUNG UND P6.9 TAG-0-RESET – 27.08.2026

### 92.1 P4.1 und P4.2 aus der aktiven Prüfliste genommen
- Nutzerentscheidung 27.08.2026: P4.1 wird nicht vorab geprüft. Gebühren-PDF und Prüfungs-Mailtext werden erst kontrolliert, wenn tatsächlich eine Prüfung ansteht.
- P4.2 wird ebenfalls nicht als aktiver Prüfpunkt geführt. Der produktive persönliche Prüfungsversand wird erst beim nächsten realen PROD-Prüfungsvorgang kontrolliert.
- Beide Punkte sind damit keine offenen Arbeitsaufgaben mehr, sondern ausschließlich anlassbezogene Kontrollen.
- Die Live-Checkliste wurde entsprechend bereinigt.

### 92.2 P6.3 – 11 inaktive PROD-Personen kontrolliert archiviert
- Der Nutzer hat jeden der elf zuvor identifizierten Fälle einzeln geprüft und für die Archivierung freigegeben.
- Archiviert wurden:
  - `P00039` Jarno Ebermann
  - `P00040` Jarno Wiegele
  - `P00043` Joana Hilsmann
  - `P00058` Lars Paul
  - `P00069` Lio Joachimsmeier
  - `P00078` Maddox Brown
  - `P00088` Melih Boyali
  - `P00089` Michel Ebermann
  - `P00097` Niklas Hilleke
  - `P00099` Noel Langer
  - `P00102` Otto Sanchez Marcelo
- Vor der Änderung wurden die betroffenen PROD-Datensätze und ihre Abhängigkeiten kontrolliert. Es bestanden keine offenen aktuellen Gruppen- oder Zugangsdaten, die eine Archivierung blockieren.
- Die elf Personen wurden in `Archiv_Personen` übernommen und anschließend aus dem operativen Blatt `Personen` entfernt. Status- und Historienblätter wurden nicht gelöscht oder umgeschrieben.
- Technische Rückprüfung nach der Änderung: Alle elf Personen stehen genau im Archivbestand und nicht mehr im operativen Personenbestand.
- Archivierungszeitpunkt: 27.08.2026 22:20:39.
- P6.3 ist abgeschlossen.

### 92.3 P6.9 – einmaliger PROD-Tag-0-Reset ausgeführt
- Ziel bleibt: Bisherige Inaktivitätsmeldungen, alte 7-Tage-Fristen und noch aktive alte `PERSON_INAKTIV_AUTO`-Einmallinks gelten für die neue produktive Berechnung als nicht mehr maßgeblich. Der reguläre Nachtlauf soll danach nach dem aktuellen Regelwerk neu berechnen.
- Der Reset wurde direkt im aktuellen PROD-Datenbestand ausgeführt. Dadurch ist keine zusätzliche Apps-Script-Bereitstellung erforderlich und der Nachtlauf hängt nicht von einem neuen Deployment ab.
- Fünf noch aktive alte `PERSON_INAKTIV_AUTO`-Fälle wurden beendet: `P00035`, `P00067`, `P00075`, `P00090`, `P00092`.
- Diese Links sind nicht mehr aktiv. Sie wurden nachvollziehbar mit dem Ergebnis `Altvorgang vor Erstberechnung verworfen` abgeschlossen.
- Die im vorherigen Praxistest erzeugte Wiedervorlage `INAKTIV_WVL` für `P00062` wurde aufgehoben. Die alte Wiedervorlage bis 10.09.2026 wirkt damit nicht mehr auf die neue Berechnung.
- Die bereits wirksam entschiedene Einstufung von `P00122` als gelegentlicher Teilnehmer bleibt bewusst bestehen. Sie ist ein aktueller fachlicher Personenstatus und keine alte Frist oder offene Meldung.
- Technische Rückprüfung: Es bestehen keine noch aktiven alten `PERSON_INAKTIV_AUTO`-Falllinks aus dem zurückgesetzten Bestand und keine aktive alte Wiedervorlage für `P00062`.
- Der reguläre PROD-Nachtlauf am 28.08.2026 gegen 02:30 Uhr ist damit die erste Neuberechnung auf Basis des aktuellen Regelwerks. Die konkrete Zahl neu entstehender Fälle wird nicht vorweggenommen, weil sie aus dem dann aktuellen Datenbestand zu berechnen ist.
- P6.9 bleibt bis zur Kontrolle dieses Nachtlaufs in der Live-Checkliste `In Arbeit`. Nach erfolgreichem Lauf ist nur noch das Ergebnis zu bestätigen.

### 92.4 Maßgebliche Link- und Empfängerlogik
- Maßgeblich bleibt Abschnitt 72 in seiner aktuellen Fassung: je Person genau ein gemeinsamer Falllink und je Lauf eine Sammelmail an die konfigurierten Empfänger.
- Die ältere Idee mit je Empfänger getrennten Parallel-Links ist ausdrücklich verworfen.
- Im laufenden Arbeitsschritt wurde diese ältere Fassung zunächst kurz irrtümlich herangezogen. Der Fehler wurde vor einer Codeänderung erkannt und korrigiert.
- `Code.gs`, `Index.html` und `DateRangeDialog.html` wurden für P6.3/P6.9 nicht verändert. Insbesondere wurde keine Parallel-Link-Logik eingebaut.

### 92.5 Live-Checkliste und Projektstand
- Die native Live-Checkliste wurde aktualisiert: P4.1, P4.2 und P6.3 sind nicht mehr aktiv. P6.9 dokumentiert den ausgeführten Reset und wartet nur noch auf die Nachtlaufkontrolle.
- Der aktuelle PROD-XLSX-Snapshot wurde nach den Datenänderungen neu exportiert und zurückgelesen.
- Der aktuelle Checklisten-Snapshot wurde nach der Konsolidierung neu exportiert.
- Nutzerangabe vor diesem Arbeitsschritt: Der zuvor vorbereitete Code-Stand 20:31 ist vollständig eingespielt. Da in diesem Arbeitsschritt kein Code geändert wurde, ist keine erneute manuelle Bereitstellung erforderlich.
- `Masterprompt.txt`, PROD/TEST-Code, `Index.html`, `DateRangeDialog.html`, TEST-Datenbestand und Liga bleiben unverändert.

Drive-Arbeitsstand nach Umsetzung:
- Letzter unveränderlicher Projekt-ZIP bleibt `2026 08 27 21 24_SSV-Meschede_Judo_App_Projektstand.zip`.
- Für den Befehl `Umsetzen` wurde gemäß Masterprompt Abschnitt 28 kein neuer Abschluss-Projektstand erzeugt oder archiviert.
- PROD-Snapshot SHA-256: `713e71965dcd53e455eb628d90287308efc69e8700beb833f54b70f80996083e`
- Checklisten-Snapshot SHA-256: `adb29222817d63159f64dda19be2cc859caa512772bf5bd76300b9099855a8c6`
- PROD Code SHA-256: `f4b4fd0b868d23cc65e9b0af961527018dee05595db50d8be7191bda0fbb038a`
- PROD Index SHA-256: `91082e58b6d6e55d4c3cf723e066d09b58297a16f52142e8600c74b83697c78a`
- TEST Code SHA-256: `93c17f8bff52b6605af2f17bd662cbd2b93830542c565f464a286018448dc954`
- TEST Index SHA-256: `d65e061fb0773d4459dfa1b329bb01d0915a90bf45e62acf07a70429a3b9402f`

### 92.6 Nächster Schritt
- Nach dem regulären PROD-Nachtlauf vom 28.08.2026 zuerst P6.9 anhand des tatsächlich erzeugten Ergebnisses kontrollieren und anschließend abschließen.
- Bis dahin bleiben insbesondere P3.2, P4.3, P4.4, P5.2 bis P5.6, P6.5 und P6.10 offen beziehungsweise fachlich wartend.


## 93. GRATULATIONS-ABO UND GEBURTSTAGSDATEN – 27.08.2026 23:28

### 93.1 Verbindliche Fachlogik
- Das `Gratulations-Abo` steht ausschließlich Personen mit persönlichem Zugang und aktueller Rolle `Vorstand` oder `Admin` zur Verfügung. Aktuell sind dies maximal drei Personen.
- Das Abo ist für jeden berechtigten Zugang standardmäßig ausgeschaltet und wird von der Person selbst unter `Meine Einstellungen` ein- oder ausgeschaltet.
- Bei eingeschaltetem Abo sind drei Auswahlbereiche kombinierbar: `Trainerteam`, `Gelegentlich aktiv` und einzelne aktuell aktive Trainingsgruppen.
- `Trainerteam` umfasst aktuelle Trainer, Übungsleiter, Trainer-Assistenten sowie Personen mit Vorstand- oder Admin-Zugang. Mehrfachrollen führen nicht zu Doppelanzeigen.
- `Gelegentlich aktiv` ist ein eigener auswählbarer Bereich.
- Bei Trainingsgruppen werden nur aktuell aktive Gruppen angeboten. Die technische Gruppe `Selten da, aber immer wieder gern gesehen` wird nicht zusätzlich als normale Trainingsgruppe angeboten, weil sie bereits über `Gelegentlich aktiv` abgedeckt ist.
- Für ausgewählte Trainingsgruppen zählt die aktuelle Gruppenzuordnung. `Mitgliedschaft offen` ist kein Ausschlusskriterium.
- Eine Person, die über mehrere ausgewählte Bereiche passt, erscheint in der Mail nur einmal. Die zutreffenden Zugehörigkeiten werden gemeinsam angezeigt.
- Der eigene Geburtstag des Abonnenten wird nicht ausgefiltert. Wenn die Person selbst in ihrer Auswahl enthalten ist, erscheint sie ebenfalls.
- Pro Abonnent und Tag gibt es höchstens eine Sammelmail. Ohne passenden Geburtstag wird keine Mail verschickt.
- Die Mail zeigt je Treffer `Rufname + Nachname`, das neue Alter und die zutreffende Zugehörigkeit.

### 93.2 Datenmodell und Datenschutz
- Im Personenstamm wird bewusst nicht das vollständige Geburtsdatum gespeichert. Neu gespeichert wird nur `Geburtstag` als `TT.MM.`. Das bereits vorhandene `Geburtsjahr` wird für die Altersberechnung verwendet.
- Personen ohne verwertbaren Geburtstag oder ohne Geburtsjahr werden bis zur Nachpflege nicht im Gratulations-Abo berücksichtigt.
- `Geburtstag` wurde im PROD-Blatt `Personen` als zusätzliche Spalte am Tabellenende ergänzt. Diese Position ist technisch bewusst gewählt, damit bestehende Spaltenpositionen nicht verschoben werden.
- `Archiv_Personen` besitzt ebenfalls die zusätzliche Spalte `Geburtstag`, damit eine spätere Archivierung den Wert vollständig mitführt.
- `Zugänge` besitzt die neuen persönlichen Felder `Gratulations-Abo`, `Gratulations-Abo Trainerteam`, `Gratulations-Abo Gelegentlich aktiv` und `Gratulations-Abo Gruppen-IDs`. Bestehende Zugänge starten leer und damit ausgeschaltet.

### 93.3 Einmalige Übernahme der bekannten Geburtsdaten in PROD
- Quelle war die vom Nutzer bereitgestellte `Mitgliederverwaltung.xlsx` mit vollständigen Geburtsdaten im Blatt `Grunddaten`.
- Gegen den aktuellen operativen PROD-Personenbestand wurden ausschließlich eindeutig zuordenbare Fälle übernommen.
- Nach erneuter technischer Gegenprüfung sind 82 aktuelle Personen eindeutig mit einem Geburtstag versorgt. 28 aktuell geführte Personen bleiben bewusst ohne Geburtstag, weil keine sichere Zuordnung vorliegt.
- Nutzerkorrektur für `P00108` Rudin Hamo: `01.04.2005`.
- Nutzerkorrektur für `P00085` Samuel Hössel: Geburtstag `13.04.`, Geburtsjahr `2019`. Der Quelldateiwert 2029 wurde als offensichtlicher Jahresfehler verworfen.
- Für `P00116` Sven De Rudder wurde aus dem eindeutig zugeordneten Quelldatensatz zusätzlich das bisher fehlende Geburtsjahr `2012` ergänzt, damit das Alter berechnet werden kann. Geburtstag: `25.08.`.
- Bei dieser Jahresnachpflege wurde zunächst versehentlich die unmittelbar folgende Zeile `P00117` Sven Middel getroffen. Die Rückleseprüfung erkannte den Fehler sofort. Der Endzustand wurde kontrolliert korrigiert: `P00116` = 2012, `P00117` = 1978. Es besteht kein verbleibender Datenfehler aus diesem Zwischenstand.
- Die 28 nicht sicher zuordenbaren Personen bleiben unverändert ohne Geburtstag und werden vom Gratulations-Abo ignoriert.

### 93.4 Technische Umsetzung im Drive-Arbeitsstand
- PROD und TEST `Code.gs` wurden getrennt auf ihrem jeweiligen aktuellen Quellstand erweitert. Die beiden Dateien wurden wegen ihrer unterschiedlichen Ausgangsstände nicht blind gegeneinander ersetzt.
- Der Nachtlauf besitzt einen neuen Fachblock `Gratulations-Abo`. Er prüft nur eingeschaltete persönliche Abos von Vorstand/Admin und versendet nur bei Treffern.
- Fehlerhaft manuell eingetragene Geburtstagstexte oder ungültige persönliche E-Mail-Adressen werden für diesen Block sicher übersprungen, statt den gesamten Nachtlauf abzubrechen.
- `Index.html` besitzt für Vorstand/Admin im persönlichen Profilmenü die neue Aktion `Meine Einstellungen`. Dort wird das Gratulations-Abo mit den festgelegten Auswahlbereichen gepflegt.
- Die Personalkartei und die Personenanlage/-bearbeitung unterstützen das neue Feld `Geburtstag` im Format `TT.MM.`.
- TEST behält `EMAIL_ENABLED = false`. Ein TEST-Lauf darf daher auch mit eingeschaltetem Abo keine produktive Geburtstagsmail versenden.
- JavaScript-Syntax von PROD und TEST `Code.gs` wurde mit Node geprüft. Die JavaScript-Blöcke beider geänderten `Index.html` wurden nach Entfernung der Apps-Script-Template-Tags ebenfalls mit Node geprüft. Ergebnis: fehlerfrei.
- `DateRangeDialog.html` und `Masterprompt.txt` bleiben unverändert. Liga bleibt unberührt.

### 93.5 Bereitstellungsgrenze und nächster Schritt
- Der aktuelle Drive-Arbeitsstand von PROD und TEST `Code.gs` sowie `Index.html` trägt Stand `27.08.2026 23:26`.
- Die gebundenen Apps-Script-Projekte laufen weiterhin mit dem vorher bestätigten Stand 20:31. Über den verfügbaren Drive-Zugriff kann keine Apps-Script-Bereitstellung ausgelöst werden.
- Damit ist die Datenmigration in PROD real erfolgt und der neue Laufzeitcode im Drive-Arbeitsstand umgesetzt und technisch geprüft, aber noch nicht praktisch in TEST/PROD bereitgestellt.
- Live-Checkliste: neue Aufgabe `P6.11` `Gratulations-Abo` mit Status `In Arbeit`. Die frühere Schnellidee wurde aus `START` entfernt.
- Nächster praktischer Schritt: die neuen TEST-Dateien in das gebundene TEST-Apps-Script-Projekt übernehmen, TEST neu bereitstellen, die persönlichen Einstellungen als Vorstand/Admin praktisch prüfen und einen sicheren TEST-Simulationsweg für einen Geburtstag kontrollieren. Erst danach PROD-Code übernehmen.
- Der reguläre PROD-Nachtlauf vom 28.08.2026 bleibt parallel für P6.9 zu kontrollieren. Solange der Gratulations-Code nicht bereitgestellt ist, beeinflusst er diesen Lauf nicht.

## 94. GRATULATIONS-ABO – TESTFEHLER HAUPTSCHALTER KORRIGIERT – 27.08.2026 23:38

- Praktische TEST-Abnahme unmittelbar nach Erstbereitstellung:
  - In „Meine Einstellungen“ waren bei ausgeschaltetem Gratulations-Abo nicht nur die Detailauswahlen, sondern versehentlich auch der Hauptschalter selbst deaktiviert.
  - Sichtbares Symptom: Checkbox nicht anklickbar, Mauszeiger „nicht erlaubt“.
- Ursache eindeutig im `Index.html` eingegrenzt:
  - Die Hilfsfunktion für Mehrfachauswahl arbeitet global und ignoriert einen übergebenen Bereich.
  - Dadurch erfasste die Sperrlogik beim initial ausgeschalteten Abo alle Eingabefelder statt nur den Detailbereich unterhalb des Hauptschalters.
- Korrektur:
  - Sperrung jetzt ausdrücklich nur auf Eingabefelder innerhalb des Detailbereichs des Gratulations-Abos begrenzt.
  - Hauptschalter bleibt immer bedienbar.
  - Detailauswahlen bleiben bei ausgeschaltetem Abo bewusst deaktiviert und werden erst nach Einschalten aktiv.
- Geändert wurden ausschließlich die aktuellen `Index.html`-Arbeitsstände für TEST und PROD.
- `Code.gs` und `DateRangeDialog.html` blieben bei dieser Korrektur unverändert.
- PROD ist weiterhin nicht bereitgestellt. Die korrigierte TEST-Fassung muss erneut in das gebundene Apps-Script-Projekt übernommen und praktisch geprüft werden.


## 95. P6.11 TEST-SPEICHERFEHLER UND TAGESABSCHLUSS – 27.08.2026 23:48

### 95.1 Praktischer TEST-Stand
- Nach Übernahme des korrigierten TEST-`Index.html` wurde die Web-App erneut bereitgestellt.
- Der zuvor gesperrte Hauptschalter `Gratulations-Abo eingeschaltet` ist nun bedienbar. Damit ist der Fehler aus Abschnitt 94 praktisch behoben.
- Beim anschließenden Versuch, `Meine Einstellungen` über `Einstellungen speichern` zu sichern, erscheint reproduzierbar die Meldung `Error: Spalte fehlt: Zugänge / Sitzungsversion`.
- Dieser neue Fehler wurde am Tagesende bewusst nicht mehr analysiert oder repariert. Es wurde kein weiterer Codeversuch unternommen.

### 95.2 Verbindlicher Fortsetzungspunkt
- Morgen exakt bei P6.11 und diesem Speicherfehler weiterarbeiten.
- Zuerst den realen TEST-Sheet-Aufbau `Zugänge` und den Speicherschreibpfad der persönlichen Einstellungen prüfen. Dabei insbesondere klären, warum der Speichervorgang `Sitzungsversion` als fehlend meldet.
- Vor einer Codeänderung prüfen, ob die TEST-Sheet-Struktur gegenüber der neuen Codeerwartung unvollständig ist oder ob der neue Speicherschreibpfad einen falschen Headerkontext verwendet.
- Bis zur Ursachenklärung keine weiteren theoretischen Bedienprüfungen des Gratulations-Abos verlangen.
- Nach der Korrektur zuerst in TEST speichern, erneut öffnen und die Persistenz der Auswahl prüfen. Erst nach bestandener TEST-Abnahme den vorbereiteten PROD-Code übernehmen und PROD neu bereitstellen.

### 95.3 Aktueller Umgebungsstand
- TEST: `Code.gs` Stand 23:26 und korrigierter `Index.html` Stand 23:38 sind manuell bereitgestellt. P6.11 scheitert aktuell ausschließlich beim Speichern der persönlichen Gratulations-Abo-Einstellungen.
- PROD: gebundenes Apps-Script weiterhin Stand 20:31. Neue PROD-Quellen liegen im Drive, sind aber noch nicht bereitgestellt.
- PROD-Datenbasis: 82 eindeutige Geburtstage live, 28 bewusst leer. Neue `Geburtstag`- und Gratulations-Abo-Spalten sind live vorhanden.
- `DateRangeDialog.html`, `Masterprompt.txt` und Liga bleiben unverändert.
- Live-Checkliste P6.11 bleibt `In Arbeit` und enthält den exakten Speicherfehler als nächsten Arbeitsansatz.
- `Projektstand_erstellen_und_pruefen.py` wurde auf `RUNTIME_SCHEMA_VERSION 2026-08-27-04` sowie Pflichtprüfungen für das Gratulations-Abo aktualisiert.

### 95.4 Projektstand und Prüfsummen
- Aktueller Projektstand: `2026 08 27 23 48_SSV-Meschede_Judo_App_Projektstand.zip`.
- PROD-Snapshot SHA-256: `f463cdb260a0724f0410df08eddf7a40e7f648c17d9975811204a50ba8dd4fa9`
- Checklisten-Snapshot SHA-256: `94c8519f45a888ffcd337e659509db105a6d0f58867fb8c1588414fc10d4f1a0`
- PROD Code SHA-256: `5a08a734b084b56dc627ebdb7019c170f3fc6c77b617d352741b0cf6196395bd`
- PROD Index SHA-256: `fa0fced855b251d05c03147093bdb800f1f9ed3d6d223919e7d4fe7b0ee4e2cb`
- TEST Code SHA-256: `8206706ff570bfc7e8e31ce10b9a9b76e2fa2407ac22c2600193cd161332d469`
- TEST Index SHA-256: `2b6ee6eaf0b534ac4dd2897826101b92a1fa3aaa2562654c373c4bafe2c0db78`

## 96. P6.11 TEST-SCHEMAFEHLER EINDEUTIG BEHOBEN – 28.08.2026 05:26

### 96.1 Reale Ursache
- Das Live-TEST-Blatt `Zugänge` besaß nach der fehlerhaften Schemaergänzung nur zehn belegte Spalten. Spalte J trug den Header `Gratulations-Abo Gruppen-IDs`. `Sitzungsversion` sowie die drei übrigen Gratulations-Abo-Header fehlten.
- Die vorhandenen Sitzungsversionswerte waren nicht gelöscht. Sie standen weiterhin in Spalte J unter dem falschen Header.
- Ursache war `ensureGratulationSchema_()`: Nach dem Einfügen einer leeren Spalte rechts wurde erneut `getLastColumn()` verwendet. Da die neue Spalte noch leer war, zeigte `getLastColumn()` weiterhin auf die bisher letzte belegte Spalte. Deren Header wurde dadurch viermal überschrieben. Am Ende blieb dort nur der letzte Abo-Header stehen.
- Der Speicherschreibpfad `saveGratulationSettings()` verwendet anschließend den normalen vollständigen Zugangsschreibpfad. Dieser verlangt alle Pflichtheader und brach deshalb korrekt mit `Spalte fehlt: Zugänge / Sitzungsversion` ab. Ein falscher Headerkontext im Speicherschreibpfad lag nicht vor.

### 96.2 Korrektur ausschließlich in TEST
- TEST-`Code.gs` ergänzt neue Spalten jetzt über eine ausdrücklich berechnete Zielspalte rechts vom zuletzt belegten Header. Nach jeder Headeränderung wird der Headercache gezielt verworfen und der reale Stand neu gelesen.
- Der konkret festgestellte Fehlzustand wird idempotent erkannt: Fehlt `Sitzungsversion` direkt hinter `Letzter Login` und steht dort einer der neuen Abo-Header, wird der Header auf `Sitzungsversion` zurückgesetzt. Die bestehenden Werte bleiben an ihrer bisherigen Position erhalten.
- Die vier Abo-Spalten werden anschließend getrennt angelegt. Durch den fehlerhaften Einfügeversuch geerbte Zahlenvalidierungen werden aus diesen neuen Textspalten entfernt.
- `RUNTIME_SCHEMA_VERSION` wurde in TEST auf `2026-08-28-01` erhöht.
- Das reale TEST-Sheet `Zugänge` wurde auf die Headerfolge `Sitzungsversion`, `Gratulations-Abo`, `Gratulations-Abo Trainerteam`, `Gratulations-Abo Gelegentlich aktiv`, `Gratulations-Abo Gruppen-IDs` in J:N korrigiert. Sonstige Zugangsdaten blieben unverändert.
- PROD-Code und PROD-Sheet wurden ausdrücklich nicht verändert.

### 96.3 Bereitstellungs- und Abnahmegrenze
- Der korrigierte TEST-Quellstand liegt im Drive-Arbeitsstand. Er muss noch manuell in das gebundene TEST-Apps-Script-Projekt übernommen und neu bereitgestellt werden.
- Erst danach P6.11 praktisch prüfen: Einstellungen speichern, Dialog schließen, erneut öffnen und alle gespeicherten Auswahlwerte kontrollieren.
- Nach bestandener TEST-Abnahme muss PROD zwingend auf den bestätigten Gratulations-Abo-Stand gebracht werden. Erst danach beginnt ein weiterer Aufgabenblock.
- P6.11 bleibt bis zur praktischen TEST-Abnahme `In Arbeit`.

## 97. P6.11 ERWEITERTE TEST-SCHEMAREPARATUR – 28.08.2026 11:35

### 97.1 Praktisch bestätigte Einstellungspersistenz
- Der Nutzer übernahm den korrigierten TEST-`Code.gs`, stellte TEST neu bereit und meldete sich als Admin an.
- Der Hauptschalter ließ sich ohne Fehler speichern und blieb nach erneutem Öffnen gesetzt.
- Anschließend wurden `Trainerteam`, `Gelegentlich aktiv` und die aktive Gruppe `Fortgeschrittene` gespeichert.
- Die Rückleseprüfung im realen TEST-Blatt `Zugänge` bestätigte für Zugang `Z00014` die Werte `X`, `X`, `X` und Gruppen-ID `G00003`. Damit ist der bisherige Speicherfehler praktisch behoben.

### 97.2 Zusätzlich festgestellter alter Schemafehler
- Vor dem sicheren Geburtstagstestlauf wurden die realen TEST-Blätter `Personen` und `Archiv_Personen` kontrolliert.
- In `Personen` stand der Header `Geburtstag` in Spalte AE über den weiterhin vollständig vorhandenen Werten von `Zuletzt geändert von`. Eine getrennte Geburtstagsspalte fehlte.
- In `Archiv_Personen` stand der Header `Geburtstag` in Spalte AG über den weiterhin vollständig vorhandenen Werten von `Archiviert von`. Eine getrennte Geburtstagsspalte fehlte ebenfalls.
- Ursache war derselbe bereits bei `Zugänge` nachgewiesene Fehler der früheren Spaltenergänzung. Datenwerte wurden nicht gelöscht, sondern nur durch falsche Header fehlinterpretiert.

### 97.3 Korrektur ausschließlich in TEST
- Das reale TEST-Blatt wurde rücklesend repariert. `Personen` besitzt jetzt in AD:AF `Zuletzt geändert am`, `Zuletzt geändert von`, `Geburtstag`. `Archiv_Personen` besitzt in AF:AH `Archiviert am`, `Archiviert von`, `Geburtstag`.
- Alle 118 gelesenen Ändererwerte in `Personen` und alle 6 Archivierungswerte in `Archiv_Personen` blieben erhalten. Die neuen Geburtstagsspalten sind im TEST zunächst leer.
- Filter- und Überschriftenschutz des Blatts `Personen` wurden bis zur neuen Spalte AF erweitert.
- TEST-`Code.gs` erkennt und repariert nun auch diese beiden exakt festgestellten Fehlzustände idempotent. `RUNTIME_SCHEMA_VERSION` wurde auf `2026-08-28-02` erhöht.
- JavaScript-Syntaxprüfung mit Node: fehlerfrei. TEST-Unterordnerdatei `Code.gs` und Arbeitszwilling `01_Test_Code.gs.txt` wurden in Drive inhaltsgleich aktualisiert.
- PROD-Code und PROD-Sheet blieben unverändert.

### 97.4 Fortsetzungspunkt
- TEST-`Code.gs` Stand 28.08.2026 11:35 muss noch manuell in das gebundene TEST-Projekt übernommen und neu bereitgestellt werden.
- Danach folgt der sichere TEST-Simulationslauf mit einem passenden Geburtstag. Wegen `EMAIL_ENABLED = false` darf keine Mail versendet werden.
- P6.11 bleibt bis zu diesem Testlauf `In Arbeit`. Danach muss vor jedem weiteren Aufgabenblock PROD auf den bestätigten Stand gebracht werden.

## 98. PERSONALKARTEI – GEBURTSTAGSANZEIGE IM KOPF – 28.08.2026 18:01

- Vom Nutzer für den nächsten Bearbeitungsblock vorgemerkt.
- Aktueller TEST-Screenshot: Unter dem Namen zeigt die Personalkartei `Geburtstag 2026-08-28`.
- Gewünschte Darstellung an dieser Stelle: `Geburtstag 28.08.`. Es soll nur Tag und Monat erscheinen, passend zum bewusst gespeicherten Datenmodell `TT.MM.`.
- Diese Anzeige wird nicht in den laufenden P6.11-Test eingeschoben. Reihenfolge bleibt verbindlich: P6.11 abschließen, PROD auf den bestätigten Stand bringen, erst danach diesen neuen Aufgabenblock beginnen.

## 99. P6.11 ÖFFENTLICHER TEST-PRÜFLAUF – 28.08.2026 18:03

- Eigener Anweisungsfehler offen dokumentiert: Der Nutzer wurde aufgefordert, `runBirthdayCongratulations_` im Apps-Script-Editor auszuwählen. Funktionen mit abschließendem Unterstrich sind private Hilfsfunktionen und erscheinen dort nicht als auswählbarer Einstiegspunkt. Diese Anweisung war falsch und wiederholte einen bereits früher aufgetretenen Fehlertyp.
- Korrektur ausschließlich in TEST: neuer öffentlicher Einstiegspunkt `testBirthdayCongratulations` ohne abschließenden Unterstrich.
- Der Einstiegspunkt ist hart auf `APP.ENVIRONMENT === 'TEST'` begrenzt, ruft die reale Gratulationslogik auf und protokolliert sichtbar `Abos`, `Treffer` und `Mails`.
- TEST behält `EMAIL_ENABLED = false`. Erwarteter Mailwert ist deshalb zwingend `0`.
- TEST-`Code.gs` Stand 28.08.2026 18:03 wurde syntaktisch geprüft und in Drive sowohl im TEST-Unterordner als auch im Arbeitszwilling inhaltsgleich aktualisiert.
- PROD blieb unverändert. Der öffentliche TEST-Prüflauf wird nicht als produktiver Bedienweg übernommen.

## 100. P6.11 TEST-PRÜFLAUF – FEHLENDE STATUSHILFE KORRIGIERT – 28.08.2026 18:07

- Der öffentliche Prüflauf wurde praktisch gestartet und erreichte die reale Gratulationslogik.
- Er brach am Ende mit `ReferenceError: automationStatusWrite_ is not defined` ab. Ursache: Diese PROD-Statushilfe ist im schlankeren TEST-Code nicht vorhanden, wurde vom neu ergänzten Gratulationsblock aber ungeschützt aufgerufen.
- Korrektur ausschließlich in TEST: Der Automatikstatus wird nur in PROD geschrieben. Die eigentliche TEST-Auswertung und der öffentliche Prüflauf bleiben vollständig aktiv und protokollieren ihr Ergebnis sichtbar.
- Bewusst kein allgemeiner `typeof`-Schutz: In PROD bleibt die Statushilfe zwingende Abhängigkeit, damit ein echter PROD-Strukturfehler nicht verdeckt wird.
- TEST-`Code.gs` Stand 28.08.2026 18:07 wurde syntaktisch geprüft und in beiden Drive-Arbeitsdateien aktualisiert. PROD blieb unverändert.

## 101. P6.11 TEST-PRÜFLAUF – GEBURTSTAGSWERT NORMALISIERT – 28.08.2026 18:11

- Der korrigierte öffentliche Prüflauf wurde praktisch vollständig ausgeführt. Ergebnis: `Abos: 1 · Treffer: 0 · Mails: 0`.
- `Abos: 1` und `Mails: 0` bestätigen die aktive persönliche Einstellung sowie die TEST-Mailsperre. `Treffer: 0` war trotz Testgeburtstag `28.08.` fachlich falsch.
- Reale Ursache: Google Sheets hatte die Eingabe `28.08.` im TEST als vollständigen Datumswert gespeichert. Dies war bereits an der Personalkartei-Anzeige `2026-08-28` erkennbar. Die Gratulationslogik akzeptierte bisher ausschließlich Text im Format `TT.MM.` und verwarf den Datumswert deshalb sicher, aber fachlich ungewollt.
- Korrektur ausschließlich in TEST: Geburtstage werden nun sowohl als echtes Sheets-Datum als auch als Text sicher auf `TT.MM.` normalisiert.
- Einmalige TEST-Schemamigration `BIRTHDAY_TEXT_SCHEMA_V1` wandelt vorhandene Datumswerte in kanonischen Text `TT.MM.` um und formatiert die Geburtstagsspalten von `Personen` und `Archiv_Personen` als Text. `RUNTIME_SCHEMA_VERSION` wurde auf `2026-08-28-03` erhöht.
- Erwarteter nächster Prüflauf: `Abos: 1 · Treffer: 1 · Mails: 0`.
- PROD-Code und PROD-Sheet blieben weiterhin unverändert. Vor der späteren PROD-Bereitstellung muss dieselbe robuste Normalisierung in den getrennten PROD-Code übernommen und gegen die 82 realen Geburtstagseinträge geprüft werden.

## 102. P6.11 TEST BESTÄTIGT UND PROD-QUELLEN ANGEGLICHEN – 28.08.2026 18:52

### 102.1 Abschließende TEST-Abnahme
- Der öffentliche Prüflauf `testBirthdayCongratulations` wurde nach der Geburtstagsnormalisierung erneut ausgeführt.
- Praktisches Ergebnis: `Abos: 1 · Treffer: 1 · Mails: 0`.
- Damit sind die gespeicherte persönliche Auswahl, die fachliche Trefferermittlung und die TEST-Mailsperre bestätigt.
- Der öffentliche TEST-Einstiegspunkt wird nicht in PROD übernommen. Der produktive Nachtlauf verwendet weiterhin ausschließlich die interne Fachfunktion.

### 102.2 Reale PROD-Sheet-Prüfung vor der Übernahme
- Das native PROD-Sheet `PROD_Judo App 2.0` wurde erneut direkt geprüft.
- `Zugänge` besitzt die vollständige reale Headerfolge einschließlich `Sitzungsversion` sowie aller vier Gratulations-Abo-Spalten. Der in TEST aufgetretene Fehlzustand liegt in PROD nicht vor.
- `Personen` und `Archiv_Personen` besitzen jeweils eine getrennte Geburtstagsspalte.
- Genau 82 Geburtstagswerte sind vorhanden. Alle 82 sind bereits Textwerte im Format `TT.MM.`; kein Wert liegt als Google-Sheets-Datumsobjekt vor.
- Das PROD-Sheet wurde deshalb nicht verändert. Die 28 bewusst ungeklärten Geburtstage bleiben leer.

### 102.3 Angeglichener PROD-Quellstand
- PROD-`Code.gs` Stand 28.08.2026 18:51 enthält die bestätigte robuste Headerreparatur, die sichere Behandlung echter Sheets-Datumswerte und die einmalige Textformat-Migration für Geburtstagsspalten.
- `RUNTIME_SCHEMA_VERSION` wurde in PROD auf `2026-08-28-04` erhöht.
- Der Produktivlauf schreibt seinen Automatikstatus weiterhin zwingend über die vorhandene PROD-Statushilfe. Der TEST-spezifische öffentliche Prüflauf ist in PROD nicht enthalten.
- PROD-`Index.html` Stand 28.08.2026 18:51 enthält den bereits in TEST bestätigten bedienbaren Gratulations-Abo-Hauptschalter.
- Syntaxprüfung von PROD-`Code.gs` mit Node: fehlerfrei.
- PROD-Unterordnerdateien und die Arbeitszwillinge `01_Prod_Code.gs.txt` / `02_Prod_Index.html.txt` wurden jeweils inhaltsgleich im Drive aktualisiert.
- Prüfsummen: PROD Code `442bd4ccd6ed8dffec6046d4daeb2edf72b076c3c7ad53a09f21c07ed6fb7783`; PROD Index `18a470e741343b7e48b23622c8c2b8979be0b42dcca6d78ad47e5f75dc28f994`.

### 102.4 Bereitstellungsgrenze
- Das gebundene PROD-Apps-Script-Projekt wurde über den verfügbaren Drive-Zugriff nicht bereitgestellt.
- Nächster Schritt: beide PROD-Dateien manuell in das gebundene PROD-Projekt übernehmen und neu bereitstellen.
- P6.11 bleibt bis zur Bestätigung dieser PROD-Bereitstellung `In Arbeit`.
- Erst danach beginnt der vorgemerkte nächste Aufgabenblock zur Geburtstagsdarstellung im Kopf der Personalkartei.

## 103. P6.9, P6.10, P6.11 UND PERSONALKARTEI – QUELLSTAND 28.08.2026 19:57

### 103.1 Bestätigter Ausgangsstand
- PROD und TEST wurden durch den Nutzer mit dem P6.11-Stand vollständig neu bereitgestellt. Der anschließende PROD-nach-TEST-Datenabgleich wurde kontrolliert. P6.11 ist damit abgeschlossen.
- Der PROD-Nachtlauf vom 28.08.2026 scheiterte ausschließlich an einem vorübergehenden Google-Mailfehler. Der manuelle Nachhollauf an beide hinterlegten Empfänger war erfolgreich. P6.9 ist abgeschlossen.
- Ein automatischer erneuter Versand der vollständigen Nachtlauf-Mail nach Mailfehlern wird auf ausdrückliche Entscheidung des Nutzers nicht umgesetzt. Die Fachmeldungen bleiben über Glocke und Starthinweise verfügbar.
- P5.2 `Kurzanleitung Trainerteam` wird auf ausdrückliche Nutzerentscheidung als erledigt geführt.

### 103.2 P6.10 umgesetzt
- Wenn im Systemstatus der bestehende Inhaltsblock `Inaktivität` ausgewählt ist, enthält die PROD-Systemstatus-E-Mail nun zusätzlich den Abschnitt `Fällige offene Mitgliedschaften`.
- Aufgeführt werden nur aktuell fällige offene Mitgliedschaften. Aktive Wiedervorlagen bleiben bis zum Fälligkeitstag ausgeblendet. Danach erscheint der Fall wieder.
- Die bereits bestehende Wiedervorlage für zwei Wochen und sechs Wochen bleibt unverändert fachlich wirksam. Es war keine neue Sheet-Spalte erforderlich.
- Die TEST-Systemstatus-Simulation bildet denselben Abschnitt ab, versendet aber weiterhin keine E-Mail.

### 103.3 Personalkartei in PROD und TEST überarbeitet
- Der Geburtstag wird im Kopf robust als `TT.MM.` ausgegeben, unabhängig davon, ob Google Sheets intern Text oder einen Datumswert liefert.
- Die Kachel `PIN ändern` wurde aus der Personalkartei entfernt. Der persönliche PIN-Wechsel bleibt ausschließlich über das Drei-Punkte-Menü erreichbar.
- `Abrechnung & Ehrenamt` wird nur noch angezeigt, wenn die dargestellte Person eine Trainerqualifikation besitzt und der angemeldete Nutzer die Personalkartei verwalten darf.
- Die bisher reine Kachel `Wertungspunkte YYYY` ist jetzt bedienbar. Sie enthält die vollständige Wettkampfzusammenfassung und öffnet dieselbe Wettkampfübersicht wie die entfernte untere Kachel `Wettkämpfe`.
- Die unteren Kacheln `Wettkämpfe` und `PIN ändern` entfallen vollständig.
- Die verbleibenden Auswertungsverweise `Teilnehmerstatistik` und `Erfolgreichster Wettkämpfer` sind als gleich große Zweispalten-Kacheln ausgerichtet. Auf schmalen Ansichten stehen sie weiterhin untereinander.

### 103.4 Prüfung und Bereitstellungsgrenze
- PROD- und TEST-`Code.gs` wurden jeweils vollständig syntaktisch geprüft.
- Alle eingebetteten JavaScript-Blöcke beider `Index.html`-Dateien wurden syntaktisch geprüft.
- Strukturprüfungen bestätigen die neue Wettkampf-Kachel, das qualifikationsabhängige Ehrenamt, das Entfernen beider unteren Kacheln und das Zweispaltenlayout der Auswertungsverweise.
- Die Arbeitsdateien sind vorbereitet. Die praktische Abnahme beginnt nach manueller Übernahme und Bereitstellung der jeweils eigenen PROD- und TEST-Dateien.
- `DateRangeDialog.html` und `Masterprompt.txt` blieben unverändert.

## 104. PRAKTISCHE ABNAHME UND PROJEKTSTAND – 28.08.2026

### 104.1 Praktische Abnahme nach Bereitstellung
- Der Nutzer hat die getrennten PROD- und TEST-Quellen des Quellstands 28.08.2026 19:57 vollständig in die gebundenen Apps-Script-Projekte übernommen und beide Umgebungen neu bereitgestellt.
- Die Personalkartei wurde praktisch geprüft. Bestätigt sind: Geburtstag im Kopf als `TT.MM.`, korrekte Sichtbarkeit `Abrechnung & Ehrenamt` nur bei Trainerqualifikation, entfernte Kachel `PIN ändern`, entfernte untere Kachel `Wettkämpfe`, bedienbare obere Wertungspunkte-/Wettkampf-Kachel sowie zwei gleich große und gleichmäßig positionierte Auswertungskacheln.
- P6.10 wurde praktisch bestätigt und vom Nutzer als erledigt bewertet. Der Systemstatus-Inhaltsblock `Inaktivität` bildet fällige offene Mitgliedschaften korrekt ab. Wiedervorlagen bleiben wirksam.
- P6.9, P6.10 und P6.11 sind abgeschlossen. P5.2 ist auf ausdrückliche Nutzerentscheidung abgeschlossen.
- Abschnitt 103.4 ist damit überholt: Die dort noch offene praktische Abnahme und Bereitstellung ist erfolgt.

### 104.2 Neuer offener UI-Punkt
- Im letzten P6.10-Prüflauf fiel auf, dass der Auswahlzustand des betreffenden Auswahlfelds/der Checkbox im Systemstatus optisch nicht eindeutig erkennbar ist.
- Funktional wurde kein Fehler der P6.10-Logik festgestellt. Der Punkt wird als eigenständige UI-Verbesserung für einen späteren Umsetzungslauf offen gehalten.

### 104.3 Checklisten-Grenze
- Die in Drive liegende XLSX-Checkliste ist unverändert der Snapshot vom 27.08.2026 und enthält für P5.2 sowie P6.9, P6.10 und P6.11 noch veraltete Statusangaben.
- Diese vier Statusangaben sind durch Abschnitt 104 verbindlich überholt und dürfen nicht erneut als offen behandelt werden.
- Die XLSX wurde bei diesem Projektstand bewusst nicht umgeschrieben, weil eine verlustfreie Bearbeitung der enthaltenen Google-spezifischen Formeln mit dem verfügbaren XLSX-Editor nicht sichergestellt werden konnte.

### 104.4 Vollständiger Projektstand
- Neue vollständige Projekt-ZIP: `2026 08 28 20 45_SSV-Meschede_Judo_App_Projektstand.zip`.
- Grundlage sind die aktuellen Dateien aus `Aktueller Projektstand/Judo App` sowie die in diesem Abschnitt konsolidierte Übergabedokumentation.
- PROD- und TEST-Arbeitszwillinge wurden gegen die jeweiligen Unterordnerdateien geprüft und sind bytegleich.
- Liga wurde weder gelesen noch verändert, soweit dies für die Judo-Projektstand-Erzeugung nicht erforderlich war.
- PROD-Snapshot SHA-256: `f463cdb260a0724f0410df08eddf7a40e7f648c17d9975811204a50ba8dd4fa9`
- Checklisten-Snapshot SHA-256: `94c8519f45a888ffcd337e659509db105a6d0f58867fb8c1588414fc10d4f1a0`
- PROD Code SHA-256: `a44e34aa3fb863c14b1d84135afaa8739c390c2f7033e2121fb9c51a964fd634`
- PROD Index SHA-256: `4690330d0fc09203a44d1927fb6e8912bac783f4325ed804fe35bf04442478ff`
- TEST Code SHA-256: `7447a0879928ff4c07f33774f2d811b746234c261ff6edbb42363fe4d6ace2bf`
- TEST Index SHA-256: `218bcd5d3ac4663ec8af23012d636403b5d67892032705967b5fddff7da1dc46`


## 105. STRATEGISCHE MIGRATION WEG VON GOOGLE APPS SCRIPT – 28.08.2026

### 105.1 Entscheidung
- Die Judo-App soll aus Google Apps Script herausgeführt werden.
- Kurzfristig dient ein vorhandener Linux-Laptop als Testserver. Raspberry Pi 4B bleibt Reserve. Ein Mini-PC wird nur bei nachgewiesenem Vorteil beschafft.
- Die bestehende PROD-App bleibt während der Migration unverändert in Betrieb und Rückfallstand.

### 105.2 Zielarchitektur Phase 1
- Node.js 24 LTS.
- SQLite als lokale Datenbank.
- systemd für automatischen Dienststart.
- Tailscale Serve für privaten HTTPS-Fernzugriff ohne Router-Portfreigabe.
- Serverbindung ausschließlich an localhost.

### 105.3 Bestandsbewertung und Grenze
- `Index.html` besitzt einen zentralen `google.script.run`-Wrapper, wodurch die Browserkommunikation später zentral auf HTTP umgestellt werden kann.
- Die aktuelle Oberfläche nutzt 188 unterschiedliche RPC-Aufrufe.
- `Code.gs` ist stark an Apps-Script-Dienste gekoppelt. Ein vollständiger Big-Bang-Umbau ist unter Zeitdruck nicht vertretbar.
- Phase 1 prüft deshalb ausschließlich Server, reale Datenübernahme, Autostart und Fernzugriff. Fachfunktionen werden anschließend modulweise portiert.
