TenantAtlas/specs/186-tenant-registry-recovery-triage/quickstart.md
ahmido 9fbd3e5ec7 Spec 186: implement tenant registry recovery triage (#217)
## Summary
- turn the tenant registry into a workspace-scoped recovery triage surface with backup posture and recovery evidence columns
- preserve workspace overview backup and recovery drilldown intent by routing multi-tenant cases into filtered tenant registry slices
- add the Spec 186 planning artifacts, focused regression coverage, and shared triage presentation helpers

## Testing
- `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
- `cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/TenantRegistryRecoveryTriageTest.php tests/Feature/Filament/WorkspaceOverviewSummaryMetricsTest.php tests/Feature/Filament/WorkspaceOverviewDrilldownContinuityTest.php tests/Feature/Filament/TenantResourceIndexIsWorkspaceScopedTest.php tests/Feature/Filament/WorkspaceOverviewAuthorizationTest.php tests/Feature/Guards/ActionSurfaceContractTest.php tests/Feature/Guards/FilamentTableStandardsGuardTest.php`

## Notes
- no schema change
- no new persisted recovery truth
- branch includes the full Spec 186 spec, plan, research, data model, contract, quickstart, and tasks artifacts

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #217
2026-04-09 19:20:48 +00:00

4.3 KiB

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:
cd apps/platform && ./vendor/bin/sail up -d
  1. Work on branch 186-tenant-registry-recovery-triage.

  2. 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:

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:

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:

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.