# 1. Aktueller Status
## 1.1 Implementierung
- Hacky Proof of Concept, unvollständig (nur Kartenanlage-Ansatz, wenig Sorgfalt).

## 1.2 Striga-Integration
- Erste Calls funktionieren.
- Striga bündelt KYC/Banking/Karte/Krypto.
- Beziehung: Striga ↔ ThumbsUp (nicht App ↔ ThumbsUp).

## 1.3 ThumbsUp
- SDK nur triggerbar, UI kaum/customization nicht möglich.

## 1.4 Passkey/FaceID
- Passkey-Login vorhanden.
- Key in Keychain via FaceID geschützt.
- FaceID triggert bei sensiblen Zugriffen.

## 1.5 Bewertung Striga
- Vorteil: End-to-End (KYC/Banking/Karten/Krypto/Lightning) für ~5.000 €/Monat.

## 1.6 Ist vs. Soll
- Vorliegende User-Story-Liste = Ist-Stand.
- Striga-spezifische Stories fehlen noch.

---

# 2. Geplanter Fokus heute
## 2.1 Ziel
- Striga-Flow end-to-end (Tier 1) stabil fertigstellen.

## 2.2 Priorität
- Funktionalität/Stabilität vor UX-Optimierung.

## 2.3 Vergleich
- Dient als Benchmark vs. Lukas’ Fortschritt.

---

# 3. Geplanter Sign-up-/Onboarding-Flow
## 3.1 App-Start
- E-Mail eingeben → Create Wallet → Passkey anlegen (E-Mail als Username).

## 3.2 Namensdaten
- Vorname, Nachname erfassen.

## 3.3 Adresse
- Eingabe mit Autovervollständigung und Auswahl.

## 3.4 Telefonnummer
- Eingabe + SMS-Code verifizieren.

## 3.5 Striga-Account
- Erstellen mit E-Mail, Telefon, Name, Adresse, ggf. Geburtsdatum (Tier-1-Anforderung prüfen).

## 3.6 KYC
- Start via ThumbsUp-SDK mit Striga-Backend-Token.

## 3.7 Biometrics
- FaceID bei App-Open, Transaktionsversand, sensiblen Anzeigen.

## 3.8 Datenspeicherung
- E-Mail in Passkey-DB (mit Passkey) und Striga-DB (Nutzerverknüpfung).

---

# 4. E-Mail-Strategie
## 4.1 Striga-Anforderung
- E-Mail zwingend für Account-Erstellung.

## 4.2 Kurzfristig
- E-Mail erfassen, Striga-E-Mail-Verifizierung deaktiviert.

## 4.3 Interne Verifizierung
- Optionale eigene Verification-Mail; Verifizierungsstatus in DB tracken.

## 4.4 Alternative
- Random @nuri.com E-Mail zur Automatisierung von Codes (nur falls zulässig).

## 4.5 Datenschutz
- E-Mail de-anonymisiert Wallet teilweise; Nutzen vs. Privacy abwägen.

## 4.6 Zukunft
- Nuri-Username/Lightning-E-Mail später einführen, um Onboarding simpel zu halten.

---

# 5. Telefonnummer/2FA
## 5.1 Pflicht
- Telefonverifizierung via SMS-Code notwendig.

## 5.2 UX
- iOS AutoFill für SMS; optional E-Mail-Code parsing zur Auto-Eingabe.

## 5.3 In-App-Codes
- Codes in-App anzeigen (Push), kein App-Wechsel nötig.

## 5.4 Compliance
- Prüfen, ob automatische E-Mail-Code-Erfassung mit Striga-Policies vereinbar ist.

---

# 6. Lightning-Address/Username-Idee
## 6.1 Vision
- [e-mail] als Lightning-Address mit echter/temporärer Inbox.

## 6.2 Funktionen
- 2FA/One-Time-Codes automatisch erkennen, anzeigen, weiterleiten.

## 6.3 Use Cases
- BTC → Fiat Auto-Cash-In auf Karte via Lightning-E-Mail.

## 6.4 UX-Strategie
- Zunächst klassische E-Mail beim Login; Lightning-Handle später (First-Time-Krypto-User).

---

# 7. Subscriptions/Monetarisierung (später)
## 7.1 Karten-Tiers
- Z. B. 0,99 € / 4,99 € / 99 € monatlich.

## 7.2 Gebührenmodell
- BTC-Fees z. B. 2% / 1% / 0% je Tier.

## 7.3 Setup
- Subscriptions via Apple/Stripe; Kundendaten für Autofill nutzbar.

## 7.4 Vorteile
- Verifizierte Daten, höhere Bindung, Segmentierung.

## 7.5 Erweiterungen
- Cashback, Versicherung, weitere Benefits.

---

# 8. UX/BIOMETRICS-Details
## 8.1 FaceID bei App-Open
- Schutz der Balance/Ansichten.

## 8.2 FaceID bei Senden
- Transaktionsfreigabe und Private-Key-Zugriff absichern.

## 8.3 Erstnutzung
- Erklär-Screen nach Passkey, um „Fehlergefühl“ zu vermeiden.

## 8.4 Kindersicherheit
- Schutz vor ungewollten Transaktionen (Kinder/Shared-Geräte).

---

# 9. ThumbsUp-Integration
## 9.1 Architektur
- SDK über Striga-Backend-Token; kein direkter Vertrag App ↔ ThumbsUp.

## 9.2 UI-Customization
- Stark limitiert; Prozesshoheit bei Striga/ThumbsUp.

## 9.3 Prefill
- E-Mail/Telefon an KYC-Start übergeben, Doppeleingaben vermeiden.

## 9.4 Tier 1
- Dummy/Platzhalter vermeiden; echte Nutzerangaben früh einsammeln.

---

# 10. Team/Prozess
## 10.1 Benchmarking
- Heutiger Stand als Vergleich zu Lukas’ Arbeit.

## 10.2 Feedback-Kultur
- Ehrlicher Vergleich; bei höherer Komplexität Gesprächsanpassung.

## 10.3 User Stories
- Liste = Ist-Stand; Striga/KYC-Details ergänzen.

## 10.4 Dokumentation
- Stories in HackMD überarbeiten; dann nach GitHub; AI kann Import/Issue-Erstellung übernehmen.

---

# 11. Tools/Dev-Setup
## 11.1 Repos
- Lokal klonen; iOS/API Units vorhanden.

## 11.2 AI-Tools
- Claude Code oder Goose für Codeanalyse/Iterationen.

## 11.3 Goose-Funktionen
- Systemweite Steuerung, Filesystem, Git, Figma, Browser; Agent-Mode; Extensions.

## 11.4 Provider
- OpenRouter; Key bereitgestellt; Modelle testen (z. B. Horizon Alpha).

## 11.5 Rate Limits
- Bei Engpässen Model wechseln; Verbrauch/Kosten tracken.

## 11.6 Kontext
- In Goose Ordnerkontext setzen (z. B. nur iOS); klare Prompts (User-Story-Extraktion).

---

# 12. Offene Punkte/To-Do
## 12.1 Tier-1-Anforderungen
- Prüfen, ob Geburtsdatum zwingend ist.

## 12.2 E-Mail-Policy
- Kurzfristig unverifiziert sammeln; mittelfristig Verifizierung mit Status.

## 12.3 Striga-Mapping
- Feldzuordnung, Fehler-/Status-Handling, Retries.

## 12.4 KYC-Prefill
- So viele Felder wie möglich vorbefüllen.

## 12.5 2FA-UX
- AutoFill/Auto-Parsing und In-App-Anzeige finalisieren.

## 12.6 Security/Privacy
- Bewertung E-Mail/Datenverknüpfung, Datenminimierung und Schutz.

## 12.7 User Stories
- Aktualisieren, clustern (Onboarding, KYC, Security, Wallet, Karten, Settings), Striga/ThumbsUp ergänzen.

## 12.8 GitHub
- Aus HackMD Issues generieren, Priorisierung/Labels setzen.

---

# 13. Ergebnisziel heute
## 13.1 Voller Onboarding-Flow
- Striga Account + SMS-Verifizierung + KYC-Start lauffähig und stabil.

## 13.2 Datenhaltung
- E-Mail sauber in Passkey-DB und Striga-DB verknüpft; konsistente Nutzer-ID-Strategie.

## 13.3 Grundlage
- Basis für spätere UX-Optimierungen, Subscription-Einführung, Automatisierungen.

---

# 14. Conclusion
## 14.1 Kurzfristig
- Stabilen Striga-Tier-1-Onboarding-Flow mit klarer Datenerfassung und KYC-Start bauen; E-Mail/Telefon pragmatisch erheben; E-Mail-Verifizierung optional nachziehen.

## 14.2 Mittelfristig
- UX verfeinern (AutoFill, In-App-Codes, FaceID-Checkpoints), User Stories festigen und in GitHub operationalisieren, Privacy/Compliance sauber absichern.

## 14.3 Langfristig
- Nuri-Usernames/Lightning-Addresses einführen, Subscriptions mit Fees/Benefits, automatische Funding-Flows (BTC→Fiat auf Karte).