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
135 lines
5.3 KiB
Markdown
135 lines
5.3 KiB
Markdown
# Governance Inbox Target Experience Brief
|
|
|
|
## Metadata
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| Surface ID | UI-028 |
|
|
| Route | `/admin/governance/inbox` |
|
|
| Source screenshot | `../screenshots/desktop/ui-004-governance-inbox.png` |
|
|
| Source page report | `../page-reports/ui-004-governance-inbox.md` |
|
|
| Target sidecar | `../target-images/target/governance-inbox-target.md` |
|
|
| Primary persona | Governance operator |
|
|
| Secondary personas | Manager, auditor, support reviewer |
|
|
| Repo-truth posture | Source route and screenshot are `repo-verified`; target composition is direction only. |
|
|
|
|
## Current-State Snapshot
|
|
|
|
The page is positioned as a decision queue. The report says it must make pending work, reason, owner, impact, and next action unmistakable.
|
|
|
|
## Current-State Productization Problems
|
|
|
|
- Queue-clearing action model is not sharp enough.
|
|
- Evidence and decision status can blend with diagnostics.
|
|
- Customer-safe downstream wording needs review before outputs feed reviews.
|
|
|
|
## Target User Promise
|
|
|
|
In five seconds, an operator knows which governance decision is waiting, why it matters, and which action resolves it.
|
|
|
|
## First-Five-Seconds Target
|
|
|
|
Show decision categories, overdue/age posture, one selected priority decision, evidence basis, and the recommended next action.
|
|
|
|
## Primary Decision
|
|
|
|
Approve, reject, accept risk, assign, or escalate the highest-priority decision item.
|
|
|
|
## Primary Action
|
|
|
|
Review decision.
|
|
|
|
## Secondary Actions
|
|
|
|
Assign owner, request evidence, open finding, open review context, filter by due state.
|
|
|
|
## Target Information Hierarchy
|
|
|
|
1. Governance queue posture.
|
|
2. Priority decision item.
|
|
3. Reason, impact, owner, due state.
|
|
4. Evidence basis.
|
|
5. Action options.
|
|
6. Diagnostics and history.
|
|
|
|
## Main-View Keep / Promote / Simplify
|
|
|
|
| Treatment | Elements |
|
|
| --- | --- |
|
|
| Keep | Pending decision type, impact, scope, owner, age, evidence links. |
|
|
| Promote | Recommended next action and why this item is first. |
|
|
| Simplify | Raw reason ownership, payload detail, and equal approve/reject/action buttons. |
|
|
|
|
## Detail Drawer Treatment
|
|
|
|
Decision drawer should show the item summary, evidence basis, actor history, customer-safe summary, and action consequences before any confirmation.
|
|
|
|
## Advanced/Admin Treatment
|
|
|
|
Policy, internal reason ownership, and raw payload diagnostics stay secondary and support-gated where needed.
|
|
|
|
## Hidden/Removed Default Elements
|
|
|
|
Hide raw JSON, fingerprints, internal reason families, and provider diagnostics from the default queue.
|
|
|
|
## Target Layout Direction
|
|
|
|
Use a decision workbench: queue filters on top, priority decision column, evidence/context column, and action drawer.
|
|
|
|
## Visual Target Direction
|
|
|
|
Dark decision surface with precise spacing, amber for due/attention, coral for blocked or risky decisions, mint only for verified permitted next action, and violet for evidence links.
|
|
|
|
## Status/Trust Model
|
|
|
|
Separate decision status, evidence completeness, risk/impact, and lifecycle age. Do not use a single "good/bad" badge.
|
|
|
|
## Dangerous Actions
|
|
|
|
Approve, reject, accept risk, close, or escalate actions must be authorized server-side, confirmation-gated where high impact, and audit logged in later implementation.
|
|
|
|
## Customer-Safe Review Notes
|
|
|
|
Queue copy can feed customer review summaries, but default operator diagnostics must remain hidden from customer-readable outputs.
|
|
|
|
## Workspace/Environment Context
|
|
|
|
Workspace context is visible. Environment-bound decisions must show environment and tenant-safe scope.
|
|
|
|
## Empty / Loading / Error States
|
|
|
|
Empty state should say no governance decisions need action and offer one link to decision register. Loading preserves filters. Error state states whether the queue, evidence, or entitlement context failed.
|
|
|
|
## Accessibility Notes
|
|
|
|
Decision priority must not rely on color. Action consequences should be screen-reader readable before confirmation.
|
|
|
|
## Repo-Truth Classification
|
|
|
|
| Target element | Classification | Notes |
|
|
| --- | --- | --- |
|
|
| Governance inbox route and screenshot | repo-verified | Spec 323 browser pass reached the route. |
|
|
| Decision queue concept | repo-verified | Page report confirms intent. |
|
|
| Recommended next action | plausible-existing | Needs domain mapping in later implementation. |
|
|
| Customer-safe summary | foundation-only | Required by product direction, exact copy needs validation. |
|
|
| Unified decision taxonomy | conceptual-future-state | Must not be created in this spec. |
|
|
|
|
## Screenshot-Anchored Image Prompt
|
|
|
|
Start from `ui-004-governance-inbox.png`. Create a target design direction, not runtime implementation. Preserve the governance decision queue. Show pending decision posture, selected priority item, reason, impact, owner, due state, evidence basis, and one primary Review decision action. Keep diagnostics secondary and customer-safe language visible. Avoid generic SaaS dashboard layouts, fake compliance claims, green success without verification, placeholder text, raw debug defaults, and runtime implementation claims.
|
|
|
|
## Implementation Pattern Requirements
|
|
|
|
- One dominant decision action.
|
|
- Evidence-first decision drawer.
|
|
- Capability-aware and audit-backed mutations.
|
|
- Customer-safe summary separated from operator diagnostics.
|
|
|
|
## Later Implementation Candidate
|
|
|
|
Governance Inbox decision experience.
|
|
|
|
## Non-Goals For Later Implementation
|
|
|
|
Do not implement a broad governance taxonomy or status framework unless later specs prove behavioral consequences.
|