docs(pricing): synthesis — the design constraint is 'avoid 1-star reviews' + the must-have corollaries

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

ops/strategy/pricing-tiers.md

@@ -45,6 +45,8 @@
 
 **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).
 
+**Synthese — der eigentliche Design-Constraint: 1-Sterne-Bewertungen vermeiden.** Die ganze Architektur (kuratierte Free-Kernliste, Founding Members = erste 100 → Pro, *alle* Funktionen in Free nutzbar/keine Frustrations-Locks, Membership- statt Frustrations-Framing) ist genau die Antwort auf den Strategist's Haupt-Risiko (§7.1 Front-Door-Drop / 1-Stern). Das Risiko ist nicht ignoriert — es ist der Constraint, an dem der Plan gebaut wurde. Operative Korollare, die damit zu *Must-haves* werden (nicht „nice-to-have"): (1) die kuratierte Kernliste muss **gepflegt** sein — eine stale Liste, die offensichtliche neue Seiten verpasst, *ist* ein 1-Stern. (2) **Erwartungs-Transparenz** — „Grundschutz aktiv — voller Schutz vor allen bekannten Glücksspiel-Seiten: Pro/Legend"; ein User, der trotz Free-Schutz relapst, darf sich *informiert* fühlen, nicht *betrogen* (Betrug-Gefühl → 1-Stern). (3) Founding Members müssen sich **wirklich besonders fühlen** (Badge, ggf. direkter Draht zum Founder für Feedback) — das macht aus den ersten 100 Fürsprecher statt potenzielle Kritiker. (4) **Responsiver Support** / „schreib uns"-Pfad — ein frustrierter User, der eine persönliche Antwort kriegt, schreibt keinen 1-Stern. → Diese vier sind keine Marketing-Verschönerung, sie sind Teil der Schutz-vor-1-Stern-Mechanik.
+
 **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.