# Vorrangiger U03-Nachtrag · Technische Fehlerkorrektur
Stand: 09.10.2026, Europe/Berlin. Auftrag: U03 Zugang, Personenakte und Rollenlauf fortsetzen.

In PR 163 sind die Personenakten-API und die physische Rollenvergabe konkret korrigiert:
- Neue gemeinsame Zugangsprüfung verwendet auth.getUser() und has_active_membership mit tatsächlicher Sitzungs-ID.
- Fehlende/ungültige Sitzung: 401. Angemeldet ohne aktiven Vertrag: 403. Auth-, Konfigurations- oder Datenbankausfall: 503. Unbekannte Fehler halten den Zugriff geschlossen.
- Personenakten- und Rollenfehlerantworten enthalten keine internen Helfer-/Datenbankdetails. Eigene Aktenantworten sind private/no-store.
- Ursprungsschutz, erlaubte Rollen, UUID-Prüfung und tatsächlicher Rollenvergeber bleiben erhalten.
- 22 gezielte Regressionstests lokal bestanden, 0 Fehler. Auth und Datenbank sind in diesen Tests simuliert; keine echte Anmeldung, Kontoänderung oder Rollenvergabe.
- Die Tests sind an die bestehende CI angeschlossen. Vollständige Typ-/Build-/Browserprüfung des neuen Heads wird separat geprüft.
- Der bestehende zentrale Auth-Helfer und die Proxy-Weiterleitung sind unverändert; die dort dokumentierte Fehlerdarstellung sowie weitere API-Wege bleiben eigene Restarbeit. Diese Korrektur gilt ausdrücklich für die beiden genannten APIs.
- Kein Merge, keine Produktionsumschaltung und keine Änderung von Konto, Originalen, Vertrag oder Rollen.

Status: **Zugangs-/Rollenfehler der beiden APIs korrigiert; realer Kontodurchlauf offen.** Der nachfolgende ursprüngliche Bericht bleibt als Prüfgrundlage erhalten. Seine Aussage „Laufzeitdateien nicht verändert“ beschreibt den vorherigen Arbeitsgang und gilt nicht für diesen Nachtrag.

---

# CHA · U03 · Zugang, Personenakte und Rollenabläufe
Akten-Kennung: CHA-PAH-1883-U03-2026-10-09
Stand: 09.10.2026, Europe/Berlin.
Status: Regeln und Ablauf zugeordnet; 15 isolierte Prüfungen bestanden; tatsächlicher Kontodurchlauf offen.

## Ziel und Prüfgrundlage
U03 konkretisiert U02 für Anmeldung, bestehende Registrierung, Personenakte und fachliche Berechtigungen. Hauptcode: b606fe77fa0eccfc2e63e491710fa37f3545843c. Aufbauplan-Ausgangsstand: 385d4512fd5736f85f12b4035d654618e89d1e01 in PR 163. Redaktion wird getrennt anhand PR 167, Head 8d56f5a61132c9f115d7e0daeb725e652b7faa6b, betrachtet.

Geprüft wurden Serverauthentifizierung, Anmeldeaktion/-formular, Callback, interne Weiterleitung, proxy.ts, Personenaktenseite/-API/-Helfer, Vertragsannahme/-beleg, Bestands-/Leitungsprüfung, physische Rollenvergabe und zugehörige SQL-Quelldateien. Ergänzend wurden die bestehenden Auth-, Mitgliedschafts- und Parcours-Zugangstests gelesen. Der erfolgreiche Hauptstand-CI-Lauf 37691053998 einschließlich Typprüfung, Build und vollständiger Playwright-Probe wurde mit seinen Schritten erneut abgerufen.

Diese Prüfung verändert kein Konto, keinen Vertrag und keine Rolle. Die unten angegebenen Datenbankregeln sind aus Migrationen gelesen; aktuelle produktive Policies wurden in diesem Arbeitsgang nicht erneut abgefragt. Synthetische Tests sind keine tatsächlichen Auth-/Datenbank-/Betriebsereignisse.

## 1. Nachvollziehbare Zustände
| Zustand | Erforderlicher Nachweis | Zulässiger nächster Schritt |
|---|---|---|
| Besucher | keine Sitzung | Office, freigegebene Orientierung und öffentliche Rechts-/Erklärungseingänge |
| Registrierungsentwurf | bestehender Vorgangsbezug | Fortführung desselben Vorgangs; keine aktive Mitgliedschaft daraus ableiten |
| E-Mail/Konto bestätigt | tatsächliche Auth-/DOI-Zuordnung | Registrierung prüfen; Anmeldung ist noch keine Vertragsannahme |
| Angemeldet | Server prüft auth.getUser() | eigene Antrags-/Vertragswege; Fachrechte gesondert prüfen |
| Bestandsagent bestätigt | dokumentierte approved-Bestandsprüfung | passende Bestandskonditionen; aktive Vertragszuordnung und weitere Fachrechte bleiben erforderlich |
| Bestellung/Zahlung zugeordnet | gebundene Fassung, bestätigter Vorgang | ausdrückliche Betreiberannahme; Zahlung allein gibt keinen Mitgliederzugang |
| Vertrag angenommen/zeitlich aktiv | Annahmebeleg plus gültiger Vertragszugang | geschützter Mitgliederbereich |
| Fachlich berechtigt | zusätzlich passende aktive Rolle / fallbezogene Berechtigung | nur zugelassene Prüfung, Redaktion, Parcours oder physische Fachaktion |
| Vertrag beendet/abgelaufen | tatsächlicher Vertragsstatus und Zeitraum | Mitgliederbereich geschlossen; eigener Vertragsbeleg und öffentlicher Erklärungseingang bleiben getrennt erreichbar |
| Systemfehler | Auth-/Datenbankausfall | keine Umgehung oder neue Registrierung erzwingen; Fehler bearbeiten und erneut prüfen |

Zustände sind ein Arbeitsmodell. Die tatsächlichen Tabellenwerte, Übergangszeitpunkte und Originale müssen am bestehenden Konto bestätigt werden.

## 2. Rollen- und Zugriffsmatrix
| Rolle / Merkmal | Zugang | Personenakte / Belege | Fachaktionen | Zusätzliche Prüfung |
|---|---|---|---|---|
| Besucher | öffentliche Wege | keine privaten Akten | keine | anonyme API-Abweisung |
| Angemeldete Person ohne aktiven Vertrag | Konto-/Registrierungswege | eigener Vertragsbeleg über /api/mitgliedschaft/beleg bei vorhandenem Beleg; Mitglieder-Personenakte bleibt geschlossen | keine Mitgliedsfachaktion | Benutzerfilter, Annahmebeleg und Zeitraum |
| Aktives Mitglied | Mitgliederwege | eigene Akte / eigene Belege | freigegebene Mitgliedsaktionen | eigene/fremde Daten getrennt |
| Bestätigter Bestandsagent | aktive Vertragszuordnung weiterhin erforderlich | eigene Akte; Bestandsstatus separat | Parcours nur mit bestätigter persönlicher Berechtigung | keine automatische Ernennung aus Badge, Alias oder Zahlung |
| Agent ab Rang 3 / Mitglied nach sechs Monaten als Assistent | aktive Mitgliedschaft | eigene fallbezogene Unterlagen | Parcours nach persönlicher Zulassung | Eintrittsregel auch serverseitig/SQL im realen Lauf prüfen |
| Aktiver Director | Sitzung plus aktive directors-Zuordnung | kein pauschaler Zugriff auf beliebige persönliche Originale aus der Rollenbezeichnung ableiten | Redaktion nach PR-167-Regel; weitere Fachfunktionen separat | echte Operator-ID; Rollen-/Versionskonflikte |
| Persönliche Plattformleitung | ALLAN_PINKERTON_AUTH_USER_ID plus aktive directors-Zeile rang=leitung | im vorgesehenen Prüfverfahren | Betreiberannahme und Leitungsvorgänge | persönliche Kennung und Rolle gemeinsam erforderlich |
| Maxwell, technische physische Rolle | Sitzung, aktive Mitgliedschaft für entsprechende API und gespeicherte Fachrolle | SQL-Grundlage enthält pa_read_maxwell zusätzlich zur Eigentümerpolicy | Field-Day-/Abschlussdepeschenwege nach Fachregel | Sonderleserecht ausdrücklich prüfen; Maxwell-Darstellung ersetzt keine menschliche Zuständigkeit |
| Tafel-Director | Sitzung, aktive Mitgliedschaft, physische Rollenberechtigung | kein allgemeines Originalaktenrecht aus dieser Rolle | Vergabe der erlaubten physischen Rollen über RLS | tatsächlicher granter aus Sitzung; Ursprung und Zielbezug prüfen |
| Field Lead / weitere Einsatzrolle | aktive Mitgliedschaft und konkrete Einsatzzuordnung | eigene Einsatz-/Abschlussbelege | jeweils zugelassene Einsatzhandlung | rollen- und terminbezogene Grenzen prüfen |
| Investor | organisatorische Entscheidung, kein automatisch vergebenes Kontorecht | nur durch ausdrücklich passende technische Berechtigung | Budget-/Angebotsentscheidung | keine technische Administratorrolle aus Investorbezeichnung |

**Wichtige Präzisierung:** „Fremde Akte gesperrt“ gilt für gewöhnliche Mitglieder. Die gelesene SQL-Grundlage sieht für Maxwell ein besonderes Leserecht vor. Der eigene Aktenhelfer filtert dennoch auf die tatsächliche Sitzungs-ID. Ob und wie dieses Sonderrecht aktuell installiert ist, gehört in die reale Rollenabnahme.

## 3. Bestehenden Vorgang 0001 fortführen
1. Bestehendes Konto anhand der tatsächlich bestätigten Benutzer-ID und E-Mail zuordnen; keine zweite Mitgliedschaft erzeugen.
2. Bestehenden Registrierungsdatensatz mit Vorgang 0001 verknüpfen und Dublette ausschließen.
3. Bereits dokumentierte Nutzerbestätigung über geleistete Unterschriften beachten. Konkrete unterschriebene Fassungen, Zeitpunkt und Herkunft gesondert zuordnen; keine Unterschriften nachbilden.
4. Aktuelle Stammdaten gezielt abgleichen; persönliche/betriebliche Bankzuordnungen getrennt behandeln. Private Bankdaten werden nicht in den Aufbauplan oder das Code-Repository übernommen.
5. Tatsächliche E-Mail-/DOI-Bestätigung, Bestandsprüfung und Vertragsannahmebeleg kontrollieren.
6. Zugang ausschließlich aus gültigem Vertrag und erforderlicher Fachrolle feststellen. Eine Director-Bezeichnung im Papierbogen oder Chat vergibt keine technische Rolle.
7. Eigene Personenakte und vorhandene Belege lesen; bei leerer Akte keine Testeinträge als reale Teilnahme erzeugen.
8. Danach Kalender-, Redaktions- und Parcoursrechte jeweils einzeln prüfen und den berechtigten Gesamtdurchlauf dokumentieren.

Die tatsächliche Konto-ID und die genannten positiven Nachweise wurden in U03 nicht aus der laufenden Datenbank abgerufen. Es wird weder eine fehlende noch eine aktive Mitgliedschaft des Nutzers pauschal behauptet.

## 4. Tatsächlich ausgeführte isolierte Regelprüfungen
Die am Hauptstand gelesenen TypeScript-Funktionen wurden mit Node.js 24 über dessen TypeScript-Transformation ausgeführt. Externe Authentifizierung, Cookies, Next-Antworten und Datenbankantworten waren simuliert. Die Prüfungen liefen lokal erfolgreich: **15 bestanden, 0 fehlgeschlagen**.

| Prüfung | Ergebnis |
|---|---|
| Interner Weiterleitungspfad mit Query/Fragment bleibt erhalten | Bestanden |
| Externe URLs, protokollrelative Ziele, Backslash, Scriptziel und Steuerzeichen werden verworfen | Bestanden |
| Anonyme Personenakte führt zur Anmeldung | Bestanden |
| Fehlende Auth-Konfiguration öffnet keine Personenakte | Bestanden |
| Angemeldet ohne aktiven Vertrag erhält keinen Mitgliederbereich | Bestanden |
| Mitgliedschafts-Datenbankfehler hält Mitgliederbereich geschlossen | Bestanden |
| Gültiger aktiver Vertragsstatus lässt Mitgliederweg passieren | Bestanden |
| Öffentlicher Widerruf bleibt ohne Sitzung erreichbar | Bestanden |
| Historischer Kündigungslink führt zum öffentlichen Eingang | Bestanden |
| API-Mitgliedschaftsprüfung verweigert fehlende Sitzung | Bestanden |
| API-Mitgliedschaftsprüfung verweigert fehlenden Vertrag | Bestanden |
| API-Mitgliedschaftsprüfung verweigert Datenbankfehler | Bestanden |
| API-Mitgliedschaftsprüfung verwendet tatsächlichen Sitzungsnutzer | Bestanden |
| Eigener Aktenhelfer filtert agent_id anhand der Sitzung | Bestanden |
| Persönliche Plattformleitung benötigt konfigurierte Benutzer-ID und aktive Leitungszeile | Bestanden |

Diese Prüfungen bestätigen konkrete Anwendungsregeln. Sie sind kein aktueller SQL-RLS-Test, keine tatsächliche Anmeldung, keine aktuelle Kontoaktivierung und kein Beweis einer Originalakte. Aus den früheren erfolgreichen CI-Prüfungen wird keine neue Gesamtbetriebsabnahme abgeleitet.

## 5. Beobachtete Unterschiede und nächste technische Arbeit
| ID | Gelesener Befund | Erforderliche Bearbeitung |
|---|---|---|
| R01 | Personenaktenseite fordert lokal die Sitzung; aktive Mitgliedschaft wird für diese Seitenroute im proxy geprüft. Die entsprechende API prüft sie nochmals selbst | Weiterleitungs- und API-Probe am bereitgestellten exakten Stand; Schutz bei direktem URL-Aufruf bestätigen |
| R02 | Hauptstand fasst Mitgliedschaftsfehler in der API als 401/nicht_angemeldet zusammen; proxy leitet auch bei RPC-Ausfall auf den Zahlungsweg | Fehlerzustände verständlich unterscheiden; keine neue Zahlung als Lösung eines technischen Ausfalls suggerieren |
| R03 | Personenakten- und Rollen-API geben bei einzelnen Fehlern detailhaltige Meldungen aus dem Helfer zurück | Technische Fehlerausgabe vereinheitlichen und interne Datenbankdetails nicht in Nutzerantworten übernehmen |
| R04 | Mitgliedsbezogene Rollen und physische Rollen sind unterschiedliche Modelle | Verbindliche Zuordnung und Gültigkeit je Aktion festlegen; keine pauschale „Admin kann alles“-Regel |
| R05 | Eigener Aktenfilter und zusätzliche Maxwell-RLS-Policy bestehen nebeneinander | Gewöhnlichen Fremdzugriff und ausdrücklich erlaubten Sonderzugriff mit zwei getrennten Konten in Staging prüfen |
| R06 | Redaktion gehört zu PR 167 und besitzt eigene Operator-/Director-Prüfung | Reale berechtigte Anmeldung am Teststand durchführen; PR-163-Aufbauplan macht Redaktion nicht automatisch verfügbar |
| R07 | Auth-Fehlerunterscheidung ist im Hauptstand gröber als im Redaktionsvorschlag | Bestehende PR-167-Verbesserung vor weiterer Konsolidierung berücksichtigen, keine parallele widersprüchliche Auth-Lösung bauen |

U03 beschreibt diese Unterschiede als konkrete technische Restarbeit. Die Laufzeitdateien wurden in dieser Planungs-/Prüffortschreibung nicht verändert.

## 6. Reale Staging-Abnahme: vorbereitete Prüffälle
| Fall | Vorgang und Erwartung | Nachweis / aktueller Status |
|---|---|---|
| A01 | Eindeutiges Stagingziel, getrennte Datenbank, serverseitiger Testzugang und zwei passende Konten | tatsächliche Umgebung-/Kontoprüfung offen |
| A02 | Berechtigte Person meldet sich tatsächlich an; Sitzung bleibt nach Seitenwechsel gültig | Browserprotokoll ohne Geheimnisse offen |
| A03 | Ungültige Anmeldung und Abmeldung; danach privater Direktaufruf geschlossen | echte Auth-Probe offen |
| A04 | Vorgang 0001 dem bestehenden Konto zugeordnet | tatsächliche Datensatz-/Originalzuordnung offen |
| A05 | Eigene Akte und vorhandener eigener Vertragsbeleg abrufbar | reale Eigentümer-/Belegprobe offen |
| A06 | Zweites gewöhnliches Konto erhält keinen fremden Akten-/Belegzugriff, auch bei manipuliertem Bezug | echte Fremdzugriffsprobe offen |
| A07 | Konto ohne aktiven angenommenen Vertrag erhält keinen Mitglieder-/Einsatzweg | echte Status-/Zugangsprobe offen |
| A08 | Aktive beitragsfreie Bestandszeit wird richtig behandelt | tatsächliche Annahme-/Zeit-/Bestandszuordnung offen |
| A09 | Director und persönliche Plattformleitung werden getrennt geprüft | echte Rollen- und Negativprobe offen |
| A10 | Maxwell/Tafel-Director/Field Lead handeln nur im erlaubten Umfang | echte Rollen-/Einsatzprobe einschließlich Sonderleserecht offen |
| A11 | Parcoursberechtigung und Kalenderplanung getrennt geprüft | tatsächliche Fachprobe offen |
| A12 | Fehler, Versionskonflikt, Ablauf des Vertrags und Belegzugriff nach Ende | kontrollierte Staging-Probe offen |

Private Benutzer-IDs, Originale, Passwörter und Sitzungsdaten gehören in geschützte Nachweise; der öffentliche Aufbauplan enthält nur Prüfstatus und unvertrauliche Referenzen. Keine Testrollen oder fingierten Vertragsannahmen in Produktion.

## 7. Verantwortung, Abschluss und nächste Arbeit
Ergebnisverantwortung: Director Allan Pinkerton (Hans Engels). Wirtschaftliche Entscheidungen: Investor Hans Engels. Technische Durchführung, Rollenadministration und Abnahmeprotokoll benötigen die in U02 noch zu besetzenden ausführenden Personen. Die Assistenz hat Codeabgleich und die 15 isolierten Regelprüfungen ausgeführt.

U03 ist abgeschlossen, wenn die reale Staging-Anmeldung, Konto-/Originalzuordnung, eigene/fremde Akte und zulässige/unzulässige Rollenfälle am exakt benannten Stand nachgewiesen sind und die beobachteten Fehler-/Rollenunterschiede bearbeitet wurden. Bis dahin gilt: **„Regeln geprüft; realer Kontodurchlauf offen“**.

U04 kann mit den 30 vorhandenen Formularzuordnungen vorbereitet werden; positive Fachabläufe benötigen die U03-Zugangsgrundlage. Keine automatische Rollen-, Vertrags-, Produktions- oder Fachfreigabe.

## Quellen
- Hauptstand: https://github.com/allanpinkerton120/continental-heritage-agency/tree/b606fe77fa0eccfc2e63e491710fa37f3545843c
- platform/proxy.ts; lib/auth/supabase-server.ts; lib/auth/safe-redirect.ts; app/anmelden/actions.ts; app/anmelden/formular.tsx; app/auth/callback/route.ts
- app/mitglied/personalakte/page.tsx; app/api/physisch/personalakte/me/route.ts; lib/cha/physisch-personalakte.ts
- app/api/mitgliedschaft/beleg/route.ts; lib/cha/vertragsannahme.ts; lib/cha/veteranenlinie.ts
- app/api/physisch/role-grant/route.ts; lib/cha/physisch-maxwell.ts; app/mitglied/parcours/page.tsx
- Migrationen 20260426190100_physisch_personalakte_volltext.sql und 20261007082517_contract_acceptance_receipts.sql
- Bestehende tests/e2e/auth-sicherheit.spec.ts, mitgliedschaft-api-schranke.spec.ts und parcours-zugang.spec.ts
- PR 167: lib/cha/redaktion.ts am getrennten oben genannten Head
- Bestehender Hauptstand-CI: https://github.com/allanpinkerton120/continental-heritage-agency/actions/runs/37691053998