Plán: základní kostra aplikace (deploy → směr MVP1)

Stav dokumentu: Historický plán řezů A–D — většina kroků je v repu už splněná; checkboxy níže slouží k ověření, ne jako aktivní backlog.

Účel: stanovit technické řezy, které jdou dodat po sobě: nejdřív nejmenší deployovatelný skelet, pak kostra obrazovky podle MVP1, a nakonec plnění daty a funkcemi z 12-mvp-1.md.

Souvislosti: produkt MVP1 — 12-mvp-1.md; technické fáze 1–8 — 24-engineering-roadmap.md; routy — 23-api-and-routes.md; entity — 22-data-model.md.

Princip: dva „cíle“ vedle sebe

Cíl	Co znamená
Deploy hned	Projekt v repu, který po pushi na `main` naběhne na Cloudflare a otevře se na doméně / default URL — bez nutnosti mít hotové celé MVP1.
Směr MVP1	Routy a rozložení UI odpovídají MVP1 (`/` volitelně, `/byliny`, `/byliny/:slug`), aby se později jen doplňovala data a bloky z 12-mvp-1.md.

Doporučení: nejdřív řez A, pak řez B; řez C až poté, co je stabilní pipeline a loader/action model.

Řez A — Minimální skelet (menší než MVP1)

Výstup: funkční produkční deploy, jedna úvodní stránka (placeholder), žádná závislost na D1/R2/KV.

Scaffold — React Router v7 aplikace určená pro Cloudflare Workers (oficiální šablona / dokumentace Cloudflare + RR7), TypeScript.
Styling — Tailwind; shadcn/ui lze přidat hned nebo v řezu B (aby se první deploy nekomplikoval).
Wrangler — wrangler.toml (nebo ekvivalent), lokálně npm run build + npx wrangler deploy bez chyb.
Git → Cloudflare — napojení repozitáře podle 20-tech-stack.md; ověřit deploy po mergi na main.
Doména — po úspěchu přiřadit soulofherbs.com k projektu v dashboardu.

Akceptace řezu A: uživatel otevře nasazený web a vidí jednoduchou homepage (název projektu, krátký text).

Řez B — Kostra MVP1 bez kompletních dat

Výstup: stejný deploy jako A, ale už struktura katalogu podle IA MVP1 (12-mvp-1.md §3): routy pro seznam a detail.

Routy — /byliny (seznam), /byliny/:slug (detail); základní layout (hlavička / patička volitelně).
Data pro první iteraci — D1 s migracemi a seed (viz strategie v dokumentu; statický JSON už není potřeba).
Detail jako „šablona“ — sekce podle MVP1 (identifikace, výskyt, sběr, …).
Filtry — základ na /byliny dle 12-mvp-1.md §1.10 (admin zvlášť).

Akceptace řezu B: z /byliny jde přejít na konkrétní detail podle slug; SSR nebo hybrid podle zvoleného RR7 režimu funguje na produkci.

Řez C — Plnění minimem MVP1 (datově)

Postupně doplnit podle 12-mvp-1.md §1 a §2:

D1 migrace — tabulky odpovídající entitám MVP1 minimum (bylina, části, lokality zjednodušeně, období sběru, způsoby zpracování, spirituální použití, vědecká tvrzení, zdroje, obrázky, bezpečnostní upozornění).
Loadery — čtení z D1 místo stubů; referenční byliny ve seedu.
Obrázky — externí URL a/nebo R2 (r2_key u ukázky); plný upload až s adminem.
Základní vyhledávání podle názvu na /byliny (MVP1 §1.1) — dotaz nad D1.

Akceptace řezu C: viz „Akceptace“ v 12-mvp-1.md §5 v omezeném rozsahu (např. 10–20 bylin ve seedu).

Řez D — Po kostře (zůstává v MVP1 / další engineering fáze)

Není součástí „kostry“, ale pořadí je jasné:

Filtrace (12-mvp-1.md §1.10) → overlap s 24-engineering-roadmap.md fáze 4 (základ hotový).
Admin + Access + R2 upload → fáze 5.
SEO/metadata → fáze 6 (částečně — sitemap/robots hotové).

Shrnutí: čím začít teď

Dokončit řez A (scaffold + deploy + doména) — odškrtne položky v README.md sekci TODO (infra).
Hned potom řez B — aby URL /byliny a /byliny/:slug žily na produkci a šlo iterovat obsah a schéma bez přepisování architektury.
řez C navázat na schválený / implementovaný výřez 22-data-model.md.

Tím máte menší než MVP1 jen v řezu A–B (deploy + prázdná šablona); řez C je už cesta k první použitelné verzi podle MVP1.