# Configuration Standardization

## Overview

The Stock Bot system now uses a unified configuration approach that standardizes how services receive and use configuration. This eliminates the previous confusion between `StockBotAppConfig` and `AppConfig`, providing a single source of truth for all configuration needs.

## Key Changes

### 1. Unified Configuration Schema

The new `UnifiedAppConfig` schema:
- Provides both nested (backward compatible) and flat (DI-friendly) database configurations
- Automatically standardizes service names to kebab-case
- Handles field name mappings (e.g., `ilpPort` → `influxPort`)
- Ensures all required fields are present for DI system

### 2. Service Name Standardization

All service names are now standardized to kebab-case:
- `dataIngestion` → `data-ingestion`
- `dataPipeline` → `data-pipeline`
- `webApi` → `web-api`

This happens automatically in:
- `initializeStockConfig()` when passing service name
- `ServiceApplication` constructor
- `toUnifiedConfig()` transformation

### 3. Single Configuration Object

Services now use a single configuration object (`this.config`) that contains:
- All service-specific settings
- Database configurations (both nested and flat)
- Service metadata including standardized name
- All settings required by the DI system

## Migration Guide

### For Service Implementations

Before:
```typescript
const app = new ServiceApplication(
  config,
  {
    serviceName: 'web-api',
    // other options
  }
);

// In container factory
const configWithService = {
  ...this.config,
  service: { name: this.serviceConfig.serviceName }
};
```

After:
```typescript
const app = new ServiceApplication(
  config,  // Config already has service.serviceName
  {
    serviceName: 'web-api',  // Still needed for logger
    // other options
  }
);

// In container factory
// No manual service name addition needed
this.container = await containerFactory(this.config);
```

### For DI Container Usage

Before:
```typescript
const serviceName = config.service?.name || 'unknown';
// Had to handle different naming conventions
```

After:
```typescript
const serviceName = config.service?.serviceName || config.service?.name || 'unknown';
// Standardized kebab-case name is always available
```

### For Configuration Files

The configuration structure remains the same, but the system now ensures:
- Service names are standardized automatically
- Database configs are available in both formats
- All required fields are properly mapped

## Benefits

1. **Simplicity**: One configuration object with all necessary information
2. **Consistency**: Standardized service naming across the system
3. **Type Safety**: Unified schema provides better TypeScript support
4. **Backward Compatibility**: Old configuration formats still work
5. **Reduced Complexity**: No more manual config transformations

## Technical Details

### UnifiedAppConfig Schema

```typescript
export const unifiedAppSchema = baseAppSchema.extend({
  // Flat database configs for DI system
  redis: dragonflyConfigSchema.optional(),
  mongodb: mongodbConfigSchema.optional(),
  postgres: postgresConfigSchema.optional(),
  questdb: questdbConfigSchema.optional(),
}).transform((data) => {
  // Auto-standardize service name
  // Sync nested and flat configs
  // Handle field mappings
});
```

### Service Registry

The `SERVICE_REGISTRY` now includes aliases for different naming conventions:
```typescript
'web-api': { db: 3, ... },
'webApi': { db: 3, ... },    // Alias for backward compatibility
```

## Future Improvements

1. Remove service name aliases after full migration
2. Deprecate old configuration formats
3. Add configuration validation at startup
4. Provide migration tooling for existing services