tderoussel/vault-doctor

Vault-Arzt

Die meisten Obsidian Vaults haben kein Git und kein Undo, und viele werden live über iCloud, OneDrive oder Dropbox synchronisiert. Behandle jeden Schreibvorgang als irreversibel. Bestätige die tatsächliche Sicherungssituation des Vaults, bevor du irgendetwas anfasst, lies bevor du überschreibst, bevorzuge gezielte Änderungen gegenüber vollständigen Dateineuschreibungen und führe niemals eine schnelle Schreibschleife aus – in einem synchronisierten Ordner erzeugt dies Konfliktkopien.

Scan

Gehe .md-Dateien durch und überspringe dabei node_modules, .git, .obsidian sowie alle Build- oder Scratch-Verzeichnisse, die der Vault angesammelt hat. Erstelle die Menge der Link-Ziele aus jedem Dateinamen (Anhänge eingeschlossen, nicht nur .md), extrahiere dann [[ziele]] und entferne die Suffixe |alias, #überschrift und ^block.

Erfasse eine Ausgangsbasis – Anzahl der Notizen, eindeutige defekte Ziele, gesamte defekte Verweise, doppelte Dateinamen – damit spätere Durchläufe eine Veränderung zeigen können, anstatt dieselbe Zählung zu wiederholen.

Vor der Reparatur klassifizieren

Eine rohe Anzahl defekter Links ist keine Fehlerliste. Sortiere jeden Treffer in einen von vier Eimern:

1. Systemübergreifende Referenzen – nicht „reparieren". Manche Ziele sind überhaupt keine Vault-Notizen: Agenten-Speicher-IDs, Ticket-Schlüssel oder Kennungen aus einem anderen Tool, die zufällig in Wikilink-Syntax geschrieben wurden. Sie werden sich nie auflösen. Sie in Klartext umzuwandeln ist vertretbar; Stub-Notizen zu erstellen, um sie zufriedenzustellen, ist es nicht.

2. Dokumentation eines defekten Links – niemals anfassen. Manche Notizen zitieren absichtlich einen defekten Link, als Beispiel oder als Grundwahrheit für eine Übung („Wenn dein Tool das nicht findet, ist dein Tool falsch"). Diese zu bearbeiten zerstört das, was sie lehren. Die Wikilink-Syntax, die innerhalb von Prosa zitiert wird, gehört in dieselbe Klasse.

3. Namensverschiebung – am Ziel korrigieren, nicht an der Quelle. Wenn viele Verweise auf einen Kurznamen zeigen und die Notiz unter einem längeren Namen abgelegt ist, bevorzuge das Hinzufügen von aliases: [Kurzname] zum Frontmatter des Ziels gegenüber der Bearbeitung jeder verweisenden Datei. Eine Änderung, ein natives Obsidian-Mechanismus, kein Risiko, umgebenden Kontext zu verstümmeln.

4. Wirklich fehlende Notizen. Das Ziel hat nie existiert. Melde es; erstelle es nicht automatisch. Ein leerer Stub ist schlimmer als ein defekter Link, weil er wie beantwortet aussieht.

Das Such-und-Ersetzen-Verbot

Repariere niemals Links mit einer unbegrenzten Suchen-und-Ersetzen-Aktion. Eine blinde Ersetzung über einen gesamten Vault hinweg wird Ordnernamen, URLs, Codeblöcke und Tag-Vokabulare verstümmeln, die zufällig die Suchzeichenfolge enthalten – und da es kein Undo gibt, ist der Schaden dauerhaft. Korrigiere dateiweise, nachdem die umgebende Zeile gelesen wurde.

Weitere Prüfungen

• Doppelte Dateinamen machen Links vaultweit mehrdeutig, da Obsidian [[links]] nach Dateiname über den gesamten Vault hinweg auflöst. Der übliche Übeltäter ist ein Codeprojekt oder ein Abhängigkeitsbaum, der innerhalb des Vaults lebt und Tausende von Phantom-.md-Dateien beiträgt. Melde es; die Lösung ist, das Projekt aus dem Vault zu verschieben oder einen Ausschluss hinzuzufügen. Lösche nichts ohne Nachfrage.

• Frontmatter muss tatsächlich geparst werden. Führe jeden Block durch einen echten YAML-Parser – überfliege ihn nicht. Der dominante Fehler ist ein nicht zitierter einfacher Skalar, der : (Doppelpunkt-Leerzeichen) enthält, was an diesem Zeichen scheitert und jeden Schlüssel darunter mitreißt, wodurch der gesamte Block für das Obsidian-Eigenschaftenfenster und für Dataview unsichtbar wird. Ein zweiter häufiger Fehler: Ein nicht zitierter Wert, der mit | oder > beginnt, öffnet einen YAML-Block-Skalar.

  Die Korrektur bedeutet, Werte zu zitieren, was bei einer großen, tragenden Notiz Hunderte von Schlüsseln betreffen kann – schlage es vor, führe es niemals unaufgefordert aus, und sichere die Datei zuerst. Bis es behoben ist, folge der bestehenden (defekten) Konvention, anstatt einen zweiten Stil einzuführen; ein einzelner gültiger Schlüssel innerhalb eines ungültigen Blocks bringt nichts.

• Tags gehören in YAML als Liste, nicht als Inline-Hashtags – überprüfe sie anhand des tatsächlichen Vokabulars des Vaults und nicht anhand eines idealisierten. Melde Abweichungen; führe keine einseitigen Neutaggings durch.

• Veralteter Status – Notizen, die PAUSIERT/GESTOPPT/TODO-Marker tragen, deren Projekt aber inzwischen weitergezogen ist. Melde sie; löse sie nicht selbst auf.

• Kalte Hubs – eine Hub-Notiz, deren neuester Statusabschnitt älter ist als die letzte Aktivität des Projekts, ist veraltet. Melde die Lücke.

Ausgabe

Ein Bericht, geordnet nach Eimern, mit Anzahlen und genauen Datei:Zeile-Verweisen. Schlage Reparaturen vor; führe nur diejenigen aus, die der Benutzer genehmigt.

Gebe klar an, welche Ergebnisse überprüft und welche aus der Benennung abgeleitet sind – ein Ziel, das wie eine Verschiebung aussieht, könnte eine Notiz sein, die sie schreiben möchten.