--- description: "Task list for Spec 084 implementation" --- # Tasks: Verification Surfaces Unification **Input**: Design documents from `/specs/084-verification-surfaces-unification/` **Tests**: REQUIRED (Pest) — this feature changes runtime behavior. ## Phase 1: Setup (Shared Infrastructure) **Purpose**: Establish a safe baseline and align on touched surfaces. - [X] T001 Capture baseline behavior by running existing verification tests in tests/Feature/Verification/VerificationStartDedupeTest.php and tests/Feature/ProviderConnections/ProviderOperationBlockedGuidanceSpec081Test.php - [X] T002 Identify current tenant “Verify configuration” surface implementation in app/Filament/Resources/TenantResource/Pages/ViewTenant.php and document expected deltas in specs/084-verification-surfaces-unification/quickstart.md --- ## Phase 2: Foundational (Blocking Prerequisites) **Purpose**: Shared primitives required by ALL user stories. **⚠️ CRITICAL**: No user story work should begin until this phase is complete. - [X] T003 Add schema-valid stub verification report for blocked provider.connection.check runs in app/Services/Providers/ProviderOperationStartGate.php (write context.verification_report after finalizeBlockedRun) - [X] T004 [P] Add helper to build blocked/preflight verification checks payload in app/Support/Verification/ (e.g., new BlockedVerificationReportFactory.php used by ProviderOperationStartGate) - [X] T005 Add a non-breaking tenant-default start helper in app/Services/Verification/StartVerification.php (keep existing explicit-connection API; delegate default-connection resolution to ProviderOperationStartGate) - [X] T006 Ensure blocked stub report includes next steps links from context.next_steps and normalized reason_code from context.reason_code in app/Support/Verification/BlockedVerificationReportFactory.php - [X] T007 Add Pest coverage for blocked stub report invariant in tests/Feature/Verification/ (new test file asserting completed blocked provider.connection.check has context.verification_report and it validates via VerificationReportSchema) - [X] T027 Enforce tenant entitlement for tenant-associated runs in app/Policies/OperationRunPolicy.php and app/Filament/Pages/Operations/TenantlessOperationRunViewer.php (deny-as-not-found when workspace membership or tenant entitlement is missing) **Checkpoint**: A blocked provider.connection.check run always has a schema-valid stored report. --- ## Phase 3: User Story 1 — Verify tenant configuration consistently (Priority: P1) 🎯 MVP **Goal**: Start verification from tenant detail view and render the latest stored report DB-only. **Independent Test**: Trigger the tenant verify action and confirm it creates/dedupes an OperationRun and the tenant embedded viewer renders from stored run context only. ### Tests (write first) - [X] T008 [P] [US1] Update tests/Feature/ProviderConnections/ProviderOperationBlockedGuidanceSpec081Test.php to assert tenant verify start now creates a blocked OperationRun and includes a schema-valid verification_report stub - [X] T009 [P] [US1] Add tenant verify happy-path test in tests/Feature/Filament/ (new test file calling ViewTenant action and asserting ProviderConnectionHealthCheckJob dispatch + canonical view-run link) - [X] T010 [P] [US1] Add tenant embedded viewer DB-only test in tests/Feature/Filament/ (new test asserting the widget/view reads OperationRun.context only; no provider calls during render) - [X] T032 [P] [US1] Add FR-007 regression test in tests/Feature/Filament/ asserting tenant view render path never triggers synchronous verification or permission inventory persistence ### Implementation - [X] T011 [US1] Refactor “Verify configuration” action in app/Filament/Resources/TenantResource/Pages/ViewTenant.php to start/dedupe provider.connection.check via app/Services/Verification/StartVerification.php (no synchronous Graph work) - [X] T012 [US1] Apply UI enforcement to the tenant verify action in app/Filament/Resources/TenantResource/Pages/ViewTenant.php using App\Support\Rbac\UiEnforcement with Capabilities::PROVIDER_RUN (visible-but-disabled; server still 403) - [X] T013 [US1] Ensure tenant verify notifications include a canonical tenantless “View run” link using App\Support\OperationRunLinks::tenantlessView in app/Filament/Resources/TenantResource/Pages/ViewTenant.php - [X] T033 [US1] Refactor tenant list “Verify configuration” action in app/Filament/Resources/TenantResource.php to the same unified provider.connection.check start path + canonical tenantless run links - [X] T014 [P] [US1] Create a tenant verification viewer widget class in app/Filament/Widgets/Tenant/TenantVerificationReport.php (select latest provider.connection.check run for the current tenant) - [X] T015 [P] [US1] Create widget view resources/views/filament/widgets/tenant/tenant-verification-report.blade.php with states: empty (Start verification CTA), in-progress, completed (render filament.components.verification-report-viewer) - [X] T016 [US1] Register the tenant verification viewer widget on the tenant view page by updating app/Filament/Resources/TenantResource/Pages/ViewTenant.php getHeaderWidgets() to include TenantVerificationReport - [X] T017 [US1] Implement the embedded viewer “Start verification” CTA to invoke the same unified start path (StartVerification) in app/Filament/Widgets/Tenant/TenantVerificationReport.php - [X] T018 [US1] Ensure the embedded viewer “View run” link uses OperationRunLinks::tenantlessView in app/Filament/Widgets/Tenant/TenantVerificationReport.php and resources/views/filament/widgets/tenant/tenant-verification-report.blade.php **Checkpoint**: US1 works end-to-end using queued OperationRun and DB-only rendering. --- ## Phase 4: User Story 2 — Onboarding verify access behaves identically (Priority: P2) **Goal**: Onboarding verification uses the same run type, dedupe/busy semantics, and viewer behavior. **Independent Test**: Start verification in onboarding twice and assert dedupe/busy behavior and canonical links match tenant surface. ### Tests - [X] T019 [P] [US2] Update tests/Feature/Onboarding/OnboardingVerificationTest.php to assert busy/deduped notifications link to the canonical tenantless operations viewer route - [X] T020 [P] [US2] Add regression test ensuring onboarding verification uses provider.connection.check and stores verification_report in tests/Feature/Onboarding/OnboardingVerificationTest.php ### Implementation - [X] T021 [US2] Ensure app/Filament/Pages/Workspaces/ManagedTenantOnboardingWizard.php startVerification() uses the same unified provider.connection.check start mechanism (ProviderOperationStartGate) and remains enqueue-only - [X] T022 [US2] Ensure onboarding “View run” links remain canonical via OperationRunLinks::tenantlessView (or equivalent tenantlessOperationRunUrl) in app/Filament/Pages/Workspaces/ManagedTenantOnboardingWizard.php - [X] T023 [US2] Confirm onboarding verification report rendering uses App\Filament\Support\VerificationReportViewer only (no external calls) in app/Filament/Pages/Workspaces/ManagedTenantOnboardingWizard.php --- ## Phase 5: User Story 3 — Use canonical run links everywhere (Priority: P3) **Goal**: Every verification surface links to the same tenantless run viewer route, and tenantless viewing enforces workspace + tenant entitlement (404 when missing). **Independent Test**: From both tenant and onboarding surfaces, follow “View run” and confirm it resolves to the same canonical route and is deny-as-not-found for non-entitled actors. ### Tests - [X] T024 [P] [US3] Add canonical link assertions for tenant verify notifications in tests/Feature/Filament/ (update test from T009 to assert route name admin.operations.view) - [X] T025 [P] [US3] Add canonical link assertions for onboarding notifications in tests/Feature/Onboarding/OnboardingVerificationTest.php - [X] T026 [P] [US3] Add authorization test for tenantless run viewer requiring workspace membership + tenant entitlement (404 semantics) in tests/Feature/RunAuthorizationTenantIsolationTest.php ### Implementation - [X] T028 [US3] Ensure all verification surfaces use OperationRunLinks::tenantlessView (or identical canonical route helper) in app/Filament/Resources/TenantResource/Pages/ViewTenant.php and app/Filament/Pages/Workspaces/ManagedTenantOnboardingWizard.php --- ## Phase 6: Polish & Cross-Cutting Concerns **Purpose**: Formatting, stability, and quickstart validation. - [X] T034 Fix tenant page widgets to resolve tenant from record context (Admin panel) and add regression coverage for Recent operations + Start verification disabled state - [X] T029 Run formatting on changed files using vendor/bin/sail bin pint --dirty (e.g., app/Filament/Resources/TenantResource/Pages/ViewTenant.php, app/Services/Providers/ProviderOperationStartGate.php, tests/Feature/Verification/*) - [X] T030 Run targeted Pest suite for this feature using vendor/bin/sail artisan test --compact tests/Feature/Verification/ tests/Feature/ProviderConnections/ProviderOperationBlockedGuidanceSpec081Test.php tests/Feature/Onboarding/OnboardingVerificationTest.php tests/Feature/RunAuthorizationTenantIsolationTest.php - [X] T031 Validate manual flows in specs/084-verification-surfaces-unification/quickstart.md and update it if any step text is now inaccurate --- ## Dependencies & Execution Order - Phase 1 (Setup) → Phase 2 (Foundational) → user stories. - User stories after Phase 2: - **US1 (P1)** can proceed immediately after Phase 2. - **US2 (P2)** can proceed after Phase 2 (independent of US1). - **US3 (P3)** should run after US1 + US2 (to validate “every surface”). ### Dependency Graph (stories) - Foundation → US1 - Foundation → US2 - US1 + US2 → US3 --- ## Parallel Execution Examples ### US1 parallelizable tasks - T008, T009, T010, and T032 can be developed in parallel (separate test files). - T014 and T015 can be developed in parallel (widget class vs Blade view). ### US2 parallelizable tasks - T019 and T020 can be developed in parallel within tests/Feature/Onboarding/. ### US3 parallelizable tasks - T024, T025, T026 can be developed in parallel (different test targets). --- ## Implementation Strategy ### MVP First (US1) 1. Complete Phase 1–2. 2. Implement US1 tests (T008–T010, T032) → ensure they fail. 3. Implement US1 code (T011–T018, T033) → ensure tests pass. 4. Run Phase 6 tasks to format + verify. ### Incremental Delivery - Add US2 next to remove onboarding/tenant variance. - Finish with US3 to unify canonical links + tenantless authorization guarantees across all surfaces.