TenantAtlas/docs/ui-ux-enterprise-audit/target-experience-briefs/restore-safety-workflow.md

# Restore Safety Workflow Target Experience Brief

## Metadata

| Field | Value |
| --- | --- |
| Surface IDs | UI-053, UI-054 |
| Route | `/admin/workspaces/{workspace}/environments/{environment}/restore-runs` plus create/view family |
| Source screenshot | `../screenshots/desktop/ui-014-restore-runs.png` |
| Source page report | `../page-reports/ui-014-restore-runs.md` |
| Target sidecar | `../target-images/target/restore-safety-workflow-target.md` |
| Primary persona | Restore operator / approver |
| Secondary personas | Workspace owner, auditor, support reviewer |
| Repo-truth posture | Route is `repo-verified`; browser review was blocked by capability/state. Target composition is direction only. |

## Current-State Snapshot

The browser pass could not evaluate the product page because restore capability/state was unavailable. The page remains strategic because restore is the highest-risk operator workflow in the product. Spec 390 implements a bounded runtime slice: Restore-local readiness guidance and next-safe-action copy on the existing create/view surfaces without new persistence, navigation, or execution semantics.

## Current-State Productization Problems

- Actual workflow hierarchy was not reviewed in browser.
- Preview, validation, execution, result, and evidence truth need separation.
- Restore must not look like an ordinary create/list action.

## Target User Promise

In five seconds, a restore operator understands the restore source, affected scope, safety gate state, risk, required confirmation, and proof trail.

## First-Five-Seconds Target

Show a safety workflow with source backup, target environment, simulation/preview state, blockers, explicit confirmation state, and OperationRun/evidence result.

## Primary Decision

Is this restore safe and authorized to execute?

## Primary Action

Review restore preview.

## Secondary Actions

Adjust scope, run validation, open source backup, open operation, inspect evidence, cancel request.

## Target Information Hierarchy

1. Restore scope and mutation target.
2. Source backup and target environment.
3. Safety gates and validation.
4. Preview impact.
5. Confirmation requirements.
6. Execution result and evidence.
7. Raw diagnostics.

## Main-View Keep / Promote / Simplify

| Treatment | Elements |
| --- | --- |
| Keep | Restore run history, source backup, target environment, status, operation link. |
| Promote | Mutation scope, safety gates, preview result, hard confirmation. |
| Simplify | Generic list/create framing, raw provider responses, equal execute/navigation buttons. |

## Detail Drawer Treatment

Restore drawer should show safety gate evidence, item-level preview summary, conflict warnings, confirmation text, and post-run evidence. Diagnostics remain collapsed.

## Advanced/Admin Treatment

Raw provider results, retry controls, override paths, and partial-failure diagnostics are support/operator-only and capability-gated.

## Hidden/Removed Default Elements

Hide raw payloads, provider response dumps, and debug-only IDs from first view.

## Target Layout Direction

Use a stepper/wizard-like safety flow: configure scope, run validation, review preview, hard confirm, execute, inspect evidence.

## Visual Target Direction

Dark high-friction workflow with coral for irreversible risk, amber for validation gaps, mint only for simulation-safe or verified allowed steps, and strong scope callouts.

## Status/Trust Model

Separate simulation/preview state, validation completeness, execution status, result truth, and evidence availability.

## Dangerous Actions

Restore execution is destructive/high-impact. Later implementation must include dry-run/preview, explicit confirmation, authorization, audit logging, OperationRun continuity, and post-run evidence.

## Customer-Safe Review Notes

Post-restore evidence summaries may be customer/auditor-facing, but raw provider diagnostics and internal remediation notes must remain hidden.

## Workspace/Environment Context

Workspace and target environment are always visible. The source backup and affected resource scope must be visible before execution.

## Empty / Loading / Error States

Empty state should explain no restore runs exist and show safe prerequisites, not a casual execute CTA. Loading preserves scope. Error state distinguishes validation failure from execution failure.

## Accessibility Notes

The safety stepper must expose step state in text. Confirmation copy must be readable before the irreversible action.

## Repo-Truth Classification

| Target element | Classification | Notes |
| --- | --- | --- |
| Restore route family | repo-verified | Route exists, browser fixture blocked. |
| RestoreRun model and OperationRun relation | repo-verified | Existing model inventory includes RestoreRun and OperationRun. |
| Safety gate stepper | foundation-only | Required by product safety rules, exact runtime steps need later spec. |
| Hard confirmation copy | spec-only | Target direction only. |
| Partial restore conflict model | conceptual-future-state | Must be verified before implementation. |

## Screenshot-Anchored Image Prompt

Start from `ui-014-restore-runs.png` as blocked current evidence. Create a target design direction, not runtime implementation. Preserve restore execution history and restore-create/view workflow purpose. Show source backup, target environment, mutation scope, safety gates, preview impact, confirmation requirement, OperationRun link, and evidence result. Make restore visibly high-friction. Avoid generic SaaS dashboards, fake compliance claims, green success without verification, placeholder text, casual destructive actions, raw diagnostics by default, and runtime implementation claims.

## Implementation Pattern Requirements

- Restore flow uses configuration, safety checks/simulation, preview, hard confirmation, execute, evidence result.
- Authorization and audit are server-side.
- OperationRun continuity is visible but not the only proof.
- Customer-safe post-result summary separates diagnostics.

## Later Implementation Candidate

Restore safety UX productization.

## Non-Goals For Later Implementation

Do not implement restore execution semantics, provider writes, or compatibility behavior from this target artifact alone. Spec 390 intentionally keeps readiness guidance derived and local while final confirmation, execution, and evidence remain owned by existing Restore and OperationRun paths.