TenantAtlas/docs/ui-ux-enterprise-audit/target-experience-briefs/environment-dashboard.md

Environment Dashboard Target Experience Brief

Metadata

Field	Value
Surface ID	UI-011
Route	/admin/workspaces/{workspace}/environments/{environment}
Source screenshot	../screenshots/desktop/ui-002-environment-dashboard.png
Source page report	../page-reports/ui-002-environment-dashboard.md
Target sidecar	../target-images/target/environment-dashboard-target.md
Primary persona	Environment operator
Secondary personas	Manager, governance reviewer, support reviewer
Repo-truth posture	Source route and screenshot are repo-verified; target composition is direction only.

Current-State Snapshot

The page makes environment context visible and exposes backup, recovery, verification, reporting, operations, and navigation widgets. The report says too many posture and evidence signals compete for the first decision.

Current-State Productization Problems

• Backup truth, recovery readiness, verification, and operations sit at similar visual weight.
• Dangerous downstream actions do not have a single visible safety hierarchy from this landing state.
• Evidence proof exists conceptually but is not separated from health and navigation.

Target User Promise

In five seconds, an operator knows whether this environment is ready, what blocks readiness, and which safe next action is appropriate.

First-Five-Seconds Target

Show environment posture, blocking reason, latest proof, and one recommended next action before secondary domain cards.

Primary Decision

Is this environment ready, blocked, stale, or requiring review?

Primary Action

Review readiness blockers.

Secondary Actions

Open backup sets, open restore runs, compare baseline, inspect operations, review provider readiness.

Target Information Hierarchy

1. Environment context and readiness posture.
2. Blocking reason and impact.
3. Primary next action.
4. Backup/recovery proof.
5. Governance and operation drilldowns.
6. Diagnostics.

Main-View Keep / Promote / Simplify

Treatment	Elements
Keep	Environment name, workspace context, backup health, recovery readiness, operations.
Promote	Readiness blocker, evidence freshness, mutation scope note for high-impact actions.
Simplify	Equal-weight widgets, repeated links, dense verification diagnostics.

Detail Drawer Treatment

Selected blocker drawer should show scope, reason, affected evidence, latest run, and remediation path. Raw Graph/provider diagnostics remain collapsed.

Advanced/Admin Treatment

Provider diagnostics, raw report payloads, and advanced permission checks stay secondary and capability-gated where needed.

Hidden/Removed Default Elements

Hide raw IDs, provider payloads, and low-level verification details from first view.

Target Layout Direction

Use an environment command header, a readiness decision lane, and compact proof cards. Domain modules sit below as action-oriented summaries.

Visual Target Direction

Dark operational surface with warm neutral panels, amber/coral for blocked or risky posture, mint only for verified safe actions, and violet evidence links.

Status/Trust Model

Separate readiness, backup recency, recovery evidence, execution state, and governance result. Do not collapse them into one health badge.

Dangerous Actions

Backup, restore, provider fixes, and compare actions must show whether they change TenantPilot only, the Microsoft tenant, or simulation-only state before execution.

Customer-Safe Review Notes

Operator-facing default. Customer-safe exports must hide raw diagnostics and explain evidence freshness in plain language.

Workspace/Environment Context

Both workspace and environment are visible in the header and on every actionable blocker.

Empty / Loading / Error States

Empty state should explain that no environment evidence is available yet and offer one setup/check action. Loading state should keep context visible. Error state distinguishes data load failure from provider verification failure.

Accessibility Notes

Status labels need text and icon support. Readiness blockers must be navigable as list items, not only cards.

Repo-Truth Classification

Target element	Classification	Notes
Environment route and screenshot	repo-verified	Spec 323 browser pass reached the route.
Backup and recovery widgets	repo-verified	Present in report.
Readiness blocker lane	plausible-existing	Synthesizes existing signals into target hierarchy.
Mutation-scope labels	foundation-only	Required by constitution, exact runtime copy needs later spec.
Detailed provider diagnostics	conceptual-future-state	Must be verified before implementation.

Screenshot-Anchored Image Prompt

Start from ui-002-environment-dashboard.png. Create a target design direction, not runtime implementation. Preserve the environment command-surface purpose. Show environment readiness, blocker reason, primary action, backup/recovery proof, operation traceability, and secondary domain drilldowns. Keep technical diagnostics secondary. Show workspace and environment context. Avoid generic SaaS dashboards, fake compliance claims, green success without verification, placeholder text, decorative charts, and runtime implementation claims.

Implementation Pattern Requirements

• One readiness decision header.
• Distinct status dimensions for readiness, backup, recovery, operation, and governance.
• Mutation scope visible for high-impact actions.
• Evidence and OperationRun links use shared patterns.

Later Implementation Candidate

Workspace and Environment dashboard productization.

Non-Goals For Later Implementation

Do not create new environment readiness persistence or status families unless a separate spec proves behavioral consequence.