TenantAtlas/specs/266-tenant-dashboard-productization-v1/quickstart.md

# Quickstart — Tenant Dashboard Productization v1

## Preconditions

- Docker is running and the Sail stack for `apps/platform` is available.
- The feature remains inside the existing Laravel monolith and existing tenant/admin plane.
- The canonical tenant landing route already exists at `/admin/t/{tenant}`; this slice productizes it instead of adding a new shell or panel.
- No new persistence, no new governance engine, no new review engine, no new provider-health page, and no heavy new asset strategy are part of this work.

## Intended Implementation Order

1. Review the current tenant dashboard page, existing widget truth seams, current dashboard tests, and the real downstream follow-up surfaces so the productization pass stays inside the existing dashboard family.
2. Build the bounded dashboard summary query/view-model from current findings, risk-exception, governance aggregate, recovery, required-permissions, review, evidence, review-pack, and operation-run truth.
3. Replace the current first-screen stack with one composite dashboard overview surface plus conditional arrival continuity, keeping the page route and tenant context unchanged.
4. Tighten the page header so it exposes at most two visible actions and keeps support utilities out of the dominant first-action plane.
5. Implement the KPI row, recommended-actions card, governance-status digest, recent-operations digest, and aside readiness cards with honest fallback and unavailable states while preserving the decision-first hierarchy on narrower widths without horizontal scrolling.
6. Wire all CTAs to existing repo-real destinations only: Governance Inbox, findings, finding exceptions, operations, required permissions, customer review workspace, tenant review, review pack, and evidence snapshot routes.
7. Preserve tenant-prefilter continuity into canonical admin routes and capability-safe hidden or unavailable states for blocked destinations.
8. Expand the focused dashboard feature suite, add one bounded browser smoke, and run the targeted validation commands plus Pint.

## Targeted Validation Commands (after implementation)

- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Dashboard/TenantDashboardProductizationSummaryTest.php tests/Feature/Dashboard/TenantDashboardProductizationActionsTest.php tests/Feature/Dashboard/TenantDashboardProductizationAuthorizationTest.php tests/Feature/Dashboard/TenantDashboardProductizationReadinessTest.php`
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/TenantDashboardDbOnlyTest.php tests/Feature/Filament/TenantDashboardTruthAlignmentTest.php tests/Feature/Filament/TenantDashboardTenantScopeTest.php tests/Feature/Filament/TenantDashboardArrivalContextTest.php tests/Feature/Filament/TenantDashboardArrivalContextPerformanceTest.php tests/Feature/Rbac/TenantDashboardArrivalContextVisibilityTest.php tests/Feature/Monitoring/OperationsDashboardDrillthroughTest.php`
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Browser/Dashboard/TenantDashboardProductizationSmokeTest.php`
- `export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`

## Planned Smoke Checklist (after implementation)

1. Sign in to the tenant panel and open `/admin/t/{tenant}` for a seeded tenant with governance pressure and review or output signals.
2. Confirm the first screen shows no more than two header actions, no more than four KPI cards, and no more than three recommended actions.
3. Confirm the landing screen is decision-first: posture, reason, impact, and next action appear before tables or raw diagnostics.
4. Follow the primary governance CTA and confirm it lands on a repo-real, tenant-prefiltered surface such as Governance Inbox or findings.
5. Follow the recent-operations link and confirm the canonical operations surface opens with the originating tenant prefilter intact.
6. Confirm provider, risk-exception, review, evidence, and output cards show honest available, absent, or unavailable states and do not invent fake routes.
7. Confirm no raw JSON, long log block, GUID-heavy technical panel, or provider dump is visible by default.
8. Confirm the page remains usable at a common desktop viewport and a common narrow-width viewport without a horizontal scrollbar and without the first screen collapsing into a table-first layout.

## Notes

- Filament v5 already runs on Livewire v4 in this repo.
- Panel providers remain registered through [../../apps/platform/bootstrap/providers.php](../../apps/platform/bootstrap/providers.php); this slice does not add or move providers.
- No new globally searchable resource or search scope is part of this productization pass. Global-search rules remain unchanged.
- No new destructive action belongs on the dashboard shell. If implementation accidentally exposes one, it remains out of scope and must keep confirmation semantics.
- No new registered asset bundle is expected. If future implementation unexpectedly registers a Filament asset, deployment still requires `cd apps/platform && php artisan filament:assets`.
- Provider blockage remains anchored to existing required-permissions truth. This slice does not invent a standalone tenant provider-health surface.
- Customer-safe output remains anchored to existing review, evidence, and review-pack routes only. This slice does not invent a new customer-view route.
- Dashboard Productization v1 remains operator-facing. Customer-safe review consumption beyond repo-real export and review surfaces remains follow-up work for Customer Review Workspace v1.
- Localization debt is intentionally still open here. Mixed German and English dashboard copy remains acceptable for this slice and is deferred to Localization v1.