@codeyam/codeyam-cli 0.1.0-staging.8aea589 → 0.1.0-staging.bbe4da9

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

@@ -280,176 +280,75 @@ export default async function generateEntityScenarioData({
 export const generateSystemMessage = (
   scenarioName: string,
   defaultScenario: boolean,
-) => `## Overview
-- You will be provided with a structure for scenario data, the "mockData structure", and for the arguments of the function, the "argumentsData structure", and a scenario describing a new state of data for this function.
-
-- Your goal is to generate data to fulfill both the data structures and the scenario, to be returned in a JSON object.
-
-## Provided Information
-
-- The "mockData structure" and "argumentsData structure" describe all of the data required for the simulation to work. Copy the data structures exactly (if an attribute is a function it will look like "myFunction()" and that exact key "myFunction()" should be in the return value structure) and replace any primitives (e.g. "string", "number", "boolean", "date") with realistic data. 
-
-${defaultScenario ? '' : '- The "Default Scenario Data" provides the data that has already been generated for the default scenario. This data will be merged into the data for each scenario. Your goal is to modify this data as needed to satisfy the requirements of this scenario. As such you only need to specify data that is different or should be removed from the default scenario data. To remove data set some portion of the data structure to null.'}
-
-- Follow the "keyAttributeInstructions" for the scenario carefully.${defaultScenario ? ' As the Default Scenario ensure that the entire data structure is filled in with appropriate values even if they are not explicitly described in the "keyAttributeInstructions".' : ''}
-
-## Instructions
-${
-  defaultScenario
-    ? `
-- We need data for the default scenario.
-
-- The default scenario requires robust and complete data that fulfills all the "mockData" and "argumentsData" data structures if they exist, except for error attributes.
-
-- The one exception to this is error data. Sometimes the data structure will contain structures for both success and error data. In this case you should only fill in the success data and leave out the error data completely.
-
-- This data should cover for every object, attribute, and nested attribute described in the data structures (other than error data). If an item in a data structure is an array then provide multiple objects in the array. Fill in every nested attribute with realistic data. This should provide a robust and complete "database" for the simulation. If the type is described as "any" then create a realistic example of that type based on its name. If the type is "date" or "timestamp" then use the instructions below to generate a dynamic date or timestamp. 
-
-- Remember to fill in each and every attribute and nested attribute in the data structure for the default scenario (other than error data). This will make the simulation more realistic and valuable. Do not add any attributes that are not in the data structure. If an attribute is not in the data structure then it should not be included in the data.
-`
-    : `
-- This scenario is a modification of the default scenario. Figure out what needs to change about the Default Scenario in order to satisfy this scenario. If data must be removed then mark is as null at the appropriate level of the structure that the deletion should occur. Otherwise you can change any data that needs to be modified. Do not include any aspect of the structure that should remain the same as the Default Scenario.
-
-- The data generated will be merged into the Default Scenario Data in order to create the full data for this scenario.
-`
-}
-
-## Example Response
-
-{
-  "scenarioData": {
-    "scenarioName": ${scenarioName},
-    "data': {
-      "mockData": {
-        "useUser()": {
-          "user": {
-            "name": "John Doe",
-            "metadata": {
-              "hobbies": ["fishing", "hiking", "camping"]
-              "favoriteColor": "blue",
-            },
-            "joinedAt": {
-              "~~codeyam-code~~": "new Date(Date.now() - 3 * 24 * 60 * 60 * 1000)"         
-            }
-          },
-        },
-        "loadProject()": {
-          "project": {
-            "name": "New Project",
-            "slug": "new-project",
-            "files": [
-              {
-                "name": "File 1",
-                "slug": "file-1",
-                "content": "This is the content of file 1"
-              },
-              {
-                "name": "File 2",
-                "slug": "file-2",
-                "content": "This is the content of file 2"
-              },
-              {
-                "name": "File 3",
-                "slug": "file-3",
-                "content": "This is the content of file 3"
-              }
-            ]
-          }
-        }
-      },
-      "argumentsData": [
-        {
-          "open": "true",
-          "children: {
-            "~~codeyam-jsx~~": "<div>Hi!</div>"         
-          }      
-        }    
-      ]  
-    }
-  }
-}
-
-## scenarioData
-
-You will return a JSON object called scenarioData containing the name and data for this scenario.
-
-If you encounter a "date" then you should use "~~codeyam-code~~" along with code in string format. That string will be evaled to create the date or timestamp needed.
-
-For example the "timestamp" above should probably not be a hard-coded timestamp but should be a function that returns a timestamp. If you want to return a timestamp that is 24 hours in the future, you would return this object:
+) => {
+  const scenarioType = defaultScenario
+    ? `## Default Scenario
+Generate COMPLETE, robust data for the entire data structure.
+- Fill ALL fields with realistic values (except error attributes)
+- Arrays should have 2-3 items
+- Don't skip nested attributes
+- This provides the baseline data for all other scenarios`
+    : `## Non-Default Scenario
+Generate ONLY the differences from the default scenario.
+- Include only fields that need to change
+- Set to \`null\` to remove data
+- Omit unchanged fields—they merge from default`;
+
+  return `You are a test data generator. Create mock data matching a data structure and scenario requirements.
+
+${scenarioType}
+
+## CRITICAL: NO ERROR DATA
+NEVER include "error" fields in responses. Skip them entirely.
+- If structure has \`{ data: {...}, error: {...} }\`, only fill \`data\`
+- Leave out any attribute named "error"—do not set to null, omit entirely
+
+## Special Markers
+
+### Dynamic Dates (\`~~codeyam-code~~\`)
+\`\`\`json
+{ "createdAt": { "~~codeyam-code~~": "new Date(Date.now() - 24*60*60*1000)" } }
+\`\`\`
+Use for relative dates. Code runs in Node (no browser APIs, no external libraries).
 
+### JSX Children (\`~~codeyam-jsx~~\`)
+\`\`\`json
+{ "children": { "~~codeyam-jsx~~": "<div>Hello</div>" } }
 \`\`\`
+Use simple elements only (\`<div>\`, \`<span>\`). No custom components.
+
+## Function Keys
+Preserve function call syntax exactly as written in the structure:
+\`\`\`json
 {
-  "scenarioData": {
-    "scenarioName": ${scenarioName},
-    "data": {
-      "mockData": {
-        "dataLoaders": {
-          "fetchUser()": {
-            "user": {
-              "name": "John Doe",
-              "metadata": {
-                "hobbies": ["fishing", "hiking", "camping"],
-                "favoriteColor": "blue"
-              },
-              "joinedAt": {
-                "~~codeyam-code~~": "new Date(Date.now() - 3 * 24 * 60 * 60 * 1000).toISOString()"
-              }  
-            }
-          }
-        }
-      }
-    }
+  "mockData": {
+    "useUser()": { "user": { "name": "John" } },
+    "from().select()": [{ "id": "1" }]
   }
 }
 \`\`\`
 
-Keep in mind the above pattern is also valid for argumentsData.
-
-All code should be written in JavaScript. It will run in a node environment (not the browser) with no reference to external libraries. It will essentially be run in a sandboxed environment. Do not reference any external libraries in the code.
-
-With argumentsData you may also need to return a "children" argument. "children" can either be a string or a jsx element.
-
-If you want to return a jsx element you would return something like this:
-
-\`\`\`
+## Response Format
+\`\`\`json
 {
   "scenarioData": {
-    "scenarioName": ${scenarioName},
+    "scenarioName": "${scenarioName}",
     "data": {
-      "argumentsData": [
-        {
-          "children": {
-            "~~codeyam-jsx~~": "<div>Click Me!</div>"
-          }
-        }
-      ]
+      "mockData": { ... },
+      "argumentsData": [ ... ]
     }
   }
 }
 \`\`\`
 
-The "~~codeyam-jsx~~" key in a "children" prop will be rendered directly to the code as a jsx element, not a string. Only return basic elements like "<div>".
-
-Do not import or reference any libraries in this code. No external libraries will be imported.
-
-If either mockData or argumentsData is empty you can return an empty object for mockData ("{}") or empty array for argumentsData ("[]"). 
-
-If an object inside of mockData or argumentsData is intended to not exist you can set it to null.
-
-Never use "~~codeyam-code~~" or "~~codeyam-jsx~~" as a partial key in the response. Even if the key looks like it should have a relative date or code. "~~codeyam-code~~" and "~~codeyam-jsx~~" are only used as independent keys used to mark values that are code.
-
-## Common Mistakes
-
-- Do not use the term undefined in the response. If something is missing leave it out or use null.
-- Leave out error data (e.g. a data attribute labeled as "error"), especially when it is in a data structure that has success data as well. Only include the success data and simply leave out the error data. Error data is usually labeled as "error" in the structure. Leave it out entirely.
-  - Please double check this. Ensure no error data is included in the response unless specifically requested. ${defaultScenario ? `This includes the ${`DEFAULT_SCENARIO_NAME`}.` : ''} Leave out any error attributes from the response completely!
-- Do not reference data in the response (e.g. if there was a "posts" field you can not say "posts[0]" elsewhere in the response - you need to duplicate the data). Unfortunately all data must be written out directly in the response.
-- Ensure each scenario in the response matches the full scenario name, commas and all, in the scenarios provided.
-- Do not throw errors from this data in any manner. Simple leave out any error data.
-- If the data structure contains a type that is a "date" then use ~~codeyam-code~~ to generate a dynamic timestamp or date. Do not hard-code dates unless it needs to be a very specific date. Otherwise it should be a relative, dynamic date.
-- The response must be valid JSON. Do not include raw code in the response.
-${defaultScenario ? `- As the ${DEFAULT_SCENARIO_NAME} be very robust in generating data that reflects common real-world usage. All arrays and attributes, except error attributes, should be filled in with high quality data so that default simulation provides a good default of how the function behaves` : ''}
+## Rules
+- Valid JSON only—no raw code outside markers
+- No \`undefined\`—use \`null\` or omit
+- No data references (can't use \`posts[0]\` elsewhere—duplicate the value)
+- Scenario name must match exactly: "${scenarioName}"
+- Empty mockData: \`{}\`, empty argumentsData: \`[]\`
 `;
+};
 
 export const generateIncompleteSystemMessage = (
   scenarioName: string,

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

@@ -127,7 +127,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`,
@@ -195,316 +195,146 @@ 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 1-4 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.'}
-
-## The ${DEFAULT_SCENARIO_NAME}:
-
-- 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.
-
-## Other scenarios:
+    : '';
 
-- 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.
+  return `You are a test scenario designer. Generate data scenarios that demonstrate a function's behavior.
 
-## Instructions
+${contextSection}${scenarioCountText}
 
-- 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.
-
-## 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
+## Default Scenario Rules
+The FIRST scenario MUST be named exactly "${DEFAULT_SCENARIO_NAME}" (case-sensitive).
+- Fill ALL key attributes using values from their \`validValueOptions\` list
+- If "children" is an argument, populate it (otherwise output may be blank)
+- Ignore error-related attributes (set to null)
+- NEVER include \`playwrightInstructions\` - we need a screenshot BEFORE any user interaction
+- Do NOT add playwrightInstructions even if the component has forms/buttons - default shows initial state only
 
-- 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. 
-
-## 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.
-
-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:
+## Other Scenarios
+- Each produces DISTINCT output (visual: different screenshot; backend: different return/side-effect)
+- Only specify attributes that DIFFER from default
+- May include \`playwrightInstructions\` for user interactions (clicks, form fills)
 
+## keyAttributeInstructions Format
+Use \`dataStructurePath\` as key, include both variable name and instruction:
+\`\`\`json
 {
-  "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[];
-      }[]
-    }
-  ]
+  "useDiffModal().diffView": {
+    "localVariable": "diffView",
+    "instruction": "Set to 'split' mode"
+  }
 }
+\`\`\`
 
-Optionally you can include playwright instructions for front-end functions to put the function into the correct state to demonstrate the scenario.
-
-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.
-
-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 trigger execution of that code through the user actions.
-
-For \`playwrightInstructions\`, provide an array of strings representing the necessary code to run.
+## playwrightInstructions (optional, non-default only)
 \`\`\`json
 {
   "playwrightInstructions": [
-    {
-      "selectorFn": "getByLabel",
-      "selectorArgs": ["email"],
-      "actionFn": "fill",
-      "actionArgs": ["test@example.com"]
-    },
-    {
-      "selectorFn": "getByText",
-      "selectorArgs": ["Submit"],
-      "actionFn": "click",
-      "actionArgs": []
-    }
+    { "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.
 
-## Example Response
+Use when: data only appears after user action (button click, form submit), or key attribute isn't in data structure.
 
+## Rules
+- Relative dates OK in instructions: "today", "tomorrow", "last month"
+- React elements: use simple elements (\`<div>\`, \`<span>\`) - no custom JSX
+- No external library references - plain JS/TS values only
+- Scenario names: letters, numbers, spaces only (no special characters)
+- testName: Jest style with specific expectations, e.g. \`it("displays error when email invalid")\`
+- All values must be valid JSON (strings, numbers, booleans, arrays, objects) - no JavaScript literals like regex
+
+## Response Format
 \`\`\`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\")",
+      "name": "${DEFAULT_SCENARIO_NAME}",
+      "testName": "it(\"displays notifications with unread indicator\")",
+      "description": "Default state with 3 unread and 2 read notifications",
       "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"
-        }
+        "useNotifications().notifications[]": { "localVariable": "notifications[]", "instruction": "Create 5 notifications" },
+        "useNotifications().notifications[].read": { "localVariable": "notifications[].read", "instruction": "false for 3, true for 2" }
       }
     },
     {
-      "name": "No notifications",
-      "testName": "it(\"renders a default message when there are no notifications\")",
-      "description": "A user has no notifications at all.",
+      "name": "Empty state",
+      "testName": "it(\"shows placeholder when no notifications\")",
+      "description": "User has no notifications",
       "keyAttributeInstructions": {
-        "useNotifications().notifications[]": {
-          "localVariable": "notifications[]",
-          "instruction": "Should be an empty array"
-        }
-      }
-    },
-    {
-      "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"
-        }
+        "useNotifications().notifications[]": { "localVariable": "notifications[]", "instruction": "Empty array" }
       }
     }
   ]
 }
 \`\`\`
-
-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:
+const ERROR_SYSTEM_MESSAGE = `You are a security/reliability analyst. Identify data inputs that will cause UNCAUGHT ERRORS in this function.
 
-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.
+## 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
 
-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.
+## 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
 
-## Instructions
+Be conservative with high scores—they should surface truly likely errors.
 
-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.
-
-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. 
-
-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.
+## Severity Scale (1-2)
+- 1 = Minor: Unexpected behavior, no crash
+- 2 = Major: Function fails completely (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 must cause a DISTINCT error type
+- If no errors possible: \`{ "errorDataScenarios": "No errors found" }\`
 
-- 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:
+Note: In JS/TS, any non-zero value satisfies a boolean check—this won't error.
 
-\`\`\`
-{
-  "errorDataScenarios": "No errors found"
-}
-\`\`\`
-
-- Make sure each error scenario has a unique name.
-
-## 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.
-
-{
-  "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[];
-    }
-  ]
-}
-
-## Example
-Given the following data structure:
-
-\`\`\`
-{
-  "arguments": [
-    {
-      "notifications": {
-        "message": "string",
-        "read": "boolean"
-      }[]
-    }
-  ]
-}
-\`\`\`
-
-The full response might be:
-
-\`\`\`
+## 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..."
+      "dataMapping": { "notifications array": "arguments - notifications" },
+      "name": "Non-utf8 message encoding",
+      "codeSnippet": "const encoded = encodeURIComponent(message);",
+      "description": "encodeURIComponent throws on non-utf8 characters",
+      "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.",
+      "severityDescription": "Function throws uncaught error",
       "keyAttributeInstructions": {
-        "notifications[]": "Set the \"notifications array\" to an array of objects containing at least one notification with a message that contains non-utf8 characters.",
+        "notifications[]": "Array with message containing non-utf8 characters"
       }
     }
   ]
 }
 \`\`\`
-
-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.
 `;