Task: Výzkum evidence propojení datového modelu a aplikační logiky v Obsidianu

Typ: research task
Status: New
Priorita: High
Datum založení: 2026-05-17

Cíl

Navrhnout, jak v aplikaci Obsidian systematicky evidovat vazby mezi: - datovým modelem (entity, tabulky, atributy, datové typy, naming), - aplikační logikou (pluginy, validace, business rules, workflow, event handlery, integrace), - a konkrétním použitím jednotlivých polí napříč implementací.

Hlavní požadavek je, aby bylo možné dohledat až na úroveň: - konkrétní entity, - konkrétního pole/atributu, - a všech míst, kde je toto pole: - čteno, - validováno, - měněno, - odvozováno, - používáno v podmínkách, - používáno v integracích, - používáno v pluginech nebo jiné business logice.

Příklad cílového use casu

Například pro pole contact.firstname potřebuji dohledat: - ve kterých pluginech je použito, - při jakých událostech se zpracovává (create, update, pre-op, post-op, apod.), - jaké validace nad ním existují, - zda ovlivňuje další pole nebo entity, - zda vstupuje do výpočtů, synchronizací nebo notifikací, - a jaká dokumentace nebo rozhodnutí se k tomuto poli vážou.

Výzkumné otázky

Jaký knowledge model v Obsidianu zvolit, aby se dobře evidovaly entity, pole a logika?
Je vhodnější přístup:
1 note = 1 entita,
1 note = 1 pole,
1 note = 1 plugin / 1 use case,
nebo hybridní model?
Jak reprezentovat vazby typu:
„pole je použito v pluginu“
„plugin zapisuje do pole“
„validace závisí na poli“
„pole je odvozeno z jiného pole“
Jak k tomu využít:
wikilinky,
frontmatter metadata,
Dataview,
případně Canvas, Excalidraw, Juggl, Breadcrumbs nebo jiné vhodné pluginy?
Jak navrhnout strukturu tak, aby byla:
dobře udržovatelná,
čitelná pro architekta i vývojáře,
rozšiřitelná,
a použitelná i pro větší CRM / Dataverse projekty?
Jak evidovat rozdíl mezi:
datovou strukturou,
technickou implementací,
business pravidlem,
dopadem změny?
Jak v Obsidianu řešit traceability a impact analysis:
„Kde všude se používá toto pole?“
„Co se rozbije, když pole změním, přejmenuji nebo odstraním?“

Očekávaný výstup výzkumu

Výzkum má dodat konkrétní, prakticky použitelný návrh pro zavedení tohoto systému v Obsidianu.

Minimální očekávané deliverables:

Doporučený informační model
jaké typy note existují,
jaké mají povinné atributy,
jaké mezi nimi existují vazby.
Doporučená adresářová struktura vaultu
např. entities / fields / logic / rules / integrations / decisions / diagrams.
Návrh metadata standardu
YAML frontmatter pro entity, pole, pluginy, validace, use casy.
Návrh linkovací strategie
jak používat wikilinks, backlinks a typed relationships.
Ukázkový end-to-end příklad
entita Contact
pole First Name
2–3 příklady logiky, kde je pole použito
ukázka, jak pak dohledat veškeré usage pole.
Dataview / query příklady
jak zobrazit všechna pole entity,
jak zobrazit všechny pluginy používající konkrétní pole,
jak zobrazit všechny downstream závislosti.
Doporučené pluginy a jejich role
co použít,
proč,
kde jsou limity,
co je vhodné držet jednoduché a co už je overengineering.
Doporučený rollout postup
jak to zavést od nuly,
jak migrovat existující dokumentaci,
jak udržovat dokumentaci synchronizovanou s vývojem.

Požadavky na kvalitu výzkumu

Výstup musí být: - specifický a ne obecný, - orientovaný na reálné použití v CRM / Dataverse / plugin-based logice, - porovnávací, pokud existuje více rozumných variant, - s jasným doporučením „co zvolit jako default“.

Nestačí obecný popis Obsidianu. Výzkum musí řešit konkrétně: - evidenci field-level usage, - evidenci logic dependencies, - evidenci impactu změn v datovém modelu.

Preferované oblasti průzkumu

Zaměřit se zejména na: - Obsidian native přístup, - Dataview-based model, - graph / relationship pluginy, - knowledge architecture patterns pro software/documentation systems, - případné alternativy uvnitř Obsidian ekosystému.

Co porovnat

Porovnat minimálně tyto varianty: 1. čistě wikilinkový model, 2. wikilinky + YAML frontmatter, 3. YAML + Dataview-centric model, 4. graph/relationship plugin-centric model, 5. hybridní doporučený model.

Rozhodovací kritéria

Vyhodnotit podle: - dohledatelnosti usage na úrovni pole, - snadnosti údržby, - rychlosti onboardingu, - čitelnosti, - možnosti auditovat dopady změn, - míry manuální práce, - rizika rozpadu dokumentace v čase.

Doporučený formát finálního research výstupu

Finální výzkum by měl obsahovat: - executive summary, - doporučený target operating model, - porovnání variant v tabulce, - konkrétní templates notes, - ukázkové Dataview dotazy, - ukázkový model pro entitu + pole + plugin, - rollout plán, - rizika a limity.

Definice hotovo

Task je hotový, když bude existovat research dokument, který: - navrhne konkrétní způsob evidence v Obsidianu, - umožní dohledat usage konkrétního pole napříč logikou, - obsahuje konkrétní šablony a query příklady, - a dává jasné doporučení, co zavést jako standard.