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

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.1.0 · Datum: 2026-11-02

Výchozí travel: 0.21.2
Výchozí úraz: 0.14.1

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

Rozhodovací základ

Potvrzeno znamená požadavek doložený zadáním uživatele nebo platnými pokyny projektu. Neznamená to, že jej všechny současné obrazovky už splňují.
Návrh je doporučení tohoto auditu. Do závazné společné specifikace přejde až po výslovném rozhodnutí vlastníka produktu.
Ověřit označuje chybějící podklad nebo podmínku budoucí integrace. Nelze ji prohlásit za splněnou podle vzhledu prototypu.
Konkrétní nové zadání uživatele má přednost. Změna se promítne do registru rozhodnutí a verze pravidel, nikoli tichým přepsáním historického reportu.
Původní WordPress audit je zdrojem palety a historických měření; pro tento katalog jsou rozhodující aktuální produktové potřeby, doložené preference a ověřené chování.

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.

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.

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

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

Návrh · 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, návraty a editaci z rekapitulace.
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
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í: —

Návrh · DS-03

Společná výchozí geometrie pole

Pro nový základ zvážit vstupní text 16 px, minimální výšku 48 px a radius 8 px, se stejným label/hint/error vzorem. Je to návrh; ne tvrzení o dnešní shodě.

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
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

Návrh · 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
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

Návrh · 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.

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
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

Návrh · 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
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.

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

Návrh · DS-11

Společná rekapitulační fakta a oprava

Zvolit jednu vizuální gramatiku rekapitulačních sekcí: název skupiny, fakta, výběr a viditelná změna. Produktová fakta, dokumenty a návaznost zůstávají vlastní.

Zdůvodnění: Travel má jednu kartu s vnitřními skupinami, úraz sadu samostatných panelů; liší se i práce s linkou a cenou.

Kontroly

Po opravě části se vrátit na rekapitulaci a ukázat aktualizované údaje.
Odvozený návrh a platba se zneplatní podle ověřených pravidel procesu, ne pouhým přemalováním souhrnu.

Zdroj: Fresh recap snímky obou produktů; UX/UI posudek
Rozhodnutí: D07

Přístupnost a stavy

Publikace a důvěryhodnost

Návrh · SEO-01

Výslovná politika indexace prototypů

Devel a modelové kroky mají mít jednotnou záměrnou indexační politiku. Doporučení je noindex pro prototypové stránky; případné omezení přístupu řešit samostatně. Noindex ani robots.txt nejsou ochrana důvěrných dat.

Zdůvodnění: Aktuální travel má meta noindex,nofollow, úraz nemá meta noindex ani ověřenou hlavičku X-Robots-Tag. To nedokazuje, že jej vyhledávač indexuje.

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
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í: Máme historický čtecí podklad z 21. 10. 2026, nikoli nový audit produkční Ferdy.

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: Historický IMPLEMENTACE.md; architektonický posudek
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: Historický integrační podklad; current 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

Ú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

Po schválení některého rozhodnutí z reportu nebo po nové výslovné korekci uživatele.
Při změně sdílené komponenty, stavu, přístupnosti, textu kritické akce nebo produktové výjimky.
Po ověření aktuálního procesu Ferdy, mapování dat a rozhraní; znovu před zapojením skutečného adaptéru.
Po relevantním zjištění z testu s lidmi, čtečkou, reálným mobilem nebo z provozního měření.

Postup

Zapsat podnět, zdroj, dotčené produkty a stabilní ID pravidla nebo nového rozhodnutí.
Oddělit pozorovaný stav od návrhu; u výjimky uvést důvod, rozsah, vlastníka a podmínku nového přezkumu.
Výslovně zaznamenat rozhodnutí vlastníka a teprve potom změnit status návrhu. Volba uložená v prohlížeči reportu je pracovní poznámka.
Upravit tento zdrojový JSON, zvýšit jeho verzi, přidat záznam změny a popsat dopad na stávající implementace.
Ověřit společné komponenty v úrazu i travelu, sestavit nové samostatné verze a publikovat aktuální čitelný katalog.
Ponechat snapshot pravidel u historického reportu a všechny vydané ZIPy beze změny.

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.

0.1.0 · 2026-11-02: První katalog pro úraz a travel: doložené preference oddělené od návrhů sjednocení a neověřených integračních podmínek. Současné rozpory nejsou tímto dokumentem schváleny.

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

O dokumentu a jeho stavu

Rozhodovací základ

Identita a vzhled

Červený malý sekční nadpis

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

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

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

Jednotný styl ilustrativních ikon

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

Navigace

Travel bez prezentačního pruhu

Pravdivá fáze i podkrok na mobilu

Prototyp a data

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

Model zůstává modelem

Formuláře

Konkrétní jiná země

Společná výchozí geometrie pole

Stejný kontrakt validace

Vydávání a údržba

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

Reprodukovatelné verze a oba starty

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

Společné komponenty

Společná komponenta s produktovými daty

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

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

Obsah a akce

Sloveso odpovídá skutečné akci

Cena má jednotku a stabilní význam barvy

Nabídky a údaje

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

Osoby jsou produktové, pole společná

Kontakty až podle doložené potřeby

Společná rekapitulační fakta a oprava

Přístupnost a stavy

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

Předvídatelná klávesnice a fokus

Dialog jako úplný stavový kontrakt

Responzivita, zoom a dotyk

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

Publikace a důvěryhodnost

Výslovná politika indexace prototypů

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

Doložitelné obchodní a AI formulace

Příprava Ferdy

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

Datové smlouvy a serverová validace

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

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

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

Údržba a změny

Kdy aktualizovat

Postup