# Tasks: Restore Readiness Resolution Adapter v1

**Input**: `specs/390-restore-readiness-resolution-adapter-v1/spec.md`, `specs/390-restore-readiness-resolution-adapter-v1/plan.md`
**Branch**: `390-restore-readiness-resolution-adapter-v1`
**Mode**: Mode B - Restore-local guidance only

## Execution Rules

- Do not implement a generic resolution framework.
- Do not add a database migration unless `spec.md` and `plan.md` are updated first.
- Do not reuse review-publication resolution persistence for Restore.
- Do not add top-level navigation, global search surfaces, dashboards, or notification-center intake.
- Do not execute Restore from a readiness guidance action.
- Keep Restore execution behind existing confirmation, validation, and OperationRun paths.
- Keep all tasks unchecked until implementation work is actually completed.

## Phase 1: Repo Verification and Spec-Package Contracts

- [ ] T001 Verify current RestoreRun create/view routes, page classes, presenter classes, actions, and authorization methods in `apps/platform/app/Filament/Resources/RestoreRunResource.php` and nested page/presenter files.
- [ ] T002 Verify current RestoreSafetyResolver public methods and state contracts in `apps/platform/app/Support/RestoreSafety/RestoreSafetyResolver.php`.
- [ ] T003 Verify current RestoreRun status family in `apps/platform/app/Support/RestoreRunStatus.php`, including legacy statuses.
- [ ] T004 Verify OperationRun link/presenter/helper patterns used by RestoreRun and related operational pages.
- [ ] T005 Verify existing test fixture/factory patterns for RestoreRun, BackupSet, ManagedEnvironment, Workspace, and OperationRun.
- [ ] T006 Verify `RestoreRunResource` global-search behavior: confirm it has View/Edit page if searchable, or explicitly disable global search if implementation changes search behavior.
- [ ] T007 Create `specs/390-restore-readiness-resolution-adapter-v1/artifacts/current-restore-flow-inventory.md` documenting the verified Restore flow, existing safety gates, and exact code seams to reuse.
- [ ] T008 Create `specs/390-restore-readiness-resolution-adapter-v1/contracts/restore-readiness-state-matrix.md` defining Restore-local states, reasons, and priority ordering.
- [ ] T009 Create `specs/390-restore-readiness-resolution-adapter-v1/contracts/restore-requirement-map.md` mapping each readiness reason to existing RestoreSafetyResolver inputs, RestoreRun fields, and required authorization.
- [ ] T010 Create `specs/390-restore-readiness-resolution-adapter-v1/contracts/restore-ui-copy-contract.md` with approved decision-first copy and forbidden execution-implying copy.
- [ ] T011 Re-check the proportionality review after the contract files are drafted; update `spec.md` and `plan.md` before coding if any task implies new persistence or generic infrastructure.

## Phase 2: Tests First - Readiness Derivation

- [ ] T012 Add unit test coverage for missing checks readiness in `apps/platform/tests/Unit/Support/RestoreReadinessResolution/`.
- [ ] T013 Add unit test coverage for stale checks readiness in `apps/platform/tests/Unit/Support/RestoreReadinessResolution/`.
- [ ] T014 Add unit test coverage for missing preview readiness in `apps/platform/tests/Unit/Support/RestoreReadinessResolution/`.
- [ ] T015 Add unit test coverage for stale preview readiness in `apps/platform/tests/Unit/Support/RestoreReadinessResolution/`.
- [ ] T016 Add unit test coverage for current checks plus current preview ready state.
- [ ] T017 Add unit test coverage for group-mapping-required readiness where existing Restore state exposes that requirement.
- [ ] T018 Add unit test coverage for queued and running RestoreRun states deferring to OperationRun execution truth.
- [ ] T019 Add unit test coverage for completed, partial, failed, cancelled, legacy aborted, and completed-with-errors states as historical/non-actionable.
- [ ] T020 Add unit test coverage proving next safe action selection is deterministic for the same Restore state.
- [ ] T021 Add unit test coverage proving readiness derivation is side-effect-free and does not persist or dispatch work.

## Phase 3: Tests First - Authorization and Stale Action Protection

- [ ] T022 Add feature or Filament test proving a tenant-view-only user can inspect allowed readiness guidance but cannot invoke mutating preparation actions.
- [ ] T023 Add feature or Filament test proving a user without workspace/environment access cannot inspect Restore readiness through direct route access.
- [ ] T024 Add feature or Filament test proving tenant-manage access is required for mutating preparation guidance actions.
- [ ] T025 Add feature or unit test proving a stale guidance basis/fingerprint rejects a mutating preparation action without changing Restore state.
- [ ] T026 Add feature test proving existing Restore execution still requires final confirmation, hard confirm, and current safety gates.
- [ ] T027 Add feature test proving readiness guidance actions do not create OperationRun records directly.
- [ ] T028 Add feature test proving readiness guidance does not create review-publication resolution cases or steps.

## Phase 4: Restore-Local Support Implementation

- [ ] T029 Create a Restore-local support namespace under `apps/platform/app/Support/RestoreReadinessResolution/`.
- [ ] T030 Implement a Restore readiness summary value object or DTO aligned with `contracts/restore-readiness-state-matrix.md`.
- [ ] T031 Implement Restore-local reason identifiers and next-action identifiers without adding a generic taxonomy.
- [ ] T032 Implement a side-effect-free Restore readiness resolver that consumes RestoreRun or wizard state plus RestoreSafetyResolver outputs.
- [ ] T033 Implement deterministic next-action priority ordering matching the contract matrix.
- [ ] T034 Implement a Restore guidance basis/fingerprint helper that reuses existing scope/checks/preview basis concepts where possible.
- [ ] T035 Implement presenter-friendly formatting for readiness status, reason, next action, evidence, and no-auto-execute copy.
- [ ] T036 Ensure the resolver performs no Graph calls, no queue dispatches, no database writes, and no OperationRun creation.
- [ ] T037 Ensure the resolver handles in-memory wizard state without requiring a persisted RestoreRun id.
- [ ] T038 Ensure the resolver handles persisted RestoreRun records without creating new resolution cases.

## Phase 5: Create Wizard Integration

- [ ] T039 Integrate Restore readiness guidance into `RestoreRunCreatePresenter` or the existing create wizard presentation path.
- [ ] T040 Show blocked guidance for missing checks with "This will not execute the restore" copy.
- [ ] T041 Show stale preview guidance with regenerate-preview as the next safe action.
- [ ] T042 Show ready-for-confirmation guidance without bypassing existing final confirmation controls.
- [ ] T043 Wire preparation actions through existing Restore wizard action methods where possible.
- [ ] T044 Add basis/fingerprint validation before any mutating preparation action exposed by the guidance UI.
- [ ] T045 Return a clear notification or inline error when a stale action is rejected.
- [ ] T046 Ensure read-only users do not see or cannot activate mutating preparation actions.
- [ ] T047 Ensure guidance copy fits existing Filament panel layout at desktop and mobile widths.
- [ ] T048 Avoid adding heavy assets, custom global CSS, or published Filament internals.

## Phase 6: Persisted RestoreRun View Integration

- [ ] T049 Integrate local guidance into `RestoreRunDetailPresenter` or the existing RestoreRun view presentation path.
- [ ] T050 Show draft/scoped/checked/previewed persisted runs as preparation states where applicable.
- [ ] T051 Show pending/queued/running runs as execution states that defer to OperationRun evidence.
- [ ] T052 Show completed/partial/failed/cancelled/aborted/completed-with-errors runs as historical result states.
- [ ] T053 Add authorized OperationRun evidence links only where the current user may access the linked record.
- [ ] T054 Avoid preparation mutation actions on historical/non-actionable RestoreRun states.
- [ ] T055 Preserve existing row click, view page, and lifecycle action behavior on RestoreRun list/table.

## Phase 7: Filament Actions, Notifications, and Empty States

- [ ] T056 Review any new Filament action against v5 patterns and use `Action::make(...)->action(...)` for execution actions.
- [ ] T057 Add `->requiresConfirmation()` to any destructive action if implementation introduces one; otherwise document that no destructive action was introduced.
- [ ] T058 Ensure URL-only actions use `->url(...)` and are not described as modal-confirmed actions.
- [ ] T059 Add explicit success/error/stale notifications for user-triggered preparation mutations where outcomes are not instantly obvious.
- [ ] T060 Add meaningful empty/inactive states for any repeated readiness item or evidence list introduced.
- [ ] T061 Confirm no new panel provider registration is required; if it becomes required, register through `bootstrap/providers.php` only.

## Phase 8: UI Coverage and Browser Smoke

- [ ] T062 Add or update Filament feature tests for blocked wizard guidance.
- [ ] T063 Add or update Filament feature tests for stale preview guidance.
- [ ] T064 Add or update Filament feature tests for ready-for-confirmation guidance.
- [ ] T065 Add or update Filament feature tests for read-only inspection behavior.
- [ ] T066 Add or update Filament feature tests for persisted RestoreRun view guidance.
- [ ] T067 Run browser smoke for blocked, stale, ready, and read-only Restore guidance states if visible UI changed.
- [ ] T068 Verify no visible copy implies automatic Restore execution.
- [ ] T069 Update durable UI/productization coverage registry artifacts under `docs/ui-ux-enterprise-audit/` for the changed RestoreRun create/view surfaces.
- [ ] T070 Update `docs/ui-ux-enterprise-audit/target-experience-briefs/restore-safety-workflow.md` if the implementation changes the documented target experience; otherwise record an explicit checked target-brief no-change decision in the coverage update.

## Phase 9: Regression and Safety Validation

- [ ] T071 Run focused unit tests for `Support/RestoreReadinessResolution`.
- [ ] T072 Run focused Restore feature tests.
- [ ] T073 Run focused Filament RestoreRunResource tests.
- [ ] T074 Run the full platform test suite with `cd apps/platform && ./vendor/bin/sail artisan test` when feasible.
- [ ] T075 Run `cd apps/platform && ./vendor/bin/sail pint --dirty`.
- [ ] T076 Run `git diff --check`.
- [ ] T077 Verify no database migration was added.
- [ ] T078 Verify no new environment variables, queues, scheduled commands, storage volumes, or global assets were added.
- [ ] T079 Verify no review-publication resolution models/tables are referenced by Restore readiness code.
- [ ] T080 Verify no generic adapter registry or action-resolution framework was introduced.
- [ ] T081 Verify no Restore readiness code calls Microsoft Graph directly.
- [ ] T082 Verify no Restore execution path bypasses existing final confirmation and safety gates.
- [ ] T083 Verify `RestoreRunResource` global search behavior still satisfies the Filament v5 View/Edit-page rule or is explicitly disabled.
- [ ] T084 Verify Restore readiness display stays within the spec query budget for default Restore create/view renders, or document the measured exception and update the spec before delivery.
- [ ] T085 Verify mutating preparation actions preserve/reuse existing audit or operation evidence behavior; document why no audit event is required for any non-mutating path.
- [ ] T086 Verify the provider seam remains platform-core presentation over existing RestoreRun/BackupSet/RestoreSafetyResolver/OperationRun data and does not leak provider-specific semantics into platform-core contracts.
- [ ] T087 Verify OperationRun-linked UI reuses the central OperationRun Start UX Contract, remains deep-link/inspect-only, and does not queue DB notifications from readiness guidance.
- [ ] T088 Verify status-like readiness cues use BadgeCatalog/BadgeRenderer or another central shared status path instead of page-local badge styling.

## Phase 10: Delivery Notes

- [ ] T089 Document implementation validation results in the final response, including tests run and any skipped browser checks.
- [ ] T090 State Livewire v4.0+ compliance in the final implementation response.
- [ ] T091 State provider registration impact in the final implementation response.
- [ ] T092 State global-search status for RestoreRunResource in the final implementation response.
- [ ] T093 State destructive-action/confirmation/authorization handling in the final implementation response.
- [ ] T094 State asset strategy and whether `filament:assets` is needed in the final implementation response.
- [ ] T095 State the testing plan/results in the final implementation response.

## Dependencies

- Phase 1 must complete before app code changes.
- Phase 2 and Phase 3 tests should be written before or alongside Phase 4 support implementation.
- Phase 4 must complete before UI integration in Phases 5 and 6.
- Phase 5 and Phase 6 can proceed independently after Phase 4.
- Phase 8 browser smoke depends on visible UI integration.
- Phase 9 must complete before delivery.

## Parallel Work Candidates

- T012 through T021 can be split by readiness state after contracts exist.
- T022 through T028 can be split by authorization/stale-action concern after fixture patterns are verified.
- T049 through T055 can proceed in parallel with T039 through T048 after the support resolver is stable.
- T062 through T066 can be written in parallel with UI integration once page/presenter seams are known.