Open Questions
Kompletní seznam otevřených otázek identifikovaných během analýzy a specifikace projektu Colosseum MA. Otázky jsou organizované podle zdrojového dokumentu (PRD-00 až PRD-06, Tech Spec).
Otázky jsou připraveny pro správu v Supabase databázi — každá má unikátní kód, kategorii, prioritu a stav. Odpovědi budou zaznamenávány průběžně po konzultacích s klientem.
Celkem: 62 otázek | Stav: 55 otevřených, 7 vyřešených z CoreAPI analýzy a architektury (únor 2026)
Souhrn podle zdroje
| Zdroj | Počet otázek | High priority | Medium priority | Low priority |
|---|---|---|---|---|
| PRD-00 — Přehled projektu | 6 | 4 | 2 | 0 |
| PRD-01 — Nákup vstupenek | 8 | 3 | 5 | 0 |
| PRD-02 — Klientská zóna | 6 | 4 | 2 | 0 |
| PRD-03 — Notifikace a personalizace | 7 | 1 | 6 | 0 |
| PRD-04 — Věrnostní program | 8 | 5 | 3 | 0 |
| PRD-05 — White-label B2B | 7 | 4 | 3 | 0 |
| PRD-06 — Obsah a podpora | 8 | 1 | 7 | 0 |
| Tech Spec — Mobilní vývoj | 12 | 5 | 6 | 1 |
| Celkem | 62 | 27 | 34 | 1 |
PRD-00 — Přehled projektu
OQ-00-01 [TBD] high
Ticket Swap — Chceme oficiální sekundární trh na převod vstupenek? Jaká pravidla (cenový strop, poplatek)?
- Kontext: Funkce je v kategorii TBD — čeká na rozhodnutí klienta. Zahrnuje marketplace, detail transakce, potvrzení převodu. 3 obrazovky (P13, S25, X26).
- Dopad: Významná změna scope — nový marketplace modul, právní a obchodní implikace
OQ-00-02 [F2+] medium
Blog / obsah — Bude v MVP, nebo až v další fázi? Kdo bude tvořit obsah?
- Kontext: Aktuálně zařazeno do F2+. Rozhodnutí o dřívějším zařazení by přesunulo S20, S21, X25 do F1 a navýšilo scope.
- Dopad: Ovlivňuje content strategii a scope F2+
OQ-00-03 [F2+] medium
White-label MVP segment — Začínáme s divadly, nebo jinými institucemi?
- Kontext: Workshop identifikoval divadla a hudbu jako segmenty s opakovanou návštěvností a motivací ke stažení app.
- Dopad: Ovlivňuje pilotní strategii white-label B2B
OQ-00-04 [MVP] high
Typ aplikace — React Native vs. Flutter? Rozhodnutí závisí na kompetencích dodavatelského týmu.
- Kontext: Podrobná analýza v
context/analysis/tech-stack-rn-vs-flutter.md. Flutter má výhody u interaktivního sálu, white-label a výkonu. RN u talent poolu a nativního look & feel. - Dopad: Blokuje technické plánování a prototypování celého projektu
OQ-00-05 [MVP] high
Prohlídkové vstupenky — Jsou součástí MVP?
- Kontext: V zadání zmíněny (časované prohlídky, nečasované okruhy), ale v MVP rozpisu nejsou explicitně. Pokud schváleno, znamená novou primární obrazovku s time slot pickerem.
- Dopad: +8h nová primární obrazovka (time slot picker)
OQ-00-06 [MVP] high
Hotovostní platba — Jak přesně funguje scénář „rezervace s hotovostní platbou"? Kde a kdy zákazník platí?
- Kontext: Scénář vyžaduje vyzvednutí na pokladně. Ovlivňuje X2 (Thank you — Rezervováno) a business rules.
- Dopad: Ovlivňuje checkout flow, X2 obrazovku a business rules
PRD-01 — Nákup vstupenek
OQ-01-01 [MVP] high — VYŘEŠENO z CoreAPI
Prohlídkové vstupenky — Jsou časované prohlídky a nečasované okruhy součástí MVP?
- Kontext: Pokud schváleno → nová primární obrazovka s time slot pickerem (+8h).
- Dopad: +8h nová primární obrazovka (time slot picker)
- Odpověď z CoreAPI: API plně podporuje tours + circuits (
POST /cart/ticket/add/tour,GET /cashdesk/tour/{tourId},GET /catalog/tour/{tourId},GET /cashdesk/non-timed-circuit). Rozhodnutí je business scope, ne tech bariéra. Viz CoreAPI integrace.
OQ-01-02 [MVP] high
Hotovostní platba — Jak přesně funguje scénář „rezervace s hotovostní platbou"? Kde a kdy zákazník platí? Jak dlouho je rezervace platná?
- Kontext: Hotovost = pouze rezervace, zákazník platí na pokladně. Vyzvednutí min. X minut před akcí.
- Dopad: Ovlivňuje X2 a business rules
OQ-01-03 [MVP] medium — VYŘEŠENO z CoreAPI
Kupóny — kumulativnost — Lze uplatnit více kupónů na jednu objednávku? Nebo jen jeden?
- Kontext: Aktuálně TBD v business rules. Validace v real-time proti API.
- Dopad: Ovlivňuje P5 UI a validační logiku
- Odpověď z CoreAPI: Ano, kupóny JSOU kumulativní. API rozlišuje tři úrovně: per-ticket (
/cart/ticket/set-voucher), cart-level (/cart/voucher/add) a platební (/cart/voucher-payment/add). Uživatel může mít per-ticket slevu + cart-level kupón + platební voucher na jedné objednávce.DiscountType: Percent, ByAmount, ToAmount.
OQ-01-04 [MVP] high — VYŘEŠENO z CoreAPI
Seat map formát — V jakém formátu dodává Colosseum API data pro sály? SVG? JSON s koordináty?
- Kontext: Stávající web používá textový grid (SCR-WEB-29, SCR-WEB-30). MA bude mít grafický SVG.
- Dopad: Klíčové pro tech spec seat map
- Odpověď z CoreAPI: JSON s koordináty.
HallSeatOnlinemáx1, y1, x2, y2(obdélníkové souřadnice sedadla),color(#AARRGGBB),rotation(stupně clockwise). Sekce sálu (HallSection) mají tvary: Rectangle, Triangle, Quadrilateral, Ellipse. Endpointy:GET /cashdesk/event/{eventId}+GET /cashdesk/event/matrix/{eventId}. Klient renderuje Canvas/SVG z těchto JSON dat.
OQ-01-05 [MVP] medium — VYŘEŠENO z CoreAPI
Servisní poplatek — Účtuje Colosseum servisní poplatek k ceně vstupenky? Jak se zobrazuje zákazníkovi?
- Kontext: Ceny v CZK, včetně DPH. Poplatky zobrazeny v souhrnu košíku.
- Dopad: Ovlivňuje cenový souhrn v P5
- Odpověď z CoreAPI: Ano, fees jsou separátní řádky v košíku a objednávce. Cart a Order mají
fees[]sTransactionFee/OrderFeeobjekty. Zobrazují se jako samostatné položky v cenovém souhrnu (ne zahrnuté v ceně vstupenky).
OQ-01-06 [MVP] medium
Landscape seat map — Podporujeme landscape orientaci pro seat map (P4)?
- Kontext: Seat map (P4) je nejkomplexnější obrazovka — SVG/Canvas viewport s pinch-to-zoom. Velké sály mohou být přehlednější na šířku.
- Dopad: +4h varianta P4
OQ-01-07 [MVP] medium
Doplňkový prodej v MVP — Chceme v MVP alespoň placeholder pro doplňkový prodej v košíku, nebo čistě až F2+?
- Kontext: Plný doplňkový prodej (S23) je zařazen do F2+. F1 má preview upsell doplňků v košíku (P5).
- Dopad: Ovlivňuje P5 design
OQ-01-08 [MVP] medium
Předplatné nákup — Jak probíhá nákup předplatného? Je to single transaction nebo série nákupů?
- Kontext: Abonmá = sada představení za zvýhodněnou cenu. Nákup jako celek nebo jednotlivě.
- Dopad: Ovlivňuje S11 flow
PRD-02 — Klientská zóna
OQ-02-01 [MVP] medium
Email editace — Může uživatel změnit email po registraci? Pokud ano, jak probíhá ověření?
- Kontext: Ověření nového emailu přes potvrzovací link. Starý email platný do potvrzení nového.
- Dopad: Ovlivňuje S14 (Editace profilu)
OQ-02-02 [MVP] high
Sdílení = kopie vs. převod — Je sdílení vstupenky kopie (obě strany mají přístup) nebo převod (odesílatel ztrácí přístup)?
- Kontext: Aktuální návrh: sdílená vstupenka = kopie, ne převod. Obě strany mají přístup.
- Dopad: Ovlivňuje S8, X17 a business rules — zásadní dopad na sdílení a bezpečnost vstupenek
OQ-02-03 [MVP] high
Guest → registrace migration — Pokud guest nakoupí a pak se zaregistruje, propojí se jeho objednávky s novým účtem?
- Kontext: Guest nedostane wallet — vstupenky pouze na email. Migrace objednávek po registraci.
- Dopad: Ovlivňuje backend i UX flow — propojení objednávek
OQ-02-04 [MVP] high
Tablet layout — Řešíme tablet verzi klientské zóny?
- Kontext: Tablet verze přidává adaptivní layouty pro iPad a Android tablety.
- Dopad: +20–30 % na adaptivní layouty — významné navýšení scope
OQ-02-05 [MVP] high
Dark mode — Je dark mode součástí MVP?
- Kontext: Dark mode vyžaduje validaci celého design systému v tmavém režimu.
- Dopad: Ovlivňuje DS, +8–12h na validaci
OQ-02-06 [F1] medium
Onboarding timing — Zobrazuje se S6 ihned po registraci, nebo až po prvním nákupu?
- Kontext: Ovlivňuje conversion funnel — zobrazení před nákupem může odradit, po nákupu může zlepšit retenci.
- Dopad: Ovlivňuje conversion funnel a retenci
PRD-03 — Notifikace a personalizace
OQ-03-01 [MVP] medium
Timing custom pre-promptu (X12) — Zobrazit po registraci, po 2. návštěvě, nebo obojí?
- Kontext: Custom pre-prompt dialog s hodnotovou propozicí se zobrazuje před systémovým permission dialogem.
- Dopad: Vliv na opt-in rate push notifikací
OQ-03-02 [F1] high
Watchdog — priorita notifikace — Pokud se uvolní místa a watchdog má 50 uživatelů, dostanou všichni notifikaci současně?
- Kontext: Race condition na omezený počet míst. Watchdog je per user + per EventDate.
- Dopad: Race condition — ovlivňuje UX a fairness systému při omezeném počtu míst
OQ-03-03 [F1] medium
Personalizace bez onboardingu — Pokud uživatel přeskočí onboarding (S6), mají se personalizované notifikace generovat na základě historie nákupů?
- Kontext: Uživatel bez preferencí aktuálně nedostává personalizované push.
- Dopad: Ovlivňuje personalizační strategii a dosah notifikací
OQ-03-04 [F1] medium
Dotazník spokojenosti — Interní řešení (in-app formulář) nebo napojení na external service (Survicate, Typeform)?
- Kontext: Push notifikace ~3 dny po akci s odkazem na krátký dotazník.
- Dopad: Ovlivňuje integrační náročnost a náklady
OQ-03-05 [F1] medium
Re-engagement threshold — Kolik dní neaktivity = re-engagement push? Default 30 dní — odsouhlasit s klientem.
- Kontext: Konfigurovatelné v CMS, default 30 dní.
- Dopad: Ovlivňuje re-engagement strategii
OQ-03-06 [F2+] medium
Geofence notifikace (F2+) — Vyžaduje „Always" location permission, což výrazně snižuje opt-in.
- Kontext: Geolokační obrazovka (S22) zobrazuje akce na mapě. Max 1 geofence push denně.
- Dopad: Vysoká technická náročnost, nízký opt-in rate pro Always permission
OQ-03-07 [F1] medium
Grouping notifikací — Flat feed s groupingem více než 3 za méně než 1h. Validovat — není vhodnější grouping per event?
- Kontext: Notifikační centrum (S19) — chronologický feed. Grouping se aktivuje při více než 3 notifikacích stejného typu za méně než 1h.
- Dopad: Ovlivňuje UX notifikačního centra
PRD-04 — Věrnostní program
OQ-04-01 [F1] high
Bodový přepočet — Je 5 % z nákupu finální? Jaký je minimální nákup pro připsání bodů?
- Kontext: Aktuálně: 5 % z celkové ceny vstupenek bez poplatků, zaokrouhleno nahoru. Průměrný nákup 2 000 Kč = 100 bodů.
- Dopad: Zásadní dopad na ekonomiku věrnostního programu a motivaci uživatelů
OQ-04-02 [F1] high
Merch logistika — Kdo zajišťuje fulfillment merch objednávek? Pořadatel přímo, nebo Colosseum jako prostředník?
- Kontext: Merch od pořadatele (reklamní předmět) nebo interní Colosseum merch. Lhůta per pořadatel (CMS).
- Dopad: Významný dopad na provozní náklady a logistiku — fulfillment, skladování, doručení
OQ-04-03 [F1] high
Kupón od pořadatele — obchodní model — Jak přesvědčit pořadatele, aby poskytoval slevy do věrnostního e-shopu?
- Kontext: TasteTown model — pořadatel získá nové zákazníky výměnou za slevu. Pořadatel definuje výši slevy, Colosseum bodovou cenu.
- Dopad: Zásadní pro obchodní model věrnostního programu a spolupráci s pořadateli
OQ-04-04 [F1] high
VIP místa v košíku — Jak se kupón z e-shopu promítne do kategorie v seat map / košíku?
- Kontext: Výměna za „kategorii zákazníka" uplatnitelnou v košíku. Technicky propojení loyalty a checkout flow.
- Dopad: Významná technická komplexita — integrace loyalty s checkout a seat map
OQ-04-05 [F1] high
Bar / občerstvení — validace — Jak se ověřuje uplatnění kupónu na občerstvení? QR scan barem?
- Kontext: Technicky: ukázání QR v aplikaci na baru. Otázka integrace s POS systémy na venue.
- Dopad: Vyžaduje integraci s POS systémy pořadatelů — významný scope
OQ-04-06 [F2+] medium
Level systém (F2+) — Jaké konkrétní benefity per úroveň? Early access = kolik dní předem?
- Kontext: Navrhované úrovně: Bronze/Silver/Gold/Platinum dle lifetime bodů.
- Dopad: Ovlivňuje gamifikační strategii a motivaci uživatelů
OQ-04-07 [F1] medium
Expirace — komunikace — Stačí 1 push notifikace 14 dní předem, nebo série (14d, 7d, 1d)?
- Kontext: Body expirují 12 měsíců po posledním zisku (rolling window).
- Dopad: Ovlivňuje komunikační strategii a uživatelskou spokojenost
OQ-04-08 [F1] high
Záporný bodový zůstatek — Při refundu po utracení bodů: interně záporný stav, UI zobrazí 0. Je to OK?
- Kontext: Aktuální návrh: zůstatek může jít do mínusu interně, UI zobrazí 0, další zisky nejprve pokryjí záporný stav.
- Dopad: Finanční a právní dopad — ochrana spotřebitele vs. zneužití refundů
PRD-05 — White-label B2B
OQ-05-01 [F2+] high
Věrnostní program ve white-label — Sdílený Colosseum Premium nebo separátní program per pořadatel?
- Kontext: Sdílený má výhodu pro uživatele (víc bodů), separátní pro pořadatele (vlastní branding věrnosti).
- Dopad: Zásadní architektonické rozhodnutí — ovlivňuje datový model a UX napříč aplikacemi
OQ-05-02 [F2+] high
Publikace pod klientovým developer účtem — Někteří klienti mohou chtít vlastní App Store / Play Store účet.
- Kontext: Standard: Colosseum účet. Ale Národní divadlo, velké sítě mohou chtít vlastní.
- Dopad: Technické a obchodní implikace — build pipeline, distribuce, správa certifikátů
OQ-05-03 [F2+] high
Pricing model — Setup fee + monthly subscription? Revenue share z prodejů? Kombinace?
- Kontext: Business model pro white-label produkt. Ovlivňuje scope a tier strukturu konfigurace.
- Dopad: Zásadní obchodní rozhodnutí — ovlivňuje celý B2B business model
OQ-05-04 [F2+] medium
Custom funkce per klient — Kde je hranice white-label konfigurace vs. custom development?
- Kontext: White-label standard: konfigurace přes CMS. Custom development = oddělená kalkulace.
- Dopad: Ovlivňuje produktovou strategii a škálovatelnost white-label
OQ-05-05 [F2+] high
Pilotní klient — Kdo bude první white-label zákazník?
- Kontext: Workshop doporučuje divadla a hudbu jako pilotní segment s opakovanou návštěvností.
- Dopad: Blokuje pilotní fázi — výběr klienta ovlivňuje prioritizaci funkcí
OQ-05-06 [F2+] medium
Web builder (varianta řešení z workshopu) — Je alternativa (2) Colosseum Web Builder stále na stole?
- Kontext: Workshop identifikoval 3 varianty. Aktuálně jdeme cestou (3) white-label MVP.
- Dopad: Ovlivňuje dlouhodobou produktovou roadmapu
OQ-05-07 [F2+] medium
Obsah ve white-label — Má pořadatel přístup k blog modulu? Nebo jen k bannerům a novinkám?
- Kontext: Zjednodušené CMS: banner management, novinky, push notifikace pod vlastním brandem.
- Dopad: Ovlivňuje scope CMS a content managementu pro B2B klienty
PRD-06 — Obsah a podpora
OQ-06-01 [F1] high
Chat řešení — Vlastní implementace, nebo napojení na existující helpdesk (Zendesk, Intercom, Freshdesk)?
- Kontext: S18 (Chat / rozšířená podpora) v F1. Doporučení: napojení na existující helpdesk řešení přes SDK / API.
- Dopad: Významný dopad na náklady a rychlost implementace — vlastní vs. SaaS řešení
OQ-06-02 [F2+] medium
Kdo tvoří blog obsah? — Colosseum interní tým, external copywriter, nebo pořadatelé?
- Kontext: Doporučení: min. 10 článků při spuštění, 2–3 nové týdně.
- Dopad: Ovlivňuje content strategii a provozní náklady
OQ-06-03 [F2+] medium
Blog kategorie — Finální seznam kategorií?
- Kontext: Aktuální návrh: Rozhovory / Tipy / Recenze / Novinky / Za scénou.
- Dopad: Ovlivňuje strukturu content modelu a CMS
OQ-06-04 [F1] medium
FAQ — self-service scope — Kolik FAQ položek při launchi F1? Kdo je tvoří?
- Kontext: FAQ (S17) s kategorizovanými otázkami a vyhledáváním.
- Dopad: Ovlivňuje objem práce na obsahu a kvalitu self-service
OQ-06-05 [F1] medium
Volání z aplikace — Klasický telefonní hovor (native dialer), nebo VoIP (in-app volání)?
- Kontext: Doporučení: native dialer v F1, VoIP jako F2+ volitelné rozšíření.
- Dopad: Ovlivňuje technickou komplexitu a náklady
OQ-06-06 [F1] medium
Podpora per pořadatel vs. centrální — Má každý pořadatel svou linku podpory, nebo vše jde přes Colosseum?
- Kontext: White-label app zobrazuje kontakt na pořadatele s Colosseum fallbackem.
- Dopad: Ovlivňuje routing podpory a provozní model
OQ-06-07 [F2+] medium
Blog v MVP? — Aktuální zařazení F2+. Přesun do F1 by navýšil scope o 3 obrazovky.
- Kontext: Souvisí s OQ-00-02. Přesun do F1 = S20, S21, X25 (+9h design).
- Dopad: Přesun do F1 = +9h na design (S20, S21, X25)
OQ-06-08 [F2+] medium
Sociální sítě — in-app feed? — Embedded Instagram feed / YouTube playlist přímo v aplikaci?
- Kontext: Aktuálně jen ikony s linky na Instagram, Facebook, YouTube. Embedded = vyšší engagement, ale závislost na external API.
- Dopad: Ovlivňuje engagement a závislost na externích API
Tech Spec — Mobilní vývoj
OQ-T-01 [MVP] high — VYŘEŠENO z CoreAPI
Seat map data formát — V jakém formátu Colosseum API dodává sálové plány? SVG? JSON s koordináty? Proprietární formát?
- Kontext: Stávající web používá textový grid. MA vyžaduje SVG/Canvas rendering s pinch-to-zoom. Klíčové pro P4.
- Dopad: Klíčové pro seat map implementaci — blokuje technický návrh P4
- Odpověď z CoreAPI: Viz OQ-01-04 — JSON s koordináty (
x1,y1,x2,y2), barva (#AARRGGBB), rotace. Endpointy:cashdesk/event/{id}+cashdesk/event/matrix/{id}. Klient renderuje Canvas/SVG.
OQ-T-02 [MVP] high
Real-time seat updates — Potřebujeme WebSocket pro real-time obsazenost sálu, nebo stačí polling?
- Kontext: Debounced seat status refresh je v performance požadavcích. WebSocket vs. polling má zásadní dopad na architekturu.
- Dopad: Architektura, performance, UX — zásadní při špičkovém prodeji
OQ-T-03 [MVP] medium
Certificate pinning — Má Colosseum infrastruktura podporu pro certificate pinning?
- Kontext: Doporučeno pro API endpointy. Závisí na infrastruktuře a CDN.
- Dopad: Ovlivňuje security model aplikace
OQ-T-04 [F1] medium — VYŘEŠENO z architektury
Push notification provider — Používá Colosseum vlastní push infra nebo integrujeme APNs/FCM přímo?
- Kontext: Token management: device token se napojí na user account. MVP základ, F1 plný systém.
- Dopad: Ovlivňuje F1 architekturu notifikačního systému
- Odpověď: Existuje dedikovaný Notification Server s vlastní DB (uživatelé + FCM tokeny). APP registruje FCM token přímo u Notification Serveru. Dva zdroje triggerů: automatické z Colossea + marketingové webhooky z DatoCMS. Delivery přes Firebase (FCM). Viz Architektura.
OQ-T-05 [MVP] high
Platební brána — Která platební brána (GoPay, ČSOB, Stripe, Comgate...)?
- Kontext: Apple Pay / Google Pay preferovány. Kartová platba přes platební bránu.
- Dopad: Ovlivňuje checkout UX a SDK integraci — klíčové pro P6
OQ-T-06 [MVP] medium
CDN pro obrázky — Poskytuje Colosseum API responsivní image varianty (width/height params)?
- Kontext: Image loading strategie: progressive loading, WebP, CDN s responsivními variantami (1x, 2x, 3x).
- Dopad: Ovlivňuje image loading strategii a performance
OQ-T-07 [MVP] high
Framework rozhodnutí — Flutter nebo React Native? Termín rozhodnutí?
- Kontext: Viz
context/analysis/tech-stack-rn-vs-flutter.md. Rozhodnutí závisí na kompetencích vývojového týmu. - Dopad: Blokuje celé technické plánování a prototypování projektu
OQ-T-08 [MVP] high
Tablet podpora — Řešíme adaptive layout pro tablety (iPad, Android tablets)?
- Kontext: Souvisí s OQ-02-04. Tablet verze přidává významný scope.
- Dopad: +20–30 % design effort na responsive breakpointy — významné navýšení scope
OQ-T-09 [TBD] low
App Clips / Instant Apps — Chceme lightweight instant verzi pro sdílené odkazy?
- Kontext: Event detail landing bez nutnosti instalace. Nízká priorita, ale dobrý conversion nástroj.
- Dopad: Rozšíření scope — nice-to-have pro konverzi z deep linků
OQ-T-10 [MVP] medium
Analytics a crash reporting tooling — Firebase Analytics + Crashlytics, Sentry, Mixpanel, Amplitude?
- Kontext: Klíčové události definovány v tech spec sekce 11. Automatický crash reporting s breadcrumbs.
- Dopad: Ovlivňuje SDK integraci, velikost binary a privacy compliance
OQ-T-11 [MVP] medium
QR rolling code — Má QR kód na vstupence být statický nebo rolling (periodicky obnovovaný)?
- Kontext: QR payload podepsaný serverovým klíčem. Offline validace vyžaduje podpis bez API volání.
- Dopad: Ovlivňuje offline architekturu a bezpečnost vstupenek
OQ-T-12 [MVP] high — VYŘEŠENO z CoreAPI + architektury
Existující API — Má Colosseum existující REST API (pro web), které bude rozšířeno, nebo se staví nové API?
- Kontext: Stávající web pravděpodobně má vlastní API. Rozhodnutí ovlivňuje celý backend scope a timeline.
- Dopad: Zásadní dopad na architekturu a timeline — rozšíření existujícího vs. nové API
- Odpověď: Colosseum má dvě existující API: SOAP (sync představení/pořadatelů do DatoCMS) a JSON (
coreapi_online.json, 70 endpointů, v17.0.0.0) pro zákaznickou zónu. APP bude používat existující JSON API přímo. Programový obsah jde přes PORTAL (Next.js BFF). Viz Architektura.
Prioritizace
Blokující pro MVP (nutné rozhodnout co nejdříve)
| Kód | Otázka | Oblast |
|---|---|---|
| OQ-00-04 | Framework — Flutter vs. React Native | Celý projekt |
| OQ-T-07 | Framework rozhodnutí — termín | Celý projekt |
| OQ-T-05 | Platební brána | Checkout |
| OQ-T-02 | Real-time seat updates (WebSocket vs. polling) | Seat map |
| OQ-00-06 / OQ-01-02 | Hotovostní platba flow | Checkout |
| OQ-02-04 / OQ-T-08 | Tablet podpora | Design scope |
| OQ-02-05 | Dark mode v MVP | Design system |
| OQ-02-02 | Sdílení = kopie vs. převod | Vstupenky |
| OQ-02-03 | Guest → registrace migration | Auth |
Důležité pro F1 plánování
| Kód | Otázka | Oblast |
|---|---|---|
| OQ-04-01 | Bodový přepočet — finální hodnota | Loyalty |
| OQ-04-02 | Merch logistika | Loyalty |
| OQ-04-03 | Kupón od pořadatele — obchodní model | Loyalty |
| OQ-04-04 | VIP místa v košíku — technická implementace | Loyalty × Checkout |
| OQ-04-05 | Bar / občerstvení — validace (POS integrace) | Loyalty |
| OQ-03-02 | Watchdog — priorita notifikace (fairness) | Notifikace |
| OQ-06-01 | Chat řešení — vlastní vs. SaaS | Podpora |
Strategické (F2+ roadmap)
| Kód | Otázka | Oblast |
|---|---|---|
| OQ-00-01 | Ticket Swap — sekundární trh | Scope |
| OQ-05-01 | Věrnostní program ve white-label | White-label |
| OQ-05-03 | Pricing model white-label | Business |
| OQ-05-05 | Pilotní klient | White-label |