docs(pricing): mail=safety-feature for this audience, target-group device/mailbox reality, founding-members (first 100 → Pro)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ops/strategy/pricing-tiers.md

@@ -41,6 +41,10 @@
 
 **Strategische Wette (User, „kenne die Zielgruppe sehr gut"):** *Voller* Schutz = **Legend-only** ist Absicht. Die Wette: ein Mensch in Recovery wandert nach ein paar Monaten **von selbst** zu Legend (mindestens als Probe), weil die Sucht gegen Lücken arbeitet — irgendwann will er *alles* dicht (Multi-Device, volle Blocklist, Echtzeit-Mail). Bedingungen, damit diese Wette aufgeht: (1) das **Front-Door-Erlebnis** darf den User nicht in Woche 1 verlieren (Relapse auf einer offensichtlichen Seite / Deinstall / 1-Stern) — die kuratierte Kernliste ist genau die *Infrastruktur* dafür, nicht ein Widerspruch zur „Legend = voll"-Strategie: sie kauft die Zeit, bis die Wette greift. (2) Die App muss **transparent** sein, dass Legend = voller Schutz ist (z.B. „Grundschutz aktiv — voller Schutz vor allen bekannten Glücksspiel-Seiten: Pro/Legend") — der User muss die Treppe *sehen*, um in sie hineinwachsen zu können; „versteckt" wäre die Strategie nur ggü. dem *Markt*, nicht ggü. dem einzelnen Nutzer. Restrisiko bleibt der Front-Door-Drop (Strategist §7.1) — vom User bewusst akzeptiert.
 
+**Founding Members (User, 2026-05-11):** Die **ersten 100 User bekommen automatisch Pro** — als „Founding Members". Launch-Taktik: Early-Adopter belohnen, den Community-Nukleus seeden, Word-of-Mouth + Feedback. Passt zur Community-Conversion-Philosophie (die ersten 100 sind die wachsende Community, die spätere User sehen). Offene Details: (a) Dauer — *lifetime* Pro (Standard für „founding member") oder N Monate? Annahme: lifetime. (b) Badge — „Founding Member"-Abzeichen in Profil/Community (Status/Anerkennung)? Annahme: ja. (c) Founding Member will später Legend → zahlt vollen Legend-Preis (sein Pro ist Geschenk, kein Rabatt-Anker); kündigt er ein bezahltes Legend → fällt zurück auf Founding-Pro, nicht auf Free. Impl (Phase 2, rebreak-backend): Signup-Counter / `foundingMember`-Flag auf dem Profil, für die ersten 100 automatisch gesetzt + `plan='pro'` (exempt von normaler free→pro-Logik und von Downgrade-Reconciliation); Badge im Frontend.
+
+**Zielgruppen-Realität (korrigiert Strategist-Annahmen §7.2):** Der Mail-Newsletter-Schutz ist für diese Zielgruppe ein **Sicherheits-Feature, kein Komfort** — eine einzige Casino-Mail kann realen Schaden verursachen (der Strategist's „die meisten kriegen wenige Casino-Mails" / „Daemon = Garnitur #3" gilt nicht für jemanden in Recovery). Außerdem: Zocker/Süchtige haben typischerweise **mehr als ein Gerät** und **mehr als 3 Mailboxen** (in DE besonders — viele E-Mail-Adressen, Wegwerf-Accounts, neue Accounts während aktiver Sucht). → Die Free/Pro-Limits (1 Gerät, 1 bzw. 3 Mailboxen) liegen *absichtlich unter* dem, was ein ernsthafter Betroffener braucht — das ist der Funnel zu Legend (∞ Mailboxen + Echtzeit-IMAP-Daemon + Multi-Device-DNS). Implikation für Phase 2: das Daemon-Gating ist kein „nice to have", und `mo` muss einplanen, dass ein Legend-User *viele* gleichzeitige IDLE-Sessions hat (Skalierung des `imap-idle`-Daemons).
+
 **Offene Implementierungs-Punkte (→ Phase 2, eigener Workstream):**
 1. **Kuratierte Free-Kernliste** — Subset der HaGeZi-Liste nach Popularität/Traffic-Rang filtern (~1–2k), ~monatlich nachziehen. Neue `getPlanLimits`-Achse `globalBlocklist: 'curated' | 'full'` (oder Boolean + zweites Listenfile). → rebreak-backend.
 2. **IMAP-IDLE-Daemon-Gating auf Legend** — Daemon (`backend/imap-idle/`) hält nur für Legend-`MailConnection`s eine IDLE-Session; free=4h-fixed-Cron, pro=Intervall-Wahl (1/4/8h), legend=Live. → rebreak-backend + mo.