Typowe pytanie przy starcie z Obsidianem: *czy powinienem mieć jeden duży vault, czy kilka mniejszych?* Odpowiedź zależy od tego, czego oczekujesz. Ale jest coś, czego wiele osób nie bierze pod uwagę: jeden dobrze zaprojektowany vault może obsługiwać projekty o zupełnie różnym charakterze — jednocześnie, bez kolizji, z pełną separacją tam gdzie potrzeba i pełną integracją tam gdzie to wartość. To nie jest kwestia rozmiaru sejfu. To kwestia architektury. ## Czym różni się vault od folderu na dysku Vault to nie tylko miejsce na pliki. To środowisko z własną logiką: linkami dwukierunkowymi, frontmatter jako warstwą metadanych, Dataview jako silnikiem zapytań, pluginami jako rozszerzeniami zachowania. Folder na dysku przechowuje pliki. Vault rozumie relacje między nimi. To rozróżnienie staje się ważne gdy vault zaczyna obsługiwać więcej niż jeden kontekst. ## Cztery zastosowania, jeden vault ### 1. Osobisty workspace Daily notes, projekty bieżące, kanbany, listy zadań, przechwycone myśli. Miejsce, gdzie dzieje się codzienna praca. Mechanika: Dataview jako dynamiczny widok zadań (`task` queries), tagi statusów, linki do projektów jako kontekst. Struktura rośnie razem z pracą, nie jest narzucona z góry. ### 2. Archiwum referencyjne Baza wiedzy, która nie starzeje się razem z folderami. Artykuły, notatki, badania, linki, cytowania — dostępne przez wyszukiwanie pełnotekstowe, tagi i graf powiązań. Kluczowa różnica: tutaj nie szukasz przez lokalizację pliku (*gdzie to zapisałem?*), ale przez kontekst (*co wiem o tym temacie?*). Linki dwukierunkowe pokazują powiązania, które sam byś przeoczył. Graf wiedzy to wizualizacja myślenia — nie dla estetyki, ale dla nawigacji. ### 3. Źródło dla strony WWW Vault jako CMS. Pliki markdown z frontmatterem (`publish: true`, `category`, `description`, `created`) stają się artykułami na stronie. Obsidian Publish synchronizuje wybrany podzbiór — bez eksportu, bez osobnego workflow. Piszesz w sejfie, publikujesz jednym kliknięciem. Ten wzorzec działa też poza Publishem: vault jako statyczne repozytorium treści, eksportowane do Astro, Jekyll, Hugo czy własnego stacka. Wystarczy że skrypt czyta pliki i buduje stronę — pliki są wystarczająco ustrukturyzowane przez frontmatter żeby to obsłużyć. ### 4. Baza danych dla AI REST API Obsidianu pozwala zewnętrznym narzędziom — skryptom, agentom, modelom językowym — czytać i pisać do sejfu jak do każdej innej bazy danych. Praktyczny efekt: AI asystent, który zna zawartość Twoich notatek. Może przeszukiwać, cytować, uzupełniać. Nie jest osobnym narzędziem — jest klientem tego samego vault, w którym pracujesz. To fundamentalna różnica w stosunku do AI-as-a-black-box. ## Dlaczego prosta struktura to umożliwia Siłą napędową tego wszystkiego jest to, że vault to tylko folder z plikami tekstowymi. Żadnego vendor lock-in, żadnego proprietary formatu, żadnego API do odblokowania. Każdy skrypt w Pythonie może przejrzeć vault. Każdy serwer HTTP może wystawić go przez REST. Każde narzędzie które czyta markdown — czyta też Twoje notatki. Obsidian jest tu jednym z interfejsów do danych, nie jedynym możliwym. To jest właśnie sens *file over app*: dane przeżywają narzędzia. Gdy pojawi się lepszy edytor, lepszy silnik publikacji, lepszy klient AI — przełączasz się bez migracji. Pliki zostają. ## Separacja bez izolacji Wiele kontekstów w jednym vault nie oznacza bałaganu. Separację zapewniają: - **Frontmatter** — każdy plik ma swój kontekst: projekt, kategoria, status, `publish: true/false` - **Dataview** — widoki filtrują to co potrzebne; workspace widzi swoje, strona widzi swoje - **Tagi i linki** — powiązania tam gdzie sens, granice tam gdzie potrzeba Jeden vault, wiele rzeczywistości — bez kompromisów między nimi. --- *Powiązane:* - [[Obsidian jako platforma, nie notatnik]] — dlaczego plain text to fundament, nie ograniczenie - [[Obsidian mówi językiem danych]] — frontmatter i Dataview jako wspólny język człowieka z maszyną - [[Obsidian + AI — maszyna w tej samej bazie]] — jak AI pracuje z vault przez REST API