# Feature-Specific Type Files Audit

**Date**: 2025-01-27  
**Action**: 1.1.3.12 - Audit all feature-specific type files  
**Status**: ✅ Complete

## Overview

This document lists all feature-specific type files and identifies which types can be replaced with generated types from OpenAPI.

## Feature Type Files Found

### 1. `src/features/tracks/types/track.ts`
**Purpose**: Track-related types for tracks feature

**Types Defined**:
- `TrackStatus` enum - Values: uploading, processing, completed, failed
- `Track` interface - 20+ fields (id, creator_id, title, artist, duration, etc.)
- `UploadProgress` interface - Upload state tracking

**Status**: 
- ✅ `TrackStatus` matches backend enum (uploading, processing, completed, failed)
- ⚠️ `Track` interface duplicates `VezaBackendApiInternalModelsTrack` from generated types
- ✅ `UploadProgress` is frontend-specific (keep)

**Migration Plan**:
- Replace `Track` with `VezaBackendApiInternalModelsTrack`
- Replace `TrackStatus` enum with `VezaBackendApiInternalModelsTrackStatus` type
- Keep `UploadProgress` (frontend state)

### 2. `src/features/auth/types/index.ts`
**Purpose**: Authentication-related types

**Types Defined**:
- Re-exports `User`, `AuthTokens` from `@/types` (backward compatibility)
- `LoginCredentials` - Form data type
- `RegisterCredentials` - Form data type
- `AuthResponse` - Uses `User` and `AuthTokens` from `@/types`
- `RefreshResponse` - Token refresh response
- Form data types: `LoginFormData`, `RegisterFormData`, `ForgotPasswordFormData`, `ResetPasswordFormData`
- API request types: `VerifyEmailRequest`, `ResendVerificationRequest`, `CheckUsernameRequest`, etc.
- OAuth types: `OAuthProvider`, `OAuthProvidersResponse`
- 2FA types: `TwoFactorSetupResponse`, `TwoFactorVerifyRequest`, `TwoFactorStatusResponse`

**Status**:
- ⚠️ Re-exports `User` from `@/types` (will need update when User is migrated)
- ⚠️ `AuthResponse` uses `User` and `AuthTokens` (will need update)
- ⚠️ `RefreshResponse` may duplicate `VezaBackendApiInternalDtoTokenResponse`
- ⚠️ Request types may duplicate generated DTOs
- ✅ Form data types are frontend-specific (keep)
- ✅ OAuth types may be frontend-specific (verify)

**Migration Plan**:
- Update re-exports to use generated types
- Replace `RefreshResponse` with `VezaBackendApiInternalDtoTokenResponse`
- Replace request types with generated DTOs
- Keep form data types (frontend-specific)
- Verify OAuth types against generated types

### 3. `src/features/chat/types/index.ts`
**Purpose**: Chat-related types (WebSocket)

**Types Defined**:
- `MessageAttachment` - File attachment for messages
- `OutgoingMessage` - WebSocket outgoing message types
- `IncomingMessage` - WebSocket incoming message types
- `HistoryMessage` - Message history structure

**Status**:
- ✅ All types are WebSocket-specific (not in REST API)
- ✅ No duplication with generated types
- ✅ Keep all types (WebSocket protocol types)

**Migration Plan**:
- Keep all types (WebSocket-specific, not in OpenAPI spec)
- No migration needed

### 4. `src/features/roles/types/role.ts`
**Purpose**: Role and permission types

**Types Defined**:
- `Role` interface - Role definition
- `Permission` interface - Permission definition
- `UserRole` interface - User-role assignment
- `AssignRoleRequest` - Request to assign role

**Status**:
- ⚠️ `Role`, `Permission`, `UserRole` may duplicate backend types
- ⚠️ `AssignRoleRequest` may duplicate generated request type
- Need to check against generated types

**Migration Plan**:
- Check against generated role/permission types
- Replace if duplicates exist
- Keep frontend-specific extensions if any

### 5. `src/features/settings/types/settings.ts`
**Purpose**: Settings-related types

**Types Defined**:
- `NotificationSettings` - Email/push notification preferences
- `PrivacySettings` - Privacy preferences
- `ContentSettings` - Content preferences
- `PreferenceSettings` - Language/timezone/theme
- `PlaybackSettings` - Audio playback preferences
- `UserSettings` - Combined settings object
- `UpdateSettingsRequest` - Settings update request

**Status**:
- ✅ Most types are frontend-specific (UI preferences)
- ⚠️ `UpdateSettingsRequest` may duplicate backend request type
- Need to verify against backend settings endpoints

**Migration Plan**:
- Keep most types (frontend-specific preferences)
- Check `UpdateSettingsRequest` against generated types
- Replace if duplicates exist

## Summary

**Total Feature Type Files**: 5 files

**Files Requiring Migration**:
1. ✅ `features/tracks/types/track.ts` - `Track` and `TrackStatus` need replacement
2. ⚠️ `features/auth/types/index.ts` - Re-exports and request types need replacement
3. ✅ `features/chat/types/index.ts` - No migration needed (WebSocket-specific)
4. ⚠️ `features/roles/types/role.ts` - May need replacement (verify against generated)
5. ✅ `features/settings/types/settings.ts` - Mostly keep (frontend-specific)

**Estimated Types to Replace**: 8-12 types across 3 files

**Types to Keep**:
- WebSocket-specific types (chat)
- Frontend-only state types
- UI-specific extensions
- Feature-specific business logic types

## Next Steps

1. ✅ **Action 1.1.3.12**: Audit complete - This document
2. ⏭️ **Action 1.1.3.13**: Update feature-specific type files to use generated types
3. ⏭️ **Action 1.1.3.14**: Remove duplicate properties from extensions

## Validation

✅ All feature type files identified  
✅ Migration needs documented  
⚠️ Detailed type-by-type analysis needed during migration
