TenantAtlas/specs/207-shared-test-fixture-slimming/tasks.md

Tasks: Shared Test Fixture Slimming

Input: Design documents from /specs/207-shared-test-fixture-slimming/ Prerequisites: plan.md, spec.md, research.md, data-model.md, contracts/, quickstart.md

Tests: Tests are REQUIRED for this feature because it changes shared test helpers, factory defaults, migration behavior, guard coverage, and lane-impact validation in a Laravel/Pest codebase. Operations / RBAC / UI surfaces: Not applicable to product runtime. This feature is limited to repository test infrastructure, factories, contributor guidance, and Spec 206 lane-measurement reuse.

Phase 1: Setup (Shared Infrastructure)

Purpose: Create the missing regression-test surfaces that the fixture-slimming work will fill.

• T001 Create the missing fixture-slimming test files in apps/platform/tests/Feature/Guards/FixtureLaneImpactBudgetTest.php, apps/platform/tests/Unit/Factories/OperationRunFactoryTest.php, apps/platform/tests/Unit/Factories/BackupSetFactoryTest.php, and apps/platform/tests/Unit/Factories/ProviderCredentialFactoryTest.php
• T002 [P] Expand the shared regression scaffolding in apps/platform/tests/Feature/Guards/FixtureCostProfilesGuardTest.php, apps/platform/tests/Unit/Support/CreateUserWithTenantProfilesTest.php, apps/platform/tests/Unit/Factories/TenantFactoryTest.php, apps/platform/tests/Unit/Factories/ProviderConnectionFactoryTest.php, and apps/platform/tests/Unit/Factories/ProviderCredentialFactoryTest.php

---

Phase 2: Foundational (Blocking Prerequisites)

Purpose: Record the pre-migration measurement baseline, classify the hidden-cost surface, and establish the canonical fixture-profile vocabulary before story work begins.

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

• T003 Capture the pre-migration fast-feedback and confidence lane baseline and reuse the Spec 206 comparison seams in apps/platform/tests/Support/TestLaneManifest.php, apps/platform/tests/Support/TestLaneReport.php, apps/platform/tests/Feature/Guards/FixtureLaneImpactBudgetTest.php, and specs/207-shared-test-fixture-slimming/quickstart.md
• T004 [P] Inventory and classify the shared helper surface, high-usage caller packs, and hidden cascade findings in specs/207-shared-test-fixture-slimming/data-model.md and specs/207-shared-test-fixture-slimming/quickstart.md
• T005 Implement the canonical minimal, standard, and full fixture profile catalog plus temporary legacy alias resolution in apps/platform/tests/Pest.php

Checkpoint: The shared support layer has a recorded pre-migration baseline, a classified audit surface, one canonical profile language, and one measurement path that all stories can build on.

---

Phase 3: User Story 1 - Use A Minimal Fixture By Default (Priority: P1)

Goal: Make the default shared fixture path and default factory behavior create only the smallest valid context.

Independent Test: Run the helper and factory guards and verify that ordinary calls do not create provider, credential, cache, UI, or hidden workspace graph side effects.

Tests for User Story 1

• T006 [P] [US1] Add failing minimal-helper and user-side-effect coverage in apps/platform/tests/Unit/Support/CreateUserWithTenantProfilesTest.php and apps/platform/tests/Feature/Guards/FixtureCostProfilesGuardTest.php
• T007 [P] [US1] Add failing lean tenant and workspace cascade coverage in apps/platform/tests/Unit/Factories/TenantFactoryTest.php and apps/platform/tests/Unit/Factories/OperationRunFactoryTest.php

Implementation for User Story 1

• T008 [US1] Make minimal the default shared fixture path and apply the already-defined standard side-effect contract in apps/platform/tests/Pest.php
• T009 [US1] Remove implicit lean-workspace provisioning from apps/platform/app/Models/Tenant.php and apps/platform/database/factories/TenantFactory.php
• T010 [US1] Add lean operation-context defaults in apps/platform/database/factories/OperationRunFactory.php and apps/platform/database/factories/BackupSetFactory.php

Checkpoint: The shared helper default and touched core factory defaults stay lean unless a test explicitly asks for more context.

---

Phase 4: User Story 2 - Opt Into Heavy Context Deliberately (Priority: P1)

Goal: Preserve valid heavy integration setup, but require it to announce itself clearly through explicit profiles or states.

Independent Test: Run the helper and factory guards and verify that explicit provider, credential, backup, cache, and UI-context requests create the promised extra context without hiding behind the minimal default.

Tests for User Story 2

• T011 [P] [US2] Add failing explicit provider, credential, user-relationship, cache, and UI-context coverage in apps/platform/tests/Unit/Support/CreateUserWithTenantProfilesTest.php and apps/platform/tests/Feature/Guards/FixtureCostProfilesGuardTest.php
• T012 [P] [US2] Add failing explicit heavy-state coverage for provider, provider-credential, and backup graphs in apps/platform/tests/Unit/Factories/ProviderConnectionFactoryTest.php, apps/platform/tests/Unit/Factories/ProviderCredentialFactoryTest.php, and apps/platform/tests/Unit/Factories/BackupSetFactoryTest.php

Implementation for User Story 2

• T013 [US2] Add explicit heavy, provider-enabled, credential-enabled, and ui-context helper entry points plus temporary transition aliases in apps/platform/tests/Pest.php
• T014 [US2] Add explicit heavy factory states for provider, provider-credential, and backup graphs in apps/platform/database/factories/ProviderConnectionFactory.php, apps/platform/database/factories/ProviderCredentialFactory.php, and apps/platform/database/factories/BackupSetFactory.php
• T015 [US2] Make heavy-by-intent builder setup announce itself in apps/platform/tests/Feature/Concerns/BuildsBaselineCompareMatrixFixtures.php, apps/platform/tests/Feature/Concerns/BuildsGovernanceArtifactTruthFixtures.php, apps/platform/tests/Feature/Concerns/BuildsPortfolioTriageFixtures.php, and apps/platform/tests/Feature/Concerns/BuildsOperatorExplanationFixtures.php

Checkpoint: Heavy setup remains available, but the call site now makes it obvious when the test is asking for integration-heavy context.

---

Phase 5: User Story 3 - Migrate High-Usage Callers Safely (Priority: P2)

Goal: Move the first high-usage expensive callers onto the lightest valid profiles without unnecessary broad breakage.

Independent Test: Run the migrated caller packs and verify that narrow tests adopt minimal or standard profiles while the legacy full-context path remains available, visibly heavier, and marked for removal where still needed.

Tests for User Story 3

• T016 [P] [US3] Add failing migration-pack regression coverage for console and navigation callers in apps/platform/tests/Feature/Console/ReconcileOperationRunsCommandTest.php, apps/platform/tests/Feature/Console/ReconcileBackupScheduleOperationRunsCommandTest.php, and apps/platform/tests/Feature/Navigation/RelatedNavigationResolverMemoizationTest.php
• T017 [P] [US3] Add failing migration-pack regression coverage for RBAC and drift callers in apps/platform/tests/Feature/Spec080WorkspaceManagedTenantAdminMigrationTest.php and apps/platform/tests/Feature/BaselineDriftEngine/FindingFidelityTest.php

Implementation for User Story 3

• T018 [US3] Migrate the first console and navigation caller pack to minimal or standard profiles in apps/platform/tests/Feature/Console/ReconcileOperationRunsCommandTest.php, apps/platform/tests/Feature/Console/ReconcileBackupScheduleOperationRunsCommandTest.php, and apps/platform/tests/Feature/Navigation/RelatedNavigationResolverMemoizationTest.php
• T019 [US3] Migrate the first RBAC and drift caller pack to minimal or standard profiles in apps/platform/tests/Feature/Spec080WorkspaceManagedTenantAdminMigrationTest.php and apps/platform/tests/Feature/BaselineDriftEngine/FindingFidelityTest.php
• T020 [US3] Preserve and label the visible legacy full-context path and declare its removal trigger in apps/platform/tests/Pest.php, README.md, and specs/207-shared-test-fixture-slimming/quickstart.md

Checkpoint: The first high-usage packs in the standard lanes use cheaper profiles, and any remaining full-context path is explicit rather than hidden.

---

Phase 6: User Story 4 - Catch Fixture Cost Regressions Early (Priority: P2)

Goal: Add guard coverage and lane validation so hidden fixture-cost regressions are caught before they spread.

Independent Test: Run the fixture guards plus the Spec 206 fast-feedback and confidence reports and verify that hidden cascades fail loudly and lane outcomes stay stable or improved.

Tests for User Story 4

• T021 [P] [US4] Add hidden-cascade audit coverage for the tenant boot hook, user-side effects in shared helper defaults, provider connection defaults, provider-credential defaults, and backup-set callbacks in apps/platform/tests/Unit/Support/CreateUserWithTenantProfilesTest.php, apps/platform/tests/Unit/Factories/TenantFactoryTest.php, apps/platform/tests/Unit/Factories/ProviderConnectionFactoryTest.php, apps/platform/tests/Unit/Factories/ProviderCredentialFactoryTest.php, and apps/platform/tests/Unit/Factories/BackupSetFactoryTest.php
• T022 [P] [US4] Add lane-impact regression coverage against the Spec 206 budgets in apps/platform/tests/Feature/Guards/FixtureLaneImpactBudgetTest.php and apps/platform/tests/Feature/Guards/TestLaneArtifactsContractTest.php

Implementation for User Story 4

• T023 [US4] Record the cascade-audit dispositions and fixture cost signals in README.md and apps/platform/tests/Pest.php
• T024 [US4] Wire the recorded pre- and post-migration lane comparison into scripts/platform-test-report, apps/platform/tests/Support/TestLaneReport.php, and apps/platform/tests/Support/TestLaneManifest.php
• T025 [US4] Publish concise author guidance for minimal vs standard vs full fixture setup in README.md and specs/207-shared-test-fixture-slimming/quickstart.md

Checkpoint: Hidden-cost regressions are guarded, and the fixture changes are measurable against the existing lane budgets.

---

Phase 7: Polish & Cross-Cutting Concerns

Purpose: Reconcile the implementation with the design artifacts and validate the end-to-end workflow.

• T026 [P] Reconcile the implemented fixture-profile catalog, temporary alias retirement data, and audit coverage with specs/207-shared-test-fixture-slimming/contracts/shared-fixture-profile.schema.json and specs/207-shared-test-fixture-slimming/contracts/shared-test-fixture-slimming.logical.openapi.yaml
• T027 Run focused fixture and migration-pack validation with cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/CreateUserWithTenantProfilesTest.php, cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Factories, cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Console, cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Navigation/RelatedNavigationResolverMemoizationTest.php, cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Spec080WorkspaceManagedTenantAdminMigrationTest.php, and cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/BaselineDriftEngine/FindingFidelityTest.php
• T028 Run post-migration Spec 206 lane validation and compare against the recorded pre-migration baseline with ./scripts/platform-test-lane fast-feedback, ./scripts/platform-test-lane confidence, ./scripts/platform-test-report fast-feedback, and ./scripts/platform-test-report confidence
• T029 Run formatting with cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent

---

Dependencies & Execution Order

Phase Dependencies

• Setup (Phase 1): No dependencies and can start immediately.
• Foundational (Phase 2): Depends on Setup completion and blocks all story work.
• User Story 1 (Phase 3): Starts after Foundational completion.
• User Story 2 (Phase 4): Starts after Foundational completion and is independently testable, but it shares apps/platform/tests/Pest.php and the touched factory seams with US1.
• User Story 3 (Phase 5): Depends on US1 and US2 because caller migration needs the new lean and heavy profile semantics to be stable first.
• User Story 4 (Phase 6): Depends on US1, US2, and US3 because guard coverage and lane comparison need the implemented profile and migration behavior in place.
• Polish (Phase 7): Runs after the desired user stories are complete.

User Story Dependencies

• User Story 1 (P1): No dependency on other stories. This is the recommended MVP slice.
• User Story 2 (P1): Depends only on the foundational profile catalog and is independently testable once the helper and factory contracts exist.
• User Story 3 (P2): Depends on US1 and US2 because migration packs need the new explicit profile behavior before callers can move safely.
• User Story 4 (P2): Depends on US1, US2, and US3 because regression guards and lane comparisons must validate the final migrated behavior.

Within Each User Story

• Tests MUST be written and fail before implementation.
• The pre-migration lane baseline must be recorded before helper or factory semantics change.
• Shared helper profile changes must land before touched caller files migrate to them.
• Lean tenant/workspace behavior must be fixed before operation or backup factories are treated as slimmed.
• Explicit heavy profiles and states must exist before legacy heavy callers are redirected to them.
• Lane-impact comparison must use the existing Spec 206 seams rather than a new one-off harness.

Parallel Opportunities

• T002 can run in parallel with T001 after the new test files are created.
• T003 and T004 can run in parallel before T005 codifies the canonical profile vocabulary.
• US1 test tasks T006 and T007 can run in parallel.
• US2 test tasks T011 and T012 can run in parallel.
• US3 test tasks T016 and T017 can run in parallel.
• US4 test tasks T021 and T022 can run in parallel.
• After US1 and US2 are complete, one developer can migrate callers while another adds the lane-impact guard and reporting work.

---

Parallel Example: User Story 1

# Run the lean-default tests in parallel:
Task: "Add failing minimal-helper side-effect coverage in apps/platform/tests/Unit/Support/CreateUserWithTenantProfilesTest.php and apps/platform/tests/Feature/Guards/FixtureCostProfilesGuardTest.php"
Task: "Add failing lean tenant and workspace cascade coverage in apps/platform/tests/Unit/Factories/TenantFactoryTest.php and apps/platform/tests/Unit/Factories/OperationRunFactoryTest.php"

---

Parallel Example: User Story 2

# Run the explicit-heavy tests in parallel:
Task: "Add failing explicit provider, credential, cache, and UI-context coverage in apps/platform/tests/Unit/Support/CreateUserWithTenantProfilesTest.php and apps/platform/tests/Feature/Guards/FixtureCostProfilesGuardTest.php"
Task: "Add failing explicit heavy-state coverage for provider and backup graphs in apps/platform/tests/Unit/Factories/ProviderConnectionFactoryTest.php and apps/platform/tests/Unit/Factories/BackupSetFactoryTest.php"

---

Parallel Example: User Story 3

# Run the migration-pack regressions in parallel:
Task: "Add failing migration-pack regression coverage for console and navigation callers in apps/platform/tests/Feature/Console/ReconcileOperationRunsCommandTest.php, apps/platform/tests/Feature/Console/ReconcileBackupScheduleOperationRunsCommandTest.php, and apps/platform/tests/Feature/Navigation/RelatedNavigationResolverMemoizationTest.php"
Task: "Add failing migration-pack regression coverage for RBAC and drift callers in apps/platform/tests/Feature/Spec080WorkspaceManagedTenantAdminMigrationTest.php and apps/platform/tests/Feature/BaselineDriftEngine/FindingFidelityTest.php"

---

Parallel Example: User Story 4

# Run the regression guards in parallel:
Task: "Add hidden-cascade audit coverage for the tenant boot hook, provider connection defaults, and backup-set callbacks in apps/platform/tests/Unit/Factories/TenantFactoryTest.php, apps/platform/tests/Unit/Factories/ProviderConnectionFactoryTest.php, and apps/platform/tests/Unit/Factories/BackupSetFactoryTest.php"
Task: "Add lane-impact regression coverage against the Spec 206 budgets in apps/platform/tests/Feature/Guards/FixtureLaneImpactBudgetTest.php and apps/platform/tests/Feature/Guards/TestLaneArtifactsContractTest.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. Stop and validate that the default shared helper and touched default factories stay lean.

Incremental Delivery

1. Record the pre-migration baseline, classify the audit surface, and land the canonical fixture profile vocabulary.
2. Ship the minimal-default behavior in the shared helper and core factories.
3. Add explicit heavy opt-in behavior so legitimate integration tests remain readable.
4. Migrate the first high-usage caller packs in the standard lanes.
5. Finish with guard coverage, lane validation, and contributor guidance.

Parallel Team Strategy

1. One developer establishes the canonical profile catalog and shared comparison seams.
2. A second developer can own the minimal-default and explicit-heavy factory work once the profile catalog exists.
3. A third developer can migrate the first caller packs after the new profile behavior is stable.
4. A final pass adds regression guards, lane comparisons, and documentation updates.

---

Notes

• [P] tasks touch different files and have no unresolved dependency on incomplete work.
• US1 is the recommended MVP because it restores the cheap default path first.
• US2 preserves legitimate heavy integration coverage without hiding its cost.
• US3 converts the highest-usage expensive callers into evidence-backed migration packs.
• US4 makes the new fixture discipline durable through guards and lane-budget validation.