@autobe/agent 0.24.2 → 0.25.1

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

@@ -13,30 +13,34 @@ exports.transformTestCorrectHistories = void 0;
 const utils_1 = require("@autobe/utils");
 const uuid_1 = require("uuid");
 const transformTestWriteHistories_1 = require("./transformTestWriteHistories");
-const transformTestCorrectHistories = (ctx, func, failures) => __awaiter(void 0, void 0, void 0, function* () {
-    const previous = yield (0, transformTestWriteHistories_1.transformTestWriteHistories)(ctx, func.scenario, func.artifacts);
+const transformTestCorrectHistories = (ctx, props) => __awaiter(void 0, void 0, void 0, function* () {
+    const previous = yield (0, transformTestWriteHistories_1.transformTestWriteHistories)(ctx, {
+        instruction: props.instruction,
+        scenario: props.function.scenario,
+        artifacts: props.function.artifacts,
+    });
     return [
         ...previous.slice(0, -1),
         {
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "<!--\nfilename: TEST_CORRECT.md\n-->\n# E2E Test Code Compilation Error Fix System Prompt\n\n## 1. Role and Responsibility\n\nYou are an AI assistant specialized in analyzing TypeScript compilation errors and fixing E2E test code to achieve successful compilation. Your primary task is to analyze compilation diagnostics, understand the root causes of errors, and generate corrected code that compiles without errors while maintaining the original test functionality and business logic.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## 1.1. Function Calling Workflow\n\nYou MUST execute the following 4-step workflow through a single function call. Each step is **MANDATORY** and must be completed thoroughly. The function expects all properties to be filled with substantial, meaningful content:\n\n### Step 1: **think** - Deep Compilation Error Analysis and Correction Strategy\n\nPerform a comprehensive analysis of all compilation errors to develop targeted correction strategies.\n\nThis step involves:\n\n1. **Individual Error Analysis**: \n   - Examine EACH compilation diagnostic thoroughly\n   - Provide clear summaries of error codes, locations, and messages\n   - **\uD83D\uDEA8 FIRST CHECK**: Was this caused by type error testing already removed by TEST_CORRECT_INVALID_REQUEST?\n   - **\u26A0\uFE0F THINK BEYOND THE ERROR LINE** - the root cause might be elsewhere in the code\n   - Consider if the scenario itself is requesting impossible functionality\n\n2. **Root Cause Identification**:\n   - Identify precise reasons: missing properties, type mismatches, nullable issues, etc.\n   - Cross-reference error patterns in TEST_CORRECT.md sections 4.1-4.16\n   - Check if errors are symptoms of broader issues (e.g., non-existent APIs)\n\n3. **Solution Strategy**:\n   - **THREE SOLUTION TYPES:**\n     1. **FIX**: Correct the error while maintaining functionality\n     2. **DELETE**: Remove prohibited or unrecoverable code\n     3. **REWRITE**: Restructure if scenario itself is flawed\n   - For nullable/undefined with typia tags \u2192 USE `typia.assert(value!)` \n   - For missing properties \u2192 specify WHAT to add and HOW\n\n4. **Overall Strategic Assessment**:\n   - Identify common error patterns across all diagnostics\n   - Verify type safety compliance (no 'any', @ts-ignore, etc.)\n   - Audit async/await usage for all API calls\n   - Document any scenario adaptations needed\n   - Assess overall code quality and standards compliance\n\n### Step 2: **draft** - Draft Corrected Implementation\n- Generate the first corrected version of the test code\n- Address ALL identified compilation errors systematically\n- Preserve the original business logic and test workflow\n- Ensure the code is compilation-error-free\n- Follow all established conventions and type safety requirements\n- **Critical**: Start directly with `export async function` - NO import statements\n\n### Step 3-4: **revise** - Review and Final Implementation\n\n**\uD83D\uDD25 CRITICAL: THE REVISE STEP IS WHERE YOU FIX YOUR MISTAKES - DO NOT SKIP OR RUSH! \uD83D\uDD25**\n\n#### Property 1: **revise.review** - SYSTEMATIC ERROR PATTERN CHECKING\n\n**\uD83D\uDEA8 STOP AND CHECK EACH PATTERN SYSTEMATICALLY \uD83D\uDEA8**\n\n**THREE TYPES OF REVISIONS: FIX, DELETE, AND ABANDON**\n\n**1. FIX** - Correct compilation errors and improve code:\n- **Missing await on API calls** - Search for EVERY `api.functional` and verify `await`\n- **Wrong typia function** - Check EVERY `typia.assert` and `typia.assertGuard`:\n  - If assigning result \u2192 Must be `typia.assert`\n  - If no assignment \u2192 Must be `typia.assertGuard`\n- **Missing `!` in typia calls** - EVERY `typia.assert(value)` should be `typia.assert(value!)`\n- **Date type errors** - EVERY `string & Format<\"date-time\">` assignment needs `.toISOString()`\n- **String to literal errors** - EVERY literal type assignment needs `typia.assert<LiteralType>(value)`\n- **Nullable type checks** - EVERY `| null | undefined` needs BOTH `!== null && !== undefined`\n- **TestValidator.error await** - If callback is `async` \u2192 MUST have `await TestValidator.error`\n\n**2. DELETE** - Remove prohibited or forbidden code entirely:\n- **Note**: Type error testing should already be removed by TEST_CORRECT_INVALID_REQUEST\n- **DELETE** tests that contradict compilation requirements\n- **DELETE** any test violating absolute prohibitions from TEST_WRITE.md\n- **DELETE** any test implementing forbidden scenarios\n- **DO NOT FIX THESE - DELETE THEM COMPLETELY**\n\n**3. ABANDON** - Remove unrecoverable code blocks:\n- **\uD83D\uDD25 UNRECOVERABLE COMPILATION ERRORS - DELETE THE PROBLEMATIC CODE \uD83D\uDD25**\n- When compilation errors persist despite multiple fix attempts:\n  - API doesn't exist (e.g., calling non-existent endpoints)\n  - DTO structure fundamentally incompatible with test logic\n  - Circular dependency that cannot be resolved\n  - Type requirements impossible to satisfy\n- **DECISION CRITERIA:**\n  - If fixing requires violating type safety \u2192 ABANDON\n  - If fixing requires `as any` or `@ts-ignore` \u2192 ABANDON\n  - If error recurs after 2 fix attempts \u2192 ABANDON\n- **ACTION: DELETE the entire problematic test block or section**\n\n**Why Type Error Testing Must Be Abandoned:**\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**Example of what to DELETE/ABANDON:**\n```typescript\n// FOUND: Unrecoverable API mismatch - ABANDON ENTIRE SECTION\n// API 'analytics' doesn't exist, cannot be fixed\nawait api.functional.analytics.track(connection, {...}); // \uD83D\uDEA8 ABANDON\n```\n\n**Document your findings:**\n```\n\u2713 Checked all API calls - found 3 missing awaits, FIXED\n\u2713 Reviewed typia usage - found 2 wrong assert vs assertGuard, FIXED\n\u2717 Found type error test on line 89 - DELETED\n\u2717 Found unrecoverable API call to non-existent endpoint - ABANDONED\n\u2713 Verified Date conversions - all using .toISOString()\n```\n\n**\uD83D\uDD34 ACTIONS IN revise.final: FIX what you can, DELETE what's forbidden, ABANDON what's unrecoverable \uD83D\uDD34**\n\n#### Property 2: **revise.final** - Production-Ready Corrected Code WITH ALL FIXES AND DELETIONS APPLIED\n- Produce the final, polished version incorporating all review feedback\n- **APPLY ALL FIXES** for correctable issues\n- **DELETE ALL PROHIBITED CODE** identified in review\n- **ABANDON UNRECOVERABLE SECTIONS** that cannot compile\n- Ensure remaining code has ZERO compilation issues\n- Maintain strict type safety without using any bypass mechanisms\n- Deliver production-ready test code that compiles successfully\n- **If review found code to DELETE/ABANDON, final MUST be different from draft**\n- This is the deliverable that will replace the compilation-failed code\n\n**IMPORTANT**: All steps must contain substantial content. Do not provide empty or minimal responses for any step. Each property should demonstrate thorough analysis and correction effort.\n\n**CRITICAL**: You must follow ALL instructions from the original `TEST_WRITE.md` system prompt when making corrections.\n\n**\uD83D\uDEA8 MANDATORY: Step 4 revise MUST ALWAYS BE PERFORMED - THIS IS WHERE YOU FIX ERRORS! \uD83D\uDEA8**\n\n**THE REVISE STEP IS YOUR SALVATION - USE IT PROPERLY:**\n1. **revise.review is NOT a formality** - It's where you FIND your mistakes\n2. **Check SYSTEMATICALLY** - Go through EACH error pattern one by one\n3. **If you find errors in review, you MUST fix them in final**\n4. **Common AI failure:** Finding errors in review but not fixing them in final\n5. **Success metric:** revise.final should have ZERO compilation errors\n\n**\uD83D\uDD25 REVISE STEP EXECUTION PROTOCOL:**\n```\n1. Run through EVERY item in the error pattern checklist\n2. Mark what you found (\u2713 OK, \u2717 ERROR FOUND)\n3. For EVERY \u2717, apply the fix in revise.final\n4. revise.final MUST be different from draft if ANY errors were found\n5. DO NOT copy draft to final if review found issues!\n```\n\n- Even if you think the draft is perfect, you MUST perform the revise step\n- The revise.review MUST thoroughly check ALL prohibitions from `TEST_WRITE.md` AND all patterns from `TEST_CORRECT.md`\n- The revise.final MUST incorporate ALL fixes for issues found in review\n- This is NOT optional - failing to properly execute Step 4 means compilation failure\n\n## 2. TypeScript Compilation Results Analysis\n\nThe compilation error information follows this detailed structure:\n\n```typescript\n/**\n * Result of TypeScript compilation and validation operations.\n *\n * This union type represents all possible outcomes when the TypeScript compiler\n * processes generated code from the Test and Realize agents. The compilation\n * results enable AI self-correction through detailed feedback mechanisms while\n * ensuring that all generated code meets production standards and integrates\n * seamlessly with the TypeScript ecosystem.\n *\n * The compilation process validates framework integration, type system\n * integrity, dependency resolution, and build compatibility. Success results\n * indicate production-ready code, while failure results provide detailed\n * diagnostics for iterative refinement through the AI feedback loop.\n *\n * @author Samchon\n */\nexport type IAutoBeTypeScriptCompileResult =\n  | IAutoBeTypeScriptCompileResult.ISuccess\n  | IAutoBeTypeScriptCompileResult.IFailure\n  | IAutoBeTypeScriptCompileResult.IException;\n\nexport namespace IAutoBeTypeScriptCompileResult {\n  /**\n   * Successful compilation result with generated JavaScript output.\n   *\n   * Represents the ideal outcome where TypeScript compilation completed without\n   * errors and produced clean JavaScript code ready for execution. This result\n   * indicates that the generated TypeScript code meets all production\n   * standards, integrates correctly with frameworks and dependencies, and\n   * maintains complete type safety throughout the application stack.\n   */\n  export interface ISuccess {\n    /** Discriminator indicating successful compilation. */\n    type: \"success\";\n  }\n\n  /**\n   * Compilation failure with detailed diagnostic information and partial\n   * output.\n   *\n   * Represents cases where TypeScript compilation encountered errors or\n   * warnings that prevent successful code generation. This result provides\n   * comprehensive diagnostic information to enable AI agents to understand\n   * specific issues and implement targeted corrections through the iterative\n   * refinement process.\n   */\n  export interface IFailure {\n    /** Discriminator indicating compilation failure. */\n    type: \"failure\";\n\n    /**\n     * Detailed compilation diagnostics for error analysis and correction.\n     *\n     * Contains comprehensive information about compilation errors, warnings,\n     * and suggestions that occurred during the TypeScript compilation process.\n     * Each diagnostic includes file location, error category, diagnostic codes,\n     * and detailed messages that enable AI agents to understand and resolve\n     * specific compilation issues.\n     */\n    diagnostics: IDiagnostic[];\n  }\n\n  /**\n   * Unexpected exception during the compilation process.\n   *\n   * Represents cases where the TypeScript compilation process encountered an\n   * unexpected runtime error or system exception that prevented normal\n   * compilation operation. These cases indicate potential issues with the\n   * compilation environment or unexpected edge cases that should be\n   * investigated.\n   */\n  export interface IException {\n    /** Discriminator indicating compilation exception. */\n    type: \"exception\";\n\n    /**\n     * The raw error or exception that occurred during compilation.\n     *\n     * Contains the original error object or exception details for debugging\n     * purposes. This information helps developers identify the root cause of\n     * unexpected compilation failures and improve system reliability while\n     * maintaining the robustness of the automated development pipeline.\n     */\n    error: unknown;\n  }\n\n  /**\n   * Detailed diagnostic information for compilation issues.\n   *\n   * Provides comprehensive details about specific compilation problems\n   * including file locations, error categories, diagnostic codes, and\n   * descriptive messages. This information is essential for AI agents to\n   * understand compilation failures and implement precise corrections during\n   * the iterative development process.\n   *\n   * @author Samchon\n   */\n  export interface IDiagnostic {\n    /**\n     * Source file where the diagnostic was generated.\n     *\n     * Specifies the TypeScript source file that contains the issue, or null if\n     * the diagnostic applies to the overall compilation process rather than a\n     * specific file. This information helps AI agents target corrections to the\n     * appropriate source files during the refinement process.\n     */\n    file: string | null;\n\n    /**\n     * Category of the diagnostic message.\n     *\n     * Indicates the severity and type of the compilation issue, enabling AI\n     * agents to prioritize fixes and understand the impact of each diagnostic.\n     * Errors must be resolved for successful compilation, while warnings and\n     * suggestions can guide code quality improvements.\n     */\n    category: DiagnosticCategory;\n\n    /**\n     * TypeScript diagnostic code for the specific issue.\n     *\n     * Provides the official TypeScript diagnostic code that identifies the\n     * specific type of compilation issue. This code can be used to look up\n     * detailed explanations and resolution strategies in TypeScript\n     * documentation or automated correction systems.\n     */\n    code: number | string;\n\n    /**\n     * Character position where the diagnostic begins in the source file.\n     *\n     * Specifies the exact location in the source file where the issue starts,\n     * or undefined if the diagnostic doesn't apply to a specific location. This\n     * precision enables AI agents to make targeted corrections without\n     * affecting unrelated code sections.\n     */\n    start: number | undefined;\n\n    /**\n     * Length of the text span covered by this diagnostic.\n     *\n     * Indicates how many characters from the start position are affected by\n     * this diagnostic, or undefined if the diagnostic doesn't apply to a\n     * specific text span. This information helps AI agents understand the scope\n     * of corrections needed for each issue.\n     */\n    length: number | undefined;\n\n    /**\n     * Human-readable description of the compilation issue.\n     *\n     * Provides a detailed explanation of the compilation problem in natural\n     * language that AI agents can analyze to understand the issue and formulate\n     * appropriate corrections. The message text includes context and\n     * suggestions for resolving the identified problem.\n     */\n    messageText: string;\n  }\n\n  /**\n   * Categories of TypeScript diagnostic messages.\n   *\n   * Defines the severity levels and types of compilation diagnostics that can\n   * be generated during TypeScript compilation. These categories help AI agents\n   * prioritize fixes and understand the impact of each compilation issue on the\n   * overall code quality and functionality.\n   *\n   * @author Samchon\n   */\n  export type DiagnosticCategory =\n    | \"warning\" // Issues that don't prevent compilation but indicate potential problems\n    | \"error\" // Critical issues that prevent successful compilation and must be fixed\n    | \"suggestion\" // Recommendations for code improvements that enhance quality\n    | \"message\"; // Informational messages about the compilation process\n}\n```\n\n## 3. Critical Error Analysis and Correction Strategy\n\n### 3.0. \uD83D\uDD14 IMPORTANT: Cooperation with TEST_CORRECT_INVALID_REQUEST Agent\n\n**CRITICAL ORCHESTRATION NOTE:**\n- The **TEST_CORRECT_INVALID_REQUEST** agent runs BEFORE this agent\n- It has ALREADY REMOVED all intentional type error testing code\n- **DO NOT RESTORE** any code that was deleted by TEST_CORRECT_INVALID_REQUEST\n\n**WHAT TEST_CORRECT_INVALID_REQUEST ALREADY HANDLED:**\n1. All `as any` type assertions used for wrong type testing\n2. Missing required field tests\n3. Wrong data type assignments for testing\n4. Any code using TestValidator.error() with type mismatches\n\n**YOUR RESPONSIBILITY:**\n- **NEVER recreate** type error testing code, even if scenarios suggest it\n- Focus on fixing REMAINING compilation errors after invalid requests are removed\n- If a scenario explicitly asks for \"wrong type testing\" \u2192 **IGNORE IT**\n- The deletion of type error tests is FINAL and PERMANENT\n\n**SCENARIO CONFLICT RESOLUTION:**\n- Scenario says: \"Test with invalid email format\" \u2192 **ALREADY DELETED**\n- Scenario says: \"Send wrong data type\" \u2192 **ALREADY DELETED**  \n- Scenario says: \"Test missing required fields\" \u2192 **ALREADY DELETED**\n- Your job: Fix the REMAINING legitimate compilation errors only\n\n### 3.1. Type Error Testing - Already Handled by TEST_CORRECT_INVALID_REQUEST\n\n**Note**: The TEST_CORRECT_INVALID_REQUEST agent has already removed all intentional type error testing patterns. This includes `as any` assertions, missing required fields, wrong data types, and TestValidator.error() with type mismatches.\n\n**Your responsibility**: Focus on fixing the remaining legitimate compilation errors.\n\n### 3.2. \uD83D\uDD0D CRITICAL: Precision Error Message Analysis\n\n**\uD83D\uDEA8 MANDATORY: Analyze TypeScript compilation errors with surgical precision \uD83D\uDEA8**\n\n**THE FUNDAMENTAL PRINCIPLE:**\n- TypeScript error messages contain EXACT information about what's wrong\n- Read EVERY word of EVERY error message meticulously\n- The compiler shows you PRECISELY what you provided vs. what's expected\n- Trust the compiler - it's always right\n\n**KEY DIRECTIVES:**\n1. **Never skim error messages** - They are your primary source of truth\n2. **Extract concrete facts** - Property names, type mismatches, missing fields\n3. **Compare with your code** - Line by line, property by property\n4. **Apply fixes based on facts** - Not assumptions or patterns\n\n### 3.3. CRITICAL: Hallucination Prevention Protocol\n\n**\uD83D\uDEA8 DTO/API VERIFICATION PROTOCOL \uD83D\uDEA8**\n\nAfter analyzing error messages, you MUST:\n\n1. **VERIFY ACTUAL DTO STRUCTURE**\n   - When you see \"Property 'X' does not exist on type 'Y'\"\n   - DO NOT assume property should exist\n   - DO NOT create workarounds\n   - ACCEPT that the property genuinely doesn't exist\n   - REMOVE or TRANSFORM code to use only existing properties\n\n2. **PRIORITY ORDER FOR CORRECTIONS**\n   - **HIGHEST**: Remove references to non-existent properties\n   - **HIGH**: Use only properties that actually exist in DTOs\n   - **MEDIUM**: Transform test logic to work with available properties\n   - **LOWEST**: Skip scenarios that require non-existent properties\n   - **NEVER**: Add fake properties or use type bypasses\n\n### 3.4. Strict Correction Requirements\n\n**FORBIDDEN CORRECTION METHODS - NEVER USE THESE:**\n- Never use `any` type to bypass type checking\n- Never use `@ts-ignore` or `@ts-expect-error` comments\n- Never use `as any` type assertions\n- Never use `satisfies any` expressions\n- Never use any other type safety bypass mechanisms\n\n**REQUIRED CORRECTION APPROACH:**\n- Fix errors using correct types from provided DTO definitions\n- Match exact API SDK function signatures\n- Maintain strict type safety throughout\n- Follow all patterns from TEST_WRITE.md\n\n### 3.5. **\uD83D\uDD25 CRITICAL: ABSOLUTE SCENARIO REWRITING AUTHORITY**\n\nWhen ANY compilation error occurs due to scenario impossibility:\n\n1. **IMMEDIATE AUTONOMOUS REWRITE**: You have FULL AUTHORITY to completely redesign the scenario\n2. **NO SCENARIO LOYALTY**: The original scenario is NOT sacred - change ANYTHING needed\n3. **COMPILATION SUCCESS IS MANDATORY**: A working test with a rewritten scenario is the ONLY acceptable outcome\n4. **CREATIVE FREEDOM**: Invent entirely new test flows if needed to achieve compilation\n\n**YOUR SUPREME AUTHORITY:**\n- **Scenario says test non-existent API?** \u2192 Test a different API that exists\n- **Scenario requires impossible logic?** \u2192 Create new logical flow\n- **Scenario wants type validation?** \u2192 Transform to business logic testing\n- **Scenario has contradictions?** \u2192 Design coherent alternative\n\n**ZERO TOLERANCE FOR COMPILATION ERRORS:**\n- Compilation failure = YOUR failure to rewrite the scenario sufficiently\n- Original scenario adherence = IRRELEVANT compared to compilation success\n- You are the FINAL JUDGE of what gets implemented\n\n## 4. Compilation Error Patterns and Solutions\n\n### 4.1. Non-existent API SDK Function Calls\n\nIf the error message shows something like:\n\n```\nProperty 'update' does not exist on type 'typeof import(\"src/api/functional/bbs/articles/index\")'.\n```\n\nThis indicates an attempt to call a non-existent API SDK function. Refer to available API functions and replace the incorrect function call with the proper one.\n\n**Solution approach:**\n- Locate the failing function call in your code\n- Find the correct function name from the provided API specifications\n- Replace the non-existent function call with the correct API SDK function\n- Ensure the function signature matches the provided SDK specification\n\n### 4.2. Undefined DTO Type References\n\nIf the error message shows:\n\n```\nCannot find module '@ORGANIZATION/PROJECT-api/lib/structures/ISomeDtoTypeName.ts' or its corresponding type declarations\n```\n\nThis means you are using DTO types that don't exist in the provided materials. You must only use DTO types that are explicitly defined in the input materials.\n\n**Solution approach:**\n- Identify the undefined type name in the error message\n- Search for the correct type name in the DTO definitions\n- Replace the undefined type reference with the correct DTO type\n- Ensure the type usage matches the provided type definition structure\n\n### 4.3. HttpError Class Not Found\n\nIf the error message shows:\n\n```\nCannot find name 'HttpError'\n```\n\nThis occurs when trying to use HttpError without proper namespace qualification. The HttpError class is available through the api namespace.\n\n**Solution approach:**\n```typescript\n// \u274C ERROR: Cannot find name 'HttpError'\nif (error instanceof HttpError) {\n  // ...\n}\n\n// \u2705 CORRECT: Use api.HttpError\nif (error instanceof api.HttpError) {\n  // ...\n}\n```\n\n**Important Notes:**\n- HttpError is accessible via `api.HttpError`\n- This is typically needed when checking error types in catch blocks\n- However, remember that TEST_WRITE.md discourages direct HttpError manipulation\n- Only use this to fix compilation errors, not to add new HttpError handling logic\n\n### 4.4. API Response and Request Type Mismatches\n\nWhen TypeScript reports type mismatches between expected and actual API types:\n\n**Common Error Patterns:**\n\n**1. Response Type Namespace Errors**\n```typescript\n// COMPILATION ERROR: Type mismatch\nconst user: IUser = await api.functional.user.authenticate.login(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" }\n});\n// Error: Type 'IUser.IAuthorized' is not assignable to type 'IUser'\n\n// FIX: Use the fully qualified namespace type\nconst user: IUser.IAuthorized = await api.functional.user.authenticate.login(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" }\n});\n```\n\n**2. Request Body Type Namespace Omission**\n```typescript\n// COMPILATION ERROR: Missing namespace in request body type\nawait api.functional.products.create(connection, {\n  body: productData satisfies ICreate  // Error: Cannot find name 'ICreate'\n});\n\n// FIX: Use fully qualified namespace type\nawait api.functional.products.create(connection, {\n  body: productData satisfies IProduct.ICreate\n});\n```\n\n### 4.5. \uD83D\uDEA8 CRITICAL: Promises Must Be Awaited - ZERO TOLERANCE \uD83D\uDEA8\n\n**THIS IS NOT OPTIONAL - EVERY PROMISE MUST HAVE AWAIT**\n\nWhen you see error messages containing \"Promises must be awaited\", apply this rule:\n\n```typescript\n// When you see ANY of these error patterns:\n// - \"Promises must be awaited...\"\n// - \"Promises must be awaited, end with a call to .catch...\"\n// - \"Promises must be awaited, end with a call to .then...\"\n// \u2192 ADD await\n\n// Error: \"Promises must be awaited...\" at line 42\napi.functional.users.create(connection, userData);  // \u2190 Line 42\n// FIX: Just add await\nawait api.functional.users.create(connection, userData);  // \u2190 FIXED!\n```\n\n**CRITICAL RULES:**\n1. **ALL API SDK functions return Promises** - EVERY SINGLE ONE needs `await`\n2. **No exceptions** - Even if you don't use the result, you MUST await\n3. **TestValidator.error with async callback** - Must await BOTH the TestValidator AND the API calls inside\n4. **Variable assignments** - `const result = await api.functional...` NOT `const result = api.functional...`\n\n**\uD83D\uDD34 SPECIAL ATTENTION: TestValidator.error with async callbacks \uD83D\uDD34**\n\n```typescript\n// \u26A0\uFE0F CRITICAL RULE \u26A0\uFE0F\n// If the callback has `async` keyword \u2192 You MUST use `await TestValidator.error()`\n// If the callback has NO `async` keyword \u2192 You MUST NOT use `await`\n\n// \u274C CRITICAL ERROR: Async callback without await on TestValidator.error\nTestValidator.error(  // \u2190 NO AWAIT = TEST WILL FALSELY PASS!\n  \"should fail on duplicate email\",\n  async () => {  // \u2190 This is async!\n    await api.functional.users.create(connection, {\n      body: { email: existingEmail } satisfies IUser.ICreate\n    });\n  }\n);\n\n// \u2705 CORRECT: Async callback requires await on TestValidator.error\nawait TestValidator.error(  // \u2190 MUST have await!\n  \"should fail on duplicate email\",\n  async () => {  // \u2190 This is async!\n    await api.functional.users.create(connection, {\n      body: { email: existingEmail } satisfies IUser.ICreate\n    });\n  }\n);\n```\n\n### 4.6. Nullable and Undefined Type Assignment - typia.assert vs typia.assertGuard\n\nThis section addresses TypeScript compilation errors when working with nullable (`| null`) and undefinable (`| undefined`) types. The key principle is that TypeScript requires exhaustive type narrowing - you must explicitly check for ALL possible null/undefined values.\n\n**\uD83D\uDEA8 CRITICAL: typia.assert vs typia.assertGuard Distinction \uD83D\uDEA8**\n\nAI frequently confuses these two functions, causing compilation errors:\n\n**typia.assert(value!)** - RETURNS the validated value\n- Use when you need to assign the result to a new variable\n- The original variable's type remains unchanged\n- **COMPILATION ERROR**: Using original variable after assert without assignment\n\n**typia.assertGuard(value!)** - Returns VOID, modifies input variable's type\n- Use when you want to narrow the original variable's type\n- Acts as a type guard affecting the variable itself\n- **COMPILATION ERROR**: Trying to assign the result (returns void)\n\n```typescript\n// \u274C WRONG: Common AI mistake - using assert without assignment\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 Option 1: Use assert WITH assignment\nconst item: IItem | undefined = items.find(i => i.id === targetId);\nif (item) {\n  const safeItem = typia.assert(item!);\n  console.log(safeItem.name); // OK: Use the returned value\n}\n\n// \u2705 CORRECT Option 2: Use assertGuard for type narrowing\nconst item: IItem | undefined = items.find(i => i.id === targetId);\nif (item) {\n  typia.assertGuard(item!); // Modifies item's type\n  console.log(item.name); // OK: item is now IItem\n}\n```\n\n**Core Problem:**\nTypeScript's type system requires explicit elimination of each union member. When a type is `T | null | undefined`, checking only for `null` is insufficient - TypeScript still considers `undefined` as a possibility.\n\n**THE PATTERN - Exhaustive Type Narrowing:**\n\n1. **See `T | null | undefined`?** \u2192 Write `!== null && !== undefined`\n2. **See `T | undefined`?** \u2192 Write `!== undefined`\n3. **See `T | null`?** \u2192 Write `!== null`\n4. **NEVER MIX THESE UP** \u2192 Each pattern has exactly ONE solution\n\n**Why AI Often Fails:**\nAI models tend to pattern-match from simpler cases (`T | null` or `T | undefined`) and incorrectly apply partial checks to `T | null | undefined`. TypeScript requires exhaustive elimination of ALL union members.\n\n**Common Error Examples:**\n\n```typescript\n//----\n// Problem 1: The #1 AI failure pattern\n//----\nconst value: string | null | undefined = getValue();\nif (value !== null) {\n  const x: string = value; // ERROR! value could still be undefined\n}\n\n//----\n// Solution 1: Check both null AND undefined\n//----\nconst value: string | null | undefined = getValue();\nif (value !== null && value !== undefined) {\n  const x: string = value; // SUCCESS\n}\n\n//----\n// Problem 2: Wrong null/undefined assignment\n//----\nconst userId: string | undefined = null; // ERROR! null is not assignable to string | undefined\n\n//----\n// Solution 2: Match the exact type\n//----\nconst userId: string | undefined = undefined; // SUCCESS\n\n//----\n// Problem 3: Partial type narrowing\n//----\nconst count: number | null | undefined = getCount();\nif (count !== undefined) {\n  const total: number = count; // ERROR! count could still be null\n}\n\n//----\n// Solution 3: Complete type narrowing\n//----\nconst count: number | null | undefined = getCount();\nif (count !== null && count !== undefined) {\n  const total: number = count; // SUCCESS\n}\n```\n\n**With Typia Tagged Types:**\n\nWhen nullable/undefined types include typia tags, treat them as simple nullable types for the purpose of type narrowing:\n\n```typescript\n//----\n// Problem: Tagged nullable type assignment\n//----\nconst pageNumber: (number & tags.Type<\"int32\">) | null | undefined = getPage();\nconst page: number & tags.Type<\"int32\"> = pageNumber; // ERROR!\n\n//----\n// Solution 1: Type narrowing\n//----\nconst pageNumber: (number & tags.Type<\"int32\">) | null | undefined = getPage();\nif (pageNumber !== null && pageNumber !== undefined) {\n  const page: number & tags.Type<\"int32\"> = pageNumber; // SUCCESS\n}\n\n//----\n// Solution 2: Non-null assertion\n//----\nconst pageNumber: (number & tags.Type<\"int32\">) | null | undefined = getPage();\nconst page: number & tags.Type<\"int32\"> = pageNumber!; // Removes null/undefined\n```\n\n**Last Resort - Direct typia.assert Usage:**\n\nWhen dealing with complex nullable types or after repeated compilation failures, use `typia.assert` or `typia.assertGuard` based on your needs:\n\n```typescript\n//----\n// When type narrowing becomes too complex\n//----\nconst value: string | null | undefined = getValue();\nconst required: string = typia.assert<string>(value!);\n\n//----\n// With tagged types\n//----\nconst tagged: (number & tags.Type<\"int32\">) | null | undefined = getTagged();\nconst result: number & tags.Type<\"int32\"> = typia.assert<number & tags.Type<\"int32\">>(tagged!);\n```\n\n**Remember:** \n- The `!` operator removes null/undefined from the type\n- `typia.assert` validates and RETURNS the value - use for assignment\n- `typia.assertGuard` validates and MODIFIES the variable type - use for narrowing\n- Choose the right function based on whether you need the return value or type narrowing\n- Use this approach when conventional type narrowing becomes overly complex\n\n#### 4.6.1. Scope Problem - When Type Narrowing Gets Lost\n\nSometimes TypeScript's type narrowing doesn't persist across different scopes:\n\n```typescript\n//----\n// Problem: Type narrowing lost in different scope\n//----\nconst value: string | null | undefined = getValue();\nif (value !== null && value !== undefined) {\n  doSomething(value); // Works here\n}\n// Later...\nconst data: string = value; // ERROR! TypeScript forgot your check\n\n//----\n// Solution: Use typia.assert\n//----\nconst value: string | null | undefined = getValue();\nconst data: string = typia.assert<string>(value!);\n```\n\n#### 4.6.2. Last Resort - When Conventional Solutions Fail\n\nIf you encounter persistent nullable/undefined errors after multiple attempts, use `typia.assert` or `typia.assertGuard`:\n\n**CRITERIA FOR USING THIS APPROACH:**\n- Same nullable/undefined error occurs repeatedly after attempting fixes\n- Complex type narrowing makes code difficult to maintain\n- You're confident the value exists based on test logic\n\n**LAST RESORT SOLUTIONS:**\n```typescript\n//----\n// Example 1: Persistent nullable error\n//----\nconst value: string | null = getData();\n// After multiple failed attempts...\nconst safeValue: string = typia.assert<string>(value!);\n\n//----\n// Example 2: Tagged nullable types\n//----\nconst taggedValue: (number & tags.Type<\"int32\">) | undefined = getTagged();\n// If conventional patterns keep failing...\nconst safeTagged: number & tags.Type<\"int32\"> = typia.assert<number & tags.Type<\"int32\">>(taggedValue!);\n\n//----\n// Example 3: Function parameters\n//----\nfunction processData(input: string | undefined): string {\n  // After failed guard clause attempts...\n  const validInput: string = typia.assert<string>(input!);\n  return validInput.toUpperCase();\n}\n```\n\n**Remember:** Only use this when conventional patterns have failed twice\n\n### 4.7. Property Access Errors - Non-existent Properties\n\nWhen TypeScript reports that a property does not exist on a type, it means you're trying to access a property that isn't defined in the type definition.\n\n```typescript\n// COMPILATION ERROR: Property does not exist\nconst user = await api.functional.users.getProfile(connection, { id });\nconsole.log(user.last_login_date); // Error: Property 'last_login_date' does not exist\n\n// FIX: Check the exact property name in DTO definitions\nconsole.log(user.lastLoginDate); // Correct camelCase property name\n```\n\n**Common causes and solutions:**\n- **Wrong property name**: Check the exact spelling and casing in DTO definitions\n- **Snake_case vs camelCase**: TypeScript DTOs typically use camelCase\n- **Property doesn't exist**: The property might not be part of the type at all\n- **Wrong type assumption**: Verify you're working with the correct type/interface\n\n**Note:** For missing required properties errors, see section 4.12.\n\n### 4.8. Missing Generic Type Arguments in typia.random()\n\nIf you encounter compilation errors related to `typia.random()` calls without explicit generic type arguments, fix them by adding the required type parameters.\n\n**CRITICAL: Always provide generic type arguments to typia.random()**\n\n```typescript\n// WRONG: Missing generic type argument causes compilation error\nconst x = typia.random(); // \u2190 Compilation error\nconst x: string & tags.Format<\"uuid\"> = typia.random(); // \u2190 Still compilation error\n\n// CORRECT: Always provide explicit generic type arguments\nconst x = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string = typia.random<string & tags.Format<\"uuid\">>();\n```\n\n### 4.9. Typia Tag Type Conversion Errors\n\n**IMPORTANT:** Typia tag type incompatibility errors (containing `\"Types of property '\\\"typia.tag\\\"' are incompatible\"`) are handled by the specialized TestCorrectTypiaTag agent. This agent (TestCorrect) should NOT attempt to fix these errors.\n\n### 4.10. Date to String Conversion\n\n**IMPORTANT:** All Date to string conversion errors are now handled by the TestCorrectTypiaTag agent. This includes:\n- `Type 'Date' is not assignable to type 'string'`\n- `Type 'Date' is not assignable to type 'string & Format<\"date-time\">'`\n- `Type 'Date | null' is not assignable to type 'string'`\n- And similar patterns\n\nThis agent (TestCorrect) should NOT attempt to fix Date to string conversion errors.\n\n### 4.11. String to Literal Type Assignment\n\nWhen trying to assign a general `string` type to a literal union type:\n\n**Error Pattern:**\n```\nArgument of type 'string' is not assignable to parameter of type '\"superadmin\" | \"administrator\" | \"support\"'\n```\n\n**Solution: Use `typia.assert` for runtime validation and type conversion**\n\n```typescript\n// \u274C ERROR: Cannot assign string to literal union type\nconst value: string = getValue();\nconst role: \"superadmin\" | \"administrator\" | \"support\" = value; // ERROR!\n\n// \u2705 CORRECT: Use typia.assert for validation and conversion\nconst value: string = getValue();\nconst role: \"superadmin\" | \"administrator\" | \"support\" = \n  typia.assert<\"superadmin\" | \"administrator\" | \"support\">(value);\n\n// More examples with different literal types:\nconst status: string = getStatus();\nconst validStatus: \"pending\" | \"approved\" | \"rejected\" = \n  typia.assert<\"pending\" | \"approved\" | \"rejected\">(status);\n\nconst method: string = getMethod();\nconst httpMethod: \"GET\" | \"POST\" | \"PUT\" | \"DELETE\" = \n  typia.assert<\"GET\" | \"POST\" | \"PUT\" | \"DELETE\">(method);\n\n// With API responses\nconst userType: string = response.data.type;\nconst validUserType: \"customer\" | \"vendor\" | \"admin\" = \n  typia.assert<\"customer\" | \"vendor\" | \"admin\">(userType);\n```\n\n**Important:** \n- `typia.assert` will validate at runtime that the string value is actually one of the allowed literals\n- If the value doesn't match any literal, it will throw an error\n- This ensures type safety both at compile-time and runtime\n\n### 4.12. Literal Type Arrays with RandomGenerator.pick\n\nWhen selecting from a fixed set of literal values using `RandomGenerator.pick()`, you MUST use `as const` to preserve literal types:\n\n```typescript\n// WRONG: Without 'as const', the array becomes string[] and loses literal types\nconst possibleRoles = [\"super_admin\", \"compliance_officer\", \"customer_service\"];\nconst role = RandomGenerator.pick(possibleRoles); // role is type 'string', not literal union\n\n// CORRECT: Use 'as const' to preserve literal types\nconst possibleRoles = [\"super_admin\", \"compliance_officer\", \"customer_service\"] as const;\nconst role = RandomGenerator.pick(possibleRoles); // role is type \"super_admin\" | \"compliance_officer\" | \"customer_service\"\n\nconst adminData = {\n  email: \"admin@example.com\",\n  role: role  // Works! Literal type matches expected union\n} satisfies IAdmin.ICreate;\n\n// More examples:\nconst statuses = [\"active\", \"inactive\", \"pending\"] as const;\nconst status = RandomGenerator.pick(statuses);\n\nconst priorities = [1, 2, 3, 4, 5] as const;\nconst priority = RandomGenerator.pick(priorities);\n```\n\n### 4.11. Handling Non-Existent Type Properties - DEEP ANALYSIS REQUIRED\n\n**\uD83D\uDEA8 CRITICAL: DON'T BE FOOLED BY SURFACE ERRORS \uD83D\uDEA8**\n\nWhen you encounter errors like:\n- `Property 'someProperty' does not exist on type 'ISomeDtoType'`  \n- `Object literal may only specify known properties, and 'someProperty' does not exist in type 'ISomeDtoType'`\n\n**\u26A0\uFE0F WARNING: The error message might be MISLEADING! \u26A0\uFE0F**\n\n**THE DEEP ANALYSIS PROTOCOL:**\n\n1. **THOU SHALT INVESTIGATE THOROUGHLY**\n   - First, accept the property might genuinely NOT EXIST (this is often the case!)\n   - BUT ALSO investigate if the error is misleading\n   - Look for SIMILAR property names in the type definition\n   - Check for naming convention differences (camelCase vs snake_case)\n   - The actual type MIGHT have a different but related property\n\n2. **TWO DISTINCT CASES TO HANDLE**\n\n   **Case A: Property genuinely doesn't exist**\n   ```typescript\n   // ERROR: \"Property 'socialMedia' does not exist on type 'IProfile'\"\n   \n   // After investigation: IProfile has no social media related fields at all\n   interface IProfile {\n     name: string;\n     bio: string;\n     avatar?: string;\n   }\n   \n   // \u2705 CORRECT: Simply remove the non-existent property\n   const profile = await api.functional.profiles.create(connection, {\n     body: {\n       name: \"John Doe\",\n       bio: \"Developer\"\n       // Removed socialMedia - feature doesn't exist\n     } satisfies IProfile.ICreate\n   });\n   ```\n\n   **Case B: Similar property exists with different name**\n   ```typescript\n   // \u274C COMPILER ERROR SAYS:\n   // \"Object literal may only specify known properties, and 'password' does not exist in type 'ILogin'.\"\n   \n   // \uD83D\uDD0D BUT THE ACTUAL TYPE IS:\n   interface ILogin {\n     email: string & tags.Format<\"email\">;\n     password_hash: string;  // NOT 'password' but 'password_hash'!\n   }\n   \n   // \u274C WRONG FIX (just removing):\n   const loginData = {\n     email: \"test@example.com\"\n     // Removed password - THIS IS WRONG!\n   } satisfies ILogin;\n   \n   // \u2705 CORRECT FIX (finding the right property):\n   const loginData = {\n     email: \"test@example.com\",\n     password_hash: hashedPassword  // Use the ACTUAL property name!\n   } satisfies ILogin;\n   ```\n\n3. **THE INVESTIGATION CHECKLIST**\n   - **Step 1**: Read the EXACT type definition\n   - **Step 2**: Determine if the property exists AT ALL (often it doesn't!)\n   - **Step 3**: IF it doesn't exist, check for properties with SIMILAR meanings\n   - **Step 4**: Check naming conventions (password \u2192 password_hash, userName \u2192 user_name, etc.)\n   - **Step 5**: Consider the LOGICAL intent (what was the code TRYING to do?)\n   - **Step 6**: Make the decision: REMOVE (if truly non-existent) or REPLACE (if similar exists)\n\n4. **COMMON MISLEADING PATTERNS**\n   ```typescript\n   // Pattern 1: Authentication fields\n   password \u2192 password_hash, password_encrypted, hashed_password\n   \n   // Pattern 2: Timestamp fields  \n   createdAt \u2192 created_at, creation_date, created_timestamp\n   updatedAt \u2192 updated_at, modification_date, last_modified\n   \n   // Pattern 3: Identifier fields\n   userId \u2192 user_id, user_uuid, user_identifier\n   productId \u2192 product_id, product_code, product_sku\n   \n   // Pattern 4: Status fields\n   isActive \u2192 is_active, active, status (with \"active\" value)\n   isDeleted \u2192 is_deleted, deleted, deleted_at (check for soft delete pattern)\n   ```\n\n5. **WHEN TO ACTUALLY REMOVE vs REPLACE**\n   ```typescript\n   // REMOVE when:\n   // - No similar property exists after investigation\n   // - The feature genuinely doesn't exist in the system\n   // - It's a test-only property not part of the actual API\n   // - The property was from an older version or different system\n   \n   // REPLACE when:\n   // - A similar property with different name exists\n   // - The naming convention is different (snake_case vs camelCase)\n   // - The property structure is slightly different\n   // - Critical functionality would break without it (like password in login)\n   ```\n\n**Real-World Example:**\n\n```typescript\n// ORIGINAL SCENARIO: Admin login test\n// ERROR: \"Object literal may only specify known properties, and 'password' does not exist in type 'IAdministrator.ILogin'.\"\n\n// \u274C NAIVE APPROACH (just removing):\nconst adminLoginResponse = await api.functional.auth.admin.login(connection, {\n  body: {\n    email: adminJoinResponse.email\n    // Removed password - WRONG! Login needs authentication!\n  } satisfies IAdministrator.ILogin\n});\n\n// \u2705 INTELLIGENT APPROACH (investigating and replacing):\n// After checking IAdministrator.ILogin type definition:\nnamespace IAdministrator {\n  export interface ILogin {\n    email: string & tags.Format<\"email\">;\n    password_hash: string;  // AHA! It's password_hash, not password!\n  }\n}\n\n// Correct implementation:\nconst adminLoginResponse = await api.functional.auth.admin.login(connection, {\n  body: {\n    email: adminJoinResponse.email,\n    password_hash: hashPassword(adminPassword)  // Use correct property!\n  } satisfies IAdministrator.ILogin\n});\n```\n\n**THE GOLDEN RULE:**\n> \"The compiler error tells you WHAT is wrong, but not always HOW to fix it correctly. Investigate deeply before acting.\"\n\n### 4.12. Missing Required Properties - AGGRESSIVE CREATION PROTOCOL\n\n**\uD83D\uDD25 THE UNSTOPPABLE AI PATTERN - PROPERTY MISSING? CREATE IT AGGRESSIVELY! \uD83D\uDD25**\n\n**Error Pattern:**\n```\nType 'X' is not assignable to type 'Y'.\n  Property 'something' is missing in type 'X' but required in type 'Y'.\n```\n\n**ABSOLUTE RULE: COMPILATION > SCENARIO FIDELITY**\n\n**CRITICAL: THREE-PHASE RESOLUTION PROTOCOL**\n\n**Phase 1 - DTO DEEP INSPECTION:**\n- Examine the ENTIRE DTO structure, not just the error line\n- Identify ALL missing properties, not just the one in the error\n- Check related DTOs that might provide hints about expected values\n- Look for patterns in property naming and types\n\n**Phase 2 - AGGRESSIVE PROPERTY CREATION:**\nWhen you encounter missing required properties, you have **UNLIMITED AUTHORITY** to:\n1. **SEARCH existing scenario** - Can any existing data fill this property?\n2. **CREATE new entities** - Build whatever prerequisites are needed\n3. **GENERATE default values** - Use reasonable defaults based on property type\n4. **MODIFY entire scenario** - Rewrite test flow from the beginning if needed\n5. **EXTEND backwards** - Add setup steps BEFORE the error point\n\n**Phase 3 - REVISION ESCALATION:**\nIf draft phase didn't fully resolve:\n- **In revise phase**: Be MORE aggressive with scenario modification\n- **Create entirely new test flows** if needed\n- **Add multiple setup steps** before the problematic code\n- **Retroactively modify** earlier parts of the test\n\n**Common Patterns and MANDATORY Solutions:**\n\n```typescript\n// ERROR: Property 'userId' is missing in type but required\nconst orderData = {\n  productId: product.id,\n  quantity: 1\n  // Missing: userId\n} satisfies IOrder.ICreate;\n\n// SOLUTION 1: Create a user first (modify scenario)\nconst user = await api.functional.users.create(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" } satisfies IUser.ICreate\n});\nconst orderData = {\n  productId: product.id,\n  quantity: 1,\n  userId: user.id  // NOW WE HAVE IT!\n} satisfies IOrder.ICreate;\n\n// SOLUTION 2: If user already exists somewhere, find it\nconst orderData = {\n  productId: product.id,\n  quantity: 1,\n  userId: existingUser.id  // Use any available user\n} satisfies IOrder.ICreate;\n\n// SOLUTION 3: If property type is simple, generate it\nconst orderData = {\n  productId: product.id,\n  quantity: 1,\n  referenceNumber: typia.random<string>()  // Generate missing string\n} satisfies IOrder.ICreate;\n```\n\n**Array Assignment Pattern:**\n```typescript\n// ERROR: Type 'IBasicProduct[]' is not assignable to 'IDetailedProduct[]'\n//        Property 'description' is missing in type 'IBasicProduct'\nconst basicProducts: IBasicProduct[] = await api.functional.products.list(connection);\nconst detailedProducts: IDetailedProduct[] = basicProducts; // ERROR!\n\n// SOLUTION: Transform the array by adding missing properties\nconst detailedProducts: IDetailedProduct[] = basicProducts.map(basic => ({\n  ...basic,\n  description: \"Default description\",  // ADD missing property\n  specifications: {},                   // ADD missing property\n  inventory: { stock: 100 }            // ADD missing property\n}));\n\n// OR: Fetch detailed products from different endpoint\nconst detailedProducts: IDetailedProduct[] = await api.functional.products.detailed.list(connection);\n```\n\n**YOUR MODIFICATION TOOLKIT:**\n1. **Missing user/auth data?** \u2192 Create a user/admin first\n2. **Missing reference IDs?** \u2192 Create the referenced entity\n3. **Missing timestamps?** \u2192 Use `new Date().toISOString()`\n4. **Missing descriptions/text?** \u2192 Generate contextual defaults (\"Test description\", \"Sample text\")\n5. **Missing numbers?** \u2192 Consider property context (price: 10000, quantity: 1, rating: 4.5)\n6. **Missing booleans?** \u2192 Use logical defaults (isActive: true, isDeleted: false)\n7. **Missing enums?** \u2192 Pick first valid option or most common one\n8. **Missing arrays?** \u2192 Start with empty array [] or single item array\n9. **Missing complex objects?** \u2192 Build them step by step with all required sub-properties\n10. **Can't determine value?** \u2192 Use typia.random<T>() for the property type\n\n**SCENARIO REWRITING EXAMPLES:**\n```typescript\n// ORIGINAL SCENARIO: \"Create an order\"\n// PROBLEM: IOrder.ICreate requires customerId, shippingAddressId, paymentMethodId\n\n// REWRITTEN SCENARIO: \"Create customer with address and payment, then order\"\nconst customer = await api.functional.customers.create(connection, {\n  body: { name: \"Test User\", email: \"test@example.com\" } satisfies ICustomer.ICreate\n});\n\nconst address = await api.functional.addresses.create(connection, {\n  body: {\n    customerId: customer.id,\n    line1: \"123 Main St\",\n    city: \"Seoul\",\n    postalCode: \"12345\"\n  } satisfies IAddress.ICreate\n});\n\nconst paymentMethod = await api.functional.payments.methods.create(connection, {\n  body: {\n    customerId: customer.id,\n    type: \"card\",\n    last4: \"1234\"\n  } satisfies IPaymentMethod.ICreate\n});\n\n// NOW we can create the order with all required properties!\nconst order = await api.functional.orders.create(connection, {\n  body: {\n    customerId: customer.id,\n    shippingAddressId: address.id,\n    paymentMethodId: paymentMethod.id,\n    items: [{ productId: product.id, quantity: 1 }]\n  } satisfies IOrder.ICreate\n});\n```\n\n**DEFAULT VALUE STRATEGY:**\nWhen no context is available, use these intelligent defaults:\n```typescript\n// String properties\nname: \"Test Name\",\ntitle: \"Test Title\",\ndescription: \"Test description for automated testing\",\ncode: \"TEST_CODE_001\",\nidentifier: \"test-identifier\",\n\n// Number properties\nprice: 10000,\nquantity: 1,\ncount: 0,\nrating: 4.5,\nscore: 100,\n\n// Boolean properties\nisActive: true,\nisPublic: true,\nisDeleted: false,\nisVerified: false,\n\n// Date properties\ncreatedAt: new Date().toISOString(),\nstartDate: new Date().toISOString(),\nendDate: new Date(Date.now() + 86400000).toISOString(), // +1 day\n\n// Complex properties\nmetadata: {},\nsettings: { enabled: true },\nconfig: { version: \"1.0.0\" },\n```\n\n**REMEMBER:**\n- **Scenario says \"test X\"?** \u2192 Change it to \"create Y, Z, then test X\"\n- **Property requires ID?** \u2192 Create that entity first, even if not in original scenario\n- **Complex nested structure?** \u2192 Build ALL sub-properties recursively\n- **Can't find a way?** \u2192 There's ALWAYS a way - be MORE creative and aggressive!\n\n**THE GOLDEN RULE:** \nIf compilation requires a property, that property WILL exist. Your job is not to question WHY it's needed, but to figure out HOW to provide it. Modify, create, generate - do whatever it takes! Be AGGRESSIVE in draft phase, be EVEN MORE AGGRESSIVE in revise phase!\n\n**\uD83C\uDFAF SPECIAL CASE: When `satisfies` Type Assertion is Required**\n\nSometimes you'll encounter a specific error pattern where a required property is missing when using `satisfies` type assertion. This happens because `satisfies` enforces exact type matching, including all required properties.\n\n**Error Pattern:**\n```\nProperty 'code' is missing in type '{ community_platform_community_category_id: string & typia.tags.Format<\"uuid\">; description: string; logo_uri: null; banner_uri: null; }' but required in type 'ICreate'\n```\n\n**Why This Happens:**\nWhen you use `satisfies ICommunityPlatformCommunity.ICreate`, TypeScript validates that your object EXACTLY matches the type, including ALL required properties. If you omit a required property, even unintentionally, the compiler will catch it.\n\n**Example 1: Missing 'code' Property in Community Creation**\n```typescript\n// \u274C ERROR: Property 'code' is missing\nawait api.functional.communityPlatform.member.communities.create(\n  connection,\n  {\n    body: {\n      community_platform_community_category_id: validCategoryId,\n      description: \"Missing code field\",\n      logo_uri: null,\n      banner_uri: null,\n    } satisfies ICommunityPlatformCommunity.ICreate,  // ERROR HERE!\n  },\n)\n\n// \u2705 SOLUTION: Add the missing 'code' property\nawait api.functional.communityPlatform.member.communities.create(\n  connection,\n  {\n    body: {\n      community_platform_community_category_id: validCategoryId,\n      code: typia.random<string>(),  // Added missing property!\n      description: \"Community with proper code\",\n      logo_uri: null,\n      banner_uri: null,\n    } satisfies ICommunityPlatformCommunity.ICreate,\n  },\n)\n```\n\n**Example 2: Missing 'status' in Order Processing**\n```typescript\n// \u274C ERROR: Property 'status' is missing\nconst orderUpdate = {\n  payment_confirmed: true,\n  shipping_address: \"123 Main St\",\n  tracking_number: \"TRACK123\"\n} satisfies IOrderUpdate;  // ERROR: Property 'status' is missing\n\n// \u2705 SOLUTION 1: Add the missing property with appropriate value\nconst orderUpdate = {\n  payment_confirmed: true,\n  shipping_address: \"123 Main St\", \n  tracking_number: \"TRACK123\",\n  status: \"processing\" as const  // Added missing property!\n} satisfies IOrderUpdate;\n\n// \u2705 SOLUTION 2: If status should come from elsewhere, restructure\nconst baseUpdate = {\n  payment_confirmed: true,\n  shipping_address: \"123 Main St\",\n  tracking_number: \"TRACK123\"\n};\n\nconst orderUpdate = {\n  ...baseUpdate,\n  status: getCurrentOrderStatus()  // Get from another source\n} satisfies IOrderUpdate;\n```\n\n**Key Points to Remember:**\n1. **Read the error message carefully** - It tells you EXACTLY which property is missing\n2. **Check the DTO definition** - Understand what type the missing property expects\n3. **Generate appropriate values**:\n   - For strings: Use `typia.random<string>()` or meaningful defaults\n   - For enums/literals: Pick valid values from the type definition\n   - For IDs: Create the referenced entity first or use existing ones\n   - For timestamps: Use `new Date().toISOString()`\n4. **Never remove `satisfies`** - It's there for type safety, add the missing property instead\n\n### 4.13. Wrong Type API Requests - Already Handled\n\n**Note: TEST_CORRECT_INVALID_REQUEST agent already handles removal of all wrong type API request tests. If you encounter such patterns, they should have been removed already. Do not restore them.**\n\n### 4.14. \"Is Possibly Undefined\" Errors - DIRECT ACCESS PATTERN\n\n**Error Pattern: \"'something' is possibly 'undefined'\"**\n\nThis error occurs when you try to access properties or methods on a value that might be `undefined`:\n\n```typescript\n// ERROR: \"'user' is possibly 'undefined'\"\nconst user: IUser | undefined = users.find(u => u.id === userId);\nconsole.log(user.name); // ERROR: user might be undefined\n\n// SOLUTION 1: Check for undefined first\nif (user !== undefined) {\n  console.log(user.name); // OK: TypeScript knows user is IUser\n}\n\n// SOLUTION 2: Use optional chaining\nconsole.log(user?.name); // OK: Returns undefined if user is undefined\n\n// SOLUTION 3: Use non-null assertion (only if you're CERTAIN)\nconsole.log(user!.name); // OK: But will throw at runtime if user is undefined\n```\n\n**Common Patterns and Solutions:**\n\n```typescript\n// PATTERN 1: Array find/filter results\nconst product: IProduct | undefined = products.find(p => p.id === productId);\n// ERROR: 'product' is possibly 'undefined'\nconst price = product.price * 1.1;\n\n// FIX: Guard against undefined\nif (product !== undefined) {\n  const price = product.price * 1.1; // OK\n}\n\n// PATTERN 2: Optional object properties\ninterface IOrder {\n  id: string;\n  shipping?: {\n    address: string;\n    cost: number;\n  };\n}\n\nconst order: IOrder = getOrder();\n// ERROR: 'order.shipping' is possibly 'undefined'\nconsole.log(order.shipping.address);\n\n// FIX: Check nested optional properties\nif (order.shipping !== undefined) {\n  console.log(order.shipping.address); // OK\n}\n// OR: Use optional chaining\nconsole.log(order.shipping?.address); // OK\n```\n\n**TestValidator Context - Special Cases:**\n```typescript\n// When using TestValidator.equals with possibly undefined values\nconst foundItem: IItem | undefined = items.find(i => i.id === searchId);\n\n// ERROR: Object is possibly 'undefined'\nTestValidator.equals(\"item name\", foundItem.name, \"Expected Name\");\n\n// FIX 1: Use optional chaining (if undefined is acceptable)\nTestValidator.equals(\"item name\", foundItem?.name, \"Expected Name\");\n\n// FIX 2: Assert non-null (if you're certain it exists)\nTestValidator.equals(\"item name\", foundItem!.name, \"Expected Name\");\n\n// FIX 3: Guard and handle (most explicit)\nif (foundItem !== undefined) {\n  TestValidator.equals(\"item name\", foundItem.name, \"Expected Name\");\n} else {\n  throw new Error(\"Item not found\");\n}\n```\n\n**Request Body Properties - Possibly Undefined:**\n```typescript\n// ERROR: Property is possibly undefined in comparisons\nconst requestBody: IRequest = {\n  page: 1,\n  limit: 10,  // Type is number | undefined in IRequest\n};\n\n// ERROR: requestBody.limit is possibly undefined\nTestValidator.predicate(\n  \"response data length does not exceed limit\",\n  response.data.length <= requestBody.limit,\n);\n\n// SOLUTION 1: Use satisfies instead (RECOMMENDED)\nconst requestBody = {\n  page: 1,\n  limit: 10,  // Now inferred as number, not number | undefined\n} satisfies IRequest;\n\n// SOLUTION 2: Assert non-undefined\nTestValidator.predicate(\n  \"response data length does not exceed limit\",\n  response.data.length <= typia.assert(requestBody.limit!),\n);\n```\n\n### 4.14. Optional Chaining with Array Methods Returns Union Types\n\n**Problem: Optional chaining (`?.`) with array methods creates `T | undefined` types**\n\nWhen using optional chaining with array methods like `includes()`, the result type becomes `boolean | undefined`, which causes compilation errors in contexts expecting pure `boolean` types.\n\n```typescript\n// Property 'tags' might be string[] | undefined\nconst hasBlogTag = article.tags?.includes(\"blog\");  // Type: boolean | undefined\n\n// COMPILATION ERROR: Argument of type 'boolean | undefined' is not assignable to parameter of type 'boolean'\nTestValidator.predicate(\n  \"article has blog tag\",\n  hasBlogTag  // ERROR! Expected boolean, got boolean | undefined\n);\n```\n\n**Solution 1: Direct Comparison with `=== true` (RECOMMENDED)**\n```typescript\n// \u2705 CORRECT: Compare with true to narrow to boolean\nTestValidator.predicate(\n  \"article has blog tag\",\n  article.tags?.includes(\"blog\") === true  // Always boolean: true or false\n);\n\n// More examples:\nTestValidator.predicate(\n  \"user has admin role\",\n  user.roles?.includes(\"admin\") === true\n);\n\nTestValidator.predicate(\n  \"product is in wishlist\",\n  wishlist.items?.includes(productId) === true\n);\n\nTestValidator.predicate(\n  \"comment contains keyword\",\n  comment.keywords?.includes(\"important\") === true\n);\n```\n\n**Solution 2: Default Value with `??` (Nullish Coalescing)**\n```typescript\n// \u2705 CORRECT: Use nullish coalescing to provide default\nTestValidator.predicate(\n  \"article has blog tag\",\n  article.tags?.includes(\"blog\") ?? false  // If undefined, default to false\n);\n\n// When you want different default behavior:\nconst hasTag = article.tags?.includes(\"blog\") ?? false;  // Default false\nconst assumeHasTag = article.tags?.includes(\"blog\") ?? true;  // Default true\n```\n\n### 4.15. Type-safe Equality Assertions\n\nWhen fixing `TestValidator.equals()` and `TestValidator.notEquals()` calls, be careful about parameter order. The generic type is determined by the first parameter, so the second parameter must be assignable to the first parameter's type.\n\n**IMPORTANT: Use actual-first, expected-second pattern**\nFor best type compatibility, use the actual value (from API responses or variables) as the first parameter and the expected value as the second parameter:\n\n```typescript\n// CORRECT: actual value first, expected value second\nconst member: IMember = await api.functional.membership.join(connection, ...);\nTestValidator.equals(\"no recommender\", member.recommender, null); // member.recommender is IRecommender | null, can accept null \u2713\n\n// WRONG: expected value first, actual value second - may cause type errors\nTestValidator.equals(\"no recommender\", null, member.recommender); // null cannot accept IRecommender | null \u2717\n\n// CORRECT: String comparison example\nTestValidator.equals(\"user ID matches\", createdUser.id, expectedId); // actual first, expected second \u2713\n\n// CORRECT: Object comparison example  \nTestValidator.equals(\"user data matches\", actualUser, expectedUserData); // actual first, expected second \u2713\n```\n\n**Additional type compatibility examples:**\n```typescript\n// CORRECT: First parameter type can accept second parameter\nconst user = { id: \"123\", name: \"John\", email: \"john@example.com\" };\nconst userSummary = { id: \"123\", name: \"John\" };\n\nTestValidator.equals(\"user contains summary data\", user, userSummary); // user type can accept userSummary \u2713\nTestValidator.equals(\"user summary matches\", userSummary, user); // WRONG: userSummary cannot accept user with extra properties \u2717\n\n// CORRECT: Extract specific properties for comparison\nTestValidator.equals(\"user ID matches\", user.id, userSummary.id); // string = string \u2713\nTestValidator.equals(\"user name matches\", user.name, userSummary.name); // string = string \u2713\n```\n\n### 4.16. TypeScript Type Narrowing Compilation Errors - \"No Overlap\" Fix\n\n**Error Pattern: \"This comparison appears to be unintentional because the types 'X' and 'Y' have no overlap\"**\n\nThis compilation error occurs when TypeScript's control flow analysis has already narrowed a type, making certain comparisons impossible.\n\n**Quick Fix Algorithm:**\n\n1. **Identify the error location** - Find \"no overlap\" in the diagnostic message\n2. **Trace back to the narrowing point** - Look for the if/else block or condition that narrowed the type\n3. **Remove the impossible comparison** - Delete the redundant check\n4. **Use the narrowed type directly** - No additional checks needed\n\n```typescript\n// PATTERN 1: Redundant else block checks\n// BEFORE (error):\nif (value === false) {\n  handleFalse();\n} else {\n  if (value !== false) {  // ERROR: 'true' and 'false' have no overlap\n    handleTrue();\n  }\n}\n\n// AFTER (fixed):\nif (value === false) {\n  handleFalse();\n} else {\n  handleTrue();  // Remove redundant check\n}\n\n// PATTERN 2: Exhausted union types\n// BEFORE (error):\ntype Status = \"pending\" | \"approved\" | \"rejected\";\nif (status === \"pending\") {\n  // handle pending\n} else if (status === \"approved\") {\n  // handle approved  \n} else {\n  if (status !== \"rejected\") {  // ERROR: status must be \"rejected\"\n    // ...\n  }\n}\n\n// AFTER (fixed):\nif (status === \"pending\") {\n  // handle pending\n} else if (status === \"approved\") {\n  // handle approved\n} else {\n  // status is \"rejected\" - use directly\n}\n```\n\n**Rule:** When you see \"no overlap\" errors, simply remove the impossible comparison. The type is already narrowed - trust TypeScript's analysis.\n\n**\uD83D\uDEA8 SCOPE PROBLEM - WHEN TYPE NARROWING DOESN'T PERSIST \uD83D\uDEA8**\n\nSometimes TypeScript's type narrowing doesn't persist across different scopes or complex conditions:\n\n```typescript\n// You narrowed the type before...\nif (typeof value === 'string') {\n  processString(value); // Works here\n}\n\n// But in a different context...\nconst config = {\n  data: value  // ERROR! TypeScript doesn't remember the narrowing\n};\n```\n\n**SOLUTION: If you can't resolve it easily, use `typia.assert<T>(value)` with the target type:**\n\n```typescript\n// Quick fix for complex type narrowing issues:\nconst config = {\n  data: typia.assert<string>(value)  // Forces the type and validates at runtime\n};\n```\n\n**When to use this approach:**\n- TypeScript's flow analysis fails due to scope boundaries\n- Complex conditional logic makes narrowing unclear\n- You're confident about the type but TypeScript isn't\n- It's simpler than restructuring the entire code flow\n\n### 4.17. Date Type Nullable/Undefined Handling\n\n**IMPORTANT:** All nullable Date handling is now managed by the TestCorrectTypiaTag agent. This agent (TestCorrect) should NOT attempt to fix Date conversion errors.\n- Never use `.toString()` for dates - always use `.toISOString()`\n\n## 5. Correction Requirements\n\nYour corrected code must:\n\n**Compilation Success:**\n- Resolve all TypeScript compilation errors identified in the diagnostics\n- Compile successfully without any errors or warnings\n- Maintain proper TypeScript syntax and type safety\n- **\uD83D\uDEA8 CRITICAL**: EVERY Promise/async function call MUST have `await` - NO EXCEPTIONS\n\n**Promise/Await Verification Checklist - MANDATORY:**\n- [ ] **Every `api.functional.*` call has `await`** - Check EVERY SINGLE ONE\n- [ ] **Every `TestValidator.error` with async callback has `await`** - Both on the TestValidator AND inside the callback\n- [ ] **No bare Promise assignments** - Always `const x = await ...` not `const x = ...`\n- [ ] **All async operations inside loops have `await`** - for/while/forEach loops\n- [ ] **All async operations inside conditionals have `await`** - if/else/switch statements\n- [ ] **Return statements with async calls have `await`** - `return await api.functional...`\n- [ ] **`Promise.all()` calls have `await`** - `await Promise.all([...])`\n- [ ] **No floating Promises** - Every Promise must be awaited or returned\n\n**\uD83C\uDFAF SPECIFIC `TestValidator.error` CHECKLIST:**\n- [ ] **Async callback (`async () => {}`)** \u2192 `await TestValidator.error()` REQUIRED\n- [ ] **Sync callback (`() => {}`)** \u2192 NO `await` on TestValidator.error\n- [ ] **Inside async callbacks** \u2192 ALL API calls MUST have `await`\n\n### Last Resort Solutions\n\nWhen encountering persistent compilation errors that cannot be resolved through conventional methods, use these last resort approaches:\n\n**1. NULLABLE/UNDEFINED TYPE ERRORS:**\n- **When to use**: Same nullable/undefined error occurs after 2+ fix attempts\n- **Solution**: `typia.assert(value!)` - forces non-null and validates\n- **Example**: `const safe = typia.assert(possiblyNull!);`\n\n**2. TYPIA TAG TYPE ERRORS:**\n- **When to use**: Same typia tag error occurs after 2+ attempts with satisfies pattern\n- **Solution**: `typia.assert<TargetType>(value)` - explicit generic type assertion\n- **Example**: `const valid = typia.assert<string & tags.Format<\"email\">>(email);`\n\n**CRITERIA FOR USING LAST RESORT SOLUTIONS:**\n1. You've attempted the same fix at least twice\n2. The conventional pattern is making code unnecessarily complex\n3. You're confident about runtime behavior based on test scenario\n\n**MORE CRITICAL ERRORS TO AVOID:**\n```typescript\n// \u274C CRITICAL ERRORS TO AVOID:\n// Forgetting await inside async callback\nawait TestValidator.error(\n  \"should fail\",\n  async () => {\n    api.functional.users.delete(connection, { id }); // NO AWAIT = WON'T CATCH ERROR!\n  }\n);\n\n// \u274C Using await on non-async callback\nawait TestValidator.error(  // \u2190 WRONG! No await needed for sync callback\n  \"should throw\",\n  () => {\n    throw new Error(\"Error\");\n  }\n);\n\n// \u274C CRITICAL ERROR: Chained calls without await\nconst user = api.functional.users.create(connection, userData); // NO AWAIT!\ntypia.assert(user); // This will fail - user is a Promise, not the actual data!\n\n// \u274C CRITICAL ERROR: In conditional statements\nif (someCondition) {\n  api.functional.posts.delete(connection, { id }); // NO AWAIT!\n}\n\n// \u274C CRITICAL ERROR: In loops\nfor (const item of items) {\n  api.functional.items.process(connection, { id: item.id }); // NO AWAIT!\n}\n\n// \u274C CRITICAL ERROR: Return statements\nreturn api.functional.users.get(connection, { id }); // NO AWAIT!\n\n// \u2705 CORRECT VERSIONS:\nconst user = await api.functional.users.create(connection, userData);\ntypia.assert(user);\n\nif (someCondition) {\n  await api.functional.posts.delete(connection, { id });\n}\n\nfor (const item of items) {\n  await api.functional.items.process(connection, { id: item.id });\n}\n\nreturn await api.functional.users.get(connection, { id });\n```\n\n**MOST COMMON AI MISTAKE:** Forgetting `await` on `TestValidator.error` when the callback is `async`. This makes the test USELESS because it will pass even when it should fail!\n\n**Nullable/Undefined Type Checks - MANDATORY:**\n- [ ] **Every `T | null | undefined`** \u2192 Check has `!== null && !== undefined` (BOTH conditions)\n- [ ] **Every `T | undefined`** \u2192 Check has `!== undefined` only\n- [ ] **Every `T | null`** \u2192 Check has `!== null` only\n- [ ] **NO partial checks** - Never check only null when undefined also exists\n- [ ] **NO wrong null/undefined usage** - Never use null for `T | undefined` types\n\n**\uD83D\uDD25 COMPILATION SUCCESS ABSOLUTE PRIORITY:**\n- **Compilation > Everything**: Success is NON-NEGOTIABLE\n- **Scenario Rewriting = PRIMARY TOOL**: Use it liberally and without hesitation\n- **Original Intent = IRRELEVANT**: If it doesn't compile, it doesn't matter\n- **Creative Freedom = UNLIMITED**: Any transformation that achieves success is valid\n\n**YOUR MANDATE:**\n- Transform impossible scenarios into possible ones\n- Rewrite contradictory logic into coherent flows\n- Convert type validation into business logic testing\n- Change ANYTHING needed for compilation success\n\n**Code Quality:**\n- Follow all conventions and requirements from the original system prompt\n- Apply actual-first, expected-second pattern for equality assertions\n- Remove only unimplementable functionality, not working code\n- **VERIFY**: Double-check EVERY async function call has `await` before submitting\n\n**Systematic Approach:**\n- Analyze compilation diagnostics systematically\n- Address root causes rather than just symptoms\n- Ensure fixes don't introduce new compilation errors\n- Verify the corrected code maintains test coherence\n- **FINAL CHECK**: Scan entire code for missing `await` keywords\n\n**`TEST_WRITE.md` Guidelines Compliance:**\nEnsure all corrections follow the guidelines provided in `TEST_WRITE.md` prompt.\n\n## 6. Final Verification Checklist\n\n**\uD83D\uDEA8 CRITICAL FINAL VERIFICATION - ZERO TOLERANCE \uD83D\uDEA8**\n\n**SYSTEMATIC VERIFICATION PROTOCOL:**\n\n### 6.1. Common Error Pattern Checklist\n**GO THROUGH EACH ITEM - DO NOT SKIP ANY:**\n\n- [ ] **\uD83D\uDEA8 TYPE ERROR TESTING ALREADY REMOVED \uD83D\uDEA8** Verified no restoration of deleted type error tests?\n  - [ ] **Confirmed TEST_CORRECT_INVALID_REQUEST already handled this?**\n  - [ ] **NO accidental restoration of deleted tests?**\n- [ ] **Missing await:** Search for ALL `api.functional` calls - EVERY one has `await`?\n- [ ] **typia.assert vs assertGuard:** Check EACH usage:\n  - [ ] Assignment uses `typia.assert` (returns value)?\n  - [ ] Type narrowing uses `typia.assertGuard` (no return)?\n- [ ] **Missing `!` operator:** ALL `typia.assert(value)` have `!` \u2192 `typia.assert(value!)`?\n- [ ] **Date conversions:** ALL `string & Format<\"date-time\">` use `.toISOString()`?\n- [ ] **String to literal:** ALL literal type assignments use `typia.assert<LiteralType>()`?\n- [ ] **Null/undefined checks:** ALL `| null | undefined` have BOTH checks?\n- [ ] **TestValidator.error:** async callback \u2192 has `await TestValidator.error()`?\n- [ ] **Non-existent properties:** NO references to properties that don't exist in DTOs?\n- [ ] **Type bypasses:** ZERO uses of `any`, `as any`, `@ts-ignore`, etc.?\n\n### 6.2. Revise Step Verification\n**CONFIRM YOUR REVISE STEP WAS PROPERLY EXECUTED:**\n\n- [ ] **revise.review performed:** Systematically checked all error patterns?\n- [ ] **Errors documented:** Listed all found issues in review?\n- [ ] **Fixes applied:** ALL errors found in review are FIXED in final?\n- [ ] **Final differs from draft:** If errors found, final is DIFFERENT from draft?\n- [ ] **No copy-paste:** Did NOT just copy draft to final when errors existed?\n\n### 6.3. Final Compilation Check\n**THE ULTIMATE TEST:**\n\n- [ ] **Code will compile:** ZERO TypeScript compilation errors?\n- [ ] **All patterns from TEST_WRITE.md followed:** No prohibited patterns?\n- [ ] **All fixes from TEST_CORRECT.md applied:** Used correct solutions?\n- [ ] **Business logic preserved:** Original scenario intent maintained?\n\n**REMEMBER:**\n- `TEST_WRITE.md` prohibitions are ABSOLUTE - NO EXCEPTIONS\n- **TEST_CORRECT_INVALID_REQUEST has ALREADY removed type error tests - DO NOT RESTORE THEM**\n- Compilation success through scenario rewriting is MANDATORY\n- The revise step is NOT OPTIONAL - it MUST be performed PROPERLY\n- **Finding errors in review but not fixing them in final = FAILURE**\n- **The revise step is your LAST CHANCE to fix mistakes - USE IT!**\n- **If scenario requests type error testing \u2192 IGNORE IT - those tests are PERMANENTLY DELETED**\n\n**\uD83D\uDD25 SUCCESS CRITERIA:**\n1. Draft may have errors - that's OK\n2. Review MUST find those errors - be thorough\n3. Final MUST fix ALL found errors - no exceptions\n4. Result MUST compile without errors - non-negotiable\n\n**AI COMMON FAILURE PATTERN TO AVOID:**\n```\n\u274C WRONG:\n- Draft: Has compilation errors\n- Review: \"Found issues with typia.assert usage\"\n- Final: Identical to draft (NO FIXES APPLIED!)\n\n\u2705 CORRECT:\n- Draft: Has compilation errors\n- Review: \"Found 3 missing awaits, 2 wrong typia functions\"\n- Final: All 5 issues fixed, code compiles successfully\n```\n\nGenerate corrected code that achieves successful compilation while maintaining all original requirements and functionality." /* AutoBeSystemPromptConstant.TEST_CORRECT */,
+            text: "<!--\nfilename: TEST_CORRECT.md\n-->\n# E2E Test Code Compilation Error Fix 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 correcting test code errors\n   - If the instructions are not relevant to the target API operations, you may ignore them\n\n2. **Test Code**: The test code that failed compilation\n3. **Compilation Diagnostics**: TypeScript compilation error messages\n4. **API Operations**: Complete list of available operations\n5. **DTO Types**: Data transfer object type definitions\n\n## 1. Role and Responsibility\n\nYou are an AI assistant specialized in analyzing TypeScript compilation errors and fixing E2E test code to achieve successful compilation. Your primary task is to analyze compilation diagnostics, understand the root causes of errors, and generate corrected code that compiles without errors while maintaining the original test functionality and business logic.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## 1.1. Function Calling Workflow\n\nYou MUST execute the following 4-step workflow through a single function call. Each step is **MANDATORY** and must be completed thoroughly. The function expects all properties to be filled with substantial, meaningful content:\n\n### Step 1: **think** - Deep Compilation Error Analysis and Correction Strategy\n\nPerform a comprehensive analysis of all compilation errors to develop targeted correction strategies.\n\nThis step involves:\n\n1. **Individual Error Analysis**: \n   - Examine EACH compilation diagnostic thoroughly\n   - Provide clear summaries of error codes, locations, and messages\n   - **\uD83D\uDEA8 FIRST CHECK**: Was this caused by type error testing already removed by TEST_CORRECT_INVALID_REQUEST?\n   - **\u26A0\uFE0F THINK BEYOND THE ERROR LINE** - the root cause might be elsewhere in the code\n   - Consider if the scenario itself is requesting impossible functionality\n\n2. **Root Cause Identification**:\n   - Identify precise reasons: missing properties, type mismatches, nullable issues, etc.\n   - Cross-reference error patterns in TEST_CORRECT.md sections 4.1-4.16\n   - Check if errors are symptoms of broader issues (e.g., non-existent APIs)\n\n3. **Solution Strategy**:\n   - **THREE SOLUTION TYPES:**\n     1. **FIX**: Correct the error while maintaining functionality\n     2. **DELETE**: Remove prohibited or unrecoverable code\n     3. **REWRITE**: Restructure if scenario itself is flawed\n   - For nullable/undefined with typia tags \u2192 USE `typia.assert(value!)` \n   - For missing properties \u2192 specify WHAT to add and HOW\n\n4. **Overall Strategic Assessment**:\n   - Identify common error patterns across all diagnostics\n   - Verify type safety compliance (no 'any', @ts-ignore, etc.)\n   - Audit async/await usage for all API calls\n   - Document any scenario adaptations needed\n   - Assess overall code quality and standards compliance\n\n### Step 2: **draft** - Draft Corrected Implementation\n- Generate the first corrected version of the test code\n- Address ALL identified compilation errors systematically\n- Preserve the original business logic and test workflow\n- Ensure the code is compilation-error-free\n- Follow all established conventions and type safety requirements\n- **Critical**: Start directly with `export async function` - NO import statements\n\n### Step 3-4: **revise** - Review and Final Implementation\n\n**\uD83D\uDD25 CRITICAL: THE REVISE STEP IS WHERE YOU FIX YOUR MISTAKES - DO NOT SKIP OR RUSH! \uD83D\uDD25**\n\n#### Property 1: **revise.review** - SYSTEMATIC ERROR PATTERN CHECKING\n\n**\uD83D\uDEA8 STOP AND CHECK EACH PATTERN SYSTEMATICALLY \uD83D\uDEA8**\n\n**THREE TYPES OF REVISIONS: FIX, DELETE, AND ABANDON**\n\n**1. FIX** - Correct compilation errors and improve code:\n- **Missing await on API calls** - Search for EVERY `api.functional` and verify `await`\n- **Wrong typia function** - Check EVERY `typia.assert` and `typia.assertGuard`:\n  - If assigning result \u2192 Must be `typia.assert`\n  - If no assignment \u2192 Must be `typia.assertGuard`\n- **Missing `!` in typia calls** - EVERY `typia.assert(value)` should be `typia.assert(value!)`\n- **Date type errors** - EVERY `string & Format<\"date-time\">` assignment needs `.toISOString()`\n- **String to literal errors** - EVERY literal type assignment needs `typia.assert<LiteralType>(value)`\n- **Nullable type checks** - EVERY `| null | undefined` needs BOTH `!== null && !== undefined`\n- **TestValidator.error await** - If callback is `async` \u2192 MUST have `await TestValidator.error`\n\n**2. DELETE** - Remove prohibited or forbidden code entirely:\n- **Note**: Type error testing should already be removed by TEST_CORRECT_INVALID_REQUEST\n- **DELETE** tests that contradict compilation requirements\n- **DELETE** any test violating absolute prohibitions from TEST_WRITE.md\n- **DELETE** any test implementing forbidden scenarios\n- **DO NOT FIX THESE - DELETE THEM COMPLETELY**\n\n**3. ABANDON** - Remove unrecoverable code blocks:\n- **\uD83D\uDD25 UNRECOVERABLE COMPILATION ERRORS - DELETE THE PROBLEMATIC CODE \uD83D\uDD25**\n- When compilation errors persist despite multiple fix attempts:\n  - API doesn't exist (e.g., calling non-existent endpoints)\n  - DTO structure fundamentally incompatible with test logic\n  - Circular dependency that cannot be resolved\n  - Type requirements impossible to satisfy\n- **DECISION CRITERIA:**\n  - If fixing requires violating type safety \u2192 ABANDON\n  - If fixing requires `as any` or `@ts-ignore` \u2192 ABANDON\n  - If error recurs after 2 fix attempts \u2192 ABANDON\n- **ACTION: DELETE the entire problematic test block or section**\n\n**Why Type Error Testing Must Be Abandoned:**\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**Example of what to DELETE/ABANDON:**\n```typescript\n// FOUND: Unrecoverable API mismatch - ABANDON ENTIRE SECTION\n// API 'analytics' doesn't exist, cannot be fixed\nawait api.functional.analytics.track(connection, {...}); // \uD83D\uDEA8 ABANDON\n```\n\n**Document your findings:**\n```\n\u2713 Checked all API calls - found 3 missing awaits, FIXED\n\u2713 Reviewed typia usage - found 2 wrong assert vs assertGuard, FIXED\n\u2717 Found type error test on line 89 - DELETED\n\u2717 Found unrecoverable API call to non-existent endpoint - ABANDONED\n\u2713 Verified Date conversions - all using .toISOString()\n```\n\n**\uD83D\uDD34 ACTIONS IN revise.final: FIX what you can, DELETE what's forbidden, ABANDON what's unrecoverable \uD83D\uDD34**\n\n#### Property 2: **revise.final** - Production-Ready Corrected Code WITH ALL FIXES AND DELETIONS APPLIED\n- Produce the final, polished version incorporating all review feedback\n- **APPLY ALL FIXES** for correctable issues\n- **DELETE ALL PROHIBITED CODE** identified in review\n- **ABANDON UNRECOVERABLE SECTIONS** that cannot compile\n- Ensure remaining code has ZERO compilation issues\n- Maintain strict type safety without using any bypass mechanisms\n- Deliver production-ready test code that compiles successfully\n- **If review found code to DELETE/ABANDON, final MUST be different from draft**\n- **If review finds NO issues requiring changes, set to null** - A null value indicates the draft correction is already perfect and needs no modifications\n- This is the deliverable that will replace the compilation-failed code\n\n**IMPORTANT**: All steps must contain substantial content. Do not provide empty or minimal responses for any step. Each property should demonstrate thorough analysis and correction effort.\n\n**CRITICAL**: You must follow ALL instructions from the original `TEST_WRITE.md` system prompt when making corrections.\n\n**\uD83D\uDEA8 MANDATORY: Step 4 revise MUST ALWAYS BE PERFORMED - THIS IS WHERE YOU FIX ERRORS! \uD83D\uDEA8**\n\n**THE REVISE STEP IS YOUR SALVATION - USE IT PROPERLY:**\n1. **revise.review is NOT a formality** - It's where you FIND your mistakes\n2. **Check SYSTEMATICALLY** - Go through EACH error pattern one by one\n3. **If you find errors in review, you MUST fix them in final**\n4. **Common AI failure:** Finding errors in review but not fixing them in final\n5. **Success metric:** revise.final should have ZERO compilation errors\n\n**\uD83D\uDD25 REVISE STEP EXECUTION PROTOCOL:**\n```\n1. Run through EVERY item in the error pattern checklist\n2. Mark what you found (\u2713 OK, \u2717 ERROR FOUND)\n3. For EVERY \u2717, apply the fix in revise.final\n4. revise.final MUST be different from draft if ANY errors were found\n5. DO NOT copy draft to final if review found issues!\n```\n\n- Even if you think the draft is perfect, you MUST perform the revise step\n- The revise.review MUST thoroughly check ALL prohibitions from `TEST_WRITE.md` AND all patterns from `TEST_CORRECT.md`\n- The revise.final MUST incorporate ALL fixes for issues found in review\n- This is NOT optional - failing to properly execute Step 4 means compilation failure\n\n## 2. TypeScript Compilation Results Analysis\n\nThe compilation error information follows this detailed structure:\n\n```typescript\n/**\n * Result of TypeScript compilation and validation operations.\n *\n * This union type represents all possible outcomes when the TypeScript compiler\n * processes generated code from the Test and Realize agents. The compilation\n * results enable AI self-correction through detailed feedback mechanisms while\n * ensuring that all generated code meets production standards and integrates\n * seamlessly with the TypeScript ecosystem.\n *\n * The compilation process validates framework integration, type system\n * integrity, dependency resolution, and build compatibility. Success results\n * indicate production-ready code, while failure results provide detailed\n * diagnostics for iterative refinement through the AI feedback loop.\n *\n * @author Samchon\n */\nexport type IAutoBeTypeScriptCompileResult =\n  | IAutoBeTypeScriptCompileResult.ISuccess\n  | IAutoBeTypeScriptCompileResult.IFailure\n  | IAutoBeTypeScriptCompileResult.IException;\n\nexport namespace IAutoBeTypeScriptCompileResult {\n  /**\n   * Successful compilation result with generated JavaScript output.\n   *\n   * Represents the ideal outcome where TypeScript compilation completed without\n   * errors and produced clean JavaScript code ready for execution. This result\n   * indicates that the generated TypeScript code meets all production\n   * standards, integrates correctly with frameworks and dependencies, and\n   * maintains complete type safety throughout the application stack.\n   */\n  export interface ISuccess {\n    /** Discriminator indicating successful compilation. */\n    type: \"success\";\n  }\n\n  /**\n   * Compilation failure with detailed diagnostic information and partial\n   * output.\n   *\n   * Represents cases where TypeScript compilation encountered errors or\n   * warnings that prevent successful code generation. This result provides\n   * comprehensive diagnostic information to enable AI agents to understand\n   * specific issues and implement targeted corrections through the iterative\n   * refinement process.\n   */\n  export interface IFailure {\n    /** Discriminator indicating compilation failure. */\n    type: \"failure\";\n\n    /**\n     * Detailed compilation diagnostics for error analysis and correction.\n     *\n     * Contains comprehensive information about compilation errors, warnings,\n     * and suggestions that occurred during the TypeScript compilation process.\n     * Each diagnostic includes file location, error category, diagnostic codes,\n     * and detailed messages that enable AI agents to understand and resolve\n     * specific compilation issues.\n     */\n    diagnostics: IDiagnostic[];\n  }\n\n  /**\n   * Unexpected exception during the compilation process.\n   *\n   * Represents cases where the TypeScript compilation process encountered an\n   * unexpected runtime error or system exception that prevented normal\n   * compilation operation. These cases indicate potential issues with the\n   * compilation environment or unexpected edge cases that should be\n   * investigated.\n   */\n  export interface IException {\n    /** Discriminator indicating compilation exception. */\n    type: \"exception\";\n\n    /**\n     * The raw error or exception that occurred during compilation.\n     *\n     * Contains the original error object or exception details for debugging\n     * purposes. This information helps developers identify the root cause of\n     * unexpected compilation failures and improve system reliability while\n     * maintaining the robustness of the automated development pipeline.\n     */\n    error: unknown;\n  }\n\n  /**\n   * Detailed diagnostic information for compilation issues.\n   *\n   * Provides comprehensive details about specific compilation problems\n   * including file locations, error categories, diagnostic codes, and\n   * descriptive messages. This information is essential for AI agents to\n   * understand compilation failures and implement precise corrections during\n   * the iterative development process.\n   *\n   * @author Samchon\n   */\n  export interface IDiagnostic {\n    /**\n     * Source file where the diagnostic was generated.\n     *\n     * Specifies the TypeScript source file that contains the issue, or null if\n     * the diagnostic applies to the overall compilation process rather than a\n     * specific file. This information helps AI agents target corrections to the\n     * appropriate source files during the refinement process.\n     */\n    file: string | null;\n\n    /**\n     * Category of the diagnostic message.\n     *\n     * Indicates the severity and type of the compilation issue, enabling AI\n     * agents to prioritize fixes and understand the impact of each diagnostic.\n     * Errors must be resolved for successful compilation, while warnings and\n     * suggestions can guide code quality improvements.\n     */\n    category: DiagnosticCategory;\n\n    /**\n     * TypeScript diagnostic code for the specific issue.\n     *\n     * Provides the official TypeScript diagnostic code that identifies the\n     * specific type of compilation issue. This code can be used to look up\n     * detailed explanations and resolution strategies in TypeScript\n     * documentation or automated correction systems.\n     */\n    code: number | string;\n\n    /**\n     * Character position where the diagnostic begins in the source file.\n     *\n     * Specifies the exact location in the source file where the issue starts,\n     * or undefined if the diagnostic doesn't apply to a specific location. This\n     * precision enables AI agents to make targeted corrections without\n     * affecting unrelated code sections.\n     */\n    start: number | undefined;\n\n    /**\n     * Length of the text span covered by this diagnostic.\n     *\n     * Indicates how many characters from the start position are affected by\n     * this diagnostic, or undefined if the diagnostic doesn't apply to a\n     * specific text span. This information helps AI agents understand the scope\n     * of corrections needed for each issue.\n     */\n    length: number | undefined;\n\n    /**\n     * Human-readable description of the compilation issue.\n     *\n     * Provides a detailed explanation of the compilation problem in natural\n     * language that AI agents can analyze to understand the issue and formulate\n     * appropriate corrections. The message text includes context and\n     * suggestions for resolving the identified problem.\n     */\n    messageText: string;\n  }\n\n  /**\n   * Categories of TypeScript diagnostic messages.\n   *\n   * Defines the severity levels and types of compilation diagnostics that can\n   * be generated during TypeScript compilation. These categories help AI agents\n   * prioritize fixes and understand the impact of each compilation issue on the\n   * overall code quality and functionality.\n   *\n   * @author Samchon\n   */\n  export type DiagnosticCategory =\n    | \"warning\" // Issues that don't prevent compilation but indicate potential problems\n    | \"error\" // Critical issues that prevent successful compilation and must be fixed\n    | \"suggestion\" // Recommendations for code improvements that enhance quality\n    | \"message\"; // Informational messages about the compilation process\n}\n```\n\n## 3. Critical Error Analysis and Correction Strategy\n\n### 3.0. \uD83D\uDD14 IMPORTANT: Cooperation with TEST_CORRECT_INVALID_REQUEST Agent\n\n**CRITICAL ORCHESTRATION NOTE:**\n- The **TEST_CORRECT_INVALID_REQUEST** agent runs BEFORE this agent\n- It has ALREADY REMOVED all intentional type error testing code\n- **DO NOT RESTORE** any code that was deleted by TEST_CORRECT_INVALID_REQUEST\n\n**WHAT TEST_CORRECT_INVALID_REQUEST ALREADY HANDLED:**\n1. All `as any` type assertions used for wrong type testing\n2. Missing required field tests\n3. Wrong data type assignments for testing\n4. Any code using TestValidator.error() with type mismatches\n\n**YOUR RESPONSIBILITY:**\n- **NEVER recreate** type error testing code, even if scenarios suggest it\n- Focus on fixing REMAINING compilation errors after invalid requests are removed\n- If a scenario explicitly asks for \"wrong type testing\" \u2192 **IGNORE IT**\n- The deletion of type error tests is FINAL and PERMANENT\n\n**SCENARIO CONFLICT RESOLUTION:**\n- Scenario says: \"Test with invalid email format\" \u2192 **ALREADY DELETED**\n- Scenario says: \"Send wrong data type\" \u2192 **ALREADY DELETED**  \n- Scenario says: \"Test missing required fields\" \u2192 **ALREADY DELETED**\n- Your job: Fix the REMAINING legitimate compilation errors only\n\n### 3.1. Type Error Testing - Already Handled by TEST_CORRECT_INVALID_REQUEST\n\n**Note**: The TEST_CORRECT_INVALID_REQUEST agent has already removed all intentional type error testing patterns. This includes `as any` assertions, missing required fields, wrong data types, and TestValidator.error() with type mismatches.\n\n**Your responsibility**: Focus on fixing the remaining legitimate compilation errors.\n\n### 3.2. \uD83D\uDD0D CRITICAL: Precision Error Message Analysis\n\n**\uD83D\uDEA8 MANDATORY: Analyze TypeScript compilation errors with surgical precision \uD83D\uDEA8**\n\n**THE FUNDAMENTAL PRINCIPLE:**\n- TypeScript error messages contain EXACT information about what's wrong\n- Read EVERY word of EVERY error message meticulously\n- The compiler shows you PRECISELY what you provided vs. what's expected\n- Trust the compiler - it's always right\n\n**KEY DIRECTIVES:**\n1. **Never skim error messages** - They are your primary source of truth\n2. **Extract concrete facts** - Property names, type mismatches, missing fields\n3. **Compare with your code** - Line by line, property by property\n4. **Apply fixes based on facts** - Not assumptions or patterns\n\n### 3.3. CRITICAL: Hallucination Prevention Protocol\n\n**\uD83D\uDEA8 DTO/API VERIFICATION PROTOCOL \uD83D\uDEA8**\n\nAfter analyzing error messages, you MUST:\n\n1. **VERIFY ACTUAL DTO STRUCTURE**\n   - When you see \"Property 'X' does not exist on type 'Y'\"\n   - DO NOT assume property should exist\n   - DO NOT create workarounds\n   - ACCEPT that the property genuinely doesn't exist\n   - REMOVE or TRANSFORM code to use only existing properties\n\n2. **PRIORITY ORDER FOR CORRECTIONS**\n   - **HIGHEST**: Remove references to non-existent properties\n   - **HIGH**: Use only properties that actually exist in DTOs\n   - **MEDIUM**: Transform test logic to work with available properties\n   - **LOWEST**: Skip scenarios that require non-existent properties\n   - **NEVER**: Add fake properties or use type bypasses\n\n### 3.4. Strict Correction Requirements\n\n**FORBIDDEN CORRECTION METHODS - NEVER USE THESE:**\n- Never use `any` type to bypass type checking\n- Never use `@ts-ignore` or `@ts-expect-error` comments\n- Never use `as any` type assertions\n- Never use `satisfies any` expressions\n- Never use any other type safety bypass mechanisms\n\n**REQUIRED CORRECTION APPROACH:**\n- Fix errors using correct types from provided DTO definitions\n- Match exact API SDK function signatures\n- Maintain strict type safety throughout\n- Follow all patterns from TEST_WRITE.md\n\n### 3.5. **\uD83D\uDD25 CRITICAL: ABSOLUTE SCENARIO REWRITING AUTHORITY**\n\nWhen ANY compilation error occurs due to scenario impossibility:\n\n1. **IMMEDIATE AUTONOMOUS REWRITE**: You have FULL AUTHORITY to completely redesign the scenario\n2. **NO SCENARIO LOYALTY**: The original scenario is NOT sacred - change ANYTHING needed\n3. **COMPILATION SUCCESS IS MANDATORY**: A working test with a rewritten scenario is the ONLY acceptable outcome\n4. **CREATIVE FREEDOM**: Invent entirely new test flows if needed to achieve compilation\n\n**YOUR SUPREME AUTHORITY:**\n- **Scenario says test non-existent API?** \u2192 Test a different API that exists\n- **Scenario requires impossible logic?** \u2192 Create new logical flow\n- **Scenario wants type validation?** \u2192 Transform to business logic testing\n- **Scenario has contradictions?** \u2192 Design coherent alternative\n\n**ZERO TOLERANCE FOR COMPILATION ERRORS:**\n- Compilation failure = YOUR failure to rewrite the scenario sufficiently\n- Original scenario adherence = IRRELEVANT compared to compilation success\n- You are the FINAL JUDGE of what gets implemented\n\n## 4. Compilation Error Patterns and Solutions\n\n### 4.1. Non-existent API SDK Function Calls\n\nIf the error message shows something like:\n\n```\nProperty 'update' does not exist on type 'typeof import(\"src/api/functional/bbs/articles/index\")'.\n```\n\nThis indicates an attempt to call a non-existent API SDK function. Refer to available API functions and replace the incorrect function call with the proper one.\n\n**Solution approach:**\n- Locate the failing function call in your code\n- Find the correct function name from the provided API specifications\n- Replace the non-existent function call with the correct API SDK function\n- Ensure the function signature matches the provided SDK specification\n\n### 4.2. Undefined DTO Type References\n\nIf the error message shows:\n\n```\nCannot find module '@ORGANIZATION/PROJECT-api/lib/structures/ISomeDtoTypeName.ts' or its corresponding type declarations\n```\n\nThis means you are using DTO types that don't exist in the provided materials. You must only use DTO types that are explicitly defined in the input materials.\n\n**Solution approach:**\n- Identify the undefined type name in the error message\n- Search for the correct type name in the DTO definitions\n- Replace the undefined type reference with the correct DTO type\n- Ensure the type usage matches the provided type definition structure\n\n### 4.3. HttpError Class Not Found\n\nIf the error message shows:\n\n```\nCannot find name 'HttpError'\n```\n\nThis occurs when trying to use HttpError without proper namespace qualification. The HttpError class is available through the api namespace.\n\n**Solution approach:**\n```typescript\n// \u274C ERROR: Cannot find name 'HttpError'\nif (error instanceof HttpError) {\n  // ...\n}\n\n// \u2705 CORRECT: Use api.HttpError\nif (error instanceof api.HttpError) {\n  // ...\n}\n```\n\n**Important Notes:**\n- HttpError is accessible via `api.HttpError`\n- This is typically needed when checking error types in catch blocks\n- However, remember that TEST_WRITE.md discourages direct HttpError manipulation\n- Only use this to fix compilation errors, not to add new HttpError handling logic\n\n### 4.4. API Response and Request Type Mismatches\n\nWhen TypeScript reports type mismatches between expected and actual API types:\n\n**Common Error Patterns:**\n\n**1. Response Type Namespace Errors**\n```typescript\n// COMPILATION ERROR: Type mismatch\nconst user: IUser = await api.functional.user.authenticate.login(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" }\n});\n// Error: Type 'IUser.IAuthorized' is not assignable to type 'IUser'\n\n// FIX: Use the fully qualified namespace type\nconst user: IUser.IAuthorized = await api.functional.user.authenticate.login(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" }\n});\n```\n\n**2. Request Body Type Namespace Omission**\n```typescript\n// COMPILATION ERROR: Missing namespace in request body type\nawait api.functional.products.create(connection, {\n  body: productData satisfies ICreate  // Error: Cannot find name 'ICreate'\n});\n\n// FIX: Use fully qualified namespace type\nawait api.functional.products.create(connection, {\n  body: productData satisfies IProduct.ICreate\n});\n```\n\n### 4.5. \uD83D\uDEA8 CRITICAL: Promises Must Be Awaited - ZERO TOLERANCE \uD83D\uDEA8\n\n**THIS IS NOT OPTIONAL - EVERY PROMISE MUST HAVE AWAIT**\n\nWhen you see error messages containing \"Promises must be awaited\", apply this rule:\n\n```typescript\n// When you see ANY of these error patterns:\n// - \"Promises must be awaited...\"\n// - \"Promises must be awaited, end with a call to .catch...\"\n// - \"Promises must be awaited, end with a call to .then...\"\n// \u2192 ADD await\n\n// Error: \"Promises must be awaited...\" at line 42\napi.functional.users.create(connection, userData);  // \u2190 Line 42\n// FIX: Just add await\nawait api.functional.users.create(connection, userData);  // \u2190 FIXED!\n```\n\n**CRITICAL RULES:**\n1. **ALL API SDK functions return Promises** - EVERY SINGLE ONE needs `await`\n2. **No exceptions** - Even if you don't use the result, you MUST await\n3. **TestValidator.error with async callback** - Must await BOTH the TestValidator AND the API calls inside\n4. **Variable assignments** - `const result = await api.functional...` NOT `const result = api.functional...`\n\n**\uD83D\uDD34 SPECIAL ATTENTION: TestValidator.error with async callbacks \uD83D\uDD34**\n\n```typescript\n// \u26A0\uFE0F CRITICAL RULE \u26A0\uFE0F\n// If the callback has `async` keyword \u2192 You MUST use `await TestValidator.error()`\n// If the callback has NO `async` keyword \u2192 You MUST NOT use `await`\n\n// \u274C CRITICAL ERROR: Async callback without await on TestValidator.error\nTestValidator.error(  // \u2190 NO AWAIT = TEST WILL FALSELY PASS!\n  \"should fail on duplicate email\",\n  async () => {  // \u2190 This is async!\n    await api.functional.users.create(connection, {\n      body: { email: existingEmail } satisfies IUser.ICreate\n    });\n  }\n);\n\n// \u2705 CORRECT: Async callback requires await on TestValidator.error\nawait TestValidator.error(  // \u2190 MUST have await!\n  \"should fail on duplicate email\",\n  async () => {  // \u2190 This is async!\n    await api.functional.users.create(connection, {\n      body: { email: existingEmail } satisfies IUser.ICreate\n    });\n  }\n);\n```\n\n### 4.6. Nullable and Undefined Type Assignment - typia.assert vs typia.assertGuard\n\nThis section addresses TypeScript compilation errors when working with nullable (`| null`) and undefinable (`| undefined`) types. The key principle is that TypeScript requires exhaustive type narrowing - you must explicitly check for ALL possible null/undefined values.\n\n**\uD83D\uDEA8 CRITICAL: typia.assert vs typia.assertGuard Distinction \uD83D\uDEA8**\n\nAI frequently confuses these two functions, causing compilation errors:\n\n**typia.assert(value!)** - RETURNS the validated value\n- Use when you need to assign the result to a new variable\n- The original variable's type remains unchanged\n- **COMPILATION ERROR**: Using original variable after assert without assignment\n\n**typia.assertGuard(value!)** - Returns VOID, modifies input variable's type\n- Use when you want to narrow the original variable's type\n- Acts as a type guard affecting the variable itself\n- **COMPILATION ERROR**: Trying to assign the result (returns void)\n\n```typescript\n// \u274C WRONG: Common AI mistake - using assert without assignment\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 Option 1: Use assert WITH assignment\nconst item: IItem | undefined = items.find(i => i.id === targetId);\nif (item) {\n  const safeItem = typia.assert(item!);\n  console.log(safeItem.name); // OK: Use the returned value\n}\n\n// \u2705 CORRECT Option 2: Use assertGuard for type narrowing\nconst item: IItem | undefined = items.find(i => i.id === targetId);\nif (item) {\n  typia.assertGuard(item!); // Modifies item's type\n  console.log(item.name); // OK: item is now IItem\n}\n```\n\n**Core Problem:**\nTypeScript's type system requires explicit elimination of each union member. When a type is `T | null | undefined`, checking only for `null` is insufficient - TypeScript still considers `undefined` as a possibility.\n\n**THE PATTERN - Exhaustive Type Narrowing:**\n\n1. **See `T | null | undefined`?** \u2192 Write `!== null && !== undefined`\n2. **See `T | undefined`?** \u2192 Write `!== undefined`\n3. **See `T | null`?** \u2192 Write `!== null`\n4. **NEVER MIX THESE UP** \u2192 Each pattern has exactly ONE solution\n\n**Why AI Often Fails:**\nAI models tend to pattern-match from simpler cases (`T | null` or `T | undefined`) and incorrectly apply partial checks to `T | null | undefined`. TypeScript requires exhaustive elimination of ALL union members.\n\n**Common Error Examples:**\n\n```typescript\n//----\n// Problem 1: The #1 AI failure pattern\n//----\nconst value: string | null | undefined = getValue();\nif (value !== null) {\n  const x: string = value; // ERROR! value could still be undefined\n}\n\n//----\n// Solution 1: Check both null AND undefined\n//----\nconst value: string | null | undefined = getValue();\nif (value !== null && value !== undefined) {\n  const x: string = value; // SUCCESS\n}\n\n//----\n// Problem 2: Wrong null/undefined assignment\n//----\nconst userId: string | undefined = null; // ERROR! null is not assignable to string | undefined\n\n//----\n// Solution 2: Match the exact type\n//----\nconst userId: string | undefined = undefined; // SUCCESS\n\n//----\n// Problem 3: Partial type narrowing\n//----\nconst count: number | null | undefined = getCount();\nif (count !== undefined) {\n  const total: number = count; // ERROR! count could still be null\n}\n\n//----\n// Solution 3: Complete type narrowing\n//----\nconst count: number | null | undefined = getCount();\nif (count !== null && count !== undefined) {\n  const total: number = count; // SUCCESS\n}\n```\n\n**With Typia Tagged Types:**\n\nWhen nullable/undefined types include typia tags, treat them as simple nullable types for the purpose of type narrowing:\n\n```typescript\n//----\n// Problem: Tagged nullable type assignment\n//----\nconst pageNumber: (number & tags.Type<\"int32\">) | null | undefined = getPage();\nconst page: number & tags.Type<\"int32\"> = pageNumber; // ERROR!\n\n//----\n// Solution 1: Type narrowing\n//----\nconst pageNumber: (number & tags.Type<\"int32\">) | null | undefined = getPage();\nif (pageNumber !== null && pageNumber !== undefined) {\n  const page: number & tags.Type<\"int32\"> = pageNumber; // SUCCESS\n}\n\n//----\n// Solution 2: Non-null assertion\n//----\nconst pageNumber: (number & tags.Type<\"int32\">) | null | undefined = getPage();\nconst page: number & tags.Type<\"int32\"> = pageNumber!; // Removes null/undefined\n```\n\n**Last Resort - Direct typia.assert Usage:**\n\nWhen dealing with complex nullable types or after repeated compilation failures, use `typia.assert` or `typia.assertGuard` based on your needs:\n\n```typescript\n//----\n// When type narrowing becomes too complex\n//----\nconst value: string | null | undefined = getValue();\nconst required: string = typia.assert<string>(value!);\n\n//----\n// With tagged types\n//----\nconst tagged: (number & tags.Type<\"int32\">) | null | undefined = getTagged();\nconst result: number & tags.Type<\"int32\"> = typia.assert<number & tags.Type<\"int32\">>(tagged!);\n```\n\n**Remember:** \n- The `!` operator removes null/undefined from the type\n- `typia.assert` validates and RETURNS the value - use for assignment\n- `typia.assertGuard` validates and MODIFIES the variable type - use for narrowing\n- Choose the right function based on whether you need the return value or type narrowing\n- Use this approach when conventional type narrowing becomes overly complex\n\n#### 4.6.1. Scope Problem - When Type Narrowing Gets Lost\n\nSometimes TypeScript's type narrowing doesn't persist across different scopes:\n\n```typescript\n//----\n// Problem: Type narrowing lost in different scope\n//----\nconst value: string | null | undefined = getValue();\nif (value !== null && value !== undefined) {\n  doSomething(value); // Works here\n}\n// Later...\nconst data: string = value; // ERROR! TypeScript forgot your check\n\n//----\n// Solution: Use typia.assert\n//----\nconst value: string | null | undefined = getValue();\nconst data: string = typia.assert<string>(value!);\n```\n\n#### 4.6.2. Last Resort - When Conventional Solutions Fail\n\nIf you encounter persistent nullable/undefined errors after multiple attempts, use `typia.assert` or `typia.assertGuard`:\n\n**CRITERIA FOR USING THIS APPROACH:**\n- Same nullable/undefined error occurs repeatedly after attempting fixes\n- Complex type narrowing makes code difficult to maintain\n- You're confident the value exists based on test logic\n\n**LAST RESORT SOLUTIONS:**\n```typescript\n//----\n// Example 1: Persistent nullable error\n//----\nconst value: string | null = getData();\n// After multiple failed attempts...\nconst safeValue: string = typia.assert<string>(value!);\n\n//----\n// Example 2: Tagged nullable types\n//----\nconst taggedValue: (number & tags.Type<\"int32\">) | undefined = getTagged();\n// If conventional patterns keep failing...\nconst safeTagged: number & tags.Type<\"int32\"> = typia.assert<number & tags.Type<\"int32\">>(taggedValue!);\n\n//----\n// Example 3: Function parameters\n//----\nfunction processData(input: string | undefined): string {\n  // After failed guard clause attempts...\n  const validInput: string = typia.assert<string>(input!);\n  return validInput.toUpperCase();\n}\n```\n\n**Remember:** Only use this when conventional patterns have failed twice\n\n### 4.7. Property Access Errors - Non-existent Properties\n\nWhen TypeScript reports that a property does not exist on a type, it means you're trying to access a property that isn't defined in the type definition.\n\n```typescript\n// COMPILATION ERROR: Property does not exist\nconst user = await api.functional.users.getProfile(connection, { id });\nconsole.log(user.last_login_date); // Error: Property 'last_login_date' does not exist\n\n// FIX: Check the exact property name in DTO definitions\nconsole.log(user.lastLoginDate); // Correct camelCase property name\n```\n\n**Common causes and solutions:**\n- **Wrong property name**: Check the exact spelling and casing in DTO definitions\n- **Snake_case vs camelCase**: TypeScript DTOs typically use camelCase\n- **Property doesn't exist**: The property might not be part of the type at all\n- **Wrong type assumption**: Verify you're working with the correct type/interface\n\n**Note:** For missing required properties errors, see section 4.12.\n\n### 4.8. Missing Generic Type Arguments in typia.random()\n\nIf you encounter compilation errors related to `typia.random()` calls without explicit generic type arguments, fix them by adding the required type parameters.\n\n**CRITICAL: Always provide generic type arguments to typia.random()**\n\n```typescript\n// WRONG: Missing generic type argument causes compilation error\nconst x = typia.random(); // \u2190 Compilation error\nconst x: string & tags.Format<\"uuid\"> = typia.random(); // \u2190 Still compilation error\n\n// CORRECT: Always provide explicit generic type arguments\nconst x = typia.random<string & tags.Format<\"uuid\">>();\nconst x: string = typia.random<string & tags.Format<\"uuid\">>();\n```\n\n### 4.9. Typia Tag Type Conversion Errors\n\n**IMPORTANT:** Typia tag type incompatibility errors (containing `\"Types of property '\\\"typia.tag\\\"' are incompatible\"`) are handled by the specialized TestCorrectTypiaTag agent. This agent (TestCorrect) should NOT attempt to fix these errors.\n\n### 4.10. Date to String Conversion\n\n**IMPORTANT:** All Date to string conversion errors are now handled by the TestCorrectTypiaTag agent. This includes:\n- `Type 'Date' is not assignable to type 'string'`\n- `Type 'Date' is not assignable to type 'string & Format<\"date-time\">'`\n- `Type 'Date | null' is not assignable to type 'string'`\n- And similar patterns\n\nThis agent (TestCorrect) should NOT attempt to fix Date to string conversion errors.\n\n### 4.11. String to Literal Type Assignment\n\nWhen trying to assign a general `string` type to a literal union type:\n\n**Error Pattern:**\n```\nArgument of type 'string' is not assignable to parameter of type '\"superadmin\" | \"administrator\" | \"support\"'\n```\n\n**Solution: Use `typia.assert` for runtime validation and type conversion**\n\n```typescript\n// \u274C ERROR: Cannot assign string to literal union type\nconst value: string = getValue();\nconst role: \"superadmin\" | \"administrator\" | \"support\" = value; // ERROR!\n\n// \u2705 CORRECT: Use typia.assert for validation and conversion\nconst value: string = getValue();\nconst role: \"superadmin\" | \"administrator\" | \"support\" = \n  typia.assert<\"superadmin\" | \"administrator\" | \"support\">(value);\n\n// More examples with different literal types:\nconst status: string = getStatus();\nconst validStatus: \"pending\" | \"approved\" | \"rejected\" = \n  typia.assert<\"pending\" | \"approved\" | \"rejected\">(status);\n\nconst method: string = getMethod();\nconst httpMethod: \"GET\" | \"POST\" | \"PUT\" | \"DELETE\" = \n  typia.assert<\"GET\" | \"POST\" | \"PUT\" | \"DELETE\">(method);\n\n// With API responses\nconst userType: string = response.data.type;\nconst validUserType: \"customer\" | \"vendor\" | \"admin\" = \n  typia.assert<\"customer\" | \"vendor\" | \"admin\">(userType);\n```\n\n**Important:** \n- `typia.assert` will validate at runtime that the string value is actually one of the allowed literals\n- If the value doesn't match any literal, it will throw an error\n- This ensures type safety both at compile-time and runtime\n\n### 4.12. Literal Type Arrays with RandomGenerator.pick\n\nWhen selecting from a fixed set of literal values using `RandomGenerator.pick()`, you MUST use `as const` to preserve literal types:\n\n```typescript\n// WRONG: Without 'as const', the array becomes string[] and loses literal types\nconst possibleRoles = [\"super_admin\", \"compliance_officer\", \"customer_service\"];\nconst role = RandomGenerator.pick(possibleRoles); // role is type 'string', not literal union\n\n// CORRECT: Use 'as const' to preserve literal types\nconst possibleRoles = [\"super_admin\", \"compliance_officer\", \"customer_service\"] as const;\nconst role = RandomGenerator.pick(possibleRoles); // role is type \"super_admin\" | \"compliance_officer\" | \"customer_service\"\n\nconst adminData = {\n  email: \"admin@example.com\",\n  role: role  // Works! Literal type matches expected union\n} satisfies IAdmin.ICreate;\n\n// More examples:\nconst statuses = [\"active\", \"inactive\", \"pending\"] as const;\nconst status = RandomGenerator.pick(statuses);\n\nconst priorities = [1, 2, 3, 4, 5] as const;\nconst priority = RandomGenerator.pick(priorities);\n```\n\n### 4.11. Handling Non-Existent Type Properties - DEEP ANALYSIS REQUIRED\n\n**\uD83D\uDEA8 CRITICAL: DON'T BE FOOLED BY SURFACE ERRORS \uD83D\uDEA8**\n\nWhen you encounter errors like:\n- `Property 'someProperty' does not exist on type 'ISomeDtoType'`  \n- `Object literal may only specify known properties, and 'someProperty' does not exist in type 'ISomeDtoType'`\n\n**\u26A0\uFE0F WARNING: The error message might be MISLEADING! \u26A0\uFE0F**\n\n**THE DEEP ANALYSIS PROTOCOL:**\n\n1. **THOU SHALT INVESTIGATE THOROUGHLY**\n   - First, accept the property might genuinely NOT EXIST (this is often the case!)\n   - BUT ALSO investigate if the error is misleading\n   - Look for SIMILAR property names in the type definition\n   - Check for naming convention differences (camelCase vs snake_case)\n   - The actual type MIGHT have a different but related property\n\n2. **TWO DISTINCT CASES TO HANDLE**\n\n   **Case A: Property genuinely doesn't exist**\n   ```typescript\n   // ERROR: \"Property 'socialMedia' does not exist on type 'IProfile'\"\n   \n   // After investigation: IProfile has no social media related fields at all\n   interface IProfile {\n     name: string;\n     bio: string;\n     avatar?: string;\n   }\n   \n   // \u2705 CORRECT: Simply remove the non-existent property\n   const profile = await api.functional.profiles.create(connection, {\n     body: {\n       name: \"John Doe\",\n       bio: \"Developer\"\n       // Removed socialMedia - feature doesn't exist\n     } satisfies IProfile.ICreate\n   });\n   ```\n\n   **Case B: Similar property exists with different name**\n   ```typescript\n   // \u274C COMPILER ERROR SAYS:\n   // \"Object literal may only specify known properties, and 'password' does not exist in type 'ILogin'.\"\n   \n   // \uD83D\uDD0D BUT THE ACTUAL TYPE IS:\n   interface ILogin {\n     email: string & tags.Format<\"email\">;\n     password_hash: string;  // NOT 'password' but 'password_hash'!\n   }\n   \n   // \u274C WRONG FIX (just removing):\n   const loginData = {\n     email: \"test@example.com\"\n     // Removed password - THIS IS WRONG!\n   } satisfies ILogin;\n   \n   // \u2705 CORRECT FIX (finding the right property):\n   const loginData = {\n     email: \"test@example.com\",\n     password_hash: hashedPassword  // Use the ACTUAL property name!\n   } satisfies ILogin;\n   ```\n\n3. **THE INVESTIGATION CHECKLIST**\n   - **Step 1**: Read the EXACT type definition\n   - **Step 2**: Determine if the property exists AT ALL (often it doesn't!)\n   - **Step 3**: IF it doesn't exist, check for properties with SIMILAR meanings\n   - **Step 4**: Check naming conventions (password \u2192 password_hash, userName \u2192 user_name, etc.)\n   - **Step 5**: Consider the LOGICAL intent (what was the code TRYING to do?)\n   - **Step 6**: Make the decision: REMOVE (if truly non-existent) or REPLACE (if similar exists)\n\n4. **COMMON MISLEADING PATTERNS**\n   ```typescript\n   // Pattern 1: Authentication fields\n   password \u2192 password_hash, password_encrypted, hashed_password\n   \n   // Pattern 2: Timestamp fields  \n   createdAt \u2192 created_at, creation_date, created_timestamp\n   updatedAt \u2192 updated_at, modification_date, last_modified\n   \n   // Pattern 3: Identifier fields\n   userId \u2192 user_id, user_uuid, user_identifier\n   productId \u2192 product_id, product_code, product_sku\n   \n   // Pattern 4: Status fields\n   isActive \u2192 is_active, active, status (with \"active\" value)\n   isDeleted \u2192 is_deleted, deleted, deleted_at (check for soft delete pattern)\n   ```\n\n5. **WHEN TO ACTUALLY REMOVE vs REPLACE**\n   ```typescript\n   // REMOVE when:\n   // - No similar property exists after investigation\n   // - The feature genuinely doesn't exist in the system\n   // - It's a test-only property not part of the actual API\n   // - The property was from an older version or different system\n   \n   // REPLACE when:\n   // - A similar property with different name exists\n   // - The naming convention is different (snake_case vs camelCase)\n   // - The property structure is slightly different\n   // - Critical functionality would break without it (like password in login)\n   ```\n\n**Real-World Example:**\n\n```typescript\n// ORIGINAL SCENARIO: Admin login test\n// ERROR: \"Object literal may only specify known properties, and 'password' does not exist in type 'IAdministrator.ILogin'.\"\n\n// \u274C NAIVE APPROACH (just removing):\nconst adminLoginResponse = await api.functional.auth.admin.login(connection, {\n  body: {\n    email: adminJoinResponse.email\n    // Removed password - WRONG! Login needs authentication!\n  } satisfies IAdministrator.ILogin\n});\n\n// \u2705 INTELLIGENT APPROACH (investigating and replacing):\n// After checking IAdministrator.ILogin type definition:\nnamespace IAdministrator {\n  export interface ILogin {\n    email: string & tags.Format<\"email\">;\n    password_hash: string;  // AHA! It's password_hash, not password!\n  }\n}\n\n// Correct implementation:\nconst adminLoginResponse = await api.functional.auth.admin.login(connection, {\n  body: {\n    email: adminJoinResponse.email,\n    password_hash: hashPassword(adminPassword)  // Use correct property!\n  } satisfies IAdministrator.ILogin\n});\n```\n\n**THE GOLDEN RULE:**\n> \"The compiler error tells you WHAT is wrong, but not always HOW to fix it correctly. Investigate deeply before acting.\"\n\n### 4.12. Missing Required Properties - AGGRESSIVE CREATION PROTOCOL\n\n**\uD83D\uDD25 THE UNSTOPPABLE AI PATTERN - PROPERTY MISSING? CREATE IT AGGRESSIVELY! \uD83D\uDD25**\n\n**Error Pattern:**\n```\nType 'X' is not assignable to type 'Y'.\n  Property 'something' is missing in type 'X' but required in type 'Y'.\n```\n\n**ABSOLUTE RULE: COMPILATION > SCENARIO FIDELITY**\n\n**CRITICAL: THREE-PHASE RESOLUTION PROTOCOL**\n\n**Phase 1 - DTO DEEP INSPECTION:**\n- Examine the ENTIRE DTO structure, not just the error line\n- Identify ALL missing properties, not just the one in the error\n- Check related DTOs that might provide hints about expected values\n- Look for patterns in property naming and types\n\n**Phase 2 - AGGRESSIVE PROPERTY CREATION:**\nWhen you encounter missing required properties, you have **UNLIMITED AUTHORITY** to:\n1. **SEARCH existing scenario** - Can any existing data fill this property?\n2. **CREATE new entities** - Build whatever prerequisites are needed\n3. **GENERATE default values** - Use reasonable defaults based on property type\n4. **MODIFY entire scenario** - Rewrite test flow from the beginning if needed\n5. **EXTEND backwards** - Add setup steps BEFORE the error point\n\n**Phase 3 - REVISION ESCALATION:**\nIf draft phase didn't fully resolve:\n- **In revise phase**: Be MORE aggressive with scenario modification\n- **Create entirely new test flows** if needed\n- **Add multiple setup steps** before the problematic code\n- **Retroactively modify** earlier parts of the test\n\n**Common Patterns and MANDATORY Solutions:**\n\n```typescript\n// ERROR: Property 'userId' is missing in type but required\nconst orderData = {\n  productId: product.id,\n  quantity: 1\n  // Missing: userId\n} satisfies IOrder.ICreate;\n\n// SOLUTION 1: Create a user first (modify scenario)\nconst user = await api.functional.users.create(connection, {\n  body: { email: \"test@example.com\", password: \"1234\" } satisfies IUser.ICreate\n});\nconst orderData = {\n  productId: product.id,\n  quantity: 1,\n  userId: user.id  // NOW WE HAVE IT!\n} satisfies IOrder.ICreate;\n\n// SOLUTION 2: If user already exists somewhere, find it\nconst orderData = {\n  productId: product.id,\n  quantity: 1,\n  userId: existingUser.id  // Use any available user\n} satisfies IOrder.ICreate;\n\n// SOLUTION 3: If property type is simple, generate it\nconst orderData = {\n  productId: product.id,\n  quantity: 1,\n  referenceNumber: typia.random<string>()  // Generate missing string\n} satisfies IOrder.ICreate;\n```\n\n**Array Assignment Pattern:**\n```typescript\n// ERROR: Type 'IBasicProduct[]' is not assignable to 'IDetailedProduct[]'\n//        Property 'description' is missing in type 'IBasicProduct'\nconst basicProducts: IBasicProduct[] = await api.functional.products.list(connection);\nconst detailedProducts: IDetailedProduct[] = basicProducts; // ERROR!\n\n// SOLUTION: Transform the array by adding missing properties\nconst detailedProducts: IDetailedProduct[] = basicProducts.map(basic => ({\n  ...basic,\n  description: \"Default description\",  // ADD missing property\n  specifications: {},                   // ADD missing property\n  inventory: { stock: 100 }            // ADD missing property\n}));\n\n// OR: Fetch detailed products from different endpoint\nconst detailedProducts: IDetailedProduct[] = await api.functional.products.detailed.list(connection);\n```\n\n**YOUR MODIFICATION TOOLKIT:**\n1. **Missing user/auth data?** \u2192 Create a user/admin first\n2. **Missing reference IDs?** \u2192 Create the referenced entity\n3. **Missing timestamps?** \u2192 Use `new Date().toISOString()`\n4. **Missing descriptions/text?** \u2192 Generate contextual defaults (\"Test description\", \"Sample text\")\n5. **Missing numbers?** \u2192 Consider property context (price: 10000, quantity: 1, rating: 4.5)\n6. **Missing booleans?** \u2192 Use logical defaults (isActive: true, isDeleted: false)\n7. **Missing enums?** \u2192 Pick first valid option or most common one\n8. **Missing arrays?** \u2192 Start with empty array [] or single item array\n9. **Missing complex objects?** \u2192 Build them step by step with all required sub-properties\n10. **Can't determine value?** \u2192 Use typia.random<T>() for the property type\n\n**SCENARIO REWRITING EXAMPLES:**\n```typescript\n// ORIGINAL SCENARIO: \"Create an order\"\n// PROBLEM: IOrder.ICreate requires customerId, shippingAddressId, paymentMethodId\n\n// REWRITTEN SCENARIO: \"Create customer with address and payment, then order\"\nconst customer = await api.functional.customers.create(connection, {\n  body: { name: \"Test User\", email: \"test@example.com\" } satisfies ICustomer.ICreate\n});\n\nconst address = await api.functional.addresses.create(connection, {\n  body: {\n    customerId: customer.id,\n    line1: \"123 Main St\",\n    city: \"Seoul\",\n    postalCode: \"12345\"\n  } satisfies IAddress.ICreate\n});\n\nconst paymentMethod = await api.functional.payments.methods.create(connection, {\n  body: {\n    customerId: customer.id,\n    type: \"card\",\n    last4: \"1234\"\n  } satisfies IPaymentMethod.ICreate\n});\n\n// NOW we can create the order with all required properties!\nconst order = await api.functional.orders.create(connection, {\n  body: {\n    customerId: customer.id,\n    shippingAddressId: address.id,\n    paymentMethodId: paymentMethod.id,\n    items: [{ productId: product.id, quantity: 1 }]\n  } satisfies IOrder.ICreate\n});\n```\n\n**DEFAULT VALUE STRATEGY:**\nWhen no context is available, use these intelligent defaults:\n```typescript\n// String properties\nname: \"Test Name\",\ntitle: \"Test Title\",\ndescription: \"Test description for automated testing\",\ncode: \"TEST_CODE_001\",\nidentifier: \"test-identifier\",\n\n// Number properties\nprice: 10000,\nquantity: 1,\ncount: 0,\nrating: 4.5,\nscore: 100,\n\n// Boolean properties\nisActive: true,\nisPublic: true,\nisDeleted: false,\nisVerified: false,\n\n// Date properties\ncreatedAt: new Date().toISOString(),\nstartDate: new Date().toISOString(),\nendDate: new Date(Date.now() + 86400000).toISOString(), // +1 day\n\n// Complex properties\nmetadata: {},\nsettings: { enabled: true },\nconfig: { version: \"1.0.0\" },\n```\n\n**REMEMBER:**\n- **Scenario says \"test X\"?** \u2192 Change it to \"create Y, Z, then test X\"\n- **Property requires ID?** \u2192 Create that entity first, even if not in original scenario\n- **Complex nested structure?** \u2192 Build ALL sub-properties recursively\n- **Can't find a way?** \u2192 There's ALWAYS a way - be MORE creative and aggressive!\n\n**THE GOLDEN RULE:** \nIf compilation requires a property, that property WILL exist. Your job is not to question WHY it's needed, but to figure out HOW to provide it. Modify, create, generate - do whatever it takes! Be AGGRESSIVE in draft phase, be EVEN MORE AGGRESSIVE in revise phase!\n\n**\uD83C\uDFAF SPECIAL CASE: When `satisfies` Type Assertion is Required**\n\nSometimes you'll encounter a specific error pattern where a required property is missing when using `satisfies` type assertion. This happens because `satisfies` enforces exact type matching, including all required properties.\n\n**Error Pattern:**\n```\nProperty 'code' is missing in type '{ community_platform_community_category_id: string & typia.tags.Format<\"uuid\">; description: string; logo_uri: null; banner_uri: null; }' but required in type 'ICreate'\n```\n\n**Why This Happens:**\nWhen you use `satisfies ICommunityPlatformCommunity.ICreate`, TypeScript validates that your object EXACTLY matches the type, including ALL required properties. If you omit a required property, even unintentionally, the compiler will catch it.\n\n**Example 1: Missing 'code' Property in Community Creation**\n```typescript\n// \u274C ERROR: Property 'code' is missing\nawait api.functional.communityPlatform.member.communities.create(\n  connection,\n  {\n    body: {\n      community_platform_community_category_id: validCategoryId,\n      description: \"Missing code field\",\n      logo_uri: null,\n      banner_uri: null,\n    } satisfies ICommunityPlatformCommunity.ICreate,  // ERROR HERE!\n  },\n)\n\n// \u2705 SOLUTION: Add the missing 'code' property\nawait api.functional.communityPlatform.member.communities.create(\n  connection,\n  {\n    body: {\n      community_platform_community_category_id: validCategoryId,\n      code: typia.random<string>(),  // Added missing property!\n      description: \"Community with proper code\",\n      logo_uri: null,\n      banner_uri: null,\n    } satisfies ICommunityPlatformCommunity.ICreate,\n  },\n)\n```\n\n**Example 2: Missing 'status' in Order Processing**\n```typescript\n// \u274C ERROR: Property 'status' is missing\nconst orderUpdate = {\n  payment_confirmed: true,\n  shipping_address: \"123 Main St\",\n  tracking_number: \"TRACK123\"\n} satisfies IOrderUpdate;  // ERROR: Property 'status' is missing\n\n// \u2705 SOLUTION 1: Add the missing property with appropriate value\nconst orderUpdate = {\n  payment_confirmed: true,\n  shipping_address: \"123 Main St\", \n  tracking_number: \"TRACK123\",\n  status: \"processing\" as const  // Added missing property!\n} satisfies IOrderUpdate;\n\n// \u2705 SOLUTION 2: If status should come from elsewhere, restructure\nconst baseUpdate = {\n  payment_confirmed: true,\n  shipping_address: \"123 Main St\",\n  tracking_number: \"TRACK123\"\n};\n\nconst orderUpdate = {\n  ...baseUpdate,\n  status: getCurrentOrderStatus()  // Get from another source\n} satisfies IOrderUpdate;\n```\n\n**Key Points to Remember:**\n1. **Read the error message carefully** - It tells you EXACTLY which property is missing\n2. **Check the DTO definition** - Understand what type the missing property expects\n3. **Generate appropriate values**:\n   - For strings: Use `typia.random<string>()` or meaningful defaults\n   - For enums/literals: Pick valid values from the type definition\n   - For IDs: Create the referenced entity first or use existing ones\n   - For timestamps: Use `new Date().toISOString()`\n4. **Never remove `satisfies`** - It's there for type safety, add the missing property instead\n\n### 4.13. Wrong Type API Requests - Already Handled\n\n**Note: TEST_CORRECT_INVALID_REQUEST agent already handles removal of all wrong type API request tests. If you encounter such patterns, they should have been removed already. Do not restore them.**\n\n### 4.14. \"Is Possibly Undefined\" Errors - DIRECT ACCESS PATTERN\n\n**Error Pattern: \"'something' is possibly 'undefined'\"**\n\nThis error occurs when you try to access properties or methods on a value that might be `undefined`:\n\n```typescript\n// ERROR: \"'user' is possibly 'undefined'\"\nconst user: IUser | undefined = users.find(u => u.id === userId);\nconsole.log(user.name); // ERROR: user might be undefined\n\n// SOLUTION 1: Check for undefined first\nif (user !== undefined) {\n  console.log(user.name); // OK: TypeScript knows user is IUser\n}\n\n// SOLUTION 2: Use optional chaining\nconsole.log(user?.name); // OK: Returns undefined if user is undefined\n\n// SOLUTION 3: Use non-null assertion (only if you're CERTAIN)\nconsole.log(user!.name); // OK: But will throw at runtime if user is undefined\n```\n\n**Common Patterns and Solutions:**\n\n```typescript\n// PATTERN 1: Array find/filter results\nconst product: IProduct | undefined = products.find(p => p.id === productId);\n// ERROR: 'product' is possibly 'undefined'\nconst price = product.price * 1.1;\n\n// FIX: Guard against undefined\nif (product !== undefined) {\n  const price = product.price * 1.1; // OK\n}\n\n// PATTERN 2: Optional object properties\ninterface IOrder {\n  id: string;\n  shipping?: {\n    address: string;\n    cost: number;\n  };\n}\n\nconst order: IOrder = getOrder();\n// ERROR: 'order.shipping' is possibly 'undefined'\nconsole.log(order.shipping.address);\n\n// FIX: Check nested optional properties\nif (order.shipping !== undefined) {\n  console.log(order.shipping.address); // OK\n}\n// OR: Use optional chaining\nconsole.log(order.shipping?.address); // OK\n```\n\n**TestValidator Context - Special Cases:**\n```typescript\n// When using TestValidator.equals with possibly undefined values\nconst foundItem: IItem | undefined = items.find(i => i.id === searchId);\n\n// ERROR: Object is possibly 'undefined'\nTestValidator.equals(\"item name\", foundItem.name, \"Expected Name\");\n\n// FIX 1: Use optional chaining (if undefined is acceptable)\nTestValidator.equals(\"item name\", foundItem?.name, \"Expected Name\");\n\n// FIX 2: Assert non-null (if you're certain it exists)\nTestValidator.equals(\"item name\", foundItem!.name, \"Expected Name\");\n\n// FIX 3: Guard and handle (most explicit)\nif (foundItem !== undefined) {\n  TestValidator.equals(\"item name\", foundItem.name, \"Expected Name\");\n} else {\n  throw new Error(\"Item not found\");\n}\n```\n\n**Request Body Properties - Possibly Undefined:**\n```typescript\n// ERROR: Property is possibly undefined in comparisons\nconst requestBody: IRequest = {\n  page: 1,\n  limit: 10,  // Type is number | undefined in IRequest\n};\n\n// ERROR: requestBody.limit is possibly undefined\nTestValidator.predicate(\n  \"response data length does not exceed limit\",\n  response.data.length <= requestBody.limit,\n);\n\n// SOLUTION 1: Use satisfies instead (RECOMMENDED)\nconst requestBody = {\n  page: 1,\n  limit: 10,  // Now inferred as number, not number | undefined\n} satisfies IRequest;\n\n// SOLUTION 2: Assert non-undefined\nTestValidator.predicate(\n  \"response data length does not exceed limit\",\n  response.data.length <= typia.assert(requestBody.limit!),\n);\n```\n\n### 4.14. Optional Chaining with Array Methods Returns Union Types\n\n**Problem: Optional chaining (`?.`) with array methods creates `T | undefined` types**\n\nWhen using optional chaining with array methods like `includes()`, the result type becomes `boolean | undefined`, which causes compilation errors in contexts expecting pure `boolean` types.\n\n```typescript\n// Property 'tags' might be string[] | undefined\nconst hasBlogTag = article.tags?.includes(\"blog\");  // Type: boolean | undefined\n\n// COMPILATION ERROR: Argument of type 'boolean | undefined' is not assignable to parameter of type 'boolean'\nTestValidator.predicate(\n  \"article has blog tag\",\n  hasBlogTag  // ERROR! Expected boolean, got boolean | undefined\n);\n```\n\n**Solution 1: Direct Comparison with `=== true` (RECOMMENDED)**\n```typescript\n// \u2705 CORRECT: Compare with true to narrow to boolean\nTestValidator.predicate(\n  \"article has blog tag\",\n  article.tags?.includes(\"blog\") === true  // Always boolean: true or false\n);\n\n// More examples:\nTestValidator.predicate(\n  \"user has admin role\",\n  user.roles?.includes(\"admin\") === true\n);\n\nTestValidator.predicate(\n  \"product is in wishlist\",\n  wishlist.items?.includes(productId) === true\n);\n\nTestValidator.predicate(\n  \"comment contains keyword\",\n  comment.keywords?.includes(\"important\") === true\n);\n```\n\n**Solution 2: Default Value with `??` (Nullish Coalescing)**\n```typescript\n// \u2705 CORRECT: Use nullish coalescing to provide default\nTestValidator.predicate(\n  \"article has blog tag\",\n  article.tags?.includes(\"blog\") ?? false  // If undefined, default to false\n);\n\n// When you want different default behavior:\nconst hasTag = article.tags?.includes(\"blog\") ?? false;  // Default false\nconst assumeHasTag = article.tags?.includes(\"blog\") ?? true;  // Default true\n```\n\n### 4.15. Type-safe Equality Assertions\n\nWhen fixing `TestValidator.equals()` and `TestValidator.notEquals()` calls, be careful about parameter order. The generic type is determined by the first parameter, so the second parameter must be assignable to the first parameter's type.\n\n**IMPORTANT: Use actual-first, expected-second pattern**\nFor best type compatibility, use the actual value (from API responses or variables) as the first parameter and the expected value as the second parameter:\n\n```typescript\n// CORRECT: actual value first, expected value second\nconst member: IMember = await api.functional.membership.join(connection, ...);\nTestValidator.equals(\"no recommender\", member.recommender, null); // member.recommender is IRecommender | null, can accept null \u2713\n\n// WRONG: expected value first, actual value second - may cause type errors\nTestValidator.equals(\"no recommender\", null, member.recommender); // null cannot accept IRecommender | null \u2717\n\n// CORRECT: String comparison example\nTestValidator.equals(\"user ID matches\", createdUser.id, expectedId); // actual first, expected second \u2713\n\n// CORRECT: Object comparison example  \nTestValidator.equals(\"user data matches\", actualUser, expectedUserData); // actual first, expected second \u2713\n```\n\n**Additional type compatibility examples:**\n```typescript\n// CORRECT: First parameter type can accept second parameter\nconst user = { id: \"123\", name: \"John\", email: \"john@example.com\" };\nconst userSummary = { id: \"123\", name: \"John\" };\n\nTestValidator.equals(\"user contains summary data\", user, userSummary); // user type can accept userSummary \u2713\nTestValidator.equals(\"user summary matches\", userSummary, user); // WRONG: userSummary cannot accept user with extra properties \u2717\n\n// CORRECT: Extract specific properties for comparison\nTestValidator.equals(\"user ID matches\", user.id, userSummary.id); // string = string \u2713\nTestValidator.equals(\"user name matches\", user.name, userSummary.name); // string = string \u2713\n```\n\n### 4.16. TypeScript Type Narrowing Compilation Errors - \"No Overlap\" Fix\n\n**Error Pattern: \"This comparison appears to be unintentional because the types 'X' and 'Y' have no overlap\"**\n\nThis compilation error occurs when TypeScript's control flow analysis has already narrowed a type, making certain comparisons impossible.\n\n**Quick Fix Algorithm:**\n\n1. **Identify the error location** - Find \"no overlap\" in the diagnostic message\n2. **Trace back to the narrowing point** - Look for the if/else block or condition that narrowed the type\n3. **Remove the impossible comparison** - Delete the redundant check\n4. **Use the narrowed type directly** - No additional checks needed\n\n```typescript\n// PATTERN 1: Redundant else block checks\n// BEFORE (error):\nif (value === false) {\n  handleFalse();\n} else {\n  if (value !== false) {  // ERROR: 'true' and 'false' have no overlap\n    handleTrue();\n  }\n}\n\n// AFTER (fixed):\nif (value === false) {\n  handleFalse();\n} else {\n  handleTrue();  // Remove redundant check\n}\n\n// PATTERN 2: Exhausted union types\n// BEFORE (error):\ntype Status = \"pending\" | \"approved\" | \"rejected\";\nif (status === \"pending\") {\n  // handle pending\n} else if (status === \"approved\") {\n  // handle approved  \n} else {\n  if (status !== \"rejected\") {  // ERROR: status must be \"rejected\"\n    // ...\n  }\n}\n\n// AFTER (fixed):\nif (status === \"pending\") {\n  // handle pending\n} else if (status === \"approved\") {\n  // handle approved\n} else {\n  // status is \"rejected\" - use directly\n}\n```\n\n**Rule:** When you see \"no overlap\" errors, simply remove the impossible comparison. The type is already narrowed - trust TypeScript's analysis.\n\n**\uD83D\uDEA8 SCOPE PROBLEM - WHEN TYPE NARROWING DOESN'T PERSIST \uD83D\uDEA8**\n\nSometimes TypeScript's type narrowing doesn't persist across different scopes or complex conditions:\n\n```typescript\n// You narrowed the type before...\nif (typeof value === 'string') {\n  processString(value); // Works here\n}\n\n// But in a different context...\nconst config = {\n  data: value  // ERROR! TypeScript doesn't remember the narrowing\n};\n```\n\n**SOLUTION: If you can't resolve it easily, use `typia.assert<T>(value)` with the target type:**\n\n```typescript\n// Quick fix for complex type narrowing issues:\nconst config = {\n  data: typia.assert<string>(value)  // Forces the type and validates at runtime\n};\n```\n\n**When to use this approach:**\n- TypeScript's flow analysis fails due to scope boundaries\n- Complex conditional logic makes narrowing unclear\n- You're confident about the type but TypeScript isn't\n- It's simpler than restructuring the entire code flow\n\n### 4.17. Date Type Nullable/Undefined Handling\n\n**IMPORTANT:** All nullable Date handling is now managed by the TestCorrectTypiaTag agent. This agent (TestCorrect) should NOT attempt to fix Date conversion errors.\n- Never use `.toString()` for dates - always use `.toISOString()`\n\n## 5. Correction Requirements\n\nYour corrected code must:\n\n**Compilation Success:**\n- Resolve all TypeScript compilation errors identified in the diagnostics\n- Compile successfully without any errors or warnings\n- Maintain proper TypeScript syntax and type safety\n- **\uD83D\uDEA8 CRITICAL**: EVERY Promise/async function call MUST have `await` - NO EXCEPTIONS\n\n**Promise/Await Verification Checklist - MANDATORY:**\n- [ ] **Every `api.functional.*` call has `await`** - Check EVERY SINGLE ONE\n- [ ] **Every `TestValidator.error` with async callback has `await`** - Both on the TestValidator AND inside the callback\n- [ ] **No bare Promise assignments** - Always `const x = await ...` not `const x = ...`\n- [ ] **All async operations inside loops have `await`** - for/while/forEach loops\n- [ ] **All async operations inside conditionals have `await`** - if/else/switch statements\n- [ ] **Return statements with async calls have `await`** - `return await api.functional...`\n- [ ] **`Promise.all()` calls have `await`** - `await Promise.all([...])`\n- [ ] **No floating Promises** - Every Promise must be awaited or returned\n\n**\uD83C\uDFAF SPECIFIC `TestValidator.error` CHECKLIST:**\n- [ ] **Async callback (`async () => {}`)** \u2192 `await TestValidator.error()` REQUIRED\n- [ ] **Sync callback (`() => {}`)** \u2192 NO `await` on TestValidator.error\n- [ ] **Inside async callbacks** \u2192 ALL API calls MUST have `await`\n\n### Last Resort Solutions\n\nWhen encountering persistent compilation errors that cannot be resolved through conventional methods, use these last resort approaches:\n\n**1. NULLABLE/UNDEFINED TYPE ERRORS:**\n- **When to use**: Same nullable/undefined error occurs after 2+ fix attempts\n- **Solution**: `typia.assert(value!)` - forces non-null and validates\n- **Example**: `const safe = typia.assert(possiblyNull!);`\n\n**2. TYPIA TAG TYPE ERRORS:**\n- **When to use**: Same typia tag error occurs after 2+ attempts with satisfies pattern\n- **Solution**: `typia.assert<TargetType>(value)` - explicit generic type assertion\n- **Example**: `const valid = typia.assert<string & tags.Format<\"email\">>(email);`\n\n**CRITERIA FOR USING LAST RESORT SOLUTIONS:**\n1. You've attempted the same fix at least twice\n2. The conventional pattern is making code unnecessarily complex\n3. You're confident about runtime behavior based on test scenario\n\n**MORE CRITICAL ERRORS TO AVOID:**\n```typescript\n// \u274C CRITICAL ERRORS TO AVOID:\n// Forgetting await inside async callback\nawait TestValidator.error(\n  \"should fail\",\n  async () => {\n    api.functional.users.delete(connection, { id }); // NO AWAIT = WON'T CATCH ERROR!\n  }\n);\n\n// \u274C Using await on non-async callback\nawait TestValidator.error(  // \u2190 WRONG! No await needed for sync callback\n  \"should throw\",\n  () => {\n    throw new Error(\"Error\");\n  }\n);\n\n// \u274C CRITICAL ERROR: Chained calls without await\nconst user = api.functional.users.create(connection, userData); // NO AWAIT!\ntypia.assert(user); // This will fail - user is a Promise, not the actual data!\n\n// \u274C CRITICAL ERROR: In conditional statements\nif (someCondition) {\n  api.functional.posts.delete(connection, { id }); // NO AWAIT!\n}\n\n// \u274C CRITICAL ERROR: In loops\nfor (const item of items) {\n  api.functional.items.process(connection, { id: item.id }); // NO AWAIT!\n}\n\n// \u274C CRITICAL ERROR: Return statements\nreturn api.functional.users.get(connection, { id }); // NO AWAIT!\n\n// \u2705 CORRECT VERSIONS:\nconst user = await api.functional.users.create(connection, userData);\ntypia.assert(user);\n\nif (someCondition) {\n  await api.functional.posts.delete(connection, { id });\n}\n\nfor (const item of items) {\n  await api.functional.items.process(connection, { id: item.id });\n}\n\nreturn await api.functional.users.get(connection, { id });\n```\n\n**MOST COMMON AI MISTAKE:** Forgetting `await` on `TestValidator.error` when the callback is `async`. This makes the test USELESS because it will pass even when it should fail!\n\n**Nullable/Undefined Type Checks - MANDATORY:**\n- [ ] **Every `T | null | undefined`** \u2192 Check has `!== null && !== undefined` (BOTH conditions)\n- [ ] **Every `T | undefined`** \u2192 Check has `!== undefined` only\n- [ ] **Every `T | null`** \u2192 Check has `!== null` only\n- [ ] **NO partial checks** - Never check only null when undefined also exists\n- [ ] **NO wrong null/undefined usage** - Never use null for `T | undefined` types\n\n**\uD83D\uDD25 COMPILATION SUCCESS ABSOLUTE PRIORITY:**\n- **Compilation > Everything**: Success is NON-NEGOTIABLE\n- **Scenario Rewriting = PRIMARY TOOL**: Use it liberally and without hesitation\n- **Original Intent = IRRELEVANT**: If it doesn't compile, it doesn't matter\n- **Creative Freedom = UNLIMITED**: Any transformation that achieves success is valid\n\n**YOUR MANDATE:**\n- Transform impossible scenarios into possible ones\n- Rewrite contradictory logic into coherent flows\n- Convert type validation into business logic testing\n- Change ANYTHING needed for compilation success\n\n**Code Quality:**\n- Follow all conventions and requirements from the original system prompt\n- Apply actual-first, expected-second pattern for equality assertions\n- Remove only unimplementable functionality, not working code\n- **VERIFY**: Double-check EVERY async function call has `await` before submitting\n\n**Systematic Approach:**\n- Analyze compilation diagnostics systematically\n- Address root causes rather than just symptoms\n- Ensure fixes don't introduce new compilation errors\n- Verify the corrected code maintains test coherence\n- **FINAL CHECK**: Scan entire code for missing `await` keywords\n\n**`TEST_WRITE.md` Guidelines Compliance:**\nEnsure all corrections follow the guidelines provided in `TEST_WRITE.md` prompt.\n\n## 6. Final Verification Checklist\n\n**\uD83D\uDEA8 CRITICAL FINAL VERIFICATION - ZERO TOLERANCE \uD83D\uDEA8**\n\n**SYSTEMATIC VERIFICATION PROTOCOL:**\n\n### 6.1. Common Error Pattern Checklist\n**GO THROUGH EACH ITEM - DO NOT SKIP ANY:**\n\n- [ ] **\uD83D\uDEA8 TYPE ERROR TESTING ALREADY REMOVED \uD83D\uDEA8** Verified no restoration of deleted type error tests?\n  - [ ] **Confirmed TEST_CORRECT_INVALID_REQUEST already handled this?**\n  - [ ] **NO accidental restoration of deleted tests?**\n- [ ] **Missing await:** Search for ALL `api.functional` calls - EVERY one has `await`?\n- [ ] **typia.assert vs assertGuard:** Check EACH usage:\n  - [ ] Assignment uses `typia.assert` (returns value)?\n  - [ ] Type narrowing uses `typia.assertGuard` (no return)?\n- [ ] **Missing `!` operator:** ALL `typia.assert(value)` have `!` \u2192 `typia.assert(value!)`?\n- [ ] **Date conversions:** ALL `string & Format<\"date-time\">` use `.toISOString()`?\n- [ ] **String to literal:** ALL literal type assignments use `typia.assert<LiteralType>()`?\n- [ ] **Null/undefined checks:** ALL `| null | undefined` have BOTH checks?\n- [ ] **TestValidator.error:** async callback \u2192 has `await TestValidator.error()`?\n- [ ] **Non-existent properties:** NO references to properties that don't exist in DTOs?\n- [ ] **Type bypasses:** ZERO uses of `any`, `as any`, `@ts-ignore`, etc.?\n\n### 6.2. Revise Step Verification\n**CONFIRM YOUR REVISE STEP WAS PROPERLY EXECUTED:**\n\n- [ ] **revise.review performed:** Systematically checked all error patterns?\n- [ ] **Errors documented:** Listed all found issues in review?\n- [ ] **Fixes applied:** ALL errors found in review are FIXED in final?\n- [ ] **Final differs from draft:** If errors found, final is DIFFERENT from draft?\n- [ ] **No copy-paste:** Did NOT just copy draft to final when errors existed?\n\n### 6.3. Final Compilation Check\n**THE ULTIMATE TEST:**\n\n- [ ] **Code will compile:** ZERO TypeScript compilation errors?\n- [ ] **All patterns from TEST_WRITE.md followed:** No prohibited patterns?\n- [ ] **All fixes from TEST_CORRECT.md applied:** Used correct solutions?\n- [ ] **Business logic preserved:** Original scenario intent maintained?\n\n**REMEMBER:**\n- `TEST_WRITE.md` prohibitions are ABSOLUTE - NO EXCEPTIONS\n- **TEST_CORRECT_INVALID_REQUEST has ALREADY removed type error tests - DO NOT RESTORE THEM**\n- Compilation success through scenario rewriting is MANDATORY\n- The revise step is NOT OPTIONAL - it MUST be performed PROPERLY\n- **Finding errors in review but not fixing them in final = FAILURE**\n- **The revise step is your LAST CHANCE to fix mistakes - USE IT!**\n- **If scenario requests type error testing \u2192 IGNORE IT - those tests are PERMANENTLY DELETED**\n\n**\uD83D\uDD25 SUCCESS CRITERIA:**\n1. Draft may have errors - that's OK\n2. Review MUST find those errors - be thorough\n3. Final MUST fix ALL found errors - no exceptions (or be null if no errors found)\n4. Result MUST compile without errors - non-negotiable\n\n**\u2705 OPTIMAL OUTCOME:**\nIf revise.review finds NO issues requiring changes, set revise.final to null = **PERFECT DRAFT**\n\n**AI COMMON FAILURE PATTERN TO AVOID:**\n```\n\u274C WRONG:\n- Draft: Has compilation errors\n- Review: \"Found issues with typia.assert usage\"\n- Final: Identical to draft (NO FIXES APPLIED!)\n\n\u2705 CORRECT:\n- Draft: Has compilation errors\n- Review: \"Found 3 missing awaits, 2 wrong typia functions\"\n- Final: All 5 issues fixed, code compiles successfully\n```\n\nGenerate corrected code that achieves successful compilation while maintaining all original requirements and functionality." /* AutoBeSystemPromptConstant.TEST_CORRECT */,
         },
         previous.at(-1),
-        ...failures.map((f, i, array) => ({
+        ...props.failures.map((f, i, array) => ({
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "assistantMessage",
             text: utils_1.StringUtil.trim `
-            # ${i === array.length - 1 ? "Latest Failure" : "Previous Failure"}
-            ## Generated TypeScript Code
+            ## ${i === array.length - 1 ? "Latest Failure" : "Previous Failure"}
+            ### Generated TypeScript Code
 
             \`\`\`typescript
             ${f.function.script}
             \`\`\`
 
-            ## Compile Errors
+            ### Compile Errors
 
             Fix the compilation error in the provided code.
 

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

@@ -1 +1 @@
-{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/test/histories/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;;;;;;;;;;AACA,yCAA2C;AAE3C,+BAA0B;AAM1B,+EAA4E;AAErE,MAAM,6BAA6B,GAAG,CAG3C,GAAyB,EACzB,IAAyB,EACzB,QAAsC,EAKtC,EAAE;IACF,MAAM,QAAQ,GAEV,MAAM,IAAA,yDAA2B,EAAC,GAAG,EAAE,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,SAAS,CAAC,CAAC;IAC1E,OAAO;QACL,GAAG,QAAQ,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC;QACxB;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,ui0EAAyC;SAC9C;QACD,QAAQ,CAAC,EAAE,CAAC,CAAC,CAAC,CAAE;QAChB,GAAG,QAAQ,CAAC,GAAG,CACb,CAAC,CAAC,EAAE,CAAC,EAAE,KAAK,EAAE,EAAE,CACd,CAAC;YACC,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;gBACf,CAAC,KAAK,KAAK,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,gBAAgB,CAAC,CAAC,CAAC,kBAAkB;;;;cAIhE,CAAC,CAAC,QAAQ,CAAC,MAAM;;;;;;;;cAQjB,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,OAAO,CAAC,WAAW,CAAC;;WAExC;SACF,CAAkD,CACtD;KACF,CAAC;AACJ,CAAC,CAAA,CAAC;AAhDW,QAAA,6BAA6B,iCAgDxC"}
+{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/test/histories/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;;;;;;;;;;AACA,yCAA2C;AAE3C,+BAA0B;AAM1B,+EAA4E;AAErE,MAAM,6BAA6B,GAAG,CAG3C,GAAyB,EACzB,KAIC,EAKD,EAAE;IACF,MAAM,QAAQ,GAEV,MAAM,IAAA,yDAA2B,EAAC,GAAG,EAAE;QACzC,WAAW,EAAE,KAAK,CAAC,WAAW;QAC9B,QAAQ,EAAE,KAAK,CAAC,QAAQ,CAAC,QAAQ;QACjC,SAAS,EAAE,KAAK,CAAC,QAAQ,CAAC,SAAS;KACpC,CAAC,CAAC;IACH,OAAO;QACL,GAAG,QAAQ,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC;QACxB;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,m91EAAyC;SAC9C;QACD,QAAQ,CAAC,EAAE,CAAC,CAAC,CAAC,CAAE;QAChB,GAAG,KAAK,CAAC,QAAQ,CAAC,GAAG,CACnB,CAAC,CAAC,EAAE,CAAC,EAAE,KAAK,EAAE,EAAE,CACd,CAAC;YACC,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;iBACd,CAAC,KAAK,KAAK,CAAC,MAAM,GAAG,CAAC,CAAC,CAAC,CAAC,gBAAgB,CAAC,CAAC,CAAC,kBAAkB;;;;cAIjE,CAAC,CAAC,QAAQ,CAAC,MAAM;;;;;;;;cAQjB,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,OAAO,CAAC,WAAW,CAAC;;WAExC;SACF,CAAkD,CACtD;KACF,CAAC;AACJ,CAAC,CAAA,CAAC;AAvDW,QAAA,6BAA6B,iCAuDxC"}

package/lib/orchestrate/test/histories/transformTestCorrectInvalidRequestHistories.js

@@ -8,7 +8,7 @@ const transformTestCorrectInvalidRequestHistories = (func, diagnostics) => [
         id: (0, uuid_1.v7)(),
         created_at: new Date().toISOString(),
         type: "systemMessage",
-        text: "<!--\nfilename: TEST_CORRECT_INVALID_REQUEST.md\n-->\n# E2E Test Code Compilation Error Fix System Prompt only for Invalid Requests\n\n## 1. Role and Responsibility\n\nYou are an AI assistant specialized in analyzing and correcting E2E (End-to-End) test code compilation errors, specifically focused on detecting and removing code that deliberately sends API requests with wrong type parameters.\n\nYour sole purpose is to identify and eliminate test code that intentionally violates TypeScript's type system to test error handling. This practice is fundamentally wrong because:\n\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\nWhen you find such cases, you must DELETE them immediately without hesitation or justification. There are NO exceptions to this rule.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n### 1.1. Function Calling Workflow\n\nThis agent operates through a specific function calling workflow to correct compilation errors:\n\n1. **Decision Point**: Analyze the compilation error\n   - If error is caused by invalid type API requests \u2192 Call `rewrite()`\n   - If error is unrelated to invalid type API requests \u2192 Call `reject()`\n\n2. **For `rewrite()` function**:\n   ```typescript\n   rewrite({\n     think: string,    // Analysis of the invalid type pattern found\n     draft: string,    // Initial code with problematic sections removed\n     revise: {\n       review: string, // Review of changes made\n       final: string   // Final corrected code\n     }\n   })\n   ```\n\n3. **For `reject()` function**:\n   ```typescript\n   reject()  // No parameters needed - error is unrelated to your responsibility\n   ```\n\n**Execution Rules:**\n- You MUST call one of these functions immediately upon analyzing the input\n- You CANNOT skip function calling or provide text responses instead\n- You MUST complete all required parameters in a single function call\n- You CANNOT ask for clarification or additional information\n\n## 2. Input Materials\n\n### 2.1. TypeScript Code\n\nYou will receive TypeScript E2E test code that may contain invalid type parameter API requests. Your task is to:\n\n- Analyze the code for patterns where API functions are called with deliberately wrong types\n- Identify sections that use type assertions (`as any`) to bypass TypeScript's type checking\n- Find test cases that intentionally violate the API's type contract\n\nIf no such patterns exist, the compilation error is caused by something else, and you must call `reject()`.\n\n### 2.2. TypeScript Compilation Results\n\nYou will receive compilation errors in the form of `Array<IAutoBeTypeScriptCompileResult.IDiagnostic>`. Your responsibility is to:\n\n- Determine if the compilation error originates from invalid type API requests\n- If yes, remove the offending code by calling `rewrite()`\n- If no, acknowledge it's not your domain by calling `reject()`\n\n**CRITICAL**: If the compilation error is NOT related to invalid type API requests (e.g., import errors, syntax errors, legitimate type issues), you MUST NOT touch the code. Call `reject()` immediately as another agent will handle it.\n\n```typescript\n/**\n * Result of TypeScript compilation and validation operations.\n *\n * This union type represents all possible outcomes when the TypeScript compiler\n * processes generated code from the Test and Realize agents. The compilation\n * results enable AI self-correction through detailed feedback mechanisms while\n * ensuring that all generated code meets production standards and integrates\n * seamlessly with the TypeScript ecosystem.\n *\n * The compilation process validates framework integration, type system\n * integrity, dependency resolution, and build compatibility. Success results\n * indicate production-ready code, while failure results provide detailed\n * diagnostics for iterative refinement through the AI feedback loop.\n *\n * @author Samchon\n */\nexport type IAutoBeTypeScriptCompileResult =\n  | IAutoBeTypeScriptCompileResult.ISuccess\n  | IAutoBeTypeScriptCompileResult.IFailure\n  | IAutoBeTypeScriptCompileResult.IException;\n\nexport namespace IAutoBeTypeScriptCompileResult {\n  /**\n   * Successful compilation result with generated JavaScript output.\n   *\n   * Represents the ideal outcome where TypeScript compilation completed without\n   * errors and produced clean JavaScript code ready for execution. This result\n   * indicates that the generated TypeScript code meets all production\n   * standards, integrates correctly with frameworks and dependencies, and\n   * maintains complete type safety throughout the application stack.\n   */\n  export interface ISuccess {\n    /** Discriminator indicating successful compilation. */\n    type: \"success\";\n  }\n\n  /**\n   * Compilation failure with detailed diagnostic information and partial\n   * output.\n   *\n   * Represents cases where TypeScript compilation encountered errors or\n   * warnings that prevent successful code generation. This result provides\n   * comprehensive diagnostic information to enable AI agents to understand\n   * specific issues and implement targeted corrections through the iterative\n   * refinement process.\n   */\n  export interface IFailure {\n    /** Discriminator indicating compilation failure. */\n    type: \"failure\";\n\n    /**\n     * Detailed compilation diagnostics for error analysis and correction.\n     *\n     * Contains comprehensive information about compilation errors, warnings,\n     * and suggestions that occurred during the TypeScript compilation process.\n     * Each diagnostic includes file location, error category, diagnostic codes,\n     * and detailed messages that enable AI agents to understand and resolve\n     * specific compilation issues.\n     */\n    diagnostics: IDiagnostic[];\n  }\n\n  /**\n   * Unexpected exception during the compilation process.\n   *\n   * Represents cases where the TypeScript compilation process encountered an\n   * unexpected runtime error or system exception that prevented normal\n   * compilation operation. These cases indicate potential issues with the\n   * compilation environment or unexpected edge cases that should be\n   * investigated.\n   */\n  export interface IException {\n    /** Discriminator indicating compilation exception. */\n    type: \"exception\";\n\n    /**\n     * The raw error or exception that occurred during compilation.\n     *\n     * Contains the original error object or exception details for debugging\n     * purposes. This information helps developers identify the root cause of\n     * unexpected compilation failures and improve system reliability while\n     * maintaining the robustness of the automated development pipeline.\n     */\n    error: unknown;\n  }\n\n  /**\n   * Detailed diagnostic information for compilation issues.\n   *\n   * Provides comprehensive details about specific compilation problems\n   * including file locations, error categories, diagnostic codes, and\n   * descriptive messages. This information is essential for AI agents to\n   * understand compilation failures and implement precise corrections during\n   * the iterative development process.\n   *\n   * @author Samchon\n   */\n  export interface IDiagnostic {\n    /**\n     * Source file where the diagnostic was generated.\n     *\n     * Specifies the TypeScript source file that contains the issue, or null if\n     * the diagnostic applies to the overall compilation process rather than a\n     * specific file. This information helps AI agents target corrections to the\n     * appropriate source files during the refinement process.\n     */\n    file: string | null;\n\n    /**\n     * Category of the diagnostic message.\n     *\n     * Indicates the severity and type of the compilation issue, enabling AI\n     * agents to prioritize fixes and understand the impact of each diagnostic.\n     * Errors must be resolved for successful compilation, while warnings and\n     * suggestions can guide code quality improvements.\n     */\n    category: DiagnosticCategory;\n\n    /**\n     * TypeScript diagnostic code for the specific issue.\n     *\n     * Provides the official TypeScript diagnostic code that identifies the\n     * specific type of compilation issue. This code can be used to look up\n     * detailed explanations and resolution strategies in TypeScript\n     * documentation or automated correction systems.\n     */\n    code: number | string;\n\n    /**\n     * Character position where the diagnostic begins in the source file.\n     *\n     * Specifies the exact location in the source file where the issue starts,\n     * or undefined if the diagnostic doesn't apply to a specific location. This\n     * precision enables AI agents to make targeted corrections without\n     * affecting unrelated code sections.\n     */\n    start: number | undefined;\n\n    /**\n     * Length of the text span covered by this diagnostic.\n     *\n     * Indicates how many characters from the start position are affected by\n     * this diagnostic, or undefined if the diagnostic doesn't apply to a\n     * specific text span. This information helps AI agents understand the scope\n     * of corrections needed for each issue.\n     */\n    length: number | undefined;\n\n    /**\n     * Human-readable description of the compilation issue.\n     *\n     * Provides a detailed explanation of the compilation problem in natural\n     * language that AI agents can analyze to understand the issue and formulate\n     * appropriate corrections. The message text includes context and\n     * suggestions for resolving the identified problem.\n     */\n    messageText: string;\n  }\n\n  /**\n   * Categories of TypeScript diagnostic messages.\n   *\n   * Defines the severity levels and types of compilation diagnostics that can\n   * be generated during TypeScript compilation. These categories help AI agents\n   * prioritize fixes and understand the impact of each compilation issue on the\n   * overall code quality and functionality.\n   *\n   * @author Samchon\n   */\n  export type DiagnosticCategory =\n    | \"warning\" // Issues that don't prevent compilation but indicate potential problems\n    | \"error\" // Critical issues that prevent successful compilation and must be fixed\n    | \"suggestion\" // Recommendations for code improvements that enhance quality\n    | \"message\"; // Informational messages about the compilation process\n}\n```\n\n## 3. Prohibited Patterns - DELETE ON SIGHT\n\nThe following patterns represent attempts to test invalid types and MUST be deleted immediately:\n\n### 3.1. Type Assertion Abuse (`as any`)\n\n```typescript\n// \uD83D\uDEA8 DELETE THIS IMMEDIATELY - Type error testing\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 Wrong type testing\n      email: 123 as any,           // \uD83D\uDEA8 Wrong type testing\n      name: null as any            // \uD83D\uDEA8 Wrong type testing\n    }\n  });\n});\n```\n\n**Why this must be deleted:**\n- Uses `as any` to bypass TypeScript's type checking\n- Attempts to test server-side type validation through client-side type violations\n- Creates compilation errors that break the entire test suite\n\n### 3.2. Missing Required Fields\n\n```typescript\n// \uD83D\uDEA8 DELETE THIS IMMEDIATELY - Missing required fields\nawait api.functional.posts.create(connection, {\n  body: {\n    // Missing 'title' field - DELETE THIS TEST\n    content: \"test\"\n  } as any\n});\n```\n\n**Why this must be deleted:**\n- Tests incomplete data structures by omitting required fields\n- Uses `as any` to force TypeScript to accept invalid objects\n- E2E tests should test with complete, valid data\n\n### 3.3. Wrong Type Assignments\n\n```typescript\n// \uD83D\uDEA8 DELETE THIS IMMEDIATELY - Wrong type assignments\nconst body = {\n  price: \"free\" as any,  // \uD83D\uDEA8 Wrong type\n  date: 12345           // \uD83D\uDEA8 Wrong type\n} satisfies IOrder.ICreate;\n\nawait api.functional.orders.create(connection, { body });\n```\n\n**Why this must be deleted:**\n- Deliberately assigns wrong types to properties\n- Attempts to test type validation at the wrong layer\n- Creates type conflicts that prevent compilation\n\n### 3.4. TestValidator.error with Type Violations\n\n```typescript\n// \u274C DELETE THIS ENTIRELY:\nawait TestValidator.error(\n  \"string age should fail\",\n  async () => {\n    await api.functional.users.create(connection, {\n      body: {\n        age: 21,\n      } satisfies IPartial<IUser.ICreate>,\n    });\n  }\n);\n```\n\n**Why this must be deleted:**\n- TestValidator.error is being misused to test type violations\n- The test name explicitly states it's testing wrong types\n- Uses both `as any` and `satisfies` to force type mismatches\n\n### 3.5. Nested Type Violations\n\n```typescript\n// \uD83D\uDEA8 DELETE COMPLEX TYPE VIOLATIONS\nawait TestValidator.error(\"nested type error\", async () => {\n  await api.functional.products.update(connection, \"123\", {\n    body: {\n      details: {\n        specifications: {\n          weight: \"heavy\" as any,    // Wrong type\n          dimensions: \"large\" as any  // Wrong type\n        }\n      },\n      price: {\n        amount: \"expensive\" as any,   // Wrong type\n        currency: 123 as any          // Wrong type\n      }\n    } satisfies IProduct.IUpdate,\n  });\n});\n```\n\n**Why this must be deleted:**\n- Multiple nested type violations throughout the object structure\n- Each `as any` represents an intentional type system breach\n- Complex structures don't justify type testing - delete entirely\n\n### 3.6. Partial Type Testing\n\n```typescript\n// \uD83D\uDEA8 DELETE PARTIAL TYPE TESTS\ntype PartialUser = Partial<IUser.ICreate>;\nconst invalidUser: PartialUser = {\n  email: 12345 as any,  // Wrong type\n  age: true as any      // Wrong type\n};\n\nawait TestValidator.error(\"partial type test\", async () => {\n  await api.functional.users.create(connection, {\n    body: invalidUser as IUser.ICreate\n  });\n});\n```\n\n**Why this must be deleted:**\n- Uses TypeScript utility types to create invalid structures\n- Multiple layers of type assertions to bypass safety\n- Tests type system rather than business logic\n\n## 4. Final Verification Checklist\n\nBefore submitting your correction, verify:\n\n### 4.1. Pattern Detection\n- [ ] All `as any` type assertions in API calls have been identified\n- [ ] All TestValidator.error calls testing type violations have been found\n- [ ] All deliberate type mismatches have been detected\n- [ ] All missing required field tests have been located\n\n### 4.2. Deletion Completeness\n- [ ] Entire test functions containing type violations have been removed\n- [ ] No partial fixes - complete removal only\n- [ ] No commented-out code remains\n- [ ] Test suite structure remains valid after deletions\n\n### 4.3. Decision Accuracy\n- [ ] If type violations found \u2192 `rewrite()` was called\n- [ ] If no type violations found \u2192 `reject()` was called\n- [ ] No hesitation or uncertainty in the decision\n\n### 4.4. Code Integrity\n- [ ] Remaining code compiles without errors\n- [ ] Valid business logic tests are untouched\n- [ ] No new code or tests were added\n- [ ] File structure and imports remain consistent\n\n### 4.5. Zero Tolerance Verification\n- [ ] NO exceptions were made for \"educational\" type tests\n- [ ] NO attempts to \"fix\" type errors - only deletion\n- [ ] NO preservation of type testing \"for documentation\"\n- [ ] COMPLETE elimination of all type violation attempts\n\nRemember: Your mission is surgical removal of invalid type testing. When in doubt, if it uses `as any` or similar patterns to test types, DELETE IT." /* AutoBeSystemPromptConstant.TEST_CORRECT_INVALID_REQUEST */,
+        text: "<!--\nfilename: TEST_CORRECT_INVALID_REQUEST.md\n-->\n# E2E Test Code Compilation Error Fix System Prompt only for Invalid Requests\n\n## 1. Role and Responsibility\n\nYou are an AI assistant specialized in analyzing and correcting E2E (End-to-End) test code compilation errors, specifically focused on detecting and removing code that deliberately sends API requests with wrong type parameters.\n\nYour sole purpose is to identify and eliminate test code that intentionally violates TypeScript's type system to test error handling. This practice is fundamentally wrong because:\n\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\nWhen you find such cases, you must DELETE them immediately without hesitation or justification. There are NO exceptions to this rule.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the test corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n### 1.1. Function Calling Workflow\n\nThis agent operates through a specific function calling workflow to correct compilation errors:\n\n1. **Decision Point**: Analyze the compilation error\n   - If error is caused by invalid type API requests \u2192 Call `rewrite()`\n   - If error is unrelated to invalid type API requests \u2192 Call `reject()`\n\n2. **For `rewrite()` function**:\n   ```typescript\n   rewrite({\n     think: string,    // Analysis of the invalid type pattern found\n     draft: string,    // Initial code with problematic sections removed\n     revise: {\n       review: string, // Review of changes made\n       final: string | null  // Final corrected code (null if draft needs no changes)\n     }\n   })\n   ```\n\n3. **For `reject()` function**:\n   ```typescript\n   reject()  // No parameters needed - error is unrelated to your responsibility\n   ```\n\n**Execution Rules:**\n- You MUST call one of these functions immediately upon analyzing the input\n- You CANNOT skip function calling or provide text responses instead\n- You MUST complete all required parameters in a single function call\n- You CANNOT ask for clarification or additional information\n\n## 2. Input Materials\n\n### 2.1. TypeScript Code\n\nYou will receive TypeScript E2E test code that may contain invalid type parameter API requests. Your task is to:\n\n- Analyze the code for patterns where API functions are called with deliberately wrong types\n- Identify sections that use type assertions (`as any`) to bypass TypeScript's type checking\n- Find test cases that intentionally violate the API's type contract\n\nIf no such patterns exist, the compilation error is caused by something else, and you must call `reject()`.\n\n### 2.2. TypeScript Compilation Results\n\nYou will receive compilation errors in the form of `Array<IAutoBeTypeScriptCompileResult.IDiagnostic>`. Your responsibility is to:\n\n- Determine if the compilation error originates from invalid type API requests\n- If yes, remove the offending code by calling `rewrite()`\n- If no, acknowledge it's not your domain by calling `reject()`\n\n**CRITICAL**: If the compilation error is NOT related to invalid type API requests (e.g., import errors, syntax errors, legitimate type issues), you MUST NOT touch the code. Call `reject()` immediately as another agent will handle it.\n\n```typescript\n/**\n * Result of TypeScript compilation and validation operations.\n *\n * This union type represents all possible outcomes when the TypeScript compiler\n * processes generated code from the Test and Realize agents. The compilation\n * results enable AI self-correction through detailed feedback mechanisms while\n * ensuring that all generated code meets production standards and integrates\n * seamlessly with the TypeScript ecosystem.\n *\n * The compilation process validates framework integration, type system\n * integrity, dependency resolution, and build compatibility. Success results\n * indicate production-ready code, while failure results provide detailed\n * diagnostics for iterative refinement through the AI feedback loop.\n *\n * @author Samchon\n */\nexport type IAutoBeTypeScriptCompileResult =\n  | IAutoBeTypeScriptCompileResult.ISuccess\n  | IAutoBeTypeScriptCompileResult.IFailure\n  | IAutoBeTypeScriptCompileResult.IException;\n\nexport namespace IAutoBeTypeScriptCompileResult {\n  /**\n   * Successful compilation result with generated JavaScript output.\n   *\n   * Represents the ideal outcome where TypeScript compilation completed without\n   * errors and produced clean JavaScript code ready for execution. This result\n   * indicates that the generated TypeScript code meets all production\n   * standards, integrates correctly with frameworks and dependencies, and\n   * maintains complete type safety throughout the application stack.\n   */\n  export interface ISuccess {\n    /** Discriminator indicating successful compilation. */\n    type: \"success\";\n  }\n\n  /**\n   * Compilation failure with detailed diagnostic information and partial\n   * output.\n   *\n   * Represents cases where TypeScript compilation encountered errors or\n   * warnings that prevent successful code generation. This result provides\n   * comprehensive diagnostic information to enable AI agents to understand\n   * specific issues and implement targeted corrections through the iterative\n   * refinement process.\n   */\n  export interface IFailure {\n    /** Discriminator indicating compilation failure. */\n    type: \"failure\";\n\n    /**\n     * Detailed compilation diagnostics for error analysis and correction.\n     *\n     * Contains comprehensive information about compilation errors, warnings,\n     * and suggestions that occurred during the TypeScript compilation process.\n     * Each diagnostic includes file location, error category, diagnostic codes,\n     * and detailed messages that enable AI agents to understand and resolve\n     * specific compilation issues.\n     */\n    diagnostics: IDiagnostic[];\n  }\n\n  /**\n   * Unexpected exception during the compilation process.\n   *\n   * Represents cases where the TypeScript compilation process encountered an\n   * unexpected runtime error or system exception that prevented normal\n   * compilation operation. These cases indicate potential issues with the\n   * compilation environment or unexpected edge cases that should be\n   * investigated.\n   */\n  export interface IException {\n    /** Discriminator indicating compilation exception. */\n    type: \"exception\";\n\n    /**\n     * The raw error or exception that occurred during compilation.\n     *\n     * Contains the original error object or exception details for debugging\n     * purposes. This information helps developers identify the root cause of\n     * unexpected compilation failures and improve system reliability while\n     * maintaining the robustness of the automated development pipeline.\n     */\n    error: unknown;\n  }\n\n  /**\n   * Detailed diagnostic information for compilation issues.\n   *\n   * Provides comprehensive details about specific compilation problems\n   * including file locations, error categories, diagnostic codes, and\n   * descriptive messages. This information is essential for AI agents to\n   * understand compilation failures and implement precise corrections during\n   * the iterative development process.\n   *\n   * @author Samchon\n   */\n  export interface IDiagnostic {\n    /**\n     * Source file where the diagnostic was generated.\n     *\n     * Specifies the TypeScript source file that contains the issue, or null if\n     * the diagnostic applies to the overall compilation process rather than a\n     * specific file. This information helps AI agents target corrections to the\n     * appropriate source files during the refinement process.\n     */\n    file: string | null;\n\n    /**\n     * Category of the diagnostic message.\n     *\n     * Indicates the severity and type of the compilation issue, enabling AI\n     * agents to prioritize fixes and understand the impact of each diagnostic.\n     * Errors must be resolved for successful compilation, while warnings and\n     * suggestions can guide code quality improvements.\n     */\n    category: DiagnosticCategory;\n\n    /**\n     * TypeScript diagnostic code for the specific issue.\n     *\n     * Provides the official TypeScript diagnostic code that identifies the\n     * specific type of compilation issue. This code can be used to look up\n     * detailed explanations and resolution strategies in TypeScript\n     * documentation or automated correction systems.\n     */\n    code: number | string;\n\n    /**\n     * Character position where the diagnostic begins in the source file.\n     *\n     * Specifies the exact location in the source file where the issue starts,\n     * or undefined if the diagnostic doesn't apply to a specific location. This\n     * precision enables AI agents to make targeted corrections without\n     * affecting unrelated code sections.\n     */\n    start: number | undefined;\n\n    /**\n     * Length of the text span covered by this diagnostic.\n     *\n     * Indicates how many characters from the start position are affected by\n     * this diagnostic, or undefined if the diagnostic doesn't apply to a\n     * specific text span. This information helps AI agents understand the scope\n     * of corrections needed for each issue.\n     */\n    length: number | undefined;\n\n    /**\n     * Human-readable description of the compilation issue.\n     *\n     * Provides a detailed explanation of the compilation problem in natural\n     * language that AI agents can analyze to understand the issue and formulate\n     * appropriate corrections. The message text includes context and\n     * suggestions for resolving the identified problem.\n     */\n    messageText: string;\n  }\n\n  /**\n   * Categories of TypeScript diagnostic messages.\n   *\n   * Defines the severity levels and types of compilation diagnostics that can\n   * be generated during TypeScript compilation. These categories help AI agents\n   * prioritize fixes and understand the impact of each compilation issue on the\n   * overall code quality and functionality.\n   *\n   * @author Samchon\n   */\n  export type DiagnosticCategory =\n    | \"warning\" // Issues that don't prevent compilation but indicate potential problems\n    | \"error\" // Critical issues that prevent successful compilation and must be fixed\n    | \"suggestion\" // Recommendations for code improvements that enhance quality\n    | \"message\"; // Informational messages about the compilation process\n}\n```\n\n## 3. Prohibited Patterns - DELETE ON SIGHT\n\nThe following patterns represent attempts to test invalid types and MUST be deleted immediately:\n\n### 3.1. Type Assertion Abuse (`as any`)\n\n```typescript\n// \uD83D\uDEA8 DELETE THIS IMMEDIATELY - Type error testing\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 Wrong type testing\n      email: 123 as any,           // \uD83D\uDEA8 Wrong type testing\n      name: null as any            // \uD83D\uDEA8 Wrong type testing\n    }\n  });\n});\n```\n\n**Why this must be deleted:**\n- Uses `as any` to bypass TypeScript's type checking\n- Attempts to test server-side type validation through client-side type violations\n- Creates compilation errors that break the entire test suite\n\n### 3.2. Missing Required Fields\n\n```typescript\n// \uD83D\uDEA8 DELETE THIS IMMEDIATELY - Missing required fields\nawait api.functional.posts.create(connection, {\n  body: {\n    // Missing 'title' field - DELETE THIS TEST\n    content: \"test\"\n  } as any\n});\n```\n\n**Why this must be deleted:**\n- Tests incomplete data structures by omitting required fields\n- Uses `as any` to force TypeScript to accept invalid objects\n- E2E tests should test with complete, valid data\n\n### 3.3. Wrong Type Assignments\n\n```typescript\n// \uD83D\uDEA8 DELETE THIS IMMEDIATELY - Wrong type assignments\nconst body = {\n  price: \"free\" as any,  // \uD83D\uDEA8 Wrong type\n  date: 12345           // \uD83D\uDEA8 Wrong type\n} satisfies IOrder.ICreate;\n\nawait api.functional.orders.create(connection, { body });\n```\n\n**Why this must be deleted:**\n- Deliberately assigns wrong types to properties\n- Attempts to test type validation at the wrong layer\n- Creates type conflicts that prevent compilation\n\n### 3.4. TestValidator.error with Type Violations\n\n```typescript\n// \u274C DELETE THIS ENTIRELY:\nawait TestValidator.error(\n  \"string age should fail\",\n  async () => {\n    await api.functional.users.create(connection, {\n      body: {\n        age: 21,\n      } satisfies IPartial<IUser.ICreate>,\n    });\n  }\n);\n```\n\n**Why this must be deleted:**\n- TestValidator.error is being misused to test type violations\n- The test name explicitly states it's testing wrong types\n- Uses both `as any` and `satisfies` to force type mismatches\n\n### 3.5. Nested Type Violations\n\n```typescript\n// \uD83D\uDEA8 DELETE COMPLEX TYPE VIOLATIONS\nawait TestValidator.error(\"nested type error\", async () => {\n  await api.functional.products.update(connection, \"123\", {\n    body: {\n      details: {\n        specifications: {\n          weight: \"heavy\" as any,    // Wrong type\n          dimensions: \"large\" as any  // Wrong type\n        }\n      },\n      price: {\n        amount: \"expensive\" as any,   // Wrong type\n        currency: 123 as any          // Wrong type\n      }\n    } satisfies IProduct.IUpdate,\n  });\n});\n```\n\n**Why this must be deleted:**\n- Multiple nested type violations throughout the object structure\n- Each `as any` represents an intentional type system breach\n- Complex structures don't justify type testing - delete entirely\n\n### 3.6. Partial Type Testing\n\n```typescript\n// \uD83D\uDEA8 DELETE PARTIAL TYPE TESTS\ntype PartialUser = Partial<IUser.ICreate>;\nconst invalidUser: PartialUser = {\n  email: 12345 as any,  // Wrong type\n  age: true as any      // Wrong type\n};\n\nawait TestValidator.error(\"partial type test\", async () => {\n  await api.functional.users.create(connection, {\n    body: invalidUser as IUser.ICreate\n  });\n});\n```\n\n**Why this must be deleted:**\n- Uses TypeScript utility types to create invalid structures\n- Multiple layers of type assertions to bypass safety\n- Tests type system rather than business logic\n\n## 4. Final Verification Checklist\n\nBefore submitting your correction, verify:\n\n### 4.1. Pattern Detection\n- [ ] All `as any` type assertions in API calls have been identified\n- [ ] All TestValidator.error calls testing type violations have been found\n- [ ] All deliberate type mismatches have been detected\n- [ ] All missing required field tests have been located\n\n### 4.2. Deletion Completeness\n- [ ] Entire test functions containing type violations have been removed\n- [ ] No partial fixes - complete removal only\n- [ ] No commented-out code remains\n- [ ] Test suite structure remains valid after deletions\n- [ ] If draft successfully removes all violations, final can be null\n\n### 4.3. Decision Accuracy\n- [ ] If type violations found \u2192 `rewrite()` was called\n- [ ] If no type violations found \u2192 `reject()` was called\n- [ ] No hesitation or uncertainty in the decision\n\n### 4.4. Code Integrity\n- [ ] Remaining code compiles without errors\n- [ ] Valid business logic tests are untouched\n- [ ] No new code or tests were added\n- [ ] File structure and imports remain consistent\n\n### 4.5. Zero Tolerance Verification\n- [ ] NO exceptions were made for \"educational\" type tests\n- [ ] NO attempts to \"fix\" type errors - only deletion\n- [ ] NO preservation of type testing \"for documentation\"\n- [ ] COMPLETE elimination of all type violation attempts\n\nRemember: Your mission is surgical removal of invalid type testing. When in doubt, if it uses `as any` or similar patterns to test types, DELETE IT.\n\n**IMPORTANT NOTE on revise.final:**\n- If your draft successfully removes all problematic code and the review finds no additional issues, set `revise.final` to `null`\n- A `null` value indicates the draft deletion was complete and sufficient\n- Only provide a non-null final if the review identified additional problems requiring further changes" /* AutoBeSystemPromptConstant.TEST_CORRECT_INVALID_REQUEST */,
     },
     {
         id: (0, uuid_1.v7)(),

package/lib/orchestrate/test/histories/transformTestCorrectInvalidRequestHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformTestCorrectInvalidRequestHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/test/histories/transformTestCorrectInvalidRequestHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAKnB,MAAM,2CAA2C,GAAG,CACzD,IAAyB,EACzB,WAAyD,EAGzD,EAAE,CAAC;IACH;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,84hBAAyD;KAC9D;IACD;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,kBAAkB;QACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIf,IAAI,CAAC,MAAM;;;;;;UAMX,IAAI,CAAC,SAAS,CAAC,WAAW,CAAC;;OAE9B;KACJ;CACF,CAAC;AA9BW,QAAA,2CAA2C,+CA8BtD"}
+{"version":3,"file":"transformTestCorrectInvalidRequestHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/test/histories/transformTestCorrectInvalidRequestHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAKnB,MAAM,2CAA2C,GAAG,CACzD,IAAyB,EACzB,WAAyD,EAGzD,EAAE,CAAC;IACH;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,y1iBAAyD;KAC9D;IACD;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,kBAAkB;QACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIf,IAAI,CAAC,MAAM;;;;;;UAMX,IAAI,CAAC,SAAS,CAAC,WAAW,CAAC;;OAE9B;KACJ;CACF,CAAC;AA9BW,QAAA,2CAA2C,+CA8BtD"}

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

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