ahmido
3eff4d8579
## Summary - add the Spec 325 artifacts for screenshot-anchored strategic target images - update the UI/UX enterprise audit documents to capture strategic surfaces and grouped follow-up candidates - add supporting follow-up specs, target experience briefs, and target image assets for the audit workflow ## Testing - not run (documentation/spec artifact changes only) Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #385
136 lines
5.9 KiB
Markdown
136 lines
5.9 KiB
Markdown
# 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.
|