Deleting a document in Kodori is a soft-delete — the status flips to `tombstoned` but the bytes stay in object storage, the audit trail stays intact, and the document remains fully recoverable during the retention window. /trash is where you go to recover.
## What's there
Every tombstoned document in the workspace, newest-first. Each row shows display name, sensitivity, size, MIME type, who deleted it, and when. Search by name across the bin. Capped at the 100 newest tombstoned docs per view; refine the search to find older entries.
## Restoring
Owners and admins see checkboxes alongside each row plus a "Restore" button at the top.
- Tick one or more rows - Type an optional reason (defaults to "Restored from /trash") - Click Restore
Each restored doc appends `document.restored` to its audit stream alongside whatever tombstoning context it already had. Failures continue past — if 9 of 10 selected docs restore and one fails (say it's bound to a since-released hold whose deny rule is now stale), the panel reports "9 succeeded, 1 failed" and you can drill into the failed doc on /doc/<id>.
## When tombstoned ≠ recoverable
Tombstoning is the soft-delete state; `document.purged` is the hard delete. After a purge sweep runs, the row no longer exists in document_objects and won't appear here. The audit chain still records that the doc once existed, but the bytes are gone. v1 of Kodori does NOT auto-purge tombstoned docs — every purge is operator-initiated. Future revisit: per-tenant configurable hard-delete-after-N-days.