RutinaCases — my.mnx.cz

Modely Claude — který na co

Přehled aktuálních modelů (červenec 2026) pro rozhodování, kdy použít který — v Claude Code i v claude.ai.

Přehled modelů

Model	Tier	Nejlepší pro	Context
Haiku 4.5	Rychlý / levný	Opakující se jednoduché úkoly, rychlé dotazy	200 K
Sonnet 4.6	Vyvážený	Kódování, deployment prompty, každodenní práce	1 M
Opus 4.8	Výkonný	Složité plánování, nové sekce webu, architektura	1 M
Fable 5	Špičkový	Nejnáročnější frontierové úlohy	1 M

Mythos Preview — nejsilnější model, není veřejně dostupný. Anthropic ho nasazuje jen u vybraných organizací v rámci Project Glasswing.

Jednoduché pravidlo pro každodenní práci

Situace	Model
Plánuji, vymýšlím, píšu nový obsah	Opus 4.8 (nebo Fable 5 pro nejtěžší úkoly)
Kóduji, deployuji, ladím CSS	Sonnet 4.6 — od 2/2026 jako první Sonnet překonal starší Opus v coding benchmarcích
Opakuji stejný typ úkolu mockrát	Haiku 4.5 — zbytečně neplýtvat Opusem
Claude Code (výchozí)	Sonnet 4.6 — Claude Code ho používá automaticky

Kredity a tokeny — jak to funguje

Token ≈ 0,75 slova (nebo 4 znaky). Platíš za vstupy (co pošleš) i výstupy (co Claude vrátí).

Proč session stojí tolik kreditů: každá zpráva v chatu = celá historie konverzace znovu jako vstup — čím delší chat, tím dražší každý další dotaz. Velké soubory v kontextu (index.html 1600+ řádků) = tisíce tokenů při každém str_replace.
Fable/Opus = ~5× dražší než Sonnet, ~10–25× dražší než Haiku.

Úkol	Proč	Model
Psaní nového obsahu / plánování	Kreativní a analytické úkoly potřebují plný výkon	Opus 4.8
Deployment prompt + editace	Mechanická práce — Sonnet to zvládne stejně dobře	Sonnet 4.6
Rychlý dotaz / jednořádková oprava	Zbytečně neplýtvat Opusem	Haiku 4.5

Jak šetřit kredity

Nový chat = prázdný kontext → levnější dotazy, zvláště po dlouhých sessions
Mechanické úkoly (deployment, str_replace) → Sonnet nebo Claude Code místo chatu
Velké soubory nepřikládat celé, pokud stačí jen výňatek
/compact v Claude Code zhustí historii a uvolní tokeny mid-session
Kontrolovat usage na claude.ai po každé delší session — zvláště při práci s Opusem nebo Fable

Terminál — úplné základy

Minimum příkazů macOS terminálu pro pohyb po složkách a spuštění Claude Code. Všechny jsou bezpečné — nic nemažou, nic nemění.

Příkaz	Co dělá
`pwd`	Vypíše, ve které složce právě jsem („print working directory")
`ls`	Vypíše obsah aktuální složky (soubory a podsložky)
`cd web-my-mnx`	Přejde do složky `web-my-mnx` („change directory")
`cd ..`	Přejde o složku výš
`open .`	Otevře aktuální složku ve Finderu — tečka = „tady"
`claude`	Spustí novou Claude Code session v aktuální složce
`claude -c`	Obnoví poslední session v aktuální složce (continue)
Tab	Doplní rozepsaný název souboru/složky — rychlejší a bez překlepů
↑ šipka nahoru	Vrátí předchozí napsaný příkaz — nemusí se psát znovu

Standardní start pracovní session: otevřít Terminál → cd web-my-mnx → claude (nebo claude -c pro navázání). Ověření, že jsem ve správné složce: pwd.

CLAUDE.md — paměť projektu

Soubor v kořeni repa web-my-mnx, který Claude Code přečte automaticky při každém startu session. Napíšeš do něj pravidla jednou — a nemusíš je opakovat v každém promptu. Přežije /compact i restart session.

Co to řeší

Opakující se pravidla jednou natrvalo — „supabase.js nikdy neměnit", „migrace nespouštět", brand tokeny. Nemusí se psát do každého zadání jako v Kostře promptu — Claude Code je má vždy.
Platí napříč všemi appkami — jeden kořenový soubor pro celé repo (frootkaces, projects, faktucases, rutinacases), protože pravidla jsou pro všechny stejná.
Kostra promptu se tím zkrátí — v zadání pak stačí to, co je pro daný úkol specifické.

Kam patří — a kam ne

Patří do kořene složky web-my-mnx na disku, vedle složek appek. Commituje se do gitu jako každý jiný soubor.
Nepatří na FTP — je to instrukce jen pro Claude Code na disku, na živém webu nemá co dělat. Stejně jako se tam nenahrává složka .git.
Průběžně procházet — když se objeví nové pravidlo, doplnit ho i sem, ne jen do hlavy. Stejná logika jako u tohoto living docu.

Založení: v Claude Code session otevřené v web-my-mnx stačí říct „vytvoř CLAUDE.md v kořeni repa" a vložit obsah — nebo soubor uložit ručně v CotEditoru a commitnout.

Obecné principy

Univerzální napříč appkami — platí pro Frootkaces, Jobcases i FaktuCases stejně.

Screenshot ≠ přesná míra. Skvělé na „tohle je špatně, podívej se" — ne na přesné px hodnoty (DPI displeje, browser zoom, Photoshop sampling to zkreslí). Na čísla použít DevTools inspector.
Otevřená rozhodnutí zapsat hned do living docu — jinak se snadno ztratí mezi dneškem a „za dva týdny, až na to dojde".
Víc souvisejících změn spojit do jednoho Claude Code promptu místo mnoha drobných kol tam-a-zpět — šetří credits i čas.
Sledovat diff před commit/push, ne slepě odsouhlasit.
„Yes" u git commands, ne „always allow" — jednotlivé schvalování zůstává, i když by to ušetřilo pár kliknutí.
Kontrolovat credit usage po delších sessions nebo před větším úkolem.

Schvalování v Claude Code

Preventivní sekce — co vědět před kliknutím na Yes. Není to SOS: SOS řeší, co dělat, když se něco už pokazilo; tohle je „na co si dát pozor předem".

⚠️ Watch before you approve

U těchto příkazů se zastavit a přečíst pořádně, co přesně se schvaluje:

Příkaz obsahuje	Proč pozor
`rm` / `rm -rf`	Trvale maže soubory/složky — bez koše, bez návratu. Zkontrolovat cestu znak po znaku.
`sudo`	Příkaz běží se správcovskými právy — může sahat kamkoliv v systému.
`database`	Práce s daty — Claude Code nikdy nesmí sám spouštět migrace ani mazat data.
`secret` / klíče	Práce s tokeny a hesly — secrets nepatří do kódu ani do gitu, jen do heslo manažeru a Supabase Manage secrets.

Jak číst diff

Zelené řádky s + = co se do souboru přidává. Červené s - = co se maže. Řádek, který se mění, se zobrazí jako červený (stará verze) + zelený (nová verze) pod sebou.
Hlavní otázka při čtení: mění se něco mimo zadání? Pokud diff sahá do souboru nebo sekce, o které prompt nemluvil — zeptat se proč, ne odklikávat.
Nemusíš rozumět každému řádku CSS/JS — stačí poznat, kde se změna děje (který soubor, která sekce) a jestli rozsah odpovídá zadání. Na jednotlivé vlastnosti je CSS tahák níže.
Malý diff (pár řádků) = přečíst celý. Velký diff = projít aspoň názvy souborů a začátky bloků — a když něco nesedí, zeptat se Claude Code, co ten blok dělá, než se schválí.

Pravidlo — jednotlivě, nebo autopilot?

Dvě možnosti schvalování v Claude Code:

Scénář A — jednotlivé schvalování: Claude Code se ptá na každou změnu zvlášť. Vždy se podívat, co přesně se schvaluje, než se řekne Yes.
Scénář B — „od teď dělej změny bez ptaní" v rámci složky: rychlejší, ale jen když je zadání jisté a jde o nerizikový úkol (např. čisté CSS úpravy).

Jednoduché pravidlo: Nejistá nebo nejasná instrukce → zůstat u jednotlivého schvalování. Jasný úkol, jednoduchá složka, důvěra v zadání → autopilot v rámci složky. U git příkazů vždy jednotlivě — Yes, ne „always allow".

Plan mode — nejdřív plán, pak kód

Než Claude Code začne psát, umí nejdřív vypsat plán kroků ke schválení — teprve po odsouhlasení sáhne na soubory. Přesně princip „nejdřív navrhnout, pak stavět".

Zapnutí: Shift+Tab přepíná mezi plan mode a act mode. V plan mode Claude Code jen navrhuje, nemění.
Kdy se hodí: u větší nebo nejasné změny — vidíš dopředu, co se chystá dělat, a můžeš plán opravit dřív, než vznikne kód k odklikávání.
Kdy netřeba: u drobné jednoznačné úpravy je plan mode zbytečný mezikrok.

Bezpečné příkazy v Claude Code terminálu

Základní sada, kterou lze používat bez obav — nic z toho nesahá do kódu ani do gitu.

Příkaz	Co dělá
`/help`	Zobrazí seznam všech dostupných příkazů v aktuální session
`/config`	Otevře vizuální nastavení Claude Code (žádné psaní do souborů). Tady se dá jednou nastavit čeština napevno — Claude Code pak odpovídá česky trvale
`/clear`	Vymaže historii konverzace na prázdný kontext. Předchozí konverzace zůstává uložená na disku
`/compact`	Zhustí historii konverzace, uvolní místo v kontextu, zachová klíčové informace
`/cost`	Zobrazí aktuální spotřebu tokenů/nákladů v dané session
`/exit`	Bezpečně ukončí session
`Esc` ×2	Vyvolá „rewind" menu — lze vrátit poslední změny v kódu, historie konverzace zůstane zachovaná
`claude -c`	Obnoví nejnovější session ve stávající složce
`claude --resume`	Obnoví konkrétní session podle ID — i z jiné složky

Před /exit vždy zkontroluj, jestli recap na konci session nezmiňuje něco nedodělaného (např. čekající Supabase migraci) — vyřešit nebo vědomě odložit předtím, než se ukončí.

Taháky pro koding

Rychlé reference pro samostatnou práci — kostra promptu, CSS vlastnosti z diffů, mapa appky a klávesové zkratky. Cíl: méně dotazů, méně screenshotů, méně kol tam-a-zpět.

Co má dobrý prompt pro Claude Code vždy obsahovat

1Který soubor / která appka — přesná cesta (např. projects/index.html), ne „ten job tracker".
2Co změnit — konkrétní seznam změn, všechny související v jednom kole.
3Čeho se nedotýkat — výslovně: supabase.js nikdy neměnit ani nenačítat, spuštěné migrace needitovat.
4Brand tokeny odkazem — „brandová fialová #7B2FFF, tmavé pozadí #0d0d0f" — přesné hodnoty jsou v tabu Brand tokeny níže.
5Pravidlo pro migrace — „migraci jen připrav jako nový idempotentní soubor, nespouštěj — spustím ručně v SQL Editoru".
6Co na závěr — commit s terse jednořádkovou zprávou + Co-Authored-By, push až po mém odsouhlasení.

Kostra ke zkopírování

## Zadání — [appka], [datum]

Soubor: [cesta k souboru]

### Změny
1. [změna 1 — co, kde, jak má vypadat]
2. [změna 2]

### Nesahat
- supabase.js (frozen, neměnit, nenačítat)
- [cokoliv dalšího mimo zadání]

### Databáze (pokud je potřeba)
- Migraci jen připrav jako nový idempotentní soubor
  (ADD COLUMN IF NOT EXISTS…), nespouštěj.

### Závěr
- Ukaž mi diff, commit terse zprávou + Co-Authored-By,
  push až po odsouhlasení.

Čím konkrétnější zadání, tím méně kol a méně credits. Když si nejsem jistá řešením — nejdřív probrat v chatu, prompt vyrobit až z hotového rozhodnutí.

Nejčastější vlastnosti v diffech

Jednořádkově — abych věděla, co schvaluji. DTP paralely v závorkách.

Vlastnost	Co dělá
`margin`	Vnější odsazení — prostor okolo prvku, mezi ním a sousedy
`padding`	Vnitřní odsazení — prostor mezi okrajem prvku a jeho obsahem (jako inset v textovém rámečku)
`display:flex`	Zapne řazení dětí do řádku/sloupce — základ layoutu karet a lišt
`gap`	Mezera mezi prvky ve flex/grid kontejneru (jako gutter mezi sloupci)
`border-radius`	Kulaté rohy — `999px` = pilulka
`box-shadow`	Stín kolem prvku; s `inset` stín dovnitř — trik na fialový pruh i autofill fix
`font-family / size / weight`	Písmo, velikost, řez (400 regular, 700 bold…)
`color` / `background`	Barva textu / barva pozadí — v appkách přes tokeny `var(--accent)`
`position:sticky`	Prvek „se přilepí" při scrollování (header, levá navigace)
`@media (max-width:…)`	Pravidla jen pro obrazovky do dané šířky — mobilní verze
`transform`	Posun/rotace/zvětšení prvku — po efektu vždy uklidit na `''`
`transition`	Plynulá animace změny (hover efekty) — trvání + easing

Nejčastější JS vzory v diffech

Jednořádkově — co ten kód dělá, když ho vidím ve schvalovaném diffu.

Vzor	Co dělá
`const` / `let`	Vytvoří „krabičku" na hodnotu. `const` = nemění se, `let` = může se měnit
`function nazev() {…}`	Pojmenovaný blok kódu — spustí se, až když ho někdo zavolá `nazev()`
`document.querySelector('.trida')`	Najde na stránce první prvek podle CSS selektoru — most mezi HTML a JS
`addEventListener('click', …)`	„Až se na tohle klikne, udělej tohle" — základ veškeré interaktivity
`if (…) {…} else {…}`	Rozhodování — když platí podmínka, udělej A, jinak B
`===` vs `=`	`===` porovnává („rovná se?"), `=` přiřazuje hodnotu — záměna je klasická chyba
`async` / `await`	„Počkej na výsledek, než jedeš dál" — vždycky u Supabase dotazů (data jedou po síti)
`try {…} catch (e) {…}`	„Zkus tohle, a když to spadne, neshoď celou stránku — udělej catch"
`classList.add / remove / toggle`	Přidá/odebere CSS třídu prvku — tak se v JS přepíná vzhled (aktivní tab, otevřená karta)
`forEach(item => {…})`	„Pro každou položku v seznamu udělej tohle" — smyčka přes úkoly, joby, řádky
`JSON.parse / stringify`	Převod dat mezi textem a objektem — text ↔ struktura, se kterou umí JS pracovat
`// komentář` a `/* … */`	Poznámky v kódu — prohlížeč je ignoruje, jsou jen pro lidi

V diffu nemusím rozumět celé logice — stačí poznat vzor („aha, přidává klikací akci na tlačítko") a ověřit, že to odpovídá zadání.

Jak číst chybovou hlášku v Console

Červený řádek v Console má vždy stejnou stavbu. Když ho umím přečíst, nemusím posílat screenshot — zkopíruju text a je to.

Uncaught TypeError: Cannot read properties of null (reading 'value')
    at ulozUkol (index.html:842)
│         │                                    │            │
│         │                                    │            └─ ŘÁDEK 842 — tam se to stalo
│         │                                    └─ ve funkci ulozUkol
│         └─ CO se pokazilo (čte .value z něčeho, co je null)
└─ TYP chyby

Hláška obsahuje	Co to znamená lidsky
`… of null` / `… of undefined`	Kód sahá na prvek, který na stránce nenašel — často překlep v názvu třídy/ID, nebo prvek ještě neexistuje
`… is not a function`	Volá se něco, co není funkce — překlep v názvu, nebo se nenačetl soubor (třeba supabase.js)
`Unexpected token` / `SyntaxError`	Překlep v samotném kódu — chybějící závorka, čárka, uvozovka. Stránka bývá celá bílá
`Failed to fetch` / `NetworkError`	Nepovedlo se spojení po síti — Supabase nedostupná, špatná URL, výpadek internetu
`401` / `403`	„Nemáš oprávnění" — vypršelá session, špatný klíč, nebo RLS policy blokuje dotaz
`404`	„Nenalezeno" — špatná cesta k souboru nebo URL (překlep, soubor není na FTP)
Žlutá hláška (warning)	Jen varování, nic nespadlo — většinou lze ignorovat, na rozdíl od červené

Postup vždy stejný: 1) Console (Cmd+Option+J) → 2) najít první červený řádek (další chyby bývají jen důsledek) → 3) zkopírovat celý text pravým tlačítkem → 4) vložit do promptu pro Claude i s větou, co jsem zrovna dělala. Text chyby je vždycky lepší než screenshot.

Mapa index.html — kde co hledat

Všechny appky my.mnx.cz mají stejnou stavbu jednoho HTML souboru. Když hledám ručně (CotEditor, Cmd+F), vím do které čtvrtiny koukat.

index.html
├── <head>
│   ├── meta, title, fonty, favicon
│   └── <style>        ← VŠECHNO CSS
│       ├── :root { --tokeny }   ← barvy a fonty na jednom místě
│       ├── styly sekcí (header, karty, tabulky…)
│       ├── @media print         ← vzhled pro tisk/PDF
│       └── @media (max-width)   ← mobilní verze
├── <body>
│   ├── login obrazovka
│   ├── header (brand, verze, odhlásit)
│   ├── obsah appky (karty, formuláře, seznamy)
│   └── <script>
│       ├── logika appky (JS)    ← chování, klikání, data
│       └── Supabase blok        ← přihlašování, NEsahat
│           (URL + anon key + auth funkce)
└── supabase.js  ← samostatný frozen soubor vedle

Měním barvu/vzhled → <style>, nejspíš rovnou :root tokeny.
Měním text/strukturu → tělo <body>, hledat Cmd+F podle viditelného textu.
Měním chování (co se stane po kliknutí) → <script> s logikou.
Supabase blok a supabase.js → nesahat, jen přes promptované zadání.

Klávesové zkratky

Zkratka	Co dělá
`Cmd+Shift+R`	Hard refresh — načte stránku bez cache (povinné po FTP nahrání)
`Cmd+Option+I`	Otevře DevTools (Safari i Chrome)
`Cmd+Option+J`	Chrome: otevře DevTools rovnou na záložce Console
`Cmd+F`	Hledání na stránce / v souboru (CotEditor, DevTools, prohlížeč)
`Cmd+Shift+N`	Anonymní okno (Chrome) — živá kontrola po nahrání bez cache a přihlášení
`Esc` ×2	Claude Code: rewind menu — vrátit poslední změny v kódu
Tab / ↑	Terminál: doplnění názvu / předchozí příkaz

Step-by-step: Supabase & GitHub

Konkrétní pořadí kroků pro úkony, které se opakují nejčastěji. Přibývat budou další taby, jak se objeví další opakující se nástroj/úkon.

Supabase — nová migrace nejčastější úkon

Migrace vždy piš jako nový idempotentní soubor — nikdy needituj ani nepřepisuj tu, která už byla spuštěná. Jinak by historie změn v databázi neseděla s tím, co je v databázi reálně nastavené.

1Vytvoř nový SQL soubor migrace — nikdy needituj ten, který už byl spuštěný. Popisný název, ne generický (add-po-number-jobcases.sql, ne migration2.sql).
2Piš idempotentně: ADD COLUMN IF NOT EXISTS, a před ADD CONSTRAINT vždy nejdřív DROP CONSTRAINT IF EXISTS. Migrace musí jít spustit i podruhé bez chyby.
3Pokud vzniká nová tabulka — zapni RLS a rovnou definuj policy v tom samém souboru. Tabulka bez definované policy nepustí k datům vůbec nikoho, ani tebe.
4Claude Code migraci nikdy nespouští sám — jen pojmenuje a připraví soubor. Spuštění vždy ručně v Supabase SQL Editoru.
5Po spuštění ověř výsledek v Table Editoru — sloupec/tabulka/constraint vypadá přesně tak, jak měl.
6Rychlý test RLS po každé nové/upravené policy — vyzkoušet přístup z odhlášeného stavu nebo jiného účtu, ne jen ze svého vlastního přihlášení. Jedině tak se ověří, že cizí data opravdu nejsou vidět.
7Pokud migrace zavádí nový secret (token, klíč) — patří do Edge Functions → Manage secrets, nikdy do kódu ani do gitu. Zapsat na bezpečné místo mimo appku (heslo manažer), potřeba je jen jednou.

Commit = kontrolní bod

Git je systém, který si pamatuje každou změnu v kódu — stejně jako se v DTP ukládá CTP-AR-v1.indd, CTP-AR-v2.indd. Každý commit = jeden checkpoint, jeden „snapshot" s datem a popisem, co se změnilo. Když se něco pokazí, jde se vrátit k libovolnému staršímu commitu — bezpečnostní síť pro kód.

Dvě místa, kde commit existuje: 1) lokálně na Macu — ve skryté složce .git uvnitř projektu (sem se commituje), 2) na GitHub serveru — online záloha (sem se pushuje).
Bezpečnostní řetězec: Mac (pracovní prostředí) → GitHub (push záloha) → externí disk (Time Machine, celý disk). I kdyby se rozbil Mac, kód je na GitHubu; i kdyby GitHub zanikl, kód je na Macu i na disku.
Git vs. Supabase: git verzuje kód (HTML/CSS/JS), Supabase ukládá data appky (joby, úkoly, uživatele). Změna CSS → git commit. Nový sloupec v tabulce → Supabase migrace, ne git.
Historie na GitHubu: sekce s commity pod sebou (každý s jednořádkovým popiskem) je vizuální podoba historie verzí — kdykoliv jde otevřít a vrátit se k libovolné z nich.

Tři místa, kde web žije

Kód appky existuje na třech různých místech, každé má jinou roli. Plést si je = nahrát změnu tam, kam nepatří.

Disk (Mac) — pracoviště. Složka web-my-mnx ve Finderu, uvnitř skrytá složka .git. Tohle je repo — tady se edituje, tady pracuje Claude Code, tady vzniká commit. Sem patří i soubory jen pro vývoj (např. CLAUDE.md), které se na web nikdy nenahrávají.
GitHub — online záloha repa. Push pošle kopii repa (včetně .git historie) na GitHub. Záloha disku mimo Mac.
FTP web (Active24) — živý web. Přes Monsta FTP se nahrávají jen hotové soubory (HTML), aby appka reálně běžela na my.mnx.cz. Sem se nikdy nenahrává .git, CLAUDE.md ani rozpracovaný stav — jen commitnutý, ověřený soubor.

Rozdíl: commit žije na 2 místech (Mac + GitHub), ale web na 3 (Mac + GitHub + FTP). GitHub není živý web — push kód zazálohuje, ale na my.mnx.cz se nic neprojeví, dokud se soubor nenahraje přes FTP.

⚠️ Disk a web musí zůstat v souladu

Nejzákeřnější způsob, jak si rozbít projekt: nechat rozejít disk (repo) a živý web. Git je zdroj pravdy jen tehdy, když v něm je opravdu to, co běží na webu. Dva směry, oba nebezpečné:

Směr 1 — nikdy nenahrávat na FTP bez commitu. Když nahraješ na FTP soubor, který není zacommitovaný a pushnutý, běží na webu verze, která není nikde v gitu. Když se pak něco pokazí, není se kam vrátit — a příště přepíšeš živou verzi starším souborem z disku, protože disk „neví", že web je jinde. Pořadí je vždy: disk → commit → push → teprve pak FTP.

Směr 2 — nikdy nestahovat z FTP a přepisovat jím disk. Když si stáhneš soubor z FTP (třeba „ten poslední, co běží") a nahradíš jím verzi na disku, přijdeš o git historii toho souboru a zaneseš do repa verzi, kterou git nikdy neviděl vznikat. Když si nejsi jistá, co je aktuální, zdroj pravdy je git (git log, git status), ne to, co náhodou leží na FTP.

Jednou větou: soubor putuje z disku na web, nikdy ne opačně. FTP je výstup, ne záloha. Kdykoli je pochybnost „která verze je ta pravá", odpověď hledej v gitu.

GitHub / Claude Code — commit & push

Standardní kolo od promptu po živou appku.

1Zadej Claude Code kompletní, samostatný prompt (.md) — víc souvisejících změn v jednom kole, ne drobné kroky tam-a-zpět.
2Než cokoliv schválíš, projdi diff — co přesně se v souboru mění, řádek po řádku.
3Schvaluj git příkazy jednotlivě — Yes, ne „always allow", i za cenu pár kliknutí navíc.
4Po commitu a pushi ověř na GitHubu, že push skutečně proběhl (commit se zobrazuje v historii repozitáře).
5Teprve po potvrzeném pushi nahrávej přes Monsta FTP — nikdy rovnou z rozpracovaného stavu na disku.
6Po nahrání projeď pre-FTP checklist výše a udělej hard refresh, než zavřeš laptop.
7Amend commit message jen dokud není pushnuto — po pushi už zprávu ani obsah commitu neměnit. Amend mění historii; lokálně je bezpečný, na GitHubu už ne. I amend schvalovat jednotlivě (Yes) a zkontrolovat novou zprávu.

Pre-FTP / pre-deploy checklist

Projet pokaždé před nahráním čehokoliv vizuálního přes Monsta FTP — bez ohledu na to, jak malá změna to byla. Cíl: zachytit vedlejší efekty mimo aktuální fokus, ne jen to, co se právě měnilo.

1Nejužší mobil — DevTools na ~375px (iPhone SE), ne jen vlastní telefon. „Vypadá dobře na mém iPhonu" ≠ „vypadá dobře na nejmenším podporovaném zařízení."
2Print / Save as PDF — jednou proklikat, pokud se sáhlo na cokoliv vizuálního (i nepřímo — UI změna může zpětně ovlivnit i print CSS).
3Autofill bug — rychlý pohled na pole typu text, email, tel, date, number. Známý recidivující bug napříč appkami — lepší mít v návyku, než čekat, až si ho všimnu náhodou.
4Diff odpovídá nahrávanému souboru — ověřit, že se přes FTP nahrává skutečně ten commitnutý soubor, ne starší necommitnutá verze.
5Hard refresh (Cmd+Shift+R) + živá kontrola po nahrání, než se zavře laptop — ne „nahrála jsem, asi to bude OK."

DevTools — jak otevřít a k čemu slouží

Sada nástrojů zabudovaná v prohlížeči na počítači, kterou se ověřuje, jak stránka vypadá na různě velkých obrazovkách — bez nutnosti pořád nahrávat na FTP a kontrolovat na telefonu.

Safari — Nastavení → Pokročilé → zaškrtnout „Zobrazit nabídku Vývoj v panelu nabídek". Pak Vývoj → Zobrazit editor webů (nebo Cmd+Option+I). V panelu ikonka pro responzivní režim přepne na simulaci mobilní šířky.
Chrome — pravým tlačítkem → Prozkoumat (nebo Cmd+Option+I). Ikonka telefonu/tabletu nahoře (Toggle device toolbar). V dropdownu zvolit zařízení nebo ručně nastavit šířku na 375px — bod 1 z Pre-FTP checklistu.
Otevřít stránku, přepnout na 375px a hned vidět, jestli něco přetéká nebo se řeže — bez nahrávání na FTP nebo screenshotů z telefonu.
Pravým tlačítkem na konkrétní prvek → Prozkoumat, hned vidíš, které CSS pravidlo mu dělá danou šířku/chování.

Pozn.: Náhledy souborů otevřené přímo v appce Claude (poznáš podle ikon ✕ a „..." místo Safari lišty) nemusí responzivitu/media queries vykreslovat spolehlivě. Pro reálné ověření mobilní verze je potřeba buď skutečná URL v Safari (přes „Publish" v menu preview), nebo DevTools na počítači.

SOS — když se něco pokazí

Rychlá první pomoc podle příznaku. Zásada číslo jedna: nic dalšího neměnit, dokud nevíš, co se stalo — dvě změny naráz se ladí mnohem hůř než jedna.

Příznak	Co udělat (v tomto pořadí)
Změna se na webu neprojevila	1) Hard refresh `Cmd+Shift+R` — nejčastější příčina je cache. 2) Ověřit v Monsta FTP, že soubor je opravdu nahraný (datum/velikost). 3) Zkontrolovat, jestli se nenahrál do špatné složky.
Claude Code udělal změnu, kterou nechci	1) `Esc` ×2 → „Rewind code only" — vrátí kód, konverzace zůstane. 2) Pokud už je commitnuto, požádat Claude Code o revert commitu — a projít diff toho revertu stejně pečlivě jako každý jiný.
Appka nepustí k datům / prázdný seznam po přihlášení	Skoro vždy RLS. 1) Zkontrolovat, že tabulka má policy (ne jen zapnuté RLS). 2) Ověřit, že policy počítá s přihlášeným uživatelem (`auth.uid()`). 3) Podívat se do konzole prohlížeče (Cmd+Option+J) na chybové hlášky.
Migrace spadla s chybou	1) Přečíst chybu celou — Supabase říká přesně co a kde. 2) Nejčastější příčiny: constraint už existuje (chybí `DROP ... IF EXISTS`), překlep v názvu tabulky/sloupce. 3) Opravit a spustit znovu — proto se migrace píšou idempotentně.
Formulářová pole mají divné barvy/pozadí	Chrome autofill bug — známý recidivista. Fix vyžaduje `box-shadow inset` trik + `-webkit-text-fill-color` a musí pokrýt všechny `input[type]` varianty. Detail v CSS kterékoli hotové appky.
Nahrála jsem přes FTP špatnou verzi	Klid — správná verze je v gitu. 1) V projektu ověřit přes `git status` / diff, který soubor je ten správný commitnutý. 2) Nahrát znovu ten správný. 3) Hard refresh a živá kontrola.
Nevím, v jakém stavu jsem skončila minule	1) `claude -c` obnoví poslední session i s kontextem. 2) Recap na konci minulé session — tam bývá co je rozdělané. 3) `git log` ukáže poslední commity s popisky — proto se píšou pořádně.
Stránka je úplně bílá / prázdná	Skoro vždy JS chyba, která zastavila celý skript. 1) Otevřít Console (`Cmd+Option+J`) — první červený řádek říká co a na kterém řádku. 2) Zkopírovat chybu celou do promptu pro Claude. 3) Častá příčina: překlep v JS nebo nenačtený `supabase.js`.
Supabase mě odhlásilo / nechce přihlásit	1) Zkusit přihlášení znovu — session občas vyprší, to je normální. 2) Zkontrolovat Console, jestli se načetl `supabase.js`. 3) Pokud nejde dlouhodobě: v Supabase dashboardu ověřit, že projekt běží (free-tier se po neaktivitě pozastavuje).
Monsta FTP se nepřipojí / nenahrává	1) Zkusit obnovit stránku Monsta FTP a přihlásit znovu přes admin.active24.cz. 2) Zkontrolovat připojení k internetu. 3) Pokud trvá — počkat pár minut (výpadek hostingu) a zkusit znovu; soubor mezitím nikam nezmizí, je v gitu.

Když nic z tabulky nesedí: neexperimentovat naslepo. Popsat Claude (chat nebo Code) přesně co se stalo, co bylo poslední, co fungovalo — a chybovou hlášku vložit celou, ne převyprávěnou.

Základní výbava — bez čeho se neobejdeš

Minimální sada návyků a nástrojů pro začátek. Nic z toho nevyžaduje instalaci — všechno už je v Macu nebo v prohlížeči.

1Konzole prohlížeče (Console) — když appka „nefunguje a nevím proč", první pohled patří sem. V DevTools záložka Console — červené řádky říkají, co přesně se rozbilo (nenačtený supabase.js, JS chyba, špatná cesta k souboru). Text chyby jde zkopírovat rovnou do promptu pro Claude.
2Lokální náhled bez FTP — HTML soubor jde otevřít rovnou v Safari na počítači (dvojklik na soubor, nebo přetáhnout do okna prohlížeče). Zachytí většinu vizuálních chyb ještě před nahráním. Pozor: Supabase auth v lokálním náhledu nemusí fungovat — vizuál ale ano.
3Git příkazy jen na čtení — git status (co je změněné a necommitnuté), git log --oneline (historie commitů v jednom řádku), git diff (co přesně se změnilo). Nic nemění, jen ukazují stav — bezpečné kdykoliv, doplněk k tabulce bezpečných příkazů níže.
4Záloha celého disku — git chrání kód, ale ne zbytek (obrázky, dokumenty, FTP konfiguraci). Time Machine na externí disk, ideálně 1× týdně — stejný rytmus jako záloha iCloud struktury ve folder systému.
5Jedna změna = jeden commit — necommitovat půl dne práce najednou. Když se něco pokazí, jde vrátit jen ta jedna věc. Popisek commitu píše Claude Code — stačí kontrolovat, že odpovídá tomu, co se fakt dělalo.

Appky na my.mnx.cz

Přehled projektů v ekosystému — co dělá a v jakém je stavu.

Appka	Co dělá	Stav
Frootkaces	Osobní denní plánovač úkolů — kategorie, zvýrazňování, export do kalendáře, archiv	Hotovo, live
Jobcases	Sledování freelance zakázek — karty s klientem, stavem, termíny, cenou, kontaktem	Live, ladí se
FaktuCases	Generátor faktur, cenových nabídek a proforma faktur	V plánování
RutinaCases	Tato stránka — postupy, checklisty, taháky a referenční tabulky	Live

Technické pojmy, které se v této rutině vrací nejčastěji.

Badge: Malá „pilulka" s krátkým textem (např. MNX, DESIGN, 2026001) — typicky pro rychlé vizuální štítkování.
Box-shadow vs. border: Dva různé způsoby, jak v CSS nakreslit hranu/stín kolem prvku — pokud si spolu „šlápnou na nohu", řešením bývá nahradit border box-shadowem.
Chevron: Šipka (typicky ˅ / ˄) značící, že se dá něco rozbalit/sbalit kliknutím.
CSS proměnná / token: Pojmenovaná barva/hodnota (např. --accent, --ink) definovaná na jednom místě a použitá na mnoha místech v appce — při změně brandové barvy se nemusí přepisovat všude ručně.
Claude Code: Nástroj v terminálu, kterému se zadávají prompty a on sám edituje soubory na disku, spouští příkazy a dělá git commity — na rozdíl od chatu má přímý přístup k souborům.
Constraint (databáze): Pravidlo v databázi, které hlídá platnost dat ve sloupci — třeba že hodnota nesmí být prázdná nebo musí být unikátní. Než se constraint znovu přidá, je potřeba starý nejdřív smazat (DROP CONSTRAINT IF EXISTS), jinak databáze nahlásí, že už tam je.
FTP / Monsta FTP: Způsob, jak se soubor appky fyzicky dostane z počítače na webhosting (Active24). Bez nahrání přes FTP se změna na webu neprojeví, i kdyby byla hotová a commitnutá v gitu.
Git — commit / push / diff: Commit = uložit aktuální stav jako checkpoint s popiskem. Push = poslat checkpointy na GitHub. Diff = přehled, co přesně se v souboru změnilo, než se to potvrdí.
Glass efekt (glassmorphism): Vizuální styl karet appky: poloprůhledné pozadí s blur a jemnou světlou hranou. Odtud název .glass třídy v CSS.
Hero (prvek/text): Nejvýraznější, opticky nejdůležitější prvek dané sekce — u job karty je to název zakázky, proto je největší a nejtučnější.
Idempotentní: Vlastnost skriptu/příkazu, který jde spustit vícekrát za sebou a pokaždé skončí stejným výsledkem, aniž by něco pokazil. Příklad: ADD COLUMN IF NOT EXISTS — pokud sloupec už existuje, nic se nestane, appka nespadne na chybě. Proto se Supabase migrace píšou vždy idempotentně: kdyby se omylem spustily podruhé, nic se nerozbije.
@media print: Samostatná sada CSS pravidel použitá jen při tisku nebo Print → Save as PDF. Appka pak vypadá jinak než na obrazovce (světlé pozadí místo tmavého).
Migrace: Soubor s SQL příkazy, který mění strukturu databáze — přidá sloupec, tabulku, pravidlo apod. Každá změna struktury = nový soubor migrace; ten už spuštěný se needituje, jinak historie změn v databázi neodpovídá tomu, co je v ní reálně nastavené.
RLS (Row Level Security): Pravidlo v databázi, které hlídá, že vidíš jen svá vlastní data, ne cizí. Musí být zapnuté a mít definované pravidlo, jinak appka nikoho nepustí k datům vůbec.
Supabase: Služba, která appkám dodává přihlašování (Auth) a databázi (PostgreSQL). Zjednodušeně: místo, kde appka ukládá data, aby byla stejná na mobilu i na počítači.
Viewport / mobile-first: Viewport je viditelná plocha obrazovky. „Mobile-first" znamená, že appka se navrhuje primárně pro úzkou mobilní šířku a teprve pak se řeší větší obrazovky.

Rozměry formátů

Referenční tabulka rozměrů — web, sociální sítě, tisk, reklamní formáty. Doplňovat průběžně o další rozměry, které se opakovaně používají.

Web — breakpointy

Prvek	Rozměr (š)	Použití
Nejužší mobil	`375px`	iPhone SE — povinný test v DevTools před každým FTP nahráním
Tablet	`768px`	Standardní tablet breakpoint (portrait)
Desktop	`1440px`	Běžná pracovní šířka layoutu
Desktop (velký)	`1920px`	Full HD, web header / hero sekce

LinkedIn

Prvek	Rozměr (px)	Poměr	Použití
Feed post / thumbnail	`1080×1080`	1:1	Statický post, web thumbnail
Carousel slide	`1080×1350`	4:5	Jeden slide v carousel postu
Banner (profil)	`1584×396`	4:1	Banner na profilu LinkedIn
Web header / cover	`1920×1080`	16:9	Nejčastější — banner, web header, cover
Link preview obrázek	`1200×627`	~1.91:1	Náhled odkazu při sdílení (OG image)

Facebook

Prvek	Rozměr (px)	Poměr	Použití
Feed post (čtverec)	`1080×1080`	1:1	Standardní feed post
Feed post (na výšku)	`1080×1350`	4:5	Feed post s větším záběrem
Sdílený odkaz / link	`1200×630`	~1.91:1	Náhled u sdíleného odkazu
Titulní foto (cover)	`820×312`	~2.63:1	Cover foto stránky (desktop zobrazení)

Instagram

Prvek	Rozměr (px)	Poměr	Použití
Feed post (čtverec)	`1080×1080`	1:1	Standardní feed post
Feed post (na výšku)	`1080×1350`	4:5	Feed post s větším záběrem — doporučený formát
Stories / Reels	`1080×1920`	9:16	Celoobrazovkový formát na výšku
Profilová fotka	`320×320`	1:1	Zobrazuje se kruhově, nahrávat čtvercové

Reklamní formáty (IAB)

Prvek	Rozměr (px)	Poměr	Použití
Medium Rectangle	`300×250`	6:5	Standardní IAB formát, nejčastější display reklama
Leaderboard	`728×90`	~8.1:1	Standardní IAB formát, horizontální banner
Vlastní formát	`1090×600`	~1.8:1	Zavedený vlastní formát dle naming-system

Tisk (mm)

Prvek	Rozměr (mm)	Poměr	Použití
Vizitka	`85×55`	~1.55:1	Standardní EU formát vizitky
A4	`210×297`	~1:1.41	Dokumenty, výroční zprávy, tiskové PDF

Tisk = CMYK, 300 dpi, spadávka + ořezové značky (suffix -to-print). Web/online = RGB, 72–96 dpi (suffix -online) — viz naming-system.md, sekce 3.

Systémové dokumenty

Naming systém, shortcodes a folder systém — v jednom místě, pohromadě s výstupními rozměry a step-by-step postupy výše.

Základní pravidla

Bez diakritiky, bez mezer — pomlčka - místo mezery
Nikdy nepoužívat slova Final, OK, Approved, Hotovo v názvu
Co je finální = leží ve složce 00-Final-Output — název to řešit nemusí
Datum formát YYMMDD (např. 260615) — pouze u sdílených souborů

Základní struktura názvu: [Klient]-[Typ]-[Popis]-[fáze]-v[číslo].[přípona]

Rychlý přehled — co kam

Situace	Kde leží	Název obsahuje
Pracuji na projektu	`03-Workups/`	v1, v2…
Posílám klientovi náhled	`04-Export/Rounds/`	v1, v2…
Posílám do tisku	`04-Export/Rounds/`	to-print + verze
Posílám online výstup	`04-Export/Rounds/`	online + verze
Sdílím přes OneDrive	`OneDrive/SHARED/`	verze + datum YYMMDD
Projekt je uzavřen	`04-Export/00-Final-Output/` 🔴	poslední verze
Portfolio ukázka	`02-PORTFOLIO/03-Export/`	rozměr

Admin — číselné řady

Tři oddělené řady — INV, EST a JOB — každá začíná každý rok znovu od 001. Čísla JOB přiděluje appka Jobcases.

Typ	Formát	Příklad
Faktura (INV)	`[RRRR][PPP]`	2026001
Cost Estimate (EST)	`[RRRR][PPP]`	2026001
Zakázka (JOB)	`[RRRR][PPP]`	2026001

Co nikdy nedělat

Přepisovat původní název fotografie od klienta — přidat naming za něj: original-name_CTP-AR-v1.jpg
Mezery v názvu (Annual Report 2025.pdf)
Přepisovat předchozí verzi — vždy uložit jako novou
Posílat klientovi soubor bez čísla verze
Datum uprostřed názvu (CTP-260615-AR.pdf)
Plné názvy místo shortcodes (AnnualReport místo AR)

Workflow — fáze práce

brief → design → workups → approved → to-print / online

Kód	Fáze	Popis
`brief`	1	Fáze zadání
`design`	2	Fáze návrhu
`workups`	3	Fáze rozpracování
`approved`	4	Odsouhlaseno klientem
`to-print`	5a	Tiskový výstup — CMYK, ořezy, přesahy
`online`	5b	Online výstup — RGB, screen/web/LI

Typy práce — dokumenty, formáty, nástroje

Kód	Typ práce
`AR`	Annual Report / Výroční zpráva
`MAG`	Magazine / Časopis (nebo název magazínu, např. GRID)
`BR`	Branding / Rebranding
`MAN`	Brand Guide / Manuál
`BC`	Business Card / Vizitka
`LOGO`	Logo
`PKG`	Packaging / Obal
`APP`	Apparel / Oblečení
`GOODS`	Merchandise / Goods
`AD`	Inzerát / Advertisement
`PR`	Press Release
`LI`	LinkedIn
`WEB`	Web / Online
`MOCK`	Mockup — maketa produktu i PDF implementace
`PPT`	PowerPoint šablona
`TMPL`	Template / Šablona
`RTU`	Retuše

Admin dokumenty

Kód	Typ dokumentu	Číselná řada
`INV`	Faktura	vlastní řada
`EST`	Cost Estimate / Cenová nabídka	vlastní řada
`PRF`	Proforma faktura	přebírá číslo budoucí faktury
`CNT`	Smlouva / Contract	—
`TAX`	Daňové podklady	—
`INS`	Pojištění / Insurance	—
`JOB`	Zakázka (evidence v Jobcases)	vlastní řada

Klienti

Pořadí je vlastní (ne abecední) — stejné pořadí používá rozbalovací nabídka v Jobcases.

#	Kód	Klient
1	`MNX`	Monika / mnx.cz — vlastní brand
2	`CSDZ`	Česká společnost pro duševní zdraví
3	`LAB`	LABRIX
4	`CTP`	CTP Invest

Neaktivní klienti (archiv) — kódy zůstávají kvůli čitelnosti starých souborů, v Jobcases se nenabízí.

Kód	Klient
`CS`	Česká spořitelna
`DT`	Deloitte
`GEN`	Česká pojišťovna / Generali
`KAU`	Kaufland
`PIL`	Pilsner Urquell
`PM`	Philip Morris
`TMO`	T-Mobile
`UNI`	Unilever / KNORR
`VOD`	Vodafone

⚠️ Pravidlo — fotografie od klienta

NIKDY nepřepisovat originální název fotografie od klienta. Původní název zachovat, vlastní naming přidat za něj: original-name_CTP-AR-v1.jpg, IMG_4521_MNX-BR-v1.jpg

Hlavní struktura — iCloud

iCloud/
├── _Older/                ← vše před tímto systémem
├── 01-Klienti/
├── 02-Portfolio/
├── 03-Kurzy/
├── 04-Brand/
├── 05-Admin/
└── 06-Privates/

01-Klienti

Každý klient = vlastní složka, uvnitř vždy stejná struktura. Nový klient = vždy kopírovat _Sablona-Klient, přejmenovat, nesahat jinak.

01-Klienti/
├── _Sablona-Klient/       ← kopírovat pro každého nového klienta
│   ├── 00-Admin/          ← smlouva, nabídka, faktury
│   ├── 01-Brief/
│   ├── 02-Sources/        ← co dodal klient
│   ├── 03-Workups/        ← rozpracované soubory
│   └── 04-Export/
│       ├── 00-Final-Output/  ← 🔴
│       └── Rounds/
└── CTP-Invest/  (stejná struktura)

02-Portfolio

02-Portfolio/
├── 00-Admin/
├── 01-Sources/    ← Annual-Reports, Magazines, Rebranding, Goods...
├── 02-Workups/    ← Mockups, Images
├── 03-Export/
│   ├── 00-Final-Output/  ← 🔴
│   └── Rounds/
├── Older/
└── 04-Texts/      ← bio-CZ.md, bio-EN.md, awards.md

04-Brand

Vlastní brand = ty jsi klient. Každý brand projekt má stejnou strukturu jako klientská šablona.

04-Brand/
├── 00-Admin/       ← brand guidelines, rozhodnutí
├── Logo/
├── Print/          ← vizitky, hlavičkový papír
├── PowerPoint-Templates/
├── Web-mnx/        ← projekt webu mnx.cz
├── Vizitka-Web/     ← hotový web vizitky
└── Social/         ← LI bannery, profilovka, posty

05-Admin

05-Admin/
├── Invoices/2026/
├── Cost-Estimates/
├── Contracts/
├── Tax/2026/
└── Insurance/

06-Privates & OneDrive

06-Privates/            ← bez podsložek, prostý archiv
OneDrive/Shared/
├── [Client-Name]/
└── [Client-Name]/       ← jen sdílení s klienty

Pravidla systému

Čísla na začátku složek = pořadí v Finderu (00, 01, 02…)
00-Admin vždy jako první složka v každém projektu
Názvy: první písmeno velké, zbytek malé — bez diakritiky, bez mezer
_Sablona s podtržítkem = vždy nahoře v abecedním řazení
Older = nesahat, archiv
00-Final-Output vždy červený tag v Finderu
Nový projekt = vždy kopírovat šablonu, nikdy neprovizovat

Barvy

Hex	Token	Použití
`#7B2FFF`	`--accent`	Brandová fialová — accent, badge, cursor dot, aktivní stavy
`#0d0d0f`	`--ink` / dark bg	Text na světlém pozadí; tmavé pozadí mnx.cz landing page
`#e6e6e6`	`--bg`	Pozadí této stránky — cca 10 % K z CMYK
`#f1e8ff`	`--accent-tint`	Světlý fialový nádech — code pilulky, zvýrazněné boxy

Typografie

Font	Použití
Jost Black 900	Display font mnx.cz landing page (MONIX→MNX animace, watermark)
Systémový monospace	Labely, nadpisy a kódové prvky napříč appkami my.mnx.cz
JetBrains Mono + Inter	Tato stránka — mono na nadpisy/kód, Inter na běžný text

Při zadávání promptů do Claude Code stačí odkázat sem: „brandová fialová #7B2FFF, tmavé pozadí #0d0d0f" — přesné hodnoty jsou vždy tady, není třeba je hledat v kódu appek.

Legal checklist — veřejný web

Týká se mnx.cz i dalšího veřejně přístupného webu. Interní appky na my.mnx.cz (Frootkaces, Jobcases…) jsou za přihlášením — legal povinnosti se na ně nevztahují.

Povinné údaje pro OSVČ (§ 435 obč. zákoníku)

Jméno a příjmení (přesně jak je v živnostenském rejstříku — nestačí jen značka MNX)
Adresa místa podnikání / sídlo
IČO
Údaj o zápisu do živnostenského rejstříku
DIČ — na webu není povinné, ale je zvykem ho uvést

GDPR — pokud web sbírá jakákoliv data

Cookies lišta s možností volby (souhlas / odmítnutí)
Stránka „Zásady zpracování osobních údajů" s uvedeným správcem dat
Upozornění před každým formulářem s odkazem na zásady

Při prodeji služeb / kurzů (fáze 2+)

Obchodní podmínky
Reklamační řád (lhůta 30 dní)
Odkaz na mimosoudní řešení sporů — ČOI
Možnost odstoupení od smlouvy do 14 dní

Pokuty: živnostenský úřad nebo ČOI může uložit pokutu až 100 000 Kč za chybějící identifikační údaje; za GDPR porušení ÚOOÚ až miliony. Pravděpodobnost kontroly malého prezentačního webu je nízká, ale oprava zabere 20 minut — nestojí to za riziko.

Toto není právní poradenství — při pochybnostech ověřit u právníka nebo na webu ÚOOÚ (uoou.cz) a ČOI (coi.cz).