07 — Otevřené otázky, rizika a rozhodnutí

A. Otázky pro Economia (klient)

A1. REMP CRM — Scope a nasazení [KRITICKÉ]

Otázka: Je potvrzeno, že bude nasazen REMP CRM (Nette moduly: crm-users-module, crm-subscriptions-module, crm-payments-module, crm-segment-module)? REMP monorepo (Beam, Campaign, Mailer, SSO) neobsahuje subscription/entitlement management — ten je v CRM modulech.

Proč je důležité: Celá integrace paywallu a subscription sync stojí na existenci REMP CRM API. Bez CRM nelze:

• Ověřit entitlement (má uživatel přístup?)
• Synchronizovat předplatné
• Segmentovat uživatele pro Campaign a Mailer

Rozhodnutí potřebné od: Economia + FatChilli (REMP vendor)

A2. Demo / staging prostředí [KRITICKÉ]

Otázka: Je k dispozici demo prostředí REMP pro proklikání? A vývojové API (staging) pro testování integrace?

Potřebujeme:

• Přístup k REMP CRM staging + API tokeny
• Přístup k REMP Mailer staging + API tokeny
• Přístup k REMP Campaign staging + API tokeny
• Test uživatele a subscription types v staging

Dopad: Bez staging prostředí nemůže začít vývoj (blokuje Sprint 1).

A3. Self-care systém [VYSOKÁ PRIORITA]

Otázka: Jak bude vypadat self-care pro čtenáře? REMP CRM je SoT pro předplatné. Varianty:

a) REMP CRM UI — uživatel spravuje předplatné přímo v REMP CRM rozhraní (FatChilli dodá).

b) CMS frontend + CRM API — CMS poskytne UI (šablony), které volá REMP CRM backend API. (pokud požadavek na konzistentní UX s webem)

c) Hybrid — profil v CMS, správa předplatného a newsletter odběrů v REMP UI.

Dopad: REMP CRM je SoT. Otázka je jen o frontendovém UI.

A4. Subscription plány a content access [VYSOKÁ PRIORITA]

Otázka: Jaké subscription plány budou existovat a jaký obsah odemykají?

Potřebujeme definici:

Mapování na PaywallTags:

A5. EGO-SSO (Ecoidentita) — stav implementace [VYSOKÁ PRIORITA]

Otázka: V jakém stavu je EGO-SSO?

• Je EGO-SSO provider funkční? (Viz Implementace EGO-SSO pro klienty)
• Jaká data vrací userinfo endpoint? (Viz SSO — userinfo endpoint)
• Existuje eco_user_id jako stabilní identifikátor?
• Funguje registrace nového uživatele?
• Je definovaný scope pro consent management?

Implementace v CMS: CMS-353, větev CMS-353_Ego_identita.

Architektura cookies: Na doméně druhého řádu (.hn.cz) je zřejmě potřeba Cloudflare Worker, který nastaví sdílenou auth cookie, čitelnou jak Folio CMS, tak dalšími Economia weby. Kdo Worker provozuje a jaký formát cookie má mít?

Dopad: Bez EGO-SSO nelze implementovat user sync do REMP CRM.

A6. Platební brána [STŘEDNÍ PRIORITA]

Otázka: Jaká platební brána bude použita?

• GoPay? ComGate? Stripe?
• Bude brána integrována v REMP CRM (FatChilli)?
• Podporuje recurring (card-on-file)?

Dopad: Platební brána je zodpovědnost FatChilli v rámci REMP CRM. CMS ji neřeší.

A7. Newsletter strategie — psaní v CMS, rozesílka přes REMP [VYSOKÁ PRIORITA]

Požadavek HN: Psát newslettery v Folio CMS (TipTap WYSIWYG editor) pro jednotné editační rozhraní s prolinky na články a další objekty CMS, ale reader delivery a subscriptions ponechat v REMP.

Otázka pro FatChilli:

1. Je MailCreateTemplateHandler (POST /api/v1/mailers/templates) aktivní ve vašem deploymentu?
2. Může CMS přes toto API pushovat hotové HTML šablony k rozesílce?
3. Je možné přes API aktualizovat existující template, nebo jen vytvářet nové?
4. Jaký mail_layout (header/footer/unsubscribe wrapper) bude registrován pro HN newslettery?
5. Jak funguje template versioning — archivují se staré verze?

Zjištění z analýzy REMP Mailer:

• API endpoint MailCreateTemplateHandler přijímá parametry template_html a template_text — tedy CMS může pushovat hotový obsah.
• Alternativně Mailer podporuje IGenerator interface pro pull obsahu z externího zdroje — ale to vyžaduje custom vývoj na straně FatChilli.
• Viz detailní analýza v 06 — Notifikace a e-maily.

Doporučený přístup: Push (CMS → Mailer API). Nevyžaduje custom vývoj na straně FatChilli, CMS má plnou kontrolu nad editačním workflow a Mailer zůstává delivery enginem.

Další otázky:

• Jaké newslettery jsou plánovány? (denní digest, týdenní souhrn, autorské, rubrikové, breaking news)
• Seznam mail typů a jejich frekvenci
• Kdo má přístup k editaci šablon
• Jaký obsah se do NL vkládá (plné články, excerpty, linky?)

A8. Mobilní aplikace [NIŽŠÍ PRIORITA]

Otázka: Jak bude mobilní aplikace (INT-07) komunikovat s REMP?

• Přímé volání REMP CRM API pro entitlement?
• Nebo přes Folio CMS API proxy?
• Jak se autentizuje uživatel v aplikaci?

B. Otázky pro REMP / FatChilli (vendor)

B1. REMP CRM API dokumentace [KRITICKÉ]

Otázka: Existuje kompletní API dokumentace REMP CRM? Repozitáře na github.com/remp2020 (crm-users-module, crm-subscriptions-module, crm-payments-module) jsou téměř prázdné. Kde je aktuální API spec?

Potřebujeme:

• Kompletní endpoint list (OpenAPI / Swagger)
• Autentizace (API token format, permissions)
• Rate limits
• Error response format
• Webhook specification

B2. Segment providery v deploymentu [VYSOKÁ PRIORITA]

Otázka: Které segment providery jsou skutečně zapnuté v deploymentu Economia a jaké aliasy mají používat CMS integrace?

Kontext: Z aktuálního remp kódu plyne, že Mailer používá aliasy crm-segment, remp-segment, mailer-segment, zatímco Campaign pracuje s underscore variantami (crm_segment, remp_segment). Pro CMS integraci potřebujeme potvrdit:

• že newsletter recipient segmenty půjdou přes REMP CRM provider,
• jaký přesný kód/provider se má používat v produkčním deploymentu,
• zda se někde používá Beam segmentace už ve fázi 1, nebo až později.

Potřebná specifikace:

• seznam povolených provider aliasů per služba,
• naming convention pro segment codes,
• odpovědnost za správu segmentů (FatChilli / Economia).

B3. Webhook support [VYSOKÁ PRIORITA]

Otázka: Podporuje REMP CRM outgoing webhooky? Jaké events?

• Subscription created / updated / expired?
• User updated / deleted?
• Payment received?

Alternativa: Polling (CMS periodicky checkuje CRM) — méně efektivní.

B4. Content access model [VYSOKÁ PRIORITA]

Otázka: Jak přesně funguje content_access v REMP CRM subscription types? Je to:

a) Array of string tags (e.g., ["web", "premium"]) — a CMS matchuje proti PaywallTag?

b) Hierarchický model (premium > web > free)?

c) Custom entitlement rules definovatelné v CRM admin?

B5. User ext_id vs. email dedup [STŘEDNÍ PRIORITA]

Otázka: Při POST /api/v1/users/register — jak se řeší deduplikace?

• Dle ext_id?
• Dle email?
• Co když existuje user se stejným emailem ale jiným ext_id?

B6. Mailer — layout wrapper a CMS push workflow [STŘEDNÍ PRIORITA]

Otázka: Jak přesně v deploymentu funguje Mailer layout wrapper pro template push z CMS?

• Jaké proměnné jsou dostupné v layoutu?
• Jak se skládá unsubscribe blok / footer?
• Existuje template editor v admin a jak se do něj promítají API-created templates?
• Je podporovaný update existující template, nebo jen create nových verzí?

Souvisí s A7 (Newsletter z CMS): Pokud CMS pushuje hotové HTML přes MailCreateTemplateHandler, Twig/T Latte vrstva v Maileru zůstává primárně v layoutu (header, footer, unsubscribe). Důležité ověřit, že wrapper nekonfliktuje s CMS-generated HTML.

B7. SLA a provoz [STŘEDNÍ PRIORITA]

Otázka: Jaké SLA poskytuje REMP?

• Uptime garantie
• Response time pro API
• Eskalační proces při výpadku
• Kdo monitoruje REMP služby?
• Kdo řeší produkční incidenty?

C. Rozhodnutí k učinění (Sinfin + Economia)

C1. Source of Truth pro subscription stav

Doporučení: REMP CRM jako SoT pro produkty, předplatné a platby. CMS jako tenká integrační vrstva (entitlement cache, webhook handling).

C2. Paywall evaluation — server vs. client side

Doporučení: Server-side s Redis cache pro entitlement.

C3. Transakční e-maily — odpovědnost systémů

Transakční e-maily pro čtenáře neposílá Folio CMS — odesílají je zdrojové systémy:

Stav: Kompletní seznam transakčních e-mailů v REMP CRM, jejich mail_type_code a případné přizpůsobení šablon je záležitostí Economia ↔ FatChilli — Sinfin do konfigurace REMP Maileru nezasahuje. Z pohledu CMS je důležitý pouze newsletter flow (viz A7).

C4. metered paywall

Otázka: Bude metered paywall (X článků zdarma)?

Pokud ano:

• Counting mechanismus (cookie / localStorage / server-side per user)
• Reset perioda (měsíčně?)
• Kolik článků zdarma?
• Jak se počítá pro anonymní vs. přihlášené?

D. Rizika

D1. REMP CRM API neznámé [VYSOKÉ RIZIKO]

Popis: Nemáme kompletní API dokumentaci REMP CRM. Odhady vychází z předpokládaných endpointů.

Mitigace:

• Získat API docs / Swagger od FatChilli ASAP
• Proof-of-concept integration v Sprint 1
• Buffer v odhadu (+15 %)

D2. EGO-SSO (Ecoidentita) není hotové [VYSOKÉ RIZIKO]

Popis: Pokud EGO-SSO SSO redirect + userinfo flow není funkční do startu projektu, nelze implementovat user sync. Viz CMS-353 a Implementace EGO-SSO pro klienty.

Navíc je třeba vyřešit sdílení auth cookies na úrovni domény druhého řádu (.hn.cz) — pravděpodobně skrze Cloudflare Worker.

Mitigace:

• Mock EGO-SSO provider pro development
• Prioritizovat EGO-SSO implementaci v epiku 34
• Ověřit stav Cloudflare Worker konfigurace s Economia DevOps

D3. REMP CRM subscription types a checkout nejsou definovány [VYSOKÉ RIZIKO]

Popis: FatChilli musí nakonfigurovat subscription types, checkout flow a platební bránu v REMP CRM. Bez toho nelze testovat entitlement ani paywall.

Mitigace:

• FatChilli definuje subscription types a checkout v rámci REMP CRM ASAP
• Alternativa: mock subscription types pro development

D4. Performance — entitlement check na každém page load [STŘEDNÍ RIZIKO]

Popis: Volání REMP CRM API pro každý article show s paywallem.

Mitigace:

• Redis cache (TTL 2–5 min)
• Webhook-based cache invalidation
• Circuit breaker pro CRM API

D5. REMP CRM outage → paywall breakdown [STŘEDNÍ RIZIKO]

Popis: Pokud REMP CRM není dostupný, CMS nemůže ověřit entitlement.

Mitigace:

• Degraded mode: článek zůstane zamknutý (safe default)
• Cached entitlement survives short outages
• Health check endpoint + alerting

D6. Data synchronizace race conditions [NÍZKÉ RIZIKO]

Popis: REMP CRM vytvoří subscription → webhook → CMS invaliduje cache → user navštíví článek → cache ještě neaktualizována.

Mitigace:

• Webhook processing s vysokou prioritou
• Optimistic UI (po platbě rovnou odemknout lokálně v REMP CRM flow)
• Krátký TTL na entitlement cache

E. Co se stane při nepopsané funkcionalitě

Proces pro nové požadavky

1. Identifikace: Nový požadavek je zadán jako user story / epic
2. Analýza dopadu: PM + Tech Lead posoudí, zda spadá do REMP CRM, Folio CMS, nebo jiný systém
3. Rozhodovací strom:
   • Týká se obsahu / redakce → Folio CMS
   • Týká se plateb / předplatného / produktů / checkout → REMP CRM (FatChilli)
   • Týká se segmentace / cílení → REMP CRM / Campaign
   • Týká se e-mailů → REMP Mailer
   • Týká se analytics → REMP Beam (fáze 2)
4. API rozšíření: Pokud stávající API nepostačuje:
   • Definovat nový endpoint / parametr
   • Review s REMP vendorem (pokud je potřeba změna na straně REMP)
   • Implementovat na obou stranách
5. Nacenění: Ad-hoc požadavky se nacení zvlášť (SP + overheads)

Eskalační matice

F. Na co jste se nezeptali (unsolicited insights)

F1. GDPR a souhlas se zpracováním

Při synchronizaci user dat do REMP CRM dochází k přenosu PII do dalšího systému. Uživatel musí být informován (privacy policy) a ideálně dát souhlas.

F2. E-mail deliverability

REMP Mailer bude odesílat e-maily jménem Economia. Je potřeba:

• SPF / DKIM / DMARC záznamy pro doménu economia.cz / hn.cz
• Warming up pro novou odesílací infrastrukturu
• Monitoring deliverability (bounce rate, spam complaints)

F3. A/B testing paywall messaging

Campaign může A/B testovat paywall bannery, ale samotné paywall lock UI v CMS ne. Zvážit:

• Server-side A/B testing pro paywall CTA
• Metriky: conversion rate, churn rate

F4. Content protection beyond paywall

Paywall chrání HTML obsah. Ale:

• Obrázky v článku — jsou na CDN a přístupné přímo?
• RSS feed — obsahuje plné články?
• SEO snippets — Google crawlery vidí plný obsah?
• AMP — jak se řeší paywall v AMP?

F5. Multi-site architektura

Folio CMS podporuje multi-site (HN, Respekt, …). Jak se REMP integruje cross-site?

• Jeden REMP CRM instance pro všechny Economia weby?
• Subscription types per site?
• Cross-site entitlement (combo předplatné)?

F6. Migrace legacy subscription dat

Pokud existují stávající předplatitelé (legacy e-shop), musí být migrováni:

• Import do REMP CRM (bulk)
• Link na Ecoidentita user ID
• Zachování expiration dates

F7. Monitoring a observability

Integrované systémy vyžadují end-to-end monitoring:

• Latency REMP API calls (p50, p95, p99)
• Error rate per endpoint
• Sync job failure rate
• Entitlement cache hit ratio
• Newsletter delivery rate

F8. Testovatelnost

Pro CI/CD pipeline je nutné:

• Mock REMP API pro unit testy (WebMock / VCR)
• REMP staging pro integration testy
• Seed data management
• Test isolation (REMP staging nesmí být sdílený s jinými projekty)