@autobe/agent 0.5.2 → 0.7.0

package/lib/orchestrate/test/orchestrateTestScenario.js

@@ -0,0 +1,700 @@
+"use strict";
+var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    var desc = Object.getOwnPropertyDescriptor(m, k);
+    if (!desc || ("get" in desc ? !m.__esModule : desc.writable || desc.configurable)) {
+      desc = { enumerable: true, get: function() { return m[k]; } };
+    }
+    Object.defineProperty(o, k2, desc);
+}) : (function(o, m, k, k2) {
+    if (k2 === undefined) k2 = k;
+    o[k2] = m[k];
+}));
+var __setModuleDefault = (this && this.__setModuleDefault) || (Object.create ? (function(o, v) {
+    Object.defineProperty(o, "default", { enumerable: true, value: v });
+}) : function(o, v) {
+    o["default"] = v;
+});
+var __importStar = (this && this.__importStar) || (function () {
+    var ownKeys = function(o) {
+        ownKeys = Object.getOwnPropertyNames || function (o) {
+            var ar = [];
+            for (var k in o) if (Object.prototype.hasOwnProperty.call(o, k)) ar[ar.length] = k;
+            return ar;
+        };
+        return ownKeys(o);
+    };
+    return function (mod) {
+        if (mod && mod.__esModule) return mod;
+        var result = {};
+        if (mod != null) for (var k = ownKeys(mod), i = 0; i < k.length; i++) if (k[i] !== "default") __createBinding(result, mod, k[i]);
+        __setModuleDefault(result, mod);
+        return result;
+    };
+})();
+var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
+    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
+    return new (P || (P = Promise))(function (resolve, reject) {
+        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
+        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
+        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
+        step((generator = generator.apply(thisArg, _arguments || [])).next());
+    });
+};
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.orchestrateTestScenario = orchestrateTestScenario;
+const __typia_transform__validateReport = __importStar(require("typia/lib/internal/_validateReport.js"));
+const core_1 = require("@agentica/core");
+const typia_1 = __importDefault(require("typia"));
+const assertSchemaModel_1 = require("../../context/assertSchemaModel");
+const transformTestScenarioHistories_1 = require("./transformTestScenarioHistories");
+function orchestrateTestScenario(ctx) {
+    return __awaiter(this, void 0, void 0, function* () {
+        var _a, _b, _c, _d, _e, _f;
+        const files = Object.entries((_b = (_a = ctx.state().interface) === null || _a === void 0 ? void 0 : _a.files) !== null && _b !== void 0 ? _b : {})
+            .filter(([filename]) => {
+            return filename.startsWith("test/features/api/");
+        })
+            .reduce((acc, [filename, content]) => {
+            return Object.assign(acc, { [filename]: content });
+        }, {});
+        const operations = (_d = (_c = ctx.state().interface) === null || _c === void 0 ? void 0 : _c.document.operations) !== null && _d !== void 0 ? _d : [];
+        const endpoints = operations.map((it) => {
+            return {
+                method: it.method,
+                path: it.path,
+                summary: it.summary,
+                description: it.description,
+                parameters: it.parameters,
+                requestBody: it.requestBody,
+                responseBody: it.responseBody,
+            };
+        });
+        const start = new Date();
+        let completed = 0;
+        const scenarios = yield Promise.all(endpoints.map((endpoint, i, arr) => __awaiter(this, void 0, void 0, function* () {
+            var _a, _b;
+            const endponits = arr.filter((_el, j) => i !== j);
+            const rows = yield process(ctx, endpoint, endponits, files);
+            ctx.dispatch({
+                type: "testScenario",
+                scenarios: rows,
+                total: rows.flatMap((el) => el.scenarios).length,
+                step: (_b = (_a = ctx.state().test) === null || _a === void 0 ? void 0 : _a.step) !== null && _b !== void 0 ? _b : 0,
+                completed,
+                created_at: start.toISOString(),
+            });
+            return rows;
+        })));
+        return {
+            type: "testScenario",
+            scenarios: scenarios.flat(),
+            total: scenarios.flat().flatMap((el) => el.scenarios).length,
+            step: (_f = (_e = ctx.state().test) === null || _e === void 0 ? void 0 : _e.step) !== null && _f !== void 0 ? _f : 0,
+            completed,
+            created_at: start.toISOString(),
+        };
+    });
+}
+function process(ctx, endpoint, endpoints, files) {
+    return __awaiter(this, void 0, void 0, function* () {
+        var _a;
+        const pointer = {
+            value: null,
+        };
+        const agentica = new core_1.MicroAgentica({
+            model: ctx.model,
+            vendor: ctx.vendor,
+            config: Object.assign(Object.assign({}, ((_a = ctx.config) !== null && _a !== void 0 ? _a : { locale: "en-US" })), { systemPrompt: {
+                    describe: () => {
+                        return "Answer only 'completion' or 'failure'.";
+                    },
+                } }),
+            tokenUsage: ctx.usage(),
+            histories: [
+                ...(0, transformTestScenarioHistories_1.transformTestScenarioHistories)(ctx.state(), endpoints, files),
+            ],
+            controllers: [
+                createApplication({
+                    model: ctx.model,
+                    build: (next) => {
+                        pointer.value = next.scenarios;
+                    },
+                }),
+            ],
+        });
+        agentica.on("request", (event) => __awaiter(this, void 0, void 0, function* () {
+            if (event.body.tools)
+                event.body.tool_choice = "required";
+        }));
+        yield agentica.conversate([
+            "Make User Scenarios for below endpoint:",
+            "",
+            "```json",
+            JSON.stringify(endpoint, null, 2),
+            "```",
+        ].join("\n"));
+        if (pointer.value === null)
+            throw new Error("Failed to make scenarios.");
+        return pointer.value;
+    });
+}
+function createApplication(props) {
+    (0, assertSchemaModel_1.assertSchemaModel)(props.model);
+    const application = collection[props.model];
+    return {
+        protocol: "class",
+        name: "Make User Scenarios",
+        application,
+        execute: {
+            makeScenario: (next) => {
+                props.build(next);
+            },
+        },
+    };
+}
+const claude = {
+    model: "claude",
+    options: {
+        reference: true,
+        separate: null
+    },
+    functions: [
+        {
+            name: "makeScenario",
+            parameters: {
+                description: " Properties containing the endpoints and user scenarios.\n\n------------------------------\n\nCurrent Type: {@link IMakeScenarioProps}",
+                type: "object",
+                properties: {
+                    scenarios: {
+                        title: "Array of user scenarios",
+                        description: "Array of user scenarios.",
+                        type: "array",
+                        items: {
+                            description: "Current Type: {@link AutoBeTest.IScenario}",
+                            type: "object",
+                            properties: {
+                                endpoint: {
+                                    description: "Target API endpoint for user scenario generation.\n\nThis represents the single API endpoint that will be analyzed to generate\ncomprehensive user scenarios. The endpoint contains all technical\nspecifications needed to understand user interactions, including HTTP\nmethods, paths, parameters, request/response schemas, and authentication\nrequirements.\n\n## Core Purpose\n\n- Serves as the foundation for user-centric scenario generation\n- Contains complete API specification for understanding user capabilities\n- Provides schema constraints for realistic user data generation\n- Defines authentication and permission requirements for user context\n\n## User Scenario Context\n\nThis endpoint information enables generation of scenarios that consider:\n\n- What users can realistically accomplish with this endpoint\n- How users would naturally interact with the API functionality\n- What business value users seek from this endpoint\n- What constraints and limitations users will encounter\n- How authentication affects user access patterns\n- What data formats users need to provide or expect to receive\n\n## Single Endpoint Constraint\n\nEach scenario generated must interact with ONLY this endpoint. Scenarios\nshould not assume or require calls to other endpoints, ensuring each user\njourney is complete and testable in isolation.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
+                                    type: "object",
+                                    properties: {
+                                        path: {
+                                            title: "HTTP path of the API operation",
+                                            description: "HTTP path of the API operation.\n\nThe URL path for accessing this API operation, using path parameters\nenclosed in curly braces (e.g., `/shoppings/customers/sales/{saleId}`).\n\nIt must be corresponded to the {@link parameters path parameters}.\n\nThe path structure should clearly indicate which database entity this\noperation is manipulating, helping to ensure all entities have\nappropriate API coverage.",
+                                            type: "string"
+                                        },
+                                        method: {
+                                            title: "HTTP method of the API operation",
+                                            description: "HTTP method of the API operation.\n\nNote that, if the API operation has {@link requestBody}, method must not\nbe `get`.\n\nAlso, even though the API operation has been designed to only get\ninformation, but it needs complicated request information, it must be\ndefined as `patch` method with {@link requestBody} data specification.\n\n- `get`: get information\n- `patch`: get information with complicated request data\n  ({@link requestBody})\n- `post`: create new record\n- `put`: update existing record\n- `delete`: remove record",
+                                            oneOf: [
+                                                {
+                                                    "const": "get"
+                                                },
+                                                {
+                                                    "const": "post"
+                                                },
+                                                {
+                                                    "const": "put"
+                                                },
+                                                {
+                                                    "const": "delete"
+                                                },
+                                                {
+                                                    "const": "patch"
+                                                }
+                                            ]
+                                        }
+                                    },
+                                    required: [
+                                        "path",
+                                        "method"
+                                    ]
+                                },
+                                scenarios: {
+                                    title: "Comprehensive collection of user-centric scenarios for the endpoint",
+                                    description: "Comprehensive collection of user-centric scenarios for the endpoint.\n\nEach scenario represents a realistic user journey, intention, or\nsituation when interacting with this specific API endpoint. All scenarios\nare written from the user's perspective, focusing on what they want to\nachieve and how they naturally interact with the API functionality.\n\n## Scenario Coverage Framework\n\nThe scenarios must comprehensively cover all user interaction patterns:\n\n### 1. Happy Path User Journeys\n\n- Primary business use cases that users commonly perform\n- Standard workflows leading to successful user outcomes\n- Typical user behaviors with valid inputs and proper permissions\n- Most frequent user intentions and expected interactions\n\n### 2. Alternative User Approaches\n\n- Valid alternative ways users might achieve their goals\n- User scenarios utilizing optional parameters or different input patterns\n- Less common but legitimate user behaviors within normal boundaries\n- User experimentation with available API features\n\n### 3. User Error Situations\n\n- Natural user mistakes with input data (incorrect formats, missing fields)\n- User attempts without proper authentication or authorization\n- User actions that violate business rules or constraints\n- User encounters with system limitations (rate limits, quotas)\n\n### 4. Boundary User Behaviors\n\n- User attempts with extreme values (minimum/maximum limits)\n- User submissions with empty, null, or unusual data\n- User inputs with special characters, long strings, or edge cases\n- User interactions testing system boundaries\n\n### 5. Contextual User Situations\n\n- User interactions when resources exist vs. don't exist\n- Different user roles attempting the same actions\n- Time-sensitive user scenarios (expired sessions, scheduled operations)\n- User attempts during various system states\n\n## User-Centric Quality Standards\n\nEach scenario must:\n\n- Focus entirely on user motivation, context, and expected outcomes\n- Describe realistic business situations users actually encounter\n- Include clear user intent and the value they seek\n- Specify user-provided data and user-expected results\n- Be complete within the single endpoint constraint\n- Provide sufficient context for understanding user behavior patterns\n- Avoid technical implementation details or testing terminology\n\n## Single Endpoint Constraint Application\n\nEvery scenario must:\n\n- Complete the entire user journey using only this one endpoint\n- Not depend on or reference other API endpoints\n- Include all necessary context within the scenario itself\n- Represent a complete, self-contained user interaction\n\n## Business Value Focus\n\nThese user scenarios ensure:\n\n- Understanding of real user needs and behaviors\n- Comprehensive coverage of user interaction patterns\n- Proper handling of user errors and edge cases\n- Appropriate user feedback and experience design\n- Business rule validation from user perspective\n- Security and permission handling for different user contexts",
+                                    type: "array",
+                                    items: {
+                                        description: "Current Type: {@link AutoBeTest.Scenario}",
+                                        type: "object",
+                                        properties: {
+                                            functionName: {
+                                                title: "Descriptive function name derived from the user scenario",
+                                                description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\n- Must start with `test_` prefix (mandatory requirement)\n- Use snake_case formatting throughout\n- Include the primary user action (create, get, update, delete, list, etc.)\n- Specify the target resource (user, product, order, profile, etc.)\n- Add scenario-specific context (valid_data, invalid_email, not_found,\n  etc.)\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_[user_action]_[resource]_[scenario_context]`\n\nWhere:\n\n- `user_action`: What the user is trying to do\n- `resource`: What the user is interacting with\n- `scenario_context`: The specific situation or condition\n\n## User-Focused Examples\n\n- `test_create_user_profile_with_complete_information` - User providing all\n  available profile data\n- `test_retrieve_user_profile_when_profile_exists` - User accessing their\n  existing profile\n- `test_update_user_email_with_valid_new_address` - User changing their\n  email to a valid new one\n- `test_delete_user_account_when_user_lacks_permission` - User attempting\n  account deletion without authorization\n- `test_search_user_profiles_with_pagination_preferences` - User browsing\n  profiles with specific pagination\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions",
+                                                type: "string"
+                                            },
+                                            scenario: {
+                                                description: "Comprehensive user scenario description written from pure user\nperspective.\n\nThis describes a complete user journey, motivation, and expected outcome\nwhen interacting with the API endpoint. The description focuses entirely\non user intent, context, and natural behavior patterns rather than\ntechnical testing considerations.\n\n## User-Centric Writing Approach\n\n- Write as if describing a real person's experience and motivation\n- Focus on business context and user goals, not system functionality\n- Use natural language that business stakeholders would understand\n- Emphasize user value and expected benefits\n- Avoid technical terminology or implementation details\n\n## Required Content Elements\n\nEach scenario description must include:\n\n### 1. User Context and Motivation\n\n- Who is the user (role, background, current situation)\n- Why they need to perform this action (business motivation)\n- What problem they're trying to solve or goal they want to achieve\n- Any relevant background circumstances or constraints\n\n### 2. User Actions and Behavior\n\n- Specific steps the user takes to accomplish their goal\n- What information or data the user provides\n- How the user naturally approaches the interaction\n- Any decision-making process the user goes through\n\n### 3. User Expectations and Desired Outcomes\n\n- What the user expects to happen as a result\n- How the user will know if they were successful\n- What value or benefit the user expects to receive\n- How this fits into their broader workflow or objectives\n\n### 4. Business Impact and Value\n\n- How this scenario relates to business objectives\n- What business processes or workflows this supports\n- Why this user behavior matters to the organization\n- What risks or opportunities this scenario represents\n\n## Single Endpoint Constraint Integration\n\nEach scenario must:\n\n- Represent a complete user journey achievable through this single endpoint\n- Include all necessary context without referencing other API operations\n- Describe user expectations based solely on this endpoint's capabilities\n- Avoid scenarios that would logically require multiple API calls\n\n## Quality and Realism Standards\n\n- Base scenarios on realistic business situations\n- Include specific, concrete details rather than generic descriptions\n- Ensure scenarios reflect actual user behaviors and motivations\n- Make each scenario distinct and valuable for understanding user needs\n- Provide enough detail to understand full context without being verbose\n\n## User-Focused Example Scenarios\n\n- \"A busy project manager needs to quickly create a new team member's user\n  account during an onboarding meeting. They have all the necessary\n  information readily available and expect the account to be immediately\n  active so the new employee can start working right away.\"\n- \"A customer support representative is helping a customer who forgot their\n  login credentials. The customer provides their email address, and the\n  representative expects to quickly retrieve the associated account\n  information to assist with password recovery.\"\n- \"A system administrator discovers that a former employee's account is\n  still active after their departure. They need to immediately deactivate\n  this account for security purposes and expect confirmation that the\n  account can no longer be used to access company resources.\"\n\n## Language and Tone\n\n- Use active voice and present tense when describing user actions\n- Write in a narrative style that tells the user's story\n- Balance professional tone with human context\n- Ensure accessibility for both technical and non-technical readers\n- Maintain consistency in perspective throughout the description",
+                                                type: "string"
+                                            }
+                                        },
+                                        required: [
+                                            "functionName",
+                                            "scenario"
+                                        ]
+                                    }
+                                }
+                            },
+                            required: [
+                                "endpoint",
+                                "scenarios"
+                            ]
+                        }
+                    }
+                },
+                required: [
+                    "scenarios"
+                ],
+                additionalProperties: false,
+                $defs: {}
+            },
+            description: "Make user scenarios for the given endpoints.",
+            validate: (() => { const _io0 = input => Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.functionName && "string" === typeof input.scenario; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarios) || _report(_exceptionable, {
+                    path: _path + ".scenarios",
+                    expected: "Array<AutoBeTest.IScenario>",
+                    value: input.scenarios
+                })) && input.scenarios.map((elem, _index3) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                    path: _path + ".scenarios[" + _index3 + "]",
+                    expected: "AutoBeTest.IScenario",
+                    value: elem
+                })) && _vo1(elem, _path + ".scenarios[" + _index3 + "]", true && _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".scenarios[" + _index3 + "]",
+                    expected: "AutoBeTest.IScenario",
+                    value: elem
+                })).every(flag => flag) || _report(_exceptionable, {
+                    path: _path + ".scenarios",
+                    expected: "Array<AutoBeTest.IScenario>",
+                    value: input.scenarios
+                })].every(flag => flag); const _vo1 = (input, _path, _exceptionable = true) => [("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
+                    path: _path + ".endpoint",
+                    expected: "AutoBeOpenApi.IEndpoint",
+                    value: input.endpoint
+                })) && _vo2(input.endpoint, _path + ".endpoint", true && _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".endpoint",
+                    expected: "AutoBeOpenApi.IEndpoint",
+                    value: input.endpoint
+                }), (Array.isArray(input.scenarios) || _report(_exceptionable, {
+                    path: _path + ".scenarios",
+                    expected: "Array<AutoBeTest.Scenario>",
+                    value: input.scenarios
+                })) && input.scenarios.map((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                    path: _path + ".scenarios[" + _index4 + "]",
+                    expected: "AutoBeTest.Scenario",
+                    value: elem
+                })) && _vo3(elem, _path + ".scenarios[" + _index4 + "]", true && _exceptionable) || _report(_exceptionable, {
+                    path: _path + ".scenarios[" + _index4 + "]",
+                    expected: "AutoBeTest.Scenario",
+                    value: elem
+                })).every(flag => flag) || _report(_exceptionable, {
+                    path: _path + ".scenarios",
+                    expected: "Array<AutoBeTest.Scenario>",
+                    value: input.scenarios
+                })].every(flag => flag); const _vo2 = (input, _path, _exceptionable = true) => ["string" === typeof input.path || _report(_exceptionable, {
+                    path: _path + ".path",
+                    expected: "string",
+                    value: input.path
+                }), "get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method || _report(_exceptionable, {
+                    path: _path + ".method",
+                    expected: "(\"delete\" | \"get\" | \"patch\" | \"post\" | \"put\")",
+                    value: input.method
+                })].every(flag => flag); const _vo3 = (input, _path, _exceptionable = true) => ["string" === typeof input.functionName || _report(_exceptionable, {
+                    path: _path + ".functionName",
+                    expected: "string",
+                    value: input.functionName
+                }), "string" === typeof input.scenario || _report(_exceptionable, {
+                    path: _path + ".scenario",
+                    expected: "string",
+                    value: input.scenario
+                })].every(flag => flag); const __is = input => "object" === typeof input && null !== input && _io0(input); let errors; let _report; return input => {
+                if (false === __is(input)) {
+                    errors = [];
+                    _report = __typia_transform__validateReport._validateReport(errors);
+                    ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
+                        path: _path + "",
+                        expected: "IMakeScenarioProps",
+                        value: input
+                    })) && _vo0(input, _path + "", true) || _report(true, {
+                        path: _path + "",
+                        expected: "IMakeScenarioProps",
+                        value: input
+                    }))(input, "$input", true);
+                    const success = 0 === errors.length;
+                    return success ? {
+                        success,
+                        data: input
+                    } : {
+                        success,
+                        errors,
+                        data: input
+                    };
+                }
+                return {
+                    success: true,
+                    data: input
+                };
+            }; })()
+        }
+    ]
+};
+const collection = {
+    chatgpt: {
+        model: "chatgpt",
+        options: {
+            reference: true,
+            strict: false,
+            separate: null
+        },
+        functions: [
+            {
+                name: "makeScenario",
+                parameters: {
+                    description: " Properties containing the endpoints and user scenarios.\n\n------------------------------\n\nCurrent Type: {@link IMakeScenarioProps}",
+                    type: "object",
+                    properties: {
+                        scenarios: {
+                            title: "Array of user scenarios",
+                            description: "Array of user scenarios.",
+                            type: "array",
+                            items: {
+                                description: "Current Type: {@link AutoBeTest.IScenario}",
+                                type: "object",
+                                properties: {
+                                    endpoint: {
+                                        description: "Target API endpoint for user scenario generation.\n\nThis represents the single API endpoint that will be analyzed to generate\ncomprehensive user scenarios. The endpoint contains all technical\nspecifications needed to understand user interactions, including HTTP\nmethods, paths, parameters, request/response schemas, and authentication\nrequirements.\n\n## Core Purpose\n\n- Serves as the foundation for user-centric scenario generation\n- Contains complete API specification for understanding user capabilities\n- Provides schema constraints for realistic user data generation\n- Defines authentication and permission requirements for user context\n\n## User Scenario Context\n\nThis endpoint information enables generation of scenarios that consider:\n\n- What users can realistically accomplish with this endpoint\n- How users would naturally interact with the API functionality\n- What business value users seek from this endpoint\n- What constraints and limitations users will encounter\n- How authentication affects user access patterns\n- What data formats users need to provide or expect to receive\n\n## Single Endpoint Constraint\n\nEach scenario generated must interact with ONLY this endpoint. Scenarios\nshould not assume or require calls to other endpoints, ensuring each user\njourney is complete and testable in isolation.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
+                                        type: "object",
+                                        properties: {
+                                            path: {
+                                                title: "HTTP path of the API operation",
+                                                description: "HTTP path of the API operation.\n\nThe URL path for accessing this API operation, using path parameters\nenclosed in curly braces (e.g., `/shoppings/customers/sales/{saleId}`).\n\nIt must be corresponded to the {@link parameters path parameters}.\n\nThe path structure should clearly indicate which database entity this\noperation is manipulating, helping to ensure all entities have\nappropriate API coverage.",
+                                                type: "string"
+                                            },
+                                            method: {
+                                                title: "HTTP method of the API operation",
+                                                description: "HTTP method of the API operation.\n\nNote that, if the API operation has {@link requestBody}, method must not\nbe `get`.\n\nAlso, even though the API operation has been designed to only get\ninformation, but it needs complicated request information, it must be\ndefined as `patch` method with {@link requestBody} data specification.\n\n- `get`: get information\n- `patch`: get information with complicated request data\n  ({@link requestBody})\n- `post`: create new record\n- `put`: update existing record\n- `delete`: remove record",
+                                                type: "string",
+                                                "enum": [
+                                                    "get",
+                                                    "post",
+                                                    "put",
+                                                    "delete",
+                                                    "patch"
+                                                ]
+                                            }
+                                        },
+                                        required: [
+                                            "path",
+                                            "method"
+                                        ]
+                                    },
+                                    scenarios: {
+                                        title: "Comprehensive collection of user-centric scenarios for the endpoint",
+                                        description: "Comprehensive collection of user-centric scenarios for the endpoint.\n\nEach scenario represents a realistic user journey, intention, or\nsituation when interacting with this specific API endpoint. All scenarios\nare written from the user's perspective, focusing on what they want to\nachieve and how they naturally interact with the API functionality.\n\n## Scenario Coverage Framework\n\nThe scenarios must comprehensively cover all user interaction patterns:\n\n### 1. Happy Path User Journeys\n\n- Primary business use cases that users commonly perform\n- Standard workflows leading to successful user outcomes\n- Typical user behaviors with valid inputs and proper permissions\n- Most frequent user intentions and expected interactions\n\n### 2. Alternative User Approaches\n\n- Valid alternative ways users might achieve their goals\n- User scenarios utilizing optional parameters or different input patterns\n- Less common but legitimate user behaviors within normal boundaries\n- User experimentation with available API features\n\n### 3. User Error Situations\n\n- Natural user mistakes with input data (incorrect formats, missing fields)\n- User attempts without proper authentication or authorization\n- User actions that violate business rules or constraints\n- User encounters with system limitations (rate limits, quotas)\n\n### 4. Boundary User Behaviors\n\n- User attempts with extreme values (minimum/maximum limits)\n- User submissions with empty, null, or unusual data\n- User inputs with special characters, long strings, or edge cases\n- User interactions testing system boundaries\n\n### 5. Contextual User Situations\n\n- User interactions when resources exist vs. don't exist\n- Different user roles attempting the same actions\n- Time-sensitive user scenarios (expired sessions, scheduled operations)\n- User attempts during various system states\n\n## User-Centric Quality Standards\n\nEach scenario must:\n\n- Focus entirely on user motivation, context, and expected outcomes\n- Describe realistic business situations users actually encounter\n- Include clear user intent and the value they seek\n- Specify user-provided data and user-expected results\n- Be complete within the single endpoint constraint\n- Provide sufficient context for understanding user behavior patterns\n- Avoid technical implementation details or testing terminology\n\n## Single Endpoint Constraint Application\n\nEvery scenario must:\n\n- Complete the entire user journey using only this one endpoint\n- Not depend on or reference other API endpoints\n- Include all necessary context within the scenario itself\n- Represent a complete, self-contained user interaction\n\n## Business Value Focus\n\nThese user scenarios ensure:\n\n- Understanding of real user needs and behaviors\n- Comprehensive coverage of user interaction patterns\n- Proper handling of user errors and edge cases\n- Appropriate user feedback and experience design\n- Business rule validation from user perspective\n- Security and permission handling for different user contexts",
+                                        type: "array",
+                                        items: {
+                                            description: "Current Type: {@link AutoBeTest.Scenario}",
+                                            type: "object",
+                                            properties: {
+                                                functionName: {
+                                                    title: "Descriptive function name derived from the user scenario",
+                                                    description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\n- Must start with `test_` prefix (mandatory requirement)\n- Use snake_case formatting throughout\n- Include the primary user action (create, get, update, delete, list, etc.)\n- Specify the target resource (user, product, order, profile, etc.)\n- Add scenario-specific context (valid_data, invalid_email, not_found,\n  etc.)\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_[user_action]_[resource]_[scenario_context]`\n\nWhere:\n\n- `user_action`: What the user is trying to do\n- `resource`: What the user is interacting with\n- `scenario_context`: The specific situation or condition\n\n## User-Focused Examples\n\n- `test_create_user_profile_with_complete_information` - User providing all\n  available profile data\n- `test_retrieve_user_profile_when_profile_exists` - User accessing their\n  existing profile\n- `test_update_user_email_with_valid_new_address` - User changing their\n  email to a valid new one\n- `test_delete_user_account_when_user_lacks_permission` - User attempting\n  account deletion without authorization\n- `test_search_user_profiles_with_pagination_preferences` - User browsing\n  profiles with specific pagination\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions",
+                                                    type: "string"
+                                                },
+                                                scenario: {
+                                                    description: "Comprehensive user scenario description written from pure user\nperspective.\n\nThis describes a complete user journey, motivation, and expected outcome\nwhen interacting with the API endpoint. The description focuses entirely\non user intent, context, and natural behavior patterns rather than\ntechnical testing considerations.\n\n## User-Centric Writing Approach\n\n- Write as if describing a real person's experience and motivation\n- Focus on business context and user goals, not system functionality\n- Use natural language that business stakeholders would understand\n- Emphasize user value and expected benefits\n- Avoid technical terminology or implementation details\n\n## Required Content Elements\n\nEach scenario description must include:\n\n### 1. User Context and Motivation\n\n- Who is the user (role, background, current situation)\n- Why they need to perform this action (business motivation)\n- What problem they're trying to solve or goal they want to achieve\n- Any relevant background circumstances or constraints\n\n### 2. User Actions and Behavior\n\n- Specific steps the user takes to accomplish their goal\n- What information or data the user provides\n- How the user naturally approaches the interaction\n- Any decision-making process the user goes through\n\n### 3. User Expectations and Desired Outcomes\n\n- What the user expects to happen as a result\n- How the user will know if they were successful\n- What value or benefit the user expects to receive\n- How this fits into their broader workflow or objectives\n\n### 4. Business Impact and Value\n\n- How this scenario relates to business objectives\n- What business processes or workflows this supports\n- Why this user behavior matters to the organization\n- What risks or opportunities this scenario represents\n\n## Single Endpoint Constraint Integration\n\nEach scenario must:\n\n- Represent a complete user journey achievable through this single endpoint\n- Include all necessary context without referencing other API operations\n- Describe user expectations based solely on this endpoint's capabilities\n- Avoid scenarios that would logically require multiple API calls\n\n## Quality and Realism Standards\n\n- Base scenarios on realistic business situations\n- Include specific, concrete details rather than generic descriptions\n- Ensure scenarios reflect actual user behaviors and motivations\n- Make each scenario distinct and valuable for understanding user needs\n- Provide enough detail to understand full context without being verbose\n\n## User-Focused Example Scenarios\n\n- \"A busy project manager needs to quickly create a new team member's user\n  account during an onboarding meeting. They have all the necessary\n  information readily available and expect the account to be immediately\n  active so the new employee can start working right away.\"\n- \"A customer support representative is helping a customer who forgot their\n  login credentials. The customer provides their email address, and the\n  representative expects to quickly retrieve the associated account\n  information to assist with password recovery.\"\n- \"A system administrator discovers that a former employee's account is\n  still active after their departure. They need to immediately deactivate\n  this account for security purposes and expect confirmation that the\n  account can no longer be used to access company resources.\"\n\n## Language and Tone\n\n- Use active voice and present tense when describing user actions\n- Write in a narrative style that tells the user's story\n- Balance professional tone with human context\n- Ensure accessibility for both technical and non-technical readers\n- Maintain consistency in perspective throughout the description",
+                                                    type: "string"
+                                                }
+                                            },
+                                            required: [
+                                                "functionName",
+                                                "scenario"
+                                            ]
+                                        }
+                                    }
+                                },
+                                required: [
+                                    "endpoint",
+                                    "scenarios"
+                                ]
+                            }
+                        }
+                    },
+                    required: [
+                        "scenarios"
+                    ],
+                    additionalProperties: false,
+                    $defs: {}
+                },
+                description: "Make user scenarios for the given endpoints.",
+                validate: (() => { const _io0 = input => Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.functionName && "string" === typeof input.scenario; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarios) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<AutoBeTest.IScenario>",
+                        value: input.scenarios
+                    })) && input.scenarios.map((elem, _index3) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index3 + "]",
+                        expected: "AutoBeTest.IScenario",
+                        value: elem
+                    })) && _vo1(elem, _path + ".scenarios[" + _index3 + "]", true && _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index3 + "]",
+                        expected: "AutoBeTest.IScenario",
+                        value: elem
+                    })).every(flag => flag) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<AutoBeTest.IScenario>",
+                        value: input.scenarios
+                    })].every(flag => flag); const _vo1 = (input, _path, _exceptionable = true) => [("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    })) && _vo2(input.endpoint, _path + ".endpoint", true && _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    }), (Array.isArray(input.scenarios) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<AutoBeTest.Scenario>",
+                        value: input.scenarios
+                    })) && input.scenarios.map((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index4 + "]",
+                        expected: "AutoBeTest.Scenario",
+                        value: elem
+                    })) && _vo3(elem, _path + ".scenarios[" + _index4 + "]", true && _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index4 + "]",
+                        expected: "AutoBeTest.Scenario",
+                        value: elem
+                    })).every(flag => flag) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<AutoBeTest.Scenario>",
+                        value: input.scenarios
+                    })].every(flag => flag); const _vo2 = (input, _path, _exceptionable = true) => ["string" === typeof input.path || _report(_exceptionable, {
+                        path: _path + ".path",
+                        expected: "string",
+                        value: input.path
+                    }), "get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method || _report(_exceptionable, {
+                        path: _path + ".method",
+                        expected: "(\"delete\" | \"get\" | \"patch\" | \"post\" | \"put\")",
+                        value: input.method
+                    })].every(flag => flag); const _vo3 = (input, _path, _exceptionable = true) => ["string" === typeof input.functionName || _report(_exceptionable, {
+                        path: _path + ".functionName",
+                        expected: "string",
+                        value: input.functionName
+                    }), "string" === typeof input.scenario || _report(_exceptionable, {
+                        path: _path + ".scenario",
+                        expected: "string",
+                        value: input.scenario
+                    })].every(flag => flag); const __is = input => "object" === typeof input && null !== input && _io0(input); let errors; let _report; return input => {
+                    if (false === __is(input)) {
+                        errors = [];
+                        _report = __typia_transform__validateReport._validateReport(errors);
+                        ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
+                            path: _path + "",
+                            expected: "IMakeScenarioProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IMakeScenarioProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            }
+        ]
+    },
+    claude,
+    llama: claude,
+    deepseek: claude,
+    "3.1": claude,
+    "3.0": {
+        model: "3.0",
+        options: {
+            constraint: true,
+            recursive: 3,
+            separate: null
+        },
+        functions: [
+            {
+                name: "makeScenario",
+                parameters: {
+                    type: "object",
+                    properties: {
+                        scenarios: {
+                            type: "array",
+                            items: {
+                                type: "object",
+                                properties: {
+                                    endpoint: {
+                                        type: "object",
+                                        properties: {
+                                            path: {
+                                                type: "string",
+                                                title: "HTTP path of the API operation",
+                                                description: "HTTP path of the API operation.\n\nThe URL path for accessing this API operation, using path parameters\nenclosed in curly braces (e.g., `/shoppings/customers/sales/{saleId}`).\n\nIt must be corresponded to the {@link parameters path parameters}.\n\nThe path structure should clearly indicate which database entity this\noperation is manipulating, helping to ensure all entities have\nappropriate API coverage."
+                                            },
+                                            method: {
+                                                type: "string",
+                                                "enum": [
+                                                    "get",
+                                                    "post",
+                                                    "put",
+                                                    "delete",
+                                                    "patch"
+                                                ],
+                                                title: "HTTP method of the API operation",
+                                                description: "HTTP method of the API operation.\n\nNote that, if the API operation has {@link requestBody}, method must not\nbe `get`.\n\nAlso, even though the API operation has been designed to only get\ninformation, but it needs complicated request information, it must be\ndefined as `patch` method with {@link requestBody} data specification.\n\n- `get`: get information\n- `patch`: get information with complicated request data\n  ({@link requestBody})\n- `post`: create new record\n- `put`: update existing record\n- `delete`: remove record"
+                                            }
+                                        },
+                                        required: [
+                                            "path",
+                                            "method"
+                                        ],
+                                        description: "Target API endpoint for user scenario generation.\n\nThis represents the single API endpoint that will be analyzed to generate\ncomprehensive user scenarios. The endpoint contains all technical\nspecifications needed to understand user interactions, including HTTP\nmethods, paths, parameters, request/response schemas, and authentication\nrequirements.\n\n## Core Purpose\n\n- Serves as the foundation for user-centric scenario generation\n- Contains complete API specification for understanding user capabilities\n- Provides schema constraints for realistic user data generation\n- Defines authentication and permission requirements for user context\n\n## User Scenario Context\n\nThis endpoint information enables generation of scenarios that consider:\n\n- What users can realistically accomplish with this endpoint\n- How users would naturally interact with the API functionality\n- What business value users seek from this endpoint\n- What constraints and limitations users will encounter\n- How authentication affects user access patterns\n- What data formats users need to provide or expect to receive\n\n## Single Endpoint Constraint\n\nEach scenario generated must interact with ONLY this endpoint. Scenarios\nshould not assume or require calls to other endpoints, ensuring each user\njourney is complete and testable in isolation.\n\n------------------------------\n\nDescription of the current {@link AutoBeOpenApi.IEndpoint} type:\n\n> API endpoint information.",
+                                        additionalProperties: false
+                                    },
+                                    scenarios: {
+                                        type: "array",
+                                        items: {
+                                            type: "object",
+                                            properties: {
+                                                functionName: {
+                                                    type: "string",
+                                                    title: "Descriptive function name derived from the user scenario",
+                                                    description: "Descriptive function name derived from the user scenario.\n\nThe function name serves as a concise, technical identifier that clearly\nrepresents the specific user scenario being described. It should be\nimmediately understandable and directly correspond to the user situation\nwithout requiring additional context.\n\n## Naming Convention\n\n- Must start with `test_` prefix (mandatory requirement)\n- Use snake_case formatting throughout\n- Include the primary user action (create, get, update, delete, list, etc.)\n- Specify the target resource (user, product, order, profile, etc.)\n- Add scenario-specific context (valid_data, invalid_email, not_found,\n  etc.)\n\n## Content Structure\n\nFunction names should follow this pattern:\n`test_[user_action]_[resource]_[scenario_context]`\n\nWhere:\n\n- `user_action`: What the user is trying to do\n- `resource`: What the user is interacting with\n- `scenario_context`: The specific situation or condition\n\n## User-Focused Examples\n\n- `test_create_user_profile_with_complete_information` - User providing all\n  available profile data\n- `test_retrieve_user_profile_when_profile_exists` - User accessing their\n  existing profile\n- `test_update_user_email_with_valid_new_address` - User changing their\n  email to a valid new one\n- `test_delete_user_account_when_user_lacks_permission` - User attempting\n  account deletion without authorization\n- `test_search_user_profiles_with_pagination_preferences` - User browsing\n  profiles with specific pagination\n\n## Clarity Guidelines\n\n- Prioritize clarity over brevity\n- Avoid technical jargon or implementation terms\n- Use terminology that reflects user perspective\n- Ensure the name alone conveys the user's intent\n- Make it understandable to non-technical stakeholders\n- Keep consistent with user scenario description\n\n## Single Endpoint Alignment\n\nFunction names must reflect scenarios that:\n\n- Accomplish user goals through this single endpoint only\n- Don't imply dependency on other API operations\n- Represent complete user interactions"
+                                                },
+                                                scenario: {
+                                                    type: "string",
+                                                    description: "Comprehensive user scenario description written from pure user\nperspective.\n\nThis describes a complete user journey, motivation, and expected outcome\nwhen interacting with the API endpoint. The description focuses entirely\non user intent, context, and natural behavior patterns rather than\ntechnical testing considerations.\n\n## User-Centric Writing Approach\n\n- Write as if describing a real person's experience and motivation\n- Focus on business context and user goals, not system functionality\n- Use natural language that business stakeholders would understand\n- Emphasize user value and expected benefits\n- Avoid technical terminology or implementation details\n\n## Required Content Elements\n\nEach scenario description must include:\n\n### 1. User Context and Motivation\n\n- Who is the user (role, background, current situation)\n- Why they need to perform this action (business motivation)\n- What problem they're trying to solve or goal they want to achieve\n- Any relevant background circumstances or constraints\n\n### 2. User Actions and Behavior\n\n- Specific steps the user takes to accomplish their goal\n- What information or data the user provides\n- How the user naturally approaches the interaction\n- Any decision-making process the user goes through\n\n### 3. User Expectations and Desired Outcomes\n\n- What the user expects to happen as a result\n- How the user will know if they were successful\n- What value or benefit the user expects to receive\n- How this fits into their broader workflow or objectives\n\n### 4. Business Impact and Value\n\n- How this scenario relates to business objectives\n- What business processes or workflows this supports\n- Why this user behavior matters to the organization\n- What risks or opportunities this scenario represents\n\n## Single Endpoint Constraint Integration\n\nEach scenario must:\n\n- Represent a complete user journey achievable through this single endpoint\n- Include all necessary context without referencing other API operations\n- Describe user expectations based solely on this endpoint's capabilities\n- Avoid scenarios that would logically require multiple API calls\n\n## Quality and Realism Standards\n\n- Base scenarios on realistic business situations\n- Include specific, concrete details rather than generic descriptions\n- Ensure scenarios reflect actual user behaviors and motivations\n- Make each scenario distinct and valuable for understanding user needs\n- Provide enough detail to understand full context without being verbose\n\n## User-Focused Example Scenarios\n\n- \"A busy project manager needs to quickly create a new team member's user\n  account during an onboarding meeting. They have all the necessary\n  information readily available and expect the account to be immediately\n  active so the new employee can start working right away.\"\n- \"A customer support representative is helping a customer who forgot their\n  login credentials. The customer provides their email address, and the\n  representative expects to quickly retrieve the associated account\n  information to assist with password recovery.\"\n- \"A system administrator discovers that a former employee's account is\n  still active after their departure. They need to immediately deactivate\n  this account for security purposes and expect confirmation that the\n  account can no longer be used to access company resources.\"\n\n## Language and Tone\n\n- Use active voice and present tense when describing user actions\n- Write in a narrative style that tells the user's story\n- Balance professional tone with human context\n- Ensure accessibility for both technical and non-technical readers\n- Maintain consistency in perspective throughout the description"
+                                                }
+                                            },
+                                            required: [
+                                                "functionName",
+                                                "scenario"
+                                            ],
+                                            description: "Current Type: {@link AutoBeTest.Scenario}",
+                                            additionalProperties: false
+                                        },
+                                        title: "Comprehensive collection of user-centric scenarios for the endpoint",
+                                        description: "Comprehensive collection of user-centric scenarios for the endpoint.\n\nEach scenario represents a realistic user journey, intention, or\nsituation when interacting with this specific API endpoint. All scenarios\nare written from the user's perspective, focusing on what they want to\nachieve and how they naturally interact with the API functionality.\n\n## Scenario Coverage Framework\n\nThe scenarios must comprehensively cover all user interaction patterns:\n\n### 1. Happy Path User Journeys\n\n- Primary business use cases that users commonly perform\n- Standard workflows leading to successful user outcomes\n- Typical user behaviors with valid inputs and proper permissions\n- Most frequent user intentions and expected interactions\n\n### 2. Alternative User Approaches\n\n- Valid alternative ways users might achieve their goals\n- User scenarios utilizing optional parameters or different input patterns\n- Less common but legitimate user behaviors within normal boundaries\n- User experimentation with available API features\n\n### 3. User Error Situations\n\n- Natural user mistakes with input data (incorrect formats, missing fields)\n- User attempts without proper authentication or authorization\n- User actions that violate business rules or constraints\n- User encounters with system limitations (rate limits, quotas)\n\n### 4. Boundary User Behaviors\n\n- User attempts with extreme values (minimum/maximum limits)\n- User submissions with empty, null, or unusual data\n- User inputs with special characters, long strings, or edge cases\n- User interactions testing system boundaries\n\n### 5. Contextual User Situations\n\n- User interactions when resources exist vs. don't exist\n- Different user roles attempting the same actions\n- Time-sensitive user scenarios (expired sessions, scheduled operations)\n- User attempts during various system states\n\n## User-Centric Quality Standards\n\nEach scenario must:\n\n- Focus entirely on user motivation, context, and expected outcomes\n- Describe realistic business situations users actually encounter\n- Include clear user intent and the value they seek\n- Specify user-provided data and user-expected results\n- Be complete within the single endpoint constraint\n- Provide sufficient context for understanding user behavior patterns\n- Avoid technical implementation details or testing terminology\n\n## Single Endpoint Constraint Application\n\nEvery scenario must:\n\n- Complete the entire user journey using only this one endpoint\n- Not depend on or reference other API endpoints\n- Include all necessary context within the scenario itself\n- Represent a complete, self-contained user interaction\n\n## Business Value Focus\n\nThese user scenarios ensure:\n\n- Understanding of real user needs and behaviors\n- Comprehensive coverage of user interaction patterns\n- Proper handling of user errors and edge cases\n- Appropriate user feedback and experience design\n- Business rule validation from user perspective\n- Security and permission handling for different user contexts"
+                                    }
+                                },
+                                required: [
+                                    "endpoint",
+                                    "scenarios"
+                                ],
+                                description: "Current Type: {@link AutoBeTest.IScenario}",
+                                additionalProperties: false
+                            },
+                            title: "Array of user scenarios",
+                            description: "Array of user scenarios."
+                        }
+                    },
+                    required: [
+                        "scenarios"
+                    ],
+                    description: " Properties containing the endpoints and user scenarios.\n\n------------------------------\n\nCurrent Type: {@link IMakeScenarioProps}",
+                    additionalProperties: false
+                },
+                description: "Make user scenarios for the given endpoints.",
+                validate: (() => { const _io0 = input => Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io1(elem)); const _io1 = input => "object" === typeof input.endpoint && null !== input.endpoint && _io2(input.endpoint) && (Array.isArray(input.scenarios) && input.scenarios.every(elem => "object" === typeof elem && null !== elem && _io3(elem))); const _io2 = input => "string" === typeof input.path && ("get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method); const _io3 = input => "string" === typeof input.functionName && "string" === typeof input.scenario; const _vo0 = (input, _path, _exceptionable = true) => [(Array.isArray(input.scenarios) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<AutoBeTest.IScenario>",
+                        value: input.scenarios
+                    })) && input.scenarios.map((elem, _index3) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index3 + "]",
+                        expected: "AutoBeTest.IScenario",
+                        value: elem
+                    })) && _vo1(elem, _path + ".scenarios[" + _index3 + "]", true && _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index3 + "]",
+                        expected: "AutoBeTest.IScenario",
+                        value: elem
+                    })).every(flag => flag) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<AutoBeTest.IScenario>",
+                        value: input.scenarios
+                    })].every(flag => flag); const _vo1 = (input, _path, _exceptionable = true) => [("object" === typeof input.endpoint && null !== input.endpoint || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    })) && _vo2(input.endpoint, _path + ".endpoint", true && _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".endpoint",
+                        expected: "AutoBeOpenApi.IEndpoint",
+                        value: input.endpoint
+                    }), (Array.isArray(input.scenarios) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<AutoBeTest.Scenario>",
+                        value: input.scenarios
+                    })) && input.scenarios.map((elem, _index4) => ("object" === typeof elem && null !== elem || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index4 + "]",
+                        expected: "AutoBeTest.Scenario",
+                        value: elem
+                    })) && _vo3(elem, _path + ".scenarios[" + _index4 + "]", true && _exceptionable) || _report(_exceptionable, {
+                        path: _path + ".scenarios[" + _index4 + "]",
+                        expected: "AutoBeTest.Scenario",
+                        value: elem
+                    })).every(flag => flag) || _report(_exceptionable, {
+                        path: _path + ".scenarios",
+                        expected: "Array<AutoBeTest.Scenario>",
+                        value: input.scenarios
+                    })].every(flag => flag); const _vo2 = (input, _path, _exceptionable = true) => ["string" === typeof input.path || _report(_exceptionable, {
+                        path: _path + ".path",
+                        expected: "string",
+                        value: input.path
+                    }), "get" === input.method || "post" === input.method || "put" === input.method || "delete" === input.method || "patch" === input.method || _report(_exceptionable, {
+                        path: _path + ".method",
+                        expected: "(\"delete\" | \"get\" | \"patch\" | \"post\" | \"put\")",
+                        value: input.method
+                    })].every(flag => flag); const _vo3 = (input, _path, _exceptionable = true) => ["string" === typeof input.functionName || _report(_exceptionable, {
+                        path: _path + ".functionName",
+                        expected: "string",
+                        value: input.functionName
+                    }), "string" === typeof input.scenario || _report(_exceptionable, {
+                        path: _path + ".scenario",
+                        expected: "string",
+                        value: input.scenario
+                    })].every(flag => flag); const __is = input => "object" === typeof input && null !== input && _io0(input); let errors; let _report; return input => {
+                    if (false === __is(input)) {
+                        errors = [];
+                        _report = __typia_transform__validateReport._validateReport(errors);
+                        ((input, _path, _exceptionable = true) => ("object" === typeof input && null !== input || _report(true, {
+                            path: _path + "",
+                            expected: "IMakeScenarioProps",
+                            value: input
+                        })) && _vo0(input, _path + "", true) || _report(true, {
+                            path: _path + "",
+                            expected: "IMakeScenarioProps",
+                            value: input
+                        }))(input, "$input", true);
+                        const success = 0 === errors.length;
+                        return success ? {
+                            success,
+                            data: input
+                        } : {
+                            success,
+                            errors,
+                            data: input
+                        };
+                    }
+                    return {
+                        success: true,
+                        data: input
+                    };
+                }; })()
+            }
+        ]
+    },
+};
+//# sourceMappingURL=orchestrateTestScenario.js.map