# 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.