vault trash restore

Holt eine soft-gelöschte Notiz aus dem Trash zurück nach content/ — oder eine aussortierte Datei zurück nach assets/. Umkehrung von entity delete bzw. des Datei-Löschens im Aufräumen-Bereich.

Apparat erkennt anhand der NanoID selbst, ob es sich um eine Notiz oder eine Datei handelt, und legt sie an der richtigen Stelle wieder ab.

Einfachster Fall

apparat vault trash restore V1StGXRa

Apparat sucht die Entität mit dieser NanoID unter .apparat/trash/, zeigt ihren Titel und fragt nach Bestätigung:

About to restore "Maria Beispiel" (id: V1StGXRa, type: person, deleted: 2026-04-20) to vault "recherche"
  → file:    2026-04-19--maria-beispiel--V1StGXRa.md
  → moves back to content/
Continue? [Y/n]

Der Default ist Y — anders als bei entity delete, das N als Default hat. Restore ist die harmlose Richtung; wer die Id getippt hat, will in aller Regel restoren.

Bei einer Datei sieht die Rückfrage entsprechend aus und die Datei wandert nach assets/ zurück:

About to restore asset "2026-04-19--budget-chart--As3Df9Gh.png" (id: As3Df9Gh, type: image/png) to vault "recherche"
  → moves back to assets/
Continue? [Y/n]

Die zugehörige .sha256-Prüfsummen­datei wandert automatisch mit zurück.

Mit yes (oder Enter) wandert die Datei atomar zurück nach content/, das deleted-Feld wird aus dem Frontmatter entfernt, updated bekommt einen frischen Zeitstempel. Alle anderen Felder und der Fließtext bleiben bit-identisch. Hat die Löschung Verweise in anderen Notizen mit-bereinigt, setzt der Restore genau diese Verweise in den betroffenen Notizen wieder — gezielt, nicht durch Zurückrollen der ganzen Datei; welche Notizen das waren, meldet das Kommando. Dadurch bleiben zwischenzeitliche Bearbeitungen einer verweisenden Notiz erhalten, und der Verweis kehrt trotzdem zurück; einen Verweis, den du in der Zwischenzeit von Hand wieder angelegt hast, lässt der Restore unangetastet (keine Dopplung). Nur wo der verlinkte Text inzwischen umgeschrieben oder die verweisende Notiz entfernt wurde, lässt sich ein einzelner Verweis nicht mehr setzen — solche Fälle weist das Kommando als übersprungen aus.

Nicht-interaktiver Modus

Im --no-interaction-Modus (Skripte, CI) arbeitet vault trash restore still — kein Prompt, kein --force nötig:

apparat vault trash restore V1StGXRa --no-interaction
# → funktioniert direkt.

Das ist der absichtliche Unterschied zu entity delete, das im Skript-Kontext --force verlangt. Restore lässt sich trivial rückgängig machen (einfach wieder entity delete), die --force-Hürde wäre hier rituell ohne Substanz.

Vault-Auswahl

Wie bei allen Kommandos in diesem Namespace: ohne --vault greift die übliche Auto-Lokalisierung (CWD-Erkennung, einziger registrierter Vault, interaktive Auswahl). Explizit:

apparat vault trash restore V1StGXRa --vault=arbeit
apparat vault trash restore V1StGXRa --vault=/home/max/vaults/recherche

Was nach der Wiederherstellung auf der Platte liegt

Vorher (nach einem früheren entity delete V1StGXRa):

vaults/recherche/
└── .apparat/
    └── trash/
        └── 2026-04-19--maria-beispiel--V1StGXRa.md

Nachher (nach vault trash restore V1StGXRa):

vaults/recherche/
├── content/
│   └── 2026-04-19--maria-beispiel--V1StGXRa.md
└── .apparat/
    └── trash/
        └── (leer, sofern das die einzige Trash-Datei war)

Im Frontmatter der restaurierten Datei ist das deleted-Feld verschwunden, updated zeigt den Zeitpunkt des Restores:

updated: '2026-04-28T12:10:00+00:00'

Datum, Slug und NanoID im Dateinamen bleiben eins zu eins erhalten — Link-Ziele in fremden Entitäten, die die NanoID enthalten, bleiben gültig.

Verhalten in Sonderfällen

Wenn du die Datei im Trash von Hand bearbeitet hast (etwa deleted manuell überschrieben), wird das Feld beim Restore trotzdem vollständig entfernt; das updated-Feld wird neu gesetzt. Sollte unter content/ bereits eine Datei mit demselben Namen liegen, bricht Apparat mit einem klaren Fehler ab und überlässt dir die Auflösung — in der normalen Nutzung kann das nicht passieren, weil NanoIDs einmalig sind.

Fehler