Skip to content

Obsahová pravidla

Konvence checkboxů (stejný styl jako v 12-katalog-a-karta-byliny.md — GitHub Markdown task list):

  • §1–§7: u každé položky je - [ ] — checklist normy (co má obsah splňovat při kontrole byliny / záznamu). Ve zdrojáku jsou výchozí neodškrtnuté; při práci můžeš v PR nebo lokálně odškrtávat.
  • §8: - [ ] / - [x] — implementace ve webu a v modelu (kód hotový vs. zbývá).

1. Oddělení typů tvrzení

V aplikaci musí být jasně oddělené:

  • vědecké tvrzení
  • tradiční použití
  • spirituální použití
  • historická zmínka
  • lidová pověra
  • osobní / komunitní zkušenost

2. Spirituální a tradiční část

Tato část může obsahovat:

  • rituály
  • symbolika
  • lidové použití
  • staré herbáře
  • mytologie
  • pověry
  • „babské“ rady
  • spojení s emocemi
  • psychosomatické interpretace

Nesmí být prezentována jako vědecky ověřená medicínská informace.

3. Vědecká část

Každé vědecké tvrzení musí obsahovat:

  • shrnutí tvrzení
  • typ studie
  • síla důkazu
  • zdroj
  • URL nebo DOI
  • rok publikace
  • omezení studie

(V datech nemusí být všechna pole vždy vyplněná; na kartě se zobrazují tam, kde existují.)

4. Typy vědeckých důkazů

Doporučený slovníček pro klasifikaci (cíl pro editory / budoucí validaci):

  • in vitro
  • studie na zvířatech
  • observační studie
  • klinická studie
  • randomizovaná kontrolovaná studie
  • systematické review
  • meta-analýza
  • farmakologický přehled
  • institucionální monografie
  • nedostatek důkazů

5. Bezpečnost

U bylin evidovat (jako témata / upozornění, podle datového modelu):

  • toxicitu
  • kontraindikace
  • těhotenství
  • kojení
  • děti
  • alergie
  • interakce s léky
  • fotosenzitivitu
  • riziko dávkování
  • riziko záměny
  • riziko špatného zpracování

6. Doporučené bezpečnostní úrovně

info
caution
dangerous
avoid_home_use
  • u veřejných záznamů preferovat jen tyto hodnoty (herbs.safety_level) a sjednotit ostatní slugy v datech

(V seed datech se může objevit i jiný slug — sjednocení s tímto výčtem je otázka obsahu a §8.)

7. Obrázky

Každý obrázek by měl mít:

  • typ
  • alt text
  • popisek
  • autor
  • licence
  • zdroj
  • vazba na bylinu
  • pořadí

Doporučené hodnoty typu obrázku (image_type):

  • celá rostlina
  • detail listu
  • detail květu
  • plod / semeno
  • kořen
  • stanoviště
  • srovnání
  • sušená bylina
  • zpracování
  • botanická ilustrace
  • spirituální / symbolický obrázek

8. Stav vůči aplikaci a co lze doplnit

Tato sekce sleduje implementaci (kód a D1). [x] neznamená, že každý řádek v databázi má všechna pole vyplněná — jen že aplikace / model to podporují tam, kde jsou data.

Podrobnější mapování polí viz 22-data-model.md a karta byliny (app/routes/byliny.$slug.tsx).

8.1. §1 — Oddělení typů tvrzení

Hotovo v hrubých rysech: vědecké záznamy jsou v samostatné sekci oproti spirituálním/tradičním; u spirituálních je upozornění, že nejde o léčebná doporučení.

Implementováno: sloupec claim_nature + slovníček v app/lib/spiritual-content-labels.ts (migrace 0010_spiritual_nature_facets.sql). Doplňkově zůstávají volné texty category a claim_strength u starších záznamů.

Ne úplně totéž co §1: v UI není šest samostatných „kanálů“ pro každý typ z §1 — jedna sekce + pole claim_nature (pět slugů) a samostatná vědecká sekce.

  • Oddělené sekce v UI (věda vs tradice) a disclaimer u spirituálního obsahu
  • Řízené hodnoty / slovníček odpovídající §1 (claim_nature, volitelně legacy claim_strength)

8.2. §2 — Spirituální a tradiční část

Hotovo: sekce může nést různé typy obsahu; disclaimer v UI; štítky podtypů z facets (JSON) a popisky ve spiritual-content-labels.ts.

Zbývá (rozšíření): filtrování v katalogu podle těchto štítků — viz tasks/done/stitky-tvrzeni-a-typy-dukazu.md (rozcestník domén) a tasks/filtry-katalogu-bylin.md §3.

8.3. §3 — Vědecká část

Hotovo v UI: shrnutí, typ studie, síla důkazu, rok, omezení, odkaz nebo název zdroje (je-li source_url); dále DOI (odkaz na resolver), autoři, časopis, volitelně účinná látka a poznámka k dávce — vše jen pokud je v DB vyplněné. Dávka výslovně jen informativně.

Mezera vůči normě §3: u konkrétních záznamů nemusí být vždy vyplněný zdroj ani URL/DOI (záleží na obsahu).

  • Základní pole tvrzení v UI (shrnutí, typ, síla, rok, omezení, zdroj/URL)
  • DOI, autoři, časopis, volitelně dávka / účinná látka v UI, pokud jsou v DB
  • Veřejná legenda významu evidence_level a study_type — rozbalovací blok v sekci „Vědecké poznatky“ (app/components/herb-detail-legends.tsx, slovníček v claim-labels.ts).

8.4. §4 — Typy vědeckých důkazů

Mezera: evidence_level a study_type jsou nezávazné textové řetězce. Doplnit lze: číselník v dokumentaci pro editory, validaci při zápisu nebo enum v DB; nápověda ve formuláři rozhraní editora (32-admin.md §9), aby hodnoty odpovídaly výčtu v §4. Migrace 0023_slug_normalization.sql sjednocuje již uložené hodnoty na malá písmena a trim.

  • Sjednocení / validace evidence_level a study_type vůči §4 (dokumentace, DB nebo rozhraní editora — 32-admin.md)

8.5. §5 — Bezpečnost

Hotovo částečně: strukturované safety_warnings (typ, závažnost, text), herbs.safety_level, souhrnné drug_interactions_note a phototoxicity_note na kartě.

Omezení vůči §5: jednotlivá témata z §5 (těhotenství, děti, …) nejsou povinná samostatná pole — často jsou obsažená v textu description / warning_type jako volný text. To není totéž jako „evidence máme vždy vyčleněnou toxicitu, kojení, …“.

Doplnit: sjednotit nebo zadokumentovat význam warning_type vůči tématům z §5; filtrování nebo skupiny v UI. České štítky pro warning_type a severity na kartě byliny: app/lib/claim-labels.ts (labelSafetyWarningType, labelSafetySeverity). Krátká legenda typů (SafetyWarningTypesLegend) v sekci Bezpečnost.

  • Strukturovaná upozornění + souhrnné texty na kartě (obecný mechanismus)
  • České popisky severity a warning_type ve výpisu upozornění (claim-labels.ts)
  • Stručná legenda warning_type na kartě byliny (rozbalovací blok)
  • Slovníček / mapování warning_type na téma z §5; filtrování či skupiny v UI

8.6. §6 — Bezpečnostní úrovně

Hotovo: v UI je safety_level českým štítkem (labelHerbSafetyLevel) a pod úvodním blokem na kartě byliny je legenda stupňů (herbSafetyLevelLegendRows v app/lib/claim-labels.ts, zobrazení v app/routes/byliny.$slug.tsx). D1 migrace 0023_slug_normalization.sql sjednocuje safety_level na doporučený tvar (lower(trim) + základní synonymum safe → generally_recognized_safe).

  • České štítky pro doporučené hodnoty safety_level na kartě byliny (claim-labels.ts)
  • Legenda významu stupňů (herbSafetyLevelLegendRows) pod úvodním blokem na kartě byliny

8.7. §7 — Obrázky

Hotovo v UI: typ (image_type), alt, popisek (caption), pořadí (řazení v dotazu).

Mezera: pole photographer, license, source_url z tabulky images se na kartě nezobrazují — doplnit drobnou patičku u obrázku (autor, licence, zdroj), aby to odpovídalo §7.

Doplnit: řízený slovníček image_type podle výčtu v §7 (nebo dokumentovat povolené hodnoty), aby katalog obrázků byl konzistentní. České popisky v UI: labelImageType v app/lib/claim-labels.ts.

  • Typ, alt, popisek, pořadí v UI
  • Autor, licence, zdroj (photographer, license, source_url) v patičce u obrázku
  • České popisky běžných image_type na kartě (labelImageType v claim-labels.ts)
  • Řízený slovníček / dokumentace povolených image_type pro editory