TenantAtlas/specs/234-dead-transitional-residue/tasks.md

Tasks: Dead Transitional Residue Cleanup

Input: Design documents from /specs/234-dead-transitional-residue/ Prerequisites: plan.md, spec.md, research.md, data-model.md, quickstart.md

Tests: Required. This feature changes runtime behavior by removing active runtime/support residue, so Pest coverage must be added or updated in apps/platform/tests/Feature/Filament/TenantTruthCleanupSpec179Test.php, apps/platform/tests/Feature/Filament/TenantLifecycleStatusDomainSeparationTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileArchiveActionTest.php, apps/platform/tests/Feature/Filament/BaselineProfileListFiltersTest.php, apps/platform/tests/Feature/Filament/BaselineProfileScopeV2PersistenceTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileWorkspaceOwnershipTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileAuthorizationTest.php, apps/platform/tests/Unit/Badges/TenantBadgesTest.php, and apps/platform/tests/Unit/Badges/BadgeCatalogTest.php. Operations: No new OperationRun, audit-only DB action, or queued workflow is introduced. This cleanup stays inside existing runtime behavior, fixture defaults, and regression coverage. RBAC: No authorization semantics change. Existing tenant/admin Filament access, tenant isolation, and current 404 versus 403 behavior must remain unchanged in the touched tenant and baseline regression files. UI / Surface Guardrails: No operator-facing surface is added or redesigned. Keep standard-native-filament relief and use the existing tenant and baseline pages only as continuity proof. Filament UI Action Surfaces: No new Filament Resource, Page, RelationManager, or action surface is introduced. TenantResource and BaselineProfileResource keep their current surfaces and global-search posture. Badges: BadgeCatalog remains authoritative. The legacy tenant app-status badge domain must be removed centrally from apps/platform/app/Support/Badges/BadgeCatalog.php and apps/platform/app/Support/Badges/BadgeDomain.php, and active badge domains must remain covered by tests.

Organization: Tasks are grouped by user story so each slice stays independently testable after the shared proof surfaces are prepared. Recommended delivery order is US1 and US2 in parallel after Foundational, then a final cross-cutting verification phase, because the retirement proof only matters once the tenant and baseline cleanup slices are both in place.

Test Governance Checklist

• Lane assignment is named and is the narrowest sufficient proof for the changed behavior.
• New or changed tests stay in the smallest honest family, and any heavy-governance or browser addition is explicit.
• Shared helpers, factories, seeds, fixtures, and context defaults stay cheap by default; any widening is isolated or documented.
• Planned validation commands cover the change without pulling in unrelated lane cost.
• The declared surface test profile or standard-native-filament relief is explicit.
• Any material budget, baseline, trend, or escalation note is recorded in the active spec or PR.

Phase 1: Setup (Shared Cleanup Anchors)

Purpose: Lock the cleanup inventory and proving commands before editing runtime or test files.

• T001 [P] Verify the cleanup anchor inventory across apps/platform/app/Models/BaselineProfile.php, apps/platform/app/Support/Badges/BadgeCatalog.php, apps/platform/app/Support/Badges/BadgeDomain.php, apps/platform/app/Support/Badges/Domains/TenantAppStatusBadge.php, apps/platform/database/factories/TenantFactory.php, and apps/platform/app/Console/Commands/SeedBackupHealthBrowserFixture.php
• T002 [P] Verify the narrow validation lane and proving commands in specs/234-dead-transitional-residue/plan.md and specs/234-dead-transitional-residue/quickstart.md

Checkpoint: Cleanup scope and proving commands are locked before code changes begin.

---

Phase 2: Foundational (Blocking Proof Surfaces)

Purpose: Audit the real consumer boundaries before removing residue so story work does not rediscover hidden dependencies mid-slice.

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

• T003 [P] Audit all TenantAppStatus and TenantAppStatusBadge consumers across apps/platform/app/Support/Badges/BadgeCatalog.php, apps/platform/app/Support/Badges/BadgeDomain.php, apps/platform/app/Support/Badges/Domains/TenantAppStatusBadge.php, apps/platform/tests/Unit/Badges/TenantBadgesTest.php, and apps/platform/tests/Unit/Badges/BadgeCatalogTest.php
• T004 [P] Audit every ambient or explicit app_status usage boundary across apps/platform/database/factories/TenantFactory.php, apps/platform/app/Console/Commands/SeedBackupHealthBrowserFixture.php, apps/platform/tests/Feature/Filament/TenantTruthCleanupSpec179Test.php, and apps/platform/tests/Feature/Filament/TenantLifecycleStatusDomainSeparationTest.php
• T005 [P] Audit every BaselineProfile::STATUS_ consumer and baseline continuity proof file across apps/platform/app/Models/BaselineProfile.php, apps/platform/tests/Feature/Baselines/BaselineProfileArchiveActionTest.php, apps/platform/tests/Feature/Filament/BaselineProfileListFiltersTest.php, apps/platform/tests/Feature/Filament/BaselineProfileScopeV2PersistenceTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileWorkspaceOwnershipTest.php, and apps/platform/tests/Feature/Baselines/BaselineProfileAuthorizationTest.php
• T006 [P] Lock the cross-cutting retirement proof and follow-up decision sink in specs/234-dead-transitional-residue/plan.md, specs/234-dead-transitional-residue/quickstart.md, and specs/234-dead-transitional-residue/tasks.md

Checkpoint: Hidden-dependency boundaries are explicit and the story slices can proceed without overlapping proof setup work.

---

Phase 3: User Story 1 - Keep Tenant Truth Free Of Retired App-Status Semantics (Priority: P1) 🎯 MVP

Goal: Remove tenant app-status residue from active badge/default paths without changing current tenant lifecycle, provider, or RBAC truth.

Independent Test: Run the tenant-truth regressions with explicit legacy app_status values and verify the tenant list/detail surfaces still suppress them while active tenant truth remains unchanged.

Tests for User Story 1

• T007 [P] [US1] Add tenant list/detail assertions that explicit historical app_status values stay suppressed in apps/platform/tests/Feature/Filament/TenantTruthCleanupSpec179Test.php
• T008 [P] [US1] Add lifecycle and RBAC separation assertions that do not rely on TenantFactory defaults in apps/platform/tests/Feature/Filament/TenantLifecycleStatusDomainSeparationTest.php
• T009 [P] [US1] Add tenant badge assertions that the legacy app-status domain no longer participates in active tenant semantics in apps/platform/tests/Unit/Badges/TenantBadgesTest.php

Implementation for User Story 1

• T010 [P] [US1] Remove the TenantAppStatus registration path from apps/platform/app/Support/Badges/BadgeDomain.php and apps/platform/app/Support/Badges/BadgeCatalog.php
• T011 [US1] Delete the retired mapper in apps/platform/app/Support/Badges/Domains/TenantAppStatusBadge.php
• T012 [P] [US1] Remove the ambient app_status default from apps/platform/database/factories/TenantFactory.php
• T013 [P] [US1] Remove the forced tenant app_status fixture value from apps/platform/app/Console/Commands/SeedBackupHealthBrowserFixture.php
• T014 [US1] Reconcile explicit legacy setup and active-domain expectations in apps/platform/tests/Feature/Filament/TenantTruthCleanupSpec179Test.php, apps/platform/tests/Feature/Filament/TenantLifecycleStatusDomainSeparationTest.php, and apps/platform/tests/Unit/Badges/TenantBadgesTest.php

Checkpoint: User Story 1 is independently functional and tenant truth no longer depends on the retired badge path or ambient app_status defaults.

---

Phase 4: User Story 2 - Use One Baseline Profile Status Language (Priority: P1)

Goal: Remove deprecated baseline profile alias language so BaselineProfileStatus is the only active lifecycle contract.

Independent Test: Run the existing baseline profile archive, list/filter, view/edit continuity, and workspace-ownership regressions after alias removal and verify behavior is unchanged.

Tests for User Story 2

• T015 [P] [US2] Add archive-flow assertions that only BaselineProfileStatus drives lifecycle behavior in apps/platform/tests/Feature/Baselines/BaselineProfileArchiveActionTest.php
• T016 [P] [US2] Add list/filter assertions that baseline profile behavior does not require alias constants in apps/platform/tests/Feature/Filament/BaselineProfileListFiltersTest.php
• T017 [P] [US2] Add view/edit continuity assertions after alias removal in apps/platform/tests/Feature/Filament/BaselineProfileScopeV2PersistenceTest.php
• T018 [P] [US2] Add workspace-ownership continuity assertions after alias removal in apps/platform/tests/Feature/Baselines/BaselineProfileWorkspaceOwnershipTest.php

Implementation for User Story 2

• T019 [US2] Remove deprecated STATUS_DRAFT, STATUS_ACTIVE, and STATUS_ARCHIVED constants from apps/platform/app/Models/BaselineProfile.php
• T020 [US2] Update baseline profile regressions to use only App\Support\Baselines\BaselineProfileStatus in apps/platform/tests/Feature/Baselines/BaselineProfileArchiveActionTest.php, apps/platform/tests/Feature/Filament/BaselineProfileListFiltersTest.php, apps/platform/tests/Feature/Filament/BaselineProfileScopeV2PersistenceTest.php, and apps/platform/tests/Feature/Baselines/BaselineProfileWorkspaceOwnershipTest.php

Checkpoint: User Story 2 is independently functional and baseline profile lifecycle behavior now has one canonical status language.

---

Phase 5: Cross-Cutting Verification - Prove The Residue Is Fully Retired

Goal: Lock in regression proof that the retired semantics are gone from active runtime/support paths.

Release Gate: Run the focused regression pack plus the residue searches after User Story 1 and User Story 2 are complete, and confirm there are no unexpected matches or hidden-default dependencies left in the touched files.

Verification for Cross-Cutting Closeout

• T021 [P] Add badge catalog assertions that the retired tenant app-status domain is absent while active domains remain registered in apps/platform/tests/Unit/Badges/BadgeCatalogTest.php
• T022 [P] Add regression assertions that legacy app_status is always opt-in setup in apps/platform/tests/Feature/Filament/TenantTruthCleanupSpec179Test.php and apps/platform/tests/Feature/Filament/TenantLifecycleStatusDomainSeparationTest.php

Implementation for Cross-Cutting Closeout

• T023 Run and review the residue searches for BaselineProfile::STATUS_|TenantAppStatus|tenant_app_status and app_status across apps/platform/app/Models/BaselineProfile.php, apps/platform/app/Support/Badges/BadgeCatalog.php, apps/platform/app/Support/Badges/BadgeDomain.php, apps/platform/app/Support/Badges/Domains/TenantAppStatusBadge.php, apps/platform/database/factories/TenantFactory.php, apps/platform/app/Console/Commands/SeedBackupHealthBrowserFixture.php, apps/platform/tests/Feature/Filament/TenantTruthCleanupSpec179Test.php, apps/platform/tests/Feature/Filament/TenantLifecycleStatusDomainSeparationTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileArchiveActionTest.php, apps/platform/tests/Feature/Filament/BaselineProfileListFiltersTest.php, apps/platform/tests/Feature/Filament/BaselineProfileScopeV2PersistenceTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileWorkspaceOwnershipTest.php, apps/platform/tests/Unit/Badges/TenantBadgesTest.php, and apps/platform/tests/Unit/Badges/BadgeCatalogTest.php
• T024 Record any hidden-dependency follow-up or confirm clean retirement in specs/234-dead-transitional-residue/plan.md and specs/234-dead-transitional-residue/quickstart.md

Checkpoint: The feature has explicit proof that the dead residue is no longer part of active truth.

---

Phase 6: Polish & Cross-Cutting Concerns

Purpose: Finish formatting and run the narrow proving workflow for the full cleanup.

• T025 Run formatting for apps/platform/app/Models/BaselineProfile.php, apps/platform/app/Support/Badges/BadgeCatalog.php, apps/platform/app/Support/Badges/BadgeDomain.php, apps/platform/database/factories/TenantFactory.php, apps/platform/app/Console/Commands/SeedBackupHealthBrowserFixture.php, apps/platform/tests/Unit/Badges/BadgeCatalogTest.php, apps/platform/tests/Unit/Badges/TenantBadgesTest.php, apps/platform/tests/Feature/Filament/TenantTruthCleanupSpec179Test.php, apps/platform/tests/Feature/Filament/TenantLifecycleStatusDomainSeparationTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileArchiveActionTest.php, apps/platform/tests/Feature/Filament/BaselineProfileListFiltersTest.php, apps/platform/tests/Feature/Filament/BaselineProfileScopeV2PersistenceTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileWorkspaceOwnershipTest.php, and apps/platform/tests/Feature/Baselines/BaselineProfileAuthorizationTest.php with cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
• T026 [P] Run the tenant-truth validation pack from specs/234-dead-transitional-residue/quickstart.md against apps/platform/tests/Feature/Filament/TenantTruthCleanupSpec179Test.php and apps/platform/tests/Feature/Filament/TenantLifecycleStatusDomainSeparationTest.php
• T027 [P] Run the baseline-profile and badge validation pack from specs/234-dead-transitional-residue/quickstart.md against apps/platform/tests/Feature/Baselines/BaselineProfileArchiveActionTest.php, apps/platform/tests/Feature/Filament/BaselineProfileListFiltersTest.php, apps/platform/tests/Feature/Filament/BaselineProfileScopeV2PersistenceTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileWorkspaceOwnershipTest.php, apps/platform/tests/Feature/Baselines/BaselineProfileAuthorizationTest.php, apps/platform/tests/Unit/Badges/TenantBadgesTest.php, and apps/platform/tests/Unit/Badges/BadgeCatalogTest.php

---

Dependencies & Execution Order

Phase Dependencies

• Setup (Phase 1): Starts immediately and locks the cleanup inventory plus proving commands.
• Foundational (Phase 2): Depends on Setup and blocks all story work until the hidden-dependency boundaries and closeout proof sinks are explicit.
• User Story 1 (Phase 3): Depends on Foundational and is the recommended MVP cut.
• User Story 2 (Phase 4): Depends on Foundational and can proceed in parallel with User Story 1 because it touches a separate runtime truth domain.
• Cross-Cutting Verification (Phase 5): Depends on User Story 1 and User Story 2 because the final retirement proof only makes sense after both cleanup slices land.
• Polish (Phase 6): Depends on all desired user stories and the cross-cutting verification phase being complete.

User Story Dependencies

• US1: No dependencies beyond Foundational.
• US2: No dependencies beyond Foundational.

Within Each User Story

• Write the story tests first and confirm they fail before implementation is considered complete.
• Keep the cleanup canonical: no compatibility aliases, no fallback readers, and no restoration of ambient legacy defaults.
• Keep BadgeCatalog authoritative for tenant badge semantics and BaselineProfileStatus authoritative for baseline lifecycle semantics.
• Finish story-level verification before moving to the next dependent slice.

Parallel Opportunities

• T001 and T002 can run in parallel during Setup.
• T003, T004, T005, and T006 can run in parallel during Foundational work.
• T007, T008, and T009 can run in parallel for User Story 1, followed by T010, T011, T012, and T013 in parallel before reconciling tests in T014.
• T015, T016, T017, and T018 can run in parallel for User Story 2.
• User Story 1 and User Story 2 can proceed in parallel after Foundational is complete.
• T021 and T022 can run in parallel during cross-cutting verification.
• T026 and T027 can run in parallel during final validation.

---

Parallel Example: User Story 1

# User Story 1 tests in parallel
T007 apps/platform/tests/Feature/Filament/TenantTruthCleanupSpec179Test.php
T008 apps/platform/tests/Feature/Filament/TenantLifecycleStatusDomainSeparationTest.php
T009 apps/platform/tests/Unit/Badges/TenantBadgesTest.php

# User Story 1 implementation in parallel after the tests are in place
T010 apps/platform/app/Support/Badges/BadgeDomain.php + apps/platform/app/Support/Badges/BadgeCatalog.php
T011 apps/platform/app/Support/Badges/Domains/TenantAppStatusBadge.php
T012 apps/platform/database/factories/TenantFactory.php
T013 apps/platform/app/Console/Commands/SeedBackupHealthBrowserFixture.php

Parallel Example: User Story 2

# User Story 2 tests in parallel
T015 apps/platform/tests/Feature/Baselines/BaselineProfileArchiveActionTest.php
T016 apps/platform/tests/Feature/Filament/BaselineProfileListFiltersTest.php
T017 apps/platform/tests/Feature/Filament/BaselineProfileScopeV2PersistenceTest.php
T018 apps/platform/tests/Feature/Baselines/BaselineProfileWorkspaceOwnershipTest.php

Parallel Example: Cross-Story Delivery After Foundational

# Tenant cleanup and baseline cleanup can proceed in parallel after Phase 2
T010-T014 apps/platform/app/Support/Badges/* + apps/platform/database/factories/TenantFactory.php + apps/platform/app/Console/Commands/SeedBackupHealthBrowserFixture.php
T019-T020 apps/platform/app/Models/BaselineProfile.php + apps/platform/tests/Feature/Baselines/* + apps/platform/tests/Feature/Filament/BaselineProfileListFiltersTest.php + apps/platform/tests/Feature/Filament/BaselineProfileScopeV2PersistenceTest.php

---

Implementation Strategy

MVP First (User Story 1 Only)

1. Complete Phase 1: Setup.
2. Complete Phase 2: Foundational.
3. Complete Phase 3: User Story 1.
4. Run T025 and T026 before widening the slice.

Incremental Delivery

1. Ship User Story 1 to remove tenant app-status residue from active badge/default paths.
2. Ship User Story 2 to collapse baseline lifecycle language onto BaselineProfileStatus only.
3. Run the cross-cutting verification phase to lock in proof that the residue is fully retired.
4. Finish with formatting and the focused validation workflow.

Parallel Team Strategy

1. One contributor can prepare the badge and tenant-truth proof surfaces while another prepares the baseline continuity proof surfaces in Phase 2.
2. After Foundational is complete, one contributor can execute User Story 1 while another executes User Story 2.
3. Once both cleanup slices land, a final pass can focus on cross-cutting retirement proof and the narrow validation commands.

---

Notes

• [P] tasks target different files and can be worked independently once upstream blockers are cleared.
• [US1] and [US2] map directly to the feature specification user stories.
• The suggested MVP scope is Phase 1 through Phase 3 only.
• All tasks above follow the required checklist format with task ID, optional parallel marker, story label where applicable, and exact file paths.