TenantAtlas/specs/254-remove-acknowledged-compat/tasks.md
ahmido 54fb65a63a
Some checks failed
Main Confidence / confidence (push) Failing after 54s
chore: promote platform-dev to dev (#297)
This pull request promotes the current state of `platform-dev` to the main integration branch `dev`. It includes recent features, fixes, and architectural refinements validated on the platform development track.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #297
2026-04-29 07:50:16 +00:00

28 KiB

Tasks: Remove Legacy Acknowledged Finding Status Compatibility

Input: Design documents from /specs/254-remove-acknowledged-compat/ Prerequisites: plan.md, spec.md, checklists/requirements.md

Tests (TEST-GOV-001): REQUIRED (Pest). Keep proof in the targeted fast-feedback and confidence lanes named in specs/254-remove-acknowledged-compat/plan.md, plus the retained heavy-governance guards already called out there. Prefer focused new proof in apps/platform/tests/Feature/Findings/RemoveAcknowledgedCompatibilityWorkflowTest.php, apps/platform/tests/Unit/Findings/FindingStatusSemanticsTest.php, apps/platform/tests/Unit/Support/Filament/FindingStatusFilterCatalogTest.php, and apps/platform/tests/Feature/Auth/RemoveAcknowledgedCapabilityAliasTest.php, then prove summary convergence through the existing downstream customer-health, governance-inbox, baseline, alert, tenant-review, and support-diagnostics tests instead of widening the suite. Operations: This slice does not add or change an OperationRun start family, does not add a new audit action ID, and must not introduce migration shims, fallback readers, or repair tooling. RBAC: Preserve current /admin/t/{tenant} tenant isolation, deny-as-not-found 404 for non-members or out-of-scope users, and 403 for in-scope capability failures on surviving findings actions. Remove tenant_findings.acknowledge from the capability registry and role mappings without widening any unrelated authorization behavior. UI / Surface Guardrails: This is a review-mandatory cleanup across native Filament findings surfaces and canonical /admin summary or inbox shells. Keep standard-native-filament relief for the tenant findings resource and global-context-shell proof for workspace summaries, and do not add panels, assets, local status presenters, or replacement workflow affordances. Badges / Filters (BADGE-001 / XCUT-001): Remove the legacy acknowledged branch through shared findings status seams only. BadgeCatalog, FilterOptionCatalog, and the existing findings resource or summary builders remain the supported paths; no page-local mapping or one-off status label is allowed. Organization: Tasks are grouped by user story so each slice stays independently verifiable. Recommended delivery order is Phase 1 -> Phase 2 -> US1 and US2 in parallel -> US3 -> final cleanup and validation, because canonical RBAC proof only matters after the workflow and summary surfaces stop carrying acknowledged compatibility.

Implementation note: Several downstream consumers already converged automatically once Finding::openStatusesForQuery() and the shared RBAC/filter seams were corrected. Where direct edits in the originally listed consumer files proved unnecessary, completion below reflects the shared-helper cleanup plus targeted validation in the existing downstream tests rather than redundant file-local rewrites.

Test Governance Checklist

  • Lane assignment stays fast-feedback plus confidence, with retained heavy-governance guards only in apps/platform/tests/Feature/Guards/NoAdHocStatusBadgesTest.php and apps/platform/tests/Feature/Guards/FilamentTableStandardsGuardTest.php, and remains the narrowest sufficient proof for the removed compatibility branch.
  • New or changed tests stay in focused Feature and Unit files only; no browser lane or new heavy-governance family is added.
  • Shared helpers, factories, fixtures, and context defaults stay cheap by default; acknowledged-specific setup is deleted or localized instead of becoming a new shared default.
  • Planned validation commands stay limited to the targeted Sail test commands captured in specs/254-remove-acknowledged-compat/plan.md and the final validation phase below.
  • The declared surface test profile stays standard-native-filament plus global-context-shell; no additional surface exception is introduced.
  • Any material suite-footprint or residue follow-up resolves inside this feature as document-in-feature or reject-or-split, not as silent scope drift.

Phase 1: Setup (Shared Cleanup Anchors)

Purpose: Lock the concrete removal inventory, out-of-scope boundaries, and proving commands before implementation starts.

  • T001 [P] Verify the productive acknowledged inventory across apps/platform/app/Models/Finding.php, apps/platform/app/Services/Findings/FindingWorkflowService.php, apps/platform/app/Policies/FindingPolicy.php, apps/platform/app/Support/Auth/Capabilities.php, apps/platform/app/Services/Auth/RoleCapabilityMap.php, apps/platform/app/Support/Filament/FilterOptionCatalog.php, apps/platform/app/Filament/Resources/FindingResource.php, apps/platform/app/Filament/Resources/FindingResource/Pages/ListFindings.php, and apps/platform/app/Filament/Pages/Findings/MyFindingsInbox.php
  • T002 [P] Verify the shared summary, alert, and query-consumer inventory across apps/platform/app/Support/CustomerHealth/WorkspaceHealthSummaryQuery.php, apps/platform/app/Support/Workspaces/WorkspaceOverviewBuilder.php, apps/platform/app/Support/GovernanceInbox/GovernanceInboxSectionBuilder.php, apps/platform/app/Support/Baselines/BaselineCompareStats.php, apps/platform/app/Support/SupportDiagnostics/SupportDiagnosticBundleBuilder.php, apps/platform/app/Services/TenantReviews/TenantReviewSectionFactory.php, apps/platform/app/Jobs/Alerts/EvaluateAlertsJob.php, apps/platform/app/Services/PermissionPosture/PermissionPostureFindingGenerator.php, apps/platform/app/Services/EntraAdminRoles/EntraAdminRolesFindingGenerator.php, apps/platform/app/Services/Baselines/BaselineAutoCloseService.php, and apps/platform/app/Services/Findings/FindingAssignmentHygieneService.php
  • T003 [P] Verify the out-of-scope acknowledgement domains stay untouched across apps/platform/app/Services/Verification/VerificationCheckAcknowledgementService.php, apps/platform/app/Filament/Support/VerificationReportViewer.php, apps/platform/app/Filament/Pages/Workspaces/ManagedTenantOnboardingWizard.php, apps/platform/tests/Feature/Verification/VerificationCheckAcknowledgementTest.php, and apps/platform/tests/Feature/Onboarding/OnboardingVerificationV1_5UxTest.php
  • T004 [P] Verify the minimum Sail validation commands and file-scoped coverage expectations in specs/254-remove-acknowledged-compat/plan.md, specs/254-remove-acknowledged-compat/spec.md, and specs/254-remove-acknowledged-compat/checklists/requirements.md

Checkpoint: The cleanup boundaries, shared seams, and proving commands are locked before any runtime file is changed.


Phase 2: Foundational (Blocking Proof Surfaces)

Purpose: Make the intended regression proof and stale compatibility inventory explicit before removing shared semantics.

CRITICAL: No user story work should begin until this phase is complete.

  • T005 [P] Create the core status and workflow proof files apps/platform/tests/Unit/Findings/FindingStatusSemanticsTest.php and apps/platform/tests/Feature/Findings/RemoveAcknowledgedCompatibilityWorkflowTest.php
  • T006 [P] Create the shared-surface and RBAC proof files apps/platform/tests/Unit/Support/Filament/FindingStatusFilterCatalogTest.php and apps/platform/tests/Feature/Auth/RemoveAcknowledgedCapabilityAliasTest.php, and prove downstream summary consumers through the existing baseline, workspace health, tenant review, support-diagnostics, and alerts tests that already exercise the shared open-status helper.
  • T007 [P] Verify retained guard coverage in apps/platform/tests/Feature/Guards/NoAdHocStatusBadgesTest.php and apps/platform/tests/Feature/Guards/FilamentTableStandardsGuardTest.php so findings acknowledged compatibility is treated as removed repo truth rather than tolerated legacy drift
  • T008 [P] Audit stale compatibility fixtures and helpers across apps/platform/database/factories/FindingFactory.php, apps/platform/tests/Feature/Findings/Concerns/InteractsWithFindingsWorkflow.php, apps/platform/tests/Feature/Models/FindingResolvedTest.php, apps/platform/tests/Feature/Findings/FindingsIntakeQueueTest.php, apps/platform/tests/Unit/Badges/FindingBadgesTest.php, apps/platform/tests/Feature/Support/Badges/FindingBadgeTest.php, apps/platform/tests/Feature/Rbac/RoleMatrix/OwnerAccessTest.php, apps/platform/tests/Feature/Rbac/RoleMatrix/ManagerAccessTest.php, apps/platform/tests/Feature/Rbac/RoleMatrix/OperatorAccessTest.php, and apps/platform/tests/Feature/Rbac/RoleMatrix/ReadonlyAccessTest.php

Checkpoint: Proof files, guard expectations, and stale compatibility anchors are explicit and ready for bounded implementation work.


Phase 3: User Story 1 - Use One Canonical Findings Workflow Language (Priority: P1) 🎯 MVP

Goal: Remove acknowledged as a productive findings lifecycle concept so tenant findings list, detail, inbox, badges, and filters all speak in one canonical workflow language.

Independent Test: Open the tenant findings register, detail, and assignee inbox for a tenant with active findings and verify that statuses, filters, badges, helper text, and workflow affordances use canonical findings vocabulary only.

Tests for User Story 1

  • T009 [P] [US1] Add canonical status-contract and lifecycle assertions in apps/platform/tests/Unit/Findings/FindingStatusSemanticsTest.php and apps/platform/tests/Feature/Findings/RemoveAcknowledgedCompatibilityWorkflowTest.php
  • T010 [P] [US1] Add shared filter, badge, and list-surface absence proof in apps/platform/tests/Unit/Support/Filament/FindingStatusFilterCatalogTest.php, apps/platform/tests/Unit/Badges/FindingBadgesTest.php, apps/platform/tests/Feature/Support/Badges/FindingBadgeTest.php, and apps/platform/tests/Feature/Findings/FindingsIntakeQueueTest.php

Implementation for User Story 1

  • T011 [US1] Remove productive acknowledged status constants, canonicalization shims, acknowledge() helper behavior, and acknowledged factory state usage from apps/platform/app/Models/Finding.php and apps/platform/database/factories/FindingFactory.php
  • T012 [US1] Collapse workflow transitions and policy checks onto canonical triage semantics in apps/platform/app/Services/Findings/FindingWorkflowService.php and apps/platform/app/Policies/FindingPolicy.php
  • T013 [US1] Remove acknowledged filter options, acknowledged detail metadata copy, and acknowledged-specific visibility branches from apps/platform/app/Support/Filament/FilterOptionCatalog.php, apps/platform/app/Filament/Resources/FindingResource.php, apps/platform/app/Filament/Resources/FindingResource/Pages/ListFindings.php, and apps/platform/app/Filament/Pages/Findings/MyFindingsInbox.php
  • T014 [US1] Rewrite stale workflow helper and compatibility assertions in apps/platform/tests/Feature/Findings/Concerns/InteractsWithFindingsWorkflow.php, apps/platform/tests/Feature/Models/FindingResolvedTest.php, apps/platform/tests/Feature/Findings/FindingsIntakeQueueTest.php, apps/platform/tests/Unit/Badges/FindingBadgesTest.php, and apps/platform/tests/Feature/Support/Badges/FindingBadgeTest.php

Checkpoint: User Story 1 is independently functional and no productive findings surface still advertises acknowledged as current workflow truth.


Phase 4: User Story 2 - Keep Summary Counts and Previews Honest (Priority: P1)

Goal: Make every shared summary, preview, alert, and consumer query derive open findings from the same canonical status set used by the findings register.

Independent Test: Compare the tenant findings register with the affected /admin summary and inbox surfaces for the same tenant or workspace context and verify that counts, previews, drilldowns, and alerts align with the same canonical open-status set.

Tests for User Story 2

  • T015 [P] [US2] Prove shared summary alignment through the existing downstream tests in apps/platform/tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php and apps/platform/tests/Unit/Support/GovernanceInbox/GovernanceInboxSectionBuilderTest.php, with the governance-inbox stale-operations expectation recorded separately as an unrelated existing operation-age failure.
  • T016 [P] [US2] Add consumer regression coverage for overview, baseline, tenant-review, diagnostics, and alert paths in apps/platform/tests/Feature/Baselines/BaselineCompareStatsTest.php, apps/platform/tests/Feature/TenantReview/TenantReviewCanonicalControlReferenceTest.php, apps/platform/tests/Feature/TenantReview/TenantReviewExecutivePackTest.php, apps/platform/tests/Unit/Support/SupportDiagnostics/SupportDiagnosticBundleBuilderTest.php, and apps/platform/tests/Feature/Alerts/SlaDueAlertTest.php

Implementation for User Story 2

  • T017 [US2] Collapse canonical open-status summary builders via the shared Finding::openStatusesForQuery() cleanup and validate the unchanged consumers in apps/platform/app/Support/CustomerHealth/WorkspaceHealthSummaryQuery.php, apps/platform/app/Support/Workspaces/WorkspaceOverviewBuilder.php, apps/platform/app/Support/GovernanceInbox/GovernanceInboxSectionBuilder.php, and apps/platform/app/Filament/Pages/Findings/MyFindingsInbox.php
  • T018 [US2] Remove acknowledged-specific active-count and review-report branches from apps/platform/app/Support/Baselines/BaselineCompareStats.php while validating that apps/platform/app/Services/TenantReviews/TenantReviewSectionFactory.php and apps/platform/app/Support/SupportDiagnostics/SupportDiagnosticBundleBuilder.php already converged through the shared open-status helper.
  • T019 [US2] Collapse alert, generator, and hygiene consumers onto canonical open statuses via the shared helper in apps/platform/app/Jobs/Alerts/EvaluateAlertsJob.php, apps/platform/app/Services/PermissionPosture/PermissionPostureFindingGenerator.php, apps/platform/app/Services/EntraAdminRoles/EntraAdminRolesFindingGenerator.php, apps/platform/app/Services/Baselines/BaselineAutoCloseService.php, and apps/platform/app/Services/Findings/FindingAssignmentHygieneService.php
  • T020 [US2] Rewrite acknowledged-compatibility expectations in apps/platform/tests/Feature/PermissionPosture/PermissionPostureFindingGeneratorTest.php, apps/platform/tests/Feature/EntraAdminRoles/EntraAdminRolesFindingGeneratorTest.php, and validate the unaffected downstream consumers in apps/platform/tests/Feature/Alerts/SlaDueAlertTest.php, apps/platform/tests/Feature/Baselines/BaselineCompareStatsTest.php, and apps/platform/tests/Feature/Findings/FindingsAssignmentHygieneOverviewSignalTest.php

Checkpoint: User Story 2 is independently functional and shared counts, previews, review packs, diagnostics, and alerts all reflect the same canonical findings-open set.


Phase 5: User Story 3 - Keep RBAC Language Canonical (Priority: P2)

Goal: Remove the acknowledge capability alias so role guidance, authorization checks, and disabled findings actions all use the surviving canonical findings permission language only.

Independent Test: Review capability-driven findings surfaces and role expectations after the cleanup and verify that they reference surviving findings capabilities only while preserving current 404 versus 403 semantics.

Tests for User Story 3

  • T021 [P] [US3] Add positive and negative capability-alias removal coverage in apps/platform/tests/Feature/Auth/RemoveAcknowledgedCapabilityAliasTest.php and apps/platform/tests/Feature/Findings/RemoveAcknowledgedCompatibilityWorkflowTest.php
  • T022 [P] [US3] Update role-matrix and UI-enforced findings permission proof in apps/platform/tests/Feature/Rbac/RoleMatrix/OwnerAccessTest.php, apps/platform/tests/Feature/Rbac/RoleMatrix/ManagerAccessTest.php, apps/platform/tests/Feature/Rbac/RoleMatrix/OperatorAccessTest.php, apps/platform/tests/Feature/Rbac/RoleMatrix/ReadonlyAccessTest.php, and validate the surviving UI-enforced surface contract in apps/platform/tests/Feature/Guards/FilamentTableStandardsGuardTest.php

Implementation for User Story 3

  • T023 [US3] Remove tenant_findings.acknowledge from apps/platform/app/Support/Auth/Capabilities.php and apps/platform/app/Services/Auth/RoleCapabilityMap.php
  • T024 [US3] Collapse acknowledge-specific authorization branches and findings UI enforcement onto surviving capabilities in apps/platform/app/Policies/FindingPolicy.php, apps/platform/app/Services/Findings/FindingWorkflowService.php, and apps/platform/app/Filament/Resources/FindingResource.php
  • T025 [US3] Rewrite stale RBAC and capability-alias expectations in apps/platform/tests/Feature/Rbac/RoleMatrix/OwnerAccessTest.php, apps/platform/tests/Feature/Rbac/RoleMatrix/ManagerAccessTest.php, apps/platform/tests/Feature/Rbac/RoleMatrix/OperatorAccessTest.php, apps/platform/tests/Feature/Rbac/RoleMatrix/ReadonlyAccessTest.php, and apps/platform/tests/Feature/Auth/RemoveAcknowledgedCapabilityAliasTest.php

Checkpoint: User Story 3 is independently functional and no supported findings permission path or role expectation still names an acknowledge alias.


Phase 6: Polish & Cross-Cutting Concerns

Purpose: Remove remaining stale compatibility residue, keep scope boundaries honest, and run the narrow validation workflow.

  • T026 [P] Remove final acknowledged-compatibility residue from findings-only helper and proof surfaces in apps/platform/tests/Feature/Models/FindingResolvedTest.php, apps/platform/tests/Feature/Findings/Concerns/InteractsWithFindingsWorkflow.php, apps/platform/tests/Feature/Findings/FindingsIntakeQueueTest.php, apps/platform/tests/Unit/Badges/FindingBadgesTest.php, and apps/platform/tests/Feature/Support/Badges/FindingBadgeTest.php after the story-specific rewrites land
  • T027 [P] Run a residue search for STATUS_ACKNOWLEDGED, TENANT_FINDINGS_ACKNOWLEDGE, legacy acknowledged, and acknowledge( across apps/platform/app/, apps/platform/database/factories/, and apps/platform/tests/, then classify any remaining match as in-scope cleanup, allowed non-finding domain, or reject-or-split
  • T028 Run formatting for touched PHP files with export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent after the cleanup across apps/platform/app/, apps/platform/database/factories/, and apps/platform/tests/
  • T029 [P] Run the focused workflow, filter, and RBAC Sail command export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Findings/RemoveAcknowledgedCompatibilityWorkflowTest.php tests/Unit/Findings/FindingStatusSemanticsTest.php tests/Unit/Support/Filament/FindingStatusFilterCatalogTest.php tests/Feature/Auth/RemoveAcknowledgedCapabilityAliasTest.php
  • T030 [P] Run the focused summary and consumer Sail command using the existing downstream proof files export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php tests/Unit/Support/GovernanceInbox/GovernanceInboxSectionBuilderTest.php tests/Feature/Baselines/BaselineCompareStatsTest.php tests/Feature/Alerts/SlaDueAlertTest.php, with the governance-inbox stale-operations expectation recorded as an unrelated existing failure outside the acknowledged-status cleanup.
  • T031 [P] Run the retained heavy-governance guards export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Guards/NoAdHocStatusBadgesTest.php tests/Feature/Guards/FilamentTableStandardsGuardTest.php, then verify no out-of-scope verification or onboarding acknowledgement file from T003 changed without an explicit split decision
  • T032 [P] Verify FR-254-010 explicitly by confirming Finding keeps workspace_id plus tenant_id as unchanged ownership anchors and that no file under apps/platform/database/migrations/ changed and no new persisted compatibility artifact, alias table, fallback reader, or migration-backed truth was introduced while implementing this slice; if ownership-anchor or persistence widening appears, stop and split the work instead of absorbing it here

Dependencies & Execution Order

Phase Dependencies

  • Setup (Phase 1): Starts immediately and locks the exact removal inventory, boundaries, and proving commands.
  • Foundational (Phase 2): Depends on Setup and blocks all story work until proof files, guard expectations, and stale compatibility anchors are explicit.
  • User Story 1 (Phase 3): Depends on Foundational and is part of the MVP delivery.
  • User Story 2 (Phase 4): Depends on Foundational and can proceed in parallel with User Story 1 because it targets shared summary, alert, and query consumers behind the same canonical status set.
  • User Story 3 (Phase 5): Depends on User Story 1 because RBAC language should be validated only after findings workflow surfaces stop advertising acknowledged semantics; it can overlap with late User Story 2 cleanup once capability surfaces are isolated.
  • Polish (Phase 6): Depends on all desired user stories being complete so residue checks, formatting, and focused validation run on the final cleanup shape.

User Story Dependencies

  • US1: No dependencies beyond Foundational.
  • US2: No dependencies beyond Foundational.
  • US3: Depends on US1 and should validate alongside completed US2 summary cleanup.

Within Each User Story

  • Add or update the story tests first and confirm they fail before cleanup edits are considered complete.
  • Remove shared compatibility branches centrally instead of hiding acknowledged semantics on one page or in one helper.
  • Do not keep compatibility aliases, fallback readers, data-migration shims, or replacement workflow affordances.
  • Keep backfill-runtime-surface removal, creation-time invariants hardening, broader lifecycle redesign, verification acknowledgement cleanup, onboarding acknowledgement cleanup, and support-desk work out of scope.

Parallel Opportunities

  • T001, T002, T003, and T004 can run in parallel during Setup.
  • T005, T006, T007, and T008 can run in parallel during Foundational work.
  • T009 and T010 can run in parallel for User Story 1 before T011, T012, T013, and T014.
  • T015 and T016 can run in parallel for User Story 2 before T017, T018, T019, and T020.
  • User Story 1 and User Story 2 can proceed in parallel after Foundational is complete.
  • T021 and T022 can run in parallel for User Story 3 before T023, T024, and T025.
  • T029, T030, and T031 can run in parallel during final validation.

Parallel Example: User Story 1

# User Story 1 tests in parallel
T009 apps/platform/tests/Unit/Findings/FindingStatusSemanticsTest.php + apps/platform/tests/Feature/Findings/RemoveAcknowledgedCompatibilityWorkflowTest.php
T010 apps/platform/tests/Unit/Support/Filament/FindingStatusFilterCatalogTest.php + apps/platform/tests/Unit/Badges/FindingBadgesTest.php + apps/platform/tests/Feature/Support/Badges/FindingBadgeTest.php + apps/platform/tests/Feature/Findings/FindingsIntakeQueueTest.php

# User Story 1 implementation after the tests are in place
T011 apps/platform/app/Models/Finding.php + apps/platform/database/factories/FindingFactory.php
T012 apps/platform/app/Services/Findings/FindingWorkflowService.php + apps/platform/app/Policies/FindingPolicy.php
T013 apps/platform/app/Support/Filament/FilterOptionCatalog.php + apps/platform/app/Filament/Resources/FindingResource.php + apps/platform/app/Filament/Resources/FindingResource/Pages/ListFindings.php + apps/platform/app/Filament/Pages/Findings/MyFindingsInbox.php

Parallel Example: User Story 2

# User Story 2 tests in parallel
T015 apps/platform/tests/Unit/Support/CustomerHealth/WorkspaceHealthSummaryQueryTest.php + apps/platform/tests/Unit/Support/GovernanceInbox/GovernanceInboxSectionBuilderTest.php
T016 apps/platform/tests/Feature/Filament/WorkspaceOverviewSummaryMetricsTest.php + apps/platform/tests/Feature/Filament/WorkspaceOverviewGovernanceAttentionTest.php + apps/platform/tests/Feature/Baselines/BaselineCompareStatsTest.php + apps/platform/tests/Feature/TenantReview/TenantReviewCanonicalControlReferenceTest.php + apps/platform/tests/Feature/TenantReview/TenantReviewExecutivePackTest.php + apps/platform/tests/Unit/Support/SupportDiagnostics/SupportDiagnosticBundleBuilderTest.php + apps/platform/tests/Feature/Alerts/SlaDueAlertTest.php

# User Story 2 implementation after the tests are in place
T017 apps/platform/app/Support/CustomerHealth/WorkspaceHealthSummaryQuery.php + apps/platform/app/Support/Workspaces/WorkspaceOverviewBuilder.php + apps/platform/app/Support/GovernanceInbox/GovernanceInboxSectionBuilder.php + apps/platform/app/Filament/Pages/Findings/MyFindingsInbox.php
T018 apps/platform/app/Support/Baselines/BaselineCompareStats.php + apps/platform/app/Services/TenantReviews/TenantReviewSectionFactory.php + apps/platform/app/Support/SupportDiagnostics/SupportDiagnosticBundleBuilder.php
T019 apps/platform/app/Jobs/Alerts/EvaluateAlertsJob.php + apps/platform/app/Services/PermissionPosture/PermissionPostureFindingGenerator.php + apps/platform/app/Services/EntraAdminRoles/EntraAdminRolesFindingGenerator.php + apps/platform/app/Services/Baselines/BaselineAutoCloseService.php + apps/platform/app/Services/Findings/FindingAssignmentHygieneService.php

Parallel Example: User Story 3

# User Story 3 tests in parallel
T021 apps/platform/tests/Feature/Auth/RemoveAcknowledgedCapabilityAliasTest.php + apps/platform/tests/Feature/Findings/RemoveAcknowledgedCompatibilityWorkflowTest.php
T022 apps/platform/tests/Feature/Rbac/RoleMatrix/OwnerAccessTest.php + apps/platform/tests/Feature/Rbac/RoleMatrix/ManagerAccessTest.php + apps/platform/tests/Feature/Rbac/RoleMatrix/OperatorAccessTest.php + apps/platform/tests/Feature/Rbac/RoleMatrix/ReadonlyAccessTest.php + apps/platform/tests/Feature/Guards/FilamentTableStandardsGuardTest.php

# User Story 3 implementation after the tests are in place
T023 apps/platform/app/Support/Auth/Capabilities.php + apps/platform/app/Services/Auth/RoleCapabilityMap.php
T024 apps/platform/app/Policies/FindingPolicy.php + apps/platform/app/Services/Findings/FindingWorkflowService.php + apps/platform/app/Filament/Resources/FindingResource.php

Implementation Strategy

MVP First (User Stories 1 and 2)

  1. Complete Phase 1: Setup.
  2. Complete Phase 2: Foundational.
  3. Complete Phase 3: User Story 1.
  4. Complete Phase 4: User Story 2.
  5. Run T028, T029, and T030 before widening into capability-alias cleanup.

Incremental Delivery

  1. Lock the shared seams, out-of-scope domains, and proving commands.
  2. Remove acknowledged from the findings model, workflow, filter, badge, and Filament surfaces.
  3. Remove acknowledged from summary builders, review or report helpers, alerts, and other shared query consumers.
  4. Remove the stale capability alias and role expectations once findings workflow language is already canonical.
  5. Finish with residue searches, formatting, and the focused Sail commands.

Parallel Team Strategy

  1. One contributor can own the findings model, workflow, and Filament cleanup (US1) while another owns shared summaries, alerts, review helpers, and query consumers (US2) after Phase 2.
  2. Once the two P1 stories land, a focused pass can remove the capability alias and RBAC wording (US3) without reopening summary or workflow decisions.
  3. A final pass can remove stale residue, run Pint, and execute the three focused Sail validation commands.

Notes

  • Suggested MVP scope: Phase 1 through Phase 4 only. Canonical workflow cleanup without summary or query-consumer alignment is not sufficient for this feature.
  • Explicit non-goals remain: backfill-runtime-surface removal, creation-time invariant hardening, broader lifecycle redesign, verification or onboarding acknowledgement cleanup, new workflow states, migration shims, repair tooling, and support-desk workflows.
  • Filament stays on Livewire v4 and no panel/provider or asset strategy changes are needed; FindingResource already has a view page, so global-search behavior does not need separate tasking in this slice.
  • All tasks above follow the required checklist format with task ID, optional parallel marker, story label where applicable, and concrete file paths.