TenantAtlas/specs/364-restore-high-risk-operation-reconciliation/tasks.md

Tasks: Spec 364 - Restore and High-Risk Operation Reconciliation

Input: Design documents from /specs/364-restore-high-risk-operation-reconciliation/ Prerequisites: spec.md, plan.md

Tests: Runtime behavior changes are required to use Pest. This feature needs Unit and Feature coverage. Browser smoke is required only if visible Operations or Restore detail hierarchy materially changes.

Operations: Existing restore.execute runs must continue to use OperationRunService, the current OperationRun UX contract, and current queued/terminal notification behavior. OperationRun.status and OperationRun.outcome transitions must remain service-owned.

RBAC: No new capability strings are expected. Existing workspace/managed-environment entitlement and restore execution capability semantics remain authoritative.

Non-goals: Do not add new operation types, new OperationRun outcomes, new migrations, new Graph contracts, new high-risk framework machinery, new Restore wizard behavior, or compatibility shims.

Test Governance Checklist

• Lane assignment is named and is the narrowest sufficient proof for restore proof hardening.
• New or changed tests stay in the smallest honest family; any browser smoke is explicit and justified.
• Shared helpers, factories, seeds, fixtures, and context defaults stay cheap by default.
• Planned validation commands cover the change without pulling unrelated lane cost.
• The declared surface profiles shared-detail-family, monitoring-state-page, and dangerous-workflow are explicit.
• No new outcome/status family, persistence layer, or generic high-risk framework is introduced.

Phase 1: Setup And Repo Truth

Purpose: Re-confirm the exact current restore and OperationRun truth before implementation.

• T001 Re-read specs/364-restore-high-risk-operation-reconciliation/spec.md, plan.md, tasks.md, and checklists/requirements.md.
• T002 Re-read related historical context only: Specs 333, 335, 358, 359, 360, 361, 362, and 363. Do not modify their artifacts.
• T003 [P] Confirm current restore adapter behavior in apps/platform/app/Support/Operations/Reconciliation/RestoreExecuteReconciliationAdapter.php.
• T004 [P] Confirm current service-owned reconciliation write behavior in apps/platform/app/Services/OperationRunService.php and apps/platform/app/Services/AdapterRunReconciler.php.
• T005 [P] Confirm current restore result/proof truth in apps/platform/app/Support/RestoreSafety/RestoreSafetyResolver.php, apps/platform/app/Filament/Resources/RestoreRunResource/Presenters/RestoreRunDetailPresenter.php, and apps/platform/resources/views/filament/infolists/entries/restore-results.blade.php.
• T006 [P] Confirm current restore execution start and audit behavior in apps/platform/app/Filament/Resources/RestoreRunResource.php, apps/platform/app/Jobs/ExecuteRestoreRunJob.php, and apps/platform/app/Services/Intune/RestoreService.php.
• T007 Confirm no migration, package, env var, queue family, scheduler, storage, Filament panel/provider, asset registration, or global-search change is required.

Phase 2: Foundational Tests

Purpose: Add failing tests for proof-gated restore.execute reconciliation before runtime edits.

• T008 [P] Add coverage for complete success proof, preview-only, missing post-run evidence, mixed item outcomes, blocked proof, failed proof, missing audit continuity, soft-deleted RestoreRun proof, and wrong-scope proof. Completed in apps/platform/tests/Feature/Operations/Spec364RestoreExecuteReconciliationTest.php because the proof contract is DB-backed.
• T009 [P] Add coverage asserting RestoreExecuteReconciliationAdapter does not return succeeded for previewed, terminal-status-only, missing-proof, missing-audit, soft-deleted, or wrong-scope RestoreRuns. Completed in the focused Spec 364 Feature coverage.
• T010 [P] Add Feature coverage in apps/platform/tests/Feature/Operations/Spec364RestoreExecuteReconciliationTest.php proving adapter reconciliation writes safe context.reconciliation, flat numeric summary counts, safe audit/proof reason metadata, and existing outcomes only.
• T011 [P] Add Feature coverage proving a RestoreRun from another workspace, another managed environment, or a soft-deleted RestoreRun cannot reconcile the OperationRun or leak related links. Completed in Spec364RestoreExecuteReconciliationTest.php.
• T012 [P] Add or extend Feature coverage for current Operations/detail fallout so proof gaps read as partial/blocked/failed instead of calm success. Completed through focused Spec 364 coverage plus restore/operation regression suites.
• T013 [P] Add or extend Restore detail Feature coverage so operation proof and post-run evidence remain distinct. Completed through existing Spec 335 restore detail coverage and updated recovery-attention regressions.

Phase 3: Restore Adapter Hardening (P1)

Goal: Reconcile restore.execute as succeeded only with a complete proof bundle.

Independent Test: T008-T011 pass and show no success for preview-only, missing-proof, missing-audit, soft-deleted, wrong-scope, or mixed-result cases.

• T014 Implement proof-gated success rules from the spec's Success Proof Bundle Matrix in apps/platform/app/Support/Operations/Reconciliation/RestoreExecuteReconciliationAdapter.php.
• T015 Ensure RestoreRunStatus::Previewed is treated as pre-execution truth and never maps to successful restore.execute execution in apps/platform/app/Support/Operations/Reconciliation/RestoreExecuteReconciliationAdapter.php.
• T016 Map mixed item outcomes or incomplete verification/post-run evidence to OperationRunOutcome::PartiallySucceeded with restore-specific reason metadata in apps/platform/app/Support/Operations/Reconciliation/RestoreExecuteReconciliationAdapter.php.
• T017 Map write-gate/provider/backup/scope blockers to existing blocked or failed outcomes when same-scope restore proof exists, and reserve non-final not_reconciled only for cases where the adapter cannot safely identify same-scope proof.
• T018 Keep summary counts flat numeric-only and compatible with current OperationRun summary rules in apps/platform/app/Support/Operations/Reconciliation/RestoreExecuteReconciliationAdapter.php.
• T019 N/A - proof-rule duplication stayed bounded inside RestoreExecuteReconciliationAdapter; no broader helper or framework was added.
• T020 Verify apps/platform/app/Services/AdapterRunReconciler.php still syncs restore timestamps only from safe evidence and does not turn non-final decisions into writes.

Phase 4: Visible Proof Fallout (P1/P2)

Goal: Keep Operations and Restore detail honest without creating a new UI pattern.

Independent Test: Feature tests show Operations and Restore detail distinguish success, partial, blocked, failed, and proof gaps.

• T021 N/A - current OperationRun surfaces already render context.reconciliation proof-gap reasons.
• T022 Update apps/platform/app/Filament/Resources/OperationRunResource.php only if the shared implementation seam must expose restore proof-gap metadata consistently.
• T023 N/A - the presenter already preserved operation proof versus post-run evidence; only recovery-attention outcome interpretation needed adjustment.
• T024 Preserved the Restore Run detail distinction between operation proof and post-run evidence in apps/platform/resources/views/filament/infolists/entries/restore-results.blade.php.
• T025 Keep raw provider payloads, raw credential data, and internal reason ownership out of default-visible UI and audit metadata.
• T026 Do not add a new page, route, navigation entry, Filament panel/provider registration, or asset registration.

Phase 5: Unsupported Families And Anti-Creep

Goal: Keep Spec 364 bounded to restore.execute.

• T027 Add or extend static/Unit coverage proving restore.verify, restore.rollback.*, promotion.execute, AI execution, and generic high-risk operation types are not registered by Spec 364.
• T028 Verify apps/platform/app/Support/Operations/Reconciliation/OperationRunReconciliationRegistry.php does not gain a generic high-risk adapter or future restore family in this slice.
• T029 Verify no new OperationRunOutcome, OperationRunStatus, RestoreRunStatus, database migration, or persisted restore verification model was introduced.
• T030 Record any future restore verification or rollback needs as follow-up only in the implementation close-out note, not in runtime code.

Phase 6: Validation And Close-Out

Purpose: Run focused validation and document the final proof boundary.

• T031 Run cd apps/platform && php vendor/bin/pest --filter=Spec364.
• T032 Run cd apps/platform && php vendor/bin/pest --filter=Restore.
• T033 Run cd apps/platform && php vendor/bin/pest --filter=OperationRun.
• T034 N/A - no new Spec 364 browser smoke file was added; existing restore browser smoke coverage ran under the broad Restore filter.
• T035 Run cd apps/platform && php vendor/bin/pint --dirty.
• T036 Run git diff --check.
• T037 Confirm final implementation keeps reconciliation DB-local and does not introduce Graph/provider calls from adapter, presenter, or render paths.
• T038 Confirm Livewire v4.0+ compliance remains unchanged and Filament providers remain registered through apps/platform/bootstrap/providers.php.
• T039 Confirm globally searchable resources were not enabled or changed; if any resource global search was touched unexpectedly, document View/Edit page safety or disable it.
• T040 Confirm destructive/high-impact restore actions still execute via ->action(...), require confirmation, reauthorize server-side, write audit logs, and are covered by tests.
• T041 Confirmed no new Filament assets were registered; filament:assets deployment handling is unchanged.
• T042 Close-out is recorded in the agent final response: proof boundary, tests run, browser smoke decision, deployment impact, and deferred follow-up candidates.

Dependencies & Execution Order

• Phase 1 must finish before tests and implementation.
• Phase 2 tests should be added before Phase 3 runtime edits.
• Phase 3 blocks Phase 4 visible fallout because UI should consume final proof semantics.
• Phase 5 can run after Phase 3 and before close-out.
• Phase 6 is final validation.

Parallel Opportunities

• T003-T006 can run in parallel.
• T008-T013 can be authored in parallel if they touch separate test files.
• T021-T024 can be split only after proof semantics are final.
• Validation commands should run after implementation and formatting.

Implementation Strategy

1. Prove the current adapter overclaims success with focused failing tests.
2. Tighten adapter proof rules without changing persistence or operation outcomes.
3. Adjust visible presentation only where existing copy cannot express stricter proof truth.
4. Guard unsupported future families.
5. Run focused validation and browser smoke only if UI hierarchy changed.

Notes

• [P] tasks are parallelizable only when they touch separate files.
• Every user-visible proof or reason label must avoid false recovery claims.
• Do not implement application code during SpecKit preparation.