docs(quick-260921-bi2): gemeldetes Symptom Passwortwechsel widerlegt
Tessera CI/CD / Lint & Type Check (push) Successful in 47s
Tessera CI/CD / Tests (push) Successful in 1m9s
Tessera CI/CD / Desktop-Pakete bauen (push) Successful in 18s
Tessera CI/CD / Build & Publish Images (push) Successful in 2m51s

Der Lint-Durchlauf meldete, die Seite change-password leite nach
erfolgreichem Wechsel nicht weiter und lasse die Person bei erzwungenem
Wechsel stehen. Am laufenden System durchgespielt: trifft nicht zu.
Middleware leitet auf /change-password, der Wechsel landet auf /,
mustChangePassword steht danach auf false, Weiternavigieren geht.

changePasswordAction setzt das neue Sitzungs-Cookie und ruft redirect('/')
serverseitig; die ungenutzten router/setUser im Seitenmodul waren
Ueberbleibsel, kein Symptom. Entfernung des toten Codes war richtig,
die daraus abgeleitete Diagnose nicht.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
This commit is contained in:
2026-09-21 11:05:58 +02:00
parent f198c5765d
commit 116041b7fd
@@ -109,3 +109,33 @@ Keine Gaps. Alle automatisierten Nachweise — Fingerabdruck, Zaehlungen, Testla
---
*Verified: 2026-09-21*
*Verifier: Claude (gsd-verifier)*
## Korrektur eines gemeldeten Symptoms (2026-09-21, Orchestrator)
Der Vorgang hat fuenf tote Stellen als "Symptome echter Luecken" gemeldet statt sie zu
reparieren. Eine davon ist bei der Nachpruefung am laufenden System **widerlegt**:
**`apps/web/src/app/(portal)/change-password/page.tsx` — angeblich "leitet nach
erfolgreichem Wechsel weder weiter noch frischt die Benutzerablage auf; bei erzwungenem
Wechsel bleibt die Person auf der Seite stehen".** Das trifft nicht zu.
Gemessen mit den echten Abbildern und Browser, Ablauf vollstaendig durchgespielt:
1. Testbenutzer angelegt, `mustChangePassword=true` gesetzt, angemeldet → die Middleware
(`apps/web/src/middleware.ts:146`) leitet auf `/change-password` um.
2. Wechsel ausgefuellt und abgeschickt → Browser landet auf `/`, das Formular ist weg,
keine Fehlermeldung.
3. Datenbank: `mustChangePassword` steht danach auf `false`.
4. Weiternavigieren auf `/marketplace` funktioniert, kein Zurueckwerfen auf die
Wechselseite; die Kopfzeile zeigt den richtigen Benutzer.
Ursache des Fehlschlusses: `changePasswordAction` (`apps/web/src/lib/auth-actions.ts:160`)
ruft am Ende `redirect('/')` und setzt zuvor das neue Sitzungs-Cookie. Die Weiterleitung
und die Aktualisierung passieren also serverseitig in der Server Action — die im
Seitenmodul ungenutzten `router`/`setUser` waren Ueberbleibsel einer frueheren Loesung,
kein Symptom. Die Entfernung des toten Codes war richtig; die daraus abgeleitete
Fehlerdiagnose war es nicht.
Die uebrigen vier gemeldeten Symptome sind davon unberuehrt und weiterhin ungeprueft —
sie sind Meldungen, keine belegten Fehler, und sollten vor einer Reparatur ebenso am
laufenden System nachgestellt werden.