# Cluster Search Default Deploy Type

## Current Design

- UI cluster overview calls `/dashboard/clusters2` through `getGlobalClusters`.
- Internal users can pass `deploy_type_v2` filters from the Deploy Type column.
- Backend `CloudClusters2` maps `deploy_type_v2` to `ListOrganizationAndClusterFilter.DeployTypeV2`.
- `applyDashboardNonQueryFilters` appends `c.deploy_type_v2 IN ?` when that filter is present.
- Text search still uses exact ID branches plus `%LIKE%` on cluster and tenant names when policy allows it.

## Risks

- Starter tenants can dominate production row count and make unfiltered searches expensive.
- A leading-wildcard `%LIKE%` predicate is not made index-backed by a normal B-tree index.
- UI-only defaults must not remove the user's ability to explicitly search starter clusters.

## Target Contract

- The cluster overview defaults to non-starter deploy types for internal users.
- Clearing or changing the Deploy Type filter remains user-controlled.
- The backend keeps `deploy_type_v2` as the canonical filter field for this screen.
- The database has an index that can prune starter rows before default sorted listing.
- Numeric ID search continues to use indexed equality branches.

## Implementation Steps

1. Default the UI Deploy Type filter to every known `deploy_type_v2` except `starter`.
2. Show Deploy Type values with a blue tag and add a page notification about the default.
3. Add a backend migration for `clusters(deploy_type_v2, created_at)`.
4. Add dry-run SQL tests for deploy-type filter propagation.

## Verification Checklist

- `go test ./pkg/datasource`
- `pnpm --filter @clinic/web exec tsc --noEmit`
- After AWS SSO is refreshed: run production `SHOW INDEX FROM clusters` and `EXPLAIN` for `/dashboard/clusters2`-equivalent queries.