entity delete
Löscht eine Entität aus einem Vault. Soft-Delete: die Datei landet nicht im Nirwana, sondern im Quarantäne-Ordner .apparat/trash/ innerhalb des Vaults. Reversibel per vault trash restore; die NanoID bleibt für die gelöschte Entität reserviert und wird niemals neu vergeben.
Einfachster Fall
apparat entity delete V1StGXRa
Apparat sucht die Entität mit dieser NanoID in content/, zeigt ihren Titel und fragt nach Bestätigung:
About to delete "Maria Beispiel" (id: V1StGXRa, type: person) from vault "recherche" → file: 2026-04-19--maria-beispiel--V1StGXRa.md → moves to .apparat/trash/ → the NanoId will never be re-used, even after the trash is emptied. Continue? [y/N]
Mit yes wird die Datei atomar nach .apparat/trash/ verschoben; ihr Frontmatter bekommt ein deleted-Feld (heute als ISO-Datum) und einen frischen updated-Zeitstempel. Danach ist die Entität aus entity list, entity search und dem Graph verschwunden.
Mit no (oder Enter, weil der Default N ist) passiert nichts; die Entität bleibt unverändert.
Ohne Rückfrage: --force
apparat entity delete V1StGXRa --force
Überspringt den Bestätigungs-Prompt. Praktisch für Skripte oder wenn du es wirklich eilig hast — aber bewusst explizit einzutippen, damit Tipper nicht versehentlich halbe Vaults leeren.
Nicht-interaktiver Modus
Im --no-interaction-Modus (z.B. in CI-Pipelines) verlangt entity delete zwingend --force. Ohne bricht das Kommando ab:
apparat entity delete V1StGXRa --no-interaction # Refusing to delete without --force in non-interactive mode. # Exit code: 1 apparat entity delete V1StGXRa --no-interaction --force # → funktioniert
Diese Doppelsicherung soll verhindern, dass ein schief konfiguriertes Skript unbeabsichtigt löscht.
Vault-Auswahl
Wie bei allen Entity-Kommandos: ohne --vault greift die übliche Auto-Lokalisierung (CWD-Erkennung, einziger registrierter Vault, interaktive Auswahl). Explizit:
apparat entity delete V1StGXRa --vault=arbeit apparat entity delete V1StGXRa --vault=/home/max/vaults/recherche apparat entity delete V1StGXRa --vault=https://apparat.example.com/vaults/recherche
Was nach der Löschung auf der Platte liegt
Vorher:
vaults/recherche/
└── content/
└── 2026-04-19--maria-beispiel--V1StGXRa.md
Nachher:
vaults/recherche/
├── content/
│ └── (leer, sofern das die einzige Entität war)
└── .apparat/
└── trash/
└── 2026-04-19--maria-beispiel--V1StGXRa.md
Verwiesen andere Notizen auf die Entität, liegt neben der Trash-Datei zusätzlich ein kleines Bündel. Es hält nicht ganze Datei-Kopien fest, sondern nur das, was beim Aufräumen aus jeder verweisenden Notiz entfernt wurde (welche Beziehung, welcher Textlink) — die Grundlage dafür, dass die Wiederherstellung genau diese Verweise wieder einsetzen kann:
.apparat/trash/.bundles/V1StGXRa/ └── manifest.json (welche Verweise je Notiz entfernt wurden)
Der Dateiname der gelöschten Entität bleibt unverändert — Datum, Slug und NanoID wandern eins zu eins mit. Im Frontmatter stehen jetzt zwei zusätzliche Felder:
deleted: '2026-04-28' updated: '2026-04-28T09:15:00+00:00'
deleted ist tagesgenau; die Uhrzeit des Löschvorgangs steckt im gleichzeitig aktualisierten updated-Feld. Die restlichen Frontmatter-Felder und der Fließtext bleiben bit-identisch erhalten.
Begleitwirkungen
Verweise aus anderen Notizen auf die gelöschte Entität räumt Apparat im selben Vorgang mit auf — sowohl Beziehungen im Frontmatter als auch Links im Fließtext. Ein Textlink wird dabei auf seinen lesbaren Beschriftungstext zurückgestutzt (aus [Maria Beispiel](…) wird schlicht Maria Beispiel), sodass keine ins Leere zeigenden Links zurückbleiben. Was dabei entfernt wurde, hält das Bündel als gezieltes Gegenstück fest — die Wiederherstellung setzt deshalb genau diese Verweise wieder ein, statt ganze Dateien zurückzurollen; zwischenzeitliche Bearbeitungen der verweisenden Notizen bleiben dabei erhalten. Welche Notizen angefasst wurden, meldet das Kommando nach der Löschung.
Binärdateien unter assets/, auf die die Entität verwies, bleiben bewusst liegen — dieselbe Datei kann von mehreren Entitäten genutzt werden, deshalb löscht Apparat keine Anhänge mit. Die freigegebene NanoID wird nie wiederverwendet: auch nach vault trash empty bleibt sie als Tombstone belegt, damit alte Verweise nie versehentlich auf eine andere Entität zeigen.
Wiederherstellung und endgültiges Entsorgen
vault trash list— zeigt, was aktuell im Trash liegt.vault trash restore <id>— holt die Datei aus dem Trash zurück nachcontent/, entferntdeleted, setztupdatedneu und stellt die zuvor bereinigten Verweise in den anderen Notizen wieder her.vault trash empty [<id>]— entfernt die Datei endgültig, räumt das Sicherungsbündel weg und hinterlässt einen Tombstone-Eintrag in.apparat/tombstones.yaml.
Der Trash bleibt ein normaler Ordner: eine versehentlich gelöschte Entität lässt sich notfalls auch über den Dateimanager wieder nach content/ verschieben. Die offiziellen Kommandos oben sind aber der zuverlässige Weg — nur sie nehmen auch die Verweis-Bereinigung in den anderen Notizen wieder zurück.
Fehler
- „No entity with id "…" in vault "…"" — die NanoID existiert im gewählten Vault nicht, jedenfalls nicht in
content/. Eventuell ist die Entität bereits gelöscht? Schau in.apparat/trash/nach. - „Entity id "…" is not a valid NanoId" — das übergebene Argument hat nicht das NanoID-Format
[A-Za-z0-9]{8}. Typisch: eine Dateinamen-Komponente versehentlich als ID übergeben. - „A trash entry already exists at "…"" — im Trash liegt bereits eine Datei mit demselben Namen. Das sollte in normaler Benutzung nie vorkommen; bevor du weiter machst, wirf einen Blick in den Trash und kläre, was dort existiert.
- „Refusing to delete without --force in non-interactive mode." — du musst im
--no-interaction-Modus explizit--forcemitgeben.