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.

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.