Plainva

Automatisierung & Skripte

Stand: 2026-10-22

Plainva hat kein Plugin-System, das fremden Code ausführt. Stattdessen ist der Vault selbst die Erweiterungs-Schnittstelle: Deine Notizen sind reines Markdown, Datenbanken sind reines YAML (.base), und die OKF-Konventionen geben jeder Datei eine vorhersagbare Struktur. Alles, was Dateien lesen und schreiben kann — ein Shell-Skript, ein Python-Programm, ein CLI-Werkzeug, ein geplanter Job oder ein KI-Agent — kann Deinen Vault erweitern, erzeugen oder umbauen, ganz ohne eine Plainva-spezifische API.

Diese Seite erklärt, wie das sicher geht. Das genaue Byte-Format jeder Datei steht separat in der Dateiformat-Referenz; diese Seite ist der praktische Begleiter: die Regeln, der Ablauf und was Du einer KI mitgibst.

Warum Dateien statt einer Plugin-Sandbox

Wenn Du etwas möchtest, das Plainva nicht von Haus aus kann, wartest Du nicht auf ein Plugin — Du schreibst ein kleines Skript gegen die Dateien.

Einen Vault sicher lesen

Alles ist UTF-8-Text:

Lesen braucht nie besondere Vorsicht — Textdateien können durch bloßes Lesen nicht „beschädigt” werden. Die Regeln unten drehen sich alle ums Schreiben.

Einen Vault sicher schreiben

Hältst Du diese Regeln ein, übernehmen Plainva (und Obsidian) Deine Änderungen sauber. Plainva überwacht den Vault-Ordner: Ein externer Schreibvorgang wird automatisch erkannt und neu indexiert, meist innerhalb einer Sekunde.

  1. Schreibe UTF-8. Gib einer neuen Datei LF-Zeilenenden und kein BOM — so schreibt Plainva selbst. Eine Datei, die schon CRLF-Zeilenenden oder ein BOM hat, darf sie behalten: Plainva liest beides und lässt beides, wie es ist, auch wenn die Notiz bearbeitet oder synchronisiert wird. Die Ausnahme ist ein Wagenrücklauf allein als Zeilenende — so enden die Zeilen alter Mac-Dateien: Plainva liest eine solche Datei, speichert sie aber mit LF, sobald es sie zum ersten Mal ändert. Nicht lesen kann es eine andere Kodierung — UTF-16 oder Windows-1252, wie manche Windows-Werkzeuge sie standardmäßig schreiben. Eine solche Datei öffnet Plainva nicht: es zeigt Diese Datei ist kein Text und bietet sie dem Programm des Systems an (In Standard-App öffnen, am Telefon Teilen), und nichts in Plainva schreibt einen Text über sie — kein Speichern, keine Eigenschaft, kein Link, den ein Umbenennen umschreibt. Der Versionsverlauf hält sie Byte für Byte, und Wiederherstellen oder Duplizieren kopiert ihre Bytes. Um sie in Plainva zu bearbeiten, speichere sie im anderen Programm als UTF-8. Speichert ein anderes Programm eine Datei in einer anderen Kodierung, während Du darin ungespeicherte Änderungen hast, legt Plainva Deine Änderungen als .CONFLICT-Datei daneben; der Vergleich bietet dann Aktuelle Datei durch Konfliktkopie ersetzen, Beide Dateien behalten und Konfliktkopie löschen an. Ein Sync überträgt sie trotzdem unversehrt — Byte für Byte, wie ein Bild: sie wird nicht zusammengeführt, und haben zwei Geräte sie gleichzeitig geändert, bleibt Deine Fassung als .CONFLICT-Datei erhalten.
  2. Schreibe atomar. Schreibe in eine temporäre Datei im selben Ordner und benenne sie dann über das Ziel um. Eine halb geschriebene Notiz (etwa nach einem Absturz) ist schlimmer als keine Änderung. Plainva selbst schreibt jede Notiz so.
  3. Bewahre OKF-Frontmatter und unbekannte Schlüssel. Behalte type und okf_version, wenn Du eine Notiz neu schreibst, und wirf nie Frontmatter-Schlüssel weg, die Du nicht kennst — reiche sie unverändert durch. „Räume” keine Schlüssel auf, die Du nicht verstehst.
  4. Fass .plainva/ nie an. Dieser Ordner enthält Plainvas gerätelokalen Index, Backups, Graph-Pins und Sync-Status. Er ist nicht Teil Deiner Inhalte und darf von Deinen Skripten nie geschrieben, synchronisiert oder nach Git committet werden.
  5. Halte die .base-Regeln ein. Eine .base nutzt nur Obsidians vier Top-Level-Schlüssel (filters, formulas, properties, views); jede Ansicht braucht einen name; Filter sind einwurzelig. Alle Plainva-spezifischen Daten liegen unter verschachtelten plainva:-Unterschlüsseln. Die Dateiformat-Referenz enthält den vollständigen Vertrag inklusive eines zweiseitigen Relations-Beispiels.
  6. Streite nicht mit dem Editor. Wenn eine Notiz in Plainva geöffnet ist und ungespeicherte Änderungen hat, schreibe sie nicht im selben Moment per Skript neu. Plainva hat als Sicherheitsnetz einen Konflikt-Auflöser, aber der sauberste Weg ist, die App zuerst speichern zu lassen (oder Notizen zu bearbeiten, die gerade nicht offen sind).

Muster

Ein paar häufige Aufgaben, alle nur Dateioperationen:

Halte Skripte möglichst idempotent: Zweimaliges Ausführen darf keine Inhalte verdoppeln.

Den Vault einer KI übergeben

Ein KI-Agent mit Lese-/Schreibzugriff auf einen Vault-Ordner ist genau der Fall, für den dieses Design gebaut ist. Damit er korrekt arbeitet:

  1. Gib ihm die Dateiformat-Referenz. Sie ist für einen maschinellen Leser geschrieben: der OKF-Frontmatter-Vertrag, die Eigenschaft→YAML-Serialisierung, das vollständige .base-Schema mit seinen harten Obsidian-Regeln, der index.md-Vertrag und die Sicherheitsregeln — alles, was ein Agent braucht, um Dateien zu bearbeiten, ohne sie zu zerstören.
  2. Setz ihn auf den Vault-Ordner an, nicht auf .plainva/. Sag klar, dass .plainva/ tabu ist.
  3. Verlange atomare, minimale Änderungen. Ein Agent, der eine ganze Notiz neu schreibt, um eine Eigenschaft zu ändern, sollte den Rest von Frontmatter und Text wortgetreu bewahren.

Weil der Vertrag ein Dokument ist und keine laufende API, funktionieren dieselben Anweisungen mit jeder KI, offline wie online.

Sicherheit in Kürze

Siehe auch