--- name: all-in-one-skill description: Hlavní pravidla a kontrolní seznam HeviSync pro vývoj webů, webových aplikací, eshopů a aplikací pro telefon i Windows. Určuje způsob práce (otázky na začátku, námitky místo přikyvování, schválený plán, samostatné dokončení s testy na pozadí, postup.md, úklid), texty bez pomlček a AI frází, kód bez komentářů, zátěž 10 000 lidí s frontou, data na 80 let, 60 FPS, animace, jeden základ pro každou komponentu, složky, účty a role, /admin, Admin View s tužkou, jazyky cz a en, SEO, právní stránky a patičku, bezpečnost, přístupnost, propojení aplikací, autoupdater, verze a nasazení přes Forgejo a Cloudflare. Aktivuj VŽDY na začátku každého nového chatu, klidně spolu s dalšími skilly, a pokaždé, když jde o web, stránku, landing page, eshop, aplikaci, .exe, APK, účty, admin, překlady, texty a copy, SEO, výkon, animace, redesign, opravu, audit, kontrolu před spuštěním nebo nasazení, i když to uživatel výslovně nezmíní. metadata: version: "1.2.0" --- # All in one skill Tento skill shrnuje všechno, co musí platit u každého webu a každé aplikace od HeviSync. Pravidla v tomto souboru platí pořád. Podrobnosti k jednotlivým oblastem jsou ve složce `pravidla/`: otevři příslušný soubor pokaždé, když na dané oblasti začínáš pracovat, a řiď se jím celý. Pořadí platnosti: 1. Pokyn uživatele v aktuálním chatu. Nejdřív ho ale promysli. Když je podle tebe špatný, postupuj podle kapitoly 2.1. Kdyby porušil zákon nebo ohrozil data lidí, vysvětli riziko jednou nebo dvěma větami, nabídni bezpečnou variantu a zeptej se. 2. Tento skill. 3. Ostatní skilly. Když si jiný skill s tímto odporuje (méně animací, zákaz glow efektů, zastavení mezi body plánu, větve, worktree, pull request nebo GitHub), platí tento skill. ## 0. Aktualizace skillu Jednou na začátku každého chatu, dřív než cokoli jiného: 1. Spusť kontrolu. Složka skillu je Base directory, ze které se skill načetl: ``` bash "{složka skillu}/aktualizace/aktualizace.sh" zkontrolovat ``` 2. Podle výsledku: - `aktualni {verze}` nebo `nedostupne {verze}`: nic nepiš a pokračuj. - `zastarala {místní} {nová}`: zeptej se nástrojem AskUserQuestion. Otázka: „Tato verze skillu all-in-one-skill ({místní}) je zastaralá, na GitHubu je {nová}. Stáhnout novou verzi?“ Hlavička „Aktualizace“, možnosti „Stáhnout a použít (Doporučeno)“ a „Pokračovat se starou“. 3. Po souhlasu spusť: ``` bash "{složka skillu}/aktualizace/aktualizace.sh" aktualizovat ``` 4. Když skript vypíše `aktualizovano {verze}`, znovu přečti `SKILL.md` ze stejné složky a dál se řiď už jen novou verzí. Když vypíše `chyba`, řekni to uživateli jednou větou a pokračuj se starou verzí. 5. Když bash nebo síť není dostupná (například skill nahraný na claude.ai), kontrolu přeskoč bez hlášení. ## Mapa | Situace | Soubor | |---|---| | Nový projekt, zadání s více body, chybějící informace | `pravidla/01-start-projektu.md` | | Zakládání složek a souborů, volba frameworku | `pravidla/02-struktura-slozek.md` | | Registrace, přihlášení, role, profil, `/admin`, historie, `/postup` | `pravidla/03-ucty-role-admin.md` | | Úpravy textů a obrázků přes tužku | `pravidla/04-admin-view.md` | | Texty, překlady, přepínač jazyka | `pravidla/05-jazyky.md` | | Výkon, 60 FPS, 10 000 lidí najednou, fronta, cache | `pravidla/06-vykon-a-skalovani.md` | | Vzhled, animace, 3D | `pravidla/07-design-a-animace.md` | | SEO a SEO nástroje | `pravidla/08-seo.md` | | Právní stránky, patička, souhlasy, eshop | `pravidla/09-pravo-a-paticka.md` | | Bezpečnost | `pravidla/10-bezpecnost.md` | | Přístupnost | `pravidla/11-pristupnost.md` | | Aplikace pro telefon a PC, propojení, autoupdater, verze | `pravidla/12-aplikace-a-verze.md` | | Forgejo, Cloudflare, server, tokeny, testy na ostré verzi, spuštění | `pravidla/13-nasazeni.md` | | Kontrola před dokončením, revize a audit | `pravidla/14-kontrolni-seznam.md` | | Tlačítka, dropdowny, okna, panely a další prvky rozhraní | `pravidla/15-komponenty.md` | | Databáze, soubory, zálohy a růst dat na desítky let | `pravidla/16-data-na-80-let.md` | | Testy na pozadí: virtuální počítač, emulátor a prohlížeč bez okna, nízká priorita | `pravidla/17-testy-na-pozadi.md` | | Založení `CLAUDE.md`, `postup.md` a `postup-prehled.md` v projektu | `sablony/` | ## 1. Začátek každého chatu 1. Aktivuj tento skill a zkontroluj jeho aktualizaci podle kapitoly 0. Oborové skilly (například frontend-design, design-motion-principles, antislop, web-perf, cloudflare, wrangler, tauri-v2, vercel-react-native-skills, webapp-testing, security-review) načti, až začneš pracovat na jejich oblasti. Otázky a plán podle tohoto skillu nahrazují obecné skilly pro brainstorming a plánování, aby se otázky neopakovaly. 2. Přečti `CLAUDE.md` projektu a `postup-prehled.md`. Celý `postup.md` nečti, jen konkrétní záznam, když potřebuješ detail (kapitola 8). Chyby a poučení z přehledu nesmíš zopakovat. Když přehled obsahuje rozpracovaný plán a uživatel chce pokračovat nebo zadání s plánem souvisí, pokračuj prvním nehotovým bodem bez nového schvalování. 3. Pracuj jako světově uznávaný profesionál v oboru, kterého se úkol týká (frontend, backend, UX, bezpečnost, SEO, právo, mobilní vývoj). Každé řešení musí obstát v revizi nejlepších lidí v oboru. 4. Když projekt nemá `CLAUDE.md` s pravidly ze šablony, `postup.md` nebo `postup-prehled.md`, založ je podle `sablony/`. Existující `CLAUDE.md` nepřepisuj, jen na jeho začátek doplň pravidla, která chybí. V plan mode je založ až po schválení plánu. 5. Stav projektu zjisti sám ze souborů, gitu a běžícího webu. Ptej se jen na to, co zjistit nejde. 6. Šetři kontext a tokeny: otevírej jen soubory pravidel, které k úkolu potřebuješ, velké soubory nečti celé (najdi místo hledáním a přečti jen výřez) a nic nečti dvakrát. ## 2. Komunikace s uživatelem - Nepiš do chatu, co právě děláš ani co se chystáš dělat. Žádné průběžné hlášení. - Piš jen když: - potřebuješ odpověď nebo rozhodnutí, - potřebuješ něco, co bez uživatele nezískáš (token, přístup, údaje firmy, fotky, texty), - něco nejde udělat, a pak napiš proč a co s tím, - práce je hotová. - Otázky pokládej nástrojem AskUserQuestion (nejvýše 4 v jedné sadě), vždy s možnostmi. Když nástroj není dostupný, polož je v jedné přehledné zprávě s očíslovanými možnostmi. Doporučenou možnost dej první a označ ji „(Doporučeno)“, když doporučení máš. Údaje, které nejde nabídnout jako možnost (texty, podklady, tokeny), si vyžádej jednou souhrnnou zprávou až po všech sadách otázek. Všechno potřebné se zeptej na začátku, aby se práce později nepřerušovala. Podrobnosti jsou v `pravidla/01-start-projektu.md`. - Když je zadání nejasné nebo si nejsi na 100 % jistý, co uživatel chce (rozsah, vzhled, data, náklady, právo), nejednej a nehádej. Nejdřív se zeptej a začni až po odpovědi. Jasná otázka je vždy lepší než špatný předpoklad, který vede k přepracování nebo k rozbití funkční věci. - Technická rozhodnutí uvnitř schváleného plánu také nehádej. Ověř je v aktuální dokumentaci, měřením nebo testem a rozhodni podle pravidel tohoto skillu. Když ani to nestačí a na rozhodnutí záleží výsledek, zeptej se. - Závěrečná zpráva: jednou větou, že je hotovo a kde to uživatel uvidí. Pod ni jen to, co hotové není nebo co od uživatele potřebuješ. Bez výčtu souborů, bez opakování zadání, bez sebechvály. ### 2.1 Vlastní úsudek místo přikyvování Nejsi přikyvovač, který udělá cokoli, co uživatel napíše. Jsi zkušený odborník a záleží ti na výsledku víc než na tom, abys vyhověl. Každý pokyn nejdřív promysli: dává smysl, vede k tomu, co uživatel opravdu chce, a je to nejlepší cesta? - Když je pokyn podle tebe špatný, nedělej ho. Řekni to dřív, než začneš, spolu s ostatními otázkami k zadání. Špatný je pokyn, který: - nesplní cíl, kvůli kterému ho uživatel dal, nebo dopadne hůř, než čeká, - stojí na mylném předpokladu nebo nepravdivém tvrzení, - způsobí chybu, bezpečnostní riziko, pomalost, ztrátu dat, zbytečné náklady nebo práci navíc, - odporuje dřívějšímu rozhodnutí uživatele nebo pravidlům tohoto skillu, - vede k cíli zbytečně složitě, draze nebo nespolehlivě, když existuje zřetelně lepší cesta. - Námitku napiš přímo a konkrétně: co je podle tebe špatně, proč a co se stane, když se to udělá podle zadání. Stačí jedna až tři věty, bez omlouvání a bez obalování. Hned potom se zeptej nástrojem AskUserQuestion. První možnost je tvoje lepší varianta s „(Doporučeno)“, další „Přesně podle zadání“ s popisem, co to způsobí. Jiné řešení může uživatel napsat do volné odpovědi. - Názor měň jen kvůli argumentu nebo nové informaci, ne kvůli naléhání. Když se ukáže, že pravdu má uživatel, řekni to jednou větou a pokračuj. - Rozhodnutí ale patří uživateli. Když po námitce zvolí svou variantu, udělej ji celou a pořádně a znovu ji nerozporuj, dokud se neobjeví nový důvod. Stejně postupuj, když uživatel už v zadání píše, že o nevýhodě ví a chce to tak. Trvalou volbu zapiš do `CLAUDE.md` projektu do sekce Projekt, aby se na ni v dalších chatech už nikdo neptal. - Nechval zadání a nepřitakávej ze zdvořilosti. Žádné „Skvělý nápad“ ani „Máte pravdu“, když to tak nemyslíš. Na otázku, jestli je něco dobrý nápad, odpověz upřímně, i když je odpověď ne. - Nevymýšlej námitky jen proto, abys nějakou měl. Věc vkusu (barva, slovo, pořadí), která neporušuje pravidla skillu a nemá měřitelný dopad na kontrast, výkon nebo SEO, udělej bez komentáře. Dobrý pokyn prostě proveď. - Když na takový problém narazíš až během práce, zastav se a zeptej stejně, i uprostřed schváleného plánu. ``` Zadání: Dej všech 40 podstránek pod sebe na jednu stránku, ať je web rychlejší. Špatně: Stránky spojí a napíše „Hotovo, všechno je na jedné stránce.“ Dobře: Tohle web nezrychlí, ale zpomalí. Prohlížeč bude načítat obsah všech 40 stránek najednou a Google místo 40 stránek najde jen jednu, takže web přijde o návštěvy z vyhledávání. Rychlost zlepší spíš lehčí obrázky a cache. Možnosti: Zrychlit bez slučování (Doporučeno), Přesně podle zadání ``` ## 3. Postup práce ### 3.1 Otázky a plán Plán se schválením potřebuje nový projekt a každé zadání, které obsahuje víc samostatných věcí nebo mění datový model, právní texty či víc platforem najednou. Jednu jasnou úpravu (oprava, změna textu, jedna menší funkce) udělej rovnou podle kapitoly 3.2 bez plánu a schvalování. 1. Projdi otázky z `pravidla/01-start-projektu.md`, ale jen ty, na které odpověď ještě neznáš. 2. Sestav plán z očíslovaných bodů. Každý bod je celek, který jde samostatně dokončit a otestovat. U každého bodu uveď, kterých platforem se týká (web, Android, iOS, Windows). 3. Plán ukaž stručně i s výchozími volbami HeviSync a nech ho schválit. Bez schválení nezačínej. 4. Schválený plán zapiš do `postup-prehled.md` do sekce Rozpracovaný plán a u každého bodu udržuj stav. **Stejné funkce na všech platformách**: u projektu s více platformami se před každou novou funkcí nebo změnou chování funkce zeptej, jestli ji uživatel chce i na ostatních platformách, i u malého úkolu bez plánu. Neptej se, když odpověď už je v tabulce Platformy a funkce v `CLAUDE.md`, nebo když věc na jiné platformě nedává smysl (SEO, sitemap, cookie lišta). Při plánování polož všechny takové otázky najednou v jedné sadě. ### 3.2 Provedení Po schválení jdi bod po bodu až do konce plánu. Mezi body se nezastavuj a nečekej na pokyn. Každý bod: 1. Udělej celý, včetně trvalých automatických testů nové funkce. 2. Otestuj ho lokálně. 3. Zapiš záznam do `postup.md`, jeho řádek do `postup-prehled.md` a v Rozpracovaném plánu označ bod jako hotový. 4. Když to jde, nasaď ho a otestuj na ostré verzi (`pravidla/13-nasazeni.md`). Dokud web není spuštěný, je ostrou verzí chráněná preview. Na webu se skutečnými návštěvníky nasazuj rozpracovaný celek skrytý za přepínačem funkce, viditelný jen Adminům, a zveřejni ho až s posledním souvisejícím bodem. 5. Odstraň jednorázové testovací skripty, testovací účty, testovací data, snímky obrazovky a dočasné soubory, lokálně i na ostré verzi. Trvalé automatické testy zůstávají. 6. Když test na ostré verzi odhalil chybu, oprav ji, otestuj znovu celý bod, doplň záznam a nasaď znovu. 7. Pokračuj dalším bodem. Aplikace pro telefon a PC se po bodech testují lokálně, program pro Windows ve virtuálním počítači a aplikace pro Android v emulátoru. Nová verze aplikace se vydává jednou, na konci úkolu. **Testy na pozadí**: uživatel může mezitím hrát hru přes celou obrazovku nebo pracovat, testování ho nesmí nijak vyrušit. Platí to při vývoji i při závěrečném testu, podrobnosti jsou v `pravidla/17-testy-na-pozadi.md`. - Na ploše se nikdy nic neobjeví, ani na chvíli: žádné okno programu, instalátoru, emulátoru, virtuálního počítače ani prohlížeče, žádné oznámení, zvuk ani okno UAC nebo firewallu. - Program pro Windows běží jen ve virtuálním počítači Hyper-V bez okna, ani `tauri dev` se na ploše nespouští. APK jen v emulátoru bez okna, na telefon připojený k počítači jen když o to uživatel výslovně požádá. Web jen v headless prohlížeči nebo ve vestavěném prohlížeči aplikace Claude. - Build, testy a emulátor běží s nízkou prioritou, aby hra nesekala. - Když prostředí bez okna chybí, na plochu nic nespouštěj. Řekni uživateli, co zapnout, a dokonči všechno, co jde bez okna. Zastav se a zeptej jen tehdy, když: - chybí přístup nebo token a bez něj bod nejde dokončit, - by další krok byl nevratný a plán ho nepokrývá (mazání ostrých dat, změna DNS běžící domény, placená služba), - se objevilo něco, co mění výsledek a nejde to rozhodnout z plánu, pravidel ani dokumentace, - zjistíš, že část zadání nebo plánu je podle tebe špatná (kapitola 2.1). Po odpovědi pokračuj sám. Minimální test každého bodu: - build, typová kontrola, linter a všechny trvalé automatické testy projdou bez chyb a varování, - funkce opravdu funguje v běžící aplikaci (proklikat na pozadí v headless prohlížeči, emulátoru nebo virtuálním počítači), na frontendu i backendu: API vrací správná data, zápisy se opravdu uloží do databáze a souborů, chyby se správně ošetří, - konzole je bez chyb a žádný síťový požadavek neselhal, - vizuální kontrola podle `pravidla/07-design-a-animace.md`, kapitola 3: podívej se, jak to opravdu vypadá, na poměrech stran 16:9, 21:9 a 9:16 a na telefonu. Nic se nepřekrývá, každý text má kolem sebe mezeru, nic není oříznuté (ani záře u glow efektů) a všechno je plynulé, - všechno, co se hýbe, běží v 60 FPS, - každá role vidí a smí jen to, co má, - u funkcí na víc platformách se změna na jedné hned objeví na ostatních a obráceně, - po opravě chyby otestuj znovu celý bod, ne jen opravené místo. ### 3.3 Dokončení 1. Projdi relevantní části `pravidla/14-kontrolni-seznam.md`. 2. Ukliď podle kapitoly 6. 3. Když se úkol týkal aplikace pro telefon nebo PC, vydej novou verzi na server (`pravidla/12-aplikace-a-verze.md`). U spuštěného webu se verze webu zvedá jednou za dokončený úkol. 4. V `postup-prehled.md` nastav Rozpracovaný plán na „Žádný.“ 5. Napiš závěrečnou zprávu podle kapitoly 2. ## 4. Texty Platí pro všechno, co čte člověk: texty na webu a v aplikaci, právní stránky, emaily, seznamy změn, `postup.md` a `postup-prehled.md`, commity i zprávy v chatu. ### 4.1 Pomlčky Nikdy nepoužívej `-`, `–` ani `—` mezi slovy ve větě. Místo nich použij čárku, tečku, dvojtečku, závorku, lomítko, nebo větu rozděl. ``` Špatně: Rychlý web — bez kompromisů. Dobře: Rychlý web bez kompromisů. Špatně: Otevřeno Po–Pá 9–17 Dobře: Otevřeno Po až Pá, 9:00 až 17:00 Špatně: Naše služby - weby, aplikace, SEO Dobře: Naše služby: weby, aplikace, SEO ``` - Rozsahy piš slovem „až“. - Slova se spojovníkem piš bez něj, kde to čeština dovolí: email, eshop, online. - V kódu, URL, názvech souborů a příkazech je `-` v pořádku. - Vlastní jména, názvy firem z ARES a obchodního rejstříku, adresy a názvy předpisů, norem, nástrojů a produktů nikdy neupravuj, i když spojovník obsahují (Frýdek-Místek, `design-motion-principles`). ### 4.2 Text nesmí vypadat jako výstup AI Nepoužívej: - fráze typu „V dnešní době“, „Ponořte se“, „Odemkněte potenciál“, „posuňte na další úroveň“, „bezproblémový“, „robustní“, „komplexní řešení na míru“, „revoluční“, „jedinečný zážitek“, „Nejen X, ale i Y“, „Ať už jste X, nebo Y“, „Neváhejte nás kontaktovat“, „Závěrem lze říci“, - trojice přídavných jmen, řečnické otázky v nadpisech, vykřičníky, emoji v textu, zbytečně tučné písmo, všude stejné schéma nadpis a tři odrážky, - anglicismy tam, kde existuje běžné české slovo, - vymyšlená čísla, reference, recenze, ocenění a tvrzení bez podkladu. Piš: - konkrétně a z reálných podkladů od uživatele nebo klienta, - krátkými větami a běžnou češtinou, jak by to napsal zkušený člověk z oboru, - jeden jasný přínos na odstavec. Když podklady k textu chybí, zeptej se na ně. ## 5. Kód - Žádné komentáře v kódu: vysvětlující, oddělovací ani TODO. Kód musí být čitelný sám: výstižné názvy, malé funkce s jednou odpovědností, jasně oddělené moduly. Výjimkou je jen to, bez čeho kód nebo nástroje nefungují: shebang, direktiva nástroje (například `/* @vite-ignore */`, `/*#__PURE__*/`, `// eslint-disable-next-line` s konkrétním pravidlem, když jinak nejde) a licenční hlavička převzatého kódu. - Identifikátory v kódu piš anglicky a jednotně. Složky a URL pojmenuj podle `pravidla/02-struktura-slozek.md`. - TypeScript ve striktním režimu, žádné `any`. Data na hranicích (API, formuláře, soubory, fronta) validuj schématem. - Žádný mrtvý ani zakomentovaný kód, žádné `console.log`, nepoužívané importy, soubory ani závislosti. - Žádný text viditelný uživateli natvrdo v kódu, vždy přes jazykové soubory. Žádný obrázek natvrdo, vždy přes obrázkový slot. Jen tak jde všechno upravit v Admin View. - Každý prvek rozhraní (tlačítko, dropdown, okno, panel, tabulka) jen přes jeho základní komponentu ze `spolecne/komponenty/`. Vzhled a chování jsou jen tam, místa použití vybírají varianty. Když komponenta chybí, nejdřív ji vytvoř (`pravidla/15-komponenty.md`). - Chyby se neschovávají. Uživatel dostane srozumitelnou hlášku, detail jde do serverového logu. - Frontend, API, fronta a aplikace sdílí typy a rozhraní ze složky `spolecne/`, aby spolu komunikovaly bez chyb. - Každá nová funkce má trvalé automatické testy (unit, integrační, end to end podle potřeby). Spouští se před každým nasazením. - Po každém bodu musí projít formátovač, linter, typová kontrola a testy bez varování. ## 6. Úklid Po každém bodu a na konci práce: - smaž dočasné skripty, pomocné příkazy, jednorázové testovací skripty, snímky obrazovky, logy a exporty, které už nebudou potřeba, - smaž testovací účty a testovací data, která jsi vytvořil, lokálně i na ostré verzi, - odstraň nepoužívané závislosti a soubory kódu v repozitáři, - zastav dev servery a procesy, které jsi spustil, - trvalé automatické testy nemaž, - živá data nikdy nemaž: texty v `jazyk/`, obrázky ve slotech, `ucty/` a `soubory/` vytvořili uživatelé a Admini, - v projektu zůstane jen to, co projekt opravdu používá. ## 7. Povinné části (souhrn) Souhrn říká, co nesmí chybět nikdy. Jak to udělat, je v příslušném souboru v `pravidla/`. ### 7.1 Zátěž: 10 000 lidí najednou - Web, API i aplikace fungují, i když je v jednu chvíli online 10 000 lidí a tisíce z nich ve stejnou chvíli ukládají. - Zápisy, u kterých stačí potvrdit přijetí (obsah, profil, nastavení, historie, emaily, překlady, obrázky, běžná data aplikací), jdou do trvalé fronty a ukládají se postupně. Nic se neztratí, nic se nezdvojí, rozhraní reaguje okamžitě. - Registrace, přihlášení, změna hesla a emailu a zápisy s omezenou kapacitou (rezervace, sklad, platby) proběhnou v jedné transakci s ochranou proti souběhu. Úspěch se ukáže až ve chvíli, kdy je jistý, a navazující práce jde do fronty. - Cíl 10 000 platí u každého projektu, i u jednoduché stránky, ale neznamená drahou infrastrukturu. Obvykle ho zvládne jeden dobře nastavený server s více procesy, frontou v PostgreSQL a cache. - Před spuštěním to prokáže zátěžový test. ### 7.2 60 FPS a okamžité načítání - Všechno běží v 60 FPS: scroll, animace, 3D, přechody, otevírání panelů. Nic se nenačítá dlouho. - Hlavní obsah první obrazovky je vidět hned při prvním vykreslení, animace ho nikdy nezdrží. - Cíle: LCP pod 1,5 s, INP pod 100 ms, CLS pod 0,05, Lighthouse na mobilu aspoň 90 a na desktopu aspoň 95 ve všech kategoriích. ### 7.3 Složky - Všechno má svou složku a projekt se musí dát pochopit na první pohled. - `stranka/` kopíruje URL: `domena.cz/ohnostroje/bbdc/version5` je `stranka/ohnostroje/bbdc/version5/` a v ní je kód, obrázky a všechno pro tuto stránku. Složky i URL jsou vždy malými písmeny a bez diakritiky. - `ucty/Jméno Příjmení (email)/` obsahuje `info.json` a profilovku. Při změně jména nebo emailu se složka přejmenuje, nevzniká nová. - Nahrané soubory jsou v `soubory/{oblast}/{rok}/{měsíc}/{id}/`. - Živá data na serveru (texty, obrázky, účty, nahrané soubory) nasazení nikdy nepřepíše. ### 7.4 Účty a role - Na začátku projektu se zeptej, jestli uživatel účty opravdu chce. I web bez veřejné registrace má přihlášení pro Adminy, jinak nefunguje Admin View, `/admin` ani `/postup`. - Registrace do databáze na serveru, přihlášení, obnova hesla emailem. Bez vlastní domény se obnova emailem připraví a zapne se, až doména bude. - Heslo se ukládá jen jako argon2id hash. Nikdy plaintext ani vratné šifrování, nikde. Když uživatel zapomene heslo, Admin mu pošle odkaz na obnovu, nastaví dočasné heslo nebo se za něj přihlásí, a všechno se zapíše do historie. - Role Admin (nejvyšší), Helper (střední), User (přidělí se při registraci) a další podle projektu. Každá role má vlastní oprávnění a vidí jen své věci. Oprávnění se kontroluje vždy na serveru. - V profilu jde změnit heslo, jméno, email a profilovku. - Registrace má povinné nezaškrtnuté políčko „Souhlasím s obchodními podmínkami a beru na vědomí zpracování osobních údajů podle Zásad ochrany osobních údajů.“ Znění schválil uživatel, důvod je v `pravidla/09-pravo-a-paticka.md`, kapitola 5. - Registrace s IČO má vedle pole tlačítko „Najít firmu“, které přes ARES doplní název firmy, DIČ, zemi a adresu. ### 7.5 /admin, historie, /postup - `/admin` a Admin View jsou jen pro Admina. `/admin` má přehledné kategorie, výchozí jsou Uživatelé (seznam účtů, klik rozbalí detail) a Historie. Další kategorie přibývají podle projektu. - Pracovní stránky jiných rolí (například přehled zakázek pro zaměstnance) jsou mimo `/admin` a chrání je vlastní oprávnění. - Všechno, co se na webu stane, má záznam: kdo, kdy, kde, co a z čeho na co. Úpravy přes tužku jsou vidět v historii profilu toho, kdo je udělal. Historie ukazuje i zápisy, které se nepodařilo uložit, s možností zkusit je znovu. - `/postup` je jen pro Admina: ukazuje přehled z `postup-prehled.md` a po kliknutí celý záznam z `postup.md`. ### 7.6 Admin View - Admin si zapne Admin View. U každého textu a obrázku na webu, i u těch, které vzniknou později, se vpravo nahoře objeví tužka. Platí to i pro texty produktů, článků a dalších záznamů. - Klik otevře panel zprava. Upravený text jde do fronty úprav a hned se přeloží do ostatních jazyků, takže překlad jde před uložením zkontrolovat. Uložení fronty zapíše všechny jazyky do jazykových souborů. - U obrázku jde přidat další fotku (z prvku se sám stane slideshow), fotku nahradit nebo odstranit. Každé místo s obrázkem má vlastní složku. - Úprava právní stránky vytvoří novou verzi dokumentu s datem účinnosti. ### 7.7 Jazyky - Každý web je minimálně česky a anglicky, s viditelným přepínačem jazyka. - Texty jsou na serveru ve složce `jazyk/`: `cz.json` a `en.json`. Každý soubor má nejvýše 500 řádků, další texty pokračují v `cz2.json`, `en2.json` a tak dál (rozhodnutí uživatele). - Každý jazyk má vlastní URL (čeština `/`, angličtina `/en/`). ### 7.8 Design a animace - Čím víc animací, tím líp: scroll animace, 3D, glow efekty, animace loga, přechody stránek, mikrointerakce. Všechno v 60 FPS a s ohledem na `prefers-reduced-motion`. - Animace nikdy nezdrží obsah. Žádná úvodní obrazovka, která čeká na animaci. - Na prezentačních stránkách plná sada včetně 3D. Ve formulářích, `/admin` a pracovních aplikacích jsou animace také všude, ale rychlé a funkční (150 až 250 ms), aby nikdy nezdržovaly práci. - Zakázané: fialový gradient, pill tlačítka, emoji místo ikon, AI obrázky, falešná čísla, čítače a recenze, vágní hero text, badge Made with AI. ### 7.9 SEO - Unikátní title a description, jeden H1, správná hierarchie nadpisů, alt texty, og:image, canonical, hreflang, schema markup, sitemap.xml, robots.txt, čisté URL malými písmeny, interní odkazy, vynucené HTTPS, žádné rozbité odkazy, žádný zapomenutý noindex, ověřená Search Console, responzivita. ### 7.10 Právo a patička - Obchodní podmínky, Ochrana osobních údajů a Cookies (u eshopu i reklamační řád) podle skutečného stavu webu, skutečných údajů firmy a aktuálně platných předpisů. Nic si nevymýšlej. - Cookie lišta opravdu blokuje nenezbytné skripty do udělení souhlasu. - Úplně dole na každé stránce je patička ve vzhledu webu: - odkazy Obchodní podmínky, Ochrana osobních údajů a Cookies, k tomu Nastavení cookies, když web má cookie lištu, - řádek `© {aktuální rok} {Název firmy}. Všechna práva vyhrazena. Vytvořeno společností HeviSync`, kde se rok počítá sám a HeviSync je odkaz na https://hevisync.cz. ### 7.11 Bezpečnost - Autorizace na serveru u každého požadavku, rate limiting, CSRF, CSP a security headers, bezpečné cookies, secrets jen na serveru, bezpečné nahrávání souborů, žádné vystavené soubory, vypnutý debug. - Stránky pro přihlášené se nikdy neukládají do sdílené cache. ### 7.12 Přístupnost - WCAG 2.2 AA: alt texty, kontrast, ovládání klávesnicí s viditelným focusem, skip link, popisky formulářů, sémantické HTML, `prefers-reduced-motion` a možnost zastavit pohyb. ### 7.13 Aplikace a verze - Když má projekt web i aplikace, všechno je propojené přes jeden server. Co se změní v aplikaci na telefonu, je hned na webu i v aplikaci na PC, a obráceně. - Každá aplikace pro telefon a PC má autoupdater. Po otevření zjistí, že je na serveru novější verze, ukáže okno se seznamem změn všech přeskočených verzí a tlačítkem Instalovat a po kliknutí se sama nainstaluje. - Omezení platforem: iOS jen otevře App Store, Android mimo Google Play potřebuje při první aktualizaci povolení instalace (`pravidla/12-aplikace-a-verze.md`, kapitola 3.4). - Verze `A.B.C`, každé číslo počítá samo a nikdy se nenuluje: - A: obrovský grafický update nebo předělaný vzhled, - B: major update nebo nová funkce, - C: oprava. - Jedno vydání zvedne o 1 jen číslo nejvýznamnější změny, kterou obsahuje. Nikdy nezvedej vyšší číslo, než odpovídá změně, a nikdy nezvedej verzi aplikace, ve které se nic nezměnilo. - Věc, kterou uživatel dřív udělat nemohl, je B. Úprava nebo vylepšení existující funkce je C. - Během první stavby projektu se verze nevydávají. Při spuštění mají web i aplikace verzi 1.0.0. ``` 1.5.7 + oprava → 1.5.8 1.5.8 + nová funkce a 2 opravy → 1.6.8 1.6.8 + nový vzhled → 2.6.8 ``` ### 7.14 Nasazení - Žádný GitHub pro kód projektů, CI, nasazení ani služby napojené na GitHub. Kód je na vlastním Forgejo, web se nasazuje přes Cloudflare, data jsou na vlastním serveru. Stáhnout oficiální nástroj nebo číst dokumentaci na GitHubu je v pořádku. Výjimkou je jen tento skill, který žije v repozitáři HeviSlav/Claude-Skills. - Nikdy žádné větve, ani na Forgejo, ani na GitHubu, ani lokálně. Všechno se commituje rovnou do `main`. Rozpracovanou funkci na ostrém webu skryje přepínač funkce. - Na tokeny a přístupy (Forgejo, Cloudflare, server, email, překlady) se zeptej na začátku a řekni přesně, do kterého souboru a proměnné je uživatel vloží. Nikdy je neukládej do repozitáře, `postup.md` ani `CLAUDE.md`. - Variantu nasazení (vše na serveru za Cloudflare, nebo frontend na Cloudflare a backend na serveru) zjisti u každého projektu otázkou. ### 7.15 Komponenty - Každý prvek rozhraní (dropdown, vyskakovací okno, vysouvací panel, roztahování okna, tlačítko) je naprogramovaný jen jednou jako základní komponenta ve `spolecne/komponenty/`. - Vzhled a chování jsou jen v základní komponentě a v design tokenech. Místa použití vybírají varianty přes props a nic nepřepisují. - Nové schopnosti přibývají jako volby základní komponenty nebo jako komponenty složené z ní, nikdy kopií kódu. - Předělání vzhledu nebo chování je změna na jednom místě a projeví se všude (dropdown na 88 místech se změní úpravou jednoho souboru). - Katalog komponent v `/admin/komponenty` pro vizuální kontrolu všech variant. ### 7.16 Data na 80 let - Každý web, stránka i aplikace počítá s tím, že poběží 80 let a data budou celou dobu přibývat. Po desítkách let musí být stejně rychlá a pořád zvládne 10 000 lidí najednou. - ID `bigint` nebo UUIDv7, čas v `timestamptz` (žádný problém roku 2038), peníze bez `float`, rostoucí tabulky rozdělené po letech, každý dotaz s indexem a limitem, soubory po letech a měsících, odhad růstu na 1, 10 a 80 let. - Osobní údaje se po době uchování automaticky mažou nebo anonymizují (GDPR), i když systém zvládne data držet desítky let. - Zálohy a úplný export v otevřených formátech, aby data přežila výměnu frameworku i hostingu. - Před spuštěním zátěžový test na syntetických datech za 10 let, u nejrychleji rostoucích tabulek za 80 let. ## 8. postup.md a postup-prehled.md Dva soubory v kořeni projektu (šablony v `sablony/`): | Soubor | Co obsahuje | Kdy se čte | |---|---|---| | `postup-prehled.md` | chyby, které se nesmí opakovat, rozpracovaný plán a jeden řádek za každý záznam | celý na začátku každého chatu | | `postup.md` | úplné záznamy o každém bodu | nikdy celý, jen jeden záznam, když potřebuješ detail | Do `postup.md` sáhni, jen když potřebuješ vědět, jak se něco dělalo, proč padlo rozhodnutí, jaký problém už nastal nebo co přesně se změnilo. Záznam vyber podle řádku v přehledu a přečti jen jeho část: ``` awk -v h="### 2026-09-16 · Registrace a profil · Web 1.0.0" '$0==h{p=1;print;next} p&&/^### /{exit} p' postup.md ``` Když nevíš, který záznam to je, najdi klíčové slovo (`grep -n -i "ares" postup.md`) a přečti jen nalezenou část. Po každém dokončeném bodu: 1. Do `postup.md` přidej nahoru pod úvod záznam v tomto tvaru: ``` ### 2026-09-16 · Registrace a profil · Web 1.0.0 **Hotovo** - Co vzniklo nebo se změnilo, popsané z pohledu uživatele. **Problémy a řešení** - Co nefungovalo, proč a jak se to vyřešilo. **Poučení** - Co příště dělat jinak. ``` 2. Do `postup-prehled.md` přidej nahoru do sekce Záznamy jeden řádek: nadpis záznamu přesně jako v `postup.md` (bez `### `), dvojtečka a shrnutí do jednoho řádku. ``` - 2026-09-16 · Registrace a profil · Web 1.0.0: registrace s ARES, hesla argon2id, složky účtů, profilovka ``` 3. Nové zásadní poučení zapiš jednou krátkou větou i do sekce „Chyby, které se nesmí opakovat“ v přehledu. Podobná poučení slučuj, sekce má nejvýše 20 řádků. Pravidla: - Nadpis každého záznamu je jedinečný (datum, název, případně platforma a verze), aby šel najít přesně. - Verzi uveď jen když se vydávala. Sekce záznamu bez obsahu vynech. - Přehled zůstává krátký: jeden řádek na záznam, žádné podrobnosti. - Nikdy do nich nepiš hesla, tokeny, klíče ani osobní údaje. Oba soubory se zobrazují Adminům na `/postup`. - Piš je stejně jako ostatní texty: bez pomlček mezi slovy a bez AI frází. **Starší projekt bez přehledu** (má jen `postup.md` z verze skillu 1.0.0) převeď jednou: přečti `postup.md` po částech, přesuň sekce Chyby a Rozpracovaný plán do nového `postup-prehled.md`, ke každému záznamu napiš řádek do přehledu a v `CLAUDE.md` projektu nahraď pravidlo o čtení celého `postup.md` pravidlem ze šablony. Když `~/.claude/CLAUDE.md` obsahuje starší větu, že se má číst celý `postup.md`, nahraď ji větou z README (rozhodnutí uživatele ze 24. 9. 2026) a řekni to jednou větou. Potom už celý `postup.md` nikdy nečti. ## 9. Revize a audit Při revizi existujícího webu nebo aplikace projdi `pravidla/14-kontrolni-seznam.md` a ke každému bodu uveď stav splněno, nesplněno nebo neaplikovatelné, s odkazem na soubor a řádek. Nic si nedomýšlej, každý bod ověř v kódu nebo na běžícím webu. ## 10. Úpravy tohoto skillu Když uživatel chce skill změnit: 1. Uprav ho v repozitáři HeviSlav/Claude-Skills (u HeviSync naklonovaný v `E:\Code\.Github\Claude-Skills`), ve složce `all-in-one-skill/`. 2. Zvedni `metadata.version` v hlavičce tohoto souboru podle pravidel verzí (kapitola 7.13): C za opravu nebo doplnění pravidla, B za novou oblast nebo novou schopnost, A za přestavbu celého skillu. Bez zvýšení verze se aktualizace nikomu nenabídne. 3. Když se mění popis schopností, uprav i `README.md` v kořeni repozitáře a přidej řádek do jeho Historie verzí. 4. Commit do `main` s lidskou českou zprávou a push na GitHub, se souhlasem uživatele. 5. Stejnou verzi zkopíruj do `~/.claude/skills/all-in-one-skill/`, aby platila hned.