TenantAtlas/specs/186-tenant-registry-recovery-triage/spec.md

Feature Specification: Tenant Registry Recovery Triage

Feature Branch: 186-tenant-registry-recovery-triage
Created: 2026-04-09
Status: Draft
Input: User description: "Spec 186 — Tenant Registry Recovery Triage"

Spec Scope Fields (mandatory)

• Scope: workspace
• Primary Routes:
  • /admin as the workspace overview that currently surfaces backup and recovery attention counts and needs a more useful portfolio drill-through
  • /admin/tenants as the canonical tenant registry collection route that becomes the working recovery-triage surface for visible tenants
  • /admin/tenants/{tenant} as the existing tenant-registry inspect route opened by full-row click from the registry
  • /admin/choose-tenant only as the displaced multi-tenant fallback for backup and recovery attention drilldowns; this feature removes that fallback for those posture-specific cases
  • /admin/t/{tenant} as the canonical tenant-dashboard follow-up opened by the existing safe shortcut when one affected tenant is in scope or when deeper tenant surfaces are not the safest truthful destination
  • /admin/t/{tenant}/backup-sets and /admin/t/{tenant}/restore-runs only when an existing tenant-scoped destination preserves the same posture reason without overclaiming or breaking permissions
• Data Ownership:
  • Tenant identity, lifecycle, and directory metadata remain authoritative on the tenant registry row and continue to belong to the existing tenant record
  • Tenant backup posture remains derived from the existing tenant-level backup-health source of truth built from current backup and schedule records; this feature adds no new persisted portfolio posture table or score
  • Tenant recovery evidence remains derived from the existing tenant-level recovery-evidence source of truth built from restore history; this feature adds no new persisted recovery registry summary or portfolio confidence artifact
  • Registry filters, sorting, and workspace drilldowns remain derived views over visible tenant truth only; this feature does not create a second domain model for backup or recovery posture
• RBAC:
  • Workspace membership remains required to render /admin and /admin/tenants
  • Only tenants visible inside the current workspace and tenant-membership scope may appear in the registry, contribute to posture filters, or appear behind backup and recovery drilldowns
  • The tenant dashboard and any deeper backup or restore surfaces continue to enforce existing tenant-scoped read and mutation permissions; registry visibility does not upgrade access
  • Non-members remain deny-as-not-found, and any deeper destination that is not available must fall back to a safe allowed tenant surface rather than a broken or misleading link

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

Surface	Surface Type	Primary Inspect/Open Model	Row Click	Secondary Actions Placement	Destructive Actions Placement	Canonical Collection Route	Canonical Detail Route	Scope Signals	Canonical Noun	Critical Truth Visible by Default	Exception Type
Tenant registry list	CRUD / list-first resource	Full-row click remains the canonical inspect path for tenant registry detail, while one safe inline shortcut continues the triage flow into the tenant dashboard	required	One inline safe shortcut plus existing More menu	Existing More and bulk More placement remain unchanged	/admin/tenants	/admin/tenants/{tenant}	Active workspace plus visible-tenant scope stay explicit	Tenants / Tenant	Backup posture and recovery evidence are visible beside lifecycle metadata	Working-surface registry augmentation
Workspace overview backup and recovery drilldowns	Embedded status summary / drill-in surface	Explicit stat or attention click opens a filtered tenant registry for multi-tenant cases or the tenant dashboard for a single-tenant case	forbidden	none	none	/admin	/admin/tenants or /admin/t/{tenant} depending on affected-tenant count	Active workspace plus visible-tenant scope stay explicit before navigation	Backup attention / Recovery attention	Which visible tenants need backup or recovery follow-up and whether the cause is preserved through the next click	Mixed-count drilldown surface
Tenant dashboard follow-up landing	Tenant landing / detail-first follow-up	Direct page open from a registry shortcut or single-tenant workspace drilldown	forbidden	Existing dashboard actions only	none added by this feature	/admin/t/{tenant}	/admin/t/{tenant}/backup-sets or /admin/t/{tenant}/restore-runs remain secondary destinations	Workspace context plus tenant context remain explicit	Tenant dashboard	Tenant-level backup health and recovery evidence confirm why the registry prioritized the tenant	Existing tenant dashboard pattern

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

Surface	Primary Persona	Surface Type	Primary Operator Question	Default-visible Information	Diagnostics-only Information	Status Dimensions Used	Mutation Scope	Primary Actions	Dangerous Actions
Tenant registry list	Workspace operator	List-first working surface	Which visible tenants are weak on backups or recovery evidence, and which one should I open first?	Tenant identity, environment, lifecycle, backup posture, recovery evidence, and visible triage filter or sort state	Full backup-quality diagnostics, restore-run outcome detail, and deep explanations remain downstream	lifecycle, backup posture, recovery evidence	none added by this feature; existing tenant maintenance actions stay secondary	Filter by posture, sort worst-first, inspect the registry detail route by row click, use the tenant-dashboard shortcut when needed	Existing sync, archive, or other destructive or operational actions remain unchanged and secondary
Workspace overview backup and recovery drilldowns	Workspace operator	Embedded summary / drill-in	Which registry slice should I open from this count, and will it preserve why I clicked?	Backup-attention or recovery-attention count plus one bounded destination	Tenant-by-tenant diagnostics remain secondary to the drill-through	backup attention volume, recovery attention volume	none	Open filtered tenant registry or direct tenant dashboard	none
Tenant dashboard follow-up landing	Workspace operator after drill-through	Tenant landing page	Why was this tenant prioritized, and what deeper surface should I open next?	Tenant-level backup health, recovery evidence, and the same bounded posture context that triggered the registry ranking	Full backup-set and restore-run diagnostics remain deeper tenant surfaces	backup posture, recovery evidence, tenant-local follow-up	none added by this feature	Continue to backup sets or restore runs when needed	none added by this feature

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: No. Tenant backup-health truth and tenant recovery-evidence truth remain authoritative.
• New persisted entity/table/artifact?: No. The feature explicitly forbids a new persisted portfolio posture table, score, or confidence ledger.
• New abstraction?: No. The narrow implementation is to extend the existing tenant registry and workspace drill-through behavior with derived posture columns, filters, and ordering.
• New enum/state/reason family?: No. The feature reuses the existing tenant backup posture and recovery-evidence states and only defines ordering over them in registry context.
• New cross-domain UI framework/taxonomy?: No. The slice keeps the existing backup and recovery vocabulary and avoids a new confidence or triage framework.
• Current operator problem: Workspace operators can already see that some tenants are weak on backup health or recovery evidence, but they still cannot answer from one working surface which tenants are absent, stale, degraded, weakened, or unvalidated, nor which tenant should be opened first.
• Existing structure is insufficient because: The current tenant registry is still metadata-first and the current workspace backup and recovery drilldowns lose cause by sending multi-tenant cases to a generic tenant chooser instead of a filtered registry slice.
• Narrowest correct implementation: Reuse the existing tenant registry as the canonical portfolio triage surface, add posture columns and posture filters backed by existing truth, add a consistent worst-first ordering, and redirect backup and recovery drilldowns into that filtered registry without introducing new persistence or a broader portfolio matrix.
• Ownership cost: The repo takes on additional registry rendering logic, posture filter and ordering rules, drill-through preservation rules, query-bounded loading, and regression coverage for truthfulness, RBAC, and list usability.
• Alternative intentionally rejected: A new portfolio recovery dashboard, a persisted posture summary table, a new global score, or a redesigned tenant chooser were rejected because they add a second truth or a larger IA shift before the existing registry surface is used correctly.
• Release truth: Current-release workflow hardening. The domain truth already exists; this slice makes the portfolio workflow usable.

User Scenarios & Testing (mandatory)

User Story 1 - See Weak Tenants On One Registry Surface (Priority: P1)

As a workspace operator, I want the tenant registry to show backup posture and recovery evidence directly on each visible row so that I can identify weak tenants within seconds without opening every tenant dashboard.

Why this priority: This is the core workflow gap. Without visible posture on the registry itself, the product still forces tenant-by-tenant inspection.

Independent Test: Can be fully tested by seeding visible tenants with mixed backup and recovery states, opening /admin/tenants, and verifying that each row shows bounded backup posture and recovery evidence without turning metadata into recovery truth.

Acceptance Scenarios:

1. Given visible tenants include absent, stale, degraded, and healthy backup posture cases, When the operator opens /admin/tenants, Then each row shows a scan-friendly backup-posture signal.
2. Given visible tenants include weakened, unvalidated, and no_recent_issues_visible recovery evidence cases, When the operator opens /admin/tenants, Then each row shows a separate recovery-evidence signal.
3. Given a tenant has healthy backups and no_recent_issues_visible recovery evidence, When the row renders, Then the registry does not claim that the tenant is recovery proven, fully recoverable, or healthy overall.

---

User Story 2 - Filter And Rank The Weakest Tenants First (Priority: P1)

As a workspace operator, I want posture filters and a worst-first ordering so that I can reduce the registry to the exact weak slice I need and start with the highest-priority tenants.

Why this priority: Visibility alone is not enough. The registry must behave like a triage surface, not just a directory.

Independent Test: Can be fully tested by applying backup and recovery filters and by invoking posture-oriented ordering in a mixed visible tenant set.

Acceptance Scenarios:

1. Given visible tenants have mixed backup posture, When the operator filters for degraded, Then only visible degraded tenants remain in the registry.
2. Given visible tenants have mixed recovery evidence, When the operator filters for unvalidated, Then only visible unvalidated tenants remain in the registry.
3. Given the registry contains calm and weak tenants, When the operator uses worst-first triage ordering, Then weak tenants appear before calm tenants in a consistent, testable order.

---

User Story 3 - Preserve Workspace Meaning During Drilldown (Priority: P1)

As a workspace operator, I want backup and recovery attention counts to open a filtered tenant registry instead of a generic tenant chooser so that the reason I clicked remains visible after navigation.

Why this priority: The workspace overview is already honest about counts, but it still drops the operator into a surface that does not preserve the cause.

Independent Test: Can be fully tested by opening backup and recovery attention drilldowns for single-tenant and multi-tenant cases and verifying that the destination keeps the same meaning.

Acceptance Scenarios:

1. Given more than one visible tenant contributes to backup attention, When the operator opens that drilldown, Then the destination is /admin/tenants with backup-posture intent already preserved.
2. Given more than one visible tenant contributes to recovery attention, When the operator opens that drilldown, Then the destination is /admin/tenants with recovery-evidence intent already preserved.
3. Given exactly one visible tenant contributes to a backup or recovery attention drilldown, When the operator opens it, Then the destination may go directly to /admin/t/{tenant} instead of the registry.

---

User Story 4 - Keep Scope And Truth Boundaries Honest (Priority: P3)

As a workspace operator with partial tenant visibility, I want the registry and its drilldowns to remain truthful without leaking hidden tenants or overstating what deeper surfaces prove.

Why this priority: Portfolio aggregation is only acceptable if it stays bounded by workspace and tenant scope and does not turn partial evidence into stronger claims.

Independent Test: Can be fully tested by mixing visible and hidden tenants with posture issues and verifying that only visible tenants appear in the registry, filters, and drilldown results.

Acceptance Scenarios:

1. Given hidden tenants have backup or recovery issues, When the operator uses registry filters or workspace drilldowns, Then hidden tenants do not appear in rows, counts, or labels.
2. Given a user can see registry posture but cannot open a deeper backup or restore surface, When the user continues triage from the registry, Then the UI offers an allowed fallback such as the tenant dashboard instead of a broken link.
3. Given a visible tenant has stale last sync metadata but healthy backup posture, When the registry renders, Then lifecycle and metadata signals remain distinct from backup posture and do not override it.

Edge Cases

• A visible tenant may have healthy backups but unvalidated recovery evidence; the registry must keep that tenant discoverable through the recovery filter instead of letting healthy backup posture hide the weaker recovery truth.
• A visible tenant may have both backup attention and recovery-evidence weakness at the same time; the registry must show both domains independently while triage ordering uses one consistent highest-priority tier.
• A filtered registry view may return zero visible rows because the active filter no longer matches any in-scope tenant; the empty state must remain bounded to the visible workspace slice and must not imply that hidden tenants are calm.
• A tenant may be archived, inactive, or otherwise operationally unusual while still having calm backup and recovery posture; lifecycle presentation must not be used as a substitute for recovery triage.
• A user may be able to see posture truth on the registry but lack permission for deeper backup or restore surfaces; triage must still have one safe next click.

Requirements (mandatory)

This feature introduces no new Microsoft Graph calls, no new queued or scheduled work, no new OperationRun, and no new persistence. It is a read-first workspace triage slice that reuses the existing tenant backup-health and recovery-evidence truth inside the tenant registry and workspace drilldown flow.

Authorization spans the workspace/admin plane at /admin and /admin/tenants, with read-only drill-through into the tenant plane at /admin/t/{tenant} and, only when already allowed, deeper backup or restore surfaces. Non-members remain 404. Established members continue to rely on existing server-side capability checks for deeper destinations. Registry visibility and filter state must never broaden tenant access.

The feature changes status-like list signals, so centralized badge semantics remain authoritative. Backup posture and recovery evidence may be rendered on the registry with shared status primitives or equivalent central mappings, but the registry must not introduce page-local status language or new claim families. Labels must stay bounded to Backup posture, Recovery evidence, absent, stale, degraded, healthy, weakened, unvalidated, and no recent issues visible, or closely equivalent wording that carries the same limits.

The affected Filament surfaces keep one primary inspect or open model. The tenant registry remains the canonical collection route. Full-row click remains the canonical inspect affordance for the registry, while one safe inline dashboard shortcut remains the fast triage continuation. No redundant view action, empty action group, or destructive placement change is introduced. The workspace overview remains a read-only drill-in surface. UX-001 create and edit form rules are unchanged because this slice only refines list and drilldown behavior.

The feature must not create a second recovery-confidence truth. It may only derive registry ordering and filter behavior from existing tenant backup-health and recovery-evidence states. Tests must focus on business consequences such as wrong rows, wrong filters, wrong ordering, lost drilldown meaning, hidden-tenant leakage, metadata substitution, and overclaiming language.

Functional Requirements

• FR-186-001: The system MUST add a visible backup-posture signal to each tenant-registry row and MUST derive that signal from the existing tenant-level backup-health source of truth.
• FR-186-002: The registry MUST recognize at least absent, stale, degraded, and healthy as backup-posture states without redefining how those states are determined.
• FR-186-003: Backup posture on the registry MUST remain a bounded summary signal and MUST NOT claim or imply restore success.
• FR-186-004: The system MUST add a visible recovery-evidence signal to each tenant-registry row and MUST derive that signal from the existing tenant-level recovery-evidence source of truth.
• FR-186-005: The registry MUST recognize at least weakened, unvalidated, and no_recent_issues_visible as recovery-evidence states without redefining how those states are determined.
• FR-186-006: Recovery evidence on the registry MUST remain a bounded summary signal and MUST NOT claim or imply that recovery is proven, guaranteed, or fully validated.
• FR-186-007: The tenant registry MUST keep tenant identity and lifecycle metadata visually and semantically separate from backup posture and recovery evidence.
• FR-186-008: The tenant registry MUST provide a backup-posture filter with at least absent, stale, degraded, and healthy as selectable states.
• FR-186-009: The tenant registry MUST provide a recovery-evidence filter with at least weakened, unvalidated, and no_recent_issues_visible as selectable states.
• FR-186-010: Registry posture filters MUST act only on visible rows inside the current workspace and tenant scope and MUST NOT reveal out-of-scope tenants.
• FR-186-011: The tenant registry MUST provide a consistent worst-first triage ordering for mixed posture rows.
• FR-186-012: Combined triage ordering MUST rank tenants by the highest active weakness tier using this order: backup absent, recovery weakened, backup stale, recovery unvalidated, backup degraded, then calm rows.
• FR-186-013: When multiple tenants share the same weakness tier, the registry MUST break ties by tenant name in ascending order.
• FR-186-014: A multi-tenant workspace backup-attention drilldown MUST land on /admin/tenants with backup-posture intent already preserved.
• FR-186-015: A multi-tenant workspace recovery-attention drilldown MUST land on /admin/tenants with recovery-evidence intent already preserved.
• FR-186-016: A single-tenant backup-attention or recovery-attention drilldown MAY continue directly to /admin/t/{tenant} when only one visible tenant is affected.
• FR-186-017: Drilldown intent MUST remain recoverable at the destination through visible filter state, visible ordering, or equivalent default-visible context.
• FR-186-018: Each posture-relevant tenant-registry row MUST expose at least one fast, permission-safe next step, with the tenant dashboard as the canonical fallback destination.
• FR-186-019: Deeper backup-set or restore-run destinations MAY be used only when they preserve the same posture reason and remain permission-safe for the current user.
• FR-186-020: The registry MUST NOT substitute lifecycle status, last sync, policy count, or general tenant status for backup posture or recovery evidence.
• FR-186-021: Registry rendering MUST remain query-bounded and MUST avoid uncontrolled per-row resolver fanout when posture data is loaded for a visible page of tenants.
• FR-186-022: Only visible tenants inside the current workspace and tenant scope may contribute to registry posture, posture filters, or workspace drilldown targets.
• FR-186-023: When a user can see registry posture but cannot open a deeper backup or restore destination, the registry MUST remain truthful and MUST fall back to an allowed tenant surface instead of offering a broken or misleading path.
• FR-186-024: Registry wording MUST NOT claim recoverable, recovery proven, validated overall, or any equivalent stronger statement that exceeds the underlying backup and recovery evidence.
• FR-186-025: The feature MUST ship without a schema migration, without a new persisted portfolio posture summary, without a new global recovery score, and without changing tenant-level resolver truth.
• FR-186-026: Regression coverage MUST prove posture-column rendering, backup filters, recovery filters, worst-first ordering, workspace backup drilldown, workspace recovery drilldown, single-tenant drilldown fallback, RBAC-safe visibility, no metadata substitution, and no overclaiming labels.

Derived Registry Semantics

• Visible backup posture: The registry consumes the current tenant backup-health posture exactly as it already exists at tenant level. This slice does not redefine backup-health truth.
• Visible recovery evidence: The registry consumes the current tenant recovery-evidence overview state exactly as it already exists at tenant level. This slice does not redefine recovery-evidence truth.
• Registry backup attention set: The set of visible tenants whose backup posture is absent, stale, or degraded.
• Registry recovery attention set: The set of visible tenants whose recovery evidence is weakened or unvalidated.
• Registry calm row: A visible tenant row whose backup posture is healthy and whose recovery evidence is no_recent_issues_visible. A calm row is not a proof of recoverability.
• Registry drilldown intent: The preserved explanation of why the operator opened the registry, expressed through visible backup or recovery filter state, visible worst-first ordering, or an equivalent bounded context indicator.

Triage Priority Rules

• Backup-only order: absent before stale before degraded before healthy.
• Recovery-only order: weakened before unvalidated before no_recent_issues_visible.
• Combined registry order: backup absent, recovery weakened, backup stale, recovery unvalidated, backup degraded, then calm rows.
• Dual-signal rule: If one tenant is weak in both posture domains, the highest active tier governs ordering while both posture signals remain visible.
• Secondary order: Ties inside one tier resolve by tenant name ascending.
• Bounded-claim rule: Even the calm tier may say only that no recent issues are visible; it may not say that recovery is proven.

UI Action Matrix (mandatory when Filament is changed)

Surface	Location	Header Actions	Inspect Affordance (List/Table)	Row Actions (max 2 visible)	Bulk Actions (grouped)	Empty-State CTA(s)	View Header Actions	Create/Edit Save+Cancel	Audit log?	Notes / Exemptions
Tenant registry list	Tenant registry list surface	Existing tenant-entry header action remains unchanged	Full-row click remains the canonical registry inspect affordance and opens the existing registry detail route	Existing inline dashboard shortcut remains the fast triage continuation into the tenant dashboard; existing conditional onboarding shortcut stays conditional	Existing grouped tenant maintenance actions remain unchanged	Existing tenant-entry empty-state CTA remains unchanged	Existing tenant detail header actions remain unchanged	Existing edit flow remains unchanged	no new audit behavior	This feature changes default-visible posture truth, filters, and ordering only. The action-surface contract remains satisfied with one primary inspect model and one safe dashboard follow-up shortcut, with no new destructive placement.
Workspace overview backup and recovery drilldowns	Workspace overview summary and attention surface	none	Explicit stat or attention click only	none	none	Existing workspace empty-state behavior remains bounded to visible scope	n/a	n/a	no new audit behavior	Multi-tenant backup and recovery drilldowns now open the filtered tenant registry. Single-tenant drilldowns may still open the tenant dashboard directly.
Tenant dashboard fallback landing	Tenant dashboard follow-up landing	Existing dashboard actions remain unchanged	Direct page open only	none added by this feature	none	Existing dashboard empty states remain unchanged	n/a	n/a	no new audit behavior	The tenant dashboard is the canonical safe fallback when deeper backup or restore surfaces would lose the same posture reason or violate permissions.

Key Entities (include if feature involves data)

• Tenant registry row: The visible portfolio record that combines tenant identity and lifecycle metadata with bounded backup posture and bounded recovery evidence.
• Backup posture summary: The existing tenant-level backup-health assessment rendered in a scan-friendly registry form.
• Recovery evidence summary: The existing tenant-level recovery-evidence overview rendered in a scan-friendly registry form.
• Registry drilldown intent: The preserved explanation of why the registry was opened, including the active posture filter and worst-first ordering context.

Success Criteria (mandatory)

Measurable Outcomes

• SC-186-001: In acceptance review, a workspace operator can identify within 10 seconds which visible tenants are weak on backup posture, which visible tenants are weak on recovery evidence, and which tenant should be opened first from /admin/tenants.
• SC-186-002: In 100% of covered regression scenarios, backup posture and recovery evidence render as separate signals on tenant-registry rows and never collapse into one ambiguous recovery score.
• SC-186-003: In 100% of covered filter scenarios, backup and recovery filters return only visible in-scope tenants matching the selected posture state.
• SC-186-004: In 100% of covered ordering scenarios, worst-first triage ordering places every weak visible tenant ahead of calm rows according to the defined priority rules.
• SC-186-005: In 100% of covered workspace drilldown scenarios, multi-tenant backup and recovery drilldowns preserve cause by landing on the filtered registry, while single-tenant drilldowns preserve the direct tenant-dashboard shortcut.
• SC-186-006: In 100% of covered truthfulness scenarios, the registry never uses labels that imply recovery proof, guaranteed recoverability, or an overall validated state.
• SC-186-007: In targeted query-bounded regression coverage, representative mixed-tenant registry rendering does not degrade into uncontrolled per-row resolver fanout when posture signals are enabled.

Assumptions

• Existing tenant-level backup-health truth and tenant-level recovery-evidence truth are already stable enough to be reused on the registry without redefining either domain.
• The tenant dashboard remains the correct canonical fallback destination when a more specific backup or restore surface would not preserve the same posture reason or would not be permitted.
• The current tenant-registry inspect and maintenance flows remain in place; this slice hardens triage usefulness rather than redesigning the whole resource.
• The workspace overview keeps its existing backup-attention and recovery-attention meaning; this slice changes the destination for multi-tenant drilldowns, not the existence of those metrics.

Dependencies

• Existing workspace overview counts and attention drilldowns on /admin
• Existing tenant registry on /admin/tenants
• Existing tenant dashboard on /admin/t/{tenant}
• Existing tenant-level backup-health truth and tenant-level recovery-evidence truth
• Existing workspace and tenant RBAC boundaries and safe destination fallback patterns

Non-Goals

• Redesigning Choose tenant as a posture-triage surface
• Redesigning the workspace overview itself beyond changing backup and recovery drilldown targets
• Redesigning tenant detail pages or introducing a new tenant-registry visual language outside the recovery-triage goal
• Changing tenant-level resolver logic for backup health or recovery evidence
• Adding a new persisted portfolio posture table, a new global recovery score, or new dashboard widgets
• Changing backup, restore, or domain persistence models

Risks

• If the registry visually blends lifecycle metadata with backup or recovery posture, operators may still misread directory metadata as recovery truth.
• If drilldown intent is not visibly preserved, the workspace overview will continue to feel semantically sharper than the registry it opens.
• If ordering rules are inconsistent or unstable, weak tenants will still be lost in normal directory browsing.
• If posture loading is implemented as naive per-row resolution, registry performance may regress under moderate visible-tenant counts.
• If registry wording overreaches, operators may treat healthy backups and calm recovery evidence as proof of successful recovery.

Definition of Done

This feature is complete when:

• the tenant registry shows backup posture per visible row,
• the tenant registry shows recovery evidence per visible row,
• both posture domains are filterable,
• the registry supports a consistent weak-first triage ordering,
• multi-tenant workspace backup and recovery drilldowns land on a useful filtered tenant registry surface,
• single-tenant workspace backup and recovery drilldowns may still go directly to the tenant dashboard,
• the registry never overclaims recoverability or recovery proof,
• RBAC and query-bounded behavior are protected by focused regression coverage.