Deletion Request Detail
What the Screen Is For
This proposed page brings one deletion decision and its progress together. Staff can preserve the workspace while the decision is reversible, then follow removal and inspect the retained outcome.
What It Shows and Lets People Do
Read the request’s copied identity, reason, dates, action facts, failure summary, removal counts and verification. Detail includes notice records and job references; job snapshots require the shared job reads. Hold, release and cancel submit a reason and the reviewed request version under their respective permissions. Schedule resume and purge retry need deletion-request authority, but their current routes take neither a reason nor a version.
States and Errors
Hide preservation actions once execution starts, and explain a race that the service refuses because destruction has begun. Reload after a stale-version refusal. Offer schedule recovery for an eligible stopped watcher and purge retry for a failed removal. Completion keeps the page readable without preservation actions; a missing external ledger can still require operational recovery.
Patterns It Must Respect
The documented detail requirement uses confirmation for consequential actions and links to shared job inspection. Layout, dialogs and a notice table remain proposed patterns because the console implementation is outside the read scope. The service cannot currently fulfill a requirement that every action submits a reason and version.