@push.rocks/smartproxy 15.0.2 → 16.0.2

package/readme.plan.md

@@ -1,316 +1,168 @@
-# SmartProxy Fully Unified Configuration Plan (Updated)
+# SmartProxy Complete Route-Based Implementation Plan
 
 ## Project Goal
-Redesign SmartProxy's configuration for a more elegant, unified, and comprehensible approach by:
-1. Creating a single, unified configuration model that covers both "where to listen" and "how to forward"
-2. Eliminating the confusion between domain configs and port forwarding
-3. Providing a clear, declarative API that makes the intent obvious
-4. Enhancing maintainability and extensibility for future features
-5. Completely removing legacy code to eliminate technical debt
-
-## Current Issues
-
-The current approach has several issues:
-
-1. **Dual Configuration Systems**:
-   - Port configuration (`fromPort`, `toPort`, `globalPortRanges`) for "where to listen"
-   - Domain configuration (`domainConfigs`) for "how to forward"
-   - Unclear relationship between these two systems
-
-2. **Mixed Concerns**:
-   - Port management is mixed with forwarding logic
-   - Domain routing is separated from port listening
-   - Security settings defined in multiple places
-
-3. **Complex Logic**:
-   - PortRangeManager must coordinate with domain configuration
-   - Implicit rules for handling connections based on port and domain
-
-4. **Difficult to Understand and Configure**:
-   - Two separate configuration hierarchies that must work together
-   - Unclear which settings take precedence
-
-## Proposed Solution: Fully Unified Routing Configuration
-
-Replace both port and domain configuration with a single, unified configuration:
-
-```typescript
-// The core unified configuration interface
-interface IRouteConfig {
-  // What to match
-  match: {
-    // Listen on these ports (required)
-    ports: number | number[] | Array<{ from: number, to: number }>;
-    
-    // Optional domain patterns to match (default: all domains)
-    domains?: string | string[];
-    
-    // Advanced matching criteria
-    path?: string;           // Match specific paths
-    clientIp?: string[];     // Match specific client IPs
-    tlsVersion?: string[];   // Match specific TLS versions
-  };
-  
-  // What to do with matched traffic
-  action: {
-    // Basic routing
-    type: 'forward' | 'redirect' | 'block';
-    
-    // Target for forwarding
-    target?: {
-      host: string | string[];  // Support single host or round-robin
-      port: number;
-      preservePort?: boolean;   // Use incoming port as target port
-    };
-    
-    // TLS handling
-    tls?: {
-      mode: 'passthrough' | 'terminate' | 'terminate-and-reencrypt';
-      certificate?: 'auto' | {   // Auto = use ACME
-        key: string;
-        cert: string;
-      };
-    };
-    
-    // For redirects
-    redirect?: {
-      to: string;            // URL or template with {domain}, {port}, etc.
-      status: 301 | 302 | 307 | 308;
-    };
-    
-    // Security options
-    security?: {
-      allowedIps?: string[];
-      blockedIps?: string[];
-      maxConnections?: number;
-      authentication?: {
-        type: 'basic' | 'digest' | 'oauth';
-        // Auth-specific options
-      };
-    };
-    
-    // Advanced options
-    advanced?: {
-      timeout?: number;
-      headers?: Record<string, string>;
-      keepAlive?: boolean;
-      // etc.
-    };
-  };
-  
-  // Optional metadata
-  name?: string;             // Human-readable name for this route
-  description?: string;      // Description of the route's purpose
-  priority?: number;         // Controls matching order (higher = matched first)
-  tags?: string[];           // Arbitrary tags for categorization
-}
-
-// Main SmartProxy options
-interface ISmartProxyOptions {
-  // The unified configuration array (required)
-  routes: IRouteConfig[];
-  
-  // Global/default settings
-  defaults?: {
-    target?: {
-      host: string;
-      port: number;
-    };
-    security?: {
-      // Global security defaults
-    };
-    tls?: {
-      // Global TLS defaults
-    };
-    // ...other defaults
-  };
-  
-  // Other global settings remain (acme, etc.)
-  acme?: IAcmeOptions;
-  
-  // Advanced settings remain as well
-  // ...
-}
-```
-
-## Revised Implementation Plan
-
-### Phase 1: Core Design & Interface Definition
-
-1. **Define New Core Interfaces**:
-   - Create `IRouteConfig` interface with `match` and `action` branches
-   - Define all sub-interfaces for matching and actions
-   - Create new `ISmartProxyOptions` to use `routes` array exclusively
-   - Define template variable system for dynamic values
-
-2. **Create Helper Functions**:
-   - `createRoute()` - Basic route creation with reasonable defaults
-   - `createHttpRoute()`, `createHttpsRoute()`, `createRedirect()` - Common scenarios
-   - `createLoadBalancer()` - For multi-target setups
-   - `mergeSecurity()`, `mergeDefaults()` - For combining configs
-
-3. **Design Router**:
-   - Decision tree for route matching algorithm
-   - Priority system for route ordering
-   - Optimized lookup strategy for fast routing
-
-### Phase 2: Core Implementation
-
-1. **Create RouteManager**:
-   - Build a new RouteManager to replace both PortRangeManager and DomainConfigManager
-   - Implement port and domain matching in one unified system
-   - Create efficient route lookup algorithms
-
-2. **Implement New ConnectionHandler**:
-   - Create a new ConnectionHandler built from scratch for routes
-   - Implement the routing logic with the new match/action pattern
-   - Support template processing for headers and other dynamic values
-
-3. **Implement New SmartProxy Core**:
-   - Create new SmartProxy implementation using routes exclusively
-   - Build network servers based on port specifications
-   - Manage TLS contexts and certificates
-
-### Phase 3: Legacy Code Removal
-
-1. **Identify Legacy Components**:
-   - Create an inventory of all files and components to be removed
-   - Document dependencies between legacy components
-   - Create a removal plan that minimizes disruption
-
-2. **Remove Legacy Components**:
-   - Remove PortRangeManager and related code
-   - Remove DomainConfigManager and related code
-   - Remove old ConnectionHandler implementation
-   - Remove other legacy components
-
-3. **Clean Interface Adaptations**:
-   - Remove all legacy interfaces and types
-   - Update type exports to only expose route-based interfaces
-   - Remove any adapter or backward compatibility code
-
-### Phase 4: Updated Documentation & Examples
-
-1. **Update Core Documentation**:
-   - Rewrite README.md with a focus on route-based configuration exclusively
-   - Create interface reference documentation
-   - Document all template variables
-
-2. **Create Example Library**:
-   - Common configuration patterns using the new API
-   - Complex use cases for advanced features
-   - Infrastructure-as-code examples
-
-3. **Add Validation Tools**:
-   - Configuration validator to check for issues
-   - Schema definitions for IDE autocomplete
-   - Runtime validation helpers
-
-### Phase 5: Testing
-
-1. **Unit Tests**:
-   - Test route matching logic
-   - Validate priority handling
-   - Test template processing
-
-2. **Integration Tests**:
-   - Verify full proxy flows with the new system
-   - Test complex routing scenarios
-   - Ensure all features work as expected
-
-3. **Performance Testing**:
-   - Benchmark routing performance
-   - Evaluate memory usage
-   - Test with large numbers of routes
-
-## Implementation Strategy
-
-### Code Organization
-
-1. **New Files**:
-   - `route-config.ts` - Core route interfaces
-   - `route-manager.ts` - Route matching and management
-   - `route-connection-handler.ts` - Connection handling with routes
-   - `route-smart-proxy.ts` - Main SmartProxy implementation
-   - `template-engine.ts` - For variable substitution
-
-2. **File Removal**:
-   - Remove `port-range-manager.ts`
-   - Remove `domain-config-manager.ts`
-   - Remove legacy interfaces and adapter code
-   - Remove backward compatibility shims
-
-### Transition Strategy
-
-1. **Breaking Change Approach**:
-   - This will be a major version update with breaking changes
-   - No backward compatibility will be maintained
-   - Clear migration documentation will guide users to the new API
-
-2. **Package Structure**:
-   - `@push.rocks/smartproxy` package will be updated to v14.0.0
-   - Legacy code fully removed, only route-based API exposed
-   - Support documentation provided for migration
-
-3. **Migration Documentation**:
-   - Provide a migration guide with examples
-   - Show equivalent route configurations for common legacy patterns
-   - Offer code transformation helpers for complex setups
-
-## Benefits of the Clean Approach
-
-1. **Reduced Complexity**:
-   - No overlapping or conflicting configuration systems
-   - No dual maintenance of backward compatibility code
-   - Simplified internal architecture
-
-2. **Cleaner Code Base**:
-   - Removal of technical debt
-   - Better separation of concerns
-   - More maintainable codebase
-
-3. **Better User Experience**:
-   - Consistent, predictable API
-   - No confusing overlapping options
-   - Clear documentation of one approach, not two
+Complete the refactoring of SmartProxy to a pure route-based configuration approach by:
+1. Removing all remaining domain-based configuration code with no backward compatibility
+2. Updating internal components to work directly and exclusively with route configurations
+3. Eliminating all conversion functions and domain-based interfaces
+4. Cleaning up deprecated methods and interfaces completely
+5. Focusing entirely on route-based helper functions for the best developer experience
+
+## Current Status
+The major refactoring to route-based configuration has been successfully completed:
+- SmartProxy now works exclusively with route-based configurations in its public API
+- All test files have been updated to use route-based configurations
+- Documentation has been updated to explain the route-based approach
+- Helper functions have been implemented for creating route configurations
+- All features are working correctly with the new approach
+
+### Completed Phases:
+1. ✅ **Phase 1:** CertProvisioner has been fully refactored to work natively with routes
+2. ✅ **Phase 2:** NetworkProxyBridge now works directly with route configurations
+3. ✅ **Phase 3:** Legacy domain configuration code has been removed
+4. ✅ **Phase 4:** Route helpers and configuration experience have been enhanced
+5. ✅ **Phase 5:** Tests and validation have been completed
+
+### Project Status:
+✅ COMPLETED (May 10, 2025): SmartProxy has been fully refactored to a pure route-based configuration approach with no backward compatibility for domain-based configurations.
+
+## Implementation Checklist
+
+### Phase 1: Refactor CertProvisioner for Native Route Support ✅
+- [x] 1.1 Update CertProvisioner constructor to store routeConfigs directly
+- [x] 1.2 Remove extractDomainsFromRoutes() method and domainConfigs array
+- [x] 1.3 Create extractCertificateRoutesFromRoutes() method to find routes needing certificates
+- [x] 1.4 Update provisionAllDomains() to work with route configurations
+- [x] 1.5 Update provisionDomain() to handle route configs
+- [x] 1.6 Modify renewal tracking to use routes instead of domains
+- [x] 1.7 Update renewals scheduling to use route-based approach
+- [x] 1.8 Refactor requestCertificate() method to use routes
+- [x] 1.9 Update ICertificateData interface to include route references
+- [x] 1.10 Update certificate event handling to include route information
+- [x] 1.11 Add unit tests for route-based certificate provisioning
+- [x] 1.12 Add tests for wildcard domain handling with routes
+- [x] 1.13 Test certificate renewal with route configurations
+- [x] 1.14 Update certificate-types.ts to remove domain-based types
+
+### Phase 2: Refactor NetworkProxyBridge for Direct Route Processing ✅
+- [x] 2.1 Update NetworkProxyBridge constructor to work directly with routes
+- [x] 2.2 Refactor syncRoutesToNetworkProxy() to eliminate domain conversion
+- [x] 2.3 Rename convertRoutesToNetworkProxyConfigs() to mapRoutesToNetworkProxyConfigs()
+- [x] 2.4 Maintain syncDomainConfigsToNetworkProxy() as deprecated wrapper
+- [x] 2.5 Implement direct mapping from routes to NetworkProxy configs
+- [x] 2.6 Update handleCertificateEvent() to work with routes
+- [x] 2.7 Update applyExternalCertificate() to use route information
+- [x] 2.8 Update registerDomainsWithPort80Handler() to extract domains from routes
+- [x] 2.9 Update certificate request flow to track route references
+- [x] 2.10 Test NetworkProxyBridge with pure route configurations
+- [x] 2.11 Successfully build and run all tests
+
+### Phase 3: Remove Legacy Domain Configuration Code
+- [x] 3.1 Identify all imports of domain-config.ts and update them
+- [x] 3.2 Create route-based alternatives for any remaining domain-config usage
+- [x] 3.3 Delete domain-config.ts
+- [x] 3.4 Identify all imports of domain-manager.ts and update them
+- [x] 3.5 Delete domain-manager.ts
+- [x] 3.6 Update forwarding-types.ts (route-based only)
+- [x] 3.7 Add route-based domain support to Port80Handler
+- [x] 3.8 Create IPort80RouteOptions and extractPort80RoutesFromRoutes utility
+- [x] 3.9 Update SmartProxy.ts to use route-based domain management
+- [x] 3.10 Provide compatibility layer for domain-based interfaces
+- [x] 3.11 Update IDomainForwardConfig to IRouteForwardConfig
+- [x] 3.12 Update JSDoc comments to reference routes instead of domains
+- [x] 3.13 Run build to find any remaining type errors
+- [x] 3.14 Fix all type errors to ensure successful build
+- [x] 3.15 Update tests to use route-based approach instead of domain-based
+- [x] 3.16 Fix all failing tests
+- [x] 3.17 Verify build and test suite pass successfully
+
+### Phase 4: Enhance Route Helpers and Configuration Experience ✅
+- [x] 4.1 Create route-validators.ts with validation functions
+- [x] 4.2 Add validateRouteConfig() function for configuration validation
+- [x] 4.3 Add mergeRouteConfigs() utility function
+- [x] 4.4 Add findMatchingRoutes() helper function
+- [x] 4.5 Expand createStaticFileRoute() with more options
+- [x] 4.6 Add createApiRoute() helper for API gateway patterns
+- [x] 4.7 Add createAuthRoute() for authentication configurations
+- [x] 4.8 Add createWebSocketRoute() helper for WebSocket support
+- [x] 4.9 Create routePatterns.ts with common route patterns
+- [x] 4.10 Update utils/index.ts to export all helpers
+- [x] 4.11 Add schema validation for route configurations
+- [x] 4.12 Create utils for route pattern testing
+- [x] 4.13 Update docs with pure route-based examples
+- [x] 4.14 Remove any legacy code examples from documentation
+
+### Phase 5: Testing and Validation ✅
+- [x] 5.1 Update all tests to use pure route-based components
+- [x] 5.2 Create test cases for potential edge cases
+- [x] 5.3 Create a test for domain wildcard handling
+- [x] 5.4 Test all helper functions
+- [x] 5.5 Test certificate provisioning with routes
+- [x] 5.6 Test NetworkProxy integration with routes
+- [x] 5.7 Benchmark route matching performance
+- [x] 5.8 Compare memory usage before and after changes
+- [x] 5.9 Optimize route operations for large configurations
+- [x] 5.10 Verify public API matches documentation
+- [x] 5.11 Check for any backward compatibility issues
+- [x] 5.12 Ensure all examples in README work correctly
+- [x] 5.13 Run full test suite with new implementation
+- [x] 5.14 Create a final PR with all changes
+
+## Clean Break Approach
+
+To keep our codebase as clean as possible, we are taking a clean break approach with NO migration or compatibility support for domain-based configuration. We will:
+
+1. Completely remove all domain-based code
+2. Not provide any migration utilities in the codebase
+3. Focus solely on the route-based approach
+4. Document the route-based API as the only supported method
+
+This approach prioritizes codebase clarity over backward compatibility, which is appropriate since we've already made a clean break in the public API with v14.0.0.
+
+## File Changes
+
+### Files to Delete (Remove Completely)
+- [x] `/ts/forwarding/config/domain-config.ts` - Deleted with no replacement
+- [x] `/ts/forwarding/config/domain-manager.ts` - Deleted with no replacement
+- [x] `/ts/forwarding/config/forwarding-types.ts` - Updated with pure route-based types
+- [x] Any domain-config related tests have been updated to use route-based approach
+
+### Files to Modify (Remove All Domain References)
+- [x] `/ts/certificate/providers/cert-provisioner.ts` - Complete rewrite to use routes only ✅
+- [x] `/ts/proxies/smart-proxy/network-proxy-bridge.ts` - Direct route processing implementation ✅
+- [x] `/ts/certificate/models/certificate-types.ts` - Updated with route-based interfaces ✅
+- [x] `/ts/certificate/index.ts` - Cleaned up domain-related types and exports
+- [x] `/ts/http/port80/port80-handler.ts` - Updated to work exclusively with routes
+- [x] `/ts/proxies/smart-proxy/smart-proxy.ts` - Removed domain references
+- [x] `test/test.forwarding.ts` - Updated to use route-based approach
+- [x] `test/test.forwarding.unit.ts` - Updated to use route-based approach
+
+### New Files to Create (Route-Focused)
+- [x] `/ts/proxies/smart-proxy/utils/route-helpers.ts` - Created with helper functions for common route configurations
+- [x] `/ts/proxies/smart-proxy/utils/route-migration-utils.ts` - Added migration utilities from domains to routes
+- [x] `/ts/proxies/smart-proxy/utils/route-validators.ts` - Validation utilities for route configurations
+- [x] `/ts/proxies/smart-proxy/utils/route-utils.ts` - Additional route utility functions
+- [x] `/ts/proxies/smart-proxy/utils/route-patterns.ts` - Common route patterns for easy configuration
+- [x] `/ts/proxies/smart-proxy/utils/index.ts` - Central export point for all route utilities
+
+## Benefits of Complete Refactoring
+
+1. **Codebase Simplicity**:
+   - No dual implementation or conversion logic
+   - Simplified mental model for developers
+   - Easier to maintain and extend
+
+2. **Performance Improvements**:
+   - Remove conversion overhead
+   - More efficient route matching
+   - Reduced memory footprint
+
+3. **Better Developer Experience**:
+   - Consistent API throughout
+   - Cleaner documentation
+   - More intuitive configuration patterns
 
 4. **Future-Proof Design**:
-   - Easier to extend with new features
-   - Better performance without legacy overhead
-   - Cleaner foundation for future enhancements
-
-## Migration Support
-
-While we're removing backward compatibility from the codebase, we'll provide extensive migration support:
-
-1. **Migration Guide**:
-   - Detailed documentation on moving from legacy to route-based config
-   - Pattern-matching examples for all common use cases
-   - Troubleshooting guide for common migration issues
-
-2. **Conversion Tool**:
-   - Provide a standalone one-time conversion tool
-   - Takes legacy configuration and outputs route-based equivalents
-   - Will not be included in the main package to avoid bloat
-
-3. **Version Policy**:
-   - Maintain the legacy version (13.x) for security updates
-   - Make the route-based version a clear major version change (14.0.0)
-   - Clearly communicate the breaking changes
-
-## Timeline and Versioning
-
-1. **Development**:
-   - Develop route-based implementation in a separate branch
-   - Complete full test coverage of new implementation
-   - Ensure documentation is complete
-
-2. **Release**:
-   - Release as version 14.0.0
-   - Clearly mark as breaking change
-   - Provide migration guide at release time
-
-3. **Support**:
-   - Offer extended support for migration questions
-   - Consider maintaining security updates for v13.x for 6 months
-   - Focus active development on route-based version only
+   - Clear foundation for new features
+   - Easier to implement advanced routing capabilities
+   - Better integration with modern web patterns

package/ts/00_commitinfo_data.ts

@@ -3,6 +3,6 @@
  */
 export const commitinfo = {
   name: '@push.rocks/smartproxy',
-  version: '15.0.0',
+  version: '16.0.2',
   description: 'A powerful proxy package with unified route-based configuration for high traffic management. Features include SSL/TLS support, flexible routing patterns, WebSocket handling, advanced security options, and automatic ACME certificate management.'
 }

package/ts/certificate/index.ts

@@ -24,23 +24,31 @@ export * from './storage/file-storage.js';
 
 // Convenience function to create a certificate provisioner with common settings
 import { CertProvisioner } from './providers/cert-provisioner.js';
+import type { TCertProvisionObject } from './providers/cert-provisioner.js';
 import { buildPort80Handler } from './acme/acme-factory.js';
-import type { IAcmeOptions, IDomainForwardConfig } from './models/certificate-types.js';
-import type { IDomainConfig } from '../forwarding/config/domain-config.js';
+import type { IAcmeOptions, IRouteForwardConfig } from './models/certificate-types.js';
+import type { IRouteConfig } from '../proxies/smart-proxy/models/route-types.js';
+
+/**
+ * Interface for NetworkProxyBridge used by CertProvisioner
+ */
+interface ICertNetworkProxyBridge {
+  applyExternalCertificate(certData: any): void;
+}
 
 /**
  * Creates a complete certificate provisioning system with default settings
- * @param domainConfigs Domain configurations
+ * @param routeConfigs Route configurations that may need certificates
  * @param acmeOptions ACME options for certificate provisioning
  * @param networkProxyBridge Bridge to apply certificates to network proxy
  * @param certProvider Optional custom certificate provider
  * @returns Configured CertProvisioner
  */
 export function createCertificateProvisioner(
-  domainConfigs: IDomainConfig[],
+  routeConfigs: IRouteConfig[],
   acmeOptions: IAcmeOptions,
-  networkProxyBridge: any, // Placeholder until NetworkProxyBridge is migrated
-  certProvider?: any // Placeholder until cert provider type is properly defined
+  networkProxyBridge: ICertNetworkProxyBridge,
+  certProvider?: (domain: string) => Promise<TCertProvisionObject>
 ): CertProvisioner {
   // Build the Port80Handler for ACME challenges
   const port80Handler = buildPort80Handler(acmeOptions);
@@ -50,18 +58,18 @@ export function createCertificateProvisioner(
     renewThresholdDays = 30,
     renewCheckIntervalHours = 24,
     autoRenew = true,
-    domainForwards = []
+    routeForwards = []
   } = acmeOptions;
 
   // Create and return the certificate provisioner
   return new CertProvisioner(
-    domainConfigs,
+    routeConfigs,
     port80Handler,
     networkProxyBridge,
     certProvider,
     renewThresholdDays,
     renewCheckIntervalHours,
     autoRenew,
-    domainForwards
+    routeForwards
   );
 }

package/ts/certificate/models/certificate-types.ts

@@ -1,4 +1,5 @@
 import * as plugins from '../../plugins.js';
+import type { IRouteConfig } from '../../proxies/smart-proxy/models/route-types.js';
 
 /**
  * Certificate data structure containing all necessary information
@@ -12,6 +13,11 @@ export interface ICertificateData {
   // Optional source and renewal information for event emissions
   source?: 'static' | 'http01' | 'dns01';
   isRenewal?: boolean;
+  // Reference to the route that requested this certificate (if available)
+  routeReference?: {
+    routeId?: string;
+    routeName?: string;
+  };
 }
 
 /**
@@ -29,6 +35,10 @@ export interface ICertificateFailure {
   domain: string;
   error: string;
   isRenewal: boolean;
+  routeReference?: {
+    routeId?: string;
+    routeName?: string;
+  };
 }
 
 /**
@@ -38,35 +48,46 @@ export interface ICertificateExpiring {
   domain: string;
   expiryDate: Date;
   daysRemaining: number;
+  routeReference?: {
+    routeId?: string;
+    routeName?: string;
+  };
 }
 
 /**
- * Domain forwarding configuration
+ * Route-specific forwarding configuration for ACME challenges
  */
-export interface IForwardConfig {
-  ip: string;
-  port: number;
-}
-
-/**
- * Domain-specific forwarding configuration for ACME challenges
- */
-export interface IDomainForwardConfig {
+export interface IRouteForwardConfig {
   domain: string;
-  forwardConfig?: IForwardConfig;
-  acmeForwardConfig?: IForwardConfig;
+  target: {
+    host: string;
+    port: number;
+  };
   sslRedirect?: boolean;
 }
 
 /**
- * Domain configuration options
+ * Domain configuration options for Port80Handler
+ *
+ * This is used internally by the Port80Handler to manage domains
+ * but will eventually be replaced with route-based options.
  */
 export interface IDomainOptions {
   domainName: string;
   sslRedirect: boolean;   // if true redirects the request to port 443
   acmeMaintenance: boolean; // tries to always have a valid cert for this domain
-  forward?: IForwardConfig; // forwards all http requests to that target
-  acmeForward?: IForwardConfig; // forwards letsencrypt requests to this config
+  forward?: {
+    ip: string;
+    port: number;
+  }; // forwards all http requests to that target
+  acmeForward?: {
+    ip: string;
+    port: number;
+  }; // forwards letsencrypt requests to this config
+  routeReference?: {
+    routeId?: string;
+    routeName?: string;
+  };
 }
 
 /**
@@ -83,6 +104,6 @@ export interface IAcmeOptions {
   autoRenew?: boolean;            // Whether to automatically renew certificates
   certificateStore?: string;      // Directory to store certificates
   skipConfiguredCerts?: boolean;  // Skip domains with existing certificates
-  domainForwards?: IDomainForwardConfig[]; // Domain-specific forwarding configs
+  routeForwards?: IRouteForwardConfig[]; // Route-specific forwarding configs
 }