Skip to content
04 / DESIGNOVÁ A INŽENÝRSKÁ CASE STUDYGrafika pro restaurace · Eshopové šablony · Discord botV PROVOZU

Linka.

  1. Vstup
  2. Audit
  3. Bannery
  4. Ikony
  5. Screeny
  6. Šablona
  7. Chrome
  8. Předání

Grafik postavil výrobní linku pro restaurace. Ne generátor. Bannery, ikony, screeny do obchodů i celé eshopové šablony dělá Claude Code podle pravidel, která jsem sepsal z 13 let grafického a UI designu. A měří, co se dá změřit, dřív než chybu uvidí obchod, klient nebo zákazník.

POSTAVIL DAVID RAJNOHA ·  SRPEN–ŘÍJEN 2026
Dolů
00Přehled projektu
Role
Designér a inženýrPravidla, linka, šablony, bot
Kontext
Objednávkové systémy pro restauraceInterní práce u zaměstnavatele
Období
Srpen–říjen 2026Stav · denně v provozu
Stack
Python · Node · Claude CodeChrome DevTools Protocol · Discord
0
Skriptů linky · 11 509 řádků
0
Eshopových šablon od září
0
Zapsaných chyb platformy
0
Minut medián · zakázka z Discordu
01
Problém
Zákazník
Restaurace na objednávkové platformě
Potřebuje
Grafiku do dvou obchodů + eshop
Dřív
Ručně, klienta po klientovi
Jedna restaurace, jedna sada
  • Bannery · eshop, appka, Google Play
  • Balík log · všechny sloty adminu
  • 38 ikon · App Store + Google Play
  • Screeny do obchodů · sada pro každý obchod
  • QR kód na účtenku
  • Posty a plakáty „Stáhni si appku“
  • Eshopová šablona · desktop + mobil

Restaurace, která začne prodávat online, potřebuje překvapivě hodně grafiky. Bannery na eshop, do appky a na Google Play. Balík log ve všech rozměrech, které admin chce. Ikony do obou obchodů. Dvě sady screenů, protože Apple a Google chtějí každý něco jiného. QR kód na účtenku. Plakáty, že má appku. A navrch má samotný eshop vypadat jako ta restaurace, ne jako výchozí vzhled platformy.

Všechno se dělalo ručně a od nuly pro každého klienta. Řetězce se rozjížděly: jedna síť pizzerií měla 9 eshopů pro 11 provozoven ve třech různých podobách. Nikdo to tak nechtěl. Prostě to tak vzniklo, pobočku po pobočce.

„Každá restaurace potřebovala stejnou sadu a každá ji dostala vyrobenou od nuly. Ta práce nebyla těžká. Byla pořád stejná, a pokaždé se dala pokazit jinak.“
02
Teze

Linka, ne generátor. Stroj dělá opakovanou práci a měření. Vkus, značka a schválení zůstávají na člověku.

Generátor vám dá něco, co vypadá hotově. Linka vám dá něco, co prošlo kontrolou na každé stanici, a zastaví se, když kontrola neprojde. Každá brána kvality v ní je proto, že jednou něco prošlo.

Co zůstává na člověku
  • Vkus: co je dobré a co je slop
  • Značka a komunikace s klientem
  • Schválení nové práce; zakázky z Discordu kontroluje kolegyně
  • Nahrání do adminu a do obchodů
  • Z nové chyby udělat nové pravidlo
Co dělá stroj
  • Každý rozměr, každý formát, každý obchod
  • Kontrast, rozměry, alfa, přetečení, dotykové cíle — změřené
  • Každou stránku a stav eshopu ve skutečném Chromu
  • Řekne, kde se zastavil a proč
  • Nikdy nic nenahrává sám
03
Linka na grafiku

Dovnitř jedna fotka, tři loga a URL. Ven zkontrolovaná sada.

Vstup je to, co restaurace opravdu má: jednu fotku jídla, logo ve třech variantách a adresu eshopu. Všechno o klientovi je v jednom souboru se zadáním — barvy, písma, texty na banner. Ve skriptech není o klientovi nic natvrdo.

  1. 01

    Vstupy

    Změří loga a fotku dřív, než se cokoli spustí: lem kolem loga, tečky po upscalu, podklad zapečený do „průhledného“ souboru.

    Při špatném vstupu zastaví běh

  2. 02

    Audit

    Přečte živý eshop: ID, co je už nasazené, loga, pokrytí fotkami.

    Ví, co existuje, než vyrobí další

  3. 03

    Bannery

    Přesné rozměry pro eshop, appku a Google Play. Nadpis se zvětší do místa, max dva řádky.

    Kontrast a rušnost pod textem, změřené

  4. 04

    Balík log

    Loga do všech slotů adminu, piny s kontrastem 3:1 proti mapě, favicon ze značky.

    Kontrolní stránka pro Chrome: tab, mapa, patička

  5. 05

    Ikony

    38 ikon pro oba obchody a feature graphic. Ikona Play jako plný čtverec, iOS tmavá a tónovaná varianta.

    Bezpečná zóna v maskách Androidu

  6. 06

    Screeny

    Čtyři obrazovky na obchod, jedno souvislé pozadí rozřezané na čtyři, správný telefon pro správný obchod.

    Rozměry, alfa, švy mezi panely

  7. 07

    Checklist

    Porovná každý výstup s pravidly obchodu, kam míří.

    „HOTOVO“, nebo „obchod nevezme“

Linka nikdy nic nenahrává. Člověk se podívá na kontaktní archy a nahraje to do adminu a do obchodů. Dvě fáze nejsou skripty vůbec: napsat eshopovou šablonu a projít každou stránku v Chromu. To je práce Claude Code, viz další sekce.

04
Eshopové šablony

Claude Code postaví celou šablonu a pak projde každou stránku ve skutečném prohlížeči.

Platforma má dva adminy a každý bere šablonu v úplně jiné podobě. Postup je pro oba stejný: postavit, ověřit na živém webu před nasazením, nasadit, ověřit znovu naostro.

Starý admin

CSS a JS diff připojený na konec zkompilovaného stylu

Šablony jsou ve složce pro každou provozovnu. Linter chytá pasti platformy — potichu zahodí clamp(), min(), max(), @import a // komentáře — pak CSS načte v headless Chromu a spočítá, kolik pravidel prohlížeč opravdu přijal.

Síť pizzerií: 9 eshopů pro 11 provozoven ve třech podobách, sjednocené do jedné. Soubor každé pobočky nese i její dosavadní kód (přesměrování, kiosek). Simulace před nasazením: 9 poboček a appka, 1440 i 390 px, 20 běhů. Po nasazení 13. října kontrola naostro na živých webech: 20 běhů, 16 prošlo napoprvé a 4 po opakování (napoprvé ukázaly starou stránku, než se uložení v adminu propsalo). Kiosek vypadal na dvou pobočkách pixel po pixelu stejně jako předtím, na třetí s rozdílem 2 px ve vyhlazení.

Nový admin

Šablona jako JSON: layout, stránky, prefaby, proměnné stylu

Pro každého klienta builder, který JSON vygeneruje, takže se oprava dělá jednou ve zdroji, ne v JSONu o 200 kB. Vedle toho playbook nové šablony a katalog chyb platformy a technik, zapisovaný tak, jak se na ně přicházelo.

Tmavá šablona pro restauraci se dvěma vchody — z jedné strany Mexiko, z druhé Itálie — podle návrhu klienta, desktop i mobil, odladěná end to end.

Smyčka, u každé šablony
  1. 01
    Build

    Builder → JSON. Pojistka shodí build, když do šablony prosákne jméno nebo prefix minulého klienta.

  2. 02
    Injekce

    Audit vloží CSS a tokeny šablony do živého webu na místo, kde budou po nasazení.

  3. 03
    Audit

    10 scénářů na 5 šířkách. Ke každému screenshot a měření.

  4. 04
    Oprava

    Jedna oprava v builderu, nový build, znovu audit.

  5. 05
    Nasazení

    Nahrává člověk. Nic se nenasadí samo.

  6. 06
    Přejímka

    Stejný audit bez injekce, na skutečně nasazeném webu.

audit-zive.mjs — výňatek z reportu
# Audit sablona.json · CSS vlozene pred hydrataci · 1440 1024 768 440 390## Staticka kontrola CSShover mimo @media(hover:hover) ............. 0pravidel s :active (tap odezva) ............ 36prefers-reduced-motion ..................... anohex mimo tokeny ............................ 0scenar    sirka  preteka kontrast dotyk<44 bez-hover chybyhome      1440   0        0        0       0/17      1home       390   0        0        0       0/16      1menu       390   0        0        0       0/18      1modal     1440   0        0        0       0/4       1   zavreni .95 .76 .37 .00kosik      440   0        0        2       0/24      2   pridano, odber+platba+spropitnekontakt   1440   0        0        0       1/12      1pravni     390   0        0        0       —         1   VOP ok, GDPR ok
Skutečný report, zkrácený. Nejsou to samé nuly: dva dotykové cíle pod 44 px v košíku na 440 px a jeden prvek bez hoveru na kontaktu šly zpátky k opravě. Chyba v konzoli je platformy — je tam i bez šablony.
05
Brány kvality

Každá brána je jizva.

Žádná z nich nebyla navržená předem. Každá je tam proto, že chyba jednou k někomu došla — k recenzentovi obchodu, ke kolegyni, ke klientovi, nebo ke mně.

Grafika

  • Přesné rozměry a žádná alfa, podle obchodu
    ↳ App Store odmítl sadu, kterou Google vzal
  • Rámeček telefonu podle obchodu
    ↳ Z Google Play se vrátil rámeček, který vypadal jako iPhone
  • Kontrast a rušnost pod každým nadpisem
    ↳ Text na fotce jídla musí jít přečíst i v náhledu
  • Švy mezi panely ve screenech
    ↳ Čtyři obrazovky sdílejí jedno pozadí a musí navazovat
  • Čeština v souborech písma, které Google opravdu servíruje
    ↳ Některá oblíbená písma č, ř, ž vůbec nemají
  • Špatný vstup zastaví běh
    ↳ Logo s lemem pokazí každý výstup po něm

Eshop

  • Přetečení do strany na 5 šířkách
    ↳ Mobil se rozbije první
  • Kontrast každého textu proti skutečnému podkladu
    ↳ Vrstvy s alfou jednoduchou kontrolu obelžou
  • Písma opravdu načtená, změřená na canvasu
    ↳ Písmo, které se nenačte, potichu spadne na náhradní
  • Dotykové cíle 44 px na mobilu
    ↳ Zákazník restaurace objednává jedním palcem
  • Hover skutečnou myší, zavírací animace modalu
    ↳ Zavíraný modal 0,3 s stál a pak naráz zmizel
  • Strom uzlů proti šabloně, která jede v produkci
    ↳ Špatný typ uzlu nevykreslí nic, a to s nulou chyb
checklist.py — sada do obchodů před opravou
# 3-store/listingGooglePlay/01-1080x1920.png ......... OKGooglePlay/02-1080x1920.png ......... OKAppStore/01-1242x2688.png ........... obchod nevezme: slot chce 1206x2622AppStore/02-1242x2688.png ........... obchod nevezme: slot chce 1206x2622NENI HOTOVO · 2 vystupy neprojdou pravidly App Store
06
Co se rozbilo

Sedm věcí, které se pokazily, a co změnily.

Držím si je, protože jsou to skutečný návrh celého systému. Každá skončila jako pravidlo, skript nebo brána — ne jako poznámka, že mám být opatrnější.

  1. 23. 9.01

    App Store odmítl screeny

    Co se stalo
    Jedna sada screenů 1080×1920 šla do obou obchodů. Google ji vzal, App Store Connect ne. Kolegyně na to přišla až při nahrávání. Horší je, že checklist hlásil HOTOVO, i když sada pro Apple vůbec neexistovala.
    Co se změnilo
    Dvě sady, jedna pro každý obchod. Checklist teď čte hlavičku PNG a kontroluje přesný rozměr a alfu podle pravidel každého obchodu.
  2. 1. 10.02

    „Typický iPhone, myslím, že to neschválí.“

    Co se stalo
    Rámeček telefonu v sadě pro Google Play měl průstřel kamery, ale tělo iPhonu. Kolegyně sadu vrátila.
    Co se změnilo
    Rámeček se volí podle obchodu: pro Google Play Android s androidím stavovým řádkem, pro Apple iPhone.
  3. 9. 10.03

    „Potřebujeme real fotku, ne AI slop.“

    Co se stalo
    Návrh banneru ukazoval jídlo, které si model přimyslel. Vypadalo dobře, a nebylo to jídlo té restaurace.
    Co se změnilo
    Na banneru je jen skutečné jídlo. AI smí skutečnou fotku překomponovat do tvaru banneru, pixely jídla jdou nechat původní, a když AI na obrázek sáhla, řekne se to hned.
  4. 12. 10.04

    Apple změnil povinný rozměr

    Co se stalo
    Nový povinný slot iPhone 6,3" bere jen 1179×2556 nebo 1206×2622. Hotové sady tří klientů (1242×2688 a 1320×2868) neprošly.
    Co se změnilo
    Skript odvodí sadu 6,3" z té stávající, checklist dostal nové pravidlo a všichni tři klienti byli převedení týž den.
  5. 26. 8.05

    Menu zmizelo s nulou chyb

    Co se stalo
    Nová šablona se nasadila bez filtru kategorií a bez všech produktů. HTTP 200, čistá konzole. Vypadalo to, že klient nemá produkty. Tři špatné typy uzlů najednou.
    Co se změnilo
    Zlaté pravidlo playbooku: strom 1:1 podle šablony, která jede v produkci, novinky po jedné. Skript porovná typy uzlů před prvním nasazením.
  6. 18. 9.06

    Naše CSS schovalo přídavky, které zákazník zaplatil

    Co se stalo
    Pravidlo, které mělo schovat prázdnou poznámku, schovalo i řádek „Přidáno: slanina, čedar“. Poznámka je prázdná skoro vždy, takže zaplacené přídavky z rekapitulace košíku mizely.
    Co se změnilo
    Opraveno týž den na třech eshopech i v jejich appkách. Poučení šlo do katalogu chyb: prázdný potomek neznamená prázdný blok — než něco platformě schovám, přečtu si její zdroj.
  7. 29. 9.07

    Simulace nevidí, co data nevyvolají

    Co se stalo
    Audit před nasazením běžel na webu se 4 kategoriemi. Skutečná restaurace jich měla 20, platforma ukázala šipku posunu — jako plný barevný kruh přes kategorii.
    Co se změnilo
    Po každém nasazení běží stejný audit znovu na skutečném webu, bez injekce. Přesně tak se u sítě pizzerií našla neviditelná lišta „Máme zavřeno“.
07
Discord bot

Linku spouští zprávou i kolegyně, které nejsou grafičky.

Ne chatbot, který generuje obrázky. Fronta zakázek s jasnými hranicemi: kolegyně z podpory nebo obchodu napíše, co restaurace potřebuje, přiloží soubory a hotovou sadu dostane zpátky do stejného vlákna.

OBR. 01 — JEDNA ZAKÁZKA
  1. 01
    Kolegyně

    Napíše zakázku do kanálu, přiloží logo nebo QR

  2. 02
    Discord bot (Docker)

    Otevře vlákno, stáhne přílohy, zařadí zakázku do fronty

  3. 03
    Worker

    Bere jednu zakázku najednou, pustí session Claude Code v repu linky

  4. 04
    Claude Code

    Stejná pravidla jako ruční práce. Do vlákna píše jen dvěma nástroji: odpověď a dotaz

  5. 05
    Vlákno

    Milníky, pak výsledek s přílohami. Odpověď naváže na stejnou session

Návrhová rozhodnutí

Souborový protokol, jeden zapisovatel na soubor
Bot a worker nikdy nepíšou do stejného souboru. Žádné zámky, které by šly pokazit.
Jedna zakázka najednou
Dvě session v jednom repu by si přepisovaly výstupy.
Stejná pravidla jako ruční práce
Session čte stejná pravidla a paměť projektu jako já. Poznatek smí nahlásit, zapsat ne.
Tep
Bot ví, jestli PC jede. Po 12 minutách ticha worker sám napíše, jak to vypadá.
Dohnání po spánku
Když se PC probudí, stáhnou se zmeškané zprávy, nejvýš 3 dny zpátky.
Velké soubory přes sdílený disk
Co má přes 20 MB, jde jako odkaz místo přílohy.

Bezpečnostní model

  • Zakázku spustí jen povolení lidé — ne webhooky, ne jiní boti.
  • Hook před každým nástrojem: zápis jen do výstupních složek a šablon, nikdy do pravidel, paměti a skriptů.
  • Žádná tajemství, žádná síť kromě vlastních nástrojů pro vlákno.
  • Žádný přístup k mému přihlášenému Chromu. Snímky eshopu dělá headless Chrome ze skriptů linky.
  • Přílohy jen z výstupních složek, s filtrem na všechno, co vypadá jako klíč.
  • Bot prošel dvěma koly recenze AI agenty pro bezpečnost, okrajové případy a slepou kontrolu bez kontextu. Druhé kolo (6. 10.) našlo přes 20 nálezů, ty podstatné jsou opravené.

Popsané schválně jako model. Konkrétní konfigurace by byla návod, jak to obejít.

08
Jedna zakázka od začátku do konce

Celá sada pro appku za 15 minut.

Skutečná zakázka z logu, 6. října. Kolegyně chtěla sadu pro appku pizzerie na novém adminu. Časy jsou z logu workeru, zprávy jsou to, co session psala do vlákna.

ZAKÁZKA#20261006-0736
Kolegyně z podpory
  1. 1)Screeny do App Store i Google Play podle jejich eshopu, se správnými rámečky telefonů
  2. 2)Ikony pro nový admin, všech 7 vrstev
  3. 3)QR na účtenku — QR z adminu přikládám
⎘ app-qr-code.svg
  1. 00:00
    startSession startuje.
  2. 00:52
    vláknoProhlížím, co už pro klienta existuje, než začnu generovat.
  3. 02:06
    vláknoČtu QR z přílohy, abych zjistil, kam vede.
  4. 02:10
    hookHook zablokoval příkaz: frontu zakázek spravuje worker — inbox, outbox ani stav neupravuj.
  5. 02:36
    vláknoPřiložené QR je stejné jako to v předávací složce. Jdu na screeny.
  6. 04:50
    vláknoDvě drobné vady ve snímcích: nad nadpisem vykukuje okraj karty, dole je useknutý nadpis. Dolaďuju posun stránky.
  7. 10:02
    vláknoSnímky eshopu jsou čisté. Pouštím generování obou sad.
  8. 11:06
    vláknoIkony sedí: značka v bezpečné zóně, favicon čitelný na světlém i tmavém.
  9. 11:45
    vláknoQR ověřené: Android skočí rovnou do Google Play, iPhone dostane stránku s oběma obchody.
  10. 12:45
    vláknoKontroluju rozměry a alfa kanál všech souborů.
  11. 13:44
    vláknoNa pozadí banneru do Google Play je vidět svislý šev. Upravuju výřez na jeden panel.
  12. 14:57
    výsledekHotovo. ZIP (18,9 MB), náhled screenů a QR na účtenku jsou ve vlákně.

89 kroků, 14 min 55 s, mezitím bez člověka. Nová práce byly obě sady screenů; ikony a QR byly hotové z dřívější zakázky a session je jen ověřila. Před nahráním výsledek zkontrolovala kolegyně.

09
Čísla

Jen to, co je změřené.

Spočítané na disku a v logu zakázek 17. října 2026. Úspora času proti ruční práci tu není: nezměřil jsem ji, tak ji netvrdím.

44
Python skriptů linky na grafiku
11 509 řádků
1 260
Řádků runbooku
PIPELINE.md
12
Předaných balíků od 5. 10.
6 klientů, včetně oprav a doplněných sad
12+9
Eshopových šablon postavených nebo přestavěných od září
starý admin + nový admin
88
Zapsaných chyb platformy
a k tomu 95 technik
10×5
Scénářů auditu × šířek
u každé šablony, před i po nasazení
11
Zakázek přes Discord za první týden
5.–12. 10. · 1 testovací
12
Minut medián zakázky z Discordu
8 zakázek bez čekání na odpověď · nejdéle 42
2 127
Řádků TypeScriptu v botovi
bot + worker · 24 testovacích souborů
10
Poctivé limity

Co to není.

  1. 01

    Dva režimy, dvě míry dozoru. Novou práci dělám se session Claude Code já a schvaluju ji. Zakázky z Discordu běží beze mě a výsledek kontroluje kolegyně. Brány jsou stejné, oko grafika u nich není.

  2. 02

    Nic se nenahrává samo. Do adminu a do obchodů nahrávají lidé.

  3. 03

    Simulace před nasazením neukáže stavy, které data na testovacím webu nevyvolají. Proto má každé nasazení přejímku naostro.

  4. 04

    Windows nemá sandbox pro shell. Pravidla hlídají tvar příkazu a odhodlaný útočník by je skriptem obešel. Pro pár kolegyň přijatelné, pro víc lidí ne.

  5. 05

    Worker běží na mém PC. Když je vypnuté, zakázky čekají.

  6. 06

    Vzorek zakázek přes bota je malý: 11 za první týden.

Produkt jsou pravidla.

Skripty by šly přepsat snadno. Čas zabral seznam věcí, které se nesmí stát znovu — a linka, která je při každém běhu zkontroluje.

Napsat DavidoviZpět na všechny práce