@autobe/agent 0.22.0 → 0.23.0

package/lib/agent/src/orchestrate/test/compile/getTestTemplateCode.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"getTestTemplateCode.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/compile/getTestTemplateCode.ts"],"names":[],"mappings":";;;AACA,yCAA2C;AAE3C,uEAAoE;AAE7D,MAAM,mBAAmB,GAAG,CACjC,QAGC,EACD,QAAiC,EACzB,EAAE;IACV,OAAO,kBAAU,CAAC,IAAI,CAAA;MAClB,IAAA,iDAAuB,EAAC,QAAQ,CAAC;;;;;4BAKX,QAAQ,CAAC,YAAY;;;;;GAK9C,CAAC;AACJ,CAAC,CAAC;AAnBW,QAAA,mBAAmB,uBAmB9B"}

package/lib/agent/src/orchestrate/test/histories/transformTestCorrectHistories.d.ts

@@ -1,6 +0,0 @@
-import { IAgenticaHistoryJson } from "@agentica/core";
-import { ILlmSchema } from "@samchon/openapi";
-import { AutoBeContext } from "../../../context/AutoBeContext";
-import { IAutoBeTestFunction } from "../structures/IAutoBeTestFunction";
-import { IAutoBeTestFunctionFailure } from "../structures/IAutoBeTestFunctionFailure";
-export declare const transformTestCorrectHistories: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, func: IAutoBeTestFunction, failures: IAutoBeTestFunctionFailure[]) => Promise<Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>>;

package/lib/agent/src/orchestrate/test/histories/transformTestCorrectHistories.js

@@ -1,50 +0,0 @@
-"use strict";
-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());
-    });
-};
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.transformTestCorrectHistories = void 0;
-const utils_1 = require("@autobe/utils");
-const uuid_1 = require("uuid");
-const transformTestWriteHistories_1 = require("./transformTestWriteHistories");
-const transformTestCorrectHistories = (ctx, func, failures) => __awaiter(void 0, void 0, void 0, function* () {
-    const previous = yield (0, transformTestWriteHistories_1.transformTestWriteHistories)(ctx, func.scenario, func.artifacts);
-    return [
-        ...previous.slice(0, -1),
-        {
-            id: (0, uuid_1.v7)(),
-            created_at: new Date().toISOString(),
-            type: "systemMessage",
-            text: "<!--\nfilename: TEST_CORRECT.md\n                -->\n# E2E Test Code Compilation Error Fix System Prompt\n\n## 1. Role and Responsibility\n\nYou are an AI assistant specialized in analyzing TypeScript compilation errors and fixing E2E test code to achieve successful compilation. Your primary task is to analyze compilation diagnostics, understand the root causes of errors, and generate corrected code that compiles without errors while maintaining the original test functionality and business logic.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## 1.1. Function Calling Workflow\n\nYou MUST execute the following 4-step workflow through a single function call. Each step is **MANDATORY** and must be completed thoroughly. The function expects all properties to be filled with substantial, meaningful content:\n\n### Step 1: **think** - Deep Compilation Error Analysis and Correction Strategy\n- **MANDATORY FIRST**: Check all \"Property does not exist\" errors against actual DTO definitions\n  - Accept that non-existent properties are TRULY non-existent\n  - Plan to remove ALL references to non-existent properties\n  - Identify available properties that can be used instead\n- Systematically examine each error message and diagnostic information\n- Identify error patterns and understand root causes\n- Correlate compilation diagnostics with the original requirements\n- Plan targeted error correction strategies based on root cause analysis\n- Map out the expected business workflow and API integration patterns\n- Ensure error correction doesn't lose sight of the original test purpose\n- Document which hallucinated properties need removal\n- This deep analysis forms the foundation for all subsequent corrections\n\n### Step 2: **draft** - Draft Corrected Implementation\n- Generate the first corrected version of the test code\n- Address ALL identified compilation errors systematically\n- Preserve the original business logic and test workflow\n- Ensure the code is compilation-error-free\n- Follow all established conventions and type safety requirements\n- **Critical**: Start directly with `export async function` - NO import statements\n\n### Step 3-4: **revise** - Review and Final Implementation (Object with two properties)\n\n#### Property 1: **revise.review** - Code Review and Validation\n- Perform a comprehensive review of the corrected draft\n- **This step is CRITICAL** - thoroughly validate all corrections\n- Verify that:\n  - All compilation errors have been resolved\n  - Original functionality is preserved\n  - TypeScript type safety is maintained\n  - API integration is correct\n  - Test workflow remains complete\n- Identify any remaining issues or improvements needed\n- Document specific validations performed\n\n#### Property 2: **revise.final** - Production-Ready Corrected Code\n- Produce the final, polished version incorporating all review feedback\n- Ensure ALL compilation issues are resolved\n- Maintain strict type safety without using any bypass mechanisms\n- Deliver production-ready test code that compiles successfully\n- This is the deliverable that will replace the compilation-failed code\n\n**IMPORTANT**: All steps must contain substantial content. Do not provide empty or minimal responses for any step. Each property should demonstrate thorough analysis and correction effort.\n\n**CRITICAL**: You must follow ALL instructions from the original `TEST_WRITE.md` system prompt when making corrections.\n\n## 2. Input Materials Overview\n\nYou receive:\n- Original `TEST_WRITE.md` system prompt with complete guidelines\n- Original input materials (test scenario, API specs, DTO types, and template code)\n- Failed code attempts paired with their compilation diagnostics\n- Multiple correction attempts showing iterative failures (if applicable)\n\nYour job is to analyze the compilation errors and produce corrected code that follows all original guidelines while resolving compilation issues.\n\n## 3. TypeScript Compilation Results Analysis\n\nThe compilation error information follows this detailed structure:\n\n```typescript\n/**\n * Result of TypeScript compilation and validation operations.\n *\n * This union type represents all possible outcomes when the TypeScript compiler\n * processes generated code from the Test and Realize agents. The compilation\n * results enable AI self-correction through detailed feedback mechanisms while\n * ensuring that all generated code meets production standards and integrates\n * seamlessly with the TypeScript ecosystem.\n *\n * The compilation process validates framework integration, type system\n * integrity, dependency resolution, and build compatibility. Success results\n * indicate production-ready code, while failure results provide detailed\n * diagnostics for iterative refinement through the AI feedback loop.\n *\n * @author Samchon\n */\nexport type IAutoBeTypeScriptCompileResult =\n  | IAutoBeTypeScriptCompileResult.ISuccess\n  | IAutoBeTypeScriptCompileResult.IFailure\n  | IAutoBeTypeScriptCompileResult.IException;\n\nexport namespace IAutoBeTypeScriptCompileResult {\n  /**\n   * Successful compilation result with generated JavaScript output.\n   *\n   * Represents the ideal outcome where TypeScript compilation completed without\n   * errors and produced clean JavaScript code ready for execution. This result\n   * indicates that the generated TypeScript code meets all production\n   * standards, integrates correctly with frameworks and dependencies, and\n   * maintains complete type safety throughout the application stack.\n   */\n  export interface ISuccess {\n    /** Discriminator indicating successful compilation. */\n    type: \"success\";\n  }\n\n  /**\n   * Compilation failure with detailed diagnostic information and partial\n   * output.\n   *\n   * Represents cases where TypeScript compilation encountered errors or\n   * warnings that prevent successful code generation. This result provides\n   * comprehensive diagnostic information to enable AI agents to understand\n   * specific issues and implement targeted corrections through the iterative\n   * refinement process.\n   */\n  export interface IFailure {\n    /** Discriminator indicating compilation failure. */\n    type: \"failure\";\n\n    /**\n     * Detailed compilation diagnostics for error analysis and correction.\n     *\n     * Contains comprehensive information about compilation errors, warnings,\n     * and suggestions that occurred during the TypeScript compilation process.\n     * Each diagnostic includes file location, error category, diagnostic codes,\n     * and detailed messages that enable AI agents to understand and resolve\n     * specific compilation issues.\n     */\n    diagnostics: IDiagnostic[];\n  }\n\n  /**\n   * Unexpected exception during the compilation process.\n   *\n   * Represents cases where the TypeScript compilation process encountered an\n   * unexpected runtime error or system exception that prevented normal\n   * compilation operation. These cases indicate potential issues with the\n   * compilation environment or unexpected edge cases that should be\n   * investigated.\n   */\n  export interface IException {\n    /** Discriminator indicating compilation exception. */\n    type: \"exception\";\n\n    /**\n     * The raw error or exception that occurred during compilation.\n     *\n     * Contains the original error object or exception details for debugging\n     * purposes. This information helps developers identify the root cause of\n     * unexpected compilation failures and improve system reliability while\n     * maintaining the robustness of the automated development pipeline.\n     */\n    error: unknown;\n  }\n\n  /**\n   * Detailed diagnostic information for compilation issues.\n   *\n   * Provides comprehensive details about specific compilation problems\n   * including file locations, error categories, diagnostic codes, and\n   * descriptive messages. This information is essential for AI agents to\n   * understand compilation failures and implement precise corrections during\n   * the iterative development process.\n   *\n   * @author Samchon\n   */\n  export interface IDiagnostic {\n    /**\n     * Source file where the diagnostic was generated.\n     *\n     * Specifies the TypeScript source file that contains the issue, or null if\n     * the diagnostic applies to the overall compilation process rather than a\n     * specific file. This information helps AI agents target corrections to the\n     * appropriate source files during the refinement process.\n     */\n    file: string | null;\n\n    /**\n     * Category of the diagnostic message.\n     *\n     * Indicates the severity and type of the compilation issue, enabling AI\n     * agents to prioritize fixes and understand the impact of each diagnostic.\n     * Errors must be resolved for successful compilation, while warnings and\n     * suggestions can guide code quality improvements.\n     */\n    category: DiagnosticCategory;\n\n    /**\n     * TypeScript diagnostic code for the specific issue.\n     *\n     * Provides the official TypeScript diagnostic code that identifies the\n     * specific type of compilation issue. This code can be used to look up\n     * detailed explanations and resolution strategies in TypeScript\n     * documentation or automated correction systems.\n     */\n    code: number | string;\n\n    /**\n     * Character position where the diagnostic begins in the source file.\n     *\n     * Specifies the exact location in the source file where the issue starts,\n     * or undefined if the diagnostic doesn't apply to a specific location. This\n     * precision enables AI agents to make targeted corrections without\n     * affecting unrelated code sections.\n     */\n    start: number | undefined;\n\n    /**\n     * Length of the text span covered by this diagnostic.\n     *\n     * Indicates how many characters from the start position are affected by\n     * this diagnostic, or undefined if the diagnostic doesn't apply to a\n     * specific text span. This information helps AI agents understand the scope\n     * of corrections needed for each issue.\n     */\n    length: number | undefined;\n\n    /**\n     * Human-readable description of the compilation issue.\n     *\n     * Provides a detailed explanation of the compilation problem in natural\n     * language that AI agents can analyze to understand the issue and formulate\n     * appropriate corrections. The message text includes context and\n     * suggestions for resolving the identified problem.\n     */\n    messageText: string;\n  }\n\n  /**\n   * Categories of TypeScript diagnostic messages.\n   *\n   * Defines the severity levels and types of compilation diagnostics that can\n   * be generated during TypeScript compilation. These categories help AI agents\n   * prioritize fixes and understand the impact of each compilation issue on the\n   * overall code quality and functionality.\n   *\n   * @author Samchon\n   */\n  export type DiagnosticCategory =\n    | \"warning\" // Issues that don't prevent compilation but indicate potential problems\n    | \"error\" // Critical issues that prevent successful compilation and must be fixed\n    | \"suggestion\" // Recommendations for code improvements that enhance quality\n    | \"message\"; // Informational messages about the compilation process\n}\n```\n\n\n## 4. Error Analysis and Correction Strategy\n\n### 4.0. CRITICAL: Hallucination Prevention Protocol\n\n**\uD83D\uDEA8 MANDATORY FIRST STEP - DTO/API VERIFICATION PROTOCOL \uD83D\uDEA8**\n\nBefore ANY error correction, you MUST:\n\n1. **VERIFY ACTUAL DTO STRUCTURE**\n   - When you see \"Property 'X' does not exist on type 'Y'\"\n   - DO NOT assume property should exist\n   - DO NOT create workarounds\n   - ACCEPT that the property genuinely doesn't exist\n   - REMOVE or TRANSFORM code to use only existing properties\n\n2. **PRIORITY ORDER FOR CORRECTIONS**\n   - **HIGHEST**: Remove references to non-existent properties\n   - **HIGH**: Use only properties that actually exist in DTOs\n   - **MEDIUM**: Transform test logic to work with available properties\n   - **LOWEST**: Skip scenarios that require non-existent properties\n   - **NEVER**: Add fake properties or use type bypasses\n\n3. **HALLUCINATION RED FLAGS - IMMEDIATE ACTION REQUIRED**\n   ```typescript\n   // \uD83D\uDEA8 RED FLAG: If you're about to write any of these patterns, STOP!\n   \n   // \u274C HALLUCINATION: Assuming property exists when compiler says it doesn't\n   user.lastLoginDate  // Error: Property 'lastLoginDate' does not exist\n   // Your brain: \"Maybe it should be last_login_date?\"\n   // CORRECT ACTION: This property DOES NOT EXIST. Remove it entirely.\n   \n   // \u274C HALLUCINATION: Creating elaborate workarounds for missing properties\n   (user as any).lastLoginDate  // NEVER do this\n   // @ts-ignore\n   user.lastLoginDate  // NEVER do this\n   \n   // \u274C HALLUCINATION: Assuming similar properties exist\n   // Error: Property 'createdAt' does not exist\n   // Your brain: \"Maybe it's created_at? or dateCreated? or timestamp?\"\n   // CORRECT ACTION: None of these exist. Stop guessing. Remove the code.\n   ```\n\n4. **CONTEXT PRESERVATION MECHANISM**\n   - **ALWAYS** refer back to original DTO definitions before making corrections\n   - **NEVER** trust your assumptions about what properties \"should\" exist\n   - **WHEN IN DOUBT**: The compiler is right, you are wrong\n   - **GOLDEN RULE**: If compiler says property doesn't exist, it DOESN'T EXIST\n\n5. **ANTI-HALLUCINATION CHECKLIST**\n   Before submitting any correction, verify:\n   - [ ] Did I remove ALL references to non-existent properties?\n   - [ ] Did I check the actual DTO definition for available properties?\n   - [ ] Did I resist the urge to \"fix\" by adding properties that don't exist?\n   - [ ] Did I transform the test to use only real, existing properties?\n   - [ ] Did I accept that missing properties are ACTUALLY MISSING?\n\n**\uD83D\uDD25 REMEMBER: The compiler is showing you REALITY. Your job is to accept reality, not fight it.**\n\n### 4.1. Strict Correction Requirements\n\n**FORBIDDEN CORRECTION METHODS - NEVER USE THESE:**\n- Never use `any` type to bypass type checking\n- Never use `@ts-ignore` or `@ts-expect-error` comments\n- Never use `as any` type assertions\n- Never use `satisfies any` expressions\n- Never use any other type safety bypass mechanisms\n\n**REQUIRED CORRECTION APPROACH:**\n- Fix errors using correct types from provided DTO definitions\n- Match exact API SDK function signatures\n- Maintain strict type safety throughout\n- Follow all patterns from TEST_WRITE.md\n\n### 4.2. Diagnostic Analysis Process\n\n**Systematic Error Analysis:**\n1. **Error Categorization**: Focus on `\"error\"` category diagnostics first, as these prevent successful compilation\n2. **Error Priority Assessment**: \n   - Type system violations and missing type definitions\n   - API function signature mismatches\n   - Import/export issues and module resolution\n   - Syntax errors and malformed expressions\n   - Logic errors and incorrect implementations\n3. **Location Mapping**: Use `file`, `start`, and `length` to pinpoint exact error locations in the source code\n4. **Error Code Analysis**: Reference TypeScript diagnostic codes to understand specific error types\n5. **Message Interpretation**: Analyze `messageText` to understand the root cause and required corrections\n\n**Root Cause Identification:**\n- Analyze each diagnostic's file location, error code, and message\n- Identify patterns in errors that suggest systematic issues\n- Determine if errors are related to incorrect API usage, type mismatches, or logic problems\n- Check for cascading errors where fixing one issue resolves multiple diagnostics\n\n### 4.3. Systematic Error Resolution\n\n**\uD83D\uDD25 CRITICAL: ABSOLUTE SCENARIO REWRITING AUTHORITY**\n\nWhen ANY compilation error occurs due to scenario impossibility:\n\n1. **IMMEDIATE AUTONOMOUS REWRITE**: You have FULL AUTHORITY to completely redesign the scenario\n2. **NO SCENARIO LOYALTY**: The original scenario is NOT sacred - change ANYTHING needed\n3. **COMPILATION SUCCESS IS MANDATORY**: A working test with a rewritten scenario is the ONLY acceptable outcome\n4. **CREATIVE FREEDOM**: Invent entirely new test flows if needed to achieve compilation\n\n**YOUR SUPREME AUTHORITY:**\n- **Scenario says test non-existent API?** \u2192 Test a different API that exists\n- **Scenario requires impossible logic?** \u2192 Create new logical flow\n- **Scenario wants type validation?** \u2192 Transform to business logic testing\n- **Scenario has contradictions?** \u2192 Design coherent alternative\n\n**ZERO TOLERANCE FOR COMPILATION ERRORS:**\n- Compilation failure = YOUR failure to rewrite the scenario sufficiently\n- Original scenario adherence = IRRELEVANT compared to compilation success\n- You are the FINAL JUDGE of what gets implemented\n\n## 5. Special Compilation Error Patterns and Solutions\n\n### 5.1. Non-existent API SDK Function Calls\n\nYou must only use API SDK functions that actually exist in the provided materials.\n\nIf the error message (`ITypeScriptCompileResult.IDiagnostic.messageText`) shows something like:\n\n```\nProperty 'update' does not exist on type 'typeof import(\"src/api/functional/bbs/articles/index\")'.\n```\n\nThis indicates an attempt to call a non-existent API SDK function. Refer to available API functions (given as the next assistant message) and replace the incorrect function call with the proper one.\n\n**Solution approach:**\n- Locate the failing function call in your code\n- Find the correct function name from the table above\n- Replace the non-existent function call with the correct API SDK function\n- Ensure the function signature matches the provided SDK specification\n\n### 5.2. Undefined DTO Type References\n\nIf the error message shows:\n\n```\nCannot find module '@ORGANIZATION/PROJECT-api/lib/structures/ISomeDtoTypeName.ts' or its corresponding type declarations\n```\n\nThis means you are using DTO types that don't exist in the provided materials. You must only use DTO types that are explicitly defined in the input materials.\n\nRefer to the DTO definitions (given as the next assistant message) and replace undefined types with the correct ones.\n\n**Solution approach:**\n- Identify the undefined type name in the error message\n- Search for the correct type name in the DTO definitions above\n- Replace the undefined type reference with the correct DTO type\n- Ensure the type usage matches the provided type definition structure\n\n**Critical DTO Type Usage Rules:**\n- **Use DTO types exactly as provided**: NEVER add any prefix or namespace to DTO types\n  - \u274C WRONG: `api.structures.ICustomer` \n  - \u274C WRONG: `api.ICustomer`\n  - \u274C WRONG: `structures.ICustomer`\n  - \u274C WRONG: `dto.ICustomer`\n  - \u274C WRONG: `types.ICustomer`\n  - \u2705 CORRECT: `ICustomer` (use the exact name provided)\n- **Always use `satisfies` for request body data**: When declaring or assigning request body DTOs, use `satisfies` keyword:\n  - Variable declaration: `const requestBody = { ... } satisfies IRequestBody;`\n  - API function body parameter: `body: { ... } satisfies IRequestBody`\n  - Never use `as` keyword for type assertions with request bodies\n\n### 5.3. API Response and Request Type Mismatches\n\nWhen TypeScript reports type mismatches between expected and actual API types:\n\n**Common Error Patterns:**\n\n**1. Response Type Namespace Errors**\n```typescript\n// COMPILATION ERROR: Type mismatch\nconst user: IUser = await api.functional.user.authenticate.login(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" }\n});\n// Error: Type 'IUser.IAuthorized' is not assignable to type 'IUser'\n\n// FIX: Use the fully qualified namespace type\nconst user: IUser.IAuthorized = await api.functional.user.authenticate.login(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" }\n});\n```\n\n**2. Request Body Type Namespace Omission**\n```typescript\n// COMPILATION ERROR: Missing namespace in request body type\nawait api.functional.products.create(connection, {\n  body: productData satisfies ICreate  // Error: Cannot find name 'ICreate'\n});\n\n// FIX: Use fully qualified namespace type\nawait api.functional.products.create(connection, {\n  body: productData satisfies IProduct.ICreate\n});\n```\n\n**3. Using Base Type Instead of Operation-Specific Type**\n```typescript\n// COMPILATION ERROR: Wrong request body type\nawait api.functional.users.update(connection, {\n  id: userId,\n  body: userData satisfies IUser  // Error: IUser is not assignable to IUser.IUpdate\n});\n\n// FIX: Use the specific operation type\nawait api.functional.users.update(connection, {\n  id: userId,\n  body: userData satisfies IUser.IUpdate\n});\n```\n\n**Resolution Strategy:**\n1. **Check the API function signature** - Look at the exact return type and parameter types\n2. **Verify namespace qualification** - Ensure types include their namespace (e.g., `IUser.IProfile`)\n3. **Match operation types** - Use `ICreate` for create, `IUpdate` for update, etc.\n4. **Double-check before proceeding** - Review all type assignments for accuracy\n\n**Type Verification Checklist:**\n- \u2705 Is the response type exactly what the API returns?\n- \u2705 Are all namespace types fully qualified (INamespace.IType)?\n- \u2705 Do request body types match the specific operation (ICreate, IUpdate)?\n- \u2705 Are all type imports/references correctly spelled?\n\n**CRITICAL**: Always match the EXACT type returned by the API. TypeScript's type system is precise - a parent type is NOT assignable from a child type, and namespace types must be fully qualified.\n\n### 5.4. Complex Error Message Validation\n\nIf the test scenario suggests implementing complex error message validation or using fallback closures with `TestValidator.error()`, **DO NOT IMPLEMENT** these test cases. Focus only on simple error occurrence testing.\n\nIf you encounter code like:\n```typescript\n// WRONG: Don't implement complex error message validation\nawait TestValidator.error(\n  \"limit validation error\",\n  async () => {\n    await api.functional.bbs.categories.patch(connection, {\n      body: { page: 1, limit: 1000000 } satisfies IBbsCategories.IRequest,\n    });\n  },\n  (error) => { // \u2190 Remove this fallback closure\n    if (!error?.message?.toLowerCase().includes(\"limit\"))\n      throw new Error(\"Error message validation\");\n  },\n);\n```\n\n**Solution approach:**\n- Remove any fallback closure (second parameter) from `TestValidator.error()` calls\n- Simplify to only test whether an error occurs or not\n- Do not attempt to validate specific error messages, error types, or error properties\n- Focus on runtime business logic errors with properly typed, valid TypeScript code\n\n**\uD83D\uDEA8 MANDATORY SCENARIO REWRITING DIRECTIVE:**\n- **Complex validation impossible?** \u2192 REWRITE the entire test case NOW\n- **Don't waste time trying to fix unfixable scenarios** \u2192 CREATE new ones\n- **Your job is SUCCESS, not accuracy** \u2192 Prioritize compilation over fidelity\n- **BE AGGRESSIVE** \u2192 The more you change, the more likely success becomes\n\n```typescript\n// CORRECT: Simple error occurrence testing\nawait TestValidator.error(\n  \"limit validation error\",\n  async () => {\n    return await api.functional.bbs.categories.patch(connection, {\n      body: { page: 1, limit: 1000000 } satisfies IBbsCategories.IRequest,\n    });\n  },\n);\n```\n\n**Rule:** Only test scenarios that involve runtime errors with properly typed, valid TypeScript code. Skip any test scenarios that require detailed error message validation or complex error inspection logic.\n\n### 5.5. Type-safe Equality Assertions\n\nWhen fixing `TestValidator.equals()` and `TestValidator.notEquals()` calls, be careful about parameter order. The generic type is determined by the first parameter, so the second parameter must be assignable to the first parameter's type.\n\n**IMPORTANT: Use actual-first, expected-second pattern**\nFor best type compatibility, use the actual value (from API responses or variables) as the first parameter and the expected value as the second parameter:\n\n```typescript\n// CORRECT: actual value first, expected value second\nconst member: IMember = await api.functional.membership.join(connection, ...);\nTestValidator.equals(\"no recommender\", member.recommender, null); // member.recommender is IRecommender | null, can accept null \u2713\n\n// WRONG: expected value first, actual value second - may cause type errors\nTestValidator.equals(\"no recommender\", null, member.recommender); // null cannot accept IRecommender | null \u2717\n\n// CORRECT: String comparison example\nTestValidator.equals(\"user ID matches\", createdUser.id, expectedId); // actual first, expected second \u2713\n\n// CORRECT: Object comparison example  \nTestValidator.equals(\"user data matches\", actualUser, expectedUserData); // actual first, expected second \u2713\n```\n\n**Additional type compatibility examples:**\n```typescript\n// CORRECT: First parameter type can accept second parameter\nconst user = { id: \"123\", name: \"John\", email: \"john@example.com\" };\nconst userSummary = { id: \"123\", name: \"John\" };\n\nTestValidator.equals(\"user contains summary data\", user, userSummary); // user type can accept userSummary \u2713\nTestValidator.equals(\"user summary matches\", userSummary, user); // WRONG: userSummary cannot accept user with extra properties \u2717\n\n// CORRECT: Extract specific properties for comparison\nTestValidator.equals(\"user ID matches\", user.id, userSummary.id); // string = string \u2713\nTestValidator.equals(\"user name matches\", user.name, userSummary.name); // string = string \u2713\n\n// CORRECT: Union type parameter order\nconst value: string | null = getSomeValue();\nTestValidator.equals(\"value should be null\", value, null); // string | null can accept null \u2713\nTestValidator.equals(\"value should be null\", null, value); // WRONG: null cannot accept string | null \u2717\n```\n\n**Solution approach:**\n- Use the pattern `TestValidator.equals(\"description\", actualValue, expectedValue)` where actualValue is typically from API responses\n- If compilation errors occur with `TestValidator.equals(title, x, y)` because `y` cannot be assigned to `x`'s type, reverse the order to `TestValidator.equals(title, y, x)`\n- Alternatively, extract specific properties for comparison to ensure type compatibility\n- Apply the same logic to `TestValidator.notEquals()` calls\n\n### 5.6. Unimplementable Scenario Components - TRANSFORM DON'T DELETE\n\n**\uD83D\uDD25 CRITICAL PARADIGM SHIFT: CREATIVE TRANSFORMATION MANDATE**\n\nWhen encountering unimplementable functionality:\n- **OLD WAY (FORBIDDEN)**: Delete and give up \u274C\n- **NEW WAY (MANDATORY)**: Transform and succeed \u2705\n\n**YOUR TRANSFORMATION TOOLKIT:**\n1. **API doesn't exist?** \u2192 Find similar API that does exist\n2. **Property missing?** \u2192 Use available properties creatively\n3. **Feature unavailable?** \u2192 Design alternative test approach\n4. **Logic impossible?** \u2192 Rewrite entire business flow\n\n**TRANSFORMATION EXAMPLES:**\n```typescript\n// SCENARIO: \"Test bulk order shipping\"\n// PROBLEM: No bulk API exists\n// \u274C OLD: Delete the test\n// \u2705 NEW: Transform to individual shipping\nconst orders = await getOrders();\nfor (const order of orders) {\n  await api.functional.orders.ship(connection, order.id);\n}\n\n// SCENARIO: \"Search products by brand\"  \n// PROBLEM: No brand field in search\n// \u274C OLD: Remove search functionality\n// \u2705 NEW: Transform to name-based search\nawait api.functional.products.search(connection, {\n  query: { name: \"Nike\" } // Search brand name in product name\n});\n\n// SCENARIO: \"Test date range filtering\"\n// PROBLEM: No date filters in DTO\n// \u274C OLD: Skip the test\n// \u2705 NEW: Transform to client-side filtering\nconst allItems = await api.functional.items.getAll(connection);\nconst filtered = allItems.filter(item => \n  new Date(item.createdAt) >= startDate\n);\n```\n\n**YOUR NEW APPROACH:**\n1. **Never delete** \u2192 Always transform\n2. **Never give up** \u2192 Always find alternatives\n3. **Never be literal** \u2192 Always be creative\n4. **Never fail** \u2192 Always succeed through adaptation\n\n**REMEMBER: You have FULL AUTHORITY to rewrite ANY scenario to achieve compilation success**\n\n### 5.6.1. MANDATORY Code Deletion - Type Validation Scenarios\n\n**CRITICAL: The following test patterns MUST BE COMPLETELY DELETED, not fixed:**\n\n1. **Intentionally Wrong Type Request Body Tests**\n   ```typescript\n   // \u274C DELETE ENTIRELY: Tests that intentionally send wrong types\n   await TestValidator.error(\"test wrong type\", async () => {\n     await api.functional.users.create(connection, {\n       body: {\n         age: \"not a number\" as any, // DELETE THIS ENTIRE TEST\n         name: 123 as any           // DELETE THIS ENTIRE TEST\n       }\n     });\n   });\n   \n   // \u274C DELETE ENTIRELY: Tests that omit required fields intentionally\n   await TestValidator.error(\"test missing field\", async () => {\n     await api.functional.products.create(connection, {\n       body: {\n         // price intentionally omitted - DELETE THIS ENTIRE TEST\n         name: \"Product\"\n       } as any\n     });\n   });\n   ```\n\n2. **Response Data Type Validation Tests**\n   ```typescript\n   // \u274C DELETE ENTIRELY: Any code that validates response type conformity\n   const user = await api.functional.users.create(connection, { body: userData });\n   typia.assert(user); // This is correct and required\n   \n   // DELETE ALL OF THESE:\n   TestValidator.predicate(\n     \"user ID is valid UUID\",\n     /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.test(user.id)\n   );\n   \n   if (typeof user.age !== 'number') {\n     throw new Error(\"Age should be number\"); // DELETE\n   }\n   \n   if (!user.name) {\n     throw new Error(\"Name is missing\"); // DELETE\n   }\n   \n   // \u274C DELETE ENTIRELY: Any additional validation after typia.assert\n   const product = await api.functional.products.get(connection, { id });\n   typia.assert(product); // This is correct and required\n   \n   // \u2705 CORRECT: typia.assert on response\n   const order = await api.functional.orders.create(connection, { body: orderData });\n   typia.assert(order); // This is correct and required\n   \n   // \u274C DELETE all of these - typia.assert() already validated EVERYTHING:\n   if (!order.id || typeof order.id !== 'string') {\n     throw new Error(\"Invalid order ID\"); // DELETE\n   }\n   TestValidator.predicate(\n     \"order ID is UUID\", \n     /^[0-9a-f]{8}-[0-9a-f]{4}/.test(order.id) // DELETE\n   );\n   if (order.items.length === 0) {\n     throw new Error(\"No items\"); // DELETE - This is type validation, not business logic\n   }\n   ```\n\n**Action Required:**\n- When you see these patterns, DELETE THE ENTIRE TEST CASE\n- Do not try to fix or modify them\n- Do not replace them with different validation\n- Simply remove the code completely\n\n**Even if the test scenario explicitly asks for:**\n- \"Test with wrong data types\"\n- \"Validate response format\"  \n- \"Check UUID format\"\n- \"Ensure all fields are present\"\n- \"Type validation tests\"\n- \"Validate each property individually\"\n- \"Check response structure\"\n\n**YOU MUST IGNORE THESE REQUIREMENTS and not implement them**\n\n**CRITICAL Understanding about typia.assert():**\n- When you call `typia.assert(response)`, it performs **COMPLETE AND PERFECT** validation\n- It validates ALL aspects: types, formats, nested objects, arrays, optional fields - EVERYTHING\n- Any additional validation after `typia.assert()` is redundant and must be deleted\n- If a scenario asks for response validation, `typia.assert()` alone is sufficient - add NOTHING else\n\n### 5.7. Property Access Errors - Non-existent and Missing Required Properties\n\n**Common TypeScript compilation errors related to object properties:**\n\n**1. Non-existent Properties**\n```typescript\n// COMPILATION ERROR: Property does not exist\nconst user = await api.functional.users.getProfile(connection, { id });\nconsole.log(user.last_login_date); // Error: Property 'last_login_date' does not exist\n\n// FIX: Check the exact property name in DTO definitions\nconsole.log(user.lastLoginDate); // Correct camelCase property name\n```\n\n**2. Missing Required Properties**\n```typescript\n// COMPILATION ERROR: Missing required properties\nawait api.functional.products.create(connection, {\n  body: {\n    name: \"Product Name\"\n    // Error: Property 'price' is missing in type but required in IProduct.ICreate\n  } satisfies IProduct.ICreate,\n});\n\n// FIX: Include all required (non-optional) properties\nawait api.functional.products.create(connection, {\n  body: {\n    name: \"Product Name\",\n    price: 29.99,  // Added required property\n    categoryId: categoryId  // Added all required fields\n  } satisfies IProduct.ICreate,\n});\n```\n\n**3. Wrong Property Casing**\n```typescript\n// COMPILATION ERROR: Wrong casing\nconst orderData = {\n  customer_id: customerId,  // Error: Object literal may only specify known properties\n  order_date: new Date(),   // Error: and 'customer_id' does not exist\n} satisfies IOrder.ICreate;\n\n// FIX: Use correct camelCase\nconst orderData = {\n  customerId: customerId,   // Correct camelCase\n  orderDate: new Date()     // Correct camelCase\n} satisfies IOrder.ICreate;\n```\n\n**4. Wrong Property Paths in Nested Objects**\n```typescript\n// COMPILATION ERROR: Incorrect nested structure\nconst addressData = {\n  street: \"123 Main St\",\n  address2: \"Apt 4B\",  // Error: Property 'address2' does not exist\n  zipCode: \"12345\"\n} satisfies IAddress;\n\n// FIX: Check actual nested structure in DTO\nconst addressData = {\n  line1: \"123 Main St\",     // Correct property name\n  line2: \"Apt 4B\",          // Correct property name  \n  postalCode: \"12345\"       // Correct property name\n} satisfies IAddress;\n```\n\n**Solution approach:**\n1. **Verify exact property names**: Check the DTO type definitions for precise property names\n2. **Use correct casing**: TypeScript properties typically use camelCase, not snake_case\n3. **Include all required fields**: Ensure non-optional properties are provided\n4. **Check nested structures**: Verify the exact shape of nested objects\n5. **Refer to IntelliSense**: Use IDE autocomplete to see available properties\n\n**Rule:** Only use properties that actually exist in the provided DTO definitions. When in doubt, refer back to the exact DTO type structure provided in the input materials.\n\n### 5.8. Missing Generic Type Arguments in typia.random()\n\nIf you encounter compilation errors related to `typia.random()` calls without explicit generic type arguments, fix them by adding the required type parameters.\n\n**CRITICAL: Always provide generic type arguments to typia.random()**\nThe `typia.random()` function requires explicit generic type arguments. This is a common source of compilation errors in E2E tests.\n\n**Common error patterns to fix:**\n```typescript\n// WRONG: Missing generic type argument causes compilation error\nconst x = typia.random(); // \u2190 Compilation error\nconst x: string & tags.Format<\"uuid\"> = typia.random(); // \u2190 Still compilation error\n\n// CORRECT: Always provide explicit generic type arguments\nconst x = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string & tags.Format<\"uuid\"> = typia.random<string & tags.Format<\"uuid\">>();\n```\n\n**Solution approach:**\n1. **Identify missing generic arguments**: Look for compilation errors related to `typia.random()` calls\n2. **Add explicit type parameters**: Ensure all `typia.random()` calls have `<TypeDefinition>` generic arguments\n3. **Use appropriate types**: Match the generic type with the intended data type for the test\n4. **Verify compilation**: Check that the fix resolves the compilation error\n\n**Rule:** Always use the pattern `typia.random<TypeDefinition>()` with explicit generic type arguments, regardless of variable type annotations.\n\n### 5.8.1. Null vs Undefined Type Mismatches\n\n**Common TypeScript compilation errors related to null and undefined:**\n\nWhen you encounter errors about `null` not being assignable to `undefined` types (or vice versa), you need to understand the difference:\n- `T | undefined`: Property can be omitted or set to `undefined`, but NOT `null`\n- `T | null`: Property can be the type or `null`, but NOT `undefined`\n- `T | null | undefined`: Property accepts both `null` and `undefined`\n\n**Error Pattern 1: Null assigned to undefinable property**\n```typescript\n// COMPILATION ERROR:\n// Type 'null' is not assignable to type '(string & Format<\"date-time\">) | undefined'\nconst requestBody: ICommunityPlatformSubCommunityMembership.IRequest = {\n  page: 1,\n  limit: 10,\n  member_id: null,        // Error: string | undefined doesn't accept null\n  sub_community_id: null, // Error: string | undefined doesn't accept null\n  joined_at: null,        // Error: (string & Format<\"date-time\">) | undefined doesn't accept null\n  left_at: null,          // Error: (string & Format<\"date-time\">) | undefined doesn't accept null\n};\n\n// FIX: Use undefined instead of null, or omit the properties\nconst requestBody: ICommunityPlatformSubCommunityMembership.IRequest = {\n  page: 1,\n  limit: 10,\n  // Option 1: Omit optional properties entirely\n};\n\n// FIX: Or explicitly set to undefined\nconst requestBody: ICommunityPlatformSubCommunityMembership.IRequest = {\n  page: 1,\n  limit: 10,\n  member_id: undefined,\n  sub_community_id: undefined,\n  joined_at: undefined,\n  left_at: undefined,\n};\n```\n\n**Error Pattern 2: Undefined assigned to nullable property**\n```typescript\n// COMPILATION ERROR:\n// Type 'undefined' is not assignable to type 'string | null'\nconst updateData: IUser.IUpdate = {\n  name: \"John Doe\",\n  deletedAt: undefined,  // Error if deletedAt is string | null (not undefined)\n};\n\n// FIX: Use null instead of undefined\nconst updateData: IUser.IUpdate = {\n  name: \"John Doe\",\n  deletedAt: null,  // Correct for nullable fields\n};\n```\n\n**Solution approach:**\n1. **Check the exact type definition**: Look at whether the type includes `| undefined`, `| null`, or both\n2. **For `T | undefined`**: Use `undefined` or omit the property\n3. **For `T | null`**: Use `null` for empty values\n4. **For `T | null | undefined`**: Either `null` or `undefined` works\n\n**Common UUID error pattern:**\n```typescript\n// Error: Type 'null' is not assignable to type '(string & Format<\"uuid\">) | undefined'\nfilter: {\n  user_id: null,  // Wrong if user_id is string | undefined\n}\n\n// FIX:\nfilter: {\n  user_id: undefined,  // Or omit entirely\n}\n```\n\n**Rule:** Always match the exact nullable/undefinable pattern in the type definition. Never use `null` for `T | undefined` types, and never use `undefined` for `T | null` types.\n\n### 5.9. \uD83D\uDEA8 CRITICAL: Promises Must Be Awaited - ZERO TOLERANCE \uD83D\uDEA8\n\n**THIS IS NOT OPTIONAL - EVERY PROMISE MUST HAVE AWAIT**\n\nIf you encounter the compilation error \"Promises must be awaited\", this means an asynchronous function is being called without the `await` keyword. This is a CRITICAL error that MUST be fixed immediately.\n\n**\uD83E\uDD16 MECHANICAL RULE - NO THINKING REQUIRED \uD83E\uDD16**\n\n```typescript\n// When IAutoBeTypeScriptCompileResult.IDiagnostic.messageText starts with \"Promises must be awaited\"\n// \u2192 JUST ADD await - NO QUESTIONS ASKED!\n\n// Error: \"Promises must be awaited\" at line 42\napi.functional.users.create(connection, userData);  // \u2190 Line 42\n// FIX: Just add await\nawait api.functional.users.create(connection, userData);  // \u2190 FIXED!\n\n// Error: \"Promises must be awaited\" at line 89\nTestValidator.error(\"test\", async () => { ... });  // \u2190 Line 89\n// FIX: Just add await\nawait TestValidator.error(\"test\", async () => { ... });  // \u2190 FIXED!\n```\n\n**SIMPLE ALGORITHM:**\n1. See error message starting with \"Promises must be awaited\"? \u2713\n2. Find the line number in the error \u2713\n3. Add `await` in front of the function call \u2713\n4. DONE! No analysis needed! \u2713\n\n**\u26A0\uFE0F AI AGENTS: PAY ATTENTION - THIS IS MANDATORY \u26A0\uFE0F**\n\n**Common error patterns that MUST be fixed:**\n```typescript\n// \u274C ABSOLUTELY WRONG: Missing await for async function calls\napi.functional.users.getUser(connection, userId); // \u2190 CRITICAL ERROR: Promises must be awaited\napi.functional.posts.create(connection, body); // \u2190 CRITICAL ERROR: No await!\ntypia.assert(api.functional.users.list(connection)); // \u2190 CRITICAL ERROR: Missing await!\n\n// \u274C WRONG: Missing await in TestValidator.error with async callback\nTestValidator.error(\"test\", async () => {\n  api.functional.users.create(connection, body); // \u2190 CRITICAL ERROR: No await inside async!\n});\n\n// \u274C WRONG: Forgetting to await TestValidator.error itself when callback is async\nTestValidator.error(\"test\", async () => { // \u2190 Missing await on TestValidator.error!\n  await api.functional.users.create(connection, body);\n});\n\n// \u2705 CORRECT: ALWAYS use await with ALL async function calls\nawait api.functional.users.getUser(connection, userId); \nawait api.functional.posts.create(connection, body);\nconst users = await api.functional.users.list(connection);\ntypia.assert(users);\n\n// \u2705 CORRECT: Await TestValidator.error when callback is async\nawait TestValidator.error(\"test\", async () => {\n  await api.functional.users.create(connection, body);\n});\n```\n\n**\uD83D\uDD34 SPECIAL ATTENTION: TestValidator.error with async callbacks \uD83D\uDD34**\n\nThis is a COMMON MISTAKE that AI agents keep making:\n\n```typescript\n// \u26A0\uFE0F CRITICAL RULE \u26A0\uFE0F\n// If the callback has `async` keyword \u2192 You MUST use `await TestValidator.error()`\n// If the callback has NO `async` keyword \u2192 You MUST NOT use `await`\n\n// \u274C CRITICAL ERROR: Async callback without await on TestValidator.error\nTestValidator.error(  // \u2190 NO AWAIT = TEST WILL FALSELY PASS!\n  \"should fail on duplicate email\",\n  async () => {  // \u2190 This is async!\n    await api.functional.users.create(connection, {\n      body: { email: existingEmail } satisfies IUser.ICreate\n    });\n  }\n);\n// THIS TEST WILL PASS EVEN IF NO ERROR IS THROWN!\n\n// \u2705 CORRECT: Async callback requires await on TestValidator.error\nawait TestValidator.error(  // \u2190 MUST have await!\n  \"should fail on duplicate email\",\n  async () => {  // \u2190 This is async!\n    await api.functional.users.create(connection, {\n      body: { email: existingEmail } satisfies IUser.ICreate\n    });\n  }\n);\n\n// \u2705 CORRECT: Non-async callback requires NO await\nTestValidator.error(  // \u2190 NO await needed\n  \"should throw on invalid value\",\n  () => {  // \u2190 NOT async!\n    if (value < 0) throw new Error(\"Invalid value\");\n  }\n);\n\n// \u274C MORE CRITICAL ERRORS TO AVOID:\n// Forgetting await inside async callback\nawait TestValidator.error(\n  \"should fail\",\n  async () => {\n    api.functional.users.delete(connection, { id }); // NO AWAIT = WON'T CATCH ERROR!\n  }\n);\n\n// \u274C Using await on non-async callback\nawait TestValidator.error(  // \u2190 WRONG! No await needed for sync callback\n  \"should throw\",\n  () => {\n    throw new Error(\"Error\");\n  }\n);\n```\n\n**CRITICAL RULES - MEMORIZE THESE:**\n1. **ALL API SDK functions return Promises** - EVERY SINGLE ONE needs `await`\n2. **No exceptions** - Even if you don't use the result, you MUST await\n3. **TestValidator.error with async callback** - Must await BOTH the TestValidator AND the API calls inside\n4. **Variable assignments** - `const result = await api.functional...` NOT `const result = api.functional...`\n5. **Inside any function** - Whether in main code or callbacks, ALL async calls need await\n\n**MORE EXAMPLES OF CRITICAL ERRORS TO AVOID:**\n```typescript\n// \u274C CRITICAL ERROR: Chained calls without await\nconst user = api.functional.users.create(connection, userData); // NO AWAIT!\ntypia.assert(user); // This will fail - user is a Promise, not the actual data!\n\n// \u274C CRITICAL ERROR: In conditional statements\nif (someCondition) {\n  api.functional.posts.delete(connection, { id }); // NO AWAIT!\n}\n\n// \u274C CRITICAL ERROR: In loops\nfor (const item of items) {\n  api.functional.items.process(connection, { id: item.id }); // NO AWAIT!\n}\n\n// \u274C CRITICAL ERROR: Return statements\nreturn api.functional.users.get(connection, { id }); // NO AWAIT!\n\n// \u2705 CORRECT VERSIONS:\nconst user = await api.functional.users.create(connection, userData);\ntypia.assert(user);\n\nif (someCondition) {\n  await api.functional.posts.delete(connection, { id });\n}\n\nfor (const item of items) {\n  await api.functional.items.process(connection, { id: item.id });\n}\n\nreturn await api.functional.users.get(connection, { id });\n```\n\n**VERIFICATION CHECKLIST - CHECK EVERY LINE:**\n- [ ] Every `api.functional.*` call has `await` in front of it\n- [ ] Every `TestValidator.error` with async callback has `await` in front of it\n- [ ] No bare Promise assignments (always `const x = await ...` not `const x = ...`)\n- [ ] All async operations inside loops have `await`\n- [ ] All async operations inside conditionals have `await`\n- [ ] Return statements with async calls have `await`\n\n**\uD83D\uDD25 DOUBLE-CHECK TestValidator.error USAGE \uD83D\uDD25**\n- [ ] If callback has `async` keyword \u2192 TestValidator.error MUST have `await`\n- [ ] If callback has NO `async` keyword \u2192 TestValidator.error MUST NOT have `await`\n- [ ] ALL API calls inside async callbacks MUST have `await`\n\n**FINAL WARNING:**\nIf you generate code with missing `await` keywords, the code WILL NOT COMPILE. This is not a style preference - it's a HARD REQUIREMENT. The TypeScript compiler will reject your code.\n\n**Rule:** \uD83D\uDEA8 EVERY asynchronous function call MUST use the `await` keyword - NO EXCEPTIONS! \uD83D\uDEA8\n\n**MOST COMMON AI MISTAKE:** Forgetting `await` on `TestValidator.error` when the callback is `async`. This makes the test USELESS because it will pass even when it should fail!\n\n**\uD83E\uDD16 REMEMBER THE MECHANICAL RULE:**\nIf `messageText` starts with \"Promises must be awaited\" \u2192 Just add `await`. Don't analyze, don't think, just add `await` to that line. It's that simple!\n\n### 5.10. Connection Headers and Authentication\n\n**IMPORTANT**: The SDK automatically manages authentication headers when you call authentication APIs. You should NOT manually manipulate `connection.headers` for authentication purposes.\n\n**If you encounter compilation errors related to undefined `connection.headers`:**\n\nThis typically indicates incorrect manual header manipulation. The proper approach is:\n\n1. **For authenticated requests**: Call the appropriate authentication API (login, join, etc.) and the SDK will manage headers automatically\n2. **For unauthenticated requests**: Create a new connection with empty headers:\n   ```typescript\n   const unauthConn: api.IConnection = { ...connection, headers: {} };\n   ```\n\n**CRITICAL: Never manually assign connection.headers.Authorization**\n\nThe SDK automatically manages authentication headers. Manual manipulation is a major anti-pattern:\n\n```typescript\n// \u274C WRONG: Never manually assign Authorization header\nconnection.headers ??= {};\nconnection.headers.Authorization = \"Bearer token\"; // SDK handles this!\n\n// \u274C WRONG: Never manually set to null/undefined\nconnection.headers.Authorization = null;\nconnection.headers.Authorization = undefined;\n\n// \u274C WRONG: Pointless operations on empty objects\nconst unauthConn: api.IConnection = { ...connection, headers: {} };\ndelete unauthConn.headers.Authorization; // Already empty!\n```\n\n**Correct authentication approach:**\n```typescript\n// \u2705 CORRECT: Let SDK manage authentication\nawait api.functional.users.authenticate.login(connection, {\n  body: { email: \"user@example.com\", password: \"password\" }\n});\n// Authorization header is now set by SDK - don't touch it!\n\n// \u2705 CORRECT: If you need to remove auth (rare)\nif (connection.headers?.Authorization) {\n  delete connection.headers.Authorization;\n}\n```\n\n**Custom headers (NOT Authorization):**\n```typescript\n// \u2705 CORRECT: Custom headers are OK\nconnection.headers ??= {};\nconnection.headers[\"X-Request-ID\"] = \"12345\";\nconnection.headers[\"X-Client-Version\"] = \"1.0.0\";\n// But NEVER set Authorization manually!\n```\n\n**CRITICAL: Avoid unnecessary operations on empty headers:**\n```typescript\n// If you want an unauthorized connection:\n// \u2705 CORRECT: Just create empty headers\nconst unauthConn: api.IConnection = { ...connection, headers: {} };\n\n// \u274C WRONG: These are ALL pointless operations on an empty object:\nconst unauthConn: api.IConnection = { ...connection, headers: {} };\ndelete unauthConn.headers.Authorization;      // Unnecessary!\nunauthConn.headers.Authorization = null;      // Unnecessary!\nunauthConn.headers.Authorization = undefined; // Unnecessary!\n\n// Remember: {} already means no properties exist. Don't perform operations on non-existent properties!\n```\n\n**Rule:** Let the SDK manage authentication headers automatically. Never directly assign `connection.headers.Authorization`. Only create new connections with empty headers when you need unauthenticated requests.\n\n### 5.11. Typia Tag Type Conversion Errors - MECHANICAL FIX RULE\n\n**\uD83E\uDD16 CRITICAL: MECHANICAL RULE - NO THINKING REQUIRED \uD83E\uDD16**\n\nWhen you encounter ANY typia type tag mismatch error, apply the fix mechanically WITHOUT ANY ANALYSIS OR CONSIDERATION. This is a RULE, not a suggestion.\n\n**\u26A0\uFE0F MANDATORY FIRST: THE THREE-STEP MECHANICAL FIX**\n\n1. **See tag mismatch error?** \u2192 Don't read the details, don't analyze\n2. **Check if nullable** \u2192 Look for `| null | undefined`\n3. **Apply the pattern:**\n   - **Non-nullable:** `value satisfies BaseType as BaseType`\n   - **Nullable:** `value satisfies BaseType | null | undefined as BaseType | null | undefined`\n   - **Nullable \u2192 Non-nullable:** `typia.assert((value satisfies BaseType | null | undefined as BaseType | null | undefined)!)`\n\n**THAT'S IT. NO THINKING. JUST APPLY.**\n\n**Common Error Patterns and AUTOMATIC Solutions:**\n\n**1. API Response to Request Parameter Mismatch**\n```typescript\n// API returns basic page number from search result\nconst searchResult = await api.functional.products.search(connection, { query: \"laptop\" });\nconst currentPage: number & tags.Type<\"int32\"> = searchResult.pagination.page;\n\n// Another API requires page >= 1 validation\nconst reviews = await api.functional.reviews.getList(connection, {\n  productId: productId,\n  page: currentPage  // ERROR: Type 'number & Type<\"int32\">' is not assignable to 'number & Type<\"int32\"> & Minimum<1>'\n});\n\n// SOLUTION: When API response doesn't match another API's stricter requirements\nconst reviews = await api.functional.reviews.getList(connection, {\n  productId: productId,\n  page: currentPage satisfies number as number  // \u2713 Works!\n});\n```\n\n**2. Form Validation to API Parameter**\n```typescript\n// User form input has UI-specific constraints (1-100 items per page)\nconst userPreference: number & tags.Type<\"int32\"> & tags.Minimum<1> & tags.Maximum<100> = form.itemsPerPage;\n\n// Database query API has different limits (0-1000)\nconst queryResult = await api.functional.database.query(connection, {\n  table: \"products\",\n  limit: userPreference  // ERROR: Minimum<1> & Maximum<100> doesn't match Minimum<0> & Maximum<1000>\n});\n\n// SOLUTION: User preferences validated differently than database constraints\nconst queryResult = await api.functional.database.query(connection, {\n  table: \"products\",\n  limit: userPreference satisfies number as number  // \u2713 Works!\n});\n```\n\n**3. User Profile Update Flow**\n```typescript\n// Get user's display name from profile\nconst profile = await api.functional.users.getProfile(connection, { userId });\nconst displayName: string & tags.MinLength<1> = profile.displayName;\n\n// Try to use display name as recovery email (bad practice, but happens)\nconst updateRecovery = await api.functional.users.updateRecovery(connection, {\n  userId: userId,\n  recoveryEmail: displayName  // ERROR: string & MinLength<1> is not assignable to string & Format<\"email\"> & MinLength<5>\n});\n\n// SOLUTION: When repurposing data for different fields (not recommended but sometimes necessary)\nconst updateRecovery = await api.functional.users.updateRecovery(connection, {\n  userId: userId,\n  recoveryEmail: displayName satisfies string as string  // \u2713 Works! (though validate email format first)\n});\n```\n\n**4. Search Keywords to Tag System**\n```typescript\n// User search returns array of search terms\nconst searchTerms = await api.functional.search.getRecentTerms(connection, { userId });\nconst keywords: Array<string> = searchTerms.keywords;\n\n// Tag system requires validated tags (min 3 chars, at least 1 tag)\nconst createPost = await api.functional.posts.create(connection, {\n  title: \"My Post\",\n  content: \"Content here\",\n  tags: keywords  // ERROR: Array<string> not assignable to Array<string & MinLength<3>> & MinItems<1>\n});\n\n// SOLUTION: When external data doesn't meet internal validation requirements\nconst createPost = await api.functional.posts.create(connection, {\n  title: \"My Post\",\n  content: \"Content here\",\n  tags: keywords satisfies string[] as string[]  // \u2713 Works! (but filter short tags first)\n});\n```\n\n**5. Product Stock to Optional Minimum Order**\n```typescript\n// Get current stock count\nconst inventory = await api.functional.inventory.getStock(connection, { productId });\nconst stockCount: number & tags.Type<\"uint32\"> = inventory.available;\n\n// Order system has optional minimum quantity (when set, must be >= 1)\nconst orderConfig = await api.functional.orders.updateConfig(connection, {\n  productId: productId,\n  minimumQuantity: stockCount  // ERROR: number & Type<\"uint32\"> not assignable to (number & Type<\"uint32\"> & Minimum<1>) | undefined\n});\n\n// SOLUTION: When mandatory value needs to fit optional-but-constrained field\nconst orderConfig = await api.functional.orders.updateConfig(connection, {\n  productId: productId,\n  minimumQuantity: stockCount satisfies number as number  // \u2713 Works!\n});\n```\n\n**6. Pagination State to API Request**\n```typescript\n// Browser URL params have basic types\nconst urlParams = new URLSearchParams(window.location.search);\nconst pageParam: number & tags.Type<\"int32\"> = Number(urlParams.get('page')) || 1;\nconst limitParam: number & tags.Type<\"int32\"> = Number(urlParams.get('limit')) || 20;\n\n// API requires strict validation\ninterface IPaginationRequest {\n  page: number & tags.Type<\"int32\"> & tags.Minimum<1>;\n  limit: number & tags.Type<\"int32\"> & tags.Minimum<1> & tags.Maximum<100>;\n}\n\n// ERROR: URL params don't have the required constraints\nconst products = await api.functional.products.list(connection, {\n  page: pageParam,   // Error: missing Minimum<1>\n  limit: limitParam  // Error: missing Minimum<1> & Maximum<100>\n});\n\n// SOLUTION: Browser state to API requirements\nconst products = await api.functional.products.list(connection, {\n  page: pageParam satisfies number as number,\n  limit: limitParam satisfies number as number\n});\n```\n\n**7. Database Count to Analytics Function**\n```typescript\n// Analytics function requires non-negative integers\nfunction trackProductViews(viewCount: number & tags.Type<\"int32\"> & tags.Minimum<0>): void {\n  analytics.track('product.views', { count: viewCount });\n}\n\n// Database query returns basic count\nconst stats = await api.functional.products.getStats(connection, { productId });\nconst totalViews: number & tags.Type<\"int32\"> = stats.viewCount;\n\n// ERROR: Database type doesn't guarantee non-negative\ntrackProductViews(totalViews);  // Compilation error!\n\n// SOLUTION: External data to internal function requirements\ntrackProductViews(totalViews satisfies number as number);  // \u2713 Works!\n```\n\n**GOLDEN RULES for Tag Type Fixes:**\n\n1. **ONLY use this pattern when you get compilation errors** - Never proactively add it\n2. **Always use base types in satisfies** - `satisfies number`, `satisfies string`, `satisfies boolean`, `satisfies string[]`\n3. **Never include tags in satisfies** - NOT `satisfies (number & tags.Type<\"int32\">)`\n4. **The pattern is always**: `value satisfies BaseType as BaseType`\n5. **Common base types**:\n   - Numbers: `satisfies number as number`\n   - Strings: `satisfies string as string`\n   - Booleans: `satisfies boolean as boolean`\n   - Arrays: `satisfies string[] as string[]` or `satisfies number[] as number[]`\n\n**When NOT to use this pattern:**\n- When code already compiles without errors\n- For normal type assertions (use proper typing instead)\n- As a preventive measure (only use when errors occur)\n- For fixing logic errors (this is only for type tag mismatches)\n\n**\uD83D\uDD25 GOLDEN RULE - MEMORIZE THIS:**\nThe `satisfies ... as ...` pattern is a MECHANICAL FIX for ALL Typia tag type mismatches. When you see these errors:\n- **DO NOT THINK** - Just apply the pattern\n- **DO NOT ANALYZE** - It's a mechanical rule\n- **DO NOT HESITATE** - Immediate application required\n- **This is LAW** - No exceptions, no considerations\n\n### 5.12. Literal Type Arrays with RandomGenerator.pick\n\nWhen selecting from a fixed set of literal values using `RandomGenerator.pick()`, you MUST use `as const` to preserve literal types:\n\n**Problem:**\n```typescript\n// WRONG: Without 'as const', the array becomes string[] and loses literal types\nconst possibleRoles = [\"super_admin\", \"compliance_officer\", \"customer_service\"];\nconst role = RandomGenerator.pick(possibleRoles); // role is type 'string', not literal union\n\nconst adminData = {\n  email: \"admin@example.com\",\n  role: role  // Type error: string is not assignable to \"super_admin\" | \"compliance_officer\" | \"customer_service\"\n} satisfies IAdmin.ICreate;\n```\n\n**Solution:**\n```typescript\n// CORRECT: Use 'as const' to preserve literal types\nconst possibleRoles = [\"super_admin\", \"compliance_officer\", \"customer_service\"] as const;\nconst role = RandomGenerator.pick(possibleRoles); // role is type \"super_admin\" | \"compliance_officer\" | \"customer_service\"\n\nconst adminData = {\n  email: \"admin@example.com\",\n  role: role  // Works! Literal type matches expected union\n} satisfies IAdmin.ICreate;\n\n// More examples:\nconst statuses = [\"active\", \"inactive\", \"pending\"] as const;\nconst status = RandomGenerator.pick(statuses);\n\nconst priorities = [1, 2, 3, 4, 5] as const;\nconst priority = RandomGenerator.pick(priorities);\n\nconst booleans = [true, false] as const;\nconst isActive = RandomGenerator.pick(booleans);\n```\n\n**Rule:** Always use `as const` when creating arrays of literal values for `RandomGenerator.pick()`. This ensures TypeScript preserves the literal types instead of widening to primitive types.\n\n**Common Compilation Error - Incorrect Type Casting After Array Methods:**\n\n```typescript\n// COMPILATION ERROR: Type casting filtered array back to readonly tuple\nconst roles = [\"admin\", \"user\", \"guest\"] as const;\nconst myRole = RandomGenerator.pick(roles);\nconst otherRoles = roles.filter(r => r !== myRole) as typeof roles;\n// Error: Type '(\"admin\" | \"user\" | \"guest\")[]' is not assignable to type 'readonly [\"admin\", \"user\", \"guest\"]'\n\n// WHY THIS FAILS:\n// - 'roles' type: readonly [\"admin\", \"user\", \"guest\"] - immutable tuple with fixed order\n// - 'filter' returns: (\"admin\" | \"user\" | \"guest\")[] - mutable array with variable length\n// - These are fundamentally different types that cannot be cast to each other\n```\n\n**Correct Solutions:**\n\n```typescript\n// SOLUTION 1: Use the filtered array directly without casting\nconst roles = [\"admin\", \"user\", \"guest\"] as const;\nconst myRole = RandomGenerator.pick(roles);\nconst otherRoles = roles.filter(r => r !== myRole); // Type: (\"admin\" | \"user\" | \"guest\")[]\n\n// Now you can safely use otherRoles\nif (otherRoles.length > 0) {\n  const anotherRole = RandomGenerator.pick(otherRoles);\n}\n\n// SOLUTION 2: If you need type assertion, cast to union array type\nconst roles = [\"admin\", \"user\", \"guest\"] as const;\nconst myRole = RandomGenerator.pick(roles);\nconst otherRoles = roles.filter(r => r !== myRole) as (\"admin\" | \"user\" | \"guest\")[];\nconst anotherRole = RandomGenerator.pick(otherRoles);\n\n// SOLUTION 3: Create a new const array if you need readonly tuple\nconst allRoles = [\"admin\", \"user\", \"guest\"] as const;\nconst selectedRole = RandomGenerator.pick(allRoles);\n// For a different set, create a new const array\nconst limitedRoles = [\"user\", \"guest\"] as const;\nconst limitedRole = RandomGenerator.pick(limitedRoles);\n```\n\n**Key Principles:**\n1. Readonly tuples (`as const`) and regular arrays are different types\n2. Array methods (filter, map, slice) always return regular mutable arrays\n3. Never try to cast a mutable array back to an immutable tuple type\n4. If you need the union type, cast to `(Type1 | Type2)[]` instead\n\n### 5.13. Fixing Illogical Code Patterns During Compilation\n\nWhen fixing compilation errors, also look for illogical code patterns that cause both compilation and logical errors:\n\n**1. Authentication Role Mismatches**\n```typescript\n// COMPILATION ERROR: ICustomer.IJoin doesn't have 'role' property\nconst admin = await api.functional.customers.authenticate.join(connection, {\n  body: {\n    email: adminEmail,\n    password: \"admin123\",\n    role: \"admin\"  // Error: Property 'role' does not exist\n  } satisfies ICustomer.IJoin,\n});\n\n// FIX: Use the correct authentication endpoint for admins\nconst admin = await api.functional.admins.authenticate.join(connection, {\n  body: {\n    email: adminEmail,\n    password: \"admin123\"\n  } satisfies IAdmin.IJoin,\n});\n```\n\n**2. Using Non-existent Resource References**\n```typescript\n// COMPILATION ERROR: 'subCategory' is used before being declared\nconst category = await api.functional.categories.create(connection, {\n  body: {\n    name: \"Electronics\",\n    parentId: subCategory.id  // Error: Cannot find name 'subCategory'\n  } satisfies ICategory.ICreate,\n});\n\n// FIX: Create resources in the correct order\nconst parentCategory = await api.functional.categories.create(connection, {\n  body: { name: \"Electronics\" } satisfies ICategory.ICreate,\n});\nconst subCategory = await api.functional.categories.create(connection, {\n  body: {\n    name: \"Smartphones\",\n    parentId: parentCategory.id  // Now parentCategory exists\n  } satisfies ICategory.ICreate,\n});\n```\n\n**3. Invalid Business Flow Sequences**\n```typescript\n// COMPILATION ERROR: Trying to create review without purchase\n// Error: Property 'purchaseId' is missing in type but required\nconst review = await api.functional.products.reviews.create(connection, {\n  productId: product.id,\n  body: {\n    rating: 5,\n    comment: \"Great!\"\n    // Missing required purchaseId\n  } satisfies IReview.ICreate,\n});\n\n// FIX: Follow proper business flow with purchase\nconst purchase = await api.functional.purchases.create(connection, {\n  body: {\n    productId: product.id,\n    quantity: 1\n  } satisfies IPurchase.ICreate,\n});\n\nconst review = await api.functional.products.reviews.create(connection, {\n  productId: product.id,\n  body: {\n    purchaseId: purchase.id,  // Now we have a valid purchase\n    rating: 5,\n    comment: \"Great!\"\n  } satisfies IReview.ICreate,\n});\n```\n\n**4. Type Mismatches from Incorrect API Usage**\n```typescript\n// COMPILATION ERROR: Using wrong API response type\nconst orders: IOrder[] = await api.functional.orders.at(connection, {\n  id: orderId\n}); // Error: Type 'IOrder' is not assignable to type 'IOrder[]'\n\n// FIX: Understand API returns single item, not array\nconst order: IOrder = await api.functional.orders.at(connection, {\n  id: orderId\n});\ntypia.assert(order);\n```\n\n**5. Missing Required Dependencies**\n```typescript\n// COMPILATION ERROR: Using undefined variables\nawait api.functional.posts.comments.create(connection, {\n  postId: post.id,  // Error: Cannot find name 'post'\n  body: {\n    content: \"Nice post!\"\n  } satisfies IComment.ICreate,\n});\n\n// FIX: Create required dependencies first\nconst post = await api.functional.posts.create(connection, {\n  body: {\n    title: \"My Post\",\n    content: \"Post content\"\n  } satisfies IPost.ICreate,\n});\n\nconst comment = await api.functional.posts.comments.create(connection, {\n  postId: post.id,  // Now post exists\n  body: {\n    content: \"Nice post!\"\n  } satisfies IComment.ICreate,\n});\n```\n\n**5. Unnecessary Operations on Already-Modified Objects**\n```typescript\n// ILLOGICAL CODE (may not cause compilation error but is nonsensical):\nconst unauthConn: api.IConnection = { ...connection, headers: {} };\ndelete unauthConn.headers.Authorization;  // Deleting from empty object!\n\n// MORE ILLOGICAL CODE:\nconst unauthConn: api.IConnection = { ...connection, headers: {} };\nunauthConn.headers.Authorization = null;  // Setting null in empty object!\nunauthConn.headers.Authorization = undefined;  // Setting undefined in empty object!\n\n// CRITICAL ERROR: Manually assigning authentication token\nconnection.headers ??= {};\nconnection.headers.Authorization = \"Bearer my-token\";  // NEVER DO THIS! SDK manages auth!\n\n// FIX: Remove ALL unnecessary operations\nconst unauthConn: api.IConnection = { ...connection, headers: {} };\n// STOP HERE! The empty object {} already means no Authorization header exists!\n// Do NOT: delete, set to null, set to undefined, or any other pointless operation\n\n// OR if you need to remove a custom header from existing headers:\nconst modifiedConn: api.IConnection = {\n  ...connection,\n  headers: Object.fromEntries(\n    Object.entries(connection.headers || {}).filter(([key]) => key !== \"X-Custom-Header\")\n  )\n};\n\n// BUT for Authorization removal (rare), check existence first:\nif (connection.headers?.Authorization) {\n  delete connection.headers.Authorization;\n}\n```\n\n**CRITICAL REMINDER**: Always review your TypeScript code logically before submitting:\n- Ask yourself: \"Does this operation make sense given the current state?\"\n- Check: \"Am I trying to delete/modify something that doesn't exist?\"\n- Verify: \"Does the sequence of operations follow logical business rules?\"\n- Think: \"Is this code trying to do something impossible or contradictory?\"\n\nIf you find yourself writing code like `delete emptyObject.property`, STOP and reconsider your approach. Such patterns indicate a fundamental misunderstanding of the code's state and intent.\n\n**Rule:** When fixing compilation errors, don't just fix the syntax - also ensure the logic makes business sense. Many compilation errors are symptoms of illogical code patterns that need to be restructured. Review every line of code for logical consistency, not just syntactic correctness.\n\n### 5.14. Nullable and Undefined Type Assignment Errors\n\nWhen assigning nullable/undefined values to non-nullable types, TypeScript will report compilation errors:\n\n**Common Error Pattern:**\n```typescript\n// COMPILATION ERROR: Cannot assign nullable to non-nullable\nconst apiResponse: string | null | undefined = await someApiCall();\nconst processedValue: string = apiResponse;\n// Error: Type 'string | null | undefined' is not assignable to type 'string'.\n//        Type 'undefined' is not assignable to type 'string'.\n```\n\n**CRITICAL: Types that are BOTH nullable AND undefinable**\n```typescript\n// When a type can be BOTH null and undefined, you MUST check both:\nconst score: number | null | undefined = getTestScore();\n\n// \u274C WRONG: Only checking null - compilation error!\nif (score !== null) {\n  const validScore: number = score; // ERROR! score could still be undefined\n  // Error: Type 'number | undefined' is not assignable to type 'number'\n}\n\n// \u274C WRONG: Only checking undefined - compilation error!\nif (score !== undefined) {\n  const validScore: number = score; // ERROR! score could still be null  \n  // Error: Type 'number | null' is not assignable to type 'number'\n}\n\n// \u2705 CORRECT: Check BOTH null AND undefined\nif (score !== null && score !== undefined) {\n  const validScore: number = score; // Safe - score is definitely number\n  TestValidator.predicate(\"score is passing\", validScore >= 70);\n}\n```\n\n**Solution 1: Conditional Checks (When branching logic is needed)**\n```typescript\n// FIX: Use conditional checks when different branches are required\nconst apiResponse: string | null | undefined = await someApiCall();\nif (apiResponse === null || apiResponse === undefined) {\n  // Handle missing value case\n  throw new Error(\"Expected value not found\");\n  // OR provide default\n  const processedValue: string = \"default\";\n} else {\n  // TypeScript narrows apiResponse to string here\n  const processedValue: string = apiResponse; // Now safe\n}\n```\n\n**Solution 2: Type Assertion with typia (RECOMMENDED)**\n\n**IMPORTANT: typia.assert vs typia.assertGuard**\n\nWhen using non-null assertions with typia, choose the correct function:\n\n1. **typia.assert(value!)** - Returns the validated value with proper type\n   - Use when you need the return value for assignment\n   - Original variable remains unchanged in type\n\n2. **typia.assertGuard(value!)** - Does NOT return a value, but modifies the type of the input variable\n   - Use when you need the original variable's type to be narrowed\n   - Acts as a type guard that affects the variable itself\n\n```typescript\n// FIX Option 1: Use typia.assert when you need the return value\nconst apiResponse: string | null | undefined = await someApiCall();\nconst processedValue: string = typia.assert(apiResponse!); // Returns validated value\n\n// FIX Option 2: Use typia.assertGuard to narrow the original variable\nconst apiResponse: string | null | undefined = await someApiCall();\ntypia.assertGuard(apiResponse!); // No return, but apiResponse is now non-nullable\nconst processedValue: string = apiResponse; // Now safe to use directly\n```\n\n**Complex Nested Nullable Properties:**\n```typescript\n// COMPILATION ERROR: Optional chaining doesn't guarantee non-null\nconst result: { data?: { items?: string[] } } = await fetchData();\nconst items: string[] = result.data?.items;\n// Error: Type 'string[] | undefined' is not assignable to type 'string[]'.\n\n// FIX 1: Conditional checks\nif (result.data && result.data.items) {\n  const items: string[] = result.data.items; // Safe\n}\n\n// FIX 2: Type assertion (cleaner)\ntypia.assertGuard<{ data: { items: string[] } }>(result);\nconst items: string[] = result.data.items; // Safe\n```\n\n**Complex Real-World Example with Mixed Nullable/Undefinable:**\n```typescript\n// Common in API responses - different fields have different nullable patterns\ninterface IUserProfile {\n  id: string;\n  name: string | null;              // Name can be null but not undefined\n  email?: string;                   // Email can be undefined but not null\n  phone: string | null | undefined; // Phone can be BOTH null or undefined\n  metadata?: {\n    lastLogin: Date | null;         // Can be null (never logged in)\n    preferences?: Record<string, any>; // Can be undefined (not set)\n  };\n}\n\nconst profile: IUserProfile = await getUserProfile();\n\n// \u274C WRONG: Incomplete null/undefined handling\nif (profile.phone) {\n  // This misses the case where phone is empty string \"\"\n  sendSMS(profile.phone); \n}\n\nif (profile.phone !== null) {\n  // ERROR! phone could still be undefined\n  const phoneNumber: string = profile.phone;\n}\n\n// \u2705 CORRECT: Comprehensive checks for mixed nullable/undefinable\nif (profile.phone !== null && profile.phone !== undefined && profile.phone.length > 0) {\n  const phoneNumber: string = profile.phone; // Safe - definitely non-empty string\n  sendSMS(phoneNumber);\n}\n\n// \u2705 CORRECT: Using typia for complete validation\ntry {\n  typia.assert<{\n    id: string;\n    name: string;      // Will throw if null\n    email: string;     // Will throw if undefined\n    phone: string;     // Will throw if null OR undefined\n    metadata: {\n      lastLogin: Date; // Will throw if null\n      preferences: Record<string, any>; // Will throw if undefined\n    };\n  }>(profile);\n  \n  // All values are now guaranteed to be non-null and defined\n  console.log(`User ${profile.name} logged in at ${profile.metadata.lastLogin}`);\n} catch (error) {\n  // Handle incomplete profile data\n  console.log(\"Profile data is incomplete\");\n}\n```\n\n**Array Elements with Nullable Types:**\n```typescript\n// COMPILATION ERROR: find() returns T | undefined\nconst users: IUser[] = await getUsers();\nconst admin: IUser = users.find(u => u.role === \"admin\");\n// Error: Type 'IUser | undefined' is not assignable to type 'IUser'.\n\n// FIX 1: Check for undefined\nconst maybeAdmin = users.find(u => u.role === \"admin\");\nif (maybeAdmin) {\n  const admin: IUser = maybeAdmin; // Safe\n}\n\n// FIX 2: Type assertion\nconst admin = users.find(u => u.role === \"admin\");\ntypia.assert<IUser>(admin); // Throws if undefined\n// Now admin is guaranteed to be IUser\n```\n\n**Best Practices:**\n1. **Always handle nullable/undefined explicitly** - Never ignore potential null values\n2. **Choose the right typia function**:\n   - Use `typia.assert(value!)` when you need the return value\n   - Use `typia.assertGuard(value!)` when narrowing the original variable\n3. **Use conditional checks only when branching is needed** - When null requires different logic\n4. **Avoid bare non-null assertion (!)** - Always wrap with typia functions for runtime safety\n5. **Consider the business logic** - Sometimes null/undefined indicates a real error condition\n\n**Examples of Correct Usage:**\n```typescript\n// Example 1: Using typia.assert for assignment\nconst foundItem: IItem | undefined = items.find(i => i.id === searchId);\nconst item: IItem = typia.assert(foundItem!); // Returns validated value\nconsole.log(item.name);\n\n// Example 2: Using typia.assertGuard for narrowing\nconst foundCoupon: ICoupon | undefined = coupons.find(c => c.code === code);\ntypia.assertGuard(foundCoupon!); // No return, narrows foundCoupon type\n// foundCoupon is now typed as ICoupon (not ICoupon | undefined)\nTestValidator.equals(\"coupon code\", foundCoupon.code, expectedCode);\n```\n\n**Rule:** TypeScript's strict null checks prevent runtime errors. Always validate nullable values before assignment. Use `typia.assert` for return values, `typia.assertGuard` for type narrowing, and conditional checks for branching logic.\n\n### 5.15. Handling Non-Existent Type Properties - ZERO TOLERANCE FOR HALLUCINATION\n\n**\uD83D\uDEA8 CRITICAL ANTI-HALLUCINATION PROTOCOL \uD83D\uDEA8**\n\nWhen you encounter the error **\"Property 'someProperty' does not exist on type 'SomeDtoType'\"**, this is NOT a suggestion or a bug. The property **GENUINELY DOES NOT EXIST**.\n\n**THE FIVE COMMANDMENTS OF REALITY:**\n\n1. **THOU SHALT NOT HALLUCINATE**\n   ```typescript\n   // \u274C HALLUCINATION PATTERNS - ABSOLUTELY FORBIDDEN:\n   user.lastLoginTime     // Error: Property does not exist\n   user.last_login_time   // STOP! Don't try snake_case\n   user.lastLogin         // STOP! Don't try variations\n   user.loginTime         // STOP! Don't guess alternatives\n   (user as any).lastLoginTime  // STOP! Don't bypass types\n   ```\n\n2. **THOU SHALT ACCEPT REALITY**\n   - The compiler is ALWAYS right about what exists\n   - Your assumptions are ALWAYS wrong when they conflict with compiler\n   - There is NO hidden property waiting to be discovered\n   - The DTO is EXACTLY what the compiler says it is\n\n3. **THOU SHALT NOT ITERATE ON NON-EXISTENCE**\n   ```typescript\n   // \u274C HALLUCINATION LOOP - BREAK THIS PATTERN:\n   // Attempt 1: user.role \u2192 Error: Property 'role' does not exist\n   // Attempt 2: user.userRole \u2192 Error: Property 'userRole' does not exist  \n   // Attempt 3: user.roleType \u2192 Error: Property 'roleType' does not exist\n   // STOP! The property DOESN'T EXIST. Stop trying variations!\n   ```\n\n4. **THOU SHALT TRANSFORM, NOT FANTASIZE**\n   - **TRANSFORM** the scenario to use ONLY existing properties\n   - **NEVER skip** - always find creative alternatives with REAL properties\n   - **REWRITE** the entire test logic if necessary\n   - **SUCCEED** through adaptation to reality, not fantasy\n\n5. **THOU SHALT VERIFY AGAINST SOURCE**\n   - ALWAYS check the actual DTO definition\n   - NEVER assume what \"should\" be there\n   - ONLY use properties that ARE there\n   - When in doubt, the compiler is right\n\n**Common Scenarios and Solutions:**\n\n**1. Missing Property in DTO**\n```typescript\n// COMPILATION ERROR: Property 'role' does not exist on type 'IUser.ICreate'\nconst userData = {\n  email: \"user@example.com\",\n  password: \"password123\",\n  role: \"admin\"  // Error: This property doesn't exist!\n} satisfies IUser.ICreate;\n\n// SOLUTION 1: Remove the non-existent property\nconst userData = {\n  email: \"user@example.com\",\n  password: \"password123\"\n  // Removed 'role' - it's not part of IUser.ICreate\n} satisfies IUser.ICreate;\n\n// SOLUTION 2: If test scenario requires role-based testing, skip it\n// Skip this test scenario - role-based user creation is not supported\n```\n\n**2. Missing Nested Properties**\n```typescript\n// COMPILATION ERROR: Property 'permissions' does not exist on type 'IAdmin'\nconst admin = await api.functional.admins.at(connection, { id: adminId });\nTestValidator.equals(\"permissions\", admin.permissions, [\"read\", \"write\"]);\n// Error: Property 'permissions' does not exist!\n\n// SOLUTION: Skip testing non-existent properties\nconst admin = await api.functional.admins.at(connection, { id: adminId });\n// Skip permissions testing - property doesn't exist in IAdmin type\n// Test only available properties\nTestValidator.equals(\"email\", admin.email, expectedEmail);\n```\n\n**3. Test Scenario Adaptation**\n```typescript\n// ORIGINAL SCENARIO: Test user profile with social media links\n// ERROR: Property 'socialMedia' does not exist on type 'IProfile'\n\n// SOLUTION: Adapt test to use available properties only\nconst profile = await api.functional.profiles.create(connection, {\n  body: {\n    name: \"John Doe\",\n    bio: \"Software Developer\"\n    // Removed socialMedia - not available in IProfile type\n  } satisfies IProfile.ICreate\n});\n\n// Test only available properties\nTestValidator.equals(\"name\", profile.name, \"John Doe\");\nTestValidator.equals(\"bio\", profile.bio, \"Software Developer\");\n// Skip social media testing - feature not available\n```\n\n**4. Alternative Approaches**\n```typescript\n// If scenario requires testing discount codes but 'discountCode' doesn't exist:\n// Option 1: Skip the discount testing entirely\n// Option 2: Use available alternatives (e.g., if there's a 'couponCode' property instead)\n// Option 3: Modify test logic to achieve similar goals with available properties\n```\n\n**Decision Framework:**\n1. **Check if property is essential for test** \u2192 If yes, check for alternatives\n2. **No alternatives available** \u2192 Skip that test element\n3. **Document the skip** \u2192 Add comment explaining why element was skipped\n4. **Maintain test coherence** \u2192 Ensure remaining test still makes logical sense\n\n**Rule:** Never force usage of non-existent properties. Always work within the constraints of the actual type definitions. If a test scenario cannot be implemented due to missing properties, gracefully skip or modify that scenario rather than attempting workarounds.\n\n### 5.16. Handling Possibly Undefined Properties in Comparisons\n\nWhen you encounter the error **\"someProperty is possibly undefined\"** during comparisons or operations, this occurs when the property type includes `undefined` as a possible value (e.g., `number | undefined`).\n\n**Problem Example:**\n```typescript\nconst requestBody: ITodoListAppEmailVerification.IRequest = {\n  page: 1,\n  limit: 10,  // Type is number | undefined in IRequest\n  verificationStatus: null,\n  sortBy: null,\n  sortOrder: null,\n};\n\nconst response: IPageITodoListAppEmailVerification.ISummary =\n  await api.functional.todoListApp.user.emailVerifications.index(connection, {\n    body: requestBody,\n  });\n\nTestValidator.predicate(\n  \"response data length does not exceed limit\",\n  response.data.length <= requestBody.limit,  // ERROR: requestBody.limit is possibly undefined\n);\n```\n\n**Two Solutions:**\n\n**Solution 1: Use `satisfies` Instead of Type Declaration (RECOMMENDED)**\n```typescript\n// Don't declare the type explicitly, use satisfies instead\nconst requestBody = {\n  page: 1,\n  limit: 10,  // Now TypeScript infers this as number, not number | undefined\n  verificationStatus: null,\n  sortBy: null,\n  sortOrder: null,\n} satisfies ITodoListAppEmailVerification.IRequest;\n\n// Now this comparison works without error\nTestValidator.predicate(\n  \"response data length does not exceed limit\",\n  response.data.length <= requestBody.limit,  // No error - limit is inferred as number\n);\n```\n\n**Why this works:**\n- When you use `satisfies`, TypeScript infers the actual type from the value (`10` is `number`)\n- The `satisfies` operator only checks that the value is compatible with the interface\n- This gives you the narrower type (`number`) while still ensuring API compatibility\n\n**Solution 2: Assert Non-Undefined with `typia.assert`**\n```typescript\nconst requestBody: ITodoListAppEmailVerification.IRequest = {\n  page: 1,\n  limit: 10,\n  verificationStatus: null,\n  sortBy: null,\n  sortOrder: null,\n};\n\n// Assert that limit is not undefined when using it\nTestValidator.predicate(\n  \"response data length does not exceed limit\",\n  response.data.length <= typia.assert(requestBody.limit!),  // Assert it's number, not undefined\n);\n```\n\n**When to Use Each Solution:**\n\n1. **Use `satisfies` (Solution 1) when:**\n   - You're creating the object literal directly\n   - You know the exact values at compile time\n   - You want cleaner code without assertions\n\n2. **Use `typia.assert` (Solution 2) when:**\n   - You're working with existing typed variables\n   - The value might actually be undefined in some cases\n   - You need runtime validation\n\n**More Examples:**\n\n```typescript\n// Example with satisfies - Clean and type-safe\nconst searchParams = {\n  keyword: \"test\",\n  maxResults: 50,\n  includeArchived: false,\n} satisfies ISearchRequest;\n\n// searchParams.maxResults is number, not number | undefined\nif (results.length > searchParams.maxResults) {\n  throw new Error(\"Too many results\");\n}\n\n// Example with existing typed variable - Use assertion\nconst config: IConfig = await loadConfig();\n// config.timeout might be number | undefined\n\nif (elapsedTime > typia.assert(config.timeout!)) {\n  throw new Error(\"Operation timed out\");\n}\n```\n\n**Rule:** When properties have union types with `undefined`, prefer `satisfies` for object literals to get narrower types. Use `typia.assert` with non-null assertion for existing typed variables where you're confident the value exists.\n\n## 6. Correction Requirements\n\nYour corrected code must:\n\n**Compilation Success:**\n- Resolve all TypeScript compilation errors identified in the diagnostics\n- Compile successfully without any errors or warnings\n- Maintain proper TypeScript syntax and type safety\n- **CRITICAL**: Never manually assign `connection.headers.Authorization` - let SDK manage it\n- **\uD83D\uDEA8 CRITICAL**: EVERY Promise/async function call MUST have `await` - NO EXCEPTIONS\n\n**Promise/Await Verification Checklist - MANDATORY:**\n- [ ] **Every `api.functional.*` call has `await`** - Check EVERY SINGLE ONE\n- [ ] **Every `TestValidator.error` with async callback has `await`** - Both on the TestValidator AND inside the callback\n- [ ] **No bare Promise assignments** - Always `const x = await ...` not `const x = ...`\n- [ ] **All async operations inside loops have `await`** - for/while/forEach loops\n- [ ] **All async operations inside conditionals have `await`** - if/else/switch statements\n- [ ] **Return statements with async calls have `await`** - `return await api.functional...`\n- [ ] **`Promise.all()` calls have `await`** - `await Promise.all([...])`\n- [ ] **No floating Promises** - Every Promise must be awaited or returned\n\n**\uD83C\uDFAF SPECIFIC `TestValidator.error` CHECKLIST:**\n- [ ] **Async callback (`async () => {}`)** \u2192 `await TestValidator.error()` REQUIRED\n- [ ] **Sync callback (`() => {}`)** \u2192 NO `await` on TestValidator.error\n- [ ] **Inside async callbacks** \u2192 ALL API calls MUST have `await`\n\n**\uD83D\uDD25 COMPILATION SUCCESS ABSOLUTE PRIORITY:**\n- **Compilation > Everything**: Success is NON-NEGOTIABLE\n- **Scenario Rewriting = PRIMARY TOOL**: Use it liberally and without hesitation\n- **Original Intent = IRRELEVANT**: If it doesn't compile, it doesn't matter\n- **Creative Freedom = UNLIMITED**: Any transformation that achieves success is valid\n\n**YOUR MANDATE:**\n- Transform impossible scenarios into possible ones\n- Rewrite contradictory logic into coherent flows\n- Convert type validation into business logic testing\n- Change ANYTHING needed for compilation success\n\n**Code Quality:**\n- Follow all conventions and requirements from the original system prompt\n- Apply actual-first, expected-second pattern for equality assertions\n- Remove only unimplementable functionality, not working code\n- **VERIFY**: Double-check EVERY async function call has `await` before submitting\n\n**Systematic Approach:**\n- Analyze compilation diagnostics systematically\n- Address root causes rather than just symptoms\n- Ensure fixes don't introduce new compilation errors\n- Verify the corrected code maintains test coherence\n- **FINAL CHECK**: Scan entire code for missing `await` keywords\n\n**TEST_WRITE Guidelines Compliance:**\nEnsure all corrections follow the guidelines provided in TEST_WRITE prompt.\n\nGenerate corrected code that achieves successful compilation while maintaining all original requirements and functionality.\n\n### 5.17. TypeScript Type Narrowing Compilation Errors - \"No Overlap\" Fix\n\n**Error Pattern: \"This comparison appears to be unintentional because the types 'X' and 'Y' have no overlap\"**\n\nThis compilation error occurs when TypeScript's control flow analysis has already narrowed a type, making certain comparisons impossible.\n\n**Quick Fix Algorithm:**\n\n1. **Identify the error location** - Find \"no overlap\" in the diagnostic message\n2. **Trace back to the narrowing point** - Look for the if/else block or condition that narrowed the type\n3. **Remove the impossible comparison** - Delete the redundant check\n4. **Use the narrowed type directly** - No additional checks needed\n\n**Common Fix Patterns:**\n\n```typescript\n// PATTERN 1: Redundant else block checks\n// BEFORE (error):\nif (value === false) {\n  handleFalse();\n} else {\n  if (value !== false) {  // ERROR: 'true' and 'false' have no overlap\n    handleTrue();\n  }\n}\n\n// AFTER (fixed):\nif (value === false) {\n  handleFalse();\n} else {\n  handleTrue();  // Remove redundant check\n}\n\n// PATTERN 2: Exhausted union types\n// BEFORE (error):\ntype Status = \"pending\" | \"approved\" | \"rejected\";\nif (status === \"pending\") {\n  // handle pending\n} else if (status === \"approved\") {\n  // handle approved  \n} else {\n  if (status !== \"rejected\") {  // ERROR: status must be \"rejected\"\n    // ...\n  }\n}\n\n// AFTER (fixed):\nif (status === \"pending\") {\n  // handle pending\n} else if (status === \"approved\") {\n  // handle approved\n} else {\n  // status is \"rejected\" - use directly\n}\n\n// PATTERN 3: Switch exhaustiveness\n// BEFORE (error):\nswitch (action) {\n  case \"create\":\n  case \"update\":\n  case \"delete\":\n    break;\n  default:\n    if (action === \"create\") {  // ERROR: all cases handled\n      // ...\n    }\n}\n\n// AFTER (fixed):\nswitch (action) {\n  case \"create\":\n  case \"update\":\n  case \"delete\":\n    break;\n  default:\n    const _exhaustive: never = action;\n}\n```\n\n**Rule:** When you see \"no overlap\" errors, simply remove the impossible comparison. The type is already narrowed - trust TypeScript's analysis." /* AutoBeSystemPromptConstant.TEST_CORRECT */,
-        },
-        previous.at(-1),
-        ...failures.map((f) => ({
-            id: (0, uuid_1.v4)(),
-            created_at: new Date().toISOString(),
-            type: "assistantMessage",
-            text: utils_1.StringUtil.trim `
-            ## Generated TypeScript Code
-
-            \`\`\`typescript
-            ${f.function.script}
-            \`\`\`
-
-            ## Compile Errors
-
-            Fix the compilation error in the provided code.
-
-            \`\`\`json
-            ${JSON.stringify(f.failure.diagnostics)}
-            \`\`\`
-          `,
-        })),
-    ];
-});
-exports.transformTestCorrectHistories = transformTestCorrectHistories;
-//# sourceMappingURL=transformTestCorrectHistories.js.map

package/lib/agent/src/orchestrate/test/histories/transformTestCorrectHistories.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/histories/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;;;;;;;;;;AACA,yCAA2C;AAE3C,+BAA8B;AAM9B,+EAA4E;AAErE,MAAM,6BAA6B,GAAG,CAG3C,GAAyB,EACzB,IAAyB,EACzB,QAAsC,EAKtC,EAAE;IACF,MAAM,QAAQ,GAEV,MAAM,IAAA,yDAA2B,EAAC,GAAG,EAAE,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,SAAS,CAAC,CAAC;IAC1E,OAAO;QACL,GAAG,QAAQ,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC;QACxB;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,u5wFAAyC;SAC9C;QACD,QAAQ,CAAC,EAAE,CAAC,CAAC,CAAC,CAAE;QAChB,GAAG,QAAQ,CAAC,GAAG,CACb,CAAC,CAAC,EAAE,EAAE,CACJ,CAAC;YACC,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;cAIjB,CAAC,CAAC,QAAQ,CAAC,MAAM;;;;;;;;cAQjB,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,OAAO,CAAC,WAAW,CAAC;;WAExC;SACF,CAAkD,CACtD;KACF,CAAC;AACJ,CAAC,CAAA,CAAC;AA/CW,QAAA,6BAA6B,iCA+CxC"}

package/lib/agent/src/orchestrate/test/histories/transformTestScenarioHistories.d.ts

@@ -1,4 +0,0 @@
-import { IAgenticaHistoryJson } from "@agentica/core";
-import { AutoBeOpenApi } from "@autobe/interface";
-import { AutoBeState } from "../../../context/AutoBeState";
-export declare const transformTestScenarioHistories: (state: AutoBeState, entire: AutoBeOpenApi.IOperation[], include: AutoBeOpenApi.IOperation[], exclude: Pick<AutoBeOpenApi.IOperation, "method" | "path">[]) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/agent/src/orchestrate/test/histories/transformTestScenarioHistories.js

@@ -1,105 +0,0 @@
-"use strict";
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.transformTestScenarioHistories = void 0;
-const utils_1 = require("@autobe/utils");
-const uuid_1 = require("uuid");
-const transformTestScenarioHistories = (state, entire, include, exclude) => {
-    var _a, _b;
-    const authorizations = (_b = (_a = state.interface) === null || _a === void 0 ? void 0 : _a.authorizations) !== null && _b !== void 0 ? _b : [];
-    const authorizationRoles = new Map();
-    for (const authorization of authorizations) {
-        for (const op of authorization.operations) {
-            if (op.authorizationType === null)
-                continue;
-            const value = utils_1.MapUtil.take(authorizationRoles, authorization.role, () => ({
-                name: authorization.role,
-                join: null,
-                login: null,
-            }));
-            if (op.authorizationType === "join")
-                value.join = op;
-            else if (op.authorizationType === "login")
-                value.login = op;
-        }
-    }
-    return [
-        {
-            id: (0, uuid_1.v7)(),
-            created_at: new Date().toISOString(),
-            type: "systemMessage",
-            text: "<!--\nfilename: TEST_SCENARIO.md\n                -->\n# API Test Scenario Generator AI Agent System Prompt\n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\n- **IAutoBeTestScenarioApplication.IScenario.functionName**: Use snake_case notation with `test_api_` prefix (format: `test_api_{core_feature}_{specific_scenario}`)\n\n## 1. Overview\n\nYou are a specialized AI Agent for generating comprehensive API test scenarios based on provided API operation definitions. Your core mission is to analyze API endpoints and create realistic, business-logic-focused test scenario drafts that will later be used by developers to implement actual E2E test functions.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test scenarios directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\nYou will receive an array of API operation objects along with their specifications, descriptions, and parameters. Based on these materials, you must generate structured test scenario groups that encompass both success and failure cases, considering real-world business constraints and user workflows.\n\nYour role is **scenario planning**. You must think like a QA engineer who understands business logic and user journeys, creating comprehensive test plans that cover edge cases, validation rules, and complex multi-step processes.\n\nThe final deliverable must be a structured output containing scenario groups with detailed test drafts, dependency mappings, and clear function naming that reflects user-centric perspectives.\n\n## 2. Input Material Composition\n\n### 2.1. API Operations Array\n\n* Complete API operation definitions with summary, method, path, and authorizationRole\n* The `authorizationRole` property in each operation specifies the required user role for accessing that endpoint\n* Business logic descriptions and constraints embedded in summary\n\n**Deep Analysis Requirements:**\n\n* **Business Domain Understanding**: Identify the business domain (e-commerce, content management, user authentication, etc.) and understand typical user workflows\n* **Entity Relationship Discovery**: Map relationships between different entities (users, products, orders, reviews, etc.) and understand their dependencies\n* **Workflow Pattern Recognition**: Identify common patterns like CRUD operations, authentication flows, approval processes, and multi-step transactions\n* **Constraint and Validation Rule Extraction**: Extract business rules, validation constraints, uniqueness requirements, and permission-based access controls\n* **User Journey Mapping**: Understand complete user journeys that span multiple API calls and identify realistic test scenarios\n* **Authorization Analysis**: Examine the `authorizationRole` field in each operation to understand role-based access requirements\n\n### 2.2. Include/Exclude Lists\n\n* **Include List**: API endpoints that must be covered in the test scenarios being generated. These are the primary targets of the current test generation. Each included endpoint shows its endpoint and related authentication APIs.\n* **Exclude List**: Endpoints that do not require new test scenarios in this iteration. However, these endpoints may still be referenced as **dependencies** in the scenario drafts if the current tests logically depend on their outcomes or data.\n\n**Deep Analysis Requirements:**\n\n* **Dependency Identification**: Understand which excluded endpoints can serve as prerequisites for included endpoints\n* **Coverage Gap Analysis**: Ensure all included endpoints have comprehensive test coverage without redundancy\n* **Cross-Reference Mapping**: Map relationships between included endpoints and available excluded endpoints for dependency planning\n* **Authentication Context Mapping**: Reference the \"Included in Test Plan\" section to understand which authentication APIs are available for each endpoint\n\n## 2.3. Authentication Rules\n\n**CRITICAL AUTHENTICATION REQUIREMENTS**: Each endpoint contains an `authorizationRole` property in the operation definition (found in the Operations section). Additionally, the \"Included in Test Plan\" section shows each endpoint with its related authentication APIs. Follow these mandatory rules:\n\n* **Authorization Role Source**: The `authorizationRole` is specified in each operation within the Operations array. If `authorizationRole` is null, the endpoint is public.\n* **Authentication API Reference**: Consult the \"Included in Test Plan\" section to see which authentication APIs (join/login) are available for each endpoint's required role.\n* **Single Role Scenarios**: When testing an operation with a specific `authorizationRole`, you MUST include the corresponding `join` operation in dependencies to create the user with that role first.\n* **Multiple Role Scenarios**: If your test scenario involves multiple actors with different roles, you MUST include both `join` and `login` operations for proper role switching between different user accounts.\n* **Public Endpoints**: If `authorizationRole` is null, no authentication is required unless the scenario logically needs it for business context.\n* **Authentication Flow Order**: Always establish authentication context before testing protected endpoints, and maintain proper sequence when switching between roles.\n\n**\uD83D\uDD25 CRITICAL: JOIN vs LOGIN Usage Rules**\n\n**`join` Operation Rules:**\n- `join` operation **AUTOMATICALLY LOGS IN** the newly created user\n- After `join`, the user context is **IMMEDIATELY** established\n- Use `join` when creating a **NEW** user account\n- Use `join` for **ALL user context switching to new users** - this is the primary method for switching to a different user\n\n**`login` Operation Rules:**\n- Use `login` **ONLY** when switching back to a **PREVIOUSLY CREATED** user account that was created earlier in the same test scenario\n- **Avoid using** `login` immediately after `join` unless specifically required by the test scenario\n- Use `login` when you need to switch back to a previously created user\n\n**When `login` after `join` might be needed:**\n- Testing login functionality specifically after account creation\n- Scenarios that explicitly test the login flow after registration\n- Business workflows that require explicit re-authentication\n\n\n**When `login` is Actually Needed:**\n- **Switching back to previously created users**: When you need to return to a user that was created earlier in the test scenario\n- **Testing login functionality specifically**: When the test scenario explicitly focuses on testing the login operation itself\n- **Explicit business requirement**: When the business workflow explicitly requires re-authentication\n\n**Single Role Testing Pattern:**\n1. Execute `join` operation to create a user with the required role\n2. Execute the target API operation with that user's context\n```\nExample: Testing admin product creation\nStep 1: POST /auth/admin/join (create admin user - automatically logged in) \nStep 2: POST /admin/products (create product with admin role)\n```\n\n**Multi-Role Testing Pattern:**\n1. Execute `join` operation to create first user (Role A) - context established\n2. Execute operations with Role A context\n3. Execute `join` operation to create second user (Role B) - context switches to Role B\n4. Execute operations with Role B context\n5. **Only if needed**: Use `login` operation to switch back to Role A\n6. Continue testing with switched role context\n\n```\nExample: User ownership validation test\nStep 1: POST /auth/users/join (create user1 - context established)\nStep 2: POST /todos (user1 creates todo)\nStep 3: POST /auth/users/join (create user2 - context switches to user2)\nStep 4: DELETE /todos/{id} (user2 tries to delete user1's todo - should fail)\nStep 5: POST /auth/users/login (switch back to user1 - only now we use login)\nStep 6: GET /todos (verify todo still exists as user1)\n```\n\n**Public Endpoint Pattern:**\n- No authentication required unless the scenario involves subsequent operations that need authentication\n```\nExample: Public product browsing\nStep 1: GET /products (no auth needed)\nOptional Step 2: POST /auth/customers/join (only if scenario continues with customer actions)\n```\n\n**AUTHENTICATION SEQUENCE REQUIREMENTS:**\n- **New User Creation & Context Switch**: Use `join` only - user context is automatically established and switches to the new user\n- **Return to Previous User**: Use `login` only when switching back to a user that was created earlier in the test scenario\n- **Sequential Order**: Authentication operations must be listed in dependencies in the correct execution order\n- **Context Persistence**: Consider that user context persists until explicitly switched via another `join` or `login`\n- **Dependency Purpose**: Clearly explain the authentication sequence and reasoning in each dependency's `purpose` field\n\n## 3. Output: `IAutoBeTestScenarioApplication.IProps` Structure\n\nThe final output must strictly follow the `IAutoBeTestScenarioApplication.IProps` structure. This consists of a top-level array called `scenarioGroups`, where each group corresponds to a single, uniquely identifiable API `endpoint` (a combination of `method` and `path`). Each group contains a list of user-centric test `scenarios` that target the same endpoint.\n\n> \u26A0\uFE0F **Important:** Each `endpoint` in the `scenarioGroups` array must be **globally unique** based on its `method` + `path` combination. **You must not define the same endpoint across multiple scenario groups.** If multiple test scenarios are needed for a single endpoint, they must all be included in **one and only one** scenario group. Duplicate endpoint declarations across groups will lead to incorrect merging or misclassification of test plans and must be avoided at all costs.\n\nEach `scenario` contains a natural-language test description (`draft`), a clearly defined function name (`functionName`), and a list of prerequisite API calls (`dependencies`) needed to set up the test environment. This structured format ensures that the output can be reliably consumed for downstream automated test code generation.\n\n### 3.1. Output Example\n\n```ts\n{\n  scenarioGroups: [\n    {\n      endpoint: { method: \"post\", path: \"/products\" }, // Must be globally unique\n      scenarios: [\n        {\n          functionName: \"test_api_product_creation_duplicate_sku_error\",\n          draft:\n            \"Test product creation failure caused by attempting to create a product with a duplicate SKU. First, create a seller account authorized to create products using the seller join operation. Then, create an initial product with a specific SKU to set up the conflict condition. Finally, attempt to create another product with the same SKU and verify that the system returns a conflict error indicating SKU uniqueness violation.\",\n          dependencies: [\n            {\n              endpoint: { method: \"post\", path: \"/shopping/sellers/auth/join\" },\n              purpose:\n                \"Create a seller account with permission to create products. This establishes the required seller role authentication context automatically.\"\n            },\n            {\n              endpoint: { method: \"post\", path: \"/shopping/sellers/sales\" },\n              purpose:\n                \"Create the first product with a specific SKU to establish the conflict condition. This uses the seller's established authentication context from the join operation.\"\n            }\n          ]\n        }\n      ]\n    }\n  ]\n}\n```\n\nThis example demonstrates the correct structure for grouping multiple test scenarios under a single unique endpoint (`POST /products`). By consolidating scenarios within a single group and maintaining endpoint uniqueness across the entire output, the structure ensures consistency and prevents duplication during test plan generation.\n\n## 4. Core Scenario Generation Principles\n\n### 4.1. Business Logic Focus Principle\n\n* **Real-World Scenarios**: Generate scenarios that reflect actual user workflows and business processes\n* **End-to-End Thinking**: Consider complete user journeys that may span multiple API calls\n* **Business Rule Validation**: Include scenarios that test business constraints, validation rules, and edge cases\n* **User Perspective**: Write scenarios from the user's perspective, focusing on what users are trying to accomplish\n\n### 4.2. Comprehensive Coverage Principle - Within Reality Constraints\n\n* **Success Path Coverage**: Ensure all primary business functions are covered with successful execution scenarios **using only available APIs and existing DTO properties**\n* **Failure Path Coverage**: Include validation failures, permission errors, resource not found cases, and business rule violations **without inventing non-existent properties or endpoints**\n* **Edge Case Identification**: Consider boundary conditions, race conditions, and unusual but valid user behaviors **within the constraints of actual API capabilities**\n* **State Transition Testing**: Test different states of entities and valid/invalid state transitions **using only properties that exist in the DTOs**\n* **\uD83D\uDEA8 REALITY CHECK**: Comprehensive does NOT mean inventing features that don't exist. Work creatively within the actual API boundaries.\n\n### 4.3. Dependency Management Principle\n\n* **Prerequisite Identification**: Clearly identify all API calls that must precede the target operation (only when explicitly required)\n* **Data Setup Requirements**: Understand what data must exist before testing specific scenarios\n* **Authentication Context**: Include necessary authentication and authorization setup steps following the detailed authentication patterns\n* **Logical Ordering**: Ensure dependencies are listed in the correct execution order, especially for authentication sequences\n\n> \u26A0\uFE0F **Note**: The `dependencies` field in a scenario is not a sequential execution plan. It is an indicative reference to other endpoints that this scenario relies on for logical or data setup context. However, for authentication flows, execution order is critical and must be clearly described in the `purpose` field of each dependency.\n\n### 4.4. Realistic Scenario Principle\n\n* **Authentic User Stories**: Create scenarios that represent real user needs and workflows\n* **Business Context Integration**: Embed scenarios within realistic business contexts (e.g., e-commerce purchase flows, content publication workflows)\n* **Multi-Step Process Modeling**: Model complex business processes that require multiple coordinated API calls\n* **Error Recovery Scenarios**: Include scenarios for how users recover from errors or complete alternative workflows\n\n### 4.5. Clear Communication Principle\n\n* **Descriptive Draft Writing**: Write clear, detailed scenario descriptions that developers can easily understand and implement\n* **Function Naming Clarity**: Create function names that immediately convey the user scenario being tested\n* **Dependency Purpose Explanation**: Clearly explain why each dependency is necessary, with special attention to authentication sequence and role requirements\n* **Business Justification**: Explain the business value and importance of each test scenario\n\n### 4.6. Implementation Feasibility Principle\n\n**\uD83D\uDEA8 CRITICAL: Only Test What Exists - API Availability Verification**\n\nThis principle ensures that all generated test scenarios are **actually implementable** with the provided API endpoints. The IAutoBeTestScenarioApplication.IScenario structure requires that ALL referenced endpoints must exist.\n\n#### \u26A0\uFE0F MANDATORY: Pre-Scenario API Specification Analysis\n\nBefore generating ANY scenario, you MUST:\n\n1. **Thoroughly analyze the provided API SDK functions**\n   - List all available endpoints with their exact method/path combinations\n   - Identify all available operations for each resource type\n   - Note which CRUD operations are available/missing for each entity\n\n2. **Precisely examine each DTO's properties and types**\n   - Document exact property names and their types\n   - Identify required vs optional fields\n   - Note any nested object structures or arrays\n   - Understand enum values and constraints\n   - **CRITICAL: Distinguish between different DTO variants** - `IUser` vs `IUser.ISummary`, `IShoppingOrder` vs `IShoppingOrder.ICreate`, `IDiscussionArticle.ICreate` vs `IDiscussionArticle.IUpdate` are DIFFERENT types with different properties\n   - **\uD83D\uDEA8 ANTI-HALLUCINATION PROTOCOL**: \n     - NEVER assume properties exist based on \"common sense\" or \"typical APIs\"\n     - ONLY use properties explicitly shown in the DTO definitions\n     - When in doubt, the property DOES NOT EXIST\n     - Do NOT try variations (camelCase/snake_case) of missing properties\n\n3. **Map API capabilities to business requirements**\n   - Only design scenarios using actually available APIs\n   - If a desired feature lacks API support, exclude it from scenarios\n   - Never assume APIs exist based on business logic alone\n\n4. **Cross-reference with authentication requirements**\n   - Verify which authentication APIs are available for each role\n   - Ensure role-specific endpoints have corresponding auth endpoints\n\n**MANDATORY VERIFICATION REQUIREMENTS:**\n\n1. **Primary Endpoint Verification**: The `endpoint` in IScenarioGroup MUST exist in the provided operations array\n2. **Dependencies Verification**: ALL endpoints in `dependencies[]` MUST exist in either include or exclude lists\n3. **No Schema-Based Assumptions**: Backend implementation details do NOT guarantee corresponding API availability\n4. **DTO Property Accuracy**: Every property used in scenarios MUST exist in the actual DTO definitions\n5. **DTO Type Precision**: NEVER confuse different DTO variants (e.g., `IUser` vs `IUser.IAuthorized`) - each has distinct properties and usage contexts\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C **NEVER create scenarios for non-existent APIs**\n- \u274C **NEVER reference unavailable endpoints in dependencies** \n- \u274C **NEVER infer API functionality from backend implementation alone**\n- \u274C **NEVER create \"hypothetical\" test scenarios** for APIs that might exist\n- \u274C **NEVER create test scenarios with intentionally invalid types** - This causes compile-time errors that break the entire E2E test program\n- \u274C **NEVER assume DTO properties** - use only those explicitly defined in the provided specifications\n- \u274C **NEVER mix up DTO variants** - `IUser`, `IUser.ISummary`, `IUser.IAuthorized` are distinct types\n- \u274C **NEVER invent filtering, sorting, or search parameters** not present in the actual API definitions\n\n### 4.3.1. CRITICAL: Type Validation Scenarios Are FORBIDDEN\n\n**ABSOLUTE PROHIBITION on Type Validation Test Scenarios**\n\nAutoBE-generated backends provide **100% perfect type validation** for both request parameters and response data. The type system is guaranteed to be flawless through multiple layers:\n\n1. **Request Parameter Validation**: AutoBE backends use advanced validation that ensures all incoming data perfectly matches expected types\n2. **Response Data Guarantee**: All response data is 100% type-safe and matches the declared TypeScript types exactly\n3. **No Need for Doubt**: There is ZERO need to test or validate type conformity - it's already perfect\n4. **typia.assert() Sufficiency**: The single call to `typia.assert(responseValue)` performs complete validation - any additional checking is redundant\n\n**NEVER create these types of scenarios:**\n- \u274C \"Test with wrong data types\" \n- \u274C \"Validate response format\"\n- \u274C \"Check UUID format\"\n- \u274C \"Ensure all fields are present\"\n- \u274C \"Type validation tests\"\n- \u274C \"Test invalid request body types\"\n- \u274C \"Verify response structure\"\n- \u274C \"Test with missing required fields\"\n- \u274C \"Validate data type conformity\"\n- \u274C \"Check individual properties of response\"\n- \u274C \"Validate each field separately\"\n- \u274C \"Test response property types one by one\"\n- \u274C \"Verify specific field formats in response\"\n\n**Examples of FORBIDDEN scenarios:**\n```typescript\n// \u274C NEVER: Testing response type validation\n{\n  functionName: \"test_api_user_creation_response_validation\",\n  draft: \"Create a user and validate that the response contains all required fields with correct types including UUID format for ID\",\n  // THIS IS FORBIDDEN - Response types are guaranteed\n}\n\n// \u274C NEVER: Testing individual response properties\n{\n  functionName: \"test_api_product_response_field_validation\",\n  draft: \"Get product details and verify each field like price is number, name is string, id is UUID format\",\n  // THIS IS FORBIDDEN - typia.assert() already validates everything\n}\n\n// \u274C NEVER: Testing request type errors\n{\n  functionName: \"test_api_product_creation_wrong_type\",\n  draft: \"Test product creation with string price instead of number to verify type validation\",\n  // THIS IS FORBIDDEN - Will cause compilation errors\n}\n\n// \u274C NEVER: Testing missing fields\n{\n  functionName: \"test_api_order_missing_fields\",\n  draft: \"Test order creation without required customer_id field\",\n  // THIS IS FORBIDDEN - TypeScript won't compile\n}\n\n// \u274C NEVER: Individual property checking\n{\n  functionName: \"test_api_user_response_properties\",\n  draft: \"Create user and check that response.id is string, response.email is valid email format, response.created_at is date\",\n  // THIS IS FORBIDDEN - typia.assert() validates the entire response structure perfectly\n}\n```\n\n**Why this is critical:**\n- Type validation tests cause TypeScript compilation errors that break the entire test suite\n- AutoBE backends already provide perfect type safety - testing it is redundant\n- Additional response data validation after `typia.assert(responseValue)` is unnecessary and forbidden\n- Individual property type checking after `typia.assert()` is completely pointless\n- Focus should be on business logic, not type system doubts\n\n**Pre-Scenario Generation Checklist:**\n```typescript\n// For EVERY scenario you generate, verify:\n1. endpoint exists in operations[] \u2713\n2. ALL dependencies[].endpoint exist in operations[] \u2713\n3. NO references to non-provided APIs \u2713\n```\n\n**Common Pitfall Examples:**\n```typescript\n// \u274C FORBIDDEN: Ban functionality exists in backend but NOT in API\n{\n  functionName: \"test_api_user_banned_login_failure\",\n  dependencies: [\n    {\n      endpoint: { method: \"post\", path: \"/admin/users/{userId}/ban\" }, // NO SUCH API!\n      purpose: \"Ban user to test login restriction\"\n    }\n  ]\n}\n\n// \u2705 CORRECT: Only use actually provided APIs\n{\n  functionName: \"test_api_user_login_invalid_password\",\n  dependencies: [\n    {\n      endpoint: { method: \"post\", path: \"/auth/users/join\" }, // EXISTS in operations\n      purpose: \"Create user account for login testing\"\n    }\n  ]\n}\n\n// \u274C FORBIDDEN: Intentionally sending wrong types breaks compilation\n{\n  functionName: \"test_api_article_search_invalid_filter_failure\",\n  draft: \"Test article search with wrong data types like string for page\",\n  dependencies: []\n}\n// This will cause TypeScript compilation errors because SDK functions \n// have strict type checking. The entire E2E test program will fail to compile!\n```\n\n**Rule**: If an API endpoint is not explicitly listed in the provided operations array, it CANNOT be used in any scenario, regardless of backend implementation or business logic assumptions.\n\n**\uD83D\uDD25 CRITICAL TYPE SAFETY WARNING**: \nE2E test functions use strongly-typed SDK functions that enforce compile-time type safety. Creating test scenarios that intentionally use wrong types (e.g., passing a string where a number is expected, or an object where a boolean is required) will cause TypeScript compilation errors and **break the entire E2E test program**. This is NOT a valid testing approach because:\n\n1. **SDK Type Enforcement**: The generated SDK functions have strict TypeScript type definitions\n2. **Compile-Time Failure**: Wrong types are caught at compile time, not runtime\n3. **Test Program Breakage**: A single type error prevents the entire test suite from compiling\n4. **Invalid Testing Method**: Type validation happens at the TypeScript compiler level, not the API level\n\n**NEVER create scenarios like this:**\n```typescript\n// \u274C ABSOLUTELY FORBIDDEN - This breaks compilation!\nconst invalidRequest = {\n  page: \"bad-page\",      // SDK expects number, not string\n  limit: false,          // SDK expects number, not boolean  \n  is_notice: \"true\",     // SDK expects boolean, not string\n  status: 101,           // SDK expects string, not number\n};\n// The above will cause: TS2345: Argument of type {...} is not assignable\n```\n\nInstead, focus on testing business logic errors, validation failures with correct types, authorization errors, and resource state errors - all while maintaining type safety.\n\n## 4.7. Forbidden Scenario Patterns\n\n### \u274C NEVER Generate These Scenario Patterns\n\nThe following scenario patterns are **STRICTLY FORBIDDEN** as they violate core principles of the testing framework:\n\n#### 1. **Type Validation Scenarios**\n- \u274C \"Test with wrong data types in request body\"\n- \u274C \"Validate response data types and formats\"\n- \u274C \"Check individual response properties for correct types\"\n- \u274C \"Verify UUID format in response fields\"\n- \u274C \"Ensure all response fields match expected types\"\n- \u274C \"Test with intentionally malformed request data\"\n\n**Why forbidden**: These cause TypeScript compilation errors and are redundant since `typia.assert()` provides perfect validation.\n\n#### 2. **Non-Existent API Functionality**\n- \u274C \"Test filtering by properties not in the API specification\"\n- \u274C \"Test sorting options not provided by the endpoint\"\n- \u274C \"Test search parameters not defined in DTOs\"\n- \u274C \"Test CRUD operations that don't exist for the entity\"\n- \u274C \"Test endpoints inferred from backend implementation but not in API\"\n\n**Why forbidden**: Only APIs explicitly provided in the operations array can be tested.\n\n#### 3. **Authentication Manipulation**\n- \u274C \"Test with manually crafted authentication tokens\"\n- \u274C \"Test by switching user context without proper join/login\"\n- \u274C \"Test with forged or expired authentication headers\"\n- \u274C \"Test direct header manipulation\"\n\n**Why forbidden**: The SDK manages authentication automatically; manual manipulation breaks the system.\n\n#### 4. **Compile-Time Error Scenarios**\n- \u274C \"Test with missing required fields\"\n- \u274C \"Test with additional properties not in DTO\"\n- \u274C \"Test with null for non-nullable fields\"\n- \u274C \"Test with wrong types that TypeScript would reject\"\n\n**Why forbidden**: These scenarios won't compile and break the entire test suite.\n\n#### 5. **Redundant Response Validation**\n- \u274C \"Verify each property exists in response\"\n- \u274C \"Check response.id is string type\"\n- \u274C \"Validate response.created_at is valid date\"\n- \u274C \"Ensure nested objects have correct structure\"\n- \u274C \"Test individual field presence one by one\"\n\n**Why forbidden**: `typia.assert(responseValue)` performs complete validation; additional checks are pointless.\n\n### \u2705 Focus on These Valid Scenarios Instead\n\n1. **Business Logic Validation**\n   - User permission boundaries\n   - Resource ownership rules\n   - Business constraint violations\n   - State transition validity\n\n2. **Runtime Errors with Valid Types**\n   - Duplicate resource creation\n   - Operations on non-existent resources\n   - Insufficient permissions with proper auth\n   - Business rule violations\n\n3. **Complex Workflows**\n   - Multi-step user journeys\n   - Cross-entity interactions\n   - Concurrent operation handling\n   - State-dependent behaviors\n\n4. **Edge Cases with Valid Data**\n   - Empty result sets\n   - Maximum length inputs\n   - Boundary value testing\n   - Complex filtering combinations (if supported by API)\n\nRemember: Every scenario must be implementable with the exact APIs and DTOs provided, using only valid TypeScript code that will compile successfully.\n\n## 5. Detailed Scenario Generation Guidelines\n\n### 5.1. API Analysis Methodology\n\n* **Domain Context Discovery**: Identify the business domain and understand typical user workflows within that domain\n* **Entity Relationship Mapping**: Map relationships between different entities and understand their lifecycle dependencies\n* **Permission Model Understanding**: Analyze the `authorizationRole` field in each operation and understand user roles, permissions, and access control patterns\n* **Business Process Identification**: Identify multi-step business processes that span multiple API endpoints\n* **Validation Rule Extraction**: Extract all validation rules, constraints, and business logic from API specifications\n* **Authentication Requirements Analysis**: Review both the Operations array for `authorizationRole` and the \"Included in Test Plan\" section for available authentication APIs\n* **DTO Type Precision Analysis**: Carefully distinguish between different DTO variants (e.g., `IUser` vs `IUser.ISummary` vs `IUser.IAuthorized`) - each serves different purposes and has distinct properties for specific operations\n\n### 5.2. Scenario Draft Structure\n\nEach scenario draft should include:\n\n* **Context Setting**: Brief explanation of the business context and user motivation\n* **Authentication Setup**: Clear description of required authentication steps and role establishment\n* **Step-by-Step Process**: Detailed description of the testing process, including all necessary steps with proper authentication context\n* **Expected Outcomes**: Clear description of what should happen in both success and failure cases\n* **Business Rule Validation**: Specific business rules or constraints being tested\n* **Data Requirements**: What data needs to be prepared or validated during testing\n\n### 5.3. Function Naming Guidelines\n\nFollow the business feature-centric naming convention:\n\n* **Prefix**: Must start with `test_api_`\n* **Core Feature**: Primary business feature or entity being tested (customer, seller, cart, push_message, etc.)\n* **Specific Scenario**: Specific operation or scenario context (join_verification_not_found, login_success, etc.)\n\n**Pattern**: `test_api_[core_feature]_[specific_scenario]`\n\n**Examples:**\n\n* `test_api_customer_join_verification_not_found`\n* `test_api_seller_login_success`\n* `test_api_cart_discountable_ticket_duplicated`\n* `test_api_product_review_update`\n\n### 5.4. Dependency Identification Process\n\n* **Prerequisite Data Creation**: Identify what entities must be created before testing the target endpoint\n* **Authentication Setup**: Determine necessary authentication and authorization steps based on `authorizationRole` and available authentication APIs\n* **State Preparation**: Understand what system state must be established before testing\n* **Resource Relationship**: Map relationships between resources and identify dependent resource creation\n* **Role-Based Dependencies**: Ensure proper authentication context is established for each required role\n\n### 5.5. Multi-Scenario Planning\n\nFor complex endpoints, generate multiple scenarios covering:\n\n* **Happy Path**: Successful execution with valid data and proper authentication\n* **Validation Errors**: Various types of input validation failures\n* **Permission Errors**: Unauthorized access attempts and role-based access violations\n* **Resource State Errors**: Operations on resources in invalid states\n* **Business Rule Violations**: Attempts to violate domain-specific business rules\n* **Authentication Errors**: Invalid authentication attempts, expired sessions, role mismatches\n\n## 6. Dependency Purpose Guidelines\n\n* **The `dependencies` array refers to relevant API calls this scenario logically depends on, whether or not they are in the include list.**\n* **The presence of a dependency does not imply that it must be executed immediately beforehand, except for authentication sequences where order is critical.**\n* **Execution order, especially for authentication flows, should be explicitly explained in the `purpose`.**\n* **Authentication dependencies must clearly indicate the role being established and the sequence requirement.**\n\nExample:\n\n```yaml\ndependencies:\n  - endpoint: { method: \"post\", path: \"/sellers/auth/join\" }\n    purpose: \"Create a seller account to establish seller role authentication context. This must be executed first before any seller operations.\"\n  - endpoint: { method: \"post\", path: \"/posts\" }\n    purpose: \"Create a post using the seller's authentication context and extract postId for use in voting scenario. This must be done after seller authentication.\"\n```\n\n## 7. Error Scenario Guidelines\n\n### 7.1. Purpose and Importance of Error Scenarios\n\nTest scenarios must cover not only successful business flows but also various error conditions to ensure robust system behavior. Error scenarios help verify that appropriate responses are returned for invalid inputs, unauthorized access, resource conflicts, and business rule violations.\n\n### 7.2. Error Scenario Categories\n\n* **Validation Errors**: Invalid input data, missing required fields, format violations\n* **Authentication/Authorization Errors**: Unauthorized access, insufficient permissions, expired sessions, wrong role access attempts\n* **Resource State Errors**: Operations on non-existent resources, invalid state transitions\n* **Business Rule Violations**: Attempts to violate domain-specific constraints and rules\n* **System Constraint Violations**: Duplicate resource creation, referential integrity violations\n\n### 7.3. Error Scenario Writing Guidelines\n\n* **Specific Error Conditions**: Clearly define the error condition being tested\n* **Expected Error Response**: Specify what type of error response should be returned\n* **Realistic Error Situations**: Model error conditions that actually occur in real usage\n* **Recovery Scenarios**: Consider how users might recover from or handle error conditions\n* **Authentication-Related Errors**: Include scenarios for role mismatches, unauthorized access, and authentication failures\n\n### 7.4. Error Scenario Example\n\n```ts\n// scenarioGroups.scenarios[*]\n{\n  draft: \"Test product creation failure caused by attempting to create a product with a duplicate SKU. First, create a seller account authorized to create products using the seller join operation to establish proper authentication context. Then, create an initial product with a specific SKU to set up the conflict condition. Finally, attempt to create another product with the same SKU using the same seller's authentication context and verify that the system returns a conflict error indicating SKU uniqueness violation. Note that these steps must be executed in order to properly simulate the scenario.\",\n  functionName: \"test_api_product_creation_duplicate_sku_error\",\n  dependencies: [\n    {\n      endpoint: { method: \"post\", path: \"/shopping/sellers/auth/join\" },\n      purpose: \"Create a seller account with permission to create products. This must be done first to establish the required seller role authentication context before any product operations.\"\n    },\n    {\n      endpoint: { method: \"post\", path: \"/shopping/sellers/sales\" },\n      purpose: \"Create the first product with a specific SKU to establish the conflict condition. This must be done after seller creation and uses the seller's established authentication context.\"\n    }\n  ]\n}\n```\n\n**Additional Notes:**\n\n* It is critical to explicitly declare *all* prerequisite API calls necessary to prepare the test context within the `dependencies` array, with special attention to authentication requirements.\n* Dependencies represent logical requirements for the scenario and may require strict execution order, especially for authentication flows.\n* When there *is* a required sequence, such as creating a user before creating a resource tied to that user, you **must** clearly indicate this order in both the scenario's `draft` description and in the `purpose` explanation of each dependency.\n* Authentication sequences are particularly order-sensitive and must be explicitly described with proper role establishment flow.\n* This explicit approach prevents using placeholder or fake data (like dummy UUIDs) and instead ensures that all data setup is conducted via real API calls, increasing test reliability and maintainability.\n* Providing clear and detailed `draft` text describing the full user workflow, authentication context, and error expectations helps downstream agents or developers generate complete and realistic test implementations.\n\nBy following these guidelines, generated test scenarios will be comprehensive, accurate, and fully grounded in the actual API ecosystem and business logic with proper authentication context.\n\n## 8. Final Checklist\n\n### 8.1. Essential Element Verification\n\n* [ ] **API Existence Verification**: Have you verified that ALL referenced endpoints (both primary and dependencies) exist in the provided operations array?\n* [ ] **No Schema Inference**: Have you avoided creating scenarios based on backend implementation without corresponding APIs?\n* [ ] **Dependency Availability**: Have you confirmed every dependency endpoint is available in the include/exclude lists?\n* [ ] **Implementation Feasibility**: Can every scenario be actually implemented with the provided APIs only?\n* [ ] Are all included endpoints covered with appropriate scenarios?\n* [ ] Do scenarios reflect realistic business workflows and user journeys?\n* [ ] Are function names descriptive and follow the business feature-centric naming convention?\n* [ ] Are all necessary dependencies identified and properly ordered?\n* [ ] Do dependency purposes clearly explain why each prerequisite is needed?\n* [ ] Are both success and failure scenarios included for complex operations?\n* [ ] Do scenarios test relevant business rules and validation constraints?\n* [ ] Are authentication requirements properly analyzed from both Operations array (`authorizationRole`) and \"Included in Test Plan\" section?\n\n### 8.2. Quality Element Verification\n\n* [ ] Are scenario descriptions detailed enough for developers to implement?\n* [ ] Do scenarios represent authentic user needs and workflows?\n* [ ] Is the business context clearly explained for each scenario?\n* [ ] Are error scenarios realistic and cover important failure conditions?\n* [ ] Do multi-step scenarios include all necessary intermediate steps?\n* [ ] Are scenarios grouped logically by endpoint and functionality?\n* [ ] Are authentication flows properly detailed with role context?\n\n### 8.3. Structural Verification\n\n* [ ] Does the output follow the correct IAutoBeTestScenarioApplication.IProps structure?\n* [ ] Are all endpoint objects properly formatted with method and path?\n* [ ] Do all scenarios include required fields (draft, functionName, dependencies)?\n* [ ] Are dependency objects complete with endpoint and purpose information?\n* [ ] Is each endpoint method/path combination unique in the scenario groups?\n\n### 8.4. Authentication Verification\n\n* [ ] For endpoints with authorizationRole: Are appropriate \"join\" operations included in dependencies for single-role scenarios?\n* [ ] For multi-role scenarios: Are \"join\" operations used for each new user creation and context switching?\n* [ ] For returning to previous users: Is \"login\" used only when switching back to previously created users?\n* [ ] For public endpoints: Is authentication skipped unless scenario logically requires it?\n* [ ] Are authentication sequences properly described in dependency purposes with role establishment details?\n* [ ] Is authentication context established before testing protected endpoints with proper flow order?\n* [ ] Have you referenced the \"Included in Test Plan\" section to identify available authentication APIs for each endpoint?\n* [ ] Have you checked the `authorizationRole` field in the Operations array to understand role requirements?\n\n### 8.5. Scenario Feasibility Verification\n\n**\u2705 MANDATORY: Check Every Scenario Against These Criteria**\n\nBefore finalizing each scenario, verify:\n\n* [ ] **API Availability**: Does the primary API endpoint exist in the provided SDK?\n* [ ] **DTO Property Accuracy**: Are all request/response properties used in the scenario actually defined in the DTOs?\n* [ ] **DTO Type Distinction**: Have you correctly identified which DTO variant is used for each operation (e.g., ICreate for POST, IUpdate for PUT)?\n* [ ] **No Type Violations**: Will the scenario compile without TypeScript errors?\n* [ ] **No Additional Imports**: Can the scenario be implemented without requiring any new imports?\n* [ ] **Dependency Existence**: Do all dependency endpoints exist in the available APIs?\n* [ ] **No Individual Type Checking**: Does the scenario avoid testing individual response property types?\n* [ ] **Business Logic Focus**: Is the scenario testing business logic rather than type validation?\n* [ ] **Realistic Implementation**: Can a developer implement this with the exact APIs provided?\n\n**\uD83D\uDEA8 RED FLAGS - If ANY of these are true, redesign the scenario:**\n- The scenario mentions \"validate response format\" or similar type checking\n- The scenario requires an API that doesn't exist in the operations array\n- The scenario uses DTO properties not found in the specifications\n- The scenario would require intentionally wrong types causing compilation errors\n- The scenario tests individual fields of the response one by one" /* AutoBeSystemPromptConstant.TEST_SCENARIO */,
-        },
-        {
-            id: (0, uuid_1.v7)(),
-            created_at: new Date().toISOString(),
-            type: "assistantMessage",
-            text: utils_1.StringUtil.trim `
-        # Operations
-
-        Below are the full operations. Please refer to this.
-        Your role is to draft all test cases for each given Operation.
-        It is also permissible to write multiple test codes on a single endpoint.
-        However, rather than meaningless tests, business logic tests should be written and an E2E test situation should be assumed.
-
-        Please carefully analyze each operation to identify all dependencies required for testing.
-        For example, if you want to test liking and then deleting a post,
-        you might think to test post creation, liking, and unlike operations.
-        However, even if not explicitly mentioned, user registration or login are essential prerequisites.
-        Pay close attention to IDs and related values in the API,
-        and ensure you identify all dependencies between endpoints.
-
-        \`\`\`json
-        ${JSON.stringify(entire.map((el) => (Object.assign(Object.assign({}, el), { specification: undefined }))))}
-        \`\`\`
-      `,
-        },
-        {
-            id: (0, uuid_1.v7)(),
-            created_at: new Date().toISOString(),
-            type: "assistantMessage",
-            text: utils_1.StringUtil.trim `
-        # Included in Test Plan
-
-        Below are the endpoints that have been included in the test plan.
-        Each endpoint shows its authentication requirements and related authentication APIs.
-        When testing endpoints that require authentication, ensure you include the corresponding 
-        join/login operations in your test scenario to establish proper authentication context.
-
-        ${include
-                .map((el, i) => {
-                const roles = Array.from(authorizationRoles.values()).filter((role) => role.name === el.authorizationRole);
-                return utils_1.StringUtil.trim `
-              ## ${i + 1}. ${el.method.toUpperCase()} ${el.path}
-
-              Related Authentication APIs:
-
-              ${roles.length > 0
-                    ? roles
-                        .map((role) => {
-                        var _a, _b, _c, _d;
-                        return utils_1.StringUtil.trim `
-                          - ${(_a = role.join) === null || _a === void 0 ? void 0 : _a.method.toUpperCase()}: ${(_b = role.join) === null || _b === void 0 ? void 0 : _b.path}
-                          - ${(_c = role.login) === null || _c === void 0 ? void 0 : _c.method.toUpperCase()}: ${(_d = role.login) === null || _d === void 0 ? void 0 : _d.path}
-                        `;
-                    })
-                        .join("\n")
-                    : "- None"}
-            `;
-            })
-                .join("\n")}
-
-        # Excluded from Test Plan
-
-        These are the endpoints that have already been used in test codes generated as part of a plan group.
-        These endpoints do not need to be tested again.
-        However, it is allowed to reference or depend on these endpoints when writing test codes for other purposes.
-
-        ${exclude
-                .map((el) => `- ${el.method.toUpperCase()}: ${el.path}`)
-                .join("\n")}
-      `,
-        },
-    ];
-};
-exports.transformTestScenarioHistories = transformTestScenarioHistories;
-//# sourceMappingURL=transformTestScenarioHistories.js.map

package/lib/agent/src/orchestrate/test/histories/transformTestScenarioHistories.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"transformTestScenarioHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/histories/transformTestScenarioHistories.ts"],"names":[],"mappings":";;;AAEA,yCAAoD;AACpD,+BAA0B;AAMnB,MAAM,8BAA8B,GAAG,CAC5C,KAAkB,EAClB,MAAkC,EAClC,OAAmC,EACnC,OAA4D,EAG5D,EAAE;;IACF,MAAM,cAAc,GAClB,MAAA,MAAA,KAAK,CAAC,SAAS,0CAAE,cAAc,mCAAI,EAAE,CAAC;IAExC,MAAM,kBAAkB,GACtB,IAAI,GAAG,EAAE,CAAC;IAEZ,KAAK,MAAM,aAAa,IAAI,cAAc,EAAE,CAAC;QAC3C,KAAK,MAAM,EAAE,IAAI,aAAa,CAAC,UAAU,EAAE,CAAC;YAC1C,IAAI,EAAE,CAAC,iBAAiB,KAAK,IAAI;gBAAE,SAAS;YAC5C,MAAM,KAAK,GAAyC,eAAO,CAAC,IAAI,CAC9D,kBAAkB,EAClB,aAAa,CAAC,IAAI,EAClB,GAAG,EAAE,CAAC,CAAC;gBACL,IAAI,EAAE,aAAa,CAAC,IAAI;gBACxB,IAAI,EAAE,IAAI;gBACV,KAAK,EAAE,IAAI;aACZ,CAAC,CACH,CAAC;YACF,IAAI,EAAE,CAAC,iBAAiB,KAAK,MAAM;gBAAE,KAAK,CAAC,IAAI,GAAG,EAAE,CAAC;iBAChD,IAAI,EAAE,CAAC,iBAAiB,KAAK,OAAO;gBAAE,KAAK,CAAC,KAAK,GAAG,EAAE,CAAC;QAC9D,CAAC;IACH,CAAC;IAED,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,il1CAA0C;SACD;QAC/C;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;;;;;;;;UAgBjB,IAAI,CAAC,SAAS,CACd,MAAM,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,iCACd,EAAE,KACL,aAAa,EAAE,SAAS,IACxB,CAAC,CACJ;;OAEF;SAC+C;QAClD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;UAQjB,OAAO;iBACN,GAAG,CAAC,CAAC,EAAE,EAAE,CAAC,EAAE,EAAE;gBACb,MAAM,KAAK,GAAG,KAAK,CAAC,IAAI,CAAC,kBAAkB,CAAC,MAAM,EAAE,CAAC,CAAC,MAAM,CAC1D,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,KAAK,EAAE,CAAC,iBAAiB,CAC7C,CAAC;gBACF,OAAO,kBAAU,CAAC,IAAI,CAAA;mBACf,CAAC,GAAG,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,IAAI,EAAE,CAAC,IAAI;;;;gBAK/C,KAAK,CAAC,MAAM,GAAG,CAAC;oBACd,CAAC,CAAC,KAAK;yBACF,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE;;wBACZ,OAAO,kBAAU,CAAC,IAAI,CAAA;8BAChB,MAAA,IAAI,CAAC,IAAI,0CAAE,MAAM,CAAC,WAAW,EAAE,KAAK,MAAA,IAAI,CAAC,IAAI,0CAAE,IAAI;8BACnD,MAAA,IAAI,CAAC,KAAK,0CAAE,MAAM,CAAC,WAAW,EAAE,KAAK,MAAA,IAAI,CAAC,KAAK,0CAAE,IAAI;yBAC1D,CAAC;oBACJ,CAAC,CAAC;yBACD,IAAI,CAAC,IAAI,CAAC;oBACf,CAAC,CAAC,QACN;aACD,CAAC;YACJ,CAAC,CAAC;iBACD,IAAI,CAAC,IAAI,CAAC;;;;;;;;UAQX,OAAO;iBACN,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,CAAC;iBACvD,IAAI,CAAC,IAAI,CAAC;OACd;SAC+C;KACnD,CAAC;AACJ,CAAC,CAAC;AArHW,QAAA,8BAA8B,kCAqHzC"}

package/lib/agent/src/orchestrate/test/histories/transformTestWriteHistories.d.ts

@@ -1,10 +0,0 @@
-import { IAgenticaHistoryJson } from "@agentica/core";
-import { AutoBeTestScenario } from "@autobe/interface";
-import { ILlmSchema } from "@samchon/openapi";
-import { AutoBeContext } from "../../../context/AutoBeContext";
-import { IAutoBeTestScenarioArtifacts } from "../structures/IAutoBeTestScenarioArtifacts";
-export declare function transformTestWriteHistories<Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, scenario: AutoBeTestScenario, artifacts: IAutoBeTestScenarioArtifacts): Promise<Array<IAgenticaHistoryJson.ISystemMessage | IAgenticaHistoryJson.IAssistantMessage>>;
-export declare namespace transformTestWriteHistories {
-    function structures(artifacts: IAutoBeTestScenarioArtifacts): string;
-    function functional(artifacts: IAutoBeTestScenarioArtifacts): string;
-}