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