@scenarist/core 0.1.2 → 0.1.16

package/README.md

@@ -1,21 +1,23 @@
 # @scenarist/core
 
 > **Note:** This is an internal package. Users should install framework-specific adapters instead:
+>
 > - **Express:** `@scenarist/express-adapter`
 > - **Next.js:** `@scenarist/nextjs-adapter`
 > - **Playwright:** `@scenarist/playwright-helpers`
 >
 > All types are re-exported from adapters for convenience. See the [full documentation](https://scenarist.io) for usage guides.
 
-The core domain logic for Scenarist - a framework-agnostic library for managing MSW mock scenarios in E2E testing environments.
+The core domain logic for Scenarist - a framework-agnostic library for managing MSW mock scenarios for scenario-based testing where your real code runs.
 
 ## What is Scenarist?
 
-**Scenarist** enables concurrent E2E tests to run with different backend states by switching mock scenarios at runtime via test IDs. No application restarts needed, no complex per-test mocking, just simple scenario switching.
+**Scenarist** enables concurrent tests to run with different backend states by switching mock scenarios at runtime via test IDs. Your real application code executes while external API responses are controlled by scenarios. No application restarts needed, no complex per-test mocking, just simple scenario switching.
 
 **Problem it solves:**
 
 Testing multiple backend states (success, errors, loading, edge cases) traditionally requires:
+
 - Restarting your app for each scenario
 - Complex per-test MSW handler setup
 - Serial test execution to avoid conflicts
@@ -27,11 +29,14 @@ Define scenarios once, switch at runtime via HTTP calls, run tests in parallel w
 
 ```typescript
 // Define once
-const errorScenario = { id: 'error', mocks: [{ method: 'GET', url: '*/api/*', response: { status: 500 } }] };
+const errorScenario = {
+  id: "error",
+  mocks: [{ method: "GET", url: "*/api/*", response: { status: 500 } }],
+};
 
 // Switch instantly
-await switchScenario('test-1', 'error'); // Test 1 sees errors
-await switchScenario('test-2', 'success'); // Test 2 sees success (parallel!)
+await switchScenario("test-1", "error"); // Test 1 sees errors
+await switchScenario("test-2", "success"); // Test 2 sees success (parallel!)
 
 // Tests run concurrently with different backend states
 ```
@@ -39,26 +44,31 @@ await switchScenario('test-2', 'success'); // Test 2 sees success (parallel!)
 ## Why Use Scenarist?
 
 **Runtime Scenario Switching**
+
 - Change entire backend state with one API call
 - No server restarts between tests
 - Instant feedback during development
 
 **True Parallel Testing**
+
 - 100+ tests run concurrently with different scenarios
 - Each test ID has isolated scenario state
 - No conflicts between tests
 
 **Reusable Scenarios**
+
 - Define scenarios once, use across all tests
 - Version control your mock scenarios
 - Share scenarios across teams
 
 **Framework-Agnostic Core**
+
 - Zero framework dependencies
 - Works with Express, Next.js, and any Node.js framework
 - Hexagonal architecture enables custom adapters
 
 **Type-Safe & Tested**
+
 - TypeScript strict mode throughout
 - 100% test coverage
 - Immutable, declarative data structures
@@ -80,6 +90,7 @@ src/
 ### Hexagonal Architecture Principles
 
 **Types (Data Structures):**
+
 - Defined with `type` keyword
 - All properties are `readonly` for immutability
 - Use declarative patterns (no imperative functions, closures, or hidden logic)
@@ -87,37 +98,43 @@ src/
 - Examples: `ScenaristScenario`, `ScenaristConfig`, `ActiveScenario`, `ScenaristMock`
 
 **Ports (Behavior Contracts):**
+
 - Defined with `interface` keyword (domain ports) or `type` keyword (adapter contracts)
 - Contracts that adapters must implement
 - Domain ports: `ScenarioManager`, `ScenarioStore`, `RequestContext`
 - Adapter contract: `ScenaristAdapter<TMiddleware>`, `BaseAdapterOptions`
 
 **Domain (Implementations):**
+
 - Pure TypeScript functions and factory patterns
 - No framework dependencies
 - Implements the core business logic
 
 ## Core Capabilities
 
-Scenarist provides 20+ powerful features for E2E testing. All capabilities are framework-agnostic and available via any adapter (Express, Next.js, etc.).
+Scenarist provides 20+ powerful features for scenario-based testing. All capabilities are framework-agnostic and available via any adapter (Express, Next.js, etc.).
 
 ### Request Matching (11 capabilities)
 
 **1. Body matching (partial match)**
+
 - Match requests based on request body fields
 - Additional fields in request are ignored
 - Perfect for testing different payload scenarios
 
 **2. Header matching (case-insensitive)**
+
 - Match requests based on header values
 - Header names are case-insensitive
 - Ideal for user tier testing (`x-user-tier: premium`)
 
 **3. Query parameter matching**
+
 - Match requests based on query string parameters
 - Enables different responses for filtered requests
 
 **4. String matching (6 modes)**
+
 - **Plain string** (`"value"`): Exact match (backward compatible)
 - **Equals** (`{ equals: "value" }`): Explicit exact match
 - **Contains** (`{ contains: "substring" }`): Substring matching
@@ -126,15 +143,18 @@ Scenarist provides 20+ powerful features for E2E testing. All capabilities are f
 - **Regex** (`{ regex: { source: "pattern", flags: "i" } }`): Pattern matching with ReDoS protection
 
 **5. ReDoS protection for regex matching**
+
 - Validates regex patterns before execution using `redos-detector`
 - Prevents catastrophic backtracking attacks
 - Rejects unsafe patterns at scenario registration
 
 **6. Combined matching (all criteria together)**
+
 - Combine body + headers + query parameters
 - ALL criteria must pass for mock to apply
 
 **7. Specificity-based selection**
+
 - Most specific mock wins regardless of position
 - Calculated score: body fields + headers + query params
 - No need to carefully order your mocks
@@ -144,20 +164,24 @@ Scenarist provides 20+ powerful features for E2E testing. All capabilities are f
 - Last fallback wins enables active scenario fallbacks to override default fallbacks
 
 **8. Fallback mocks**
+
 - Mocks without match criteria act as catch-all
 - Specific mocks always take precedence
 - Perfect for default responses
 - When multiple fallbacks exist, last one wins (enables override pattern)
 
 **9. Number and boolean matching**
+
 - Automatically stringifies number/boolean criteria values
 - Enables matching against numeric query params and body fields
 
 **10. Null matching**
+
 - `null` criteria matches empty string (`""`)
 - Useful for optional fields
 
 **11. Type coercion**
+
 - All match values converted to strings before comparison
 - Consistent behavior across headers, query params, and body
 
@@ -185,11 +209,13 @@ Per [RFC 2616 Section 4.2](https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.htm
 ```
 
 **Implementation Details:**
+
 - Core's `ResponseSelector` normalizes both request headers AND criteria headers to lowercase
 - Adapters pass headers as-is (no normalization required)
 - Works regardless of framework (Express, Next.js, etc.)
 
 **Why This Matters:**
+
 - Browser and client libraries may send headers with any casing
 - Tests remain portable across different HTTP clients
 - Standards-compliant behavior prevents matching bugs
@@ -197,55 +223,67 @@ Per [RFC 2616 Section 4.2](https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.htm
 ### Response Sequences (4 capabilities)
 
 **7. Single responses**
+
 - Return same response every time
 - Simplest mock definition
 
 **8. Response sequences (ordered)**
+
 - Return different response on each call
 - Perfect for polling APIs (pending → processing → complete)
 
 **9. Repeat modes (last, cycle, none)**
+
 - `last`: Stay at final response forever
 - `cycle`: Loop back to first response
 - `none`: Mark as exhausted after last response
 
 **10. Sequence exhaustion with fallback**
+
 - Exhausted sequences (`repeat: none`) skip to next mock
 - Enables rate limiting scenarios
 
 ### Stateful Mocks (6 capabilities)
 
 **11. State capture from requests**
+
 - Extract values from request body, headers, or query
 - Store in per-test-ID state
 
 **12. State injection via templates**
+
 - Inject captured state into responses using `{{state.X}}`
 - Dynamic responses based on earlier requests
 
 **13. Array append support**
+
 - Syntax: `stateKey[]` appends to array
 - Perfect for shopping cart scenarios
 
 **14. Nested state paths**
+
 - Support dot notation: `user.profile.name`
 - Both capture and injection support nesting
 
 **15. State isolation per test ID**
+
 - Each test ID has isolated state
 - Parallel tests don't interfere
 
 **16. State reset on scenario switch**
+
 - State cleared when switching scenarios
 - Fresh state for each scenario
 
 ### Core Features (4 capabilities)
 
 **17. Multiple API mocking**
+
 - Mock any number of external APIs
 - Combine APIs in single scenario
 
 **18. Automatic default scenario fallback**
+
 - Active scenarios automatically inherit mocks from default scenario
 - Default + active scenario mocks collected together
 - Specificity-based selection chooses best match
@@ -253,10 +291,12 @@ Per [RFC 2616 Section 4.2](https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.htm
 - No explicit fallback mocks needed in specialized scenarios
 
 **19. Test ID isolation (parallel tests)**
+
 - Run 100+ tests concurrently
 - Each test ID has isolated scenario/state
 
 **20. Scenario switching at runtime**
+
 - Change backend state with one HTTP call
 - No application restart needed
 
@@ -313,17 +353,17 @@ import {
   InMemoryScenarioStore,
   buildConfig,
   type ScenaristScenario,
-} from '@scenarist/core';
+} from "@scenarist/core";
 
 // 1. Define scenarios (declarative patterns)
 const defaultScenario: ScenaristScenario = {
-  id: 'default',
-  name: 'Default Scenario',
-  description: 'Baseline mocks for all APIs',
+  id: "default",
+  name: "Default Scenario",
+  description: "Baseline mocks for all APIs",
   mocks: [
     {
-      method: 'GET',
-      url: 'https://api.example.com/users',
+      method: "GET",
+      url: "https://api.example.com/users",
       response: {
         status: 200,
         body: { users: [] },
@@ -333,17 +373,17 @@ const defaultScenario: ScenaristScenario = {
 };
 
 const happyPathScenario: ScenaristScenario = {
-  id: 'happy-path',
-  name: 'Happy Path',
-  description: 'All API calls succeed',
+  id: "happy-path",
+  name: "Happy Path",
+  description: "All API calls succeed",
   devToolEnabled: true,
   mocks: [
     {
-      method: 'GET',
-      url: 'https://api.example.com/users',
+      method: "GET",
+      url: "https://api.example.com/users",
       response: {
         status: 200,
-        body: { users: [{ id: 1, name: 'Test User' }] },
+        body: { users: [{ id: 1, name: "Test User" }] },
       },
     },
   ],
@@ -351,11 +391,11 @@ const happyPathScenario: ScenaristScenario = {
 
 // 2. Build configuration (declarative plain data)
 const config = buildConfig({
-  enabled: process.env.NODE_ENV !== 'production', // Evaluated first!
+  enabled: process.env.NODE_ENV !== "production", // Evaluated first!
   defaultScenario: defaultScenario, // REQUIRED - fallback for unmocked requests
-  strictMode: false,  // true = error on unmocked requests, false = passthrough
+  strictMode: false, // true = error on unmocked requests, false = passthrough
   headers: {
-    testId: 'x-scenarist-test-id',
+    testId: "x-scenarist-test-id",
   },
 });
 
@@ -371,10 +411,10 @@ manager.registerScenario(defaultScenario); // Must register default
 manager.registerScenario(happyPathScenario);
 
 // 6. Switch to a scenario
-const result = manager.switchScenario('test-123', 'happy-path');
+const result = manager.switchScenario("test-123", "happy-path");
 
 if (result.success) {
-  console.log('Scenario activated!');
+  console.log("Scenario activated!");
 }
 ```
 
@@ -384,15 +424,15 @@ Scenarist supports 5 matching strategies for headers, query params, and body fie
 
 ```typescript
 const scenario: ScenaristScenario = {
-  id: 'string-matching-examples',
+  id: "string-matching-examples",
   mocks: [
     // 1. Exact match (default)
     {
-      method: 'GET',
-      url: '/api/products',
+      method: "GET",
+      url: "/api/products",
       match: {
         headers: {
-          'x-user-tier': 'premium',  // Must match exactly
+          "x-user-tier": "premium", // Must match exactly
         },
       },
       response: { status: 200, body: { products: [] } },
@@ -400,11 +440,11 @@ const scenario: ScenaristScenario = {
 
     // 2. Explicit exact match (same as above)
     {
-      method: 'GET',
-      url: '/api/products',
+      method: "GET",
+      url: "/api/products",
       match: {
         headers: {
-          'x-user-tier': { equals: 'premium' },
+          "x-user-tier": { equals: "premium" },
         },
       },
       response: { status: 200, body: { products: [] } },
@@ -412,23 +452,23 @@ const scenario: ScenaristScenario = {
 
     // 3. Contains (substring match)
     {
-      method: 'GET',
-      url: '/api/products',
+      method: "GET",
+      url: "/api/products",
       match: {
         headers: {
-          'x-campaign': { contains: 'summer' },  // Matches 'summer-sale', 'mega-summer-event', etc.
+          "x-campaign": { contains: "summer" }, // Matches 'summer-sale', 'mega-summer-event', etc.
         },
       },
-      response: { status: 200, body: { campaign: 'summer' } },
+      response: { status: 200, body: { campaign: "summer" } },
     },
 
     // 4. Starts with (prefix match)
     {
-      method: 'GET',
-      url: '/api/keys',
+      method: "GET",
+      url: "/api/keys",
       match: {
         headers: {
-          'x-api-key': { startsWith: 'sk_' },  // Matches 'sk_test_123', 'sk_live_456', etc.
+          "x-api-key": { startsWith: "sk_" }, // Matches 'sk_test_123', 'sk_live_456', etc.
         },
       },
       response: { status: 200, body: { valid: true } },
@@ -436,11 +476,11 @@ const scenario: ScenaristScenario = {
 
     // 5. Ends with (suffix match)
     {
-      method: 'GET',
-      url: '/api/users',
+      method: "GET",
+      url: "/api/users",
       match: {
         query: {
-          email: { endsWith: '@company.com' },  // Matches 'john@company.com', 'admin@company.com', etc.
+          email: { endsWith: "@company.com" }, // Matches 'john@company.com', 'admin@company.com', etc.
         },
       },
       response: { status: 200, body: { users: [] } },
@@ -448,19 +488,19 @@ const scenario: ScenaristScenario = {
 
     // 6. Regex (pattern match with ReDoS protection)
     {
-      method: 'GET',
-      url: '/api/products',
+      method: "GET",
+      url: "/api/products",
       match: {
         headers: {
           referer: {
             regex: {
-              source: '/premium|/vip',  // Matches any referer containing '/premium' or '/vip'
-              flags: 'i',  // Case-insensitive
+              source: "/premium|/vip", // Matches any referer containing '/premium' or '/vip'
+              flags: "i", // Case-insensitive
             },
           },
         },
       },
-      response: { status: 200, body: { tier: 'premium' } },
+      response: { status: 200, body: { tier: "premium" } },
     },
   ],
 };
@@ -472,34 +512,34 @@ You can use native JavaScript RegExp objects directly instead of the serialized
 
 ```typescript
 const scenario: ScenaristScenario = {
-  id: 'native-regex-examples',
+  id: "native-regex-examples",
   mocks: [
     // Native RegExp in URL matching
     {
-      method: 'GET',
-      url: /\/api\/v\d+\/products/,  // Matches /api/v1/products, /api/v2/products, etc.
+      method: "GET",
+      url: /\/api\/v\d+\/products/, // Matches /api/v1/products, /api/v2/products, etc.
       response: { status: 200, body: { products: [] } },
     },
 
     // Native RegExp in header matching
     {
-      method: 'GET',
-      url: '/api/products',
+      method: "GET",
+      url: "/api/products",
       match: {
         headers: {
-          referer: /\/premium|\/vip/i,  // Case-insensitive pattern
+          referer: /\/premium|\/vip/i, // Case-insensitive pattern
         },
       },
-      response: { status: 200, body: { tier: 'premium' } },
+      response: { status: 200, body: { tier: "premium" } },
     },
 
     // Both forms are equivalent and have same ReDoS protection
     {
-      method: 'GET',
-      url: '/api/data',
+      method: "GET",
+      url: "/api/data",
       match: {
         query: {
-          filter: /^\w+$/,  // Native RegExp
+          filter: /^\w+$/, // Native RegExp
           // Same as: { regex: { source: '^\\w+$', flags: '' } }
         },
       },
@@ -516,9 +556,13 @@ const scenario: ScenaristScenario = {
 Scenarist supports three pattern types with different hostname matching behaviors:
 
 **1. Pathname-only patterns** (origin-agnostic)
+
 ```typescript
-{ url: '/api/users/:id' }
+{
+  url: "/api/users/:id";
+}
 ```
+
 - **Matches ANY hostname** - environment-agnostic
 - Best for mocks that should work across localhost, staging, production
 - Example: `/api/users/123` matches requests to:
@@ -527,9 +571,13 @@ Scenarist supports three pattern types with different hostname matching behavior
   - `https://api.production.com/api/users/123` ✅
 
 **2. Full URL patterns** (hostname-specific)
+
 ```typescript
-{ url: 'http://api.example.com/users/:id' }
+{
+  url: "http://api.example.com/users/:id";
+}
 ```
+
 - **Matches ONLY the specified hostname** - environment-specific
 - Best for mocks that should only apply to specific domains
 - Example: `http://api.example.com/users/:id` matches:
@@ -538,9 +586,13 @@ Scenarist supports three pattern types with different hostname matching behavior
   - `https://api.example.com/users/123` ❌ (different protocol)
 
 **3. Native RegExp patterns** (origin-agnostic)
+
 ```typescript
-{ url: /\/users\/\d+/ }
+{
+  url: /\/users\/\d+/;
+}
 ```
+
 - **Matches ANY hostname** - substring matching (MSW weak comparison)
 - Best for flexible pattern matching across environments
 - Example: `/\/users\/\d+/` matches:
@@ -555,30 +607,30 @@ Scenarist supports three pattern types with different hostname matching behavior
 const defaultScenario = {
   mocks: [
     {
-      url: '/api/products',  // Works in dev, staging, prod
-      response: { status: 200, body: { products: [] } }
-    }
-  ]
+      url: "/api/products", // Works in dev, staging, prod
+      response: { status: 200, body: { products: [] } },
+    },
+  ],
 };
 
 // ✅ Use full URL patterns when hostname matters
 const productionOnlyScenario = {
   mocks: [
     {
-      url: 'https://api.production.com/admin',  // Only matches production
-      response: { status: 403, body: { error: 'Admin disabled in prod' } }
-    }
-  ]
+      url: "https://api.production.com/admin", // Only matches production
+      response: { status: 403, body: { error: "Admin disabled in prod" } },
+    },
+  ],
 };
 
 // ✅ Use RegExp for flexible pattern matching
 const versionAgnosticScenario = {
   mocks: [
     {
-      url: /\/api\/v\d+\/users/,  // Matches /api/v1/users, /api/v2/users, etc.
-      response: { status: 200, body: { users: [] } }
-    }
-  ]
+      url: /\/api\/v\d+\/users/, // Matches /api/v1/users, /api/v2/users, etc.
+      response: { status: 200, body: { users: [] } },
+    },
+  ],
 };
 ```
 
@@ -590,36 +642,48 @@ Here are helpful regex patterns for common use cases:
 
 ```typescript
 // API versioning - match any version number
-{ url: /\/api\/v\d+\// }
+{
+  url: /\/api\/v\d+\//;
+}
 // Matches: /api/v1/, /api/v2/, /api/v10/, etc.
 
 // Numeric IDs only (reject non-numeric)
-{ url: /\/users\/\d+$/ }
+{
+  url: /\/users\/\d+$/;
+}
 // Matches: /users/123 ✅
 // Rejects: /users/abc ❌
 
 // File extensions
-{ url: /\.json$/ }
+{
+  url: /\.json$/;
+}
 // Matches: /data.json, /api/users.json ✅
 // Rejects: /data.xml, /users ❌
 
 // Optional trailing slash
-{ url: /\/products\/?$/ }
+{
+  url: /\/products\/?$/;
+}
 // Matches: /products ✅ and /products/ ✅
 
 // Multiple extensions
-{ url: /\.(jpg|png|gif)$/i }
+{
+  url: /\.(jpg|png|gif)$/i;
+}
 // Matches: image.jpg, photo.PNG, avatar.gif ✅
 
 // UUID format (simplified)
-{ url: /\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i }
+{
+  url: /\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
+}
 // Matches: /550e8400-e29b-41d4-a716-446655440000 ✅
 
 // Subdomain matching
 {
   match: {
     headers: {
-      host: /^(api|cdn)\.example\.com$/
+      host: /^(api|cdn)\.example\.com$/;
     }
   }
 }
@@ -634,15 +698,29 @@ Here are helpful regex patterns for common use cases:
 
 ```typescript
 // ❌ REJECTED - Catastrophic backtracking
-{ url: /(a+)+b/ }
+{
+  url: /(a+)+b/;
+}
 // Error: Unsafe regex pattern detected
 
 // ❌ REJECTED - Exponential time complexity
-{ match: { headers: { referer: { regex: { source: '(x+x+)+y' } } } } }
+{
+  match: {
+    headers: {
+      referer: {
+        regex: {
+          source: "(x+x+)+y";
+        }
+      }
+    }
+  }
+}
 // Error: Unsafe regex pattern detected
 
 // ✅ SAFE - Linear time complexity
-{ url: /\/api\/[^/]+\/users/ }
+{
+  url: /\/api\/[^/]+\/users/;
+}
 // Matches safely with bounded backtracking
 ```
 
@@ -667,7 +745,7 @@ All adapters must accept these base options:
 ```typescript
 type BaseAdapterOptions<T extends ScenaristScenarios> = {
   readonly enabled: boolean;
-  readonly scenarios: T;  // REQUIRED - scenarios object (must have 'default' key)
+  readonly scenarios: T; // REQUIRED - scenarios object (must have 'default' key)
   readonly strictMode?: boolean;
   readonly headers?: {
     readonly testId?: string;
@@ -690,14 +768,12 @@ Adapters can extend this with framework-specific options:
 
 ```typescript
 // Express adapter
-type ExpressAdapterOptions<T extends ScenaristScenarios> = BaseAdapterOptions<T> & {
-  // Add Express-specific options if needed
-};
+type ExpressAdapterOptions<T extends ScenaristScenarios> =
+  BaseAdapterOptions<T> & { // Add Express-specific options if needed };
 
 // Next.js adapter
-type NextJSAdapterOptions<T extends ScenaristScenarios> = BaseAdapterOptions<T> & {
-  // Add Next.js-specific options if needed
-};
+type NextJSAdapterOptions<T extends ScenaristScenarios> =
+  BaseAdapterOptions<T> & { // Add Next.js-specific options if needed };
 ```
 
 ### ScenaristAdapter<T, TMiddleware>
@@ -706,11 +782,17 @@ All adapters must return an object matching this contract:
 
 ```typescript
 type ScenaristAdapter<T extends ScenaristScenarios, TMiddleware = unknown> = {
-  readonly config: ScenaristConfig;  // Resolved configuration
-  readonly middleware?: TMiddleware;  // Framework-specific middleware (optional - Next.js doesn't have global middleware)
-  readonly switchScenario: (testId: string, scenarioId: ScenarioIds<T>, variant?: string) => ScenaristResult<void, Error>;
+  readonly config: ScenaristConfig; // Resolved configuration
+  readonly middleware?: TMiddleware; // Framework-specific middleware (optional - Next.js doesn't have global middleware)
+  readonly switchScenario: (
+    testId: string,
+    scenarioId: ScenarioIds<T>,
+    variant?: string,
+  ) => ScenaristResult<void, Error>;
   readonly getActiveScenario: (testId: string) => ActiveScenario | undefined;
-  readonly getScenarioById: (scenarioId: ScenarioIds<T>) => ScenaristScenario | undefined;
+  readonly getScenarioById: (
+    scenarioId: ScenarioIds<T>,
+  ) => ScenaristScenario | undefined;
   readonly listScenarios: () => ReadonlyArray<ScenaristScenario>;
   readonly clearScenario: (testId: string) => void;
   readonly start: () => void;
@@ -719,10 +801,12 @@ type ScenaristAdapter<T extends ScenaristScenarios, TMiddleware = unknown> = {
 ```
 
 The generic parameters:
+
 - `T extends ScenaristScenarios`: The scenarios object type for type-safe scenario IDs
 - `TMiddleware`: Framework-specific middleware type
 
 Examples:
+
 - Express: `ScenaristAdapter<typeof scenarios, Router>`
 - Next.js: `ScenaristAdapter<typeof scenarios, never>` (no global middleware)
 
@@ -731,7 +815,7 @@ Examples:
 ```typescript
 // Express adapter implementation
 export const createScenarist = <T extends ScenaristScenarios>(
-  options: ExpressAdapterOptions<T>
+  options: ExpressAdapterOptions<T>,
 ): ScenaristAdapter<T, Router> => {
   // Implementation automatically wires:
   // - MSW server with dynamic handler
@@ -747,8 +831,9 @@ export const createScenarist = <T extends ScenaristScenarios>(
 
   return {
     config: resolvedConfig,
-    middleware: router,  // Express Router
-    switchScenario: (id, scenario, variant) => manager.switchScenario(id, scenario, variant),
+    middleware: router, // Express Router
+    switchScenario: (id, scenario, variant) =>
+      manager.switchScenario(id, scenario, variant),
     // ... all other required methods
     start: () => server.listen(),
     stop: async () => server.close(),