Automated PR created by Codex via Gitea API. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #461
49 lines
2.2 KiB
Markdown
49 lines
2.2 KiB
Markdown
# UI-014 Restore Runs
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| Route | `/admin/workspaces/{workspace}/environments/{environment}/restore-runs` |
|
|
| Source | `RestoreRunResource` |
|
|
| Area / scope | Backup / restore / environment |
|
|
| Archetype | Backup / Restore |
|
|
| Design depth | Strategic Surface |
|
|
| Repo truth | repo-verified route; browser blocked |
|
|
| Screenshot | `../screenshots/desktop/ui-014-restore-runs.png` |
|
|
| Browser status | Local Spec 180 fixture returned Forbidden; Spec 390 adds create/view readiness guidance and requires a focused smoke fixture. |
|
|
|
|
## First Five Seconds
|
|
|
|
The browser pass could not evaluate the product page because restore capability/state was unavailable. The route is still strategic because restore is the highest-risk operator workflow in the product.
|
|
|
|
## Productization Review
|
|
|
|
- Decision-first: not evaluated in browser.
|
|
- Evidence-first: restore preview, request, result, and recovery proof must be central.
|
|
- Context: environment-bound route.
|
|
- Customer/auditor safety: high after execution.
|
|
- Diagnostics: raw provider responses must stay secondary.
|
|
|
|
## Information Inventory
|
|
|
|
Expected default content should distinguish restore intent, simulation/preview, validation, requested items, execution state, result truth, and recovery evidence.
|
|
|
|
## Dangerous Actions
|
|
|
|
Restore execution is destructive/high-impact. Target state must include dry-run/preview, explicit confirmation, audit, OperationRun continuity, and post-run evidence.
|
|
|
|
## Scores
|
|
|
|
| IA | Density | User Clarity | Sellability | Disclosure | Hierarchy | DS Fit | A11y | Responsive | Components | UX Writing | Perf |
|
|
| ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
|
|
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|
|
|
|
## Top Issues
|
|
|
|
1. Browser review blocked by local capability/data.
|
|
2. Restore workflow needs continued browser proof for broader failure/conflict/confirmation states after Spec 390 readiness guidance.
|
|
3. Preview/result/evidence truth must be separated visually.
|
|
|
|
## Target Direction
|
|
|
|
P0 restore safety implementation-wave smoke with an authorized fixture. Spec 390 covers Restore-local readiness and next-safe-action guidance on create/view; list and broader terminal/failure states still need follow-up coverage.
|