# UI Bloat Pattern Registry

Verification level: derived from existing implementation using Spec 368 audit findings and recommendations.

## Pattern 1: Repeated Lifecycle Or Status Language

- **Observed in**: Operations, Backup, Restore, Customer Review.
- **Impact**: Dilutes the primary decision and makes healthy pages feel busy.
- **Rule**: One first-viewport block owns status, reason, impact, and next action.
- **Allowed exception**: row-level badges for independent rows.

## Pattern 2: Zero Metric Card Spam

- **Observed in**: Environment Dashboard, Operations Hub, Restore Run.
- **Impact**: No-action states look like dashboards of warnings.
- **Rule**: Suppress zero cards when the primary decision already says no action is needed.
- **Allowed exception**: zero is itself proof or audit-significant.

## Pattern 3: Technical Metadata In Main Content

- **Observed in**: Backup Set, Baseline Profile, OperationRun.
- **Impact**: Operators parse internals before the decision.
- **Rule**: Move IDs, timing, normalization lineage, provider details, and operation context to sidebar or collapsed details.
- **Allowed exception**: explicit diagnostic/system surface.

## Pattern 4: Shell Chrome Density

- **Observed in**: most captured admin/customer pages.
- **Impact**: Page question is delayed below navigation, notification replay, and repeated context.
- **Rule**: First viewport must keep the page's current question visible.
- **Allowed exception**: critical active warning or blocking context.

## Pattern 5: Evidence And Diagnostics Ambiguity

- **Observed in**: Evidence Snapshot, Required Permissions, System Panel blocked/partial audit.
- **Impact**: Reviewers cannot tell whether a claim is supported by evidence, diagnostics, or unverified runtime state.
- **Rule**: Evidence proves claims; diagnostics explain failure. Keep them visually and verbally separate.
- **Allowed exception**: support surfaces may show both, but still label them separately.

## Pattern 6: Provider Readiness Inference

- **Observed in**: Provider Connections list.
- **Impact**: Operators infer readiness from capability/config columns instead of seeing a primary readiness decision.
- **Rule**: Configuration surfaces lead with readiness, blocker reason, required action, and affected scope.

## Pattern 7: Customer-Safe Surface Density

- **Observed in**: Customer Review Workspace.
- **Impact**: Good customer-safe content still demands too much scanning.
- **Rule**: Customer/auditor first viewport shows outcome, limitation, evidence/report availability, accepted risks when relevant, and one handoff/review action.