6417b4cd33
Apps mit Guest-/Login-optional-Modus brauchen kein Full-Screen-
Login-Gate mehr. Aktionen, die einen Account brauchen, werden in
gate.require { ... } gewrappt — Login wird zur Inline-Eskalation,
nicht zum App-Block.
ManaAuthGate — @Observable-State-Maschine:
- require(reason:work:) sync und async Overloads
- Bei .signedIn: Aktion läuft sofort
- Bei .signedOut/.guest: Sign-In-Sheet öffnet, Aktion gemerkt;
nach erfolgreichem Sign-In läuft sie automatisch
- lastReason als optionaler Telemetrie-Hint
ManaAuthGateModifier / View.manaAuthGate(_:signIn:) — hängt das
Sign-In-Sheet an einen Root-View, beobachtet auth.status. Wechsel
auf .signedIn schließt das Sheet + resolved pending; manuelles
Dismiss verwirft.
Konvention für native Apps:
1. bootstrap() → bei .signedOut → enterGuestMode()
2. Root-View zeigt immer App-Inhalte, nie eine Vollbild-Login-Wall
3. Account-Aktionen via gate.require { ... }
Memoro hat das informell schon. Cards komplett umgestellt (siehe
cards-native commit). Manaspur folgt.
7 neue Tests: sofortiger Run bei .signedIn, Defer bei .signedOut/
.guest, resolvePending, cancelPending, lastReason-Tracking.
Setzt mana-swift-core ≥ 1.2.0 voraus.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
93 lines
3.9 KiB
Markdown
93 lines
3.9 KiB
Markdown
# Changelog
|
|
|
|
Alle Änderungen werden hier dokumentiert. Format orientiert an
|
|
[Keep a Changelog](https://keepachangelog.com), Versionierung nach
|
|
[Semver](https://semver.org).
|
|
|
|
## [Unreleased]
|
|
|
|
## [0.2.0] — 2026-05-13
|
|
|
|
Minor — Action-Level-Gate für Apps mit Guest-/Login-optional-Modus.
|
|
Komplett additiv; braucht `mana-swift-core` ≥ 1.2.0.
|
|
|
|
### ManaAuthUI — neu: ManaAuthGate
|
|
|
|
- `ManaAuthGate` — `@Observable`-State-Maschine, die eine Aktion erst
|
|
laufen lässt, wenn der User eingeloggt ist. Wenn nicht, wird das
|
|
Sign-In-Sheet aufgeklappt und die Aktion gemerkt; nach erfolgreichem
|
|
Sign-In läuft sie automatisch.
|
|
- Zwei `require`-Overloads: synchron (`() -> Void`) und async
|
|
(`() async -> Void`). Konsumenten schreiben `gate.require { ... }`
|
|
ohne sich um das Gate-Lifecycle zu kümmern.
|
|
- `ManaAuthGateModifier` / `View.manaAuthGate(_:signIn:)` — hängt das
|
|
Sign-In-Sheet an einen Root-View und beobachtet `auth.status`.
|
|
Wechsel auf `.signedIn` schließt das Sheet und löst die Pending-
|
|
Aktion aus; manuelles Dismiss verwirft die Pending-Aktion.
|
|
- `lastReason` als optionaler Telemetrie-Hint pro `require`-Call.
|
|
|
|
### Konvention
|
|
|
|
Native-Apps sollen `mana-swift-core` v1.2.0 + Guest-Mode + diesen Gate
|
|
als Standardweg nutzen. Pattern für Cards/Manaspur/Memoro:
|
|
|
|
1. Beim App-Start: `bootstrap()`, dann bei `.signedOut` → `enterGuestMode()`.
|
|
2. Root-View zeigt immer App-Inhalte; **nie** eine Vollbild-Login-Wall.
|
|
3. Aktionen, die einen Account brauchen, werden in
|
|
`gate.require { ... }` gewrappt — Login wird zur Inline-Eskalation
|
|
statt zum App-Block.
|
|
|
|
Memoro hat dieses Muster informell schon umgesetzt (ContentView ohne
|
|
Hard-Gate). Cards + Manaspur ziehen mit ihren nächsten Releases nach.
|
|
|
|
### Tests
|
|
|
|
- 7 neue Tests für `ManaAuthGate`: sofortiger Run bei `.signedIn`,
|
|
Defer bei `.signedOut`/`.guest`, `resolvePending` nach Sign-In,
|
|
`cancelPending`, `lastReason`-Tracking.
|
|
|
|
## [0.1.0] — 2026-05-13
|
|
|
|
Phase 2 aus dem Native-Auth-Vollausbau-Plan (Option A, siehe
|
|
`../mana/docs/MANA_SWIFT.md`). Entstanden weil drei Apps fast-byte-
|
|
identische `LoginView.swift`-Dateien hatten und Sign-Up/Forgot-PW
|
|
komplett fehlten.
|
|
|
|
### ManaAuthUI (neu)
|
|
|
|
- `ManaBrandConfig` — App-injiziertes Bündel aus appName, tagline,
|
|
primary/surface/background/error-Colors. Apps liefern hier ihr
|
|
Theme (z.B. forest für Cards/Manaspur, default-mana für Memoro).
|
|
- Base-Components: `ManaAuthScaffold`, `ManaPrimaryButton`,
|
|
`ManaTextField`, `ManaSecureField` — geteilte Bausteine, alle
|
|
brand-aware.
|
|
- `ManaLoginView` + `LoginViewModel` — Email/PW-Login mit
|
|
Sign-Up- und Forgot-PW-Buttons. Bei `.emailNotVerified` automatisch
|
|
ins `ManaEmailVerifyGateView` umgeleitet (Resend-Mail-Button).
|
|
- `ManaSignUpView` + `SignUpViewModel` — Registrierung mit
|
|
Email/Name/Passwort. Nach Submit: Bestätigungs-Mail-Hinweis-Screen.
|
|
- `ManaEmailVerifyGateView` — wenn Login `.emailNotVerified` warf,
|
|
bietet "Bestätigungs-Mail erneut senden".
|
|
- `ManaForgotPasswordView` + `ForgotPasswordViewModel` — Reset-Mail
|
|
anfordern. Server antwortet immer 200 (keine User-Enumeration),
|
|
UI meldet generisch.
|
|
- `ManaResetPasswordView` + `ResetPasswordViewModel` — neues
|
|
Passwort setzen mit Token aus Reset-Mail. Wird aus dem
|
|
Universal-Link-Handler der App aufgerufen.
|
|
- `ManaChangeEmailView`, `ManaChangePasswordView`,
|
|
`ManaDeleteAccountView` — Account-Bausteine für die AccountView
|
|
der App. **`ManaDeleteAccountView` ist App-Store-Pflicht
|
|
(Guideline 5.1.1(v))** für jede App mit Account-Erstellung.
|
|
|
|
### Tests
|
|
|
|
- ViewModel-Tests via URLProtocol-Mock für jeden Auth-Flow.
|
|
- Brand-Config-Defaults.
|
|
|
|
### Bekannte Einschränkungen
|
|
|
|
- `ManaChangeEmailView`/`ManaChangePasswordView`/`ManaDeleteAccountView`
|
|
funktionieren erst nach Phase-3-Server-PR (Bearer-Plugin in
|
|
`mana-auth`). UI ist fertig, Wire ist fertig, Server muss nachziehen.
|
|
- 2FA, Magic-Link, Passkey-Flows nicht enthalten. Folgen in v0.2.0
|
|
zusammen mit ManaCore v1.2.0 und dem Server-PR.
|