agent-generator 1.0.3 → 1.0.5

package/install-extension.js

@@ -35,7 +35,7 @@ if (!fs.existsSync(targetDir)) {
 }
 
 // Copy extension files
-const filesToCopy = ['main.js', 'package.json', 'Generator_Patterns', 'source', '.agents'];
+const filesToCopy = ['main.js', 'package.json', '.agents', '.github'];
 const currentDir = __dirname;
 
 filesToCopy.forEach(file => {

package/package.json

@@ -2,7 +2,7 @@
     "name": "agent-generator",
     "displayName": "Generator Agent",
     "description": "A Copilot Agent for conditional rule-based data generation",
-    "version": "1.0.3",
+    "version": "1.0.5",
     "publisher": "IshwaryaRamesh",
     "engines": {
         "vscode": "^1.80.0"
@@ -45,9 +45,7 @@
         "main.js",
         "install-extension.js",
         ".agents",
-        ".github",
-        "Generator_Patterns",
-        "source"
+        ".github"
     ],
     "devDependencies": {
         "@types/vscode": "^1.80.0",

package/Generator_Patterns/Conditional.md

@@ -1,84 +0,0 @@
-# CONDITIONAL Generator — Rule-Based Data Selection
-
----
-
-## Overview
-
-A **Conditional Generator** selects a data generator based on predefined conditions. It enables dynamic test data generation by evaluating input values or context and branching to different generator logic accordingly.
-
----
-
-## When to Use
-
-- When the value of a parameter depends on other input values or request context.
-- To implement business rules, feature flags, or scenario-specific data.
-- For fallback/default logic when no condition matches.
-
----
-
-## Structure
-
-A conditional generator contains:
-- `type`: Must be `"conditional"`
-- `conditions`: List of condition objects, each with:
-	- `when`: The condition to evaluate (key, operator, value)
-	- `then`: The generator or value to use if the condition matches
-- `else`: (optional) The generator or value to use if no conditions match
-
----
-
-## Example
-
-```json
-{
-	"generators": {
-		"snippet_id": [
-			{
-				"type": "conditional",
-				"conditions": [
-					{
-						"when": {
-							"key": "$.input.query:modules",
-							"equals": "tickets"
-						},
-						"then": {
-							"use": "$generators:#/generators/ticket_id"
-						}
-					},
-					{
-						"when": {
-							"key": "$.input.query:modules",
-							"equals": "contacts"
-						},
-						"then": {
-							"use": "$generators:#/generators/contact_id"
-						}
-					}
-				],
-				"else": "$generators:#/generators/activity_id"
-			}
-		]
-	}
-}
-```
-
----
-
-## Best Practices
-
-- Use input-based branching: reference request path, query, or body fields in `when`.
-- Reference other generators in `then` using correct relative paths or `$generators:` syntax.
-- Always provide an `else` clause if possible to avoid unexpected nulls.
-- Keep conditions mutually exclusive and clear.
-- Avoid deeply nested or overly complex chains for readability.
-
----
-
-## Validation Checklist
-
-- Ensure all referenced generators exist.
-- Test each condition path for expected output.
-
----
-
-*Last Updated: 17 February 2026*

package/Generator_Patterns/Dynamic.md

@@ -1,129 +0,0 @@
-
-# Rule: Referencing Single-Entity Dynamic Generator Dependencies
-
-When a dynamic generator is used as a dependency for another generator (e.g., createTicket), always reference the dependency in params as $<generatorname>.value, regardless of the dataPath used in the dependency generator. This ensures the correct value is passed even if the dataPath returns an array or a single value.
-
-**Example:**
-
-Dependency generator:
-```json
-{
-  "type": "dynamic",
-  "name": "departments",
-  "generatorOperationId": "support.Department.getDepartments",
-  "dataPath": "$.response.body:$.data[*].id"
-}
-```
-
-Dependent generator:
-```json
-{
-  "type": "dynamic",
-  "name": "ticket",
-  "generatorOperationId": "support.Ticket.createTicket",
-  "params": {
-    "departmentId": "$departments.value"
-  }
-}
-```
-
-## What It Does
-A DYNAMIC Generator fetches data from real API responses.
-
----
-
-## When to Use DYNAMIC
-- When you need real system data that changes frequently (e.g., active agent IDs, current ticket IDs).
-- When there is an API available to fetch the required data.
-  
----
-
-## Required Properties
-
-| Property | Type | Purpose |
-|----------|------|---------|
-| `type` | string | Must be `"dynamic"` |
-| `generatorOperationId` | string | Which API operation to call |
-| `dataPath` | string | Where to extract data from response |
-
-## Optional Properties
-
-| Property | Type | Purpose |
-|----------|------|---------|
-| `params` | object | Filter parameters: `{"status": "ACTIVE"}` |
-| `name` | string | Generator identifier (unique label for referencing in params) |
-
----
-
-## DataPath Format
-
-**Pattern:** `$.response.body:$.path.to.data`
-
-**Examples:**
-- `$.response.body:$.data[0].id` - First item ID
-- `$.response.body:$.data[*].id` - All item IDs
-- `$.response.body:$.items[0].manager.id` - Nested field
-
----
-
-## Examples
-
-### Single Result
-Fetch the first matching record:
-```json
-{
-  "type": "dynamic",
-  "generatorOperationId": "support.Agent.getAgents",
-  "dataPath": "$.response.body:$.data[0].id"
-}
-```
-### With Filter Parameters
-Find specific records:
-```json
-{
-  "type": "dynamic",
-  "generatorOperationId": "support.Agent.getAgents",
-  "dataPath": "$.response.body:$.data[*].id",
-  "params": {"status": "ACTIVE"}
-}
-```
-### Nested Field
-Extract from object hierarchy:
-```json
-{
-  "type": "dynamic",
-  "generatorOperationId": "support.Department.getDepartment",
-  "dataPath": "$.response.body:$.manager.id"
-}
-```
----
-
-## Best Practices
-
-**Do:**
-- Use params to filter for specific scenarios
-- Give descriptive names showing the filter/status
-- Verify operationId exists in OpenAPI specification
-  
-**Avoid:**
-- Assuming first result is always valid
-- Generic names like "id"
-- Forgetting `[*]` on array parameters
-- Hardcoding fallback without DYNAMIC
-  
----
-
-## Check
-- operationId is spelled correctly
-- dataPath matches actual response structure
-- params filter isn't too strict
-
-## Reference
-- **Fetch Method:** API operations
-- **Data Type:** Real system data
-- **Scope:** Cross-entity references possible
-- **Updates:** Auto-syncs with system data
-
----
-
-*Last Updated: 17 February 2026*

package/Generator_Patterns/PathConfig.properties

@@ -1,4 +0,0 @@
-
-# Path configurations for generator framework (using source folder)
-GENERATOR_CONFIG_PATH=../source/api-data-generators/support/
-OAS_FILE_PATH=../source/openapi-specifications/v1.0/support/

package/Generator_Patterns/README.md

@@ -1,118 +0,0 @@
-# Data Generation Framework
-
-## What is this?
-
-This framework helps you generate test data for APIs defined in OpenAPI (OAS) files.
-
-In simple words:
-- You define generators in JSON.
-- Generators call APIs, reuse values, and build input data.
-- You can chain generators when one value depends on another.
-
-## What is a generator?
-
-A generator is a small JSON step that produces data.
-
-Examples:
-- Fetch `departmentId` from an API response
-- Reuse a value from request input
-- Set a fixed value like `priority = "high"`
-
-All generators must be inside the `generators` object.
-
-Basic format:
-
-```json
-{
-  "generators": {
-    "generator_name": [
-      {
-        "type": "..."
-      }
-    ]
-  }
-}
-```
-
-## About the Generator Agent
-
-The Generator Agent helps developers create generator files faster and correctly.
-
-The agent does the following:
-- Reads the target operation from OAS
-- Finds required dependencies from related operations
-- Creates generator steps in the correct dependency order
-- Uses only fields that exist in OAS (no invented params)
-- Produces output in the required `generators` JSON structure
-
-## Where to find paths
-
-Use `PathConfig.properties` as the source of truth:
-- `GENERATOR_CONFIG_PATH` for generator file locations
-- `OAS_FILE_PATH` for OpenAPI specification locations
-
-Always use these configured paths instead of hardcoding paths.
-
-## Generator types
-
-Use the right type based on your need:
-
-| Type | Purpose | Documentation |
-| --- | --- | --- |
-| Dynamic | Get values from API operations | [Dynamic](./Dynamic.md) |
-| Remote | Get values from system/remote helpers | [Remote](./Remote.md) |
-| Static | Use fixed constant values | [Static](./Static.md) |
-| Reference | Reuse existing values from input/other generators | [Reference](./Reference.md) |
-| Conditional | Choose values based on conditions | [Conditional](./Conditional.md) |
-
-## JSONPath quick guide
-
-Common response mapping format:
-
-`$.location:$.path`
-
-Examples:
-- `$.data[*].id` → all ids in an array
-- `$.data[0].id` → first id
-- `$.manager.id` → nested value
-- `$.users[?(@.active == true)].id` → filtered values
-
-## Developer workflow (quick)
-
-1. Identify the target API operation.
-2. Read the target operation in OAS.
-3. Identify dependency operations and required values.
-4. Choose proper generator types.
-5. Create a new generator file in the correct folder.
-6. Keep dependencies in order inside the same generator array.
-7. Validate all params and paths against OAS.
-
-## Important rules
-
-- Use snake_case generator names.
-- Keep names meaningful and short.
-- Use singular for single value, plural for list values.
-- Do not add fields that are not present in OAS.
-- Do not modify existing generators unless explicitly requested.
-
-## Reference Syntax
-
-```
-$<generatorname>.value                    // Generator reference
-$.input.body:$.fieldName                  // Request body
-$.input.query:$.paramName                 // Query parameter
-$.input.path:$.pathParam                  // URL path
-$.input.header:$.HeaderName               // HTTP header
-```
-
-## DataPath Format
-
-```
-$.response.body:$.data[0].id              // First item ID
-$.response.body:$.data[*].id              // All item IDs
-$.response.body:$.id                      // Direct ID field
-$.response.body:$.manager.id              // Nested field
-$.response.body:$.items[?(@.status == 'active')].id  // Filtered values
-```
-
-Last updated: 23 February 2026

package/Generator_Patterns/Reference.md

@@ -1,98 +0,0 @@
-# REFERENCE Generator - Use Request Input Data
-
-## What It Does
-
-Passes data directly from incoming request to response without modification. Extracts values from request body, query parameters, path parameters, or headers.
-
----
-
-## When to Use REFERENCE
-
-Use REFERENCE when:
-A Reference Generator extracts data from previous API responses.- Using data from request body
-- Getting values from query parameters
-- Using path parameters
-- Using header values
-- Data comes directly from request
-
-**Common Scenarios:**
-- Pass ticket ID from request to response
-- Use query parameters in operations
-- Extract URL path parameters
-- Forward authorization headers
-- Use nested request objects
-
----
-
-## Required Properties
-
-| Property | Type | Purpose |
-|----------|------|---------|
-| `type` | string | Must be `"reference"` |
-| `ref` | string | Path to request data |
-
-## Reference Path Format
-
-**Pattern:** `$.input.{location}:$.{jsonPath}`
-
-### Location Types
-
-| Location | Source | Example |
-|----------|--------|---------|
-| `$.input.body` | Request body JSON | `$.input.body:$.ticketId` |
-| `$.input.query` | Query parameters | `$.input.query:$.departmentId` |
-| `$.input.path` | URL path parameters | `$.input.path:$.ticketId` |
-| `$.input.header` | HTTP headers | `$.input.header:$.Authorization` |
-
-### Path Selector Examples
-
-| Reference | Extracts |
-|-----------|----------|
-| `$.input.body:$.fieldName` | Simple field from body |
-| `$.input.body:$.parent.child.fieldName` | Nested field |
-| `$.input.body:$.items[*].id` | All array IDs |
-| `$.input.body:$.items[0].id` | First array ID |
-| `$.input.query:$.parameterName` | Query parameter |
-| `$.input.path:$.pathParamName` | Path parameter |
-| `$.input.header:$.HeaderName` | Header value |
-
----
-
-## Best Practices
-
-**Do:**
-- Verify request contains the fields you reference
-- Use exact field names (case-sensitive)
-- Use clear generator names matching source
-
-**Avoid:**
-- Referencing fields that don't exist
-- Assuming request structure without docs
-- Using REFERENCE for static values
-- Ignoring case sensitivity
-
----
-
-## When to Use REFERENCE
-
-| Scenario | Use REFERENCE |
-|----------|---|
-| Pass-through from request | Yes |
-| Get data from request | Yes |
-| Fetch from database | No |
-| Fixed constant | No |
-| System timestamp | No |
-| Logic-based value | No |
-
----
-
-## Reference
-
-- **Fetch Method:** Request fields
-- **Data Type:** Request data (pass-through)
-- **Scope:** Single request scope
-- **Updates:** From request content
-
----
-
-*Last Updated: 17 February 2026*