TenantAtlas/specs/184-dashboard-recovery-honesty/quickstart.md
2026-04-09 01:19:36 +02:00

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
```