Plainva

Automatisering & scripts

Laatst bijgewerkt: 2026-10-22

Plainva heeft geen pluginsysteem dat code van derden uitvoert. In plaats daarvan is de vault zelf de uitbreidingsinterface: je notities zijn gewone Markdown, databases zijn gewone YAML (.base), en de OKF-conventies geven elk bestand een voorspelbare structuur. Alles wat bestanden kan lezen en schrijven — een shellscript, een Python-programma, een CLI-tool, een geplande taak of een KI-agent — kan je vault uitbreiden, genereren of herstructureren zonder ook maar één Plainva-specifieke API.

Deze pagina legt uit hoe je dat veilig doet. Het exacte bestandsformaat, tot op byte-niveau, is voor elk bestand apart gedocumenteerd in de Bestandsformaat-referentie; deze pagina is de praktische aanvulling: de regels, de werkwijze, en wat je een KI-assistent moet meegeven.

Waarom bestanden in plaats van een plugin-sandbox

Wil je iets wat Plainva niet standaard doet, dan wacht je niet op een plugin — je schrijft een klein script tegen de bestanden.

Een vault veilig lezen

Alles is UTF-8-tekst:

Lezen vraagt nooit om voorzichtigheid — tekstbestanden kunnen niet “beschadigd” raken door ze te lezen. De regels hieronder gaan allemaal over schrijven.

Een vault veilig schrijven

Volg deze regels en Plainva (en Obsidian) accepteren je wijzigingen probleemloos. Plainva houdt de vaultmap in de gaten: een externe schrijfactie wordt automatisch opgemerkt en opnieuw geïndexeerd, meestal binnen een seconde.

  1. Schrijf UTF-8. Geef een nieuw bestand LF-regeleinden en geen BOM — zo schrijft Plainva zelf. Een bestand dat al CRLF-regeleinden of een BOM heeft, mag die houden: Plainva leest beide en laat ze zoals ze zijn, ook wanneer de notitie wordt bewerkt of gesynchroniseerd. De uitzondering is een regeleinde dat alleen uit een wagenterugloop (CR) bestaat — wat oude Mac-bestanden hebben: Plainva leest zo’n bestand, maar slaat het met LF op zodra het dat bestand voor het eerst wijzigt. Wat het niet kan lezen, is een andere codering — UTF-16 of Windows-1252, die sommige Windows-tools standaard schrijven. Zo’n bestand opent Plainva niet: het toont Dit bestand is geen tekst en biedt het aan het programma van het systeem aan (Openen in standaardapp; op de telefoon Delen), en niets in Plainva schrijft er een tekst overheen — geen opslaan, geen eigenschap, geen link die een hernoeming herschrijft. De Versiegeschiedenis bewaart het byte voor byte, en herstellen of dupliceren kopieert de bytes. Om het in Plainva te bewerken, sla je het in het andere programma op als UTF-8. Slaat een ander programma een bestand op in een andere codering terwijl je er niet-opgeslagen wijzigingen in hebt, dan bewaart Plainva je wijzigingen ernaast als een .CONFLICT-bestand; de vergelijking biedt dan Huidig bestand vervangen door conflictkopie, Beide bestanden behouden en Conflictkopie verwijderen. Een sync brengt het toch ongeschonden over — byte voor byte, zoals een afbeelding: het wordt niet samengevoegd, en als twee apparaten het tegelijk hebben gewijzigd, blijft jouw versie bewaard als een .CONFLICT-bestand.
  2. Schrijf atomair. Schrijf naar een tijdelijk bestand in dezelfde map en hernoem dat vervolgens naar de doelnaam. Een half geschreven notitie (bijvoorbeeld na een crash) is erger dan helemaal geen wijziging. Plainva schrijft zelf elke notitie op deze manier.
  3. Bewaar de OKF-frontmatter en onbekende sleutels. Behoud type en okf_version wanneer je een notitie herschrijft, en laat nooit frontmattersleutels vallen die je niet herkent — ze moeten een lees-/schrijfronde ongewijzigd doorstaan. “Ruim” geen sleutels op die je niet begrijpt.
  4. Raak .plainva/ nooit aan. Die map bevat Plainva’s lokale (per-apparaat) index, back-ups, vastzettingen in de graaf en sync-status. Het is geen onderdeel van je inhoud en mag door je scripts nooit worden beschreven, gesynchroniseerd of naar Git gecommit.
  5. Houd je aan de .base-regels. Een .base gebruikt alleen Obsidians vier top-level sleutels (filters, formulas, properties, views); elke weergave heeft een name nodig; filters zijn eenwortelig. Alle Plainva-specifieke data staat onder geneste plainva:-subsleutels. De Bestandsformaat-referentie bevat het volledige contract, inclusief een tweezijdig relatievoorbeeld.
  6. Werk niet tegen de editor in. Is een notitie open en heeft ze niet-opgeslagen wijzigingen in Plainva, herschrijf haar dan liever niet op datzelfde moment vanuit een script. Plainva heeft een conflictoplosser als vangnet, maar de schoonste weg is de app eerst te laten opslaan (of notities te bewerken die op dat moment niet open staan).

Patronen

Een paar veelvoorkomende taken, allemaal gewoon bestandsbewerkingen:

Houd scripts waar mogelijk idempotent: twee keer draaien mag geen inhoud verdubbelen.

De vault overdragen aan een KI-assistent

Een KI-agent met lees-/schrijftoegang tot een vaultmap is precies het scenario waarvoor dit ontwerp is gemaakt. Om hem correct te laten werken:

  1. Geef hem de Bestandsformaat-referentie. Die is geschreven voor een machinale lezer: het OKF-frontmattercontract, de eigenschap→YAML-serialisatie, het volledige .base-schema met de harde Obsidian-regels, het index.md-contract en de veiligheidsregels — alles wat een agent nodig heeft om bestanden te bewerken zonder ze te breken.
  2. Wijs hem naar de vaultmap, niet naar de map .plainva/. Maak duidelijk dat .plainva/ verboden terrein is.
  3. Vraag om atomaire, minimale wijzigingen. Een agent die een hele notitie herschrijft om één eigenschap te wijzigen, moet de rest van de frontmatter en de tekst woordelijk bewaren.

Omdat het contract een document is en geen live API, werken dezelfde instructies met elke assistent, offline of online.

Veiligheidsregels op een rij

Zie ook