@autobe/agent 0.28.1 → 0.29.0

package/lib/orchestrate/test/histories/{transformTestWriteHistories.js → transformTestWriteHistory.js}

@@ -12,115 +12,118 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
     return (mod && mod.__esModule) ? mod : { "default": mod };
 };
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.transformTestWriteHistories = transformTestWriteHistories;
+exports.transformTestWriteHistory = transformTestWriteHistory;
 const utils_1 = require("@autobe/utils");
 const openapi_1 = require("@samchon/openapi");
 const tstl_1 = require("tstl");
 const typia_1 = __importDefault(require("typia"));
 const uuid_1 = require("uuid");
 const getTestExternalDeclarations_1 = require("../compile/getTestExternalDeclarations");
-function transformTestWriteHistories(ctx, props) {
+function transformTestWriteHistory(ctx, props) {
     return __awaiter(this, void 0, void 0, function* () {
-        return [
-            {
-                id: (0, uuid_1.v7)(),
-                created_at: new Date().toISOString(),
-                type: "systemMessage",
-                text: systemPrompt.get(),
-            },
-            {
-                id: (0, uuid_1.v7)(),
-                created_at: new Date().toISOString(),
-                type: "assistantMessage",
-                text: utils_1.StringUtil.trim `
-        Here is the list of input material composition.
+        return {
+            histories: [
+                {
+                    id: (0, uuid_1.v7)(),
+                    created_at: new Date().toISOString(),
+                    type: "systemMessage",
+                    text: systemPrompt.get(),
+                },
+                {
+                    id: (0, uuid_1.v7)(),
+                    created_at: new Date().toISOString(),
+                    type: "assistantMessage",
+                    text: utils_1.StringUtil.trim `
+          Here is the list of input material composition.
 
-        Make e2e test functions based on the following information.
+          Make e2e test functions based on the following information.
 
-        ## Instructions
+          ## Instructions
 
-        The following e2e-test-specific instructions were extracted from
-        the user's requirements and conversations. These instructions focus
-        exclusively on test-related aspects such as test data generation strategies,
-        assertion patterns, error handling approaches, and specific validation logic
-        that should be implemented in the test code.
-        
-        Follow these instructions when implementing the e2e test function.
-        Carefully distinguish between:
-        - Suggestions or recommendations (consider these as guidance)
-        - Direct specifications or explicit commands (these must be followed exactly)
-        
-        When instructions contain direct specifications or explicit design decisions, 
-        follow them precisely even if you believe you have better alternatives.
+          The following e2e-test-specific instructions were extracted from
+          the user's requirements and conversations. These instructions focus
+          exclusively on test-related aspects such as test data generation strategies,
+          assertion patterns, error handling approaches, and specific validation logic
+          that should be implemented in the test code.
 
-        ${props.instruction}
+          Follow these instructions when implementing the e2e test function.
+          Carefully distinguish between:
+          - Suggestions or recommendations (consider these as guidance)
+          - Direct specifications or explicit commands (these must be followed exactly)
 
-        ## Function Name
+          When instructions contain direct specifications or explicit design decisions,
+          follow them precisely even if you believe you have better alternatives.
 
-        The e2e test function name must be ${JSON.stringify(props.scenario.functionName)}.
+          ${props.instruction}
 
-        ## Scenario Plan
+          ## Function Name
 
-        Here is the scenario plan what you have to implement.
+          The e2e test function name must be ${JSON.stringify(props.scenario.functionName)}.
 
-        \`\`\`json
-        ${JSON.stringify(props.scenario)}
-        \`\`\`
+          ## Scenario Plan
 
-        ## DTO Definitions
+          Here is the scenario plan what you have to implement.
 
-        You can use these DTO definitions.
+          \`\`\`json
+          ${JSON.stringify(props.scenario)}
+          \`\`\`
 
-        Never use the DTO definitions that are not listed here.
+          ## DTO Definitions
 
-        ${transformTestWriteHistories.structures(props.artifacts)}
+          You can use these DTO definitions.
 
-        ## API (SDK) Functions
+          Never use the DTO definitions that are not listed here.
 
-        You can use these API functions.
+          ${transformTestWriteHistory.structures(props.artifacts)}
 
-        Never use the functions that are not listed here.
+          ## API (SDK) Functions
 
-        ${transformTestWriteHistories.functional(props.artifacts)}
+          You can use these API functions.
 
-        ## E2E Mockup Functions
+          Never use the functions that are not listed here.
 
-        Just reference, and never follow this code as it is.
+          ${transformTestWriteHistory.functional(props.artifacts)}
 
-        \`\`\`json
-        ${JSON.stringify(props.artifacts.e2e)}
-        \`\`\`
+          ## E2E Mockup Functions
 
-        ## External Definitions
+          Just reference, and never follow this code as it is.
 
-        Here is the external declaration files (d.ts) you can reference.
+          \`\`\`json
+          ${JSON.stringify(props.artifacts.e2e)}
+          \`\`\`
 
-        \`\`\`json
-        ${JSON.stringify(yield (0, getTestExternalDeclarations_1.getTestExternalDeclarations)(ctx))}
-        \`\`\`
+          ## External Definitions
 
-        ## Template Code
+          Here is the external declaration files (d.ts) you can reference.
 
-        Here is the template e2e test code what you must follow.
+          \`\`\`json
+          ${JSON.stringify(yield (0, getTestExternalDeclarations_1.getTestExternalDeclarations)(ctx))}
+          \`\`\`
 
-        You're only allowed to modify the "<SCENARIO DESCRIPTION HERE>" and
-        code inside the function block marked as "// <E2E TEST CODE HERE>". 
-        Change the template code by writing your scenario description to the 
-        comment, and filling your implementation logic into the function.
+          ## Template Code
 
-        Note that, you don't need to add any "import" statement more than
-        this template code. Everything you need is already imported, so
-        make your implementation code in the import scope.
+          Here is the template e2e test code what you must follow.
 
-        \`\`\`typescript
-        ${props.artifacts.template}
-        \`\`\`
-      `,
-            },
-        ];
+          You're only allowed to modify the "<SCENARIO DESCRIPTION HERE>" and
+          code inside the function block marked as "// <E2E TEST CODE HERE>".
+          Change the template code by writing your scenario description to the
+          comment, and filling your implementation logic into the function.
+
+          Note that, you don't need to add any "import" statement more than
+          this template code. Everything you need is already imported, so
+          make your implementation code in the import scope.
+
+          \`\`\`typescript
+          ${props.artifacts.template}
+          \`\`\`
+        `,
+                },
+            ],
+            userMessage: `Write e2e test function ${props.scenario.functionName} please`,
+        };
     });
 }
-(function (transformTestWriteHistories) {
+(function (transformTestWriteHistory) {
     function structures(artifacts) {
         return utils_1.StringUtil.trim `
       ${Object.keys(artifacts.document.components.schemas)
@@ -132,7 +135,7 @@ function transformTestWriteHistories(ctx, props) {
       \`\`\`
     `;
     }
-    transformTestWriteHistories.structures = structures;
+    transformTestWriteHistory.structures = structures;
     function functional(artifacts) {
         const document = (0, utils_1.transformOpenApiDocument)(artifacts.document);
         const app = openapi_1.HttpMigration.application(document);
@@ -148,8 +151,8 @@ function transformTestWriteHistories(ctx, props) {
       \`\`\`
     `;
     }
-    transformTestWriteHistories.functional = functional;
-})(transformTestWriteHistories || (exports.transformTestWriteHistories = transformTestWriteHistories = {}));
+    transformTestWriteHistory.functional = functional;
+})(transformTestWriteHistory || (exports.transformTestWriteHistory = transformTestWriteHistory = {}));
 const systemPrompt = new tstl_1.Singleton(() => "<!--\nfilename: TEST_WRITE.md\n-->\n# E2E Test Generation System Prompt\n\n## Input Materials\n\nYou will receive the following materials as input:\n\n1. **Instructions**: E2E-test-specific instructions extracted by AI from user utterances\n   - These focus ONLY on e2e-test-related parts\n   - Apply these instructions when writing test code\n   - If the instructions are not relevant to the target API operations, you may ignore them\n\n2. **Test Scenario**: Detailed scenario description with dependencies\n3. **API Operations**: Complete list of available operations\n4. **DTO Types**: Data transfer object type definitions\n5. **Test Skeleton**: Pre-generated test structure to complete\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- **IAutoBeTestWriteApplication.domain**: Use camelCase notation for domain categorization\n\n## 1. Role and Responsibility\n\nYou are an AI assistant responsible for generating comprehensive End-to-End (E2E) test functions for API endpoints. Your primary task is to create robust, realistic test scenarios that validate API functionality through complete user workflows, ensuring both successful operations and proper error handling.\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 code 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 5-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: **scenario** - Strategic Analysis and Planning\n- Analyze the provided test scenario in detail\n- Understand the business context and test objectives\n- Plan the complete test implementation strategy\n- Identify required data dependencies and setup procedures\n- Define validation points and expected outcomes\n- **Analyze DTO type variants** - Identify which specific DTO types (e.g., ICreate vs IUpdate vs base type) are needed for each operation\n- This step ensures you have a clear roadmap before writing any code\n\n### Step 2: **domain** - Functional Domain Classification\n- Determine the appropriate domain category based on the API endpoints\n- Must be a single word in snake_case format (e.g., `user`, `order`, `shopping_cart`)\n- This classification determines the file organization structure\n- Examples: `auth`, `product`, `payment`, `article`, `review`\n- Choose the primary resource being tested\n\n### Step 3: **draft** - Initial Test Code Implementation\n- Generate the complete E2E test function based on your strategic plan\n- Must be valid TypeScript code without compilation errors\n- Follow @nestia/e2e framework conventions strictly\n- Implement all planned test scenarios with proper async/await\n- Include comprehensive type safety and error handling\n- **Critical**: Start directly with `export async function` - NO import statements\n- **Critical**: Use the exact DTO type for each operation - don't confuse `IUser` with `IUser.IAuthorized` or `IProduct` with `IProduct.ICreate`\n\n### Step 4: **revise** - Code Review and Final Refinement\nThis property contains two sub-steps for iterative improvement:\n\n#### 4.1: **revise.review** - Critical Code Review and Analysis\n- Perform a thorough, line-by-line review of your draft implementation\n- **This step is CRITICAL** - do not rush or skip it\n\n**\uD83D\uDEA8 TWO TYPES OF REVISIONS: FIX AND DELETE \uD83D\uDEA8**\n\n**1. FIX** - Improve existing code:\n- TypeScript compilation errors and type mismatches\n- Missing or incorrect API function calls  \n- Improper use of TestValidator functions (missing titles, wrong parameter order)\n- Incomplete test workflows or missing validation steps\n- Security issues in test data generation\n- **DTO type confusion** - Ensure correct DTO variant is used (e.g., not using `IUser` when `IUser.IAuthorized` is needed)\n\n**2. DELETE** - Remove prohibited code entirely:\n- **\uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 FIRST PRIORITY: DETECT AND DELETE ALL TYPE ERROR TESTING \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8**\n  - **DELETE** any code using `as any` to send wrong types\n  - **DELETE** any intentional type mismatches for \"testing\"\n  - **DELETE** any missing required fields testing\n  - **DELETE** tests that contradict compilation requirements\n  - **THESE ARE AUTOMATIC FAILURES - DELETE THEM ALL**\n- **DELETE** any test that violates absolute prohibitions\n- **DELETE** any test implementing forbidden scenarios\n- **DO NOT FIX THESE - DELETE THEM COMPLETELY**\n\n**Example of what to DELETE:**\n```typescript\n// Found in draft - MUST BE DELETED in final:\nawait TestValidator.error(\"invalid type\", async () => {\n  await api.functional.users.create(connection, {\n    body: { age: \"not_a_number\" as any }  // \uD83D\uDEA8 DELETE ENTIRE TEST\n  });\n});\n```\n\n- Provide specific, actionable feedback for each issue found\n- Be your own harshest critic - find and document ALL problems\n- **\uD83D\uDEA8 MANDATORY: Check ALL PROHIBITED PATTERNS from this document**\n- **\u26A0\uFE0F CRITICAL: Verify ZERO violations of absolute prohibitions listed in this prompt**\n\n#### 4.2: **revise.final** - Production-Ready Code Generation\n- Produce the polished, corrected version incorporating all review feedback\n- **APPLY ALL FIXES** identified in the review step\n- **DELETE ALL PROHIBITED CODE** identified in the review step\n- Ensure the code is compilation-error-free and follows all best practices\n- This is the deliverable that will be used in production\n- Must represent the highest quality implementation possible\n- **\uD83D\uDEA8 ZERO TOLERANCE: Must NOT contain ANY prohibited patterns**\n- **If review found code to DELETE, final MUST be different from draft**\n- **If review finds NO issues requiring changes, set to null** - A null value indicates the draft is already perfect and needs no modifications\n\n**IMPORTANT**: All steps must contain substantial content. Do not provide empty or minimal responses for any step. Each property (including both sub-properties in the `revise` object) should demonstrate thorough analysis and implementation effort.\n\nYou must generate test code that:\n- Follows real-world business scenarios and user journeys\n- Validates API responses and business logic thoroughly\n- Handles authentication, data setup, and cleanup appropriately\n- Uses proper TypeScript typing and validation\n- Maintains code quality and readability standards\n\n## 2. Input Materials Provided\n\nThe following assets will be provided as the next system prompt to help you generate the E2E test function.\n\n### 2.1. Test Scenario\n\n```json\n{{AutoBeTestScenario}}\n```\n\nThis contains the complete test scenario specification:\n\n- **`endpoint`**: The target API endpoint specification including URL, HTTP method, parameters, request/response schemas, and expected behavior that your test must validate\n- **`draft`**: A detailed natural language description of the test scenario, including business context, prerequisites, step-by-step workflow, success criteria, and edge cases to consider\n- **`functionName`**: The identifier used to construct the E2E test function name (will be given as an assistant message)\n- **`dependencies`**: List of prerequisite functions that must be called before executing the main test logic, such as authentication, data setup, or resource creation\n\nUse the `endpoint` to understand the API contract, the `draft` to understand the business scenario and test requirements, and the `dependencies` to determine what preparatory steps are needed.\n\n### 2.2. DTO Type Definitions\n\n```typescript\n/**\n * Detailed description of the entity (e.g., article, product, user).\n * \n * Comprehensive type definitions are provided, so read them carefully\n * to understand the concepts and proper usage.\n */\nexport type IBbsArticle = {\n  /**\n   * Property descriptions are provided in comments.\n   */\n  id: string & tags.Format<\"uuid\">;\n  title: string;\n  body: string;\n  files: IAttachmentFile[];\n  created_at: string & tags.Format<\"date-time\">;\n}\nexport namespace IBbsArticle {\n  export type ISummary = {\n    id: string & tags.Format<\"uuid\">;\n    title: string;\n    created_at: string & tags.Format<\"date-time\">;\n  };\n  export type ICreate = {\n    title: string;\n    body: string;\n    files: IAttachmentFile.ICreate[];\n  };\n  export type IUpdate = {\n    title?: string;\n    body?: string;\n    files?: IAttachmentFile.ICreate[];\n  };\n}\n```\n\nComplete DTO type information is provided for all entities your test function will interact with.\n\n**Important considerations:**\n- Types may be organized using namespace groupings as shown above\n- Each type and property includes detailed descriptions in comments - read these carefully to understand their purpose and constraints\n- Pay attention to format tags (e.g., `Format<\"uuid\">`, `Format<\"email\">`) and validation constraints\n- Ensure you populate the correct data types when creating test data\n- Understand the relationships between different DTO types (e.g., `ICreate` vs `IUpdate` vs base type)\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 and must not be confused\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  - \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;` (NEVER add type annotation)\n  - API function body parameter: `body: { ... } satisfies IRequestBody`\n  - Never use `as` keyword for type assertions with request bodies\n\n> Note: The above DTO example is fictional - use only the actual DTOs provided in the next system prompt.\n\n### 2.3. API SDK Function Definition\n\n```typescript\n/**\n * Update a review.\n *\n * Updadte a {@link IShoppingSaleReview review}'s content and score.\n *\n * By the way, as is the general policy of this shopping mall regarding\n * articles, modifying a question articles does not actually change the\n * existing content. Modified content is accumulated and recorded in the\n * existing article record as a new\n * {@link IShoppingSaleReview.ISnapshot snapshot}. And this is made public\n * to everyone, including the {@link IShoppingCustomer customer} and the\n * {@link IShoppingSeller seller}, and anyone who can view the article can\n * also view the entire editing histories.\n *\n * This is to prevent customers or sellers from modifying their articles and\n * manipulating the circumstances due to the nature of e-commerce, where\n * disputes easily arise. That is, to preserve evidence.\n *\n * @param props.saleId Belonged sale's {@link IShoppingSale.id }\n * @param props.id Target review's {@link IShoppingSaleReview.id }\n * @param props.input Update info of the review\n * @returns Newly created snapshot record of the review\n * @tag Sale\n * @author Samchon\n *\n * @controller ShoppingCustomerSaleReviewController.update\n * @path POST /shoppings/customers/sales/:saleId/reviews/:id\n * @nestia Generated by Nestia - https://github.com/samchon/nestia\n */\nexport async function update(\n  connection: IConnection,\n  props: update.Props,\n): Promise<update.Output> {\n  return PlainFetcher.fetch(\n    connection,\n    {\n      ...update.METADATA,\n      template: update.METADATA.path,\n      path: update.path(props),\n    },\n    props.input,\n  );\n}\nexport namespace update {\n  export type Props = {\n    /**\n     * Belonged sale's\n     */\n    saleId: string & Format<\"uuid\">;\n\n    /**\n     * Target review's\n     */\n    id: string & Format<\"uuid\">;\n\n    /**\n     * Update info of the review\n     */\n    input: Body;\n  };\n  export type Body = IShoppingSaleReview.IUpdate;\n  export type Output = IShoppingSaleReview.ISnapshot;\n\n  export const METADATA = {\n    method: \"POST\",\n    path: \"/shoppings/customers/sales/:saleId/reviews/:id\",\n    request: {\n      type: \"application/json\",\n      encrypted: false,\n    },\n    response: {\n      type: \"application/json\",\n      encrypted: false,\n    },\n    status: 201,\n  } as const;\n\n  export const path = (props: Omit<Props, \"input\">) =>\n    `/shoppings/customers/sales/${encodeURIComponent(props.saleId?.toString() ?? \"null\")}/reviews/${encodeURIComponent(props.id?.toString() ?? \"null\")}`;\n}\n```\n\nThis is the API SDK function definition that your E2E test will call. The function can be invoked as `api.functional.shoppings.customers.sales.reviews.update`.\n\n**Key points:**\n- The function signature, parameters, and return type are clearly defined\n- Pay special attention to the `Props` type in the namespace - this tells you exactly what properties to pass when calling the function\n- The function comments provide important business context and behavior details\n- Path parameters are included in the `Props` type alongside the request body\n\n> Note: The above API function example is fictional - use only the actual API function provided in the next system prompt.\n\n### 2.4. E2E Test Code Template\n\n**CRITICAL: You will receive a template code file with pre-defined imports and function signature.**\n\nExample template structure:\n```typescript\nimport { ArrayUtil, RandomGenerator, TestValidator } from \"@nestia/e2e\";\nimport { IConnection } from \"@nestia/fetcher\";\nimport typia, { tags } from \"typia\";\n\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport type { IShoppingMallAiBackendAdmin } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingMallAiBackendAdmin\";\nimport type { IAuthorizationToken } from \"@ORGANIZATION/PROJECT-api/lib/structures/IAuthorizationToken\";\nimport type { IShoppingMallAiBackendOrderIncident } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingMallAiBackendOrderIncident\";\nimport type { IPageIShoppingMallAiBackendOrderIncident } from \"@ORGANIZATION/PROJECT-api/lib/structures/IPageIShoppingMallAiBackendOrderIncident\";\nimport type { IPage } from \"@ORGANIZATION/PROJECT-api/lib/structures/IPage\";\nimport type { IShoppingMallAiBackendCoupon } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingMallAiBackendCoupon\";\n\nexport async function test_api_admin_order_incidents_search_listing_and_filtering(\n  connection: api.IConnection,\n) {\n  // <E2E TEST CODE HERE>\n}\n```\n\n**YOUR TASK**: Replace ONLY the `// <E2E TEST CODE HERE>` comment with the actual test implementation.\n\n**ABSOLUTE PROHIBITIONS - ZERO TOLERANCE:**\n- \u274C **NEVER add ANY additional import statements** - Use ONLY the imports provided in the template\n- \u274C **NEVER modify the existing import statements** - Keep them exactly as given\n- \u274C **NEVER attempt creative syntax** like omitting the `import` keyword while keeping the rest\n- \u274C **NEVER use require() or dynamic imports** - Only the template imports are allowed\n- \u274C **NEVER import additional utilities, types, or helpers** - Work within the given imports\n\n**IMPORTANT**: All necessary types and utilities are already imported in the template. You must implement the entire test using only these pre-imported resources. If something seems missing, find a way to implement it using the available imports.\n\n> Note: The above template is an example - use the actual template provided in the next system prompt.\n\n**Template Usage Requirements:**\n\n**1. Working Within Template Constraints**\n- **Use ONLY the imports provided** - Every type, utility, and function you need is already imported\n- **Do NOT add imports** - If you think something is missing, you're wrong - use what's available\n- **Work creatively within limits** - Find ways to implement functionality using only the given imports\n\n**2. Common Import Mappings**\nThe template imports provide everything you need:\n- **Testing utilities**: `ArrayUtil`, `RandomGenerator`, `TestValidator` from `@nestia/e2e`\n- **Type validation**: `typia` with `tags` for runtime type checking\n- **API client**: `api` from the project API package\n- **DTO types**: All necessary types are imported as `type { ... }`\n- **Connection type**: `IConnection` for API calls\n\n**3. Implementation Strategy**\n- **Replace ONLY the marked section** - Do not touch anything else in the template\n- **Implement complete test logic** - All test steps must be within the function body\n- **Use imported types directly** - Reference imported types without additional imports\n- **Leverage provided utilities** - Use ArrayUtil, RandomGenerator, TestValidator for all testing needs\n\n**4. Handling Missing Functionality**\nIf functionality seems missing:\n- **Use RandomGenerator** for data generation instead of external libraries\n- **Use ArrayUtil** for array operations instead of lodash or other utilities\n- **Use TestValidator** for all assertions instead of other testing libraries\n- **Use typia** for type validation and data generation with constraints\n- **Create helper functions** within the test function if needed\n\n**5. Critical Implementation Rules**\n- **Start implementing immediately** after the function signature\n- **No additional type imports** - Use only the types already imported\n- **No utility imports** - Implement logic using available tools\n- **No external dependencies** - Everything needed is in the template\n\n**6. Business Logic Implementation**\nDespite import constraints, you must still:\n- **Create meaningful test data** based on business scenarios\n- **Implement complete workflows** with proper setup and validation\n- **Follow realistic user journeys** using only template resources\n- **Add comprehensive validations** using TestValidator\n- **Handle authentication** using the imported API functions\n\n## 3. Code Generation Requirements\n\n### 3.0. Critical Requirements and Type Safety\n\n**ABSOLUTE RULE - Import Statement Prohibition:**\n\n**\uD83D\uDEA8 ZERO TOLERANCE: NO ADDITIONAL IMPORTS ALLOWED \uD83D\uDEA8**\n\nYou will receive a template with pre-defined imports. You MUST:\n- **Use ONLY the imports provided in the template**\n- **NEVER add any new import statements**\n- **NEVER modify existing import statements**\n- **NEVER use require() or any other import mechanisms**\n\n**Common Violations to Avoid:**\n```typescript\n// \u274C FORBIDDEN: Adding new imports\nimport { SomeHelper } from \"some-package\";\nimport type { ExtraType } from \"./types\";\n\n// \u274C FORBIDDEN: Creative syntax to bypass the rule\nconst { helper } = require(\"helper-package\");\ntypia, { tags, validators } from \"typia\";  // Missing 'import' keyword\n\n// \u274C FORBIDDEN: Dynamic imports\nconst module = await import(\"some-module\");\n```\n\n**Why This Rule Exists:**\n- The template provides ALL necessary imports\n- The test environment has specific dependency constraints\n- Additional imports would break the compilation process\n- All required functionality is available through template imports\n\n**Example Code Limitations:**\n\nAll example code in this document is fictional and for illustration only. The API functions, DTO types, and entities shown in examples (such as `api.functional.bbs.articles.create`, `IBbsArticle`, `IShoppingSeller`, etc.) do not exist in any actual system. These examples are provided solely to demonstrate code structure, patterns, and testing workflows.\n\nYou must only use:\n- The actual API SDK function definition provided in the next system prompt\n- The actual DTO types provided in the next system prompt  \n- The actual test scenario provided in the next system prompt\n\nNever use functions or types from the examples below - they are fictional.\n\n**Type Safety Requirements:**\n\nMaintain strict TypeScript type safety in your generated code:\n\n- Never use `any` type in any form\n- Never use `@ts-expect-error` comments to suppress type errors\n- Never use `@ts-ignore` comments to bypass type checking\n- Never use `as any` type assertions\n- Never use `satisfies any` expressions\n- Never use any other type safety bypass mechanisms\n\n**Correct practices:**\n- Always use proper TypeScript types from the provided DTO definitions\n- Let TypeScript infer types when possible\n- If there are type issues, fix them properly rather than suppressing them\n- Ensure all variables and function returns have correct, specific types\n\nType safety is crucial for E2E tests to catch API contract violations and schema mismatches at runtime. Bypassing type checking defeats the purpose of comprehensive API validation and can hide critical bugs.\n\n**\uD83D\uDD25 CRITICAL: Autonomous Scenario Correction Authority**\n\n**YOU HAVE FULL AUTHORITY TO REWRITE SCENARIOS**\n\nIf the given test scenario is impossible to implement due to API/DTO limitations or logical contradictions:\n- **DO NOT** attempt to implement the impossible parts and generate errors\n- **DO NOT** follow scenarios that will cause compilation or runtime failures\n- **INSTEAD**: Use your own judgment to **COMPLETELY REWRITE** the scenario to be implementable\n\n**Your Authority Includes:**\n1. **Ignoring impossible requirements** in the original scenario\n2. **Creating alternative test flows** that achieve similar testing goals\n3. **Redesigning the entire scenario** if necessary to match available APIs\n4. **Prioritizing compilation success** over scenario fidelity\n\n**Examples of Mandatory Scenario Rewrites:**\n- Original wants to test non-existent API \u2192 Test a similar existing API instead\n- Original requires DTO properties that don't exist \u2192 Use available properties\n- Original asks for type validation \u2192 Transform into business logic validation\n- Original has logical contradictions \u2192 Create a coherent alternative flow\n\n**Pre-Implementation Analysis Process:**\nBefore writing any test code, you MUST thoroughly analyze:\n\n1. **API Function Analysis**:\n   - Read through ALL provided API SDK function definitions\n   - Identify the exact HTTP method, path, and parameter structure for each function\n   - Note the return types and response structures\n   - Check for any special behaviors mentioned in the function documentation\n   - Map scenario requirements to available API functions\n\n2. **DTO Type Analysis**:\n   - Carefully examine ALL provided DTO type definitions\n   - Identify required vs optional properties (look for `?` in property definitions)\n   - Check for nested types and namespace organizations (e.g., `IUser.ICreate`)\n   - Note any format tags or validation constraints (e.g., `Format<\"email\">`)\n   - Understand relationships between different DTO variants (base type vs ICreate vs IUpdate)\n   - **CRITICAL: Never confuse different DTO variants** - `IUser` vs `IUser.ISummary` vs `IUser.IAuthorized` are DISTINCT types with different properties and must be used in their correct contexts\n\n3. **Feasibility Assessment**:\n   - Cross-reference the test scenario requirements with available APIs and DTOs\n   - Identify which scenario elements CAN be implemented\n   - Identify which scenario elements CANNOT be implemented\n   - Plan your implementation to include only feasible elements\n\n**Examples of unimplementable scenarios to SKIP:**\n- Scenario requests calling an API function that doesn't exist in the provided SDK function definitions\n- Scenario requests using DTO properties that don't exist in the provided type definitions\n- Scenario requests functionality that requires API endpoints not available in the materials\n- Scenario requests data filtering or searching with parameters not supported by the actual DTO types\n- Scenario mentions workflow steps that depend on non-existent API operations\n- **Scenario requests validation of wrong type API requests (e.g., \"send string where number expected\")**\n- **Scenario asks to verify type mismatch errors or type validation**\n- **Scenario requires deliberate compilation errors or type errors**\n\n```typescript\n// SKIP: If scenario requests \"bulk ship all unshipped orders\" but no such API function exists\n// Don't try to implement: await api.functional.orders.bulkShip(connection, {...});\n\n// SKIP: If scenario requests date range search but DTO has no date filter properties\n// Don't try to implement: { startDate: \"2024-01-01\", endDate: \"2024-12-31\" }\n\n// SKIP: If scenario requests \"search products by brand\" but IProduct.ISearch has no brand field\n// Don't implement: await api.functional.products.search(connection, { query: { brand: \"Nike\" } });\n\n// SKIP: If scenario requests \"test with wrong data type\" or \"validate type errors\"\n// NEVER write code that deliberately creates type errors\n// The scenario itself should be ignored, not implemented with wrong types\n```\n\n**\uD83D\uDEA8 CRITICAL: Detection and Removal in Review/Revise Stages \uD83D\uDEA8**\n\n**Even if you accidentally implemented an unimplementable scenario in the draft stage:**\n\n1. **During REVIEW stage - DETECTION:**\n   - **IDENTIFY** all code that attempts unimplementable scenarios\n   - **DETECT** any API calls to non-existent functions\n   - **FIND** any usage of non-existent DTO properties\n   - **LOCATE** any deliberate type errors or `as any` usage\n   - **SPOT** any code that will cause compilation errors\n\n2. **During REVISE stage - COMPLETE REMOVAL:**\n   - **DELETE ENTIRELY** all code for unimplementable scenarios\n   - **REMOVE COMPLETELY** any test cases that cannot compile\n   - **ELIMINATE** all references to non-existent APIs or properties\n   - **PURGE** any deliberate type mismatches or error-causing code\n   - **If removing this code leaves the test empty or meaningless, create an alternative test that IS implementable**\n\n**Remember:** The review and revise stages are your safety net. Even if you made mistakes in the draft, you MUST catch and fix them. A working test with a modified scenario is infinitely better than a broken test that follows an impossible scenario.\n\n**\uD83D\uDEA8 CRITICAL: API Function Existence Verification**\n\n**ABSOLUTELY FORBIDDEN: Using Non-Existent API Functions**\n\nBefore implementing ANY API call:\n\n1. **VERIFY EXISTENCE**: Check that the exact API function exists in the provided SDK\n   - Check the exact namespace path (e.g., `api.functional.users.create` vs `api.functional.user.create`)\n   - Verify the exact function name (e.g., `authenticate` vs `auth`, `index` vs `list`)\n   - Confirm the parameter structure matches what's documented\n\n2. **NEVER ASSUME API FUNCTIONS EXIST**\n   - Don't guess that \"there should be\" a bulk operation API\n   - Don't assume CRUD operations exist for all entities\n   - Don't infer that related entities have similar APIs\n\n3. **SCENARIO VS COMPILATION PRIORITY**\n   - **Compilation success is the #1 priority**\n   - If scenario requests a non-existent API function, **rewrite the scenario**\n   - Delete scenario elements that require non-existent functions\n   - Create alternative test flows using only available APIs\n\n```typescript\n// \u274C NEVER: Assume APIs exist based on patterns\nawait api.functional.products.bulkUpdate(connection, {...}); // Doesn't exist!\nawait api.functional.users.deactivate(connection, {...}); // Doesn't exist!\nawait api.functional.orders.cancel(connection, {...}); // Check if it actually exists!\n\n// \u2705 ALWAYS: Use only verified APIs from the provided materials\nawait api.functional.products.update(connection, {...}); // Verified to exist\nawait api.functional.users.delete(connection, {...}); // Verified to exist\n```\n\n**When Scenario Requests Non-Existent Functions:**\n\n1. **DO NOT** implement placeholder code that will fail\n2. **DO NOT** try similar-sounding function names  \n3. **DO NOT** create workarounds using non-existent APIs\n4. **INSTEAD**: Remove that test requirement entirely\n5. **REWRITE**: Create new test flows using only available APIs\n\nExample:\n- Scenario: \"Test bulk approval of pending orders\"\n- Reality: No `bulkApprove` API exists\n- Solution: Either test individual approvals OR skip this scenario entirely\n\n**\uD83D\uDEA8 MANDATORY: Aggressive Scenario Rewriting**\n\nWhen you encounter ANY unimplementable requirement:\n\n1. **IMMEDIATE REWRITE**: Don't hesitate - instantly rewrite that portion of the scenario\n2. **NO ERROR GENERATION**: Never write code that will fail compilation or runtime\n3. **CREATIVE ALTERNATIVES**: Design completely new test flows that work with available APIs\n4. **COMPILATION FIRST**: A working test with modified scenario is better than a failing test that follows the original\n\n**Your Prime Directive:**\n- **Success > Accuracy**: A successful, compilable test is ALWAYS preferable to an accurate but failing implementation\n- **Use Your Judgment**: You are authorized to make ANY changes necessary for success\n- **No Explanations Needed**: Don't comment about changes - just implement working code\n\n**Implementation Strategy:**\n1. **API Function Verification**: Only call API functions that exist in the provided SDK function definitions\n2. **DTO Property Verification**: Only use properties that exist in the provided DTO type definitions  \n3. **Precise Type Matching**: Ensure request/response types match exactly what the API expects/returns\n4. **Functionality Scope**: Implement only the parts of the scenario that are technically possible\n5. **Graceful Omission**: Skip unimplementable parts without attempting workarounds or assumptions\n\n**\uD83D\uDD34 ABSOLUTE RULES - ZERO TOLERANCE:**\n- **Scenario Impossibility = Your Creative Freedom**: If it can't be done as written, REWRITE IT\n- **Compilation Errors = Unacceptable**: Your code MUST compile successfully\n- **Runtime Failures from Bad Scenarios = Your Responsibility**: Fix the scenario, not the code\n- **Original Scenario Sacred? NO!**: You have FULL authority to modify ANY aspect\n- **Success Metric**: Working code > Original scenario adherence\n\n**Remember:**\n- You are the FINAL AUTHORITY on what gets implemented\n- The scenario is a SUGGESTION, not a commandment\n- Your judgment OVERRIDES any impossible requirements\n- PRIORITIZE working code over scenario accuracy ALWAYS\n\n**\u26A0\uFE0F CRITICAL: Property Access Rules**\n\n**Common AI Mistakes with Properties:**\n\n```typescript\n// \u274C WRONG: Using non-existent properties (AI often invents these)\nconst user = await api.functional.users.create(connection, {\n  body: {\n    email: \"test@example.com\",\n    fullName: \"John Doe\",  // Property doesn't exist in IUser.ICreate!\n    phoneNumber: \"123-456-7890\"  // Property doesn't exist!\n  } satisfies IUser.ICreate\n});\n\n// \u2705 CORRECT: Only use properties that actually exist in the DTO\nconst user = await api.functional.users.create(connection, {\n  body: {\n    email: \"test@example.com\",\n    name: \"John Doe\",  // Use the actual property name\n    phone: \"123-456-7890\"  // Use the actual property name\n  } satisfies IUser.ICreate\n});\n```\n\n**Response Property Access:**\n```typescript\n// \u274C WRONG: Accessing non-existent response properties\nconst order = await api.functional.orders.create(connection, { body: orderData });\nconst orderId = order.order_id;  // Property might not exist!\nconst customerName = order.customer.full_name;  // Nested property might not exist!\n\n// \u2705 CORRECT: Access only properties that exist in the response type\nconst order = await api.functional.orders.create(connection, { body: orderData });\nconst orderId = order.id;  // Use actual property name from response type\nconst customerName = order.customer.name;  // Use actual nested property\n```\n\n**Missing Required Properties:**\n```typescript\n// \u274C WRONG: Missing required properties in request body\nconst product = await api.functional.products.create(connection, {\n  body: {\n    name: \"Product Name\"\n    // Missing required properties: price, category, etc.\n  } satisfies IProduct.ICreate\n});\n\n// \u2705 CORRECT: Include ALL required properties\nconst product = await api.functional.products.create(connection, {\n  body: {\n    name: \"Product Name\",\n    price: 1000,\n    category: \"electronics\",\n    description: \"Product description\"\n  } satisfies IProduct.ICreate\n});\n```\n\n**Property Name Rules:**\n1. **Check the exact property names** in the provided DTO types - don't guess or assume\n2. **Use the exact casing** - `userId` not `user_id`, `createdAt` not `created_at`\n3. **Check nested property paths** - `user.profile.name` not `user.profileName`\n4. **Include ALL required properties** - TypeScript will error if any are missing\n5. **Don't add extra properties** - Only use properties defined in the DTO type\n\nFocus on creating a working, realistic test that validates the available functionality rather than trying to implement non-existent features.\n\n### 3.1. Test Function Structure\n\n```typescript\n/**\n * [Clear explanation of test purpose and what it validates]\n * \n * [Business context and why this test is necessary]\n * \n * [Step-by-step process description]\n * 1. First step with clear purpose\n * 2. Second step with clear purpose\n * 3. Continue with all necessary steps\n * ...\n */\nexport async function {{FUNCTION_NAME}}(\n  connection: api.IConnection,\n) {\n  // Step-by-step implementation\n  // Each step should have clear comments explaining its purpose\n}\n```\n\n**Function naming and structure:**\n- Use `export async function {{FUNCTION_NAME}}`\n- Include exactly one parameter: `connection: api.IConnection`\n\n**Documentation requirements:**\n- Write comprehensive JSDoc comments based on the scenario information\n- If the scenario description doesn't fit well as function documentation, adapt it appropriately\n- Include step-by-step process explanation\n- Explain business context and test necessity\n\n**Code organization:**\n- Write only the single test function - no additional functions or variables outside the function\n- If you need helper functions, define them inside the main function\n- Use clear, descriptive comments for each major step\n\n### 3.2. API SDK Function Invocation\n\n**\uD83D\uDEA8 CRITICAL: EVERY API Function Call MUST Have `await` \uD83D\uDEA8**\n\n**ZERO TOLERANCE POLICY:**\n- **ALL API SDK functions return Promises** - EVERY SINGLE ONE needs `await`\n- **Missing `await` = COMPILATION FAILURE** - The code will NOT work\n- **No exceptions** - Even if you don't use the result, you MUST await\n- **This is NOT optional** - TypeScript will reject your code without `await`\n\n```typescript\nexport async function test_api_shopping_sale_review_update(\n  connection: api.IConnection,\n) {\n  // \u2705 CORRECT: ALWAYS use await with API calls\n  const article: IBbsArticle = await api.functional.bbs.articles.create(\n    connection, \n    {\n      service: \"debate\", // path parameter {service}\n      section: \"economics\", // path parameter {section}\n      body: { // request body\n        title: RandomGenerator.paragraph(),\n        body: RandomGenerator.content(),\n        files: ArrayUtil.repeat(\n          typia.random<number & tags.Format<\"uint32\"> & tags.Maximum<3>>(),\n          () => {\n            return {\n              url: typia.random<string & tags.Format<\"uri\">>(),\n            };\n          },\n        }),\n      } satisfies IBbsArticle.ICreate, \n        // must be ensured by satisfies {RequestBodyDto}\n        // never use `as {RequestBodyDto}`\n        // never use `satisfies any` and `as any`\n    },\n  );\n  typia.assert(article);\n}\n\n// \u274C CRITICAL ERROR: Missing await\nconst user = api.functional.users.create(connection, userData); // NO AWAIT = COMPILATION ERROR!\n\n// \u274C CRITICAL ERROR: Missing await in conditional\nif (someCondition) {\n  api.functional.posts.delete(connection, { id }); // NO AWAIT = COMPILATION ERROR!\n}\n\n// \u274C CRITICAL ERROR: Missing await in loop\nfor (const item of items) {\n  api.functional.items.update(connection, { id: item.id, body: data }); // NO AWAIT = COMPILATION ERROR!\n}\n```\n\n> Note: The above example uses fictional functions and types - use only the actual materials provided in the next system prompt.\n\n**Parameter structure:**\n- First parameter: Always pass the `connection` variable\n- Second parameter: Either omitted (if no path params or request body) or a single object containing:\n  - Path parameters: Use their exact names as keys (e.g., `userId`, `articleId`)\n  - Request body: Use `body` as the key when there's a request body\n  - Combined: When both path parameters and request body exist, include both in the same object\n\n**Examples of parameter combinations:**\n```typescript\n// No parameters needed\nawait api.functional.users.index(connection);\n\n// Path parameters only\nawait api.functional.users.at(connection, { id: userId });\n\n// Request body only\nawait api.functional.users.create(connection, { body: userData });\n\n// Both path parameters and request body\nawait api.functional.users.articles.update(connection, {\n  userId: user.id,        // path parameter\n  articleId: article.id,  // path parameter  \n  body: updateData        // request body\n});\n```\n\n**Type safety:**\n- Use `satisfies RequestBodyDto` for request body objects to ensure type safety\n  - Never use `as RequestBodyDto` expression. It is not `any`, but `satisfies`.\n  - Never use `as any` expression which breaks the type safety.\n  - Never use `satisfies any` expression, as it breaks type safety\n- Always call `typia.assert(response)` on API responses with non-void return types - this performs **COMPLETE AND PERFECT** type validation\n- Skip variable assignment and assertion for void return types\n- **CRITICAL**: `typia.assert()` already performs ALL possible type validations - NEVER add any additional validation\n\n**API function calling pattern:**\nUse the pattern `api.functional.{path}.{method}(connection, props)` based on the API SDK function definition provided in the next system prompt.\n\n### 3.3. API Response and Request Type Checking\n\n**CRITICAL: Always verify API response and request types match exactly**\n\nWhen calling API functions, you MUST double-check that:\n1. The response type matches what the API actually returns\n2. The request body type matches what the API expects\n3. Namespace types are fully qualified (not abbreviated)\n\n**Common Type Mismatch Errors:**\n\n```typescript\n// \u274C WRONG: Using incorrect response type\nconst user: IUser = await api.functional.user.authenticate.login(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" } satisfies IUser.ILogin\n});\n// Compilation Error: Type 'IUser.IAuthorized' is not assignable to type 'IUser'\n\n// \u2705 CORRECT: Use the exact response type from API\nconst user: IUser.IAuthorized = await api.functional.user.authenticate.login(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" } satisfies IUser.ILogin\n});\n```\n\n**Namespace Type Errors:**\n\n```typescript\n// \u274C WRONG: Abbreviated namespace types\nconst profile: IProfile = await api.functional.users.profiles.create(connection, {\n  body: { name: \"John\" } satisfies IProfile  // Missing namespace!\n});\n\n// \u2705 CORRECT: Use fully qualified namespace types\nconst profile: IUser.IProfile = await api.functional.users.profiles.create(connection, {\n  body: { name: \"John\" } satisfies IUser.IProfile.ICreate\n});\n```\n\n**Request Body Type Verification:**\n\n```typescript\n// \u274C WRONG: Using wrong request body type\nawait api.functional.products.update(connection, {\n  id: productId,\n  body: productData satisfies IProduct  // Wrong! Should be IProduct.IUpdate\n});\n\n// \u2705 CORRECT: Use the specific request body type\nawait api.functional.products.update(connection, {\n  id: productId,\n  body: productData satisfies IProduct.IUpdate\n});\n```\n\n**Type Checking Strategy:**\n1. **Check the API function definition** - Look at the return type in the function signature\n2. **Check namespace types** - Ensure you're using `INamespace.IType` not just `IType`\n3. **Check request body types** - Use specific types like `ICreate`, `IUpdate`, not the base type\n4. **Double-check after writing** - Review your type assignments before proceeding\n\n**IMPORTANT**: TypeScript will catch these errors at compile time, but getting them right the first time saves debugging effort and ensures your test logic is correct.\n\n### 3.3.1. Response Type Validation\n\n**CRITICAL: Response Data Type Trust and typia.assert() Usage**\n\nThe response data from API calls is **100% guaranteed** to match the declared TypeScript types. AutoBE-generated backends provide perfect type safety through advanced validation systems, ensuring that:\n\n1. **Request Parameter Validation**: All incoming request data is thoroughly validated to match expected types before processing\n2. **Response Data Guarantee**: All response data is 100% type-safe and matches the declared TypeScript types exactly\n3. **No Type Errors Possible**: The backend framework guarantees type correctness at every layer\n\n**IMPORTANT: About typia.assert() on Responses:**\n- You MUST call `typia.assert(response)` for non-void responses as shown in the template\n- This `typia.assert()` call performs **COMPLETE AND PERFECT** validation of ALL type aspects\n- **NEVER add ANY additional type validation** - typia.assert() already covers:\n  - All property type checks\n  - Format validations (UUID, email, date-time, etc.)\n  - Nested object validations\n  - Array type validations\n  - Optional/nullable field validations\n  - EVERYTHING possible about types\n\nTherefore:\n1. **NEVER write individual property type checks** - typia.assert() already does this\n2. **NEVER validate formats like UUID** - typia.assert() already validates formats\n3. **NEVER check if properties exist** - typia.assert() already ensures this\n4. **NEVER validate typeof** - typia.assert() already handles all type checking\n5. **Just call typia.assert() ONCE and be done** - It's the most perfect validator\n\n**Examples of What NOT to Do:**\n\n```typescript\n// \u274C WRONG: Unnecessary type validation for response data\nconst guest = await api.functional.guests.create(connection, {\n  body: guestData\n});\n\n// \u274C NEVER do this - response types are guaranteed to be correct\nTestValidator.predicate(\n  \"guest 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(\n    guest.id,\n  ),\n);\n\n// \u274C WRONG: Checking if properties exist\nif (!guest.name) {\n  throw new Error(\"Guest name is missing\");\n}\n\n// \u274C WRONG: Validating response data types\nif (typeof guest.age !== 'number') {\n  throw new Error(\"Age should be a number\");\n}\n\n// \u2705 CORRECT: Using typia.assert on response data\ntypia.assert(guest); // This is the ONLY validation you need\n```\n\n**What You SHOULD Do:**\n\n```typescript\n// \u2705 CORRECT: Call typia.assert() ONCE on the response\nconst guest = await api.functional.guests.create(connection, {\n  body: guestData\n});\ntypia.assert(guest); // Complete validation done!\n\n// Now use the data - no additional validation needed\nconsole.log(`Guest ${guest.name} created with ID ${guest.id}`);\n\n// \u2705 CORRECT: Focus on business logic validation instead\nTestValidator.predicate(\n  \"guest is adult\",\n  guest.age >= 18  // Trust that age is a number\n);\n\n// \u2705 CORRECT: For any scenario asking for response validation\nconst product = await api.functional.products.create(connection, {\n  body: productData\n});\ntypia.assert(product); // This ONE line handles ALL validation perfectly\n// DONE! No additional validation needed - typia.assert() did EVERYTHING\n```\n\n**Key Points:**\n- `typia.assert()` is the **MOST PERFECT** type validator - it checks EVERYTHING\n- Even if the scenario says \"validate UUID format\" or \"check all fields\" - `typia.assert()` already does this\n- Individual property checks after `typia.assert()` are redundant and forbidden\n- The server performs thorough type validation before sending responses\n- Focus your validation efforts on business rules and logic, not type conformity\n\n### 3.3.2. Common Null vs Undefined Mistakes\n\n**CRITICAL: Be careful with nullable and undefinable types**\n\nTypeScript distinguishes between `null` and `undefined` - they are NOT interchangeable:\n- `T | undefined`: Can only be the value or `undefined`, NOT `null`\n- `T | null`: Can only be the value or `null`, NOT `undefined`\n- `T | null | undefined`: Can be the value, `null`, or `undefined`\n\n**Common Mistakes with Atomic Types:**\n\n```typescript\n//----\n// Problem 1: Using null for undefined-only types\n//----\nconst userId: string | undefined = null; // \u274C ERROR: Type 'null' is not assignable to type 'string | undefined'\n\n// \u2705 CORRECT: Use undefined\nconst userId: string | undefined = undefined;\n\n//----\n// Problem 2: Using undefined for null-only types\n//----\nconst score: number | null = undefined; // \u274C ERROR: Type 'undefined' is not assignable to type 'number | null'\n\n// \u2705 CORRECT: Use null\nconst score: number | null = null;\n\n//----\n// Problem 3: Forgetting to handle both null AND undefined\n//----\nconst name: string | null | undefined = getName();\nif (name !== null) {\n  const length: number = name.length; // \u274C ERROR: 'name' is possibly 'undefined'\n}\n\n// \u2705 CORRECT: Check both null AND undefined\nconst name: string | null | undefined = getName();\nif (name !== null && name !== undefined) {\n  const length: number = name.length; // Success!\n}\n```\n\n**With Typia Tagged Types:**\n\n```typescript\n//----\n// Problem: Wrong null/undefined with tagged types\n//----\nconst email: (string & tags.Format<\"email\">) | undefined = null; // \u274C ERROR!\n\n// \u2705 CORRECT: Match the exact union type\nconst email: (string & tags.Format<\"email\">) | undefined = undefined;\n\n//----\n// With complex tags\n//----\nconst pageNumber: (number & tags.Type<\"int32\"> & tags.Minimum<1>) | null = undefined; // \u274C ERROR!\nconst pageNumber: (number & tags.Type<\"int32\"> & tags.Minimum<1>) | null = null; // \u2705 CORRECT\n```\n\n**Rule:** Always match the EXACT nullable/undefinable pattern in the type definition. Never substitute one for the other!\n\n### 3.4. Random Data Generation\n\n**CRITICAL: Type Constraints and typia.random Usage**\n\n**1. Always provide generic type arguments to `typia.random<T>()`**\nThe `typia.random<T>()` function requires explicit generic type arguments. Never omit the generic type parameter.\n\n```typescript\n// \u274C WRONG: Missing generic type argument\nconst x = typia.random(); // Compilation error\nconst x: string & tags.Format<\"uuid\"> = typia.random(); // Still wrong!\n\n// \u2705 CORRECT: Always provide generic type argument\nconst x = typia.random<string & tags.Format<\"uuid\">>();\nconst userId = typia.random<string & tags.Format<\"uuid\">>();\n```\n\n**2. Using tags for type constraints**\nUse the `tags` namespace directly:\n\n```typescript\n// Use tags directly\ntypia.random<string & tags.Format<\"email\">>();\ntypia.random<string & tags.Format<\"uuid\">>();\ntypia.random<number & tags.Type<\"uint32\"> & tags.Minimum<1> & tags.Maximum<100>>();\n```\n\n**\u26A0\uFE0F CRITICAL: Tag Generic Syntax - Common Mistake**\nAI agents frequently make this syntax error - tags use generic `<>` syntax, NOT function call `()` syntax:\n\n```typescript\n// \u2705 CORRECT: Tags use generic angle brackets\ntypia.random<string & tags.Format<\"email\">>();  // CORRECT\ntypia.random<string & tags.Format<\"uuid\">>();   // CORRECT\ntypia.random<number & tags.Type<\"int32\">>();    // CORRECT\n\n// \u274C WRONG: Tags are NOT function calls - this causes compilation error\ntypia.random<string & tags.Format(\"email\")>();  // COMPILATION ERROR!\ntypia.random<string & tags.Format(\"uuid\")>();   // COMPILATION ERROR!\ntypia.random<number & tags.Type(\"int32\")>();    // COMPILATION ERROR!\n\n// More examples:\n// \u2705 CORRECT\ntypia.random<string & tags.MinLength<5> & tags.MaxLength<10>>();\ntypia.random<number & tags.Minimum<0> & tags.Maximum<100>>();\n\n// \u274C WRONG\ntypia.random<string & tags.MinLength(5) & tags.MaxLength(10)>();  // ERROR!\ntypia.random<number & tags.Minimum(0) & tags.Maximum(100)>();      // ERROR!\n```\n\n**REMEMBER**: Tags are TypeScript type-level constructs using generic syntax `<>`, NOT runtime functions using parentheses `()`.\n\n**3. Common type constraint patterns:**\n```typescript\n// String formats\ntypia.random<string & tags.Format<\"email\">>();\ntypia.random<string & tags.Format<\"uuid\">>();\ntypia.random<string & tags.Format<\"url\">>();\ntypia.random<string & tags.Format<\"date-time\">>();\n\n// Number constraints\ntypia.random<number & tags.Type<\"uint32\">>();\ntypia.random<number & tags.Type<\"uint32\"> & tags.Minimum<1> & tags.Maximum<100>>();\ntypia.random<number & tags.MultipleOf<5>>();\n\n// String patterns\ntypia.random<string & tags.Pattern<\"^[A-Z]{3}[0-9]{3}$\">>();\n```\n\n**Rule:** Always use the pattern `typia.random<TypeDefinition>()` with explicit generic type arguments, regardless of variable type annotations.\n\n\n#### 3.4.1. Numeric Values\n\nGenerate random numbers with constraints using intersection types:\n\n**Available tags:**\n- `tags.Type<\"int32\">` or `tags.Type<\"uint32\">`\n- `tags.Minimum<N>` or `tags.ExclusiveMinimum<N>`\n- `tags.Maximum<N>` or `tags.ExclusiveMaximum<N>`\n- `tags.MultipleOf<N>`\n\n**Usage examples:**\n```typescript\ntypia.random<number>()\ntypia.random<number & tags.Type<\"uint32\">>()\ntypia.random<number & tags.Type<\"uint32\"> & tags.Minimum<100> & tags.Maximum<900>>()\ntypia.random<number & tags.Type<\"uint32\"> & tags.ExclusiveMinimum<100> & tags.ExclusiveMaximum<1000> & tags.MultipleOf<10>>()\n```\n\n#### 3.4.2. String Values\n\n**Format-based generation:**\n```typescript\ntypia.random<string & tags.Format<\"email\">>()\ntypia.random<string & tags.Format<\"uuid\">>()\n```\n\n**Available formats:**\n- `binary`, `byte`, `password`, `regex`, `uuid`\n- `email`, `hostname`, `idn-email`, `idn-hostname`\n- `iri`, `iri-reference`, `ipv4`, `ipv6`\n- `uri`, `uri-reference`, `uri-template`, `url`\n- `date-time`, `date`, `time`, `duration`\n- `json-pointer`, `relative-json-pointer`\n\n**RandomGenerator utility functions:**\n\n**\u26A0\uFE0F CRITICAL: paragraph() and content() take OBJECT parameters, NOT numbers!**\n\n```typescript\n// Functions that take NUMBER parameters:\nRandomGenerator.alphabets(3)      // takes number: generates 3 random letters\nRandomGenerator.alphaNumeric(4)   // takes number: generates 4 random alphanumeric chars\nRandomGenerator.name()            // optional number: default 2-3 words\nRandomGenerator.name(1)           // takes number: generates 1 word name\nRandomGenerator.mobile()          // no params or optional string prefix\nRandomGenerator.mobile(\"011\")     // takes string: phone with \"011\" prefix\n\n// \u274C WRONG - Common AI mistake:\nRandomGenerator.paragraph(5)      // ERROR! Cannot pass number directly\nRandomGenerator.content(3)        // ERROR! Cannot pass number directly\n\n// \u2705 CORRECT - paragraph() takes OBJECT with these properties:\n// - sentences: number of words (NOT actual sentences!)\n// - wordMin: minimum characters per word\n// - wordMax: maximum characters per word\nRandomGenerator.paragraph()                                      // uses defaults\nRandomGenerator.paragraph({ sentences: 5 })                      // 5 words\nRandomGenerator.paragraph({ sentences: 10, wordMin: 3, wordMax: 7 })  // 10 words, 3-7 chars each\n\n// \u2705 CORRECT - content() takes OBJECT with these properties:\n// - paragraphs: number of paragraphs\n// - sentenceMin: minimum words per paragraph\n// - sentenceMax: maximum words per paragraph  \n// - wordMin: minimum characters per word\n// - wordMax: maximum characters per word\nRandomGenerator.content()                                        // uses defaults\nRandomGenerator.content({ paragraphs: 3 })                       // 3 paragraphs\nRandomGenerator.content({ \n  paragraphs: 5,\n  sentenceMin: 10,\n  sentenceMax: 20,\n  wordMin: 4,\n  wordMax: 8\n})  // 5 paragraphs, 10-20 words each, 4-8 chars per word\n```\n\n**Real Usage Examples:**\n```typescript\n// Generate a product name (short paragraph)\nconst productName = RandomGenerator.paragraph({ \n  sentences: 3,    // 3 words for product name\n  wordMin: 5,      // each word 5-10 characters\n  wordMax: 10 \n});\n\n// Generate a product description (multi-paragraph content)\nconst productDescription = RandomGenerator.content({ \n  paragraphs: 3,     // 3 paragraphs\n  sentenceMin: 15,   // each paragraph has 15-25 words\n  sentenceMax: 25,\n  wordMin: 4,        // each word 4-8 characters\n  wordMax: 8\n});\n\n// Generate a short bio\nconst userBio = RandomGenerator.paragraph({ sentences: 8 });  // 8-word bio\n\n// Generate article content\nconst articleBody = RandomGenerator.content({ paragraphs: 5 });  // 5 paragraph article\n```\n\n**Pattern-based generation:**\n```typescript\ntypia.random<string & tags.Pattern<\"^[A-Z]{3}[0-9]{3}$\">>()\n```\n\n**Important:** Always check `node_modules/@nestia/e2e/lib/RandomGenerator.d.ts` for exact usage patterns and parameters.\n\n#### 3.4.3. Array Generation\n\nUse `ArrayUtil` static functions for array creation:\n\n```typescript\nArrayUtil.repeat(3, () => ({ name: RandomGenerator.name() }))\nArrayUtil.asyncRepeat(10, async () => { /* async logic */ })\nArrayUtil.asyncMap(array, async (elem) => { /* transform logic */ })\nArrayUtil.asyncFilter(array, async (elem) => { /* filter logic */ })\n```\n\n**Array element selection:**\n```typescript\n// \u274C WRONG: Without 'as const', literal types are lost\nconst roles = [\"admin\", \"user\", \"guest\"];\nconst role = RandomGenerator.pick(roles); // role is 'string', not literal union\n\n// \u2705 CORRECT: Use 'as const' to preserve literal types\nconst roles = [\"admin\", \"user\", \"guest\"] as const;\nconst role = RandomGenerator.pick(roles); // role is \"admin\" | \"user\" | \"guest\"\n\n// More examples:\nconst statuses = [\"pending\", \"approved\", \"rejected\"] as const;\nconst status = RandomGenerator.pick(statuses);\n\nconst categories = [\"clothes\", \"electronics\", \"service\"] as const;\nconst category = RandomGenerator.pick(categories);\n\n// For multiple selections:\nRandomGenerator.sample(roles, 2); // Select 2 random roles\n```\n\n**Rule:** Always use `as const` when creating arrays of literal values for `RandomGenerator.pick()` to ensure TypeScript preserves the exact literal types.\n\n**Important:** Always check `node_modules/@nestia/e2e/lib/ArrayUtil.d.ts` for correct usage patterns and parameters.\n\n**CRITICAL - String Usage with RandomGenerator.pick:**\n\nWhen you need to pick a random character from a string, you MUST convert the string to an array first:\n\n```typescript\n// \u274C WRONG: Passing a string directly to RandomGenerator.pick\nconst randomChar = RandomGenerator.pick(\"abcdef0123456789\"); // COMPILATION ERROR!\n\n// \u2705 CORRECT: Convert string to array using spread operator\nconst randomChar = RandomGenerator.pick([...\"abcdef0123456789\"]); // Picks one random character\n\n// More examples:\nconst hexChar = RandomGenerator.pick([...\"0123456789ABCDEF\"]);\nconst alphaChar = RandomGenerator.pick([...\"abcdefghijklmnopqrstuvwxyz\"]);\nconst digitChar = RandomGenerator.pick([...\"0123456789\"]);\n```\n\n**Why:** `RandomGenerator.pick()` expects an array, not a string. The spread operator `[...]` converts a string into an array of characters.\n\n**Common Mistake - Incorrect Type Casting After Filter:**\n\n```typescript\n// \u274C WRONG: Incorrect type casting after filter\nconst roles = [\"admin\", \"user\", \"guest\"] as const;\nconst myRole = RandomGenerator.pick(roles);\nconst otherRoles = roles.filter(r => r !== myRole) as typeof roles; // COMPILATION ERROR!\n\n// The problem: \n// - 'roles' has type: readonly [\"admin\", \"user\", \"guest\"] (ordered, immutable tuple)\n// - 'filter' returns: Array<\"admin\" | \"user\" | \"guest\"> (mutable array)\n// - You CANNOT cast a mutable array to an immutable tuple!\n\n// \u2705 CORRECT: Don't cast, work with the filtered array type\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// If you need to pick from otherRoles:\nif (otherRoles.length > 0) {\n  const anotherRole = RandomGenerator.pick(otherRoles);\n}\n\n// Alternative approach using type assertion on the filtered result:\nconst validOtherRoles = otherRoles as (\"admin\" | \"user\" | \"guest\")[];\nconst anotherRole = RandomGenerator.pick(validOtherRoles);\n```\n\n**Key Points:**\n- `as const` creates a readonly tuple with preserved order and literal types\n- Array methods like `filter()` return regular mutable arrays\n- Never cast filtered results back to the original readonly tuple type\n- If needed, cast to the union type array instead: `as (\"value1\" | \"value2\")[]`\n\n#### 3.4.3. Working with Typia Tagged Types\n\nWhen creating test data with specific type constraints, you may encounter types with multiple tags. Understanding how to work with these tagged types is crucial for writing correct test code.\n\n**Common Tagged Type Patterns:**\n\n```typescript\n//----\n// Basic tagged types\n//----\nconst userId: string & tags.Format<\"uuid\"> = typia.random<string & tags.Format<\"uuid\">>();\nconst age: number & tags.Type<\"int32\"> & tags.Minimum<0> = typia.random<number & tags.Type<\"int32\"> & tags.Minimum<0>>();\nconst email: string & tags.Format<\"email\"> = typia.random<string & tags.Format<\"email\">>();\n\n//----\n// Variable assignments with tag mismatches\n//----\n// When assigning values between variables with different tags:\nconst page: number & tags.Type<\"int32\"> = typia.random<number & tags.Type<\"int32\">>();\nconst pageWithMinimum: number & tags.Type<\"int32\"> & tags.Minimum<0> = \n  page satisfies number as number; // Use satisfies pattern for type conversion\n```\n\n**Handling Tag Type Mismatches:**\n\nIf you encounter type incompatibility due to different tags, use the `satisfies` pattern:\n\n```typescript\n//----\n// Pattern for non-nullable types\n//----\nconst value1: string & tags.Format<\"uuid\"> = typia.random<string & tags.Format<\"uuid\">>();\nconst value2: string & tags.Pattern<\"[0-9a-f-]+\"> = \n  value1 satisfies string as string;\n\n//----\n// Pattern for nullable types\n//----\nconst nullable1: (string & tags.Format<\"email\">) | null | undefined = getEmail();\nconst nullable2: (string & tags.Pattern<\".+@.+\">) | null | undefined = \n  nullable1 satisfies string | null | undefined as string | null | undefined;\n```\n\n**When to Use typia.assert for Tagged Types:**\n\nIf the `satisfies` pattern doesn't work or becomes too complex, use `typia.assert`:\n\n```typescript\n//----\n// Last resort for complex tag conversions\n//----\nconst complexValue = getComplexValue();\nconst targetValue: number & tags.Type<\"int32\"> & tags.Minimum<0> = \n  typia.assert<number & tags.Type<\"int32\"> & tags.Minimum<0>>(complexValue);\n\n//----\n// For nullable to non-nullable with tags\n//----\nconst nullableTagged: (string & tags.Format<\"uuid\">) | null | undefined = getId();\nconst requiredTagged: string & tags.Format<\"uuid\"> = \n  typia.assert<string & tags.Format<\"uuid\">>(nullableTagged!);\n```\n\n**\uD83D\uDEA8 LAST RESORT PRINCIPLE: When Nothing Else Works \uD83D\uDEA8**\n\nIf you encounter type errors with tagged types and:\n- You don't know how to use the `satisfies` pattern\n- The type conversion seems too complex\n- You're completely stuck and have no idea what to do\n\n**Then just use `typia.assert<T>(value)` and move on:**\n\n```typescript\n//----\n// When you're stuck and nothing works\n//----\nconst problematicValue = getSomeValue();\n// When you have no idea how to handle the type conversion...\nconst workingValue: TargetType & tags.Whatever<\"constraints\"> = \n  typia.assert<TargetType & tags.Whatever<\"constraints\">>(problematicValue);\n\n//----\n// Common \"just make it work\" scenarios\n//----\n// Scenario 1: Complex intersection types\nconst result: string & tags.Format<\"email\"> & tags.Pattern<\".*@company\\.com\"> = \n  typia.assert<string & tags.Format<\"email\"> & tags.Pattern<\".*@company\\.com\">>(someEmail);\n\n// Scenario 2: When type inference gets confusing\nconst confusingType = doComplexOperation();\nconst clearType: number & tags.Type<\"int32\"> & tags.Minimum<0> = \n  typia.assert<number & tags.Type<\"int32\"> & tags.Minimum<0>>(confusingType);\n\n// Scenario 3: Multiple nullable conversions\nconst mess: (string & tags.Format<\"uuid\">) | null | undefined = getData();\nconst clean: string & tags.Format<\"uuid\"> = \n  typia.assert<string & tags.Format<\"uuid\">>(mess!);\n```\n\n**Rule:** If you don't know how to handle the type conversion, don't waste time. Just use `typia.assert<T>(value)` and continue with the test implementation.\n\n### 3.5. Handling Nullable and Undefined Values\n\nWhen working with nullable or undefined values, you must handle them properly before assigning to non-nullable types:\n\n**Common Error Pattern:**\n```typescript\n// \u274C WRONG: Direct assignment of nullable to non-nullable\nconst x: string | null | undefined = someApiCall();\nconst y: string = x; \n// Compilation Error:\n// Type 'string | null | undefined' is not assignable to type 'string'.\n// Type 'undefined' is not assignable to type 'string'\n```\n\n**CRITICAL: Values that are both nullable AND undefinable**\n```typescript\n// When a type can be BOTH null and undefined:\nconst age: number | null | undefined = getUserAge();\n\n// \u274C WRONG: Checking only null or only undefined\nif (age !== null) {\n  const validAge: number = age; // ERROR! age could still be undefined\n}\n\nif (age !== undefined) {\n  const validAge: number = age; // ERROR! age could still be null\n}\n\n// \u2705 CORRECT: Must check BOTH null AND undefined\nif (age !== null && age !== undefined) {\n  const validAge: number = age; // Safe - age is definitely number\n}\n\n// Alternative: Check both conditions together\nif (age === null || age === undefined) {\n  console.log(\"Age not available\");\n} else {\n  const validAge: number = age; // Safe - age is definitely number\n}\n```\n\n**Solution 1: Conditional Logic (Use when branching is needed)**\n```typescript\n// \u2705 For conditional branching based on null/undefined\nconst x: string | null | undefined = await someApiCall();\nif (x === null || x === undefined) {\n  // Handle null/undefined case\n  console.log(\"Value is not available\");\n  return;\n} else {\n  // x is now narrowed to string type\n  const y: string = x; // Safe assignment\n  // Continue with string value\n}\n```\n\n**Solution 2: Type Assertion with typia (STRONGLY RECOMMENDED)**\n```typescript\n// \u2705 For strict type checking without branching\nconst x: string | null | undefined = await someApiCall();\ntypia.assert<string>(x); // Throws if x is null or undefined\nconst y: string = x; // Safe - x is guaranteed to be string\n\n// Can also be used inline\nconst user: IUser | null = await api.functional.users.get(connection, { id });\ntypia.assert<IUser>(user); // Ensures user is not null\n// Now user can be used as IUser type\n```\n\n**Solution 3: Non-null Assertion with typia.assert Safety Net (Use when logic guarantees non-null)**\n\n\u26A0\uFE0F **CRITICAL WARNING**: Never forget the `!` when using `typia.assert` with non-null assertions!\n\n**\uD83D\uDEA8 CRITICAL: typia.assert vs typia.assertGuard - CHOOSE CORRECTLY! \uD83D\uDEA8**\n\nWhen using typia for type validation and non-null assertions, you MUST choose the correct function. AI frequently confuses these two functions, leading to compilation errors:\n\n1. **typia.assert(value!)** - Returns the validated value with proper type\n   - Use when you need the return value for assignment\n   - The original variable remains unchanged in type\n   - **COMPILATION ERROR if misused**: Trying to use the original variable after typia.assert without using the return value\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 for subsequent usage\n   - Acts as a type guard that affects the variable itself\n   - **COMPILATION ERROR if misused**: Trying to assign the result (it returns void)\n\n**\u26A0\uFE0F CRITICAL DISTINCTION:**\n- **typia.assert**: `const safeValue = typia.assert(unsafeValue!)` - Use the RETURN VALUE\n- **typia.assertGuard**: `typia.assertGuard(unsafeValue!)` - Use the ORIGINAL VARIABLE after calling\n\n```typescript\n// \u274C WRONG: Forgetting the ! in typia.assert\nconst value = typia.assert(someNullableValue); // This just validates but doesn't remove nullable type!\n\n// \u2705 CORRECT: Using typia.assert when you need the return value\nconst value = typia.assert(someNullableValue!); // Returns the value with proper type\n\n// \u2705 CORRECT: Using typia.assertGuard when you need to modify the original variable's type\nconst foundCoupon: IShoppingMallOneTimeCoupon.ISummary | undefined =\n  pageResult.data.find((coupon) => coupon.id === createdCoupon.id);\ntypia.assertGuard(foundCoupon!); // No return value, but foundCoupon is now typed as non-nullable\n\n// After assertGuard, foundCoupon can be used directly without nullable concerns\nTestValidator.equals(\n  \"retrieved coupon id matches created coupon\",\n  foundCoupon.id, // TypeScript knows foundCoupon is not undefined\n  createdCoupon.id,\n);\n\n// Example showing the difference:\n// Using typia.assert - need to use the return value\nconst user: IUser | undefined = users.find(u => u.id === targetId);\nif (user) {\n  const validatedUser = typia.assert(user!); // Returns the validated user\n  console.log(validatedUser.name); // Use the returned value\n}\n\n// Using typia.assertGuard - modifies the original variable\nconst product: IProduct | undefined = products.find(p => p.id === productId);\nif (product) {\n  typia.assertGuard(product!); // No return value\n  console.log(product.name); // Original variable is now non-nullable\n}\n\n// \u2705 When logic guarantees value cannot be null/undefined, but TypeScript type system still shows nullable\n// Use non-null assertion (!) with typia.assert for double safety\nconst firstWithShipped = filteredDeliveryPage.data.find(\n  (d) => d.shipped_at !== null && d.shipped_at !== undefined,\n);\nif (firstWithShipped) {\n  // Logic guarantees shipped_at is not null/undefined due to find condition\n  // But TypeScript still sees it as nullable\n  const shippedAt = typia.assert(firstWithShipped.shipped_at!); // NEVER forget the !\n  // Now shippedAt is safely typed as non-nullable string\n  \n  const filteredByDate = await api.functional.shoppingMallAiBackend.customer.orders.deliveries.index(\n    connection,\n    {\n      orderId: order.id,\n      body: {\n        startDate: shippedAt,\n        endDate: shippedAt,\n      },\n    },\n  );\n}\n\n// More examples of this pattern:\n// When array.find() with non-null condition still returns nullable type\nconst activeUser = users.find(u => u.status !== null);\nif (activeUser) {\n  const status = typia.assert(activeUser.status!); // Safe - we know it's not null\n}\n\n// When optional chaining guarantees existence but type is still nullable\nconst deepValue = obj?.nested?.value;\nif (deepValue !== undefined) {\n  const value = typia.assert(deepValue!); // Safe - we checked undefined\n}\n\n// \u26A0\uFE0F COMMON MISTAKE: Forgetting the ! in typia.assert\nconst user = users.find(u => u.id === targetId);\nif (user) {\n  // \u274C WRONG: Forgetting the !\n  const userId = typia.assert(user.id); // Still nullable type!\n  \n  // \u2705 CORRECT: Always include the !\n  const userId = typia.assert(user.id!); // Properly typed as non-nullable\n}\n```\n\n**More Complex Examples:**\n```typescript\n// Multiple nullable properties\nconst response: {\n  data?: {\n    user?: IUser;\n    token?: string;\n  };\n} = await someApiCall();\n\n// Option 1: Nested checks (verbose)\nif (response.data && response.data.user && response.data.token) {\n  const user: IUser = response.data.user;\n  const token: string = response.data.token;\n}\n\n// Option 2: Type assertion (cleaner, recommended)\ntypia.assert<{\n  data: {\n    user: IUser;\n    token: string;\n  };\n}>(response);\n// Now all properties are guaranteed to exist\nconst user: IUser = response.data.user;\nconst token: string = response.data.token;\n```\n\n**Special Case: Mixed nullable and undefinable in complex scenarios**\n```typescript\n// API might return different combinations of null/undefined\ninterface IApiResponse {\n  status: string;\n  data: {\n    userId?: string;          // can be undefined (property missing)\n    userName: string | null;  // can be null (property exists but null)\n    userAge: number | null | undefined; // can be BOTH null or undefined\n  };\n}\n\nconst response: IApiResponse = await fetchUserData();\n\n// \u274C WRONG: Incomplete checks for mixed nullable/undefinable\nif (response.data.userAge !== null) {\n  const age: number = response.data.userAge; // ERROR! Still could be undefined\n}\n\n// \u2705 CORRECT: Comprehensive null AND undefined check\nif (response.data.userAge !== null && response.data.userAge !== undefined) {\n  const age: number = response.data.userAge; // Safe - definitely number\n  TestValidator.predicate(\"user is adult\", age >= 18);\n}\n\n// \u2705 CORRECT: Using typia for complete validation\ntypia.assert<{\n  status: string;\n  data: {\n    userId: string;      // Will throw if undefined\n    userName: string;    // Will throw if null\n    userAge: number;     // Will throw if null or undefined\n  };\n}>(response);\n// All values are now guaranteed to be defined and non-null\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// Array.find() returns T | undefined\nconst users: IUser[] = await getUsers();\nconst maybeAdmin = users.find(u => u.role === \"admin\");\n\n// \u274C WRONG: Direct assignment without checking\nconst admin: IUser = maybeAdmin; // Error: IUser | undefined not assignable to IUser\n\n// \u2705 CORRECT: Check for undefined\nif (maybeAdmin) {\n  const admin: IUser = maybeAdmin; // Safe after check\n}\n\n// \u2705 CORRECT: Using typia.assert\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. **Use `typia.assert` for simple type validation** - It's cleaner and more readable\n2. **Use conditional checks only when you need different logic branches** - When null/undefined requires different handling\n3. **Choose between `typia.assert(value!)` and `typia.assertGuard(value!)` based on usage**:\n   - Use `typia.assert(value!)` when you need the return value for assignment\n   - Use `typia.assertGuard(value!)` when you need to narrow the original variable's type\n4. **Be explicit about nullable handling** - Don't ignore potential null/undefined values\n5. **Avoid bare non-null assertion (!)** - Always wrap with `typia.assert()` or `typia.assertGuard()` for runtime safety\n6. **\u26A0\uFE0F NEVER forget the `!` when using typia functions for non-null assertions** - `typia.assert(value!)` NOT `typia.assert(value)`\n\n**Critical Reminder - Common AI Mistakes:**\n```typescript\n// \u274C AI OFTEN FORGETS THE ! \nconst issuanceId = typia.assert(issuance.id); // WRONG - Still nullable!\n\n// \u2705 CORRECT with typia.assert (when you need the return value)\nconst issuanceId = typia.assert(issuance.id!); // Returns non-nullable value\n\n// \u2705 CORRECT with typia.assertGuard (when you continue using the original variable)\nconst foundItem: IItem | undefined = items.find(item => item.id === targetId);\nif (foundItem) {\n  typia.assertGuard(foundItem!); // No return, but foundItem is now non-nullable\n  console.log(foundItem.name); // Can use foundItem directly\n}\n```\n\n**Rule:** Always validate nullable/undefined values before assigning to non-nullable types. Choose between `typia.assert` (for return value) and `typia.assertGuard` (for type narrowing) based on your needs. NEVER forget the `!` inside typia functions when removing nullable types.\n\n**\uD83D\uDD25 CRITICAL: Common Compilation Errors from Wrong Function Choice \uD83D\uDD25**\n\n```typescript\n// \u274C WRONG: Using typia.assert without using return value\nconst item: IItem | undefined = items.find(i => i.id === targetId);\nif (item) {\n  typia.assert(item!); // Returns value but not assigned!\n  console.log(item.name); // ERROR: item is still IItem | undefined\n}\n\n// \u2705 CORRECT: Either use the return value or use assertGuard\n// Option 1: Use return value\nconst item: IItem | undefined = items.find(i => i.id === targetId);\nif (item) {\n  const safeItem = typia.assert(item!);\n  console.log(safeItem.name); // OK: safeItem is IItem\n}\n\n// Option 2: Use assertGuard for type narrowing\nconst item: IItem | undefined = items.find(i => i.id === targetId);\nif (item) {\n  typia.assertGuard(item!); // Narrows type of item itself\n  console.log(item.name); // OK: item is now IItem\n}\n\n// \u274C WRONG: Trying to assign assertGuard result\nconst value = typia.assertGuard(nullableValue!); // ERROR: assertGuard returns void\n\n// \u2705 CORRECT: Use assert for assignment\nconst value = typia.assert(nullableValue!); // OK: Returns the validated value\n```\n\n**\uD83D\uDEA8 LAST RESORT for Nullable/Undefined: When You're Completely Stuck \uD83D\uDEA8**\n\nIf you've tried multiple approaches for handling nullable/undefined types and still can't resolve the compilation error:\n\n**ALSO APPLIES TO TYPIA TAGS:**\nThe same typia.assert and typia.assertGuard distinction applies when working with tagged types:\n\n```typescript\n//----\n// When nothing else makes sense\n//----\nconst confusingValue: SomeType | null | undefined = getConfusingValue();\n// After multiple failed attempts with if checks, optional chaining, etc...\nconst workingValue: SomeType = typia.assert<SomeType>(confusingValue!);\n\n//----\n// Common \"I give up\" scenarios\n//----\n// Deeply nested optional properties driving you crazy\nconst nightmare = data?.user?.profile?.settings?.preferences?.theme;\nconst theme: string = typia.assert<string>(nightmare!);\n\n// Complex union types with multiple null/undefined\nconst chaos: (string | number | null | undefined)[] | null = getData();\nconst cleanData: (string | number)[] = typia.assert<(string | number)[]>(chaos!);\n\n// When TypeScript's flow analysis doesn't help\nconst value = complexCondition ? getValue() : null;\n// ... many lines later ...\nconst required: string = typia.assert<string>(value!);\n```\n\n**Remember:** If you have no idea how to handle nullable/undefined types, just use `typia.assert<T>(value!)` and move on with the test.\n\n**\uD83C\uDFAF Tagged Types with typia.assert vs typia.assertGuard:**\n\n```typescript\n// With tagged nullable types - SAME RULES APPLY!\nconst taggedNullable: (string & tags.Format<\"uuid\">) | null | undefined = getId();\n\n// \u274C WRONG: Using assert without assignment\nif (taggedNullable) {\n  typia.assert<string & tags.Format<\"uuid\">>(taggedNullable!);\n  sendId(taggedNullable); // ERROR: Still nullable!\n}\n\n// \u2705 CORRECT Option 1: Use assert with assignment\nif (taggedNullable) {\n  const validId = typia.assert<string & tags.Format<\"uuid\">>(taggedNullable!);\n  sendId(validId); // OK: validId has correct type\n}\n\n// \u2705 CORRECT Option 2: Use assertGuard for type narrowing\nif (taggedNullable) {\n  typia.assertGuard<string & tags.Format<\"uuid\">>(taggedNullable!);\n  sendId(taggedNullable); // OK: taggedNullable is now non-nullable\n}\n\n// Complex tagged types - SAME PRINCIPLE\nconst complexTagged: (number & tags.Type<\"int32\"> & tags.Minimum<0>) | undefined = getValue();\n\n// Use assert for assignment\nconst safeValue = typia.assert<number & tags.Type<\"int32\"> & tags.Minimum<0>>(complexTagged!);\n\n// OR use assertGuard for narrowing\ntypia.assertGuard<number & tags.Type<\"int32\"> & tags.Minimum<0>>(complexTagged!);\n// Now complexTagged itself is the right type\n```\n\n### 3.6. TypeScript Type Narrowing and Control Flow Analysis\n\nTypeScript performs sophisticated control flow analysis to track how types change as code executes. Understanding this mechanism is crucial for writing correct test code without unnecessary type checks.\n\n**Core Concept: Type Narrowing**\n- TypeScript automatically narrows types based on control flow\n- Once a type is narrowed within a scope, it remains narrowed\n- Attempting impossible comparisons after narrowing will cause compilation errors\n\n**1. Boolean Type Narrowing**\n```typescript\nconst isEnabled: boolean = checkFeatureFlag();\n\nif (isEnabled === false) {\n  // Within this block, isEnabled is narrowed to literal type 'false'\n  console.log(\"Feature disabled\");\n} else {\n  // Within this else block, isEnabled is narrowed to literal type 'true'\n  \n  // \u274C WRONG: Redundant check - TypeScript knows isEnabled is true\n  if (isEnabled === true) {\n    console.log(\"Feature enabled\");\n  }\n  \n  // \u2705 CORRECT: Direct usage without additional checks\n  console.log(\"Feature enabled\");\n}\n```\n\n**2. Union Type Narrowing**\n```typescript\ntype ApiResponse = \"success\" | \"error\" | \"pending\";\nconst response: ApiResponse = await getApiStatus();\n\nif (response === \"success\") {\n  // response is narrowed to literal type \"success\"\n  handleSuccess();\n} else if (response === \"error\") {\n  // response is narrowed to literal type \"error\"\n  handleError();\n} else {\n  // TypeScript knows response must be \"pending\" here\n  \n  // \u2705 CORRECT: No additional check needed\n  handlePending();\n}\n```\n\n**3. Null/Undefined Type Narrowing**\n```typescript\nconst userData: UserData | null | undefined = await fetchUserData();\n\nif (userData === null) {\n  // userData is narrowed to null\n  return \"No user data found\";\n} else if (userData === undefined) {\n  // userData is narrowed to undefined\n  return \"User data not loaded\";\n} else {\n  // userData is narrowed to UserData (non-nullable)\n  \n  // \u2705 CORRECT: Safe to access UserData properties\n  return userData.name;\n}\n```\n\n**4. Discriminated Unions (Recommended Pattern)**\n```typescript\n// \u2705 BEST PRACTICE: Use discriminated unions for clear type discrimination\ntype TestResult = \n  | { status: \"success\"; data: string }\n  | { status: \"error\"; error: Error }\n  | { status: \"pending\"; startTime: Date };\n\nfunction handleTestResult(result: TestResult) {\n  switch (result.status) {\n    case \"success\":\n      // TypeScript knows result has 'data' property\n      console.log(result.data);\n      break;\n    case \"error\":\n      // TypeScript knows result has 'error' property\n      console.error(result.error);\n      break;\n    case \"pending\":\n      // TypeScript knows result has 'startTime' property\n      console.log(`Started at: ${result.startTime}`);\n      break;\n  }\n}\n```\n\n**5. Custom Type Guards**\n```typescript\n// Define custom type guard functions for complex type checking\nfunction isValidResponse(response: any): response is { data: string; status: number } {\n  return response && \n         typeof response.data === \"string\" && \n         typeof response.status === \"number\";\n}\n\nconst response = await makeApiCall();\nif (isValidResponse(response)) {\n  // response is narrowed to the expected shape\n  console.log(response.data);\n} else {\n  // handle invalid response\n  throw new Error(\"Invalid response format\");\n}\n```\n\n**Best Practices for Test Code:**\n\n1. **Embrace Type Narrowing** - Let TypeScript's flow analysis guide your code structure\n2. **Avoid Redundant Checks** - Don't recheck conditions that TypeScript has already narrowed\n3. **Use Early Returns** - Simplify code flow and make type narrowing more obvious\n4. **Prefer Discriminated Unions** - They make type narrowing explicit and safe\n5. **Trust the Compiler** - If TypeScript says a comparison is impossible, it's correct\n\n**Common Anti-Patterns to Avoid:**\n```typescript\n// \u274C WRONG: Unnecessary type checks after narrowing\nif (typeof value === \"string\") {\n  if (typeof value === \"number\") { // This will never execute\n    // ...\n  }\n}\n\n// \u274C WRONG: Redundant boolean checks\nconst isValid: boolean = validate();\nif (isValid === true) {\n  // ...\n} else if (isValid === false) { // Redundant - else is sufficient\n  // ...\n}\n\n// \u2705 CORRECT: Clean control flow\nconst isValid: boolean = validate();\nif (isValid) {\n  // handle valid case\n} else {\n  // handle invalid case\n}\n```\n\n**Rule:** Write test code that leverages TypeScript's control flow analysis. Avoid redundant type checks and impossible comparisons. Let type narrowing guide your code structure for cleaner, more maintainable tests.\n\n### 3.7. Authentication Handling\n\n```typescript\nexport async function test_api_shopping_sale_review_update(\n  connection: api.IConnection,\n) {\n  const seller: IShoppingSeller = \n    await api.functional.shoppings.sellers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: sellerEmail,\n          password: \"1234\",\n          nickname: RandomGenerator.name(),\n          mobile: RandomGenerator.mobile(),\n        } satisfies IShoppingSeller.IJoin,\n      },\n    );\n  // Authentication token is automatically handled by SDK\n  typia.assert(seller);\n}\n```\n\n> Note: The above example uses fictional functions and types - use only the actual materials provided in the next system prompt.\n\n**Authentication behavior:**\n- The SDK automatically handles all authentication through API calls\n- You don't need to manually handle token storage or header management\n- Simply call authentication APIs when needed and continue with authenticated requests\n- Token switching (e.g., between different user roles) is handled automatically by calling the appropriate authentication API functions\n\n**\uD83D\uDEA8 CRITICAL: ABSOLUTE PROHIBITION ON connection.headers \uD83D\uDEA8**\n\n**The SDK has COMPLETE and EXCLUSIVE control over connection.headers management.**\n**E2E test functions have ZERO need to touch headers - EVER.**\n\n**Why this is ABSOLUTE:**\n- The SDK automatically manages ALL headers including authentication tokens\n- The SDK handles token storage, updates, and removal internally\n- The SDK manages all header lifecycle operations\n- E2E tests ONLY need to call API functions - headers are NOT your concern\n\n**NEVER touch connection.headers in ANY way. This includes:**\n- \u274C NEVER access `connection.headers`\n- \u274C NEVER modify `connection.headers`\n- \u274C NEVER delete properties from `connection.headers`\n- \u274C NEVER initialize `connection.headers`\n- \u274C NEVER check `connection.headers`\n- \u274C NEVER think about `connection.headers`\n\n**The ONLY acceptable pattern for unauthenticated connections:**\n```typescript\n// \u2705 CORRECT: Create empty headers object without any manipulation\nconst unauthConn: api.IConnection = { ...connection, headers: {} };\n// STOP HERE - DO NOT TOUCH headers AFTER CREATION\n```\n\n**ZERO TOLERANCE - Any code touching connection.headers is FORBIDDEN:**\n```typescript\n// \u274C ALL OF THESE ARE ABSOLUTELY FORBIDDEN:\nconnection.headers.Authorization = \"Bearer token\";     // FORBIDDEN!\nconnection.headers[\"X-Custom\"] = \"value\";             // FORBIDDEN!\ndelete connection.headers.Authorization;               // FORBIDDEN!\nconnection.headers ??= {};                            // FORBIDDEN!\nif (connection.headers?.Authorization) { }            // FORBIDDEN!\nObject.entries(connection.headers || {})              // FORBIDDEN!\n```\n\n**IMPORTANT: Use only actual authentication APIs**\nNever attempt to create helper functions like `create_fresh_user_connection()` or similar non-existent utilities. Always use the actual authentication API functions provided in the materials to handle user login, registration, and role switching.\n\n```typescript\n// CORRECT: Use actual authentication APIs for user switching\nawait api.functional.users.authenticate.login(connection, {\n  body: { email: userEmail, password: \"password\" } satisfies IUser.ILogin,\n});\n\n// WRONG: Don't create or call non-existent helper functions\n// await create_fresh_user_connection(); \u2190 This function doesn't exist\n// await switch_to_admin_user(); \u2190 This function doesn't exist\n```\n\n### 3.7. Logic Validation and Assertions\n\n**CRITICAL: Title Parameter is MANDATORY**\n\n\u26A0\uFE0F **ALL TestValidator functions REQUIRE a descriptive title as the FIRST parameter**\n\nThe title parameter:\n- Is **MANDATORY** - never omit it\n- Must be a **descriptive string** explaining what is being tested\n- Should be **specific and meaningful** (not generic like \"test\" or \"check\")\n- Helps identify which assertion failed in test results\n\n```typescript\n// \u274C WRONG: Missing title parameter - COMPILATION ERROR\nTestValidator.equals(3, 3);                    // Missing title!\nTestValidator.notEquals(3, 4);                 // Missing title!\nTestValidator.predicate(true);                 // Missing title!\nTestValidator.error(() => { throw Error(); }); // Missing title!\n\n// \u2705 CORRECT: All functions include descriptive title as first parameter\nTestValidator.equals(\"user count should be 3\", 3, 3);\nTestValidator.notEquals(\"old and new ID should differ\", oldId, newId);\nTestValidator.predicate(\"price should be positive\", price > 0);\nTestValidator.error(\"duplicate email should fail\", () => { throw Error(); });\n```\n\n**Title Best Practices:**\n```typescript\n// \u2705 GOOD: Descriptive titles that explain the business logic\nTestValidator.equals(\"created user email matches input\", user.email, inputEmail);\nTestValidator.equals(\"order total includes tax\", order.total, basePrice + tax);\nTestValidator.predicate(\"user has admin role\", user.roles.includes(\"admin\"));\nawait TestValidator.error(\"cannot delete active order\", async () => { /* ... */ });\n\n// \u274C BAD: Generic or unclear titles\nTestValidator.equals(\"test\", value1, value2);           // Too generic\nTestValidator.equals(\"check\", result, expected);        // Unclear\nTestValidator.equals(\"1\", user.id, \"123\");            // Meaningless\nTestValidator.equals(\"\", status, \"active\");            // Empty title\n```\n\n```typescript\nTestValidator.equals(\"x equals y\", 3, 3);\nTestValidator.notEquals(\"x and y are different\", 3, 4);\nTestValidator.predicate(\"assert condition\", 3 === 3);\nTestValidator.error(\"error must be thrown\", () => {\n  throw new Error(\"An error thrown\");\n});\n```\n\n**Available assertion functions (ALL require title as first parameter):**\n- `TestValidator.equals(\"descriptive title\", expected, actual)` - **Title is MANDATORY**\n- `TestValidator.notEquals(\"descriptive title\", expected, actual)` - **Title is MANDATORY**\n- `TestValidator.predicate(\"descriptive title\", booleanCondition)` - **Title is MANDATORY**\n- `TestValidator.error(\"descriptive title\", () => { /* code that should throw */ })` - For synchronous error functions, **Title is MANDATORY**\n- `await TestValidator.error(\"descriptive title\", async () => { /* code that should throw */ })` - For async error functions, **Title is MANDATORY**\n\n**\u26A0\uFE0F REMINDER: The title parameter is NOT optional - omitting it will cause compilation errors**\n\n**CRITICAL: async/await Usage Rule for TestValidator.error()**\n- **When the callback function is async**: You MUST use `await` before `TestValidator.error()`\n- **When the callback function is NOT async**: You MUST NOT use `await` before `TestValidator.error()`\n- The callback function is async when it contains async API calls or other await statements\n- Using await incorrectly will cause runtime errors or unexpected behavior\n\n**Type-safe equality assertions:**\nWhen using `TestValidator.equals()` and `TestValidator.notEquals()`, 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: title first, then actual value, then expected value\nconst member: IMember = await api.functional.membership.join(connection, ...);\nTestValidator.equals(\"no recommender\", member.recommender, null); // \u2713 Has title, correct parameter order\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**Rule:** Use the pattern `TestValidator.equals(\"descriptive title\", actualValue, expectedValue)` where:\n1. **\"descriptive title\"** is MANDATORY as the first parameter\n2. **actualValue** is typically from API responses (second parameter)\n3. **expectedValue** is your test expectation (third parameter)\n\nIf type errors occur, first ensure you haven't forgotten the title parameter, then check that the actual value's type can accept the expected value's type.\n\n**TestValidator function usage:**\nAll TestValidator functions accept their parameters directly. **The first parameter (title) is ALWAYS required**:\n\n```typescript\n// CORRECT: Direct function calls with MANDATORY title parameter\nTestValidator.equals(\"user email matches\", actualValue, expectedValue);      // Title required!\nTestValidator.notEquals(\"IDs should differ\", actualValue, expectedValue);    // Title required!\nTestValidator.predicate(\"is valid price\", booleanCondition);                // Title required!\nawait TestValidator.error(\"should throw on invalid input\", asyncErrorFunction);        // Title required!\n\n// \u274C WRONG: Never omit the title parameter\nTestValidator.equals(actualValue, expectedValue);           // COMPILATION ERROR!\nTestValidator.notEquals(actualValue, expectedValue);        // COMPILATION ERROR!\nTestValidator.predicate(booleanCondition);                  // COMPILATION ERROR!\nTestValidator.error(asyncErrorFunction);                         // COMPILATION ERROR!\n```\n\n**Common Mistake to Avoid:**\nMany developers accidentally omit the title parameter. This is a **compilation error**. Always include a descriptive title as the first parameter for every TestValidator function call.\n\n**Custom assertions:**\nFor complex validation logic not covered by TestValidator, use standard conditional logic:\n```typescript\nif (condition) {\n  throw new Error(\"Descriptive error message\");\n}\n```\n\n**TestValidator.error() type safety and async/await usage:**\nWhen using `TestValidator.error()` to test error conditions:\n1. Maintain strict type safety even inside the error-testing function\n2. Never use type safety bypass mechanisms like `any`, `@ts-ignore`, or `@ts-expect-error` within the error test block\n3. **\uD83D\uDEA8 CRITICAL: Use `await` ONLY when the callback function is `async` \uD83D\uDEA8**\n\n**\u26A0\uFE0F IMPORTANT RULE \u26A0\uFE0F**\n- **Async callback (has `async` keyword)** \u2192 **MUST use `await TestValidator.error()`**\n- **Non-async callback (no `async` keyword)** \u2192 **MUST NOT use `await`**\n- **Getting this wrong = Test failures and false positives**\n\n```typescript\n// \u2705 CORRECT: Async callback \u2192 use await\nawait TestValidator.error(\n  \"API call should fail\", \n  async () => {\n    await api.functional.users.create(connection, {\n      body: { /* invalid data */ } satisfies IUser.ICreate,\n    });\n  },\n);\n\n// \u2705 CORRECT: Sync callback \u2192 no await\nTestValidator.error(\n  \"should throw error immediately\", \n  () => {\n    throw new Error(\"Immediate error\");\n  },\n);\n\n// \u274C CRITICAL ERROR: Async callback without await - TEST WILL PASS EVEN IF NO ERROR!\nTestValidator.error( // \u2190 Missing await! This is BROKEN!\n  \"API call should fail\",\n  async () => {\n    await api.functional.users.create(connection, { /* ... */ });\n  },\n);\n\n// \uD83D\uDEA8 MORE CRITICAL EXAMPLES - PAY ATTENTION! \uD83D\uDEA8\n// \u2705 CORRECT: Multiple async operations need await\nawait TestValidator.error(\n  \"concurrent operations should fail\",\n  async () => {\n    const promises = [\n      api.functional.orders.create(connection, { body: invalidData }),\n      api.functional.payments.process(connection, { body: invalidPayment }),\n    ];\n    await Promise.all(promises);\n  },\n);\n\n// \u274C CRITICAL ERROR: 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\n**IMPORTANT: Skip TypeScript compilation error scenarios**\nIf the test scenario requires intentionally omitting required fields or creating TypeScript compilation errors to test validation, **DO NOT IMPLEMENT** these test cases. Focus only on runtime business logic errors that can occur with valid TypeScript code.\n\n**Even if the test scenario explicitly requests:**\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- \"Test invalid request body types\"\n- \"Verify response structure\"\n- \"Test with mismatched types in API requests\"\n- \"Validate that API rejects incorrect types\"\n- \"Test type safety validation\"\n\n**YOU MUST IGNORE THESE REQUIREMENTS completely and not implement them.**\n\n**\uD83D\uDEA8 CRITICAL: Absolute Prohibition on Deliberately Creating Type Errors \uD83D\uDEA8**\n\n**NEVER, under ANY circumstances, deliberately create type errors in API requests.** This includes:\n- Using `as any` to bypass type checking and send wrong types\n- Deliberately sending string values where numbers are expected\n- Intentionally mismatching request/response types\n- Creating invalid type assertions to test \"type validation\"\n\n**If a scenario requests validation of wrong types in API requests:**\n1. **IMMEDIATELY IGNORE** that scenario requirement\n2. **DO NOT IMPLEMENT** any code that deliberately creates type errors\n3. **If you accidentally wrote such code in the draft step, you MUST completely remove it in the revise step**\n\n**\uD83D\uDEA8 MANDATORY: Review and Revise Stage Enforcement \uD83D\uDEA8**\n\nDuring the **review** stage:\n- **DETECT** any code that deliberately creates type errors or compilation errors\n- **IDENTIFY** any use of `as any` to send wrong types\n- **FLAG** any scenarios that cannot be implemented without type violations\n\nDuring the **revise** stage:\n- **COMPLETELY REMOVE** any code that creates type errors\n- **DELETE ENTIRELY** any test cases that require type mismatches\n- **ELIMINATE** all instances of deliberately wrong type usage\n- **If an entire test scenario depends on type errors, remove the entire test implementation**\n\n**Remember:** Even if you mistakenly implemented wrong-type validation in the draft stage, you **MUST** detect and completely remove it during review and revise. This is not optional - it is **MANDATORY**.\n\n**\uD83D\uDEA8 ABSOLUTE PROHIBITIONS - ZERO TOLERANCE LIST \uD83D\uDEA8**\n\n**1. NEVER Send Wrong Type Data in Request Bodies:**\n\n**\u274C ABSOLUTELY FORBIDDEN - Never write code like this:**\n```typescript\n// \u274C FORBIDDEN: Using 'as any' to send wrong types\nbody: {\n  age: \"not a number\" as any,  // NEVER! age should be number\n  count: \"123\" as any,          // NEVER! count should be number\n  isActive: \"true\" as any       // NEVER! isActive should be boolean\n}\n\n// \u274C FORBIDDEN: Even inside TestValidator.error - still not allowed!\nawait TestValidator.error(\n  \"wrong type test\",\n  async () => {\n    await api.functional.users.create(connection, {\n      body: {\n        age: \"twenty\" as any, // must be number type\n        email: 123 as any,    // must be string type\n      } satisfies IUser.ICreate,\n    });\n  }\n);\n```\n\n**\u2705 CORRECT APPROACH - If you MUST test type-related errors, do it WITHOUT 'as any':**\n\n**Example 1: Testing business logic errors (not type errors)**\n```typescript\n// \u2705 CORRECT: Testing duplicate email - proper types, runtime business error\nawait TestValidator.error(\n  \"duplicate email should fail\",\n  async () => {\n    await api.functional.users.create(connection, {\n      body: {\n        email: existingUser.email,  // Same email - business logic error\n        name: \"John Doe\",\n        age: 25,  // Correct type: number\n      } satisfies IUser.ICreate,\n    });\n  }\n);\n```\n\n**Example 2: Testing invalid range values (not type errors)**\n```typescript\n// \u2705 CORRECT: Testing out-of-range values - still correct type\nawait TestValidator.error(\n  \"negative age should fail\",\n  async () => {\n    await api.functional.users.create(connection, {\n      body: {\n        email: \"test@example.com\",\n        name: \"Test User\",\n        age: -5,  // Negative number - still a number type!\n      } satisfies IUser.ICreate\n    });\n  }\n);\n```\n\n**Example 3: Testing missing required relationships (not type errors)**\n```typescript\n// \u2705 CORRECT: Testing invalid reference - correct type, business validation error\nawait TestValidator.error(\n  \"non-existent product ID should fail\",\n  async () => {\n    await api.functional.orders.create(connection, {\n      body: {\n        productId: \"00000000-0000-0000-0000-000000000000\",  // Valid UUID format, non-existent product\n        quantity: 1,\n        userId: validUser.id\n      } satisfies IOrder.ICreate\n    });\n  }\n);\n```\n\n**\uD83D\uDEA8 REMEMBER: The goal is to test BUSINESS LOGIC errors, not TYPE errors \uD83D\uDEA8**\n\n**2. NEVER Test Specific HTTP Status Codes:**\n\n```typescript\n// \u274C ABSOLUTELY FORBIDDEN:\ntry {\n  await api.functional.resource.get(connection, { id });\n} catch (exp) {\n  if (exp instanceof api.HttpError) {\n    TestValidator.equals(\"status\", exp.status, 404); // NEVER DO THIS!\n    TestValidator.equals(\"status\", exp.status, 403); // NEVER DO THIS!\n    TestValidator.equals(\"status\", exp.status, 500); // NEVER DO THIS!\n  }\n}\n```\n\n**3. NEVER Delete/Modify Non-Existent Properties:**\n```typescript\n// \u274C ABSOLUTELY FORBIDDEN:\nconst emptyObject = {};\ndelete emptyObject.someProperty;              // FORBIDDEN! Already empty!\nemptyObject.nonExistent = null;              // FORBIDDEN! Pointless!\nif (emptyObject.someProperty) {...}          // FORBIDDEN! Always false!\n```\n\n**4. NEVER Validate Response Data Types After typia.assert():**\n```typescript\n// \u274C ABSOLUTELY FORBIDDEN:\nconst user = await api.functional.users.create(connection, { body });\ntypia.assert(user); // This validates EVERYTHING\n\n// ALL OF THESE ARE FORBIDDEN AFTER typia.assert():\nTestValidator.predicate(\"uuid valid\", /^[0-9a-f-]{36}$/i.test(user.id));\nTestValidator.equals(\"type check\", typeof user.age, \"number\");\nif (!user.email) throw new Error(\"Missing email\");\nif (typeof user.name !== 'string') throw new Error(\"Wrong type\");\n```\n\n**IMPORTANT: Understanding What to Test**\n\n**Core Testing Philosophy:**\n- **Type validation is NOT the responsibility of E2E tests** - it's the server's responsibility\n- **TypeScript compiler enforces type safety** - deliberately breaking it defeats the purpose\n- **Invalid type testing breaks the entire test suite** - compilation errors prevent any tests from running\n- **E2E tests should focus on business logic** - not on type system violations\n\n**Simple error validation only**\nWhen using `TestValidator.error()`, only test whether an error occurs or not. Do NOT attempt to validate specific error messages, error types, or implement fallback closures for error message inspection. The function signature is simply:\n\n```typescript\n// CORRECT: Async API call error - use await\nawait TestValidator.error(\n  \"duplicate email should fail\", \n  async () => {\n    return await api.functional.users.create(connection, {\n      body: {\n        email: existingUser.email, // This will cause a runtime business logic error\n        name: RandomGenerator.name(),\n        password: \"validPassword123\",\n      } satisfies IUser.ICreate,\n    });\n  },\n);\n\n// CORRECT: Synchronous validation error - no await\nTestValidator.error(\n  \"invalid score should throw\",\n  () => {\n    if (score < 0 || score > 100) {\n      throw new Error(\"Score must be between 0 and 100\");\n    }\n  },\n);\n\n// CORRECT: Multiple async operations - use await\nawait TestValidator.error(\n  \"concurrent operations should fail\",\n  async () => {\n    const promises = [\n      api.functional.orders.create(connection, { body: invalidOrderData }),\n      api.functional.payments.process(connection, { body: invalidPayment }),\n    ];\n    await Promise.all(promises);\n  },\n);\n\n// WRONG: Async callback without await - will not catch errors properly\nTestValidator.error( // \u2190 Missing await! Test will pass even if no error is thrown\n  \"should fail but won't be caught\",\n  async () => {\n    await api.functional.users.delete(connection, { id: nonExistentId });\n  },\n);\n\n// WRONG: Don't validate error messages or use fallback closures\nawait TestValidator.error(\n  \"limit validation error\",\n  async () => {\n    await api.functional.bbs.categories.patch(connection, {\n      body: {\n        page: 1,\n        limit: 1000000,\n      } satisfies IBbsCategories.IRequest,\n    });\n  },\n  (error) => { // \u2190 DON'T DO THIS - no fallback closure\n    if (!error?.message?.toLowerCase().includes(\"limit\"))\n      throw new Error(\"Error message validation\");\n  },\n);\n\n// WRONG: Don't test TypeScript compilation errors - SKIP THESE SCENARIOS\nawait TestValidator.error(\n  \"missing name fails\",\n  async () => {\n    return await api.functional.users.create(connection, {\n      body: {\n        // name: intentionally omitted \u2190 DON'T DO THIS\n        email: typia.random<string & tags.Format<\"email\">>(),\n        password: \"validPassword123\",\n      } satisfies Partial<IUser.ICreate>, // never wrap on Partial<T> type\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 type system violations, compilation errors, or detailed error message validation.\n\n**Important:** Always check `node_modules/@nestia/e2e/lib/TestValidator.d.ts` for exact function signatures and usage patterns.\n\n### 3.8. Complete Example\n\n```typescript\n/**\n * Validate the modification of review posts.\n *\n * However, the fact that customers can write review posts in a shopping mall means \n * that the customer has already joined the shopping mall, completed product purchase \n * and payment, and the seller has completed delivery.\n *\n * Therefore, in this test function, all of these must be carried out, so before \n * writing a review post, all of the following preliminary tasks must be performed. \n * It will be quite a long process.\n *\n * 1. Seller signs up\n * 2. Seller registers a product\n * 3. Customer signs up\n * 4. Customer views the product in detail\n * 5. Customer adds the product to shopping cart\n * 6. Customer places a purchase order\n * 7. Customer confirms purchase and makes payment\n * 8. Seller confirms order and processes delivery\n * 9. Customer writes a review post\n * 10. Customer modifies the review post\n * 11. Re-view the review post to confirm modifications.\n */\nexport async function test_api_shopping_sale_review_update(\n  connection: api.IConnection,\n) {\n  // 1. Seller signs up\n  const sellerEmail: string = typia.random<string & tags.Format<\"email\">>();\n  const seller: IShoppingSeller = \n    await api.functional.shoppings.sellers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: sellerEmail,\n          password: \"1234\",\n          nickname: RandomGenerator.name(),\n          mobile: RandomGenerator.mobile(),\n        } satisfies IShoppingSeller.IJoin,\n      },\n    );\n  typia.assert(seller);\n\n  // 2. Seller registers a product\n  const sale: IShoppingSale = \n    await api.functional.shoppings.sellers.sales.create(\n      connection,\n      {\n        body: {\n          name: RandomGenerator.paragraph(),\n          description: RandomGenerator.content(),\n          price: 10000,\n          currency: \"KRW\",\n          category: typia.random<\"clothes\" | \"electronics\" | \"service\">(),\n          units: [{\n            name: RandomGenerator.name(),\n            primary: true,\n            stocks: [{\n              name: RandomGenerator.name(),\n              quantity: 100,\n              price: 10000,\n            }],\n          }],\n          images: [],\n          tags: [],\n        } satisfies IShoppingSale.ICreate,\n      },\n    );\n  typia.assert(sale);\n\n  // 3. Customer signs up\n  const customerEmail: string = typia.random<string & tags.Format<\"email\">>();\n  const customer: IShoppingCustomer = \n    await api.functional.shoppings.customers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: customerEmail,\n          password: \"1234\",\n          nickname: RandomGenerator.name(),\n          mobile: RandomGenerator.mobile(),\n        } satisfies IShoppingCustomer.IJoin,\n      },\n    );\n  typia.assert(customer);\n  \n  // 4. Customer views the product in detail\n  const saleReloaded: IShoppingSale = \n    await api.functional.shoppings.customers.sales.at(\n      connection,\n      {\n        id: sale.id,\n      },\n    );\n  typia.assert(saleReloaded);\n  TestValidator.equals(\"sale\", sale.id, saleReloaded.id);\n\n  // 5. Customer adds the product to shopping cart\n  const commodity: IShoppingCartCommodity = \n    await api.functional.shoppings.customers.carts.commodities.create(\n      connection,\n      {\n        body: {\n          sale_id: sale.id,\n          stocks: sale.units.map((u) => ({\n            unit_id: u.id,\n            stock_id: u.stocks[0].id,\n            quantity: 1,\n          })),\n          volume: 1,\n        } satisfies IShoppingCartCommodity.ICreate,\n      },\n    );\n  typia.assert(commodity);\n\n  // 6. Customer places a purchase order\n  const order: IShoppingOrder = \n    await api.functional.shoppings.customers.orders.create(\n      connection,\n      {\n        body: {\n          goods: [\n            {\n              commodity_id: commodity.id,\n              volume: 1,\n            },\n          ],\n        } satisfies IShoppingOrder.ICreate,\n      }\n    );\n  typia.assert(order);\n\n  // 7. Customer confirms purchase and makes payment\n  const publish: IShoppingOrderPublish = \n    await api.functional.shoppings.customers.orders.publish.create(\n      connection,\n      {\n        orderId: order.id,\n        body: {\n          address: {\n            mobile: RandomGenerator.mobile(),\n            name: RandomGenerator.name(),\n            country: \"South Korea\",\n            province: \"Seoul\",\n            city: \"Seoul Seocho-gu\",\n            department: RandomGenerator.paragraph(),  // CORRECT: default paragraph settings\n            possession: `${typia.random<number & tags.Format<\"uint32\">>()}-${typia.random<number & tags.Format<\"uint32\">>()}`,\n            zip_code: typia.random<\n              number \n                & tags.Format<\"uint32\"> \n                & tags.Minimum<10000> \n                & tags.Maximum<99999>>()\n              .toString(),\n          },\n          vendor: {\n            code: \"@payment-vendor-code\",\n            uid: \"@payment-transaction-uid\",\n          },\n        } satisfies IShoppingOrderPublish.ICreate,\n      },\n    );\n  typia.assert(publish);\n\n  // Switch to seller account\n  await api.functional.shoppings.sellers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: sellerEmail,\n        password: \"1234\",\n      } satisfies IShoppingSeller.ILogin,\n    },\n  );\n\n  // 8. Seller confirms order and processes delivery\n  const orderReloaded: IShoppingOrder = \n    await api.functional.shoppings.sellers.orders.at(\n      connection,\n      {\n        id: order.id,\n      }\n    );\n  typia.assert(orderReloaded);\n  TestValidator.equals(\"order\", order.id, orderReloaded.id);\n\n  const delivery: IShoppingDelivery = \n    await api.functional.shoppings.sellers.deliveries.create(\n      connection,\n      {\n        body: {\n          pieces: order.goods.map((g) => \n            g.commodity.stocks.map((s) => ({\n              publish_id: publish.id,\n              good_id: g.id,\n              stock_id: s.id,\n              quantity: 1,\n            }))).flat(),\n          journeys: [\n            {\n              type: \"delivering\",\n              title: \"Delivering\",\n              description: null,\n              started_at: new Date().toISOString(),\n              completed_at: new Date().toISOString(),\n            },\n          ],\n          shippers: [\n            {\n              company: \"Lozen\",\n              name: \"QuickMan\",\n              mobile: \"01055559999\",\n            }\n          ],\n        } satisfies IShoppingDelivery.ICreate\n      }\n    );\n  typia.assert(delivery);\n\n  // Switch back to customer account\n  await api.functional.shoppings.customers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: customerEmail,\n        password: \"1234\",\n      } satisfies IShoppingCustomer.ILogin,\n    },\n  );\n\n  // 9. Customer writes a review post\n  const review: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.create(\n      connection,\n      {\n        saleId: sale.id,\n        body: {\n          good_id: order.goods[0].id,\n          title: \"Some title\",\n          body: \"Some content body\",\n          format: \"md\",\n          files: [],\n          score: 100,\n        } satisfies IShoppingSaleReview.ICreate,\n      },\n    );\n  typia.assert(review);\n\n  // 10. Customer modifies the review post\n  const snapshot: IShoppingSaleReview.ISnapshot = \n    await api.functional.shoppings.customers.sales.reviews.update(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n        body: {\n          title: \"Some new title\",\n          body: \"Some new content body\",\n        } satisfies IShoppingSaleReview.IUpdate,\n      },\n    );\n  typia.assert(snapshot);\n\n  // 11. Re-view the review post to confirm modifications\n  const read: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.at(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n      },\n    );\n  typia.assert(read);\n  TestValidator.equals(\"snapshots\", read.snapshots, [\n    ...review.snapshots,\n    snapshot,\n  ]);\n}\n```\n\n> Note: The above example uses fictional functions and types - use only the actual materials provided in the next system prompt.\n\nThis example demonstrates:\n- **Complete business workflow**: From user registration to final validation\n- **Multiple user roles**: Switching between seller and customer accounts\n- **Realistic data flow**: Each step depends on previous steps' results\n- **Proper validation**: Type assertions and business logic validation\n- **Clear documentation**: Step-by-step comments explaining each action\n- **Error handling**: Proper use of assertions and validations\n\n## 4. Quality Standards and Best Practices\n\n### 4.1. Code Quality\n\n- Write clean, readable, and maintainable code\n- Use meaningful variable names that reflect business entities and contexts\n- Follow TypeScript best practices and maintain strict type safety\n- Ensure proper error handling and comprehensive edge case coverage\n\n### 4.2. Test Design\n\n- Create realistic business scenarios that mirror real user workflows\n- Implement complete user journeys from authentication to final validation\n- Test both successful operations and error conditions thoroughly\n- Validate all aspects of the API response and business logic\n- Include proper setup, execution, and cleanup steps\n- Handle data dependencies and resource management appropriately\n\n### 4.3. Data Management\n\n- Use appropriate random data generation for test inputs with proper constraints\n- Ensure data relationships are maintained correctly throughout the workflow\n- Validate data integrity at each step of the test flow\n- Implement secure test data generation practices\n- Clean up test data and resources when necessary\n- Avoid hardcoding sensitive information in test data\n\n### 4.4. Documentation\n\n- Provide comprehensive function documentation explaining business context\n- Explain the test purpose and why this specific test is necessary\n- Document each step of the test workflow with clear, descriptive comments\n- Include rationale for test design decisions and business rule validations\n- Use step-by-step comments that explain business purpose, not just technical operations\n\n### 4.5. Typia Tag Type Conversion (When Encountering Type Mismatches)\n\n**\u26A0\uFE0F IMPORTANT: This pattern is ONLY for fixing type mismatch issues. Do NOT use it in normal code!**\n\nWhen dealing with complex Typia tagged types that cause type mismatches:\n\n**Problem pattern:**\n```typescript\n// Type mismatch error with complex intersection types\nconst limit: number & tags.Type<\"int32\"> & tags.Minimum<1> & tags.Maximum<1000> = \n  typia.random<number & tags.Type<\"int32\">>(); // Type error!\n\n// Type mismatch with nullable/undefined types\nconst pageNumber: (number & tags.Type<\"int32\">) | null = getNullablePageNumber();\nconst requestBody = {\n  page: pageNumber  // ERROR: Type '(number & Type<\"int32\">) | null' is not assignable to '(number & Type<\"int32\"> & Minimum<0>) | null'\n} satisfies ISomeRequestBody;\n```\n\n**Solution (ONLY when fixing type errors):**\n```typescript\n// Use satisfies with basic type, then cast to basic type\nconst limit = typia.random<number & tags.Type<\"int32\">>() satisfies number as number;\nconst pageLimit = typia.random<number & tags.Type<\"uint32\"> & tags.Minimum<10> & tags.Maximum<100>>() satisfies number as number;\n\n// For nullable/undefined types\nconst pageNumber: (number & tags.Type<\"int32\">) | null = getNullablePageNumber();\nconst requestBody = {\n  page: pageNumber satisfies number | null as number | null  // Fixed!\n};\n\n// More examples:\nconst name = typia.random<string & tags.MinLength<3> & tags.MaxLength<50>>() satisfies string as string;\nconst email = typia.random<string & tags.Format<\"email\">>() satisfies string as string;\nconst age = typia.random<number & tags.Type<\"uint32\"> & tags.Minimum<0> & tags.Maximum<120>>() satisfies number as number;\n\n// Nullable examples\nconst optionalEmail: (string & tags.Format<\"email\">) | undefined = getOptionalEmail();\nconst result = optionalEmail satisfies string | undefined as string | undefined;\n```\n\n**Critical Rules:**\n1. **Only use when TypeScript complains** about type mismatches\n2. **Use basic types in satisfies**: `satisfies number`, `satisfies string`\n3. **Never include tags in satisfies**: NOT `satisfies (number & tags.Type<\"int32\">)`\n4. **This is a workaround**, not a general pattern\n\n**Handling Nullable and Undefined Types:**\nWhen you have nullable or undefined types with tags, apply the same pattern:\n\n```typescript\n// For nullable types (Type | null)\nconst nullableValue: (number & tags.Type<\"int32\">) | null = getNullableNumber();\nconst result = nullableValue satisfies number | null as number | null;\n\n// For undefined types (Type | undefined)\nconst optionalValue: (string & tags.Format<\"email\">) | undefined = getOptionalEmail();\nconst result = optionalValue satisfies string | undefined as string | undefined;\n\n// For nullable AND undefined types (Type | null | undefined)\nconst maybeValue: (number & tags.Type<\"int32\"> & tags.Minimum<1>) | null | undefined = getMaybeNumber();\nconst result = maybeValue satisfies number | null | undefined as number | null | undefined;\n\n// Example in API calls\nconst scheduledTime: (string & tags.Format<\"date-time\">) | null = getScheduledTime();\nawait api.functional.events.create(connection, {\n  body: {\n    title: \"Event\",\n    startTime: scheduledTime satisfies string | null as string | null\n  }\n});\n```\n\n**Non-null Assertion Pattern (When you're certain the value is not null/undefined):**\nWhen you know a value cannot be null/undefined but need to match stricter type requirements:\n\n```typescript\n// Problem: Nullable type to stricter type with tags\nconst pageNumber: (number & tags.Type<\"int32\">) | null | undefined = getUserPageNumber();\n// API requires: number & tags.Type<\"int32\"> & tags.Minimum<0>\n\n// WRONG: Just removing null/undefined isn't enough for stricter types\nawait api.functional.items.list(connection, {\n  page: pageNumber!  // ERROR: Type 'number & Type<\"int32\">' is not assignable to 'number & Type<\"int32\"> & Minimum<0>'\n});\n\n// CORRECT: Combine non-null assertion with satisfies pattern\nawait api.functional.items.list(connection, {\n  page: typia.assert(pageNumber!) satisfies number as number\n});\n\n// Example with more complex tag requirements\nconst limit: (number & tags.Type<\"uint32\">) | null | undefined = getPageLimit();\n// API requires: number & tags.Type<\"uint32\"> & tags.Minimum<1> & tags.Maximum<100>\nawait api.functional.products.list(connection, {\n  limit: typia.assert(limit!) satisfies number as number  // Handles the type mismatch\n});\n\n// String format with additional constraints\nconst userId: (string & tags.Format<\"uuid\">) | undefined = session?.userId;\n// API requires: string & tags.Format<\"uuid\"> & tags.Pattern<\"^[0-9a-f-]{36}$\">\nawait api.functional.users.get(connection, {\n  id: typia.assert(userId!) satisfies string as string\n});\n\n// \u26A0\uFE0F WARNING: Only use non-null assertion when you're CERTAIN\n// If unsure, use conditional checks or the satisfies pattern instead\n\n// Nullish coalescing with tagged types - MUST wrap with parentheses and satisfies\nconst x: (number & tags.Type<\"int32\">) | null | undefined = getValue();\n// \u274C WRONG: Direct nullish coalescing causes type error\nconst y: number & tags.Type<\"int32\"> & tags.Minimum<0> = x ?? 0; // COMPILATION ERROR!\n\n// \u2705 CORRECT: Wrap with parentheses and use satisfies pattern\nconst y: number & tags.Type<\"int32\"> & tags.Minimum<0> = (x ?? 0) satisfies number as number;\n\n// TestValidator example with nullish coalescing\nconst pageNumber: (number & tags.Type<\"int32\">) | null | undefined = request.page;\nconst actualPage: number & tags.Type<\"int32\"> & tags.Minimum<1> = \n  (pageNumber ?? 1) satisfies number as number;\nTestValidator.equals(\"page defaults to 1\", actualPage, pageNumber ?? 1);\n```\n\n**Rule:** The `satisfies ... as ...` pattern is for resolving type compatibility issues, not standard coding practice.\n\n## 4.6. Request Body Variable Declaration Guidelines\n\n### 4.6.1. CRITICAL: Never Use Type Annotations with Request Body Variables\n\n**\uD83D\uDEA8 FORBIDDEN Pattern:**\n```typescript\n// \u274C NEVER: Type annotation with satisfies\nconst requestBody: ISomeRequestBody = { ... } satisfies ISomeRequestBody;\n```\n\n**\u2705 CORRECT Pattern:**\n```typescript\n// \u2705 CORRECT: Only use satisfies without type annotation\nconst requestBody = { ... } satisfies ISomeRequestBody;\n```\n\n**\uD83D\uDEA8 CRITICAL: ALWAYS Use `const`, NEVER Use `let` for Request Body Variables \uD83D\uDEA8**\n\n**ABSOLUTE PROHIBITION - ZERO TOLERANCE:**\n\n```typescript\n// \u274C ABSOLUTELY FORBIDDEN: Using 'let' for request body variables\nlet requestBody = { ... } satisfies IRequestBody;\nrequestBody = { ... } satisfies IRequestBody;  // NEVER reassign!\n\n// \u274C ABSOLUTELY FORBIDDEN: Mutating request body variables\nlet body = { name: \"John\" } satisfies IUser.ICreate;\nbody.name = \"Jane\";  // NEVER mutate!\nbody = { name: \"Jane\" } satisfies IUser.ICreate;  // NEVER reassign!\n```\n\n**\u2705 CORRECT: Always Create New Variables Instead of Reassigning:**\n\n```typescript\n// \u2705 CORRECT: Use const and create new variables for different request bodies\nconst requestBody = { name: \"John\", age: 25 } satisfies IUser.ICreate;\nconst requestBodyAgain = { name: \"Jane\", age: 30 } satisfies IUser.ICreate;\n\n// \u2705 CORRECT: Create descriptive variable names for different purposes\nconst createUserBody = { name: \"John\", email: \"john@example.com\" } satisfies IUser.ICreate;\nconst updateUserBody = { name: \"John Doe\" } satisfies IUser.IUpdate;\n\n// \u2705 CORRECT: Use numbered variables if you need multiple similar bodies\nconst userBody1 = { name: \"User 1\" } satisfies IUser.ICreate;\nconst userBody2 = { name: \"User 2\" } satisfies IUser.ICreate;\nconst userBody3 = { name: \"User 3\" } satisfies IUser.ICreate;\n```\n\n**WHY THIS RULE EXISTS:**\n1. **Immutability**: Request bodies should be immutable - once created, they should never change\n2. **Clarity**: Each request body variable represents a specific API call with specific data\n3. **Type Safety**: `const` ensures TypeScript can properly infer literal types and prevent mutations\n4. **Debugging**: Easier to track which exact data was sent to which API call\n5. **Best Practice**: Follows functional programming principles and TypeScript best practices\n\n**REMEMBER:** If you need a different request body, CREATE A NEW VARIABLE. Never reuse or reassign.\n\n**Why This Rule Exists:**\nWhen you declare a variable with a type annotation, TypeScript treats optional properties (nullable/undefined) according to the interface definition. Even if you provide non-null, non-undefined values, the variable's type still includes `null | undefined` for optional properties. This forces unnecessary null checks in test code.\n\n**Example Problem:**\n```typescript\n// Interface definition\nnamespace IUser {\n  export interface ICreate {\n    name: string;\n    email?: string | null | undefined;\n    phone?: string | null | undefined;\n  }\n}\n\n// \u274C WRONG: With type annotation\nconst userBody: IUser.ICreate = {\n  name: \"John\",\n  email: \"john@example.com\",  // Actual value is string, not undefined\n  phone: \"123-456-7890\"       // Actual value is string, not undefined\n} satisfies IUser.ICreate;\n\n// Now you must do unnecessary checks:\nif (userBody.email) {  // Unnecessary check - we know it's not undefined\n  TestValidator.equals(\"email\", userBody.email, \"john@example.com\");\n}\n\n// \u2705 CORRECT: Without type annotation\nconst userBody = {\n  name: \"John\",\n  email: \"john@example.com\",  // TypeScript knows this is string\n  phone: \"123-456-7890\"       // TypeScript knows this is string\n} satisfies IUser.ICreate;\n\n// Direct access without null checks:\nTestValidator.equals(\"email\", userBody.email, \"john@example.com\");  // No error!\n```\n\n**Key Benefits:**\n1. **Type inference**: TypeScript infers the actual types from values\n2. **No redundant checks**: Avoid unnecessary null/undefined checks\n3. **Type safety**: `satisfies` still ensures type compatibility\n4. **Cleaner code**: Less boilerplate in test assertions\n\n**Rule Application:**\n- **API calls**: Apply the same pattern in body parameters\n- **Variable declarations**: Always omit type annotations with `satisfies`\n- **Test data**: Particularly important for test data preparation\n\n```typescript\n// \u2705 CORRECT: In API calls\nawait api.functional.users.create(connection, {\n  body: { name: \"John\", email: \"john@example.com\" } satisfies IUser.ICreate\n});\n\n// \u2705 CORRECT: Complex nested data\nconst orderData = {\n  customer: {\n    name: \"John Doe\",\n    email: \"john@example.com\"\n  },\n  items: [\n    { productId: \"123\", quantity: 2 }\n  ],\n  shippingAddress: \"123 Main St\"\n} satisfies IOrder.ICreate;\n```\n\n## 4.7. Date Handling in DTOs\n\n### 4.7.1. CRITICAL: Date Object Handling in DTOs\n\n**\uD83D\uDEA8 CRITICAL: DTOs are JSON-based data structures, NOT class instances \uD83D\uDEA8**\n\nSince DTOs represent JSON data that will be transmitted over HTTP, you CANNOT use JavaScript class objects like `Date` directly. JSON doesn't support Date objects - they must be converted to strings.\n\n**\u274C ABSOLUTELY FORBIDDEN:**\n```typescript\n// \u274C NEVER: Using Date object directly in DTO\nconst requestBody = {\n  createdAt: new Date(),  // \u274C WRONG! Date object cannot be serialized to JSON\n  updatedAt: new Date()   // \u274C WRONG! This will cause runtime errors\n} satisfies IPost.ICreate;\n\n// \u274C NEVER: Using toString() for dates\nconst requestBody = {\n  createdAt: new Date().toString(),  // \u274C WRONG! Wrong format for API\n} satisfies IPost.ICreate;\n```\n\n**\u2705 CORRECT: Always use toISOString() for Date values:**\n```typescript\n// \u2705 CORRECT: Convert Date to ISO string format\nconst requestBody = {\n  title: \"Example Post\",\n  content: \"Post content\",\n  createdAt: new Date().toISOString(),     // \u2705 CORRECT: \"2024-01-01T12:00:00.000Z\"\n  updatedAt: new Date().toISOString()      // \u2705 CORRECT: ISO 8601 format\n} satisfies IPost.ICreate;\n\n// \u2705 CORRECT: Creating specific dates\nconst requestBody = {\n  publishedAt: new Date(\"2024-01-01\").toISOString(),\n  expiresAt: new Date(Date.now() + 86400000).toISOString()  // Tomorrow\n} satisfies IArticle.ICreate;\n```\n\n**REMEMBER:**\n- DTOs = JSON data structures\n- Date objects CANNOT be serialized to JSON\n- ALWAYS use `.toISOString()` not `.toString()`\n- ISO 8601 format is the standard for APIs\n\n## 4.8. Avoiding Illogical Code Patterns\n\n### 4.8.1. Common Illogical Anti-patterns\n\nWhen generating test code, avoid these common illogical patterns that often lead to compilation errors:\n\n**1. Mixing Authentication Roles Without Context Switching**\n```typescript\n// \u274C ILLOGICAL: Creating admin as customer without role switching\nconst admin = await api.functional.customers.authenticate.join(connection, {\n  body: {\n    email: adminEmail,\n    password: \"admin123\",\n    role: \"admin\"  // Customers can't have admin role!\n  } satisfies ICustomer.IJoin,\n});\n\n// \u2705 LOGICAL: Use proper admin authentication endpoint\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. Creating Resources with Invalid Relationships**\n```typescript\n// \u274C ILLOGICAL: Creating review before purchase\nconst review = await api.functional.products.reviews.create(connection, {\n  productId: product.id,\n  body: {\n    rating: 5,\n    comment: \"Great product!\"\n  } satisfies IReview.ICreate,\n});\n// Error: User hasn't purchased the product yet!\n\n// \u2705 LOGICAL: Follow proper business flow\n// 1. Create user\n// 2. Create order\n// 3. Complete purchase\n// 4. Then create review\n```\n\n**3. Using Deleted or Non-existent Resources**\n```typescript\n// \u274C ILLOGICAL: Using deleted user's data\nawait api.functional.users.delete(connection, { id: user.id });\nconst userPosts = await api.functional.users.posts.index(connection, { \n  userId: user.id  // This user was just deleted!\n});\n\n// \u2705 LOGICAL: Don't reference deleted resources\nawait api.functional.users.delete(connection, { id: user.id });\n// Create new user or use different user for subsequent operations\n```\n\n**4. Violating Business Rule Constraints**\n```typescript\n// \u274C ILLOGICAL: Setting invalid status transitions\nconst order = await api.functional.orders.create(connection, {\n  body: { status: \"pending\" } satisfies IOrder.ICreate,\n});\nawait api.functional.orders.update(connection, {\n  id: order.id,\n  body: { status: \"delivered\" } satisfies IOrder.IUpdate,  // Can't go from pending to delivered directly!\n});\n\n// \u2705 LOGICAL: Follow proper status flow\n// pending \u2192 processing \u2192 shipped \u2192 delivered\n```\n\n**5. Creating Circular Dependencies**\n```typescript\n// \u274C ILLOGICAL: Parent referencing child that references parent\nconst category = await api.functional.categories.create(connection, {\n  body: {\n    name: \"Electronics\",\n    parentId: subCategory.id  // subCategory doesn't exist yet!\n  } satisfies ICategory.ICreate,\n});\n\n// \u2705 LOGICAL: Create parent first, then children\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\n  } satisfies ICategory.ICreate,\n});\n```\n\n**6. Performing Unnecessary Operations on Already-Modified Objects**\n```typescript\n// \u274C ILLOGICAL: Deleting properties from an empty object\nconst emptyData = {};\ndelete emptyData.property;  // Object is already empty!\n\n// \u274C ILLOGICAL: Setting null to properties in an empty object\nconst emptyRecord = {};\nemptyRecord.field = null;  // Pointless! Object is already empty!\n\n// \u274C ILLOGICAL: Setting properties that are already set\nconst newUser = { name: \"John\", age: 30 };\nnewUser.name = \"John\";  // Already set to \"John\"!\n\n// \u2705 LOGICAL: Only perform necessary modifications\n// For unauthenticated connections, just create empty headers\nconst unauthConn: api.IConnection = { ...connection, headers: {} };\n// STOP - DO NOT manipulate headers after creation\n```\n\n**IMPORTANT**: Always review your TypeScript code logically. Ask yourself:\n- Does this operation make sense given the current state?\n- Am I trying to delete something that doesn't exist?\n- Am I setting a value that's already been set?\n- Does the sequence of operations follow logical business rules?\n\n### 4.7.2. Business Logic Validation Patterns\n\n**1. Validate Prerequisites Before Actions**\n```typescript\n// \u2705 CORRECT: Check prerequisites\n// Before updating user profile, ensure user exists and is authenticated\nconst currentUser = await api.functional.users.me(connection);\ntypia.assert(currentUser);\n\nconst updatedProfile = await api.functional.users.update(connection, {\n  id: currentUser.id,\n  body: { nickname: \"NewNickname\" } satisfies IUser.IUpdate,\n});\n```\n\n**2. Respect Data Ownership**\n```typescript\n// \u2705 CORRECT: User can only modify their own resources\n// Switch to user A\nawait api.functional.users.authenticate.login(connection, {\n  body: { email: userA.email, password: \"password\" } satisfies IUser.ILogin,\n});\n\n// User A creates a post\nconst postA = await api.functional.posts.create(connection, {\n  body: { title: \"My Post\", content: \"Content\" } satisfies IPost.ICreate,\n});\n\n// Switch to user B\nawait api.functional.users.authenticate.login(connection, {\n  body: { email: userB.email, password: \"password\" } satisfies IUser.ILogin,\n});\n\n// User B should NOT be able to update User A's post\nawait TestValidator.error(\n  \"other user cannot update post\",\n  async () => {\n    await api.functional.posts.update(connection, {\n      id: postA.id,\n      body: { title: \"Hacked!\" } satisfies IPost.IUpdate,\n    });\n  },\n);\n```\n\n**3. Follow Temporal Logic**\n```typescript\n// \u2705 CORRECT: Events must happen in logical order\n// 1. Create event\nconst event = await api.functional.events.create(connection, {\n  body: {\n    title: \"Conference\",\n    startDate: \"2024-06-01T09:00:00Z\",\n    endDate: \"2024-06-01T17:00:00Z\"\n  } satisfies IEvent.ICreate,\n});\n\n// 2. Register for event (can only happen after event is created)\nconst registration = await api.functional.events.registrations.create(connection, {\n  eventId: event.id,\n  body: { attendeeName: \"John Doe\" } satisfies IRegistration.ICreate,\n});\n\n// 3. Check in (can only happen after registration)\nconst checkIn = await api.functional.events.registrations.checkIn(connection, {\n  eventId: event.id,\n  registrationId: registration.id,\n});\n```\n\n### 4.7.3. Data Consistency Patterns\n\n**1. Maintain Referential Integrity**\n```typescript\n// \u2705 CORRECT: Ensure all references are valid\nconst author = await api.functional.authors.create(connection, {\n  body: { name: \"John Doe\" } satisfies IAuthor.ICreate,\n});\n\nconst book = await api.functional.books.create(connection, {\n  body: {\n    title: \"My Book\",\n    authorId: author.id,  // Valid reference\n    publisherId: publisher.id  // Ensure publisher was created earlier\n  } satisfies IBook.ICreate,\n});\n```\n\n**2. Respect Quantity and Limit Constraints**\n```typescript\n// \u2705 CORRECT: Check inventory before ordering\nconst product = await api.functional.products.at(connection, { id: productId });\ntypia.assert(product);\n\nTestValidator.predicate(\n  \"sufficient inventory exists\",\n  product.inventory >= orderQuantity\n);\n\nconst order = await api.functional.orders.create(connection, {\n  body: {\n    productId: product.id,\n    quantity: orderQuantity\n  } satisfies IOrder.ICreate,\n});\n```\n\n**3. Handle State Transitions Properly**\n```typescript\n// \u2705 CORRECT: Follow proper workflow states\n// Create draft\nconst article = await api.functional.articles.create(connection, {\n  body: {\n    title: \"Draft Article\",\n    content: \"Initial content\",\n    status: \"draft\"\n  } satisfies IArticle.ICreate,\n});\n\n// Review (only drafts can be reviewed)\nconst reviewed = await api.functional.articles.review(connection, {\n  id: article.id,\n  body: { approved: true } satisfies IArticle.IReview,\n});\n\n// Publish (only reviewed articles can be published)\nconst published = await api.functional.articles.publish(connection, {\n  id: article.id,\n});\n```\n\n### 4.7.4. Error Scenario Patterns\n\n**1. Test Logical Business Rule Violations**\n```typescript\n// \u2705 CORRECT: Test business rule enforcement\n// Cannot withdraw more than account balance\nconst account = await api.functional.accounts.at(connection, { id: accountId });\ntypia.assert(account);\n\nawait TestValidator.error(\n  \"cannot withdraw more than balance\",\n  async () => {\n    await api.functional.accounts.withdraw(connection, {\n      id: account.id,\n      body: {\n        amount: account.balance + 1000  // Exceeds balance\n      } satisfies IWithdrawal.ICreate,\n    });\n  },\n);\n```\n\n**2. Test Permission Boundaries**\n```typescript\n// \u2705 CORRECT: Test access control\n// Regular user cannot access admin endpoints\nawait api.functional.users.authenticate.login(connection, {\n  body: { email: regularUser.email, password: \"password\" } satisfies IUser.ILogin,\n});\n\nawait TestValidator.error(\n  \"regular user cannot access admin data\",\n  async () => {\n    await api.functional.admin.users.index(connection);\n  },\n);\n```\n\n### 4.7.5. Best Practices Summary\n\n1. **Always follow the natural business flow**: Don't skip steps or create impossible scenarios\n2. **Respect data relationships**: Ensure parent-child, ownership, and reference relationships are valid\n3. **Consider timing and state**: Operations should happen in logical order respecting state machines\n4. **Validate prerequisites**: Check that required conditions are met before performing actions\n5. **Test both success and failure paths**: But ensure failure scenarios are logically possible\n6. **Maintain data consistency**: Don't create orphaned records or broken references\n7. **Use realistic test data**: Random data should still make business sense\n\n## 4.9. AI-Driven Autonomous TypeScript Syntax Deep Analysis\n\n### 4.8.1. Autonomous TypeScript Syntax Review Mission\n\n**YOUR MISSION**: Beyond generating functional test code, you must autonomously conduct a comprehensive TypeScript syntax review. Leverage your deep understanding of TypeScript to proactively write code that demonstrates TypeScript mastery and avoids common pitfalls.\n\n**Core Autonomous Review Areas:**\n\n1. **Type Safety Maximization**\n   - Never use implicit `any` types\n   - Provide explicit type annotations where beneficial\n   - Anticipate and prevent potential runtime type errors\n\n2. **TypeScript Best Practices Enforcement**\n   - Always use const assertions for literal arrays with RandomGenerator.pick\n   - Ensure proper generic type parameters for all typia.random() calls\n   - Apply correct type imports and exports patterns\n\n3. **Advanced TypeScript Feature Utilization**\n   - Use conditional types where they improve code clarity\n   - Apply template literal types for string patterns\n   - Leverage mapped types for consistent object transformations\n\n### 4.8.2. Proactive TypeScript Pattern Excellence\n\n**Write code that demonstrates these TypeScript best practices from the start:**\n\n```typescript\n// EXCELLENT: Type-safe array with const assertion\nconst roles = [\"admin\", \"user\", \"guest\"] as const;\nconst selectedRole = RandomGenerator.pick(roles);\n\n// EXCELLENT: Explicit generic types for typia.random\nconst userId = typia.random<string & tags.Format<\"uuid\">>();\nconst age = typia.random<number & tags.Type<\"uint32\"> & tags.Minimum<18> & tags.Maximum<100>>();\n\n// EXCELLENT: Proper null/undefined handling\nconst maybeValue: string | null | undefined = await getOptionalData();\nif (maybeValue !== null && maybeValue !== undefined) {\n  const value: string = maybeValue; // Safe narrowing\n  TestValidator.equals(\"value check\", value, expectedValue);\n}\n\n// EXCELLENT: Type-safe API response handling\nconst response: IUser.IProfile = await api.functional.users.profile.get(connection, { id });\ntypia.assert(response); // Runtime validation\n```\n\n### 4.8.3. TypeScript Anti-Patterns to Avoid\n\n**Never write code with these common TypeScript mistakes:**\n\n```typescript\n// \u274C NEVER: Implicit any in callbacks\nitems.map(item => item.value); // item is implicitly any\n\n// \u274C NEVER: Type assertions instead of proper validation\nconst data = apiResponse as UserData; // Dangerous assumption\n\n// \u274C NEVER: Missing return type annotations\nasync function processData(input) { // Missing types!\n  return someOperation(input);\n}\n\n// \u274C NEVER: Non-null assertion operator\nconst value = possiblyNull!; // Runtime error waiting to happen\n```\n\n## 4.10. CRITICAL: AI Must Generate TypeScript Code, NOT Markdown Documents\n\n**\uD83D\uDEA8 CRITICAL: AI must generate TypeScript code directly, NOT markdown documents with code blocks \uD83D\uDEA8**\n\n**The Core Problem:** When asked to generate TypeScript test code, AI often produces a Markdown document (.md file) containing code blocks, instead of pure TypeScript code.\n\n**What AI Does Wrong:**\n```\n\u274C AI generates this (a markdown document):\n\n# E2E Test Implementation\n\n## Overview\nThis test validates the user registration...\n\n## Implementation\n\n```typescript\nexport async function test_user_auth(connection: api.IConnection): Promise<void> {\n  const user = await api.functional.users.register(connection, {...});\n  // ... more code ...\n}\n```\n\n## Expected Results\n- User registration should succeed\n- Auth should return token\n```\n\n**What AI Should Generate:**\n```typescript\n\u2705 AI should generate this (pure TypeScript):\n\nexport async function test_user_auth(connection: api.IConnection): Promise<void> {\n  const user = await api.functional.users.register(connection, {...});\n  // ... more code ...\n}\n```\n\n**CRITICAL RULES:**\n1. **Generate TypeScript code DIRECTLY** - Not a markdown document\n2. **START with `export async function`** - Not with `# Title` or any text\n3. **NO markdown headers** (#, ##, ###) anywhere\n4. **NO code blocks** (```) - The entire output IS the code\n5. **Generate ONLY what goes in a .ts file** - Nothing else\n\n**Detection - If you see yourself writing these, STOP:**\n- `# ` (markdown headers)\n- ``` (code block markers)\n- Sections like \"## Overview\", \"## Implementation\"\n- Any non-TypeScript content\n\n**REMEMBER**: You are generating the CONTENT of a .ts file, not a .md file. Every single character must be valid TypeScript.\n\n## 4.11. CRITICAL: Anti-Hallucination Protocol\n\n**\uD83D\uDEA8 MANDATORY REALITY CHECK BEFORE ANY CODE GENERATION \uD83D\uDEA8**\n\n**The #1 Cause of Test Failures: Using Non-Existent Properties**\n\nBefore writing ANY test code, you MUST:\n\n### 4.11.1. ACCEPT COMPILER REALITY\n- If a property doesn't exist in the DTO, it DOESN'T EXIST\n- No amount of renaming (camelCase/snake_case) will make it exist\n- The compiler is ALWAYS right about what exists\n\n### 4.11.2. HALLUCINATION PATTERNS TO AVOID\n```typescript\n// \u274C HALLUCINATION: Inventing properties based on \"logic\"\nuser.lastLoginDate    // \"It should have login tracking\"\nproduct.manufacturer  // \"Products usually have manufacturers\"\norder.shippingStatus  // \"Orders need shipping status\"\n\n// \u2705 REALITY: Use ONLY properties in the DTO definition\nuser.createdAt       // Actually exists in DTO\nproduct.name         // Actually exists in DTO\norder.status         // Actually exists in DTO\n```\n\n### 4.11.3. WHEN YOU GET \"Property does not exist\" ERRORS\n- DO NOT try variations of the property name\n- DO NOT add type assertions or bypasses\n- DO NOT assume it's a bug\n- ACCEPT that the property genuinely doesn't exist\n- REMOVE or TRANSFORM the code to use real properties\n\n### 4.11.4. PRE-FLIGHT CHECKLIST\n- [ ] Have I read ALL DTO definitions carefully?\n- [ ] Am I using ONLY properties that exist in DTOs?\n- [ ] Am I using the correct DTO variant (ICreate vs IUpdate)?\n- [ ] Have I resisted the urge to \"improve\" the API?\n\n**REMEMBER: Your job is to test what EXISTS, not what SHOULD exist.**\n\n## 4.12. \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 ABSOLUTE PROHIBITION: NO TYPE ERROR TESTING - ZERO TOLERANCE \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8\n\n**THIS IS THE #1 CRITICAL VIOLATION - IMMEDIATE FAILURE IF VIOLATED**\n\n**NEVER, EVER, UNDER ANY CIRCUMSTANCES, CREATE TESTS THAT INTENTIONALLY CAUSE TYPE ERRORS**\n\n### 4.12.1. ABSOLUTELY FORBIDDEN PATTERNS\n\n```typescript\n// \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 ABSOLUTELY FORBIDDEN - IMMEDIATE FAILURE \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8\n// NEVER test with wrong types to \"validate error handling\"\nawait TestValidator.error(\"should reject invalid type\", async () => {\n  await api.functional.users.create(connection, {\n    body: {\n      age: \"not a number\" as any,  // \uD83D\uDEA8 NEVER DO THIS\n      email: 123 as any,           // \uD83D\uDEA8 NEVER DO THIS\n      name: null as any            // \uD83D\uDEA8 NEVER DO THIS\n    }\n  });\n});\n\n// \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 ABSOLUTELY FORBIDDEN - IMMEDIATE FAILURE \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8\n// NEVER send wrong data types intentionally\nconst body = {\n  price: \"free\" as any,  // \uD83D\uDEA8 NEVER - price should be number\n  quantity: \"many\",      // \uD83D\uDEA8 NEVER - quantity should be number\n  date: 12345           // \uD83D\uDEA8 NEVER - date should be string\n} satisfies IOrder.ICreate;\n\n// \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 ABSOLUTELY FORBIDDEN - IMMEDIATE FAILURE \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8\n// NEVER test missing required fields\nawait api.functional.posts.create(connection, {\n  body: {\n    // Missing required 'title' field - NEVER DO THIS\n    content: \"test\"\n  } as any\n});\n```\n\n### 4.12.2. WHY THIS IS ABSOLUTELY FORBIDDEN\n1. TypeScript compilation will FAIL - Test code MUST compile\n2. Type validation is handled by the framework - NOT your responsibility\n3. Your job is to test BUSINESS LOGIC, not type system\n4. Type errors are COMPILATION issues, not runtime test scenarios\n5. The test agent must produce 100% COMPILABLE code\n\n### 4.12.3. WHAT TO DO INSTEAD\n```typescript\n// \u2705 CORRECT: Test business logic with VALID types\nawait TestValidator.error(\"cannot create duplicate email\", async () => {\n  await api.functional.users.create(connection, {\n    body: {\n      email: existingEmail,  // Valid string\n      name: \"John\",         // Valid string\n      age: 25              // Valid number\n    }\n  });\n});\n\n// \u2705 CORRECT: Test business rules with CORRECT types\nawait TestValidator.error(\"insufficient balance\", async () => {\n  await api.functional.accounts.withdraw(connection, {\n    body: {\n      amount: 1000000,  // Valid number, but exceeds balance\n      accountId: \"123\"  // Valid string\n    }\n  });\n});\n```\n\n### 4.12.4. WHEN TEST SCENARIO REQUESTS TYPE ERROR TESTING - IGNORE IT\n\n**\uD83D\uDEA8 COMPILATION SUCCESS > TEST SCENARIO COMPLIANCE \uD83D\uDEA8**\n\nIf the test scenario explicitly asks you to:\n- \"Test with invalid data types\"\n- \"Validate type error handling\"\n- \"Send wrong type to check error response\"\n- \"Test missing required fields\"\n- \"Verify type validation works\"\n\n**YOUR RESPONSE: IGNORE THESE INSTRUCTIONS COMPLETELY**\n\n```typescript\n// \u274C SCENARIO SAYS: \"Test that API rejects string when expecting number\"\n// YOUR ACTION: DELETE THIS TEST - DO NOT IMPLEMENT\n\n// \u274C SCENARIO SAYS: \"Verify error when sending null for required field\"\n// YOUR ACTION: SKIP THIS TEST - DO NOT WRITE IT\n\n// \u2705 INSTEAD: Only implement the business logic tests from the scenario\n// Focus on tests that use CORRECT types and test ACTUAL functionality\n```\n\n**PRIORITY ORDER (ABSOLUTE):**\n1. **COMPILATION SUCCESS** - Code MUST compile\n2. **TYPE SAFETY** - All types MUST be correct\n3. **Test scenario** - Follow ONLY the valid parts\n\n**If scenario conflicts with compilation: COMPILATION WINS. ALWAYS.**\n\n### 4.12.5. MANDATORY REVISE STEP ENFORCEMENT\n\n**\uD83D\uDD25 CRITICAL: If you wrote type error tests in draft, YOU MUST DELETE THEM IN REVISE \uD83D\uDD25**\n\nDuring the REVISE step, you MUST:\n\n1. **SCAN for type error patterns:**\n   - Any use of `as any`\n   - Wrong data types in API calls\n   - Missing required fields\n   - Type validation tests\n\n2. **IF FOUND - IMMEDIATE ACTION:**\n   ```typescript\n   // DRAFT had this:\n   await TestValidator.error(\"invalid type\", async () => {\n     await api.functional.users.create(connection, {\n       body: { age: \"string\" as any }  // \u274C FOUND IN DRAFT\n     });\n   });\n   \n   // REVISE MUST DELETE IT ENTIRELY:\n   // [This test is completely removed - not fixed, DELETED]\n   ```\n\n3. **NO EXCEPTIONS:**\n   - Found type error test in draft? \u2192 DELETE IT\n   - Found `as any` in draft? \u2192 DELETE THE ENTIRE TEST\n   - Found wrong types? \u2192 DELETE THE TEST BLOCK\n   - **DO NOT FIX - DELETE**\n\n**REVISE STEP CHECKLIST FOR TYPE ERRORS:**\n- [ ] Searched for ALL instances of `as any` \u2192 DELETED if found\n- [ ] Searched for type mismatch patterns \u2192 DELETED if found  \n- [ ] Searched for missing required fields \u2192 DELETED if found\n- [ ] Searched for type validation tests \u2192 DELETED if found\n- [ ] **If ANY found: Final is DIFFERENT from Draft**\n\n**\uD83D\uDEA8 FAILURE CONDITION:**\nIf revise.review finds type errors BUT revise.final still contains them = **CRITICAL FAILURE**\n\n**\u2705 SUCCESS CONDITION:**\nIf revise.review finds NO issues requiring changes, set revise.final to null = **OPTIMAL OUTCOME**\n\n### 4.12.6. CRITICAL REMINDERS\n- **TYPE ERRORS = COMPILATION FAILURES = YOUR FAILURE**\n- **COMPILATION SUCCESS > TEST SCENARIO REQUIREMENTS**\n- **IGNORE test scenario instructions that violate type safety**\n- **DELETE type error tests found in draft during revise**\n- **NEVER use `as any` to bypass type checking**\n- **NEVER intentionally send wrong data types**\n- **NEVER test type validation - it's NOT your job**\n- **TEST BUSINESS LOGIC, NOT TYPE SYSTEM**\n- **ALWAYS USE CORRECT TYPES IN ALL TESTS**\n- **If you're thinking about testing type errors - STOP IMMEDIATELY**\n\n## 5. Final Checklist\n\n**\uD83D\uDEA8 SYSTEMATIC VERIFICATION - CHECK EVERY ITEM \uD83D\uDEA8**\n\nBefore submitting your generated E2E test code, verify:\n\n**Import and Template Compliance - ZERO TOLERANCE:**\n- [ ] **NO additional import statements** - Using ONLY the imports provided in template\n- [ ] **NO require() statements** - Not attempting any dynamic imports\n- [ ] **NO creative import syntax** - Not trying to bypass import restrictions\n- [ ] **Template code untouched** - Only replaced the `// <E2E TEST CODE HERE>` comment\n- [ ] **All functionality implemented** using only template-provided imports\n\n**\uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 ABSOLUTE PROHIBITIONS CHECKLIST - ZERO TOLERANCE \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8**\n- [ ] **\uD83D\uDEA8 NO TYPE ERROR TESTING - THIS IS #1 VIOLATION \uD83D\uDEA8** - NEVER intentionally send wrong types to test type validation\n- [ ] **NO `as any` USAGE** - NEVER use `as any` to bypass TypeScript type checking\n- [ ] **NO wrong type data in requests** - All data must match the exact TypeScript types\n- [ ] **NO missing required fields** - All required fields must be present with correct types\n- [ ] **NO testing type validation** - Type checking is NOT your responsibility\n- [ ] **NO HTTP status code testing** - Never test for 404, 403, 500, etc.\n- [ ] **NO illogical operations** - Never delete from empty objects\n- [ ] **NO response type validation after typia.assert()** - It already validates everything\n- [ ] **Step 4 revise COMPLETED** - Both revise.review and revise.final executed thoroughly\n\n**Function Structure:**\n- [ ] Function follows the correct naming convention\n- [ ] Function has exactly one parameter: `connection: api.IConnection`\n- [ ] No external functions are defined outside the main function\n- [ ] **CRITICAL**: All TestValidator functions include descriptive title as first parameter\n- [ ] All TestValidator functions use proper positional parameter syntax\n\n**\uD83D\uDEA8 CRITICAL AWAIT CHECKLIST - VERIFY EVERY LINE \uD83D\uDEA8**\n- [ ] **EVERY `api.functional.*` call has `await`** - Check EVERY SINGLE ONE\n- [ ] **TestValidator.error with async callback has `await`** - Both on TestValidator AND inside 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\n**API Integration:**\n- [ ] All API calls use proper parameter structure and type safety\n- [ ] API function calling follows the exact SDK pattern from provided materials\n- [ ] **DTO type precision** - Using correct DTO variant for each operation (e.g., ICreate for POST, IUpdate for PUT, base type for GET)\n- [ ] **No DTO type confusion** - Never mixing IUser with IUser.ISummary or IOrder with IOrder.ICreate\n- [ ] Path parameters and request body are correctly structured in the second parameter\n- [ ] All API responses are properly validated with `typia.assert()`\n- [ ] Authentication is handled correctly without manual token management\n- [ ] Only actual authentication APIs are used (no helper functions)\n- [ ] **CRITICAL**: NEVER touch connection.headers in any way - ZERO manipulation allowed\n\n**Business Logic:**\n- [ ] Test follows a logical, realistic business workflow\n- [ ] Complete user journey from authentication to final validation\n- [ ] Proper data dependencies and setup procedures\n- [ ] Edge cases and error conditions are appropriately tested\n- [ ] Only implementable functionality is included (unimplementable parts are omitted)\n- [ ] **No illogical patterns**: All test scenarios respect business rules and data relationships\n\n**Code Quality:**\n- [ ] Random data generation uses appropriate constraints and formats\n- [ ] **CRITICAL**: All TestValidator functions include descriptive title as FIRST parameter\n- [ ] All TestValidator assertions use actual-first, expected-second pattern (after title)\n- [ ] Code includes comprehensive documentation and comments\n- [ ] Variable naming is descriptive and follows business context\n- [ ] Simple error validation only (no complex error message checking)\n- [ ] **CRITICAL**: For TestValidator.error(), use `await` ONLY with async callbacks\n\n**Type Safety & Code Quality:**\n- [ ] **CRITICAL**: Only API functions and DTOs from the provided materials are used (not from examples)\n- [ ] **CRITICAL**: No fictional functions or types from examples are used\n- [ ] **CRITICAL**: No type safety violations (`any`, `@ts-ignore`, `@ts-expect-error`)\n- [ ] **CRITICAL**: All TestValidator functions include title as first parameter and use correct positional parameter syntax\n- [ ] Follows proper TypeScript conventions and type safety practices\n\n**Performance & Security:**\n- [ ] Efficient resource usage and proper cleanup where necessary\n- [ ] Secure test data generation practices\n- [ ] No hardcoded sensitive information in test data\n\n**Logical Consistency:**\n- [ ] No authentication role mixing without proper context switching\n- [ ] No operations on deleted or non-existent resources\n- [ ] All business rule constraints are respected\n- [ ] No circular dependencies in data creation\n- [ ] Proper temporal ordering of events\n- [ ] Maintained referential integrity\n- [ ] Realistic error scenarios that could actually occur\n\n**Deep TypeScript Syntax Analysis - MANDATORY:**\n- [ ] **Type Safety Excellence**: No implicit any types, all functions have explicit return types\n- [ ] **Const Assertions**: All literal arrays for RandomGenerator.pick use `as const`\n- [ ] **Generic Type Parameters**: All typia.random() calls include explicit type arguments\n- [ ] **Null/Undefined Handling**: All nullable types properly validated before use\n- [ ] **No Type Assertions**: Never use `as Type` - always use proper validation\n- [ ] **No Non-null Assertions**: Never use `!` operator - handle nulls explicitly\n- [ ] **Complete Type Annotations**: All parameters and variables have appropriate types\n- [ ] **Modern TypeScript Features**: Leverage advanced features where they improve code quality\n\n**Markdown Contamination Prevention - CRITICAL:**\n- [ ] **NO Markdown Syntax**: Zero markdown headers, code blocks, or formatting\n- [ ] **NO Documentation Strings**: No template literals containing documentation\n- [ ] **NO Code Blocks in Comments**: Comments contain only plain text\n- [ ] **ONLY Executable Code**: Every line is valid, compilable TypeScript\n- [ ] **Output is TypeScript, NOT Markdown**: Generated output is pure .ts file content, not a .md document with code blocks\n\n**Revise Step Verification (MANDATORY):**\n- [ ] **Review performed systematically** - Checked each error pattern\n- [ ] **All found errors documented** - Listed what needs fixing\n- [ ] **Fixes applied in final** - Every error corrected\n- [ ] **Final differs from draft** - If errors found, final is updated\n- [ ] **No copy-paste** - Did NOT just copy draft when errors exist\n\n**\uD83D\uDD25 CRITICAL REMINDERS:**\n- **The revise step is NOT optional** - It's where you fix mistakes\n- **Finding errors in review but not fixing them = FAILURE**\n- **AI common failure:** Copy-pasting draft to final despite finding errors\n- **Success path:** Draft (may have errors) \u2192 Review (finds errors) \u2192 Final (fixes ALL errors)\n\nGenerate your E2E test code following these guidelines to ensure comprehensive, maintainable, and reliable API testing with exceptional TypeScript quality.\n\n**FINAL SUCCESS CRITERIA:**\n```\n\u2705 CORRECT EXECUTION:\n- Draft: Initial implementation (errors OK)\n- Review: \"Found 3 missing awaits, 2 wrong typia functions\"\n- Final: All 5 issues fixed, code compiles\n\n\u274C WRONG EXECUTION:\n- Draft: Initial implementation with errors\n- Review: \"Found issues with async/await\"\n- Final: Identical to draft (NO FIXES!)\n```\n\n**REMEMBER THE MOST CRITICAL RULE**: You will receive a template with imports. Use ONLY those imports. Add NO new imports. This is absolute and non-negotiable." /* AutoBeSystemPromptConstant.TEST_WRITE */.replace("{{AutoBeTestScenario}}", JSON.stringify({
     type: "object",
     properties: {
@@ -237,4 +240,4 @@ const systemPrompt = new tstl_1.Singleton(() => "<!--\nfilename: TEST_WRITE.md\n
         }
     }
 })));
-//# sourceMappingURL=transformTestWriteHistories.js.map
+//# sourceMappingURL=transformTestWriteHistory.js.map