TenantAtlas/specs/390-restore-readiness-resolution-adapter-v1/spec.md

Feature Specification: Restore Readiness Resolution Adapter v1

Feature Branch: 390-restore-readiness-resolution-adapter-v1 Created: 2026-06-20 Status: Ready for implementation planning Input: User-provided candidate draft at /Users/ahmeddarrazi/Downloads/spec-390-restore-readiness-resolution-adapter-v1-improved.md

Candidate Selection Summary

Spec 390 is selected as a direct, user-provided manual candidate. It follows the completed resolution-readiness work in Specs 386 through 389 and applies the proven decision-first pattern to Restore preparation without turning it into a generic workflow framework.

The active automatic queue in docs/product/spec-candidates.md has no safe next-best-prep target remaining. Manual backlog alternatives were deferred because they either require explicit promotion or are broader than this bounded Restore-owned slice.

Completed-spec guardrail result:

• specs/386-review-publication-resolution-workflow-v1/ is completed and remains historical context only.
• specs/387-review-publication-resolution-decision-ux-v1/ is completed and remains historical context only.
• specs/388-resolution-proof-currentness-contract-v1/ is completed and remains historical context only.
• specs/389-governance-inbox-resolution-intake-v1/ is completed and remains historical context only.
• No existing specs/390-restore-readiness-resolution-adapter-v1/ artifact existed before this preparation branch.

Current repo truth shows the persisted resolution tables are review-publication-specific (review_publication_resolution_cases, review_publication_resolution_steps) and are not an approved generic action-key storage foundation. Therefore this spec selects Mode B for v1: Restore-local readiness guidance on existing Restore surfaces. Persisted generic resolution cases for Restore are out of scope unless a later spec explicitly creates and approves a generic persistence foundation.

Spec Candidate Check

Dimension	Score	Rationale
Nutzen	2	Restore is a critical admin workflow where blocked preparation must be explainable and safe.
Dringlichkeit	2	Existing Restore code already has readiness gates, but the user-facing path from blocked state to next safe action is fragmented.
Scope	2	The v1 slice is bounded to existing RestoreRun create/view surfaces and local derived guidance.
Komplexitaetslast	1	The draft introduces readiness states, reason families, and action planning, so implementation must stay Restore-local.
Produktnaehe	2	The result directly improves restore operator workflow and safety.
Wiederverwendung	1	It reuses existing RestoreSafetyResolver, RestoreRun, OperationRun, and Filament surfaces, but must not reuse review-specific persistence.

Decision: Approved as a bounded Core Enterprise feature with Mode B selected for v1.

Scope shrink applied during preparation:

• No generic workflow engine.
• No adapter registry.
• No new global navigation or global search surface.
• No automatic execution of Restore.
• No new persistence tables by default.
• No reuse of review-publication resolution persistence for Restore.
• No replacement of the Restore Wizard, RestoreSafetyResolver, Restore Preview, validation gates, confirmation, or OperationRun execution truth.

Scope

In Scope

• Derive a Restore-owned readiness summary from existing RestoreRun, wizard state, backup set, preview, checks, and OperationRun evidence.
• Show decision-first guidance when Restore cannot continue safely.
• Present deterministic next safe actions such as run checks, regenerate preview, review group mappings, review backup selection, open evidence, or return to confirmation when ready.
• Protect against stale guidance by tying guidance to the same basis/fingerprint concepts already used by Restore safety code.
• Support in-memory wizard state without creating orphaned persisted resolution cases.
• Support persisted RestoreRun records with local guidance on the existing view surface where the underlying record exists.
• Keep all execution truth inside existing Restore execution gates, confirmation, OperationRun, and safety validation.

Out of Scope

• Generic resolution framework, adapter registry, or cross-domain workflow engine.
• Persisted generic resolution cases or steps for Restore.
• New restore-specific database tables.
• New top-level navigation, global search result type, dashboard widget, or notification center intake.
• Automatic Restore execution, queued execution from guidance actions, or bypass of confirmation.
• Replacement of RestoreSafetyResolver, existing preview generation, checks, or execution services.
• Microsoft Graph write calls from the readiness guidance layer.
• Broad redesign of Restore Wizard layout beyond the guidance and action affordances needed by this feature.

Spec Scope Fields

• Scope: Existing tenant/environment-scoped Restore preparation and RestoreRun inspection surfaces in the Filament admin panel.
• Primary Routes:
  • GET admin/workspaces/{workspace}/environments/{environment}/restore-runs
  • GET admin/workspaces/{workspace}/environments/{environment}/restore-runs/create
  • GET admin/workspaces/{workspace}/environments/{environment}/restore-runs/{record}
• Route Names:
  • filament.admin.resources.workspaces.{workspace}.environments.{environment}.restore-runs.index
  • filament.admin.resources.workspaces.{workspace}.environments.{environment}.restore-runs.create
  • filament.admin.resources.workspaces.{workspace}.environments.{environment}.restore-runs.view
• Data Ownership: Existing restore_runs, backup_sets, and operation_runs remain the only persisted records involved. Restore readiness summary, reason, next action, and basis/fingerprint values are derived and non-persisted. Tenant-bound RestoreRun data remains scoped by workspace plus managed environment/tenant authorization; unsaved wizard state remains in-memory only.
• RBAC Requirements: Workspace/tenant/environment non-members must receive deny-as-not-found behavior through existing page/resource authorization. Members without view capability must not inspect readiness. Members without manage capability must not mutate preparation state and server-side execution must fail with capability denial. UI visibility is not authorization.
• Canonical View Status: This is not a new tenantless canonical view. Existing environment-scoped RestoreRun create/view surfaces remain the canonical operator surfaces for this feature.

User Problem

Restore operators can reach blocked, stale, or incomplete preparation states where the platform prevents unsafe execution, but the next safe recovery action is not always obvious. This creates support risk and can lead to repeated previews, skipped checks, or confusion between "not ready" and "failed."

This feature makes the Restore preparation state understandable without weakening the existing safety gates.

Primary Operator Copy Contract

The experience must use decision-first, safety-first language:

• "Restore can't continue yet."
• "Next safe action."
• "This will not execute the restore."
• "This guidance is based on the current restore scope and preview state."
• "The restore still requires final confirmation before execution."

The UI must avoid language that implies the readiness action executes the restore, approves a restore, or overrides a safety gate.

Users and Permissions

Actor	Capability expectation	Allowed by this spec
Workspace member with tenant view access	Inspect Restore readiness and evidence for accessible tenant/environment records.	View guidance and evidence links only.
Workspace member with tenant manage access	Perform existing Restore preparation actions.	Run checks, generate/regenerate preview, update wizard preparation inputs through existing Restore UI paths.
User without workspace membership or environment access	No access.	Existing access checks continue to block the surface.
User without manage access	No mutation.	Guidance actions that mutate preparation state are hidden or blocked by policy/server checks.

UI visibility is not authorization. All mutating preparation actions must still enforce server-side access checks.

User Scenarios and Tests

User Story 1 - Blocked Restore Shows the Next Safe Action (Priority: P1)

As an authorized restore operator, I want a blocked Restore preparation state to explain why Restore cannot continue and which safe action should happen next, so that I can recover without guessing.

Acceptance Criteria:

1. Given a Restore wizard state with missing or stale checks, when the operator reaches the preparation step, then the UI states that Restore cannot continue yet and shows "Run readiness checks" as the next safe action.
2. Given a Restore wizard state with a stale preview basis, when the operator reaches confirmation, then the UI blocks execution guidance and shows "Regenerate preview" as the next safe action.
3. Given a blocked state, when the operator sees the next safe action, then the copy states that the action will not execute the restore.

User Story 2 - Current Readiness Allows Continuation Without Extra Friction (Priority: P1)

As an authorized restore operator, I want current checks and preview evidence to be recognized, so that I can continue to confirmation without unnecessary repeated work.

Acceptance Criteria:

1. Given current checks and preview that match the selected Restore scope, when the operator reviews readiness, then the UI shows the Restore is ready for final confirmation.
2. Given current evidence with an OperationRun link, when the operator inspects details, then the UI links to the existing evidence where allowed.
3. Given current readiness, when the operator proceeds, then existing final confirmation and execution gates still apply.

User Story 3 - Persisted RestoreRun Records Explain Their State (Priority: P2)

As an operator reviewing a saved RestoreRun, I want the view page to explain whether the run is draft, previewed, pending, running, completed, failed, cancelled, or stale, so that I can decide what to inspect next.

Acceptance Criteria:

1. Given a draft or scoped RestoreRun with incomplete preparation, when an authorized user opens its view page, then the page shows local readiness guidance and next safe inspection/preparation action.
2. Given a queued or running RestoreRun, when an authorized user opens its view page, then the page emphasizes existing OperationRun execution truth rather than preparation guidance.
3. Given a completed, partial, failed, cancelled, or legacy-aborted RestoreRun, when an authorized user opens its view page, then the page links to existing result/evidence details and does not offer preparation actions that would imply mutation of that historical run.

User Story 4 - Unauthorized Users Cannot Mutate Preparation State (Priority: P2)

As a tenant owner, I want Restore readiness actions to obey existing RBAC boundaries, so that read-only users cannot run preparation mutations.

Acceptance Criteria:

1. Given a user with tenant view access but not tenant manage access, when the user sees readiness guidance, then mutating preparation actions are unavailable and server-side calls are rejected.
2. Given a user without workspace or environment access, when the user tries to access Restore readiness surfaces directly, then existing authorization behavior is preserved.
3. Given a user with manage access, when the user starts a preparation action, then the action logs or preserves existing audit/evidence behavior already associated with that Restore preparation action.

Requirements

Functional Requirements

• FR-390-001: The system MUST produce a Restore readiness summary from existing Restore state, including selected backup set, selected scope/items, checks state, preview state, group mapping requirements, execution status, and available OperationRun evidence.
• FR-390-002: The readiness summary MUST identify whether Restore is blocked, needs preparation, ready for final confirmation, executing, completed, failed, cancelled, or historical/non-actionable.
• FR-390-003: The readiness summary MUST identify the primary reason Restore cannot continue when it is not ready.
• FR-390-004: The readiness summary MUST identify one deterministic next safe action when a safe action exists.
• FR-390-005: The next safe action MUST be preparation-only unless it delegates to the existing final confirmation path.
• FR-390-006: The next safe action copy MUST state when the action will not execute the restore.
• FR-390-007: The system MUST protect against stale action execution by comparing the action's basis/fingerprint with the current Restore basis before performing a mutating preparation action.
• FR-390-008: The system MUST use existing RestoreSafetyResolver concepts for preview/check currentness where possible instead of creating a parallel source of truth.
• FR-390-009: The system MUST keep Restore execution authorization, confirmation, validation, and queueing inside the existing Restore execution path.
• FR-390-010: The system MUST NOT execute a Restore as part of a readiness guidance action.
• FR-390-011: The system MUST NOT create review-publication resolution cases or steps for Restore.
• FR-390-012: The system MUST NOT introduce generic resolution persistence in this v1 spec.
• FR-390-013: The system MUST support in-memory wizard state by showing inline guidance only.
• FR-390-014: The system MUST support persisted RestoreRun records by showing local guidance on existing Restore view surfaces where the record already exists.
• FR-390-015: The system MUST not create orphaned persisted cases for unsaved wizard state.
• FR-390-016: The system MUST keep the Restore Wizard as the owner of preparation input collection.
• FR-390-017: The system MUST keep Restore Preview as the owner of preview content.
• FR-390-018: The system MUST keep OperationRun as the owner of execution/evidence truth.
• FR-390-019: The system MUST show evidence links only where the current user is authorized to access the linked record.
• FR-390-020: The system MUST preserve existing tenant/workspace/environment scoping.
• FR-390-021: Mutating readiness/preparation actions MUST require the same manage capability expected by existing Restore preparation actions.
• FR-390-022: Read-only inspection MUST require the same view capability expected by existing RestoreRun view access.
• FR-390-023: Any new destructive or high-impact Filament action introduced by implementation MUST execute through Action::make(...)->action(...), enforce server-side authorization, and include ->requiresConfirmation() when destructive.
• FR-390-024: URL-only navigation actions MUST not be described as confirmed actions unless Filament v5 documentation is verified for that behavior.
• FR-390-025: Global search behavior MUST remain valid for RestoreRunResource: either the resource has an Edit/View page if searchable, or global search is explicitly disabled.
• FR-390-026: The implementation MUST provide meaningful empty or inactive states for any table, list, or repeated readiness item it adds.
• FR-390-027: The implementation MUST not add heavy global frontend assets for this feature.
• FR-390-028: The implementation MUST use existing Filament v5 and Livewire v4 patterns and avoid Filament v3/v4 APIs.
• FR-390-029: The implementation MUST avoid new Microsoft Graph calls during page render or readiness display.
• FR-390-030: The implementation MUST not assume a provider-specific restore backend beyond the existing RestoreRun data and service abstractions.
• FR-390-031: The implementation MUST maintain auditability for user-triggered preparation mutations by reusing or preserving existing operation/audit trails where available.
• FR-390-032: The implementation MUST include tests proving that stale guidance cannot mutate an out-of-date Restore preparation state.
• FR-390-033: The implementation MUST include tests proving read-only users cannot trigger mutating preparation actions.
• FR-390-034: The implementation MUST include tests proving execution still requires existing final confirmation and safety gates.

Non-Functional Requirements

• NFR-390-001: Readiness derivation MUST be deterministic for the same Restore state.
• NFR-390-002: Readiness derivation MUST be side-effect-free.
• NFR-390-003: Readiness display MUST not materially increase query count on Restore create/view pages.
• NFR-390-004: Readiness copy MUST be concise enough to fit existing Filament panel surfaces on desktop and mobile.
• NFR-390-005: The implementation MUST be testable without external Microsoft Graph calls.
• NFR-390-006: The implementation MUST be deployable without new environment variables, queue workers, scheduled commands, or persistent storage by default.

UI Surface Impact

Surface	Impact
RestoreRun create wizard	Existing page changed. Adds decision-first readiness guidance and next safe action affordances in current wizard steps.
RestoreRun view page	Existing page changed. Adds local readiness/status explanation for persisted runs where useful.
RestoreRun list table	No required change. Do not add new bulk or row mutation unless implementation proves a narrow need and updates this spec first.
Global search	No new result type. Validate existing RestoreRunResource hard rule if the implementation touches resource search behavior.
Navigation	No new top-level navigation, cluster, widget, or dashboard surface.
OperationRun links	Existing evidence links may be reused where authorization permits.

UI/UX Surface Classification

This feature materially changes reachable operator-facing surfaces. No No UI surface impact decision is claimed. Implementation must update the durable UI/productization coverage registry under docs/ui-ux-enterprise-audit/ for the changed RestoreRun create/view surfaces, or stop and update this spec if repo coverage tooling proves a narrower checked decision is required.

Surface	Page archetype	Surface class	Native/custom/shared	Primary persona	Primary operator question	Dominant next action	Dangerous actions	State ownership
RestoreRun create wizard	Create/Edit staged workflow	Preparation workflow surface	Native Surface using Filament wizard/presenter paths; no UI exception planned	Tenant operator/manager preparing a restore	"What prevents this restore from being safe to confirm, and what should I do next?"	Run checks, regenerate preview, review mappings, or continue to final confirmation when ready	Existing final Restore execution remains the dangerous action and stays behind existing confirmation/hard-confirm gates	Requested/draft/restorable state is owned by the Restore wizard and RestoreSafetyResolver-derived basis; readiness display is derived presentation only
RestoreRun view page	View/Detail status surface	Detail/status inspection surface	Native Surface using existing RestoreRun detail presenter paths; no UI exception planned	Tenant operator/manager or read-only reviewer inspecting a saved restore	"What state is this RestoreRun in, what evidence exists, and is any safe preparation/inspection action available?"	Inspect evidence, open OperationRun, or return to the create/preparation flow only where existing state permits	No new dangerous action; historical states must not expose preparation mutations	Inspect/execution state is owned by RestoreRun and OperationRun; local guidance must not duplicate or override execution truth

Page contract details:

• Default-visible information: readiness/status, primary reason, next safe action, mutation scope, and final-confirmation requirement.
• Diagnostics-only information: raw basis/fingerprint details, raw preview/check payload fragments, and support evidence metadata.
• Support/raw evidence gating: diagnostic/raw links require authorized view access to the related RestoreRun, BackupSet, environment, or OperationRun record.
• Duplicate-truth prevention: RestoreSafetyResolver remains checks/preview currentness truth; RestoreRun remains persisted restore status truth; OperationRun remains execution/evidence truth.
• Status-like readiness cues must use existing BadgeCatalog/BadgeRenderer or another central shared status path when rendered as badges; page-local badge colors or ad hoc status styling are not allowed.
• Multiple audience handling: read-only users get inspection-only affordances; tenant-manage users may use the existing Restore wizard preparation controls. V1 readiness guidance itself remains passive and does not introduce new guidance-owned mutating buttons; non-members must not learn the record exists.

UI Action Matrix

Action	Surface	Mutates preparation state	Executes Restore	Authorization	Confirmation
Run readiness checks	RestoreRun create wizard	Yes, through existing wizard control	No	Tenant manage	Existing action semantics, add confirmation only if implementation makes it high-impact/destructive. V1 guidance only labels this as the next safe action.
Generate preview	RestoreRun create wizard	Yes, through existing wizard control	No	Tenant manage	Existing action semantics. V1 guidance only labels this as the next safe action.
Regenerate preview	RestoreRun create wizard	Yes, through existing wizard control	No	Tenant manage	Existing action semantics. V1 guidance only labels this as the next safe action. Any future guidance-owned mutate button must validate stale basis before mutation.
Review group mappings	RestoreRun create wizard	User edits existing input	No	Tenant manage	Not destructive by itself.
Open evidence	RestoreRun create/view	No	No	Tenant view for linked record	Navigation action only.
Continue to confirmation	RestoreRun create wizard	No direct mutation	No	Tenant manage	Existing final confirmation still required before execution.
Execute restore	Existing Restore execution path	Yes	Yes	Tenant manage plus existing gates	Existing confirmation, hard confirm, safety validation, and OperationRun execution truth remain mandatory.

Key Entities and Concepts

This spec prefers existing entities and local derived value objects over new persisted models.

• RestoreRun: Existing persisted restore record. Owns restore status, selected scope, preview/results metadata, group mapping, idempotency key, and OperationRun linkage.
• BackupSet: Existing source for backup payload selection and restore scope.
• OperationRun: Existing evidence/execution truth for queued/running/completed operational work.
• RestoreSafetyResolver: Existing source for scope basis, preview basis, checks basis, preview integrity, checks integrity, and execution readiness concepts.
• Restore Readiness Summary: New local derived contract describing the current Restore preparation decision and reason. It is not a database entity.
• Restore Next Safe Action: New local derived contract describing a safe preparation or inspection action. It is not an execution command.
• Restore Guidance Basis/Fingerprint: New or reused deterministic basis value used by the resolver and tests to compare rendered guidance against current Restore scope. V1 exposes no guidance-owned mutating action; any future mutating guidance action must use this value to reject stale attempts before mutation.

Proportionality Review

This feature introduces a local Restore-specific readiness summary/action contract and possibly a small Restore-specific state/reason family. It does not introduce a new persisted entity, generic workflow engine, cross-domain taxonomy, or storage abstraction.

Constitution review result:

• New persisted entity: No.
• New database table: No.
• New enum/status family: Yes, but only local Restore readiness/reason/action identifiers derived from existing Restore state.
• New abstraction: Yes, bounded to Restore readiness derivation and presentation.
• New taxonomy/framework: No. Generic action resolution remains out of scope.
• Canonical user-facing view: No new canonical view. Existing Restore create/view surfaces remain the canonical surfaces.
• Reuse before build: Required. RestoreSafetyResolver, RestoreRun, RestoreRun presenters, OperationRun links, existing policies/capabilities, and Filament action patterns must be reused where possible.

The proportional response is to create Restore-local contracts and tests, not persistence or a generic adapter system.

Edge Cases

• RestoreRun has a legacy aborted status. Treat it as historical/non-actionable and preserve existing display compatibility.
• RestoreRun has stale checks but current preview. The next safe action must prioritize checks before confirmation.
• RestoreRun has current checks but stale preview. The next safe action must prioritize preview regeneration.
• RestoreRun is queued or running. Guidance must defer to OperationRun execution truth and avoid preparation actions.
• RestoreRun is completed, partial, failed, cancelled, or completed with errors. Guidance must explain result/evidence inspection and avoid preparation mutations.
• Wizard state is unsaved. Guidance must remain inline and non-persisted.
• User loses manage access after the page renders. Mutating action must fail server-side.
• Restore scope changes after readiness action render. Action must fail stale basis validation and ask the operator to refresh/regenerate.
• BackupSet or environment access is unavailable. Guidance must show safe blocked state without leaking inaccessible names or payload details.

Success Criteria

• SC-390-001: In tests, a blocked Restore preparation state produces one clear reason and one deterministic next safe action.
• SC-390-002: In tests, current checks and preview allow continuation to final confirmation while still requiring existing execution confirmation gates.
• SC-390-003: In tests, stale basis data prevents mutating readiness/preparation actions.
• SC-390-004: In tests, read-only users can inspect allowed readiness information but cannot trigger mutating preparation actions.
• SC-390-005: Browser smoke coverage verifies blocked, stale, and ready Restore wizard states with no copy implying automatic execution.
• SC-390-006: No new migration, environment variable, queue, scheduled command, global asset registration, or navigation surface is required for v1.

Testing Expectations

Implementation must include:

• Unit tests for Restore readiness derivation from representative Restore states.
• Unit tests for stale basis comparison, plus feature coverage proving V1 guidance stays passive and existing Restore execution gates remain canonical.
• Feature/Filament tests for RestoreRun create wizard guidance and action authorization.
• Feature/Filament tests for RestoreRun view guidance on persisted records.
• Tests proving existing execution confirmation/safety gates are still required.
• Browser smoke coverage for at least blocked, stale, and ready states if UI changes are visible in the panel.

Testing / Lane / Runtime Impact

• Runtime behavior impact: Yes. The implementation changes visible RestoreRun create/view behavior and adds derived readiness support code.
• Affected validation lanes:
  • Unit: Restore-local readiness resolver, reason/action selection, stale basis comparison, side-effect-free behavior.
  • Feature/Filament: RestoreRun create/view rendering, authorization boundaries, passive guidance behavior, execution-prerequisite blocking, and execution-gate preservation.
  • Browser: Feature-local smoke for blocked, stale, ready, and read-only visible UI states.
• Fixture/helper/factory/seed/context cost: Use existing Workspace, ManagedEnvironment, BackupSet, RestoreRun, OperationRun, membership, and capability fixtures/factories. Do not introduce provider, workspace, membership, or browser context as implicit defaults in shared helpers.
• Heavy-family decision: Keep. Browser coverage is feature-local smoke because the feature materially changes visible operator workflow; do not create a new broad heavy-governance family.
• Runtime budget/baseline/trend impact: No material suite-cost increase is expected. If browser or fixture expansion materially changes runtime, document the measured impact in the implementation PR and escalate as document-in-feature; recurring/structural cost must become follow-up-spec.
• Query budget: Restore readiness display must not add more than two database queries to the default Restore create or view render compared with the pre-feature fixture baseline. Authorized evidence links may add relationship loading only when visible and must be eager-loaded or documented.
• Escalation outcome: keep, provided implementation stays Restore-local and avoids generic persistence, hidden heavy fixtures, and broad browser families.

Preferred local validation commands:

cd apps/platform && ./vendor/bin/sail artisan test
cd apps/platform && ./vendor/bin/sail pint --dirty

Focused commands may be used during implementation once concrete test paths exist.

Deployment and Runtime Impact

• Database migrations: Not expected for v1.
• Environment variables: Not expected.
• Queue workers: No new workers expected.
• Scheduled commands: Not expected.
• Storage/volumes: Not expected.
• Filament assets: No new heavy assets expected. If registered assets are added despite this plan, deployment must include cd apps/platform && php artisan filament:assets.
• Staging validation: Required because Restore is an Intune-critical flow, even though v1 is guidance/preparation-only.
• Production promotion: Validate on Staging first, including authorization and no-auto-execute behavior.

Assumptions

• Existing RestoreRun create/view pages remain the primary surfaces.
• Existing RestoreSafetyResolver and RestoreRun presenter classes provide enough state to derive readiness without new persistence.
• Existing tenant manage/view capabilities remain the correct authorization boundary for Restore preparation and inspection.
• Mode B is sufficient for v1 because current resolution persistence is review-publication-specific.
• Any future generic resolution persistence requires a separate spec and proportionality review.

Open Questions

No blocking product questions remain for preparation. Implementation must verify exact class names, route names, and test fixture helpers before editing application code.

Follow-Up Candidates

• Persisted generic resolution case foundation, if a future cross-domain action-resolution model is explicitly approved.
• Governance Inbox Restore readiness intake, after Restore-local guidance proves stable.
• Provider-specific Restore adapter expansion, after the local Restore contract is validated.
• Restore preview item-level remediation guidance, if operators need row-level recovery actions.