ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
185-workspace-recovery-posture-visibility
TenantAtlas/specs/184-dashboard-recovery-honesty/quickstart.md
ahmido f1a73490e4 feat: finalize dashboard recovery honesty (#215) 
## Summary
- add a dedicated Recovery Readiness dashboard widget for backup posture and recovery evidence
- group Needs Attention items by domain and elevate the recovery call-to-action
- align restore-run and recovery posture tests with the extracted widget and continuity flows
- include the related spec artifacts for 184-dashboard-recovery-honesty

## Verification
- `cd /Users/ahmeddarrazi/Documents/projects/TenantAtlas/apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
- `cd /Users/ahmeddarrazi/Documents/projects/TenantAtlas/apps/platform && ./vendor/bin/sail artisan test --compact --filter="DashboardKpisWidget|DashboardRecoveryPosture|TenantDashboardDbOnly|TenantpilotSeedBackupHealthBrowserFixtureCommand|NeedsAttentionWidget"`
- browser smoke verified on the calm, unvalidated, and weakened dashboard states

## Notes
- Livewire v4.0+ compliant with Filament v5
- no panel provider changes; Laravel 11+ provider registration remains in `bootstrap/providers.php`
- Recovery Readiness stays within the existing tenant dashboard asset strategy; no new Filament asset registration required

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #215
2026-04-08 23:21:36 +00:00

3.9 KiB
Raw Permalink Blame History

Quickstart: Dashboard Recovery Posture Honesty

Prerequisites

  1. Start the application services if they are not already running:
cd apps/platform && ./vendor/bin/sail up -d
  1. Use a tenant member account with at least readonly access for verification.

Focused Automated Verification

Run the smallest relevant test set first:

cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/DashboardKpisWidgetTest.php
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/NeedsAttentionWidgetTest.php
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/RestoreResultAttentionSurfaceTest.php
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/RestoreRunUiEnforcementTest.php
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Rbac/DashboardRecoveryPostureVisibilityTest.php
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/RestoreSafety/RestoreResultAttentionTest.php

When implementation adds the new continuity and performance guard files, run them as well. The performance regression must exercise both the tenant dashboard and the restore-run list render paths:

cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/RestoreRunListContinuityTest.php
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/DashboardRecoveryPosturePerformanceTest.php

Format after code changes:

cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent

Manual Validation Scenarios

Scenario 1: Healthy backups, no restore history

  1. Open the tenant dashboard.
  2. Verify Backup posture can still be healthy.
  3. Verify the dashboard also shows that recovery evidence is unvalidated.
  4. Verify the backup-health claim boundary is visible on the summary surface.
  5. Follow the recovery drillthrough and confirm the restore-run list explains that no relevant restore history exists.

Scenario 2: Recent failed, partial, or follow-up restore

  1. Open the tenant dashboard for a tenant with recent problematic restore history.
  2. Verify Needs Attention surfaces the recovery issue before any all-clear messaging.
  3. Follow the drillthrough.
  4. Confirm the destination surface shows the same reason: failed, partial, or follow-up required.

Scenario 3: No recent restore issues visible

  1. Open the tenant dashboard for a tenant with recent executed restore history and no current attention state.
  2. Verify the surface can say no recent restore issues are visible.
  3. Verify it still stops short of proving or guaranteeing recovery.

Scenario 4: Readonly tenant member

  1. Sign in as a readonly tenant member.
  2. Open the same tenant dashboard.
  3. Verify the summary remains cautious and truthful.
  4. Verify restore-run history remains inspectable for the readonly member.
  5. Verify restore mutations remain disabled.

Scenario 5: In-scope member without restore-history view

  1. Sign in as a tenant member who can open the dashboard but lacks restore-history viewing capability.
  2. Open the tenant dashboard.
  3. Verify the recovery summary stays unvalidated or weakened as appropriate and does not become calmer because drillthrough is unavailable.
  4. Follow the recovery action if one is offered.
  5. Confirm the restore-history surface denies access with 403 semantics while the dashboard summary remains truthful.

Non-goals Check

Before considering the slice complete, verify that no surface introduces any of the following language:

  • recovery proven
  • recovery guaranteed
  • strong recovery confidence
  • Any equivalent positive claim stronger than the current evidence supports

Deployment Note

No new Filament assets are planned for this slice. Deployment keeps the existing asset step unchanged:

cd apps/platform && php artisan filament:assets