TenantAtlas/specs/185-workspace-recovery-posture-visibility/spec.md

# Feature Specification: Workspace Recovery Posture Visibility

**Feature Branch**: `185-workspace-recovery-posture-visibility`  
**Created**: 2026-04-09  
**Status**: Draft  
**Input**: User description: "Spec 185 — Workspace Recovery Posture Visibility"

## Spec Scope Fields *(mandatory)*

- **Scope**: workspace
- **Primary Routes**:
  - `/admin` as the workspace-level overview where `WorkspaceOverview`, `WorkspaceSummaryStats`, and `WorkspaceNeedsAttention` answer the first portfolio triage question
  - `/admin/choose-tenant` as the bounded tenant-entry fallback when the operator needs to move from workspace triage into one tenant without a more precise allowed destination
  - `/admin/t/{tenant}` as the canonical tenant dashboard drill-through for backup-health and recovery-evidence follow-up
  - `/admin/t/{tenant}/backup-sets` and `/admin/t/{tenant}/restore-runs` only when an existing reason-specific destination can preserve the same weakness context without weakening claim boundaries or violating permissions
- **Data Ownership**:
  - Tenant-owned backup truth remains authoritative for backup posture, including the derived tenant backup-health assessment built from existing backup and schedule records
  - Tenant-owned restore truth remains authoritative for recovery evidence, including the existing dashboard-level recovery-evidence overview derived from restore history and restore-result attention
  - Workspace overview metrics, attention items, calmness, and drill-through hints remain derived workspace-level views over visible tenant truth; this feature introduces no new persisted workspace recovery posture, score, or confidence ledger
- **RBAC**:
  - Workspace membership remains required to render `/admin` and all workspace-level aggregation shown by this feature
  - Only tenants visible inside the current workspace and capability scope may contribute to backup metrics, recovery metrics, calmness suppression, or attention items
  - Tenant dashboard and any deeper backup or restore destinations continue to enforce existing tenant-scoped read and mutation permissions; workspace-level visibility never upgrades access
  - Non-members or out-of-scope actors remain deny-as-not-found, and members who cannot open a deeper destination must still receive truthful workspace summary language without hidden-tenant leakage or dead-end drill-throughs

## 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Workspace overview page | Workspace landing page | The page itself is the canonical workspace entry and hosts embedded recovery and backup triage surfaces | forbidden | Quick actions only | none | `/admin` | none | Active workspace identity stays visible and every promoted issue keeps tenant identity explicit | Workspace overview | Which visible tenants need backup or recovery follow-up first | Singleton landing surface |
| Workspace summary stats | Embedded status summary / drill-in surface | Explicit stat click when a metric has a precise next destination; otherwise intentionally passive | forbidden | none | none | `/admin` | Matching tenant dashboard or choose-tenant fallback when no single precise tenant target exists | Workspace identity plus visible-tenant scope | Backup attention / Recovery attention | Separate cross-tenant counts for backup weakness and recovery-evidence weakness | Mixed metric summary surface |
| Workspace `Needs Attention` | Embedded triage summary | Each attention item opens one allowed tenant destination that preserves the same weakness reason | forbidden | none | none | `/admin` | `/admin/t/{tenant}` by default, with deeper existing tenant backup or restore surfaces only when context continuity is preserved | Tenant name, issue family, and visible scope remain explicit before navigation | Attention / Attention item | The highest-priority visible tenant backup or recovery weakness and the next click | Multi-destination triage surface |
| Tenant dashboard recovery landing | Tenant detail-first landing | The tenant dashboard is the canonical recovery and backup landing when workspace triage needs one tenant-wide destination | forbidden | Existing dashboard actions only | none added by this feature | `/admin/t/{tenant}` | Existing tenant backup or restore follow-up surfaces remain secondary destinations | Active workspace plus tenant context | Tenant dashboard | Backup-health and recovery-evidence truth remain visible without losing why the workspace flagged 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 |
|---|---|---|---|---|---|---|---|---|---|
| Workspace overview page | Workspace operator | Workspace landing page | Which visible tenants are weak on backups or recovery evidence, and where should I go first? | Backup-attention count, recovery-attention count, prioritized attention, calmness boundary, and tenant labels | Raw backup metadata, full restore histories, and low-level diagnostics remain downstream | backup health, recovery evidence, existing governance, existing operations | none | Open a priority tenant from attention or choose a tenant deliberately | none |
| Workspace summary stats | Workspace operator | Embedded summary | How many visible tenants need backup follow-up, and how many need recovery-evidence follow-up? | Separate backup and recovery counts with bounded labels | Tenant-by-tenant breakdown remains secondary | backup attention volume, recovery attention volume | none | Open the affected tenant or tenant-entry surface | none |
| Workspace `Needs Attention` | Workspace operator | Embedded triage summary | Which tenant needs attention now, why, and what should I click next? | Tenant name, issue family, bounded reason, clear action label | Full restore-result detail, backup-set history, and deep schedule context remain downstream | backup severity, recovery-evidence severity, existing workspace priority ordering | none | Open the tenant dashboard or an allowed reason-specific tenant surface | none |
| Tenant dashboard recovery landing | Workspace operator after drill-through | Tenant landing page | Why did the workspace flag this tenant, and what backup or recovery truth confirms it? | Tenant backup health, tenant recovery evidence, and the same bounded weakness context | Full backup-set and restore-run diagnostics remain deeper drill-through surfaces | backup posture, recovery-evidence posture, 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 workspace recovery posture record, workspace recovery score, or persisted confidence model.
- **New abstraction?**: No. The narrow change is to extend the existing workspace overview builder and existing workspace surfaces with more truthful derived aggregation.
- **New enum/state/reason family?**: Yes, but derived only. The feature adds workspace attention families such as `backup_health` and `recovery_evidence`, plus checked-domain markers for those families. Tenant posture states remain defined by existing tenant-level truth.
- **New cross-domain UI framework/taxonomy?**: No. This slice strengthens existing workspace triage and explicitly avoids a new portfolio matrix or recovery-confidence framework.
- **Current operator problem**: Workspace operators can currently see honest tenant-level backup and recovery signals, but they cannot tell from the workspace overview which visible tenants are weakest, which tenants need recovery-evidence follow-up, or whether workspace calmness is real versus omission-driven.
- **Existing structure is insufficient because**: The current workspace overview already summarizes governance, findings, compare, and operations, but it does not yet promote tenant backup-health and tenant recovery-evidence truth into workspace-first triage. Operators are forced into tenant-by-tenant inspection.
- **Narrowest correct implementation**: Extend visible tenant contexts, workspace summary metrics, workspace attention families, calmness checked domains, and workspace-to-tenant drill-through continuity so that existing tenant truth becomes triage-ready at `/admin` without introducing new persistence or a stronger recovery-claim engine.
- **Ownership cost**: The repo takes on additional workspace aggregation logic, severity ordering, bounded claim copy, query-bounded data loading, and targeted regression coverage for metrics, attention, calmness, drill-through continuity, and RBAC-safe omission.
- **Alternative intentionally rejected**: A dedicated portfolio recovery matrix, a persisted workspace recovery score, tenant-list columns for recovery posture, or a new recovery-confidence engine were rejected because they introduce new truth and broader IA change before the current workspace overview tells the existing truth honestly.
- **Release truth**: Current-release truth hardening. Tenant truth already exists; this slice makes workspace triage usable.

## User Scenarios & Testing *(mandatory)*

### User Story 1 - See Backup And Recovery Hotspots Fast (Priority: P1)

As a workspace operator, I want the workspace overview to show separate backup and recovery-evidence attention counts so that I can tell within seconds how many visible tenants need follow-up in each domain.

**Why this priority**: This is the core workspace-first workflow gap. Without a truthful cross-tenant count, operators still have to inspect tenants one by one.

**Independent Test**: Can be fully tested by seeding visible tenants with mixes of `absent`, `stale`, `degraded`, `unvalidated`, `weakened`, and calm states, then verifying that `/admin` shows separate backup and recovery counts without overclaiming workspace confidence.

**Acceptance Scenarios**:

1. **Given** visible tenants include backup-weak and recovery-weak cases, **When** the operator opens `/admin`, **Then** the summary shows at least one backup-attention metric and one recovery-attention metric with separate counts.
2. **Given** visible tenants are mixed across backup and recovery weakness families, **When** the workspace overview renders, **Then** the counts reflect only the visible tenants that need follow-up in each domain.
3. **Given** all visible tenants are healthy on backups and have `no_recent_issues_visible` recovery evidence, **When** the overview renders, **Then** backup and recovery attention metrics do not invent problem counts.

---

### User Story 2 - Open The Right Tenant First (Priority: P1)

As a workspace operator, I want workspace attention to rank the weakest visible tenants and give me one clear next click so that I can start triage from the highest-value tenant rather than from raw activity.

**Why this priority**: Counts alone do not solve the workflow gap. The overview must also answer which tenant should be opened first.

**Independent Test**: Can be fully tested by seeding mixed workspaces and verifying that attention items rank `absent` above `stale` above `degraded`, rank `weakened` above `unvalidated`, and carry tenant-safe drill-through destinations.

**Acceptance Scenarios**:

1. **Given** one visible tenant has `absent` backup health and another has `degraded` backup health, **When** the attention list renders, **Then** the absent-backup tenant appears first within the backup-health family.
2. **Given** one visible tenant has `weakened` recovery evidence and another has `unvalidated` recovery evidence, **When** the attention list renders, **Then** the weakened-recovery tenant appears first within the recovery-evidence family.
3. **Given** an operator opens a workspace attention item, **When** the destination loads, **Then** the tenant identity and the same weakness reason remain recoverable on the target surface.

---

### User Story 3 - Trust Calmness Boundaries (Priority: P2)

As a workspace operator, I want calmness on the workspace overview to explicitly include backup health and recovery evidence so that I know a calm workspace is calm because those domains were checked, not because they were ignored.

**Why this priority**: False calmness by omission is the main trust failure this slice is intended to remove.

**Independent Test**: Can be fully tested by rendering the workspace overview for calm and non-calm portfolios and verifying that calmness is suppressed whenever backup or recovery attention exists and that calm wording explicitly names the covered domains.

**Acceptance Scenarios**:

1. **Given** a visible tenant has backup or recovery attention, **When** calmness is derived for `/admin`, **Then** the workspace overview is not calm and the checked-domain contract includes backup health and recovery evidence.
2. **Given** all visible tenants are calm across covered domains, **When** the overview renders, **Then** the calmness statement explicitly says that backup health and recovery evidence were included.
3. **Given** hidden tenants may exist outside the current visible scope, **When** calmness is shown, **Then** the calm statement remains bounded to visible tenants rather than making a stronger portfolio-wide claim.

---

### User Story 4 - Preserve Permission-Safe Portfolio Truth (Priority: P3)

As a workspace operator with partial tenant visibility, I want workspace-level backup and recovery triage to remain truthful without leaking hidden tenants so that the overview stays safe under RBAC boundaries.

**Why this priority**: Workspace aggregation is only acceptable if it remains tenant-safe and permission-safe under partial visibility.

**Independent Test**: Can be fully tested by mixing visible and hidden tenants with backup and recovery issues, then verifying that `/admin` counts only visible tenants, leaks no hidden tenant names or reason text, and still stays bounded in its calmness claims.

**Acceptance Scenarios**:

1. **Given** a user cannot see some tenants with backup or recovery issues, **When** the workspace overview renders, **Then** hidden tenants do not appear in counts, attention items, or reason text.
2. **Given** only hidden tenants have backup or recovery issues, **When** the workspace overview renders, **Then** any calmness claim stays explicitly scoped to visible tenants.
3. **Given** a user can see the workspace overview but cannot open a more precise backup or restore destination, **When** a workspace item renders, **Then** it uses an allowed tenant-dashboard fallback or a safe non-clickable state instead of a dead-end link.

### Edge Cases

- All visible tenants may be `healthy` on backups and `no_recent_issues_visible` on recovery evidence; the workspace overview must allow calmness only when both domains are included in checked domains.
- A workspace may contain many `unvalidated` tenants at once; recovery-evidence counts and attention must stay explicit without turning the absence of proof into a stronger negative or positive claim.
- One visible tenant may have `absent` backup health while all other visible tenants are calm; the absent-backup tenant must still prevent workspace calmness and appear as the first backup attention item.
- A mixed workspace may contain `weakened`, `unvalidated`, `stale`, `degraded`, and healthy tenants simultaneously; ordering must stay consistent and bounded rather than collapsing everything into one generic urgency bucket.
- Hidden tenants may still have backup or recovery issues; the workspace overview must neither leak those tenants nor imply that hidden tenants are calm.
- A tenant may have `no_recent_issues_visible` recovery evidence but still have stale or absent backup posture; backup attention must remain visible and must not be canceled out by calm recovery evidence.
- A tenant may be the only actionable backup or recovery problem while the rest of the workspace is quiet; metrics, attention, and calmness must still point clearly to that one tenant.

## Requirements *(mandatory)*

**Constitution alignment (required):** This feature introduces no new Microsoft Graph calls, no new write workflow, and no new queued or scheduled operation. It is a read-first workspace triage slice that promotes existing tenant backup-health and recovery-evidence truth onto the existing workspace overview.

**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** The slice remains derived-first. It adds no new persistence, no portfolio confidence engine, and no new broad abstraction layer. The only new semantic additions are derived workspace attention families and checked-domain markers that sit on top of already-shipped tenant truth.

**Constitution alignment (OPS-UX):** No new `OperationRun`, progress surface, or execution path is introduced. Existing operations remain execution truth only. This feature changes how the workspace overview summarizes and prioritizes existing tenant backup and recovery signals.

**Constitution alignment (RBAC-UX):** The feature lives primarily in the workspace plane at `/admin` with read-only drill-through into the tenant plane at `/admin/t/{tenant}` and, only when authorized, deeper existing tenant backup or restore surfaces. Non-members or actors outside workspace or tenant scope remain `404`. Existing deeper read and mutation permissions remain server-side and unchanged. Workspace aggregation must use only visible tenants, must not leak hidden tenant problems, and must use safe destination fallbacks when a precise downstream surface is not allowed.

**Constitution alignment (OPS-EX-AUTH-001):** Not applicable. No authentication-handshake behavior changes.

**Constitution alignment (BADGE-001):** Existing centralized status semantics for backup health, restore-result attention, and recovery-evidence language remain authoritative. The workspace overview may elevate those semantics, but it must not invent a page-local badge or color system for portfolio recovery posture.

**Constitution alignment (UI-FIL-001):** The feature reuses the existing Filament workspace overview page and existing workspace widgets. Semantic emphasis must come from aligned copy, ordering, and existing shared primitives rather than custom local markup or a new widget family.

**Constitution alignment (UI-NAMING-001):** Operator-facing language must keep `Backup health` and `Recovery evidence` separate. Primary labels may use terms such as `Backup attention`, `Recovery attention`, `Needs attention`, `Visible tenants need attention`, `Backup health`, and `Recovery evidence`, but must not introduce `recovery proven`, `restore guaranteed`, `workspace ready`, or equivalent overclaims.

**Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001):** `WorkspaceOverview` remains the canonical workspace landing surface. `WorkspaceSummaryStats` remains an embedded summary strip. `WorkspaceNeedsAttention` remains the workspace triage surface. The tenant dashboard remains the canonical fallback drill-through. No redundant `View` affordances or new destructive controls are introduced.

**Constitution alignment (OPSURF-001):** Default-visible content on `/admin` must answer the operator's first triage question within 5 to 10 seconds: which visible tenants are weak on backups, which are weak on recovery evidence, and where the next click should go. Diagnostics remain downstream on the tenant dashboard and deeper tenant pages.

**Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001):** The feature must not create a second recovery-confidence truth. It may only derive workspace-level visibility and prioritization from existing tenant truth, and tests must focus on business consequences such as false calmness, hidden-tenant leakage, wrong priority order, and lost drill-through context.

**Constitution alignment (Filament Action Surfaces):** The Action Surface Contract remains satisfied. `WorkspaceOverview`, `WorkspaceSummaryStats`, and `WorkspaceNeedsAttention` remain read-only drill-through surfaces with no destructive actions, no empty action groups, and no redundant view actions. UI-FIL-001 remains satisfied and no new exception is required.

**Constitution alignment (UX-001 — Layout & Information Architecture):** The feature does not add new create or edit forms. It refines the existing workspace landing page. Backup and recovery posture must appear as first-scan portfolio triage signals rather than as hidden downstream detail, and calmness wording must remain explicit about which domains were checked.

### Functional Requirements

- **FR-185-001**: The system MUST extend each visible tenant context used by the workspace overview with the current tenant backup-health posture from the existing tenant backup-health source of truth.
- **FR-185-002**: The workspace overview MUST recognize at least `absent`, `stale`, `degraded`, and `healthy` as backup-health posture classes without redefining how those states are determined.
- **FR-185-003**: The system MUST extend each visible tenant context used by the workspace overview with the current tenant recovery-evidence overview state from the existing tenant recovery-evidence source of truth.
- **FR-185-004**: The workspace overview MUST recognize at least `unvalidated`, `weakened`, and `no_recent_issues_visible` as recovery-evidence states without redefining how those states are determined.
- **FR-185-005**: Workspace summary metrics MUST expose at least one backup-attention metric and one recovery-attention metric and MUST keep those portfolio signals separate.
- **FR-185-006**: Workspace `Needs Attention` MUST support a `backup_health` family that surfaces every visible tenant whose backup posture is not `healthy`.
- **FR-185-007**: The `backup_health` family MUST prioritize `absent` above `stale` above `degraded`.
- **FR-185-008**: Workspace `Needs Attention` MUST support a `recovery_evidence` family that surfaces every visible tenant whose recovery evidence is `weakened` or `unvalidated`, and it MUST NOT surface `no_recent_issues_visible` as a problem item.
- **FR-185-009**: Every backup-health or recovery-evidence attention item MUST include the affected tenant, bounded reason text, one clear action, and one tenant-safe destination.
- **FR-185-010**: Workspace metrics, attention, and calmness copy MUST keep backup health and recovery evidence as separate signals and MUST NOT merge them into a single ambiguous portfolio posture score or label.
- **FR-185-011**: Workspace calmness MUST evaluate backup health and recovery evidence alongside the existing checked domains and MUST add `backup_health` and `recovery_evidence`, or functionally equivalent markers, to the checked-domain contract.
- **FR-185-012**: Workspace calmness MUST NOT render a calm state when any visible tenant triggers backup-health or recovery-evidence attention.
- **FR-185-013**: Calmness copy MUST explicitly state that backup health and recovery evidence were included and MUST keep any calm claim bounded to visible tenants.
- **FR-185-014**: Workspace-level wording MUST NOT claim or imply that the workspace is recovery proven, that portfolio restore readiness is guaranteed, or that healthy backups prove successful recovery.
- **FR-185-015**: Drill-through from workspace backup or recovery metrics and attention items MUST preserve tenant identity and the originating weakness reason; the tenant dashboard is the canonical fallback when no more precise allowed destination can preserve that context.
- **FR-185-016**: Workspace aggregation MUST count and surface only tenants visible within the current workspace and capability scope and MUST NOT leak hidden tenant names, counts, or problem detail.
- **FR-185-017**: When hidden tenants exist or no more precise downstream capability is available, workspace copy and navigation MUST remain bounded to visible evidence and use safe fallbacks or non-clickable states instead of stronger claims or dead-end links.
- **FR-185-018**: Global workspace attention ordering MUST integrate backup-health and recovery-evidence families without unintentionally breaking existing governance or operations priorities outside the intended severity rules.
- **FR-185-019**: Workspace backup and recovery aggregation MUST remain practical for moderate visible-tenant counts, SHOULD use batch or preloaded truth where available, and MUST avoid uncontrolled per-tenant N+1 patterns.
- **FR-185-020**: The feature MUST ship without a new persisted workspace recovery posture model, workspace recovery score, tenant-list posture column set, dedicated portfolio matrix page, or recovery-confidence engine.
- **FR-185-021**: Regression coverage MUST prove builder aggregation, separate summary metrics, backup-health attention, recovery-evidence attention, checked-domain expansion, honest calmness copy, drill-through continuity, RBAC-safe visibility, representative mixed-workspace ordering, and query-bounded render behavior.

## Derived State Semantics

- **Tenant backup-health source**: The workspace overview consumes tenant backup-health posture exactly as already derived at tenant level. This slice does not redefine backup-health rules.
- **Tenant recovery-evidence source**: The workspace overview consumes tenant recovery-evidence overview state exactly as already derived at tenant level. This slice does not redefine recovery-evidence rules.
- **Workspace backup attention set**: The set of visible tenants whose tenant backup-health posture is `absent`, `stale`, or `degraded`, ordered by `absent`, then `stale`, then `degraded`.
- **Workspace recovery attention set**: The set of visible tenants whose tenant recovery-evidence state is `weakened` or `unvalidated`, ordered by `weakened`, then `unvalidated`.
- **Checked domains contract**: Workspace calmness is only allowed when existing workspace domains plus `backup_health` and `recovery_evidence` were actually checked and no visible tenant triggers attention in those domains.
- **Calmness boundary**: Any calm workspace statement produced by this feature is a statement about visible tenants and covered domains only. It is never a proof of full portfolio recovery readiness.

## Attention Priority Rules

- **Backup health family order**: `absent` before `stale` before `degraded`.
- **Recovery evidence family order**: `weakened` before `unvalidated`.
- **Cross-family integration rule**: Backup-health and recovery-evidence items must enter the existing workspace attention ordering in a way that preserves the current governance and operations intent of the workspace overview rather than silently replacing it with a backup-only or recovery-only queue.
- **Bounded claim rule**: An item may say that a tenant needs backup follow-up or recovery-evidence follow-up, but it may not say that the tenant or the workspace is recovery proven or guaranteed.

## Smoke-Test Goals

- Seed one workspace with multiple visible tenants where one tenant is `absent` on backup health, one is `stale` on backup health, one is `unvalidated` on recovery evidence, one is `weakened` on recovery evidence, and one is calm.
- Verify that `/admin` shows separate backup and recovery summary metrics and that both metrics remain truthful under mixed visible tenants.
- Verify that `Needs Attention` shows backup-health and recovery-evidence items with the expected priority order and one clear next click per item.
- Verify that calmness is shown only in the fully calm visible-workspace case and that calm wording explicitly includes backup health and recovery evidence.
- Verify that drill-through opens the correct tenant and preserves why that tenant was flagged.
- Verify that hidden tenants do not appear in counts or attention items when the operator lacks visibility.

## Success Criteria *(mandatory)*

### Measurable Outcomes

- **SC-185-001**: In acceptance review, a workspace operator can determine within 10 seconds from `/admin` how many visible tenants need backup follow-up, how many need recovery-evidence follow-up, and which tenant to open first.
- **SC-185-002**: In 100% of covered regression scenarios, visible tenants with `absent`, `stale`, or `degraded` backup posture appear in the correct backup metric and backup attention flow, and visible tenants with `weakened` or `unvalidated` recovery evidence appear in the correct recovery metric and recovery attention flow.
- **SC-185-003**: In 100% of covered calmness scenarios, the workspace overview shows calmness only when backup health and recovery evidence are included in checked domains and no visible tenant triggers either family.
- **SC-185-004**: In 100% of covered drill-through scenarios, workspace backup or recovery attention preserves tenant identity and the same weakness reason at the destination or allowed fallback.
- **SC-185-005**: In 100% of covered RBAC scenarios, hidden tenants do not leak through counts, item labels, or reason text, and any calmness claim stays explicitly bounded to visible tenants.
- **SC-185-006**: Targeted DB-only or query-bounded regression coverage proves that representative moderate-tenant workspace rendering does not degrade into uncontrolled per-tenant query fanout when backup and recovery signals are enabled.
- **SC-185-007**: The feature ships without a schema migration, a new persisted workspace recovery model, a new workspace recovery score, or a new recovery-confidence engine.

## Assumptions

- Existing tenant dashboard work already surfaces honest backup-health and recovery-evidence truth that can be reused as workspace-level drill-through context.
- The current workspace overview composition remains in place; this slice extends tenant contexts, summary metrics, attention families, and calmness semantics rather than redesigning the page.
- The tenant dashboard remains the correct fallback destination whenever a deeper backup or restore surface would lose context or violate the operator's permissions.
- Existing tenant backup and restore truth can be loaded in a batched or eager-loaded way that keeps workspace rendering practical for moderate tenant counts.

## Non-Goals

- Building a dedicated portfolio recovery matrix or a new workspace recovery page
- Introducing a persisted workspace recovery score, workspace posture model, or recovery-confidence ledger
- Redefining tenant backup-health logic or tenant recovery-evidence logic
- Adding backup or recovery posture columns to the tenant resource list
- Redesigning the entire workspace overview information architecture
- Adding automatic restore validation, scheduled recovery probes, or a broader recovery-confidence engine
- Claiming that the workspace or portfolio is recovery proven or restore guaranteed

## Dependencies

- Existing `WorkspaceOverview`, `WorkspaceSummaryStats`, `WorkspaceNeedsAttention`, and `WorkspaceOverviewBuilder` workspace surfaces
- Existing tenant backup-health truth and the tenant-level backup-health source of truth
- Existing tenant recovery-evidence truth and the tenant-level recovery-evidence source of truth
- Existing tenant dashboard and, when allowed, deeper tenant backup-set and restore-run surfaces used for drill-through continuity
- Existing workspace and tenant RBAC scoping and safe destination fallback patterns

## Risks

- If workspace copy collapses backup health and recovery evidence into one blended posture, operators will lose the distinction this slice is meant to restore.
- If calmness does not explicitly include the new checked domains, the workspace overview may remain falsely calm by omission.
- If aggregation ignores visible-scope boundaries, hidden tenant recovery or backup problems could leak through counts, wording, or navigation.
- If the implementation relies on naive per-tenant resolver calls, workspace rendering could regress under moderate tenant counts.
- If drill-through destinations cannot recover the same weakness reason, the workspace overview will feel more precise than the tenant truth it opens.

## Definition of Done

Spec 185 is complete when:

- the workspace overview makes backup-health weakness visible across visible tenants,
- the workspace overview makes recovery-evidence weakness visible across visible tenants,
- workspace summary metrics show separate backup and recovery attention counts,
- `WorkspaceNeedsAttention` cleanly integrates `backup_health` and `recovery_evidence` families,
- workspace calmness includes backup health and recovery evidence in its checked-domain and claim-boundary logic,
- no over-strong recovery or restore-confidence claim is introduced,
- drill-through remains triage-ready and preserves tenant context,
- RBAC-safe aggregation and omission behavior are covered,
- query-bounded tests cover representative multi-tenant render behavior,
- and the workspace overview becomes a usable workspace-first triage surface without adding a new recovery-confidence engine.