ahmido
f1a73490e4
## 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
93 lines
3.9 KiB
Markdown
93 lines
3.9 KiB
Markdown
# Quickstart: Dashboard Recovery Posture Honesty
|
|
|
|
## Prerequisites
|
|
|
|
1. Start the application services if they are not already running:
|
|
|
|
```bash
|
|
cd apps/platform && ./vendor/bin/sail up -d
|
|
```
|
|
|
|
2. Use a tenant member account with at least readonly access for verification.
|
|
|
|
## Focused Automated Verification
|
|
|
|
Run the smallest relevant test set first:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
cd apps/platform && php artisan filament:assets
|
|
``` |