86 lines
4.3 KiB
Markdown
86 lines
4.3 KiB
Markdown
# Quickstart: Tenant Registry Recovery Triage
|
|
|
|
## Purpose
|
|
|
|
Validate that the tenant registry becomes a useful recovery-triage surface and that workspace backup or recovery drilldowns preserve their meaning.
|
|
|
|
## Prerequisites
|
|
|
|
1. Start the local stack:
|
|
|
|
```bash
|
|
cd apps/platform && ./vendor/bin/sail up -d
|
|
```
|
|
|
|
2. Work on branch `186-tenant-registry-recovery-triage`.
|
|
|
|
3. Use an owner or readonly workspace member who can see multiple tenants in the same workspace.
|
|
|
|
## Primary Automated Verification
|
|
|
|
Run the focused test set that covers the registry, workspace drilldowns, and scope safety:
|
|
|
|
```bash
|
|
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/TenantRegistryRecoveryTriageTest.php
|
|
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/WorkspaceOverviewSummaryMetricsTest.php
|
|
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/WorkspaceOverviewDrilldownContinuityTest.php
|
|
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/TenantResourceIndexIsWorkspaceScopedTest.php
|
|
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/WorkspaceOverviewAuthorizationTest.php
|
|
```
|
|
|
|
Expected outcomes:
|
|
|
|
- Tenant registry rows show separate `Backup posture` and `Recovery evidence` signals.
|
|
- Exact backup and recovery filters return only matching visible tenants.
|
|
- Worst-first triage ordering places weak tenants ahead of calm rows.
|
|
- Query-bounded registry posture loading does not regress into uncontrolled per-row resolver fanout.
|
|
- Multi-tenant workspace backup and recovery metrics open the filtered tenant registry instead of `ChooseTenant`.
|
|
- Single-tenant workspace drilldowns still open the tenant dashboard.
|
|
- No out-of-scope tenant leaks into registry rows, filters, or destinations.
|
|
|
|
## Manual Smoke Validation
|
|
|
|
Use a workspace that already contains a mixed visible tenant set with at least these cases:
|
|
|
|
- one tenant with `absent` backup posture
|
|
- one tenant with `stale` backup posture
|
|
- one tenant with `degraded` backup posture
|
|
- one tenant with `weakened` recovery evidence
|
|
- one tenant with `unvalidated` recovery evidence
|
|
- one calm tenant with `healthy` backup posture and `no recent issues visible`
|
|
|
|
Then verify:
|
|
|
|
1. Open `/admin` and confirm `Backup attention` and `Recovery attention` counts still appear separately.
|
|
2. If `Backup attention > 1`, click the metric and confirm the destination is `/admin/tenants` with backup posture filter intent preserved and weak tenants first.
|
|
3. If `Recovery attention > 1`, click the metric and confirm the destination is `/admin/tenants` with recovery-evidence filter intent preserved and weak tenants first.
|
|
4. Open `/admin/tenants` directly and confirm the registry shows separate `Backup posture` and `Recovery evidence` columns next to metadata and lifecycle fields.
|
|
5. Apply a backup filter such as `degraded` and confirm only degraded visible tenants remain.
|
|
6. Apply a recovery filter such as `unvalidated` and confirm only unvalidated visible tenants remain.
|
|
7. Confirm calm rows do not erase weak rows when worst-first ordering is active.
|
|
8. Open a prioritized row and confirm the registry detail route preserves the same bounded weakness truth shown in the list.
|
|
9. Use the safe dashboard shortcut for that prioritized tenant and confirm the tenant dashboard still shows the same bounded weakness truth.
|
|
10. Confirm the registry never says `recoverable`, `recovery proven`, or `validated overall`.
|
|
11. Time the first `/admin/tenants` triage scan and confirm a workspace operator can identify which visible tenants are weak on backup posture, which are weak on recovery evidence, and which tenant to open first within 10 seconds.
|
|
|
|
## Optional Fixture Note
|
|
|
|
The existing fixture command below is useful for backup-health smoke work, but it does not seed the full multi-tenant mixed posture matrix required for Spec 186 by itself:
|
|
|
|
```bash
|
|
cd apps/platform && ./vendor/bin/sail artisan tenantpilot:backup-health:seed-browser-fixture --force-refresh
|
|
```
|
|
|
|
For Spec 186, the focused Pest tests remain the primary acceptance harness.
|
|
|
|
## Formatting
|
|
|
|
Before handing off implementation, run:
|
|
|
|
```bash
|
|
cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
|
|
```
|
|
|
|
## No Migration Expected
|
|
|
|
This feature should complete with no schema migration and no new persisted posture summary. |