TenantAtlas/specs/371-core-operator-view-surfaces-productization/spec.md

Feature Specification: Spec 371 - Core Operator View Surfaces Productization Pass v1

Feature Branch: 371-core-operator-view-surfaces-productization Created: 2026-06-10 Status: Draft / Ready for implementation review Input: User-provided Spec 371 draft plus Spec 368 Candidate B and Spec 370 Global Surface Information Architecture Contract v1.

Candidate Selection Summary

• Selected candidate: Core Operator View Surfaces Productization Pass v1.
• Source: User-provided Spec 371 draft and specs/368-platform-ui-signal-to-noise-browser-audit/spec-candidates.md Candidate B.
• Why selected: Spec 368 identified Backup Set View as a remaining restore-critical operator surface where lifecycle, timing, related context, and technical detail still compete with backup usability and included-item truth. The user-provided Spec 371 draft explicitly asks to apply the Spec 370 decision-first contract to core operator surfaces.
• Roadmap relationship: Supports the roadmap's UI/product maturity polish, backup/restore safety, and decision-centered operator workflow lanes without opening new backend foundations.
• Repo-truth adjustment: Several surfaces named by the draft already have completed or validated productization specs. This package must not reopen those completed packages or reimplement their work. Spec 371 therefore focuses active implementation on Backup Set list/detail productization and capability-backed browser proof, while treating Environment Dashboard, Operations Hub, OperationRun View, Restore Run View, and Baseline Profile View as regression/context surfaces only.
• Smallest viable implementation slice: Productize the existing Backup Sets list and Backup Set detail surfaces so backup usability, included items, degradation/blocker state, and the safest next action are visible before lifecycle metadata, operation IDs, exact timestamps, or raw/technical context. Add/repair bounded browser proof only for the scoped backup surfaces.
• Deferred close alternatives:
  • Full six-page productization pass: deferred because multiple pages already have completed specs and reopening them would violate the completed-spec guardrail.
  • Environment Dashboard pass: completed by Specs 330 and 352; regression-only in this spec.
  • Operations Hub pass: completed by Specs 328, 365, and 367; regression-only in this spec.
  • OperationRun detail pass: completed by Specs 358-367; regression-only in this spec.
  • Restore Run detail pass: completed by Spec 335; regression-only in this spec.
  • Baseline Profile detail pass: completed by Spec 369; regression-only in this spec.
  • Customer/auditor surface safety, diagnostic surface separation, UI bloat regression guard, provider connections, system panel, and required permissions remain follow-up candidates.
• Completed-spec guardrail: Related completed specs are context only and must not be edited: Specs 328, 330, 335, 352, 367, 369, and 370. Spec 368 is an audit/source artifact and must not be rewritten.

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: Operators use backup sets to decide whether a captured restore point is usable and what it includes, but the current Backup Set detail can make lifecycle metadata, related operation context, and technical fields feel like peers of the actual restore decision.
• Today's failure: A backup can look record-complete while the operator still has to scan timing, status, operation link, quality text, and item sections to decide whether the backup is usable, degraded, or ready for guarded restore review.
• User-visible improvement: Backup Sets become a calm restore-point truth surface: usability/readiness first, included items second, degradations/blockers only when present, operation/evidence links reachable but secondary, and technical metadata on demand.
• Smallest enterprise-capable version: A page-local productization pass over existing BackupSetResource, ViewBackupSet, ListBackupSets, BackupItemsRelationManager, existing quality summary truth, and existing backup/restore actions. No new backup engine, restore engine, persisted readiness field, OperationRun type, Graph contract, or UI framework.
• Explicit non-goals: No restore workflow logic changes, no backup capture logic changes, no migrations, no models, no new tables, no Graph calls, no new operation types, no new restore eligibility truth, no customer/auditor surfaces, no system panel, no provider connections, no broad shell/sidebar/topbar work, and no changes to completed spec packages.
• Permanent complexity imported: Focused Feature/Livewire coverage, a bounded browser smoke fixture/report, optional page-local derived helper or presenter only if existing inline logic becomes hard to review, and spec-local artifacts. No new persisted truth or cross-domain UI framework is expected.
• Why now: Spec 370 created the reusable decision-first contract, and Spec 368's Backup Set finding remains the main restore-critical Candidate B surface not already covered by a completed productization spec.
• Why not local: A label-only change would not prove backup usability, included-item truth, action hierarchy, and metadata demotion together. A global pattern component would overbuild. The narrow correct slice is a repo-truth-bounded Backup Set productization pass with browser proof.
• Approval class: Workflow Compression.
• Red flags triggered: High-impact backup/restore-adjacent action surface and UI productization scope. Defense: the spec preserves existing resource-level capability checks, UI enforcement, confirmations, audit, OperationRun behavior, and restore safety language, while limiting active implementation to existing backup surfaces.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 1 | Gesamt: 11/12
• Decision: approve.

Spec Scope Fields (mandatory)

• Scope: environment-owned backup/restore workflow surface.
• Primary Routes:
  • /admin/workspaces/{workspace}/environments/{environment}/backup-sets
  • /admin/workspaces/{workspace}/environments/{environment}/backup-sets/{record}
• Regression Context Routes:
  • /admin/workspaces/{workspace}/environments/{environment}
  • /admin/workspaces/{workspace}/operations
  • /admin/workspaces/{workspace}/operations/{run}
  • /admin/workspaces/{workspace}/environments/{environment}/restore-runs/{record}
  • /admin/baseline-profiles/{record}
• Data Ownership: Existing backup sets and backup items remain environment-owned records under current workspace and managed environment scope. No data model change is planned.
• RBAC: Existing workspace membership, managed-environment entitlement, resource-level capability checks, UiEnforcement/WorkspaceUiEnforcement, and deny-as-not-found behavior remain authoritative. This spec does not add a BackupSetPolicy.

For environment-owned routes:

• Default filter behavior when workspace context is active: Backup Set list/detail must resolve from explicit workspace and managed-environment route context, not hidden remembered environment state.
• Explicit entitlement checks preventing cross-tenant leakage: Wrong workspace or inaccessible managed environment must remain denied as not found before backup-set content, operation links, or restore affordances are revealed.

UI Surface Impact (mandatory - UI-COV-001)

Does this spec add, remove, rename, or materially change any reachable UI surface?

• No UI surface impact
• Existing page changed
• New page/route added
• Navigation changed
• Filament panel/provider surface changed
• New modal/drawer/wizard/action added
• Existing table/detail/relation display state materially changed
• Customer-facing surface changed
• Dangerous action changed
• Status/evidence/review presentation changed
• Workspace/environment context presentation changed

UI/Productization Coverage (mandatory when UI Surface Impact is not "No UI surface impact")

• Route/page/surface: Backup Sets list and Backup Set detail under environment-owned routes; BackupSetResource, ListBackupSets, ViewBackupSet, and BackupItemsRelationManager.
• Current or new page archetype: Backup / Restore strategic surface, matching docs/ui-ux-enterprise-audit/page-reports/ui-013-environment-backup-sets.md.
• Design depth: Strategic Surface.
• Repo-truth level: repo-verified route and code; browser-verified before-state from Spec 368 screenshot artifacts/screenshots/admin/005-workflow-surface-view-backup-set.png; UI audit registry currently notes fixture/capability gaps for UI-051/UI-052.
• Existing pattern reused: Spec 370 surface IA contract, existing backup quality summary, existing Backup Set badges, existing resource-level capability/UI enforcement, existing OperationRun links, and existing Restore Run safety language for copy alignment only.
• New pattern required: none beyond optional page-local derived summary/helper if needed to reduce repeated inline logic.
• Screenshot required: yes. Use before screenshot from Spec 368 and capture after screenshots under specs/371-core-operator-view-surfaces-productization/artifacts/screenshots/.
• Page audit required: yes, update docs/ui-ux-enterprise-audit/page-reports/ui-013-environment-backup-sets.md and related coverage notes, or record an explicit no-count-change rationale if route/archetype remains unchanged.
• Customer-safe review required: no. This is operator/MSP restore-point truth, not a customer-facing surface.
• Dangerous-action review required: yes. Existing soft-delete restore of archived Backup Sets, archive/delete/force-delete, retry/capture-related actions, and add/remove policy actions must preserve existing confirmation, authorization, audit, and OperationRun behavior. This spec must not introduce or promote a new restore-from-backup action/link. No destructive action may be moved into a more prominent unsafe placement.
• Coverage files in scope for update or explicit validation:
  • docs/ui-ux-enterprise-audit/route-inventory.md - update only if route status/browser status changes.
  • docs/ui-ux-enterprise-audit/design-coverage-matrix.md - update if coverage status or screenshot references change.
  • docs/ui-ux-enterprise-audit/page-reports/ui-013-environment-backup-sets.md - update after implementation/browser proof.
  • docs/ui-ux-enterprise-audit/strategic-surfaces.md
  • docs/ui-ux-enterprise-audit/grouped-follow-up-candidates.md
  • docs/ui-ux-enterprise-audit/unresolved-pages.md
  • N/A - no reachable UI surface impact
• No-impact rationale when applicable: N/A.

Cross-Cutting / Shared Pattern Reuse

• Cross-cutting feature?: yes.
• Interaction class(es): status messaging, backup quality/readiness, action links, OperationRun links, restore-adjacent safety copy, table/list empty state, evidence/diagnostics disclosure, technical metadata disclosure.
• Systems touched: BackupSetResource, ViewBackupSet, ListBackupSets, BackupItemsRelationManager, backup quality summary helpers, badge renderers, OperationRun links, resource-level capability/UI enforcement, browser fixture commands/tests if existing.
• Existing pattern(s) to extend: Spec 370 first-viewport contract; Spec 335 restore result proof separation; Spec 333 restore create safety flow; existing BackupSetQualitySummary; existing backup set badges and UI enforcement.
• Shared contract / presenter / builder / renderer to reuse: Existing Backup Set helpers first; BadgeCatalog/BadgeRenderer for status-like badges; OperationRunLinks/existing operation link helpers for run navigation; UiEnforcement/WorkspaceUiEnforcement for actions.
• Why the existing shared path is sufficient or insufficient: Existing paths appear sufficient for backup quality, item count, operation links, authorization, and action safety. The gap is hierarchy and fixture-backed browser proof, not missing backend truth.
• Allowed deviation and why: A small page-local derived summary/helper is allowed if it replaces scattered closure logic and remains derived-only.
• Consistency impact: Backup usability, restore-readiness copy, quality/degradation labels, operation links, and dangerous-action hierarchy must stay aligned with Restore Run, Restore Create, OperationRun, and audit language.
• Review focus: Verify no new restore eligibility truth, no false recovery/safety claims, no raw payload default visibility, no hidden cross-workspace leakage, and no action safety regression.

OperationRun UX Impact

• Touches OperationRun start/completion/link UX?: link and presentation semantics only, unless existing backup actions already start operation runs.
• Shared OperationRun UX contract/layer reused: existing OperationRunLinks, OperationUxPresenter, and backup action OperationRun flows where already present.
• Delegated start/completion UX behaviors: preserve existing queued toast, Open operation link, already-running/dedupe feedback, browser event, and operation URL resolution.
• Local surface-owned behavior that remains: backup usability explanation, included-item hierarchy, and page-level action guidance.
• Queued DB-notification policy: unchanged / N/A.
• Terminal notification path: unchanged.
• Exception required?: none expected.

Provider Boundary / Platform Core Check

• Shared provider/platform boundary touched?: no new provider seam.
• Boundary classification: Backup Set UI remains platform-owned restore-point truth over provider-backed captured payloads.
• Seams affected: display of backup content, source environment, captured item types, provider payload references, and technical diagnostics.
• Neutral platform terms preserved or introduced: workspace, managed environment, backup set, backup item, restore point, operation, evidence, diagnostics, degradation, usable, action needed.
• Provider-specific semantics retained and why: Microsoft/Intune policy type labels may remain where they describe the captured item. Raw provider IDs, Graph payloads, and provider internals are technical/support detail and must not become default primary copy.
• Why this does not deepen provider coupling accidentally: No Graph calls, contracts, provider adapters, persisted taxonomy, or provider-specific backup logic are introduced.
• Follow-up path: document-in-feature for contained copy/display exceptions; follow-up-spec if a recurring provider payload disclosure issue is found.

UI / Surface Guardrail Impact

Surface / Change	Operator-facing surface change?	Native vs Custom	Shared-Family Relevance	State Layers Touched	Exception Needed?	Low-Impact / N/A Note
Backup Sets list decision summary	yes	Native Filament resource/table	status messaging, backup quality, action links	page, table, route scope	no	Existing route and resource only
Backup Set detail first viewport	yes	Native Filament infolist/page, optional page-local helper	restore-point truth, evidence/diagnostics, action links	page, detail, derived display	no	Active implementation focus
Backup items relation/table hierarchy	yes	Native RelationManager/table	included-item inventory	relation table	no	Must keep item inventory primary
Backup technical metadata demotion	yes	Native sections/details/aside where available	diagnostics/progressive disclosure	detail display	no	Metadata remains accessible
Completed surfaces regression context	no active refactor	Existing implemented patterns	status/evidence/action hierarchy	none unless regression found	no	Do not reopen completed specs

Decision-First Surface Role

Surface	Decision Role	Human-in-the-loop Moment	Immediately Visible for First Decision	On-Demand Detail / Evidence	Why This Is Primary or Why Not	Workflow Alignment	Attention-load Reduction
Backup Sets list	Secondary decision queue	Operator chooses which restore point to inspect or act on	name, usability/quality, item count, current degradation, latest operation link, safe inspect path	detailed items, operation context, raw metadata	Secondary because final trust decision happens on detail	backup/restore review	reduces table scanning before selecting a backup
Backup Set detail	Primary Decision Surface	Operator decides whether backup is usable and what to do next	usability/readiness, reason, impact, item count, degradation/blocker if present, one primary next action	operation trace, exact timestamps, raw IDs, source context, technical quality counters	Primary restore-point truth surface	backup review before restore	puts restore usability ahead of metadata
Backup items relation/table	Evidence / inventory surface	Operator verifies what is included	included items, item quality/problem state	raw payload details and provider identifiers	Primary content below summary, not metadata	restore preparation and audit	avoids separate reconstruction of contents

Audience-Aware Disclosure

Surface	Audience Modes In Scope	Decision-First Default-Visible Content	Operator Diagnostics	Support / Raw Evidence	One Dominant Next Action	Hidden / Gated By Default	Duplicate-Truth Prevention
Backup Sets list	operator-MSP, manager, readonly reviewer	backup usability, item count, degradation state, inspect/open action	operation link and compact quality detail	raw payloads not shown	open backup set	raw IDs/provider payloads/exact timestamps	one quality state per row
Backup Set detail	operator-MSP, support reviewer	usable/action needed state, reason, impact, item inventory, degradation/blocker	operation context, source schedule, retention/timing	raw backup payload, provider IDs, technical counters	review items or open the source operation; no new restore-start action	raw/support detail collapsed or secondary	top summary owns current decision; later sections add proof/detail

UI/UX Surface Classification

Surface	Action Surface Class	Surface Type	Likely Next Operator Action	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 / Justification
Backup Sets list	List / Table / Workflow	Backup / Restore list	Open a backup set or create backup set	record URL / explicit view	expected if current resource supports it	More/detail header	More or detail header only	/admin/workspaces/{workspace}/environments/{environment}/backup-sets	/admin/workspaces/{workspace}/environments/{environment}/backup-sets/{record}	workspace and environment route	Backup set	usability/quality, item count, degradation, latest operation	none
Backup Set detail	Detail / Header Actions	Restore-point detail	Review included items or open the source operation	detail page	N/A	detail header or related context	separated, confirmed, authorized, audited	same as above	same as above	workspace, environment, source operation	Backup set	usable/action needed, reason, impact, included items, current degradation	none

Operator Surface Contract

Surface	Primary Persona	Decision / Operator Action Supported	Surface Type	Primary Operator Question	Default-visible Information	Diagnostics-only Information	Status Dimensions Used	Mutation Scope	Primary Actions	Dangerous Actions
Backup Set detail	Workspace manager / backup operator	Decide whether a backup can be trusted for restore review	Backup / restore detail	Is this backup usable, and what is included?	usability, reason, impact, captured item count, item inventory, current degradation/blocker, safe next action	raw payloads, exact timestamps, source operation context, provider/internal IDs	lifecycle, backup quality, item completeness, operation availability	TenantPilot backup/restore workflows; Microsoft mutation only through existing restore flow outside this spec	Review backup items, Open operation	soft-delete restore of archived Backup Sets, archive, delete/force-delete, add/remove items if present

Proportionality Review

• New source of truth?: no.
• New persisted entity/table/artifact?: no runtime persistence. Spec-local Markdown artifacts and screenshots only.
• New abstraction?: no expected runtime abstraction; optional page-local derived helper only if it replaces scattered page logic.
• New enum/state/reason family?: no.
• New cross-domain UI framework/taxonomy?: no. This consumes Spec 370 and existing UI standards.
• Current operator problem: Backup usability and included-item truth do not dominate the restore-point detail page.
• Existing structure is insufficient because: Existing resource/table/detail paths contain the needed truth, but the current hierarchy can still put lifecycle and technical metadata near the main decision.
• Narrowest correct implementation: Recompose existing Backup Set list/detail output around a derived decision summary and item inventory; demote metadata; add focused tests and browser proof.
• Ownership cost: Focused Feature/Livewire tests, one bounded browser smoke/report, and UI audit coverage update.
• Alternative intentionally rejected: A global component framework, new backup readiness persistence, or reimplementation of already-completed Environment Dashboard/Operations/Restore/Baseline surfaces.
• Release truth: current-release operator productization.

Compatibility posture

This feature assumes pre-production. No legacy aliases, migration shims, backfills, historical fixture migration, or dual-read compatibility path is required unless the spec is amended.

Testing / Lane / Runtime Impact

• Test purpose / classification: Feature/Livewire for Backup Set list/detail rendering, action affordances, RBAC/scope; Browser for bounded backup-set first-viewport and screenshot proof.
• Validation lane(s): fast-feedback/confidence for focused Pest tests; browser for backup-set smoke; git diff --check; Pint for touched PHP.
• Why this classification and these lanes are sufficient: The change is a Filament resource/detail hierarchy and action-safety pass. Feature tests prove server-rendered truth/action behavior; browser smoke proves the first-viewport signal-to-noise improvement and fixture reachability.
• New or expanded test families: Spec371BackupSetProductizationTest and Spec371BackupSetProductizationSmokeTest.
• Fixture / helper cost impact: Reuse existing workspace/environment/backup-set factories and browser harness if available. If no suitable browser fixture exists, add the smallest capability-backed fixture only for backup-set review and document the cost.
• Heavy-family visibility / justification: Browser coverage is explicit and bounded to Backup Sets list/detail because the source finding is browser-verified UI signal-to-noise and the UI audit registry currently lists backup-set fixture gaps.
• Special surface test profile: backup/restore strategic surface, shared-detail-family.
• Standard-native relief or required special coverage: Native Filament components should carry layout; special coverage is required for decision-first default visibility, metadata demotion, and dangerous-action preservation.
• Reviewer handoff: Reviewers must confirm no new backup/restore truth, no authorization regression, no technical detail removal, no raw provider payload in primary content, and no completed spec package edits.
• Budget / baseline / trend impact: none expected. Record any browser fixture broadening or new seed cost in the implementation close-out.
• Escalation needed: document-in-feature if backup-set fixture cost or UI coverage registry updates are contained; follow-up-spec if browser fixture gaps are structural across backup/restore.
• Active feature PR close-out entry: Guardrail / Exception / Smoke Coverage.
• Planned validation commands:
  • cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=Spec371
  • cd apps/platform && ./vendor/bin/sail artisan test --compact --filter=BackupSet
  • cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Browser/Spec371BackupSetProductizationSmokeTest.php --compact
  • cd apps/platform && ./vendor/bin/sail pint --dirty
  • git diff --check
• Runtime impact: UI rendering and browser fixture/test coverage only; no env vars, migrations, queues, scheduler, storage, Graph calls, or Filament asset registration expected.

User Stories & Testing

User Story 1 - Decide backup usability quickly (Priority: P1)

As a backup operator, I want the Backup Set detail page to tell me whether the backup is usable and what it includes before lifecycle or technical metadata, so I can decide whether to inspect items or open the source operation before any separate restore workflow.

Independent Test: Render backup sets with healthy, degraded, and empty/incomplete item states and assert the first decision section contains usability/readiness, reason, impact, item count, current degradation/blocker if present, and one dominant next action before exact timestamps, operation ID, raw payload, or provider metadata.

Acceptance Scenarios:

1. Given a completed backup set with no degradations and backup items, When the detail page renders, Then the first viewport says the backup is usable, names item count/content, and offers review/open action before technical metadata.
2. Given a backup set with degraded or failed items, When the detail page renders, Then current degradation is prominent and the safest next action is review/investigation rather than optimistic restore copy.
3. Given a backup set with no items or incomplete capture, When the detail page renders, Then it explains why restore confidence is blocked without exposing raw payload or operation context as the primary answer.

User Story 2 - Keep dangerous backup/restore actions safe (Priority: P1)

As a reviewer, I want existing soft-delete restore, archive/delete, and backup item mutations to keep existing confirmation, authorization, audit, and OperationRun behavior while the page hierarchy changes, so productization does not weaken governance safety.

Independent Test: Use Filament action tests to prove authorized actors see allowed actions, readonly or wrong-scope actors cannot execute them, destructive/high-impact actions remain confirmation-gated, and existing OperationRun/open-operation feedback remains unchanged.

Acceptance Scenarios:

1. Given a readonly or unauthorized workspace member, When the Backup Set list/detail renders, Then mutating soft-delete restore/archive/add/remove actions are hidden or disabled consistently with current resource-level capability/UI enforcement.
2. Given an authorized actor starts an existing high-impact backup/restore-related action, When the action succeeds or dedupes, Then existing OperationRun feedback and canonical operation links remain intact.
3. Given a destructive backup action remains available, When tests inspect the action, Then it still uses ->action(...), ->requiresConfirmation(), server-side authorization, audit behavior, and safe placement.

User Story 3 - Make Backup Sets list scan-first (Priority: P2)

As an operator scanning backup history, I want the Backup Sets list to surface usability/quality, item count, degradation, and the inspect path, so I can choose a backup without reading lifecycle metadata first.

Independent Test: Render the Backup Sets list with healthy and degraded rows and assert the visible columns/copy prioritize backup usability and included-item information while exact technical metadata remains secondary or hidden by default.

Acceptance Scenarios:

1. Given the list contains healthy and degraded backups, When it renders, Then rows distinguish usable versus action-needed backups without multiple zero/no-issue cards.
2. Given no backup sets exist, When the list renders, Then the empty state explains how to create or capture a backup in one clear CTA if authorized.
3. Given a backup row has an operation link, When the row renders, Then the operation remains reachable but does not compete with the inspect/open backup path.

User Story 4 - Prove browser reachability and no regression on completed surfaces (Priority: P3)

As a product reviewer, I want the implementation to capture backup-set before/after proof and spot-check completed context surfaces without editing completed packages, so the pass improves the open gap without undoing finished work.

Independent Test: Run a bounded browser smoke for Backup Sets list/detail and record after screenshots. Spot-check completed surfaces only for obvious regression if the implementation touches shared helpers that affect them.

Acceptance Scenarios:

1. Given the backup-set browser fixture exists or is added narrowly, When the smoke test runs, Then it captures list/detail screenshots and records no JavaScript errors.
2. Given implementation touches only backup-specific files, When regression scope is reviewed, Then Environment Dashboard, Operations Hub, OperationRun, Restore Run, and Baseline Profile are not edited.
3. Given a shared helper unexpectedly affects a completed surface, When that is discovered, Then implementation stops to update spec/plan or narrows the change.

Functional Requirements

• FR-001: Backup Set detail MUST render a first-read decision summary above lifecycle metadata and technical context.
• FR-002: The summary MUST state backup usability/readiness, reason, impact, captured item count, current degradation/blocker only if present, and one dominant next action when a safe action exists.
• FR-003: The detail page MUST make included backup items primary content, not an afterthought behind metadata.
• FR-004: The list page MUST expose scan-first backup usability/quality and item count without zero-card spam.
• FR-005: Technical metadata, internal IDs, source operation context, exact timestamps, provider IDs, raw payloads, and quality counters MUST be sidebar, secondary, hidden, or collapsed by default unless they are the current blocker.
• FR-006: Existing soft-delete restore, archive/delete, add/remove, and operation-link affordances MUST preserve current authorization, confirmation, audit, and OperationRun semantics; no new restore-from-backup action/link is introduced by this spec.
• FR-007: The implementation MUST NOT create a new backup readiness field, restore eligibility field, status family, persisted artifact, Graph contract, or OperationRun type.
• FR-008: Wrong-workspace or wrong-environment access MUST remain denied as not found before content or action state leaks.
• FR-009: Browser proof MUST capture Backup Sets list/detail after screenshots or document the exact fixture/reachability blocker.
• FR-010: Completed context specs MUST not be edited or converted back into preparation state.
• FR-011: If BackupSetResource global-search metadata is touched, its effective non-participation MUST either be preserved by explicitly disabling global search or changed only with safe View/Edit pages, scoped URLs, $recordTitleAttribute, and tests; no global search enablement is expected.
• FR-012: UI audit registry artifacts MUST be updated or explicitly marked unchanged with a rationale after implementation.

Non-Functional Requirements

• NFR-001: Keep implementation page-local to backup surfaces unless a small existing shared helper is the narrowest correct place.
• NFR-002: No Graph calls may occur during page render.
• NFR-003: Use Filament v5 and Livewire v4-compatible components and tests; no Livewire v3 or Filament v3/v4 APIs.
• NFR-004: Panel provider registration remains in apps/platform/bootstrap/providers.php; no provider registration change is expected.
• NFR-005: No Filament asset registration is expected; if assets are unexpectedly registered, deployment must include cd apps/platform && php artisan filament:assets.
• NFR-006: Preserve calm enterprise operator UX: one dominant decision, one primary action, diagnostics/evidence reachable but separated, no false positive calmness.

Out Of Scope

Environment Dashboard refactor, Operations Hub refactor, OperationRun actionability or detail refactor, Restore Run detail refactor, Baseline Profile detail refactor, Customer Review Workspace, Environment Review, Review Pack, Stored Report, Evidence Snapshot, Required Permissions, System Panel, Provider Connections, Environment Diagnostics, restore execution logic, backup capture logic, baseline compare engine, migrations, models, jobs, policies, Graph contracts, package changes, route additions, and shell/sidebar/topbar work.

Acceptance Criteria

• AC-001: Backup Set detail first viewport answers "Is this backup usable, what is included, and what should I do next?" before technical metadata.
• AC-002: Backup Set list rows prioritize usability/quality, included item count, degradation if present, and inspect/open path.
• AC-003: Degraded/incomplete backups show action-needed truth prominently; healthy backups avoid repeated zero/no-issue blocks.
• AC-004: Existing destructive/high-impact actions remain confirmed, authorized, audited, and safely placed.
• AC-005: Existing OperationRun links/feedback remain canonical and scope-safe.
• AC-006: Focused Pest/Livewire tests and bounded browser smoke pass, or non-run reasons are documented.
• AC-007: UI audit/page-report coverage is updated or explicitly marked unchanged.
• AC-008: No application code outside the approved backup-surface scope changes unless the spec/plan are updated first.

Success Criteria

• Backup Set View reaches a browser-verified score target of at least 4.0 using the Spec 368 score model, or the remaining gap is documented with a follow-up.
• Backup Sets list remains at least 4.0 and no longer requires operators to infer backup usability from lifecycle or operation metadata.
• No completed context surface is edited unless a shared-helper regression forces a documented spec/plan update.
• No new runtime persistence, status family, provider contract, or broad UI framework is introduced.

Assumptions

• Existing backup quality and item inventory truth are sufficient to derive usability/readiness copy.
• Existing resource-level capability checks and UI enforcement already govern backup and restore-adjacent actions; this spec preserves and tests them rather than replacing them.
• A bounded backup-set browser fixture can be reused or added without broad seed/default test cost.
• The repo is pre-production, so no migration compatibility work is needed.

Risks

• Backup-set browser fixture work may reveal broader capability/auth gaps. If structural, escalate to follow-up rather than hiding it inside this spec.
• Page-local helper extraction could drift into a backup UI framework. Keep any helper derived, local, and justified by readability.
• Restore-adjacent copy could overclaim safety. Use only repo-backed backup quality and existing action availability truth.
• Touching shared badge/action helpers could affect completed surfaces. Prefer backup-local changes and stop to update spec/plan if shared changes become necessary.

Open Questions

• None blocking preparation. During implementation, verify whether existing browser fixture coverage can reach Backup Sets list/detail without broad seed changes.

Follow-up Spec Candidates

• Customer/Auditor Surface Safety Pass v1.
• Diagnostic Surface Separation v1.
• UI Bloat Regression Guard v1 after at least two runtime consumers validate Spec 370.
• Backup/restore browser fixture hardening if fixture gaps affect more than Backup Sets.
• Provider Connections readiness productization.
• System Panel audit fixture and productization pass.