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

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 Verify tenant-manage access remains required for existing Restore preparation mutations; V1 guidance exposes no mutating guidance-owned actions.
• T025 Add unit test proving stale guidance basis/fingerprint comparison rejects an out-of-date basis without changing Restore state; V1 guidance exposes no mutating guidance-owned action.
• 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 Keep preparation mutations on existing Restore wizard action methods; V1 readiness guidance remains passive next-safe-action copy.
• T044 N/A for V1: no mutating preparation action is exposed by readiness guidance; stale basis helper is implemented for future guidance-owned actions.
• T045 N/A for V1: no stale guidance-owned action can be invoked; existing wizard action feedback remains unchanged.
• 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 N/A for V1 readiness guidance: no new user-triggered preparation mutation is introduced; existing wizard action notifications remain canonical.
• 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. Not run in this pass; focused PHP and browser suites were used due repo-wide runtime.
• 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.