# Quickstart: Filter UX Standardization

## Goal

Bring Tier 1 and Tier 2 Filament resource lists onto a single filter UX standard using native Filament filters, native session persistence, and focused guard coverage.

## Foundation Steps

1. Review the current filter standard and comprehensive audit to confirm the Tier 1 and Tier 2 targets.
2. Confirm the missing persistence trio on `InventoryItemResource`, `PolicyVersionResource`, `RestoreRunResource`, `AlertDeliveryResource`, and `EntraGroupResource`.
3. Confirm the current central status vocabularies already available through enums, badge catalogs, or tag-badge catalogs.
4. Confirm `OperationRunResource` as the reference implementation for the native date-range pattern.
5. Identify any resource with query-risk filters before extending search or filtering behavior.

## First-Wave Implementation Steps

1. Add `persistFiltersInSession()`, `persistSearchInSession()`, and `persistSortInSession()` to all missing Tier 1 and Tier 2 filtered resource lists.
2. Extend `FilamentTableStandardsGuardTest` so Tier 1 and Tier 2 persistence is enforced consistently.
3. Add essential missing filters to `RestoreRunResource`, `PolicyVersionResource`, `InventoryItemResource`, `FindingResource`, `AlertDeliveryResource`, and `BaselineProfileResource`.
4. Reuse the native `OperationRunResource` date-range shape for new date-range filters and ensure `indicateUsing()` is present.
5. Normalize soft-delete behavior to the existing Archived/Active/All pattern on every in-scope soft-deletable resource list.
6. Replace prioritized local status arrays with centralized option sources backed by the thin shared helper layer where needed.
7. Keep domain-specific filter intent resource-local while using the thin shared helper layer only for repeated mechanical presets.

## Approved Follow-up Surfaces

1. Add the same persistence and filter treatment to `BaselineSnapshotResource` when governance review shows the missing filter gap in daily use.
2. Add type/restore/platform filtering to `BackupItemsRelationManager` when backup reviewers need to isolate specific foundations or RBAC entries inside a backup set.
3. Keep these follow-ups Filament-native and low-risk; they are extensions of the same standard, not a second filter framework.

## Verification

### Automated

```bash
vendor/bin/sail up -d
vendor/bin/sail artisan test --compact tests/Feature/Guards/FilamentTableStandardsGuardTest.php
vendor/bin/sail artisan test --compact tests/Feature/Filament/TableStatePersistenceTest.php
vendor/bin/sail artisan test --compact tests/Feature/Filament/BaselineSnapshotListFiltersTest.php
vendor/bin/sail artisan test --compact tests/Feature/Filament/BackupItemsRelationManagerFiltersTest.php
vendor/bin/sail artisan test --compact tests/Feature/Filament/Findings
vendor/bin/sail artisan test --compact tests/Feature/Filament/Alerts
vendor/bin/sail bin pint --dirty --format agent
```

### Manual

1. Narrow an in-scope resource list with search, sort, and filters, refresh the page, and confirm the same state remains.
2. Navigate away from the same list and return within the session to confirm list-state persistence holds.
3. Apply each new date-range filter and confirm the indicator summary shows the active window clearly.
4. Verify Archived, Active, and All semantics on each changed soft-deletable surface.
5. Verify workspace-scoped monitoring lists and tenant-scoped inventory/governance lists do not reveal records outside the current entitlement boundary.
6. On `Baseline Snapshots`, filter by baseline, state, and capture window, then clear the filters and confirm the full workspace-scoped list returns.
7. Inside a backup set, filter `Items` by type, restore mode, and platform to isolate RBAC or foundation entries without losing the backup-set scope.

## Rollback

- Revert the affected resource `table()` filter definitions and any guard updates that enforce the new standard.
- Keep the thin shared helper layer mechanically scoped and remove only pieces that stop serving repeated archived, date-range, or centralized-option use cases.
- No database rollback is required because the feature introduces no schema changes.