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

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

@@ -5,21 +5,19 @@ import generateChangesEntityScenariosGenerator from './promptGenerators/generate
 import {
   Analysis,
   Entity,
+  ExecutionFlow,
   ReadonlyAnalysisMap,
   Scenario,
 } from '~codeyam/types';
 import { ScenarioResult } from './generateEntityScenarios';
-import findMatchingAttribute from './findMatchingAttribute';
 import { awsLog } from '~codeyam/utils';
 import { sanitizePlaywrightInstructions } from './validatePlaywrightInstructions';
-import gatherRelevantDependentKeyAttributes from './gatherRelevantDependentKeyAttributes';
 import { AI, DEFAULT_LARGER_MODEL, parseJsonSafe } from '~codeyam/ai';
 
 interface GenerateChangesEntityScenariosArgs {
   entity: Entity;
-  keyAttributes: Analysis['metadata']['keyAttributes'];
-  addedKeyAttributes: Analysis['metadata']['keyAttributes'];
-  removedKeyAttributes: Analysis['metadata']['keyAttributes'];
+  executionFlows?: ExecutionFlow[];
+  previousExecutionFlows?: ExecutionFlow[];
   dependentAnalyses?: ReadonlyAnalysisMap;
   existingScenarios: Scenario[];
   commitDiff: string;
@@ -33,10 +31,8 @@ const DEFAULT_SCENARIO_NAME = 'Default Scenario';
 
 export default async function generateChangesEntityScenarios({
   entity,
-  keyAttributes,
-  addedKeyAttributes,
-  removedKeyAttributes,
-  dependentAnalyses,
+  executionFlows,
+  previousExecutionFlows,
   existingScenarios,
   commitDiff,
   analysis,
@@ -44,15 +40,22 @@ export default async function generateChangesEntityScenarios({
   model,
   changedDataStructureFields = [],
 }: GenerateChangesEntityScenariosArgs) {
-  const relevantDependentKeyAttributes = gatherRelevantDependentKeyAttributes(
-    entity,
-    dependentAnalyses,
+  // Determine added/removed flows
+  const currentFlowIds = new Set((executionFlows ?? []).map((f) => f.id));
+  const previousFlowIds = new Set(
+    (previousExecutionFlows ?? []).map((f) => f.id),
   );
+
+  const addedFlows =
+    executionFlows?.filter((f) => !previousFlowIds.has(f.id)) ?? [];
+  const removedFlows =
+    previousExecutionFlows?.filter((f) => !currentFlowIds.has(f.id)) ?? [];
+
+  // If no changes, return existing scenarios
   if (
-    (!addedKeyAttributes || addedKeyAttributes.length === 0) &&
-    (!removedKeyAttributes || removedKeyAttributes.length === 0) &&
-    !existingScenarios.some((s) => s.metadata?.playwrightInstructions) &&
-    Object.keys(relevantDependentKeyAttributes).length === 0
+    addedFlows.length === 0 &&
+    removedFlows.length === 0 &&
+    !existingScenarios.some((s) => s.metadata?.playwrightInstructions)
   ) {
     return { scenarios: existingScenarios };
   }
@@ -61,20 +64,20 @@ export default async function generateChangesEntityScenarios({
     `CodeYam: Generating ${error ? 'error ' : ''}changes entity scenarios`,
     {
       filePath: entity.filePath,
-      entityNam: entity.name,
-      analysis: analysis.id,
-      keyAttributes: keyAttributes.map((a) => a.externalPath),
-      addedKeyAttributes: addedKeyAttributes?.map((a) => a.externalPath),
-      removedKeyAttributes: removedKeyAttributes?.map((a) => a.externalPath),
+      entityName: entity.name,
+      analysisId: analysis.id,
+      currentFlowCount: executionFlows?.length ?? 0,
+      addedFlows: addedFlows.map((f) => f.id),
+      removedFlows: removedFlows.map((f) => f.id),
     },
   );
 
   const prompt = generateChangesEntityScenariosGenerator({
     entity,
-    keyAttributes,
-    addedKeyAttributes,
-    removedKeyAttributes,
-    dependentAnalyses,
+    mergedDataStructure: analysis.metadata.mergedDataStructure,
+    executionFlows,
+    addedFlows,
+    removedFlows,
     existingScenarios,
     commitDiff,
     error,
@@ -91,7 +94,7 @@ export default async function generateChangesEntityScenarios({
     type: `generate${error ? 'Error' : ''}ChangesEntityScenarios`,
     systemMessage: error
       ? ERROR_SYSTEM_MESSAGE
-      : generateChangesSystemMessage(context, scenarioCount, false),
+      : generateChangesSystemMessage(context, scenarioCount),
     prompt,
     model: model ?? DEFAULT_LARGER_MODEL,
   });
@@ -109,32 +112,17 @@ export default async function generateChangesEntityScenarios({
           path: entity.file.path,
         },
       },
-      keyAttributes,
-      addedKeyAttributes,
-      removedKeyAttributes,
-      dependentAnalyses: Object.fromEntries(
-        Object.entries(dependentAnalyses ?? {}).map(([path, analyses]) => [
-          path,
-          Object.fromEntries(
-            Object.entries(analyses).map(([name, analysis]) => [
-              name,
-              {
-                metadata: {
-                  keyAttributes: analysis.metadata?.keyAttributes,
-                },
-              },
-            ]),
-          ),
-        ]),
-      ),
+      executionFlows,
+      addedFlows,
+      removedFlows,
       existingScenarios: existingScenarios.map((s) => ({
         id: s.id,
         name: s.name,
         description: s.description,
         metadata: {
-          error: s.metadata.error,
-          keyAttributeInstructions: s.metadata.keyAttributeInstructions,
-          playwrightInstructions: s.metadata.playwrightInstructions,
+          error: s.metadata?.error,
+          coveredFlows: s.metadata?.coveredFlows,
+          playwrightInstructions: s.metadata?.playwrightInstructions,
         },
       })),
       commitDiff,
@@ -144,7 +132,7 @@ export default async function generateChangesEntityScenarios({
           isolatedDataStructure: {
             equivalentSignatureVariables:
               entity.metadata.isolatedDataStructure
-                .equivalentSignatureVariables,
+                ?.equivalentSignatureVariables,
           },
         },
       },
@@ -189,7 +177,7 @@ export default async function generateChangesEntityScenarios({
     );
 
     const revisedFromPreviousVersion = previousVersion
-      ? !!scenarioInfo.keyAttributeInstructions
+      ? !!scenarioInfo.coveredFlows
       : undefined;
     const useScenarioData = !previousVersion || revisedFromPreviousVersion;
 
@@ -202,58 +190,42 @@ export default async function generateChangesEntityScenarios({
         : previousVersion.description,
       metadata: {
         testName:
-          useScenarioData || !previousVersion.metadata.testName
+          useScenarioData || !previousVersion?.metadata?.testName
             ? scenarioInfo.testName
             : previousVersion.metadata.testName,
         error,
         revisedFromPreviousVersion,
         codeSnippet: useScenarioData
           ? scenarioInfo.codeSnippet
-          : previousVersion.metadata.codeSnippet,
-        fix: useScenarioData ? scenarioInfo.fix : previousVersion.metadata.fix,
+          : previousVersion?.metadata?.codeSnippet,
+        fix: useScenarioData
+          ? scenarioInfo.fix
+          : previousVersion?.metadata?.fix,
         fixSnippet: useScenarioData
           ? scenarioInfo.fixSnippet
-          : previousVersion.metadata.fixSnippet,
+          : previousVersion?.metadata?.fixSnippet,
         likelihood: useScenarioData
           ? scenarioInfo.likelihood
-          : previousVersion.metadata.likelihood,
+          : previousVersion?.metadata?.likelihood,
         likelihoodDescription: useScenarioData
           ? scenarioInfo.likelihoodDescription
-          : previousVersion.metadata.likelihoodDescription,
+          : previousVersion?.metadata?.likelihoodDescription,
         severity: useScenarioData
           ? scenarioInfo.severity
-          : previousVersion.metadata.severity,
+          : previousVersion?.metadata?.severity,
         severityDescription: useScenarioData
           ? scenarioInfo.severityDescription
-          : previousVersion.metadata.severityDescription,
-        dataMapping: useScenarioData
-          ? scenarioInfo.dataMapping
-          : previousVersion.metadata.dataMapping,
-        keyAttributeInstructions: useScenarioData
-          ? Object.keys(scenarioInfo.keyAttributeInstructions).reduce(
-              (acc: any, key) => {
-                const attributesList = keyAttributes.map(
-                  (attr) => attr.internalPath,
-                );
-                const matchingKey = findMatchingAttribute(
-                  key,
-                  attributesList,
-                  entity.metadata.isolatedDataStructure
-                    .equivalentSignatureVariables,
-                );
-                acc[matchingKey] = scenarioInfo.keyAttributeInstructions[key];
-                return acc;
-              },
-              {},
-            )
-          : previousVersion.metadata.keyAttributeInstructions,
+          : previousVersion?.metadata?.severityDescription,
+        coveredFlows: useScenarioData
+          ? scenarioInfo.coveredFlows || []
+          : previousVersion?.metadata?.coveredFlows || [],
         playwrightInstructions: useScenarioData
           ? sanitizePlaywrightInstructions(
               scenarioInfo.playwrightInstructions || [],
               entity.name,
               scenarioInfo.name,
             )
-          : previousVersion.metadata.playwrightInstructions,
+          : previousVersion?.metadata?.playwrightInstructions,
       },
       previousVersionId: previousVersion?.id,
     });
@@ -269,325 +241,146 @@ export default async function generateChangesEntityScenarios({
 function generateChangesSystemMessage(
   context?: string,
   scenarioCount?: number,
-  isError?: boolean,
 ): string {
-  return `We have a function that was recently changed. We want to know if the existing data scenarios are still valid, if any should be changed or removed at all, or if any should be added to effectively capture the change that just took place.
-
-${
-  context
-    ? `## Business Logic Context
-
+  const contextSection = context
+    ? `## Business Context
 ${context}
 
-Focus your scenario updates on demonstrating this specific change. ${scenarioCount ? `Generate ${scenarioCount} total scenario${scenarioCount > 1 ? 's' : ''}.` : ''}
+Focus scenario updates on demonstrating this change.${scenarioCount ? ` Generate ${scenarioCount} total scenario${scenarioCount > 1 ? 's' : ''}.` : ''}
 
 `
-    : ''
-}
-
-${
-  !context && scenarioCount
-    ? `Generate ${scenarioCount} total scenario${scenarioCount > 1 ? 's' : ''}.
+    : scenarioCount
+      ? `Generate ${scenarioCount} total scenario${scenarioCount > 1 ? 's' : ''}.
 
 `
-    : ''
-}
+      : '';
 
-Also if any of the existing scenarios have playwright instructions, we want to ensure that they are still valid and if not, update them to reflect the changes.
+  return `You are updating data scenarios after a code change. Determine which existing scenarios need updating, which should be removed, and if new ones are needed.
 
-It is important to focus on the added or removed key attributes, the change to the code, and the playwright instructions. If a dependency was involved in the change then look at its key attributes, if it has any, as well. 
+${contextSection}## Your Goal: Maintain Full Execution Flow Coverage
 
-If the change involves a dependency that has key attributes listed then be sure to include key attribute instructions for the key attributes of that dependency in the scenarios. We want to ensure dependencies demonstrate their state in this function as well.
+You are given:
+- \`executionFlows\`: All current distinct outcomes/behaviors this component can produce
+- \`addedFlows\`: New flows that didn't exist before
+- \`removedFlows\`: Flows that no longer exist
+- \`existingScenarios\`: Current scenarios with their coveredFlows
 
-We want to ensure that we have scenarios that capture the changes and how the function behaves differently now. The added or removed key attributes and the playwright instructions are the most important part of this.
+**Your job**: Update scenarios to maintain coverage of ALL current execution flows.
 
-If a key attribute was removed:
-  - Look at scenarios that use that key attribute.
-  - If the scenario still makes sense as a scenario for this code then adjust the \`keyAttributeInstructions\` to add new key attributes that make up for the removed key attributes.
-  - If the scenario no longer makes sense then remove it.
-  - Try to ensure scenarios that scenarios are not removed without replacing them with another scenario unless the existing scenario is truly no longer needed. If there are fewer than three scenarios remaining please create new scenarios to ensure there are at least three scenarios that capture the behavior of the function.
+## Update Rules
 
-IMPORTANT: If the ${DEFAULT_SCENARIO_NAME} scenario contains a removed key attribute then it must be updated to remove that key attribute, usually replacing it with a new key attribute. This is the default scenario. It should not contain any removed key attributes, but it must always exist. If it does then it is not a valid scenario.
+### Removed Flows
+- If an existing scenario only covers removed flows, remove the scenario
+- If a scenario covers both removed and current flows, update its coveredFlows to remove the deleted ones
 
-If a key attribute was added:
-  - Create new or edit existing scenarios to capture the new behavior that the added key attribute introduces.
+### Added Flows
+- Create new scenarios or update existing ones to cover new flows
+- Follow the same rules as initial scenario generation:
+  - Blocking flows (blocksOtherFlows: true) get their own dedicated scenarios
+  - Non-blocking flows can be combined with compatible existing scenarios
 
-If any of the playwright instructions are no longer valid:
-  - Update the playwright instructions to reflect the changes in the code.
+### Unchanged Scenarios
+- Return name only (no other fields needed) if the scenario's covered flows are all still valid
 
-If new scenarios are warranted, note in the description for the scenario how the output of the function is affected and what the user should look for to understand what has changed. This is very important for the user to understand the impact of the change. For new scenarios modify the ${DEFAULT_SCENARIO_NAME} keyAttributeInstructions as little as possible to highlight the change or range of changes.
+### Default Scenario
+- First scenario must be "${DEFAULT_SCENARIO_NAME}" (exact name)
+- NEVER include playwrightInstructions—captures initial state only
+- Should cover as many non-blocking, non-error flows as possible
 
-If no changes are required to the existing scenarios (all keyAttributes, their values, and any playwright instructions are still valid) and there are no new scenarios then provide a brief overview of the change and why no scenarios are changed or new scenarios are needed. For example:
+## Response Format
 
-\`\`\`
+If no changes needed:
+\`\`\`json
 {
-  "overview": "The styles of the returned component are updated. The existing scenarios will show these changes. No new scenarios are needed.",
+  "overview": "Style updates only. Existing scenarios remain valid.",
   "dataScenarios": "No changes required"
 }
 \`\`\`
 
-Otherwise return all relevant scenarios, only removing ones that no longer make sense. Always try to replace removed scenarios with new scenarios if the behavior the scenario was testing is still relevant, even if the key attributes have changed.
-
-If an existing scenario is still valid and requires no changes (all keyAttributes, their values, and any playwright instructions are still valid) then simply return it, but with nothing but the name provided in the response.
-
-When creating a new scenario follow the pattern of the existing scenarios, providing "keyAttributeInstructions" that another AI can read to generate the data for each scenario. The "keyAttributeInstructions" should detail exactly how to populate the data structure with data for the function to behave as described in the scenario. New scenarios should have distinctly different "keyAttributeInstructions" from existing scenarios to higlight diverse states for the function.
-
-You can assume the other AI will generate reasonable data to satisfy the data structure, so focus the "keyAttributeInstructions" on the interesting parts of the data that should be generated.
-
-## Instructions
-
-- For each key attribute select from one of the valid values provided in the key attribtutes list.
-- If the function is a front-end (visual) function, then pay special attention to key attributes that will change the visual appearance of the function. In the "${DEFAULT_SCENARIO_NAME}" scenario if there are attributes such as "children", ensure they are populated so that they front end function renders visually interesting results.
-- 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.
-  - 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.
-
-## Dependencies
-
-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.
-
-## Relative Dates
-
-If a relative date is required you can describe it in the "keyAttributeInstructions", e.g. 'today', 'tomorrow', 'next week', 'last month'.
-
-## Rules
-
-- 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.
-
-- 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.
-
-## Response Structure
-
-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.
-
-{
-  "dataScenarios": [
-    {
-      "name": string;
-      "testName": string;
-      "description": string;
-      "keyAttributeInstructions": {
-        ["keyAttributePath"]: string;
-      },
-      "playwrightInstructions?": {
-        "selectorFn": string;
-        "selectorArgs": string[];
-        "actionFn": string;
-        "actionArgs": string[];
-      }[]
-    }
-  ]
-}
-
-Optionally you can include playwright instructions for front-end functions if any are needed to put the function into the correct state to demonstrate the scenario.
-
-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.
-
-If the data won't exist or be used without user actions then use the "playwrightInstructions" to provide the necessary code to run in Playwright.
-
-Please check all existing scenarios for any outdated or invalid playwright instructions. If any exist, update them to reflect the changes in the code. and return the full scenario with the updated playwright instructions.
-
-For \`playwrightInstructions\`, provide an array of strings representing the necessary code to run.
+Otherwise:
 \`\`\`json
 {
-  "playwrightInstructions": [
-    {
-      "selectorFn": "getByLabel",
-      "selectorArgs": ["email"],
-      "actionFn": "fill",
-      "actionArgs": ["test@example.com"]
-    },
-    {
-      "selectorFn": "getByText",
-      "selectorArgs": ["Submit"],
-      "actionFn": "click",
-      "actionArgs": []
-    }
-  ]
-}
-\`\`\`
-
-For an existing scenario that does not need to change, only provide the name of the scenario in the response:
-
-{
-  "overview": string;
-  "dataScenarios": [
-    {
-      "name": string;
-    }
-  ]
-}
-
-## Example
-
-Assuming a change that impacted how the component displayed if there were no notifications, the full response might be:
-
-\`\`\`
-{
-  "overview": "This change impacted how the component displays when there are no notifications. Creating one new scenario with no notifications to test this. All other scenarios are still valid.",
+  "overview": "Added empty state scenario for new display behavior.",
   "dataScenarios": [
+    { "name": "${DEFAULT_SCENARIO_NAME}" },
+    { "name": "Settings Modal" },
     {
-      "name": ${DEFAULT_SCENARIO_NAME}
-    },
-    {
-      "name": "Many notifications, a few unread"
-    },
-    {
-      "name": "No notifications",
-      "testName": "it(\"renders a default message when there are no notifications\")",
-      "description": "A user has no notifications at all.",
-      "keyAttributeInstructions": {
-        "notifications[]": "set to an empty array",
-      }
+      "name": "Empty State",
+      "testName": "it(\\"shows empty message when no items\\")",
+      "description": "User has no items to display.",
+      "coveredFlows": ["empty-list"]
     }
   ]
 }
 \`\`\`
 
-Note the terseness of the description for the new scenario. It should not start with "This scenario..." or "In this scenario...". It should be a simple declarative statement that describes the scenario.
-
-The first data scenario is your response should always be the ${DEFAULT_SCENARIO_NAME} with that exact name.
+## Field Descriptions
 
-Remember to only use the valid values provided in the key attributes list in the "keyAttributeInstructions".
+- **name**: Human-readable scenario name (letters, numbers, spaces only)
+- **testName**: Jest-style test description (only for new/updated scenarios)
+- **description**: What the user sees (only for new/updated scenarios)
+- **coveredFlows**: Array of execution flow IDs this scenario covers (only for new/updated scenarios)
+- **playwrightInstructions**: User interactions needed (only for new/updated scenarios that require interaction)
 
-Remember to include keyAttributeInstructions for dependencies as well, especially if the change involves one.
-
-Do not use any special characters in the scenario names. Keep them short and concise and only use letters, numbers, and spaces.
-
-Remember to update playwright instructions, if any exist, as needed. Scenarios can not have invalid playwright instructions or the simulation will fail.
+## Rules
+- Scenario names: letters, numbers, spaces only
+- testName: Jest style with specific expectations
+- All values must be valid JSON
+- EVERY execution flow must be covered by at least one scenario
+- Blocking flows get dedicated scenarios
 `;
 }
 
-const ERROR_SYSTEM_MESSAGE = `We have a function that was recently changed. We want to know if the change introduced any potential bugs or fixed any existing error scenarios.
-
-Please look at the diff and the resulting code to determine if there are any new ways to cause the function to fail that are not properly handled by existing error scenarios. 
+const ERROR_SYSTEM_MESSAGE = `You are reviewing error scenarios after a code change. Determine if the change introduced new potential bugs or fixed existing ones.
 
-If the changes to the code do not introduce any more potential errors then do not create any new error scenarios. We've provided all existing error scenarios. Do not duplicate any of them. If any of them are no longer valid then remove them. If they are still valid then return their name with no additional information.
+## Task
+- Existing error scenarios: return name only if still valid, remove if fixed
+- New errors from the change: create new error scenarios
+- No new errors and no existing ones: return \`{ "errorDataScenarios": "No errors found" }\`
 
-If new error scenarios are warranted, note in the description for the scenario how the change introduced an error, provide 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 instructions on how to generate the necessary data to cause the error.
+## What Qualifies as an Error
+- MUST cause actual thrown error (not awkward behavior)
+- MUST be fixable in THIS function's code
+- MUST NOT be catchable by static type analysis
+- MUST NOT assume dependent functions fail
 
-For each new 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.
+## Likelihood Scale (1-10)
+- 1-3: Requires unusual/wrong data
+- 4-6: Plausible edge case
+- 7-9: Common real-world scenario
+- 10: ONLY if guaranteed bug regardless of input
 
-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.
+Be conservative with high scores.
 
-If there are no existing error scenarios and no new potential errors have been introduced then return the following:
-
-\`\`\`
-{
-  "errorDataScenarios": "No errors found"
-}
-\`\`\`
-
-## New Error Scenarios Instructions
-
-You can assume the other AI will generate reasonable data to satisfy the data structure, so focus the "keyAttributeInstructions" on the parts of the data that must be generated to cause the error.
-
-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.
-
-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.
-
-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 explains the scenario and why it is interesting. The name should be unique and short (no more than 30 characters), and the description should provide context for the error scenario.
-
-Focus on "Major" errors. Only include "Minor" errors if they are very likely to occur.
+## Severity Scale (1-2)
+- 1 = Minor: Unexpected behavior, no crash
+- 2 = Major: Function fails (focus here)
 
 ## 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 causes a DISTINCT error type
 
-- 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.
-
-- 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 new 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.
-
-## Response
-Respond with the error scenarios in a JSON object format, without additional information or delimiters. Ensure clarity and specificity in each error scenario to facilitate accurate data generation for testing or demonstration purposes.
-
-{
-  "errorDataScenarios": [
-    {
-      "dataMapping": { [key: string]: string };
-      "name": string;
-      "codeSnippet": string;
-      "description": string;
-      "fix": string;
-      "fixSnippet": string;
-      "likelihood": number;
-      "likelihoodDescription": string;
-      "severity": number;
-      "severityDescription": string;      
-      "keyAttributeInstructions": { [key: string]: string };
-    }
-  ]
-}
-
-## Example
-Given the following data structure:
-
-\`\`\`
-{
-  "props": {
-    "notifications": {
-      "message": "string",
-      "read": "boolean"
-    }[]
-  }
-}
-\`\`\`
-
-And assuming a change that impacted how the component displayed if there were no notifications, the full response might be:
-
-\`\`\`
+## Response Format
+\`\`\`json
 {
   "errorDataScenarios": [
+    { "name": "Existing valid error" },
     {
-      name: "Error: Existing error scenario 1"
-    },
-    {
-      name: "Error: Existing error scenario 2"
-    },
-    {
-      "name": "Error: 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 encoding error",
+      "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 { encoded = encodeURIComponent(message); } catch (e) { ... }",
       "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 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.
 `;