Přeskočit na obsah
Společný návrh kalkulaček

Pravidla návrhu a dalšího vývoje kalkulaček

Stav k 4. 11. 2026 · Travel 0.24.0 · Úraz 0.16.2

Verze 0.15.0 · stav k 2026-11-04

Původní WordPress stylopis · Aktuální pravidla vývoje

O dokumentu a jeho stavu

Stav pravidla je uveden u každé položky. Návrh ani stav „ověřit“ nepředstavují schválení. Tento dokument není plošným rozhodnutím o implementaci.

Verze: 0.15.0 · Datum: 2026-11-04

Výchozí travel: 0.24.0
Výchozí úraz: 0.16.2

Stáhnout strukturovaný katalog JSON · Historický snímek 0.1.0

Rozhodnutí přijatá pro tuto verzi

Vybrané volby byly následně výslovně zadány k realizaci. Nerozhodnuté oblasti zachovávají dosavadní podobu.

Rozhodovací základ

Identita a vzhled

Potvrzeno · ZAD-01

Červený malý sekční nadpis

Eyebrow/kicker, například název pojištění a úvodní popisek formuláře, zůstává červený #F42534 v úvodu, krocích, kartách a detailech. Nesmí se při sjednocování modré přebarvit na modrou.

Zdůvodnění: Výslovná korekce uživatele z 2. 11. 2026. Kontrast malého významového textu vůči podkladu zůstává otevřeným rozporem, nikoli prokázanou shodou WCAG. D02=A nyní výslovně zachovává stávající prototypový odstín; nejde o schválení shody přístupnosti pro produkci.

Kontroly
  • Odečíst výsledný styl statických i dynamických kickerů na mobilu a desktopu.
  • Prověřit kontrast na skutečném podkladu a případnou změnu odstínu předložit k rozhodnutí.

Zdroj: AGENTS.md; zadání červených malých nadpisů; section-accents.css
Rozhodnutí: D02

Potvrzeno · ZAD-02

Světlé písmo zelené hlavní akce

Hlavní zelená tlačítka používají světlé, nyní bílé písmo. Tichá náhrada tmavým textem není přijatou úpravou.

Zdůvodnění: Výslovný požadavek uživatele. Současná bílá na #00B53B má vypočteně 2,737:1; volba přístupnější zelené je nové rozhodnutí při zachování bílého písma. D02=A zachovává aktuální zelenou pro tuto prototypovou iteraci bez prohlášení o shodě WCAG.

Kontroly
  • Ověřit klid, hover, focus, disabled a loading odděleně.
  • Nevydávat samotné dodržení barvy textu za splnění kontrastních kritérií.

Zdroj: Zadání bílého písma na zelených akcích; aktuální měření a kontrastní posudek
Rozhodnutí: D02

Potvrzeno · ZAD-03

Bílý formulář na tmavším okolí

Formulářové karty a pole mají světlé plochy, stránka tmavší šedý podklad podle současného travelu. Základní reference je #FFFFFF proti #F2F4F7.

Zdůvodnění: Uživatel výslovně zvolil tento vztah ploch i přes odlišnosti původního WordPressu.

Kontroly
  • Prověřit skutečný výsledek kaskády u polí, panelů a vnořených sekcí.
  • Selected, chyba ani disabled nesmějí ztratit význam kvůli plošnému přebarvení.

Zdroj: Zadání sjednocení formulářů; uraz-unified.css; travel-refinement.css
Rozhodnutí: —

Potvrzeno · ZAD-04

Společná kontaktní hlavička a patička

Úraz používá konstrukci produktové hlavičky travelu. Patička má společný vzhled s pozadím #003B71 a světlým obsahem. Kontakty zůstávají správné pro konkrétní produkt.

Zdůvodnění: Výslovné požadavky na přenos hlavičky a patičky mezi produkty.

Kontroly
  • Ověřit produktový e-mail, telefon, pracovní dobu, odkazy a mobilní zobrazení.
  • Nedovozovat správnost kontaktu pouze ze shodného layoutu.

Zdroj: Zadání hlavičky a patičky; aktuální HTML obou verzí
Rozhodnutí: —

Potvrzeno · ZAD-08

Jednotný styl ilustrativních ikon

Travelové země mají navazovat na styl úrazových rizik: stejný modro-bílý materiál, tahy, odlesk a jemný stín. Nové členy sady vytvářet v odpovídajícím vektorovém formátu, pokud rozšiřují stávající SVG.

Zdůvodnění: Výslovné zadání ikon travelu ve stylu úrazu; formát je praktické zachování nynější sady.

Kontroly
  • Porovnat vedle sebe stejné zobrazovací velikosti a zkontrolovat čitelnost menšího motivu.
  • Smysl volby musí být dostupný textem, nikoli jen ilustrací.

Zdroj: Zadání ikon travelu; aktuální assets/destinations a assets/risks
Rozhodnutí: —

Návrh · DS-02

Typografické role místo plošných změn

Výchozí hero 48/34 px a pracovní H1 32/26 px s váhou 600 již vycházejí společně. Sekce formuláře, cena, nápověda a kicker mají vlastní role; nenahrazovat je jedním globálním H2 nebo velikostí všech textů.

Zdůvodnění: Čerstvá měření potvrzují shodu hlavních titulků, ale rozdíly sekcí a polí.

Kontroly
  • Porovnat stejné role na 375/1440 px a při zvětšení.
  • Zaznamenat odůvodněné výjimky pro husté nabídky či opakované osoby.

Zdroj: evidence/measurements.json; UX a architektonický posudek
Rozhodnutí: D05

Potvrzeno · ZAD-13

Jednotné značky a formulářové sekce

Úvodní výhody používají zelené kruhové značky s bílým zaškrtnutím podle travelu. Výběrové karty úrazu mají kulatý stavový checkmark. Osobní formuláře údaje/people sdílejí bílé bloky, boxová pole a červenou linku pod nadpisy podle úrazu.

Zdůvodnění: Výslovná vizuální korekce uživatele; červená linka patří nadpisu, nikoli běžnému poli.

Kontroly
  • Porovnat první krok a vybrané/nevybrané karty obou produktů na mobilu i desktopu.
  • Formulářové nadpisy mají 100 × 2 px červenou linku; pole zachovávají 16 px/r8/min48.

Zdroj: Navazující zadání uživatele z 2. 11. 2026
Rozhodnutí: —

Potvrzeno · ZAD-14

Kompaktní travel a ilustrační systém rizik

Travel na desktopu nemá další margin pod navigací. Počty mazlíčků v prvním kroku nemají vlastní podbarvení. Cestovní rizika používají ilustrované SVG ve stejném stylu jako rizika úrazu; vhodné existující ilustrace lze znovu použít.

Zdůvodnění: Výslovné navazující zadání; oddělit produktový obsah od společného vizuálního systému.

Kontroly
  • Na desktopu změřit mezeru pod navigací a na prvním kroku zkontrolovat mazlíčky.
  • Ověřit viditelné ikony ve výběru, mapě a odpovídajících detailech bez rozbitých prostředků.

Zdroj: Navazující zadání uživatele z 2. 11. 2026
Rozhodnutí: —

Navigace

Potvrzeno · ZAD-05

Travel bez prezentačního pruhu

Nový travel nedostává prezentační hlavičku ani odkaz na rozcestník verzí v produktové hlavičce. Čtyři vnější fáze používají logiku úrazu.

Zdůvodnění: Výslovné zadání pro současnou i budoucí práci; nástroje pro přezkum prototypu nemají přebít produktový průchod.

Kontroly
  • Otevřít oba starty a ověřit hlavičku.
  • Kontrolovat fáze Kalkulace, Konfigurace, Údaje a Rekapitulace a zachování dat při návratu.

Zdroj: AGENTS.md; předchozí zadání navigace
Rozhodnutí: D04

Potvrzeno · DS-05

Pravdivá fáze i podkrok na mobilu

Mobilní navigace má rozlišit čtyři vnější fáze a aktuální produktový podkrok. Číslo 1/4 nesmí slibovat čtyři obrazovky, pokud jich proces obsahuje více.

Zdůvodnění: Travel a úraz mají stejné fáze, ale rozdílné mobilní popisky a vnitřní členění.

Kontroly
  • Projít všechny větve a návraty před rekapitulací; v rekapitulaci je návrat k editaci podle nového zadání vypnutý.
  • Přechod zachová potvrzená data a má srozumitelný fokus; neuložený draft má definované chování.

Zdroj: travel-navigation.js; ferda-flow.js; fresh snímky; výslovné zadání implementace dle JSON z 2. 11. 2026
Rozhodnutí: D04

Prototyp a data

Potvrzeno · ZAD-06

Průchod bez AI a živých služeb

Každá prezentovaná větev prototypu musí být průchozí lokálně bez AI/API. Nabídnout ruční cestu nebo upravitelná modelová data; mapa rizik nesmí být blokována nefunkční AI.

Zdůvodnění: Uživatel požaduje produkční vzhled a současně všechny možnosti pro testování, pro travel i úraz.

Kontroly
  • Zablokovat vnější síť a projít demo i prázdný začátek.
  • Vyzkoušet alternativní vstup, mapu, volby, nabídky, úpravy a modelové dokončení.

Zdroj: AGENTS.md; zadání průchodnosti prototypů
Rozhodnutí: —

Potvrzeno · ZAD-07

Model zůstává modelem

Nezapojovat skutečné sjednání, platbu, e-maily ani živé AI. Kritické potvrzení má pravdivě popisovat modelový stav a nesmí vydávat simulaci za uskutečněné odeslání či smlouvu.

Zdůvodnění: Projektové vymezení modelových dat a vypnutých integrací. Aktuální travel má v potvrzení textový rozpor, přestože síťové odeslání je zablokované.

Kontroly
  • Ověřit vedlejší účinky i text výsledné obrazovky.
  • Přezkoumat e-mailový návrh, platbu, číslo smlouvy a dokončení v obou produktech.

Zdroj: AGENTS.md; marketingový posudek; fresh snímek travel done
Rozhodnutí: D09

Formuláře

Potvrzeno · ZAD-09

Konkrétní jiná země

Ve travelu nahrazuje obecné volby Evropa/mimo Evropu jediná Jiná země s následným seznamem konkrétních zemí. Vybraná země se zachová a používá v navazujícím průchodu.

Zdůvodnění: Výslovná korekce uživatele ve verzi 0.21.1.

Kontroly
  • Zkontrolovat podmíněné zobrazení a required/disabled skrytého selectu.
  • Ověřit evropskou i mimoevropskou zemi v nabídkách, mapě a po návratu; modelová oblast není potvrzením skutečného krytí.

Zdroj: Zadání Jiná země; travel-countries.js
Rozhodnutí: —

Potvrzeno · DS-03

Společná výchozí geometrie pole

Nové společné pole používá vstupní text 16 px, minimální výšku 48 px a radius 8 px. Checkbox, radio, range a hidden mají vlastní geometrii; jejich stav a význam se tímto nepřepisuje. Zachovat existující povinnost a funkční validaci.

Zdůvodnění: Travel má v mobilním vzorku datum 12 px/r7 a klienta 14 px/r7, úraz příkladová pole 16 px/r8. Potřeba zůstat kompaktní nesmí znečitelnit zadávání.

Kontroly
  • Vyzkoušet dlouhé hodnoty, datum, select i vyhledávání zaměstnání.
  • Ověřit skutečný telefon, softwarovou klávesnici, zvětšení textu a menší šířky.

Zdroj: Fresh měření; architektonický posudek; výslovné zadání implementace dle JSON z 2. 11. 2026
Rozhodnutí: D05

Návrh · A11Y-02

Stejný kontrakt validace

Pole má jednoznačný label, hint a viditelnou chybu s vazbou přes ID/aria-describedby; při chybě aria-invalid. Složená otázka používá legend. Skryté podmíněné pole není validováno a chyba nezmizí pouze změnou barvy.

Zdůvodnění: Travel a úraz mají rozdílnou implementaci chyb; stejný vzhled ji nenahradí.

Kontroly
  • Vyvolat chybu prázdným startem, opravit ji a odeslat znovu.
  • Ověřit souhrn/umístění první chyby i čtečku; nezaměňovat vypnutou osobní validaci prototypu za produkční pravidlo.

Zdroj: Architektonický posudek; current form renderery
Rozhodnutí: D05

Vydávání a údržba

Potvrzeno · ZAD-10

Historie a původní kořenový úraz se zachovávají

Starší vydané složky a ZIPy nepřepisovat. Původní serverový /cmp_uraz/ ponechat beze změny kvůli cizím odkazům; aktuální prototypy a reporty patří pod /prototypy/.

Zdůvodnění: Opakované explicitní vymezení uživatele a projektová pravidla.

Kontroly
  • Před a po nasazení porovnat symlink i součty původního úrazu.
  • Nové vydání aktivovat samostatně, s uchovaným předchozím cílem pro návrat.

Zdroj: AGENTS.md; DEPLOYMENT-PROTOTYPY.md
Rozhodnutí: —

Potvrzeno · ZAD-11

Reprodukovatelné verze a oba starty

Změna vzniká přes zdrojový recept jako nová samostatná verze, včetně vizuálních subverzí. Udržovat ukázkový i prázdný začátek a jednotný rozcestník s až deseti posledními verzemi viditelnými.

Zdůvodnění: Dosavadní schválený postup verzování a prezentace.

Kontroly
  • Sestavit znovu a porovnat výsledek i obsah ZIPu.
  • Prázdný začátek nesmí obnovit modelová osobní data; odkazy otevírají správné verze.

Zdroj: AGENTS.md; zadání verzování a rozcestníku
Rozhodnutí: —

Návrh · DEV-02

Přejímka změny podle dotčených rolí

Společná změna se ověří na obou produktech, z obou startů, ve stejných reprezentativních stavech. Rozsah kontroly odpovídá změně; výsledky a meze se uloží k vydání.

Zdůvodnění: Samotná shoda úvodu nestačí pro dynamické karty, dialogy nebo rekapitulaci.

Kontroly
  • Zachytit before/after, počítané styly, chybové stavy a dotčené větve.
  • Rozlišit screenshot, funkční průchod, klávesnicový test, test se čtečkou a test s lidmi; nezaměňovat jejich důkazní sílu.

Zdroj: Metodika tohoto reportu; tři posudky
Rozhodnutí: —

Společné komponenty

Potvrzeno · DS-01

Společná komponenta s produktovými daty

Zvolit sdílené sémantické tokeny a kontrakty komponent, ale zachovat produktové otázky, výpočet, osoby, krytí a dokumenty jako vlastní konfigurace.

Zdůvodnění: Shodné základní role dnes neodstraňují rozdíly úrazové konfigurace a cestovní mapy/aktivit.

Kontroly
  • Každá sdílená komponenta má dokumentované vstupy, stavy, události a produktové výjimky.
  • Pilot funguje v obou renderech dříve než se rozšíří na všechny obrazovky.

Zdroj: Tři odborné posudky; směr B hlavního reportu; výslovné zadání implementace dle JSON z 2. 11. 2026
Rozhodnutí: D01

Návrh · DS-04

Škála mezer, rohů a šířek

Definovat jednu výchozí škálu mezer 4/8/12/16/24/32/48 px, akční radius 8 px a obsahový 15 px. Maximální šířky a chování bočního shrnutí odvozovat od úlohy; výjimky pojmenovat.

Zdůvodnění: Současné komponenty mají směs rolí a geometrie; přesná hodnota není univerzální pravidlo původního WordPressu.

Kontroly
  • Vyhodnotit rozdíl formulářové karty, volby, nabídky a dialogu samostatně.
  • Nedělat velký dialog automaticky stejně velký jako informační kartu.

Zdroj: UX/UI a architektonický posudek
Rozhodnutí: D05

Potvrzeno · DEV-01

Vlastník každé CSS role a produktová výjimka

Směřovat ke kaskádě primitives → sémantické role → komponenty → produktové adaptéry → explicitní výjimky. Každá role má vlastníka a ukázky; nové výjimky neřešit řetězením širokých !important pravidel bez přezkumu.

Zdůvodnění: Dnešní finální akcentová vrstva opravuje předchozí široké přebarvení. Pořadí souborů a specifičnost jsou rizikem dalších úprav. První sdílená vrstva vlastní navigaci, pole a Summary; starší kaskáda se nepřepisuje plošně.

Kontroly
  • Před refaktorem změřit vítězný výsledný styl a všechny relevantní stavy.
  • Výjimka má produkt, důvod, rozsah a datum dalšího přezkumu.

Zdroj: Architektonický posudek; současná CSS kaskáda; výslovné zadání implementace dle JSON z 2. 11. 2026
Rozhodnutí: D01

Obsah a akce

Návrh · DS-06

Sloveso odpovídá skutečné akci

Zelená znamená hlavní postup či výběr, vedlejší detail a změna mají vlastní roli. Tlačítko vybírající nabídku nemá slibovat uzavření smlouvy. Modelový e-mail nebo platbu nazvat podle skutečného účinku.

Zdůvodnění: Výchozí travel karty už používají Vybrat, aktivní detail má jinou formulaci; nejde o totéž co neaktivní zachované renderery.

Kontroly
  • Ověřit viditelné karty, detail nabídky, rekapitulaci, platbu a konec.
  • Stejná akce má shodný název a ikonu; odlišný účinek nemusí mít stejné sloveso.

Zdroj: Marketingový posudek; aktivní renderery a screenshoty
Rozhodnutí: D09

Potvrzeno · DS-07

Cena má jednotku a stabilní význam barvy

Výchozí role ceny má být navy a vždy má vyjádřit časovou jednotku a obsah. Nepřenášet roční úrazovou cenu na cenu travelu za cestu. Ověřit červenou travelovou rekapitulační výjimku.

Zdůvodnění: Travel výsledky a boční shrnutí mají navy, jeho rekapitulace červenou; úrazová rekapitulace navy.

Kontroly
  • Porovnat výsledky, výběr, konfiguraci a rekapitulaci.
  • Při změně varianty/frekvence zůstává jasná celková částka i jednotka.

Zdroj: evidence/gpt-6-sol/price-probe.json; výslovné zadání implementace dle JSON z 2. 11. 2026
Rozhodnutí: D07

Nabídky a údaje

Návrh · DS-08

Stejná struktura nabídky, vlastní produktové porovnání

Sjednotit roli loga, názvu, ceny, klíčového krytí, dostupnosti, detailu a výběru. Zachovat cestovní aktivity/shodu i úrazovou matici rizik a frekvence; všechny modelové možnosti zůstanou dosažitelné.

Zdůvodnění: 22 travel variant a úrazové rizikové kombinace nejsou shodná informační úloha. Volba D06=A ponechává nynější jeden úplný travel seznam; společná nabídková komponenta zůstává dalším návrhem.

Kontroly
  • Ověřit řazení, filtr/seskupení a dostupnost všech variant i návrat z porovnání.
  • Nepřevzít počet sloupců nebo řádků jen kvůli shodnému vzhledu.

Zdroj: UX/UI posudek; dataset a current výsledky
Rozhodnutí: D06

Návrh · DS-09

Osoby jsou produktové, pole společná

Sdílet zobrazení jména, adresy, kontaktu a chyb; vztah pojistník/pojištěný, opakovaní cestující, obmyšlené osoby a dotazník určuje konkrétní produkt.

Zdůvodnění: Stejný formulář všech osob by potlačil skutečně odlišné povinnosti a závislosti.

Kontroly
  • Ověřit jiné osoby, sdílenou adresu, podmíněné osoby a úpravu z rekapitulace.
  • Změna role osoby zachová jen relevantní potvrzené hodnoty.

Zdroj: Aktuální people kroky; historický Ferda podklad
Rozhodnutí: —

Návrh · DS-10

Kontakty až podle doložené potřeby

Rozhodnout, proč a kdy se žádá e-mail a telefon. Preferovat kontakt po ceně/výběru, pokud výpočet či ověřený proces nevyžaduje dřívější krok; dřívější lead má jasný účel a odlišené povinné/volitelné údaje.

Zdůvodnění: Úraz nyní chce e-mail před cenou, travel v údajích; technickou potřebu aktuální Ferdy tento audit neověřil.

Kontroly
  • Doložit potřebu každého povinného kontaktu a sjednotit vysvětlení účelu.
  • Ověřit formulaci Bez telefonního spamu oproti zamýšlenému provoznímu postupu.

Zdroj: Marketingový posudek; core/profile a client-form
Rozhodnutí: D03

Potvrzeno · DS-11

Společná rekapitulace bez úprav

Rekapitulace slouží pouze ke kontrole údajů a pokračování. Neobsahuje úpravy jednotlivých sekcí ani navigační návrat k editaci. Fakta jsou přímo v bílém bloku, bez vnořování do šedých karet. Dokumenty, potřebné souhlasy a návazná modelová platba zůstávají dostupné. Kompaktní horní část obsahuje pojišťovnu, produkt, lhůtní pojistné úrazu (u travelu cenu za cestu) a tlačítko k platbě. Roční součet úrazu a zvolená frekvence zůstávají rozlišitelné; fakta jsou na desktopu ve dvou sloupcích. Mezi dvěma sloupci je u nových běžných verzí jemný svislý předěl v existující 32px mezeře; jednosloupcové mobilní rozvržení zůstává bez něj. Na mobilu do 600 CSS px je platební akce na samostatném řádku pod identitou a cenou, přes celou šířku obsahu. Desktop se tímto upřesněním nemění.

Zdůvodnění: Nové výslovné zadání nahrazuje dřívější společnou rekapitulaci s opravami. Produktová fakta, cena a jednotka se zachovávají.

Kontroly
  • Z rekapitulace není dostupná změna údajů ani návrat do dřívější editační fáze přes její ovládací prvky.
  • Ověřit souhlasy, dokumenty a celý modelový průchod k platbě.
  • Sekce souhrnu mají průhledné pozadí a oddělující linky v jednom bílém bloku.
  • Horní blok má skutečně vybraný produkt, pojišťovnu a splatnou částku; při jiné frekvenci se neukazuje roční součet jako splátka.
  • Pokračování k platbě funguje z horního bloku na mobilu i desktopu; údaje ani dokumenty se neztratí.

Zdroj: Navazující výslovné zadání kompaktních rekapitulací z 2. 11. 2026
Rozhodnutí: D07

Potvrzeno · ZAD-12

Jeden úplný seznam travel nabídek s původem dat

V travelu 0.23 zachovat jeden seznam všech 23 variant od 11 pojišťoven: 20 modelových nabídek a tři pevné testovací vzorky WS Direct (309/310/311), které nahrazují dva staré modely Direct. Tři WS zůstávají na konci; řazení mění pouze modelové nabídky. Bez skrývání do skupin. Starší verze zachovávají původních 22 variant.

Zdůvodnění: Nové výslovné zadání uživatele: offline pilot i zpřesnění modelu, nahrazení dvou modelových Direct třemi WS. Schválený plán realizace z 2. 11. 2026 pro novou verzi má přednost před dřívější přesnou kardinalitou D06=A.

Kontroly
  • Výchozí seznam má 23 nabídek, z toho 3 WS Direct a 20 modelů, 11 pojišťoven; staré Direct identity jsou odstraněné.
  • WS částky 2624/2944/4992 se nemění podle cesty; UI neuvádí neověřenou měnu ani období jako doložené.
  • Neznámé a rozporné krytí není zelená shoda, nulové plnění ani zákaz sjednání; filtry vysvětlí nemožnost posouzení.
  • Detail, porovnání, dokumentová ukázka, rekapitulace a modelová platba zachovávají původ údajů; žádné původní Direct doplňky nebo důkazy.
  • Samostatný pohled Direct a oba starty zůstávají plně průchozí bez sítě.

Zdroj: Výslovná volba uživatele a schválení implementačního plánu WS Direct z 2. 11. 2026
Rozhodnutí: D06

Přístupnost a stavy

Návrh · A11Y-01

Kontrast je přejímací podmínka, ne odhad

Měřit textový i netextový kontrast skutečných stavů proti konkrétnímu podkladu. Cílem nové společné specifikace je WCAG 2.2 AA; tento audit nepředstavuje potvrzení úplné shody.

Zdůvodnění: Současná bílá/zelená a malý červený text mají doložený rozpor. Zvětšení samotného písma nevyřeší 2,737:1 pod hranicí i velkého textu.

Kontroly
  • Zaznamenat poměry, velikost/váhu a funkční roli, ne jen hex barvy.
  • Před přijetím zvolit řešení D02 a ověřit normální, hover, focus, chybu a disabled.

Zdroj: WCAG 2.2 SC 1.4.3 a 1.4.11; kontrastní posudek
Rozhodnutí: D02

Návrh · A11Y-03

Předvídatelná klávesnice a fokus

Tab a šipky mají odpovídat významu prvku. Při výběru rádia nemá fokus neočekávaně přeskočit skupinu; při přechodu kroku se přesune na smysluplný kontext. Zvýraznění patří ovladači, ne červenému rámečku kolem celého main.

Zdůvodnění: Jiná země nyní při šipce přesune fokus do selectu. Předchozí obrys main byl zdrojem nechtěné červené linky.

Kontroly
  • Projít Tab, Shift+Tab, šipky, Home/End, Enter a Escape v relevantních skupinách.
  • Ověřit focus-visible proti pozadí a nezakrytí sticky prvky.

Zdroj: evidence/gpt-6.1-terra/keyboard.json; minulá oprava navigace
Rozhodnutí: D04

Návrh · A11Y-04

Dialog jako úplný stavový kontrakt

Dialog má jméno, smysluplný počáteční fokus, vymezenou tabulaci, dostupné zavření/Escape a návrat na spouštěč nebo popsaný náhradní cíl. Uložit potvrzuje draft, Zrušit/Escape jej zahazuje.

Zdůvodnění: Oba produkty používají různé implementace i mobilní umístění. Nativní dialog sám nezaručuje správný workflow.

Kontroly
  • Ověřit dlouhý obsah, mobilní klávesnici, opakované otevření a oba směry tabulace.
  • Prověřit návrat po překreslení/odstranění spouštěče a chování čtečky.

Zdroj: WAI-ARIA APG Dialog; výběrový keyboard test
Rozhodnutí: D08

Návrh · A11Y-05

Responzivita, zoom a dotyk

Přejímat nový základ při 320/375/768/1440 px a zvětšení textu; zkontrolovat orientaci a ovládání s klávesnicí. Návrhovým cílem ovladače je 44 × 44 CSS px, menší případy mají doložený důvod a vyhovující rozestupy.

Zdůvodnění: WCAG 2.2 minimum 24 px obsahuje výjimky; 44 px je zde návrhový cíl, nikoli tvrzení o plošné normativní povinnosti AA.

Kontroly
  • Bez horizontálního přetečení běžného formuláře; široké porovnání má pojmenovanou oblast posuvu.
  • Fyzický telefon a čtečku vést jako samostatné kontroly, ne jako výsledek desktopové emulace.

Zdroj: WCAG 2.2; architektonický posudek; současná kontrola jen Chrome375/1440
Rozhodnutí: D05

Návrh · A11Y-06

Výběr, dostupnost a asynchronní stav mají textový význam

Selected, chyba, loading a disabled jsou samostatné role. Výběr se neoznačuje pouze barvou; nedostupná akce vysvětlí důvod a nabídne dosažitelnou alternativu. AI není jediným zdrojem vysvětlení.

Zdůvodnění: Společný design musí popsat chování, ne jen klidový snímek.

Kontroly
  • Ověřit stav před volbou, po volbě, při změně a při nedostupné službě.
  • Přiměřeně oznámit změnu výsledků/potvrzení bez ztráty fokusu a vstupu.

Zdroj: Tři odborné posudky; projektové offline pravidlo
Rozhodnutí: —

Publikace a důvěryhodnost

Potvrzeno · SEO-01

Výslovná politika indexace prototypů

Nové veřejné prototypové verze a jejich HTML vstupy mají jednotné meta noindex,nofollow. D11=A ponechává veřejný přístup; noindex není ochrana důvěrných dat. Historické neměnné složky a původní kořenový úraz se hromadně nepřepisují.

Zdůvodnění: Výslovně zvoleno D11=A pro nové verze kalkulaček. Starší úraz bez noindex zůstává historickou výjimkou kvůli zachování vydání.

Kontroly
  • Ověřit skutečné HTTP hlavičky a HTML pro všechny veřejné vstupy.
  • Nezablokovat pouze robots.txt přístup k noindex, který má robot přečíst; ochranu přístupu ověřit odděleně.

Zdroj: Google Search Central; evidence/public-http.json; výslovné zadání implementace dle JSON z 2. 11. 2026
Rozhodnutí: D11

Návrh · SEO-02

Marketingová stránka a aplikační kroky mají odlišný účel

Produkční vstupní obsah může mít jedinečný titul, popis a srozumitelné vysvětlení produktu. Osobní kroky, návrhy a rekapitulace nemají sloužit jako akviziční obsah. Konkrétní URL/render/indexační plán musí odpovídat skutečné architektuře.

Zdůvodnění: Klíčová slova a SEO text se nemají mechanicky vkládat do každé obrazovky kalkulačky.

Kontroly
  • Ověřit vykreslené title, H1, popis a dostupnost smysluplného obsahu pro zvolenou veřejnou stránku.
  • Neslibovat výsledek vyhledávání ani hodnocení konverze bez měření.

Zdroj: Marketingový posudek; Google Search Central title/snippet/JavaScript
Rozhodnutí: D11

Návrh · SEO-03

Doložitelné obchodní a AI formulace

Počty pojišťoven/variant, tvrzení o pomoci AI, ceně a nezávaznosti odpovídají skutečnému režimu a ověřenému zdroji. Číslo odvozené z modelového datasetu není automaticky aktuální obchodní nabídka.

Zdůvodnění: 22 variant a 11 skupin odpovídá místním datům, nikoli nezávislému ověření trhu. Současný offline popis text ve skutečnosti neanalyzuje.

Kontroly
  • U každého slibu určit vlastníka, zdroj a okamžik aktualizace.
  • Před produkcí revidovat Bez telefonního spamu a formulace návrhu, platby a sjednání.

Zdroj: Marketingový posudek; evidence/gpt-6.1-sol/source-copy-audit.json
Rozhodnutí: D03

Příprava Ferdy

Ověřit · FER-01

Ověřit současný proces a vlastníky Ferdy

Před návrhem skutečné integrace potvrdit aktuální produkt, formulářové definice, odpovědnosti, fáze a události z dnešních owning zdrojů. Historické identity 130/132/142 a Calc/Buy/Order jsou vodítko, nikoli dnešní schválené rozhraní.

Zdůvodnění: Čtecí audit lokálních kopií z 3. 11. 2026 doložil odlišné směrování 132/142, formulářový protokol ClientActions/ResponseCache a samostatné mobilní prezentace. Autoritativní produkční commit, export formStore a cílové produkty 20/130 versus 22/142 nejsou potvrzené.

Kontroly
  • Získat aktuální mapu procesu a zodpovědného vlastníka.
  • Popsat známé/nezjištěné oblasti včetně rozdílu produktů132a142; nevymýšlet endpointy.

Zdroj: docs/ferda-interface-a-plan-2026-11-03.md; research/ferda-interface-2026-11-03/source-audit.json; historický integrační podklad
Rozhodnutí: D10

Ověřit · FER-02

Datové smlouvy a serverová validace

Zmapovat modelový stav na skutečné atributy konkrétního produktu: osoby, povolání, číselníky, destinace, rizika, částky, dotazník a dokumenty. Potvrdit pravidla serverové validace a životního cyklu výsledků.

Zdůvodnění: CMPFerda.toFerdaDraft je lokální vzor. Sám neověřuje správnost requestu, formuláře ani pojistné logiky.

Kontroly
  • Schválit DTO/schéma a chybový formát s owning systémem.
  • Ověřit invalidaci výsledků/návrhu při změně, obnovu stavu a produktové rozdíly na testovacích datech.

Zdroj: Čtecí audit Form/ClientActions z 3. 11. 2026; historický integrační podklad; současný modelový core
Rozhodnutí: D10

Ověřit · FER-03

Oddělený modelový a skutečný adaptér

UI popisuje záměr kalkulovat, vybrat nebo připravit návrh; samostatný adaptér zajišťuje ověřené skutečné volání. Modelový adaptér zůstává lokální a průchozí i při nedostupné integraci.

Zdůvodnění: Názvy UI záměrů nejsou endpointy. Přepínač režimu není náhradou autentizace, kontroly procesu a zabezpečení.

Kontroly
  • Ověřit autorizaci, správu stavu, chyby, timeout/retry a ochranu duplicit podle reálné smlouvy.
  • Před jakýmkoli skutečným vedlejším účinkem samostatně potvrdit prostředí a rozsah testu.

Zdroj: Architektonický posudek; hranice současného prototypu
Rozhodnutí: D10

Ověřit · FER-04

Dokumenty, souhlasy, platby a odborné znění

Správné verze dokumentů, souhlasy, produktové podmínky, stav platby a potvrzení musí být ověřené s odpovědnými vlastníky před produkčním použitím. Modelové dokumenty ani demo formulace nejsou takovým ověřením.

Zdůvodnění: Tento audit se týká designu a společných smluv UI; neověřuje právní či pojistnou správnost, bezpečnost produkce nebo skutečné sjednání.

Kontroly
  • V testovacím prostředí doložit návaznost nabídka → dokumenty → návrh → případná platba → potvrzení.
  • Zapsat zvlášť právní/produktové, bezpečnostní a provozní přejímky a jejich vlastníky.

Zdroj: Meze původního i nového auditu; historický Ferda podklad
Rozhodnutí: D10

Ověřit · FER-05

Pilot před rozšířením integrace

Začít jedním schváleným reprezentativním komponentem nebo čtecím integračním scénářem v ověřeném testovacím prostředí, s popsanou odpovědností, důkazem a návratem. Rozšíření na oba produkty až po vyhodnocení pilotu.

Zdůvodnění: Společný vzhled neprokazuje společný datový model ani připravenou integraci.

Kontroly
  • Definovat vstupní podmínky, úspěch, selhání a kritérium zastavení pilotu.
  • Po novém integračním zjištění aktualizovat pravidla a rozhodnutí, zachovat historický snapshot.

Zdroj: Konsolidované doporučení; plán postupného sjednocení
Rozhodnutí: D10

Experimentální vývoj

Potvrzeno · EXP-01

Dark mode pouze v oddělené větvi Experimental

Dark mode pro travel i úraz má vlastní samostatná vydání odvozená z připnutých nejvyšších běžných verzí a samostatnou sekci Experimental v rozcestníku. Experiment se neřadí mezi běžné nejnovější verze a jeho existence není schválením změn hlavní řady. Výchozí je tmavý motiv, volby jsou Tmavý / Světlý / Podle systému. Pouze tmavý experiment má výjimku z bílých ploch ZAD-03, ZAD-13 a DS-11, modré plochy patičky ZAD-04 a navy ceny DS-07 a neměnné palety D02=A: tmavé plochy, světlá modrá cena a hlavní zelená #00872E s bílým textem. Červený kicker zůstává #F42534. Světlý motiv zachovává dosavadní vzhled kromě ovladače Vzhled. Výpočty, validace, offline průchod a modelový režim se nemění; původní vydání se nepřepisují. Není požadován Git repozitář ani nasazení.

Zdůvodnění: Výslovně schválený implementační plán z 2. 11. 2026; oddělení experimentu od dříve schváleného směru.

Kontroly
  • Ověřit samostatné metadatové pole experimental, základ a experimentální označení obou produktů; běžná nejnovější verze a desítka vydání se nemění.
  • Oba starty, oba motivy a dvě šířky: 16 úplných modelových dokončení; další rozložení 320/768 px, systém, ukládání, formulářové stavy a klávesnice.
  • V tmavém motivu změřit textový kontrast nejméně 4,5 : 1 a významové hranice ovladačů 3 : 1; červený kicker #F42534 proti skutečnému podkladu.
  • Ověřit byte shodu historických souborů a ZIPů, izolaci úrazového stavu, nulové živé API a samostatnou tematickou preferenci.

Zdroj: Výslovný pokyn PLEASE IMPLEMENT THIS PLAN a předchozí odpovědi vlastníka, 2. 11. 2026
Rozhodnutí: —

Drobné sjednocení běžné řady

Potvrzeno · ZAD-15

Vizuální korekce a travel bez e-mailových obrazovek

Pro běžné verze travel 0.23.1 a úraz 0.15.3 platí výslovné zadání z 3. 11. 2026: úraz má značky rizik stejně odsazené jako destinace travelu, hover všech zelených hlavních akcí podle travelu, kontaktní písmo podle travelu a jedinou nadpisovou linku adresy pojištěného 100 × 2 px. Travel má sekční červené nadpisy a rekapitulační platební akci podle úrazu, stejně velká číselná pole jako sousední +/- a neobsahuje obě e-mailové obrazovky ani vstupní zkratky mapy. Mapa zůstává dostupná přes patičkový přehled obrazovek. Obě rekapitulace mají jemný svislý předěl uprostřed mezery mezi sloupci; na mobilu se nezobrazuje.

Zdůvodnění: Konkrétní zadání a doplňující potvrzení uživatele: odstranit návrh i potvrzovací e-mail; problém adresy se týká linky pod nadpisem. Jiné změny nejsou schválené.

Kontroly
  • Oba produkty projdou z ukázkového i prázdného startu na mobilu a desktopu bez živých API.
  • Travel má 14 obrazovek, žádný e-mailový cíl ani odkaz; rekapitulace vede přímo k modelové platbě.
  • Pole šesti počtů má bbox 30 × 32 px na desktopu a 34 × 34 px na mobilu jako sousední +/-; ostatní pole si ponechají min48.
  • Indikátory rizik úrazu mají fyzický odstup 8 px od rámečku, původní průměr 22 px a nepřekrývají text.
  • Linka adresy má pouze jeden předěl 100 × 2 px; validace polí se nemění.
  • Desktopové rekapitulace mají column-rule 1 px solid #dce4ed, mobilní jeden sloupec bez předělu.
  • Starší verze, původní kořenový úraz, již vydané ZIPy a dark experiment zůstávají beze změny.

Zdroj: Výslovné zadání a upřesnění uživatele z 3. 11. 2026
Rozhodnutí: —

Mobilní platební akce

Potvrzeno · ZAD-16

Mobilní tlačítko platby pod produktem a cenou

Pouze do 600 CSS px má být platební tlačítko v rekapitulaci obou produktů na vlastním řádku pod identitou pojišťovny/produktu a cenou, přes celou vnitřní šířku bílé rekapitulace. Krajní odsazení obsahu zůstává. Travelové tlačítko Pokračovat na rekapitulaci má 24px horní odstup od posledního pole cestujících, zachovává text a validaci. Nad 600 px se nemění uspořádání, rozměry ani typografie obou tlačítek.

Zdůvodnění: Nové výslovné zadání s mobilními snímky a následné upřesnění uživatele, že nejde o desktop. Starší pravidlo DS-11 se doplňuje pouze pro mobilní řádek akce.

Kontroly
  • Při 320/360/375/390/600 px je platební akce pod identitou i cenou a tlačítko má šířku obsahu rekapitulace bez přetečení.
  • Při 601/768/1440 px rozložení a computed styly odpovídají předchozí verzi.
  • Pokračování z údajů má na mobilu nejméně 24px odstup od posledního pole; validace se zachovává.
  • Oba produkty jsou průchozí z obou startů, modelové ceny, WS data, API blokace a starší vydání se nemění.

Zdroj: Výslovné zadání uživatele, tři přiložené snímky a mobilní upřesnění z 3. 11. 2026
Rozhodnutí: —

Rozcestník prototypů

Potvrzeno · ZAD-17

Aktuální stabilní výchozí prototyp a podklady dole

Každý produkt má v rozcestníku výslovně označenou aktuální stabilní verzi, která je výchozím prototypem. Aktuálně jde o travel 0.23.2 a úraz 0.15.5. Volba je samostatná metadata, nikoli automatické schválení libovolné novější či experimentální verze. Sekce stylopisu, společného designu a pravidel jsou pod přehledy verzí obou produktů.

Zdůvodnění: Výslovné zadání uživatele z 3. 11. 2026, včetně nasazení na devel.

Kontroly
  • Oba aktuální stabilní prototypy mají čitelné označení na mobilu i desktopu.
  • Sekce podkladů zůstávají pod oběma přehledy i po rozbalení historie a jejich odkazy fungují.
  • Oba starty a všechny kalkulačky zůstávají beze změny; historie, původní kořenový úraz a oddělený dark experiment se zachovávají.

Zdroj: Výslovné zadání uživatele z 3. 11. 2026
Rozhodnutí: —

Mobilní hlavička a výsledky

Potvrzeno · ZAD-18

Hlavička úrazu nesmí překrývat mobilní výsledky

V mobilním rozložení úrazu do 1023 CSS px při zobrazení panelu cen brandová hlavička odroluje s dokumentem, aby nezakrývala horní řádky přichycených výsledků pojišťoven. Dostupné výsledky musí zůstat čitelné a volitelné při skutečném posouvání. Ostatní kroky zachovávají původní sticky hlavičku. Od 1024 px se desktopové rozložení a chování hlavičky nemění.

Zdůvodnění: Hlášení uživatele s mobilním snímkem z 3. 11. 2026. Původní hlavička a výsledky měly shodný horní sticky okraj a rozdílné vrstvení.

Kontroly
  • Skutečný scroll na mobilních šířkách neukryje výsledky pod brandovou hlavičku.
  • Dostupné výsledky lze vybrat a pokračovat celým modelovým průchodem z obou startů.
  • Desktop, travel, data, formuláře, starší vydání a původní serverový kořenový úraz zůstávají zachované.

Zdroj: Výslovné hlášení uživatele a přiložený mobilní snímek z 3. 11. 2026
Rozhodnutí: —

Samostatné prezentace a předání do Ferdy

Potvrzeno · ZAD-19

Samostatný desktop a mobil a předávací rozhraní Ferdy

Realizovat schválený plán: pro úraz i travel samostatné desktopové a mobilní vstupy, renderery a CSS nad společným produktovým modelem a procesním kontraktem. Rozcestník má čtyři hlavní karty s explicitně zvoleným stabilním ID, dva starty na kanál a zachovanou historií. Předání do Ferdy odděluje nativní hostitelské šablony, scoped CSS a lifecycle JS od lokálních modelových výpočtů, routeru, úložiště a blokování sítě. Cílovou Ferdu ani skutečný pilot nelze odvodit z lokálních snapshotů.

Zdůvodnění: Výslovné zadání uživatele a schválení implementace plánu z 3. 11. 2026.

Kontroly
  • Čtyři kanály mají vlastní URL, renderer, CSS a izolované úložiště; změna šířky nepřepíná aplikaci.
  • Výsledky obou kanálů se shodují se společným modelem, oba starty projdou až k modelovému dokončení a fungují offline.
  • Výchozí karty určuje stabilní ID; novější kandidát je nepřepíše. Historie a pravidla/design zůstávají dostupné dole.
  • Handoff předává mapu flow a polí, obaly, komponenty, CSS a idempotentní JS pro DOMChange/notify. Syntetický harness není důkazem funkčního skutečného Formu.
  • FER-01 až FER-05 zůstávají overit do potvrzení cílové verze, produktů, Form/formStore a runtime a následného pilotu.

Zdroj: Výslovné zadání uživatele z 3. 11. 2026; docs/ferda-interface-a-plan-2026-11-03.md
Rozhodnutí: Schváleno uživatelem: Ok. Implementuj plán. Realizace samostatných prototypů a předávacího balíčku; skutečný pilot závisí na chybějících podkladech.

Mobilní výsledky úrazu

Potvrzeno · ZAD-20

Průběžné ceny nahoře a výběr pojišťovny pod riziky

V nové mobilní podverzi úrazu zobrazovat nahoře pouze sloupce s logem pojišťovny a cenou pod ním. Nabídky s tlačítky výběru jsou pod riziky. Jakmile se objeví první řádek nabídek, horní cenový přehled se skryje; při návratu k rizikům se obnoví. Zachovat cenový kontext popupu, koncept Uložit/Zrušit, sdílené výpočty a modelový režim. Desktopové vydání se nemění.

Zdůvodnění: Zadání z 4. 11. 2026 a následné výslovné upřesnění, že jde o mobilní verze.

Kontroly
  • Pět sloupců obsahuje jen logo a cenu; tlačítka výběru jsou pouze v nabídkách pod riziky. Rozdíly v krytí lze rozbalit u spodních nabídek.
  • Po skutečném posouvání přehled zůstává dostupný, skryje se při vstupu prvního výsledkového řádku do viewportu a obnoví při návratu nad nabídky. Hlavička nepřekrývá ceny.
  • Popup zachovává viditelný cenový kontext, náhled odpovídá zvolenému limitu a sdílenému modelu. Uložit potvrdí změnu a Zrušit či Escape zachová původní krytí.
  • Oba starty projdou až k modelovému dokončení; desktop, travel, ostatní kroky, historické soubory a vydané ZIPy se nezmění.

Zdroj: Výslovné zadání uživatele z 4. 11. 2026 v tomto chatu.
Rozhodnutí: Jedna nová mobilní verze; poslední upřesnění určuje nahoře jen loga/ceny a výběr pod riziky s podmíněným skrytím přehledu. Nasazení na devel je výslovně schválené.

Desktopové výsledky úrazu

Potvrzeno · ZAD-21

Nabídky napravo ve druhém kroku desktopu

V nové desktopové podverzi úrazu zobrazovat výsledky ve druhém kroku napravo od výběru rizik podle rozložení 0.10. Zachovat výpočty, formuláře a ostatní kroky. Mobilní prezentace zachovává vlastní rozložení 0.16.1.

Zdůvodnění: Nové výslovné zadání uživatele z 4. 11. 2026 po dokončení mobilní úpravy.

Kontroly
  • Krytí a nabídky jsou vedle sebe na desktopových šířkách od 1024 px; navigace zůstává přes oba sloupce.
  • Všechny dostupné nabídky lze vybrat při posouvání a na nízké obrazovce; hlavička nezakrývá výběr.
  • Oba starty projdou modelovým sjednáním. Ostatní kroky odpovídají desktopu 0.16.0.
  • Mobilní 0.16.1, travel, produktová jádra, historické soubory, ZIPy a původní serverový úraz zůstávají shodné.

Zdroj: Výslovné zadání uživatele z 4. 11. 2026: výsledky na desktopu u úrazu vpravo jako ve verzi 0.10.
Rozhodnutí: Schválena nová desktopová podverze při zachování mobilní 0.16.1; nasazení na devel navazuje na stávající zadání.

Počáteční výběr a nabídky úrazu

Potvrzeno · ZAD-22

Druhý krok bez předvolených rizik a bez předčasných cen

Na desktopu i mobilu zachovat první krok se základními údaji. Druhý krok začíná bez vybraného krytí a bez cen/nabídek. Teprve potvrzená volba rizika nebo vědomá volba předvolby zobrazí ceny; odebrání posledního rizika je skryje. Primární tlačítka mají barvy a hover z 0.10. Mobilní přehled obsahuje sloupce logo/cena v jediném rámečku; klepnutí na dostupnou nabídku vybere pojišťovnu a pokračuje stejně jako spodní tlačítko. Náhled v popupu nepovoluje výběr nepotvrzeného krytí.

Zdůvodnění: Zadání a upřesnění uživatele z 4. 11. 2026 v tomto chatu.

Kontroly
  • Ukázkový i prázdný start zachovají profil jako krok 1 a vstoupí do kroku 2 s prázdným krytím a bez cen. Pouhé otevření nebo zrušení popupu ceny neodkryje.
  • Uložení prvního rizika a vědomá volba předvolby ceny zobrazí; odebrání posledního rizika je skryje. Rozpracovaná potvrzená volba se obnoví po reloadu.
  • Na desktopu zůstávají nabídky napravo, na mobilu nahoře loga/ceny a dole podrobné nabídky se stávajícím skrytím přehledu od prvního spodního řádku.
  • Logo i cena dostupné mobilní nabídky skutečně vyberou pojišťovnu a přejdou do konfigurace. Nedostupná nabídka je neaktivní, popup je do Uložit pouze náhled.
  • Tlačítka odpovídají změřené 0.10: základ #003B71 / bílá, hover #51B24E / #102F49. Mobilní cenové sloupce nemají vlastní zaoblení, bordery ani vnitřní spodní stíny.
  • Modelové výpočty, validační pole, ostatní průchod, travel, starší vydání a původní serverový úraz se zachovávají.

Zdroj: Výslovné zadání uživatele z 4. 11. 2026; referenční 0.10; přiložený obrázek mobilního cenového přehledu.
Rozhodnutí: Nové podverze obou kanálů při zachování prvního kroku. Nasazení navazuje na stávající výslovné zadání devel.

Údržba a změny

Vlastník: Vlastník produktů rozhoduje o směru; vývojový správce udržuje katalog. Konkrétní osoby a odpovědnost za integraci je třeba určit.

Kdy aktualizovat

Postup

Verzování: Pravidla mají vlastní verzi, oddělenou od kalkulaček a portálu. 0.1.0 je první katalog s návrhy. Další obsahové doplnění nebo schválené rozhodnutí zvýší minor; oprava formulace bez změny významu patch. Nekompatibilní přijatá norma musí mít popsanou migraci a novou major verzi.

Rozhodovací report a plné posudky jsou dostupné v navigaci této stránky. Aktuální pravidla vývoje.