Moritz Conjé
Mit dem Prozessmodell stand fest, wie ich über mein Second Brain denken will. Für die tägliche Arbeit brauchte ich aber auch ein Werkzeug, das dieses Denken abbildet – ein Kanban-Board für Projekte und Aufgaben. Genau dort brach mir wenig später eines meiner vier bestehenden Boards weg, ohne jede Fehlermeldung. Der Grund dafür lag tiefer, als ich zunächst vermutet hatte.
Der eigentliche Fehler: Ordnerpfad statt Property
Das bisher genutzte Plugin Task Board filtert seine Boards ausschließlich über einen exakten Ordnerpfad-Präfix. Jede Umbenennung oder Verschiebung eines Ordners bricht diesen Filter lautlos – keine Fehlermeldung, das Board zeigt einfach null oder falsche Karten an. Genau das war bei einem meiner vier Boards bereits real passiert: Der hinterlegte Pfad existierte nicht mehr, obwohl die zugehörigen Karten mit korrektem Tag weiterhin im Vault lagen.
Bestandsaufnahme vor der Entscheidung
Bevor ich etwas geändert habe, habe ich den tatsächlichen Bestand geprüft: 76 offene und 7 erledigte Karten, verteilt auf vier Boards. Dabei kamen zwei weitere, unabhängige Probleme ans Licht. Erstens: Welcher Spalte eine Karte zugeordnet wird, hing tatsächlich an einem Tag, nicht am eigentlich dafür vorgesehenen Status-Feld – Letzteres war teils veraltet und stimmte nicht mehr zuverlässig mit der echten Spalte überein. Zweitens: Zwei Boards teilten sich denselben Ordner und denselben Tag für ihre Follow-up-Spalte, wodurch identische Karten in beiden Boards auftauchten. Der naheliegende Versuch, das durch Verschieben einzelner Dateien zwischen den Ordnern zu entwirren, erwies sich als Sackgasse – die Karten gehörten inhaltlich zu Recht in beide Kontexte, das Problem lag an der reinen Tag-Logik, nicht an der Dateiablage.
Werkzeugwahl: Bases statt Task Board
Obsidian Bases, das Core-Plugin für property-gefilterte Ansichten, war bei mir bereits im Second-Brain-Bereich im Einsatz – kein neues Konzept, sondern ein bewährtes Muster, das sich auf die Boards übertragen ließ. Ein Community-Plugin namens "Project Manager" habe ich bewusst verworfen: Es hätte ein drittes, konkurrierendes Datenmodell neben Bases und dem bestehenden Second-Brain-Schema eingeführt und selbst wieder mit derselben Ordner-first-Logik gearbeitet, die ich gerade ablösen wollte. Für die eigentliche Kanban-Optik habe ich zunächst das Community-Plugin "Base Board" installiert – Spalten werden direkt aus einer beliebigen Frontmatter-Property erzeugt, Drag & Drop schreibt die Property unmittelbar in die Datei zurück, kein eigener Pfad-Cache mehr. Weil es aber keine Swimlanes unterstützt, bin ich stattdessen auf Bases Kanban (Community-Plugin kanban-bases-view) umgestiegen, das dieselbe property-basierte Logik mitbringt und zusätzlich eine zweite Gruppierungsebene erlaubt.
Migration in der Praxis: ein paar Stolpersteine
Die eigentliche Umstellung – Tags/Status per Skript auf ein neues type/status-Schema (`prt_
Ergebnis
Alle vier ursprünglichen Boards sind migriert, dabei wurden es wegen der aufgedeckten Überschneidung bewusst fünf eigenständige Ansichten statt vier. Sämtliche 68 migrierten Original-Karten liegen jetzt archiviert, das alte Task-Board-Plugin ist deaktiviert. Sogar der Migrationsplan selbst ist inzwischen als eigene Karte im neuen System eingetragen – ein passender Schlusspunkt für ein Projekt, das mit einer lautlos verschwundenen Karte begann.
Ausblick
Offen bleibt vor allem die Dokumentation: Die Beschreibung des alten Board-Schemas muss noch durch das neue ersetzt werden, ebenso die Frage, ob die bisherige Ordnerstruktur als reine Ablage-Konvenienz erhalten bleibt. Wie es sich anfühlt, mit diesem neuen, property-basierten System tatsächlich zu arbeiten – etwa bei der Frage, wer im Second Brain und KI-Agenten welche Karten anlegen und bearbeiten darf –, ist Thema eines der nächsten Beiträge dieser Serie.
