e284240f3c
ManaAuthUI-Initialsprint mit 5 Versions-Schritten in einer Session. spieler.md + macher.md hand-curated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
79 lines
3.3 KiB
Markdown
79 lines
3.3 KiB
Markdown
---
|
||
date: 2026-05-13
|
||
day: 1
|
||
view: macher
|
||
weekday: Mittwoch
|
||
commits: 5
|
||
review: written
|
||
---
|
||
# Mittwoch, 2026-05-13 — Tag 1 (Macher-Sicht)
|
||
|
||
Initialer Sprint des Pakets. Aus drei fast-byte-identischen
|
||
`LoginView.swift`-Files in cards-native, manaspur-native und
|
||
memoro-native wird ein gemeinsames Swift-Package — plus das, was
|
||
bisher gar nicht da war: Sign-Up, E-Mail-Verifikation, Passwort-Reset,
|
||
Account-Management. Und 2FA, weil die Lücke beim Aufräumen sichtbar
|
||
wurde.
|
||
|
||
## Stats
|
||
|
||
5 Commits, +4 247 / −4 LoC, 39 Files. Sessionspanne 17:22 → 01:08,
|
||
~48 aktive Minuten in einem Durchstich. Bei +4 243 netto ist das
|
||
v0.1.0 mit allem Anhang, nicht „aktive Tipparbeit" — die Inhalte
|
||
flossen aus den drei App-Repos zusammen.
|
||
|
||
## Versionsschritte des Tages
|
||
|
||
- **v0.1.0** — vollständige Auth-Reise als SwiftUI: Login, Sign-Up,
|
||
Email-Verify-Gate, Forgot-/Reset-Password, Change-Email,
|
||
Change-Password, Delete-Account. ViewModels strikt getrennt von
|
||
Views, jeder Flow eigene `@Observable`-State-Maschine.
|
||
- **v0.2.0** — `ManaAuthGate`, der „bitte-erst-einloggen"-Wrapper
|
||
für Action-Level-Eskalation. Cards/Manaspur/Memoro brauchen das
|
||
pro Aktion, nicht pro Screen.
|
||
- **v0.3.0** — `ManaTwoFactorChallengeView` für den Login-Step,
|
||
wenn der Server 2FA verlangt.
|
||
- **v0.4.0** — `ManaTwoFactorEnrollView` (QR-Code + Verify) und
|
||
`ManaTwoFactorDisableView` (Passwort-Bestätigung).
|
||
- **v0.5.0** — `ManaTwoFactorAccountRow` für den Account-Tab und
|
||
`ManaBackupCodeRegenerateView`.
|
||
|
||
Fünf Tags in einer Session ist viel — der Schnitt war pro
|
||
Feature-Komplex, damit Consumer-Apps gezielt minor-bumpen können
|
||
ohne 2FA mitzunehmen, das sie noch nicht zeigen.
|
||
|
||
## Architektur-Entscheidungen
|
||
|
||
- **Pure SwiftUI, keine UI-Lib** — gleiche Regel wie `ManaCore`.
|
||
Senkt Drift-Risiko zwischen Vereins-Apps.
|
||
- **App injiziert `ManaBrandConfig`** — Pakets-Sources kennen keinen
|
||
App-Namen, keine Farben. `forest`/`mana`/künftige Themes leben in
|
||
der konsumierenden App, bis Token-Theme-Variants kommen.
|
||
- **ViewModel-zuerst-Pattern.** Tests gehen gegen ViewModels via
|
||
URLProtocol-Mock, Views sind dünn und ungetestet — das passt zum
|
||
Swift-Test-Realismus auf macOS-CI.
|
||
- **Account-Löschung ist Pflicht** (App-Store-Guideline 5.1.1(v));
|
||
`ManaDeleteAccountView` ist Bestandteil jedes Sign-Up-Anbieters.
|
||
- **2FA-Flow läuft komplett über `ManaCore` v1.2.0** (Guest-Mode +
|
||
Refresh-Resilience), keine eigenen API-Wrapper in UI.
|
||
|
||
## Trade-offs
|
||
|
||
- 4 243 netto Zeilen für „v0.1.0 + v0.5.0 in einer Session" — das
|
||
hat nur funktioniert, weil drei Source-Repos schon Login-Code in
|
||
ähnlicher Form hatten. Hätten wir Sign-Up parallel in drei Apps
|
||
gebaut, wäre der Tag dreimal so lang.
|
||
- Sprache deutsch im Public-API. Lokalisierungs-Refactor später,
|
||
wenn EN-Bedarf real wird; jetzt würde die Indirection bremsen.
|
||
- 2FA UI ist da, aber Server-seitig fehlt der Endpoint in
|
||
`mana-auth` noch in mancher Form — die Views laufen daher
|
||
zunächst gegen Stub-Antworten.
|
||
|
||
## Offene Punkte
|
||
|
||
- ManaTokens-Theme-Variants → erst dann `ManaBrandConfig` ersetzen.
|
||
- Snapshot-Tests für Views fehlen; ViewModel-Tests laufen.
|
||
- Localizable.xcstrings (EN) noch nicht angelegt — kommt mit der
|
||
ersten konkreten EN-Anforderung.
|
||
- Cross-App-Probelauf: 2FA-Enroll von cards-native gegen Production
|
||
noch nicht durchgespielt.
|