TenantAtlas/docs/ui-ux-enterprise-audit

Tenantial Enterprise UI Audit

Spec 323 establishes the docs-only UI Design Registry baseline for Tenantial/TenantPilot. It records what UI surfaces exist, how they are classified, which pages were reviewed in the browser, and which later design lane should own each surface.

This audit did not change runtime UI, routes, authorization, database schema, business logic, tests, assets, packages, queues, scheduler, or deployment scripts.

Outputs

• route-inventory.md: master route/page inventory with audit IDs, scope, archetype, design depth, repo-truth level, screenshots, reports, and notes.
• page-reports/: concise page-level reports for reviewed or browser-blocked pages.
• design-coverage-matrix.md: roll-up counts by area, archetype, design depth, and missing coverage.
• strategic-surfaces.md: P0/P1/P2 strategic pages that need individual target mockups or explicit product treatment.
• grouped-follow-up-candidates.md: grouped later specs so small pages do not become one spec per page.
• unresolved-pages.md: browser blockers, record/detail routes requiring seeded data, and manual-review surfaces.
• screenshots/desktop/: desktop current-state screenshots and blocker evidence from the local browser pass.
• templates/: reusable templates for future UI audit updates.

Discovery Basis

Spec 323 used multiple repo-based discovery methods:

• cd apps/platform && ./vendor/bin/sail artisan route:list --json
• Laravel Boost route listing for non-vendor route confirmation
• File discovery in apps/platform/app/Filament/Pages, Resources, Clusters, System/Pages, Livewire, resources/views, and routes
• Panel inspection in apps/platform/app/Providers/Filament and apps/platform/bootstrap/providers.php
• Navigation inspection through WorkspaceHubRegistry, WorkspaceSidebarNavigation, and AdminSurfaceScope
• Browser pass through http://localhost/admin/local/smoke-login?redirect=/admin

The browser pass used the existing local Spec 180 smoke fixture. No seeders, factories, runtime fixtures, or app code were added to make pages easier to capture.

Classification Model

Every inventory row receives:

• Primary archetype: one of the allowed Spec 323 page archetypes.
• Design depth: Strategic Surface, Domain Pattern Surface, Design-System Cleanup Surface, Internal / Deprecated / Hidden, or Manual Review Required.
• Repo truth: repo-verified, plausible-existing, foundation-only, spec-only, conceptual-future-state, or unknown.

Repo-truth labels are intentionally strict. A page can be repo-verified as a route while still requiring manual review for its final product treatment if auth, data, record state, or provider state blocks meaningful browser inspection.

Reading The Audit

Start with design-coverage-matrix.md for counts and gaps, then use route-inventory.md for row-level classification. Page reports provide the first design review for strategic and representative domain surfaces. unresolved-pages.md is the blocker ledger; a row there is not a product claim.

Screenshot links are current-state evidence only. They are not target mockups and must not be treated as approved future-state UI.

Ongoing Design Coverage Gate

After Spec 323, every UI-relevant feature must update this registry when it introduces or materially changes a reachable page, modal, drawer, form, table, action, or customer-facing state.

The mechanical PR guard is scripts/check-ui-productization-coverage. The PR fast-feedback workflow runs it against origin/dev: if guarded UI surface paths change under apps/platform/app/Filament/, apps/platform/app/Support/Navigation/, apps/platform/app/Providers/Filament/, apps/platform/resources/views/, apps/platform/app/Livewire/, or apps/platform/routes/, the PR must also update a UI coverage artifact or the active spec must contain a checked - [x] No UI surface impact decision.

Required close-out for new UI surfaces:

• Add or update a row in route-inventory.md.
• Assign primary archetype, design depth, and repo-truth level.
• Link to an existing page report, domain pattern, component pattern, or unresolved blocker.
• Add a screenshot when the page is strategic or materially different from an existing pattern.
• Add a page report when the change introduces a new product decision, workflow, dangerous action, or customer-facing experience.
• Update design-coverage-matrix.md counts.
• Add unresolved/manual-review entries when the surface cannot be reviewed.

Standard UI/UX Coverage Requirements checklist:

• Workspace, environment, tenant, and provider context are visible where the user can act on scoped data.
• Empty, loading, stale, unknown, partial, failed, and disconnected states are visually distinct from healthy states.
• Dangerous or irreversible actions are identified in the relevant page report and require confirmation, authorization, and audit continuity in the implementation spec.
• Customer-facing and auditor-facing surfaces avoid raw-first data, unsupported compliance claims, and internal-only terminology.
• Tables, filters, forms, drawers, modals, and actions are mapped to an existing domain pattern or a new target pattern.
• Strategic surfaces have a target artifact before implementation changes rely on them.
• Any page that cannot be reviewed is recorded in unresolved-pages.md with the blocking reason.

Decision model:

• New strategic page: individual target experience/mockup and follow-up spec.
• Normal domain page: map to a shared domain pattern and grouped follow-up.
• Small admin/utility page: map to design-system cleanup rules.
• Modal/drawer/action/state: map to a component/state pattern or page report section.
• Internal or experimental surface: mark internal/manual-review and avoid customer/product claims.

Baseline Counts

• UI route/page inventory rows: 98.
• Reviewed/browser-probed pages with reports: 15.
• Desktop screenshots captured: 15 total, including 12 page screenshots and 3 blocker evidence screenshots.
• Strategic surface rows identified: 44.
• Unresolved/manual-review entries: 32.

Tablet and mobile screenshots were intentionally not captured in this pass. Spec 323 permits bounded browser work; responsive screenshots should be added by the later strategic mockup and implementation-wave specs.