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
5.4 KiB
Operations Hub Target Experience Brief
Metadata
| Field | Value |
|---|---|
| Surface ID | UI-016 |
| Route | /admin/workspaces/{workspace}/operations |
| Source screenshot | ../screenshots/desktop/ui-003-operations.png |
| Source page report | ../page-reports/ui-003-operations.md |
| Target sidecar | ../target-images/target/operations-hub-target.md |
| Primary persona | Operations responder |
| Secondary personas | Manager, support reviewer, auditor |
| Repo-truth posture | Source route and screenshot are repo-verified; target composition is direction only. |
Current-State Snapshot
The page reads as an operations monitor and exposes OperationRun execution truth. The page report says active work, terminal follow-up, and diagnostic history need a sharper split.
Current-State Productization Problems
- Chronological run history can overpower the current operational decision.
- Execution state can be confused with governance health.
- Run detail, evidence, and result links need consistent hierarchy.
Target User Promise
In five seconds, an operator knows what is running, what failed or needs follow-up, and where the run proof lives.
First-Five-Seconds Target
Show an operation status strip for active, failed, partial, and completed runs, then a prioritized follow-up queue.
Primary Decision
Which operation needs attention now?
Primary Action
Open failed run.
Secondary Actions
Filter runs, open related artifact, inspect diagnostics, retry where authorized and confirmed.
Target Information Hierarchy
- Workspace operations posture.
- Attention-needed run queue.
- Active run progress.
- Recent terminal outcomes.
- Evidence/artifact links.
- Raw diagnostics.
Main-View Keep / Promote / Simplify
| Treatment | Elements |
|---|---|
| Keep | Run list, status, timestamps, source workflow, links to run detail. |
| Promote | Failed/blocked follow-up, reason, affected environment, next action. |
| Simplify | Pure chronological table, raw events as first-read content, equal action buttons. |
Detail Drawer Treatment
Run drawer should show status, outcome, summary counts, artifact links, initiator, tenant/environment scope, and diagnostics collapsed behind support detail.
Advanced/Admin Treatment
Retry/cancel actions require capability-aware visibility, confirmation where high impact, and audit continuity. Raw logs stay support-gated.
Hidden/Removed Default Elements
Hide copied payloads, provider raw errors, stack traces, and internal reason ownership from the default table.
Target Layout Direction
Use a monitoring header, a left attention queue, an active-run progress area, and a right proof/diagnostics rail.
Visual Target Direction
Dark operational console with subdued panels, amber/coral for follow-up states, violet proof links, and mint only for verified safe terminal outcomes or permitted actions.
Status/Trust Model
Keep execution status, operation outcome, data completeness, and governance result separate.
Dangerous Actions
Retry, cancel, rerun, or execute-related actions must use action handlers, authorization, confirmation where relevant, and OperationRun/audit continuity in later implementation.
Customer-Safe Review Notes
Not customer-facing by default. Customer-readable operation summaries must hide raw diagnostics and use evidence/result links.
Workspace/Environment Context
Workspace context is visible. Environment-bound runs must show environment and entitlement-safe links.
Empty / Loading / Error States
Empty state should say no operations are currently recorded and link to relevant workflow start points only when permitted. Loading should preserve filters. Error state distinguishes failed run loading from app runtime failure.
Accessibility Notes
Run status must be text-readable, sortable, and not color-only. Focus order should prioritize attention-needed runs.
Repo-Truth Classification
| Target element | Classification | Notes |
|---|---|---|
| Operations route and screenshot | repo-verified | Spec 323 browser pass reached the route. |
| OperationRun records | repo-verified | Existing model and source surface. |
| Attention-needed grouping | plausible-existing | Derived from run status/outcome, exact grouping needs later spec. |
| Artifact proof rail | foundation-only | OperationRun links exist, exact artifact mapping needs verification. |
| Retry/cancel action set | unknown | Must be verified per operation family. |
Screenshot-Anchored Image Prompt
Start from ui-003-operations.png. Create a target design direction, not runtime implementation. Preserve operations monitoring. Show active runs, failed/partial follow-up, reason, environment scope, primary open-run action, and evidence/artifact links. Keep raw diagnostics secondary. Make execution truth visibly separate from governance health. Avoid generic blue SaaS, fake compliance claims, green success without verification, placeholder text, decorative charts, and runtime implementation claims.
Implementation Pattern Requirements
- Reuse central OperationRun UX contracts.
- Use consistent run status and outcome grammar.
- Keep progress in widgets/run detail, not as broad product health.
- Hide raw/support diagnostics by default.
Later Implementation Candidate
Operations Hub productization.
Non-Goals For Later Implementation
Do not create a separate operation notification or run-link language outside the shared OperationRun UX path.