# Quickstart: Shared Test Fixture Slimming

## Goal

Reduce per-test cost in the shared support layer without reducing meaningful coverage by making minimal fixture behavior the default, moving heavy provider or membership or workspace behavior behind explicit opt-in paths, migrating the highest-usage expensive callers, and proving the result against the existing Spec 206 lane budgets.

## Implementation Order

1. Capture the pre-migration fast-feedback and confidence lane baseline with the existing Spec 206 wrappers before helper or factory edits begin.
2. Inventory and classify the existing helper and factory seams that still hide extra workspace, provider, credential, session, user-relationship, or graph state.
3. Finalize the fixture-profile vocabulary of `minimal`, `standard`, and `full` or `integration-heavy`, including mapping rules and retirement triggers for current explicit variants.
4. Audit and slim tenant workspace provisioning across both `TenantFactory` and the `Tenant` model boot hook.
5. Audit and slim the next high-cost factories, starting with `OperationRunFactory`, `ProviderConnectionFactory`, `ProviderCredentialFactory`, and `BackupSetFactory`.
6. Make heavy-by-intent builders and helpers announce their cost through naming or explicit parameters.
7. Add guard coverage that asserts lean paths stay lean and heavy paths create only their promised extra context.
8. Migrate the first high-usage caller packs in fast-feedback and confidence.
9. Measure post-migration lane impact against the recorded baseline with the existing Spec 206 lane-report tooling. `./scripts/platform-test-report` should emit the `sharedFixtureSlimmingComparison` block for `fast-feedback` and `confidence`.
10. Publish concise contributor guidance for choosing the cheapest valid fixture path.

## Suggested Code Touches

```text
apps/platform/app/Models/Tenant.php
apps/platform/database/factories/TenantFactory.php
apps/platform/database/factories/OperationRunFactory.php
apps/platform/database/factories/ProviderConnectionFactory.php
apps/platform/database/factories/BackupSetFactory.php
apps/platform/database/factories/RestoreRunFactory.php
apps/platform/tests/Pest.php
apps/platform/tests/Feature/Concerns/*
apps/platform/tests/Feature/Console/*
apps/platform/tests/Feature/Guards/*
apps/platform/tests/Feature/Navigation/*
apps/platform/tests/Feature/Spec080WorkspaceManagedTenantAdminMigrationTest.php
apps/platform/tests/Support/*
scripts/platform-test-lane
scripts/platform-test-report
```

## Validation Flow

Use focused suites while slimming one seam at a time, then validate the standard lanes against the Spec 206 baseline:

```bash
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Console
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Guards
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Navigation
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Spec080WorkspaceManagedTenantAdminMigrationTest.php
./scripts/platform-test-lane fast-feedback
./scripts/platform-test-lane confidence
./scripts/platform-test-report fast-feedback
./scripts/platform-test-report confidence
cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
```

If a touched factory or helper affects an intentionally heavy builder, validate that specific surface before measuring the lanes.

## Recorded Pre-Migration Baseline Capture

The current pre-migration snapshots for this spec were captured on `2026-04-16T13:11:57+00:00` and are the baseline that the lane-impact guard and report comparison use:

| Lane | Baseline | Budget | Target |
|------|----------|--------|--------|
| `fast-feedback` | `176.73623s` | `200s` | improve by `>=10%` or stay within `+5%` |
| `confidence` | `394.383441s` | `450s` | improve by `>=10%` or stay within `+5%` |

## Baseline References

Use the existing Spec 206 recorded measurements as the starting point for lane impact:

- `fast-feedback`: `176.74s` budget `200s`
- `confidence`: `394.38s` budget `450s`
- `heavy-governance`: `83.66s` budget `120s`
- `browser`: `128.87s` budget `150s`

The first success target for this feature is not to redesign the lane model. It is to improve per-test cost enough that at least one affected standard lane gets measurably faster while the others remain stable.

Record fresh pre-migration fast-feedback and confidence snapshots on the feature branch before fixture changes land so the eventual comparison is not inferred only from historical Spec 206 documentation.

## Legacy Alias Retirement

- `provider-enabled` retires after the first fast-feedback and confidence migration packs call `standard` directly.
- `credential-enabled` retires after credential-dependent callers move to `full` plus explicit local overrides where needed.
- `ui-context` retires after UI-context callers use the canonical `full` profile or an equally explicit local helper.
- `heavy` retires after the remaining legacy callers use `full` directly.

## Manual Review Checklist

1. Confirm the default helper path stays on `minimal` semantics and does not silently create provider or credential or UI context.
2. Confirm touched factories declare lean versus heavy behavior explicitly instead of hiding it in callbacks or attribute resolvers.
3. Confirm the tenant workspace cascade is controlled consistently across both factory and model layers.
4. Confirm legacy heavy paths remain visible, temporary during migration, and tied to explicit removal triggers.
5. Confirm the first migrated caller packs match their real business need and do not fall back to full context without explanation.
6. Confirm guard coverage asserts both absence and presence of context where appropriate.
7. Confirm both pre- and post-migration lane measurements are taken through the existing Spec 206 wrappers and artifacts under `storage/logs/test-lanes`.

## Exit Criteria

1. The shared support layer has a documented fixture-profile model with `minimal`, `standard`, and `full` or `integration-heavy`.
2. Touched high-usage helpers and factories no longer create hidden heavy context by default.
3. Legacy heavy behavior is available through an explicit and visibly temporary transition path with a declared removal trigger.
4. The first high-usage caller packs in fast-feedback and confidence have been migrated.
5. Guard coverage protects lean paths, heavy paths, and the transition path.
6. Post-migration lane measurements show at least one affected standard lane improved and no affected standard lane materially regressed against the Spec 206 budgets.