Vault-OS 0.1.0: Ein portables Betriebssystem für Obsidian-Vaults

Ein Obsidian-Vault beginnt angenehm unspektakulär: ein Ordner, ein paar Markdown-Dateien und die Freiheit, die eigene Struktur selbst zu bestimmen. Genau das macht Obsidian so attraktiv. Die Inhalte liegen lokal, lassen sich mit gewöhnlichen Werkzeugen bearbeiten und bleiben unabhängig von einer proprietären Datenbank.

Mit der Zeit wächst allerdings nicht nur das Wissen. Es entstehen Vorlagen, Regeln, Felder, Ordnerkonventionen, Suchindizes, Automationen und Integrationen mit KI-Werkzeugen. Auf dem ersten Gerät funktioniert das meist irgendwie. Beim nächsten Gerät, einem größeren Umbau oder dem ersten Update zeigt sich, dass aus einem Ordner voller Notizen längst ein kleines Betriebssystem geworden ist – nur ohne Installer, Versionsstand und Health Check.

Vault-OS macht diese Betriebsschicht explizit. Version 0.1.0 ist jetzt als Open-Source-Projekt veröffentlicht.

Was Vault-OS eigentlich ist

Vault-OS ist ein portables, AI-first und local-first Framework für unabhängig benannte Obsidian-Vaults. Es liefert:

• versionierte Regeln und Schemas,
• wiederverwendbare Workflows und Vorlagen,
• optionale Module für unterschiedliche Arbeitsweisen,
• einen manifestgesteuerten Installations- und Updateprozess,
• Validierung und Diagnosen,
• sowie providerneutrale Grundlagen für lokale KI-Agenten.

Das klingt zunächst nach einer besonders aufwendigen Vorlage. Der entscheidende Unterschied liegt aber im Lifecycle. Eine Vorlage wird kopiert und ist danach auf sich allein gestellt. Vault-OS kennt den installierten Release-Stand, prüft verwaltete Dateien über SHA-256-Prüfsummen und kann geplante Änderungen anzeigen, bevor ein Update angewendet wird.

Was Vault-OS ausdrücklich nicht ist

Vault-OS ist kein vorgefülltes zweites Gehirn, keine veröffentlichte private Wissenssammlung und keine fremde Meinung darüber, wie Dein Leben sortiert werden soll.

Es ist außerdem:

• kein Obsidian-Plugin,
• kein gehosteter Dienst,
• kein KI-Modell,
• keine Berechtigungsplattform,
• und kein Ersatz für Backup oder Synchronisation.

Dein Vault behält seinen Namen, seine Sprache, seine Inhalte und seine Fachlogik. Obsidian bleibt die Oberfläche. Markdown und YAML bleiben der offene Datenbestand.

Der wichtigste Vertrag: Wem gehört welche Datei?

Die kniffligste Frage eines aktualisierbaren Vault-Systems lautet nicht, wie Dateien kopiert werden. Sie lautet: Wer darf eine vorhandene Datei verändern?

Vault-OS unterscheidet deshalb drei Eigentumsbereiche.

Managed Files

Diese Dateien gehören zu einem Vault-OS-Release. Dazu zählen beispielsweise Systemregeln, Schemas, Workflows und installierte Assets. Sie werden ausschließlich über den Lifecycle aktualisiert.

Vor einem Update muss jede verwaltete Datei weiterhin der beim letzten Release aufgezeichneten Prüfsumme entsprechen. Wurde sie lokal verändert oder gelöscht, stoppt die gesamte Operation. Das System überschreibt den Konflikt nicht still.

Instance Files

Diese Dateien gehören dem Vault-Eigentümer. Darin liegen unter anderem aktivierte Module, Sprache, Pfade sowie lokale Feld- und Wertzuordnungen. Ein Update darf sie nicht übernehmen oder auf einen angeblich besseren Standard zurücksetzen.

Runtime Files

Release-Metadaten, Client-Adapter, Suchindizes und gerätespezifische Konfiguration gehören zur lokalen Laufzeit. Sie werden nicht Teil des synchronisierten Wissensbestands.

Diese Trennung ist weniger spektakulär als eine neue Graph-Ansicht. Dafür verhindert sie eine ganze Klasse unangenehmer Überraschungen.

Modular statt dogmatisch

Der Kern von Vault-OS installiert die gemeinsamen Betriebsregeln. Vierzehn optionale Module ergänzen unter anderem:

• PARA,
• Eingang,
• Journal,
• Wissensverarbeitung,
• Kontakte,
• Publishing,
• Vorlagen und Reviews,
• Governance und Audits,
• Git und lokale Suche,
• Navigation und Agentenkonventionen.

Jedes Modul ist standardmäßig deaktiviert. Damit lässt sich ein kleiner Journal-Vault anders aufbauen als ein umfangreiches persönliches Wissenssystem oder ein Dokumentations-Vault für ein langfristiges Projekt.

Die mitgelieferten deutschen und englischen Quellen werden anhand der Instanzkonfiguration materialisiert. Weitere Sprachen können Englisch als Fallback verwenden. Auch Ordnernamen, Systemwurzel, Frontmatter-Felder und Werte gehören zur konkreten Instanz – nicht zu einer global vorgeschriebenen Vault-Identität.

Installation ist eine Transaktion

Der Installer prüft die gewünschte Konfiguration und bereitet die vollständige Änderung vor, bevor sie in den Ziel-Vault geschrieben wird. Erst nach erfolgreichem Abschluss zeichnet Vault-OS den Release-Stand auf.

Der typische Ablauf besteht aus vier Schritten:

1. Einen reproduzierbaren Vault-OS-Release auswählen.
2. Kern und gewünschte Module installieren.
3. Benutzerdateien wie README, Dashboard und Profile kontrolliert erzeugen.
4. Den resultierenden Vault mit doctor prüfen.

Die vollständigen Befehle und Voraussetzungen stehen im Vault-OS Quick Start. Für einen bestehenden Vault ist ein aktuelles Backup Pflicht. Die ausführliche GitHub-Anleitung beschreibt außerdem abweichende Pfade und eine bewusste Side-by-Side-Migration.

Bootstrap-Dateien bleiben Benutzerdateien

Vault-OS kann fehlende Einstiegspunkte wie README.md, Dashboard.md, Profile.md und Ordner-READMEs erzeugen. Danach gehören diese Dateien vollständig dem Vault-Eigentümer.

Das ist ein wichtiger Unterschied zu verwalteten Systemdateien. Ein Dashboard ist der persönliche Einstieg in einen konkreten Wissensraum. Ein späteres Framework-Update darf daraus nicht wieder eine generische Beispielseite machen.

Der Bootstrap adoptiert deshalb auch keine bereits vorhandene Datei und überschreibt sie nicht. Vorhanden bedeutet vorhanden – nicht frei zur Übernahme.

Updates mit Vorschau und Notbremse

Änderungen an Modulen oder Pfaden werden in der sichtbaren Instanzkonfiguration vorgenommen. Danach zeigt diff, welche verwalteten Dateien sich ändern würden. Erst update wendet die vorbereitete Transaktion an.

Fehlt eine verwaltete Datei oder stimmt ihre Prüfsumme nicht mehr, wird das Update vollständig abgebrochen. Das kann im ersten Moment streng wirken. Es ist aber wesentlich angenehmer als ein erfolgreicher Updatebefehl, der im Hintergrund eine lokale Anpassung entsorgt hat.

Version 0.1 besitzt bewusst keinen automatischen Downgrade und keine Uninstall-Funktion. Für Rückbau und Entfernung bleibt ein geprüftes Backup die Grundlage.

Obsidian Sync ohne versteckten Runtime-Umzug

Die sichtbare Instanzkonfiguration kann gemeinsam mit den Markdown-Dateien über Obsidian Sync oder einen anderen geeigneten Dateidienst übertragen werden. Verborgene gerätelokale Zustände bleiben dagegen auf dem jeweiligen Rechner.

Auf einem weiteren Gerät rekonstruiert device-sync den lokalen Release-Stand, nachdem es die synchronisierten Managed- und Instance-Dateien geprüft hat. Das Kommando startet oder steuert Obsidian Sync nicht. Es überprüft nur, was der freigegebene Sync tatsächlich geliefert hat.

Damit bleibt die Synchronisation für Inhalte zuständig, während Vault-OS den lokalen Betriebszustand reproduziert. Beide Aufgaben werden nicht in einen magischen Mischprozess gekippt.

Lokale KI-Unterstützung ohne eingebautes Modell

Vault-OS ist für die Zusammenarbeit mit autorisierten lokalen KI-Agenten ausgelegt. Es installiert gemeinsame Arbeitsregeln, kanonische Skills und schmale Provider-Adapter.

In Version 0.1.0 sind Adapter für Codex und Claude Code enthalten. QMD kann als externe lokale Suche ergänzt werden. Die gemeinsame Lifecycle-Logik enthält trotzdem keine fest verdrahteten Abzweigungen für einzelne Anbieter.

Vault-OS installiert weder ein Modell noch Zugangsdaten oder Berechtigungen. Ein Browser-Chat erhält durch die Dateien keinen lokalen Zugriff. Welcher Client auf welche Verzeichnisse zugreifen darf, bleibt eine lokale Sicherheitsentscheidung.

Auch Suchergebnisse gelten lediglich als Kandidaten. Ein Agent soll die gefundene Originaldatei lesen, bevor er daraus eine Aussage ableitet oder eine Änderung vorschlägt.

MindOS als produktive Referenz

Entstanden ist Vault-OS aus der Arbeit an MindOS, dem privaten Wissenssystem von Jürgen Schadek. MindOS verbindet PARA, Journal, Wissensverarbeitung, Dataview, Automationen und lokale KI-Arbeit in einem produktiv genutzten Obsidian-Vault.

Während der Entwicklung wurde deutlich, dass die tragfähige Betriebsschicht von den persönlichen Inhalten und Pfaden getrennt werden muss. MindOS ist heute eine reale Vault-OS-Instanz und Validierungsumgebung. Das öffentliche Repository enthält jedoch weder private MindOS-Inhalte noch eine versteckte Produktdefinition.

Wie MindOS im persönlichen Alltag eingesetzt wird, beschreibt Jürgen auf seiner Website im Artikel MindOS: Mein persönliches Wissenssystem mit Vault-OS.

Für wen Vault-OS interessant ist

Vault-OS passt zu Menschen, die:

• ihre Inhalte in offenen lokalen Dateien behalten möchten,
• mehr als eine lose Sammlung von Vorlagen brauchen,
• einen Vault reproduzierbar auf mehreren Geräten betreiben wollen,
• Änderungen vor dem Anwenden prüfen möchten,
• lokale KI-Agenten mit klaren Regeln einsetzen,
• oder eine gewachsene Vault-Struktur schrittweise auf eine versionierte Grundlage stellen wollen.

Wer lediglich gelegentlich ein paar Notizen in Obsidian schreibt, braucht vermutlich kein Framework darum. Das ist kein Mangel. Gute Infrastruktur beginnt mit der ehrlichen Frage, ob das Problem überhaupt existiert.

Der Stand von Version 0.1.0

Die erste veröffentlichte Version wurde gegen neue Vaults, eine hash-verifizierte Kopie eines realen Vaults und eine bewusste Side-by-Side-Migration der produktiven Referenzinstanz geprüft. Die Installation, Updates, Synchronisationsgrenzen und Agentenadapter besitzen automatisierte Tests und dokumentierte Validierungsnachweise.

Trotzdem bleibt 0.x eine Entwicklungsreihe. Schnittstellen können sich weiterentwickeln. Wer einen reproduzierbaren Stand benötigt, sollte deshalb das Tag v0.1.0 verwenden und nicht ungeprüft den aktuellen main-Branch installieren.

Einstieg und Quellcode

Die Vault-OS-Seite auf ITextreme erklärt Funktionen, Grenzen und Installation kompakt. Quellcode, vollständige technische Dokumentation, Issues und Releases liegen im öffentlichen GitHub-Repository.

Vault-OS steht unter der Mozilla Public License 2.0. Änderungen an verteilten Vault-OS-Dateien bleiben damit offen. Eigenständige Inhalte eines Vaults werden nicht plötzlich Teil dieser Lizenz, nur weil sie neben dem Framework liegen.

Der Kern bleibt einfach: Dein Wissen gehört Dir. Die Betriebsschicht darf trotzdem ordentlich versioniert, geprüft und aktualisiert werden.