@codeyam/codeyam-cli 0.1.0-staging.1 → 0.1.0-staging.1669d45

package/analyzer-template/packages/ai/src/lib/generateEntityScenarios.ts

@@ -5,11 +5,10 @@ import generateEntityScenariosGenerator from './promptGenerators/generateEntityS
 import {
   Analysis,
   Entity,
+  ExecutionFlow,
   PlaywrightInstruction,
-  ReadonlyAnalysisMap,
   Scenario,
 } from '~codeyam/types';
-// import findMatchingAttribute from './findMatchingAttribute';
 import { awsLog } from '~codeyam/utils';
 import { sanitizePlaywrightInstructions } from './validatePlaywrightInstructions';
 import { AI, DEFAULT_LARGER_MODEL, parseJsonSafe } from '~codeyam/ai';
@@ -18,31 +17,21 @@ export interface ScenarioResult {
   name: string;
   testName: string;
   description: string;
-  // New format: { dataStructurePath: { localVariable, instruction } }
-  // Old format (deprecated): { path: instruction_string }
-  keyAttributeInstructions: {
-    [key: string]:
-      | string
-      | {
-          localVariable: string;
-          instruction: string;
-        };
-  };
-  codeSnippet: string;
-  fix: string;
-  fixSnippet: string;
-  likelihood: number;
-  likelihoodDescription: string;
-  severity: number;
-  severityDescription: string;
-  dataMapping: { [key: string]: string };
+  /** IDs of execution flows this scenario covers */
+  coveredFlows: string[];
+  codeSnippet?: string;
+  fix?: string;
+  fixSnippet?: string;
+  likelihood?: number;
+  likelihoodDescription?: string;
+  severity?: number;
+  severityDescription?: string;
   playwrightInstructions?: PlaywrightInstruction[];
 }
 
 interface GenerateEntityScenariosArgs {
   entity: Pick<Entity, 'projectId' | 'filePath' | 'name' | 'code' | 'metadata'>;
-  keyAttributes: Analysis['metadata']['keyAttributes'];
-  dependentAnalyses?: ReadonlyAnalysisMap;
+  executionFlows?: ExecutionFlow[];
   analysis: Analysis;
   error?: boolean;
   model?: AI.Model;
@@ -52,7 +41,7 @@ const DEFAULT_SCENARIO_NAME = 'Default Scenario';
 
 export default async function generateEntityScenarios({
   entity,
-  keyAttributes,
+  executionFlows,
   analysis,
   error,
   model,
@@ -62,9 +51,33 @@ export default async function generateEntityScenarios({
     entityName: entity.name,
   });
 
+  // If no execution flows are available (and not generating error scenarios),
+  // return only the Default Scenario without calling LLM
+  if (!error && (!executionFlows || executionFlows.length === 0)) {
+    console.log(
+      `CodeYam: No execution flows available for ${entity.filePath} ${entity.name}, creating Default Scenario only`,
+    );
+    const defaultScenario: Scenario = {
+      projectId: entity.projectId,
+      analysisId: analysis.id,
+      name: DEFAULT_SCENARIO_NAME,
+      description: 'Default component rendering with standard data',
+      metadata: {
+        testName: 'it("renders the component with default data")',
+        error: false,
+        coveredFlows: [],
+        playwrightInstructions: [],
+      },
+    };
+    return {
+      scenarios: [defaultScenario],
+      llmCall: null,
+    };
+  }
+
   const prompt = generateEntityScenariosGenerator({
     entity,
-    keyAttributes,
+    executionFlows,
     error,
   });
 
@@ -93,14 +106,14 @@ export default async function generateEntityScenarios({
         filePath: entity.filePath,
         code: entity.code,
       },
-      keyAttributes,
+      executionFlows,
       analysis: {
         id: analysis.id,
         metadata: {
           isolatedDataStructure: {
             equivalentSignatureVariables:
               entity.metadata.isolatedDataStructure
-                .equivalentSignatureVariables,
+                ?.equivalentSignatureVariables,
           },
         },
       },
@@ -127,7 +140,7 @@ export default async function generateEntityScenarios({
   if (!result) {
     console.log(
       `CodeYam Error: Error Generating entity ${error ? 'error ' : ''}scenarios failed: Invalid JSON response from AI`,
-      response.finishReason,
+      JSON.stringify(response, null, 2),
     );
     throw new Error(
       `CodeYam Error: Error Generating entity ${error ? 'error ' : ''}scenarios failed: Invalid JSON response from AI`,
@@ -159,23 +172,7 @@ export default async function generateEntityScenarios({
           likelihoodDescription: scenarioInfo.likelihoodDescription,
           severity: scenarioInfo.severity,
           severityDescription: scenarioInfo.severityDescription,
-          dataMapping: scenarioInfo.dataMapping,
-          keyAttributeInstructions: scenarioInfo.keyAttributeInstructions,
-          // Object.keys(
-          //   scenarioInfo.keyAttributeInstructions,
-          // ).reduce((acc, key) => {
-          //   const attributesList = keyAttributes.map(
-          //     (attr) => attr.internalPath,
-          //   );
-          //   const matchingKey = findMatchingAttribute(
-          //     key,
-          //     attributesList,
-          //     entity.metadata.isolatedDataStructure
-          //       .equivalentSignatureVariables,
-          //   );
-          //   acc[matchingKey] = scenarioInfo.keyAttributeInstructions[key];
-          //   return acc;
-          // }, {}),
+          coveredFlows: scenarioInfo.coveredFlows || [],
           playwrightInstructions: sanitizePlaywrightInstructions(
             scenarioInfo.playwrightInstructions || [],
             entity.name,
@@ -195,316 +192,227 @@ function generateSystemMessage(
   context?: string,
   scenarioCount?: number,
 ): string {
-  return `We want to generate data scenarios that will demonstrate the behavior of a function.
-
-${
-  context
-    ? `## Business Logic Context
+  const scenarioCountText = scenarioCount
+    ? `Generate exactly ${scenarioCount} scenario${scenarioCount > 1 ? 's' : ''}.`
+    : 'Generate 3-6 scenarios MAXIMUM. Do NOT exceed 6 scenarios.';
 
+  const contextSection = context
+    ? `## Business Context
 ${context}
 
-Focus your scenarios on demonstrating this specific change. Generate scenarios with the data conditions needed to reveal this new behavior.
+Focus scenarios on demonstrating this specific behavior change.
 
 `
-    : ''
-}
+    : '';
 
-${scenarioCount ? `Generate ${scenarioCount} scenario${scenarioCount > 1 ? 's' : ''}.` : 'Generate a few (between one and four) scenarios.'}
+  return `You are a test scenario designer. Generate data scenarios that demonstrate a function's behavior by covering its execution flows.
 
-## The ${DEFAULT_SCENARIO_NAME}:
+${contextSection}${scenarioCountText}
 
-- Start with the "${DEFAULT_SCENARIO_NAME}" - Call this exactly that, "${DEFAULT_SCENARIO_NAME}" and just that (case sensitive, no other text).
-- The "${DEFAULT_SCENARIO_NAME}" should provide a robust demonstration of the function with instructions for all key attributes provided. 
-  - Fill in all key attributes in the "keyAttributes" list with valid values from the "validValueOptions" list.
-  - All values provided must be from the "validValueOptions" list in the "keyAttributes" list. Do not make up values that are not in the "validValueOptions" list.
-  - Ignore any error attributes (e.g. an attribute called "error"). These should not be included or set to null.
-  - If a front-end (visual) function accepts "children" as an argument this must be populated with a valid value or the output may be blank.
-  - Do not include any "playwrightInstructions" in the "${DEFAULT_SCENARIO_NAME}" as we want a screenshot of the function before any user interactions take place.
+## Your Primary Goal: Cover ALL Execution Flows EFFICIENTLY
 
-## Other scenarios:
+You are given \`executionFlows\` - all the distinct outcomes/behaviors this component can produce. Each flow has:
+- \`id\`: Unique identifier
+- \`name\`: Human-readable name (e.g., "Modal visible", "Loading state")
+- \`description\`: What the user sees or what behavior occurs
+- \`requiredValues\`: Attribute values needed to produce this outcome
+- \`impact\`: Visual/behavioral importance ("high", "medium", "low")
+- \`blocksOtherFlows\`: If true, this outcome hides other content (modals, overlays)
+- \`isError\`: If true, this represents an error/exception scenario
+- \`exclusiveGroup\`: If set, flows with the same group are MUTUALLY EXCLUSIVE (only one can be active)
 
-- Other scenarios should produce distinct output (for a front-end (visual) function this means a visually distinct screenshot, for back-end this means a distinct return value or side effect). Focus on varying the key attributes to create distinctly different outputs.
-- You do not need to specify key attributes that are the same as the ${DEFAULT_SCENARIO_NAME}.
-- Again ignore any error attributes. These should not be included or set to null.
-- If the function is a front-end (visual) function that accepts user actions and will change it's appearance based on those user actions, then create a non-default scenario that includes "playwrightInstructions" to trigger those user actions.
+**Your job**: Create the MINIMUM number of scenarios that cover ALL execution flows.
 
-## Instructions
+## CRITICAL: Understanding Exclusive Groups
 
-- Each scenario should have: 
-  - a unique name (should be short and concise with absolutely no special characters other than spaces).
-  - a "testName" written in the style of Jest the focuses on specific expectations for the test. Try to avoid generic names like "it('should work')" or "it('should render')" and describe more specific expectations.
-  - a description that describes why the key attributes were changed from the default scenario.
-  - "keyAttributeInstructions" specifying how the key attributes should be set. All key attributes should be set with valid values from the "validValueOptions" list in the "keyAttributes" list.
-  - Optional "playwrightInstructions" that provide the necessary code to run in Playwright to put the function into the correct state to demonstrate the scenario.
-- Focus on positive scenarios that showcase the intended behavior of this function. We have another prompt for generating error scenarios. These scenarios should focus on robust but different data between scenarios that vary key attributes to demonstrate different aspects of the function's behavior.
+Flows with the same \`exclusiveGroup\` are MUTUALLY EXCLUSIVE - only ONE can be active at a time.
 
-## Dependencies
+**Example exclusive groups:**
+- \`"status-badge"\`: loading, success, error, pending - only ONE badge shows
+- \`"active-tab"\`: users, settings, profile - only ONE tab is visible
+- \`"modal"\`: settings-modal, confirm-modal - only ONE modal at a time
 
-This function may dependend on other functions that have key attributes as well. You can leverage those to generate data scenarios also by creating key attribute instructions for those key attributes in the same manner. Generally speaking key attributes for dependencies are necessary for robust scenarios.
+5. **Maximize visual diversity**: For attributes that control what content is displayed (rather than just styling), vary values across scenarios so screenshots show meaningfully different views:
+   - Don't use the same display-controlling value in every scenario
+   - Ensure at least one scenario shows the primary content view
+   - Other scenarios can demonstrate alternative display states
 
-## Relative Dates
+**Key insight**: You don't need a separate scenario for each flow in an exclusive group!
+- Pick the PRIMARY/DEFAULT option for the Default Scenario
+- Only create additional scenarios for IMPORTANT alternative states (e.g., error states, loading states)
+- Skip scenarios for minor variations within a group
 
-If a relative date is required you can describe it in the "keyAttributeInstructions", e.g. 'today', 'tomorrow', 'next week', 'last month'.
+## Scenario Strategy
 
-## Rules
+### 1. Default Scenario (REQUIRED - must be first, named exactly "${DEFAULT_SCENARIO_NAME}")
+- For each exclusive group, pick the PRIMARY/HAPPY-PATH option:
+  - Status: "success" or "ready" (not loading, not error)
+  - Tabs: The main/first tab
+  - View modes: The default view
+- Combine as many NON-BLOCKING, NON-ERROR, NON-EXCLUSIVE-CONFLICT flows as possible
+- AVOID flows with \`blocksOtherFlows: true\`
+- NEVER include \`playwrightInstructions\`
 
-- If the key attributes require react elements, keep them simple (e.g. <div> or <span>). Do not reference custom jsx elements as they will not exist.
+### 2. Blocking Flow Scenarios (ONE per blocking flow)
+Each flow with \`blocksOtherFlows: true\` gets its OWN scenario.
+- Modals, overlays, drawers hide other content
+- Don't combine blocking flows
 
-- Do not reference any external libraries, such as React, in the "keyAttributeInstructions". Assume no external libraries are available. Do not reference custom jsx elements. 
+### 3. Important Alternative States (SELECTIVE)
+Only create scenarios for IMPORTANT alternatives within exclusive groups:
+- ✅ Loading state (if exists) - important UX state
+- ✅ Error state (if exists) - important UX state
+- ✅ Empty state (if exists) - important UX state
+- ❌ Each individual tab - NOT needed (tabs are just navigation)
+- ❌ Each status badge variant - just pick the important ones
 
-## Response Structure
+### 4. CRITICAL: Skip Low-Value Scenarios
+Do NOT create separate scenarios for:
+- **Different tabs** - Tabs are just navigation. The Default Scenario covers the main tab. SKIP others.
+- **Status badge variants** - Only need: Default (success/ready) + Loading + Error. SKIP queued, pending, etc.
+- **Banner variants** - Pick ONE important banner if any. SKIP creating a scenario for each banner type.
+- **Minor variations** - If two flows show essentially the same UI with small differences, combine them or skip one.
 
-Respond with the data scenarios in a JSON object format, without additional information or delimiters. Ensure clarity and specificity in each data scenario to facilitate accurate data generation for testing or demonstration purposes.
+**Remember**: Including a flow in the Default Scenario COUNTS as covering it. You don't need a dedicated scenario for each flow.
 
-IMPORTANT: For keyAttributeInstructions, use the "dataStructurePath" from the Key Attributes as the key (e.g., "useDiffModal().diffView"), and include both the "localVariable" name and the "instruction" in the value object:
-
-{
-  "dataScenarios": [
-    {
-      "name": string;
-      "testName": string;
-      "description": string;
-      "keyAttributeInstructions": {
-        ["dataStructurePath"]: {
-          "localVariable": string;  // The local variable name (e.g., "diffView")
-          "instruction": string;    // How to set this attribute for the scenario
-        }
-      },
-      "playwrightInstructions?": {
-        "selectorFn": string;
-        "selectorArgs": string[];
-        "actionFn": string;
-        "actionArgs": string[];
-      }[]
-    }
-  ]
-}
+## Combining Flows
 
-Optionally you can include playwright instructions for front-end functions to put the function into the correct state to demonstrate the scenario.
+Flows can combine if:
+1. They have DIFFERENT \`exclusiveGroup\` values (or no exclusiveGroup)
+2. Their \`requiredValues\` don't conflict on the same attribute
 
-Usually playwright instructions should not be included in the ${DEFAULT_SCENARIO_NAME}. If playwright instructions will cause the front-end function's results to look different than create a non-default scenario that includes those instructions.
+Flows CANNOT combine if:
+1. They have the SAME \`exclusiveGroup\` - they're mutually exclusive
+2. Their \`requiredValues\` conflict (same attribute, different required value)
 
-This is often the case if the key attributes are only used through a button click or form submission or if the data required for this scenario is not listed as a key attribute and must be provided directly by the user.
+When combining flows, the scenario's mock data must satisfy ALL the requiredValues from ALL covered flows.
 
-If the data won't exist or be used without user actions then use the "playwrightInstructions" to trigger execution of that code through the user actions.
+## Output Format
 
-For \`playwrightInstructions\`, provide an array of strings representing the necessary code to run.
 \`\`\`json
 {
-  "playwrightInstructions": [
+  "dataScenarios": [
     {
-      "selectorFn": "getByLabel",
-      "selectorArgs": ["email"],
-      "actionFn": "fill",
-      "actionArgs": ["test@example.com"]
+      "name": "${DEFAULT_SCENARIO_NAME}",
+      "testName": "it(\\"displays primary content with all features visible\\")",
+      "description": "Main content view: success status, main tab selected, user logged in",
+      "coveredFlows": ["status-success", "tab-main", "user-authenticated", "content-loaded"]
     },
     {
-      "selectorFn": "getByText",
-      "selectorArgs": ["Submit"],
-      "actionFn": "click",
-      "actionArgs": []
-    }
-  ]
-}
-\`\`\`
-
-## Example Response
-
-\`\`\`json
-{
-  "dataScenarios": [
-    {
-      "name": ${DEFAULT_SCENARIO_NAME},
-      "description": "The component displays notifications. As a default state demonstrates common usage, there are 3 unread notifications and two read notifications.",
-      "testName": "it(\"displays notifications indicating unread status with a green dot\")",
-      "keyAttributeInstructions": {
-        "useNotifications().notifications[]": {
-          "localVariable": "notifications[]",
-          "instruction": "Create 5 notifications"
-        },
-        "useNotifications().notifications[].read": {
-          "localVariable": "notifications[].read",
-          "instruction": "Set to false for 3 notifications and true for 2 notifications"
-        },
-        "useNotifications().notifications[].message": {
-          "localVariable": "notifications[].message",
-          "instruction": "Messages should be no longer than 200 characters"
-        }
-      }
+      "name": "Loading State",
+      "testName": "it(\\"shows loading spinner while fetching data\\")",
+      "description": "Data is being loaded, loading badge visible",
+      "coveredFlows": ["status-loading", "tab-main"]
     },
     {
-      "name": "No notifications",
-      "testName": "it(\"renders a default message when there are no notifications\")",
-      "description": "A user has no notifications at all.",
-      "keyAttributeInstructions": {
-        "useNotifications().notifications[]": {
-          "localVariable": "notifications[]",
-          "instruction": "Should be an empty array"
-        }
-      }
+      "name": "Empty State",
+      "testName": "it(\\"shows empty message when no items\\")",
+      "description": "No items to display, empty state UI shown",
+      "coveredFlows": ["status-success", "tab-main", "empty-list"]
     },
     {
-      "name": "Many notifications, all unread, one long message",
-      "testName": "it(\"properly truncates long messages with the title containing the full message\")",
-      "description": "A user has many notifications, all unread, with one notification featuring a long message.",
-      "keyAttributeInstructions": {
-        "useNotifications().notifications[]": {
-          "localVariable": "notifications[]",
-          "instruction": "Create 10 notifications"
-        },
-        "useNotifications().notifications[].read": {
-          "localVariable": "notifications[].read",
-          "instruction": "Set to false for all notifications"
-        },
-        "useNotifications().notifications[].message": {
-          "localVariable": "notifications[].message",
-          "instruction": "Ensure at least one message is longer than 500 characters"
-        }
-      }
+      "name": "Settings Modal",
+      "testName": "it(\\"displays settings modal overlay\\")",
+      "description": "Settings modal is open and visible",
+      "coveredFlows": ["modal-settings"]
     }
   ]
 }
 \`\`\`
 
-Remember:
-
-- Name the first scenario exactly "${DEFAULT_SCENARIO_NAME}".
-- For the ${DEFAULT_SCENARIO_NAME} scenario fill in all key attributes with valid values from the "validValueOptions" list in the "keyAttributes" list. Do not leave any key attributes out of the "keyAttributeInstructions" unless they are error attributes.
-- For other scenarios, find ways to create distinctly different outputs using other valid values for key attributes or providing playwright instructions to trigger user interactions.
-- Do not use any special characters in the scenario names. Keep them short and concise and only use letters, numbers, and spaces.
-- Do not use playwright instructions in the ${DEFAULT_SCENARIO_NAME} as we want a screenshot of the function before any user interactions.
-`;
-}
-
-const SYSTEM_MESSAGE = generateSystemMessage();
-
-const ERROR_SYSTEM_MESSAGE = `What data will cause this funtion to fail with an uncaught error?
-
-In "errorDataScenarios", give each scenario a description that explains what the predicted error is, a code snippet (or multiple) showing where it will occur, a description of how it can be fixed along with example code, and provide detailed "keyAttributeInstructions" on how to generate the necessary data to cause the error.
-
-For each error scenario also provide two evaluation dynamics:
-
-1) How likely is this error to occur? (1-10)
-- 1 = Unlikely. It would require passing in data that is clearly wrong and not suited for the function.
-- 10 = Guaranteed. There is a bug in the function that will happen regardless of the data passed in.
-
-2) How severe is the error? (1 or 2)
-- 1 = Minor. The error will not break the application. It may cause confusion or unexpected behavior, but will not cause a direct failure.
-- 2 = Major. The error will cause the function to fail and will need to be fixed.
-
-## Instructions
+**Note:** This example has ~20 flows but only 4 scenarios because:
+- Exclusive groups (status, tabs) only need ONE representative in Default Scenario
+- We don't create scenarios for every tab - they're just navigation
+- Only important states (loading, empty, modal) get dedicated scenarios
 
-Another AI will then read the "keyAttributeInstructions" and generate the necessary data. You can assume the other AI will generate reasonable default data to satisfy the data structure, so only provide instructions for the essential parts of the data that should be generated.
+## Field Descriptions
 
-We can only generate data for the exact data structure provided, regardless of the code for the function. Do not provide "keyAttributeInstructions" for data that is not in the data structure.
+- **name**: Human-readable scenario name (letters, numbers, spaces only - no special characters)
+- **testName**: Jest-style test description, e.g. \`it("displays error when email invalid")\`
+- **description**: What the user sees or what behavior occurs in this scenario
+- **coveredFlows**: Array of execution flow IDs this scenario covers (from the executionFlows list)
+- **playwrightInstructions**: (optional) User interactions needed to reach this state
 
-All data must be plain that can be run in a node environment (not in the browser). Do not reference any external libraries in the "keyAttributeInstructions". If an external library is required by the function, then provide instructructions on how to fake or mock that data. 
+## playwrightInstructions Format (when needed)
 
-Focus on "Major" errors. Only include "Minor" errors is they are very likely to occur.
-
-## Response
-
-For each error scenario, start with a data mapping between the phrase you want to use in the "keyAttributeInstructions" and the exact variable in the data strucure. Then provide a name and a description that predicts how the function will error out and a suggested way to fix the error. The name should be unique and short (no more than 30 characters), and the description should provide context for the error scenario.
+\`\`\`json
+{
+  "playwrightInstructions": [
+    { "selectorFn": "getByLabel", "selectorArgs": ["Email"], "actionFn": "fill", "actionArgs": ["test@example.com"] },
+    { "selectorFn": "getByRole", "selectorArgs": ["button", { "name": "Submit" }], "actionFn": "click", "actionArgs": [] }
+  ]
+}
+\`\`\`
+Note: selectorArgs values must be JSON strings, not JavaScript regex literals.
 
 ## Rules
 
-- Do not provide "keyAttributeInstructions" for data that is not in the data structure. 
-
-- If the data structure calls for react elements, keep them simple (e.g. <div> or <span>). Do not reference custom jsx elements as they will not exist.
-
-- Do not reference any external libraries, such as React, in the "keyAttributeInstructions". Assume no external libraries are available. Do not reference custom jsx elements. If needed describe how to mock the enternal library data using plain javascript that can be run in a node environment.
-
-- Only create new error scenarios if the scenario will literally cause an error. We are not looking for awkward or unintended results, only literal errors. Do not create an error scenario if you are not confident it will cause an error. 
-
-- Do not assume that another function might cause an error. We are looking for errors that are a direct result of the code in this function.
-
-- Do not create errors that can be caught through normal type detection. We only want errors that are reasonably likely to happen and won't be caught by basic static code analysis.
-
-- Only create error scenarios that can be fixed by changing the code in this function. Do not create error scenarios that require changes to other functions or external libraries. 
-
-- Look to create a few error scenarios, but if you can not identify any way to cause an error then do not generate any error scenarios. Each error scenario should represent a distinctly different way to cause an error. If there are no errors you can respond with:
-
-\`\`\`
-{
-  "errorDataScenarios": "No errors found"
+1. **HARD LIMIT: 3-6 scenarios only** - If you generate more than 6 scenarios, you're doing it wrong. Aim for the minimum that covers important states.
+2. **${DEFAULT_SCENARIO_NAME}** must be first and named exactly that (case-sensitive)
+3. **Exclusive groups**: Pick ONE flow per group for Default Scenario. DON'T create scenarios for each option.
+4. **Blocking flows** (blocksOtherFlows: true) get dedicated scenarios
+5. **Only 2-3 additional scenarios**: Loading State, Empty State, maybe one Error or Modal
+6. **DO NOT cover every flow** - Many flows are fine being represented only in the Default Scenario
+7. Scenario names: letters, numbers, spaces only (no special characters)
+8. All values must be valid JSON
+
+**Example for a component with 27 flows:**
+- Default Scenario (covers 10+ flows including: success status, main tab, content loaded, etc.)
+- Loading State (covers loading flow)
+- Empty State (covers empty flow)
+- Modal Open (if there's an important modal)
+- Error State (if there's a critical error state)
+= 4-5 scenarios total, NOT 27
+`;
 }
-\`\`\`
 
-- Make sure each error scenario has a unique name.
+const ERROR_SYSTEM_MESSAGE = `You are a security/reliability analyst. Identify data inputs that will cause UNCAUGHT ERRORS in this function.
 
-## Response Structure
+## What Qualifies as an Error Scenario
+- MUST cause an actual thrown error (not awkward behavior)
+- MUST be fixable by changing THIS function's code
+- MUST NOT rely on type errors caught by static analysis
+- MUST NOT assume dependent functions will fail
 
-Respond with the data scenarios in a JSON object format, without additional information or delimiters. Ensure clarity and specificity in each data scenario to facilitate accurate data generation for testing or demonstration purposes.
+## Likelihood Scale (1-10)
+- 1-3: Requires clearly wrong/unusual data
+- 4-6: Plausible edge case
+- 7-9: Common real-world scenario
+- 10: ONLY if guaranteed bug regardless of input
 
-{
-  "errorDataScenarios": [
-    {
-      "dataMapping": { [key: string]: string };
-      "name": string;
-      "codeSnippet": string;
-      "description": string;
-      "fix": string;
-      "fixSnippet": string;
-      "likelihood": number;
-      "likelihoodDescription": string;
-      "severity": number;
-      "severityDescription": string;      
-      "instructions": string[];
-    }
-  ]
-}
+Be conservative with high scores—they should surface truly likely errors.
 
-## Example
-Given the following data structure:
+## Severity Scale (1-2)
+- 1 = Minor: Unexpected behavior, no crash
+- 2 = Major: Function fails completely (focus here)
 
-\`\`\`
-{
-  "arguments": [
-    {
-      "notifications": {
-        "message": "string",
-        "read": "boolean"
-      }[]
-    }
-  ]
-}
-\`\`\`
+## Rules
+- Only reference data in the provided data structure
+- React elements: simple only (\`<div>\`, \`<span>\`)
+- No external library references—mock with plain JS
+- Each scenario must cause a DISTINCT error type
+- If no errors possible: \`{ "errorDataScenarios": "No errors found" }\`
 
-The full response might be:
+Note: In JS/TS, any non-zero value satisfies a boolean check—this won't error.
 
-\`\`\`
+## Response Format
+\`\`\`json
 {
   "errorDataScenarios": [
     {
-      "dataMapping": {
-        "notifications array": "arguments - notifications"
-      },
-      "name": "Error: Message with non-utf8 characters",
-      "codeSnippet": "...\nconst encodedMessage = encodeURIComponent(message);\n...",
-      "description": "If the message contains non-utf8 characters the function will error out. The \`encodeURIComponent\` call will throw an error which is not caught.",
-      "fix": "Wrap the \`encodeURIComponent\` call in a try/catch block.",
-      "fixSnippet: "...\nlet encodedMessage: string | undefined;\ntry {\n  encodedMessage = encodeURIComponent(message)\n} catch (e) {\n  console.error('Error encoding message:', e)\n..."
+      "name": "Non-utf8 message encoding",
+      "testName": "it(\\"throws on non-utf8 characters\\")",
+      "description": "encodeURIComponent throws on non-utf8 characters",
+      "codeSnippet": "const encoded = encodeURIComponent(message);",
+      "fix": "Wrap in try/catch",
+      "fixSnippet": "try {\\n  encoded = encodeURIComponent(message);\\n} catch (e) {\\n  // handle\\n}",
       "likelihood": 7,
-      "likelihoodDescription": "The international nature of the function makes it likely that a user will input a message with non-utf8 characters.",
+      "likelihoodDescription": "International users may input non-utf8 characters",
       "severity": 2,
-      "severityDescription": "The function will error out if a message contains non-utf8 characters.",
-      "keyAttributeInstructions": {
-        "notifications[]": "Set the \"notifications array\" to an array of objects containing at least one notification with a message that contains non-utf8 characters.",
-      }
+      "severityDescription": "Function throws uncaught error",
+      "coveredFlows": []
     }
   ]
 }
 \`\`\`
-
-Please write both the \`codeSnippet\` and \`fixSnippet\` with appropriate line breaks to increase readability.
-
-Assume that all functions this function depends on exist even if they are not provided in the prompt. We have isolated this function for analysis but those dependencies do exist.
-
-Only create error scenarios based on the code that is in the function provided.
-
-Common Errors In Your Analysis:
-- Typescript/javascript: 
-    - Any object or primitive other than 0 can be used to satisfy a boolean. This will not cause an error.
-
-Do not mark anything as a "10" for likelihood unless the error will literally happen every time the function is called. In general be cautious about high likelihood scores so that errors that are truly most likely to happen show up as higher priority.
 `;