Added browser captures, scorecard, recommendations, and follow-up spec candidates for the UI signal-to-noise browser audit.
104 lines
5.0 KiB
Markdown
104 lines
5.0 KiB
Markdown
# Recommended Follow-up Specs
|
|
|
|
Verification level: derived from browser-verified audit findings and repo-verified surface inventory.
|
|
|
|
## Spec Candidate A - Global Surface Information Architecture Contract v1
|
|
|
|
Goal: Define platform-wide UI rules for decision-first display, metadata separation, zero-state suppression, and progressive disclosure.
|
|
|
|
Why now: The same bloat patterns recur across dashboards, operations, backup, customer review, and provider surfaces.
|
|
|
|
Pages included: shared guidance and examples from Operations Hub, Environment Dashboard, Baseline Compare, Customer Review Workspace.
|
|
|
|
Pages explicitly excluded: mass refactors of individual resource pages.
|
|
|
|
Expected impact: Prevents new UI bloat and gives future specs a stable target.
|
|
|
|
Risk: Over-generalizing into a UI framework. Keep this as rules and examples, not a new abstraction layer.
|
|
|
|
DoD: global rules documented; UI-COV registry alignment checked; no runtime code required unless separately approved.
|
|
|
|
Required screenshots: before examples from this audit and one target mock/example per archetype.
|
|
|
|
Tests/guards: optional static guard proposal only; no app changes in this spec unless approved.
|
|
|
|
## Spec Candidate B - Core Operator View Surfaces Productization Pass v1
|
|
|
|
Goal: Refactor highest-impact operator view pages into calmer decision-first layouts.
|
|
|
|
Why now: OperationRun, Backup Set, Restore Run, and Baseline Profile are restore/audit-critical operator surfaces.
|
|
|
|
Pages included: OperationRun View, Backup Set View, Restore Run View, Baseline Profile View, Baseline Compare.
|
|
|
|
Pages explicitly excluded: customer review workspace and system panel.
|
|
|
|
Expected impact: Faster operator decisions and less technical scanning in critical workflows.
|
|
|
|
Risk: Touching restore/operation UI can regress high-impact admin flows; keep changes page-local and test with Filament/browser smoke.
|
|
|
|
DoD: before/after screenshots; decision-first first viewport; metadata collapsed/sidebar; destructive action behavior unchanged.
|
|
|
|
Required screenshots: desktop default, details expanded, mobile for OperationRun and RestoreRun.
|
|
|
|
Tests/guards: Pest/Livewire action coverage where actions are affected; browser smoke for key view pages.
|
|
|
|
## Spec Candidate C - Customer/Auditor Surface Safety Pass v1
|
|
|
|
Goal: Ensure customer-facing surfaces are readable, evidence-first, and free from internal diagnostics by default.
|
|
|
|
Why now: Customer Review Workspace is strong but dense; evidence detail was not reachable in the available browser context.
|
|
|
|
Pages included: Customer Review Workspace, Environment Review View, Review Pack View, Stored Report View, Evidence Snapshot View.
|
|
|
|
Pages explicitly excluded: operator diagnostics and system panel.
|
|
|
|
Expected impact: Calmer customer/auditor handoff and clearer limitations/evidence readiness.
|
|
|
|
Risk: Hiding useful operator context; preserve explicit details disclosures for support users.
|
|
|
|
DoD: customer-safe first viewport; limitations and export/handoff actions visible; technical details collapsed.
|
|
|
|
Required screenshots: customer default, details expanded, mobile, evidence inaccessible state resolved.
|
|
|
|
Tests/guards: browser smoke for customer-safe text and absence of internal IDs/raw diagnostics in default view.
|
|
|
|
## Spec Candidate D - Diagnostic Surface Separation v1
|
|
|
|
Goal: Move diagnostic and raw technical details into explicit diagnostic surfaces/disclosures and make diagnostic pages action-oriented.
|
|
|
|
Why now: Required Permissions and system panel were blocked in browser context; Environment Diagnostics needs stronger next-check guidance.
|
|
|
|
Pages included: Environment Diagnostics, Required Permissions, Provider Connections, System Ops pages, OperationRun technical detail.
|
|
|
|
Pages explicitly excluded: customer reports except links into diagnostics.
|
|
|
|
Expected impact: Better support workflows without leaking debug/provider language into customer/operator decision surfaces.
|
|
|
|
Risk: Insufficient fixture/auth coverage for system panel; start by documenting access and screenshots.
|
|
|
|
DoD: diagnostic pages lead with failure, likely cause, next check, related operation/evidence; raw payloads collapsed.
|
|
|
|
Required screenshots: provider blocker state, required permissions, system ops login/reachable state.
|
|
|
|
Tests/guards: browser smoke for diagnostics summary and access fixture.
|
|
|
|
## Spec Candidate E - UI Bloat Regression Guard v1
|
|
|
|
Goal: Add lightweight guardrails to detect repeated status, zero-card spam, raw IDs in customer surfaces, and missing primary actions.
|
|
|
|
Why now: Recurring bloat is likely to return with agent-generated UI unless checked.
|
|
|
|
Pages included: guard/checklist docs first; selected smoke pages if implementation is approved.
|
|
|
|
Pages explicitly excluded: direct UI refactors.
|
|
|
|
Expected impact: Prevents future regressions without a large redesign.
|
|
|
|
Risk: Brittle tests if implemented as markup snapshots. Prefer semantic text/structure checks.
|
|
|
|
DoD: checklist and small proof-of-concept guard with explicit exceptions.
|
|
|
|
Required screenshots: examples of pass/fail states from this audit.
|
|
|
|
Tests/guards: one bounded browser/static guard; no broad visual snapshot suite.
|