diff --git a/.gitignore b/.gitignore
index e79e5c5..3a4c597 100644
--- a/.gitignore
+++ b/.gitignore
@@ -103,4 +103,9 @@ Thumbs.db
 
 # Turbo
 .turbo
-*.tsbuildinfo
+*.tsbuildinfo
+
+# AI
+.serena/
+.claude/
+docs/configuration-standardization.md
diff --git a/docs/configuration-standardization.md b/docs/configuration-standardization.md
deleted file mode 100644
index d1cef12..0000000
--- a/docs/configuration-standardization.md
+++ /dev/null
@@ -1,133 +0,0 @@
-# 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
\ No newline at end of file