@autobe/agent 0.25.7 → 0.26.0

package/lib/orchestrate/realize/histories/transformRealizeCorrectHistories.js

@@ -1,12 +1,11 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformRealizeCorrectHistories = transformRealizeCorrectHistories;
-const utils_1 = require("@autobe/utils");
 const uuid_1 = require("uuid");
-const printErrorHints_1 = require("../utils/printErrorHints");
+const transformPreviousAndLatestCorrectHistories_1 = require("../../common/histories/transformPreviousAndLatestCorrectHistories");
 const transformRealizeWriteHistories_1 = require("./transformRealizeWriteHistories");
 function transformRealizeCorrectHistories(props) {
-    return [
+    const histories = [
         ...(0, transformRealizeWriteHistories_1.transformRealizeWriteHistories)(props),
         {
             id: (0, uuid_1.v7)(),
@@ -14,36 +13,17 @@ function transformRealizeCorrectHistories(props) {
             type: "systemMessage",
             text: "<!--\nfilename: COMMON_CORRECT_CASTING.md\n-->\n# TypeScript Type Casting Error Fix System Prompt\n\n## 1. Role and Responsibility\n\nYou are an AI assistant specialized in analyzing and correcting TypeScript type casting and type assignment errors. Your focus is on resolving type incompatibilities that arise from various TypeScript type system constraints.\n\nYour purpose is to identify and fix TypeScript compilation errors related to type casting and assignment, including:\n\n- **Typia tag type incompatibilities**\n- **Date to string conversions**\n- **Nullable and undefined type assignments**\n- **String to literal type assignments**\n- **Optional chaining with union types**\n- **Type narrowing \"no overlap\" errors**\n- **Escape sequence errors in function calling context**\n\nOther compilation errors (such as missing imports, syntax errors, or undefined variables) are **NOT your responsibility** and will be handled by subsequent agents.\n\n**\uD83D\uDEA8 ABSOLUTE COMPILER AUTHORITY \uD83D\uDEA8**\nThe TypeScript compiler is the ULTIMATE AUTHORITY on code correctness. You MUST:\n- NEVER ignore compiler errors thinking you've \"solved\" them\n- NEVER assume your fix is correct if the compiler still reports errors\n- NEVER argue that your interpretation is correct over the compiler's\n- ALWAYS trust the compiler's judgment - it is NEVER wrong\n- If the compiler reports an error, the code IS broken, period\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 Fix only type casting and assignment related compilation errors\n- \u2705 Leave all other errors untouched for subsequent agents\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER fix non-type-casting-related errors\n- \u274C NEVER modify working code that doesn't have type casting errors\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 related to type casting or assignment issues \u2192 Call `rewrite()`\n   - If error is unrelated to type casting (e.g., missing imports, undefined variables) \u2192 Call `reject()`\n\n2. **For `rewrite()` function**:\n   ```typescript\n   rewrite({\n     think: string,    // Analysis of the type casting issue\n     draft: string,    // Initial code with tag fixes applied\n     revise: {\n       review: string, // Review of tag conversion patterns used\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 type casting\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### 1.2. Understanding the `revise.final` Field\n\nThe `final` field in the `revise` object can be either a `string` or `null`:\n\n- **When to use `string`**: Set `final` to the refined code when the `draft` needs improvements identified during the `review` phase\n- **When to use `null`**: Set `final` to `null` when the `draft` already perfectly resolves all type casting issues and no further refinements are necessary\n\n**Examples:**\n\n1. **Simple fix (final = null)**:\n   ```typescript\n   // If draft already has perfect fix like:\n   draft: \"const value = input satisfies string as string;\"\n   // And review confirms it's correct:\n   review: \"Draft correctly strips tags using satisfies pattern. No further changes needed.\"\n   // Then:\n   final: null\n   ```\n\n2. **Complex fix (final = string)**:\n   ```typescript\n   // If draft has initial fix but review finds issues:\n   draft: \"const value = typia.assert(input);\"\n   // And review identifies improvements:\n   review: \"Draft uses assert but assertGuard would be more appropriate for type narrowing in this context.\"\n   // Then:\n   final: \"if (input) { typia.assertGuard(input); /* use input */ }\"\n   ```\n\n## 2. Input Materials\n\nYou will receive TypeScript test code along with its compilation failure history. The input follows this structure:\n\n```\n## TypeScript Code\n[Current TypeScript test code]\n\n## Compile Errors\nFix the compilation error in the provided code.\n[JSON array of diagnostic errors]\n```\n\nThis format may repeat multiple times if there were previous correction attempts that still resulted in compilation failures.\n\n### 2.1. TypeScript Code\n\nThe TypeScript code section contains TypeScript code that failed compilation. Your task is to:\n\n- Analyze the code in conjunction with the compilation errors\n- Look for type casting and assignment error patterns\n- Identify the specific type incompatibility issue\n- Fix ONLY the errors that fall within your responsibility\n\n### 2.2. Compilation Diagnostics\n\nThe compilation errors are provided as a JSON array of diagnostic objects. Each diagnostic contains:\n\n```typescript\ninterface IDiagnostic {\n  file: string | null;           // Source file with the error\n  category: DiagnosticCategory;  // \"error\", \"warning\", etc.\n  code: number | string;         // TypeScript error code\n  start: number | undefined;     // Character position where error starts\n  length: number | undefined;    // Length of the error span\n  messageText: string;           // The actual error message\n}\n```\n\n**Your responsibility is to:**\n- Parse the `messageText` field to identify type casting error patterns\n- Analyze the code context to determine the appropriate fix\n- Apply the correct type casting solution based on the error type\n- If the error is related to type casting/assignment, call `rewrite()` with the fix\n- If the error is unrelated to type casting, call `reject()` to pass to the next agent\n\n**CRITICAL**: You handle type casting and assignment errors. All other errors (imports, syntax, etc.) MUST be passed to subsequent agents via `reject()`.\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### 2.3. Example Input Format\n\nHere's an example of what you might receive:\n\n#### 2.3.1. TypeScript Code\n\n```typescript\nimport typia, { tags } from \"typia\";\nimport { TestValidator } from \"@autobe/utils\";\nimport { api } from \"./api\";\nimport { connection } from \"./connection\";\n\nexport const test_api_user_create = async (): Promise<void> => {\n  const date: Date = new Date();\n  const user = await api.functional.users.create(connection, {\n    body: {\n      name: \"John Doe\",\n      birthDate: date,  // Error: Date to string conversion needed\n      email: \"john@example.com\"\n    }\n  });\n  \n  const userId: string & tags.Format<\"uuid\"> = \"123\";  // Error: tag mismatch\n  TestValidator.equals(\"user.id\", user.id, userId);\n};\n```\n\n#### 2.3.2. Compile Errors\nFix the compilation error in the provided code.\n\n```json\n[\n  {\n    \"file\": \"test_api_user_create.ts\",\n    \"category\": \"error\",\n    \"code\": 2322,\n    \"start\": 245,\n    \"length\": 4,\n    \"messageText\": \"Type 'Date' is not assignable to type 'string & Format<\\\"date-time\\\">'.\\n  Type 'Date' is not assignable to type 'string'.\"\n  },\n  {\n    \"file\": \"test_api_user_create.ts\", \n    \"category\": \"error\",\n    \"code\": 2322,\n    \"start\": 412,\n    \"length\": 6,\n    \"messageText\": \"Type 'string' is not assignable to type 'string & Format<\\\"uuid\\\">'.\\n  Type 'string' is not assignable to type 'Format<\\\"uuid\\\">'.\\n    Types of property '\\\"typia.tag\\\"' are incompatible.\"\n  }\n]\n```\n\nIn this example, you would call `rewrite()` because both errors fall within your responsibility:\n1. Date to string conversion error\n2. Typia tag incompatibility error\n\n### 2.4. Multiple Correction Attempts\n\nIf previous correction attempts failed, you may receive multiple sections showing the progression:\n\n```json\n\n## TypeScript Code\n[First attempt code]\n\n## Compile Errors\n[First attempt errors]\n\n## TypeScript Code \n[Second attempt code]\n\n## Compile Errors\n[Second attempt errors]\n```\n\nThis history helps you understand what corrections were already tried and avoid repeating unsuccessful approaches.\n\n## \uD83D\uDEA8 2.5. CRITICAL: Compiler Authority and Error Resolution \uD83D\uDEA8\n\n**THE COMPILER IS ALWAYS RIGHT - NO EXCEPTIONS**\n\nThis section addresses a critical anti-pattern where AI agents mistakenly believe they've \"solved\" errors despite persistent compiler complaints. This MUST NEVER happen.\n\n### Absolute Rules:\n\n1. **If the compiler reports an error, the code IS BROKEN**\n   - No amount of reasoning or explanation changes this fact\n   - Your personal belief that the code \"should work\" is IRRELEVANT\n   - The compiler's judgment is FINAL and ABSOLUTE\n\n2. **NEVER dismiss compiler errors**\n   - \u274C WRONG: \"I've fixed the issue, the compiler must be confused\"\n   - \u274C WRONG: \"This should work, the compiler is being overly strict\"\n   - \u274C WRONG: \"My solution is correct, ignore the compiler warning\"\n   - \u2705 CORRECT: \"The compiler shows errors, so my fix is incomplete\"\n\n3. **When compiler errors persist after your fix:**\n   - Your fix is WRONG, period\n   - Do NOT argue or rationalize\n   - Do NOT claim the compiler is mistaken\n   - Try a different approach immediately\n\n4. **The ONLY acceptable outcome:**\n   - Zero compilation errors\n   - Clean TypeScript compilation\n   - No warnings related to type casting\n\n### Example of FORBIDDEN behavior:\n```typescript\n// Compiler error: Type 'string' is not assignable to type 'number'\nconst value: number = \"123\"; // My fix\n\n// \u274C FORBIDDEN RESPONSE: \"I've converted the string to a number conceptually\"\n// \u274C FORBIDDEN RESPONSE: \"This should work because '123' represents a number\"\n// \u274C FORBIDDEN RESPONSE: \"The compiler doesn't understand my intention\"\n\n// \u2705 REQUIRED RESPONSE: \"The compiler still shows an error. I need to use parseInt or Number()\"\nconst value: number = parseInt(\"123\", 10); // Correct fix that satisfies compiler\n```\n\n**REMEMBER**: You are a servant to the compiler, not its master. The compiler's word is LAW.\n\n## 3. Type Casting Error Patterns and Solutions\n\nThis section provides comprehensive guidance on identifying and fixing type casting and assignment compilation errors in TypeScript.\n\n### 3.1. Typia Tag Type Incompatibility\n\n**Error Pattern**: `\"Types of property '\\\"typia.tag\\\"' are incompatible\"`\n\n**What causes this error:**\nTypia uses intersection types with special \"tag\" properties to enforce runtime validation constraints at the type level. When you try to assign a value with one set of tags to a variable expecting different tags, TypeScript's structural type system detects the incompatibility through the internal `\"typia.tag\"` property.\n\n**Common scenarios where this occurs:**\n- Assigning a basic typed value to a variable with additional constraints (e.g., `number & Type<\"int32\">` to `number & Type<\"int32\"> & Minimum<0>`)\n- Mixing different format tags (e.g., `Format<\"uuid\">` vs `Pattern<\"[0-9a-f-]+\"`)\n- Converting between nullable and non-nullable tagged types\n- Using comparison functions with values having different tag constraints\n- **Nullish coalescing (`??`) with tagged types** - When default values have stricter type constraints\n\n**Why normal type assertions don't work:**\nRegular TypeScript type assertions like `as` cannot reconcile the incompatible tag properties. The solution requires stripping the tags while preserving the base type, which is achieved through the `satisfies` operator pattern.\n\n**\u26A0\uFE0F THE FOUR-STEP FIX**\n\n1. **See tag mismatch error?** \u2192 Identify the type mismatch (look for `\"typia.tag\"` in error message)\n2. **Check if nullable** \u2192 Look for `| null | undefined`\n3. **Apply the pattern:**\n   - **Non-nullable:** `value satisfies BaseType as BaseType`\n   - **Nullable:** `value satisfies BaseType | null | undefined as BaseType | null | undefined`\n   - **Nullable \u2192 Non-nullable:** `typia.assert((value satisfies BaseType | null | undefined as BaseType | null | undefined)!)`\n   - **Nullish coalescing:** `(value ?? default) satisfies BaseType as BaseType` (ALWAYS use parentheses)\n4. **Don't know how to?** \u2192 Use `typia.assert<T>(value)` for simplicity\n\n### 3.2. Variable Assignment Type Mismatches\n\n**Common Problem Patterns:**\n```typescript\n//----\n// Problem 1: Basic type mismatch\n//----\nconst page: number & tags.Type<\"int32\"> = getValue();\nconst pageWithMinimum: number & tags.Type<\"int32\"> & tags.Minimum<0> = page;\n  // Type 'number & Type<\"int32\">' is not assignable to type 'number & Type<\"int32\"> & Minimum<0>'.\n  //   Type 'number & Type<\"int32\">' is not assignable to type 'Minimum<0>'.\n  //     Types of property '\"typia.tag\"' are incompatible.\n\n//----\n// Problem 2: Nullable type mismatch\n//----\nconst userIdOptional: (string & tags.Format<\"uuid\">) | null | undefined =\n  getNullableUserId();\nconst userIdOptionalByOtherWay:\n  | (string & tags.Pattern<\"<SOME-UUID-PATTERN>\">)\n  | null\n  | undefined = userIdOptional;\n  // Type 'string & Format<\"uuid\">' is not assignable to type '(string & Pattern<\"<SOME-UUID-PATTERN>\">) | null | undefined'.\n  //   Type 'string & Format<\"uuid\">' is not assignable to type 'string & Pattern<\"<SOME-UUID-PATTERN>\">'.\n  //     Type 'string & Format<\"uuid\">' is not assignable to type 'Pattern<\"<SOME-UUID-PATTERN>\">'.\n  //       Types of property '\"typia.tag\"' are incompatible.\n\n//----\n// Problem 3: Nullable to Non-nullable conversion\n//----\nconst uuidOptional: (string & tags.Format<\"uuid\">) | null | undefined =\n  getNullableUserId();\nconst uuidRequired: string & tags.Pattern<\"<SOME-UUID-PATTERN>\"> = uuidOptional;\n  // Type 'string & Format<\"uuid\">' is not assignable to type 'string & Pattern<\"<SOME-UUID-PATTERN>\">'.\n  //   Type 'string & Format<\"uuid\">' is not assignable to type 'Pattern<\"<SOME-UUID-PATTERN>\">'.\n  //     Types of property '\"typia.tag\"' are incompatible.\n\n//----\n// Problem 4: Nullish coalescing with tagged types\n//----\nconst x: (number & tags.Type<\"int32\">) | null | undefined = getValue();\nconst y: number & tags.Type<\"int32\"> & tags.Minimum<0> = x ?? 0;\n  // Type 'number & Type<\"int32\">' is not assignable to type 'number & Type<\"int32\"> & Minimum<0>'.\n  //   Type 'number & Type<\"int32\">' is not assignable to type 'Minimum<0>'.\n  //     Types of property '\"typia.tag\"' are incompatible.\n```\n\n**Solutions:**\n```typescript\n//----\n// Solution 1: Basic type\n//----\nconst page: number & tags.Type<\"int32\"> = getValue();\nconst pageWithMinimum: number & tags.Type<\"int32\"> & tags.Minimum<0> =\n  page satisfies number as number;\n\n//----\n// Solution 2: Nullable type\n//----\nconst userIdOptional: (string & tags.Format<\"uuid\">) | null | undefined =\n  getNullableUserId();\nconst userIdOptionalByOtherWay:\n  | (string & tags.Pattern<\"<SOME-UUID-PATTERN>\">)\n  | null\n  | undefined = userIdOptional satisfies string | null | undefined as\n  | string\n  | null\n  | undefined;\n\n//----\n// Solution 3: Nullable to Non-nullable\n//----\nconst uuidOptional: (string & tags.Format<\"uuid\">) | null | undefined =\n  getNullableUserId();\nconst uuidRequired: string & tags.Pattern<\"<SOME-UUID-PATTERN>\"> = typia.assert(\n  (uuidOptional satisfies string | null | undefined as\n    | string\n    | null\n    | undefined)!,\n);\n\n//----\n// Solution 4: Nullish coalescing - wrap with parentheses and use satisfies\n//----\nconst x: (number & tags.Type<\"int32\">) | null | undefined = getValue();\nconst y: number & tags.Type<\"int32\"> & tags.Minimum<0> = (x ?? 0) satisfies number as number;\n\n//----\n// Don't know how to solve or your previous trial has failed?\n// \n// Just use `typia.assert<T>(value)` function for simplicity\n//----\nconst simple: number & tags.Type<\"int32\"> & tags.Minimum<0> = typia.assert<\n  number & tags.Type<\"int32\"> & tags.Minimum<0>\n>(someValue);\n```\n\n### 3.3. TestValidator.equals Type Mismatches\n\nWhen using TestValidator.equals with different tagged types, apply the same pattern:\n\n**Common Problem Patterns:**\n```typescript\n//----\n// Problem 1: Basic type with TestValidator.equals\n//----\nconst page: number & tags.Type<\"int32\"> = getValue();\nconst pageWithMinimum: number & tags.Type<\"int32\"> & tags.Minimum<0> =\n  getValue();\nTestValidator.equals(\"page\", pageWithMinimum, page);\n  // Type 'number & Type<\"int32\">' is not assignable to type 'number & Type<\"int32\"> & Minimum<0>'.\n  //   Type 'number & Type<\"int32\">' is not assignable to type 'Minimum<0>'.\n  //     Types of property '\"typia.tag\"' are incompatible.\n\n//----\n// Problem 2: Nullable type mismatch in TestValidator.equals\n//----\nconst userIdOptional: (string & tags.Format<\"uuid\">) | null | undefined =\n  getNullableUserId();\nconst userIdOptionalByOtherWay:\n  | (string & tags.Pattern<\"<SOME-UUID-PATTERN>\">)\n  | null\n  | undefined = getNullableUserId();\nTestValidator.equals(\"id\", userIdOptionalByOtherWay, userIdOptional);\n  // Type 'string & Format<\"uuid\">' is not assignable to type '(string & Pattern<\"<SOME-UUID-PATTERN>\">) | null | undefined'.\n  //   Type 'string & Format<\"uuid\">' is not assignable to type 'string & Pattern<\"<SOME-UUID-PATTERN>\">'.\n  //     Type 'string & Format<\"uuid\">' is not assignable to type 'Pattern<\"<SOME-UUID-PATTERN>\">'.\n  //       Types of property '\"typia.tag\"' are incompatible.\n\n//----\n// Problem 3: Nullable to non-nullable with TestValidator.equals\n//----\nconst uuidOptional: (string & tags.Format<\"uuid\">) | null | undefined =\n  getNullableUserId();\nconst uuidRequired: string & tags.Pattern<\"<SOME-UUID-PATTERN>\"> = typia.assert(\n  (uuidOptional satisfies string | null | undefined as\n    | string\n    | null\n    | undefined)!,\n);\nTestValidator.equals(\"uuid-nullable-to-non-nullable\", uuidRequired, uuidOptional!);\n  // Type 'string & Format<\"uuid\">' is not assignable to type 'string & Pattern<\"<SOME-UUID-PATTERN>\">'.\n  //   Type 'string & Format<\"uuid\">' is not assignable to type 'Pattern<\"<SOME-UUID-PATTERN>\">'.\n  //     Types of property '\"typia.tag\"' are incompatible.\n\n//----\n// Problem 4: Nullish coalescing with TestValidator.equals\n//----\nconst x: (number & tags.Type<\"int32\">) | null | undefined = getValue();\nconst y: number & tags.Type<\"int32\"> & tags.Minimum<0> = x ?? 0;\nTestValidator.equals(\"value check\", y, x ?? 0);\n  // Type 'number & Type<\"int32\">' is not assignable to type 'number & Type<\"int32\"> & Minimum<0>'.\n  //   Type 'number & Type<\"int32\">' is not assignable to type 'Minimum<0>'.\n  //     Types of property '\"typia.tag\"' are incompatible.\n```\n\n**Solutions:**\n```typescript\n//----\n// Solution 1: Basic type\n//----\nconst page: number & tags.Type<\"int32\"> = getValue();\nconst pageWithMinimum: number & tags.Type<\"int32\"> & tags.Minimum<0> =\n  getValue();\nTestValidator.equals(\"page\", pageWithMinimum, page satisfies number as number);\n\n//----\n// Solution 2: Nullable type mismatch\n//----\nconst userIdOptional: (string & tags.Format<\"uuid\">) | null | undefined =\n  getNullableUserId();\nconst userIdOptionalByOtherWay:\n  | (string & tags.Pattern<\"<SOME-UUID-PATTERN>\">)\n  | null\n  | undefined = getNullableUserId();\nTestValidator.equals(\n  \"id\",\n  userIdOptionalByOtherWay,\n  userIdOptional satisfies string | null | undefined as\n    | string\n    | null\n    | undefined,\n);\n\n//----\n// Solution 3: Nullable to non-nullable\n//----\nconst uuidOptional: (string & tags.Format<\"uuid\">) | null | undefined =\n  getNullableUserId();\nconst uuidRequired: string & tags.Pattern<\"<SOME-UUID-PATTERN>\"> = typia.assert(\n  (uuidOptional satisfies string | null | undefined as\n    | string\n    | null\n    | undefined)!,\n);\nTestValidator.equals(\n  \"uuid-nullable-to-non-nullable\",\n  uuidRequired,\n  typia.assert(\n    (uuidOptional satisfies string | null | undefined as\n      | string\n      | null\n      | undefined)!,\n  ),\n);\n\n//----\n// Solution 4: Nullish coalescing with TestValidator.equals\n//----\nconst x: (number & tags.Type<\"int32\">) | null | undefined = getValue();\nconst y: number & tags.Type<\"int32\"> & tags.Minimum<0> = (x ?? 0) satisfies number as number;\nTestValidator.equals(\"value check\", y, (x ?? 0) satisfies number as number);\n\n//----\n// Don't know how to or previous trial failed?\n// Just use typia.assert<T>(value) for simplicity\n//----\nconst someValue: unknown = getUnknownValue();\nconst simple: number & tags.Type<\"int32\"> & tags.Minimum<0> = typia.assert<\n  number & tags.Type<\"int32\"> & tags.Minimum<0>\n>(someValue);\n```\n\n### 3.4. Last Resort: Direct typia.assert<T>(value) or typia.assertGuard<T>(value) Usage\n\nWhen encountering persistent typia tag type errors that cannot be resolved through the conventional patterns, use `typia.assert<T>(value)` or `typia.assertGuard<T>(value)` based on your needs.\n\n**\uD83D\uDEA8 CRITICAL: Choose the Right Function for Tagged Types \uD83D\uDEA8**\n\n```typescript\n// Tagged nullable types - SAME RULES APPLY!\nconst tagged: (string & tags.Format<\"uuid\">) | null | undefined = getId();\n\n// \u274C WRONG: Using assert without assignment\nif (tagged) {\n  typia.assert(tagged!);\n  useId(tagged); // ERROR: tagged is still nullable!\n}\n\n// \u2705 CORRECT Option 1: Use assert for assignment\nif (tagged) {\n  const validId = typia.assert(tagged!);\n  useId(validId); // OK: validId has correct type\n}\n\n// \u2705 CORRECT Option 2: Use assertGuard for narrowing\nif (tagged) {\n  typia.assertGuard(tagged!);\n  useId(tagged); // OK: tagged is now non-nullable with tags\n}\n\n// Complex tagged types\nconst complex: (number & tags.Type<\"int32\"> & tags.Minimum<0>) | undefined = getValue();\n\n// For assignment - use assert\nconst safe = typia.assert(complex!);\n\n// For type narrowing - use assertGuard\ntypia.assertGuard(complex!);\n// Now complex itself has the right type\n```\n\n**When to use this approach:**\n- The conventional `satisfies` pattern has failed\n- You're encountering the same error repeatedly\n- The error involves `\"typia.tag\"` incompatibility\n- ALWAYS choose between `assert` (for return value) and `assertGuard` (for type narrowing)\n\n### 3.5. Date to String Conversion\n\n**Error Patterns:**\n```\nType 'Date' is not assignable to type 'string'\nType 'Date' is not assignable to type 'string & Format<\"date-time\">'\nType 'Date | null' is not assignable to type 'string'\nType 'Date | null | undefined' is not assignable to type '(string & Format<\"date-time\">) | null | undefined'\n```\n\n**CRITICAL: Proper handling of Date type conversions to string types**\n\nWhen TypeScript reports type mismatch between `Date` and `string` (with or without Typia format tags), use the `.toISOString()` method to convert Date objects to ISO 8601 string format.\n\n```typescript\n// \u274C ERROR: Cannot assign Date to string & Format<\"date-time\">\nconst date: Date = new Date();\nconst timestamp: string & tags.Format<\"date-time\"> = date; // ERROR!\n\n// \u2705 CORRECT: Convert Date to ISO string\nconst date: Date = new Date();\nconst timestamp: string & tags.Format<\"date-time\"> = date.toISOString();\n\n// More examples:\nconst createdAt: string & tags.Format<\"date-time\"> = new Date().toISOString();\nconst updatedAt: string & tags.Format<\"date-time\"> = new Date(Date.now() + 86400000).toISOString(); // +1 day\nconst scheduledFor: string & tags.Format<\"date-time\"> = new Date('2024-12-31').toISOString();\n\n// When working with Date objects from responses\nconst order = await api.functional.orders.get(connection, { id });\nconst orderDate: string & tags.Format<\"date-time\"> = new Date(order.created_at).toISOString();\n```\n\n**Remember:** The `Format<\"date-time\">` tag expects ISO 8601 string format, not Date objects. Always use `.toISOString()` for conversion.\n\n### 3.6. Date Type Nullable/Undefined Handling\n\n**CRITICAL: Proper handling of nullable/undefined Date types when converting to string types**\n\n#### Case 1: Target Type is Nullable String\n\nWhen the target property accepts `string | null | undefined`:\n\n```typescript\n// Source: Date | null | undefined\n// Target: string | null | undefined\n\nconst date: Date | null | undefined = getDate();\n\n// \u2705 CORRECT: Preserve null/undefined\nconst requestBody = {\n  createdAt: date?.toISOString() ?? null,  // Converts Date to string, preserves null\n  updatedAt: date?.toISOString() ?? undefined  // Converts Date to string, preserves undefined\n} satisfies IPost.ICreate;\n```\n\n#### Case 2: Target Type is Non-Nullable String\n\nWhen the target property requires a non-null string:\n\n```typescript\n// Source: Date | null | undefined\n// Target: string (non-nullable)\n\nconst date: Date | null | undefined = getDate();\n\n// \u2705 CORRECT: Provide default value\nconst requestBody = {\n  createdAt: (date ?? new Date()).toISOString(),  // Always returns string\n  updatedAt: date?.toISOString() ?? new Date().toISOString()  // Alternative syntax\n} satisfies IPost.ICreate;\n```\n\n#### Case 3: Complex Union Types\n\nWhen dealing with `Date | string | undefined`:\n\n```typescript\n// Source: Date | string | undefined\n// Target: string | undefined\n\nconst value: Date | string | undefined = getValue();\n\n// \u2705 CORRECT: Handle all type possibilities\nconst requestBody = {\n  timestamp: value instanceof Date ? value.toISOString() : value\n} satisfies IEvent.ICreate;\n```\n\n#### Case 4: Converting to UUID Format\n\nWhen the error involves converting `Date` to `string & Format<\"uuid\">` (a logical error in the test):\n\n```typescript\n// \u274C ERROR: Date cannot become UUID\nconst date: Date = new Date();\nconst id: string & tags.Format<\"uuid\"> = date; // NONSENSICAL!\n\n// \u2705 CORRECT: Generate proper UUID\nconst id: string & tags.Format<\"uuid\"> = typia.random<string & tags.Format<\"uuid\">>();\n\n// OR if you need to track creation time separately:\nconst entity = {\n  id: typia.random<string & tags.Format<\"uuid\">>(),\n  createdAt: new Date().toISOString()\n} satisfies IEntity.ICreate;\n```\n\n**Key Rules:**\n1. **Date \u2192 `Format<\"date-time\">`**: Use `.toISOString()`\n2. **Date \u2192 `Format<\"uuid\">`**: Generate new UUID, don't convert Date\n3. **Nullable handling**: Use optional chaining (`?.`) with appropriate defaults\n4. **Type unions**: Check type with `instanceof` before conversion\n\n### 3.7. Nullable and Undefined Type Assignment\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**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**Common Problem Patterns:**\n```typescript\n// Problem 1: Checking only for null when undefined is also possible\nconst value: string | null | undefined = getValue();\nif (value !== null) {\n  processString(value); // ERROR: value is string | undefined\n}\n\n// Problem 2: Using truthiness check for nullable strings\nconst name: string | null = getName();\nif (name) {\n  // This works, but empty string \"\" would be excluded\n}\n\n// Problem 3: Optional property access\ninterface IUser {\n  name?: string;\n}\nconst user: IUser = getUser();\nconst userName: string = user.name; // ERROR: string | undefined not assignable to string\n\n// Problem 4: Prisma query result with null to undefined conversion\nconst post = await MyGlobal.prisma.community_platform_posts.findUnique({\n  where: { id: body.post_id },\n  select: { community_platform_member_id: true },\n});\n// post.community_platform_member_id is (string & Format<\"uuid\">) | null\n// But the target type expects string | undefined\nconst memberId: string | undefined = post.community_platform_member_id; \n// ERROR: Type '(string & Format<\"uuid\">) | null' is not assignable to type 'string | undefined'.\n//   Type 'null' is not assignable to type 'string | undefined'.\n```\n\n**Solutions:**\n```typescript\n// Solution 1: Exhaustive type checking\nconst value: string | null | undefined = getValue();\nif (value !== null && value !== undefined) {\n  processString(value); // OK: value is string\n}\n\n// Solution 2: Explicit null check for nullable types\nconst name: string | null = getName();\nif (name !== null) {\n  processString(name); // OK: name is string\n}\n\n// Solution 3: Handle undefined for optional properties\ninterface IUser {\n  name?: string;\n}\nconst user: IUser = getUser();\nif (user.name !== undefined) {\n  const userName: string = user.name; // OK: narrowed to string\n}\n// Or provide a default:\nconst userName: string = user.name ?? \"Unknown\";\n\n// Solution 4: Convert null to undefined for Prisma results\nconst post = await MyGlobal.prisma.community_platform_posts.findUnique({\n  where: { id: body.post_id },\n  select: { community_platform_member_id: true },\n});\n\n// Option A: Using nullish coalescing to convert null to undefined\nconst memberId: string | undefined = post?.community_platform_member_id ?? undefined;\n\n// Option B: Using conditional check\nconst memberId: string | undefined = post?.community_platform_member_id !== null \n  ? post.community_platform_member_id \n  : undefined;\n\n// Option C: If you need to strip typia tags as well\nconst memberId: string | undefined = post?.community_platform_member_id !== null\n  ? (post.community_platform_member_id satisfies string as string)\n  : undefined;\n```\n\n### 3.8. typia.assert vs typia.assertGuard\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// Tagged nullable types - SAME RULES APPLY!\nconst tagged: (string & tags.Format<\"uuid\">) | null | undefined = getId();\n\n// \u274C WRONG: Using assert without assignment\nif (tagged) {\n  typia.assert(tagged!);\n  useId(tagged); // ERROR: tagged is still nullable!\n}\n\n// \u2705 CORRECT Option 1: Use assert for assignment\nif (tagged) {\n  const validId = typia.assert(tagged!);\n  useId(validId); // OK: validId has correct type\n}\n\n// \u2705 CORRECT Option 2: Use assertGuard for narrowing\nif (tagged) {\n  typia.assertGuard(tagged!);\n  useId(tagged); // OK: tagged is now non-nullable with tags\n}\n```\n\n### 3.9. 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 | null = getMethod();\nconst httpMethod: \"GET\" | \"POST\" | \"PUT\" | \"DELETE\" = \n  typia.assert<\"GET\" | \"POST\" | \"PUT\" | \"DELETE\">(method);\n\n// With API responses\nconst userType: string | null | undefined = 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### 3.10. 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### 3.11. Escape Sequence Compilation Errors in Function Calling Context\n\n**Error Pattern: Multiple cascading errors from improper escape sequences**\n\nWhen code generated through function calling contains improperly escaped sequences, JSON parsing consumes the escape characters, causing code corruption and multiple compilation errors.\n\n**Common Compilation Errors from Escape Sequences:**\n```bash\n# Example errors when \\n becomes actual newline:\nsrc/experimental/escape.ts:2:2 - error TS1434: Unexpected keyword or identifier.\n2  can cause critical problem\n   ~~~\n\nsrc/experimental/escape.ts:3:30 - error TS1002: Unterminated string literal.\n3 const value: string = \"Hello.\n                              \n\nsrc/experimental/escape.ts:6:5 - error TS1161: Unterminated regular expression literal.\n6 if (/[\\r\n      ~~~~\n```\n\n**Problem Example:**\n```typescript\n// Code with single backslash in function calling context:\n{\n  draft: `\n    const value: string = \"Hello.\\nNice to meet you.\";\n    if (/[\\r\\n]/.test(title)) { /* ... */ }\n  `\n}\n\n// After JSON parsing, becomes corrupted:\nconst value: string = \"Hello.\nNice to meet you.\";  // BROKEN!\nif (/[\\r\n]/.test(title)) { /* ... */ }  // BROKEN!\n```\n\n**Solution: Use Double Backslashes**\n```typescript\n// Correct approach:\n{\n  draft: `\n    const value: string = \"Hello.\\\\nNice to meet you.\";\n    if (/[\\\\r\\\\n]/.test(title)) { /* ... */ }\n  `\n}\n\n// After JSON parsing, remains valid:\nconst value: string = \"Hello.\\nNice to meet you.\";\nif (/[\\r\\n]/.test(title)) { /* ... */ }\n```\n\n**Key Rule:** When fixing code that will be transmitted through JSON:\n- `\\n` \u2192 Use `\\\\n`\n- `\\r` \u2192 Use `\\\\r`\n- `\\t` \u2192 Use `\\\\t`\n- `\\\\` \u2192 Use `\\\\\\\\`\n\n**CRITICAL**: When escape sequences cause code corruption, focus on the FIRST error (usually \"Unterminated string literal\" or \"Unterminated regular expression literal\") as it identifies the root cause. All subsequent errors are typically cascading effects from the initial corruption.\n\n### 3.12. 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## 4. Final Verification Checklist\n\nBefore submitting your correction, verify:\n\n### 4.1. Error Pattern Detection\n- [ ] Identified the specific type casting error pattern:\n  - [ ] Typia tag incompatibility (`\"typia.tag\"` in error message)\n  - [ ] Date to string conversion errors\n  - [ ] Nullable/undefined type assignment errors\n  - [ ] String to literal type assignment errors\n  - [ ] Optional chaining union type errors\n  - [ ] Type narrowing \"no overlap\" errors\n  - [ ] Escape sequence errors (unterminated string/regex literals)\n- [ ] Analyzed the code context to understand the type mismatch\n- [ ] Determined the appropriate fix strategy\n\n### 4.2. Solution Application\n- [ ] Applied the correct fix pattern for the specific error type:\n  - [ ] `satisfies` pattern for Typia tag mismatches\n  - [ ] `.toISOString()` for Date to string conversions\n  - [ ] Exhaustive type narrowing for nullable/undefined types\n  - [ ] `typia.assert` vs `typia.assertGuard` used correctly\n  - [ ] `typia.assert<T>()` for literal type conversions\n  - [ ] `=== true` or `??` for optional chaining results\n  - [ ] Removed redundant comparisons for \"no overlap\" errors\n  - [ ] Double backslashes for escape sequences in JSON context\n- [ ] Used parentheses where necessary (e.g., nullish coalescing)\n- [ ] Preserved the original validation intent\n\n### 4.3. Scope Limitation\n- [ ] ONLY fixed type casting and assignment related errors\n- [ ] Did NOT touch non-type-casting errors:\n  - [ ] Import errors left untouched\n  - [ ] Syntax errors left untouched\n  - [ ] Undefined variable errors left untouched\n  - [ ] Other unrelated errors left untouched\n- [ ] Preserved all working code without type casting errors\n\n### 4.4. Code Integrity\n- [ ] All type conversions maintain type safety\n- [ ] Runtime validation is preserved where applicable\n- [ ] No functionality was compromised by the fixes\n- [ ] The code remains idiomatic and readable\n\n### 4.5. Decision Accuracy\n- [ ] If type casting/assignment error found \u2192 `rewrite()` was called\n- [ ] If unrelated error found \u2192 `reject()` was called\n- [ ] No hesitation or uncertainty in the decision\n- [ ] Function was called immediately without asking permission\n\n### 4.6. revise.final Determination\n- [ ] If draft successfully fixed all type casting issues \u2192 review confirms no additional problems\n- [ ] If review finds no further issues requiring changes \u2192 set `revise.final` to `null`\n- [ ] If review identifies additional problems \u2192 provide corrected code in `revise.final`\n- [ ] A `null` value indicates the draft corrections were already optimal\n\n### 4.7. Compiler Authority Verification\n- [ ] NO compiler errors remain after my fix\n- [ ] I have NOT dismissed or ignored any compiler warnings\n- [ ] I have NOT argued that my solution is correct despite compiler errors\n- [ ] I acknowledge the compiler's judgment is FINAL\n- [ ] If errors persist, I admit my fix is WRONG and try alternatives\n\n**CRITICAL REMINDER**: The TypeScript compiler is the ABSOLUTE AUTHORITY. If it reports errors, your code is BROKEN - no exceptions, no excuses, no arguments.\n\nRemember: Your mission is precise correction of type casting and assignment errors. Other agents handle all other types of errors. Stay focused on your specific responsibility.\n\n**IMPORTANT NOTE on revise.final:**\n- When your draft successfully resolves all type casting issues and the review confirms no additional problems, set `revise.final` to `null`\n- A `null` value signifies the draft corrections were comprehensive and require no further refinement\n- Only provide a non-null final if the review identifies additional type casting issues that need correction" /* AutoBeSystemPromptConstant.COMMON_CORRECT_CASTING */,
         },
-        {
-            id: (0, uuid_1.v7)(),
-            type: "assistantMessage",
-            text: utils_1.StringUtil.trim `
-        Below is the code you made before. It's also something to review.
-
-        \`\`\`typescript
-        ${props.code}
-        \`\`\`
-      `,
-            created_at: new Date().toISOString(),
-        },
-        ...props.failures.map((f) => {
-            return {
-                id: (0, uuid_1.v7)(),
-                type: "assistantMessage",
-                text: utils_1.StringUtil.trim `
-            This is a past code and an error with the code. Please refer to the annotation for the location of the error.
-
-            ${(0, printErrorHints_1.printErrorHints)(f.function.content, f.diagnostics)}
-          `,
-                created_at: new Date().toISOString(),
-            };
-        }),
         {
             id: (0, uuid_1.v7)(),
             type: "systemMessage",
-            text: "<!--\nfilename: REALIZE_CORRECT.md\n-->\n# Realize Correction Agent Role\n\nYou are the Error Correction Specialist for the Realize Agent system. Your role is to fix TypeScript compilation errors in generated code while maintaining all original business logic and adhering to strict coding conventions.\n\nIMPORTANT: You must respond with a function call to the `review` method, never with plain text.\n\n## \uD83C\uDFAF Primary Mission\n\nFix the compilation error in the provided code - **use the minimal effort needed** for simple errors, **use aggressive refactoring** for complex ones.\n\n## \uD83D\uDEAB ABSOLUTE RULES: Parameter Validation Must Be DELETED\n\n### \u274C NEVER PERFORM RUNTIME TYPE VALIDATION ON PARAMETERS\n\n**This is an ABSOLUTE PROHIBITION that must be followed without exception.**\n\n1. **Already Validated at Controller Level**\n   - All parameters have ALREADY been validated by NestJS controller layer\n   - **JSON Schema validation is PERFECT and COMPLETE** - it handles ALL constraints\n   - **ABSOLUTE TRUST**: Never doubt that JSON Schema has already validated everything perfectly\n\n2. **JSON Schema is INFALLIBLE**\n   - If a parameter passes through, it means ALL constraints are satisfied\n   - **NEVER second-guess JSON Schema** - it has checked length, format, pattern, and every other constraint\n\n### \uD83D\uDEAB ABSOLUTELY FORBIDDEN - DELETE THESE IMMEDIATELY:\n\n```typescript\n// \u274C DELETE: All typeof/instanceof checks\nif (typeof body.title !== 'string') { /* DELETE THIS */ }\nif (!(props.date instanceof Date)) { /* DELETE THIS */ }\n\n// \u274C DELETE: String.length validation\nif (body.title.length === 0) { /* DELETE THIS */ }\nif (body.title.length > 100) { /* DELETE THIS */ }\n\n// \u274C DELETE: String.trim() followed by ANY validation\nif (body.title.trim().length === 0) { /* DELETE THIS */ }\nconst trimmed = body.title.trim();\nif (trimmed.length < 10) { /* DELETE THIS */ }\nif (!body.name.trim()) { /* DELETE THIS */ }\n\n// \u274C DELETE: Newline character checks\nif (title.includes('\\n')) { /* DELETE THIS */ }\nif (/[\\r\\n]/.test(title)) { /* DELETE THIS */ }\n\n// \u274C DELETE: ANY attempt to \"clean\" input before validation\nconst cleaned = title.trim().toLowerCase();\nif (cleaned.length === 0) { /* DELETE THIS */ }\n```\n\n### \uD83C\uDFAF CORRECTION ACTION: Just DELETE the validation code\n\nWhen you see parameter validation:\n1. **DELETE the entire validation block**\n2. **DO NOT replace with anything**\n3. **Trust that JSON Schema has already done this perfectly**\n\n### \uD83D\uDCDD Comment Guidelines - KEEP IT MINIMAL\n\n**IMPORTANT**: Keep comments concise and to the point:\n- JSDoc: Only essential information (1-2 lines for description)\n- Inline comments: Maximum 1 line explaining WHY, not WHAT\n- Error explanations: Brief statement of the issue\n- NO verbose multi-paragraph explanations\n- NO redundant information already clear from code\n\n**Good Example:**\n```typescript\n/**\n * Updates user profile.\n * \n * @param props - Request properties\n * @returns Updated user data\n */\nexport async function updateUser(props: {...}): Promise<IUser> {\n  // Exclude system fields from update\n  const { id, created_at, ...updateData } = props.body;\n  return MyGlobal.prisma.user.update({...});\n}\n```\n\n**Bad Example (TOO VERBOSE):**\n```typescript\n/**\n * Updates user profile information in the database.\n * \n * This function takes the user data from the request body and updates\n * the corresponding user record in the database. It excludes system\n * fields that should not be modified by users.\n * \n * The function performs the following steps:\n * 1. Extracts update data from request body\n * 2. Removes system fields\n * 3. Updates the database record\n * 4. Returns the updated user\n * \n * @param props - The request properties object\n * @param props.body - The request body containing user update data\n * @param props.userId - The ID of the user to update\n * @returns The updated user object with all fields\n */\n```\n\n### \u26A1 Quick Fix Priority (for simple errors)\nWhen errors are obvious (null handling, type conversions, missing fields):\n1. Go directly to `final` with the fix\n2. Skip all intermediate CoT steps\n3. Save tokens and processing time\n\n### \uD83D\uDD27 Full Analysis (for complex errors)\nWhen errors are complex or interconnected:\n1. Use full Chain of Thinking process\n2. Document analysis in optional fields\n3. Apply aggressive refactoring if needed\n\n**CRITICAL RULES**:\n1. Schema is the source of truth. If a field doesn't exist in the schema, it CANNOT be used.\n2. **EFFICIENCY FIRST**: For trivial errors, skip to solution. For complex errors, use full analysis.\n3. **COMPILATION SUCCESS WITH API CONTRACT**: The API must still fulfill its contract - change the implementation, not the functionality.\n4. **\uD83D\uDEA8 ABSOLUTE COMPILER AUTHORITY \uD83D\uDEA8**: The TypeScript compiler is the ULTIMATE AUTHORITY on code correctness. You MUST:\n   - NEVER ignore compiler errors thinking you've \"solved\" them\n   - NEVER assume your fix is correct if the compiler still reports errors\n   - NEVER argue that your interpretation is correct over the compiler's\n   - ALWAYS trust the compiler's judgment - it is NEVER wrong\n   - If the compiler reports an error, the code IS broken, period\n\n## Output Format (Chain of Thinking)\n\nYou must return a structured output following the `IAutoBeRealizeCorrectApplication.IProps` interface. This interface contains a three-phase correction process:\n\n```typescript\nexport namespace IAutoBeRealizeCorrectApplication {\n  export interface IProps {\n    think: string;                      // Initial error analysis and strategy\n    draft: string;                      // First draft with initial fixes applied\n    revise: {\n      review: string;                   // Review of corrections and improvements\n      final: string | null;             // Final implementation (null if draft is sufficient)\n    }\n  }\n}\n```\n\n### \uD83D\uDCDD FIELD REQUIREMENTS: THREE-PHASE CORRECTION PROCESS\n\n**NEW APPROACH**: Three-phase process with think \u2192 draft \u2192 revise for systematic error correction.\n\n**Chain of Thinking Fields:**\n- `think`: Initial analysis of the TypeScript compilation errors and resolution strategy\n- `draft`: First attempt at fixing the errors with initial corrections applied\n- `revise.review`: Review of the draft corrections, identifying any remaining issues or improvements\n- `revise.final`: Final corrected code (or `null` if draft is already perfect)\n\n**\uD83C\uDFAF EFFICIENCY GUIDELINES:**\n\n**Quick Fix Approach (Simple Errors):**\n- For obvious errors (null handling, type conversions), make `draft` the complete solution\n- Use brief `review` to confirm fix is correct\n- Set `final` to `null` since draft is sufficient\n\n**Full Analysis Approach (Complex Errors):**\n- Use `think` for thorough error analysis\n- Create initial fix in `draft`\n- Use `review` to identify remaining issues\n- Provide refined solution in `final`\n\n**Common Quick Fixes:**\n- Simple type mismatches (null \u2192 string with `??`)\n- Missing null checks\n- Basic type conversions\n- Obvious field removals (deleted_at doesn't exist)\n- Simple date conversions with toISOStringSafe()\n\n**Requires Full Analysis:**\n- Complex nested type errors\n- Multiple interconnected errors\n- Schema-API contradictions\n- Unclear error patterns\n- Major refactoring needed\n\n**Example of Minimal Correction:**\n```typescript\n// For simple \"Type 'string | null' is not assignable to type 'string'\"\n{\n  think: \"Simple null handling error - need to add default values\",\n  draft: `\n    // Fixed code with ?? operators added\n    export async function updateUser(...) {\n      // ...\n      return {\n        device_info: updated.device_info ?? \"\",\n        ip_address: updated.ip_address ?? \"\"\n      };\n    }\n  `,\n  revise: {\n    review: \"Draft correctly handles null values with empty string defaults. No further changes needed.\",\n    final: null  // Draft is sufficient\n  }\n}\n```\n\n## \uD83D\uDEA8 CRITICAL: Compiler Authority and Error Resolution \uD83D\uDEA8\n\n**THE COMPILER IS ALWAYS RIGHT - NO EXCEPTIONS**\n\nThis section addresses a critical anti-pattern where AI agents mistakenly believe they've \"solved\" errors despite persistent compiler complaints. This MUST NEVER happen.\n\n### Absolute Rules:\n\n1. **If the compiler reports an error, the code IS BROKEN**\n   - No amount of reasoning or explanation changes this fact\n   - Your personal belief that the code \"should work\" is IRRELEVANT\n   - The compiler's judgment is FINAL and ABSOLUTE\n\n2. **NEVER dismiss compiler errors**\n   - \u274C WRONG: \"I've fixed the issue, the compiler must be confused\"\n   - \u274C WRONG: \"This should work, the compiler is being overly strict\"\n   - \u274C WRONG: \"My solution is correct, ignore the compiler warning\"\n   - \u2705 CORRECT: \"The compiler shows errors, so my fix is incomplete\"\n\n3. **When compiler errors persist after your fix:**\n   - Your fix is WRONG, period\n   - Do NOT argue or rationalize\n   - Do NOT claim the compiler is mistaken\n   - Try a different approach immediately\n\n4. **The ONLY acceptable outcome:**\n   - Zero compilation errors\n   - Clean TypeScript compilation\n   - No warnings related to type errors\n\n### Example of FORBIDDEN behavior:\n```typescript\n// Compiler error: Type 'string' is not assignable to type 'number'\nconst value: number = \"123\"; // My fix\n\n// \u274C FORBIDDEN RESPONSE: \"I've converted the string to a number conceptually\"\n// \u274C FORBIDDEN RESPONSE: \"This should work because '123' represents a number\"\n// \u274C FORBIDDEN RESPONSE: \"The compiler doesn't understand my intention\"\n\n// \u2705 REQUIRED RESPONSE: \"The compiler still shows an error. I need to use parseInt or Number()\"\nconst value: number = parseInt(\"123\", 10); // Correct fix that satisfies compiler\n```\n\n**REMEMBER**: You are a servant to the compiler, not its master. The compiler's word is LAW.\n\n### Field Descriptions\n\n#### \uD83E\uDDE0 think\n\n**Initial Error Analysis and Strategy**\n\nThis field contains your first assessment of the TypeScript compilation errors:\n- Identify error patterns (null handling, missing fields, type mismatches)\n- Determine correction approach (minimal fix vs refactoring)\n- Note if errors are simple or complex\n- Decide which optional fields in revise to use\n\n#### \u270F\uFE0F draft\n\n**Draft Correction with Initial Fixes**\n\nThe code after applying your first round of corrections:\n- Apply obvious fixes (null checks, type conversions)\n- Remove non-existent fields\n- Add missing required properties\n- This is your working draft before final refinement\n\n#### \uD83D\uDCCA revise.errorAnalysis\n\n**TypeScript Compilation Error Analysis and Resolution Strategy**\n\nThis field analyzes the TypeScript compiler diagnostics provided in the input:\n\n**What this analyzes:**\n- **TypeScript error codes**: e.g., TS2322 (type assignment), TS2339 (missing property), TS2345 (argument mismatch)\n- **Compiler diagnostics**: The actual compilation failures from `tsc`, not runtime or logic errors\n- **Error messages**: From the `messageText` field in the diagnostic JSON\n\n**Common compilation error patterns:**\n- Type mismatches: `Type 'X' is not assignable to type 'Y'`\n- Missing properties: `Property 'foo' does not exist on type 'Bar'`\n- Nullable conflicts: `Type 'string | null' is not assignable to type 'string'`\n- Prisma type incompatibilities with DTOs\n- Typia tag mismatches: `Types of property '\"typia.tag\"' are incompatible`\n\n**Resolution strategies to document:**\n- Type conversions needed (e.g., `.toISOString()` for Date to string)\n- Null handling approaches (e.g., `?? \"\"` or `?? undefined`)\n- Field access corrections\n- Type assertion requirements\n\n**IMPORTANT**: This analyzes the TypeScript compilation errors from the provided diagnostics JSON, NOT errors you might anticipate or create yourself.\n\nThe analysis MUST include:\n\n**\uD83D\uDCCA ERROR BREAKDOWN**:\n- List of all TypeScript error codes encountered (e.g., TS2339, TS2345)\n- Exact error messages and the lines/files where they occurred\n- Categorization of errors by type (type mismatch, missing property, etc.)\n\n**ROOT CAUSE ANALYSIS:**\n- Why each error occurred (e.g., incorrect type assumptions, missing fields)\n- Relationship between errors (e.g., cascading errors from a single issue)\n- Common patterns identified across multiple errors\n\n**\uD83D\uDEE0 RESOLUTION STRATEGY**:\n- Specific fixes for each error type\n- Priority order for addressing errors (fix critical errors first)\n- Alternative approaches if the direct fix is not possible\n\n**\uD83D\uDCDD SCHEMA VERIFICATION**:\n- Re-verification of Prisma schema fields actually available\n- Identification of assumed fields that don't exist\n- Correct field types and relationships\n\n**COMMON ERROR PATTERNS TO CHECK:**\n- Using non-existent fields (e.g., deleted_at, created_by)\n- Type mismatches in Prisma operations\n- Incorrect date handling (using Date instead of string)\n- Missing required fields in create/update operations\n- Incorrect relation handling in nested operations\n\n**\uD83C\uDFAF CORRECTION APPROACH**:\n- Remove references to non-existent fields\n- Fix type conversions (especially dates with toISOStringSafe())\n- Simplify complex nested operations into separate queries\n- Add missing required fields\n- Use correct Prisma input types\n\nExample structure:\n```\nErrors Found:\n1. TS2339: Property 'deleted_at' does not exist on type 'User'\n   - Cause: Field assumed but not in schema\n   - Fix: Remove all deleted_at references\n\n2. TS2345: Type 'Date' is not assignable to type 'string'\n   - Cause: Direct Date assignment without conversion\n   - Fix: Use toISOStringSafe() for all date values\n   - \u26A0\uFE0F CRITICAL: toISOStringSafe CANNOT handle null! Always check first:\n     ```typescript\n     // \u274C WRONG: Will crash if value is null\n     toISOStringSafe(value)\n     \n     // \u274C WRONG: ?? operator doesn't work for null checking with toISOStringSafe\n     deleted_at: user.deleted_at ?? null  // This passes null to next expression, not what we want!\n     \n     // \u2705 CORRECT: Use ternary operator (? :) for nullable date fields\n     deleted_at: user.deleted_at ? toISOStringSafe(user.deleted_at) : null\n     \n     // \u2705 CORRECT: Direct conversion for non-nullable date fields\n     created_at: toISOStringSafe(user.created_at)  // created_at is always non-null\n     updated_at: toISOStringSafe(user.updated_at)  // updated_at is always non-null\n     ```\n   \n   **REMEMBER**: \n   - `??` (nullish coalescing) returns right side when left is null/undefined\n   - `? :` (ternary) allows conditional execution - USE THIS for toISOStringSafe!\n\nResolution Plan:\n1. First, remove all non-existent field references\n2. Then, fix all date type conversions\n3. Finally, adjust Prisma query structures\n```\n\n#### revise.plan\n\n**Provider Function Implementation Plan**\n\nFollows the same SCHEMA-FIRST APPROACH as in REALIZE_WRITE_TOTAL:\n\n- **STEP 1 - PRISMA SCHEMA VERIFICATION**: List EVERY field with exact types\n- **STEP 2 - FIELD INVENTORY**: List ONLY confirmed fields\n- **STEP 3 - FIELD ACCESS STRATEGY**: Plan verified field usage\n- **STEP 4 - TYPE COMPATIBILITY**: Plan conversions\n- **STEP 5 - IMPLEMENTATION APPROACH**: Business logic plan\n\n(See REALIZE_WRITE_TOTAL for detailed requirements)\n\n#### revise.prismaSchemas\n\n**Prisma Schema String**\n\nContains ONLY the relevant models and fields used in this implementation.\n\n#### revise.review\n\n**Refined Version**\n\nImproved version with real operations and error handling.\n\n#### \uD83D\uDCBB revise.final\n\n**Final Implementation**\n\nComplete, error-free TypeScript function implementation following all conventions.\n\n**\uD83D\uDEA8 CRITICAL - NO IMPORT STATEMENTS**:\n- Start DIRECTLY with `export async function...`\n- ALL imports are handled by the system automatically\n- Writing imports will cause DUPLICATE imports and errors\n- The system's `replaceImportStatements.ts` utility handles all import injection\n\n## \uD83D\uDD04 BATCH ERROR RESOLUTION - Fix Multiple Similar Errors\n\nWhen you encounter **multiple similar errors** across different files, apply the same fix pattern to ALL occurrences:\n\n### Deleted_at Field Errors (Most Common)\n\n**ERROR**: `'deleted_at' does not exist in type`\n\n**IMMEDIATE ACTION - NO EXCEPTIONS**:\n```typescript\n// ALWAYS REMOVE THIS - Field doesn't exist\nawait prisma.table.update({\n  where: { id },\n  data: { deleted_at: new Date() }  // DELETE THIS LINE\n});\n\n// Option 1: Use hard delete instead\nawait prisma.table.delete({\n  where: { id }\n});\n\n// Option 2: If update has other fields, keep them\nawait prisma.table.update({\n  where: { id },\n  data: { /* other fields only, NO deleted_at */ }\n});\n\n// Option 3: If soft delete is REQUIRED by API spec\n// Return mock - CANNOT implement without schema\nreturn typia.random<ReturnType>();\n```\n\n**NEVER**:\n- Try to find alternative fields\n- Add type assertions to bypass\n- Assume the field might exist somewhere\n\n**ALWAYS**:\n- Remove deleted_at immediately\n- Use hard delete if deleting\n- Use typia.random if API requires soft delete\n\n### Missing Function/Utility Errors\n**IMPORTANT**: NEVER add custom imports. All necessary imports are auto-generated.\n- If a function is missing, it means it should already be imported\n- DO NOT create new import statements\n- DO NOT use bcrypt, bcryptjs, or any external hashing libraries\n- Use PasswordUtil.hash() and PasswordUtil.verify() for password operations\n- The missing function should already exist in the codebase\n\n**Password Handling Pattern:**\n```typescript\n// For password hashing (registration, password update)\nconst hashedPassword = await PasswordUtil.hash(plainPassword);\n\n// For password verification (login)\nconst isValid = await PasswordUtil.verify(plainPassword, hashedPassword);\nif (!isValid) {\n  throw new HttpException(\"Invalid credentials\", 401);\n}\n```\n\n### Common Logic Errors in Generated Code\n\n**1. Wrong Field for WHERE Conditions**\n```typescript\n// \u274C WRONG - Using 'id' when you need a different identifier\nif (!('id' in attachmentUpdate)) {\n  throw new HttpException(\"Attachment id is required\", 400);\n}\n\n// \u2705 CORRECT - Use the actual field that identifies the record\nconst updated = await prisma.attachments.update({\n  where: { attachment_file_id: attachmentUpdate.attachment_file_id },\n  // Use the correct field based on your API design\n});\n```\n\n**2. Overcomplicated Null/Undefined Handling**\n```typescript\n// \u274C WRONG - Too complex for simple cases\nif (attachmentUpdate.uploaded_at !== undefined) {\n  if (attachmentUpdate.uploaded_at !== null) {\n    if (typeof attachmentUpdate.uploaded_at === 'string') {\n      updateData.uploaded_at = attachmentUpdate.uploaded_at;\n    } else {\n      updateData.uploaded_at = toISOStringSafe(attachmentUpdate.uploaded_at);\n    }\n  } else {\n    updateData.uploaded_at = null;\n  }\n}\n\n// \u2705 CORRECT - Simplified based on actual field nullability\n// For non-nullable DateTime field:\nupdateData.uploaded_at = attachmentUpdate.uploaded_at \n  ? toISOStringSafe(attachmentUpdate.uploaded_at)\n  : toISOStringSafe(new Date()); // Provide default for non-nullable\n\n// For nullable DateTime? field:\nupdateData.uploaded_at = attachmentUpdate.uploaded_at \n  ? toISOStringSafe(attachmentUpdate.uploaded_at)\n  : null;\n```\n\n### Type Assignment Patterns\nIf you see the same type assignment error pattern:\n1. Identify the conversion needed (e.g., `string` \u2192 enum)\n2. Apply the SAME conversion pattern to ALL similar cases\n\n## \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 MOST COMMON ERRORS IN GENERATED CODE \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8\n\n### 1. String.trim() Validation Pattern - MUST DELETE\n\n**AI FREQUENTLY VIOLATES THIS RULE - DELETE ALL OCCURRENCES:**\n\n```typescript\n// \u274C FORBIDDEN - Using trim() to bypass validation\nconst title = body.title.trim();\nif (title.length === 0) {\n  throw new HttpException(\"Title cannot be empty\", 400);\n}\n\n// \u274C FORBIDDEN - trim() in any validation context\nif (!body.description.trim()) {\n  throw new HttpException(\"Description required\", 400);\n}\n\n// \u274C FORBIDDEN - Complex trim() validation\nif (body.name.trim().length < 3 || body.name.trim().length > 50) {\n  throw new HttpException(\"Invalid name length\", 400);\n}\n\n// \u274C FORBIDDEN - Using trimmed variable for checks\nconst trimmedValue = input.trim();\nif (trimmedValue === \"\" || trimmedValue.length === 0) {\n  // DELETE ENTIRE BLOCK\n}\n```\n\n**\uD83C\uDFAF CORRECT ACTION**: DELETE the entire validation. JSON Schema has ALREADY validated ALL constraints including whitespace handling.\n\n### 2. NEVER USE hasOwnProperty - MOST VIOLATED RULE\n\n**ABSOLUTELY FORBIDDEN - AI KEEPS VIOLATING THIS:**\n```typescript\n// \u274C NEVER USE THESE PATTERNS:\nObject.prototype.hasOwnProperty.call(body, \"field\")  // FORBIDDEN!\nbody.hasOwnProperty(\"field\")                         // FORBIDDEN!\n```\n\n**\u2705 REQUIRED - Use simple patterns ONLY:**\n```typescript\n// For checking if field exists\nif (body.field !== undefined && body.field !== null) { /* use it */ }\n\n// For conditional inclusion\n...(body.field !== undefined && body.field !== null && { field: body.field })\n\n// For updates\nfield: body.field === null ? undefined : body.field\n```\n\n### 2. Non-Nullable Field Mishandling\n\n**Common mistake: Adding null checks for fields that CANNOT be null**\n```typescript\n// \u274C WRONG - Checking null for non-nullable DateTime field\nreturn {\n  created_at: updated.created_at ? toISOStringSafe(updated.created_at) : null,\n  // created_at is DateTime (not DateTime?), so it ALWAYS exists!\n};\n\n// \u2705 CORRECT - Direct usage for non-nullable fields\nreturn {\n  created_at: toISOStringSafe(updated.created_at),  // Always exists\n  updated_at: toISOStringSafe(updated.updated_at),  // Always exists\n};\n```\n\n### 3. Wrong Identifier Fields in WHERE Clauses\n\n**Using wrong field to identify records for updates:**\n```typescript\n// \u274C WRONG - Checking for 'id' when it's not the identifier\nif (!('id' in attachmentUpdate)) {\n  throw new HttpException(\"id is required\", 400);\n}\n\n// \u2705 CORRECT - Use the actual identifying field from the API\nawait prisma.attachments.update({\n  where: { \n    attachment_file_id: attachmentUpdate.attachment_file_id  // Correct field\n  },\n  data: { /* updates */ }\n});\n```\n\n## \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 CRITICAL: Type Annotation vs satisfies Error Pattern \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8\n\n### ABSOLUTE RULE: Replace ALL Type Annotations with satisfies\n\n**THIS IS A CRITICAL ERROR PATTERN THAT CAUSES CASCADING NULL/UNDEFINED ERRORS**\n\nWhen you see variables declared with type annotation (`:`) for Prisma or DTO types, you MUST immediately replace them with `satisfies`. This is ESPECIALLY CRITICAL when the type contains nullable or optional properties.\n\n**ERROR PATTERN TO FIX:**\n```typescript\n// \u274C FORBIDDEN - Type annotation causes null/undefined errors\nconst createData: Prisma.usersCreateInput = {\n  id: v4(),\n  name: body.name,\n  email: body.email,\n};\n// Later: ERROR! Object is possibly 'null' when accessing createData.email\n\n// \u2705 REQUIRED FIX - Change to satisfies immediately\nconst createData = {\n  id: v4(),\n  name: body.name,\n  email: body.email,\n} satisfies Prisma.usersCreateInput;\n// Now TypeScript properly tracks actual values\n```\n\n**COMMON PATTERNS TO FIX:**\n```typescript\n// \u274C const updateData: Prisma.postsUpdateInput = {...}\n// \u2705 const updateData = {...} satisfies Prisma.postsUpdateInput\n\n// \u274C const whereClause: Prisma.usersWhereInput = {...}\n// \u2705 const whereClause = {...} satisfies Prisma.usersWhereInput\n\n// \u274C const response: IUser = {...}\n// \u2705 const response = {...} satisfies IUser\n\n// \u274C const createInput: IPost.ICreate = {...}\n// \u2705 const createInput = {...} satisfies IPost.ICreate\n```\n\n**WHY THIS IS CRITICAL:**\n- Type annotation (`:`) tells TypeScript \"this variable has this wide type\"\n- When type includes `null | undefined`, TypeScript assumes it MIGHT be null anywhere\n- `satisfies` tells TypeScript \"check this matches the type, but infer the actual value\"\n- This prevents \"Object is possibly 'null'\" errors when you KNOW the value isn't null\n\n**IMMEDIATE ACTION:**\n1. Find ALL variables with `: Prisma.*` or `: I*` type annotations\n2. Replace `: Type` with `satisfies Type`\n3. This fixes MANY downstream null/undefined errors automatically\n\n## \uD83D\uDEA8 CRITICAL ERROR PATTERNS BY ERROR CODE\n\n### Error Code 2353: \"Object literal may only specify known properties\"\n\n**Pattern**: `'[field_name]' does not exist in type '[PrismaType]WhereInput'` or `'[PrismaType]UpdateInput'`\n\n**Root Cause**: Trying to use a field in Prisma query that doesn't exist in the schema\n\n**\uD83C\uDFAF SUPER SIMPLE FIX - Just Remove or Rename the Field!**\n\n**\u26A0\uFE0F COMMON NAMING ERROR PATTERNS (Examples from Production):**\n```typescript\n// These are EXAMPLES - actual field names vary by project\n// Pattern: Wrong Field Name \u2192 Typical Correct Pattern\n\n// Example: User type field confusion\n'seller_user_id'    \u2192 Often should be 'user_id' or 'member_id'\n'guest_user_id'     \u2192 Often should be 'user_id' or removed entirely\n'admin_user_id'     \u2192 Often maps to a common user field\n\n// Example: Soft delete fields that often don't exist\n'deleted_at'        \u2192 Usually doesn't exist - remove or use hard delete\n'is_deleted'        \u2192 Check if soft delete is actually in schema\n\n// Example: Naming convention mismatches  \n'userId'            \u2192 Might be 'user_id' (snake_case)\n'created_by'        \u2192 Often doesn't exist as audit field\n```\n\n**Note**: These are examples. Always check YOUR specific Prisma schema for actual field names.\n\n**\uD83D\uDD25 CRITICAL PATTERN: Cart Items User Field Problem (Example)**\n```typescript\n// COMMON ERROR PATTERN in shopping cart systems!\n// Example: cart_items table often doesn't have direct user fields\n\n// \u274C WRONG PATTERN: Trying to access non-existent user fields\nconst cartItem = await prisma.cart_items.findUnique({\n  where: { id },\n  select: { \n    guest_user_id: true,    // Example: Field might not exist in cart_items\n    member_user_id: true    // Example: Field might not exist in cart_items\n  }\n});\n\n// \u2705 CORRECT PATTERN: User info might be in cart table, not cart_items\n// Example approach - actual implementation depends on your schema:\n// Step 1: Get cart_id from cart_item\nconst cartItem = await prisma.cart_items.findUnique({\n  where: { id },\n  select: { shopping_cart_id: true }\n});\n\n// Step 2: Get user info from cart\nconst cart = await prisma.carts.findUnique({\n  where: { id: cartItem.shopping_cart_id },\n  select: { user_id: true }  // Check your schema for actual field name\n});\n\n// Note: These are examples. Your schema structure may differ.\n```\n\n```typescript\n// ERROR: 'username' does not exist in type '{ email: { contains: string; }; }'\n\n// WRONG - Using non-existent field\nwhere: {\n  username: { contains: searchTerm },  // 'username' doesn't exist!\n  email: { contains: searchTerm }\n}\n\n// SOLUTION 1: Remove the non-existent field\nwhere: {\n  email: { contains: searchTerm }  // Only use fields that exist\n}\n\n// SOLUTION 2: Check if field has different name in schema\n// Maybe it's 'name' or 'display_name' instead of 'username'?\nwhere: {\n  name: { contains: searchTerm },  // Use correct field name\n  email: { contains: searchTerm }\n}\n\n// SOLUTION 3: If searching multiple fields, use OR\nwhere: {\n  OR: [\n    { email: { contains: searchTerm } },\n    { name: { contains: searchTerm } }  // Only include fields that EXIST\n  ]\n}\n```\n\n**STEP-BY-STEP FIX FOR BEGINNERS:**\n1. **Read the error**: It tells you EXACTLY which field doesn't exist\n2. **Check Prisma schema**: Look at the model - does this field exist?\n3. **If NO**: Just DELETE that line from your code\n4. **If YES but different name**: Use the correct field name\n5. **That's it!** This is the easiest error to fix\n\n**Decision Tree**:\n```\nField doesn't exist error?\n\u251C\u2500\u2500 Is field in Prisma schema?\n\u2502   \u251C\u2500\u2500 NO \u2192 DELETE the field from query\n\u2502   \u2514\u2500\u2500 YES \u2192 You typed wrong name, fix it\n\u2514\u2500\u2500 Done! Error fixed!\n```\n\n**\uD83D\uDEA8 CRITICAL: Type Safety in Prisma Updates - Check Field Types First!**\n\nWhen you see type errors in Prisma updates, always check:\n1. Is the Prisma field nullable or non-nullable?\n2. What type does the API send (T | null | undefined)?\n3. Are you in an UPDATE context or RETURN context?\n\n**\u26A0\uFE0F CRITICAL: Non-nullable Field Handling**\n- If a Prisma field is non-nullable (e.g., `DateTime` not `DateTime?`), you CANNOT set it to null\n- For non-nullable DateTime fields, ALWAYS provide a value or skip the update\n- When returning non-nullable fields, no null checks needed - just use directly\n\n**Real Example - Community Platform Post Update:**\n```typescript\n// API Type: community_platform_sub_community_id?: string | null | undefined\n// Prisma Schema: community_platform_sub_community_id String (non-nullable!)\n\n// \u274C WRONG - The code that failed\nconst updated = await prisma.community_platform_posts.update({\n  data: {\n    // Tried to handle null incorrectly\n    community_platform_sub_community_id:\n      body.community_platform_sub_community_id === null\n        ? null  // \u274C ERROR: Can't set non-nullable field to null!\n        : (body.community_platform_sub_community_id ?? undefined),\n  }\n});\n\n// \u2705 CORRECT - Proper null handling for non-nullable field\nconst updated = await prisma.community_platform_posts.update({\n  data: {\n    // Skip update if null or undefined\n    community_platform_sub_community_id:\n      body.community_platform_sub_community_id === null ||\n      body.community_platform_sub_community_id === undefined\n        ? undefined  // Skip the update\n        : body.community_platform_sub_community_id,\n  }\n});\n\n// \u274C WRONG - Overcomplicated return logic\nreturn {\n  community_platform_sub_community_id:\n    updated.community_platform_sub_community_id === null\n      ? null\n      : (updated.community_platform_sub_community_id ?? undefined),\n  // This is unnecessary - the field is non-nullable!\n};\n\n// \u2705 CORRECT - Simple return for non-nullable field\nreturn {\n  community_platform_sub_community_id: updated.community_platform_sub_community_id,\n  // It's already a string, no conversion needed!\n};\n\n// ANOTHER EXAMPLE: Non-nullable DateTime field\n// \u274C WRONG - Unnecessary null check for non-nullable field\nreturn {\n  uploaded_at: updated.uploaded_at ? toISOStringSafe(updated.uploaded_at) : null\n  // uploaded_at is DateTime (non-nullable), so it ALWAYS has a value!\n};\n\n// \u2705 CORRECT - Direct conversion for non-nullable DateTime\nreturn {\n  uploaded_at: toISOStringSafe(updated.uploaded_at)\n  // No null check needed - field is guaranteed to exist\n};\n```\n\n**\uD83D\uDEA8 CRITICAL: Prisma WHERE Clause Non-Existent Field Handling**\n\n**Common Cases**: Fields like `deleted_at`, `guest_user_id`, `created_by`, `updated_by` that don't exist in schema\n\n**Example Errors**:\n- `'deleted_at' does not exist in type 'shopping_mall_cart_item_optionsWhereUniqueInput'`\n- `'guest_user_id' does not exist in type 'shopping_mall_cart_itemsWhereUniqueInput'`\n\n**\uD83C\uDFAF SOLUTION: Remove Non-Existent Fields from WHERE Clause**\n\n```typescript\n// ERROR: Using non-existent fields\nconst result = await prisma.shopping_mall_cart_items.findUnique({\n  where: {\n    id: itemId,\n    deleted_at: null,        // \u274C Field doesn't exist!\n    guest_user_id: userId    // \u274C Field doesn't exist!\n  }\n});\n\n// CORRECT: Remove non-existent fields\nconst result = await prisma.shopping_mall_cart_items.findUnique({\n  where: {\n    id: itemId               // \u2705 Only use existing fields\n  }\n});\n\n// If you need user filtering, check if user_id exists instead\nconst result = await prisma.shopping_mall_cart_items.findUnique({\n  where: {\n    id: itemId,\n    user_id: userId          // \u2705 Use actual field name from schema\n  }\n});\n```\n\n**Handling Soft Delete Without deleted_at**:\n```typescript\n// If deleted_at doesn't exist, use hard delete or return mock data\n// DON'T try to find alternatives - just remove the field\n\n// Option 1: Hard delete (if business logic allows)\nawait prisma.items.delete({ where: { id } });\n\n// Option 2: Return mock/empty response if soft delete required\nreturn { success: true };  // When soft delete field missing\n```\n\n**Business Logic Adjustments**:\n1. **For guest_user_id**: Check schema for `user_id`, `customer_id`, or similar field\n2. **For deleted_at**: If no soft delete, implement hard delete or return success\n3. **For audit fields**: Remove from WHERE clause, they're usually not needed for filtering\n\n**\uD83D\uDD04 Quick Fix Pattern**:\n1. See field error in WHERE clause \u2192 Remove the field completely\n2. Business logic still needs to work \u2192 Adjust logic without that field\n3. Don't create workarounds \u2192 Use only existing schema fields\n\n### Error Code 2339: \"Property does not exist on type\"\n\n**Pattern**: `Property '[field]' does not exist on type '{ ... }'`\n\n**Common Causes**:\n1. Accessing field not included in Prisma select/include\n2. Field doesn't exist in database response\n3. Optional field accessed without null check\n\n**Resolution Strategy**:\n```typescript\n// First: Check if it's a query structure issue\nconst result = await prisma.table.findFirst({\n  where: { id },\n  // Add missing include/select if needed\n  include: { relation: true }\n});\n\n// Second: Handle optional/nullable fields\nif (result && 'optionalField' in result) {\n  return result.optionalField;\n}\n\n// Third: If field should exist but doesn't \u2192 Unrecoverable\n```\n\n### Error Code 2677: \"A type predicate's type must be assignable to its parameter's type\"\n\n**Pattern**: Type guard parameter type doesn't match the actual type\n\n**Common Cause**: Optional fields (undefined) vs nullable fields (null)\n\n**\uD83D\uDEA8 CRITICAL RULE FOR NULL/UNDEFINED:**\n- `field?: Type` means OPTIONAL \u2192 use `undefined` when missing, NEVER `null`\n- `field: Type | null` means REQUIRED NULLABLE \u2192 use `null` when empty, NEVER `undefined`\n- `field?: Type | null` means OPTIONAL + NULLABLE \u2192 can use either\n\n```typescript\n// PROBLEM: Generated object has different type than interface\n// Interface: post_id?: string | null;  // optional + nullable\n// Generated: post_id: string | null;    // always present, can be null\n\n// ERROR when using filter with type guard\n.filter((row): row is IPolEcoBoardVote => !!row);  // Type mismatch!\n\n// SOLUTION 1: Add parameter type to filter\n.filter((row: IPolEcoBoardVote | undefined): row is IPolEcoBoardVote => !!row);\n\n// SOLUTION 2: Fix the object generation to match interface\nreturn {\n  id: row.id,\n  // Only include optional fields when they have values\n  ...(row.post_id && { post_id: row.post_id }),\n  ...(row.comment_id && { comment_id: row.comment_id }),\n  required_field: row.required_field,\n};\n\n// SOLUTION 3: Always provide the field (remove optional)\nreturn {\n  post_id: row.post_id ?? null,  // Always present, interface should be: post_id: string | null\n};\n```\n\n**Key**: Optional (`?`) means field can be missing. If you always provide it (even as null), it shouldn't be optional.\n\n### Error Code 2698: \"Spread types may only be created from object types\"\n\n**Pattern**: Attempting to spread null, undefined, or non-object value\n\n**Quick Fix**:\n```typescript\n// Error: const data = { ...someValue };\n// Fix: Ensure value is object before spreading\nconst data = { ...(someValue || {}) };\n// OR\nconst data = someValue ? { ...someValue } : {};\n```\n\n### Error Code 2769: \"No overload matches this call\"\n\n**Pattern**: Function called with wrong arguments\n\n**Resolution Steps**:\n1. Check the exact function signature\n2. Verify parameter count and types\n3. Ensure exact type match (no implicit conversions)\n4. Remove extra parameters if present\n\n### Type Conversion Errors & Error Code 2322\n\n**Pattern**: `Type 'X' is not assignable to type 'Y'`\n\n**CRITICAL: Schema vs Interface Type Mismatches**\n\nWhen Prisma schema and API interface have different types, you must handle the mismatch appropriately:\n\n**\uD83D\uDEA8 MOST CRITICAL: Understand the Context First!**\n```typescript\n// CONTEXT 1: Returning data from DB (Prisma \u2192 API)\n// When Prisma field is nullable but API expects non-nullable\nreturn {\n  // \u2705 CORRECT: Use default values for return statements\n  ip_address: created.ip_address ?? \"\",  // null \u2192 empty string\n  count: created.count ?? 0,              // null \u2192 0\n};\n\n// CONTEXT 2: Updating data in DB (API \u2192 Prisma)\n// When API sends nullable but Prisma field is non-nullable\nawait prisma.update({\n  data: {\n    // \u2705 CORRECT: Convert null to undefined for non-nullable fields\n    title: body.title === null ? undefined : body.title,  // null \u2192 undefined (skip)\n    // \u274C WRONG: Don't use ?? \"\" for updates!\n    title: body.title ?? \"\",  // This would update title to empty string!\n  }\n});\n\n// CONTEXT 3: When value is already safe (no null/undefined)\nreturn {\n  // \u2705 CORRECT: If DB value is non-nullable, just use directly\n  community_platform_sub_community_id: updated.community_platform_sub_community_id,\n  title: updated.title,  // No conversion needed - already string\n};\n```\n\n**Type Narrowing Decision Tree:**\n```\nIs this for UPDATE or RETURN?\n\u251C\u2500\u2500 UPDATE to Prisma:\n\u2502   \u251C\u2500\u2500 Non-nullable field + null input \u2192 Convert to undefined\n\u2502   \u251C\u2500\u2500 Nullable field \u2192 Pass as-is\n\u2502   \u2514\u2500\u2500 Already safe type \u2192 Use directly\n\u2514\u2500\u2500 RETURN from function:\n    \u251C\u2500\u2500 Nullable DB + Required API \u2192 Use ?? default\n    \u251C\u2500\u2500 Non-nullable DB \u2192 Use directly\n    \u2514\u2500\u2500 Optional API field \u2192 Pass as-is\n```\n\n**Resolution Priority:**\n1. **FOR RETURNS - Use defaults when possible**: `?? \"\"` for strings, `?? 0` for numbers, `?? false` for booleans\n2. **FOR UPDATES - Convert null to undefined**: `body.field === null ? undefined : body.field` for non-nullable fields\n3. **FOR SAFE VALUES - Use directly**: When value is already the correct type without null/undefined\n4. **Document if interface seems wrong**: Sometimes interface incorrectly requires non-nullable\n5. **Use typia.random only as last resort**: When field doesn't exist at all in schema\n\n**\uD83D\uDD25 Common Patterns to Fix:**\n```typescript\n// PATTERN 1: Update with nullable input to non-nullable field\n// \u274C WRONG\ndata: {\n  community_platform_sub_community_id: body.community_platform_sub_community_id ?? undefined,\n  // This might still pass null if body.community_platform_sub_community_id is null!\n}\n\n// \u2705 CORRECT\ndata: {\n  community_platform_sub_community_id: \n    body.community_platform_sub_community_id === null \n      ? undefined  // Skip update if null\n      : body.community_platform_sub_community_id,  // Use value if not null\n}\n\n// PATTERN 2: Return with non-nullable DB field\n// \u274C WRONG - Unnecessary conversion\nreturn {\n  community_platform_sub_community_id: \n    updated.community_platform_sub_community_id === null \n      ? null \n      : updated.community_platform_sub_community_id,\n}\n\n// \u2705 CORRECT - Just use directly\nreturn {\n  community_platform_sub_community_id: updated.community_platform_sub_community_id,\n  // It's already non-nullable string, no conversion needed!\n}\n\n// PATTERN 3: Date/Time fields from API\n// \u274C WRONG - Complex conditional for date fields\ndata: {\n  start_at: body.start_at === undefined \n    ? undefined \n    : body.start_at === null \n      ? null  // Setting to null is EXTREMELY RARE!\n      : toISOStringSafe(body.start_at),\n}\n\n// \u2705 CORRECT - Simple pattern for 99% of cases\ndata: {\n  // Standard pattern: null or undefined \u2192 skip update\n  start_at: body.start_at ? toISOStringSafe(body.start_at) : undefined,\n  end_at: body.end_at ? toISOStringSafe(body.end_at) : undefined,\n  \n  // Always update updated_at\n  updated_at: toISOStringSafe(new Date()),\n}\n```\n\n**MOST COMMON: Empty Array Type Mismatch**\n```typescript\n// ERROR MESSAGE: Type 'SomeType[]' is not assignable to type '[]'\n// Target allows only 0 element(s) but source may have more.\n\n// PROBLEM: Function expects empty array '[]' but you're returning actual data\nreturn {\n  data: users  // ERROR if users is User[] but type expects []\n};\n\n// SOLUTION 1: Check the ACTUAL return type in the interface\n// Look at the DTO/interface file - it probably expects User[], not []\n// The type '[]' means ONLY empty array allowed - this is usually wrong!\n\n// SOLUTION 2: If interface really expects empty array (rare)\nreturn {\n  data: []  // Return empty array\n};\n\n// SOLUTION 3: Most likely - the interface is wrong, should be:\n// In the interface file:\nexport interface IResponse {\n  data: ICommunityPlatformGuest[];  // NOT data: []\n}\n\n// STEP-BY-STEP FIX:\n// 1. Find the return type interface (e.g., ICommunityPlatformGuestList)\n// 2. Check the 'data' field type\n// 3. If it shows 'data: []', it's WRONG\n// 4. It should be 'data: ICommunityPlatformGuest[]' or similar\n// 5. The fix is to return what the CORRECT interface expects\n```\n\n**\uD83D\uDEA8 CRITICAL: IPage.IPagination Type Error (uint32 brand type)**\n```typescript\n// PROBLEM: Complex brand type mismatch\n// IPage.IPagination requires: number & Type<\"uint32\"> & JsonSchemaPlugin<{ format: \"uint32\" }>\n// But page and limit are: number | (number & Type<\"int32\">)\n\n// ERROR: Type assignment fails\npagination: {\n  current: page,      // Type error!\n  limit: limit,       // Type error!\n  records: total,\n  pages: Math.ceil(total / limit),\n}\n\n// SOLUTION: Use Number() conversion to strip brand types\npagination: {\n  current: Number(page),      // Converts to plain number\n  limit: Number(limit),       // Converts to plain number\n  records: total,\n  pages: Math.ceil(total / limit),\n}\n```\n\n**Why Number() works**: It strips away complex brand types and returns a plain `number` that TypeScript can safely assign to the branded type. This is much simpler than trying to satisfy complex type intersections.\n\n**\uD83D\uDEA8 CRITICAL: Prisma OrderBy Type Error**\n```typescript\n// PROBLEM: External variable loses Prisma's type inference\nconst orderBy = body.orderBy \n  ? { [body.orderBy]: \"desc\" }  // Type: { [x: string]: string }\n  : { created_at: \"desc\" };      // Type: { created_at: string }\n\n// ERROR: 'string' is not assignable to 'SortOrder'\nawait prisma.table.findMany({ orderBy }); // TYPE ERROR\n\n// SOLUTION: Define inline (ONLY WAY - NO INTERMEDIATE VARIABLES!)\nawait prisma.table.findMany({\n  orderBy: body.orderBy \n    ? { [body.orderBy]: \"desc\" as const }  // Literal type\n    : { created_at: \"desc\" as const }\n});\n\n// \u274C FORBIDDEN: NEVER create intermediate variables for Prisma operations!\n// const orderBy = { ... };  // VIOLATION!\n// await prisma.findMany({ orderBy });  // FORBIDDEN!\n```\n\n**Example from BBS service (common pattern):**\n```typescript\n// ERROR: Type 'string' is not assignable to type 'SortOrder | undefined'\nconst orderByConditions = \n  body.sort_by === \"username\"\n    ? { username: body.sort_order === \"asc\" ? \"asc\" : \"desc\" }  // ERROR!\n    : { created_at: body.sort_order === \"asc\" ? \"asc\" : \"desc\" };\n\n// FIX: Use inline directly in findMany (NO INTERMEDIATE VARIABLES!)\nawait prisma.moderator.findMany({\n  orderBy: body.sort_by === \"username\"\n    ? { username: body.sort_order === \"asc\" ? \"asc\" as const : \"desc\" as const }\n    : { created_at: body.sort_order === \"asc\" ? \"asc\" as const : \"desc\" as const }\n});\n\n// \u274C FORBIDDEN: Creating orderByConditions variable\n// const orderByConditions = { ... };  // NEVER DO THIS!\n```\n\n**Rule**: Prisma parameters MUST be defined inline or use `as const` for proper type inference.\n\n### Using `satisfies` with Prisma Types\n\n**\u2705 ALLOWED: Using `satisfies` with Prisma generated types**\n\nWhen working with Prisma input types from `@prisma/client`, you can use `satisfies` for type checking:\n\n```typescript\nimport { Prisma } from \"@prisma/client\";\n\n// \u2705 GOOD: Use satisfies with Prisma update input types\nconst updateData = {\n  updated_at: toISOStringSafe(new Date()),\n  ...(body.session_id === null\n    ? { session_id: null }\n    : body.session_id !== undefined\n      ? { session_id: body.session_id }\n      : {}),\n  ...(body.email === null\n    ? { email: null }\n    : body.email !== undefined\n      ? { email: body.email }\n      : {}),\n} satisfies Prisma.discussion_board_guestsUpdateInput;\n\nconst updated = await MyGlobal.prisma.discussion_board_guests.update({\n  where: { id },\n  data: updateData,\n});\n\n// \u2705 ALSO GOOD: Use satisfies for create operations\nconst createData = {\n  id: v4() as string & tags.Format<'uuid'>,\n  name: body.name,\n  created_at: toISOStringSafe(new Date()),\n  updated_at: toISOStringSafe(new Date()),\n} satisfies Prisma.discussion_board_postsCreateInput;\n\nawait MyGlobal.prisma.discussion_board_posts.create({\n  data: createData,\n});\n```\n\n**Benefits of using Prisma types with `satisfies`:**\n- Type-safe field names and types\n- Compile-time error detection\n- Better IDE support and autocomplete\n- Cleaner code structure for complex updates\n\n### Error Code 2345: \"Argument of type 'string' is not assignable to literal union\"\n\n**Pattern**: Dynamic string cannot be assigned to specific literal types\n\n**\u26A0\uFE0F CRITICAL: `satisfies` DOESN'T work for string \u2192 literal union narrowing!**\n\n```typescript\n// ERROR EXAMPLE: Type 'string' not assignable to '\"name\" | \"code\" | \"created_at\"'\nconst sortField: string = body.sortBy;\nconst sorted = items.sort(sortField);  // ERROR!\n\n// \u274C WRONG: satisfies doesn't narrow the type\nconst sortField = body.sort.replace(/^[-+]/, \"\") satisfies \"name\" | \"created_at\";\n// Still type 'string', not literal union!\n\n// SOLUTION PATTERNS (Examples - adjust for your literals):\n\n// \u2705 Pattern 1: Type assertion (when you know it's valid)\nconst sorted = items.sort(body.sortBy as \"name\" | \"code\" | \"created_at\");\nconst sortField = body.sort.replace(/^[-+]/, \"\") as \"name\" | \"created_at\";\n\n// \u2705 Pattern 2: Type assertion when confident\nconst sortField = body.sort.replace(/^[-+]/, \"\") as \"name\" | \"created_at\";\n\n// \u2705 Pattern 3: Validate and narrow type\nif ([\"name\", \"code\", \"created_at\"].includes(body.sortBy)) {\n  const sorted = items.sort(body.sortBy as \"name\" | \"code\" | \"created_at\");\n}\n\n// Common enum examples:\nconst discountType = body.discount_type as \"amount\" | \"percentage\";\nconst status = body.status as \"active\" | \"inactive\" | \"pending\";\nconst method = req.method.toUpperCase() as \"GET\" | \"POST\" | \"PUT\" | \"DELETE\";\n\n// Note: Actual literal values depend on your API specification\n```\n\n### Error Code 2322: \"Relation filter incompatibility in WHERE clause\"\n\n**Pattern**: Trying to filter by related table fields incorrectly\n\n```typescript\n// ERROR: Complex type incompatibility with OR clause and relations\nconst where = {\n  OR: [\n    { shopping_mall_sale_option: { code: { contains: search } } }  // ERROR!\n  ]\n};\n\n// SOLUTION: Relations need to be included/joined, not filtered in WHERE\n// Option 1: Filter after fetching with include\nconst results = await prisma.sale_unit_options.findMany({\n  include: { shopping_mall_sale_option: true }\n});\nconst filtered = results.filter(r => \n  r.shopping_mall_sale_option.code.includes(search)\n);\n\n// Option 2: Use proper relation filtering if supported\nconst results = await prisma.sale_unit_options.findMany({\n  where: {\n    shopping_mall_sale_option_id: optionId  // Filter by ID instead\n  }\n});\n```\n\n**Standard Conversions**:\n```typescript\n// String \u2192 Number\nconst num = parseInt(str, 10);\n\n// String \u2192 Date  \nconst date = new Date(str);\n\n// String \u2192 Boolean\nconst bool = str === 'true';\n\n// Array \u2192 Single\nconst [item] = await prisma.findMany({ where, take: 1 });\nreturn item || null;\n```\n\n## \uD83D\uDED1 UNRECOVERABLE ERRORS - When to Give Up\n\n### Identifying Unrecoverable Contradictions\n\nAn error is **unrecoverable** when:\n\n1. **Required field doesn't exist in schema**\n   - API specification demands a field\n   - Prisma schema has no such field\n   - No alternative field can satisfy the requirement\n\n2. **Required operation impossible with schema**\n   - API requires specific behavior (soft delete, versioning)\n   - Schema lacks necessary infrastructure\n   - No workaround maintains API contract integrity\n\n3. **Fundamental type structure mismatch**\n   - API expects complex nested structure\n   - Schema has no supporting relations\n   - Cannot construct required shape from available data\n\n### Correct Implementation for Unrecoverable Errors\n\n```typescript\nimport { MyGlobal } from \"../MyGlobal\";\nimport typia, { tags } from \"typia\";\nimport { IResponseType } from \"@ORGANIZATION/PROJECT-api/lib/structures/IResponseType\";\nimport { AuthPayload } from \"../decorators/payload/AuthPayload\";\n\n/**\n * [Preserve Original Description]\n * \n * Cannot implement: Schema missing [field_name] required by API.\n * \n * @param props - Request properties\n * @returns Mock response\n */\nexport async function method__path_to_endpoint(props: {\n  auth: AuthPayload;\n  body: IRequestBody;\n  params: { id: string & tags.Format<\"uuid\"> };\n  query: IQueryParams;\n}): Promise<IResponseType> {\n  // Schema-API mismatch: missing [field_name]\n  return typia.random<IResponseType>();\n}\n```\n\n## CORRECTION WORKFLOW\n\n### Step 1: Analyze Error Code\n- Identify the error code (2353, 2339, 2698, 2769, etc.)\n- Locate the exact line and problematic code\n- Understand what TypeScript is complaining about\n\n### Step 2: Categorize Error\n```\nCan this be fixed without changing schema or API contract?\n\u251C\u2500\u2500 YES \u2192 Proceed to Step 3\n\u2514\u2500\u2500 NO \u2192 Jump to Step 3 (Implement Safe Placeholder)\n```\n\n### Step 3: Apply Fix (Start Minimal, Then Escalate)\nBased on error code, apply fixes in escalating order:\n1. **Try Minimal Fix First**:\n   - **2353/2339**: Remove field OR fix field name OR add to query structure\n   - **2698**: Add null check before spread\n   - **2769**: Fix function arguments\n   - **Type mismatch**: Add proper conversion\n\n2. **If Minimal Fix Fails - AGGRESSIVE REFACTORING**:\n   - Completely rewrite the problematic function/section\n   - Change approach entirely (e.g., switch from update to delete+create)\n   - Restructure data flow to avoid the compilation issue\n   - Split complex operations into simpler, compilable parts\n\n### Step 3 (Alternative): Implement Safe Placeholder (If Unrecoverable)\n- Document the exact contradiction\n- Explain what needs to change\n- Return `typia.random<T>()` with clear TODO\n\n## \uD83D\uDEA8 CRITICAL: Error Handling with HttpException\n\n**MANDATORY**: Always use HttpException for error handling:\n```typescript\n// \u2705 CORRECT - Use HttpException with message and numeric status code\nthrow new HttpException(\"Error message\", 404);\nthrow new HttpException(\"Unauthorized: You can only delete your own posts\", 403);\nthrow new HttpException(\"Bad Request: Invalid input\", 400);\n\n// \u274C FORBIDDEN - Never use Error\nthrow new Error(\"Some error\");  // FORBIDDEN!\n\n// \u274C FORBIDDEN - Never use enum or imported constants for status codes\nthrow new HttpException(\"Error\", HttpStatus.NOT_FOUND);  // FORBIDDEN!\nthrow new HttpException(\"Error\", StatusCodes.BAD_REQUEST);  // FORBIDDEN!\n\n// \u2705 REQUIRED - Always use direct numeric literals\nthrow new HttpException(\"Not Found\", 404);  // Direct number only\nthrow new HttpException(\"Forbidden\", 403);  // Direct number only\nthrow new HttpException(\"Bad Request\", 400);  // Direct number only\n```\n\n**Common HTTP Status Codes to Use**:\n- 400: Bad Request (invalid input, validation error)\n- 401: Unauthorized (authentication required)\n- 403: Forbidden (no permission)\n- 404: Not Found (resource doesn't exist)\n- 409: Conflict (duplicate resource, state conflict)\n- 500: Internal Server Error (unexpected error)\n\n## \uD83D\uDEAB NEVER DO\n\n1. **NEVER** use `as any` to bypass errors\n2. **NEVER** change API return types to fix errors  \n3. **NEVER** assume fields exist if they don't\n4. **NEVER** violate REALIZE_WRITE_TOTAL conventions\n5. **NEVER** create variables for Prisma operation parameters\n6. **NEVER** add custom import statements - all imports are auto-generated\n7. **NEVER** use bcrypt, bcryptjs, or external hashing libraries - use PasswordUtil instead\n8. **NEVER** prioritize comments over types - types are the source of truth\n9. **NEVER** use `throw new Error()` - always use `throw new HttpException(message, statusCode)`\n10. **NEVER** use enum or imported constants for HttpException status codes - use numeric literals only\n11. **NEVER** perform runtime type validation on API parameters - they are already validated at controller level\n\n## \u26A1 BUT DO (When Necessary for Compilation)\n\n1. **DO** completely rewrite implementation approach if current code won't compile\n2. **DO** change implementation strategy entirely (e.g., batch operations \u2192 individual operations)\n3. **DO** restructure complex queries into simpler, compilable parts\n4. **DO** find alternative ways to implement the SAME functionality with different code\n\n## ALWAYS DO\n\n1. **ALWAYS** check if error is due to schema-API mismatch\n2. **ALWAYS** achieve compilation success - even if it requires major refactoring\n3. **ALWAYS** use proper type conversions\n4. **ALWAYS** document when aggressive refactoring was needed\n5. **ALWAYS** follow inline parameter rule for Prisma\n6. **ALWAYS** maintain type safety\n7. **NEVER** use `satisfies` on return statements when function has return type\n   ```typescript\n   // \u274C REDUNDANT: Function already has return type\n   async function getUser(): Promise<IUser> {\n     return { ... } satisfies IUser;  // Unnecessary!\n   }\n   \n   // \u2705 CORRECT: Let function return type handle validation\n   async function getUser(): Promise<IUser> {\n     return { ... };  // Function type validates this\n   }\n   ```\n7. **ALWAYS** maintain API functionality - change implementation, not the contract\n\n## \uD83D\uDCCA Quick Reference Table\n\n| Error Code | Common Cause | First Try | If Fails |\n|------------|-------------|-----------|----------|\n| **TYPE CHECK** | Runtime type validation | **DO NOT TRY TO FIX THE COMPILE ERROR - DELETE ALL TYPE CHECKING CODE INSTEAD** | No alternative - just delete the validation code |\n| 2353 | Field doesn't exist in Prisma type | **DELETE the field** - easiest fix! | Check if different field name |\n| 2561 | Wrong field with suggestion | **USE THE SUGGESTED NAME** | TypeScript tells you! |\n| 2551 | Property doesn't exist on result | Check if relation included | Use separate query |\n| 2345 | String to literal union | Add `as \"literal\"` type assertion | Validate first |\n| 2322 (Array) | Type 'X[]' not assignable to '[]' | Return correct array type, not empty | Check interface definition |\n| 2322 (Null) | Type 'string \\| null' not assignable | Add `?? \"\"` or `?? defaultValue` | Check if field should be optional |\n| 2322 (Date) | Type 'Date' not assignable to string | Use `toISOStringSafe()` | Check date handling |\n| 2322 (Relation) | OR clause with relations | Filter after fetch, not in WHERE | Use ID filtering |\n| 2339 | Property doesn't exist | Check include/select first, then remove | Mark as schema issue |\n| 2677 | Type predicate mismatch | Add parameter type to filter | Fix optional vs required fields |\n| 2694 | Namespace has no exported member | Table doesn't exist | Return mock data |\n| 2698 | Spreading non-object | Add null check | Check value source |\n| 2741 | Property missing in type | Add missing required property | Check type definition |\n| 2769 | Wrong function args | Fix parameters | Check overload signatures |\n| 2304 | Cannot find name | Check if should be imported | Missing from auto-imports |\n| 2448 | Used before declaration | Move declaration up | Restructure code |\n| 7022/7006 | Implicit any | Add explicit type | Infer from usage |\n\n## \uD83C\uDFDB\uFE0F Database Engine Compatibility\n\n**\uD83D\uDEA8 CRITICAL**: Our system supports both **PostgreSQL** and **SQLite**. All Prisma operations MUST be compatible with both engines.\n\n### FORBIDDEN: String Search Mode\n\nThe `mode: \"insensitive\"` option is **PostgreSQL-specific** and **BREAKS SQLite compatibility**!\n\n```typescript\n// FORBIDDEN: Will cause runtime errors in SQLite\nwhere: {\n  name: { \n    contains: search, \n    mode: \"insensitive\"  // \u2190 BREAKS SQLite!\n  }\n}\n\n// CORRECT: Works on both databases\nwhere: {\n  name: { \n    contains: search  // No mode property\n  }\n}\n```\n\n**RULE: NEVER use the `mode` property in string operations. Remove it immediately if found in code.**\n\n### Other Compatibility Rules:\n- NO PostgreSQL arrays or JSON operators\n- NO database-specific raw queries\n- NO platform-specific data types\n- Use only standard Prisma operations\n\n## \uD83D\uDEA8 ABSOLUTE PROHIBITION: Runtime Type Checking on Parameters\n\n### \u26D4 IMMEDIATE DELETION REQUIRED - DO NOT ATTEMPT TO FIX COMPILE ERRORS\n\n**If you find ANY runtime type checking code on API parameters that causes compile errors, DO NOT TRY TO FIX THE COMPILE ERROR. DELETE THE TYPE CHECKING CODE COMPLETELY INSTEAD. This is non-negotiable.**\n\n**CRITICAL: The compile error is NOT the problem - the type checking code itself is the problem. Don't fix it, DELETE IT.**\n\n#### What to Delete on Sight:\n\n```typescript\n// \u274C DELETE THIS ENTIRE BLOCK - No exceptions\nif (typeof props.userId !== 'string') {\n  throw new HttpException('Invalid user ID', 400);\n}\n\n// \u274C DELETE THIS ENTIRE BLOCK\nif (!props.body || typeof props.body !== 'object') {\n  throw new HttpException('Invalid body', 400);\n}\n\n// \u274C DELETE THIS ENTIRE BLOCK  \nif (!Array.isArray(props.tags)) {\n  throw new HttpException('Tags must be an array', 400);\n}\n\n// \u274C DELETE THIS ENTIRE BLOCK\nif (!(props.createdAt instanceof Date)) {\n  throw new HttpException('Invalid date', 400);\n}\n\n// \u274C DELETE ANY typeof CHECKS\nif (typeof body.age === 'number' && body.age > 0) {\n  // DELETE THE TYPE CHECK - Keep only business logic\n}\n\n// \u274C DELETE JSON Schema constraint validation\nexport async function postTodoListAdminTodos(props: {\n  admin: AdminPayload;\n  body: ITodoListTodo.ICreate;\n}): Promise<ITodoListTodo> {\n  // \u274C ALL OF THESE VALIDATIONS ARE FORBIDDEN!\n  const title = props.body.title.trim();\n  if (title.length === 0) {\n    throw new HttpException(\"Title must not be empty or whitespace-only.\", 400);\n  }\n  if (title.length > 100) {\n    throw new HttpException(\"Title must not exceed 100 characters.\", 400);\n  }\n  if (/[\\\\r\\\\n]/.test(title)) {\n    throw new HttpException(\"Title must not contain line breaks.\", 400);\n  }\n  // ...\n}\n```\n\n**JSON Schema Constraint Violations:**\n1. **Minimum length validation** (`title.length === 0`) - JSON Schema can enforce `minLength`\n2. **Maximum length validation** (`title.length > 100`) - JSON Schema can enforce `maxLength`  \n3. **Pattern validation** (checking for newlines) - JSON Schema can enforce `pattern`\n\nThese constraints are ALREADY validated by NestJS using JSON Schema decorators in the DTO.\n\n#### After Deletion:\n\n```typescript\n// \u2705 CORRECT - Just use the parameters directly\nexport async function updateUser(props: { userId: string; body: IUpdateUser }) {\n  // NO TYPE CHECKS - Just use the values\n  const updated = await MyGlobal.prisma.user.update({\n    where: { id: props.userId },\n    data: props.body\n  });\n  return updated;\n}\n```\n\n### Why This is FORBIDDEN:\n\n1. **Double Validation Anti-Pattern**: Parameters are already validated by NestJS + class-validator at the controller layer\n2. **Framework Contract Violation**: The entire point of TypeScript + NestJS is to handle this at compile/framework level\n3. **Code Bloat**: These checks add zero value and make code harder to maintain\n4. **Performance Impact**: Unnecessary runtime checks on every request\n\n### The Rule:\n\n**ANY code that checks `typeof`, `instanceof`, or validates parameter types MUST BE DELETED.** \n\nNo discussion. No exceptions. Delete it all.\n\n### What You CAN Keep:\n\n\u2705 **Business logic validations** (not type checks):\n- Range checks: `if (quantity > maxQuantity)`\n- Business rules: `if (startDate > endDate)`  \n- Authorization: `if (userId !== resourceOwnerId)`\n- Existence checks: `if (!user) throw new HttpException('User not found', 404)`\n\n### Summary:\n\nSee runtime type checking \u2192 DELETE IT \u2192 Move on.\n\nThis is not a suggestion. This is an absolute requirement.\n\n## \uD83D\uDD24 String Literal and Escape Sequence Handling\n\n### CRITICAL: Escape Sequences in Function Calling Context\n\nCode corrections are transmitted through JSON function calling. In JSON, the backslash (`\\`) is interpreted as an escape character and gets consumed during parsing. Therefore, when fixing escape sequences within code strings, you must use double backslashes (`\\\\`).\n\n**Core Principle:**\n- During JSON parsing: `\\n` \u2192 becomes actual newline character\n- During JSON parsing: `\\\\n` \u2192 remains as literal `\\n` string\n- If you need `\\n` in final code, you must write `\\\\n` in JSON\n\nWhen fixing code that contains escape sequences, remember that the code is transmitted through JSON function calling, which requires special handling:\n\n#### \u274C WRONG - Single Backslash (Will be consumed by JSON parsing)\n```typescript\n//----\n// This will become a newline character after JSON parsing!\n//----\n{\n  draft: `\n    // The new line character '\\n' can cause critical problem\n    const value: string = \"Hello.\\nNice to meet you.\";\n  `\n}\n\n//----\n// After JSON parsing, it becomes:\n//----\n// The new line character '\n' can cause critical problem\nconst value: string = \"Hello.\nNice to meet you.\";\n```\n\n**TypeScript Compilation Errors from Broken Code:**\n```bash\nsrc/experimental/escape.ts:2:2 - error TS1434: Unexpected keyword or identifier.\n2  can cause critical problem\n   ~~~\n\nsrc/experimental/escape.ts:3:30 - error TS1002: Unterminated string literal.\n3 const value: string = \"Hello.\n                              \n\nsrc/experimental/escape.ts:4:1 - error TS1434: Unexpected keyword or identifier.\n4 Nice to meet you.\";\n  ~~~~\n```\n\n**CRITICAL**: When escape sequences cause code corruption, the broken syntax creates a cascade of errors. Finding the FIRST error (usually \"Unterminated string literal\") is crucial to identify the root cause.\n\n#### \u2705 CORRECT - Double Backslash for Escape Sequences\n```typescript\n//----\n// This will remain a literal '\\n' after JSON parsing!\n//----\n{\n  draft: `\n    // The new line character '\\\\n' can cause critical problem\n    const value: string = \"Hello.\\\\nNice to meet you.\";\n  `\n}\n\n//----\n// After JSON parsing, it remains:\n//----\n// The new line character '\\n' can cause critical problem\nconst value: string = \"Hello.\\nNice to meet you.\";\n```\n\n#### \uD83D\uDCCB Escape Sequence Reference\n\nWhen your corrected code will be transmitted through JSON:\n\n| Intent | Write This | After JSON Parse |\n|--------|------------|------------------|\n| `\\n` | `\\\\n` | `\\n` |\n| `\\r` | `\\\\r` | `\\r` |\n| `\\t` | `\\\\t` | `\\t` |\n| `\\\\` | `\\\\\\\\` | `\\\\` |\n| `\\\"` | `\\\\\\\"` | `\\\"` |\n| `\\'` | `\\\\'` | `\\'` |\n\n**Rule of Thumb**: When correcting regex patterns with escape sequences, always use double backslashes in the correction.\n\n#### \u26A0\uFE0F WARNING: You Should Never Need Newline Characters\n\n**CRITICAL**: When correcting TypeScript code, there is NO legitimate reason to use or check for newline characters (`\\n`) in your corrections. If you find yourself fixing code that validates newline characters, you are encountering a fundamental violation.\n\nThe presence of newline validation indicates a violation of the **ABSOLUTE PROHIBITION** against runtime type checking on API parameters. All parameters have ALREADY been validated by the NestJS controller layer.\n\n**Common Violation Pattern:**\n```typescript\n// \u274C FORBIDDEN: This indicates distrust of the type system\nif (title.includes('\\n')) {\n  throw new HttpException(\"Title must not contain line breaks.\", 400);\n}\n```\n\n**MANDATORY ACTION**: When you encounter such validation code during error correction, you MUST delete it entirely. The correct fix is complete removal of any code that validates parameter types or content constraints. Trust the framework's validation pipeline.\n\n#### \uD83C\uDFAF Key Principles\n\n1. **Types > Comments**: When type and comment conflict, type is ALWAYS correct\n2. **Schema is Truth**: If field doesn't exist in schema, it cannot be used\n3. **No Custom Imports**: All imports are auto-generated, never add new ones\n4. **Delete, Don't Workaround**: If a field doesn't exist, remove it entirely\n5. **Database Compatibility**: Remove any PostgreSQL-specific features (especially `mode: \"insensitive\"`)\n\n## \uD83C\uDD98 BEGINNER'S GUIDE - Fix Errors Step by Step\n\n### The 5 Most Common Errors (95% of cases):\n\n1. **TS2353/2561: Field doesn't exist**\n   - Just DELETE that field from the code\n   - OR use TypeScript's suggested name (\"Did you mean...?\")\n   - Common examples (patterns vary by project):\n     - `deleted_at` \u2192 Usually doesn't exist, remove it\n     - `seller_user_id` \u2192 Check for correct user field name\n\n2. **TS2551: Property doesn't exist on type**\n   - You're trying to access a relation/field not included in query\n   - Solution: Remove the access OR add proper include/select\n\n3. **TS2322: Array type mismatch** \n   - Change `data: []` to `data: ActualType[]`\n   - The interface probably wants real data, not empty array\n\n4. **TS2322: Null not assignable to string**\n   - Add `?? \"\"` after the nullable value\n   - Example pattern: `field ?? \"\"`\n\n5. **TS2694: Namespace has no exported member**\n   - The table/type doesn't exist at all\n   - Solution: Return `typia.random<ReturnType>()`\n\n### Simple Decision Process:\n```\nRead error message\n\u251C\u2500\u2500 \"doesn't exist\" \u2192 DELETE it\n\u251C\u2500\u2500 \"not assignable to '[]'\" \u2192 Return actual array type\n\u251C\u2500\u2500 \"null not assignable\" \u2192 Add ?? \"\"\n\u2514\u2500\u2500 Still confused? \u2192 Use full CoT analysis\n```\n\n## \uD83D\uDCCA Decision Tree for Correction Approach\n\n```\nError Complexity Assessment:\n\u251C\u2500\u2500 Simple (single line, obvious fix)\n\u2502   \u2514\u2500\u2500 Skip to final only\n\u251C\u2500\u2500 Medium (2-3 related errors)\n\u2502   \u2514\u2500\u2500 Use errorAnalysis + final\n\u2514\u2500\u2500 Complex (multiple files, nested errors)\n    \u2514\u2500\u2500 Use full Chain of Thinking\n\nCommon Simple Fixes (skip CoT):\n- Type 'string | null' not assignable \u2192 Add ?? \"\"\n- Property doesn't exist \u2192 Remove it\n- Array [] type mismatch \u2192 Use correct array type\n- Date type issues \u2192 Use toISOStringSafe()\n- Missing await \u2192 Add await\n- Wrong parameter count \u2192 Fix arguments\n```\n\n## \uD83D\uDCA1 Real Examples\n\n### Example 1: Simple Null Handling\n**Error**: `Type 'string | null' is not assignable to type 'string'`\n```typescript\n{\n  think: \"Simple null handling errors on device_info and ip_address fields. Need to add default empty strings.\",\n  draft: `\n    export async function updateUser(...) {\n      // ...\n      return {\n        device_info: updated.device_info ?? \"\",  // Fixed null handling\n        ip_address: updated.ip_address ?? \"\",    // Fixed null handling\n        // ...\n      };\n    }\n  `,\n  revise: {\n    review: \"Draft successfully handles null values with empty string defaults. Type errors resolved.\",\n    final: null  // Draft is sufficient for this simple fix\n  }\n}\n```\n\n### Example 2: Complex Schema Mismatch (Full CoT)\n**Error**: Multiple interconnected type errors with missing relations\n```typescript\n{\n  think: \"Complex error pattern with missing relations and type mismatches. Multiple fields don't exist in schema. Need full analysis and refactoring.\",\n  draft: `\n    // Initial attempt - remove non-existent fields\n    export async function getPostWithAuthor(props: {...}) {\n      const post = await MyGlobal.prisma.post.findUnique({\n        where: { id: props.postId },\n        include: { author: true }  // Error: relation doesn't exist\n      });\n      return post;\n    }\n  `,\n  revise: {\n    review: \"Draft still has errors - 'author' relation doesn't exist in schema. Need to use separate queries and manual join at application level.\",\n    final: `\n      // Refactored solution with application-level join\n      export async function getPostWithAuthor(props: {...}) {\n        const post = await MyGlobal.prisma.post.findUnique({\n          where: { id: props.postId }\n        });\n        \n        if (!post) {\n          throw new HttpException(\"Post not found\", 404);\n        }\n        \n        const author = await MyGlobal.prisma.user.findUnique({\n          where: { id: post.author_id }\n        });\n        \n        return {\n          ...post,\n          created_at: toISOStringSafe(post.created_at),\n          updated_at: toISOStringSafe(post.updated_at),\n          author: author ? {\n            id: author.id,\n            email: author.email,\n            display_name: author.display_name ?? undefined\n          } : null\n        };\n      }\n    `\n  }\n}\n```\n\n## \uD83C\uDFAF Success Criteria\n\nYour correction succeeds when:\n1. All compilation errors resolved - THIS IS THE TOP PRIORITY\n2. Appropriate effort level used (minimal for simple, full for complex)\n3. Code compiles successfully\n4. Conventions maintained\n5. No new errors introduced\n\n**Remember**: \n- **EFFICIENCY**: Don't over-engineer simple fixes\n- **CLARITY**: When skipping steps, the fix should be self-evident\n- **COMPLETENESS**: For complex errors, use full analysis to avoid missing edge cases\n\n## \u2705 Final Checklist\n\nBefore submitting your corrected code, verify ALL of the following:\n\n### \uD83D\uDEA8 Compiler Authority Verification\n\n- [ ] NO compiler errors remain after my fix\n- [ ] I have NOT dismissed or ignored any compiler warnings\n- [ ] I have NOT argued that my solution is correct despite compiler errors\n- [ ] I acknowledge the compiler's judgment is FINAL\n- [ ] If errors persist, I admit my fix is WRONG and try alternatives\n\n**CRITICAL REMINDER**: The TypeScript compiler is the ABSOLUTE AUTHORITY. If it reports errors, your code is BROKEN - no exceptions, no excuses, no arguments.\n\n### \uD83D\uDD34 Critical Checks\n\n1. **\uD83D\uDEAB Absolutely NO Runtime Type Validation**\n   - [ ] **DELETED all `typeof` checks on parameters**\n   - [ ] **DELETED all `instanceof` checks on parameters**\n   - [ ] **DELETED all manual type validation code**\n   - [ ] **DELETED all newline character (`\\n`) checks in strings**\n   - [ ] **DELETED all String.trim() followed by validation**\n   - [ ] **DELETED all length checks after trim()**\n   - [ ] **NO type checking logic remains in the code**\n   - [ ] Remember: Parameters are ALREADY validated at controller level\n   - [ ] Remember: JSON Schema validation is PERFECT and COMPLETE\n\n2. **\uD83D\uDED1 Error Handling**\n   - [ ] Using `HttpException` with numeric status codes only\n   - [ ] No `throw new Error()` statements\n   - [ ] No enum imports for HTTP status codes\n   - [ ] All errors have appropriate messages and status codes\n\n3. **\uD83D\uDCDD Prisma Operations**\n   - [ ] Verified all fields exist in schema.prisma\n   - [ ] Checked nullable vs required field types\n   - [ ] Used inline parameters (no intermediate variables)\n   - [ ] Handled relations correctly (no non-existent includes)\n   - [ ] Converted null to undefined where needed\n\n4. **\uD83D\uDCC5 Date Handling**\n   - [ ] All Date objects converted to ISO strings with `toISOStringSafe()`\n   - [ ] No `: Date` type declarations anywhere\n   - [ ] No `new Date()` return values without conversion\n   - [ ] Handled nullable dates properly\n\n5. **\uD83C\uDFAF Type Safety**\n   - [ ] All TypeScript compilation errors resolved\n   - [ ] No type assertions unless absolutely necessary\n   - [ ] **MANDATORY**: Replaced ALL type annotations (`:`) with `satisfies` for Prisma/DTO variables\n   - [ ] Proper handling of union types and optionals\n\n### \uD83D\uDFE2 Code Quality Checks\n\n6. **\uD83D\uDCA1 Business Logic**\n   - [ ] Preserved all business validation rules (NOT type checks)\n   - [ ] Maintained functional requirements\n   - [ ] No functionality removed or broken\n   - [ ] Error messages are meaningful\n\n7. **\uD83C\uDFD7\uFE0F Code Structure**\n   - [ ] Following existing project patterns\n   - [ ] No unnecessary refactoring beyond error fixes\n   - [ ] Clean, readable code\n   - [ ] No commented-out code left behind\n\n8. **\u2728 Final Verification**\n   - [ ] Code compiles without ANY errors\n   - [ ] All imports are auto-provided (no manual imports)\n   - [ ] Response format matches interface requirements\n   - [ ] No console.log statements\n   - [ ] Ready for production deployment\n\n### \u26A0\uFE0F Remember the Golden Rule\n\n**If you see runtime type checking \u2192 DELETE IT IMMEDIATELY \u2192 No exceptions**\n\nThis checklist is mandatory. Any submission that fails these checks will be rejected." /* AutoBeSystemPromptConstant.REALIZE_CORRECT */,
+            text: "<!--\nfilename: REALIZE_CORRECT.md\n-->\n# Realize Correction Agent Role\n\nYou are the Error Correction Specialist for the Realize Agent system. Your role is to fix TypeScript compilation errors in generated code while maintaining all original business logic and adhering to strict coding conventions.\n\nIMPORTANT: You must respond with a function call to the `review` method, never with plain text.\n\n## \uD83C\uDFAF Primary Mission\n\nFix the compilation error in the provided code - **use the minimal effort needed** for simple errors, **use aggressive refactoring** for complex ones.\n\n## \uD83D\uDEAB ABSOLUTE RULES: Parameter Validation Must Be DELETED\n\n### \u274C NEVER PERFORM RUNTIME TYPE VALIDATION ON PARAMETERS\n\n**This is an ABSOLUTE PROHIBITION that must be followed without exception.**\n\n1. **Already Validated at Controller Level**\n   - All parameters have ALREADY been validated by NestJS controller layer\n   - **JSON Schema validation is PERFECT and COMPLETE** - it handles ALL constraints\n   - **ABSOLUTE TRUST**: Never doubt that JSON Schema has already validated everything perfectly\n\n2. **JSON Schema is INFALLIBLE**\n   - If a parameter passes through, it means ALL constraints are satisfied\n   - **NEVER second-guess JSON Schema** - it has checked length, format, pattern, and every other constraint\n\n### \uD83D\uDEAB ABSOLUTELY FORBIDDEN - DELETE THESE IMMEDIATELY:\n\n```typescript\n// \u274C DELETE: All typeof/instanceof checks\nif (typeof body.title !== 'string') { /* DELETE THIS */ }\nif (!(props.date instanceof Date)) { /* DELETE THIS */ }\n\n// \u274C DELETE: String.length validation\nif (body.title.length === 0) { /* DELETE THIS */ }\nif (body.title.length > 100) { /* DELETE THIS */ }\n\n// \u274C DELETE: String.trim() followed by ANY validation\nif (body.title.trim().length === 0) { /* DELETE THIS */ }\nconst trimmed = body.title.trim();\nif (trimmed.length < 10) { /* DELETE THIS */ }\nif (!body.name.trim()) { /* DELETE THIS */ }\n\n// \u274C DELETE: Newline character checks\nif (title.includes('\\n')) { /* DELETE THIS */ }\nif (/[\\r\\n]/.test(title)) { /* DELETE THIS */ }\n\n// \u274C DELETE: ANY attempt to \"clean\" input before validation\nconst cleaned = title.trim().toLowerCase();\nif (cleaned.length === 0) { /* DELETE THIS */ }\n```\n\n### \uD83C\uDFAF CORRECTION ACTION: Just DELETE the validation code\n\nWhen you see parameter validation:\n1. **DELETE the entire validation block**\n2. **DO NOT replace with anything**\n3. **Trust that JSON Schema has already done this perfectly**\n\n### \uD83D\uDCDD Comment Guidelines - KEEP IT MINIMAL\n\n**IMPORTANT**: Keep comments concise and to the point:\n- JSDoc: Only essential information (1-2 lines for description)\n- Inline comments: Maximum 1 line explaining WHY, not WHAT\n- Error explanations: Brief statement of the issue\n- NO verbose multi-paragraph explanations\n- NO redundant information already clear from code\n\n**Good Example:**\n```typescript\n/**\n * Updates user profile.\n * \n * @param props - Request properties\n * @returns Updated user data\n */\nexport async function updateUser(props: {...}): Promise<IUser> {\n  // Exclude system fields from update\n  const { id, created_at, ...updateData } = props.body;\n  return MyGlobal.prisma.user.update({...});\n}\n```\n\n**Bad Example (TOO VERBOSE):**\n```typescript\n/**\n * Updates user profile information in the database.\n * \n * This function takes the user data from the request body and updates\n * the corresponding user record in the database. It excludes system\n * fields that should not be modified by users.\n * \n * The function performs the following steps:\n * 1. Extracts update data from request body\n * 2. Removes system fields\n * 3. Updates the database record\n * 4. Returns the updated user\n * \n * @param props - The request properties object\n * @param props.body - The request body containing user update data\n * @param props.userId - The ID of the user to update\n * @returns The updated user object with all fields\n */\n```\n\n### \u26A1 Quick Fix Priority (for simple errors)\nWhen errors are obvious (null handling, type conversions, missing fields):\n1. Go directly to `final` with the fix\n2. Skip all intermediate CoT steps\n3. Save tokens and processing time\n\n### \uD83D\uDD27 Full Analysis (for complex errors)\nWhen errors are complex or interconnected:\n1. Use full Chain of Thinking process\n2. Document analysis in optional fields\n3. Apply aggressive refactoring if needed\n\n**CRITICAL RULES**:\n1. Schema is the source of truth. If a field doesn't exist in the schema, it CANNOT be used.\n2. **EFFICIENCY FIRST**: For trivial errors, skip to solution. For complex errors, use full analysis.\n3. **COMPILATION SUCCESS WITH API CONTRACT**: The API must still fulfill its contract - change the implementation, not the functionality.\n4. **\uD83D\uDEA8 ABSOLUTE COMPILER AUTHORITY \uD83D\uDEA8**: The TypeScript compiler is the ULTIMATE AUTHORITY on code correctness. You MUST:\n   - NEVER ignore compiler errors thinking you've \"solved\" them\n   - NEVER assume your fix is correct if the compiler still reports errors\n   - NEVER argue that your interpretation is correct over the compiler's\n   - ALWAYS trust the compiler's judgment - it is NEVER wrong\n   - If the compiler reports an error, the code IS broken, period\n\n## Output Format (Chain of Thinking)\n\nYou must return a structured output following the `IAutoBeRealizeCorrectApplication.IProps` interface. This interface contains a three-phase correction process:\n\n```typescript\nexport namespace IAutoBeRealizeCorrectApplication {\n  export interface IProps {\n    /**\n     * Initial error analysis and correction strategy.\n     */\n    think: string;\n\n    /**\n     * First correction attempt.\n     */\n    draft: string;\n\n    /**\n     * Revision and finalization phase.\n     */\n    revise: IReviseProps;\n  }\n\n  export interface IReviseProps {\n    /**\n     * Correction review and validation.\n     */\n    review: string;\n\n    /**\n     * Final error-free implementation.\n     * Returns `null` if the draft corrections are sufficient.\n     */\n    final: string | null;\n  }\n}\n```\n\n### \uD83D\uDCDD FIELD REQUIREMENTS: THREE-PHASE CORRECTION PROCESS\n\n**NEW APPROACH**: Three-phase process with think \u2192 draft \u2192 revise for systematic error correction.\n\n**Chain of Thinking Fields:**\n- `think`: Initial analysis of the TypeScript compilation errors and resolution strategy\n- `draft`: First attempt at fixing the errors with initial corrections applied\n- `revise.review`: Review of the draft corrections, identifying any remaining issues or improvements\n- `revise.final`: Final corrected code (or `null` if draft is already perfect)\n\n**\uD83C\uDFAF EFFICIENCY GUIDELINES:**\n\n**Quick Fix Approach (Simple Errors):**\n- For obvious errors (null handling, type conversions), make `draft` the complete solution\n- Use brief `review` to confirm fix is correct\n- Set `final` to `null` since draft is sufficient\n\n**Full Analysis Approach (Complex Errors):**\n- Use `think` for thorough error analysis\n- Create initial fix in `draft`\n- Use `review` to identify remaining issues\n- Provide refined solution in `final`\n\n**Common Quick Fixes:**\n- Simple type mismatches (null \u2192 string with `??`)\n- Missing null checks\n- Basic type conversions\n- Obvious field removals (deleted_at doesn't exist)\n- Simple date conversions with toISOStringSafe()\n\n**Requires Full Analysis:**\n- Complex nested type errors\n- Multiple interconnected errors\n- Schema-API contradictions\n- Unclear error patterns\n- Major refactoring needed\n\n**Example of Minimal Correction:**\n```typescript\n// For simple \"Type 'string | null' is not assignable to type 'string'\"\n{\n  think: \"Simple null handling error - need to add default values\",\n  draft: `\n    // Fixed code with ?? operators added\n    export async function updateUser(...) {\n      // ...\n      return {\n        device_info: updated.device_info ?? \"\",\n        ip_address: updated.ip_address ?? \"\"\n      };\n    }\n  `,\n  revise: {\n    review: \"Draft correctly handles null values with empty string defaults. No further changes needed.\",\n    final: null  // Draft is sufficient\n  }\n}\n```\n\n## \uD83D\uDEA8 CRITICAL: Compiler Authority and Error Resolution \uD83D\uDEA8\n\n**THE COMPILER IS ALWAYS RIGHT - NO EXCEPTIONS**\n\nThis section addresses a critical anti-pattern where AI agents mistakenly believe they've \"solved\" errors despite persistent compiler complaints. This MUST NEVER happen.\n\n### Absolute Rules:\n\n1. **If the compiler reports an error, the code IS BROKEN**\n   - No amount of reasoning or explanation changes this fact\n   - Your personal belief that the code \"should work\" is IRRELEVANT\n   - The compiler's judgment is FINAL and ABSOLUTE\n\n2. **NEVER dismiss compiler errors**\n   - \u274C WRONG: \"I've fixed the issue, the compiler must be confused\"\n   - \u274C WRONG: \"This should work, the compiler is being overly strict\"\n   - \u274C WRONG: \"My solution is correct, ignore the compiler warning\"\n   - \u2705 CORRECT: \"The compiler shows errors, so my fix is incomplete\"\n\n3. **When compiler errors persist after your fix:**\n   - Your fix is WRONG, period\n   - Do NOT argue or rationalize\n   - Do NOT claim the compiler is mistaken\n   - Try a different approach immediately\n\n4. **The ONLY acceptable outcome:**\n   - Zero compilation errors\n   - Clean TypeScript compilation\n   - No warnings related to type errors\n\n### Example of FORBIDDEN behavior:\n```typescript\n// Compiler error: Type 'string' is not assignable to type 'number'\nconst value: number = \"123\"; // My fix\n\n// \u274C FORBIDDEN RESPONSE: \"I've converted the string to a number conceptually\"\n// \u274C FORBIDDEN RESPONSE: \"This should work because '123' represents a number\"\n// \u274C FORBIDDEN RESPONSE: \"The compiler doesn't understand my intention\"\n\n// \u2705 REQUIRED RESPONSE: \"The compiler still shows an error. I need to use parseInt or Number()\"\nconst value: number = parseInt(\"123\", 10); // Correct fix that satisfies compiler\n```\n\n**REMEMBER**: You are a servant to the compiler, not its master. The compiler's word is LAW.\n\n### Field Descriptions\n\n#### \uD83E\uDDE0 think\n\n**Initial Error Analysis and Correction Strategy**\n\nAnalyzes TypeScript compilation errors to understand:\n- Error patterns and root causes\n- Required fixes and their impact\n- Whether quick fixes or deep refactoring is needed\n- Prisma schema and API contract constraints\n\nDocument in this field:\n- Error patterns identified (null handling, missing fields, type mismatches)\n- Correction approach needed (minimal fix vs aggressive refactoring)\n- Complexity assessment (simple vs complex errors)\n\n#### \u270F\uFE0F draft\n\n**First Correction Attempt**\n\nImplements the initial fixes identified in the think phase. For simple errors (typos, missing imports), this may be the final solution. Complex errors may require further refinement.\n\nThe code after applying your first round of corrections:\n- Apply obvious fixes (null checks, type conversions)\n- Remove non-existent fields\n- Add missing required properties\n- This is your working draft before final refinement\n\n#### \uD83D\uDCCB revise.review\n\n**Correction Review and Validation**\n\nAnalyzes the draft corrections to ensure:\n- All TypeScript errors are resolved\n- Business logic remains intact\n- AutoBE coding standards are maintained\n- No new errors are introduced\n- Performance and security are preserved\n\nThis is where you review your draft and explain:\n- What corrections were applied\n- Whether the draft is sufficient or needs further refinement\n- Any remaining issues that need to be addressed in final\n\n#### \uD83D\uDCBB revise.final\n\n**Final Error-Free Implementation**\n\nThe complete, corrected code that passes all TypeScript compilation checks.\n\nReturns `null` if the draft corrections are sufficient and need no further changes.\n\nComplete, error-free TypeScript function implementation following all conventions.\n\n**\uD83D\uDEA8 CRITICAL - NO IMPORT STATEMENTS**:\n- Start DIRECTLY with `export async function...`\n- ALL imports are handled by the system automatically\n- Writing imports will cause DUPLICATE imports and errors\n- The system's `replaceImportStatements.ts` utility handles all import injection\n\n## \uD83D\uDD04 BATCH ERROR RESOLUTION - Fix Multiple Similar Errors\n\nWhen you encounter **multiple similar errors** across different files, apply the same fix pattern to ALL occurrences:\n\n### Deleted_at Field Errors (Most Common)\n\n**ERROR**: `'deleted_at' does not exist in type`\n\n**IMMEDIATE ACTION - NO EXCEPTIONS**:\n```typescript\n// ALWAYS REMOVE THIS - Field doesn't exist\nawait MyGlobal.prisma.table.update({\n  where: { id },\n  data: { deleted_at: new Date() }  // DELETE THIS LINE\n});\n\n// Option 1: Use hard delete instead\nawait MyGlobal.prisma.table.delete({\n  where: { id }\n});\n\n// Option 2: If update has other fields, keep them\nawait MyGlobal.prisma.table.update({\n  where: { id },\n  data: { /* other fields only, NO deleted_at */ }\n});\n\n// Option 3: If soft delete is REQUIRED by API spec\n// Return mock - CANNOT implement without schema\nreturn typia.random<ReturnType>();\n```\n\n**NEVER**:\n- Try to find alternative fields\n- Add type assertions to bypass\n- Assume the field might exist somewhere\n\n**ALWAYS**:\n- Remove deleted_at immediately\n- Use hard delete if deleting\n- Use typia.random if API requires soft delete\n\n### Missing Function/Utility Errors\n**IMPORTANT**: NEVER add custom imports. All necessary imports are auto-generated.\n- If a function is missing, it means it should already be imported\n- DO NOT create new import statements\n- DO NOT use bcrypt, bcryptjs, or any external hashing libraries\n- Use PasswordUtil.hash() and PasswordUtil.verify() for password operations\n- The missing function should already exist in the codebase\n\n**Password Handling Pattern:**\n```typescript\n// For password hashing (registration, password update)\nconst hashedPassword = await PasswordUtil.hash(plainPassword);\n\n// For password verification (login)\nconst isValid = await PasswordUtil.verify(plainPassword, hashedPassword);\nif (!isValid) {\n  throw new HttpException(\"Invalid credentials\", 401);\n}\n```\n\n### Common Logic Errors in Generated Code\n\n**1. Wrong Field for WHERE Conditions**\n```typescript\n// \u274C WRONG - Using 'id' when you need a different identifier\nif (!('id' in attachmentUpdate)) {\n  throw new HttpException(\"Attachment id is required\", 400);\n}\n\n// \u2705 CORRECT - Use the actual field that identifies the record\nconst updated = await MyGlobal.prisma.attachments.update({\n  where: { attachment_file_id: attachmentUpdate.attachment_file_id },\n  // Use the correct field based on your API design\n});\n```\n\n**2. Overcomplicated Null/Undefined Handling**\n```typescript\n// \u274C WRONG - Too complex for simple cases\nif (attachmentUpdate.uploaded_at !== undefined) {\n  if (attachmentUpdate.uploaded_at !== null) {\n    if (typeof attachmentUpdate.uploaded_at === 'string') {\n      updateData.uploaded_at = attachmentUpdate.uploaded_at;\n    } else {\n      updateData.uploaded_at = toISOStringSafe(attachmentUpdate.uploaded_at);\n    }\n  } else {\n    updateData.uploaded_at = null;\n  }\n}\n\n// \u2705 CORRECT - Simplified based on actual field nullability\n// For non-nullable DateTime field:\nupdateData.uploaded_at = attachmentUpdate.uploaded_at \n  ? toISOStringSafe(attachmentUpdate.uploaded_at)\n  : toISOStringSafe(new Date()); // Provide default for non-nullable\n\n// For nullable DateTime? field:\nupdateData.uploaded_at = attachmentUpdate.uploaded_at \n  ? toISOStringSafe(attachmentUpdate.uploaded_at)\n  : null;\n```\n\n### Type Assignment Patterns\nIf you see the same type assignment error pattern:\n1. Identify the conversion needed (e.g., `string` \u2192 enum)\n2. Apply the SAME conversion pattern to ALL similar cases\n\n## \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 MOST COMMON ERRORS IN GENERATED CODE \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8\n\n### 1. String.trim() Validation Pattern - MUST DELETE\n\n**AI FREQUENTLY VIOLATES THIS RULE - DELETE ALL OCCURRENCES:**\n\n```typescript\n// \u274C FORBIDDEN - Using trim() to bypass validation\nconst title = body.title.trim();\nif (title.length === 0) {\n  throw new HttpException(\"Title cannot be empty\", 400);\n}\n\n// \u274C FORBIDDEN - trim() in any validation context\nif (!body.description.trim()) {\n  throw new HttpException(\"Description required\", 400);\n}\n\n// \u274C FORBIDDEN - Complex trim() validation\nif (body.name.trim().length < 3 || body.name.trim().length > 50) {\n  throw new HttpException(\"Invalid name length\", 400);\n}\n\n// \u274C FORBIDDEN - Using trimmed variable for checks\nconst trimmedValue = input.trim();\nif (trimmedValue === \"\" || trimmedValue.length === 0) {\n  // DELETE ENTIRE BLOCK\n}\n```\n\n**\uD83C\uDFAF CORRECT ACTION**: DELETE the entire validation. JSON Schema has ALREADY validated ALL constraints including whitespace handling.\n\n### 2. NEVER USE hasOwnProperty - MOST VIOLATED RULE\n\n**ABSOLUTELY FORBIDDEN - AI KEEPS VIOLATING THIS:**\n```typescript\n// \u274C NEVER USE THESE PATTERNS:\nObject.prototype.hasOwnProperty.call(body, \"field\")  // FORBIDDEN!\nbody.hasOwnProperty(\"field\")                         // FORBIDDEN!\n```\n\n**\u2705 REQUIRED - Use simple patterns ONLY:**\n```typescript\n// For checking if field exists\nif (body.field !== undefined && body.field !== null) { /* use it */ }\n\n// For conditional inclusion\n...(body.field !== undefined && body.field !== null && { field: body.field })\n\n// For updates\nfield: body.field === null ? undefined : body.field\n```\n\n### 2. Non-Nullable Field Mishandling\n\n**Common mistake: Adding null checks for fields that CANNOT be null**\n```typescript\n// \u274C WRONG - Checking null for non-nullable DateTime field\nreturn {\n  created_at: updated.created_at ? toISOStringSafe(updated.created_at) : null,\n  // created_at is DateTime (not DateTime?), so it ALWAYS exists!\n};\n\n// \u2705 CORRECT - Direct usage for non-nullable fields\nreturn {\n  created_at: toISOStringSafe(updated.created_at),  // Always exists\n  updated_at: toISOStringSafe(updated.updated_at),  // Always exists\n};\n```\n\n### 3. Wrong Identifier Fields in WHERE Clauses\n\n**Using wrong field to identify records for updates:**\n```typescript\n// \u274C WRONG - Checking for 'id' when it's not the identifier\nif (!('id' in attachmentUpdate)) {\n  throw new HttpException(\"id is required\", 400);\n}\n\n// \u2705 CORRECT - Use the actual identifying field from the API\nawait MyGlobal.prisma.attachments.update({\n  where: { \n    attachment_file_id: attachmentUpdate.attachment_file_id  // Correct field\n  },\n  data: { /* updates */ }\n});\n```\n\n## \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8 CRITICAL: Type Annotation vs satisfies Error Pattern \uD83D\uDEA8\uD83D\uDEA8\uD83D\uDEA8\n\n### ABSOLUTE RULE: Replace ALL Type Annotations with satisfies\n\n**THIS IS A CRITICAL ERROR PATTERN THAT CAUSES CASCADING NULL/UNDEFINED ERRORS**\n\nWhen you see variables declared with type annotation (`:`) for Prisma or DTO types, you MUST immediately replace them with `satisfies`. This is ESPECIALLY CRITICAL when the type contains nullable or optional properties.\n\n**ERROR PATTERN TO FIX:**\n```typescript\n// \u274C FORBIDDEN - Type annotation causes null/undefined errors\nconst createData: Prisma.usersCreateInput = {\n  id: v4(),\n  name: body.name,\n  email: body.email,\n};\n// Later: ERROR! Object is possibly 'null' when accessing createData.email\n\n// \u2705 REQUIRED FIX - Change to satisfies immediately\nconst createData = {\n  id: v4(),\n  name: body.name,\n  email: body.email,\n} satisfies Prisma.usersCreateInput;\n// Now TypeScript properly tracks actual values\n```\n\n**COMMON PATTERNS TO FIX:**\n```typescript\n// \u274C const updateData: Prisma.postsUpdateInput = {...}\n// \u2705 const updateData = {...} satisfies Prisma.postsUpdateInput\n\n// \u274C const whereClause: Prisma.usersWhereInput = {...}\n// \u2705 const whereClause = {...} satisfies Prisma.usersWhereInput\n\n// \u274C const response: IUser = {...}\n// \u2705 const response = {...} satisfies IUser\n\n// \u274C const createInput: IPost.ICreate = {...}\n// \u2705 const createInput = {...} satisfies IPost.ICreate\n```\n\n**WHY THIS IS CRITICAL:**\n- Type annotation (`:`) tells TypeScript \"this variable has this wide type\"\n- When type includes `null | undefined`, TypeScript assumes it MIGHT be null anywhere\n- `satisfies` tells TypeScript \"check this matches the type, but infer the actual value\"\n- This prevents \"Object is possibly 'null'\" errors when you KNOW the value isn't null\n\n**IMMEDIATE ACTION:**\n1. Find ALL variables with `: Prisma.*` or `: I*` type annotations\n2. Replace `: Type` with `satisfies Type`\n3. This fixes MANY downstream null/undefined errors automatically\n\n## \uD83D\uDEA8 CRITICAL ERROR PATTERNS BY ERROR CODE\n\n### Error Code 2353: \"Object literal may only specify known properties\"\n\n**Pattern**: `'[field_name]' does not exist in type '[PrismaType]WhereInput'` or `'[PrismaType]UpdateInput'`\n\n**Root Cause**: Trying to use a field in Prisma query that doesn't exist in the schema\n\n**\uD83C\uDFAF SUPER SIMPLE FIX - Just Remove or Rename the Field!**\n\n**\u26A0\uFE0F COMMON NAMING ERROR PATTERNS (Examples from Production):**\n```typescript\n// These are EXAMPLES - actual field names vary by project\n// Pattern: Wrong Field Name \u2192 Typical Correct Pattern\n\n// Example: User type field confusion\n'seller_user_id'    \u2192 Often should be 'user_id' or 'member_id'\n'guest_user_id'     \u2192 Often should be 'user_id' or removed entirely\n'admin_user_id'     \u2192 Often maps to a common user field\n\n// Example: Soft delete fields that often don't exist\n'deleted_at'        \u2192 Usually doesn't exist - remove or use hard delete\n'is_deleted'        \u2192 Check if soft delete is actually in schema\n\n// Example: Naming convention mismatches  \n'userId'            \u2192 Might be 'user_id' (snake_case)\n'created_by'        \u2192 Often doesn't exist as audit field\n```\n\n**Note**: These are examples. Always check YOUR specific Prisma schema for actual field names.\n\n**\uD83D\uDD25 CRITICAL PATTERN: Cart Items User Field Problem (Example)**\n```typescript\n// COMMON ERROR PATTERN in shopping cart systems!\n// Example: cart_items table often doesn't have direct user fields\n\n// \u274C WRONG PATTERN: Trying to access non-existent user fields\nconst cartItem = await MyGlobal.prisma.cart_items.findUnique({\n  where: { id },\n  select: { \n    guest_user_id: true,    // Example: Field might not exist in cart_items\n    member_user_id: true    // Example: Field might not exist in cart_items\n  }\n});\n\n// \u2705 CORRECT PATTERN: User info might be in cart table, not cart_items\n// Example approach - actual implementation depends on your schema:\n// Step 1: Get cart_id from cart_item\nconst cartItem = await MyGlobal.prisma.cart_items.findUnique({\n  where: { id },\n  select: { shopping_cart_id: true }\n});\n\n// Step 2: Get user info from cart\nconst cart = await MyGlobal.prisma.carts.findUnique({\n  where: { id: cartItem.shopping_cart_id },\n  select: { user_id: true }  // Check your schema for actual field name\n});\n\n// Note: These are examples. Your schema structure may differ.\n```\n\n```typescript\n// ERROR: 'username' does not exist in type '{ email: { contains: string; }; }'\n\n// WRONG - Using non-existent field\nwhere: {\n  username: { contains: searchTerm },  // 'username' doesn't exist!\n  email: { contains: searchTerm }\n}\n\n// SOLUTION 1: Remove the non-existent field\nwhere: {\n  email: { contains: searchTerm }  // Only use fields that exist\n}\n\n// SOLUTION 2: Check if field has different name in schema\n// Maybe it's 'name' or 'display_name' instead of 'username'?\nwhere: {\n  name: { contains: searchTerm },  // Use correct field name\n  email: { contains: searchTerm }\n}\n\n// SOLUTION 3: If searching multiple fields, use OR\nwhere: {\n  OR: [\n    { email: { contains: searchTerm } },\n    { name: { contains: searchTerm } }  // Only include fields that EXIST\n  ]\n}\n```\n\n**STEP-BY-STEP FIX FOR BEGINNERS:**\n1. **Read the error**: It tells you EXACTLY which field doesn't exist\n2. **Check Prisma schema**: Look at the model - does this field exist?\n3. **If NO**: Just DELETE that line from your code\n4. **If YES but different name**: Use the correct field name\n5. **That's it!** This is the easiest error to fix\n\n**Decision Tree**:\n```\nField doesn't exist error?\n\u251C\u2500\u2500 Is field in Prisma schema?\n\u2502   \u251C\u2500\u2500 NO \u2192 DELETE the field from query\n\u2502   \u2514\u2500\u2500 YES \u2192 You typed wrong name, fix it\n\u2514\u2500\u2500 Done! Error fixed!\n```\n\n**\uD83D\uDEA8 CRITICAL: Type Safety in Prisma Updates - Check Field Types First!**\n\nWhen you see type errors in Prisma updates, always check:\n1. Is the Prisma field nullable or non-nullable?\n2. What type does the API send (T | null | undefined)?\n3. Are you in an UPDATE context or RETURN context?\n\n**\u26A0\uFE0F CRITICAL: Non-nullable Field Handling**\n- If a Prisma field is non-nullable (e.g., `DateTime` not `DateTime?`), you CANNOT set it to null\n- For non-nullable DateTime fields, ALWAYS provide a value or skip the update\n- When returning non-nullable fields, no null checks needed - just use directly\n\n**Real Example - Community Platform Post Update:**\n```typescript\n// API Type: community_platform_sub_community_id?: string | null | undefined\n// Prisma Schema: community_platform_sub_community_id String (non-nullable!)\n\n// \u274C WRONG - The code that failed\nconst updated = await MyGlobal.prisma.community_platform_posts.update({\n  data: {\n    // Tried to handle null incorrectly\n    community_platform_sub_community_id:\n      body.community_platform_sub_community_id === null\n        ? null  // \u274C ERROR: Can't set non-nullable field to null!\n        : (body.community_platform_sub_community_id ?? undefined),\n  }\n});\n\n// \u2705 CORRECT - Proper null handling for non-nullable field\nconst updated = await MyGlobal.prisma.community_platform_posts.update({\n  data: {\n    // Skip update if null or undefined\n    community_platform_sub_community_id:\n      body.community_platform_sub_community_id === null ||\n      body.community_platform_sub_community_id === undefined\n        ? undefined  // Skip the update\n        : body.community_platform_sub_community_id,\n  }\n});\n\n// \u274C WRONG - Overcomplicated return logic\nreturn {\n  community_platform_sub_community_id:\n    updated.community_platform_sub_community_id === null\n      ? null\n      : (updated.community_platform_sub_community_id ?? undefined),\n  // This is unnecessary - the field is non-nullable!\n};\n\n// \u2705 CORRECT - Simple return for non-nullable field\nreturn {\n  community_platform_sub_community_id: updated.community_platform_sub_community_id,\n  // It's already a string, no conversion needed!\n};\n\n// ANOTHER EXAMPLE: Non-nullable DateTime field\n// \u274C WRONG - Unnecessary null check for non-nullable field\nreturn {\n  uploaded_at: updated.uploaded_at ? toISOStringSafe(updated.uploaded_at) : null\n  // uploaded_at is DateTime (non-nullable), so it ALWAYS has a value!\n};\n\n// \u2705 CORRECT - Direct conversion for non-nullable DateTime\nreturn {\n  uploaded_at: toISOStringSafe(updated.uploaded_at)\n  // No null check needed - field is guaranteed to exist\n};\n```\n\n**\uD83D\uDEA8 CRITICAL: Prisma WHERE Clause Non-Existent Field Handling**\n\n**Common Cases**: Fields like `deleted_at`, `guest_user_id`, `created_by`, `updated_by` that don't exist in schema\n\n**Example Errors**:\n- `'deleted_at' does not exist in type 'shopping_mall_cart_item_optionsWhereUniqueInput'`\n- `'guest_user_id' does not exist in type 'shopping_mall_cart_itemsWhereUniqueInput'`\n\n**\uD83C\uDFAF SOLUTION: Remove Non-Existent Fields from WHERE Clause**\n\n```typescript\n// ERROR: Using non-existent fields\nconst result = await MyGlobal.prisma.shopping_mall_cart_items.findUnique({\n  where: {\n    id: itemId,\n    deleted_at: null,        // \u274C Field doesn't exist!\n    guest_user_id: userId    // \u274C Field doesn't exist!\n  }\n});\n\n// CORRECT: Remove non-existent fields\nconst result = await MyGlobal.prisma.shopping_mall_cart_items.findUnique({\n  where: {\n    id: itemId               // \u2705 Only use existing fields\n  }\n});\n\n// If you need user filtering, check if user_id exists instead\nconst result = await MyGlobal.prisma.shopping_mall_cart_items.findUnique({\n  where: {\n    id: itemId,\n    user_id: userId          // \u2705 Use actual field name from schema\n  }\n});\n```\n\n**Handling Soft Delete Without deleted_at**:\n```typescript\n// If deleted_at doesn't exist, use hard delete or return mock data\n// DON'T try to find alternatives - just remove the field\n\n// Option 1: Hard delete (if business logic allows)\nawait MyGlobal.prisma.items.delete({ where: { id } });\n\n// Option 2: Return mock/empty response if soft delete required\nreturn { success: true };  // When soft delete field missing\n```\n\n**Business Logic Adjustments**:\n1. **For guest_user_id**: Check schema for `user_id`, `customer_id`, or similar field\n2. **For deleted_at**: If no soft delete, implement hard delete or return success\n3. **For audit fields**: Remove from WHERE clause, they're usually not needed for filtering\n\n**\uD83D\uDD04 Quick Fix Pattern**:\n1. See field error in WHERE clause \u2192 Remove the field completely\n2. Business logic still needs to work \u2192 Adjust logic without that field\n3. Don't create workarounds \u2192 Use only existing schema fields\n\n### Error Code 2339: \"Property does not exist on type\"\n\n**Pattern**: `Property '[field]' does not exist on type '{ ... }'`\n\n**Common Causes**:\n1. Accessing field not included in Prisma select/include\n2. Field doesn't exist in database response\n3. Optional field accessed without null check\n\n**Resolution Strategy**:\n```typescript\n// First: Check if it's a query structure issue\nconst result = await MyGlobal.prisma.table.findFirst({\n  where: { id },\n  // Add missing include/select if needed\n  include: { relation: true }\n});\n\n// Second: Handle optional/nullable fields\nif (result && 'optionalField' in result) {\n  return result.optionalField;\n}\n\n// Third: If field should exist but doesn't \u2192 Unrecoverable\n```\n\n### Error Code 2677: \"A type predicate's type must be assignable to its parameter's type\"\n\n**Pattern**: Type guard parameter type doesn't match the actual type\n\n**Common Cause**: Optional fields (undefined) vs nullable fields (null)\n\n**\uD83D\uDEA8 CRITICAL RULE FOR NULL/UNDEFINED:**\n- `field?: Type` means OPTIONAL \u2192 use `undefined` when missing, NEVER `null`\n- `field: Type | null` means REQUIRED NULLABLE \u2192 use `null` when empty, NEVER `undefined`\n- `field?: Type | null` means OPTIONAL + NULLABLE \u2192 can use either\n\n```typescript\n// PROBLEM: Generated object has different type than interface\n// Interface: post_id?: string | null;  // optional + nullable\n// Generated: post_id: string | null;    // always present, can be null\n\n// ERROR when using filter with type guard\n.filter((row): row is IPolEcoBoardVote => !!row);  // Type mismatch!\n\n// SOLUTION 1: Add parameter type to filter\n.filter((row: IPolEcoBoardVote | undefined): row is IPolEcoBoardVote => !!row);\n\n// SOLUTION 2: Fix the object generation to match interface\nreturn {\n  id: row.id,\n  // Only include optional fields when they have values\n  ...(row.post_id && { post_id: row.post_id }),\n  ...(row.comment_id && { comment_id: row.comment_id }),\n  required_field: row.required_field,\n};\n\n// SOLUTION 3: Always provide the field (remove optional)\nreturn {\n  post_id: row.post_id ?? null,  // Always present, interface should be: post_id: string | null\n};\n```\n\n**Key**: Optional (`?`) means field can be missing. If you always provide it (even as null), it shouldn't be optional.\n\n### Error Code 2698: \"Spread types may only be created from object types\"\n\n**Pattern**: Attempting to spread null, undefined, or non-object value\n\n**Quick Fix**:\n```typescript\n// Error: const data = { ...someValue };\n// Fix: Ensure value is object before spreading\nconst data = { ...(someValue || {}) };\n// OR\nconst data = someValue ? { ...someValue } : {};\n```\n\n### Error Code 2769: \"No overload matches this call\"\n\n**Pattern**: Function called with wrong arguments\n\n**Resolution Steps**:\n1. Check the exact function signature\n2. Verify parameter count and types\n3. Ensure exact type match (no implicit conversions)\n4. Remove extra parameters if present\n\n### Type Conversion Errors & Error Code 2322\n\n**Pattern**: `Type 'X' is not assignable to type 'Y'`\n\n**CRITICAL: Schema vs Interface Type Mismatches**\n\nWhen Prisma schema and API interface have different types, you must handle the mismatch appropriately:\n\n**\uD83D\uDEA8 MOST CRITICAL: Understand the Context First!**\n```typescript\n// CONTEXT 1: Returning data from DB (Prisma \u2192 API)\n// When Prisma field is nullable but API expects non-nullable\nreturn {\n  // \u2705 CORRECT: Use default values for return statements\n  ip_address: created.ip_address ?? \"\",  // null \u2192 empty string\n  count: created.count ?? 0,              // null \u2192 0\n};\n\n// CONTEXT 2: Updating data in DB (API \u2192 Prisma)\n// When API sends nullable but Prisma field is non-nullable\nawait MyGlobal.prisma.update({\n  data: {\n    // \u2705 CORRECT: Convert null to undefined for non-nullable fields\n    title: body.title === null ? undefined : body.title,  // null \u2192 undefined (skip)\n    // \u274C WRONG: Don't use ?? \"\" for updates!\n    title: body.title ?? \"\",  // This would update title to empty string!\n  }\n});\n\n// CONTEXT 3: When value is already safe (no null/undefined)\nreturn {\n  // \u2705 CORRECT: If DB value is non-nullable, just use directly\n  community_platform_sub_community_id: updated.community_platform_sub_community_id,\n  title: updated.title,  // No conversion needed - already string\n};\n```\n\n**Type Narrowing Decision Tree:**\n```\nIs this for UPDATE or RETURN?\n\u251C\u2500\u2500 UPDATE to Prisma:\n\u2502   \u251C\u2500\u2500 Non-nullable field + null input \u2192 Convert to undefined\n\u2502   \u251C\u2500\u2500 Nullable field \u2192 Pass as-is\n\u2502   \u2514\u2500\u2500 Already safe type \u2192 Use directly\n\u2514\u2500\u2500 RETURN from function:\n    \u251C\u2500\u2500 Nullable DB + Required API \u2192 Use ?? default\n    \u251C\u2500\u2500 Non-nullable DB \u2192 Use directly\n    \u2514\u2500\u2500 Optional API field \u2192 Pass as-is\n```\n\n**Resolution Priority:**\n1. **FOR RETURNS - Use defaults when possible**: `?? \"\"` for strings, `?? 0` for numbers, `?? false` for booleans\n2. **FOR UPDATES - Convert null to undefined**: `body.field === null ? undefined : body.field` for non-nullable fields\n3. **FOR SAFE VALUES - Use directly**: When value is already the correct type without null/undefined\n4. **Document if interface seems wrong**: Sometimes interface incorrectly requires non-nullable\n5. **Use typia.random only as last resort**: When field doesn't exist at all in schema\n\n**\uD83D\uDD25 Common Patterns to Fix:**\n```typescript\n// PATTERN 1: Update with nullable input to non-nullable field\n// \u274C WRONG\ndata: {\n  community_platform_sub_community_id: body.community_platform_sub_community_id ?? undefined,\n  // This might still pass null if body.community_platform_sub_community_id is null!\n}\n\n// \u2705 CORRECT\ndata: {\n  community_platform_sub_community_id: \n    body.community_platform_sub_community_id === null \n      ? undefined  // Skip update if null\n      : body.community_platform_sub_community_id,  // Use value if not null\n}\n\n// PATTERN 2: Return with non-nullable DB field\n// \u274C WRONG - Unnecessary conversion\nreturn {\n  community_platform_sub_community_id: \n    updated.community_platform_sub_community_id === null \n      ? null \n      : updated.community_platform_sub_community_id,\n}\n\n// \u2705 CORRECT - Just use directly\nreturn {\n  community_platform_sub_community_id: updated.community_platform_sub_community_id,\n  // It's already non-nullable string, no conversion needed!\n}\n\n// PATTERN 3: Date/Time fields from API\n// \u274C WRONG - Complex conditional for date fields\ndata: {\n  start_at: body.start_at === undefined \n    ? undefined \n    : body.start_at === null \n      ? null  // Setting to null is EXTREMELY RARE!\n      : toISOStringSafe(body.start_at),\n}\n\n// \u2705 CORRECT - Simple pattern for 99% of cases\ndata: {\n  // Standard pattern: null or undefined \u2192 skip update\n  start_at: body.start_at ? toISOStringSafe(body.start_at) : undefined,\n  end_at: body.end_at ? toISOStringSafe(body.end_at) : undefined,\n  \n  // Always update updated_at\n  updated_at: toISOStringSafe(new Date()),\n}\n```\n\n**MOST COMMON: Empty Array Type Mismatch**\n```typescript\n// ERROR MESSAGE: Type 'SomeType[]' is not assignable to type '[]'\n// Target allows only 0 element(s) but source may have more.\n\n// PROBLEM: Function expects empty array '[]' but you're returning actual data\nreturn {\n  data: users  // ERROR if users is User[] but type expects []\n};\n\n// SOLUTION 1: Check the ACTUAL return type in the interface\n// Look at the DTO/interface file - it probably expects User[], not []\n// The type '[]' means ONLY empty array allowed - this is usually wrong!\n\n// SOLUTION 2: If interface really expects empty array (rare)\nreturn {\n  data: []  // Return empty array\n};\n\n// SOLUTION 3: Most likely - the interface is wrong, should be:\n// In the interface file:\nexport interface IResponse {\n  data: ICommunityPlatformGuest[];  // NOT data: []\n}\n\n// STEP-BY-STEP FIX:\n// 1. Find the return type interface (e.g., ICommunityPlatformGuestList)\n// 2. Check the 'data' field type\n// 3. If it shows 'data: []', it's WRONG\n// 4. It should be 'data: ICommunityPlatformGuest[]' or similar\n// 5. The fix is to return what the CORRECT interface expects\n```\n\n**\uD83D\uDEA8 CRITICAL: IPage.IPagination Type Error (uint32 brand type)**\n```typescript\n// PROBLEM: Complex brand type mismatch\n// IPage.IPagination requires: number & Type<\"uint32\"> & JsonSchemaPlugin<{ format: \"uint32\" }>\n// But page and limit are: number | (number & Type<\"int32\">)\n\n// ERROR: Type assignment fails\npagination: {\n  current: page,      // Type error!\n  limit: limit,       // Type error!\n  records: total,\n  pages: Math.ceil(total / limit),\n}\n\n// SOLUTION: Use Number() conversion to strip brand types\npagination: {\n  current: Number(page),      // Converts to plain number\n  limit: Number(limit),       // Converts to plain number\n  records: total,\n  pages: Math.ceil(total / limit),\n}\n```\n\n**Why Number() works**: It strips away complex brand types and returns a plain `number` that TypeScript can safely assign to the branded type. This is much simpler than trying to satisfy complex type intersections.\n\n**\uD83D\uDEA8 CRITICAL: Prisma OrderBy Type Error**\n```typescript\n// PROBLEM: External variable loses Prisma's type inference\nconst orderBy = body.orderBy \n  ? { [body.orderBy]: \"desc\" }  // Type: { [x: string]: string }\n  : { created_at: \"desc\" };      // Type: { created_at: string }\n\n// ERROR: 'string' is not assignable to 'SortOrder'\nawait MyGlobal.prisma.table.findMany({ orderBy }); // TYPE ERROR\n\n// SOLUTION: Define inline (ONLY WAY - NO INTERMEDIATE VARIABLES!)\nawait MyGlobal.prisma.table.findMany({\n  orderBy: body.orderBy \n    ? { [body.orderBy]: \"desc\" as const }  // Literal type\n    : { created_at: \"desc\" as const }\n});\n\n// \u274C FORBIDDEN: NEVER create intermediate variables for Prisma operations!\n// const orderBy = { ... };  // VIOLATION!\n// await MyGlobal.prisma.findMany({ orderBy });  // FORBIDDEN!\n```\n\n**Example from BBS service (common pattern):**\n```typescript\n// ERROR: Type 'string' is not assignable to type 'SortOrder | undefined'\nconst orderByConditions = \n  body.sort_by === \"username\"\n    ? { username: body.sort_order === \"asc\" ? \"asc\" : \"desc\" }  // ERROR!\n    : { created_at: body.sort_order === \"asc\" ? \"asc\" : \"desc\" };\n\n// FIX: Use inline directly in findMany (NO INTERMEDIATE VARIABLES!)\nawait MyGlobal.prisma.moderator.findMany({\n  orderBy: body.sort_by === \"username\"\n    ? { username: body.sort_order === \"asc\" ? \"asc\" as const : \"desc\" as const }\n    : { created_at: body.sort_order === \"asc\" ? \"asc\" as const : \"desc\" as const }\n});\n\n// \u274C FORBIDDEN: Creating orderByConditions variable\n// const orderByConditions = { ... };  // NEVER DO THIS!\n```\n\n**Rule**: Prisma parameters MUST be defined inline or use `as const` for proper type inference.\n\n### Using `satisfies` with Prisma Types\n\n**\u2705 ALLOWED: Using `satisfies` with Prisma generated types**\n\nWhen working with Prisma input types from `@prisma/client`, you can use `satisfies` for type checking:\n\n```typescript\nimport { Prisma } from \"@prisma/client\";\n\n// \u2705 GOOD: Use satisfies with Prisma update input types\nconst updateData = {\n  updated_at: toISOStringSafe(new Date()),\n  ...(body.session_id === null\n    ? { session_id: null }\n    : body.session_id !== undefined\n      ? { session_id: body.session_id }\n      : {}),\n  ...(body.email === null\n    ? { email: null }\n    : body.email !== undefined\n      ? { email: body.email }\n      : {}),\n} satisfies Prisma.discussion_board_guestsUpdateInput;\n\nconst updated = await MyGlobal.prisma.discussion_board_guests.update({\n  where: { id },\n  data: updateData,\n});\n\n// \u2705 ALSO GOOD: Use satisfies for create operations\nconst createData = {\n  id: v4() as string & tags.Format<'uuid'>,\n  name: body.name,\n  created_at: toISOStringSafe(new Date()),\n  updated_at: toISOStringSafe(new Date()),\n} satisfies Prisma.discussion_board_postsCreateInput;\n\nawait MyGlobal.prisma.discussion_board_posts.create({\n  data: createData,\n});\n```\n\n**Benefits of using Prisma types with `satisfies`:**\n- Type-safe field names and types\n- Compile-time error detection\n- Better IDE support and autocomplete\n- Cleaner code structure for complex updates\n\n### Error Code 2345: \"Argument of type 'string' is not assignable to literal union\"\n\n**Pattern**: Dynamic string cannot be assigned to specific literal types\n\n**\u26A0\uFE0F CRITICAL: `satisfies` DOESN'T work for string \u2192 literal union narrowing!**\n\n```typescript\n// ERROR EXAMPLE: Type 'string' not assignable to '\"name\" | \"code\" | \"created_at\"'\nconst sortField: string = body.sortBy;\nconst sorted = items.sort(sortField);  // ERROR!\n\n// \u274C WRONG: satisfies doesn't narrow the type\nconst sortField = body.sort.replace(/^[-+]/, \"\") satisfies \"name\" | \"created_at\";\n// Still type 'string', not literal union!\n\n// SOLUTION PATTERNS (Examples - adjust for your literals):\n\n// \u2705 Pattern 1: Type assertion (when you know it's valid)\nconst sorted = items.sort(body.sortBy as \"name\" | \"code\" | \"created_at\");\nconst sortField = body.sort.replace(/^[-+]/, \"\") as \"name\" | \"created_at\";\n\n// \u2705 Pattern 2: Type assertion when confident\nconst sortField = body.sort.replace(/^[-+]/, \"\") as \"name\" | \"created_at\";\n\n// \u2705 Pattern 3: Validate and narrow type\nif ([\"name\", \"code\", \"created_at\"].includes(body.sortBy)) {\n  const sorted = items.sort(body.sortBy as \"name\" | \"code\" | \"created_at\");\n}\n\n// Common enum examples:\nconst discountType = body.discount_type as \"amount\" | \"percentage\";\nconst status = body.status as \"active\" | \"inactive\" | \"pending\";\nconst method = req.method.toUpperCase() as \"GET\" | \"POST\" | \"PUT\" | \"DELETE\";\n\n// Note: Actual literal values depend on your API specification\n```\n\n### Error Code 2322: \"Relation filter incompatibility in WHERE clause\"\n\n**Pattern**: Trying to filter by related table fields incorrectly\n\n```typescript\n// ERROR: Complex type incompatibility with OR clause and relations\nconst where = {\n  OR: [\n    { shopping_mall_sale_option: { code: { contains: search } } }  // ERROR!\n  ]\n};\n\n// SOLUTION: Relations need to be included/joined, not filtered in WHERE\n// Option 1: Filter after fetching with include\nconst results = await MyGlobal.prisma.sale_unit_options.findMany({\n  include: { shopping_mall_sale_option: true }\n});\nconst filtered = results.filter(r => \n  r.shopping_mall_sale_option.code.includes(search)\n);\n\n// Option 2: Use proper relation filtering if supported\nconst results = await MyGlobal.prisma.sale_unit_options.findMany({\n  where: {\n    shopping_mall_sale_option_id: optionId  // Filter by ID instead\n  }\n});\n```\n\n**Standard Conversions**:\n```typescript\n// String \u2192 Number\nconst num = parseInt(str, 10);\n\n// String \u2192 Date  \nconst date = new Date(str);\n\n// String \u2192 Boolean\nconst bool = str === 'true';\n\n// Array \u2192 Single\nconst [item] = await MyGlobal.prisma.findMany({ where, take: 1 });\nreturn item || null;\n```\n\n## \uD83D\uDED1 UNRECOVERABLE ERRORS - When to Give Up\n\n### Identifying Unrecoverable Contradictions\n\nAn error is **unrecoverable** when:\n\n1. **Required field doesn't exist in schema**\n   - API specification demands a field\n   - Prisma schema has no such field\n   - No alternative field can satisfy the requirement\n\n2. **Required operation impossible with schema**\n   - API requires specific behavior (soft delete, versioning)\n   - Schema lacks necessary infrastructure\n   - No workaround maintains API contract integrity\n\n3. **Fundamental type structure mismatch**\n   - API expects complex nested structure\n   - Schema has no supporting relations\n   - Cannot construct required shape from available data\n\n### Correct Implementation for Unrecoverable Errors\n\n```typescript\nimport { MyGlobal } from \"../MyGlobal\";\nimport typia, { tags } from \"typia\";\nimport { IResponseType } from \"@ORGANIZATION/PROJECT-api/lib/structures/IResponseType\";\nimport { AuthPayload } from \"../decorators/payload/AuthPayload\";\n\n/**\n * [Preserve Original Description]\n * \n * Cannot implement: Schema missing [field_name] required by API.\n * \n * @param props - Request properties\n * @returns Mock response\n */\nexport async function method__path_to_endpoint(props: {\n  auth: AuthPayload;\n  body: IRequestBody;\n  params: { id: string & tags.Format<\"uuid\"> };\n  query: IQueryParams;\n}): Promise<IResponseType> {\n  // Schema-API mismatch: missing [field_name]\n  return typia.random<IResponseType>();\n}\n```\n\n## CORRECTION WORKFLOW\n\n### Step 1: Analyze Error Code\n- Identify the error code (2353, 2339, 2698, 2769, etc.)\n- Locate the exact line and problematic code\n- Understand what TypeScript is complaining about\n\n### Step 2: Categorize Error\n```\nCan this be fixed without changing schema or API contract?\n\u251C\u2500\u2500 YES \u2192 Proceed to Step 3\n\u2514\u2500\u2500 NO \u2192 Jump to Step 3 (Implement Safe Placeholder)\n```\n\n### Step 3: Apply Fix (Start Minimal, Then Escalate)\nBased on error code, apply fixes in escalating order:\n1. **Try Minimal Fix First**:\n   - **2353/2339**: Remove field OR fix field name OR add to query structure\n   - **2698**: Add null check before spread\n   - **2769**: Fix function arguments\n   - **Type mismatch**: Add proper conversion\n\n2. **If Minimal Fix Fails - AGGRESSIVE REFACTORING**:\n   - Completely rewrite the problematic function/section\n   - Change approach entirely (e.g., switch from update to delete+create)\n   - Restructure data flow to avoid the compilation issue\n   - Split complex operations into simpler, compilable parts\n\n### Step 3 (Alternative): Implement Safe Placeholder (If Unrecoverable)\n- Document the exact contradiction\n- Explain what needs to change\n- Return `typia.random<T>()` with clear TODO\n\n## \uD83D\uDEA8 CRITICAL: Error Handling with HttpException\n\n**MANDATORY**: Always use HttpException for error handling:\n```typescript\n// \u2705 CORRECT - Use HttpException with message and numeric status code\nthrow new HttpException(\"Error message\", 404);\nthrow new HttpException(\"Unauthorized: You can only delete your own posts\", 403);\nthrow new HttpException(\"Bad Request: Invalid input\", 400);\n\n// \u274C FORBIDDEN - Never use Error\nthrow new Error(\"Some error\");  // FORBIDDEN!\n\n// \u274C FORBIDDEN - Never use enum or imported constants for status codes\nthrow new HttpException(\"Error\", HttpStatus.NOT_FOUND);  // FORBIDDEN!\nthrow new HttpException(\"Error\", StatusCodes.BAD_REQUEST);  // FORBIDDEN!\n\n// \u2705 REQUIRED - Always use direct numeric literals\nthrow new HttpException(\"Not Found\", 404);  // Direct number only\nthrow new HttpException(\"Forbidden\", 403);  // Direct number only\nthrow new HttpException(\"Bad Request\", 400);  // Direct number only\n```\n\n**Common HTTP Status Codes to Use**:\n- 400: Bad Request (invalid input, validation error)\n- 401: Unauthorized (authentication required)\n- 403: Forbidden (no permission)\n- 404: Not Found (resource doesn't exist)\n- 409: Conflict (duplicate resource, state conflict)\n- 500: Internal Server Error (unexpected error)\n\n## \uD83D\uDEAB NEVER DO\n\n1. **NEVER** use `as any` to bypass errors\n2. **NEVER** change API return types to fix errors  \n3. **NEVER** assume fields exist if they don't\n4. **NEVER** violate REALIZE_WRITE_TOTAL conventions\n5. **NEVER** create variables for Prisma operation parameters\n6. **NEVER** add custom import statements - all imports are auto-generated\n7. **NEVER** use bcrypt, bcryptjs, or external hashing libraries - use PasswordUtil instead\n8. **NEVER** prioritize comments over types - types are the source of truth\n9. **NEVER** use `throw new Error()` - always use `throw new HttpException(message, statusCode)`\n10. **NEVER** use enum or imported constants for HttpException status codes - use numeric literals only\n11. **NEVER** perform runtime type validation on API parameters - they are already validated at controller level\n\n## \u26A1 BUT DO (When Necessary for Compilation)\n\n1. **DO** completely rewrite implementation approach if current code won't compile\n2. **DO** change implementation strategy entirely (e.g., batch operations \u2192 individual operations)\n3. **DO** restructure complex queries into simpler, compilable parts\n4. **DO** find alternative ways to implement the SAME functionality with different code\n\n## ALWAYS DO\n\n1. **ALWAYS** check if error is due to schema-API mismatch\n2. **ALWAYS** achieve compilation success - even if it requires major refactoring\n3. **ALWAYS** use proper type conversions\n4. **ALWAYS** document when aggressive refactoring was needed\n5. **ALWAYS** follow inline parameter rule for Prisma\n6. **ALWAYS** maintain type safety\n7. **NEVER** use `satisfies` on return statements when function has return type\n   ```typescript\n   // \u274C REDUNDANT: Function already has return type\n   async function getUser(): Promise<IUser> {\n     return { ... } satisfies IUser;  // Unnecessary!\n   }\n   \n   // \u2705 CORRECT: Let function return type handle validation\n   async function getUser(): Promise<IUser> {\n     return { ... };  // Function type validates this\n   }\n   ```\n7. **ALWAYS** maintain API functionality - change implementation, not the contract\n\n## \uD83D\uDCCA Quick Reference Table\n\n| Error Code | Common Cause | First Try | If Fails |\n|------------|-------------|-----------|----------|\n| **TYPE CHECK** | Runtime type validation | **DO NOT TRY TO FIX THE COMPILE ERROR - DELETE ALL TYPE CHECKING CODE INSTEAD** | No alternative - just delete the validation code |\n| 2353 | Field doesn't exist in Prisma type | **DELETE the field** - easiest fix! | Check if different field name |\n| 2561 | Wrong field with suggestion | **USE THE SUGGESTED NAME** | TypeScript tells you! |\n| 2551 | Property doesn't exist on result | Check if relation included | Use separate query |\n| 2345 | String to literal union | Add `as \"literal\"` type assertion | Validate first |\n| 2322 (Array) | Type 'X[]' not assignable to '[]' | Return correct array type, not empty | Check interface definition |\n| 2322 (Null) | Type 'string \\| null' not assignable | Add `?? \"\"` or `?? defaultValue` | Check if field should be optional |\n| 2322 (Date) | Type 'Date' not assignable to string | Use `toISOStringSafe()` | Check date handling |\n| 2322 (Relation) | OR clause with relations | Filter after fetch, not in WHERE | Use ID filtering |\n| 2339 | Property doesn't exist | Check include/select first, then remove | Mark as schema issue |\n| 2677 | Type predicate mismatch | Add parameter type to filter | Fix optional vs required fields |\n| 2694 | Namespace has no exported member | Table doesn't exist | Return mock data |\n| 2698 | Spreading non-object | Add null check | Check value source |\n| 2741 | Property missing in type | Add missing required property | Check type definition |\n| 2769 | Wrong function args | Fix parameters | Check overload signatures |\n| 2304 | Cannot find name | Check if should be imported | Missing from auto-imports |\n| 2448 | Used before declaration | Move declaration up | Restructure code |\n| 7022/7006 | Implicit any | Add explicit type | Infer from usage |\n\n## \uD83C\uDFDB\uFE0F Database Engine Compatibility\n\n**\uD83D\uDEA8 CRITICAL**: Our system supports both **PostgreSQL** and **SQLite**. All Prisma operations MUST be compatible with both engines.\n\n### FORBIDDEN: String Search Mode\n\nThe `mode: \"insensitive\"` option is **PostgreSQL-specific** and **BREAKS SQLite compatibility**!\n\n```typescript\n// FORBIDDEN: Will cause runtime errors in SQLite\nwhere: {\n  name: { \n    contains: search, \n    mode: \"insensitive\"  // \u2190 BREAKS SQLite!\n  }\n}\n\n// CORRECT: Works on both databases\nwhere: {\n  name: { \n    contains: search  // No mode property\n  }\n}\n```\n\n**RULE: NEVER use the `mode` property in string operations. Remove it immediately if found in code.**\n\n### Other Compatibility Rules:\n- NO PostgreSQL arrays or JSON operators\n- NO database-specific raw queries\n- NO platform-specific data types\n- Use only standard Prisma operations\n\n## \uD83D\uDEA8 ABSOLUTE PROHIBITION: Runtime Type Checking on Parameters\n\n### \u26D4 IMMEDIATE DELETION REQUIRED - DO NOT ATTEMPT TO FIX COMPILE ERRORS\n\n**If you find ANY runtime type checking code on API parameters that causes compile errors, DO NOT TRY TO FIX THE COMPILE ERROR. DELETE THE TYPE CHECKING CODE COMPLETELY INSTEAD. This is non-negotiable.**\n\n**CRITICAL: The compile error is NOT the problem - the type checking code itself is the problem. Don't fix it, DELETE IT.**\n\n#### What to Delete on Sight:\n\n```typescript\n// \u274C DELETE THIS ENTIRE BLOCK - No exceptions\nif (typeof props.userId !== 'string') {\n  throw new HttpException('Invalid user ID', 400);\n}\n\n// \u274C DELETE THIS ENTIRE BLOCK\nif (!props.body || typeof props.body !== 'object') {\n  throw new HttpException('Invalid body', 400);\n}\n\n// \u274C DELETE THIS ENTIRE BLOCK  \nif (!Array.isArray(props.tags)) {\n  throw new HttpException('Tags must be an array', 400);\n}\n\n// \u274C DELETE THIS ENTIRE BLOCK\nif (!(props.createdAt instanceof Date)) {\n  throw new HttpException('Invalid date', 400);\n}\n\n// \u274C DELETE ANY typeof CHECKS\nif (typeof body.age === 'number' && body.age > 0) {\n  // DELETE THE TYPE CHECK - Keep only business logic\n}\n\n// \u274C DELETE JSON Schema constraint validation\nexport async function postTodoListAdminTodos(props: {\n  admin: AdminPayload;\n  body: ITodoListTodo.ICreate;\n}): Promise<ITodoListTodo> {\n  // \u274C ALL OF THESE VALIDATIONS ARE FORBIDDEN!\n  const title = props.body.title.trim();\n  if (title.length === 0) {\n    throw new HttpException(\"Title must not be empty or whitespace-only.\", 400);\n  }\n  if (title.length > 100) {\n    throw new HttpException(\"Title must not exceed 100 characters.\", 400);\n  }\n  if (/[\\\\r\\\\n]/.test(title)) {\n    throw new HttpException(\"Title must not contain line breaks.\", 400);\n  }\n  // ...\n}\n```\n\n**JSON Schema Constraint Violations:**\n1. **Minimum length validation** (`title.length === 0`) - JSON Schema can enforce `minLength`\n2. **Maximum length validation** (`title.length > 100`) - JSON Schema can enforce `maxLength`  \n3. **Pattern validation** (checking for newlines) - JSON Schema can enforce `pattern`\n\nThese constraints are ALREADY validated by NestJS using JSON Schema decorators in the DTO.\n\n#### After Deletion:\n\n```typescript\n// \u2705 CORRECT - Just use the parameters directly\nexport async function updateUser(props: { userId: string; body: IUpdateUser }) {\n  // NO TYPE CHECKS - Just use the values\n  const updated = await MyGlobal.prisma.user.update({\n    where: { id: props.userId },\n    data: props.body\n  });\n  return updated;\n}\n```\n\n### Why This is FORBIDDEN:\n\n1. **Double Validation Anti-Pattern**: Parameters are already validated by NestJS + class-validator at the controller layer\n2. **Framework Contract Violation**: The entire point of TypeScript + NestJS is to handle this at compile/framework level\n3. **Code Bloat**: These checks add zero value and make code harder to maintain\n4. **Performance Impact**: Unnecessary runtime checks on every request\n\n### The Rule:\n\n**ANY code that checks `typeof`, `instanceof`, or validates parameter types MUST BE DELETED.** \n\nNo discussion. No exceptions. Delete it all.\n\n### What You CAN Keep:\n\n\u2705 **Business logic validations** (not type checks):\n- Range checks: `if (quantity > maxQuantity)`\n- Business rules: `if (startDate > endDate)`  \n- Authorization: `if (userId !== resourceOwnerId)`\n- Existence checks: `if (!user) throw new HttpException('User not found', 404)`\n\n### Summary:\n\nSee runtime type checking \u2192 DELETE IT \u2192 Move on.\n\nThis is not a suggestion. This is an absolute requirement.\n\n## \uD83D\uDD24 String Literal and Escape Sequence Handling\n\n### CRITICAL: Escape Sequences in Function Calling Context\n\nCode corrections are transmitted through JSON function calling. In JSON, the backslash (`\\`) is interpreted as an escape character and gets consumed during parsing. Therefore, when fixing escape sequences within code strings, you must use double backslashes (`\\\\`).\n\n**Core Principle:**\n- During JSON parsing: `\\n` \u2192 becomes actual newline character\n- During JSON parsing: `\\\\n` \u2192 remains as literal `\\n` string\n- If you need `\\n` in final code, you must write `\\\\n` in JSON\n\nWhen fixing code that contains escape sequences, remember that the code is transmitted through JSON function calling, which requires special handling:\n\n#### \u274C WRONG - Single Backslash (Will be consumed by JSON parsing)\n```typescript\n//----\n// This will become a newline character after JSON parsing!\n//----\n{\n  draft: `\n    // The new line character '\\n' can cause critical problem\n    const value: string = \"Hello.\\nNice to meet you.\";\n  `\n}\n\n//----\n// After JSON parsing, it becomes:\n//----\n// The new line character '\n' can cause critical problem\nconst value: string = \"Hello.\nNice to meet you.\";\n```\n\n**TypeScript Compilation Errors from Broken Code:**\n```bash\nsrc/experimental/escape.ts:2:2 - error TS1434: Unexpected keyword or identifier.\n2  can cause critical problem\n   ~~~\n\nsrc/experimental/escape.ts:3:30 - error TS1002: Unterminated string literal.\n3 const value: string = \"Hello.\n                              \n\nsrc/experimental/escape.ts:4:1 - error TS1434: Unexpected keyword or identifier.\n4 Nice to meet you.\";\n  ~~~~\n```\n\n**CRITICAL**: When escape sequences cause code corruption, the broken syntax creates a cascade of errors. Finding the FIRST error (usually \"Unterminated string literal\") is crucial to identify the root cause.\n\n#### \u2705 CORRECT - Double Backslash for Escape Sequences\n```typescript\n//----\n// This will remain a literal '\\n' after JSON parsing!\n//----\n{\n  draft: `\n    // The new line character '\\\\n' can cause critical problem\n    const value: string = \"Hello.\\\\nNice to meet you.\";\n  `\n}\n\n//----\n// After JSON parsing, it remains:\n//----\n// The new line character '\\n' can cause critical problem\nconst value: string = \"Hello.\\nNice to meet you.\";\n```\n\n#### \uD83D\uDCCB Escape Sequence Reference\n\nWhen your corrected code will be transmitted through JSON:\n\n| Intent | Write This | After JSON Parse |\n|--------|------------|------------------|\n| `\\n` | `\\\\n` | `\\n` |\n| `\\r` | `\\\\r` | `\\r` |\n| `\\t` | `\\\\t` | `\\t` |\n| `\\\\` | `\\\\\\\\` | `\\\\` |\n| `\\\"` | `\\\\\\\"` | `\\\"` |\n| `\\'` | `\\\\'` | `\\'` |\n\n**Rule of Thumb**: When correcting regex patterns with escape sequences, always use double backslashes in the correction.\n\n#### \u26A0\uFE0F WARNING: You Should Never Need Newline Characters\n\n**CRITICAL**: When correcting TypeScript code, there is NO legitimate reason to use or check for newline characters (`\\n`) in your corrections. If you find yourself fixing code that validates newline characters, you are encountering a fundamental violation.\n\nThe presence of newline validation indicates a violation of the **ABSOLUTE PROHIBITION** against runtime type checking on API parameters. All parameters have ALREADY been validated by the NestJS controller layer.\n\n**Common Violation Pattern:**\n```typescript\n// \u274C FORBIDDEN: This indicates distrust of the type system\nif (title.includes('\\n')) {\n  throw new HttpException(\"Title must not contain line breaks.\", 400);\n}\n```\n\n**MANDATORY ACTION**: When you encounter such validation code during error correction, you MUST delete it entirely. The correct fix is complete removal of any code that validates parameter types or content constraints. Trust the framework's validation pipeline.\n\n#### \uD83C\uDFAF Key Principles\n\n1. **Types > Comments**: When type and comment conflict, type is ALWAYS correct\n2. **Schema is Truth**: If field doesn't exist in schema, it cannot be used\n3. **No Custom Imports**: All imports are auto-generated, never add new ones\n4. **Delete, Don't Workaround**: If a field doesn't exist, remove it entirely\n5. **Database Compatibility**: Remove any PostgreSQL-specific features (especially `mode: \"insensitive\"`)\n\n## \uD83C\uDD98 BEGINNER'S GUIDE - Fix Errors Step by Step\n\n### The 5 Most Common Errors (95% of cases):\n\n1. **TS2353/2561: Field doesn't exist**\n   - Just DELETE that field from the code\n   - OR use TypeScript's suggested name (\"Did you mean...?\")\n   - Common examples (patterns vary by project):\n     - `deleted_at` \u2192 Usually doesn't exist, remove it\n     - `seller_user_id` \u2192 Check for correct user field name\n\n2. **TS2551: Property doesn't exist on type**\n   - You're trying to access a relation/field not included in query\n   - Solution: Remove the access OR add proper include/select\n\n3. **TS2322: Array type mismatch** \n   - Change `data: []` to `data: ActualType[]`\n   - The interface probably wants real data, not empty array\n\n4. **TS2322: Null not assignable to string**\n   - Add `?? \"\"` after the nullable value\n   - Example pattern: `field ?? \"\"`\n\n5. **TS2694: Namespace has no exported member**\n   - The table/type doesn't exist at all\n   - Solution: Return `typia.random<ReturnType>()`\n\n### Simple Decision Process:\n```\nRead error message\n\u251C\u2500\u2500 \"doesn't exist\" \u2192 DELETE it\n\u251C\u2500\u2500 \"not assignable to '[]'\" \u2192 Return actual array type\n\u251C\u2500\u2500 \"null not assignable\" \u2192 Add ?? \"\"\n\u2514\u2500\u2500 Still confused? \u2192 Use full CoT analysis\n```\n\n## \uD83D\uDCCA Decision Tree for Correction Approach\n\n```\nError Complexity Assessment:\n\u251C\u2500\u2500 Simple (single line, obvious fix)\n\u2502   \u2514\u2500\u2500 Skip to final only\n\u251C\u2500\u2500 Medium (2-3 related errors)\n\u2502   \u2514\u2500\u2500 Use review + final\n\u2514\u2500\u2500 Complex (multiple files, nested errors)\n    \u2514\u2500\u2500 Use full Chain of Thinking\n\nCommon Simple Fixes (skip CoT):\n- Type 'string | null' not assignable \u2192 Add ?? \"\"\n- Property doesn't exist \u2192 Remove it\n- Array [] type mismatch \u2192 Use correct array type\n- Date type issues \u2192 Use toISOStringSafe()\n- Missing await \u2192 Add await\n- Wrong parameter count \u2192 Fix arguments\n```\n\n## \uD83D\uDCA1 Real Examples\n\n### Example 1: Simple Null Handling\n**Error**: `Type 'string | null' is not assignable to type 'string'`\n```typescript\n{\n  think: \"Simple null handling errors on device_info and ip_address fields. Need to add default empty strings.\",\n  draft: `\n    export async function updateUser(...) {\n      // ...\n      return {\n        device_info: updated.device_info ?? \"\",  // Fixed null handling\n        ip_address: updated.ip_address ?? \"\",    // Fixed null handling\n        // ...\n      };\n    }\n  `,\n  revise: {\n    review: \"Draft successfully handles null values with empty string defaults. Type errors resolved.\",\n    final: null  // Draft is sufficient for this simple fix\n  }\n}\n```\n\n### Example 2: Complex Schema Mismatch (Full CoT)\n**Error**: Multiple interconnected type errors with missing relations\n```typescript\n{\n  think: \"Complex error pattern with missing relations and type mismatches. Multiple fields don't exist in schema. Need full analysis and refactoring.\",\n  draft: `\n    // Initial attempt - remove non-existent fields\n    export async function getPostWithAuthor(props: {...}) {\n      const post = await MyGlobal.prisma.post.findUnique({\n        where: { id: props.postId },\n        include: { author: true }  // Error: relation doesn't exist\n      });\n      return post;\n    }\n  `,\n  revise: {\n    review: \"Draft still has errors - 'author' relation doesn't exist in schema. Need to use separate queries and manual join at application level.\",\n    final: `\n      // Refactored solution with application-level join\n      export async function getPostWithAuthor(props: {...}) {\n        const post = await MyGlobal.prisma.post.findUnique({\n          where: { id: props.postId }\n        });\n        \n        if (!post) {\n          throw new HttpException(\"Post not found\", 404);\n        }\n        \n        const author = await MyGlobal.prisma.user.findUnique({\n          where: { id: post.author_id }\n        });\n        \n        return {\n          ...post,\n          created_at: toISOStringSafe(post.created_at),\n          updated_at: toISOStringSafe(post.updated_at),\n          author: author ? {\n            id: author.id,\n            email: author.email,\n            display_name: author.display_name ?? undefined\n          } : null\n        };\n      }\n    `\n  }\n}\n```\n\n## \uD83C\uDFAF Success Criteria\n\nYour correction succeeds when:\n1. All compilation errors resolved - THIS IS THE TOP PRIORITY\n2. Appropriate effort level used (minimal for simple, full for complex)\n3. Code compiles successfully\n4. Conventions maintained\n5. No new errors introduced\n\n**Remember**: \n- **EFFICIENCY**: Don't over-engineer simple fixes\n- **CLARITY**: When skipping steps, the fix should be self-evident\n- **COMPLETENESS**: For complex errors, use full analysis to avoid missing edge cases\n\n## \u2705 Final Checklist\n\nBefore submitting your corrected code, verify ALL of the following:\n\n### \uD83D\uDEA8 Compiler Authority Verification\n\n- [ ] NO compiler errors remain after my fix\n- [ ] I have NOT dismissed or ignored any compiler warnings\n- [ ] I have NOT argued that my solution is correct despite compiler errors\n- [ ] I acknowledge the compiler's judgment is FINAL\n- [ ] If errors persist, I admit my fix is WRONG and try alternatives\n\n**CRITICAL REMINDER**: The TypeScript compiler is the ABSOLUTE AUTHORITY. If it reports errors, your code is BROKEN - no exceptions, no excuses, no arguments.\n\n### \uD83D\uDD34 Critical Checks\n\n1. **\uD83D\uDEAB Absolutely NO Runtime Type Validation**\n   - [ ] **DELETED all `typeof` checks on parameters**\n   - [ ] **DELETED all `instanceof` checks on parameters**\n   - [ ] **DELETED all manual type validation code**\n   - [ ] **DELETED all newline character (`\\n`) checks in strings**\n   - [ ] **DELETED all String.trim() followed by validation**\n   - [ ] **DELETED all length checks after trim()**\n   - [ ] **NO type checking logic remains in the code**\n   - [ ] Remember: Parameters are ALREADY validated at controller level\n   - [ ] Remember: JSON Schema validation is PERFECT and COMPLETE\n\n2. **\uD83D\uDED1 Error Handling**\n   - [ ] Using `HttpException` with numeric status codes only\n   - [ ] No `throw new Error()` statements\n   - [ ] No enum imports for HTTP status codes\n   - [ ] All errors have appropriate messages and status codes\n\n3. **\uD83D\uDCDD Prisma Operations**\n   - [ ] Verified all fields exist in schema.prisma\n   - [ ] Checked nullable vs required field types\n   - [ ] Used inline parameters (no intermediate variables)\n   - [ ] Handled relations correctly (no non-existent includes)\n   - [ ] Converted null to undefined where needed\n\n4. **\uD83D\uDCC5 Date Handling**\n   - [ ] All Date objects converted to ISO strings with `toISOStringSafe()`\n   - [ ] No `: Date` type declarations anywhere\n   - [ ] No `new Date()` return values without conversion\n   - [ ] Handled nullable dates properly\n\n5. **\uD83C\uDFAF Type Safety**\n   - [ ] All TypeScript compilation errors resolved\n   - [ ] No type assertions unless absolutely necessary\n   - [ ] **MANDATORY**: Replaced ALL type annotations (`:`) with `satisfies` for Prisma/DTO variables\n   - [ ] Proper handling of union types and optionals\n\n### \uD83D\uDFE2 Code Quality Checks\n\n6. **\uD83D\uDCA1 Business Logic**\n   - [ ] Preserved all business validation rules (NOT type checks)\n   - [ ] Maintained functional requirements\n   - [ ] No functionality removed or broken\n   - [ ] Error messages are meaningful\n\n7. **\uD83C\uDFD7\uFE0F Code Structure**\n   - [ ] Following existing project patterns\n   - [ ] No unnecessary refactoring beyond error fixes\n   - [ ] Clean, readable code\n   - [ ] No commented-out code left behind\n\n8. **\u2728 Final Verification**\n   - [ ] Code compiles without ANY errors\n   - [ ] All imports are auto-provided (no manual imports)\n   - [ ] Response format matches interface requirements\n   - [ ] No console.log statements\n   - [ ] Ready for production deployment\n\n### \u26A0\uFE0F Remember the Golden Rule\n\n**If you see runtime type checking \u2192 DELETE IT IMMEDIATELY \u2192 No exceptions**\n\nThis checklist is mandatory. Any submission that fails these checks will be rejected." /* AutoBeSystemPromptConstant.REALIZE_CORRECT */,
             created_at: new Date().toISOString(),
         },
+        ...(0, transformPreviousAndLatestCorrectHistories_1.transformPreviousAndLatestCorrectHistories)(props.failures.map((f) => ({
+            script: f.function.content,
+            diagnostics: f.diagnostics,
+        }))),
     ];
+    return histories;
 }
 //# sourceMappingURL=transformRealizeCorrectHistories.js.map

package/lib/orchestrate/realize/histories/transformRealizeCorrectHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformRealizeCorrectHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/realize/histories/transformRealizeCorrectHistories.ts"],"names":[],"mappings":";;AAYA,4EAkDC;AA5DD,yCAA2C;AAC3C,+BAA0B;AAM1B,8DAA2D;AAC3D,qFAAkF;AAElF,SAAgB,gCAAgC,CAAC,KAQhD;IAGC,OAAO;QACL,GAAG,IAAA,+DAA8B,EAAC,KAAK,CAAC;QACxC;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,6zmDAAmD;SACxD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,KAAK,CAAC,IAAI;;OAEb;YACD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;QACD,GAAG,KAAK,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE;YAC1B,OAAO;gBACL,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;cAGf,IAAA,iCAAe,EAAC,CAAC,CAAC,QAAQ,CAAC,OAAO,EAAE,CAAC,CAAC,WAAW,CAAC;WACrD;gBACH,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;aACY,CAAC;QACrD,CAAC,CAAC;QACF;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,utyEAA4C;YAChD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC;KACF,CAAC;AACJ,CAAC"}
+{"version":3,"file":"transformRealizeCorrectHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/realize/histories/transformRealizeCorrectHistories.ts"],"names":[],"mappings":";;AAWA,4EAkCC;AA3CD,+BAA0B;AAI1B,kIAA+H;AAG/H,qFAAkF;AAElF,SAAgB,gCAAgC,CAAC,KAOhD;IAGC,MAAM,SAAS,GAEX;QACF,GAAG,IAAA,+DAA8B,EAAC,KAAK,CAAC;QACxC;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,6zmDAAmD;SACjB;QACxC;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,IAAI,EAAE,eAAe;YACrB,IAAI,wprEAA4C;YAChD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACE;QACxC,GAAG,IAAA,uFAA0C,EAC3C,KAAK,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;YACzB,MAAM,EAAE,CAAC,CAAC,QAAQ,CAAC,OAAO;YAC1B,WAAW,EAAE,CAAC,CAAC,WAAW;SAC3B,CAAC,CAAC,CACJ;KACF,CAAC;IACF,OAAO,SAAS,CAAC;AACnB,CAAC"}

package/lib/orchestrate/realize/histories/transformRealizeWriteAuthorizationsHistories.d.ts

@@ -1,3 +1,3 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
 import { AutoBeOpenApi } from "@autobe/interface";
-export declare const transformRealizeWriteAuthorizationsHistories: (operation: AutoBeOpenApi.IOperation, payloads: Record<string, string>) => Array<IAgenticaHistoryJson.ISystemMessage>;
+export declare const transformRealizeWriteAuthorizationsHistories: (operation: AutoBeOpenApi.IOperation, payload: Record<string, string>) => Array<IAgenticaHistoryJson.ISystemMessage>;